Repository navigation
[css-cascade] Are 'Override declarations' still a thing? #1385
Description
Historically, the CSS Cascading and Inheritance spec lists 'Override declarations' among other cascading origins. But it appears that the spec that they refer to has never been really implemented, and 'Override declarations' are now a purely theoretical concept with no connection to the reality. What about dropping them at all, in order to make the cascading algorithm simpler?
Activity
birtles commentedon May 17, 2017
SMIL uses the override level of the cascade for its animation results. However, that was defined before the animations level of the cascade was added and it should probably just contribute to the animations level of the cascade (with CSS animations defined to override SMIL animations as they currently do).
SelenIT commentedon Jul 12, 2017
If I understand correctly, the only place where SMIL spec mentions override CSS declarations refers to the Section 6.1 of the CSS2 spec and to the DOM2CSS spec. Since the former has currently been superseded by CSS Cascade 3 and the latter seems to be abandoned (probably replaced by the CSSOM spec?), maybe we can already make a note in the next level of the Cascade spec like "reference to Override styles in older animation-relates specs should be treated as reference to Animation styles" and simplify the cascade definition?
css-meeting-bot commentedon Nov 1, 2017
The Working Group just discussed
Are 'Override declarations' still a thing?, and agreed to the following resolutions:RESOLVED: remove this from both levels of CSS cascade and replacing the reference with a noteThe full IRC log of that discussion
<dael> Topic: Are 'Override declarations' still a thing?<dael> github: https://github.com//issues/1385
<dael> fremy: From the look I took it's not referenced by CSS. I think it's fine to drop, but I don't know if somebody has a strong opinion. Not easy without enough people on the call.
<dael> dbaron: I think we (Gecko) did remove the override stylesheet API if we had it.
<dael> astearns: Let's leave it as that. We have two options and we'll come back when there's more people.
<dael> fremy: Or we can resolve and if someone disagrees we re-open.
<dael> fremy: In the interest of progress.
<dael> astearns: That's fair. I would have liked to see an opinion fromm Tab with the issue.
<dael> fantasai: Tab and I don't have an opinion. We discussed last week.
<dael> astearns: Looking at the issue the last comment suggests to make a note in last level of cascade spec that we can simplify and have a note.
<dael> fantasai: I'm happy tot ake edits to remove but we can add a note pointing to it that there was a thing that no one impl.
<dael> astearns: This is only next level of css casacde?
<dael> fantasai: Both.
<dael> fantasai: Both are in CR.
<dael> astearns: Obj to removing this from both levels of CSS cascade and replacing the reference with a note?
<fantasai> s/Both./Both. If the feature doesn't exist, it doesn't exist anywhere./
<dael> RESOLVED: remove this from both levels of CSS cascade and replacing the reference with a note
<fantasai> s/CR./CR anyways./
<dael> astearns: Thanks for taking on these edits fantasai
ByteEater-pl commentedon Feb 22, 2020
Why is there no such note in CSS Cascading and Inheritance Level 4 Editor’s Draft? And what was the implementors' problem with this origin?