W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2016

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

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Fri, 23 Dec 2016 07:52:29 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-268952763-1482479548-sysbot+gh@w3.org>
I [responded to the older mail 
thread](https://lists.w3.org/Archives/Public/www-style/2016Dec/0103.html)
 before noticing this github thread. Reposting here.

----

[Text decoration level 
4](https://drafts.csswg.org/css-text-decor-4/#text-decoration-skip-property)
 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.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/727#issuecomment-268952763 
using your GitHub account
Received on Friday, 23 December 2016 07:52:32 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:30:27 UTC