- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Sep 2021 19:36:00 -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.
=========================================
TPAC Reminders
--------------
- There are calls scheduled with i18n and a11y on 20th and 27th.
Please tag Agenda+TPAC on issues that should be discussed during
those calls.
CSS Positioned Layout L3
------------------------
- Please review the updated spec text. Next week there will be a
request for republication.
- RESOLVED: Close no change: taking BR out of flow removes its effect
on the surrounding content, just like every other element
(Issue #5749: What is the behavior of an
absolutely-positioned <br>?)
CSS Highlight API
-----------------
- RESOLVED: Reference DOM's definition of invalidity for static
ranges for highlight API (Issue #5497: Invalidation of
Static Ranges)
- RESOLVED: Republish Highlight API
CSS Scrollbars
--------------
- RESOLVED: Retitle CSS Scrollbars to CSS Scrollbar Styling (Issue
#6549: Improve title)
- RESOLVED: Republish CSS Scrollbars
CSS Color Adjust
----------------
- RESOLVED: Move css-color-adjust-1 to CR
- If a decision isn't reached on issue #5469 (Should forced-colors
override `border-image`?) before the CR publication it will be
noted inline as an open issue.
CSS Sizing
----------
- RESOLVED: Add marquee to compressible elements (Issue #6342: Add
<marquee> to list of compressible elements)
- Issue #6754 (Definiteness of min-height: min-content) needs some
additional discussion off the call about what option is most
consistent and/or doesn't have negative performance implications.
Hit Testing
-----------
- chrishtr will take the lead on reviewing the differences between
Gecko and Blink implementations.
- There is still no volunteer to try and specify hit testing, but the
group would be interested in doing so if anyone does step forward.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Sep/0003.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Christian Biesinger
Oriol Brufau
Tantek Çelik
Dan Clark
Emilio Cobos Álvarez
Elika Etemad
Megan Gardner
Daniel Holbert
Sanket Joshi
Jonathan Kew
Ting-Yu Lin
Peter Linss
Morgan Reschenberg
François Remy
Jen Simmons
Miriam Suzanne
Regrets:
Chris Lilley
Lea Verou
Scribe: fantasai
Scribe's scribe: TabAtkins
Rossen: Any additional topics?
smfr: Hit testing isn't specified anywhere, and CSSWG has said
doesn't want to spec it
smfr: but inert attribute affects hit testing, can't define clearly
<emilio> smfr: you aware of https://github.com/whatwg/html/issues/5650 ?
TPAC Reminders
==============
Rossen: Calls with i18n and a11y on 20th and 27th
astearns: They will be during our regular telecons
astearns: There's a bunch of issues tagged, but probably too many for
a single hour each
astearns: If people could review and tag Agenda+ TPAC as appropriate,
would be helpful
astearns: Note that we will not have our usual calls those weeks
astearns: I'll post all the details to the internal list
CSS Positioned Layout L3
========================
<astearns> https://drafts.csswg.org/css-position-3/#changes
fantasai: I wanted to repub. We fixed a pile of errors, hopefully
correctly.
fantasai: We'd particularly appreciate review from Oriol and Ian.
fantasai: So would like to update the draft.
Rossen: Do you want to republish now, or ask for review this week?
fantasai: I'll let Oriol make that call, I haven't reviewed his
comments since yesterday
<oriol> It's https://github.com/w3c/csswg-drafts/issues/6580
oriol: I didn't review everything, but filed an issue about one part
that's confusing
Rossen: OK, sounds like we'll call for review this week and republish
next week
CSS Highlight API
=================
Invalidation of Static Ranges
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/4597
<dandclark> https://dom.spec.whatwg.org/#staticrange-valid
dandclark: Discussed structures for representing highlights
dandclark: Author could choose live or static ranges, with different
perf considerations each
dandclark: Issue was originally open to discuss, given static ranges
can become stale
dandclark: What is an invalid static range that we should not try to
paint?
dandclark: Do we want to have highlight API spec point to these
definitions in DOM spec, or do we want a different
definition
dandclark: ...
dandclark: [reads criteria]
florian: I think it's likely a good idea to point to DOM
florian: Reason this is new is that it's first time in the platform
that the static range is created by user and passed to UA
florian: other uses the UA passes to user
florian: The criteria listed are reasonable, but ...
florian: but is sensitive to the length of the node
sanketj: Should just follow DOM definition
fantasai: What about the length?
fantasai: What is the length of a node?
sanketj: For text it's number of characters
<cbiesinger> is that code points? code units?
<sanketj> @cbiesinger, yes, code units
florian: So if you have an offset bigger than length of node, one
behavior is to treat whole thing as invalid
florian: other behavior that we had originally was to clamp to within
the length
florian: Going with DOM's definition seems reasonable
Rossen: Any objections to using DOM's definition of invalid for
static ranges?
RESOLVED: Reference DOM's definition of invalidity for static ranges
for highlight API
fantasai: Do we need to republish?
fantasai: Last publication was 2020
RESOLVED: Republish highlight API
CSS Scrollbars L1
=================
Improve Title
-------------
github: https://github.com/w3c/csswg-drafts/issues/6549
fantasai: The title is "CSS Scrollbars", but we're not actually
generating scrollbars
fantasai: We're styling them, so I propose renaming to "Scrollbar
Styling"
Rossen: That makes too much sense.
TabAtkins: I presume no shortname change, just a title change?
fantasai: Yes
RESOLVED: Retitle CSS Scrollbars to CSS Scrollbar Styling
RESOLVED: Republish
CSS Positioned Layout
=====================
What is the behavior of an absolutely-positioned <br>?
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5749
Rossen: Seems the proposal is to close no change.
smfr: Question is if you have a <br> and say 'position: absolute'.
Does it trigger line breaks?
smfr: 'position: absolute' takes it out of flow
smfr: which probably means it shouldn't trigger a line break
smfr: so I think Gecko has the right behavior
smfr: Slight concern about if it's web-compatible, but if Gecko's
shipping probably OK
Rossen: Do we have any specific spec text defining it one way or
another?
smfr: I think the spec is fine, just implementers not following spec
florian: That and fact that BR and WBR aren't properly specced fully
florian: We've had discussions about how to represent them, but
haven't fully resolved
florian: but only logical behavior is if take out of flow, stop
influencing the text round it
Rossen: Sounds like we have consensus for breaking behavior here
Rossen: and that seems to be spec-compliant atm
emilio: I've never heard a compat issue with Gecko's behavior so far
<jfkthame> nor have I, fwiw
Rossen: proposed close issue no change to spec and encourage UAs to
follow Gecko's lead
RESOLVED: Close no change: taking BR out of flow removes its effect
on the surrounding content, just like every other element
<astearns> A testcase would be an excellent encouragement (and smfr
just added the tag to the issue)
emilio: Where does the WebKit behavior come from?
smfr: It's probably very historical
iank: BR inherits from text node, so has ...
CSS Color Adjust
================
Should forced-colors override `border-image`?
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5469#issuecomment-707918323
TabAtkins: This is the only issue open to block us from CR
TabAtkins: we pinged you repeatedly for the answer, and no response
TabAtkins: So put it on the agenda.
Rossen: Have some colleagues closer to the implementation, will tag
them.
fremy: wouldn't mind keeping the border image, just in case
Rossen: hopefully close on this before the end of the week
Rossen: horizontal review issue?
fantasai: We only have the one issue open. Horizontal review is done.
We want to transition to CR, once the border-image issue is
closed.
Rossen: Should we resolve provisionally, or resolve next week?
TabAtkins: up to the chair :)
Rossen: Current spec doesn't override border-image?
TabAtkins: Current spec calls for that I believe
TabAtkins: border-image is not on the list of properties getting
overridden
Rossen: That reflects current implementations. Don't see why we'd
want to change it. Does anyone have a different opinion?
TabAtkins: We're not trying to resolve on the open question right now.
TabAtkins: Question is do we want to move to CR?
Rossen: Current spec matches our expectations
<fremy> +1 to what Rossen said; also border-image is quite rare, it's
tough to say why it's used because it can be creative
TabAtkins: Question is, do we want to resolve regardless of how that
issue is resolved, or do we want to wait for that issue
before deciding?
Rossen: Currently we can proceed with CR. I will follow up with folks
here today and have closing arguments in the issue by end of
week
Rossen: If we end up changing, let's handle it later
tantek: Is the issue linked in the draft?
TabAtkins: No
Rossen: If we can't close this, put a link in there
<tantek> perhaps in the status section
Rossen: OK, calling for provisional CR transition resolution
Rossen: Any last concerns to moving forward with transition?
Publication
-----------
github: https://github.com/w3c/csswg-drafts/issues/5768
RESOLVED: Move css-color-adjust-1 to CR
CSS Sizing
==========
Add <marquee> to list of compressible elements
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6342
fantasai: We were told to add <marquee> to the list of compressible
elements, wondering if there's any objection
Rossen: Any opinions?
RESOLVED: Add marquee to compressible elements
Definiteness of min-height: min-content
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6457
“The original question still remains: the spec is currently implying
that the content-based sizing keywords in the min-* properties
don't prevent children from resolving %s against those sizes
(even though the width/height properties themselves do). This is
necessary behavior for the automatic minimum size (or else
percentages would usually be unresolvable), which can be
content-based, so it seems like it should be fine to specify that
explicitly for all the content-based sizing keywords. But given
that these keywords aren't otherwise representing definite sizes,
do we actually want to?”
TabAtkins: Original question of issue is still open
TabAtkins: For reasons of usability, we had to rule that 'min-size:
auto' does not prevent percentages on your children from
resolving
TabAtkins: even though technically the size of parent might be
dependent on size of contents
TabAtkins: because if not, percentages would hardly ever resolve in
flex or grid
TabAtkins: But we have also the min-content and max-content keywords
TabAtkins: Do we make these also not block percentage resolution on
children?
TabAtkins: Or do we want to hold the line, and have these
content-based keywords block percentage resolution
TabAtkins: just like they do in the not-min sizing properties (width/
height/etc.)
TabAtkins: Not necessarily need to resolve now, but wanted to bring
up the question
iank: I'd want to discuss with David
dholbert: I think given how treated as 'auto' right now, there might
be web-compat demand for them to have same definiteness
properties.
fantasai: Given they're "treated as auto" and not commonly used,
there's not much incentive for authors to use them right
now, especially in a min-size property; feels unlikely that
there's compat risk
Rossen: Any concrete use cases?
TabAtkins: no, this is a question of consistency
TabAtkins: what kind of divergence do we want here
TabAtkins: we need an answer for the spec, but having use cases
dholbert: For non-definite case
dholbert: consider a deeply-nested flexbox case
dholbert: Want content-based minimum
dholbert: but don't want performance complications
dholbert: so switch from auto to min-content
dholbert: That said, browser could also maybe detect the lack of
percentages inside the element
dholbert: and not run the second layout pass
dholbert: Can't think of another justification for not being definite
jfkthame: Agree
Rossen: The deeply nested elements can be made context aware and
resolve % only in the cases of having both % and min-content
Rossen: I think the performance problem stated here is more of a
speculation
Rossen: less a concrete concern
Rossen: My preference would be to keep it consistent
fantasai: Consistency works both ways
fantasai: These keywords in 'height' cause it to be indefinite
fantasai: So do we want to be consistent with that? or with
'min-height: auto'?
Rossen: Where do we go from here?
fantasai: Tab and I are happy for people to think about it. We just
wanted to bring it up and explain on the call.
Hit Testing
===========
Rossen: We don't have it specified anywhere, but acknowledge that it
exists
Rossen: and smfr points out that the inert attribute is under-defined
as a result
<smfr> https://github.com/whatwg/html/issues/5650
smfr: This is the a WHATWG issue that discussion is in
smfr: The inert attribute in HTML is intended to make an element
unresponsive to user interaction and also hidden from a11y
smfr: One of the intended uses is, in combination with dialog,
smfr: ....
smfr: behaves as though has inert attribute, not interactive
smfr: Gecko and Chrome have initial implementations of this attribute
smfr: which differ in how they prevent interaction
smfr: Chrome has gone with a more DOM-based approach, kinda like
disabled form control
smfr: Emilio's approach in Gecko is different, more like
'pointer-elements: none'
smfr: These have different behaviors wrt z-index, if you stack
elements, what happens when you click on it?
smfr: also [...]
smfr: Also, can a non-inert tree have an inert tree (???)
smfr: Trying to resolve differences between Gecko and Blink's
interpretations
smfr: Emilio believes not specified well enough for any browser to
ship it
smfr: There are some WPT, but not exhaustive
emilio: In particular, Blink's implementation also have some event
retargeting going on
emilio: Implementing it in either existing or new CSS primitives
would be great
emilio: but question of hit testing is not defined
florian: Earlier you stated that we decided we didn't want to specify
it
florian: I think our conclusion was more that it's a giant topic and
nobody is taking it up, rather than it's out of scope for us
florian: We could do it, but nobody is signing up
smfr: Hit testing is the inverse of painting, so should be able to
specify it
smfr: Also elementFromPoint is in CSSOM-view, which involves hit
testing
florian: So maybe need to bite the bullet and find someone to do it
chrishtr: Which spec would it go into?
florian: We had an earlier discussion that the property
'pointer-events' could go into css-ui
florian: as long as just a switch, why not
florian: but scope of defining all of hit testing is probably too much
florian: so probably want a standalone spec
chrishtr: Also painting is also not in an awesome spec location
either, in CSS2 right?
florian: Yes, we want a standalone spec for that also
florian: Then as new specs tweak it, can refer to that. But need a
foundation document
chrishtr: So new spec for painting, and also hit testing
chrishtr: I've been sad about state of painting also
florian: So, now that we've increased the scope :) Still looking for
a volunteer to do it
chrishtr: I'll try to find someone
Rossen: Sounds good
Rossen: Anything specific, smfr?
smfr: Would like to solve this issue before we have a hit testing
spec, because that will take years, but we need to implement
chrishtr: Alice (??) was the one who implemented, and wanted to try
to ship, but then discussions with Gecko ...
chrishtr: I will volunteer to go back and reread the blink-dev thread
chrishtr: and then respond with an update
chrishtr: I think we're quite close to having this in all three
browsers, which would be nice to achieve
Rossen: So, a lot of volunteering from Chris, which is great.
Hopefully issue will make progress, and maybe we'll even work
on it.
Rossen: Assuming nothing else on this topic, and we did everything on
the agenda
Rossen: let's close
tantek: Did we get the funding we needed for infrastructure?
<TabAtkins> nope, not yet
Rossen: I haven't heard anything. Anyone else?
Received on Wednesday, 8 September 2021 23:36:41 UTC