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
frivoal merged 3 commits into from
Dec 17, 2019
Merged

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

Changes from 1 commit
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
35 changes: 19 additions & 16 deletions css-ui-4/Overview.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1785,13 +1785,16 @@ so this specification allows flexibility.
</div>

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>controls</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>control</dfn> denotes the following [[HTML]] elements:
Copy link
Copy Markdown
Contributor

@bkardell bkardell May 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it good to be quite this specific? What if things change? Are there disagreements even on some in terms of support? Could you say instead "Examples of controls in HTML are: ....."

Copy link
Copy Markdown
Contributor Author

@jugglinmike jugglinmike May 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This definition, like the spec itself, is meant to be canonical. Ideally, if things change, they'd start by changing here. Even if we find ourselves updating the definition reactively, it seems to me that completeness is a goal of the standard. From that perspective, suggesting a partial list is less helpful than defining a complete set.

Copy link
Copy Markdown
Contributor

@bkardell bkardell May 30, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is <summary>/<details> not a control then?

Copy link
Copy Markdown
Contributor Author

@jugglinmike jugglinmike May 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question! I'll defer to the editor on that.

Copy link
Copy Markdown
Collaborator

@frivoal frivoal May 31, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking that maintaining this in a css spec is the wrong place. Tracking how the HTML spec changes will never be perfectly synchronized. Ideally, we'd just refer to a term defined in the HTML spec, and they'd update it when they add new elements. However, there doesn't seem to be one already.

Copy link
Copy Markdown
Collaborator

@SelenIT SelenIT Jun 4, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, we'd just refer to a term defined in the HTML spec

Doesn't the existing term widget satisfy this criteria? BTW, it already includes <details>.

<{button}>, <{input}>, <{meter}>, <{progress}>, <{select}>, and <{textarea}>.

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 native style of <a>controls</a>,
so that CSS can be used to restyle them.

<pre class="propdef">
Expand Down Expand Up @@ -1827,17 +1830,17 @@ Animation type: discrete
<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>controls</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.
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
UAs may render <a>controls</a> using native controls of the host operating system
or with a look and feel not otherwise expressible in CSS.

Elements other than controls must be rendered as if ''appearance/none'' had been specified.
Elements other than <a>controls</a> must be rendered as if ''appearance/none'' had been specified.

<dt><dfn>button</dfn>
<dd>
Expand Down Expand Up @@ -1886,7 +1889,7 @@ Animation type: discrete
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>controls</a>.


</dl>
Expand Down Expand Up @@ -1917,7 +1920,7 @@ Animation type: discrete
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>> values,
On <a>controls</a> where the computed value is ''appearance/auto'' or one of the <<compat>> 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 @@ -1946,7 +1949,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>controls</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 @@ -1955,7 +1958,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>control</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 @@ -1968,14 +1971,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>controls</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>controls</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 @@ -1986,16 +1989,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>control</a>
which are necessary to operate the <a>control</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>control</a>.
Aspects of a <a>control</a> which are merely needed to observe the state the <a>control</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>control</a> that they define
what needs to be preserved.

<div class=example>
Expand Down