[css-forms-1] continue to refine principles for appearance:base controls

[dbaron]

In #10866 we defined design principles for appearance:base form controls. I think the initial list of principles seem reasonable, but I think they need more testing -- we need to work through some example cases where the different principles come into conflict and see if we agree with the result we get based on how those principles are prioritized in the spec.

I'm in the process of writing up a presentation on an example (the min-inline-size and min-block-size declarations for <button>) that I think could prompt a useful discussion. I'm hoping to be able to present this at our face-to-face next week. I'll try to share more once I have it written, but I wanted to get this issue filed sooner rather than later for the purpose of planning the agenda for next week's face-to-face.

[dbaron]

Here's a (draft) linear form of what I hope to present. I'll probably break it into slides at the last minute, but I like the linear form for editing/reading until then.

[css-meeting-bot]

The CSS Working Group just discussed [css-forms-1] continue to refine principles for appearance:base controls, and agreed to the following:

• RESOLVED: Say "approximate order" for the principles
• RESOLVED: Specify that 'base' styles can't lean on the "UA Styles" exception in WCAG criteria, they're treated as author styles for this purpose

The full IRC log of that discussion

<TabAtkins> dbaron: i want to talk thru a single reasonable small example of one case where a bunch of these principles interact with each other
<TabAtkins> dbaron: i didn't quite agree with what the principles were telling me to do
<TabAtkins> dbaron: i expect others might have the same feeling, but want to check
<TabAtkins> dbaron: i also think the example is interesting on its own. Ian pointed it out to me.
<TabAtkins> dbaron: the current spec has this list of design principles for base appearance
<TabAtkins> dbaron: I think Jen made them?
<TabAtkins> jensimmons: we collaborated inside Apple
<TabAtkins> dbaron: one realtively simple example is a button element
<TabAtkins> dbaron: here's three pieces of markup. if there's no styles on the button, you get these appearances
<TabAtkins> dbaron: principle 3 says they shoudl pass 100% of wcag criteria
<TabAtkins> dbaron: looking at wcag, they say the size of a pointer input is at least 24x24 pixels
<TabAtkins> dbaron: these buttons are not all that size
<TabAtkins> dbaron: so that's a problem
<TabAtkins> dbaron: i propose a small change on this - the wcag text has an explicit exception for if the control came from the UA
<TabAtkins> dbaron: i think principle 3 should not allow us to use these UA exceptions
<TabAtkins> dbaron: in other words, we should be meeting the WCAG criteria as if we were author styles
<TabAtkins> dbaron: so what if we give the button some min sizes
<TabAtkins> dbaron: this is what's in the stylesheet today
<TabAtkins> dbaron: can get a min size in both axises
<TabAtkins> dbaron: this seems to fix our wcag problem
<TabAtkins> dbaron: back to the principles
<TabAtkins> dbaron: we're now doing some things specific to certain controls and not others, so that's not great consistency
<TabAtkins> dbaron: another princpile is resilient to being placed in other contexts, like put into a grid/flex
<TabAtkins> dbaron: so say we have a flex container, with a button child and some other bigger stuff
<TabAtkins> dbaron: we have thise min-size styles....
<TabAtkins> dbaron: before we added the min-size styles this did more or less what we wanted
<TabAtkins> dbaron: but now that we have min-size we get overlap. it overrides min-size:auto
<TabAtkins> dbaron: but we didn't really want to do that, it's important for flex/grid
<TabAtkins> dbaron: a fundamental issue, and i think it'll come up multiple times, is we want to build a thing where it gets an intrinsic size from several sources
<TabAtkins> dbaron: we want it at least this big, and also at least this big, and also at least this big, and one of those is the intrinsic size
<TabAtkins> dbaron: can we do better?
<TabAtkins> dbaron: we can do terrible things
<TabAtkins> dbaron: [hacky grid description]
<TabAtkins> dbaron: but that's a complete disaster per the principles
<TabAtkins> dbaron: hugely complicated, devs would have to understand it all to override it
<TabAtkins> dbaron: i think we can do better
<TabAtkins> dbaron: slightly better solution to fix this problem is to use calc-size()
<TabAtkins> min-block-size: calc-size(auto, max(24px, 1lh, size))
<TabAtkins> dbaron: a bit better, it works in flex, it satisfies wcag, it's a single declaration that can be easily overridden
<TabAtkins> dbaron: but it's still not great, pretty complicated expression in this default stylesheet
<TabAtkins> dbaron: if the dev wants to replace a piece they have to look it up and figure out how to tweak it
<TabAtkins> dbaron: so i think this is *better* for the principles, not *great* on easy to override but better than hacky grid solution
<TabAtkins> dbaron: does this count as consistent across controls? maybe, depends on what we do for other controls
<TabAtkins> dbaron: my feeling is this is the least bad thing so far
<astearns> q+
<jensimmons> q+
<TabAtkins> dbaron: other than the thing i said earlier about the wcag rule, one other thing i felt about applying these rules to this case, rule 5.4 was more important than many other options. list implies it's less important to 4.2, which bothers me. the other parts of 4 and 5 are probably fine, but these two particular rules bother me.
<TabAtkins> astearns: yeah, this is exactly waht the princpiles are for, to encourage this analysis
<TabAtkins> astearns: whether we adjust the ordering, this is cool, thank you
<TabAtkins> astearns: probably are gonna be some exceptions, justification for something moving up in some cases but not necessarily for all
<TabAtkins> astearns: that said i'm not against reordering
<astearns> ack astearns
<astearns> ack jensimmons
<TabAtkins> jensimmons: i agree
<TabAtkins> jensimmons: interesting that the title of the issue is "continue to refine", makes me think the question at hand is change the principles. but i think this is the whole point of the principles, they're not marching orders, they're a framework to have discussions quickly
<TabAtkins> jensimmons: and i think you're right, they do contradict sometimes, and i want to have a godo discussion about buttons, and other things
<TabAtkins> jensimmons: i didn't write these myself, we've discussed with tim, elika, anne, the dto, etc
<TabAtkins> jensimmons: we did not keep the convo in the oven to continue to bake to the point where the default ua styles are at all done
<TabAtkins> jensimmons: we pulled those out as early as we felt like we could
<TabAtkins> jensimmons: i think they're deceptively simple, like "oh we just need to decide on rounded corner, colors" and it's easy
<TabAtkins> jensimmons: but yeah, it's not
<TabAtkins> jensimmons: one advantage of appearance:auto form controls is that, regardless fo brwoser, if the page does nothing for them, the controls work.
<TabAtkins> jensimmons: and the default appearance:base controls don't work
<TabAtkins> jensimmons: so i agree there's a lot of room to grow
<ntim> q+
<astearns> ack fantasai
<TabAtkins> fantasai: i think we maybe want to add the word "approximate" as in "approximate order of descending imporantace". this isn't meant to be strict 3 always wins over 4. like usual, balancing act about how much you're violating one vs the other, etc
<TabAtkins> fantasai: i don't midn too much if we flip 4 vs 5, don't think there a strong ordering between those two
<astearns> ack ntim
<jensimmons> I should also say I don't think bikeshedding the design principles for a long time is a good use of time. We should work on the styles, and hold the design principles loosely.
<TabAtkins> +1
<fantasai> +1
<jensimmons> q+
<TabAtkins> ntim: the ua styles defined in the spec very much need refining
<iank_> q+
<TabAtkins> ntim: about the specific examples, min-size, i think that came from a PR from Joey that was applied to select
<TabAtkins> ntim: so I just took it and applied it to the spec
<fantasai> s/the spec/butotn
<fantasai> s/butotn/button/
<TabAtkins> ntim: so yeah, i'm curious to have more discussion about styles
<astearns> ack jensimmons
<TabAtkins> jensimmons: [saying what she typed in IRC]
<TabAtkins> jensimmons: we're all busy, we can probably largely skip over this and just work ont he controls, and change the principles later
<TabAtkins> jensimmons: as long as they're not blocking us
<TabAtkins> dbaron: i think that idea is fine. particularly if we take elika's suggested edit for "approximate order"
<astearns> ack iank_
<TabAtkins> dbaron: and i do intend to give more feedback on the stylesheet, that'll happen over time
<TabAtkins> iank_: one high-level thing, in this stylesheet we shoudl be very careful when changing the size proeprties to a fixed size
<TabAtkins> iank_: even a radio or checkbox with width:1ch, that has sublte effects in grid/flexbox related to stretching
<TabAtkins> iank_: so keep auto as much as possible
<ntim> q+
<TabAtkins> iank_: I think the calc-size() solution is pretty good
<astearns> ack ntim
<TabAtkins> ntim: so it sounds like next steps is to start prototyping the ua styles, and to add the word approximate
<dbaron> Proposed resolution #1: spec that order of principles is approximate
<TabAtkins> astearns: so suggesting no particular resolution just yet? or is there something in this analysis you'd like to adopt currently?
<dbaron> Proposed resolution #2: say that principle about WCAG AA standards can't use "UA styles" exceptions
<TabAtkins> ntim: i think we shoudl adopt "approximate" to the princple wording
<TabAtkins> astearns: david gives some proposed reoslutions
<TabAtkins> astearns: proposed resolution 1, objections?
<dbaron> Proposed resolution #3 (maybe more controversial): Adopt the calc-size() expression for the stylesheet.
<TabAtkins> RESOLVED: Say "approximate order" for the principles
<TabAtkins> astearns: proposed resolution 2, objections?
<TabAtkins> RESOLVED: Specify that 'base' styles can't lean on the "UA Styles" exception in WCAG criteria, they're treated as author styles for this purpose
<fantasai> Edited first resolution in https://github.com/w3c/csswg-drafts/commit/455c7774eb357f4e5a942ec22559a02f8798edc5
<TabAtkins> ntim: for proposal 3, i think we need to prototype and get some feedback first
<TabAtkins> ntim: not against it, just want to try it out first
<astearns> ack fantasai
<TabAtkins> fantasai: i just want to reraise Ian's point that it might make sense to just lean on 'auto' as much as possible, because it give sus the best default sizing behavior in a variety of contexts
<TabAtkins> fantasai: it might not always be the most ideal for every case, but it'll often get us good results in common cases
<fantasai> fantasai: and it won't break things
<TabAtkins> TabAtkins: tho use of calc-size() gives us the auto behavior *and* lets us still tweak things
<TabAtkins> dbaron: one brief example of something it might break
<TabAtkins> dbaron: this style in the UA sheet is for select and button
<TabAtkins> dbaron: if you have an empty option in select, which might not be uncommon in select as the default option
<TabAtkins> dbaron: but right now, without those minimums, the empty option will shrink the width *and* the height, and that's kinda weird
<TabAtkins> ntim: so you want to apply this to select as well? we could resolve it now if needed
<TabAtkins> dbaron: i think the calc-size() would be an improvement on the current design, yes. but we don't need to resolve on it right yet.
<TabAtkins> astearns: for time, we won't resolve on this right now. we need to break
<TabAtkins> ntim: could dbaron file an issue for fixing the select behavior?
<TabAtkins> dbaron: yes