[css-ui-4] Add warning about appearance

Author: frivoal

css-ui-4/Overview.bs

@@ -2213,6 +2213,81 @@ so this specification allows flexibility.
 
 <h3 id="appearance-switching" caniuse="css-appearance">Switching appearance</h3>
 
+<div class=issue>
+	<strong>This is not ready for shipping</strong> (see <a href="https://github.com/w3c/csswg-drafts/issues/1250">Github issue 1250</a>).
+
+	This previously existed as a prefixed form in most browsers.
+	Before standardization, in addition to none,
+	the possible values were a very long list of all the ways an element could look;
+	this list was different across browsers.
+
+	We concluded this was impossible to standardize,
+	in part because many apply to pseudo-elements that other browsers don't have,
+	as they construct form elements differently.
+
+	Instead, we'd just have an "auto" value that makes form controls look like whatever they need,
+	and a "none" value that suppresses "native" look.
+
+	However, there is evidence that this may not be web compatible,
+	due in part to uses such as:
+	<pre><code highlight=css>
+	input { appearance: none; }
+	input[type=checkbox] { appearance: checkbox; }
+	</code></pre>
+
+	Such code is sometimes limited to the vendor-prefixed variant of this property,
+	but not always,
+	as authors often include the prefixless version for the sake of future proofing
+
+	Due to substantially different behavior,
+	naïve aliasing of 'appearance' and of ''-webkit-appearance'' is unlikely to work.
+
+	Possible ways forward include:
+
+	<ol>
+		<li>Keep the design as is, if the compatibility problem is not that serious
+
+		<li>Keep the current design,
+		and add a handful of values other than ''appearance/none'' and ''appearance/auto''.
+		The design of this property does not preclude having other values.
+		As long as we have the ''appearance/auto'' value,
+		there is no need to be exhaustive.
+
+		<li>Keep the current design,
+		but also accept other values (possibly white-listed, possibly accept anything)
+		and let them behave the same as ''appearance/auto''.
+		As demonstrated in the example above,
+		common uses of values other than ''appearance/none'' and ''appearance/auto''
+		are not to switch an element's appearance into something else,
+		nor to give a native look to something that didn't have one,
+		but merely to undo a previously applied ''appearance/none''.
+		Since ''appearance/auto'' did not exist in the non standard version,
+		authors have been using specific values for this purpose,
+		but the behavior of ''appearance/auto'' would be sufficient.
+
+		<li>Combine the previous two options,
+		adding a handful of explicit values with specific behaviors,
+		and also accept any other value letting them behave the same as ''appearance/auto''.
+
+		<li>Abandon the current design,
+		and specify instead the behavior of ''-webkit-appearance'',
+		without an ''appearance/auto'' value and with all the permutations instead.
+		This probably requires specifying a few pseudo-elements as well,
+		as various values of the ''-webkit-appearance'' property
+		are used to style sub-components of form controls.
+	</ol>
+
+	Based on Microsoft's experience, it seems that the 3rd option in this list may be sufficient.
+	This would be fairly cheap in terms of specification and implementation effort.
+
+	Option 2 is somewhat more costly but reasonably so,
+	while option 5 is significantly more costly.
+
+	More feedback from implementors is needed
+	about the extent and nature of the compatibility problem,
+	and about which option may adequately address it.
+</div>
+
 While the way most elements in a document look can be fully controlled by CSS,
 form controls are typically rendered by UAs using native UI controls of the host operating system,
 which can neither be replicated nor styled using CSS.