You may have noticed some updates to the design lately, they are part of a SE network-wide update to a new base css framework.
The updates allow us to:
But more importantly, it gives you access to the new profile!
If you see any bugs please let us know in the form of answers (to this post) that illustrate one particular thing at a time.
Thanks!
status-completed We've got rid of Lucitana font and replaced it with Georgia. We haven't changed font size yet, only font face, because we want to see how this gonna work and if it's enough. You will see updated font with upcoming build on production.
A bunch of places have acquired inconveniently tiny text as a result of Lucitana becoming the standard body font at 12px. It's an unusually tiny font; its 12px is more like 9½px. The newly ensmallened text going to prove hard to read for some people, it's uncharacteristically tiny for a Stack Exchange page, and in some places it looks kinda ugly. Wherever it's bolded, the individual characters turn a bit blobby and become harder to distinguish from each other.
We could benefit from Lucitana being bumped up to 14px, or switching to Georgia for the main body font.
It becomes clear here that Lucitana's so tiny it's losing fidelity: the 'e' is missing its gap, the 't' and 'x' are getting wonky, and combinations like 'Fi' (the very last sentence in the last linked post) just look weird.
If it's set to Georgia, the font used for posts like the one you're reading right now, it's far more legible and looks much better:
Other impacted spots that could definitely do with larger text:
Here's an example of the overlarge comment-entry 'x':
font-size-adjust to set font size by the x-height of the fonts, if there is concern about making fallback fonts explode in size.
\$\endgroup\$
Nov 23, 2015 at 20:35
status-completed It's now fixed as of April 1.
Questions with favorited tags are no longer being highlighted.
It's difficult to get a good screenshot of this, but it's easy to check.
rev 2016.3.23.3373, which is a build date after your comments and [status-completed] edit above, but I'm still not seeing favourites highlighting. Did the fix get into a later build, or is the fix in but not working?
\$\endgroup\$
Mar 24, 2016 at 6:28
rev 2016.3.25.3379.
\$\endgroup\$
Mar 25, 2016 at 19:32
status-completed It's now fixed and will be live after our next production build.
Post score and vote/favourite buttons are visually misaligned. Assuredly a minor issue, but it stands out. It's one of those “can't unsee it” things once you notice it.
The visual vertical passes to right of centre of the zero here:
With numbers like seven which don't fill much of the right-hand side of their bounding box the visual vertical misalignment is exaggerated:
Though these screenshots are taken from Win7/Firefox, the same alignment is present on iOS Retina displays.
Additionally the numbers are closer to the upvote arrow than the downvote arrow. The issue is fairly pronounced on meta, less so on main.
status-completed It's now fixed and will be live after our next production build.
The gray doesn’t stand out well against the paper-y background. It used to be yellow, and more importantly had a border so it stood out.
#eee to an averaged sample of the background beside it of #f3ede2 gives a 1:1 contrast ratio.
\$\endgroup\$
Nov 25, 2015 at 18:57
status-completed It's now fixed and will be live after our next production build.
Our main site's footer links are growing envious of the header and appear to be marching upward for battle.
Please subdue them and put them back in place before a war between the header and footer breaks out and destroys the whole page of content between them!
The meta footer links seem OK for now.
status-completed It's now fixed and will be live after our next production build.
Cross-posted from our existing Q&A on the subject, to ensure it’s seen as part of this update.
p, h1, h2, and h3 all have margin-bottom: 1em; applied. What this means is that, because of their differing font sizes, the margin beneath p is set to 15px, while h1 has 21px, h2 has 19px, and h3 has 17px. As such, all headers are, quite visibly, closer to the preceding paragraph than they are to the paragraph below, i.e. the one they are actually assocated with.
Here’s an example:
This is still quite reversed. All headings should be closer to their associated content than the preceding, not the other way around. As such, 15px should be the maximum margin-bottom on all of the headings, and smaller margins would be appropriate. I understand that there is some matter of preference between equal-distance above and below, versus being closer to the following paragraph, so fine, use 15px if you must: but going above 15px is still terrible.
Here is the same page, but with all margins set to 15px instead of 1em:
Still not a huge fan of that. Note that the margin is calculated from the bottom of the lower extenders (e.g. on the g), not from the base line of the text. As a result, the top of the H is still closer to the preceding paragraph than the bottom of the H is to the following paragraph.
On the other hand, setting the bottom margin on all of the headings to 5px looks quite a lot better in my opinion:
Here, the headings have a clear visual association with the following content (i.e. the content they serve as heading for)
status-completed It's now fixed and will be live after our next production build.
Post score text colour is technically identical to the outer-rim colour of the vote buttons (#777), but because visual colour bleed disproportionately affects thin shapes, the number's colour looks too pale beside the buttons and doesn't visually match.
The text colour looks about right around #555. Here's a before and after shot, with post score as color: #777 (current) on left and color: #555 (tweaked) on the right:
The 4 on the right looks much more assertive of its existence and right to stand among those design elements than the ghostly 4 on the left.
Other grey text on the page has this “being ghostly” issue too, but only the post score and the favourites count are so close to a non-text element using the technically-same but visually-different grey value that in comparison they look like a different colour.
Compare with here on meta, where text of colour #777 nicely visually matches the lighter button colour of #9ea0a4.
status-completed It is now fixed and will be live after production build.
If you put a list inside a quotebox (i.e. start each bullet point with >*), you get an awkward empty space beneath the list, but still in the quotebox:
The margin above and below the list inside the quotebox should be the same. Most likely a LESS rule something like this:
ol, ul {
#:last-child, li:last-child {
margin-bottom: 0;
}
}
is the appropriate fix. That would look like this:
Because of the extender on the 3 there, it looks like a small space may be appropriate, but I still like this much better than the combined 1.5em of final list item and list.
(Maybe Chrome too? I don't know, I haven't tested that one.)
I have no idea what's causing this. I've never noticed it before even on other sites that have redesigns, but maybe I've just never written big answers on those.
When a post becomes decently big, there starts to be a lot of lag between me typing out a word and it appearing on my screen. I'm a fast typist, and it becomes a big problem for me. It makes it very slow just to correct small typos, since I have to wait for the text area to catch up, and then I have to wait for it to process my backspacing, and then I start typing again and waiting for it to catch up.
I installed gifcam to record this happening. The gifs are accurate and real time, the lag you see is real lag, not a problem with the gif.
There's some jerkiness at the very end of that laggy one: I end up highlighting some text somehow at the end while trying to scroll the text area in a very laggy Firefox. The lag isn't jerky though. The text I jammed out in that last gif? I did it by just bashing all the keys rapidly for a few seconds, and then I sat and waited a while for the text entry to slowly fill up with that text.
Visited tags are displayed with the link color, rather than the standard link appearance: tag-you-probably-havent-visited will be grey right now, but when you visit it, it'll turn gold here, or red on main site. If you clicked that too soon, try this-other-unique-one or delete the page for one of these made up tags from your history.
It doesn't show up this way in post previews, which are always just grey, regardless of visited-ness. That's how it used to be, so this changed during the redesign.
This affects the appearance when visiting a tag without a tag wiki:
Apparently this might just be a feature of the redesign though, since it occurs this way too on Meta Stack Exchange:
(usual tag appearance is grey)
It's great that the site notice is no longer broken, but it still doesn't look as nice as it was originally designed to look.
Current site notice appearance:
What the site notice could look like, with a few CSS tweaks:
I realize that this is a minor detail, and most users will never see it anyway. But it would still be kind of nice to have.
Vote numbers in the close vote dialog are extremely tiny.
Like, this tiny: 1 2 3 4, vs regular size: 1 2 3 4.
They're sized at 10px in the vote dialog, while the text around them is 13.65px. The 10px would probably be fine on other sites, but Georgia uses lowercase numerals. (Which is awesome. I wish more fonts did that.)
I think they were still pretty small before, but either I've only really noticed how small now, or they've become smaller during the redesign.
As SSD points out in comments, this also affects our featured count:
status-completed It's is fixed now.
The icons are stretched and cut off along the bottom using Chrome version 46.0.2490.86 (64-bit) on a 15-inch retina macbook pro, though it seems to occasionally correct itself. Safari and Firefox both seem fine so it's possibly more-so a problem on my end since we do have a lot of internet troubles at work.
It also works fine on my iPad mini and windows PC at home. Have not checked my laptop at home yet.
Our Filter button in the review queues is floating away. Not sure if this is a big deal?
RPG.SE:
vs Meta.SE, where it's at least sorta in line with the heading:
