Meeting minutes
rossen: Any other 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://
TPAC Reminders
Rossen_: Calls with i18n and a11y on 20th and 27th
astearns: They will be during our regular telecons
astearns: buch 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
<TabAtkins> fantasai: I wanted to repub. We fixed a pile of errors, hopefully correctly.
<TabAtkins> fantasai: We'd particularly appreciate review from Oriol and Ian.
<astearns> https://
<TabAtkins> fantasai: So would like to update the draft.
Rossen_: Do you want to republish now, or ask for reiew this week?
fantasai: I'll let Oriol make that call, I haven't reviewed his comments since yesterday
<oriol> It's https://
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
Invalidation of Static Ranges
github: https://
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> https://
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?
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?
Resolution: Reference DOM's definition of invalidity for static ranges for highlight API
<sanketj> @cbiesinger, yes, code units
fantasai: Do we need to republish?
fantasai: Last publication with 2020
Resolution: Republish highlight API
CSS Scrollbars L1
github: https://
<TabAtkins> fantasai: The title is "CSS Scrollbars", but we're not actually generating scrollbars
<TabAtkins> fantasai: We're styling them, so I propose renaming to "Scrollbar Styling"
Rossen_: That makes too much sense.
<TabAtkins> TabAtkins: I presume no shortname change, just a title change?
TabAtkins: presume we keep the shortname?
fantasai: yep
<TabAtkins> fantasai: yes
Resolution: Retitle CSS Scrollbars to CSS Scrollbar Styling
Resolution: Republish
CSS Positioned Layout
github: https://
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
Rossen_: proposed close issue no change to spec and encourage UAs to follow Gecko's lead
Resolution: 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
github: https://
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> 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://
Resolution: Move css-color-adjust-1 to CR
marquee vs compressible elements
github: https://
<TabAtkins> fantasai: We were told to add <marquee> to the list of compressible elements, wondering if there's any objection
Rossen_: Any opinions?
Resolution: Add marquee to compressible elements
Definiteness of min-height: min-content
github: https://
“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 quesiton
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.
<TabAtkins> 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 perf 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 perf 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 cal.
end
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 underdefined as a result
<smfr> https://
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 retargetting 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
<TabAtkins> For once, not volunteering.
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 alos
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 eveything 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?
<chrishtr> lol 2 is enough for me today :)
Meeting closed.