W3C

– DRAFT –
Canvas place element

25 September 2024

Attendees

Present
+, aardrian, alisonmaher, bkardell_, BrianE, CurtBellew, cyns, dholbert, estelle, flackr, fserb, gregwhitworth, hdv, JJ, kbabbitt, khush, kzms2, miriam, moonira, mustaq, noamr, oriol, Patrick_H_Lauke, rachelandrew, Rain, vmpstr, wendyreid, ydaniv, zcorpan
Regrets
-
Chair
Fernando Serboncini, Khushal Sagar
Scribe
vmpstr, TabAtkins, dandclark

Meeting minutes

<TabAtkins> Notes doc at WICG/canvas-place-element#13

<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/csswg-drafts#10945

[css-view-transitions-*] TPAC breakout session 2024

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

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/csswg-drafts#9745

[css-pseudo-4] Enabling carousel design patterns in CSS

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

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://gui-challenges.web.app/carousel/dist/

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/csswg-drafts#10720

[css-overflow-5] Scroll-markers

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

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/carousel

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://drafts.csswg.org/css-overflow-5/

flackr: This is the most mature of these specs, it's currently in the CSS Overflow 5 spec

<flackr> https://codepen.io/flackr/pen/MWMLPpP

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/csswg-drafts#10722

[css-overflow-5] Scroll button pseudo-elements

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

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.github.io/carousel/examples/scroll-button/

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/csswg-drafts#10715

[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://github.com/w3c/csswg-drafts/issues/10715.

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://jsbin.com/modewaj/edit?html,output

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://codepen.io/flackr/pen/yLmyPEV

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://flackr.github.io/carousel/examples/carousel/image/

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/open-ui#559

bkardell_: most recently in openui

<flackr> demo showing scroll-marker based tabs: https://flackr.github.io/carousel/examples/scroll-marker/tabs/

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/open-ui#559 (comment) was the summary of the discussion that I mentioned above)

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://github.com/salesforce/standards-explainers/blob/master/indicator-psuedo/explainer.md

<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://searchfox.org/mozilla-central/source/layout/style/res/forms.css#172

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://phabricator.services.mozilla.com/D223657 ;)

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

Minutes manually created (not a transcript), formatted by scribe.perl version 229 (Thu Jul 25 08:38:54 2024 UTC).

Diagnostics

Succeeded: s/shrink page/shrink back/

Succeeded 2 times: s/syns:/cyns:/g

Failed: s/Higgley/Higley/

Succeeded: s/higgley/Higley/

Succeeded: s/I did/I used `stretch`/

Succeeded: s/stylesheet/spec

Maybe present: ??, aaj, Adam_Page, astearns, chrishtr, dbaron, emilio, giacomo-petri, ilya, jarhar, mmocny, ntim, smaug, smfr, TabAtkins, tim, xiaochengh

All speakers: ??, aaj, aardrian, Adam_Page, astearns, bkardell_, chrishtr, cyns, dbaron, emilio, estelle, flackr, fserb, giacomo-petri, gregwhitworth, hdv, ilya, jarhar, khush, miriam, mmocny, noamr, ntim, Patrick_H_Lauke, smaug, smfr, TabAtkins, tim, wendyreid, xiaochengh, ydaniv, zcorpan

Active on IRC: aaj, aardrian, Adam_Page, alisonmaher, bkardell_, BrianE, CurtBellew, cyns, dandclark, dbaron, dholbert, emilio, estele, estelle, flackr, fserb, giacomo-petri, gregwhitworth, hdv, jamesn, jarhar, JaseW, JJ, kbabbitt, khush, kzms2, lea, miriam, mmocny, moonira, mustaq, noamr, ntim, oriol, Patrick_H_Lauke, rachelandrew, Rain, smfr, TabAtkins, tpac-breakout-bot, vmpstr, wendyreid, xiaochengh, ydaniv, zcorpan, ZoeBijl