Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Dec 17, 2019
Merged

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

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
bba7bab
[css-ui] Define `control` #3990
jugglinmike May 30, 2019
78c8282
Define 'native appearance' for host language specs to hook into, and …
zcorpan Aug 15, 2019
e8173f1
Merge branch 'master' into define-control
frivoal Dec 17, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 26 additions & 23 deletions css-ui-4/Overview.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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>

Expand All @@ -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>
Expand All @@ -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:
Expand All @@ -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>
Expand Down Expand Up @@ -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>

Expand Down Expand Up @@ -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,
Expand Down Expand Up @@ -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>
Expand All @@ -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.
Expand All @@ -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,
Expand All @@ -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>
Expand Down