[cssom] Define serialization for background shorthand

[Manishearth]

div = document.createElement('div');
div.style.background = "url(a), url(b)";
div.style.backgroundRepeat="no-repeat, no-repeat, no-repeat";
console.log(div.style.background);

This returns "" on Firefox and "url("a") no-repeat, url("b") no-repeat, no-repeat" on Chrome.

div = document.createElement('div');
div.style.background = "url(a), url(b), url(c)";
div.style.backgroundRepeat="no-repeat, repeat,";
console.log(div.style.background);

This returns "" on Firefox and "url("a") no-repeat, url("b") repeat, url("c")" on Chrome.

In case the number of values set is the same, Firefox does return a value:

div = document.createElement('div');
div.style.background = "url(a), url(b), url(c)";
div.style.backgroundRepeat="no-repeat, repeat, no-repeat";
console.log(div.style.background);

("url("a") no-repeat scroll 0% 0%, url("b") repeat scroll 0% 0%, transparent url("c") no-repeat scroll 0% 0%" on Firefox, "url("a") no-repeat, url("b") repeat, url("c") no-repeat" on Chrome)

Firefox seems to only serialize when all set longhands are of the same length (and when it does, it serializes to all default values). Chrome always serializes, and just prints out whatever was set.

This should probably be specced. Important questions to answer:

• Should we truncate everything to the length of the background-image longhand?
• For underspecified longhands, should we cycle through them to make them the same length as background-image?
• Should we be explicit (like FIrefox) or implicit (like Chrome)?
• Is serialization (of a shorthand) allowed to fail if parsing hasn't?

[Manishearth]

cc @SimonSapin

[fantasai]

Agenda+ to ask which level of css-backgrounds this goes into so that I can triage appropriately.

[css-meeting-bot]

The Working Group just discussed Define serialization for background shorthand, and agreed to the following resolutions:

• RESOLVED: postpone this until there's further evidence of use cases and move this to L4 if there is evidence

The full IRC log of that discussion

<dael> Topic: Define serialization for background shorthand
<dael> github: https://github.com//issues/418
<dael> fantasai: Defining serialization when splitting BG into multi long hands. Q is do we tackle in L3 or is L4 okay?
<dael> fantasai: Is it really important to converge now or are people happy to defer?
<dael> Rossen_: I'll piggyback on tantek point for use cases as well as ask if there are any impl that are currently seeing interop issues b/c of this and in any urgency to change their serialization.
<dael> Rossen_: I'm hearing silence which I am taking as no interest or use cases.
<dael> Rossen_: Obj to postponing this until there's further evidence of use cases and move this to L4 if there is evidence?
<tantek> +1 to at least postpone to L4, and note explicitly no use-cases
<florian> tantek: I agree, and even more so once we add the multiple borders we've resolved on, you even do explicit inset/outset at subpixel level on retina screens.
<dael> RESOLVED: postpone this until there's further evidence of use cases and move this to L4 if there is evidence

[fantasai]

So, the css-backgrounds spec currently does not include the truncation/elongation of value lists as part of the process of computing values. So the computed value--the value that is used for inheritance--definitely is the length specified per spec.

As for the output of the CSSOM APIs, if we normalize the list lengths, then roundtripping a value gives different behavior than its initial declaration.

Is serialization (of a shorthand) allowed to fail if parsing hasn't?

I don't know enough about CSSOM to answer this question.

So we have several options here:

• Change the computed values of list-valued properties to reflect the used list length
• Allow CSSOM to break roundtripping of list-valued properties with regards to the length of the list
• Allow CSSOM to fail to return a value for a shorthand

I don't know what's the best option. @dbaron ?

[ewilligers]

More observations of browser behavior:

'background' syntax is specified as

background = <bg-layer># , <final-bg-layer>
<bg-layer> =                                <bg-image> || <bg-position> [ / <bg-size> ]? || <repeat-style> || <attachment> || <box> || <box>
<final-bg-layer> =  <‘background-color’> || <bg-image> || <bg-position> [ / <bg-size> ]? || <repeat-style> || <attachment> || <box> || <box>

However, browsers do not respect the above serialization order - test page

Edge serializes inline style using

<bg-layer> =                                <bg-image> || <attachment> || <repeat-style> || <bg-position> [ / <bg-size> ]? || <box> || <box>
<final-bg-layer> =                          <bg-image> || <attachment> || <repeat-style> || <bg-position> [ / <bg-size> ]? || <box> || <box> || <‘background-color’>

Firefox serializes inline style using

<bg-layer> =                                <bg-image> || <repeat-style> || <attachment> || <bg-position> [ / <bg-size> ]? || <box> || <box>
<final-bg-layer> =  <‘background-color’> || <bg-image> || <repeat-style> || <attachment> || <bg-position> [ / <bg-size> ]? || <box> || <box>

Blink and WebKit serialize inline style using

<bg-layer> =                                <bg-image> || <bg-position> [ / <bg-size> ]? || <repeat-style> || <attachment> || <box> || <box>
<final-bg-layer> =                          <bg-image> || <bg-position> [ / <bg-size> ]? || <repeat-style> || <attachment> || <box> || <box> || <‘background-color’>

Edge and Firefox serialize computed style as empty string.

Blink serializes computed style using

<bg-layer> =                                <bg-image> || <repeat-style> || <attachment> || <bg-position> [ / <bg-size> ]? || <box> || <box>
<final-bg-layer> =  <‘background-color’> || <bg-image> || <repeat-style> || <attachment> || <bg-position> [ / <bg-size> ]? || <box> || <box>

WebKit serializes computed style by interleaving information from the different layers.