Meeting minutes
<TabAtkins> Rossen: changes to agenda?
<TabAtkins> github-bot: take up w3c/
[selectors] Should `:checked` and `:indeterminate` be exclusive?
<github-bot> OK, I'll post this discussion to w3c/
<TabAtkins> PaulG: The OP was about :checked and :indetermine being exclusive, so an element can't be both
<TabAtkins> PaulG: The HTML impl allows for them to be both, and it's even tested in some palces. But that wasn't the intent and is seen as an unfortunate bug.\
<TabAtkins> PaulG: People seem to think CSS has it right (mutually exclusive), and the AAM mappings for a11y agree, having a 3-state checked/unchecked/indeterminate
<TabAtkins> PaulG: So, original q, should these be exclusive?
<TabAtkins> Rossen: Do you know if tantek's opinion was based onf urther discussion with HTML folks, or personal opinion?
<TabAtkins> PaulG: I think what happened here is we realized the HTML behavior isn't waht was intended.
<TabAtkins> PaulG: So q is if we shoudl continue this mistake in CSS and mirror HTML, or clarify the spec and push for HTML to change it's definition.
<TabAtkins> emilio: This looks like, to the extent there's a bug, the bug is in HTML. WebKit and Gecko are correct per spec right now, right?
<TabAtkins> PaulG: yeah
<TabAtkins> emilio: so I don't think we should carve out an exception. If HTML doesn' thave the right handling for these states it shoudl be fixed there
<TabAtkins> +1, fwiw
<TabAtkins> JakeA: There'll be some weird cases in HTML where, like, if you set checked=false to false, it might change the value of indeterminate.
<TabAtkins> emilio: If we want to implement that they're exclusive, we should change it in HTML. HTML can decide what happens when you set a checked=false when it was already false, it might become not indeterminate, but that's for them.
TabAtkins: we don't have to concern ourselves with what exactly HTML does
TabAtkins: We don't have to concern ourselves with what exactly HTML does on its behavioral side
TabAtkins: The fact that they define it as boolean is their problem to solve
TabAtkins: On the CSS side, we can affirm that when spec says they are mutually exclusive, then that's what needs to happen
TabAtkins: So HTML needs to define one way or another how that tri-state comes about
TabAtkins: and what that means for its behaviors for its elements
TabAtkins: It can take whatever action is most appropriate
TabAtkins: As long as it maps the state somehow to the tri-state that we and AAM and others expect
<TabAtkins> PaulG: and if we're going that direction, Chrome/Edge are fine, Safari/Firefox need to alter
<TabAtkins> TabAtkins: [clarifying previous minutes]
<TabAtkins> emilio: Gecko/WebKit match the HTML spec, two independent booleans; not CSS's tristate
w3c/
<Zakim> fantasai, you wanted to bring up w3c/
<TabAtkins> fantasai: I wanted to bring up this comment that summarizes the possibilities
<TabAtkins> fantasai: there's multiple things that need to align. CSS, HTML, browser impls, ARIA, what AT users are getting
<TabAtkins> fantasai: We can make things align or not in various ways. We could align them all on three states, or four states, or a mix of useful behaviors.
<TabAtkins> fantasai: That last doesn't seem great to me, it seems confusing, but it's possible.
<TabAtkins> fantasai: But if CSS only represents 3 states and HTML can do 4, what do we want ARIA to represent?
It defined as a tristate seems fairly recent: w3c/
<TabAtkins> kizu: I think it would be weird if CSS had three states and HTML keeps two bools
<TabAtkins> kizu: I agree with emilio that it might be helpful to bring up to HTML.
<TabAtkins> kizu: I wonder if we could use the work on appearance:base to make this fixable. With base-checkbox we're in a new state and modifies how HTML works, CSS and selectors
TabAtkins: Definitely can't change selectors based on 'appearance'
<TabAtkins> Rossen: So on one side we have tantek (and several others) arguing for the tristate behavoir, considering HTML's behavior an unfortunate legacy. ON the other side we have HTML/ARIA considerations.
<TabAtkins> Rossen: So can we resolve on keeping the CSS-defined behavior and work with HTML and other groups to address that?
<TabAtkins> emilio: Does the spec currently say what happens with the tristate if they're done differently?
<TabAtkins> TabAtkins: CSS says it's a tri-state and that the mapping is up to the host language. HTML is just doing the mapping wrong, per spec.
See also w3c/
<TabAtkins> emilio: I think the easiest fix is to make them independent in CSS, then go fix HTML to make them a tristate
<TabAtkins> (this seems exactly backwards to me, and if we did decouple them HTML will most likely go "well we're good then" and not change anything)
<TabAtkins> fantasai: ??? points out that indetermine-checked and indetermine-unchecked have different behaviors, because they do go to different states depending on the udnerlying checked state
<TabAtkins> fantasai: so there's multiple things happening here. HTML, ATs, and underlying behavior.
<PaulG> this is the demo https://
<TabAtkins> (we're just retreading the exact discussion from last time, fwiw)
<TabAtkins> PaulG: I linked in the chat the demo that there's four states in HTML.
fantasai: We should get them all to align, whether on 3 states or 4 states
<TabAtkins> emilio: so this needs HTML to change one way or another. Can we just discuss this in HTML? I think that's the simplest solution.
<TabAtkins> emilio: So I think having the 3-state sentence in CSS is kinda silly.
TabAtkins: we could override HTML and say how to behave when the host language screws up
<TabAtkins> TabAtkins: Note that we don't *need* HTML to change to keep CSS right. If CSS says it's a tristate, and the host language definition is doing somethign different, it's just wrong, and we can say what to do in that case.
<TabAtkins> fantasai: Should we discuss this at TPAC to get everyone together?
<TabAtkins> Rossen: going back to tantek's point, captured back in CSS UI back in '99 it was written as a tristate.
<TabAtkins> Rossen: So q is what is the position of the CSSWG?
<TabAtkins> fantasai: I think our position should be that all of the different things need to agree on how many states there are. (HTML, CSS, behavior, ATs)
<emilio> +1
<TabAtkins> fantasai: And we need to satisfy UX people
<TabAtkins> fantasai: What does modern user experience believe is the right answer here?
<TabAtkins> +1
<TabAtkins> fantasai: and I don't think we ahve those people in this group right now
<TabAtkins> JakeA: This might run into things the HTML group can't solve, we have a checked attribute and indeterminate property, and you set indeterminate true and then false, what happens to the attribute - it might not be something they can solve without creating a new tristate attribute
<TabAtkins> JakeA: Which I assume they're not going to do
<TabAtkins> (I don't think they necessarily need to do anything there. The tristate can simply be represented by two booleans.)
SUMMARY: Need to bring HTML and a11y and UX people into this discussion.
[scroll-animations] ViewTimeline IDL specifies that the `subject` attribute is non-null, but allows construction with no `subject` specified
<TabAtkins> weinig: I think this is just an IDL bug
<TabAtkins> weinig: in ViewTimeline, there's a constructor that takes ViewTimelineOptions, and one of the options is the element. Because the whole constructor is optional, and element isn't required in the dict, you can call the constructor and the element is null
<TabAtkins> weinig: But in the interface itself the element isn't nullable. So that's a contradiction.
<TabAtkins> weinig: So I think the element just needs to be nullable, or we change the ViewTimeline constructor.
<TabAtkins> ydaniv: since it's also readonly, it's practically useless without a subject. I'm not sure what use-case it woudl serve to make it nullable
<TabAtkins> weinig: Yeah, that's an option. Just make the dictionary non-optional and make element a required piece
<TabAtkins> ydaniv: if that's compatible
<TabAtkins> weinig: well like you said, what would people be doing with a null ViewTimeline object?
<TabAtkins> ydaniv: probably getting an inactive VT object, but now they'd be throwing an error, so it might be a compat issue
<TabAtkins> flackr: I was going to ask what it does today, but I checked, and it's just returning a null subject
<TabAtkins> flackr: I'm fine with trying to throw an error
<TabAtkins> flackr: But I"m also fine with the element being null and the timeline being useless is okay if compat requires that
<TabAtkins> bramus: yeah just reiterating that the VT object is worthless without a subject, so it makes sense to require it
<TabAtkins> bramus: ignoring compat, we shoudl require it
<ydaniv> +1
<TabAtkins> flackr: So maybe we should try to require it, but check usage first?
<ydaniv> +1 to flackr
<TabAtkins> Rossen: Can we just resolve to require it, and then bring it back if compat says we can't do it?
<TabAtkins> bramus: One thought, maybe it was nullable in the case that we create a viewtimeline linked to an existing element, but later destroy that element, you still have a lingering VT
<TabAtkins> weinig: That's the opposite problem, currently the interface's element is non-nullable
<TabAtkins> weinig: But usually the way this works is the VT would be a strong reference to the element so it's not destroyed
<ydaniv> and the subject is readonly
<flackr> +1
<TabAtkins> (no dangling pointers)
<TabAtkins> weinig: so proposed resolution is we change the spec to make the constructor take a non-optional dictionary, and dictionary makes element required, and impls check compat of that
RESOLUTION: change the spec to make the constructor take a non-optional dictionary, and dictionary makes element required, and impls check compat of that
<TabAtkins> github-bot, take up w3c/
[css-flexbox] When omitted from the flex shorthand the flex-basis value is...
<github-bot> OK, I'll post this discussion to w3c/
TabAtkins: Along while ago, we defined that the value of flex-basis when you don't specify the basis would be 0%
TabAtkins: This was specifically to trigger indeterminate behavior
TabAtkins: Later tried to change it, to say that you get 0px
TabAtkins: We were unclear at the time whether it would be Web-compatible to do
TabAtkins: Implementations have not really followed the spec change here. They've kept 0%
TabAtkins: At this point, we're fairly certain it can't be changed
TabAtkins: So that it doesn't go down to zero
TabAtkins: We see cases where they are depending on that.
TabAtkins: So proposal is to revert
TabAtkins: Probably need to call out in the spec that it's a little weird but required for back-compat
<TabAtkins> fantasai: I think at this point this is probably correct
<TabAtkins> fantasai: the original idea is we would rely on automatic minimum to prevent these problems we were trying to solve with 0%, that gives a little more flexilibity
<TabAtkins> fantasai: but that does give slightly different behavior, basis of max-content vs flooring it at min-content is quite different, or at least can be different
PROPOSED: Switch back to 0% for compat, add a note to the spec about it
RESOLUTION: Switch omitted flex-basis back to 0% for compat, add a note to the spec about it
<TabAtkins> github-bot: take up w3c/
[css-values] A few more calc() issues in WPT tests
<github-bot> OK, I'll post this discussion to w3c/
<TabAtkins> weinig: I thin kthe second one has been resolved...
<TabAtkins> weinig: The first one, shoudl `1 * ...` be eliminated?
TabAtkins: I believe resolution was to not add it, because not very useful simplification
<TabAtkins> weinig: I feel like we resolved on this already?
<TabAtkins> weinig: The last one, I think was just wrong and I was looking for clarification.
<TabAtkins> weinig: But it looks like now everyone is failing it, so i think the test is just wrong
<TabAtkins> weinig: so resolution would be to remove the `1 * ...` test, and fix the calc-in-MQ test
<kbabbitt> changing the tests is fine with me
RESOLUTION: remove the `1 * ...` test, and fix the calc-in-MQ test
<TabAtkins> github-bot: take up w3c/
[css-values] Clarifications on how calc-mix() simplification should work
<github-bot> OK, I'll post this discussion to w3c/
<TabAtkins> weinig: I implemented calc-mix(), but ther'es no simplification rules so I made my own up and specified them ehre
TabAtkins: Proposed answers to answers Sam brought up are all correct in general
TabAtkins: Basic rule is that calc-mix() is a convenience function for linear interpolation
TabAtkins: So we should simplify the same as calc() would
<kbabbitt> +1
TabAtkins: Only one where I disagree with is the final example
TabAtkins: One of the questions he asked is, do we drop 0% cases
<TabAtkins> calc-mix(10% 0%, 10px 0%)
TabAtkins: Generally yes, that matches how we drop products from calc()
TabAtkins: But we can't drop entire thing, need to leave a value behind
TabAtkins: Here's an example that needs to simplify to something zero.
TabAtkins: His suggestion is to use first arg, and 0% vs 0px can lead to different behaviors
<TabAtkins> calc(0px + 0%)
TabAtkins: So my suggestion is we should use the resolved type of the calc-mix(), which is a blend of the two
TabAtkins: and resolve to calc(0px + 0%)
<TabAtkins> weinig: I think that's a better solution, so great
<fantasai> +1
PROPOSED: calc-mix() simplifies like calc() as described in the issue, except the mixed-type case resolves to calc(0px + 0%)
<TabAtkins> PROPOSED: Specify calc-mix() simplification to match clac() (and Sam's proposal in the issue), save for the "drop everything" case where we instead keep all the types around
RESOLUTION: calc-mix() simplifies like calc() as described in the issue, except the mixed-type case resolves to calc(0px + 0%)
[css-scroll-snap-1] [interop-2026] clarify how snap positions are calculated in the case where the target element is split into multiple boxes
<TabAtkins> emilio: when a snap target is split across multiple boxes due to fragmentation/etc, it's not super clear in the spec what we snap to, like what's the center
<TabAtkins> emilio: and some related cases, like what if you have a scroll destination between the boxes
<TabAtkins> emilio: i think there's reasonable answers, like maybe we use bounding box of the fragments like anchor does
<TabAtkins> emilio: but it would be good to confirm
<TabAtkins> (i think it's either bounding box, or first fragment; weak preference to match anchoring)
<TabAtkins> fantasai: This is actually pretty tricky
<TabAtkins> fantasai: if you have a fragmented element across columns, and you can see both columns, using the boudning box isn't unreasoanble, you'll always see at least part of the element
<TabAtkins> fantasai: but if you have multiple columns and the viewport is shorter than the columns, and the elemnt is split between bottom of one and top of another, the viewport centering on the boudning box might not let you see anything
<TabAtkins> flackr: We ahve exceptions for elements larger than the scrollport
<TabAtkins> fantasai: We allow you to pan around the whole area, but your initial view (for 'center' alignment) won't show anything
<TabAtkins> flackr: that's fair
<TabAtkins> fantasai: So I haven't given this a lot of thought yet, but I think we should *try* to do something that ensures the user can see part of the element
<TabAtkins> Rossen: [restating example, tiny viewport + tall columns]
<TabAtkins> fantasai: yes
<TabAtkins> fantasai: and if you ask for start alignment, you'll snap to the top left corner of the bounding box where the element doesn't exist
<TabAtkins> fantasai: so many failure possibilities here
<TabAtkins> fantasai: i think we need to somehow keep at least one of the fragments in the viewport.
<TabAtkins> fantasai: so like align *towards* the center, but only to the extent that we can still see some of the fragments we're snapping to
<TabAtkins> emilio: q for Rob, do you know what Blink implements here?
<TabAtkins> flackr: I *think* Blink implements bounding box. would have to double check but I think that's right
<TabAtkins> flackr: possible solution - we already have some special cases for the initial alignment for things larger than the scrollport. maybe this is a special case for that - if the bounding box is larger thant he scrollport, we instead align to the first fragment
<TabAtkins> flackr: haven't thought thru all the use-cases but it seems like a possiblity
<TabAtkins> fantasai: seems like a good option
<TabAtkins> I also think this sounds plausible
<TabAtkins> fantasai: maybe if you say "end" it uses the last fragment
<TabAtkins> flackr: yeah it might be direction-aware
<smfr> let me rejion
<TabAtkins> Rossen: So rob's path forward sounds pretty good. I assume we don't have anything like this in the spec currently?
<TabAtkins> TabAtkins: yes
<TabAtkins> smfr: i'm back. scroll-snap-align:start use first frag, end use last, center decide on what to do... would it be crazy to just generate snap points for each fragment independently?
<TabAtkins> fantasai: could do that, I guess?
<TabAtkins> fantasai: but when you try to bring something into view that won't work as you expect
<TabAtkins> fantasai: if you are elsewhere in the page, and the multicol is *smaller* than the viewport, you dont' want to center the one small fragment at the end of the first column. You want to bring the whole thing into view if you can
<TabAtkins> flackr: agree with elika here, there are cases where snapping to fragments is worse than teh bounding box
<TabAtkins> fantasai: so i think this needs a writeup and we can come back to it, because there are some subtleties around relative sizes of things
<TabAtkins> flackr: we already have this carveout for writing modes, i think this is just extending that
PROPOSAL: Snap the bounding box, but if it is bigger than the viewport, adjust the alignment [TBD].
PROPOSAL: Snap the bounding box, but if it is bigger than the viewport, adjust the alignment [TBD] to keep the element in view.
<emilio> +1
<flackr> +1
RESOLUTION: Snap the bounding box, but if it is bigger than the viewport, adjust the alignment [TBD] to keep the element in view.
<TabAtkins> fantasai: Rob, do you want to take a stab at the spec text?
<TabAtkins> flackr: sure
ACTION: flackr to write up a proposal for the adjustment
<TabAtkins> github-bot: take up w3c/
[css-scroll-snap-1] Why does scroll-snap-align: both snap in each axis independently?
<github-bot> OK, I'll post this discussion to w3c/
<TabAtkins> flackr: currently in scroll-snap we treat the axises independently, and allow you to snap to different elements on each axis
<TabAtkins> flackr: there are certainly cases where that's desirable
<TabAtkins> flackr: in most cases you can only snap in one axis anyway
<TabAtkins> flackr: but i think when you ahve an element that can snap in both directions, the intent is usually to snap to the element entirely, or not at all
<TabAtkins> flackr: so i wanted to revisit whether we can at least support this (Tab mentioned this as a possibility in a comment) or if this should even be the default and we add a way to go back to independent-axis snapping
<TabAtkins> fantasai: we discussed this pretty extensively at one point and concluded we needed both behaviors, but for level 1 we'd only do independent
<TabAtkins> fantasai: but we did recognize we'd want the joined behavior and would need a different behavior. definitely not opposed to adding it
<TabAtkins> Rossen: so adding it in level 2?
<TabAtkins> fantasai:
<TabAtkins> fantasai: yeah
<TabAtkins> flackr: and specifically with a new keyword?
<TabAtkins> fantasai: yes
<TabAtkins> fantasai: we have scroll-snap-2 spec, do we want to go ahead and add it?
<TabAtkins> PROPOSED: Add TBD keyword to do joined-axis snapping
<TabAtkins> fantasai: I suggest keyword 'pair'
<TabAtkins> (flackr suggested 'element' which I also like)
RESOLUTION: Add TBD keyword to do joined-axis snapping
(it's not an element it's a box :)
<TabAtkins> github-bot, end topic