The DOM level 2 style specs for CSSStyleDeclaration
read as follows:
------- begin citation -----------------------------------------
Interface CSSStyleDeclaration (introduced in DOM Level 2)
The CSSStyleDeclaration interface represents a single CSS declaration block.
This interface may be used to determine the style properties currently set in a
block or to set style properties explicitly within the block.
While an implementation may not recognize all CSS properties within a CSS
declaration block, it is expected to provide access to all specified properties
in the style sheet through the CSSStyleDeclaration interface.
----------- end citation --------------------------------------------------
However, Mozilla currently ignores properties it doesn't recognize in CSS style
declaration blocks, be it in inline styles or in a style rule.
From reading the specs I would expect to be able to find unrecogized properties
in the cssText, to be able to enumerate them with length/item and to read them
with getPropertyValue, at least that would comply with "provide access to all
I will attach a test case which tries these methods.
Created attachment 62674 [details]
test case (has unrecognized property named god in a style rule and inline style and tries to access these)
I wouldn't expect this to be fixed any time soon, nor am I sure we even want to
fix this. You're talking about exposing non-standard meaningless-to-mozilla CSS
properties, I'm afraid I don't see the value in exposing such properties.
Oh, and I think this is a dupe too, but I don't have the number of the other bug
There are several scenarios where this is useful. The most common is to pass
arguments to XBL bindings by adding custom style properties using CSS. For
Mass-reassigning bugs to email@example.com
This really needs to be fixed. It's a vital function for extension developers who wish to delve into the CSS3 stuff such as speech properties which are not calculated by Firefox; our last resort is to simply read in the raw style rule using cssText and process it ourselves - however, at the moment, even this is not possible since cssText does not actually give the text of the style rule.
Fixing this would violate CSS 2.1.
Which rule does it violate?
The value is not a recognized CSS2 value. The value can only be obtained by using the cssText attribute.
This seems to indicate that unrecognized values are accessible through cssText.
Hm... Well, does that mean to drop the cssText entirely? Because it seems to make more sense to simply refuse to parse unknown properties and to not use them to populate the subtree of the rule in the DOM.
But I think the cssText should still exist, because otherwise, how does one access vendor specific extensions as allowed in CSS3?
It may not be a problem if the vendor is the browser developer, but what about other vendors such as screen reader developers?
In my case, it's not even about vendor specific extensions; it's about trying to access the CSS3 speech module rules which aren't implemented in Firefox.
If you want a middle ground, one possibility might be to allow and only parse custom properties that start with a dash prefix, such as '-custom-timeline' just as we have -moz-. This then provides an upgrade path if that property becomes part of a standard, such as the community seeing that adding timelines to things through CSS is useful, so '-custom-timeline' becomes just 'timeline'.
If you don't agree with this I'd love to hear a reason other than "CSS 2.1 doesn't allow it". Standards aren't religions; they are agreements that should codify best practices rather than biblical.
Let me weigh in favor of this being implemented. Think of CSS as AOP in the browser. CSS allows separation of concern between the following 3 parties:
1. The browser defines the meaning of specific CSS properties and executes the relevant CSS rules.
2. The HTML author writes the markup, using appropriate tag and class names, making it semantically meaningful.
3. The CSS author can, without changing the markup, influence the way in which the browser renders that markup.
This works all very nicely. Now consider this slightly different situation:
2. A component author write components that generates HTML markup, with appropriate tag names and class names.
3. An application author using the components wants to influence the way the framework behaves with the components by writing CSS rules, using properties defined by the framework.
For this last scenario to be workable, we need browsers to expose unrecognized CSS properties through CSSStyleDeclaration.
World of Warcraft Interface provides an interesting way to layout elements based on anchors. In order to implement it in the browser, the most natural way is to add a new CSS rule that looks like that:
anchor: [point] [relativeElement] [relativePoint] [x] [y];
#frame | #side |
The sidebar is automatically placed at the right of the frame. The middle left of the side #side is positioned at the middle right of the #frame.
anchor: left #frame right;
This would be particularly useful for people doing cross-browser component libraries, where they call fallback to a JS implementation of unrecognised CSS properties.
Think about a polyfill CSS Grid Layout spec for example.
"New"! Sad, that this is not implemented – we should be able to access the actual rules in a sensible way (as per spec). Would make e.g. a position:sticky polyfill (that doesn't have to set the target element in JS) a _lot_ easier/feasible.
> we should be able to access the actual rules in a sensible way (as per spec)
By "per spec" I mean
While an implementation may not recognize all CSS properties within a CSS declaration block, it is expected to provide access to all specified properties in the style sheet through the CSSStyleDeclaration interface.
says: "Replacements will be provided at some future point."
Strange, how such future never seems to come around ;) Wouldn't it make more sense to first implement a replacement …
And the reasons given:
- "the CSSValue interface is thought to be too awkward for frequent use"
Well, how about infrequent use ;)
- "unknown rules should be dropped by the parser and thus never reach the DOM"
I don't care, whether they reach the DOM, but I (and others) do need access to them, somehow …
Being forced to write my own CSS parser is not necessarily going to improve the situation ;)