16:02:42 <RRSAgent> RRSAgent has joined #css
16:02:42 <RRSAgent> logging to https://www.w3.org/2021/09/08-css-irc
16:02:42 <smfr> smfr has joined #css
16:02:44 <Zakim> RRSAgent, make logs Public
16:02:45 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:03:14 <oriol> oriol has joined #css
16:03:17 <jensimmons> present+
16:04:25 <oriol> present+
16:04:25 <sanketj> present+
16:04:42 <tantek> present+
16:04:52 <ffiori> ffiori has joined #css
16:05:06 <ffiori> ffiori has left #css
16:05:43 <fantasai> smfr: hit testing isn't specified anywhere, and CSSWG has said doesn't want to spec it
16:05:51 <fantasai> smfr: but ?? attribute affects hit testing, can't define clearly
16:05:54 <TabAtkins> present+
16:05:57 <astearns> s/??/inert/
16:06:11 <dbaron[m]> Present+
16:06:14 <TabAtkins> present+
16:06:17 <fantasai> i/smfr: hit/rossen: Any other topics?
16:06:24 <emilio> smfr: you aware of https://github.com/whatwg/html/issues/5650?
16:06:27 <fantasai> Topic: TPAC Reminders
16:06:50 <fantasai> Rossen_: Calls with i18n and a11y on 20th and 27th
16:07:14 <fantasai> astearns: They will be during our regular telecons
16:07:37 <fantasai> astearns: buch of issues tagged, but probably too many for a single hour each
16:07:54 <fantasai> astearns: if people could review and tag Agenda+ TPAC as appropriate, would be helpful
16:08:10 <fantasai> astearns: note that we will not have our usual calls those weeks
16:08:46 <fantasai> astearns: I'll post all the details to the internal list
16:09:07 <fantasai> Topic: CSS Positioned Layout L3
16:09:27 <TabAtkins> fantasai: I wanted to repub. We fixed a pile of errors, hopefully correctly.
16:09:42 <TabAtkins> fantasai: We'd particularly appreciate review from Oriol and Ian.
16:09:43 <astearns> https://drafts.csswg.org/css-position-3/#changes
16:09:50 <TabAtkins> fantasai: So would like to update the draft.
16:09:51 <ffiori__> ffiori__ has joined #css
16:10:26 <cbiesinger> present+
16:10:30 <fantasai> Rossen_: Do you want to republish now, or ask for reiew this week?
16:10:54 <fantasai> fantasai: I'll let Oriol make that call, I haven't reviewed his comments since yesterday
16:11:14 <oriol> It's https://github.com/w3c/csswg-drafts/issues/6580
16:11:27 <fantasai> oriol: I didn't review everything, but filed an issue about one part that's confusing
16:11:38 <fantasai> Rossen_: OK, sounds like we'll call for review this week and republish next week
16:12:11 <fantasai> Topic: Invalidation of Static Ranges
16:12:16 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4597
16:12:44 <fantasai> dandclark: Discussed structures for representing highlights
16:12:55 <fantasai> dandclark: author could choose live or static ranges, with different perf considerations each
16:13:10 <fantasai> dandclark: issue was originally open to discuss, given static ranges can become stale
16:13:19 <dandclark> https://dom.spec.whatwg.org/#staticrange-valid
16:13:21 <fantasai> dandclark: what is an invalid static range that we should not try to paint?
16:13:43 <florian> q+
16:13:55 <fantasai> dandclark: Do we want to have highlight API spec point to these definitions in DOM spec, or do we want a different definition
16:13:58 <fantasai> dandclark: ...
16:14:08 <fantasai> dandclark: [reads criteria]
16:14:40 <fantasai> florian: I think it's likely a good idea to point to DOM
16:14:55 <fantasai> 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
16:15:05 <fantasai> florian: other uses the UA passes to user
16:15:21 <fantasai> florian: The criteria listed are reasonable, but ...
16:15:21 <dino> dino has joined #css
16:15:34 <fantasai> florian: but is sensitive to the length of the node
16:15:54 <Rossen_> ack florian
16:16:13 <fantasai> sanketj: Should just follow DOM definition
16:16:54 <fantasai> fantasai: what about the length?
16:17:18 <Rossen_> ack fantasai
16:17:26 <fantasai> fantasai: what is the length of a node?
16:17:42 <fantasai> sanketj: for text it's number of characters
16:18:08 <cbiesinger> is that code points? code units?
16:18:12 <fantasai> florian: so if you have an offset bigger than length of node, one behavior is to treat whole thing as invalid
16:18:21 <fantasai> florian: other behavior that we had originally was to clamp to within the length
16:18:34 <fantasai> florian: going with DOM's definition seems reasonable
16:18:58 <fantasai> Rossen_: Any objections to using DOM's definition of invalid for static ranges?
16:19:15 <fantasai> RESOLVED: Reference DOM's definition of invalidity for static ranges for highlight API
16:19:29 <sanketj> @cbiesinger, yes, code units
16:19:57 <fantasai> fantasai: Do we need to republish?
16:20:08 <fantasai> fantasai: Last publication with 2020
16:20:16 <fantasai> RESOLVED: Republish highlight API
16:20:27 <fantasai> Topic: CSS Scrollbars L1
16:20:33 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6549
16:20:59 <TabAtkins> fantasai: The title is "CSS Scrollbars", but we're not actually generating scrollbars
16:21:10 <TabAtkins> fantasai: We're styling them, so I propose renaming to "Scrollbar Styling"
16:21:15 <fantasai> Rossen_: That makes too much sense.
16:21:27 <TabAtkins> TabAtkins: I presume no shortname change, just a title change?
16:21:27 <fantasai> TabAtkins: presume we keep the shortname?
16:21:28 <fantasai> fantasai: yep
16:21:29 <TabAtkins> fantasai: yes
16:21:44 <fantasai> RESOLVED: Retitle CSS Scrollbars to CSS Scrollbar Styling
16:22:05 <fantasai> RESOLVED: Republish
16:22:17 <fantasai> Topic: CSS Positioned Layout
16:22:26 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5749
16:22:55 <fantasai> Rossen_: Seems the proposal is to close no change.
16:23:10 <fantasai> smfr: Question is if you have a <br> and say 'position: absolute'. Does it trigger line breaks?
16:23:22 <fantasai> smfr: 'position: absolute' takes it out of flow
16:23:30 <fantasai> smfr: which probably means it shouldn't trigger a line break
16:23:34 <fantasai> smfr: so I think Gecko has the right behavior
16:23:44 <fantasai> smfr: Slight concern about if it's web-compatible, but if Gecko's shipping probably OK
16:23:55 <fantasai> Rossen_: do we have any specific spec text defining it one way or another?
16:24:11 <fantasai> smfr: I think the spec is fine, just implementers not following spec
16:24:22 <fantasai> florian: That and fact that BR and WBR aren't properly specced fully
16:24:31 <fantasai> florian: we've had discussions about how to represent them, but haven't fully resolved
16:24:41 <fantasai> florian: but only logical behavior is if take out of flow, stop influencing the text round it
16:24:58 <emilio> q+
16:25:04 <fantasai> Rossen_: sounds like we have consensus for breaking behavior here
16:25:10 <fantasai> Rossen_: and that seems to be spec-compliant atm
16:25:22 <Rossen_> ack emilio
16:25:23 <fantasai> emilio: I've never heard a compat issue with Gecko's behavior so far
16:25:54 <fantasai> Rossen_: proposed close issue no change to spec and encourage UAs to follow Gecko's lead
16:26:22 <fantasai> RESOLVED: Close no change: taking BR out of flow removes its effect on the surrounding content, just like every other element
16:26:23 <astearns> A testcase would be an excellent encouragement (and smfr just added the tag to the issue)
16:26:37 <fantasai> emilio: Where does the WebKit behavior come from?
16:26:55 <fantasai> smfr: It's probably very historical
16:27:11 <fantasai> iank_: BR inherits from text node, so has ...
16:27:30 <fantasai> Topic: CSS Color Adjust
16:27:42 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5469#issuecomment-707918323
16:28:21 <fantasai> TabAtkins: This is the only issue open to block us from CR
16:28:30 <fantasai> TabAtkins: we pinged you repeatedly for the answer, and no response
16:28:34 <fantasai> TabAtkins: So put it on the agenda.
16:28:56 <fantasai> Rossen_: Have some colleagues closer to the implementation, will tag them.
16:29:15 <fremy> fremy: wouldn't mind keeping the border image, just in case
16:29:18 <fantasai> Rossen_: hopefully close on this before the end of the week
16:30:06 <fantasai> Rossen_: horizontal review issue?
16:30:46 <fantasai> 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.
16:30:58 <fantasai> Rossen_: should we resolve provisionally, or resolve next week?
16:31:09 <fantasai> TabAtkins: up to the chair :)
16:31:20 <fantasai> Rossen_: Current spec doesn't override border-image?
16:31:32 <fantasai> TabAtkins: current spec calls for that I believe
16:31:39 <fantasai> TabAtkins: border-image is not on the list of properties getting overridden
16:32:05 <fantasai> Rossen_: That reflects current implementations. Don't see why we'd want to change it. Does anyone have a different opinion?
16:32:14 <fantasai> TabAtkins: We're not trying to resolve on the open question right now.
16:32:22 <fantasai> TabAtkins: Question is do we want to move to CR?
16:32:37 <fantasai> Rossen_: Current spec matches our expectations
16:33:29 <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
16:34:11 <fantasai> 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?
16:34:31 <tantek> q?
16:34:40 <fantasai> 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
16:34:56 <fantasai> Rossen_: if we end up changing, let's handle it later
16:35:07 <fantasai> tantek: Is the issue linked in the draft?
16:35:32 <fantasai> TabAtkins: no
16:35:45 <fantasai> Rossen_: if we can't close this, put a link in there
16:35:56 <tantek> perhaps in the status section
16:36:11 <fantasai> Rossen_: OK, calling for provisional CR transition resolution
16:36:19 <fantasai> Rossen_: any last concerns to moving forward with transition?
16:36:31 <fantasai> topic: publication
16:36:36 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5768
16:36:46 <fantasai> RESOLVED: Move css-color-adjust-1 to CR
16:36:57 <fantasai> topic: marquee vs compressible elements
16:37:02 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6342
16:37:20 <TabAtkins> fantasai: We were told to add <marquee> to the list of compressible elements, wondering if there's any objection
16:37:38 <fantasai> Rossen_: Any opinions?
16:37:49 <fantasai> RESOLVED: Add marquee to compressible elements
16:38:04 <fantasai> topic: Definiteness of min-height: min-content
16:38:11 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6457
16:38:42 <fantasai> “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
16:38:48 <fantasai> 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?”
16:39:05 <fantasai> TabAtkins: Original question of issue is still open
16:39:22 <fantasai> TabAtkins: for reasons of usability, we had to rule that 'min-size: auto' does not prevent percentages on your children from resolving
16:39:37 <fantasai> TabAtkins: even though technically the size of parent might be dependent on size of contents
16:39:47 <fantasai> TabAtkins: because if not, percentages would hardly ever resolve in flex or grid
16:40:04 <fantasai> TabAtkins: But we have also the min-content and max-content keywords
16:40:18 <fantasai> TabAtkins: Do we make these also not block percentage resolution on children?
16:40:35 <Rossen_> q?
16:40:36 <fantasai> TabAtkins: or do we want to hold the line, and have these content-based keywords block percentage resolution
16:40:53 <fantasai> TabAtkins: just like they do in the not-min sizing properties (width/height/etc.)
16:41:08 <fantasai> TabAtkins: Not necessarily need to resolve now, but wanted to bring up the quesiton
16:41:13 <fantasai> iank_: I'd want to discuss with David
16:41:38 <fantasai> dholbert: I think given how treated as 'auto' right now, there might be web-compat demand for them to have same definiteness properties.
16:42:13 <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
16:42:23 <fantasai> Rossen_: Any concrete use cases?
16:42:30 <fantasai> TabAtkins: no, this is a question of consistency
16:42:40 <dgrogan> dgrogan has joined #css
16:42:47 <fantasai> TabAtkins: what kind of divergence do we want here
16:43:01 <fantasai> TabAtkins: we need an answer for the spec, but having use cases
16:43:05 <fantasai> dholbert: for non-definite case
16:43:18 <fantasai> dholbert: consider a deeply-nested flexbox case
16:43:22 <fantasai> dholbert: want content-based minimum
16:43:26 <fantasai> dholbert: but don't want perf complications
16:43:37 <fantasai> dholbert: so switch from auto to min-content
16:43:50 <fantasai> dholbert: That said, browser could also maybe detect the lack of percentages inside the element
16:43:55 <fantasai> dholbert: and not run the second layout pass
16:44:08 <fantasai> dholbert: Can't think of another justification for not being definite
16:44:20 <fantasai> jfkthame: agree
16:44:34 <fantasai> Rossen_: ...
16:44:44 <jfkthame> jfkthame has joined #css
16:44:47 <fantasai> Rossen_: I think the perf problem stated here is more of a speculation
16:44:54 <fantasai> Rossen_: less a concrete concern
16:44:59 <fantasai> Rossen_: my preference would be to keep it consistent
16:45:47 <fantasai> fantasai: consistency works both ways
16:45:49 <Rossen_> s/.../The deeply nested elements can be made context aware and resolve % only in the cases of having both % and min-content/
16:46:00 <fantasai> fantasai: these keywords in 'height' cause it to be indefinite
16:46:16 <fantasai> fantasai: so do we want to be consistent with that? or with 'min-height: auto'?
16:46:40 <fantasai> Rossen_: where do we go from here?
16:46:58 <fantasai> fantasai: Tab and I are happy for people to think about it. We just wanted to bring it up and explain on the cal.
16:47:03 <fantasai> Topic: end
16:47:13 <fantasai> Topic: Hit Testing
16:47:28 <fantasai> Rossen_: We don't have it specified anywhere, but acknowledge that it exists
16:47:46 <fantasai> Rossen_: and smfr points out that the inert attribute is underdefined as a result
16:47:50 <smfr> https://github.com/whatwg/html/issues/5650
16:47:58 <fantasai> smfr: This is the a WHATWG issue that discussion is in
16:48:16 <fantasai> smfr: The inert attribute in HTML is intended to make an element unresponsive to user interaction and also hidden from a11y
16:48:28 <fantasai> smfr: one of the intended uses is, in combination with dialog,
16:48:31 <fantasai> smfr: ....
16:48:40 <fantasai> smfr: behaves as though has inert attribute, not interactive
16:48:48 <fantasai> smfr: Gecko and Chrome have initial implementations of this attribute
16:48:55 <fantasai> smfr: which differ in how they prevent interaction
16:49:07 <fantasai> smfr: Chrome has gone with a more DOM-based approach, kinda like disabled form control
16:49:20 <fantasai> smfr: Emilio's approach in Gecko is different, more like 'pointer-elements: none'
16:49:33 <fantasai> smfr: These have different behaviors wrt z-index, if you stack elements, what happens when you click on it?
16:49:39 <fantasai> smfr: also [...]
16:49:53 <fantasai> smfr: Also, can a non-inert tree have an inert tree (???)
16:50:04 <fantasai> smfr: Trying to resolve differences between Gecko and Blink's interpretations
16:50:12 <fantasai> smfr: Emilio believes not specified well enough for any browser to ship it
16:50:17 <fantasai> smfr: there are some WPT, but not exhaustive
16:50:30 <fantasai> emilio: In particular, Blink's implementation also have some event retargetting going on
16:50:42 <fantasai> emilio: Implementing it in either existing or new CSS primitives would be great
16:50:48 <fantasai> emilio: but question of hit testing is not defined
16:50:56 <fantasai> florian: earlier you stated that we decided we didn't want to specify it
16:51:12 <fantasai> 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
16:51:19 <fantasai> florian: we could do it, but nobody is signing up
16:51:28 <fantasai> smfr: hit testing is the inverse of painting, so should be able to specify it
16:51:53 <fantasai> smfr: Also ?? is in CSSOM-view, which involves hit testing
16:52:01 <astearns> s/??/elementFromPoint/
16:52:02 <fantasai> florian: so maybe need to bite the bullet and find someone to do it
16:52:19 <TabAtkins> For once, not volunteering.
16:52:44 <fantasai> chrishtr: Which spec would it go into?
16:53:00 <fantasai> florian: We had an earlier discussion that the property 'pointer-events' could go into css-ui
16:53:06 <fantasai> florian: as long as just a switch, why not
16:53:15 <fantasai> florian: but scope of defining all of hit testing is probably too much
16:53:19 <fantasai> florian: so probably want a standalone spec
16:53:29 <fantasai> chrishtr: Also painting is also not in an awesome spec location either, in CSS2 right?
16:53:38 <fantasai> florian: Yes, we want a standalone spec for that also
16:53:58 <fantasai> florian: Then as new specs tweak it, can refer to that. But need a foundation document
16:54:09 <fantasai> chrishtr: So new spec for painting, and also hit testing
16:54:21 <fantasai> chrishtr: I've been sad about state of painting alos
16:54:31 <fantasai> florian: So, now that we've increased the scope :) still looking for a volunteer to do it
16:54:37 <fantasai> chrishtr: I'll try to find someone
16:55:58 <fantasai> Rossen_: Sounds good
16:56:13 <fantasai> Rossen_: Anything specific, smfr?
16:56:31 <fantasai> smfr: Would like to solve this issue before we have a hit testing spec, because that will take years, but we need to implement
16:57:06 <fantasai> chrishtr: ?? was the one who implemented, and wanted to try to ship, but then discussions with Gecko ...
16:57:20 <fantasai> chrishtr: I will volunteer to go back and reread the blink-dev thread
16:57:28 <fantasai> chrishtr: and then respond with an update
16:57:30 <astearns> s/??/Alice/
16:57:45 <fantasai> chrishtr: I think we're quite close to having this in all three browsers, which would be nice to achieve
16:58:10 <fantasai> Rossen_: so, a lot of volunteering from Chris, which is great. Hopefully issue will make progress, and maybe we'll even work on it.
16:58:18 <fantasai> Rossen_: assuming nothing else on this topic, and we did eveything on the agenda
16:58:25 <fantasai> Rossen_: let's close
16:58:43 <fantasai> tantek: Did we get the funding we needed for infrastructure?
16:58:49 <TabAtkins> nope, not yet
16:58:50 <fantasai> Rossen_: I haven't heard anything. Anyone else?
16:58:59 <chrishtr> lol 2 is enough for me today :)
16:59:22 <fantasai> Meeting closed.
16:59:34 <Rossen_> Zakim, end meeting
16:59:34 <Zakim> As of this point the attendees have been Rossen_, fremy, jfkthame, Morgan, rachelandrew, fantasai, TYLin, dholbert, miriam, dandclark, GameMaker, plinss, emilio, jensimmons, oriol,
16:59:37 <Zakim> ... sanketj, tantek, TabAtkins, dbaron[m], cbiesinger
16:59:37 <Zakim> RRSAgent, please draft minutes v2
16:59:37 <RRSAgent> I have made the request to generate https://www.w3.org/2021/09/08-css-minutes.html Zakim
16:59:39 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
16:59:44 <Zakim> Zakim has left #css
17:00:00 <aja> TabAtkins (IRC): have a sec for a questions re system colors?
17:00:06 <TabAtkins> sure
17:00:49 <aja> think SelectedItem / SelectedItemText should go in color pairing authoring advice?
17:06:14 <aja>  * TabAtkins (IRC ): think SelectedItem / SelectedItemText should go in color pairing authoring advice?
17:07:07 <Letzi> Letzi has joined #css
17:07:07 <aja> TabAtkins (IRC): : think SelectedItem / SelectedItemText should go in color pairing authoring advice?
17:07:21 <TabAtkins> lol your matrix bridge is beign weird
17:07:36 <aja> it  is :/
17:08:11 <aja> 1st time i've tried it here
17:08:46 <TabAtkins> anyway, yes
17:09:04 <TabAtkins> also, looks like there's a copypaste error on the swatches there; they're still set to highlight colors
17:09:14 <aja> shall i file an issue?
17:09:17 <TabAtkins> sure
17:09:24 <aja> k...tks
17:09:34 <florian> TabAtkins: both syntax-3 and values-4 define "identifier", and the later seems to just be a reference to the former. Maybe it shouldn't be a dfn, and should be a reference instead? Or am I missing something?
17:09:51 <TabAtkins> one or the other should probably be a ref, yeah
17:10:24 <TabAtkins> i've run into this but haven't given enough thought to which i want to be the base dfn, or if i want to give them different words
17:10:45 <florian> Can I let you deal with that? these are both your specs…
17:14:18 <florian> TabAtkins: different question: what's the appropriate bikeshed convention to use to markup the names of parameters to an algo when invoking it?
17:14:22 <florian>  In the definition of the algo itself, they tend to be marked up as variables, but at the call site, doing that gets you a warning about variables only used once
17:15:54 <TabAtkins> Yeah, I don't have a markup convention yet, because I haven't yet written the necessary code to actually verify algorithm invocations.
17:16:10 <TabAtkins> For now I'd either say don't do anything special, or do a `<var ignore>`
17:16:18 <florian> kk
17:26:39 <aja> TabAtkins (IRC): https://github.com/w3c/csswg-drafts/issues/6583
17:27:37 <aja> hmm, kelvin, eh?  interesting
17:28:02 <aja>  * hmm, kelvin(), eh?  interesting
17:32:48 <cbiesinger> ok, stupid question. when serializing a property value for .style (as opposed to computed style), should "1px auto" become the canonical "auto 1px"? (fantasai?)
17:34:19 <cbiesinger> or TabAtkins ?
17:35:40 <TabAtkins> so that's specified value, which is less well-specified ironically. not sure how much we canonicalize ordering vs just giving back the exact string the author typed
17:37:41 <cbiesinger> it looks like for aspect-ratio blink (and wpt tests) canonicalize it, so I will do the same here
17:39:14 <cbiesinger> hmm
17:39:34 <cbiesinger> maybe I shouldn't, because that makes "1px 1px auto" become "1px auto 1px", which I don't think is equivalent
17:41:11 <TabAtkins> wait what
17:41:38 <TabAtkins> which property is this
17:43:22 <cbiesinger> contain-intrinsic-size
17:44:06 <cbiesinger> wait
17:44:12 <cbiesinger> TabAtkins: nevermind, spec was changed. https://github.com/w3c/csswg-drafts/issues/6391
17:45:17 <cbiesinger> did I not get an email for that or did I miss it
17:49:10 <TabAtkins> ah, just reffing an issue in a comment doesn't send an email; that's our fault for not commenting in the thread, apologies
18:33:07 <astearns> topic: none
19:12:56 <eeeps> eeeps has joined #css
20:04:55 <jensimmons> jensimmons has joined #css
21:08:57 <dino> dino has joined #css
22:09:35 <eeeps> eeeps has joined #css
23:02:18 <jensimmons> jensimmons has joined #css
23:24:06 <Seirdy> Seirdy has joined #css
23:26:21 <jensimmons> jensimmons has joined #css
23:58:39 <jensimmons> jensimmons has joined #css