- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Mar 2023 19:29:38 -0500
- 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.
=========================================
Switching drafts.csswg.org to proxy github.io
---------------------------------------------
- RESOLVED: Proxy from drafts.csswg.org to github.io, and have
github.io redirect to our server
- plinss will set up the proxy server. rachelandrew will work with
MDN and TabAtkins will work with WHATWG to get URLs changed.
CSS Display
-----------
- RESOLVED: Inertness is determined by the base computed style for
'display', resulting in animations to 'none' being
considered inert (Issue #8389: Interaction gotchas when
delaying the effect of `display: none`)
CSS Position
------------
- RESOLVED: In LTR-tb the top-left corner is the top-left corner of
the top-left-most fragment of the first line, and the
bottom and right edges are bottommost and rightmost
edges of all the fragments. Directionality comes from
the inline (Issue #8284: Containing block formed by
fragmented inlines)
CSSOM & Backgrounds
-------------------
- RESOLVED: Move color at the end of the final-bg-layer grammar, to
make it serialize as `none` (Issue #8496: Serialization
of `background: none`)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Mar/0006.html
Present:
Rachel Andrew
Tab Atkins
David Baron
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Mason Freed
Paul Grenier
Chris Harrelson
Daniel Holbert
Jonathan Kew
Peter Linss
Eric Meyer
François Remy
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Chair: astearns
Scribe: fantasai
Agenda
======
astearns: Changes or edits to agenda?
astearns: We will have longer meetings, and more of them next week
and the week after
astearns: I will set up calendar invites, but either way
astearns: We have next Monday at 7am Pacific and wed at 8am Pacific,
both for 2 hours
astearns: Same thing the following week
astearns: Trying to burn down a bunch of the agenda
Switching drafts.csswg.org to proxy github.io
=============================================
astearns: Chris brought this up, github.io seems to be more reliable
even with recent work on the server
astearns: I think it might be time.
chrishtr: This would make it alias the github domain?
astearns: Just for our editor's drafts
chrishtr: So if you got drafts.csswg.org, it would go to github.io?
astearns: Yes
chrishtr: I agree
astearns: Building in both places
astearns: but we don't control the infrastructure around github.io
astearns: but it seems to be reasonably reliable, but we get out of
the business of hosting our own
plinss: There's still value in having our own infrastructure
plinss: It will get fixed, just not quite there yet
plinss: if we want to switch temporarily, that's fine
plinss: if we want to switch permanently, not my call
plinss: We're also running fxtf and houdini stuff
plinss: and GitHub isn't perfectly reliable, was out of sync for
awhile, too
<TabAtkins> (I'm still not sure what was causing the out-of-sync
thing on the github.io)
emilio: I think a lot of MDN is pointing to github.io now, which is
unfortunate
emilio: we should preserve our own URL, even if proxying github.io
under the hood
astearns: It's a problem, if MDN and WHATWG are pointing to
github.io, proxy server doesn't help much
emilio: GitHub does allow custom domains, can we configure a way
that points ...
emilio: I guess that would lose functionality from current drafts
server
emilio: but point DNS at github?
TabAtkins: That doesn't help problem of hard-linking to github.io
TabAtkins: but if we're quick about it, MDN and WHATWG are changeable
TabAtkins: if they both switch to using our own URL because it's
proxying github.io
<tantek> +1 TabAtkins
TabAtkins: [audio cut]
emilio: This is a problem because our server is unreliable, so
should be able to change MDN etc if we fix that
florian: Answering peter's question from earlier
florian: I think we should make the switch [audio cut]
florian: Once peter is done fixing the whole thing, we may be able
to evaluate what's the better thing to server our URLs
<chrishtr> +1 to temporary switch and see how it goes
<tantek> +1 to temporary switch with intention to switch back to our
own infra
florian: but currently the market is telling us that what we have is
not good enough
<chrishtr> we could also have a different url that goes to the
existing server for those who need it
<tantek> important thing is to maintain linking to our URLs
florian: and they're switching away from our URLs, which that's the
most important thing because we control them
florian: We should switch
<tantek> florian is saying what I would say :)
florian: We should try to make some trickery to switch from
github.io to our own if possible
<emilio> +1
<TabAtkins> We can def do some redirect trickery.
<tantek> +1
florian: but make sure our own URLs are reliable enough that people
don't refuse to link to them
<tantek> +1
<dholbert> Can't we make both sets of URLs work, with the redirect/
proxying being transparent under the hood? (Maybe what
Florian was alluding to)
fantasai: Very strong +1 to florian
fantasai: It's possible to proxy some but not all urls?
<dbaron> +1 to temporarily making drafts.csswg.org (and hopefully
also fxtf.org and css-houdini.org) use the github.io
infrastructure while preserving the csswg.org etc. URLs
fantasai: We could proxy the urls for the drafts only, but leave the
server handle other documents that the github backend
doesn't do
fantasai: That would take some load off the server, and would still
leave us with the extra functionality
fantasai: but yes, we need something that's reliable enough that
people are willing to link to it
astearns: So we can proxy to github.io, and then ask MDN and WHATWG
to use our own URLs
astearns: and if draft server is fixed, we can return to it, and
otherwise maintain the proxy
plinss: Ideal would be to have the github stuff have a redirect back
to our URLs, if it's served correctly
TabAtkins: We can put a hard redirect so if you hit the actual
github.io URL we redirect to the drafts URL
plinss: That'll help encourage people to use correct links
plinss: We just need to make sure that doesn't break the proxy
<TabAtkins> Thinking we'll do the redirect in a script in the ED
header boilerplate; we can just check what URL is
actually there.
RESOLVED: Proxy from drafts.csswg.org to github.io, and have
github.io redirect to our server
ACTION plinss to set up proxy
ACTION rachelandrew to update MDN
ACTION TabAtkins to push updates to WHATWG
CSS Display
===========
Interaction gotchas when delaying the effect of `display: none`
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8389#issuecomment-1458713903
flackr: Using display to animate from block to none
flackr: this has effect that during animation, the element can still
be interacted with and is in the a11y tree
flackr: it has problems with e.g. form submission, could
accidentally submit twice because animating out
flackr: Proposed resolution is that we look at the base value of the
display property, i.e. the value before animation is apply
flackr: When animating to none, base value would be none
flackr: Use that to determine whether the element should be in the
a11y tree
flackr: and also effectively make it inert while it's none
flackr: Longer-term, we might want to have inert be a CSS property,
and this would be part of auto behavior for inert
flackr: but this would be for doing the right thing in the simple
cases
<PaulG> +1 (from APA)
<TabAtkins> +1 from me
<masonf> +1
<fantasai> +1 to "make it work like expected without author fussing"
<bramus> +1
<emilio> +1 as long as there are tests for this
flackr: [re-explains proposal]
Rossen: There was some work that was already happening around inert,
curious if your proposal has any tracking with that work
Rossen: I'm sure inert as CSS property was considered and debated at
some point in the past, I'm not sure where we ended up, but
would be good to have a tracking issue or at least track
that discussion
<chrishtr> Link to prior discussion:
https://github.com/w3c/csswg-drafts/issues/8389#issuecomment-1419970151
chrishtr: Link to pros and cons
chrishtr: My understanding from previous discussion was that no one
had strong opinions, and the door was open to adding it in
the future
Rossen: That answers my question
chrishtr: We can do this thing for now, so by default it does the
right thing
chrishtr: and if there's significant developer need, we can add
'inert' in the future without too much trouble
flackr: Yes, this is designed to be forwards-compatible with that
emilio: I was thinking about this, inert has this feature where some
elements that escape inert-ness
emilio: e.g. modal dialog that's now 'display: none', that will not
be inert
emilio: but 'display: none' would prevent modal dialog from showing
emilio: This looks almost like inert, but with that thing where we
may not want subtrees to escape inertness?
chrishtr: If you have [scenario]
flackr: The auto behavior is based on the computed base style of
'display', which even for the descendant would be 'none'
emilio: Not really, display is not inherited
flackr: But it's within an element with a computed base display
style of 'none'
<TabAtkins> display may not be inherited, but display-none-ness
*basically* is
<masonf> modal dialog inside a display:none subtree is already
display:none.
emilio: The way inert is implemented, at least in WebKit and Gecko,
basically it's an internal inherited bit in the computed
style representation
emilio: there are things that can flip that for a subtree
emilio: When you have fullscreen element, everything is inert except
fullscreen element subtree
emilio: This inert, we don't want it to be overridden by anything
inside the subtree
<oriol> Blink also uses that approach
flackr: Even if overridden, this proposal would fix the common cases
flackr: but if we did allow overriding, you would have these edge
cases where the things animating to 'display: none' would
not include modal dialog
emilio: This proposal helps a lot for ?? cases
emilio: Just an edge case that might be better to explicitly point
out?
emilio: "inert, but actually force inertness for the entire subtree"
flackr: sounds like something we could consider if we add a CSS
property for inertness
flackr: I think there are use cases for opting subtree
emilio: If we add inert, it would be similar to visibility, can set
it differently inside a subtree
emilio: might have use cases for inert unable to flip within the
subtree
emilio: probably the spec should call out this edge case, and define
the behavior explicitly
emilio: if you have fullscreen element inside, define that behavior
fantasai: For visibility: hidden you can flip back to visible, but
visibility: collapse into a flex item doesn't allow you to
do that
fantasai: so visibility has that behavior as well
astearns: Ready to resolve?
flackr: Inertness is determined by the base computed style for
'display', resulting in animations to 'none' being
considered inert
astearns: Can make that claim generally, not just during animations?
flackr: Base computed style is all styles before animations
astearns: Any other comments or concerns?
RESOLVED: Inertness is determined by the base computed style for
'display', resulting in animations to 'none' being
considered inert
astearns: +1 to having tests for this
CSS Position
============
scribe: emilio
Containing block formed by fragmented inlines
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8284
<fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3E%3Cdiv%20style%3D%22background%3A%20gray%3B%20width%3A%20100px%3B%20height%3A%201em%3B%20display%3A%20inline-block%22%3E%3C%2Fdiv%3E%3Cspan%20style%3D%22position%3A%20relative%3B%20border%3A%20solid%20blue%22%3E%3Cspan%20style%3D%22position%3A%20absolute%3B%20inset%3A%200%3B%20border%3A%20orange%20solid%22%3E%3C%2Fspan%3Efirst%20and%3Cbr%3Esecond%20line%20that%27s%20very%20long%20and%3Cbr%3Ethird%3C%2Fspan%3E%0A%3Cp%3E%3Cspan%20style%3D%22position%3A%20relative%3B%20border%3A%20solid%20blue%22%3E%3Cspan%20style%3D%22position%3A%20absolute%3B%20inset%3A%200%3B%20border%3A%20orange%20solid%22%3E%3C%2Fspan%3Efirst%20and%3Cbr%3Esecond%20line%20that%27s%20very%20long%20and%3Cbr%3Ethird%3C%2Fspan%3E
fantasai: What do we do when the absolute positioned box is an
inline but it spans multiple lines
[fantasai describes test-case]
fantasai: firefox and chrome disagree
fantasai: So... on a single line the abspos cb is the line's bounds
fantasai: When it spans multiple lines we could use join the
top-left of the first fragment and the bottom-right of the
last
fantasai: but if the last line is to the left of the first it
creates a negative area
fantasai: chrome / webkit collapse the width to zero
fantasai: firefox does [missing]
fantasai: There are pros and cons to both approaches
fantasai: The four things we think we can do are in the bullet list
in the last comment
<fantasai> Use the first line's fragments only (so the entire
containing block is contained by its generating box).
<fantasai> Anchor at the start/start corner of the first line box
and extend to the end/end corner of the last line box,
but clamp the inline size at zero (so the end/end corner
might not overlap with a fragment).
<fantasai> Anchor at the start/start corner of the first line box
and extend to the end/end corner of the last line box,
and allow inversions (so the corners are pinned to actual
fragment corners, but the containing block might end up
between fragments).
<fantasai> Anchor at the start/start corner of the first line box
and extend to the end/end corner of either the last line
box (if that's endward of the start line) or of the first
line box (otherwise).
<dbaron> There's some old discussion of this in
https://bugzilla.mozilla.org/show_bug.cgi?id=489100 and
maybe also the somewhat-related
https://bugzilla.mozilla.org/show_bug.cgi?id=489207
TabAtkins: My preferred behavior is to anchor the top left of top
left of the first fragment, anchor bottom to the bottom
of the last fragment, and anchor right to the right-edge
of either the whole fragment, or line box edge if there
are multiple
TabAtkins: Allows cb to be as tall as the whole multi-line text box
TabAtkins: and also as wide as the whole text
TabAtkins: If there's text going further on later lines it'd be good
to include that on the box left
TabAtkins: so top-left to top-left of first fragment (matches webkit
+ blink + ff)
TabAtkins: bottom matching blink/webkit
TabAtkins: and right edge to the right edge of line box (if
multi-line) or end of fragment if it's single-fragment
<fantasai> ... rather than whereever the first fragment happened to
break
<fantasai> Tab's proposal seems reasonable to me...
dbaron: This is something I thought about a good bit about a decade
ago
dbaron: Two things I wanna point out
dbaron: One is that it's worth being reasonably careful about
directionality
dbaron: I think we all do this based on the direction prop of the
inline
dbaron: iirc chrome didn't handle rtl well but edge did
<iank> we've fixed stuff
dbaron: Related issue issue is: how do auto-offsets behave for
absposes inside inlines
dbaron: Maybe it's not that related but there are a few interesting
aspects to it
iank: Worth retesting Chrome because we've fixed a lot of these
iank: One thing to note is the start and end is complicated, because
the IFC can have different direction to the inline CB
iank: I _believe_ we use the direction of the IFC
<TabAtkins> Yeah, I'd think the IFC is probably the most coherent
thing to take the directions from?
iank: We don't necessarily want to do that but it makes sense given
all the edge cases
iank: When you say linebox we don't quite want that
iank: you probably want the max IFC inline edge coordinate
iank: because you can have multiple fragments in one line
iank: and those might not go at the end of the line box
TabAtkins: If the inline starts at the left edge of the text area
and it covers multiple lines the CB should fill the box
TabAtkins: even if the actual text bounds is slightly narrower
iank: You can have the situation where the span won't go all the way
to the inline edge but there may be some text there
iank: but it is different
iank: I think tab's proposal seems fine
astearns: I don't like something about tab's proposal, which is the
difference for the determination for the start and end edge
astearns: I think it'd make sense to also take the smallest start
edge
iank: I doubt that'd be compatible
iank: That's interoperable now, it's used to do something like a
caret at the start of an inline
TabAtkins: That's why
astearns: It's just a weird result where the orange box covers half
of the paragraph in fantasai's test-case
TabAtkins: Yeah, but it's very interoperable behavior, so I think
we're stuck with that
dbaron: Are there complications here when the inline is split across
columns/pages?
iank: There are, I can talk about what edge did here, but that's a
long tangent
TabAtkins: So we do still anchor the top-left of the CB to the
top-left of the first fragment there?
dbaron: I think the issue of splitting over columns / pages is one
of the reasons this never got fixed in Gecko
dbaron: but might also be more about the auto behavior
fantasai: Wanted to talk about about what we pin the right edge to
fantasai: end of the first line's last fragment?
fantasai: rightmost of all of the lineboxes?
fantasai: rightmost of all the fragments?
<TabAtkins> My instinct is that if there's a column/etc break, we
put the bottom edge to the end of the last fragment in
that fragmentainer, analogous to the right-edge behavior.
fantasai: line boxes have different edges with floats
<iank> From my perspective right most of either the line-boxes or
the fragments
fantasai: Do we want to consider all of the lines? Or just the first?
iank: Pretty strong bias towards all of the lines
iank: covers the case where all of the lines might not line up
<TabAtkins> Ah, I see what you mean by "probably don't want
lineboxes" then, yeah
<TabAtkins> right edge of the IFC or whatever, instead, yeah
<TabAtkins> +1 to rightmost/bottommost of all fragments
fantasai: My proposal would be to use the rightmost edge of all of
the fragments of the inline box
astearns: Hard time coming with a use case for doing much more than
what FF is doing
astearns: The case of putting a caret at the beginning of the line
is the thing we can't change
astearns: What use case is there for having an abspos thing going
over some weird section of a fragmented inline?
TabAtkins: There's no use case for doing both of the horizontal/
vertical bounds we're defining
TabAtkins: but each individually make sense
iank: Someone willing to cover all of the lines
fantasai: That's only useful if the span is the first thing in the
line
iank: True
<TabAtkins> 1) Putting something at the start of the text (requires
top/left to be the top left of the first fragment). 2)
Have something as tall as the text (background, or
overlay, etc).
<TabAtkins> I think those are the two use-cases we can reasonably
address with a single-box solution.
astearns: I worry that we're coming up with this thing that isn't
really motivated by use cases
astearns: we're defining some reasonable behavior for this edge case
where a lot of cases we could get the abspos cb further up
astearns: firefox's behavior seems simpler to spec and doesn't run
into fragmentation issues
iank: we have a solution for fragmentation
<TabAtkins> +1
iank: but somewhat hard
iank: probably don't have time on this call to consider it
iank: I think we should consider at least all of the lines' block
edges
fantasai: Proposal is that in LTR-tb the top-left corner is the
top-left corner of the top-left-most fragment of the first
line, and the bottom and right edges are bottommost and
rightmost edges of all the fragments
<dholbert> bottom right of all-of-the-fragments, or
all-of-the-line-boxes-that-contain-fragments? (if there's
a <br> that prevents the fragments from hitting the end
of the line)
<dholbert> (my question relates to a distinction that Tab was making
early on; we should be clear whether we're talking about
line boxes vs. fragments for bottom-right corner. Sorry,
my audio seems to be broken)
<emilio> proposal for dholbert's question is using the fragments
themselves
<dholbert> thanks!
<TabAtkins> (afaict, the use-cases I listed are already satisfied by
Chrome/WebKit's behavior, since neither of them depend
on the right side. But I do think a zero-width box
should be avoided if we can.)
<dbaron> (also need to be clear whether that LTR-tb is for the IFC
or the inline)
RESOLVED: Try out the proposal above, spec the fragmentation behavior
<fantasai> analogously for other writing modes, anchoring on the
same writing mode as the painting of borders
fantasai: I think you want the writing-mode of the inline element,
e.g. if you want a flag at the start of the span
emilio: iank was arguing for writing-mode of the IFC
<emeyer> I have an uneasy feeling about the proposed solution, but
I’m not sure I understand it properly..
<fantasai> Using fragments, because if you have short lines of text
you want the edges of those inlines, not the far right of
the screen
RESOLVED: In LTR-tb the top-left corner is the top-left corner of
the top-left-most fragment of the first line, and the
bottom and right edges are bottommost and rightmost edges
of all the fragments. Directionality comes from the inline
<fantasai> see testcase on borders:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3EThis%20%3Cspan%20dir%3Drtl%20style%3D%22border%3A%20solid%22%3Etest%3Cbr%3Eborder%3C%2Fspan%3E%3C%2Fp%3ERESOL
<TabAtkins> emeyer, top/left/bottom edge all match Chrome's current
behavior, right edge is the rightmost of *all* fragments
(rather than just the first, like what FF currently
does, or the last-but-clamped, like Chrome currently
does)
CSSOM & Backgrounds
===================
Serialization of `background: none`
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8496
TabAtkins: Question is how does `background: none` serialize. Using
shortest serialization and grammar is unclear
TabAtkins: because if you only specify one layer it matches
final-background-layer and image-layer
TabAtkins: and since color is the first in the
final-background-layer safari they serialize transparent
TabAtkins: other browsers serialize none
TabAtkins: Proposal is to move color to the end of final-bg-layer
TabAtkins: which makes it serialize as none
fantasai: I think it's great because it moves color to the end
fantasai: which makes sense because it's at the bottom
fantasai: but that would be a change to how a color + image
serializes, and I'm not sure that's Web-compatible
RESOLVED: Move color at the end of the final-bg-layer grammar, to
make it serialize as `none`
Received on Thursday, 9 March 2023 00:30:21 UTC