[css-cascade] About omitted subproperty value in shorthand #1068
Comments
|
Um, how are you detecting this difference? Any difference here should be undetectable. https://www.w3.org/TR/css-cascade-3/#initial |
|
Easy: get the specified value via CSSOM, which is the value before cascading. e.g. <!DOCTYPE html>
<div style="background: none"></div>
<script>
var elem = document.querySelector('div');
alert(elem.style.backgroundColor);
</script>gives us
Also, by "makes serialization code more complicated" in my first post, I meant I imagine that it makes serialization code potentially more complicated and error-prone in all browsers if follow that way, not just in Servo. At least, makes shorthand harder to round-trip. For example, Blink has this kind of behavior that <!DOCTYPE html>
<div style="background: none; background-size: 10px; background-position: initial;"></div>
<script>
var elem = document.querySelector('div');
alert(elem.style.backgroundPosition); // -> "initial"
elem.style.cssText = elem.style.cssText;
alert(elem.style.backgroundPosition); // -> "0% 0%"
</script>And WebKit is somehow worse in this case that the second one returns empty directly. This kind of issues are fixable, but that just makes the logic unnecessarily complicated. |
|
A probably more interesting one: <!DOCTYPE html>
<div style="background: none, none"></div>
<script>
var elem = document.querySelector('div');
alert(elem.style.cssText);
elem.style.backgroundPosition = elem.style.backgroundPosition;
alert(elem.style.cssText);
elem.style.cssText = elem.style.cssText;
alert(elem.style.cssText);
</script>This has different behavior between Chrome and Safari, and they both fail to round-trip in this case. Their three output of |
|
I have been advocating internally for some time already we should probably match Chrome. This is more useful to developers than the current behavior. That being said, @dbaron has a general preference for the more backwards-compatible option when it comes to serialization, which would be the Edge/Firefox behavior. I would argue that if Chrome/Safari were able to switch we should be just fine doing so too, but at the same time switching isn't a big priority for us :-) Do you have compat data that prompted you to ask, or is it just a question on what the new gecko/servo style engine should do? |
|
It doesn't seem to me Chrome's behavior is more useful. It seems more buggy and unpredictable. I agree that shorthand serialization omitting unspecified values probably has some value, but I would argue that it makes things more complicated than it should be. And simply omitting initial values in shorthand serialization when possible (rather than parsing omitted values as As I stated before, there is no compat issue so far. It is just a question raised when I was looking at Servo's code and realized why it was so buggy. |
|
Oh I was not speaking about cssText serialization, but more that I like el.style.backgroundSize returning "initial" instead of "auto" because "auto" was never specified by the author; the property has its "initial| value instead, which happens to be auto. For shorthands I think what Edge does is more pleasant but requires written rules for every property and as far as I can remember the current proposal by Google (by shane I think) was to define more general rules but these were not ready last f2f so it hasn't been discussed extensively yet. |
As I mentioned before, making it return What would you expect from the following code to output? <!DOCTYPE html>
<div id="ref" style="background: url(#a), url(#b)"></div>
<div id="test"></div>
<script>
var ref = document.getElementById('ref');
var test = document.getElementById('test');
alert(ref.style.backgroundSize);
test.style.backgroundSize = ref.style.backgroundSize;
alert(test.style.backgroundSize);
</script> |
|
Lists form a poorly thought part of css. The fact you cannot "initial" a part of a list is annoying and could be fixed. That would make Chrome's return value valid and solve the problem you are mentioning. |
|
That way, a lot more questions would be open, e.g. what about Also, if we allow I didn't say it is not feasible to do that... I just wonder whether it's worth the effort to fix that in the hard way. IIRC, @tabatkins mentioned that he was considering making it possible to cascade individual entry in a list separately, which may change the landscape of how this kind of things should behave. |
|
Yep, tab and myself do agree for a long time now that list items should be able to cascade separately, which would mean that supporting css keywords for individual list entries would make a lot of sense. Just, as you mention, this has never been a priority enough to actually happen, but there are proposals on the table. |
|
Making list entry an atomic value and allowing it to have CSS-wide keywords probably make sense. It is more tricky when it comes to other shorthand properties. Anyway, I think the bottom line is that serialization and parsing should be able to round-trip, so we need to consider them simultaneously when we want to introduce significant change to either. |
|
As this still seems unresolved, and I think the discussion above shows it's something that just needs (hopefully) a few minutes and a group resolution to move forward, I'm re-adding Agenda+. |
|
And although it mainly affects lists, other shorthands are also affected, like |
|
I'm removing the Agenda+; there's nothing for the group to discuss. The spec is clear; the @upsuper Safari is just straight up broken in that "font" example - that's not a valid "font" shorthand at all. |
|
I think the spec is clear, but it seems
So it's probably at least worth a note in the spec to clarify this, and probably ask Blink and WebKit to change their behavior to follow the spec (or reversely), so that authors wouldn't start depending on unspeced behavior of Blink and WebKit in the future. |
|
Could somebody file Blink and WebKit bugs? |
|
I think this is the Webkit variant: |
|
Thanks, jet. I think given both Blink and WebKit have an issue open from their developers for this issue, we can probably close this, since it seems they do agree with the specced behavior, and are just not active on fixing them. |
|
So the specced behavior is that you use the initial value of the property and not initial, right? That should pretty much be what we do, I liked returning "intial" better but it is true that it just doesn't work well with the rest of css, the font example is pretty convincing. |
|
Yeah, per @upsuper's original post, the spec says:
|
There is an implementation difference on what should happen for omitted subproperty value in shorthand.
Currently, Gecko and Edge reset missing subproperties in shorthand to their initial value as a declared value, while Blink and WebKit sets them to the
initialkeyword.The spec says:
so it seems to me Gecko and Edge match what the spec says. But I can see that the text here can be easily misunderstood given the existence of
initialkeyword.Can we add a note to the spec to emphasize that it is not resetting missing subproperties to the
initialkeyword? This may be worth adding a new CSSOM test into wpt.I found this when I'm fixing Servo's code, which somehow largely followed the WebKit's way, and thus fails lots of tests in Gecko. It seems to me setting
initialvalue to subproperties makes serialization code more complicated because individual shorthands would need to take CSS-wide keywords into consideration as well (and consequently lots of bugs in Servo serialization code in edge cases), so I don't want to adopt WebKit's approach here.There is no known web-compat issue so far, but this is a detectable difference, so I also hope Blink and WebKit can fix this before any real web-compat issue appears.
The text was updated successfully, but these errors were encountered: