Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-text-decor] A new property for text decorations to skip ink #962

Closed
kojiishi opened this issue Jan 20, 2017 · 14 comments
Closed

[css-text-decor] A new property for text decorations to skip ink #962

kojiishi opened this issue Jan 20, 2017 · 14 comments
Labels
Closed Accepted by CSSWG Resolution Commenter Timed Out (Assumed Satisfied) css-text-decor-4 i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response.

Comments

@kojiishi
Copy link
Contributor

From the IRC log of the WG discussion on issue #707, #727, and #843, we agreed to add a property to control skipping ink in L3, and defer other controls to L4.

This is to discuss how the property should look like.

@FremyCompany said

ink skipping: yes or no should be in level 3

and given #707 and #727, @fantasai suggested

auto | yes | no

somewhere.

As far as I understand, the discussion points are:

/cc @fantasai @frivoal @litherum @FremyCompany @dbaron @astearns @tantek @eaenet @drott
I can't find github account for Jenn and skk (anyone know?), all others in the IRC log are on the line above.

Opinions/discussions appreciated.

@kojiishi kojiishi added the css-text-decor-3 Current Work label Jan 20, 2017
@kojiishi
Copy link
Contributor Author

I can't find github account for Jenn and skk (anyone know?)

Sent an e-mail notification to them manually.

@kojiishi kojiishi added the i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. label Jan 20, 2017
@jensimmons
Copy link
Contributor

FYI, I spell Jen with one 'n', not two, so that makes me @jensimmons on GitHub (and IRC). Here I am. Thanks for emailing me directly so I'd see this.

@realskk
Copy link

realskk commented Jan 23, 2017

Thanks for letting me know, @kojiishi . My account is @realskk. (I couldn't get skk)

@kojiishi
Copy link
Contributor Author

kojiishi commented Feb 2, 2017

Got a few feedback offline:

  • Prefer to have yes in L3.
    • yes should skip ink regardless of scripts (or underline offset if Arabic wants auto to decide skip/not to skip by the underline position.)
    • yes should not skip ink for strikethrough.
  • Since strikethrough is not included, text-underline-skip-ink might be more appropriate property name?
    • It includes overline, but text-underline-position includes overline too, so we'e at least consistent.

@eaenet
Copy link

eaenet commented Feb 8, 2017

Thanks @kojiishi, that sounds great. text-underline-skip-ink does indeed seem more appropriate.

@frivoal
Copy link
Collaborator

frivoal commented Feb 15, 2017

yes should skip ink regardless of scripts (or underline offset if Arabic wants auto to decide skip/not to skip by the underline position.)

I don't think yes should cause the position of the underline to move to account for arabic. As being discussed in #727 (comment), it is likely that shifting the position of the underline is the correct behavior for that language, but that should come out of an other property (https://drafts.csswg.org/css-text-decor-4/#underline-offset).

@kojiishi
Copy link
Contributor Author

@frivoal I tried to mean that yes should skip ink regardless of scripts or underline offset. I hope this is the same as you said?

@kojiishi
Copy link
Contributor Author

WG resolved to defer the property to L4.

RESOLVED: Use text-decoration-skip-ink with at least values of auto and none and it cascade sep from shorthand. We will have some normative text desc how auto works, but we'll figure the details out in the future. Do in L4

@astearns astearns removed the Agenda+ label Feb 15, 2017
@frivoal
Copy link
Collaborator

frivoal commented Feb 16, 2017

After re-reading the minutes, it seems to me that we were partly talking past eachother on the topic of the shorthand.

I thought were were discussing whether text-decoration-skip-ink should be part of the text-decoration-skip shorthand that we previously decided to add to level 4, since that is the question that was explicitly raised by @kojiishi in the first comment in this github issue. It now seems to me that at least @fantasai was discussing whether it should be part of the text-decoration shorthand, since her key argument was that it is important that these cascade separately so that you can turn text-decorations on and off separately from deciding what they should look like:

You'll want to set it at a higher level for how you want
to behave for the document. Turning on and off for the
underline is separate. Thus they shouldn't be conflated.

That is an argument for text-decoration-skip and all related text-decoration-skip-* properties not being part of the text-decoration shorthand, and I completely agree with it (and can understand why @fantasai seemed surprised in IRC that I didn't get that point). So if that is what the resolution means, good.

This does not however address whether text-decoration-skip-ink should or should not be part of the text-decoration-skip shorthand, so I think we need a separate resolution on that. As I understand, @kojiishi thinks it should not. See this quote from #962 (comment):

It may or may not be part of the shorthand in L4, see #843 for more details.

I have read #843, and I fail to see how it provides arguments in favor of text-decoration-skip-ink not being part of the text-decoration-skip shorthand. It still makes more sense to me text-decoration-skip-ink should be part of text-decoration-skip, given that the entire purpose of that property is to reset the type of skipping we should have. It seems counter intuitive that it would only reset some kinds of skipping, and I have not seen (or understood) the use cases where you'd like to reset most types of skipping to whatever their default value is but want to preserve ink-skipping being off (keeping it on is not part of the use case, since that's the default and is therefore what you'd get if it were part of the text-decoration-skip shorthand).

If being unrelated to the text-decoration shorthand is not what we resolved on, then I don't understand how @fantasai 's argument is relevant, and I still fail to understand Koji's point.

@kojiishi
Copy link
Contributor Author

Does that mean you agree not to include to text-decoration shorthand but you prefer to include in text-decoration-skip shorthand? If so, I think I incorrectly assumed that it's no longer a discussion point, sorry about that. And I agree with your interpretation that @fantasai's comment at the weekly call was about text-decoration shorthand, not about text-decoration-skip shorthand.

I think I wrote this somewhere, but my mild preferences in the order is:

  1. Not to have text-decoration-skip shorthand.
  2. If we were to have one, not to include ink. Maybe some others too.

but I'm ok if people prefers other options.

My primary concern is when author starts using

:root { text-decoration-skip: ink; }

and when a UA supports leading-spaces, the page suddenly draws underlines to leading spaces. Stylish values are likely to be applied to the whole document, and it is possible to hit us when we want to add new values. On the other hand, semantic values are likely to be used like:

image.emoji { text-decoration-skip: none; }

so they look less risky to me.

IIRC @fantasai and I discussed that ink (and maybe edges too) is about stylish, while values like 'objects' is about semantics (such as this image is Emoji while that image is photo) and that the meaning of "skip" is somewhat different. So I assume she and I are in consensus, and I guess I incorrectly assumed all of us are in consensus.

Note, one may still do:

div.message-pane { text-decoration-skip: none }

to draw underlines to Emoji in a message app, without knowing it disables ink, edges, and all other values. That's why I feel having text-decoration-skip shorthand has more risks than benefits, but if you or anyone is strong about this, I'm ok.

@frivoal
Copy link
Collaborator

frivoal commented Feb 17, 2017

Does that mean you agree not to include to text-decoration shorthand but you prefer to include in text-decoration-skip shorthand?

Yes. But see below for an important nuance.

My primary concern is when author starts using

` :root { text-decoration-skip: ink; }

and when a UA supports leading-spaces, the page suddenly draws underlines to leading spaces.

I agree that would be bad, but this would not happen with the text-decoration-skip shorthand the way I am proposing it.

I am against a shorthand that would have this kind of syntax: text-decoration-skip: <text-decoration-skip-ink> || <text-decoration-skip-spaces> || <text-decoration-skip-foo> || <text-decoration-skip-bar>. This has the problem you describe, , as well as other similar problems as described in #843. So on that, we agree.

What I am proposing is that the values of text-decoration-skip should only be auto and nothing else. This shorthand should only have the ability to reset all its longhand to whatever their initial values is. If you want anything else, you need to go through the longhands.

That would avoid the problem discussed above.

Why would that be useful? Because we have quite a few text-decoration-skip-* properties, and getting all of them back to the default state is annoying and very verbose (and not future proof). If you want to set an element to "whatever is normal, except don't skip ink", you cannot do that only with text-decoration-skip-ink: none, because that instead means "whatever is inherited, except don't skip ink". If you've used other text-decoration-skip-* properties somewhere on the page, these two are different. You'd write text-decoration-skip: auto; text-decoration-skip-ink: none;.

It has also been proposed during the Seattle F2F that we should also be able to set the longhands via the shorthand, but that it would need a different syntax with explicit on and off for each one. Like text-decoration-skip: auto | [ink-on | ink-off] && [ leading-spaces-on | leading-spaces-off]. This would also avoid the problem you mentioned. I don't think this is necessary, but I am not strongly opposed to it. I suggest we start with just text-decoration-skip: auto, and if needed add these later.

Maybe I am misunderstanding it, but I think we agreed to that in Seattle. We have:

  • An explicit resolution to “Add all of the skipping properties” (at the end of a discussion that includes the shorthand with only none | auto)
  • An other explicit resolution to put ink skipping in level 3 and the rest in level4
  • an agreement (without resolution) that a shorthand with the current syntax (text-decoration-skip: <text-decoration-skip-ink> || <text-decoration-skip-spaces> || <text-decoration-skip-foo> || <text-decoration-skip-bar>) is bad
  • an agreement (without resolution) that the shorthand can start with a single keyword (possibly named initial or auto) resetting all the longhands to their initial values.

@kojiishi
Copy link
Contributor Author

I see, yeah, having auto as the initial value solves the initial values of new values, but it doesn't look to solve the root problem, which is, we're trying to shorthand that are implementation-wise related but use-case-wise or user-wise unrelated, and thus accidental reset can happen.

Let's say an English user installed an extension that sets :root { text-decoration-skip-spaces: yes; } since that is his favorite underline styles. This will be reset if a page wants to change edges or ink and used the shorthand. UA stylesheets may set lang(zh) { text-decoration-skip-edges: yes; }, or localizer sets edges for Chinese but developer may reset it accidentally.

On the benefit side, I don't see many cases where single author wants to set multiple values to single selector. If you have such examples, that'd help discussion.

@frivoal
Copy link
Collaborator

frivoal commented Feb 21, 2017

Let's say an English user installed an extension that sets :root { text-decoration-skip-spaces: yes;}

That's the default value, so you would not need an extension or a user stylesheet for that.

This will be reset if a page wants to change edges or ink and used the shorthand.
If a page wants to change a single other feature, it cannot use the shorthand, since the shorhand doesn't do that.

Other than that, yes, user-style sheets get overridden when authors reset various things, but that's a general problem with CSS, not even a matter of shorthand or longhand. And if the user really cares, they can use !important in their stylesheet.

As for why I think the shorthand will be useful: Since you may want the different kind of behaviors based on relatively unrelated things, you'll have unrelated selectors setting different kinds of skipping on or off in different parts of the page, as well as propagating via inheritance. In most cases, you should be just fine with that, but occasionally, you'll want to isolate yourself from that, and start with a blank state. For instance, say you have an article element inside of some UI structure. You may not want the skipping rules from the UI, whatever they are, to inherit into the article, so you apply an text-decoration-skip: auto reset on the article.

@fantasai
Copy link
Collaborator

fantasai commented Jan 1, 2020

I believe this has all been edited into the spec now per https://lists.w3.org/Archives/Public/www-style/2017Feb/0049.html see https://drafts.csswg.org/css-text-decor-4/#text-decoration-skipping

@kojiishi Let me know if there's anything left to address in this issue. (And of course feel free to open up more issues on related details. There are several marked in the draft already.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed Accepted by CSSWG Resolution Commenter Timed Out (Assumed Satisfied) css-text-decor-4 i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response.
Projects
None yet
Development

No branches or pull requests

7 participants