- From: Tobi Reif via GitHub <sysbot+gh@w3.org>
- Date: Fri, 13 Apr 2018 10:01:41 +0000
- To: public-css-archive@w3.org
There are many current options:
a) Compensating for the cross-OS differences:
eg
```
if (navigator.platform.startsWith("Win")) {
var h1 = document.querySelector("h1");
h1.style.marginTop = "-0.25em";
h1.style.marginBottom = "0.15em";
}
```
A hack.
b) Replacing each respective text with SVG:
A hack. (And some might fear that it might impact eg search engine visibility, and it might also impact accessibility, see https://www.google.com/search?q=svg+text+screen+readers .)
c) Fixing each font:
> Currently, the most practical approach to fix this seems to be to edit the font data and synchronize these different platform-specific *ascent and *descent metrics (e.g. the FontSquirrel's web font generator has the "Auto-Adjust Vertical Metrics" option in the Expert mode, and you can always adjust them manually with a font-editing tool like FontForge as a last resort).
Not efficient. A client pays me to do web dev, not for fixing each font I use 😀 Also, have you looked at the license of commercial web fonts? If I remember correctly, some do not allow any modifications. Oh, and many web developers (unfortunately) insist on having their web fonts hosted eg by Google - in that setup they couldn't fix the fonts either.
Given all of the above we need a solution.
In Chrome's SVG implementation for example there is *no* difference regarding the vertical positioning of the large-text glyphs across the main OSs. This shows it's completely feasible for browsers to not mess up large-text based layouts. That's all I want. Fixing this for medium/large text in all browsers would break existing websites, thus it must be opt-in → a new property / keyword.
> I also have a mixed feelings about adding the possibility to override the font metrics in CSS.
You don't have to think of it as telling the browser to "override the font metrics in CSS" - it could just as well be viewed as "don't break my large-text based layout, instead simply do what you do with SVG text".
The browser can do it for SVG text (even when the most problematic fonts are used), it sure can do it for HTML text as well.
> While there clearly can be valid use cases for this, especially for decorative fonts and icon fonts
No, the issue occurs quite often in my experience, and the solution would apply for all medium/large text (by far not just decoration glyphs or icon glyphs) because in most/many cases, medium/large HTML text gets positioned differently across OSs. Please see the thread above, it includes various test-pages and screenshots, andI often have to apply hacks, and @jonjohnjohnson lists a hack, and anyone who uses large text in their layouts can run into the issue.
> it still seems to be kind of a hack
The reality is ugly: Many fonts seem to be messed up, and browsers often mess up large-text based layouts across OSs. Currently we need to apply hacks. Fixing each font is not feasible. So we do need a solution. I don't see why browsers shouldn't be able to ensure consistent cross-OS glyph positioning if they can do it for SVG. (The cleaner option would be for browsers to fix their HTML text rendering to match their SVG text rendering, but that would break content, thus a new opt-in property/keyword is required.)
> overusing this hack can have too unpredictable consequences
Luckily, the opposite would be the case: Test on one OS, then predictably get the same consistent glyph-positioning on all other platforms.
> Especially in the situation where only some browsers support it correctly, which, unfortunately, is so typical for most new CSS features...
Yes sure, a new feature must get implemented widely before we can use it 😀That's the case for every other new property/keyword/feature as well. And look at eg Grid - it's a whole new layout spec and it got implemented in an incredibly concerted way. Inside a pretty small timeframe every single modern browser announced support for Grid. Implementing one new property could be much faster.
--
GitHub Notification of comment by tobireif
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2228#issuecomment-381088354 using your GitHub account
Received on Friday, 13 April 2018 10:01:44 UTC