116694 - unrecognized CSS properties are not accessible through CSSStyleDeclaration

Status: NEW

(Core :: DOM: CSS Object Model, enhancement)

Description

[Martin Honnen]

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.

Comment 1

[Martin Honnen]

Attachment: test case (has unrecognized property named god in a style rule and inline style and tries to access these)

Comment 2

[Johnny Stenback (:jst)]

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.

Comment 3

[Erik Arvidsson]

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;
}

Comment 4

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 5

[clc4tts]

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.

Comment 6

[Anne (:annevk)]

Fixing this would violate CSS 2.1.

Comment 7

[clc4tts]

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.

Comment 8

[Anne (:annevk)]

http://lists.w3.org/Archives/Public/www-style/2003Oct/0347

Comment 9

[clc4tts]

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.

Comment 10

[Brad Neuberg]

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.

Comment 11

[Alessandro Vernet]

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.

Comment 12

[vjeuxx]

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.

Comment 13

[miguel.camba]

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.

Comment 14

[Valentin Born]

"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.

Comment 15

[Valentin Born]

> 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

Comment 16

[Valentin Born]

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 ;)

Comment 17

[Armen Michaeli]

One very good reason to "pass through" unknown/unrecognized/"invalid" declarations (property-value pairs) via one or the other CSS API -- whether an existing one like Window::getComputedStyle or something else where one can obtain these values after the UA has already had a pass at parsing e.g. a stylesheet -- is to enable "polyfilling" CSS modules. For instance, consider the very fresh "CSS Anchor Positioning" spec., which Google and Mozilla already have declared intent to implement (meaning it's well on the way to become a standard). If I were to write some pop-up logic for a site, I could just invent my own API or -- in light of the fact the former will most likely find its way into Firefox and Chrome/Edge -- just "polyfill" an implementation while anticipating native support, at which point I at least won't have to re-factor the client code (ideally) or even remove polyfilling (which by nature is conditional on missing support).

The problem with "polyfilling" an implementation of the aforementioned CSS specification, has to do with the fact that, like most spec's of the kind, it introduces new CSS properties, like anchor-name etc. A "polyfill" would depend on being able to at least find the declarations of these properties in style objects through e.g. a script, so that it can implement their interpretation and so on -- anchoring elements as specified.

But I can't -- since the CSS parser "strips" or effectively "hides" the declarations UA doesn't support for this or that module.

A recourse might be to implement a CSS parser in a script, and feed every one of the same stylesheet(s) that is already linked to the document, as means to locate properties like anchor-name which the "native" CSS APIs do not vend and pretend were never there. But such an alternative in my opinion borders on insanity what regards cost-benefit -- if I were to consider my immediate problem of implementing pop-ups in some reusable fashion, such that e.g. need anchoring on non-ancestor elements which is what the aforementioned spec. describes, it would be a much more sound investment to just write a script that does this without any claim to alignment with some spec that requires access to novel properties.

As for solutions to the "we can't make the parser vend invalid properties because that would break CSS [2] compatibility" problem -- what if CSS introduced the kind of document conformance not unlike (conceptually) HTML "doctype" definition? E.g. through a new at-rule like @version, somehow specifying compliance intent. None of the existing stylesheets, by the nature of things, would be featuring such rule and thus can have the parser/APIs stay in the "quirk" mode (backwards-compatible), while stylesheets featuring e.g. @version 4; can allow the UA to behave in a manner where unknown properties are visible to and usable by API clients?