- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 25 Oct 2022 19:01:43 -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.
=========================================
Font Loading
------------
- Webkit is behaving according to the spec intent in issue #7680
(FontFaceSet.load() promise rejections). Only changes necessary
would be editorial clarifications.
- RESOLVED: Republish css-font-loading-3 as a WD once the Changes
section is up to date (Issue #7065: Lots of edits since
2014 /TR, republish?)
CSS Overflow
------------
- The proposal in issue #7708 (Is continue: discard working in the
fragment tree useful?) is implement line-clamp by making extra
lines invisible and shortening their containing block accordingly
- There was discussion about if the changes would lose useful clarity
that is currently in place from the tie in to fragmentation model
- There were many questions on the detailed consequences, so the issue
will return to Github.
Scroll Animations
-----------------
- The proposal to give authors the ability to attach a timeline to
any sibling/descendant (Issues #7047 (Scope of Named Timelines) &
#7759 (Broader Scope of Named Timelines)) seemed to be the best
approach, but probably not necessary in this level so it will be
deferred.
Selectors
---------
- The group didn't want to make any change unless the breakage was
bad for issue #7676 (The forgiving nature of :has breaks jQuery
when used with a complex :has selector). If the breakage is bad,
the lean was to make only :is() and :where() forgiving
CSS Backgrounds
---------------
- The demo for issue #7103 (The shape of box-shadow should be a
circle for a box with border-radius:50% and big spread) still
needs some additional examples before the group will be ready to
resolve.
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/32
Scribe: heycam
Font Loading
============
FontFaceSet.load() promise rejections
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7680
myles: I was debugging some stuff
myles: The question is, when you call FontFaceSet.load(), under which
circumstances will that promise be rejected?
myles: Right now the only circumstance is if the input to the
function is a syntax error
myles: this is not what any browser does, according to my testing
myles: If there were network errors, all browsers will reject that
promise
myles: that's the extent of my testing in other browsers
myles: In WebKit, our behavior is: if any of the network loads
triggered by this call fail, we'll reject the promise
myles: the important part is, in the situation where all the fonts
fail to load, there's interop there
myles: the spec should match
JakeA: It's a misreading of the spec
JakeA: although the spec says it should resolve, resolve is not the
opposite of reject, fulfill is the opposite
JakeA: you can resolve it by rejecting it
JakeA: the language the spec uses to wait for a series of promises,
it's using the same method as Promise.all()
JakeA: so it'll reject as soon as any of the input promises reject,
or it will fulfill if all of them were fulfilled
myles: Sounds great, it's editorial then
TabAtkins: During the break, I was linking us to the WebIDL terms now
they exist
TabAtkins: This was one of the first W3C specs to use promises
TabAtkins: but now we have definitions to link to
TabAtkins: WebKit is already following the spec as intended
Lots of edits since 2014 /TR, republish?
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7065
chris: The changes section in this spec bears no relation to the
edits that have been made
chris: there has been no attempt to keep that up to date
chris: but it's 2014, probably time for an update?
chris: Been a bunch of changes
TabAtkins: I say wait for a round decade
TabAtkins: Definitely does need to be updated
TabAtkins: needs a moderate amount of admin work to do that
TabAtkins: I should spend time on this next I have a free moment
chris: The changes predate when we moved to GitHub
chris: Need to trawl through the mailing list to find all the changes
astearns: Should we keep this issue open for getting the changes
section up to date?
TabAtkins: I think so
chris: We can have a conditional resolution that once the changes
section is up to date, we republish
astearns: Sounds good to me
RESOLVED: Republish css-font-loading-3 WD after Changes section is
updated
CSS Overflow
============
Scribe: TabAtkins
Scribe's scribe: fantasai
Is continue: discard working in the fragment tree useful?
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7708
emilio: Making line-clamp work using continue:discard has some side
effects
emilio: Based on fragmentation implies the boxes you clamp don't
exist, so OM APIs return 0 sizes, etc
emilio: And implies that like border-bottom disappears due to
box-decoration-break
emilio: I think it would be both easier and more useful to impl
line-clamp by clamping both content-height, as it does now,
and the scrollable overflow, and hiding the clamped lines
rather than discarding fragments
emilio: There's been some discussion - I think in general it's a lot
easier to implement but similarly useful
emilio: So easier to reach unprefixed line-clamp
emilio: We could decide to ship line-clamp as a longhand for now and
decide what to do about shorthands later
andreubotella: It's not clear how line-clamp would work with editing
andreubotella: Not clear where carat would go if you move past the
clamped line
andreubotella: Would be less of an issue with emilio's model
florian: We'd also need to define how padding/etc will work. using
fragmentation gets us that, it defines those
florian: One of the goals is to avoid reinventing all that
florian: It's true that the discarded part, we have incomplete
answers about what to do with abspos in there, what happens
to the caret, etc
florian: So maybe we do use fragmentation, but rather than discard
the post-fragmentation is invisible
florian: but saying that it's easier to do it visually is in conflict
with the existing knowledge that it's in conflict with
visual stuff
florian: like bidi content
florian: In the fragment model, in document order, when we have
enough content to place the ellipsis; that's different from
hiding characters at the end of the line
florian: Another complaint about visual aspect is you have no control
over what gets elided and whether it happens at sensible
line-break points
florian: If using fragmentation, the line breaking properties work
florian: Another thing which is useful under the current model (and
maybe usable under your new model), a lot of people want to
clamp at 3 lines, but a lot want to clamp at 100px
iank: Still possible
florian: Not impossible, but undefined. Defined with fragmentation,
but not defined without.
florian: Don't want to display a half-line, for example
florian: So I think we can find ways to define things in terms of
fragmentation that are less mysterious
florian: And also make some statements about "allowable
approximations".
florian: But I think entirely discard fragmentation would be
unfortunate
iank: Clarification, the visual model is purely about subsequent lines
iank: Still do layout placement of ellipsis, etc
iank: So not necessarily in conflict with what you want to achieve
iank: I don't wanna have a spec where all the impls do emilio's
model, and there's a bunch of soft wording about how it's
allowed
florian: Yeah point is not to write fiction, it's just that if we do
emilio's model because it's more useful, we shouldn't omit
the useful properties of the current spec
florian: If we treat it as something like a multicol where additional
cols aren't painted, you can have an answer to all the API
questions
iank: There's still subtle diffs
iank: in emilio's model it's actually desirable that you don't
fragment the borders
emilio: Say you clamp in a nested block with border/padding
emilio: it has five lines, you clamp at 3, per fragmentation you're
supposed to hide the border padding at the bottom
fantasai: Which element has line-clamp here?
emilio: The bfc
fantasai: So inside the bfc you have a text with 5 text lines
fantasai: the bfc says line-clamp:3
fantasai: so you clamp after three lines, then what's after is clamped
emilio: No
iank: You're just clamping the content box. You set the content box
to the size after clamping and then layout as normal.
<iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10735
[retreading the previous example]
emilio: The auto height of the inner box is 3 lines tall (plus mbp)
florian: So you're reinventing fragmentation...
emilio: No fragment would crop the border
florian: Yeah we have box-decoration-break that lets you control it
iank: Well they're not repeated, because this *isn't* fragmentation
[missed]
florian: If we do it with fragmentation you can choose whether to
clip those borders or not
iank: You can here, with border:0
florian: No you can't, you can't predict whether the clamp activates
or not
florian: Fragmentation already solved this, dunno why we're
reinventing
iank: I think this is a small edge case and most people would expect
the behavior from emilio's model
astearns: Agree this is probably small, but there are tons of
decisions in this space about what to do after a fragment
break, and we'd have to reinvent all of these
emilio: Don't think it's reinventing, we just do what we do if you
clamp the auto size and visually hide the overlap
iank: Very similar to empty-cells on tables, or similar to
visibility:hidden but not quite
astearns: there's a long queue
heycam: It's probably more like visibility:collapse on those
additional lines at the end, they take up no space and aren't
rendered
iank: a little diff because collapse applies to a container, and it
often gets smushed in size and there's some other effects, but
yeah
iank: The way we'd implement is exactly like empty-cells
heycam: At a high level in wk, I think we support getting to the full
fragmentation model
heycam: But we'll need an interim solution, maybe emilio's or similar
heycam: think it would be useful to enumerate the diff between this
and the full fragment solution so we can see what it's most
similar to
heycam: and how likely it is we run into compat issue in the future
heycam: like gBCR() effects, etc
heycam: If that would change between the two solutions, that might
be risky
iank: Broadly I'm supportive of emilio's suggestion
iank: webdevs strongly desire an unprefixed line-clamp
iank: We, Blink, are probably the closest to having a fragmentation
solution, but still a ways away
iank: emilio's suggestion means all engines can ship something highly
interoperable fairly quickly that will satisfy webdev demands
iank: don't want fiction, so if we do emilio's, want it in the spec
iank: emilio's gets us there very quickly
iank: I don't think emilio's and fragmentation are exclusive
astearns: If we come up with a list of things that are going to be
different, how can we move from one to the other?
iank: I don't think that we will
iank: I think we'll be shipping whichever we start with
iank: So like, I don't believe we'll be able to straight unprefix
-webkit-line-clamp even with emilio's solution, because devs
are already depending on scrollable overflow returning a
particular value to tell if clamping applied
iank: I suspect we'll get something similar
iank: with abspos at the end, for example
heycam: So what I'm hearing is that if we come to the full solution
it will need a switch
iank: I think that's ok; they're related problems but not necessarily
the same
iank: When we want to truncate content and continue it in a different
fragmentainer, I wouldn't be sad if that was a different set
of fragmentation properties
iank: People are today using prefixed line-clamp and unhappy about
it, we can all ship an unprefixed line-clamp with emilio's
solution
astearns: but it's still different than emilio's?
iank: Pretty sure we can translate most of it over, only big compat
change will be the scrollable overflow size change
florian: I don't want fiction either, so I'm happy to make
accommodations so we can match impls
florian: but I wanted to circle back to one potential difference,
because I didn't understand an earlier answer
florian: with emilio's, is it possible to "clamp after however many
lines it takes to reach 300px"?
emilio: Could be feasible, define that instead of "hide lines after
the third" you'd hide all lines whose block-end edge is after
300px
florian: So you'd size the container to 300px, fill it in, start
filling in content, then remove after...
emilio: Not remove
florian: You said you'd draw the mbp of children at the bottom, so
you'll need to make room to insert those back
florian: Note it's not the container border I'm talking about, it's
the content element's border
florian: before counting lines you don't know how many lines you'll
take
fremy: You add both top and bottom mbp as you add it, then fill in
lines until you hit the limit
iank: Yup
iank: Our -webkit-line-clamp will already abort and retry for
complicated reasons. this is fine
florian: What troubles me is not that it's undoable, clearly it is
and is even simpler, but it will have something *very
similar* to fragmentation which isn't quite fragmentation.
astearns: Which makes you uneasy
florian: Yeah
florian: The bidi part I'm not sure how you solve
florian: We don't control what chunk of text on the last line is okay
to remove
florian: this is a known problem of the existing paint-based ellipsis
emilio: I think blink does layout-time ellipsis
emilio: presumably they have to reshape arbitrary content when
inserting it to avoid clipping
florian: And it can push content around?
iank: I'll have to double check, but I think we'll reshape, like if
you land on a bad ligature we'll go back and split it
florian: It's not just painting a ligature, it's about dropping
letters or a whole word
florian: similar for an abspos in the content, the static position
changes depending on whether it's pushed to the next line or
not
iank: I think abspos are break opposite in our impl for this reason
fantasai: There's a number of directions people have wanted to extend
this in, and starting from fragmentation model gets you to
a bunch of different places that we want to end up
fantasai: while starting from a visual model doesn't
<fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10738
fantasai: I also pasted a funny test case
fantasai: it's pretty weird
fantasai: This is the model we *want*?
andreubotella: Regarding ellipsis, in current fragmentation there's
block-ellipsis where you can replace the final lines
with something
andreubotella: How would this work?
andreubotella: If the string has rtl and ltr characters?
florian: It's specified, I don't recall the details. I think we
insert the string as a string without wrapping opposite and
with bidi isolation
<break, duration 10min>
<TabAtkins> I do think the "keep the bottom mbp of the children"
thing is the big difference between fragmentation and
this that is important to authors
<TabAtkins> And this is not something you can do *at all* in
fragmentation currently, b-d-break only controls the
fragmentainer itself
[editors note, Tab is wrong: box-decoration-break controls the borders
of the broken box's fragments, not the fragmentainer]
Scroll Animations
=================
Broader Scope of Named Timelines
--------------------------------
githubs: https://github.com/w3c/csswg-drafts/issues/7047 and
https://github.com/w3c/csswg-drafts/issues/7759
<fantasai> https://github.com/w3c/csswg-drafts/issues/7047#issuecomment-1239820755
fantasai: We talked about the scope and came up with a default answer
fantasai: also what we might do to give power to people who want to
do something more far-ranging than just "prev sibling" or
"ancestor"
fantasai: so I came up with a suggestion to declare a timeline name
but not attach it to a scroll container, and then attach it
to one in the sibling/descendants
fantasai: Suggestion is a property called scroll-timeline-attachment
<TabAtkins> 'local' is the default, binds to the element you're on
<TabAtkins> 'defer' will declare the name, but attach it to something
else
fantasai: And another element can say "attach me to the timeline" of
a given name
fantasai: so if I want a global scope
fantasai: can set scroll-timeline-name:foo on the root , and
scroll-timeline-attachment:defer then on something else in
the tree set scroll-timeline-name:foo and
scroll-timeline-attachment: ancestor
fantasai: and it'll attach to that timeline scoped to the root
fantasai: I'm ambivalent about putting this in current spec, but
wanted opinions on idea
flackr: Two thoughts
flackr: If you can name a timeline that's deferred, I don't think
there's any need for the ancestor selection anymore, because
you could just name that timeline?
fantasai: 'defer; says you're planning to attach the name to
something else
fantasai: but if the element is also a scroll container
fantasai: it doesn't actually bind the timeline to its own scroller
flackr: Okay so I misunderstood, 'ancestor' is the name lookup
flackr: Yeah I proposed something similar earlier
flackr: So two, we haven't explored this idea too far yet, to see if
there's a need for it
flackr: I guess it solves every use-case since you can do global
timelines
flackr: but I'm interested to see in practice how often people need
these other scopes
flackr: Anyway if we do need this power, I think this is a reasonable
approach
astearns: Maybe this could be an open issue to put in the next level
if needed?
fantasai: Yup
astearns: unless it would be good to put in the current draft to get
more eyes on it, and punt if needed later
fantasai: I defer that judgement to flackr
flackr: I think we can add this later
Selectors
=========
Forgiving :has() breaks jQuery when used with a complex :has selector
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7676
TabAtkins: I think we've lost enough people that are relevant to this
emilio: I have an opinion, but...
emilio: tldr is Chrome shipped :has() with forgiving parsing, because
jQuery calls querySelector() and if it throws, use their
custom selector parser
emilio: I filed an issue a while ago about making @support selector()
not be forgiving, which lets jQuery do the right thing here,
but that doesn't fix existing usage
<emilio> https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235773031
emilio: 1) rename :has(), which isn't great
emilio: 2) give up on forgiving-selector-list, which also isn't
great. is()/:where() already shipped with it
emilio: 2.5) spec the webkit bug, which is unforgiving if *all* of
the selectors fail
emilio: 3) leave it; if breakage isn't too big, oh well
fremy: Another idea is to explicitly check the jquery pseudo classes
and poison them
<fantasai> -1 to special-casing jquery
emilio: There's a lot, plus jquery just has some different parsing
for the matching stuff of us, too
fantasai: I'm okay with saying :has() is unforgiving, you can nest an
:is() if you want
fantasai: lets authors be strict if they want
TabAtkins: We're not entirely consistent. :not() is unforgiving, for
example
dbaron: Two thoughts, both weak preferences
dbaron: One is, I have mixed feelings about forgiving-selector-list
dbaron: Even if the group thinks the old selector parsing is a
mistake, having two models used in different places is worse
than having just the bad one
dbaron: in terms of author confusion
dbaron: The other proposal is that :is() is different from :has() in
now two ways
TabAtkins: You're confusing it with :where. :has() is completely
different
dbaron: I'm not a fan of these names
dbaron: no strong suggestions for what to do about it
TabAtkins: Regardless of our opinions on :where(), that's not the
current issue
dbaron: I do think it compounds the problem though
fantasai: What if we just restricted forgivingness to :is() and
:where() and nowhere else. If you really want it you can
get it, and these two are basically just syntactic sugar
for expanding things out anyway.
TabAtkins: If breakage is enough to worry about, and I think it
might be
TabAtkins: then that's my preferred solution of all of them
florian: So if that's the path we go, if you want forgiving-ness, you
just do :has(:is()) ?
TabAtkins: Yeah
TabAtkins: given that some people who know about badness of breakage
aren't here
TabAtkins: I suggest we defer this, and say that if breakage is bad
enough, we go with forgivingness only in :is() and
:where()?
TabAtkins: We basically narrow to 2 options here
astearns: Or switch it to unforgiving regardless
heycam: How do we decide if it's bad enough?
TabAtkins: Been awhile since I looked
iank: I think it was bad enough that we need to make a change
dbaron: I think the breakage came from jquery's test suite, not real
sites
dbaron: but not sure
fantasai: That said, we still have you concerns
<astearns> https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235441907
astearns: This comment says even if we make it unforgiving, :is() is
still forgiving so it's a problem
TabAtkins: I made that comment, and response was that because :is()
isn't part of jquery, much much less likely to trigger a
problem
TabAtkins: It relies on code writing new standards-based selectors
using :is() in old versions of jquery, which while it can
happen is much less likely than new pages
TabAtkins: than old pages using jQuery's :has() and breaking due to
the new standard :has()
astearns: So collect more info, provisionally conclude that making
:has() unforgiving may be the path to fix if breakage is
bad?
CSS Backgrounds
===============
box-shadow of border-radius: 50% should be an ellipse
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7103
dbaron: A few weeks ago Oriol prepared a bunch of demos for this
problem
dbaron: Underlying issue is that in 2013 we changed the spec so
expansion of rounded borders, which happens primarily for
box-shadow spread, was not discontinuous
dbaron: prior it was discontinuous from 0 to non-zero border-radius
dbaron: we introduced this cubic formula
dbaron: So normally a 5px border-radius and 3px of spread means an
8px spread corner
dbaron: so they're concentric
dbaron: nobody shipped it until earlier this year
dbaron: Chromium got bug reports now about circles expanded to
non-circles
dbaron: So we want circles to stay circles
dbaron: Oriol had proposals, group was unhappy with all of them
dbaron: Since then I came up with two additional proposals, fantasai
had a third I attempted to put into Oriol's demo
dbaron: so we can look at these additional options
dbaron: So first option is the existing formula
astearns: Skip to demos, we can go back to math
<fantasai> ->
https://lists.w3.org/Archives/Public/www-archive/2022Sep/att-0012/shadow-radius.html
dbaron: This third example is a circle, that's important, and there
are some other pretty round cases
dbaron: this is the spec currently, you'll see the circle is no
longer circle at all, other round examples have flattened ends
dbaron: My first option is based on the ratio of the rounded part of
an edge to the total length of the edge, using that as a cap
on the cubic formula
dbaron: One puts the cap on before, one after the cubing, so one is
linear and the other is cubic
fantasai: In the very last, there's a sharp corner, but it gets quite
rounded in both of yours
fantasai: but your other squares aren't particularly rounded
dbaron: Elika's is capping based on --- using oriol's "% of max axis"
but not all the time, switches between it and current spec
fantasai: Each side has a straight and a curved piece. if it's all
curve, it uses % formula, if it's at least the length of
the box side it uses the spec formula, and between those it
interpolates
dbaron: The other things that's different is I did the capping based
on the ratio of rounded vs total side length, Elika did ratio
of rounded to straight part of the side
dbaron: not sure which is better
dbaron: but weird thing about Elika's is it requires a max because it
hits the cap in the middle rather than the end
astearns: The old spec is super round for the square with 1px round
corner
fantasai: Yeah, that's why we change the spec
astearns: Wonder if we'll get people wanting that, though
fantasai: Depends on what you're trying to do
fantasai: Goal was to get something continuous
fantasai: For squarish things I think current spec is better, but for
circle-ish it's broken
astearns: Sounds like we need some more options in the demo?
Received on Tuesday, 25 October 2022 23:02:26 UTC