Define how some properties disable 'appearance' (superseded by #4857) #4322

zcorpan · 2019-01-25T14:01:52Z

cc @annevk @bzbarsky @MatsPalmgren @tkent-google @frivoal

This is intended to match https://docs.google.com/document/d/1FE5YIoirPKxYbbnMd8kS6w39M8bzLTl5tf4wwOxR1wc/edit#heading=h.1jgvj9nxi09d

Still need to change the remaining of the "Widgets" section to describe what various elements do when they are different kinds of widgets, and add 'appearance: auto' to specific elements in the UA stylesheet (unless web compat requires getComputedStyle to return other keywords).

I'm not entirely confident in how to specify "author-only properties" (step 6). cc @tabatkins

Some of this should maybe be defined in css-ui instead.

/acknowledgements.html ( diff )
/browsers.html ( diff )
/browsing-the-web.html ( diff )
/canvas.html ( diff )
/common-dom-interfaces.html ( diff )
/common-microsyntaxes.html ( diff )
/comms.html ( diff )
/custom-elements.html ( diff )
/dnd.html ( diff )
/dom.html ( diff )
/dynamic-markup-insertion.html ( diff )
/edits.html ( diff )
/embedded-content-other.html ( diff )
/embedded-content.html ( diff )
/form-control-infrastructure.html ( diff )
/form-elements.html ( diff )
/forms.html ( diff )
/grouping-content.html ( diff )
/history.html ( diff )
/iana.html ( diff )
/iframe-embed-object.html ( diff )
/image-maps.html ( diff )
/imagebitmap-and-animations.html ( diff )
/images.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/input.html ( diff )
/interaction.html ( diff )
/interactive-elements.html ( diff )
/introduction.html ( diff )
/links.html ( diff )
/media.html ( diff )
/microdata.html ( diff )
/named-characters.html ( diff )
/obsolete.html ( diff )
/offline.html ( diff )
/origin.html ( diff )
/parsing.html ( diff )
/references.html ( diff )
/rendering.html ( diff )
/scripting.html ( diff )
/sections.html ( diff )
/semantics-other.html ( diff )
/semantics.html ( diff )
/server-sent-events.html ( diff )
/structured-data.html ( diff )
/syntax.html ( diff )
/system-state.html ( diff )
/tables.html ( diff )
/text-level-semantics.html ( diff )
/timers-and-user-prompts.html ( diff )
/urls-and-fetching.html ( diff )
/web-messaging.html ( diff )
/web-sockets.html ( diff )
/webappapis.html ( diff )
/webstorage.html ( diff )
/window-object.html ( diff )
/workers.html ( diff )
/xhtml.html ( diff )

zcorpan · 2019-01-25T14:05:53Z

source

+  <dfn data-x="concept-widget-button" data-export="" data-dfn-for="rendering-widget">button</dfn>,
+  <dfn data-x="concept-widget-searchfield" data-export="" data-dfn-for="rendering-widget">searchfield</dfn>,
+  <dfn data-x="concept-widget-textfield" data-export="" data-dfn-for="rendering-widget">textfield</dfn>,
+  <dfn data-x="concept-widget-slider-horizontal" data-export="" data-dfn-for="rendering-widget">slider-horizontal</dfn>,


Browsers have a separate slider-vertical widget, though the spec says to change the orientation based on rendered dimensions. Maybe we should have a different way to change the orientation (e.g. an attribute or CSS property)?

There seems to be consensus in #4177 that appearance:slider-horizontal/vertical is a bad solution.

zcorpan · 2019-01-25T14:12:06Z

source

+       data-x="concept-widget-none">none</span>.</p></li>
+
+       <li><p>If <var>computedAppearance</var> is 'menulist-button', then return <span
+       data-x="concept-widget-menulist-button">menulist-button</span>.</p></li>


See w3c/csswg-drafts#3551

zcorpan · 2019-01-25T14:13:14Z

source

+
+     <!-- meter -->
+     <li><p>If <var>localName</var> is "<code data-x="">meter</code>", then return <span
+     data-x="concept-widget-meter">meter</span>.</p></li>


See w3c/csswg-drafts#356

zcorpan · 2019-01-25T14:15:08Z

source

+    </ol>
+   </li>
+
+   <!-- others (including input type=file, input type=image, svg...) -->


Do we want to force 'none' on input type=file? Allowing button on input type=image seems potentially useful when showing alt text. I'm not sure about non-HTML elements but browsers allow it (though has no effect for most SVG elements).

IMO, we should not add new behavior.

So current behavior is to allow button on input type=file, input type=image, svg. Below you said "I don't want to keep accepting 'button' appearance on any elements". Can you clarify what you would like to do for the button value?

Oh, I misunderstood that <input type=file> with -webkit-appearance:button didn't work in WebKit/Blink. It's ok to specify the current WebKit/Blink behavior. I'm sorry for the noise.

zcorpan · 2019-01-25T14:17:11Z

source

+
+   <!-- others (including input type=file, input type=image, svg...) -->
+   <li><p>If <var>computedAppearance</var> is 'button', then return <span
+   data-x="concept-widget-button">button</span>. Otherwise, return <span


This is like WebKit/Chromium - specifying -webkit-appearance: button on a div gives it the native button widget even if borders and backgrounds are also specified. Should specifying a border/background result in 'none' instead (like Gecko)?

I don't see such behavior.

BTW, I don't want to keep accepting 'button' appearance on any elements, but it's ok to specify the current behavior.

Here's a test: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6554

I think there's some web content wanting to use 'button' appearance on div/span/a at least. I could also envision developers wanting to use it with custom elements. Do you think it should be accepted only on actual buttons, or some other elements also?

Thanks. I confirmed, and remembered http://crbug.com/612519.
It's ok to specify either of WebKit/Blink behavior and Gecko behavior for now.

However, my opinion is that we should make the 'button' appearance available only on <button> and <input> buttons. I added counters to evaluate the risk of the change; https://chromium-review.googlesource.com/c/1442348

tkent-google · 2019-01-28T10:57:53Z

source

+
+   <!-- others (including input type=file, input type=image, svg...) -->
+   <li><p>If <var>computedAppearance</var> is 'button', then return <span
+   data-x="concept-widget-button">button</span>. Otherwise, return <span


I don't see such behavior.

BTW, I don't want to keep accepting 'button' appearance on any elements, but it's ok to specify the current behavior.

tkent-google · 2019-01-28T10:58:13Z

source

+    </ol>
+   </li>
+
+   <!-- others (including input type=file, input type=image, svg...) -->


IMO, we should not add new behavior.

tkent-google · 2019-01-28T11:18:45Z

source

+  <dfn data-x="concept-widget-progress-bar" data-export="" data-dfn-for="rendering-widget">progress-bar</dfn>, and
+  <dfn data-x="concept-widget-meter" data-export="" data-dfn-for="rendering-widget">meter</dfn>.</p>
+
+  <p>To <dfn>compute the kind of widget</dfn> to use for an element <var>element</var>:</p>


The algorithm looks complex.
Now the algorithm is written in a format like:

If element type is foo and computedApparance is keyword1, if properties are ..., then appearance is keyword1, or 'none' If element type is bar and computedAppearance is keyword2, if properties are ..., then appearance is keyword2, or 'none' ...

I wonder if the following format would be simpler:

if computedApparance is keyword1, if properties are ..., then 'none' if element type is not foo, then 'none' return keyword1 if computedApparance is keyword2, if properties are ..., then 'none' if element type is not foo, then 'none' return keyword2 ...

Actually, the implementation of WebKit/Blink is something like the latter.

The computedAppearance is per spec mostly ignored except for none (+aliases) and button and menulist-button. Other keywords act like auto. So what you suggested isn't equivalent (for example, textfield on a checkbox would result in checkbox not none).

Some initial work to make introducing browsing context groups (see #4198) easier. Fixes #2636 by making opener browsing context more generally applicable and making window.open() set it. Fixes #2645 by removing creator browsing context and explicitly passing in the creator document. Tests: web-platform-tests/wpt#15078.

zcorpan · 2019-01-30T16:28:04Z

source

@@ -112777,6 +112818,13 @@ input, select, option, optgroup, button, textarea {
  text-indent: initial;
 }

+input, select, button, textarea {
+  appearance: auto;


I looked into possible web compat problems that could arise from switching the default to 'auto'.

Modernizr checks WebkitAppearance to feature-detect some input types, but this should continue to work since it checks if the value is not "textfield". Going forward, this kind of check should be done with the type IDL attribute instead. (I suppose this was working around some partial implementation.)

I didn't find anything else in httparchive that would be affected here.

Fixes #3430.

The concept of a browsing context event loop does not make much sense in a world where cross-site navigations are increasingly getting more isolated from each other. Helps with #4198.

This reduces the number of coupled top-level browsing contexts and thereby reduces the attack surface somewhat. Tests: web-platform-tests/wpt#15188. Fixes #4078.

As implied by the Note after the definition of session history entries.

Closes #4267. Related to previous work in #4181. Tests: web-platform-tests/wpt#15251

Fixes #4171.

Tests: web-platform-tests/wpt#15352. Fixes #4111.

In particular to enable noopener, noreferrer, and opener values. Also default <form target=_blank> to noopener. Tests: web-platform-tests/wpt#15356. Fixes #2983.

Name attributes of elements that can create nested browsing contexts (embed, frame, iframe, object) are only to be considered when the nested browsing context is created. Tests: web-platform-tests/wpt#15392.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1460158 for context.

Calling cancelAnimationFrame() from within a requestAnimationFrame() callback should cancel any animation frame callbacks that are pending for the current frame. The currently specified behavior does not permit that, however, since it clones the set of callbacks before iterating over them. This patch updates the algorithm to run animation frame callbacks such that it is possible to cancel a pending animation frame callback. This also brings the specified behavior into line with its implementation in Blink, EdgeHTML, and WebKit. Tests: web-platform-tests/wpt#15455. Closes #4359.

Previously, a Document could sometimes "have no browsing context". Now, "a Document's browsing context" is either a browsing context or null. Previously, "a Window's browsing context" was not defined, despite being referenced extensively. Now, it is defined to be the Window's associated Document's browsing context. Related to #3846, #4363, and #4366.

Tests: web-platform-tests/wpt#15391. Helps with #4363.

This should fix the issue seen in whatwg/fullscreen#145.

Fixes whatwg/webidl#518.

ab73443 introduced new custom element callbacks, but continued to referring to there being four callbacks. Let's stop stating how many callbacks there are. Fixes #4822.

See whatwg/webidl#750.

Fixes #4798.

Previously, sandboxed navigation did not prevent navigation via the history API; the check for the navigation was after the unload steps of the history traversal. This adds an explicit check in those methods to prevent such navigation. Fixes #880.

Further code inspection and test-writing revealed that SVG <a> elements get a 0 default tabIndex in all engines, and <object> elements get a 0 default tabIndex in Blink and WebKit. These were omitted in 15cf23a.

Fixes #4358. See also #2382.

This aligns the HTML Standard with Chrome and Firefox rather than Safari. Tests: web-platform-tests/wpt#18536. Fixes #4762.

It seems this feature got added without an agreed upon plan. Firefox fires the loadstart event, but I cannot find evidence of the other events or them using the correct class. Tests: web-platform-tests/wpt#18499. Closes #1915. Closes #3860.

Fixes #3014

Part of whatwg/html#4322

…gress/meter

This term is currently used informally to describe "the elements defined in [section 14.5]." Formalize this definition so that it may be referenced by the CSS-UI specification to describe the referenced `appearance` property. Add a note Rename the term to 'native appearance' and remove details, summary, marquee Hook into CSS UI's 'native appearance' term

zcorpan · 2019-08-22T09:59:08Z

I cherry-picked #4725 into this PR, and also rebased on latest master since there was a merge conflict. But now 132 commits are included in this PR, I'm not sure how that happened. :|

zcorpan · 2019-08-22T10:08:38Z

This is now #4857

Part of whatwg/html#4322

…e', a=testonly Automatic update from web-platform-tests HTML: Test default styles for 'appearance' Part of whatwg/html#4322 -- wpt-commits: c73e28f65eb65da982a7542d5ab71620992707ec wpt-pr: 18591

…e', a=testonly Automatic update from web-platform-tests HTML: Test default styles for 'appearance' Part of whatwg/html#4322 -- wpt-commits: c73e28f65eb65da982a7542d5ab71620992707ec wpt-pr: 18591 UltraBlame original commit: 3599a67e5fd69f33b599ba96a8d1e463f5d8bf9d

zcorpan added compat Standard is not web compatible or proprietary feature needs standardizing topic: forms interop Implementations are not interoperable with each other labels Jan 25, 2019

zcorpan commented Jan 25, 2019

View reviewed changes

tkent-google reviewed Jan 28, 2019

View reviewed changes

annevk added 2 commits January 29, 2019 14:52

Editorial: centralize nested browsing context creation

f75a7b2

zcorpan commented Jan 30, 2019

View reviewed changes

Give toDataURL() and toBlob() default parameter values

b799322

Fixes #3430.

zcorpan changed the title ~~Define how some properties disable 'appearance' (WIP)~~ Define how some properties disable 'appearance' Jan 30, 2019

zcorpan added the needs tests Moving the issue forward requires someone to write tests label Jan 30, 2019

annevk and others added 19 commits February 7, 2019 11:18

Tie event loops to agents

f97d629

The concept of a browsing context event loop does not make much sense in a world where cross-site navigations are increasingly getting more isolated from each other. Helps with #4198.

Make target=_blank imply noopener; support opener

5c68ab3

This reduces the number of coupled top-level browsing contexts and thereby reduces the attack surface somewhat. Tests: web-platform-tests/wpt#15188. Fixes #4078.

Editorial: remove some sandbox attribute copypasta

775cfc2

Remove a Document from its session history entry when it's discarded

34af0c8

As implied by the Note after the definition of session history entries.

Always set [[ScriptOrModule]] to null for event handler functions

1d6eb99

Closes #4267. Related to previous work in #4181. Tests: web-platform-tests/wpt#15251

Editorial: improve async attribute description

2b1c104

Fixes #4171.

Editorial: gsnedders's name changed

8cc0721

Editorial: inline noreferrer processing model

f47773d

Support noreferrer for window.open()

a9a7944

Tests: web-platform-tests/wpt#15352. Fixes #4111.

Add <form rel>

cf483d3

In particular to enable noopener, noreferrer, and opener values. Also default <form target=_blank> to noopener. Tests: web-platform-tests/wpt#15356. Fixes #2983.

Ignore changes to name attributes

4fe2d53

Name attributes of elements that can create nested browsing contexts (embed, frame, iframe, object) are only to be considered when the nested browsing context is created. Tests: web-platform-tests/wpt#15392.

Rendering: clarify details's internal shadow tree

42a27a1

See https://bugzilla.mozilla.org/show_bug.cgi?id=1460158 for context.

Make window.name deal with lack of browsing context

b8c084e

Tests: web-platform-tests/wpt#15391. Helps with #4363.

Editorial: minor cleanup around browsing contexts

009a513

Editorial: modernize Window's parent and frameElement

140fde2

Editorial: shorten Window's top attribute's algorithm

bc58c77

Meta: export Window's browsing context properly

26539eb

This should fix the issue seen in whatwg/fullscreen#145.

Ms2ger and others added 10 commits August 6, 2019 10:58

Editorial: cross-reference the "exposed" IDL concept

dfe50f7

Fixes whatwg/webidl#518.

Fix miscounted number of custom element callbacks

379f990

ab73443 introduced new custom element callbacks, but continued to referring to there being four callbacks. Let's stop stating how many callbacks there are. Fixes #4822.

Align with IDL dictionary changes

1224105

See whatwg/webidl#750.

Editorial: rename "Plain Unicode string" to "text" for drag data store

817ee1b

Fixes #4798.

Further tabIndex getter tweaks

7ce0b47

Further code inspection and test-writing revealed that SVG <a> elements get a 0 default tabIndex in all engines, and <object> elements get a 0 default tabIndex in Blink and WebKit. These were omitted in 15cf23a.

Fix conformance requirements on <script>'s integrity="" attribute

ef22f69

Fixes #4358. See also #2382.

Change default value of window.open()'s url argument

516e1db

This aligns the HTML Standard with Chrome and Firefox rather than Safari. Tests: web-platform-tests/wpt#18536. Fixes #4762.

Remove <img> progress events

af7cff7

It seems this feature got added without an agreed upon plan. Firefox fires the loadstart event, but I cannot find evidence of the other events or them using the correct class. Tests: web-platform-tests/wpt#18499. Closes #1915. Closes #3860.

Meta: Link to web-platform-tests in the header

4ab3633

Fixes #3014

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request Aug 21, 2019

HTML: Test default styles for 'appearance'

ff520c8

Part of whatwg/html#4322

zcorpan mentioned this pull request Aug 21, 2019

HTML: Test default styles for 'appearance' web-platform-tests/wpt#18591

Merged

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request Aug 21, 2019

HTML: Test default styles for 'appearance'

c73e28f

Part of whatwg/html#4322

zcorpan and others added 4 commits August 22, 2019 11:46

Define how some properties disable 'appearance' (WIP)

79ba5b0

Add appearance to the UA stylesheet

2f0fa03

Document remaining issues; explicitly define appearance: none for pro…

9df56ba

…gress/meter

zcorpan mentioned this pull request Aug 22, 2019

Define how some properties disable 'appearance' (superseded by #7004) #4857

Closed

8 tasks

zcorpan closed this Aug 22, 2019

zcorpan changed the title ~~Define how some properties disable 'appearance'~~ Define how some properties disable 'appearance' (superseded by #4857) Aug 22, 2019

natechapin pushed a commit to natechapin/wpt that referenced this pull request Aug 23, 2019

HTML: Test default styles for 'appearance'

1d892ad

Part of whatwg/html#4322

zcorpan mentioned this pull request Sep 11, 2019

Be resilient to mistakes that currently cause wpt-pr-bot to ask everyone to review web-platform-tests/wpt-pr-bot#79

Open

annevk deleted the zcorpan/appearance-compute-widget branch October 15, 2021 11:25

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Define how some properties disable 'appearance' (superseded by #4857) #4322

Define how some properties disable 'appearance' (superseded by #4857) #4322

zcorpan commented Jan 25, 2019 •

edited by pr-preview bot

Loading

zcorpan Jan 25, 2019

MatsPalmgren Jan 25, 2019

zcorpan Jan 25, 2019

zcorpan Jan 25, 2019

zcorpan Jan 25, 2019

tkent-google Jan 28, 2019

zcorpan Jan 28, 2019

tkent-google Jan 31, 2019

zcorpan Jan 25, 2019

tkent-google Jan 28, 2019

zcorpan Jan 28, 2019

tkent-google Jan 31, 2019 •

edited by zcorpan

Loading

tkent-google Jan 28, 2019

tkent-google Jan 28, 2019

tkent-google Jan 28, 2019

zcorpan Jan 28, 2019 •

edited

Loading

zcorpan Jan 30, 2019

zcorpan commented Aug 22, 2019

zcorpan commented Aug 22, 2019

Define how some properties disable 'appearance' (superseded by #4857) #4322

Define how some properties disable 'appearance' (superseded by #4857) #4322

Conversation

zcorpan commented Jan 25, 2019 • edited by pr-preview bot Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tkent-google Jan 31, 2019 • edited by zcorpan Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zcorpan Jan 28, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zcorpan commented Aug 22, 2019

zcorpan commented Aug 22, 2019

zcorpan commented Jan 25, 2019 •

edited by pr-preview bot

Loading

tkent-google Jan 31, 2019 •

edited by zcorpan

Loading

zcorpan Jan 28, 2019 •

edited

Loading