[CSSWG] Minutes New York F2F 2022-08-01 Part II: Values, Backgrounds, Animations, Transitions, and Fill-Stroke; CSS Text 4; CSS Text Decor [css-values][css-backgrounds][css-animations][css-transitions][fill-stroke][css-text-4][css-text-decor]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Values, Backgrounds, Animations, Transitions, and Fill-Stroke

  - RESOLVED: Keep list-valued property definition as-is (as specified
              in Backgrounds & Borders). Generalize definition and move
              to Values & Units. (Issue #7164: How to handle linked
              list-valued properties?)

CSS Text 4

  - Florian to clarify rationale for the current design in issue #7193
      (Don't provide a language parameter for word-boundary-detection)
      and also in the spec, and then get i18n feedback

CSS Text Decor

  - Since issue #5002 (Underline position for when decorating box is
      higher than regular position) was filed, ink skipping has been
      introduced and that changed the benefits of shifting
      - The group did not have consensus on the best behavior for
          underlines crossing subscripts.
      - A poll will be created to gather more opinions from authors and
          typographical experts in order to reach a decision.

  - RESOLVED: Add text-decoration-skip-self as a longhand of
              text-decoration-skip, for skipping ancestor decorations
              (Issue #2885: How to use decoration skipping to turn off


Agenda: https://github.com/w3c/csswg-drafts/projects/30

Scribes: fantasai & TabAtkins

Values, Backgrounds, Animations, Transitions, and Fill-Stroke

How to handle linked list-valued properties?
  github: https://github.com/w3c/csswg-drafts/issues/7164

  Rossen: Who's in a good position to summarize?
  fremy: We have a couple of list-valued properties (more than one
  fremy: And sometimes these properties interact with each other, each
         with a list
  fremy: So question is - how do you represent this value in computed/
         used values?
  fremy: preserve author-provided length, repeat as necessary, truncate
  fremy: Say author provides three values, but only one is used, should
         used value report just the one or all three?
  fremy: Lea mentioned on the call that for her it seems easier to have
         computed and used be the same
  fremy: So this seems to mean repeating the value as necessary to
         match the controlling property's length, or truncating to match
  fremy: Sebastian had same
  fremy: but seems strange to me
  fremy: computed value is what you inherit from
  fremy: Seems strange to say you inherit value to children that
         doesn't have all the values author provided
  fremy: Even if the parent doesn't use them, might want to use them in
         the children
  fremy: But apart from that...

  fantasai: Issue was initially filed due to complexity of adding more
            such property groups
  fantasai: specifically about box-shadow longhands
  fantasai: So question was if there's a way to make this repeating
            list situation easier to implement, or at least consistent
  fantasai: Previously the spec deferred to background specs
  fantasai: Which takes a list and repeats/truncates at used value
            time, computed value is as specified
  emilio: Not in Blink tho
  emilio: The Firefox behavior preserves the length of all lists
  emilio: I think that's generally simpler, avoids inter-dependencies
          at computed value time, which are annoying
  emilio: Also it's weird to lose values because the controlling
          property wasn't long enough, when inheriting
  emilio: So I prefer that behavior. Implementing Chrome behavior is
          just more special cases during style resolution
  emilio: so I'd rather keep the props independent and match them up at
          used value time

  dbaron: I think there may be some relationship between these rules
          and the interpolation rules
  dbaron: One thing to watch out for is if we add to this set of
          properties, which have interpolation rules that do LCM
          interpolate rather than truncation/repetition
  dbaron: Because I think we have two interpolation variants
  dbaron: There's definitely a variant where two different lengths
          gives you a list of LCM length
  dbaron: There's one where you get the longer length, padded with a
          neutral default for the shorter
  TabAtkins: I assume the third would be to interpolate the shorter
             length and truncate?
  dbaron: Don't think that's present in anything
  astearns: There's definitely a variant where we just don't
            interpolate between different lengths
  fantasai: LCM seems awful
  fantasai: 5 and 7 would give 35 values. probably not what the author
  dbaron: It does the right thing in many cases, such as
  dbaron: Might be others that do that

  fantasai: So my starting proposal is we keep the spec as-is
            (specified in B&B), maybe clarify. computed value is as
            specified, used value is repeated or truncated as necessary.
  fantasai: And make sure all specs use that behavior and file tests
            and bugs as appropriate
  fantasai: If we should do something different somebody should propose
  TabAtkins: I agree, I think that's the right proposal
  TabAtkins: iank & co, does that sound like something we can do?
  futhark: Dunno off the top of my head if we can do it
  futhark: I think it's probably fixable?
  Rossen: So not opposed?
  futhark: Not right now based on what I know
  Rossen: And it makes sense as a path forward

  Rossen: So we have a proposal. Anything else to add?
  TabAtkins: If this is the resolution, does that unblock our ability
             to do more sets of list-valued properties?
  TabAtkins: Or are we they still problematic to add?
  emilio: They're still harder to implement, but 🤷
  emilio: Less special-casey than the current Blink behavior for sure
  Rossen: So proposal is to keep the spec as is
  Rossen: Did something need to be clarified?
  fantasai: Don't specifically say the computed value is same as
            specified value, it's implied. Can be louder in the spec so
            it's obvious
  fantasai: Should review other list-valued specs besides B&B to make
            sure it's fine
  fantasai: And might want to add a generic definition in V&U so we're
            not all reffing B&B.

  TabAtkins: Proposed resolution is keep spec as-is, add generic
             definition to V&U
  fantasai: And make sure all specs are consistent with it
  Rossen: So anything to be added? Objections

  RESOLVED: Keep list-valued property definition as-is (as specified in
            B&B). Generalize definition and move to V&U.

CSS Text 4

Don't provide a language parameter for word-boundary-detection

  florian: In Text L4, we have a property to detect boundaries
  florian: and another property to use boundaries
  florian: e.g. in Japanese might want to word-break headings
  florian: If not marked up in the source, can use this property to
           auto-detect the word breaks
  florian: In CSS, ask for detection through this property
  florian: and say which languages you want to auto-detect
  florian: Implementers also want to not specify the language
  florian: Problem is as an author, how do you know what's supported?
  florian: e.g. if you say auto-detect Thai, how do you fall back if
           the browser doesn't support auto-detection for Thai?
  florian: In Japanese, normally you can break everywhere. If you turn
           that off, and only break at word boundaries, you will not
           wrap anywhere if you fail detection
  florian: If you turn off normal line-breaking, and turn on one that
           requires word boundaries to be inserted, and you fail to
           insert them, the result will be very bad

  ChrisLilley: I think what I see the i18n group say is to combine this
               with actual use of lang attributes in markup, and if you
               don't do that you get what you get
  ChrisLilley: I think they're trying to push for "use proper lang tags"
  florian: Specced to require markup lang tagging as well
  florian: You have to match on both sides. If you ask for "auto-break
           Japanese", it will only apply that to elements that are also
           tagged as Japanese
  florian: Browsers can maybe guess, but ...
  ChrisLilley: Has this been articulated to the i18n wg?
  florian: I can write it up in the issue

  emilio: It's weird to make syntax parse depend on something that may
          be system dependent
  emilio: e.g. if you make system API to do the line break, then can
          only line-break if the system supports it
  emilio: ...
  emilio: It's a bit of a hassle to pass that back through the CSS
          parsing layer

  fremy: For the fallback, seems extremely dangerous that you would
         depend on this
  fremy: It seems to be more prudent to say, if the UA is not able to
         find breaks in the text, then don't apply
  fremy: Doesn't mean you don't parse, but if you're supposed to break,
         and cannot find a place to break, sounds like a bug
  florian: This property doesn't control line-breaking
  florian: If you want to control line-breaking, you use the usual
  florian: and you can put Unicode chars to explicitly indicate
           break opportunities
  florian: What this does is to effectively inject into the markup the
           Unicode characters you didn't put yourself
  florian: We could change to make the property to autodetect and also
           control line-breaking, but already so complicated

  florian: Also this property is not just for line-breaking,
  florian: can detect word boundaries to insert spaces
  florian: can insert spaces, or line break, or both
  florian: If you don't have the characters in the markup and they fail
           to be auto-injected, then you won't wrap anywhere, and
           that's a big problem
  florian: Maybe we can find a different way to do fallback, but if
           there's a risk of content overflowing instead of wrapping,
           people can't use this property

  dbaron: Want to echo what Chris says, which is we shouldn't do too
          much based on this feedback until we make sure r12a
          understands why we did this in the first place
  dbaron: It's not clear in the spec text, and not clear in the issue
  dbaron: so go back and explain why you did it this way first

  fantasai: Sounds like the plan is for Florian to go back and explain
            why this works the way it does in the issue, and also
            clarify in the spec
  Rossen: Anything else on this issue?
  <dbaron> (r12a might still disagree, but we should find out first,
           and then perhaps discuss again)
  florian: I'll clarify

CSS Text Decor

Underline position with descendant vertical-align shifts
  github: https://github.com/w3c/csswg-drafts/issues/5002

  fantasai: Underline position requires underline to not move
  fantasai: If the underline cuts thru text, the browser should have
            chosen initial position better
  fantasai: but it shouldn't break it and shift some of them
  fantasai: Firefox avoids splitting. Could be smarter about
            positioning, but it works
  fantasai: but other browsers break the underline depending on

  iank: Our most recent behavior is in Chrome Canary but not Chrome
  iank: I believe our current canary matches Firefox in this case
  iank: When we filed this issue we were only investigating the issue.
  iank: We'll take the dominant baseline
  iank: so this should get us similar to Firefox

  fremy: Our behavior we had with Edge was intentional
  fremy: Wouldn't break the line when the text was above the natural
         baseline, but would when it went lower
  fremy: You never want underline to be striking through text
  fremy: but it does mean that with the new ink-skipping behavior, it's
         probably not as bad to have the line go through the text, since
         it doesn't visually cross it actually
  fremy: so even though I'd initially have said the edge behavior was
         what authors want, these days since we have ink-skipping the
         "always just use one baseline" is better
  fremy: especially if it's simpler and matches impls

  fantasai: So fremy I think you're proposing the spec doesn't change,
            and we encourage that the underline doesn't move for
            subscripts, but instead ink-skips as normal
  fremy: I think ink-skipping is enabled by default?
  fantasai: There's a handful of cjk characters that don't ink-skip,
            because that seemed to cause problems
  fantasai: but I think they're not frequently used as subscripts

  fremy: I think the Edge issue was to break the baseline if it didn't
         ink skip, since we do ink-skip now that's not necessary
  fantasai: So if you turn off skipping, should the browser be shifting
            baselines for subscripts?
  fremy: I vote yes
  jfkthame: I vote no, authors have properties they can use to control
  fremy: Can't do that per span, can't affect parent's position
  iank: What was Edge's behavior?
  fremy: You draw the baseline at dominant position, but if you have
         text that would cross the underline, you break it and move it
         down for the text
  iank: So this would only be when they cross the characters
  fremy: Yes
  iank: I checked with koji, he says he'd prefer Edge's behavior here
  iank: I just loaded up Edge behavior, it seems resilient

  florian: I think if the author has subscript or superscript they need
           to work around, they can use -position to work around it
  florian: and we have :has() now so you can do em:has(sub)
  fremy: It might only be on one lie
  fremy: Can't guarantee positioning even with text-underline-position
  <TabAtkins> Edge's behavior is resilient to these situations

  fantasai: I think authors want either skipping character or shifting
            the underline, don't think they want breaking
  iank: I don't particularly like current Firefox impl for this case
  fremy: Not drawing underline on characters below baseline is a risk
         you don't draw at all, if an entire line is subscripted

  iank: I think only us and gecko have this behavior. I think we'd be
        willing to switch to Edge's
  iank: What do Daniel or Jonathan think?
  <dholbert> I defer to jfkthame, (& haven't fully paged this topic in)
  jfkthame: Seems to be that gecko's behavior (has been there for many
            years) is fundamentally the right thing, and I'd prefer not
            to change it
  iank: Why do you think it's right?
  jfkthame: I think when an underline is specified on an element, it
            should be a continuous line, it shouldn't move about for
            some elements
  iank: Even if it obscures the subscripts?
  jfkthame: Sure, don't put lines on top of text, that's bad authoring
  jfkthame: I think authors have enough control to do sensible things
  iank: I think it's quite common to get into this case
  iank: And to get yourself out to fit again by using additional
  jfkthame: You mean common due to <sub>?
  iank: Yeah you don't need to use any css to get into this

  astearns: Jonathan, would you be at all interested to move the
            underline down when there's subscript, so there's a
            continuous line for all the spans?
  jfkthame: I think we could consider, and think spec currently allows
            for that
  jfkthame: have some hesitation - if you underline some text that's
            broken across several, and subscript is on one line, does
            it get a diff position from the other lines? maybe weird,
            but could think about it
  iank: Yeah I think shifting the whole thing isn't a good behavior
  iank: I think solution is to either drop the baseline entirely or
        have EdgeHTML's behavior
  fantasai: Spec did specify that kind of auto behavior in the past
  fantasai: for L3 we made it up to the UA to get to CR
  fantasai: There used to be text specifying to move it on a per-line

  dbaron: My memory of the spec was the opposite - it spec'd moving all
          the lines. I think that's harder but better behavior
  dbaron: Also, in response to Jonathan, another way for authors to hit
          this case is variability between fonts
  dbaron: Can hit it on some machines but not others due to font
  dbaron: so this should work well as part of css's robustness to
          unexpected font metrics
  <fantasai> “In determining the position of and thickness of text
             decoration lines, user agents MAY consider the font sizes
             of and dominant baselines of children. Of course, user
             agents MAY ignore children in these determinations. Such
             an averaging is done on a line per line basis.”
  <fantasai> https://www.w3.org/TR/2003/CR-css3-text-20030514/#text-decoration-overview
  <fantasai> “In determining the position and thickness of text
             decoration lines, user agents may consider the font sizes
             and dominant baselines of descendants, but for a given
             element's decoration must use the same baseline and
             thickness on each line.”
  <fantasai> https://www.w3.org/TR/2010/WD-css3-text-20101005/#decoration

  florian: Don't remember history, but spec as is today in position and
           offset, has a default of auto that allows for moving it down
  florian: but neither speaks to per-element or per-fragment
  florian: so currently ambiguous.
  florian: Maybe we start with more permissive version that allows
           either, and revisit in a bit to see if there's agreement?
  florian: could say that browsers *may* do it on per-fragment
  florian: but not obliged to if it's bad
  iank: So allow both edge's and Firefox's rendering?
  florian: No. Say you have a subscript in a long span. on first line
           you have a continuous line; it might be shifted down if the
           subscript is there.
  florian: So shift for the entire element, but allow it to be per
           linebox fragment. Not EdgeHTML style
  iank: Don't think it's necessarily what devs expect
  florian: Will be odd if you have a multiline span to see the
           underline shifted on lines without a subscript
  iank: I don't think either option is good
  iank: Both will look visually odd
  fremy: don't like shifting per line either
  Rossen: So if we move forward with florian's proposal to make spec
          more permissive
  TabAtkins: ian was objecting to that, he prefers Edge's behavior
  iank: My strong pref and I think koji's is Edge's behavior

  florian: Have we looked at what other good typography software has
           done? We're not inventing the subject
  jfkthame: Usual answer in typography is you don't do underlining
  astearns: Or you're very explicit about the effect you want
  astearns: InDesign allows you to do whatever you want with the line
  astearns: So we're talking about automated tools
  TabAtkins: But LaTeX is automated too
  fremy: For LaTeX, subscripts don't get an underline, and people are
         asking about how to get it to work
  fremy: So as far as I can see it just doesn't draw and that's bad
  fantasai: I'd expect that you draw the underline at correct position
            and skip subscipts, or use a lower underline position just
            as a document style
  florian: Alan, you said InDesign will let you do whatever, but it
           does it provide a way out of the box to do like Edge, or do
           you have to do it manually?
  astearns: I'd have to check
  fantasai: Don't think I've ever seen Edge's behavior in a document
            that wasn't generated by a browser
  <jfkthame> fantasai++
  fremy: I'd assume Word does that
  Rossen: That's correct
  <fremy> FWIW, Word does indeed behave like EdgeHTML
  <ChrisLilley> fremy, probably both usind DirectWrite api
  <fremy> ChrisLilley, quite likely, indeed

  Rossen: So we have a spec that describes Firefox behavior
  Rossen: We have a strong desire from Blink to implement the Word/Edge
  Rossen: if we need to allow both, we need at least a MAY
  Rossen: so that doesn't give us much specification
  TabAtkins: It would still help with supers to make sure that's clear
  florian: Right, still an improvement over chrome's old behavior

  fantasai: Think I don't really want to increase variations that
            typographers would be unhappy about
  fantasai: so don't want to adopt Edge's behavior unless there's
            typography community people wanting it
  iank: Do we have evidence that people don't want it? That's
        surprising to me, since it's in Word
  jfkthame: Word isn't generally considered the epitome of typography

  jfkthame: Just tested Pages on Mac, if you have a subscript it moves
            the entire line's underline
  iank: Per line or per paragraph?
  jfkthame: Didn't go that far

  iank: Would it help to quickly show examples?
  iank: [old chrome behavior, baseline jumps all over for subscripts and
        superscripts. consistent per individual element]
  iank: [Firefox's behavior, underline is just dominant. ink-skipping
        can make it appear to not draw for subscipts, depending on how
        the glyph is]
  iank: [dominant baseline *per element*, so lines without a sub/super
        still have the underline shifted]
  iank: [Edge's behavior - underline is dominant, but subscripts break
        it and draw their own underline fragment to their dominant
        baseline. Supers don't affect the underline]
  <dholbert> FWIW, LibreOffice seems to match the EdgeHTML behavior
             (not that LibreOffice is necessarily the pinnacle of text
             layout; just as another-agreeing-implementation)
  florian: I checked apple pages, it shifts per line, not per paragraph

  fantasai: I think Firefox's behavior is closest to what I'd expect
            from good typography
  emeyer: I agree
  florian: Firefox behavior could be made smarter
  fantasai: And I'd expect ink-skipping with a consistent position to
            look best
  fantasai: If you're not skipping, that's obviously a little bad
  fantasai: If you have a lot of subscripts, you
            should probably generally choose a lower underline position
  fantasai: I don't think I'd expect Edge's behavior from a
            well-typeset doc
  iank: Is it permissible to skip a giant subscript?
  fantasai: Default is ink skipping
  iank: I mean skip entirely, not just ink-skip
  iank: ink skipping works for shorter cases, like this small B
  iank: but the big edge case is a long subscript

  fantasai: We should be optimizing for reasonable cases
  several: Nah we've seen long subscripts
  fantasai: Common cases will be short subscripts and we should
            optimize for that
  bkardell: [missed]
  <bkardell> I was saying that I agree it is unusual for a long run of
             text as a subscript in general, but a lot of times
             superscripts are links, which generally are underlined
  [Note: if the superscript itself is a link, it will be underlined at
         its ownunderline position; this is just about ancestor-element
  fantasai: There has been requests to turn off underline for an
            element, that's an open Text 4 request
  fantasai: so if someone wanted to skip, that should be possible to do
  una: I noticed if you have a subscript that's a link, that's common,
       it'll have a double underline - parent going thru it, then its
  fantasai: Yeah edge behavior gives you multiple, but spec behavior is
            to have one single line that doesn't move
  fantasai: so per spec you wouldn't have double underline

  Rossen: [shows Word with a bunch of different font-size subscripts,
          generating multiple staggered underlines]
  Rossen: This example where you break the first line for a subscript
          out of the larger set font
  [changing the baseline position breaks the underline averaging
      segments in Word]
  florian: I think this is different and more complex than what was
           described as edge behavior
  florian: You're saying we have one continuous underline until we hit
           the subscript, then it changes after the subscript?
  fantasai: That's because word doesn't have a nesting hierarchy, it's
            just a linear stream of elements. so it can't preserve
            formatting across a subscript break like we can
  florian: I think LibreOffice does the Edge behavior but people are
           asking how to not do that on StackExchange
  <astearns> InDesign also does not have a hierarchy of elements. So I
             don’t think we should follow InDesign OR Word

  fremy: I cared strongly when this was first filed because we didn't
         have ink skipping, but less now
  fremy: I think Edge's behavior is safe, but if we think it's
         reasonable to cross the text and rely on ink skipping, I think
         it's an option. I don't think it's best but I'd be okay with it
  iank: I want to talk with koji to see what he'd think about, not just
        ink skipping but totally skipping the subscript; would be
        identical in common cases but different in the degenerate
        long-text case
  fremy: Only downside is it's entirely accidental if the whole text is
  fantasai: Agree it shouldn't be default, author should opt in maybe
  iank: I'd agree
  iank: ink skipping doesn't necessarily get a good effect, it still
        looks like text is crossed out

  Rossen: So it sounds like Firefox's behavior is still something we
          want to keep
  Rossen: strong desire from Ian and team to experiment and see if they
          can get something closer to Edge behavior
  Rossen: Question is how do we allow it
  fantasai: I don't think this is good to adopt unless people other
            than browser engineers want it
  fremy: Well Word is doing it and people use it every day
  florian: I just went to Word support forum and answer for if you want
           to do another behavior is "use more advanced typesetting
  <florian> https://answers.microsoft.com/en-us/msoffice/forum/all/underline-subscript-is-uneven/786e1222-87c4-4dc9-97de-83b3a08a32d8
  fantasai: I want somebody specializing in good typography to say
            "Word behavior is good and what we want" before we consider
            adopting it
  fremy: Yeah but usual policy is to say even if layout is weird, text
         should be readable
  fantasai: We try to make sure behavior is good by default, and
            resilient in weird. doesn't mean we choose bad behavior
            because it's the most straightforward way to be resilient
  <Rossen> For the record - neither of the answers posted by florian's
           link above are official Microsoft answers but folks from the

  emeyer: From what I remember of Edge and Firefox cases, I do not see
          why we'd pick Edge over Firefox
  emeyer: What Firefox was doing for ink skipping and various cases
          seemed like a better approach on balance
  emeyer: I'm not a typographical expert, but I spent a lot of time
          looking at text
  emeyer: I'd be comfortable asking the wider community
  emeyer: I agree with Elika, we're trying to make typography better,
          let's actually make it better

  <astearns> I dislike Edge’s behavior because it does two different
             things depending on whether a line starts with a span
             shifted up or shifted down relative to the rest of the line

  una: Do we want to do a survey?
  una: My team can organize it
  emeyer: Would support it
  Rossen: Would be helpful
  ChrisLilley: Should be clear it's "what do you want to see" not just
               "what does your software do"
  fantasai: "what do you like better: picture, picture, picture"
  florian: Also with short subscripts we seem to agree Firefox is good,
           only for long do we disagree
  florian: Isn't it preference to use the spec allowance to move the
           entire line down?
  iank: I think there's three options here
  iank: First is Firefox's, for short subscripts ink-skipping makes it
  iank: Second is Edge, where subscripts break the line and move it down
  iank: Third is don't draw the underline on subs at all
  iank: This has similar practical behavior to Firefox's for short; for
        long it will be different
  <fantasai> Fourth is move the entire line down
  florian: Think there's another - largely do Firefox, but allow for
           shifting the whole run's underline, perhaps with a guard to
           only do it when it's long
  fantasai: Don't think it's great to condition on the lenght of the
            subscript, it's unpredictable then
  fantasai: If you have five subscripts, two on a line skip but three
            shift, that's weird
  fantasai: Should pick one behavior, author can get other behaviors
  Rossen: We can decide not to change
  florian: I said my fourth was possibly conditional. If it's not
           conditional, it matches Apple Pages

  Rossen: So we can't get resolution yet.
  Rossen: We want to do a survey that catches all the cases we just
          described, carefully not conditioning people to one tech or
  fantasai: I suggest me and Una work on this
  Rossen: And I think convo captures enough info for posterity
  Rossen: and strong desires of what we believe is good

  ACTION: fantasai and Una to make a survey about underlining subscripts

  Rossen: anything else before we end?

  <br dur=1hr>

How to use decoration skipping to turn off underlines?
  github: https://github.com/w3c/csswg-drafts/issues/2885

  fantasai: We've had a variety of suggestions for how to turn off
            ancestor underlines on an element
  fantasai: We had a suggestion of using text-decoration-skip; it
            didn't work since it was inheriting
  fantasai: that doesn't work
  fantasai: My suggestion is to add text-decoration-skip-self: auto |
            skip | no-skip
  fantasai: could add no-skip later if it's hard
  fantasai: non-inherited property
  fantasai: auto skips if it's atomic inline
  fantasai: skip skips the element regardless
  fantasai: no-skip avoids skipping even if it's atomic inline; draw it
            over/under as if it's a character
  fantasai: useful when images are used as text, like in CJK for rare
  fantasai: (not ideal but it happens)
  fantasai: property would apply to inlines; all ancestor decorations
            would skip, but its own text decorations would apply

  astearns: This is in addition to the skipping we already have?
  fantasai: This replaces the existing text-decoration-skip:self
  fantasai: independent from ink skipping
  emilio: Is the auto behavior how browsers behave today?
  fantasai: Yes
  emilio: Sounds reasonable
  astearns: How does it interact with text-decoration-skip?
  astearns: Assume not a shorthand relationship
  fantasai: We've discussed having a shorthand for both inherited
            and non-inherited
  fantasai: several places in text where it might be useful
  fantasai: but haven't pulled the trigger yet
  fantasai: For here it's less critical, but I think it's useful for
            text-decoration-skip to be a shorthand
  fantasai: There was also some white space property where we thought
            about mixing inherited and non-inherited longhands

  emilio: Don't we already have one mixed?
  emilio: border-color? I guess that doesn't inherit
  fantasai: I think we had a proposal for one, but we never solidified
  fremy: There was something but we changed it to have a special value
         that mimics non-inheritance
  emilio: The 'all' property trivially does inherited and non-inherited
  TabAtkins: lol yeah but it's a special case
  <dbaron> At least the old Gecko style system (and maybe other
           engines) had optimizations (in the rule tree) that benefited
           from shorthands (for many common shorthands) being
           all-inherited or all-non-inherited.

  fantasai: My suggestion is we make text-decoration-skip a shorthand
            for all the skip props
  fantasai: We might need to make the keywords more unique, then

  jfkthame: Do you want to control skipping separately for the
            different decorations?
  jfkthame: Like skip underlines on subscript elements, but not
  fantasai: Yeah
  <TabAtkins> +1

  astearns: If an author wanted it, would they be able to skip
            everything and reset the others?
  jfkthame: No, if you reset on the child they'll move to match the
            child rather than being continuous

  fantasai: So maybe we want skip-all, skip-underline, etc
  astearns: Maybe we could add the specific values when we have
            use-cases? Jonathan, do you know it's something we want to
            do right now?
  jfkthame: No haven't been hearing much demand, just seemed like a
            natural request
  fantasai: It's good to bring up, as it can affect our naming
  astearns: Maybe goes back to Myles since he brought it up, to see if
            it's something he wants to design
  fantasai: I think we're resolved to add a non-inherited property (a
            longhand of text-decoration-skip) that skips
            text-decorations imposed by an ancestor
  fantasai: Open question is whether we add keywords for the specific
            types of decorations

  <dbaron> (Are there people who want text-decoration-skip-ink to apply
           to line-through decorations?)
  dbaron: Wondering about separate decorations...
  dbaron: Have we had people asking for skipping for strike-throughs
  fantasai: I haven't heard such a request
  fantasai: Currently we ink-skip on under and overlines, not
            linethroughs, since it should look like you're striking the

  astearns: Opinions or concerns?
  astearns: So proposed resolution is to add the new prop as a longhand
            of t-d-skip
  astearns: Objections?

  RESOLVED: Add text-decoration-skip-self as a longhand of
            text-decoration-skip, for skipping ancestor decorations.

Received on Tuesday, 30 August 2022 00:00:06 UTC