- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 4 Nov 2020 09:51:26 -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.
=========================================
CSS Multicol
------------
- RESOLVED: Containing block chain goes straight from spanner to the
multicol container
- RESOLVED: Publish a new WD of multicol after these edits have been
committed
CSS Grid
--------
- After discussion on issue #5566 after the call on Monday there was
a proposal to resolve that percentage of row tracks and gutters
of grid with indefinite height to auto for tracks and 0 for
gutters.
- There was an objections to this in favor of symmetry between
tracks and gutters so more outreach will be done to those
working specifically on layout.
CSS Position
------------
- RESOLVED: Add a hidden pseudo-class for this purpose, in order to
solve styling issue while leaving open the possibility
of HTML improving its API (Issue #4645: <dialog>
positioning should be describable in CSS)
CSS Logical Properties
----------------------
- RESOLVED: Inheritance of logical properties inherits the
corresponding logical property on the parent (Issue
#3029: Order of inheritance vs. mapping in logical
properties)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2020#agenda-schedule
Present:
Rachel Andrew, Fronteers
Rossen Atanassov, Microsoft
Tab Atkins-Bittner, Google
Christian Biesinger, Google
Mike Bremford, BFO
Oriol Brufau, Igalia
Tantek Çelik, Mozilla
Daniel Clark, Microsoft
Emilio Cobos Álvarez, Mozilla
Jon Davis, Pearson
Elika Etemad, Invited Expert
Brandon Ferrua, Salesforce
Megan Gardner, Apple
Brian Kardell, Igalia
Chris Lilley, W3C
Ting-Yu Lin, Mozilla
Alison Maher, Microsoft
Myles C. Maxfield, Apple Inc.
Manuel Rego, Igalia
François REMY, Invited Expert
Morgan Reschenberg, Mozilla
Florian Rivoal, Invited Expert
Jen Simmons, Apple, Inc.
Alan Stearns, Adobe
Miriam Suzanne, Invited Expert
Lea Verou, Invited Expert
Greg Whitworth, Salesforce
Fuqiao Xue, W3C
Scribe: TabAtkins
CSS Multicol
============
Containing block of column spanners
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5612
rachelandrew: Good details in the issue
rachelandrew: We don't have interop
rachelandrew: If you have abspos in a column spanner, not clear the
what containing block should be
rachelandrew: Three different options currently
rachelandrew: In the issue it came down that probably either #2 or
#3 would be most likely, either viewport (WebKit and
EdgeHTML) or the column spanner itself
rachelandrew: I suspect authors would assume the spanner is the
containing block, or at least would want that ability
rachelandrew: Option 1 is problematic anyway
rachelandrew: In gecko it would be harder to implement option 2
rachelandrew: So it's between 2 and 3, viewport and spanner
fantasai: I think option 3 is a little weird - it doesn't have relpos
fantasai: Unless there's something particularly interesting
happening on, like transform, elements don't trap abspos
unless they're relpos
fantasai: So while I'm totally fine with skipping the fragmenting
grandparent
fantasai: I think it would be weird to stop at the spanner and
not go up to the multicol itself if *that* has relpos
fantasai: and otherwise fall up to the ICB
iank: Chrome broadly agrees with that
florian: I was thinking as well
Rossen: EdgeHTML as well, the spanner is nothing special, you just
walk the ancestor chain as normal until you find a
positioned element
florian: That's a little different from what fantasai described, I
think
florian: If you have a relpos parent of the spanner, if you go by
ancestry in the tree, that would capture the abspos
florian: fantasai was talking about skipping past that straight to
the multicol, to avoid fragmentation issues
iank: Part of the problem is that the spanner isn't really
positioned in flow, it's positioned by the multicol, so option
2 is kinda in that direction
fantasai: I think from an author's perspective, yeah, skipping from
spanner to multicol would make the most sense since the
spanner isn't fragmented
fantasai: That's option 2, yeah; option 3 makes the spanner the
containing block regardless of its 'position', which seems
unexpected
fantasai: So the containing block chain should go spanner ->
multicol -> normal ancestry from there
florian: I'm confused, option 2 says viewport
astearns: If you read the text it goes into more detail
fantasai: There's no relpos in the example, that's why it goes up to
viewport
TYLin: I think option 2 is best, Gecko is buggy in edge cases
astearns: So it sounds like option 2 has consensus, containing block
chain goes spanner -> multicol and then normal from there
astearns: objections?
RESOLVED: CB chain goes straight from spanner to the multicol
container
Publication
-----------
rachelandrew: I'd also like to publish
chris: I suggest you put "Wide Review" in the SOTD, that serves the
same purpose as Last Call used to
<fantasai> https://www.w3.org/Guide/documentreview/
fantasai: And issue review requests, documented in ^^^
chris: If you need help, let us know
iank: As an fyi, google/microsoft are working on a new fragmentation
engine, which is why these issues are coming up now. we might
find more; we'll file as we do
astearns: So any objections to publishing a new draft?
RESOLVED: Publish a new WD of multicol after these edits have been
committed
CSS Grid
========
Resolution of percentage row tracks and gutters with indefinite height
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5566
rego: We discussed on Monday, asked for feedback
rego: Rachel had some comments
rachelandrew: The reason I'm seeing percentages in use is because
people are putting a grid component in an older layout
that uses percentages, because that's how we did
things with floats or even flexboxes
rachelandrew: And people generally only cared about columns, then
rachelandrew: I like staying with the symmetry, but I don't know
whether authors really expect symmetry. Probably more
important that Flex and Grid behave similarly, so I'd
be generally okay with the change.
astearns: Can you summarize for a resolution?
rego: resolve percentage of row tracks and gutters of grid with
indefinite height to auto for tracks and 0 for gutters
Rossen: Gonna be the shining voice on the hill
Rossen: Symmetry was an important part of grid and made it what it
was
Rossen: We're trying to break that principle here. I object to this
decision.
Rossen: But before I do that I want to go back and understand what
the current interop is
Rossen: Because we don't have a 2d layout system that we can have
precedent with
Rossen: We can only have interop between the Grid impls themselves
Rossen: So are we talking about interop with 1d layout systems like
Block and Flex, or between the UA impls?
astearns: Is there a consensus across impls yet?
rego: There are no track interop, there's interop on gutters.
Firefox would have to change track, but Mats says he wants to
change.
rego: With regards to Rossen's other issues, I don't know about that.
astearns: Rossen, do you have a plan to bring people around to your
objection?
Rossen: Not as part of this call.
Rossen: Issue is, what's the pressing issue? Why do we need to
resolve now? Take it another way - we've discussed this in
the past many times, another fix is to get rid of percentage
in gutters.
fantasai: Far too late for that
Rossen: But not too late to break grid, apparently?
fantasai: Percentages in gutters works just fine between columns,
and people are using them
fantasai: This is just about between rows (and in an indef height)
fantasai: So what we need is interop between browsers. And right now
we have interop on the behavior you want for gap between
rows.
fantasai: But we don't have interop for sizing tracks
fantasai: Chrome/webkit have one behavior, the one you wanted iiuc,
Firefox has another behavior
fantasai: This is causing problems because we have impls behaving
differently, so rego wants to fix that.
fantasai: So either Firefox has to change their behavior for tracks,
or Chrome/WebKit has to; one of those has to happen, then
we have interop
fantasai: And if Chrome/WebKit changes behavior, we should make gaps
behave the same way as well, which is further change
fantasai: We could theoretically go either way, but we need at least
one group of people to switch their behavior.
florian: One step I didn't follow - if Chrome/WebKit align with
Firefox, that would mean percentage on gaps and tracks
don't work the same?
fantasai: Yeah, which is why the issue says if we do that we should
also switch the gap behavior, even though we currently
have gap interop.
fantasai: I think that percentage gaps between rows are rarely used
so their behavior isn't a big issue, it's mainly just a
cleanup step to keep them consistent.
fantasai: It's really about which behavior we end up with for row
sizing
Rossen: So if current impls impl % row-gaps behavior the same, it's
essentially the same behavior that they need for row tracks?
Rossen: I'm curious about the new Chrome Grid rewrite, which
behavior is currently there
Rossen: It seems like it's the symmetric one, right?
rego: I dunno if the new grid impl has this behavior done yet
<iank> not currently implemented yet afiak.
Rossen: What I see currently is that Chrome/Firefox/WebKit have same
behavior
rego: For gutters, yes. For tracks Firefox has the different behavior
rego: Firefox resolves percentage rows to auto, and that's not
following the spec, it's alone in that behavior
rego: So if we keep the spec as is, only Firefox has to change.
rego: This proposal would take Firefox's behavior, so the other
browsers would change.
rego: When I did back-compat analysis, there were three pages that
did better in Firefox and only 1 that did worse
rego: But Chrome/WebKit aren't getting bugs reported on this,
despite the lack of interop
astearns: So sounds like we won't have agreement here
rego: Should ask the layout people about things
rego: And Mats
astearns: Yeah he said yes one way, should see if he's okay with the
other way
astearns: So we'll table this for now
CSS Position
============
scribe: florian
<dialog> positioning should be describable in CSS
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4645
TabAtkins: There's a discussion in HTML about fixing the dialog
element to use CSS instead of being a hack
TabAtkins: They realized that there's a big difference between
TabAtkins: when it's opened normally vs as a modal
TabAtkins: It's based purely on which js method you use to open it
TabAtkins: so we need some way to distinguish, and a pseudo class
seems most natural
TabAtkins: The proposal is :modal
TabAtkins: Seems good to me, but we need to make sure we don't want
to use it for something else
leaverou: Feels like defining a pseudo class to work around a
problem with the API
leaverou: Seems to me that there should be a modal attribute
leaverou: Don't see why we need to fix it in css
<fantasai> +1
<miriam> +1
<brandon> +1
leaverou: Seems weird that you need to use JS, and cannot do it in
markup, when you can already use the `open` attribute to
open it in a non-modal way
emilio: Toggling the attribute is not the same as calling dialog.open
emilio: It's bad, but that's the way it is
<emilio> https://github.com/whatwg/html/issues/5802
iank: It is a strange API, don't want to add more attributes to it
<leaverou> if the API is messy, maybe it needs more work before we
add things to CSS for it?
gregwhitworth: If this is so bad, and is so confusing, why are we
duck-taping this?
iank: Many sites use it, so there's a big compat risk
iank: We aren't happy with how the modal works today, and we're
willing to change
iank: ... to make it describable in css
iank: If we were doing it from scratch today, we'd do it differently
smfr: modal go in a magic layer of over the page
smfr: ...
iank: ......
smfr: I would like to define the top layer to be used by other
elements, it could be used here
smfr: I suggest to use UA stylesheet rules to also describe the
top-layer behavior of the modal dialog
scribe: fantasai
iank: Broadly speaking, this is what the HTML pull request does
today. It adds one new pseudo-class, :modal, and removes all
of the special-case rendering logic
iank: and replaces it basically with one additional UA stylesheet
rule
iank: What gives me confidence in this approach is that this is what
Gecko does today, using an internal pseudo-class
iank: One thing it doesn't describe, broader issue, is how does the
"top layer" work.
iank: Tab has previously wanted to explain how that works somewhere
else
iank: This fixes all the special-casing text that was there
previously, except fixing top-layer
iank: Moves us significantly closer
bkardell: There are a few proposals going back to 2014/15 or so
bkardell: to explain top layer
bkardell: not in CSS
bkardell: but there's prior attempts that exist that are worth
looking at
fantasai: Going back to Lea's point, why isn't this an attribute on
the element?
fantasai: We could do all this in the UA stylesheet keyed off an
attribute, wouldn't that be more consistent?
fantasai: Maybe removing/adding modal doesn't do anything because
it's really the show()/hide() methods and how they sync
with [open] that's important...
iank: The open attribute is very special and strange
iank: Wouldn't want to add anything like that
emilio: Adding/Removing the open attribute doesn't fire the relevant
events
emilio: dialog element is expected to be used via JS APIs
emilio: already weird that it has this reflection already
<gregwhitworth> iank, emilio and it wouldn't be web compatible to
add those linkages?
emilio: ...
astearns: Her proposal is to add a new modal attribute, not to
re-use open
leaverou: Can the issues be fixed?
emilio: Tangential to this
emilio: Removing [open] doesn't fire the right events and fix the
behavior currently
emilio: it's not great
emilio: Might want to fix it, but it's a separate issue
gregwhitworth: I agree fixing them is a separate issue, but not
separate wrt this discussion
gregwhitworth: because I like what leaverou is proposing here
gregwhitworth: In order to make dialog more cohesive, I think we
should go back and fix it
gregwhitworth: Is there a massive web-compat problem with making
open do the right thing and fire all the events?
iank: There's a few other pressures here
iank: I would be concerned with any compat change around that area.
Been there for a long while.
iank: Took us 6 months to do compat analysis just for this change
iank: and it's a bit pressing
iank: and with any major compat change, the window closes the longer
it exists
iank: Yes, we can potentially fix open and how that work, yes we can
add modal, but that would take a long time
<leaverou> it seems to not have shipped in Gecko or WebKit, how
popular can it be? https://caniuse.com/?search=dialog
emilio: My other concern with magic attributes that fire events is
XSS
emilio: DETAILS fires an event even when you parse it
emilio: and we only realized about DETAILS way too late
iank: I don't think having an attribute API for dialog is a good idea
iank: I would push back against adding a modal attribute on that
basis
gregwhitworth: Then, channeling Rossen from Grid, I think we should
be going for symmetry
gregwhitworth: Not fixing open maybe but get rid of it
astearns: This discussion seems to be opening wider and wider. Maybe
kick over to Open UI?
astearns: to discuss pseudo vs. attribute vs. no attribute?
iank: If we want to get rid of Chrome's special dialog behavior
here, we can only do this for another few months
iank: People will be relying on dialog, and will rely on our
behavior. So would like a decision now.
iank: At the request of this group and other browser vendors, did a
lot of compat analysis
iank: ...
<leaverou> re: webcompat, <dialog> is used in <0.005% of websites
(6000 in HTTPArchive):
https://docs.google.com/spreadsheets/d/1Ta7amoUeaL4pILhWzH-SCzMX9PsZeb1x_mwrX2C4eY8/edit#gid=781932961
emilio: My other bit about why I think modal attribute is not a
great idea is that it breaks how the JS APIs structure
emilio: Whether modal pseudo-class applies depends on how you open
the dialog
emilio: but you could toggle modal attribute while the dialog is open
emilio: At the point you can toggle modal, ...
[minutes clarification: what Emilio is saying here is "If we can
toggle the modal attribute, then there's no reason for two
different JS APIs to open the dialog"]
emilio: I think that [having a sane model for how these attributes
would behave and fixing the JS API] would be great
emilio: but fixing dialog positioning is important, would rather not
get side-tracked
fantasai: So I agree with iank we should fix the styling issue for
compat reasons asap
fantasai: Clearly, it will take a while for a modal attribute -
maybe that's still a possibility
fantasai: One option is that we intro a new pseudo class that
everyone can use while that's debated
fantasai: Other option is to do one internally the way that FF is
doing, not exposed to the Web
fantasai: then we can decide whether to move forward with
pseudo-class later
TabAtkins: We seem to have fairly broad implementer agreement that
they likely don't want to add modal
TabAtkins: Going back, we could maybe pursue removing open attribute
TabAtkins: so that's a possibility for us
leaverou: Adding a modal attribute is just a possibility. Could
alternately add a value to open
leaverou: open=modal
leaverou: But goes back to ???
leaverou: Introducing HTML elements that can't be used without JS is
an issue
leaverou: Shouldn't we fix this generally?
<leaverou> It sounds like the same arguments apply to <details> as
well
<leaverou> Is the direction we want to go to be adding interactive
HTML elements that can't work without JS?!
<leaverou> shouldn't these issues be addressed instead of giving up
on HTML attributes altogether?
emilio: leaverou, and gregwhitworth, would you be opposed to
defining a hidden pseudo-class, so we can move forward with
the styling issue without changing the public API of this?
emilio: It's nice to expose the pseudo-class from the UA stylesheet
emilio: but also fine with keeping it internal
emilio: and address the open/modal attributes separately from this
<iank> i can live w/ that as well.
astearns: So proposed solution is to add a hidden :modal
pseudo-class for now.
florian: Do we need to define that a hidden pseudo-class exists? Do
we need to spec anything?
TabAtkins: no
emilio: Define in HTML spec using prose instead of a pseudo, but
that's fine
astearns: We'd spec as browser-internal thing, and then if it proves
out, then we write spec text to expose it
leaverou: Is a hidden pseudo-class simply undocumented or actually
unusable by authors?
TabAtkins: Only usable in UA style sheet
gregwhitworth: I think it's a good compromise.
gregwhitworth: Deals with compat issue, but leaves the door open to
improve the API
gregwhitworth: Maybe worth noting it somewhere?
iank: We'll be adding this to the HTML spec , most likely way to
specify this
iank: is to define the :modal pseudo-class and define that it's only
usable in UA stylesheet
iank: maybe call it :-internal-modal
<TabAtkins> Yes, this is the correct way to do it
RESOLVED: Add a hidden pseudo-class for this purpose, in order to
solve styling issue while leaving open the possibility of
HTML improving its API
Logical Properties
==================
scribe: TabAtkins
Order of inheritance vs. mapping in logical properties
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3029
fantasai: Probably best to look at this diagram at the bottom
<fantasai> https://github.com/w3c/csswg-drafts/issues/3029#issuecomment-712953765
fantasai: We've got a set of logical props and physical props
fantasai: So if we have ltr parent and rtl child
fantasai: ltr parent has some set of properties on it that give it
margins on either side
fantasai: and the child has specified "margin-start: inherit"
fantasai: So what does that mean
fantasai: From the parent's left margin (the parent's start) or the
right margin (the child's start)?
fantasai: Currently impls map start/end to a physical side on the
child, using the child's writing mode, then inherit from
the parent's corresponding physical margin
fantasai: The other possible behavior, which is possibly better, is
that the child inherits its start value from the start
value of the parent
<myles> <div id="outer" style="padding-left: 20px padding-right:
30px;" dir="ltr">
<myles> <div id="inner" style="padding-inline-end: inherit"
dir="rtl"></div>
<myles> </div>
fantasai: Note that by the time we have computed values, which is
what we inherit, the left&start margins are set to the
same value, and the right&end are set to the same,
regardless of how they were specified
florian: We don't have any property that is logical & inherited
where this shows up without you explicitly saying
'inherit', right?
fantasai: Right, not so far.
fantasai: But if we did, I suspect we'd want the start margin of the
child to inherit from the start margin of the parent, not
from the matching physical side
fantasai: That's my suspicion, at least
fremy: That's also my assessment
fremy: If you wanted to inherit the right margin, you'd have said
"margin-right". If you say margin-start, you want the start
margin
fremy: If you had text-indent, you want the text-indent value,
whether it's ltr or rtl.
<fantasai> fremy, that's a good example
myles: We're positive on this change to have the writing mode
resolved based on the parent, not the child, for inheritance
myles: Two reasons for this
myles: fremy gave an argument from the author's perspective
myles: But I think the user wants it too - if they're reading a book
where paragraphs have a padding on one side, and one
paragraph is on a different writing mode, the padding should
probably flip sides
myles: Second is that it makes logical props more of a first-class
citizen
myles: This means inheritance doesn't "prefer" physical props, you
inherit what's specified, so that logical properties are more
of a first-class citizen
myles: That's good for the world and authors, but also good for impls
myles: Right now our code is a little more complicated than it could
be to make it prefer physical props
astearns: I'm assuming, r12a, that you're okay with this proposal?
r12a: Yes, I think I suggested this in the first place, so I'm happy
with it
proposed resolution: inheritance of logical properties inherits the
corresponding logical property on the parent
emilio: A bit skeptical that this is easier to implement. You only
store one value in the computed style, a physical one
emilio: So this breaks some computed-style optimizations
emilio: When two properties map to one value, you have to choose one
or the other, and right now impls agree with using the
physical one, which they store in the style
emilio: So this means you have to add a pass after applying
declarations, to know if your writing mode is different, you
should inherit them differently
astearns: So you're saying the impl may be more difficult than
stated, but are you objecting?
emilio: I think it would be unfortunate, especially given current
interop, but I don't think I have an objection until I try
to implement and it's gross
myles: So you mentioned that we only store one set of values. That's
true; neither proposal requires us to store multiple values
emilio: Right, but when you inherit a style you have a copyable part
of the style which is what inherits
emilio: All impls separate inherited data and non-inherited
emilio: So if any of them come from a logical prop, you'll need to
do the work and inherit it specially with the writing mode
of the parent
emilio: So it breaks the simple "pointer bump" impl
myles: I agree that would be an issue if this was a common thing
emilio: Right. So I think maybe you're just moving a special case
from one place to another, but...
astearns: So, any objections?
RESOLVED: inheritance of logical properties inherits the
corresponding logical property on the parent
<br until=":30">
Received on Wednesday, 4 November 2020 14:52:32 UTC