[css-text-decor] Add auto value for text-decoration-skip:

[drott]

I'd like to pick up and second Theresa's proposal to add an auto value to the
text-decoration-skip.

Quoting from the original post:

The initial value of text-decoration-skip' is currently objects'.
However, the default platform text decoration behavior on OS X and iOS
is equivalent to `ink'. We'd like to be able to match the system
behavior by default in WebKit.

I propose we add an auto' value to text-decoration-skip'. While its
definition would give UAs broad leeway, the spec should have a
non-normative note encouraging UAs to match platform conventions for
`auto'.

Once text-decoration-skip: auto' is defined, we should change the initial value of text-decoration-skip' to be `auto'.

A quick check in Safari shows that the value of webkit-text-decoration-skip: is now auto by default, and none disables it.

[drott]

CC @kojiishi, @hober

[kojiishi]

@upsuper I think you were positive in a comment in #711?

[upsuper]

Yes. But in addition to the proposal, I think it should have normative text requires it to match a given value combination (presumably the current default value objects), and only leave ink to be impl-dependent.

Actually that makes me wonder whether we actually should have a different property for ink-skip, rather than having it in the same property as other values. And also as I said in #711, the ink-skip should probably not inherit by default if we want it to apply on all types of decoration line.

[FremyCompany]

(adding myself to the conversation to keep track of progress; no strong opinion here)

[litherum]

cc @litherum

[fantasai]

I think that if a UA wants to skip ink, it should simply add that to the UA default style sheet. That's what UA default stylesheets are for. See also previous comment on this: https://www.w3.org/mid/[email protected] https://lists.w3.org/Archives/Public/www-style/2016Dec/0088.html Is there a problem with this approach? ~fantasai

[frivoal]

I responded to the older mail thread before noticing this github thread. Reposting here.

---

Text decoration level 4 also wants to add more than just objects to the initial value. It calls or objects leading-spaces trailing-spaces.

It makes sense to me to combine the two, and aim for objects leading-spaces trailing-spaces ink as the default.

I think whether we should do so by having a verbose initial value, introducing an auto value, or going via the UA stylesheet, can be informed by trying to solve one other problematic aspect of this property. Essentially, it is a list of independent toggles, but you cannot easily add or remove one while keeping whatever else would be there intact.

Say I want to add leading-spaces and trailing-spaces to the default behavior, and put this in my author stylesheet:

:root { text-decoration-skip: objects leading-spaces trailing-spaces; }

Bam, I've just accidentally killed safari's by-default ink-skipping that I wasn't even aware of.

Or say I go the other way around, and like safari's by-default ink-skipping and add it to my author stylesheet to do the same in other browsers. Now if/when browsers add leading-spaces and trailing-spaces to the default value, I miss out.

Similarly, say I want to remove object-skipping for a particular element, <del> for example how do I do that if I don't want to affect whatever else was being skipped, whether it came from default values, UA styles, or some other style I wrote myself?

I think the only precedent we have for this is the font-variant property, which is also a list of switches. If we apply the same model to text-decoration-skip, we'd have something like this (verbosity and bikesheding aside):

longhands:

text-decoration-skip-objects: none | objects
text-decoration-skip-spaces: none | [leading-spaces || trailing-spaces] | spaces
text-decoration-skip-ink: none | ink
text-decoration-skip-edges: none | edges
text-decoration-skip-box-decoration: none | box-decoration

shorthand:

text-decoration-skip: none | auto |
                     [
                       objects ||
                       [ spaces | [ leading-spaces || trailing-spaces ] ||
                       ink ||
                       edges ||
                       box-decoration
                     ]

none sets all longhands to none, auto is the initial value, and sets longhands to something smart (object ink leading-spaces trailing-spaces?), and other values are passed to through to the corresponding longhands and set all others longhands to none.

Alternatively, since we have no compat baggage to worry about and we would want authors to use these longhands to avoid the traps I mentioned at the beginning, maybe the shorthand should only have none and auto.
Actually I think I'd prefer that. Here's a possible bikesheeding:

text-decoration-skip: none | auto

text-decoration-skip-objects: none | all
text-decoration-skip-spaces: none | [leading || trailing] | all
text-decoration-skip-ink: none | all
text-decoration-skip-edges: none | all
text-decoration-skip-box-decoration: none | all

I know that's a breaking change and the spec is already in CR, but if you all agree it's a good idea, I wouldn't feel bad about doing it given the lack of implementations.

PS: the [leading || trailing] part could only be in level 4, but the rest should go in level 3 if we want to do it at all.

[fantasai]

Note that making the L4 compound initial value easier to specify and combine with other author preferences is a different issue from whether the initial value is allowed to be a UA-dependent auto value. So which issue is this bug report about?

[frivoal]

I think it is not completely independent, since the if we go along with font-variant-* style longhands to make it easier to toggle individual aspects on and off without resetting everything else, thing work much better with auto as the initial value. Which toggles get on or of can be UA dependent, but that's different from setting that "default" value via the UA stylesheet instead of throught the initial value of the property.

[fantasai]

No, it's independent. Altering the syntax here is a separate consideration from whether the initial value is allowed to be UA-dependent. So again, which issue is this bug about? Making it easier to specify and combine with other author preferences or allowing the UA to change the initial value rather than addressing its preferences through the UA stylesheet?

[drott]

I filed this issue with the aim of allowing a UA-dependent auto value to be a default. I understand the selective toggling issues @frivoal describes, but I do agree that these justify filing a separate issue.

[frivoal]

I am not in favor of different UAs having different initial values (i.e. some using auto, some using objects). I am in favor of a new auto or normal value being introduced and used as the initial value, to represent the default set of things that are on or off without having to name them all explicitly. I would prefer that it mapped to the same set of things being on or off in all browsers, but if we cannot agree on what that should be, I am ok this being UA dependent.

I have filed a separate issue to suggest adding longhands and potentially removing all other values than none and auto from the shorthand.

[kojiishi]

I agree with @drott, #843 is a good issue to discuss separately.

For ink, I'm starting to wonder why this feature is an opt-in design.

• From implementors:
  • WebKit skips ink by default.
  • Blink implements and wish to skip ink by default in near future too.
  • IIUC Gecko is also looking into this. @upsuper, do you think you want to enable by default when Gecko supports?
• From authors:
  • @ebraminio commented he wants to skip ink by default.
  • Some blogs already have text-decoration-skip: ink by default; e.g., this page has a { text-decoration-skip: ink; }.

I think if all these observations are correct, we should:

• Make skip ink the default behavior for supported configurations. For non-supported fonts/OS/UA, not skipping is a good fallback behavior.
• Remove ink from text-decoration-skip.
• Give authors ability to disable skip ink if such feature is desired.
• Give authors ability to force skip ink for undesired cases (e.g., line-through) if desired.

...is this too wild?

[ebraminio]

I was just watching this documentary about release of Netscape as Mozilla project and accidentally found out "text-decoration-skip: ink" was default behavior on those days!

Does anyone remember when text renderers lost this ability and how we didn't notice? :)

IMHO Apple did right thing on bringing it back and I can say having this workarounds issues like this http://crbug.com/569159

Also it is interesting for me to see "skip: ink" on several places of MIT DS course by Erik Demaine but not web browsers!

[frivoal]

@kojiishi
Making ink skipping be part of the default seems totally reasonable to me.

After that, as far as I am concerned, whether we provide means to turn it on or off in addition depends on #843.

[khaledhosny]

I’d like to mention that for some scripts (namely Arabic in my case) ink skipping looks rather ugly in many fonts, specially since WebKit does not use the underline position from the fonts and uses its own hardcoded value which is rather too close to the baseline resulting in many “holes” in the underline which look rather odd (see the screenshots in w3c/alreq#86 (comment)).

[frivoal]

Would ink skipping still look bad if Webkit did use the underline position from the font?

[kojiishi]

Adding a property to specify the underline position is tracked in #459, hope it resolves @khaledhosny's concern.

[khaledhosny]

Would ink skipping still look bad if Webkit did use the underline position from the font?

It might help, but since no browser does this now one can’t be sure. IMHO it is a bit premature to change the default without considering its effect on other scripts. Just my 2¢.

[ebraminio]

Interesting that all my insist about this 1 2 3 was actually about Arabic script. As a Safari user that uses Arabic script sites on everyday basis, IMHO, this actually helps the situation with Arabic script as without it, number of dots on some similar Arabic letters will be less distinguishable (at least with the particular fonts I've used) and I think Kahled can agree with me that with skip: ink, these two valid Persian/Arabic words will be more legible and distinguishable on small and big sizes:

The actual text:

سیب سبب

Safari:

Chrome:

Firefox:

I think the situation with Safari is better and I prefer to use Safari when I use a Macbook actually. The font I used to render these is one of popular Persian web fonts, Iranian Sans that doesn't contain underline position info at all (AFAIK), I guess like many other everyday webfonts.

Anyway, if Khaled don't agree with me on this, I know github.com/w3c/alreq would be a better forum to discuss about it, I couldn't register on its ML yet but I will try with another email. Obviously, I will agree with consensus of its members if they conclude web is better without skip: ink for Arabic, but I don't personally really think so.

[khaledhosny]

@ebraminio they all look equally bad, IMO. I’d expect the underline to be at least below the dots. The font is not giving a good underline position either, so Firefox is not doing any better. In w3c/alreq#86 (comment) at least 3 fonts are performing good to OK with Firefox, while all fonts are performing bad with both Safari and Chrome.

[frivoal]

@khaledhosny Not being an arabic / persian reader, I might be wrong, but it seems to me that in the above example, while they may all be ugly, the safari variant is more legible. Ideally the line should be below the diacritics, but if the font lacks this information, ink skipping seems better for readability, no?

[khaledhosny]

The problem is that many Arabic letters descend below the base line in various ways, so a too high underline (like what Safari or Chrome draw currently) will end up too fragmented and looking ugly, the underline fragments can even get too small that they can be confused for dots or vowel marks. This is clearly seen in the Arabic part of the screenshot in #707 (comment) (it looks a bit better since the underline is in a different color, but a black underline will be much worse). I think the conclusion for CJK in #707 pretty much applies to Arabic, though for slightly different reasons.

[ebraminio]

Again I can not agree with last sentence of Khaled here as I don't see the situation same with rectangular liking letters of CJK and I also don't think keeping the underline unchanged is equally bad or is not helpful. I hope others Arabic/Persian speakers comments would shed some light on this but I am just bringing Khaled's mentioned text on both skip: ink and without for their judge:

To me, this is not very different than real world English skip: inks (link) but maybe is just a new looking thing for Arabic text (which I believe on a right direction):

Some other interesting to know facts, currently Arabic Wikipedia is totally disabled links hover underline for some reason but as their decision was affected Persian Wikipedia, we had to revert their change on Persian Wikipedia (there is a false fact about Amiri on the commit message, please ignore) as it was causing UI/UX inconsistency, and, Central Kurdish Wikipedia also was interested on our change so I applied that for them also. Also some Persian news agency websites like Tabnak had disabled links underline and I believe if they asked about the reason, they would mention dots legibility issue with underline as one the reason (if not top) so current situation with underline on Arabic is it self not great (I don't like here to be accused of implying that skip: ink is making it better, even the fact, I believe it doesn't making the situation worse if not making it better)

[ebraminio]

Ok. Now I see the issue with Khaled's given link that on that size skipped underline itself became like a dot and that made me a little undecided

[kojiishi]

@r12a it'd be great if i18n can come to a consensus on what to do with Arabic. It looks like Arabic is a bit gray, compared to CJK, and WebKit has been shipping it for years. So while I understand there are bad cases, I can't determine whether it should skip by default or not.

Note, we can give controls per script, Latin probably want always on, CJK wants always off. Arabic might want on or off by default, and a switch for opt-in/out?

[kojiishi]

Please see #962 for the CSS property to opt-in/opt-out.

Now the behavior of auto for Arabic isn't clear. My understanding from the discussion above is, there are both good cases and bad cases, but since WebKit has been skipping for a while, probably skip for auto and authors should opt-out if s/he wants?

@ebraminio @khaledhosny thoughts?

[behnam]

IMHO, the skip-ink feature may look nice to someone not familiar with the script, but it's definitely a creation for the script, and although it may looks very fancy, it's not based on existing practices and could be a totally different concept from what is already known as underline, which is to draw a line below the letters.

In Arabic script, letters don't "sit" on a "baseline" (and then underline drawn under the baseline), but letters fill-in a space, a band, and the underline (overline) goes below (above) that space/band. So, "underline" does NOT strikethrough every single dot or (to put it in Latin-script definitions) hanging letters, or skip-ink at them. The position of the underline should be fixed, instead, to have minimum collision.

There's plenty of evidence of this behavior in manuscripts, lithography, and movable type. We are addressing this definition/behavior in ALReq.

[khaledhosny]

What @behnam said.

[ebraminio]

the skip-ink feature may look nice to someone not familiar with the script [...]

Just another IMHO I like to add, as someone reads or edits Persian Wikipedia on everyday basis on Safari, I see it a nice and helpful feature. Arabic definitely has some issues with underline, as Arabic Wikipedia has completely disabled underlining on https://ar.wikipedia.org but on Persian Wikipedia which underlining is not disabled and I can use this with Safari, this actually helps me to deal better with Arabic-script (Persian) text.

I think the result of alreq eventually would be moving automatic underline position more below, so, at least, just like what Khaled said, "they all look equally bad", I don't think fixing Arabic underline issue then progressing this issue would differ much from progressing this first then fixing underline Arabic issue.

[khaledhosny]

I think a better default underline position for Arabic (if font data are to be ignored) would be just below the font descender.

[frivoal]

@behnam @khaledhosny So if I understand correctly, the ideal behavior for Arabic and other languages using the same script is to position the underline so that it does not intersect, making the question of whether or not to skip irrelevant since there is no intersection.

The position of the underline is controlled by https://drafts.csswg.org/css-text-decor-4/#underline-offset, and the default value allows for that. It should probably be clarified to make sure that it not only allows for it, but actually requires it, or if we cannot do that, at least recommend it.

Some (many) current implementations may be doing a terrible job of implementing auto correctly, and place the underline in a way that does intersect. We can hope this will go away eventually, but maybe it will take a while, and maybe there are cases where that is not possible.

Also, it remains possible to place the underline manually, and make it intersect.

When that happens, what should we do if the author has not said what they want in terms of ink skipping. skip by default or not?

It seems to me that although avoiding intersections is the main goal, if intersections do happen, skipping ink is better than not. Does that make sense?

[behnam]

@frivoal, I just posted a summary of our discussion last week here: w3c/alreq#86 (comment)

We discussed underline/overline methods on the 7 February 2017 weekly meeting.

Here's a summary:

1. Existing practices (meaning almost any handwriting, lithography, movable type, and traditional word processors) puts underline/overline below/above all glyph parts (letter parts and diacritics). Therefore, this is a desired behavior.

2. We will keep looking for other practices and will document when we have good evidence.

3. Based on the samples collected, looks like implementations need to find a better way of calculating a position for underline/overline based on font data. Most probably, it will use ascend and descend values for the positioning.

4. In any case, if the underline/overline collides with ink, the prefferred default behavior would be to skip the ink.

5. When skipping ink, it's also preferred to make sure the underline/overline drawing does NOT form a short pieces, which could be easily mistaken with dots or diacratics. To prevent this, the drawing can be skipped for parts with a short width.

So, to answer to your questions,

the ideal behavior for Arabic and other languages using the same script is to position the underline so that it does not intersect, making the question of whether or not to skip irrelevant since there is no intersection.

Exactly!

The position of the underline is controlled by https://drafts.csswg.org/css-text-decor-4/#underline-offset, and the default value allows for that. It should probably be clarified to make sure that it not only allows for it, but actually requires it, or if we cannot do that, at least recommend it.

IMHO, the text-underline-* properties are designed with only Latin-similar writing systems in mind, assuming there's a baseline and letters sit on top of that, which is not a valid assumption for Arabic scripts.

If we really want to expand control over the underline/overline behavior, we should start with allowing positioning based on any of baseline, ascend, descend, and possibly other font properties. Having only two positioning options (under and over) and then manually moving the lines with an offset doesn't sound like a user-friendly alternate.

Some (many) current implementations may be doing a terrible job of implementing auto correctly, and place the underline in a way that does intersect. We can hope this will go away eventually, but maybe it will take a while, and maybe there are cases where that is not possible.

Yes, unfortunately.

Also, it remains possible to place the underline manually, and make it intersect.

When that happens, what should we do if the author has not said what they want in terms of ink skipping. skip by default or not?

It seems to me that although avoiding intersections is the main goal, if intersections do happen, skipping ink is better than not. Does that make sense?

Yes, skipping in any case of collision would be a wise choice.

[kojiishi]

@behnam

IMHO, the text-underline-* properties are designed with only Latin-similar writing systems in mind, assuming there's a baseline and letters sit on top of that, which is not a valid assumption for Arabic scripts.

See text-underline-position: under. The example picture is Latin but this property is designed primary for East Asian scripts. From your description, it looks like Arabic prefers it too.

I just filed a request to caniuse but WebKit and Blink (currently in beta) support this property. If you could see how it renders well for Arabic, that'd be helpful.

Unfortunately, I can't see it working in Gecko/Edge @gregwhitworth @masayuki-nakano

[r12a]

@kojiishi @behnam Since the request for text-underline-position review seems to diverge a little from the core of this thread, i put some results in a new issue over here #1055 hth

[behnam]

You're right, @kojiishi. I think the naming of the values got me confused about what they actually do. Let's talk about that property in #1055 then. (Thanks, @r12a!)

So, to conclude on this issue, yes, we want to have text-decoration-skip-ink for Arabic script text as default.

[drott]

@fantasai, and others, can we come back to how to specify this default? The direction of this thread seems to indicate we want ink skipping by default. The previous suggestion had been to add such a default to the UA style sheet:

I think that if a UA wants to skip ink, it should simply add that to the UA default style sheet.
That's what UA default stylesheets are for.

Is there a problem with this approach?

~fantasi

The feedback received in response to the the attempt of adding it to the UA style sheet has been that this should be a change of the initial value.

So, coming back, how about changing the initial value to one of
a) objects ink
b) objects ink leading-spaces trailing-spaces
c) a new, to-be-defined auto value.

Thanks to @litherum @annevk and @tabatkins for commenting on the UA style sheet change thread.

[tabatkins]

Yeah, @fantasai’s suggestion of a UA stylesheet value was for if a single UA wanted to do this by default. But further discussion in the thread does indeed seem to indicate that multiple browsers either already are skipping ink by default, or want to, or are okay with changing to do so. In that case, changing the initial value is the better action.

Your list of suggestions is 👍

[fantasai]

Hi! Sorry for not following up on this. The CSSWG discussed this issue in January, the minutes are available here:
https://lists.w3.org/Archives/Public/www-style/2017Feb/0049.html
https://lists.w3.org/Archives/Public/www-style/2017Feb/0069.html

The spec was updated to move the text-decoration-skip property to Level 4, to attempt splitting it out into longhands, and to define that the UA may skip ink in L3 with controls to be defined in L4.
“ UAs may interrupt underlines and overlines where the line would cross glyph ink and to some distance to either side of the glyph outline; this behavior is not controllable in this level, but will be further defined in Level 4. Line-throughs must remain continuous, however. ”
https://drafts.csswg.org/css-text-decor-3/#line-decoration

Please let me know if this resolves the issue, or if you need something else.

[drott]

Thank you. I think we can work with the resolution in https://lists.w3.org/Archives/Public/www-style/2017Feb/0069.html which @kojiishi incorporated into L4 and the note for L3 that you quoted.