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

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

Overscroll areas via command=toggle-overscroll

<github-bot> OK, I'll post this discussion to whatwg/html#12273

vmpstr: *gives intro to overscroll areas*

flackr: we started this as a css feature, and based on feedback at tpac we changed it to an html attribute which seems to have addressed some concerns

flackr: *gives demo of overscroll areas*

<JohnJansen_> can we get the link to these demos?

<flackr> https://flackr.github.io/web-demos/html/overscrollcontainer/

astearns: i didnt see a way to delete without the scroll gesture in the last demo

flackr: when i was building that demo i was looking at what the native gmail app does, and they use actions. theres additional commands associated with each item

flackr: the only stop in gmail is a single entry for the email

flackr: you can swipe up and down with a screen reader to iterate actions

flackr: with that in mind, we are pursuing an approach where an overscroll area would add an implicit action to the container its attached to, and that way screen reader users can access those

flackr: in this case, the container is the email

<dandclark> Kind of like this pattern? https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-actions/

astearns: this would require AT that understands this implicit action?

flackr: its a common thing that is already done for native apps on android, but yes it would require that

flackr: the expectation in these designs is that these are shortcuts to access things

flackr: that you would have other ways of doing

astearns: im wondering if theres a way of designing this such that having a different way to get to the action is enforced

astearns: id rather the design allows for this to be an extra way to get to an action as opposed to relying on authors to ensure there are multiple ways to get to the action

flackr: if a screenreader supports actions then we could support that though the actions

vmpstr: this is an ongoing discussion at openui. originally it was proposed that a button would be mandatory, and of course you could still hide the button. we are slowly moving away from that to say what if we dont need a button and how do we ensure this is still accessible

vmpstr: theres no hard decisions made yet, but thats the stage we're at

flackr: we can easily shift to a model, any solution

lwarlow: when you say actions, is that like the aria actions type thing? where its exposed to AT. in that case its well supported across the board

flackr: yes

lwarlow: that works for screen readers and obviously if youve got an ability to scroll the container then you can

lwarlow: if a touch screen user is using voice control i dont know if it would work

lwarlow: unless voice control exposes the actions

lwarlow: that might be one area where the design needs thinking about

lwarlow: even if its not enforced, guidance to think about this scenario

lwarlow: i think not relying on the button probably makes more sense

lwarlow: because you can still hide it

lwarlow: for the bottom sheet one, the bottom sheet there is that a dialog?

flackr: this isnt overscroll areas. there is an overscroll area at the top that is basically just a dismiss action. all of this is just a regular dialog element

lwarlow: sometimes you have just the handle you can swipe up

flackr: you could make that

keithamus: accessible isnt just the accessibility tree, i want to make sure were making a design that is flexible to many modalities of input, including motor impairment with sticky keys and people who cant use swipe gestures

keithamus: enforcing a button helps with that, even if not everyone is going to make the button visible

keithamus: if we can offer this pit of success where people at least have to think about it

keithamus: im not necessarily saying that one design is good and one is bad

flackr: we did start with button required approach. it was very awkward to create it for the gmail example and its not what gmail actually does

flackr: devrel said that the button is awful

keithamus: i could imagine the pushback, and i would challenge them and wonder whether theres another way to do it. i wonder if their keyboard behavior works to avoid swipe

keithamus: could we enforce a keyboard behavior for it?

keithamus: i understand that adding a bunch of html to do this thing is probably a poor experience

lwarlow: because this is an overscroll area rather than part of a scroll container itself, can you use the arrow keys and keyboard to scroll into it? i would guess no?

flackr: its kind of a what do you think it should do? our intuition was no

lwarlow: for the gmail example, if you focus on the email and press the arrow then it slides across

flackr: pull to refresh was a case where that would be bad

lwarlow: menu that comes in from the side probably doesnt make sense with an arrow key

flackr: this made sense for direct interactions with the page

lwarlow: if you have focusable content within it can you get into it with tab or is it inert when its closed

flackr: we intend to make it inert when closed

lwarlow: i wonder if you could make it a focus group that way

lwarlow: that probably needs more thinking about how keyboard users can get in there

lwarlow: you might have screen readers covered, but touch only or keyboard only might suffer

lwarlow: maybe keyboard needs a way to trigger actions

flackr: we wanted to start prototyping this in html

vmpstr: in the spec

vmpstr: thats the goal, is to have a pr at some point

vmpstr: i dont know if we need to resolve on anything

masonf: can we do whatwg stage 1 here?

<keithamus> https://whatwg.org/stages

cwilso: stage 1 is basically acceptance that theres interest in looking at the problem

astearns: does it require buy in from more than 1 implementor?

astearns: or no objections?

lwarlow: whatwg is interested, doesnt say specific implementors

cwilso: there has to be an explainer and there has to be consensus that whatwg is interested in looking in the problem space, and at least one implementor interested in prototyping

cwilso: doesnt actually mean that the problem is solvable or that this solution is the right one

cwilso: lets have the conversation, doesnt mean that the conversation will lead anywhere

zcorpan: just file an issue in whatwg and then we can bring it up in whatnot

keithamus: the question is whether this is an applicable forum for applying the stage

keithamus: it seems like theres enough of us here to do that

keithamus: im struggling to find a reason not to do that

*long discussion about stages*

everyone agrees to move this to stage 1

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

[selectors][css-position-4] `:modal` pseudo-class needs to account for top layer exit animations

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#13594

none

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

outline and ::picker(select)

<github-bot> OK, I'll post this discussion to whatwg/html#12286

annevk: *gives intro*

<lwarlow> The CSSwg issue for the proposed inset value: w3c/csswg-drafts#13765

lwarlow: i agree, i think that the inset value makes sense and solves the problem quite neatly

lwarlow: i can see that there could be issues in certain cases where the outline might end up clipping hte content of whatever has the outline

lwarlow: for options that wont be an issue because of the padding

lwarlow: if we use it for other things in the future then you can account for tiny bit of padding somewhere

lwarlow: would it compute to the inset keyword?

<lwarlow> Ship it

annevk: yeah. currently in webkit it doesnt because were trying to hide it. if we standardize it then it should compute as a keyword

astearns: there hasnt been any discussion on the css issue yet. the first thing that comes to my mind, if we have this keyword, its now something that authors can use everywhere. is that going to cause any issues?

annevk: its the same as if they took the width value, negated it, and put it on outline-offset. its alreayd possible. its only really novel for auto because for auto you dont know the width

annevk: for chrome youd have to use -0.5px, and for webkit youd have to use -3px

astearns: the keyword would give that to you

annevk: i think overall its a win. you dont have to ua sniff for the negated value for auto

astearns: are we deciding here to endorse this new value for outline offset and use it in this case for appearance base?

flackr: i wanted to ask if we have considered something more radical like not clipping outlines? outlines are already outside of some of the regular box painting

flackr: from a developers perspective, there are many things we can honor to outline things in a scrollable container

annevk: it would probably get a lot more complicated if you wanted to draw outside. youd need a new layer. it would be more expensive and deal with the interaction with the scrollbar

annevk: i definitely thought about it, it would be nice, but doesnt feel very pragmatic

flackr: yeah its already the case that the outline goes on top of other things that you wouldnt paint on top of like ancestor borders

flackr: i dont claim to have a complete idea here, but it seems like the developer friendly thing would be to not reserve space for the outline

annevk: i did find at least one other scenario where outline required a new layer but we didnt use one. if the border has blending, all UAs do something wrong where the blending bleeds into the outline

annevk: that path also has risky perf implications

lwarlow: i dont think theyre mutually exclusive. as a value this makes sense to add

lwarlow: i havent experienced the outline clipping in scroll containers and being really annoyed by it

lwarlow: the behavior seemed inconsistent between browsers

lwarlow: with this value i could get it consistent

lwarlow: if we could solve that separately that would be great but it doesnt need to block this

<lwarlow> Proposed Resolution: Accept outline-offset: inline keyword, it computes to the keyword, and use it on base appearance options.

flackr: yes we can pursue both. this is a nice simple short term fix

<lwarlow> Proposed Resolution: Accept outline-offset: inset keyword, it computes to the keyword, and use it on base appearance options.

<jarhar> +1

RESOLUTION: Accept outline-offset: inset keyword, it computes to the keyword, and use it on base appearance options.

astearns: i suspect that we may talk about this separately in csswg

annevk: this could just apply to option elements without needing to consider base appearance

astearns: trying to think whether there would be any web compat issues

annevk: if people looked at computed style and branched their code

<dbaron> jarhar: [ something about how options aren't focusable except when outside select so this is ok if we just make the selector match only options in a select ]

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

[css-forms-1] Include fieldset and legend

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#11983

lwarlow: this was discussed at csswg f2f, and these elements are going to get base appearance

lwarlow: while prototyping this in chrome i realized that resolution leads to a fairly bad looking fieldset legend because you have no padding and stuff like that

lwarlow: the question is what styles do we actualy want to apply besides the border change

lwarlow: html defines some, and i dont know if they make sense

lwarlow: fieldset has a weird padding block

zcorpan: is the idea to get rid of the special fieldset behavior?

annevk: can you show a picture or something?

zcorpan: still having some padding makes sense

lwarlow: as it is resolved, you dont have any padding at all

lwarlow: depending on your interpretation

lwarlow: the fieldset basically just becomes a border, and right now legend is just a plain child

lwarlow: part of me thinks that the legend might want to be rendered with a bolder font weight like we do for optgroups to signify that this is the legend

lwarlow: and then the padding value is the main thing that we have to think about

annevk: the optgroup legend also has some kind of padding? can we do the same?

<emilio> Sorry, not on the meeting, but legend already doesn't have any magic behavior right?

lwarlow: with optgroup, the options within an optgroup are shifted over

<emilio> I think we should just get rid of the magic fieldset layout

lwarlow: you dont get internal spacing

lwarlow: if you have radio buttons inside your fieldset, there is no default spacing between them

annevk: we dont have to inherit all of that. we just have to create some sort of plain appearnace people can style. if we have a border thing because fieldset which has a border, and the legend is at the top, and the content has the padding then its clear that its below the heading, then thats a clear minimal set of styles

zcorpan: would it be reasonable to get rid of the border and padding as well?

lwarlow: i think border makes sense

masonf: people usually style it to have no border right? if thats the most common thing then maybe that is the right way

lwarlow: ive never really seen this in the wild

zcorpan: appearnace base is an opt in, and we expect pages to have their own styling.

ntim: it should be usable by default.

annevk: i think it might still be ok even as a default

annevk: i think you do want to add the bold on legend to make it heading like

masonf: if you made fieldset legend bold and got rid of the border it would be good

<dbaron> Do we want "font-weight: bold" or "font-weight: bolder". I suspect we want "bolder" but I'm not 100% sure.

astearns: looking at the discussion we had 2 weeks ago, there is an assertion that making a fieldset look like a div makes it useless

astearns: and that adding a border makes it look like other controls

lwarlow: i think that making it a div doesnt make it useless, that was a misunderstanding

lwarlow: some people think that is what fieldset is useful for

lwarlow: it makes all of its contents disabled (excluding descendants of the legend)

lwarlow: theres a11y stuff to it besides just the layout. it laying out like a div is fine

annevk: we could make it more like a paragraph, so consecutive fieldsets arent bunched up. default top bottom margin of 1em

annevk: if youre not going to do a border then we could do that to indicate separation

annevk: i think fairly minimal styling is fine

zcorpan: we dont have margins for form or article or section

annevk: most of those are standalone, or they would have their own block level descendants, which in fieldset is not the case

masonf: you could put it on legend

astearns: i dont think were coming to consensus on what to do here. i think it would be good to get images of different options so that we have concrete things to choose between here. luke can you do that?

lwarlow: yes

annevk: we could do a social media poll

astearns: the csswg allows polls in their github discussions

annevk: then we can invite people, sure

end