Page MenuHomePhabricator

Avoid blurred icons and pixel rounding errors by settling on unified font size
Closed, ResolvedPublic

Description

Otherwise you get blurry icons and other pixel rounding errors.

See also: T97631 & T138734

Event Timeline

Esanders created this task.Jun 16 2017, 8:01 PM
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptJun 16 2017, 8:01 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Esanders updated the task description. (Show Details)Jun 16 2017, 8:02 PM

Change 359620 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[mediawiki/core@master] RCFilters: Adjust font size to fit UI standard

https://gerrit.wikimedia.org/r/359620

Mooeypoo added a comment.EditedJun 16 2017, 9:48 PM

The new size is only implemented on the RCFilters section, and not the results list. The results list will continue to have the same size as the nojs version (font size of the content container)

Comparison

Before (text/icons with content size; fuzzy icons)After (text/icons with standard UI size; crisp icons

Full size comparison:

Before:

After:

Avoiding blurriness in icons and having more consistent font sizes sounds good to me. However, diverging from the content font size to go for 12.8px which is smaller and using fractions of a pixel may not be ideal either. There may be other approaches to avoid the blurriness of the icons and pixel rounding errors.

@Volker_E and @RHo have been working around the areas of font sizes and icons. They may be interested in contribute to a general proposal in those areas that could work well across different products.

@matmarex commented on the Gerrit task that "We should be moving in the opposite direction :(", but then voted +1. I'm puzzled by that and generally not sure what the right way forward is here, so maybe let's figure that out first before we change the font size?

Yes. I gave it a +1 because it is an improvement to the interface. But it is adding more technical debt.

RHo added a comment.Jun 23 2017, 11:23 AM

@Volker will likely have more insight when he's back next week, but agree with @Pginer-WMF that going to a smaller fractional font-size is not ideal.
My initial thought was that blurriness should be fairly minimal if the SVG version of an icon is being used, so perhaps the extent that icon blurriness is an issue could first be reviewed? Weighing the pros & cons, it seems increasing the clarity slightly on some icons would be less beneficial than the more noticeable effect of a change that reduces text legibility [1].
Rather than change the text display to accommodate icon blurriness, can we instead decouple the relationship between the icon sizing from font-size?

[1] Much has been written about optimal sizes for reading on web, with consensus towards using body text at 1em (16px); so it would not be recommended to reduce it even further from this value. A few example sources are: W3C; Practical Typography ; Google Developers; SmashingMagazine.

My initial thought was that blurriness should be fairly minimal if the SVG version of an icon is being used, so perhaps the extent that icon blurriness is an issue could first be reviewed? (...)
Rather than change the text display to accommodate icon blurriness, can we instead decouple the relationship between the icon sizing from font-size?

Even with a vector icon, eventually you have to display it on a screen composed of square pixels. If the shapes line up exactly with those one-pixel squares, you get a crisp picture. If they don't, you get a blurry one. (If you're using a device with a Retina screen or similar, the effect is also less noticeable; if your own machine is too good, I'm sure OIT have some worse one they could lend ;) .)

How noticeable the effect is depends on the icon – icons with vertical and horizontal lines are affected the most, icons with diagonal lines or circular shapes are affected less since they are inherently "blurry" – but as you can see in the screenshots above (T168089#3356146), the effect is very visible sometimes. Look at the icon on the "Namespaces" button specifically. (Yes, that is using a vector SVG icon.)

Our icons can be displayed at any size, but due to the nature of screens, they look the best at the size they were designed at (or integer multiples of it).

Anyway, my point is that someone should be working on T97631 instead, so that we can display our existing icons at their natural size inside our existing website without changing font sizes all over the place manually.

Also, I feel I need to explain the confusing 12.8px and 14px sizes. To be clear, no one is proposing changing the size of the actual text. We only want to make the icons approximately 2 pixels smaller. :)

  • Our icons are designed at 24x24px.
  • In order to allow them to be used in text using any font size, their actual dimensions are set in em units, e.g. width: 1.875em;.
  • The values are chosen so that when used in text with font-size: 12.8px (equivalent to font-size: 0.8em), the icons display at 24x24px (12.8×1.875=24). Vector used that font size prior to the "Typography refresh" initiative, back when the icons were designed.
  • Because Vector is now using font-size: 14px (equivalent to font-size: 0.875em), the icons sizes calculate to 26.25px. This slight resizing is what's causing this blurriness.
RHo added a comment.Jun 23 2017, 12:01 PM

Also, I feel I need to explain the confusing 12.8px and 14px sizes. To be clear, no one is proposing changing the size of the actual text. We only want to make the icons approximately 2 pixels smaller. :)

Ah OK, I think there was confusion on my side since in the examples shown, text connected to icon elements have been reduced in size (e.g., filter tags, icon+button text) as have the actual component sizes (e.g., height of the filter tags, button height).

Anyway, my point is that someone should be working on T97631 instead, so that we can display our existing icons at their natural size inside our existing website without changing font sizes all over the place manually.

+1

Actually we are dealing with three base font-sizes in our OOjs UI universe: 12.8px as VE and OOjs UI default, 14px for everything in MW core, where OOjs UI is used, like RCFilters, Special Pages and things like API Sandbox or UploadWizard and 16px for OOjs UI usage in MobileFrontend.
Blurry icons are not good, but going for more technical debt instead of converging VE/Edit interface with MW core at 14px in T97631 is the wrong way, both from a technical and a UX perspective.

Actually we are dealing with three base font-sizes in our OOjs UI universe: 12.8px as VE and OOjs UI default, 14px for everything in MW core, where OOjs UI is used, like RCFilters, Special Pages and things like API Sandbox or UploadWizard and 16px for OOjs UI usage in MobileFrontend.
Blurry icons are not good, but going for more technical debt instead of converging VE/Edit interface with MW core at 14px in T97631 is the wrong way, both from a technical and a UX perspective.

The Edit/VE size is the MediaWiki content size. If you're going to change VE, you'll need to change that too. That's a really major breaking change to the way the Monobook/Vector skins display for readers, and really should be justification for holding up this issue.

The Edit/VE size is the MediaWiki content size.

Is that actually the case?

Mediawiki content seems to compute to 14px font size:

Some Mediawiki UI elements such as the sidebar menu items seem to compute to a 12px font size:

Visual Editor UI elements seem to compute to 12.8px font size:

I don't know which is the rationale for using a 12.8px font in VE's UI, but in terms of consistency with other Mediawiki font sizes, this seems to be the outlier. Given the above, I'd not expect that moving from 12.8px to 14px font size would result in a major breaking change since it would align the text to a size already in use.

May I guess without complete historical context:
The font-size of VE's toolbar oriented on vectorTabs links – 12.8px:

That's a modification of VE's interface with font-size: 0.875em which translates to 14px with only one amendment of toolbar margin:


Difference in toolbar height, again, no special amendment yet is 41px vs 45px.

I don't know which is the rationale for using a 12.8px font in VE's UI, but in terms of consistency with other Mediawiki font sizes, this seems to be the outlier. Given the above, I'd not expect that moving from 12.8px to 14px font size would result in a major breaking change since it would align the text to a size already in use.

The main reasons are VE pre-dates the typography refresh, and 12.8 is also the size of the Vector toolbar. That said the toolbar is mostly icons.

Change 359620 abandoned by Mooeypoo:
RCFilters: Adjust font size to fit UI standard

Reason:
A more thorough font-size fix is coming with an upcoming OOUI release

https://gerrit.wikimedia.org/r/359620

I think this is entirely fixed (or rather made invalid) by the patches on T97631. Font size remains at 14px (on Vector; it remains at 12.8px on MonoBook) and all of the icons look sharp.

Volker_E renamed this task from Use 12.8 instead of 14px font size to Avoid blurred icons and pixel rounding errors by settling on unified font size.Mar 24 2018, 12:31 AM
Volker_E removed Mooeypoo as the assignee of this task.
Volker_E triaged this task as Normal priority.
Volker_E removed a project: Patch-For-Review.
Volker_E added a subscriber: Mooeypoo.
Volker_E closed this task as Resolved.Mar 24 2018, 12:34 AM
Volker_E claimed this task.

Being bold here and declare this resolved, after updating the task description slightly. The icons are crisp, the interface elements are harmonized in size and appearance. A few open patches, only closely related to the general task here. \o/