-
Notifications
You must be signed in to change notification settings - Fork 693
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[cssom-1] How to serialize specified value of properties with a var()? #6484
Comments
Another interesting test-case is something not involving comments like:
Chrome serializes |
Yeah that follows from the "parse as token stream then serialize directly from the tokens" strategy. |
Yeah, that's right. Since we (should) serialize |
I'm fine with specifying that, it just needed to be made clear. If you're willing to make the impl change in Chrome, then Firefox can stay as-is, and @emilio and I can figure out between the two of us whether this requires spec edits to CSSOM or Variables. ^_^ |
cc @kbabbitt |
I notice that Firefox trims leading whitespace(s) of the original string and that other consecutive whitespace(s) are kept, (consecutive whitespaces are replaced by EDIT: I should have read #774, #881 and #6345 before. I understand that your intent is to define that the original string (and its leading whitespaces?) should be kept. To serialize a CSS value, the declaration value should be represented as a list of CSS component values |
Right, as per those issues you linked in your edit, leading (and trailing) whitespace is trimmed by the Syntax spec before anything else has a chance to see the value, and then the serialization algo puts a single space after the colon before the property value. So Firefox is correct.
I'm sorry, I'm not quite sure what you mean by this question. Could you elaborate? |
Then the trailing whitespace should be removed when serializing EDIT: following Emilo's answer, I filled this bug.
I understand from the procedure to serialize a CSS value that it expects component value(s) to be used. The current definition of a component value does not include a string, but only preserverd tokens, function, and block. And I understand from the above comments that a Therefore I was wondering if a component value can be string. But I realize that I can just understand that these cases (custom property and |
Yeah, I think that is a Gecko bug, mind filing it? |
|
e1.style.color = 'var(--color) '
e2.style = 'color: var(--color) ;'
e1.style.color === e2.style.color // ? Am I missing something or is it missing from parse a list of component values? 1. Normalize input, and set input to the result.
- 2. Repeatedly consume a component value from input until an `<EOF-token>` is returned, appending the returned values (except the final `<EOF-token>`) into a list. Return the list.
+ 2. Repeatedly consume a component value from input until an `<EOF-token>` is returned, appending the returned values (except any trailing whitespaces and the final `<EOF-token>`) into a list. Return the list. |
Please allow me to explain the issue more clearly: Case 1:
Result: Case 2: Result: I suggested a change in my previous comment that removes the trailing whitespace in case 2, but it is missing consume a run of whitespace or something to trim any leading whitespace. I assume that a side effect of the suggested change is that leading/trailing comments would be removed, eg. |
In addition to my comment in #8533 (only |
(continuing topic from #5685)
It's not currently well-specified how serialization for specified values of non-custom properties should behave when they have a var() reference.
That's a lot of words! I'm referring to this example:
Currently, Chrome serializes this as
var(--bar)
, while Firefox serializes it as/* foo */ var(--bar)
. (I'm not sure what WebKit does.)All browser, when given a property without a variable reference, like
color: /* foo */ red;
, serialize the specified value as just the keyword, without the comments.In the f2f earlier today, @emilio argued that Firefox's behavior is because it holds onto the original string for properties with variable references, and serializing using it is simplest. I think that Chrome's behavior is because it stores props with var() references as a token stream (throwing away comments), and just reserializes from the token stream.
The text was updated successfully, but these errors were encountered: