[multiple] Serialization of rules #4828
Comments
|
Agenda+ to bring the issue into general awareness; I don't expect us to decide these questions in the call. |
|
Yeah it would be good to get some discussion on this, so for example fonts 4 can say how to serialize the at-rules it has (or I can give input on what goes in CSSOM. However, we recently decided to move color serialization from CSSOM to color 4, so...) |
|
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: [multiple] Serialization of rules<dael> github: https://github.com//issues/4828 <dael> TabAtkins: Merged a PR to spec how to serialize @Property. Decided to serialize in one line. <dael> TabAtkins: Fine but wanted consistent. I looked arounda nd couldn't find one spec on how to serialize rules. But I think we tend to serialize multi line. <dael> TabAtkins: I would like to define this, prob in CSSOM, with descriptors. Then we need to decide if it's on a single line or multi-line with indents <dael> florian: I have vague memory of doing something like this in preso and trying to align to where a line is broken. I vaguely remember compat problems <dael> emilio: style rules seem to be one line <dael> Rossen_: Is prop to allow multi-line but not define how and where you should break? <dael> TabAtkins: No, no. I would like precise spec. We have it for whitespace and we need that level <dael> florian: I support doing this, write something sensible, and then if compat says we can't at least we know where <dael> emilio: I think impl are somewhat consistent so I don't think would be hard. Happy to help <dael> Rossen_: Don't see pushback on multi line <dael> emilio: Biggest is that's not what browsers do <dael> Rossen_: Compat risk? <dael> TabAtkins: If there's compat we should follow that. emilio is right style is one line so we should consistently do that <dael> florian: Seems sad too but okay <dael> Rossen_: Prop: Specify serialization is one line? <dael> TabAtkins: Prop: We define this is CSSOM to match browser compat as much as it exists. <dael> TabAtkins: emilio or I can write it out <dael> Rossen_: Objections? <dael> RESOLVED: We define this is CSSOM to match browser compat as much as it exists. |
|
So it turns out browser's aren't consistent: <!DOCTYPE html>
<style>
@font-face {
font-family: foo; src: url(foo);
font-weight: bold;
}
</style>
<script>
w(document.styleSheets[0].cssRules[0].cssText);
</script>Chrome puts all of it on one line. Firefox puts each descriptor on its own line. @emilio You expressed during the call a preference for single-line, I think? Are you okay with specifying that and getting Firefox to fix? |
|
But with |
|
ew, what a mess. I think changing style rules is a no-go, so I'd be happy to do everything in one line if other browsers are happy with that too. |
|
Ah, yeah, both Chrome and Firefox do style rules on a single line, and I agree that's the most common case and most likely to be depended on, so we should go with that. |
|
https://drafts.csswg.org/cssom/#serialize-a-css-rule does have some text that matches Firefox and Chrome. Spec for some rules is missing and we should add it though. |
…s and style rules. Style rules serialize on one line and so should @font-face blocks. Part of w3c/csswg-drafts#4828. Differential Revision: https://phabricator.services.mozilla.com/D89302 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1663231 gecko-commit: b021c9737f2bd71713c487ccb0410bd335edd5ba gecko-reviewers: xidorn
… other browsers and style rules. r=xidorn Style rules serialize on one line and so should @font-face blocks. Part of w3c/csswg-drafts#4828. Differential Revision: https://phabricator.services.mozilla.com/D89302
…s and style rules. Style rules serialize on one line and so should @font-face blocks. Part of w3c/csswg-drafts#4828. Differential Revision: https://phabricator.services.mozilla.com/D89302 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1663231 gecko-commit: b021c9737f2bd71713c487ccb0410bd335edd5ba gecko-reviewers: xidorn
…ther browsers and style rules. r=xidorn Style rules serialize on one line and so should font-face blocks. Part of w3c/csswg-drafts#4828. Differential Revision: https://phabricator.services.mozilla.com/D89302 UltraBlame original commit: b021c9737f2bd71713c487ccb0410bd335edd5ba
…ther browsers and style rules. r=xidorn Style rules serialize on one line and so should font-face blocks. Part of w3c/csswg-drafts#4828. Differential Revision: https://phabricator.services.mozilla.com/D89302 UltraBlame original commit: b021c9737f2bd71713c487ccb0410bd335edd5ba
…ther browsers and style rules. r=xidorn Style rules serialize on one line and so should font-face blocks. Part of w3c/csswg-drafts#4828. Differential Revision: https://phabricator.services.mozilla.com/D89302 UltraBlame original commit: b021c9737f2bd71713c487ccb0410bd335edd5ba
… other browsers and style rules. r=xidorn Style rules serialize on one line and so should @font-face blocks. Part of w3c/csswg-drafts#4828. Differential Revision: https://phabricator.services.mozilla.com/D89302
…browsers and style rules. Style rules serialize on one line and so should @font-face blocks. Part of w3c/csswg-drafts#4828. Differential Revision: https://phabricator.services.mozilla.com/D89302
I just merged a PR (w3c/css-houdini-drafts#980) specifying how to serialize an
@propertyrule. I wasn't sure whether it should all be serialized on one line (as the PR specified, and now in the draft), or if they should be indented on a newline, so I went looking for precedents, and it doesn't appear we have any.Afaict, no spec defines how to serialize rules at all: not CSSOM, nor any spec that defines its own at-rules, like Conditional or Animations.
I presume we want to specify this so we can be consistent, and can test rule serialization? How should it work? Where should such a definition live - individual specs, or in CSSOM, or general rules in CSSOM with explicit hooks that individual specs have to define for serialization of preludes and which descriptors to include?
The text was updated successfully, but these errors were encountered: