- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 29 Aug 2022 19:59:25 -0400
- To: www-style@w3.org
=========================================
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
underlines?)
===== FULL MEETING MINUTES ======
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
value)
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
wanted
dbaron: It does the right thing in many cases, such as
stroke-dasharray
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
it
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
--------------------------------------------------------------
https://github.com/w3c/csswg-drafts/issues/7193
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
properties
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
vertical-align
iank: Our most recent behavior is in Chrome Canary but not Chrome
Stable
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
that
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
elements
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
basis
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
variations
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
tool
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
behavior
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
subscript
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
underlines]
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
underline
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
subscripted
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
software"
<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
community
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
readable
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
another
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
characters
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
it
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
overlines
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
text
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