Meeting minutes
<TabAtkins> Notes doc at WICG/
<JaseW> Are there slides somewhere?
<ZoeBijl> Is there a queue?
<TabAtkins> (this is why we use IRC for scribing and queue control, instead of one-off docs and such)
<smfr> Aren't we out of time?
github-bot, take up w3c/
[css-view-transitions-*] TPAC breakout session 2024
<github-bot> OK, I'll post this discussion to https://
noamr: welcome to the future of css view transitions
noamr: <slide 2> previously on view transitions
… <slide 3> we have shared element transitions, things that transition into other things that are not the same element. here we have an icon transitioning to a cover
… what we did in the last few years and apple webkit did we did same document and cross document view transitions, SPAs and MPAs work with same experience
… we don't want the people to change their architecture for the experience
… the constraint is that it's same origin
… <slide 4> things we have in the oven right now: current view tranisiont are flat
… they create a pseudo element tree with snapshots old and new states. this tree is flat. it's a bunch of things stacked on top of each other. so we're working on nested transitions
… the other thing is that they are for the whole page, so we're thinking of scoped transitions that are more modular
… that's not the topic for today
… <slide 4> the story of navigation is incomplete in two ways
… first, it's limited to same origin navigations, and the world is not the same origin
… second it's gesture driven
… <slide 6> you define the transition by defining an image on both things and we use pseudo elements to style what's happening in between
… this happens in the new document
… <slide 7> in cross document view transition, all the authors can do is slap a rule and it magically works
… and the new document runs the transition
… <slide 8> why should this be only cross origin
… <slide 9> we have requests for this, you saw album to cover transition. what if it's a recommendation to a music provider. this is about a spacial relationship
… that allows you to navigate
… what about same owner and different origin
… origin is the security barrier on the web, with only a few exceptions
ilya: commerce has a distinct page, where you want to navigate from ecommerce to a wallet provider
… when you finish the wallet, you want to transition back to the site. both of those are janky
… cross origin would do wonders here
noamr: <slide 10> this is about the sense of orientation not specific to the app
… <slide 11> this is an example syntax, maybe we can say "to: any" to just allow the transition
… <slide 12> so why not then?
… <slide 13> because security
… this is an easy way to kill projects
… we were a bit more curious to understand what this means in practice
… <slide 4> so the main security thing is ancillary data leaks. this is data that isn't directly related to the request
… for instance if you ask for geolocation and you get it, it's not ancillary
… here you ask for a visual effect, but you need geometry style information and you can gather whether the user is logged in etc
… even timing whether the page allows the transition and how long it took, all of this is ancillary data and we don't want to expose any of this
… is this reasonable to expose something, but let's assume not
… <slide 15> second it's about miscoordination, think about stale links on the web
… where it leads to information that is no longer there and you can have buggy looking effects
… if it's cross ownership the other side may look bad
… <slide 16> third is spoofing, you can start a view transition and bind it to a scroll timeline or pause it
… the old side can do a bad image like call 1800 givemeallyourmoney and the user will think it's part of the new site
… so we can't do it
… so we look it at as a tradeoff triangle
… first is the expressiveness and then complexity
… <Slide 18> with security i think of it as constraints
… the first is about the spoofing part, the transition needs to be brief
… this transition can't be seconds or scroll timeline, it needs to be 1/2 second or less
… it needs to look like an animated transition
… the other one is isolated, so unlike same origin transition, here the constraint is that neither document can interrupt or observe the transition
… neither document can know if the transition happened
… this is a one way street for one document say it wants to transition and the rest is invisible
… this is what makes it possible security wise
… <slide 19> so let's say we have these principles, now we have 2 dimensions to explore
… we have root-to-root element-to-root and element-to-element
… <slide 20> this is root to root, the relationship is the whole page not per element
… this is still interesting as this is still an opener relationship
… this could be something that the page says without each elements
… <slide 21> but it's less inspiring than other stuff
… like if the opener wants an opacity style animation and the browser can run it by itself
… why do browsers control it? maybe there is some relationship there
… <slide 22> element-to-root, this is from material design. UXR found that users love this type of transition
… from list or from grid open to the whole thing. this is a common usage pattern
… this doesn't require coordination since only one page gives us interesting information. the first page gives us geometry etc, but the second page only gives us a surface
… <slide 24> we could have a special view transition name that oculd be the new root
… and the icon could transition to that name (new-root)
… the old page decides what is animation and it needs to brief, but it can do an opacity animations
fserb: what do you mean by types?
noamr: it's not important for this
fserb: and the two is the list of domains?
noamr: yes
noamr: <slide 25> the last is element to element as the last examples
… <slide 26> we have an interaction ... you still need to define all your animations in advance, and it allows you shared element
… and we need to avoid a way to avoid miscoordinations
<lea> oops sorry
<lea> wrong room
<fserb> np :)
noamr: <slide 28> we have the following implementation options
… we can run it on the browser, or run this in a special document
… the third one is that we precompile the animation, compute all the keyframes, and then run them one at a time
… none of these are simple, this allows interesting UI. security wise it's achievable
… we're not sure if the expressiveness and complexity trade-off is worth it
flackr: you mentioned that element to root the style comes from the old page. is that also true for element-to-element? if you're running in the new document you can get the styles
noamr: <missed>
ntim: can you go over impl options
noamr: one is to run in the browser, one is to do a new document
ntim: what is browser mean
khush: same as what the browser UI would do, and make it part of the browser UX
ntim: like swipe animations?
flackr: this is defined by css though right?
noamr: yes
noamr: another is to have an anonymous document, and that's what's running the animation
noamr: the third is precompile the animation all of the keyframes in advance to something like display lists and send them over to play
fserb: first, because i don't know how it works. for the same origin, how does javascript interact with this. does it execute on the new page before the transition starts
noamr: when the transition starts, the new page is already active
fserb: doesn't it break the assumption to be as fast as possible
noamr: it would be in a different renderer process and only deals with the surface
fserb: so kind of like loads int he backhground
khush: what you're saying is an existing problem when you're navigation across the two pages
… we just don't want to add more bad things like allowing an inifnite bad animations
fserb: follow-up -- in the case where we're doing root-to-root or element-to-root, then a lot of time when you use motion to hide loading time
… as in you start animating before it's ready so that it looks instance
… in the element to element you can'yt do that, but in the element-to-root you could do that
noamr: yeah, you can animate to an empty surface before it's ready
… it's an option vs render blocking
fserb: both cases exist
noamr: we'll need to research this
fserb: and the only other question: do you have because it needs a coordination that is hard
noamr: we have requests for same origin and there is an ask for it, and it's a question we need to answer
khush: the use case is you share a link and you get an image in there but when you click that image expands to an image on the new site
fserb: but those htings don't track where that image was
noamr: yeah we'd need to do something with opengraph maybe, and not rely on viewtreansition names
mmocny: for element-to-element, i envision that the coordination has to happen ahead of time. would it help if ifrmes are involved like if you have an embed and then it's a same origin navigation
noamr: this is portals
… this would be a different architecture that would be a different set of use cases, we didn't want to go there
mmocny: can i ask for shoppify, when you do check out do you see the preview of the card are there iframes
ilya: no
mmocny: but you might only need element-to-root or root-to-root
ilya: yes, element-to-root is a better experience
Adam_Page: i'm on the aria working group, and only know css superficially, but i have two accessibility related questions: could there be anything that can disruptive to the mechanics of unloading a page
… when you're having something across the new page
khush: this would be the same with cross document transition
… all of this animation happens on the new dom
Adam_Page: the second question is that accessibility was sensitive to the motion
noamr: all of the things we are there in css to do prefers-reduced-motion
noamr: we might have different defaults
aaj: i had a question about what the perceived benefit is, since there is increasing complexity. does the root-to-root use-case, can we estimate how much of the problem that solves
… is that enough to be happy or do we go beyond that
ntim: it would be weird an dinconsistent if we only did one of the use cases
noamr: it would be something we need to take a look <missed>
aaj: you start with a simple implementation and go beyond that
ntim: for developers it's confusing if you only cover cross origin but only have same origin it's confusing
noamr: you can have a long animation or something else
noamr: none of these are all shared element transitions
khush: we haven't decided what page we are running this on
flackr: if we have element-to-root then going back would be weird that you can't do the opposite (shrink back)
noamr: it's an open question
fserb: good point
khush: the other thing we want to talk about what's in the works, and talking about in view transitions next
… most users use gestyures to navigate and view transitions aren't supported there
… <slide 2> this is an example of cross document view transition and you click and you see the animation, when you do the back arrow it navigates you back
… <slide 3> this is something we're working on, and this is in other browser. the interaction when you clicked a link is the same, but when you did the swipe gesture and we're doing a animation when we do the swipe
… so we can't run the view transition there
… so we gave the users an ability to customize and took it away
… i wanted to mention that the way this is done is we capture a screenshot of the page, so when you swipe back, you can get the peek of where you're going and choose to go there or not
… <slide 4> here, we have a couple of example of other transition where customixation might be helpful where the browser can't do it automatically
… one is grid of items where you want the animaiton of detailed item to collapse to where it came from
… the browser can't do it, but the browser can't do it
ntim: how is it related
khush: if we didn't have gesture then the browser can run the transition but if you're running it with a gesture, then we can't do the view transition for that customization
… the browser isn't doing a job as good as the author could
… the second example is we're dealing with two tabs
fserb: we're talking about gestures, but you're only mentioning back gestures
khush: yes, we're starting with back gestures
noamr: thinking of dismissing dialogs, there are other gestures that exist and we were discussing whether to call it swipe to back or a gesture problem in general
flackr: the tab switch is going forward as well
khush: <slide 5> so i'm diving deep into how to solve this problem
… the red and green part is showing you whether you're on the old or new part of the navigation
… most of the interesting stuff happens on the green side
… on the old state all we do is do the navigation and do captures, but everything else including animation happens on the new page
… <slide 6> this is what the box tree/pseudo tree looks like you have old pseudo that is static images, and the new pseudo is content that is coming from the current document and that's why it's live
… <slide 7> this model doesn't work, because by design you would need to run the animation before you've navigated
… just to mention why that's bad: there's a lot of state we can undo accidentally, like if you swipe a page and that cancels a payment page without committing to the back gesture
… this is why we need to do it on the old pahge
… <slide 8> the model we're proposing, we construct the pseudo tree on the old page, and now the line is red since all of the interesting stuff is happening on the old page
… if the user decides to cancel and we snap back, nothing happens
… if they decide to invoke we flip to the new state
… <slide 9> the pseudo tree looks the same, but now the old pseudo is live content from the old page and new pseudo is static content
… <slide 10> so where is that content coming from, since we haven't navigated there
… if it's a new navigation we don't know what we can do other than prerender
… for the history navigation, we have a few options. first is the UA screenshot, which is what we're doing for browser ui
… let's wrap it up as a pseudo and give it to the page
… the other option is when you went from page A to page B, we broke down the page and captured all of that state, we currently discard it. maybe we can persist it which gives you more interesting information
… the last one is back-forward cache. if it's already there, maybe we can ask it to produce one frame and that gives you a high fidelity content
… we're proposing starting with UA screenshot
… <slide 11> mostly this is what we already have but changing how we do this, but something that is missing is that we don't have a notion of gestures that navigate
… for this feature we need this
… we're thinking of introducing these concepts
… one nice thing is that we're not eh first ones to do this
… scroll driven animations solved that problem
… <slide 12> so the idea as far as CSS is concerned, this gesture can be introduces as a timeline
… <slide 13> the one we're htinking of is similar: the first block customize-ua-gestures, is the author saying that i want to run a custom animation, so suppress your own (browser's)
… and the second part says this animation is driven by that timeline
… so far this is nothing view transition-y going on
… for same document navigations, you don't have use view transitions so maybe you can do something simpler
… the goal is modularity
… the other thing is important: we're not giving developers power of what the gesture does, back gesture still navigates back
… all you get to do is customize the back gesture
… <slide 14> this is how you would glue it into view trnasiitons
… you give it a navigation component that says gesture(--back-timeline) and how UA css will automatically use that timeline
… the ideal goal is you defined a transition and it doesn't matter if the user clicked a button or swiped
… i'm happy to hear question
fserb: there are two things: gestures to the timeline, and automatically creating back transitions depending on the forward transitions
khush: so distinction if you go back, then you load the last page
fserb: this. might be nice to have without gestures
flackr: one thing you mentioned it has to run on the old page.. if we have a bfcache, you might unload the page and bfcache it and then reload it
khush: yes and no, since we still run pagehide and things like that, and the page can cleanup the state
flackr: it may not be that bad, but setting that aside: at hte point when you're capturing the screenshots, you can capture all of the info that you want to execute targeted transitions with captures and named elements
khush: it has some intersection state
ntim: what if the website puts a vierw transition that is completely incompatible with the gesture
ntim: where it doesn't makes sense with it
khush: the site can do weird things with click based animations as well, it's all withint hte context of that
??: the site can scroll up when you scroll down
fserb: the back one is decided by the ua
khush: the action decided by the UA but the visuals are up to the author
ntim: what if the page decides that we swipe from the right instead of from the left
khush: if the site decides, and some of the semantics we have to decide
??: does that change if the page is RTL
khush: yes, as a browser we change the direction of the UX
noamr: you'd have the coordinates that are relative to the gesture and relative to the history
fserb: have you thought of the next step, you're presenting as a linear timeline, but that doesn't work in 2d gestures
noamr: you can have several coordinate systems, you can have two additional ones that are relative to teh gesture and to the historuy
… are you going in the direction of the browser history or finger direction.
… this is the type of thing to figure out
khush: we went into a lot of thinking in browser UI so authors don't have to think about it
fserb: the expressiveness is a complex problem
ntim: i'm concerned that you have a different platform that you want a different gesture to go back
khush: you can start without exposing this gesture to this platform
noamr: it's a progressive enhancement, if you don't support it nothign breaks
fserb: have you thought about naming the gestures and then having those
tim: i was going to say that there is a case either way, being able to hook into the intent of the gesture is likely more good (but can make arguments for both)
… if you're hooked into the gesture itself
… history back is history back
ntim: if you're hook into intents and you assume a certain visual effect, the gesture doesn't make sense
khush: yeah you need a combination of both
noamr: these are all the great questions
end
github-bot, take up w3c/
[css-pseudo-4] Enabling carousel design patterns in CSS
<github-bot> OK, I'll post this discussion to https://
flackr: [introduces self]
flackr: I've been doing a lot of exploration into new UI patterns on the web, one of which is carousels.
flackr: if you look up "should I use a carousel", the common answer is no
flackr: session complete
flackr: this website goes into a bunch of pitfalls people often run into when they write carousels
flackr: This particular example is a bad carousel too, it auto advances, I can't swipe, etc
flackr: despite the fact that they're often done poorly, there are many many carousel components
[tech issues]
flackr: this is bootstrap, for example
flackr: OpenUI has done a long exploration of carousel pattern
flackr: Adam created a demo showing all the different "shapes" for a carousel
flackr: dots, thumbnails, no page markers, no arrows, previews of the next item
flackr: you can have shopping carousels, where you move be3tween *pages* of items
flackr: whether we like them or not, devs create carousels, so we should make them better
flackr: looking at most of these, there's some common features
flackr: CSS today comes pretty close to letting you build something like this in a scrolling elmeent
flackr: with Scroll Snap you can make something that slides from pane to pane, supports touch
flackr: because eit's just a scroll, any scrolling mechanism works, better than explicit event handlers
flackr: you just have to roll a few pieces yourself
flackr: that's what Adam did on his site, making a few extra bits in JS
flackr: so I looked into what we can do better, so it's just scrolling, we can accelerate that, and navigate it in the browser so it's more accessible
flackr: I have an explainer where I touch on these features
flackr: you have scroll-snap, as mentioned
flackr: you often have buttons to scroll between items/pages
<flackr> demo: https://
flackr: there's often a progress indicator
flackr: the progress updates as you scroll
flackr: and if you have all of these things, you can make a carousel
flackr: you can change where these things are positioned, you can make vertical carousels, any combo
flackr: breaking these down, I think we can make it possible to express in css
flackr: i've outline a set of features i'd like to dive into, to explain what part each is offering and how it's used to build a carousel
flackr: first, some form of stylable fragmentation
flackr: to create automatic pagination
flackr: if you use multicol fragmentation, columns:1
flackr: you'll get a layout with one page of content per fragment
flackr: you'll get a long list of columns, split up into "pages"
flackr: if we let yous corll-snap to that, you get a paginated experience
flackr: scroll markers if about those progress indicators
flackr: skipping the "flow into Grid areas" temporarily
flackr: scroll buttons are the next/prev buttons
flackr: You can roll them on your own, but it would be convenient to auto create them
flackr: finally, inert
flackr: the ARIA authoring guidelines for carousels recommend that tonly the onscreen content is present in tab order, and the next/prev buttons are used to bring up the next slide
flackr: so you don't trap people in a long list of slide contents
flackr: currently authors have to do this manually, updating the inert attribute on each slide
flackr: but you could imagine updating this automatically as you scroll or click the buttons
flackr: so that's a quick overview, I want to dive into some of them
github-bot, take up w3c/
[css-overflow-5] Scroll-markers
<github-bot> OK, I'll post this discussion to https://
flackr: you can imagine this like a ToC for a scrolalble element
flackr: in my example, one way to do it is create a set of anchor links to your content
flackr: I'm proposing you add `focusgroup` to get the input semantics you expect - can arrow between them, only one is active at a time
flackr: And the browser has some tracking to update which one is "active" at a time
flackr: if your page only contains top-level sematnic items - a list of items - you can create pseudo-elements for these
flackr: this is crucial for autoamtic pagination, like columns, so you can have one marker per page, not one per item
<flackr> flackr/
flackr: here's a simple live example, three sections, declared that each creates a scrol lmarker, and they've been flowed into the scroll marker group on the left
flackr: [showing source] roughly speaking, you add a pseudo-element for each thing that needs a marker, and a scoll-marker-group pseudo is automatically created to hold them
hdv: what are the a11y semantics of something that becomes a scroll marker?
flackr: shoudl be whatever makes the most sense for these use-cases. given that we upgrade links, i assume it woudl ahve the same sematnics as an anchor link
<Patrick_H_Lauke> link with aria-current="true"...
TabAtkins: and note that in this example it's *generating* fresh anchor links, they can be whatever. if reusing elements on the page, they have to be links already
flackr: this example reuses existing links. The ToC links are in a focusgroup, and we track sc roll progress to indicate which is active
flackr: I also have a separate scroll marker group on the right to track the top-level sections.
flackr: each group has its own "current" marker
flackr: inline links, not in a focus group, dont' get considered in this, they're never marked as "current"
<flackr> https://
flackr: This is the most mature of these specs, it's currently in the CSS Overflow 5 spec
<flackr> https://
flackr: what i've shown so far is a polyfill, but we have an impl in Chrome Canary with experimental web paltform features turned on
flackr: the only content on this page is a bunch of items. they're automatically grouped into pages, with scroll markers for each page, and next/prev buttons, and it's all automatic from CSS
flackr: any questions about scroll markers or move on?
bkardell_: This is dependent on the focusgroup attribute? what's the progress on that right now?
flackr: to make a scroll marker group from link elements, that's dependent on focusgroup
flackr: we implicitly have the semantics for the pseudo-elements, but it doesn't depend on the attribute
bkardell_: does the implementation support focusgroup?
flackr: the pseudo-element impl has an implementation of focusgroup semantics, by hand. we do have a `focusgroup` impl behind a flag in Chrome, but not shipping yet.
flackr: The use of it in my earlier demo used the polyfill
jarhar: i'm not super familair with the pseudo-element API shape
jarhar: kinda seems like these are more element-like than other pseudos
jarhar: we had to make some changes to make them receive events in ways other pseudos can't
jarhar: we have, in blink, a pseudoelement class that's a subclass of Element so it kinda works
jarhar: talking with Tim, he said their pseudos are more strictly different. might be difficult for them to implement.
jarhar: wonder if there are any webkit folks around to talk about
flackr: good question. pseudos *can* be targeted by clicks and other events. we hide that the pseudo was targeted (use the owner element instead), but i fyou click on a ::before you can listen for the click event
jarhar: and you can use like hover pseudoclass?
TabAtkins: Yes, and :focus/:active if they're focusable/etc
<bkardell_> maybe we can tag ntim so they can find it when there's time and let us know :)
flackr: the CSS pseudo spec has a full definition of PseudoElement interface, subclassing Element, so there's a route to them being full-blown event targets
jarhar: okay, probably less crazy than i thought it was
github-bot, take up w3c/
[css-overflow-5] Scroll button pseudo-elements
<github-bot> OK, I'll post this discussion to https://
flackr: scroll buttons are conceptually simialr to scroll markers
flackr: they are focusable, they hang off the scroll container
flackr: and they scroll that element in the indicated direction, as specified by their selector
flackr: here i used ::scroll-down-button, but we have syntax alternatives like ::scroll-button(down), this would better let authors specify logical or physical directions, dpeneding on which is appropraite
<ntim> WebKit does want to move away from the PseudoElement class that extends Element
<flackr> https://
flackr: so i have a demo built on the polyfill - you also saw them in the Canary live demo
flackr: Here's a terms of service agreement or something, page down buttons to go down
<ntim> WebKit only uses that for ::before / ::after. The other pseudos that generate boxes are hooked to render tree building
flackr: they should implicitly become inactive when you can't scroll further
flackr: and they scroll equivalent to one page, like pressing PgDn
smfr: is that the equivalent of a smooth programmatic scroll
TabAtkins: I assume it's basically a PgDn press (possibly in other directions)
smaug: maybe a little tricky, maybe not scrolling a full view of height
flackr: my understanding is most browsers scroll 85% of the optimal viewing region of the scroller
flackr: so you can still see osme of the previous content
flackr: of course, with snap areas it'll align as necessary
dbaron: I think some may avoid letting the overlap get too big relative to the default font size, you don't want too many lines repeated
smfr: so this is independent from carousels, right? basically a generic "fake scroller" control
flackr: yes
smfr: and you could have one for the root scroller?
flackr: yes
dbaron: is it problematic for pseudos to be focusable?
flackr: i don't think so
<flackr> TabAtkins: we presumably want to make psuedos focusable
<flackr> TabAtkins: i hope it's fine
dbaron: I think there's a bunch of things taht assume the curently focused thing is an Element
flackr: my thinking is that .activeElement
dbaron: that's one of the pieces, yes
flackr: it'd give you an actual element, in the case of these buttons its the scroll container
flackr: this is similar to having focus in a shadow dom, the host element is the activeElement
dbaron: that seems like a reasonable model
dbaron: it does need to define tab order and such
bkardell_: what's the role?
flackr: depends on the pseudo, but needs to be well-defined for each.
flackr: for scroll buttons, presumably a button
flackr: i definitely want feedback on things like "what is the focus order"
flackr: i think general guidance is buttons for navigating should be together in a group, so they hit the buttons, then into the contents
bkardell_: right now scrollers don't have focus behavior, right? you focus the area.
??: it depends!
flackr: notaby this is not reproducing the scrollbar, it's adding new scrolling affordances
hdv: is there a precedent for gencontent to have their own roles
<flackr> TabAtkins: there hasn't been yet as so far they haven't been given focusability
github-bot, take up w3c/
[css-overflow-5][css-scroll-snap-2] Snapping and generating scroll-marker pseudo-elements from fragments
<github-bot> OK, I'll post this discussion to https://
flackr: Final thing that really helsp make this fall together is being able to use fragmentation to automatically create the "pages"
flackr: So if you specify that you have columns:1, that'll make one fragment per page
flackr: You could do multiple columns
flackr: we want to support some styling on these columns
flackr: scroll-snap-align is a notable one, to align the columns itself
flackr: not useful to stop a scroll halfway between columns, would rather it snap
<flackr> demo of columns: https://
flackr: the other use is generating a scroll marker
flackr: if a column is a destination you want to get to, you might want a scroll marker for it
<flackr> https://
flackr: combining these features, you can make this demo
flackr: note snap alingment isn't working yet
flackr: you can see the number of scroll-markers i generate changes as i chagne the container size, since different number of items fit on a scroll page
flackr: with snap-align support it would automatically snap to pages, arrows would work properly
flackr: this lets authors just write a list of content, and have it present in a full paginated experience
<flackr> TabAtkins: while this is fully generated, all of this can be done with real elements
<flackr> TabAtkins: allowing additional structure / semantics
cyns: This really excited me, as someone who's lead a dev team thru a carousel
TabAtkins: our exploration revealed that there were basically *zero* correct carousels on the web
cyns: but there are more correct ones ^_^
github-bot, end topic
wendyreid: I noticed in a lot of examples - and i've also struggled with this for devs - I haven't seen a lot where each item in the carousel contains a bunch of other content
wendyreid: Like say each has an image, text, and a call to action button
wendyreid: but you also want item-by-item interaction as well as interaction in each
wendyreid: so in this example (image with label) what if there's a button inside of each, too
flackr: this is just content inside a scrollable element, we're not treading new ground
<flackr> polyfilled demo: https://
TabAtkins: the only particularly new thing here is the auto-inerting. only the visible stuff in the scroller show up in the tab order, until you scroll pages
wendyreid: in this example I might have expected focus to move to the next button at the end, rather than past
flackr: we've seen both. the APG example has the buttons together in tab order, but they're visually together there.
<Patrick_H_Lauke> Agree with Wendy here ... APG pattern may not be the be all/end all
wendyreid: Yes, it depends on the visual placement
flackr: I haven't mentioned this yet, thinking of having invokercommand to let you make your own buttons that scroll; you can put them anywhere
flackr: maybe for generated content, we could use reading order to change where they are
TabAtkins: except those are abspos usually, so they "wont' participate" in reading order. but we could build on the machinery.
cyns: we were talkinga bout that in aria, having to go thru the entire slide to get to the next button can be annoying
bkardell_: I have now twice tried to tackle tabs
bkardell_: panels and panelsets
<bkardell_> openui/
bkardell_: most recently in openui
<flackr> demo showing scroll-marker based tabs: https://
bkardell_: got far, then got feedback that a bunch of the cases, Sarah Higley and I discovered that sometimes things that look like tabs shoudlnt' be ARIA tabs, but what should they be instead?
bkardell_: this might be the answer
bkardell_: these look a lot like tabs, but they're actually panels in a document, a kind of scroll
<dbaron> s/Higgley/Higley/
bkardell_: I like that
bkardell_: especially since with a MQ you could change how it's displayed, maybe on your phone it's just a long scroll of content
bkardell_: it's kinda a design affordances sometimes, different from browser tabs. those aren't design, they're a doc manager
bkardell_: I'd love to hear from more a11y people if you think this might be a decent pattern for attacking this kind of tabs
flackr: that's also one of the benefits that semantically it's just a list of content. you can just change the way it's presented based on form factor
cyns: would you change the a11y mapping based on that?
bkardell_: that's the question
bkardell_: maybe we already have things sorta like that, like collapse the menu up
bkardell_: but it seems more known-quality and subtle
cyns: the browser can do it in this case
bkardell_: yeah, and this is like scrollbars. we don't say "this is a scroll area" like in Java, you just get a scroller if you need it
bkardell_: here we can see "if you have the real estate, show them in panels" but if it's small make it just scrollable
cyns: I like how simple the code is, especially compared to other carousels
hdv: so this example wouldn't be ARIA tabs?
bkardell_: I think so, I think just having it be a scroller would be a better solution
bkardell_: ARIA tabs are cases where they're app-style tabs, more like browser tabs. those should be tabs.
bkardell_: but they're also not likely to change, they're not a style choice
dbaron: I spent an hour talking to Brian and Sarah Higley a year or so ago. I'm rereading my comments, from the long issue Brian linked.
dbaron: One thing - do you want find in page to find things in the other tab? do you want all tabs to show in a printout or all?
dbaron: I think suggestion was if find-in-page shouldn't switch the tab, and user only wants one tab in the printout, it's probably aria tabs. if it's the other way around, probably the panel-set tabs
dbaron: I haven't internalized it enough to be sure I believe it
dbaron: especially that those two things correlate well
bkardell_: i'm not sure *I* believe it. but enough people I respect have articulated it in a way that makes me think we need to take it seriously
bkardell_: if we find something that lets us make that distinction, we should do it
bkardell_: but yeah, I don't think everybody has the same feelings
bkardell_: not everyone agrees on the breakdown, or even that there should be a breakdown
bkardell_: but I think we've articulated differences that do make sense
hdv: user research about whether they prefer panel-sets vs aria tabs, doesn't seem to be a clear preference
bkardell_: does seem to likely be a user preference, people can prefer either
hdv: we saw people who liked either, makes it hard to choose
wendyreid: also it's not always semantically easy to express "going to different place on this page" vs "going to different page"
wendyreid: sometimes "tab navigation" is doing either
wendyreid: not clear to the user
wendyreid: and not really a semantic way to indicate that
ydaniv: wild idea, if I put overflow:clip (and rest is inert) it would be tabs?
<Patrick_H_Lauke> overflow:hidde (hdv)
flackr: one idea that came up in ARIA, could have a role on the scrolling element that determines the generated content role
<dbaron> (openui/
smfr: I had questions about the real ARIA tabs, presented today was high-level functionality
<Patrick_H_Lauke> bkardell I'm neutral on this. users often...don't care, as long as it works correctly and makes semantic sense
smfr: for scrolling carousels, wonder if we should do it for tabs too
smfr: you can do tabs today with radio buttons and :checked
smfr: do we want this to work better in this interface?
smfr: id' probably want non-visible tabs to be display:none for perf reasons, for example
flackr: so something similar to scroll markers, but display:nones the non-active content
there's definitely something good in there
smfr: also, you said the scroll buttons are siblings of the scroller, how does that work for the root scroller?
flackr: they're children in that case, you'd use fixpos to position them
Patrick_H_Lauke: heard about some devs doing this with radio buttons/etc
Patrick_H_Lauke: that's obvs semantically very dubious
Patrick_H_Lauke: much more positive with what i'm seeing here
Patrick_H_Lauke: more bespoke, rather than a perversion of CSS
Patrick_H_Lauke: explaining to a screen reader that, yes, there are radio buttons but they actually switch visual tabs, it's bad
Patrick_H_Lauke: so this is a good step forward
flackr: We're at time, wrapping up
<Patrick_H_Lauke> (in answer to brian's earlier question, i hid in my hotel room for the session)
<Patrick_H_Lauke> great stuff, thanks all
Styling form controls
ntim: <presents slides>
… I've given this presentation in joint csswg-openuicg meeting
… I've heard many haven't seen it
… It's presentation on how we want to make form control styling easier
… It's gathering of ideas from what's already been discussed in csswg/whatwg and some ideas from webkit team
… Problem is consistent styling of form controls is a pain
… If you've worked with form controls before you may have faced inconsistent default styles, or different parts are inconsistent
… webkit-prefixed pseudos, others in different browsers
… The way we want to address this is address incrementally
… But it's also important to look at this holistically, look at all controls
… Important to not repeat past mistakes
… One of the main ideas from CSSWG is appearance:base.
… `appearance` is prop with 2 other values, `auto` and `none`
… `base` is new value opting you in to nicer interoperable mode
… Gives you consistent pseudo elements for styling
… for UA stylesheets we want to base ourselves on a few principles.
… Needs to be identical cross browsers. Controls need to be recognizable. Styling needs to be accessible (e.g. contrast). Styling should be consistent across controls; like a design system. Need to be able to customize appearance easily without needing to reset a bunch of properties. Styling needs to be comprehensive, cover all states.
… appearance auto is native control styles. appearance: none is basically random. appearance: base is more consistent.
… Note sizing is inconsistent, maybe appearance:base can solve some of this.
… Can't really apply styles on appearance: auto, it's a non-starter for form control customization
… appearance:none is a mess. Sometimes use system colors. Checkboxes and radios just vanish.
… So not usable as starting style.
… pseudo-element tree is inconsistent
… For appearance:base UA stylesheet we inherit fonts and text colors.
… background is transparent. Border is currentColor.
… Want to hear feedback from you all about this proposal. What do you think the pain points are with styling form controls, what defaults you're annoyed about
chrishtr: Do you have screenshots of the rest?
ntim: I just have these but can make more
emilio: I think it's good we're focusing on a few simple properties that make the control look like that without adding extra stuff. Focusing on border, background-color and pretty much that is great. I think the different sizing you fixed by just inheriting font. That's because textarea and input have different default fonts. But looks reasonable to me.
… The other controls may be a lot harder but for these looks pretty good
ntim: Pitch for this is when you style from control it's as easy as styling div.
… Very simple properties, everything else inherits by default
giacomo-petri: It's great. I have concern with placeholders for the color. Browsers provide min high-contrast area. If I can decide text color by default, contrast ratio might not be sufficient
ntim: Right now I use currentColor at 50% capacity but that might not be ideal default
gregwhitworth: Important part is you are getting the same styles without us doing computation heavy stuff
… Complexity can grow quickly if e.g. you have background image
… At least with this all browsers are now rendering the same stuff
… Shouldn't be on UA to handle this
ntim: If there's a better default
gregwhitworth: sure but that's can of worms
aardrian: I love what I'm seeing. Bring in a bunch of props using inherit. Would also bring in letter-spacing and word-spacing. Both those cases inherit.
estelle: My concern is the contrast ratio. Considering a new value named mask. I'm also wondering about width. Did you make it display:block?
ntim: In my prototype I used `stretch` but may not need to force it
emilio: These are inline blocks by default
estelle: If you put width would it listen to that or to appearance:base?
emilio: We shouldn't change defaults
estelle: My concerns are not just the color contrast but if someone declares yellow or orange which has hard time meeting contrast ratio, if you put placeholder in there, what happens?
… The placeholder is text but has to be different color because it's lighter. E.g. orange on blue and ratio is already below AA generally.
… Those are concerns that if you inherit and you have placeholder text, need to ensure there's contrast so user can tell it's placeholder
… Mask is new thing presented yesterday. An HTML attribute
emilio: Still very under construction
chrishtr: If added, need to take that into account in appearance:base mode?
estelle: Yes
gregwhitworth: Is this the end of your presenttation?
ntim: no
<gregwhitworth> https://
<estelle> another thing to consider: ::focus ring style
gregwhitworth: Was going to ask what Chris asked. I want to hold off on having strong opinions because you can just introduce UA stylesheet we can review. My questions are about, e.g. with checkboxes and stuff, how do you guys aim to approach this? Not straightforward to solve given all the use cases for checkboxes
… Problems with details/summary, range, datetime, get really complicated
dbaron: I wanted to point out one of the concerns with complexity of stylsheet and complexity of overriding is also the states.
… E.g. button has hover style, focus style, combinations of these things
… Does appearance:base have all that complexity?
… When the author overrides, must they reproduce all that?
… One of the issues there is if we limit stylesheet, then it's easy to override those styles
… I think there are tradeoffs there
emilio: That's fine. It's the current state with appearance:none
gregwhitworth: We're overthinking this.
… The whole purpose of this is everybody is doing block/flex/inline...I don't have a strong opionion, I just want to see unified UA stylesheet
… and to review that
<aardrian> Agreeing with gregwhitworth that I want to see a massive UA stylesheet.
ntim: Re: dbaron's question, this is UA styesheets and those have lowest pri/specificity in cascade, so authors override anyway
dbaron: The point is partly that the moment you set anything on the control for ignoring states you've overwritten all state specific styling
gregwhitworth: The second you've opted into base you've said you don't like the native styles
dbaron: Goes back to list of 6 principles. Points out how that list conflicts with itself
ntim: Re: states, we had that convo internally about styling disabled elements. As soon as author overrides, they forget to define :disabled.
… So you define in UA stylesheet for :enabled
… Once they have disabled one on screen, will see something's wrong
xiaochengh: I'm wondering about the @@@ how much is going to style the internals of the form controls?
… Is this UA stylesheet also going to style internal pseudo elements or just the form controls?
ntim: Want to make sure styling on internal parts also applies to the principles.
xiaochengh: I feel like this is dilemma. Internal impl of form controls shouldn't be controlled by specs. By introducing this you force implementations to do it a certain way.
ntim: We also want to solve problem of inconsistent internals
… Web devs also want to style internals
… E.g. with input[type=range] they want to style those internal parts
dbaron: Lot of part of the plan here is that doing appearance: base is defining those internal pseudo elements
<Zakim> zcorpan, you wanted to say our current ua css for placeholder is opacity: 0.54 - https://
zcorpan: Placeholder uses opacity already in Gecko
emilio: Other browsers use hardcoded color
… It's changeable
emilio: Don't know if you've considered -- if we use currentColor for all these, things like color schemes stop working
ntim: If you inherit color, normally the color from the scheme inherits too
emilio: If I want to make button dark, I say input color scheme dark, it works even if ancestor is light. With this approach it doesn't
chrishtr: So if you have div with currentColor and put color scheme it has no effect
emilio: Right
miriam: But you're opting into that
gregwhitworth: Point is you have a massive stylesheet we can all look at
chrishtr: If it's an issue you need some mechanism to fix
zcorpan: Common usage of color scheme is set on root. Then transparent still gives you a dark control. Wouldn't look different if you only set color scheme on input
emilio: Maybe it's fine
khush: Implementation-wise how complicated do you expect set of pseudos to get? Tree-abiding or UA shadow DOM?
ntim: Chromium folks can speak to that
<emilio> zcorpan: https://
jarhar: Yeah, the select element for appearance base has a bunch of different elements. I'm tweaking it, some for appearance:auto and :base, exclude some for base to make it work
gregwhitworth: With new select there are new elements too
… it's not just the pseudo elements
ntim: Next part of styling controls consistently is pseudo elements
… Driving principle of designing pseudo element scheme is to cover reasonable use cases, consistency, inherit appearance from originating elements
… Could do this by `appearance: inherit !important`
emilio: Depending on how we make this work, I agree we should aim for that. Appearance is not inherited property, if we make the psedudos such that they have elements in between it gets set to auto.
ntim: That's implementation detail
gregwhitworth: He's saying youi're calling it out as principle but maybe that's not always true
ntim: <shows example of slider-like control>
… Have consistent tree as soon as you use appearance:base
… (for `<progress>`, or `<meter>`, `<input type=checkbox switch`, `<input type=range>`
… (shows tree for text-based input)
… And there's more we are thinking about
… Planning to take over form styling module level 1 doc
… Hoping to make it an actual spec
astearns: Don't look at it now, we'll start fresh
ntim: Last part is about styling pickers
… Like w/ customizable select
… Pickers are the part of the control that pops out of the page
… For this want to introduce `::picker()` pseudo with an element
… Devs can check support. Once all supported, we'll add non-functional version
… to opt-in for customization of select picker, add `::picker(select) { appearance:base}`
… This makes it no longer exceed window bounds to prevent spoofing
… For particular platforms like Apple Watch, UA might force picker to use native picker but that's up for discussion
… As for status, we're waiting on approval to publish spec
… There's already spec work for appearance:base in CSSWG and we' re prototyping
gregwhitworth: I'm not necessarily opposed. Have seen use cases I've seen that pseudos don't cover.
… We initially reached for psedudos because we were concerned about fricition, but people wanted new elements.
… In new select there are two
… The thumbs, tracks, those shouln't be pseudos. But I'll wait for the spec.
… I feel there's a lot going on that can't be covered by pseudos. But the value they bring is you end up with a spectrum of capabilities.
… May not want to extend control, just adjust styles. That's the value of pseudos
… But need to deal with that collision
ntim: Pseudos need to cover reasonable use cases. For more complex, might need HTML change to introduce new control
emilio: I see args for both but if you don't plan to support picker on given platform, could just fail to parse the selector
… Allows the dev to detect it
ntim: That's probably a better solution
gregwhitworth: I don't like the UA saying we don't care what you said
ntim: We'll do that regardless, at least this way you can detect it
xiaochengh: Are we taking the openui approach of specifying anatomy of every form control?
ntim: What I've worked on is specifying tree for all form controls
astearns: Yes to form controls, maybe not for non form controls
astearns: This presentation, send it zipped to wwarchive.
ntim: Would love your feedback. Pain points I didn't address that I should?
khush: Specifying the structure and the pseudos, that's only with appearance:base? Or also with appearance:auto?
… When are we guaranteeing you get this structure
ntim: Prefer not to with appearance:auto. Not mixing native and non-native UI.
… For appearance:none that would be nice but not sure we can because of compat
khush: So we'll have different stucture based on appearance?
emilio: We should aim to unify
ntim: I agree we should unify as much as possible
zcorpan: The compat prevents us from using appearance:none
emilio: Ideally we woulnd't have base
khush: The fact that CSS changes the tree...
emilio: It's subtle. How I'd implement it is that you don't make it change tree, but change the layout tree by hiding/unhiding elements
emilio: HTML attribute would be saner
gregwhitworth: CSSWG told us not to do that, to use appearance
ntim: UAs could set display to hide/unhide based on `appearance`
khush: So it has to be change in structure
emilio: Not necessarily
dbaron: How much change depends on what you're doing. With select there's more changes required in the DOM to account the work happening here
… Some of the stuff is enabled depending on what youi're doing so you can get hybrid cases
… Aren't there different condiditions for when you enable the new stuff?
gregwhitworth: I think it's all conditioned on `base` now
chrishtr: And `::picker`
gregwhitworth: Great work ntim
<zcorpan> RRSAgent: make minutes