– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

<astearns> github-bot, take up whatwg/html#11019

Support fragment references in the `<link>` tag's `href` attribute

<github-bot> OK, I'll post this discussion to https://github.com/whatwg/html/issues/11019.

kurt: Working on getting this to stage 2 in whatwg.
… want to get some of the concerns worked out in joint call

<astearns> related: whatwg/html#11286

kurt: Noam filed whatwg/html#11286
… seems like the biggest blocking issue. Seems to have been resolved in thread
… spec already covers it
… are there other concerns?
… before stage 2?

annevk: Not sure it's resolved. Haven't seen Olli reply
… I think Domenic thinks current situation is OK. Would be good to discuss with him
… maybe Noam too

kurt: Makes sense to set up one-off session with them?

annevk: Yes, also good to have Tab, he created the local references thing
… Treating URL starting with `#` differently
… Doesn't have the issue of re-fetching the same document
… Not sure it's actually implemented for CSS
… seems like a useful thing
… It's more intentonal. Very clear that it will always be treated as local reference, not affected by stuff like `<base>`

emilio: Gecko imlements local reference concept. I assume other engines do so in a more or less semi-consistent way
… need to handle that kind of stuff for SVG

annevk: Do you end up fetching even if URL matches but doesn't start with fragment ID?

emilio: Need to double-check that.

annevk: I can make test case

emilio: Should be easy to test

astearns: Having specific session on this with the right people sounds good

kurt: I can set up

<astearns> github-bot, take up w3c/csswg-drafts#10711 (comment)

[css-ui] Support setting offscreen content inert

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10711.

masonf: There is an HTML spec PR for this
… It's connecting to CSS concept of interactivity. There have been changes. Part of what's in PR will change
… it keeps existing behavior for modal dialogs. It allows interactivity keyword in CSS to cause intertness. It explains the existing inter attr in terms of that property
… allows to you de-inert things.
… Can exempt subtree to be un-intert. that's expected to change

flackr: We're proposing to discuss not de-inerting anymore. Have the interactivity prop be synonomous with the HTML prop
… can't escape inertness aside from preexisting dialog semantics (which is internal magic)

flackr: It becomes non-inherited property.
… The way you determine inertness is once you see inert at any point in tree, applies to all descendants, just like inert attribute

annevk: Why do we need interactivity property?

flackr: So it can be applied dynamically by CSS. Lots of cases where it's useful

<jarhar> dandclark: do we still have a11y folks involed in this conversation?

<jarhar> dandclark: theyre interested in this conversation, i hope theyre still involved

flackr: This has been ongoing discussion
… you can see in various issues
… change to interactivity is part of attempt, if we allign with HTML intert prop, it has the same implications as we already have for that
… nice cleanup, it explains HTML prop like display:none explains hidden property

masonf: This change is a result of those convos

astearns: This seems like a necessary change, but not sure it's suffiient to address all concerns from a11y folks

flackr: synonymous with HTML inert
… can argue it can be used more broadly now. But seems prescriptive to tell authors they can't do this with CSS when they can with HTML

astearns: Requires AT to update that it's not just HTML

flackr: This is just a browser thing

masonf: Right, should be exposed to AT in the same way

emilio: As part of this work are you chaning HTML inert from being magic to be mapped to CSS prop

masonf: Answer is yes. There is still magic because dialogs get to de-inert things magically

annevk: Will CSS define all the inert logic? Moving that from HTML?

masonf: No, defined in both places

annevk: Hows' that make sense

masonf: HTML spec PR refers to both CSS and HTMl concept of inert

annevk: That' snot what you said before

masonf: You said the concept of ineert, which is defined in both places

masonf: Both mechanisms apply concept of inertnesss to tree

ntim: I think anne is referring to conecept of inertness, not the attribute. Why not move the whole def to CSS?

flackr: It's editorial
… can define in CSS if that makes more sense

masonf: It's already defined in CSS, but yes let's get the language right, any of these are fine

<masonf> CSS concept: https://drafts.csswg.org/css-ui-4/#inert

annevk: I'm not sure it's editorial. If we move these concepts, we'll have to change a bunch of thigns
… Then css has to be in charge of interactivity, whether nodes are interactive

masonf: I think it does, pasted link above^

annevk: Identically to what we have in HTML?

masonf: HTML links to that definition

masonf: The behaviors come from CSS

annevk: It's not just editorial. Are the behaviors identical?

masonf: My PR removes some of these defs and refers to CSS

annevk: But not removing the entire concept

annevk: Concept could live in CSS, if identical

masonf: I agree

astearns: Makes sense to ensure we are defining something identical. But editorial in that it's something we need to work through once we decide the design we've got is what we want to move forward with with.
… whether we have interactivity prop is the more fundamental question, not sure we're there yet
… Hope this change will address the a11y concerns but need to ensure that's the case
… We don't yet have resolution to make interactivity not inherit. Can we resolve?

emilio: Can we resolve in this meeting?

astearns: Yes, it's joint meeting

annevk: Assumption is that the a11y people not in room agree with this

flackr: It's one of the things that have been identified, is a move in the right direction
… remaining concern is whether you should be able to set inertness from CSS at all

annevk: Yes that seems separate

astearns: But very relevant

flackr: But you can, with visibility: hidden

Proposed resolution: Make interactivity not inherit.

<wordsmithing resolution>

Proposed resolution: Interactivity does not inherit, and setting it on something that's inert does not change the intertness

<masonf> +1

<flackr> +1

RESOLUTION: Interactivity does not inherit, and setting it on something that's inert does not change the inert :)ness

astearns: I know this CSS prop is important to carousel set of proposals. What happens if there isn't interactivity property?

flackr: For a bunch of use cases they'll have to add prop via JS

vmpstr: Or they'll add visibility but that limits the effects you can have

flackr: Visually changes the things that are not current
… When scrolling, you would see the new contents pop into visibility as it becomes active
… In many use cases you can peek at next content
… Interactivity prop supports this

astearns: Can't do this another way?

flackr: Right

astearns: Other questions or comments?
… before we take it back to issue

masonf: I will update to incorporate the resolution, would like review after that

astearns: And you'll remove special casing for setting things uninert?

masonf: Right

<jarhar> whatwg/html#8189 (comment)

<astearns> github-bot, take up whatwg/html#8189 (comment)

Rendering <select> as a listbox is a one-line widget that opens a popup on iOS and Android

<github-bot> OK, I'll post this discussion to https://github.com/whatwg/html/issues/8189.

jarhar: This is about how select element with multiple is rendered as button with popup on mobile, and in-page listbox on desktop
… can't opt into one oth or the other, even with `size` attr
… HTML spec doesn't explain this
… I want to improve this
… Have goals mentioned in comment. Previously talked about adding new attr to do this.
… annevk recommended against, so want to use the size attr
… Have goal of feature parity across platforms
… Same HTML create same UI across platforms
… Believe in-page rendering on desktop is more highly used, have use counter to verity
… Setting size=1 to opt into button with popup rendering, size > 1 opts into listbox rendering
… Thoughts?

astearns: Concern is web compat
… Seems risky. Glad you have use counter

jarhar: Yep don't want to break the web, can change course if needed.

masonf: Nice thing here is that existing thing for size>1 is bad, so hopefully low usage

emilio: Does this change the dfault for multiple on mobile?

jarhar: That's what i'm proposing

emilio: That's the scary part.
… Does this involve impementing size = 1 with multiple on desktop?

jarhar: That's one of my goals

emilio: I think end goal is nice. Scared about webcompat. But worth a shot
… Other interesting thing is how will that work on desktop
… Not a lot of examples for muti-select
… Needs specifying
… whether you expect it to close
… Do you expect seleding a new option to require reopening the popup

<jarhar> openui/open-ui#1217

emilio: Could be either useful or annoying

jarhar: Linked issue is about this
… seen sites where there's no extra button to commit or cancel
… iOS one has close button but not an OK or cancel thing, so as soon as you select the options in native picker you can see the in-page button change
… pressing option doesn't close picker
… On android, there's both OK and Cancel buttons, doesn't commit selection until you press button
… Hoping to at least make base:appearance one consistent.
… Don't necessarily have to change native

emilio: Tricky part on desktop is that both use cases make sense
… say you have list of langs, want to select 2 or 3, don't want to have to reopen popup
… But for sorting option, most of the time you only want one but can select multiple. Good you are thinking about this. End goal makes sense, compat wise might be annoying but we'll see

<RobAtADP> what would the in page widget show after closing with multiple options selected?

jarhar: If compat doesn't work out, might be different without size attr, will have to give guidance that that be used

astearns: Maybe this is something that gets gated on appearance: base if we have compat concerns?

jarhar: Using CSS to switch modes would be challenging
… Thought we couldn't do it with in-page CSS. But the way it works now with button vs popup mode is it changes UA shadow root and slotting behavior
… chaning that on computed val of CSS prop would be not good
… Did a lot of work to have custom select slotting not to depend on this, would be more work for this new case

ntim: More fundamentally, making behavior changes based on appearance:base is something to avoid
… Appearance should be for stylistic rather than behavior changes IMO. it's confusing for devs otherwise

annevk: Tend to agree, but this is edge case.
… Isn't shadow different between auto and base already?

jarhar: Carefully designed so it doesn't change

astearns: Thought there were cases where appearance:base defined that shadow composition of a control, where it would not have been defined before

annevk: But that doesn't make it depend on computed style, could have same shadow for both

ntim: The current cases in css forms spec where we say elements work with appearance:base, it doesn't change behavior. Sliders are still sliders.
… It's just what's exposed to styling that changes.
… Anyway seems there's more consensus around making HTML attribute the opt-in. So not sure we have to consider appearance.

astearns: Other comments/questions?
… Do you want resolution today?

jarhar: No. Discussion more than enough

annevk: Don't think I ever said I don't want a new attribute. Just that we should try to understand existing behavior.
… Not sure we do, but maybe still OK with changing if it's compatible

astearns: Don't object to new attr?

annevk: Not necessarily, it depends

astearns: Also makes sense even if web compatible to consider this switch on the attr vs a design that has a new attr that was more specifically targeted to this problem
… What would make more sense for devs?

ntim: If new attr is added, shouldn't just be for the sake of compat. Shouldn't be the only reason to add new attr.
… Would make more sense to add new attribute if it's well tailored for a certain use case

masonf: I think if this were redesigned today the attribute would be popup vs in page.
… That would be more semantic

annevk: makes sense, but you still have to figure out CSS, probably in CSS

jarhar: Promising how tall the thing will be in appearance:base world might be hard or impossible

annevk: Yeah probably wont' work
… but in apperance:base world, size thing is exposed to CSS
… Can do `calc` magic and make it work
… Sounds reasonable that it can work

astearns: Seems like a non goal to preserve the existing behavior and then add extra way of getting consistent rendering
… Like the idea of having consistent rendering to fix this

annevk: yes

astearns: Yes, too many modes.
… Will wait for use counter results then come back to discuss

end