Open Bug 91370 Opened 23 years ago Updated 2 years ago

Implement setting cssText on various CSSRule implementations


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






(Reporter: bzbarsky, Unassigned)



(Keywords: dom2, Whiteboard: [webcompat])

setting cssText doesn't work anywhere at the moment.

It needs to work in:


Most of the work for nsDOMCSSDeclaration is done already, so making that work is
a one-line change:

-  // XXX TBI
-  return NS_OK;
+  return ParseDeclaration(aCssText, PR_FALSE, PR_TRUE);

Arguably, this is the most likely-to-be-used case, so it may be worth checking
in on its own.
Keywords: dom2
Peter, would you please review bz's patch in his comment above?
Whiteboard: [HAVE FIX]
Target Milestone: --- → mozilla0.9.8
sr=jst, bz, would you be able to check this one in?
Checked in.  Leaving open for now... we could make this the SetCssText metabug
or resolve it and file a bunch of new bugs..
Whiteboard: [HAVE FIX]
Target Milestone: mozilla0.9.8 → Future
Mass-reassigning bugs to
Assignee: jst → dom_bugs
Still needed? (Or: has anything been decided past 4 years?)
Ignore comment 7. It seems setting cssText is not implemented. At least not for cases like

  document.styleSheets[0].cssRules[0].cssText = "p { background:lime }"

although it doesn't throw either.

On setting it should also be checked if the statement conforms to the syntax rules. If not, SYNTAX_ERR must be thrown. If one of the declarations is invalid, it should be dropped and not form part of the setted value. And you also should not be allowed to change the type of rule. That raises a INVALID_MODIFICATION_ERR exception...
> If not, SYNTAX_ERR must be thrown.

I don't think we want to do this.  Unknown CSS is Unknown CSS -- this case should not differ from the invalid declaration case; in fact the two cannot be told apart.
Currently you throw for `p:-test- { background:lime }` for example, but not for `p { foo:bar }` (using insertRule).
Yeah, that's what the DOM2 CSS spec says; I now repent of implementing it that way.  I think we might even have a bug on it; I know dbaron has commented about it in the past.
Assignee: general → nobody
QA Contact: ian → general
Is there a reason the patch in comment 1 has not landed?
Assuming you mean comment0, it has.  See comment 4.
Yes, sorry, I meant #0.  I am confused because it doesn't seem to be landed:
QA Contact: general → style-system
Blocks: 137687
This came up in an issue about Google Drive.
Whiteboard: [webcompat]
That doesn't look relevant to this bug at all.  The code linked there is doing:

  e = fb(d.querySelectorAll("*"));
                   var g = e[f],  
       = l;

so I'm pretty sure "g" is an element.  Setting .cssText on an element's .style works perfectly fine and has for 15 years, ever since comment 4.

The real issue you seem to be running into there is that _getting_ .cssText on computed style always returns an empty string in Gecko, whereas in Chrome it returns a very long string of all the computed styles.  Looks like bug 137687 tracks this; this bug does NOT block that one.
No longer blocks: 137687
Summary: Implement setting cssText → Implement setting cssText on various CSSRule implementations
Priority: -- → P3

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

Type: defect → enhancement
Webcompat Priority: ? → ---
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.