Re: [text-decor-3] matching platform defaults with text-decoration-skip: auto

> On Dec 23, 2016, at 00:31, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
> On 02/14/2014 03:55 AM, Edward O'Connor wrote:
>> Hi,
>> 
>> 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'.
>> 
>> WDYT?
> 
> I think this could be easily handled by a UA stylesheet rule
> rather than a new UA-dependent initial value. :) WDYT?
> 
>  :root { text-decoration-skip: objects ink; }


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.

— Florian

Received on Friday, 23 December 2016 07:41:11 UTC