The DOM level 2 style specs for CSSStyleDeclaration (http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-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 specified properties". 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 handy.
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 example: selector { -moz-binding: url(someuri); -my-binding-highlight-text: red; }
Mass-reassigning bugs to dom_bugs@netscape.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? According to: http://www.w3.org/TR/DOM-Level-2-Style/css.html Quote: CSS_UNKNOWN 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.
http://lists.w3.org/Archives/Public/www-style/2003Oct/0347
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? http://www.w3.org/TR/css3-syntax 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.
I just want to add that fixing this and allowing it would be great. Yes, technically the CSS 2.1 spec says unknown CSS properties should be ignored. However, I think this was a mistake on their part. It makes it very difficult for wider experimentation to happen in the community to help evolve CSS itself, such as what Safari is doing around declarative CSS animations. I'm a JavaScript toolkit guy, working on Dojo, Really Simple History, etc. I'd love to experiment with adding new CSS properties to help the open web stay competitive with Flash and Silverlight with drop-in JavaScript libraries that can expose new CSS abilities, such as being able to do SMIL-like things with CSS. In fact, I'd argue this is how the web _should_ work; the CSS Working Group _shouldn't_ be trying to innovate. Instead, there should be extension mechanisms that allow folks like myself, Safari, and others to try out new things with CSS. Those that succeed can be cannonized and described in standards. Those that don't can be left on the cutting room floor. The JavaScript folks can try out things, then they can migrate to browsers, then they can migrate to standards; JQuery's query-based syntax had a similar path, starting as an edge innovation then moving into querySelectorAll for native support. 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: 1. The author of a framework written in JavaScript defines the meaning of specific CSS properties and executes the relevant CSS rules. 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]; Example: Sidebar ---------| |-------| | | #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. #side { anchor: left #frame right; } Semantically, I want anchor to be added in the CSS because it's where it belongs. However since I can't access this property, I will have to place it in the HTML where I can control it from Javascript.
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. """ https://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSStyleDeclaration
And http://lists.w3.org/Archives/Public/www-style/2003Oct/0347 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 ;)
or
