- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Mar 2021 09:49:35 +0000
- To: public-css-archive@w3.org
> Here are some topics and my proposals for the next meeting. Please add more if needed. > > 1. Are characters stretched/resized/etc when `advance-override` is applied? > > Proposal: no. It has no effect for the purpose of reducing layout shift, but adds a lot of complexity to spec and implementation. If using `advance-override` severely affects legibility, then it's better to just use a more similar fallback font. Agreed, no. `advance-override` doesn't touch glyph images, only spacing. (I think there should be a separate `font-size-override` that can apply a scale factor to the used font size; I suspect this would often be the better tool to use.) > 1. How is spacing added to each character? > > Proposal: spacing is added after each character, for the reasons I gave in [#5983 (comment)](https://github.com/w3c/csswg-drafts/issues/5983#issuecomment-777934132) for reasons. Disagree; I think spacing should be added equally on both sides of each glyph. Adding it asymmetrically (as some current letter-spacing implementations do) is often visually inferior IMO, particularly at run boundaries. In general this feature should not be used to insert (or remove) more than a small percentage of the glyph width -- if you need more than that, you're using a bad choice of fallback font, or should be using `font-size-override` (see above) to completely re-scale it rather than just munging the spacing. > 1. What's the default value of the second parameter, and what's the exact syntax? > > Proposal: Use two descriptors `advance-width-override` and `advance-height-override` separately. This seems the cleanest among all the ideas I came up with. > > Other ideas: > > * `normal | [ <percentage> <percentage> ]` as [currently specified](https://drafts.csswg.org/css-fonts-5/#descdef-font-face-advance-override). In other words, second parameter is the same as the first if unspecified. > > * `[normal | <percentage>] [normal | percentage]?`. In other words, it has no override to upright vertical text if the second parameter is not explicitly given. I don't have a strong preference among these options. I think I'd lean towards either the first (separate width/height descriptors) or the third (second param defaults to `normal`, so no height override unless explicitly given), as most authors won't be thinking about vertical layout at all unless it's their primary focus, and there's little reason to expect that the *same* amount of override will make sense for both axes. > 1. Add spec text to avoid over-promising. This includes: > > * It can't fully eliminate layout shift, unless the font is monospaced > * It may not work on certain cursive/complex scripts, [similar to `letter-spacing`](https://drafts.csswg.org/css-text-3/#cursive-tracking) +1 to mentioning that it may not work well with cursive/complex scripts. However, I think we should *not* have spec text (like for `letter-spacing`) saying this doesn't apply to joined scripts, or anything "sophisticated" like that. This is equivalent to loading the font resource into a font editor and adding/removing sidebearings on each glyph to change its advance by a given percentage. Whether/how those glyphs interact with each other is not our concern here. This is an operation at the level of glyphs, not Unicode scripts/characters. By all means include a warning for authors about applying this to glyphs that are supposed to visually join, but if an author nevertheless chooses to do so, they can. (I have seen old printed examples from lead-type days of `letter-spacing`-like effects in what would usually be joined scripts. Whether it's a good idea is not for us to say.) If an author wants to (for example) use Arial as a fallback, with `advance-override` applied to its Latin letters but not to Arabic, they can do that by using `unicode-range` to spread it across a couple of `@font-face` rules, applying different descriptors to the different blocks of characters. -- GitHub Notification of comment by jfkthame Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5983#issuecomment-788776441 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 2 March 2021 09:49:37 UTC