[css-ui] Auto-disable native appearance when cascaded value has author origin #4777
Labels
Comments
|
whatwg/html#4857 has a start for defining this. See https://whatpr.org/html/4857/rendering.html#appropriate-widget whatwg/html#4857 (comment) is not yet fixed, though. |
Shouldn't CSS define this, rather than HTML? |
|
A downside of the Gecko behavior is that an author can't "get back" to the UA rendering by setting the property value to one that matches the UA stylesheet. |
|
The CSS Working Group just discussed The full IRC log of that discussion<dael> Topic: [css-ui] Auto-disable native appearance when cascaded value has author origin<dael> github: https://github.com//issues/4777 <dael> florian: We have appearance property with atuo look native. WHen in native there's a number of properties where if you set to a value it disables native-ness. Example is border-bottom <dael> florian: 2 things undefined. What's the set of properties that have this effect and on which elements. Other thing, this issue, is how do these properties disable. One is FF which if author sets to any value it disables nativeness. Chrome is the values is set different then UA it disables nativeness. Chrome plans to switch to FF behavior <dael> florian: Not spec anywhere, but an attempt in HTML and a placeholdder in CSS UI 4. Mostly a heads up from Chrome they are trying this. BUt if people think it's a bad idea it's good to say so before they try <dael> smfr: I think Chrome inherited from WK. WOuld be interested in seeing experiment. If successful WK probably willing to follow <dael> florian: Since appearance are sensistive to compat I'm interested to wait out experiment before changing spec <dael> Rossen_: We're at top of hour. Anyone from Chrome that could have feedback on success now? If not we push back to GH and discuss next week <dael> florian: No experiement yet. Pinging us before hand in case it sounds like a terrible idea. Doesn't sound like it is so we should let them run and report back. <dael> Rossen_: I see. <dael> Rossen_: Let's end here and then hopefully we'll get data back from Chrome experiementation |
Maybe |
|
Firefox already supports |
|
@ExE-Boss But |
|
Yeah, I think we could support |
|
@andruud looking at the blink implementation, it seems you account for border-image properties too, which is something that we don't do: Is that intentional? I'm not quite sure if we do that intentionally or not (would need to dig the history a bit). Both ignoring them and not ignoring them makes some amount of sense, we probably just need to agree on which one makes more sense or is more useful to authors. |
|
@emilio It's intentional in the sense that I (for now) didn't intend to change which properties disable appearance, just how it happens. I guess if other visual aspects of the border (color, width, etc) are grounds for disabling, then border-image* is as well? (I don't have a strong opinion). I'm in general not a very big fan of this auto-disabling feature, but since we have it, we should probably always auto-disable when an author declaration would effectively be ignored by maintaining the appearance.
|
xeonchen
pushed a commit
to xeonchen/gecko
that referenced
this issue
Mar 26, 2020
… r=heycam This patch computes the author-specified properties during the CSS cascade, and removes the complex rule-tree-based implementation that tries to do the cascade again. This changes behavior in two ways, one of them which is not observable to content, I believe: * revert now re-enables the native styling. This was brought up in w3c/csswg-drafts#4777 and I think it is a bug-fix. This is observable to content, and I'm adding a test for it. * We don't look at inherited styles from our ancestors when `inherit` is specified in a non-author stylesheet. This was introduced for bug 452969 but we don't seem to inherit background anymore for file controls or such. It seems back then file controls used to have a text-field. I audited forms.css and ua.css and we don't explicitly inherit padding / border / background-color into any nested form control. We keep the distinction between border/background and padding, because the later has some callers. I think we should try to align with Chromium in the long run and remove the padding bit. We need to give an appearance to the range-thumb and such so that we can assert that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new internal value for that. Differential Revision: https://phabricator.services.mozilla.com/D67722
xeonchen
pushed a commit
to xeonchen/gecko
that referenced
this issue
Mar 26, 2020
… r=heycam This patch computes the author-specified properties during the CSS cascade, and removes the complex rule-tree-based implementation that tries to do the cascade again. This changes behavior in two ways, one of them which is not observable to content, I believe: * revert now re-enables the native styling. This was brought up in w3c/csswg-drafts#4777 and I think it is a bug-fix. This is observable to content, and I'm adding a test for it. * We don't look at inherited styles from our ancestors when `inherit` is specified in a non-author stylesheet. This was introduced for bug 452969 but we don't seem to inherit background anymore for file controls or such. It seems back then file controls used to have a text-field. I audited forms.css and ua.css and we don't explicitly inherit padding / border / background-color into any nested form control. We keep the distinction between border/background and padding, because the later has some callers. I think we should try to align with Chromium in the long run and remove the padding bit. We need to give an appearance to the range-thumb and such so that we can assert that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new internal value for that. Differential Revision: https://phabricator.services.mozilla.com/D67722
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Mar 26, 2020
… r=heycam This patch computes the author-specified properties during the CSS cascade, and removes the complex rule-tree-based implementation that tries to do the cascade again. This changes behavior in two ways, one of them which is not observable to content, I believe: * revert now re-enables the native styling. This was brought up in w3c/csswg-drafts#4777 and I think it is a bug-fix. This is observable to content, and I'm adding a test for it. * We don't look at inherited styles from our ancestors when `inherit` is specified in a non-author stylesheet. This was introduced for bug 452969 but we don't seem to inherit background anymore for file controls or such. It seems back then file controls used to have a text-field. I audited forms.css and ua.css and we don't explicitly inherit padding / border / background-color into any nested form control. We keep the distinction between border/background and padding, because the later has some callers. I think we should try to align with Chromium in the long run and remove the padding bit. We need to give an appearance to the range-thumb and such so that we can assert that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new internal value for that. Differential Revision: https://phabricator.services.mozilla.com/D67722 --HG-- extra : moz-landing-system : lando
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Mar 27, 2020
… r=heycam This patch computes the author-specified properties during the CSS cascade, and removes the complex rule-tree-based implementation that tries to do the cascade again. This changes behavior in two ways, one of them which is not observable to content, I believe: * revert now re-enables the native styling. This was brought up in w3c/csswg-drafts#4777 and I think it is a bug-fix. This is observable to content, and I'm adding a test for it. * We don't look at inherited styles from our ancestors when `inherit` is specified in a non-author stylesheet. This was introduced for bug 452969 but we don't seem to inherit background anymore for file controls or such. It seems back then file controls used to have a text-field. I audited forms.css and ua.css and we don't explicitly inherit padding / border / background-color into any nested form control. We keep the distinction between border/background and padding, because the later has some callers. I think we should try to align with Chromium in the long run and remove the padding bit. We need to give an appearance to the range-thumb and such so that we can assert that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new internal value for that. Differential Revision: https://phabricator.services.mozilla.com/D67722 --HG-- extra : moz-landing-system : lando
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-comments-removed
that referenced
this issue
Mar 31, 2020
… r=heycam This patch computes the author-specified properties during the CSS cascade, and removes the complex rule-tree-based implementation that tries to do the cascade again. This changes behavior in two ways, one of them which is not observable to content, I believe: * revert now re-enables the native styling. This was brought up in w3c/csswg-drafts#4777 and I think it is a bug-fix. This is observable to content, and I'm adding a test for it. * We don't look at inherited styles from our ancestors when `inherit` is specified in a non-author stylesheet. This was introduced for bug 452969 but we don't seem to inherit background anymore for file controls or such. It seems back then file controls used to have a text-field. I audited forms.css and ua.css and we don't explicitly inherit padding / border / background-color into any nested form control. We keep the distinction between border/background and padding, because the later has some callers. I think we should try to align with Chromium in the long run and remove the padding bit. We need to give an appearance to the range-thumb and such so that we can assert that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new internal value for that. Differential Revision: https://phabricator.services.mozilla.com/D67722 UltraBlame original commit: ac0d06c0ca9330d5356717094910e977cf8f6c29
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-comments-removed
that referenced
this issue
Mar 31, 2020
… r=heycam This patch computes the author-specified properties during the CSS cascade, and removes the complex rule-tree-based implementation that tries to do the cascade again. This changes behavior in two ways, one of them which is not observable to content, I believe: * revert now re-enables the native styling. This was brought up in w3c/csswg-drafts#4777 and I think it is a bug-fix. This is observable to content, and I'm adding a test for it. * We don't look at inherited styles from our ancestors when `inherit` is specified in a non-author stylesheet. This was introduced for bug 452969 but we don't seem to inherit background anymore for file controls or such. It seems back then file controls used to have a text-field. I audited forms.css and ua.css and we don't explicitly inherit padding / border / background-color into any nested form control. We keep the distinction between border/background and padding, because the later has some callers. I think we should try to align with Chromium in the long run and remove the padding bit. We need to give an appearance to the range-thumb and such so that we can assert that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new internal value for that. Differential Revision: https://phabricator.services.mozilla.com/D67722 UltraBlame original commit: 33869dd6c77528e912a1b59d3db38723ba0d0c0d
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified-and-comments-removed
that referenced
this issue
Mar 31, 2020
… r=heycam This patch computes the author-specified properties during the CSS cascade, and removes the complex rule-tree-based implementation that tries to do the cascade again. This changes behavior in two ways, one of them which is not observable to content, I believe: * revert now re-enables the native styling. This was brought up in w3c/csswg-drafts#4777 and I think it is a bug-fix. This is observable to content, and I'm adding a test for it. * We don't look at inherited styles from our ancestors when `inherit` is specified in a non-author stylesheet. This was introduced for bug 452969 but we don't seem to inherit background anymore for file controls or such. It seems back then file controls used to have a text-field. I audited forms.css and ua.css and we don't explicitly inherit padding / border / background-color into any nested form control. We keep the distinction between border/background and padding, because the later has some callers. I think we should try to align with Chromium in the long run and remove the padding bit. We need to give an appearance to the range-thumb and such so that we can assert that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new internal value for that. Differential Revision: https://phabricator.services.mozilla.com/D67722 UltraBlame original commit: ac0d06c0ca9330d5356717094910e977cf8f6c29
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified-and-comments-removed
that referenced
this issue
Mar 31, 2020
… r=heycam This patch computes the author-specified properties during the CSS cascade, and removes the complex rule-tree-based implementation that tries to do the cascade again. This changes behavior in two ways, one of them which is not observable to content, I believe: * revert now re-enables the native styling. This was brought up in w3c/csswg-drafts#4777 and I think it is a bug-fix. This is observable to content, and I'm adding a test for it. * We don't look at inherited styles from our ancestors when `inherit` is specified in a non-author stylesheet. This was introduced for bug 452969 but we don't seem to inherit background anymore for file controls or such. It seems back then file controls used to have a text-field. I audited forms.css and ua.css and we don't explicitly inherit padding / border / background-color into any nested form control. We keep the distinction between border/background and padding, because the later has some callers. I think we should try to align with Chromium in the long run and remove the padding bit. We need to give an appearance to the range-thumb and such so that we can assert that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new internal value for that. Differential Revision: https://phabricator.services.mozilla.com/D67722 UltraBlame original commit: 33869dd6c77528e912a1b59d3db38723ba0d0c0d
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified
that referenced
this issue
Mar 31, 2020
… r=heycam This patch computes the author-specified properties during the CSS cascade, and removes the complex rule-tree-based implementation that tries to do the cascade again. This changes behavior in two ways, one of them which is not observable to content, I believe: * revert now re-enables the native styling. This was brought up in w3c/csswg-drafts#4777 and I think it is a bug-fix. This is observable to content, and I'm adding a test for it. * We don't look at inherited styles from our ancestors when `inherit` is specified in a non-author stylesheet. This was introduced for bug 452969 but we don't seem to inherit background anymore for file controls or such. It seems back then file controls used to have a text-field. I audited forms.css and ua.css and we don't explicitly inherit padding / border / background-color into any nested form control. We keep the distinction between border/background and padding, because the later has some callers. I think we should try to align with Chromium in the long run and remove the padding bit. We need to give an appearance to the range-thumb and such so that we can assert that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new internal value for that. Differential Revision: https://phabricator.services.mozilla.com/D67722 UltraBlame original commit: ac0d06c0ca9330d5356717094910e977cf8f6c29
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified
that referenced
this issue
Mar 31, 2020
… r=heycam This patch computes the author-specified properties during the CSS cascade, and removes the complex rule-tree-based implementation that tries to do the cascade again. This changes behavior in two ways, one of them which is not observable to content, I believe: * revert now re-enables the native styling. This was brought up in w3c/csswg-drafts#4777 and I think it is a bug-fix. This is observable to content, and I'm adding a test for it. * We don't look at inherited styles from our ancestors when `inherit` is specified in a non-author stylesheet. This was introduced for bug 452969 but we don't seem to inherit background anymore for file controls or such. It seems back then file controls used to have a text-field. I audited forms.css and ua.css and we don't explicitly inherit padding / border / background-color into any nested form control. We keep the distinction between border/background and padding, because the later has some callers. I think we should try to align with Chromium in the long run and remove the padding bit. We need to give an appearance to the range-thumb and such so that we can assert that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new internal value for that. Differential Revision: https://phabricator.services.mozilla.com/D67722 UltraBlame original commit: 33869dd6c77528e912a1b59d3db38723ba0d0c0d
emilio
added a commit
to emilio/servo
that referenced
this issue
Apr 16, 2020
This patch computes the author-specified properties during the CSS cascade, and removes the complex rule-tree-based implementation that tries to do the cascade again. This changes behavior in two ways, one of them which is not observable to content, I believe: * revert now re-enables the native styling. This was brought up in w3c/csswg-drafts#4777 and I think it is a bug-fix. This is observable to content, and I'm adding a test for it. * We don't look at inherited styles from our ancestors when `inherit` is specified in a non-author stylesheet. This was introduced for bug 452969 but we don't seem to inherit background anymore for file controls or such. It seems back then file controls used to have a text-field. I audited forms.css and ua.css and we don't explicitly inherit padding / border / background-color into any nested form control. We keep the distinction between border/background and padding, because the later has some callers. I think we should try to align with Chromium in the long run and remove the padding bit. We need to give an appearance to the range-thumb and such so that we can assert that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new internal value for that. Differential Revision: https://phabricator.services.mozilla.com/D67722
8 tasks
|
@andruud commented in whatwg/html#4857 (comment) that we might want to include animation origin and transition origin as well, not only author origin. |
Yes, probably some things should be moved to CSS UI. Also see #3526 |
nosark
pushed a commit
to nosark/servo
that referenced
this issue
Jul 19, 2020
This patch computes the author-specified properties during the CSS cascade, and removes the complex rule-tree-based implementation that tries to do the cascade again. This changes behavior in two ways, one of them which is not observable to content, I believe: * revert now re-enables the native styling. This was brought up in w3c/csswg-drafts#4777 and I think it is a bug-fix. This is observable to content, and I'm adding a test for it. * We don't look at inherited styles from our ancestors when `inherit` is specified in a non-author stylesheet. This was introduced for bug 452969 but we don't seem to inherit background anymore for file controls or such. It seems back then file controls used to have a text-field. I audited forms.css and ua.css and we don't explicitly inherit padding / border / background-color into any nested form control. We keep the distinction between border/background and padding, because the later has some callers. I think we should try to align with Chromium in the long run and remove the padding bit. We need to give an appearance to the range-thumb and such so that we can assert that we don't call HasAuthorSpecifiedRules on non-themed stuff. I used a new internal value for that. Differential Revision: https://phabricator.services.mozilla.com/D67722
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Browsers currently automatically disable the native appearance of widgets in some cases, even if
appearanceis e.g.auto(see issue 11). This can happen when the author styles theborder,background, or in Firefox's casepadding(I believe).This issue is not about which properties disable the native appearance, but how they disable appearance, which is quite different in Firefox (which has reasonable behavior) vs Chrome/Safari (which has ... less reasonable behavior):
In Chrome (and as far as I can see in Safari), the native appearance is disabled when the author styles the background/border in such a way that it differs from the would-be background/border had only UA-origin declarations existed. This approach isn't great, because:
Instead, we should specify that border/background/etc applied by the author origin disables the native appearance regardless of their value. This is (to the best of my knowledge) what Firefox does currently.
See also related Intent to Ship on blink-dev.
The text was updated successfully, but these errors were encountered: