[css-ui-4] Remove appearance:button

Author: frivoal

css-ui-4/Overview.bs

@@ -593,13 +593,13 @@ which can neither be replicated nor styled using CSS.
 
 This specification introduces the 'appearance' property
 to provide some control over this behavior.
-In particular, using ''appearance: none'' allows authors
+Using ''appearance: none'' allows authors
 to suppress the native style of form controls,
 so that CSS can be used to fully restyle them.
 
 <pre class="propdef">
 Name: appearance
-Value: ''auto'' | ''none'' | ''button''
+Value: ''auto'' | ''none''
 Initial: auto
 Applies To: all elements
 Inherited: no
@@ -609,8 +609,8 @@ Media: all
 
 Issue: Should ''appearance/auto'' compute to ''appearance/none'' on regular elements?
 I would say no:
-to be consistent, we should then have ''appearance/auto'' compute to ''button'' on buttons, etc.
 If we did that,
+to be consistent,
 every time we introduced a new value,
 we would change what ''appearance/auto'' computes to on some elements,
 which doesn't sounds desirable.
@@ -626,17 +626,15 @@ sometimes used to implement form controls.
 Moreover, many values of such an enumeration only make sense
 on a single element or pseudo-element,
 and are never used outside of the UA stylesheet.
-Instead, this specification will only provide
-''appearance/auto'', ''appearance/none'', and
-values which are useful in an author or user stylesheet
-and for which interoperability can be achieved.
+Instead, this specification only provides
+''appearance/auto'', ''appearance/none''.
 UAs cannot therefore use the 'appearance' property
 in the UA stylesheet to give each control is native look and feel,
 and must use ''appearance:auto'' instead.
 
-Issue: IE supports -webkit-appearance, and also includes the textfield value.
+Issue: IE supports -webkit-appearance, and also includes the textfield and button values.
 Presumably this was done due to compatibility problems,
-so we may want to include it as well.
+so we may need to include it as well.
 
 <dl dfn-type=value dfn-for=appearance>
 	<dt><dfn>auto</dfn>
@@ -653,18 +651,9 @@ so we may want to include it as well.
 
 	Issue: Shouldn't this be called "normal" instead?
 	''appearance/none'' makes it sound like the targeted element will disappear.
-	<dt><dfn>button</dfn>
-	<dd>The element is rendered with the look and feel of a push button,
-	similar to the rendering of the HTML <{button}> element.
-
-	Issue: There are strong concerns as to whether this property should have any value
-	other than ''appearance/auto'' and  ''appearance/none''.
-	The ''appearance/button'' value may be necessary due to backward compatibility concerns,
-	but if it is not, there is a strong possibility that it will be dropped.
 </dl>
 
 On form control elements where the computed value is ''appearance/auto''
-and on other elements where the computed value is neither ''appearance/auto'' nor ''appearance/none'',
 UAs may disregard some CSS properties
 to ensure that the intended appearance is preserved,
 or because these property may not be meaningful for the chosen appearance.
@@ -744,11 +733,10 @@ For example, regardless of the computed value of 'appearance':
 	(although it may look different).
 	<li>Event handlers attached to the element trigger as usual.
 </ul>
+
 Conversely, changing the appearance of an element must not cause it
-to acquire the semantics, pseudo classes, event handlers, etc
-that are typical of the element whose appearance it acquires.
-For example, neither '':enabled'' nor '':disabled'' match on
-a <{div}> styled with ''appearance: button''.
+to acquire new semantics, pseudo classes, event handlers, etc
+that it did not initially have.
 The ability for an element to be focused
 is also not changed by the 'appearance' property.