Incremental rollout plan for form controls #10804
Comments
This is just while we're in the intermediate phase, right? Once we've finished all the existing controls and can make plain |
Great point - yes. After |
|
The CSS Working Group just discussed The full IRC log of that discussion<jarhar> masonf: i went through all of the form controls and some other things and detailed what ive heard from openui about whats needed<jarhar> masonf: its a list of controls that i hope we consider in scope for appearance base <jarhar> masonf: it also has thoughts about how to ship it, but we can punt that to later <jarhar> masonf: if there are comments, id love to hear them <lwarlow> q+ <astearns> ack lwarlow <astearns> q+ <jarhar> lwarlow: it mentions that button might be good as is. there are still situations where styling them can be a bit of a pain. ios safari might need to reset some properties to be able to style it <jarhar> lwarlow: i dont think that if you apply padding to it that it works out of the box <jarhar> lwarlow: also stuff around text selection that differs, which would be good to formalize in base appearance <jarhar> masonf: im familiar with text selection stuff. i dont know about the issue you brought up first, but both of them sound like interop issues <jarhar> masonf: when i say good as is i mean that theres not necessarily anything to opt in to with appearance base <jarhar> t1m: for buttons, i think that for appearance base we will want to use the same styling as select. inerhit all the properties and use currentcolor and all that stuff <jarhar> masonf: the one value that would provide is that people dont have to do resets <jarhar> masonf: the good as is list means that you can reset it and make it stylable <jarhar> astearns: what about elements not in this issue? are they absolutely not relevant? or is there a subset that you're pretty sure aren't relevant but you'd like confirmation? <jarhar> masonf: i tried to be complete as i could. i did not include details summary, which maybe is on the border of relevant <jarhar> masonf: we should have as inclusive a list as possible <jarhar> masonf: dont want to leave something out. please comment to add stuff <jarhar> astearns: would be good to add a comment saying that <jarhar> t1m: i mentioned earlier that composability is not part of css forms 1. the pseudo elements that im planning to introduce are cover a lot of use cases you mentioned. input type number with a set of pseudos you can do a plus one and minus ui <jarhar> t1m: by messing with the ordering and display contents and the pseudo elements <jarhar> t1m: i can add more about the depths of customization you can get to in the spec <jarhar> t1m: the current set of pseudos can get you really far without needing to replace all the content thats in the control <jarhar> t1m: once i get the spec out there we can discuss which ones still need composability <jarhar> lwarlow: make a comment with all the other html elements that exist, that would answer the question, would also help us find things that we misses <jarhar> *missed <jarhar> masonf: ill have to consider whether deprecated elements like <blink> are included |
|
As discussed in the meeting, I feel that the lists I included in the OP are "complete". Hopefully we shouldn't have to do anything "appearance-base-like" for any other HTML elements. But please point out omissions! If there's another control I've neglected, please comment, and I'll add it above. To help with that, here is a semi-complete list of all HTML elements, not including deprecated/obsolete ones (e.g. List of HTML elements
|
{This posting is the result of a request made at this meeting for some clarity on Google's view about how to roll out form control stylability.}
TL;DR
We want to tackle not only stylability of form controls, but interoperability and composability. We believe this is a rather large engineering task, and we therefore want the ability to ship these improvements incrementally rather than all at once. We propose continuing to use
appearance:base-controlnameas a mechanism to allow that incremental shipment, until we get to the point where "the rest" of the controls can all be shipped withappearance:base.Overview
Form (UI) controls have been a part of the web since the early days. While the form-associated controls provide a good basic set of UI controls for page design, many “table stakes” UI controls still require significant effort to build, often from scratch, such as select menus, tab controls, carousels, etc. In addition to those “large” components, just basic controls such as checkboxes, radio buttons, and range sliders still require outsized time investments from developers in order to make them work in production.
In terms of the existing set of HTML form control elements, there are two related but separate sets of problems:
<input type=checkbox>, interoperably, developers have to delete all of the native styles viaappearance:none, and then recreate the control from “scratch”, including recreating things like the checkmark glyph. As another more extreme example, see this 7000+ word blog post on how to interoperably style a range slider. Note that often (e.g. for range sliders), enabling stylability requires more than just a standardized UA stylesheet: it also requires standardization of the layout box structure of the control.<select>work has been the ability for<option>elements to contain arbitrary content, rather than just plain text. This same missing capability applies to a number of other form controls, such as the in-page portion of an<input type=date>, or<textarea>.What do “stylability", "interoperability”, and "composability" mean?
We believe “stylability” means that the UI element should respond to all relevant CSS properties, such as width/height, borders, colors, animations, directionality, fonts, grid/flex properties, etc. Basically anything that can be styled on a
<div>should also be stylable on UI controls. Also potentially included in “stylability” is the ability to style related bits of UI that come with controls, such as form validation error messages and autofill preview/filled content.“Interoperability” means that the UA stylesheet and the content model for the control should both be provided as part of the html spec. This ensures that developer CSS will be applied to the control in the same way across browsers, leading to identical rendering. This also provides a mechanism to test the appearance of controls via WPT reference tests.
“Composability” is the ability to insert other HTML elements into UI controls. For example, it should be possible for a developer to use their own
<my-button>custom element as the spin-buttons of an<input type=number>.The Ideal Approach
We’ve reached a consensus that to achieve the goals of stylability, composability, and interoperability, we will add a CSS-based “opt-in” mechanism:
appearance:base. Once the entire effort is complete, the desired end-state is that a single line of CSS can be used to opt all form controls (not including pickers) into the new customizable/interoperable mode:This must be the end-state only, and not the starting state, because once a single control has been shipped that supports
appearance:base, there’s a high risk that developers will simply add*{appearance:base}to their stylesheets, and will subsequently be surprised (in a bad way) when additional controls begin to support this mode. For this reason, we can only supportappearance:basewhen the work is “done” for all controls. If there are incremental shipments prior to that point, they will need to use a named appearance value, such asappearance: base-select.Note that since we’re close to agreement on #10440, the “pickers” for form controls will have their own opt-in mechanism, via
::picker(control) {appearance: base-control}. So it will be possible to ship the universalappearance:basevalue when the in-page parts of all controls are done, but potentially before all pickers are done. This is good because pickers are complicated.Engineering Time
Adding stylability, composability, and interoperability to all form controls is a very large task. We’ve found that even controls that seem like they’ll be easy to improve turn out to take a very long time, particularly for things that require spec changes in multiple standards bodies. For example, we’ve spent >5 years working on the
<select>, and >1 year working on<details>/<summary>. Of course, we are quite hopeful that the establishment of the WHATWG/CSSWG/OpenUI task force will speed up these timelines. It already has! But we want to make sure we’re not underestimating the size of the job ahead.For that reason, we are therefore afraid of committing to wait for all controls to be included in this effort before we’re able to ship any of them. We’d much prefer to have the flexibility to ship improvements to the web platform incrementally, rather than having to wait years (or more) for the entire package to be completed.
Detailed list of UI Controls
One point of contention about the overall plan is likely to be the “years” estimate. Since it’s very hard to generalize a strategy that uses terms like “all of the form controls” without actually looking a bit in detail at the list, I’ve compiled a list. This should contain all form-associated controls, plus others (e.g. meter and progress) that are just UI controls. I’ve included some notes about what might be missing for each, and tried to categorize the work required. Note that this is purely to get the conversation started; many of my comments are just quick thoughts. So please don’t take the specifics for each control as part of the explicit plan, but more of a helpful sketch of why their UI aspects are likely not simple to standardize. I also included links to pre-existing conversations in WHATWG, OpenUI, or elsewhere, as available.
Pickers
<select><input type="date|time|etc">datalistinto account.<input type="color">datalistinto account.<input type="file"><input type=”text” list=datalist>(see OpenUI)listattribute, but those are separate concerns. This item is about allowing custom/arbitrary<options>content within the<datalist>which gets displayed in the text suggestion picker, plus the ability to provide replacement/decoration of the picker itself (similar to the<select>picker).Need stylability/interoperability, plus potentially composability
<select>(in-page component, see above. spec PR. Will eventually also include an in-page picker for<select size=2>)<input type="date|time|etc">(in-page component)<input type="file">(in-page component)<selectedoption>?<input type="checkbox">(OpenUI)<input type="radio">(OpenUI)<input type="range">(OpenUI)<meter><progress><input type="checkbox" switch>(see WHATWG and OpenUI)<input type="number"><textarea>Likely “just” stylability/interoperability (no custom content) needed
<input type="text"><input type="email"><input type="tel"><input type="url"><input type="image"><input type="button|reset|submit"><input type="color">(in-page component, might need to work with picker)<input type="search">(there is a “clear” button - how to style it?)<input type="password">(a “reveal” button is common, see Chromium bug)Likely mostly good as-is?
<button><output><object><fieldset> **and** <legend><img><details>/<summary>Proposed Approach For In-Page Controls
We’d prefer a phased approach:
appearance: base-controlnameso that they can be incrementally shipped to the platform beforeappearance:baseis available for all controls.appearance:base. At the same time, connectappearance:basetoappearance:base-controlso that the already-shipped controls can be enabled more easily. Deprecate thebase-controlvalues forappearance.* Everywhere I use the term “ship”, I mean “to the web platform”. That includes landing the changes in standards, and beginning to enable the behavior in browsers.
Future New Controls
One important question is how to handle “new” controls that don’t already exist on the platform. Such a new control doesn’t immediately have the backwards-compatibility problem that requires
appearance: base-newcontrol, but it does still risk the general forward-compat problem of developers using*{appearance:base}. For that reason, it seems necessary to also require such a new control to get opted in to “base” mode viaappearance:base-newcontrol.The text was updated successfully, but these errors were encountered: