[css-ui] Define "native appearance" and rename control to widget (#3991)

Define 'native appearance' for host language specs to hook into, and rename 'control' to 'widget'.

Closes #3990

Author: jugglinmike

css-ui-4/Overview.bs

@@ -1745,7 +1745,7 @@ without adverse consequences to compatibility,
 so this specification allows flexibility.
 
 
-<h2 id="control-styling" oldids="form-styling">Control Styling</h2>
+<h2 id="styling-widgets" oldids="form-styling control-styling">Styling Widgets</h2>
 
 <h3 id="appearance-switching" caniuse="css-appearance">Switching appearance</h3>
 
@@ -1760,13 +1760,18 @@ Animation type: discrete
 </pre>
 
 While the way most elements in a document look can be fully controlled by CSS,
-controls are typically rendered by UAs using native UI controls of the host operating system,
+<a>widgets</a> are typically rendered by UAs using native UI controls of the host operating system,
 which can neither be replicated nor styled using CSS.
 
+The term <dfn export>widget</dfn> in this specification denotes elements that can have <dfn export>native appearance</dfn>,
+meaning that they are rendered like analogous native widgets or controls of the host operating system or platform,
+or with a look and feel not otherwise expressible in CSS.
+It is up to the host language (e.g., HTML [[HTML]]) to define which elements can have <a>native appearance</a>.
+
 This specification introduces the 'appearance' property
 to provide some control over this behavior.
 In particular, using ''appearance: none'' allows authors
-to suppress the native style of controls,
+to suppress the <a>native appearance</a> of <a>widgets</a>,
 so that CSS can be used to restyle them.
 
 <details class=note>
@@ -1782,16 +1787,16 @@ so that CSS can be used to restyle them.
 	in part because many values applied to pseudo-elements that other browsers don't have,
 	as they construct form elements differently,
 	and which should not be standardized,
-	since the ability to make for controls look substantially different on different platforms
+	since the ability to make form controls look substantially different on different platforms
 	should be preserved.
 
-	Also, because the ability to turn any arbitrary element (including any form control)
+	Also, the ability to turn any arbitrary element (including any form control)
 	into any (other) arbitrary form control
 	is considered a misfeature.
 
 	Instead, the design being specified
 	is based on just having an "auto" value that makes form controls look like whatever they need,
-	and a "none" value that suppresses "native" look.
+	and a "none" value that suppresses [=native appearance=].
 
 	However, there is evidence that this alone is not web compatible,
 	due in part to uses such as:
@@ -1816,17 +1821,16 @@ so that CSS can be used to restyle them.
 	<dt><dfn>none</dfn>
 	<dd>
 		The element is rendered following the usual rules of CSS.
-		Replaced elements other than controls are not affected by this,
+		Replaced elements other than <a>widgets</a> are not affected by this,
 		and remain replaced elements.
-		Controls are <em>not</em> made to look like native controls of the host operating system.
+		<a>Widgets</a> must not have their <a>native appearance</a>.
 		See [[#appearance-decorative]] and [[#appearance-semantics]] for details.
 
 	<dt><dfn>auto</dfn>
 	<dd>
-		UAs may render controls using native controls of the host operating system
-		or with a look and feel not otherwise expressible in CSS.
+		<a>Widgets</a> may have their <a>native appearance</a>.
 
-		Elements other than controls must be rendered as if ''appearance/none'' had been specified.
+		Elements other than <a>widgets</a> must be rendered as if ''appearance/none'' had been specified.
 
 	<dt><dfn>button</dfn>
 	<dd>
@@ -1875,8 +1879,7 @@ so that CSS can be used to restyle them.
 		some of these values need to be promoted to being full blown values
 		with effects on arbitrary elements like ''button'',
 		or that
-		some of these values need to have some side effects on some controls.
-
+		some of these values need to have some side effects on some <a>widgets</a>.
 
 </dl>
 
@@ -1906,7 +1909,7 @@ so that CSS can be used to restyle them.
 	and activating (for example by clicking) the element would toggle the state as usual.
 </div>
 
-On controls where the computed value is ''appearance/auto'' or one of the <<compat-auto>> values,
+On <a>widgets</a> where the computed value is ''appearance/auto'' or one of the <<compat-auto>> values,
 and on any element where the computed value is ''appearance/button'',
 UAs may disregard some CSS properties
 to ensure that the intended appearance is preserved,
@@ -1935,7 +1938,7 @@ Issue: Are there more properties should include in this list?
 Should we remove some?
 Should whitelist the properties that are ok to ignore instead of
 blacklisting those that are not?
-Either way, UAs do ignore some properties when rendering controls,
+Either way, UAs do ignore some properties when rendering <a>widgets</a>,
 so this specification needs to say something about this.
 
 For compatibility with legacy content, UAs must also support <dfn property export>-webkit-appearance</dfn>
@@ -1944,7 +1947,7 @@ as a [=legacy name alias=] of 'appearance'.
 <h4 id=appearance-decorative>
 Effects of 'appearance' on Decorative Aspects of Elements</h4>
 
-All decorative visual aspects of a control which are not caused by a CSS style rule
+All decorative visual aspects of a <a>widget</a> which are not caused by a CSS style rule
 must be suppressed when the appearance is changed using 'appearance',
 even if the UA's internal representation for this element
 was composed of multiple elements or pseudo elements combined together.
@@ -1957,14 +1960,14 @@ was composed of multiple elements or pseudo elements combined together.
 </div>
 
 UAs should include in their User Agent stylesheet style rules
-to give controls a recognizable shape when 'appearance' is ''appearance/none''.
+to give <a>widgets</a> a recognizable shape when 'appearance' is ''appearance/none''.
 
 Note: Authors may therefore need to override these UA style rules to get the styling
 they intended.
 
 <div class=advisement>
 	Authors may find it convenient to use ''all: unset'',
-	to get fully unstyled controls
+	to get fully unstyled <a>widgets</a>
 	which they can then style as they want without interference from the browser's UA stylesheet.
 	However, this also suppresses the focus indicators provided by the same UA stylesheet.
 	In order avoid damaging accessibility,
@@ -1975,16 +1978,16 @@ they intended.
 <h4 id=appearance-semantics>
 Effects of 'appearance' on Semantic Aspects of Elements</h4>
 
-UAs must preserve aspects of the control
-which are necessary to operate the control with its original semantics.
+UAs must preserve aspects of the <a>widget</a>
+which are necessary to operate the <a>widget</a> with its original semantics.
 The UA may however give them a different look and feel
-as long as it remains possible to operate the control.
-Aspects of a control which are merely needed to observe the state the control is in
+as long as it remains possible to operate the <a>widget</a>.
+Aspects of a <a>widget</a> which are merely needed to observe the state the <a>widget</a> is in
 and are not needed to operate it
 should be suppressed as well
 when the same information can be conveyed using ordinary CSS.
 Document languages should specify
-for each control that they define
+for each <a>widget</a> that they define
 what needs to be preserved.
 
 <div class=example>