Define how some properties disable 'appearance' (superseded by #7004) #4857
Conversation
zcorpan
added
compat
|
Thanks, @domenic! 😊 |
zcorpan
added
the
needs tests
|
I think we still need discussion to make agreement on the algorithm.
|
|
Thanks @tkent-google. Here's a test, comparing the effect of specifying:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7151 Screenshots from BrowserStackWindows 10 edge insider preview Windows 10 chrome 71 Windows 10 firefox 62 OS X Mojave safari 12.1 iPad Pro 12.9 2018 (Portrait) OS X Mojave chrome 71 OS X Mojave firefox 62 Google Nexus 9 (Portrait) OS X Mojave safari 12.1, specifying a background on Removing the concept of include background properties (i.e., making it always true) would simplify the spec and also match more browsers, so that seems like a good change. For w3c/csswg-drafts#356 So there are three states in Chrome now for cc @smfr for webkit opinions. |
Oh, you're right. WebKit/mac (but no other ports of WebKit) has include background properties flag for I think the quirky As for box-shadow and non-none appearance,
IMO, the Firefox behavior is simple and reasonable. If rendering result of appearance+box-shadow is ugly, web authors can specify appearance:none. |
So, what do we want to specify?
I'm not sure I follow. Are you saying that what the spec says now for
I agree. This is what the PR currently requires (by not saying otherwise, 'box-shadow' should just work as normal). |
Probably, remove include background properties flag though I'm not sure if WebKit people accepts it.
Yes. I'm fine with the behavior that 'meter' is never disabled by CSS properties. |
|
Thanks! @smfr can you comment (or loop in the right person for from control styling in WebKit), please? |
There was a problem hiding this comment.
Very exciting, thanks for continuing this important work! For in depth details I'll very much defer to @MatsPalmgren and others more familiar with layout.
|
So I don't think the definition here ended up matching what Gecko and Blink do about disabling appearance. See also w3c/csswg-drafts#4777. In particular, it's not about "initial-value-ness", but about "is there any author-origin declaration applying". |
The "show fallback" behavior seems extremely weird to me. It goes against how HTML normally defines when fallback content should be rendered - namely that it is intended as a fallback for UAs that don't support the element at all. As the current spec says for
I really don't think we should show the fallback content just because |
|
@MatsPalmgren the behavior for Since that issue is still open and we don't have consensus on that, I can make the behavior for |
Also: - Add appearance to the UA stylesheet - Document remaining issues; explicitly define appearance: none for progress/meter - Hook into CSS UI's 'native appearance' term
|
I've made new changes today to incorporate feedback and to reflect implementation changes in chromium and gecko. I believe this PR should match the current behavior of chromium. Please review :) I'll look at the tests for this on Thursday this week. |
|
One difference is that this uses the I did research the compat risk of this here #4322 (comment) and didn't find anything that would break (though the risk is non-zero of course). |
|
Testing plan (see Making a testing plan):
Elements to test: button, input, meter, progress, select, textarea Place tests in |
I'm going to change the default values to |
|
@tkent-google ok, thanks! Let's keep |
|
I'm looking at this again today, and realized that nothing in the spec invokes "compute the kind of widget". I wonder if CSS UI should say that the host language may define an algorithm that must be invoked at used value time. The algorithm here checks computed values, and it doesn't itself affect the computed value, so I think used value is right. |
|
cc @whatwg/css |
Expanding on @zcorpan's testing plan for "compute the kind of widget", given that the following widgets are defined:
|
Also:
Changes needed for this PR:
appearance: noneforprogressandmeter(Define how some properties disable 'appearance' (superseded by #7004) #4857 (comment))buttonto not be applicable to non-buttons(See WHATWG Working Mode: Changes for more details.)
This PR replaces #4322 and #4725. (Sorry for the new PR, but I somehow messed up #4322.)
💥 Error: Wattsi server error 💥
PR Preview failed to build. (Last tried on Sep 8, 2021, 2:50 PM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.
🔗 Related URL
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.