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

<masonf> hdv is OpenUI's version of fantasai, in terms of scribing. :-)

<jarhar> https://lists.w3.org/Archives/Public/www-archive/2024May/att-0000/appearance_base_select.pdf

presentation on styleable <select>

Slideset: https://lists.w3.org/Archives/Public/www-archive/2024May/att-0000/appearance_base_select.pdf

emilio: you mentioned having interoperable keyboard behavior… I don't mind one way or another, but wonder… behaviours are quite diffferent between platforms

emilio: is having completely standardised keyboard behaviour across platforms worth pursuing?

jarhar: this point hasn't been discussed a lot… the idea of trying to converge the behaviour in addition to stylings came up at Open UI

lea: was the datalist wrapper added because of web compat issues?

jarhar: yes

masonf: emilio, we should definitely talk about the keyboard behaviours, it was brought up at Open UI because of accessibility issues with having differences between platforms

<jarhar> issue for html parser changes: whatwg/html#10310

jensimmons: can you explain the thinking behind using appearance:base-select rather than a generic appearance base?

jarhar: yes, it was one of the points of feedback in the first agenda item

<astearns> github-bot, take up w3c/csswg-drafts#5998

[css-ui] appearance: base to enable interoperable styling of controls/components

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

github-bot, take up w3c/csswg-drafts#5998

<github-bot> hdv, ignoring request to take up w3c/csswg-drafts#5998 which is already the current github URL

jensimmons: can you explain the thinking behind using appearance:base-select rather than a generic appearance base?

jarhar: yes, it was one of the points of feedback in the first agenda item

jarhar: one of the points was that it would have forward compat issues, so when we ship the new thing we would break websites

jarhar: would be happy to make a bikeshedding issue for this so that we can choose a name

<TabAtkins> Yeah, this was proposed by the csswg in a previous discussion

jensimmons: feels like there is a larger conversation that needs to happen around the strategy, to make big high level decisions, to avoid spaghetti 5 years from now

<TabAtkins> The forward compat concern is very real

dbaron: in this case we ended up with base-select because of thinking about the future, to try and keep an obstacle out of the way

florian: I see the forward compat issue with just using `base`… but there is also a different problem with using `base-select`, what about telling other elements that they are a `base-select`?

florian: last time we discussed something like that in CSSWG

florian: I think we talked about it would be useful, but as its own value so that it would not be overly generic or specific

florian: so why should this be a CSS property rather than an attribute?

<jensimmons> Are the slides Joey presented available online?

<chrishtr> jensimmons: Joey posted a link to it earlier in this irc chat

<TabAtkins> jensimmons: yes, linked at the beginning of the call

jarhar: I've started implementing this. Thing is we can't modify DOM based on computed style, so I was able to do everything in layout

jarhar: someone on my style theme existed we could have something like the light and dark function, but then appearance auto vs base, and that seems to work

jarhar: third point, if we make it appearance base there is forward compat issue, and with base-selectw we avoid that

<Zakim> TabAtkins, you wanted to answer the base-select on wrong elements question

emilio: to play devil's advocate re base-select being too specific… there are various already existing bits where this happens. If we get to the future where all form controls have their own appearance:base-something we could in theory introduce appearance base

emilio: so we could see base-select as an in between step

emilio: I don't feel too bad about the appearance-something approach

<TabAtkins> Yup, I was gonna say exactly what Emilio is saying here, if used in the wrong elements it'll just act like auto

<una> Agree - we can always limit base-select to select elements

emilio: don't think implementing is somewhat tricky to add something for each form control but it should be fine

<jarhar> the -internal-appearance-auto-base() as ive implemented it is only for two properties

florian: I think you made a reasonable on why it is doable to do it in CSS, but why is it preferable?

florian: re that it is already the case for some properties… yes, but it goes against the design principles, the concluded we needed none and auto and nothing else

florian: so native mode or non native mode would be what this flips between

florian: final point of consideration: CSS is primarily used with HTML, but not only with HTML, so other languages that are not HTML would need to define what these form controls are, seems less great if this would only work on HTML

jarhar: I brought the HTML optin to WHATWG, there is pretty strong pushback by the editors

jarhar: it does seem to have nice developer ergonomics and get the ability to style it with CSS.

chrishtr: another argument was made, since it's really just about the styling it would be good to put it in CSS, it's not about behaviours, it is about styling

<TabAtkins> Re: coupling, while we don't do it *a lot*, we do have a number of SVG-specific properties already.

jensimmons: how much does the state switching affect the functionality of the form control vs how much does it affect styling?

jarhar: interoperable keyboard behaviour may be part of this, not sure if that is considered functionality

jensimmons: sounds like you're thinking that with the change, other markup can be put in select, whereas without the change that markup doesn't have the same behaviour inside of select?

jarhar: the native picker could use markup to try and add stuff

jarhar: one idea was that you could put images inside of options, that still works in the appearance auto mode

<florian> +1 to jensimmons

jensimmons: seems like the sense is, we want to do a lot of things with select, so we add the ability to add any HTML… so we need some kind of toggle to specify the New Thing is being used. But it's unclear then if that New Thing introduces new behaviour

jensimmons: eg what if the CSS doesn't load?

jensimmons: am thinking… maybe we don't need a big toggle switch to enable the behaviour?

chrishtr: jarhar did think about these things…the prototype he mentioned earlier did implement these things

masonf: Anne's point seems to be… most of these things are behaviours and it would not be safe (from privacy/security pov) to allow arbitrary content to pop over

emilio: Firefox restricts the select area to the top level viewport to avoid this kind of spoofing attack

masonf: sorry, meant to say in Chromium

masonf: so the point is that moving between old and new mode with a switch in HTML is that it would need to be done piece by piece, CSS switch would make that easier

jensimmons: are you assuming we should have `base-*` for each individual form control?

jarhar: yes

chrishtr: and then in the future we could introduce `base` as a shortcut so that authors don't need to worry about it

chrishtr: we want to avoid people using `base` to get the hot new stuff, but then opting in to all the things, including things they don't want

aditya: if we're using an attribute authors would need to specify that attribute everywhere in their HTML, would be easier to apply it to all your controls with one property

keithamus: that was one of Anne's points as well

keithamus: to try and represent Anne's opinions… markup represents the data structures, but not necessarily the UI… so if you put a button inside of an option would that button's text content represent the options content?

keithamus: to answer jensimmons's question… a lot of the markup stuff would be ported as good as we can to 'old' `<select>`… `appearance: base-*` would be to turn off all the styling but not as agressively as `none`

fantasai: to the extent this is about largely styling… to have one appearance base I think I agree with florian would be best to not do that

fantasai: it would be nice if we could look into how appearance base could work for all form controls, so that we could try and ship it as one thing rather than creating all the individual ones, which would be more complicated to learn for folks

fantasai: that might require a bit more work, but if we can manage to get it to work it would be better to try and do that

<TabAtkins> Note that this is the same thing we did with reading order, for similar reasons

<TabAtkins> I don't think it's possible, fundamentally, to have "base" work while we haven't designed the behavior on everything else.

<TabAtkins> *especially* the moment we start doing the input types.

astearns: I realise we didn't start with 'what we want to get out of this', jarhar what would you like out of this for next time?

jarhar: @@@

<masonf> I think redesigning all of the form controls is a bit more than "a bit more work".

<jensimmons> I really appreciate the history meeting mode – especially since much of this work has been done previously inside one or two companies. I am glad to be able to catch up and hear where the discussion is at now.

<gregwhitworth> +1 masonf

astearns: let's have a summary comment in the issue next time so that folks can review

<dbaron> I think one of the underlying issues here is that we have CSS discussions that say "X does not belong in CSS" and WHATWG discussions that say "Y does not belong in HTML" and we need to use some of this meeting sorting out that there isn't overlap between X and Y. :-)

<masonf> Much of the work has been done in the open in OpenUI, not within a few companies.

jensimmons: do feel it was useful to have a history mode meeting this time, and can be more practical next

chrishtr: +1

<jarhar> the i would like to get agreement that we should use css, whatever property or value, to opt in to the new mode instead of html was "i would like to get agreement that we should use css, whatever property or value, to opt in to the new mode instead of html"

<una> +1

astearns: we're out of time, but will start scheduling these regularly

View Transitions

[css-view-transitions-1] Should view transition names be tree scoped?

khush: Spec currently traverses all DOM elements, including those in shadow DOM

khush: Suggestion is to limit to tree-scoped

<TabAtkins> +1 to this

khush: so this would exclude things in shadow DOM

astearns: I've written some tests for tree-scoping, btw, and interop is terrible

khush: Are you talking about other features that are similar?

astearns: Yeah, I did @property rules and @xxx rules, which are supposed to be tree-scoped, and they're not handled correctly

astearns: so probably some other things are also broken

<emilio> fantasai: two things, khush does this mean that for v-t that you'll never be doing transitions on anything in the shadow dom?

<emilio> khush: yeah this means that you couldn't use something inside the shadow dom as an independent thing

<emilio> ... scoped transitions would allow you to do that

<emilio> ... but only as a unit inside the DOM

<emilio> fantasai: to alan, there's two different kinds of scoping, at-rules and name defining on elements

<emilio> ... those are quite different mechanism

<emilio> ... I'd expect less issues with things like timeline scopes and so on

kizu: Wrt other scoping things, we also have timeline-scope and anchor-name

kizu: Might want to have a way to expose these names, since might have cases where you want to expose

kizu: maybe this is a more general issue that we need to handle in CSS, and have it work consistently

<TabAtkins> +1, we need a general mechanic for weakening shadow encapsulation

<TabAtkins> But we should be consistent for now

khush: kizu's point reminds me of ::part(), could use CSS to expose names from within shadow DOM outside it

khush: maybe if you expose the element could allow it to match

khush: could make it more complicated to implement

khush: we already have things in the platform that allow such information, in those cases do you want naming in CSS to also be exposed?

astearns: That would be a separate feature, though. This is for default behavior for view transitions

khush: Does it make sense to make this resolution cover other cases also? Have a general principle

astearns: I think a separate issue on general mechanism, because we do want to consider them all

astearns: don't want to have a specific escape route just for VT

<TabAtkins> Agree, separate issues

RESOLUTION: view-transition-name lookup is tree-scoped

[css-view-transitions-1] Handle startVT for offscreen iframes

<TabAtkins> Khush, ping me with any difficulties or for review

khush: optimization that if an iframe is off-screen, we don't run lifecycle updates or slow them down

khush: So as an optimization, offscreen doesn't get animated

khush: During view transitions, looking for that refresh

khush: but for iframe won't refresh until iframe comes on screen

khush: given it's already off-screen, user isn't going to see any animation

khush: so suggestion that if it's offscreen, treat it as invisible

khush: or if iframe is detached from tree

khush: current spec is to skip the transition

khush: just update the DOM directly, since user won't see the animation anyway

khush: Question here is, what if iframe is not detached, but is far enough off-screen that it's not being animated by the browser

khush: currently what happens is transition once you bring it on screen

khush: other option is to skip the transition

khush: third option is to force the update and do the transition

khush: once the browser has set up the animation, just like other animations the UA won't need ot run the animation, just update the timeline, as long as it's offscreen

emilio: I'm not a fan of forced-rendering, because it allows [missed]

emilio: you can call requestAnimationFrame and then startViewTransition

emilio: I tend to think current behavior is more consistent with regular animation frame would work

emilio: so I think current behavior is fine

emilio: skipping transition allows you to detect this more directly, I don't think it's great

emilio: we rely on the page not knowing whether it's throttled

khush: because iframe is not getting rAF callbacks, can't they already detect offscreen?

emilio: well yeah, but you don't know if it's because of slow machine or because offscreen

emilio: can act somewhat differently, but iframe isn't allowed to unthrottle itself, which is what forced rendering would do

vmpstr: We'll timeout by the time the animation is on screen, so if call startViewTransition callback won't run until at least one rAF callback, and by that time we are likely to skip the transition

khush: timeout starts after we cache the old state. Just happens to ???

vmpstr: doesn't seem great

emilio: Should we change that so that the timeout starts when you actually call the API?

khush: don't see any reason not to

astearns: other questions/comments?

emilio: Given we unthrottle not exactly when you're in the viewport bounds, but in some range, likely that by the time you scroll to the iframe transition has finished anyway

stephenfromgoogle: Is throttling behavior thought to be interoperable at this time? Vague in the spec.

stephenfromgoogle: would we introduce an interop issue if we don't force rendering?

<vmpstr> +1

flackr: that was one of my concerns about not forcing rendering. it would expose more of those differences in behavior

emilio: that difference is already exposed by rAF timing

emilio: I think it's somewhat reasonably interoperable, at least I assume all browsers to be throttling visibility:hidden and very far off screen

emilio: this is an area that could get improvement, especially now that lazyloading thresholds are a thing

stephenfromgoogle: I can tell you, our throttling code in Chromium has no margin. If an iframe is even 1px outside viewport, it will be throttled. That's different form lazyloading, which does have a margin.

emilio: worth discussing in an HTML spec issue

emilio: in any case, I still think forced rendering is not a great option

emilio: if you call startVT, then you can force engine to unthrottle you all the time, which is not great

khush: +1 everything Emilio said

khush: especially for one frame

khush: with other CSS animations, unless animating we don't need to spend resources on it, but here do

khush: so would prefer current behavior

khush: Yes, different browsers use different margins, and different features have different margins, being exposed doesn't seem like a big constraint

flackr: difference with animations is that you can always produce the thing that would have been drawn

flackr: whereas with VT, once you draw the updated, you have destroyed the old state

flackr: can't recover if it suddently becomes visible

flackr: One use case was starting a view transition on a frame, and then bring it into view

flackr: maybe there's an alternative to consider who's starting the transition

flackr: if starting within hidden frame, ... but if starting from root frame, could unskip frame by moving it into view?

vmpstr: whether we keep these frames alive or not is also a function of whether started when iframe on screen and then moved offscreen or started offscreen

vmpstr: Also don't understand concern wrt frame throttling. You could set timeouts and force rendering in a script

vmpstr: why would they use VT to unthrottle?

flackr: Browsers can force minimum timeouts on setTimeout

vmpstr: it would force it to run rAF?

vmpstr: iframe would do more work?

flackr: yes, it would force it right away, but setTimeout would wait a second

vmpstr: what's the attack vector here?

emilio: I'm not sure whether there's a good way... I've seen frames consuming too much CPU unintentionally

emilio: I can't think of a recent case where they do it intentionally

dholbert: maybe an ad wants to start playing immediately rather than skipping a few frames, so continuously burns CPU in the background so it's ready

khush: use case I'm concerned is, it's hard for an iframe to do the right thing without a lot of code

khush: whereas with other animations, just browser doesn't spend resources. This is the first case where we would force rendering

vmpstr: more wondering about second case

vmpstr: we could enforce setTimeout limits

vmpstr: concerned that you call your startViewTransition for some effect, and that will only start running when you're on screen

vmpstr: so I would force rendering or skip trnasition, but not doing thing until on screen

emilio: alternatively set timeout mechanism to start when you call API?

vmpstr: it's timing dependent -- whether you've scrolled the frame into view within the timeout or not

vmpstr: much better than current behavior

flackr: one possibility, when we start the animation we could start it with a negative start delay, so that it would be timed as if it had started on time

flackr: this would basically defer the work until the animation became visible

khush: you'd have to render to cache?

flackr: when it becomes visible. If it doesn't become visible until end of duration, then you can skip it

khush: complexity of all the animation after caching old DOM, you still have to do at least one render to cache it

flackr: or you defer the dom change

khush: which pseudo-elements get rendered depends on the new DOM

khush: we don't know until we run the callback

flackr: you defer until it becomes visible

flackr: when it becomes visible, you do pre-snapshot, you do the update, you determine animations, and you determine that the animations are finished, so immediately jump to end state

khush: sounds like skip

flackr: except it fires all the events

flackr: and [missed]

flackr: it's only "skipped" ...

khush: what's the goal? we don't want the author to know we skipped it?

flackr: there's no difference between whether your frame was on screen or offscreen

flackr: if it comes on-screen during animation, you'll see the animation

flackr: I haven't fully thought this out, but thinking that if you know when the request to start the animation occurred, that's the start of your timeline

khush: like current behavior, except animations will finish faster

emilio: might also be consistent with how time-based CSS animations work

emilio: if you have an iframe, and then scroll down, by the time you scroll up again the browser has done no rendering updates, but animation jumps to the correct point

emilio: that's worth consideration

vmpstr: capture right now can take some amount of time, and so that time would then be immediatley skipped into the animation, which won't be a smooth experience

vmpstr: essentially the animation start waits until the capture is available; with this change it would be a frame or two of delay

vmpstr: so those first 2 frames would be immediately skipped into the third frame of the animation, which is not ideal

flackr: that's a fair concern, possible ways to mitigate that

flackr: you take the time until the frame started as your negative start delay

vmpstr: worth considering this model, but need to be careful about the math

khush: my issue is this approach is complicated. What benefit do we derive from it?

khush: ...

khush: what's the benefit of bringing iframe on screen with the old DOM?

vmpstr: it supports cases of, suppose your animation is 30s and starts offscreen, and then you scroll it into view partway through

vmpstr: it looks like everything was working all along

khush: you eventually want user to see the new state

khush: point of doing animation is to go from old state to new state nicely

astearns: maybe we should look at the new option and bring it back

emilio: perhaps more realistic use case for this model is, consider a lazyloaded iframe

emilio: page being loaded has a view transition while loading

emilio: right now, given stephen's comment about no margin

emilio: lazyloading kicks in first, page is invisible, then you call startViewTransition. If you skip it, then you discard everything the author wanted even though user is about to scroll the iframe

<flackr> +1

emilio: That model doesn't seme too complicated, just need to handle the first two frame jump

emilio: It behaves more consistently with our APIs also

emilio: rAF we just delay your callback, this seems similar

emilio: I think there are more use cases that justify this kind of model

fantasai: basically agree with astearns and emilio

fantasai: let's explore flackr's model, and come back

vmpstr: ok, let's look into the issue and comment with our findings

[css-view-transitions-2] [css-pseudo-4] Clarify ordering of `::view-transition` with other tree-abiding pseudo-elements

khush: spec says ::view-transiiton element originates from the document element

khush: but doesn't say what the ordering of the pseudo-element is wrt other pseudo-elements

khush: proposal is, since conceptually it's lifted into containing block, it's meant to be last thing that paints over entire DOM

khush: so having it be after ::after makes sense to me

fantasai: Agree. Should be after everything, including ::after

emilio: is this observable?

khush: I think maybe hit-testing. If the author removes ? from root element, whether you hit ::after or view-transition?

emilio: that's a painting order problem

emilio: It's worth putting in the spec, but might not be observable right now

khush: which is a good time to do it :)

fantasai: if we all agree, let's just resolve and put it in the spec :)

<emilio> emilio: maybe `document.documentElement.getAnimations({ subtree: true })`, if that returns pseudo-element animations?

RESOLUTION: ::view-transition pseudo is the last child of its originating element, after everything else including other pseudo-elements

Transitions

[css-transitions] Transition to height (or width) "auto"

<khush> > if that returns pseudo-element animations?

<khush> flackr can confirm. I think it's supposed to.

w3c/csswg-drafts#626 (comment)

dbaron: We discussed calc-size() proposal. One question was whether we could, instead of or in addition to calc-size(), write what people want to write

dbaron: concern was compat, but did we check

dbaron: one thing I followed up with, since I had implemented, I could implement the natural behavior where you could just transition '0x' to 'auto'

dbaron: I could figure out what could break

dbaron: There's more details in the comment in the issue, but basically what I did was a very conservative study

dbaron: ran through loading top 1000 sites with a special build

dbaron: Even with that limit, I found multiple pages that would break with this change

dbaron: [gives some examples]

dbaron: Several pages animating widths and heights from zero that was not expected

dbaron: at the same time, there was a page on ups.com with an animation that got better

dbaron: but conclusion was, given this very small and conservative sample shows multiple pages that are broken

dbaron: we know it's not web-compatible

dbaron: so we know we can't just support CSS tranistion from 0px to auto and equivalents

dbaron: given that, what I want to get out of this is to restate more firmly that we want to move forward with calc-size()

dbaron: given alternative, which would have better developer ergonomics, is not compatible

flackr: agree we can't just do it automatically

flackr: what about having a more generic opt-in for authors?

flackr: calc-size() require for each item to change the styling

flackr: whereas a switch could opt in your whole page

dbaron: we could consider something like that

dbaron: maybe use transition-behavior, which is designed to do that

dbaron: it's reset by the transition shorthand

flackr: it's also about transitions only, not animation

dbaron: I think we can do both

dbaron: current behavior with calc-size(), to get the animation you have to wrap at least one endpoint in calc-size()

dbaron: I also do worry about global overrides

dbaron: because pages are built from smaller components

fantasai: Agree with flackr

<TabAtkins> I'm completely fine with a value that can turn on the transition behavior for general values, fwiw, so long as the default behavior requires using calc-size() on at least one side.

fantasai: I think putting in transition-behavior is good, not global, easy to incorporate into transitions and gets reset whenever you do a different ransition

fantasai: for animations, could consider something in the @keyframes rule, so that it gets associated with the keyframes and used wherever the keyframes get used

astearns: but agree that doesn't preclude using calc-size()

fantasai: yes

TabAtkins: Proposed resolution, by default, only get transition if at least one side gets calc-size()

RESOLUTION: Animation to/from keyword sizes requires an opt-in, so by default only get transition if at least one side gets calc-size()

dbaron: At this point it's prototyped in Chromium, but it's getting more stable and closer to matching spec at this point

End