As for the first two failures, checking for the `content` and `strict` keywords: it looks like we tag those keywords with their own dedicated bit (bits 6 and 7) in our representation: https://searchfox.org/mozilla-central/rev/e6a03adbf7930ae0cf131cc3274c80b2aae74e51/servo/components/style/values/specified/box.rs#1382-1385 I suspect those bits are non-functional aside from preserving those keywords (if they're what was specified) in the computed style. This also means that we don't automatically abbreviate to use those keywords in the computed style if they weren't present in the specified style, though. If you compare these two testcases (check your web console): ``` data:text/html,<div id="foo" style="contain:strict"></div><script>console.log(window.getComputedStyle(foo).contain)</script> ``` ``` data:text/html,<div id="foo" style="contain:size layout style paint"></div><script>console.log(window.getComputedStyle(foo).contain)</script> ``` ...you can see that Firefox uses the longhand form (as-it-was-specified) in the latter case, whereas Chrome produces the shorter `strict` keyword there. https://drafts.csswg.org/css-contain-1/#contain-property has a `PROPOSED CORRECTION 1` block above the definition of the property which asserts that we're (a) *not* supposed to care about whether one of the short keywords were used, and (b) we're supposed to serialize back to a short keyword if it's equivalent (due to the shortest serialization principle). I'm not sure the shortest serialization principle is well-defined; but also, I suspect this is simple to fix and nice for interop & brevity, so we might as well just fix it.
Bug 1744309 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
As for the first two failures, checking for the `content` and `strict` keywords: it looks like we tag those keywords with their own dedicated bit (bits 6 and 7) in our representation: https://searchfox.org/mozilla-central/rev/e6a03adbf7930ae0cf131cc3274c80b2aae74e51/servo/components/style/values/specified/box.rs#1382-1385 I suspect those bits are non-functional aside from preserving those keywords (if they're what was specified) in the computed style. This also means that we don't automatically abbreviate to use those keywords in the computed style if they weren't present in the specified style, though. If you compare these two testcases (check your web console): ``` data:text/html,<div id="foo" style="contain:strict"></div><script>console.log(window.getComputedStyle(foo).contain)</script> ``` ``` data:text/html,<div id="foo" style="contain:size layout style paint"></div><script>console.log(window.getComputedStyle(foo).contain)</script> ``` ...you can see that Firefox uses the longhand form (as-it-was-specified) in the latter case, whereas Chrome produces the shorter `strict` keyword there. https://drafts.csswg.org/css-contain-1/#contain-property has a `PROPOSED CORRECTION 1` block above the definition of the property which asserts that we're (a) *not* supposed to care about whether one of the short keywords were used, and (b) we're supposed to serialize back to a short keyword if it's equivalent (due to the shortest serialization principle). And it links out to this very WPT test as a test for that. I'm not sure the shortest serialization principle is well-defined; but also, I suspect this is simple to fix and nice for interop & brevity, so we might as well just fix it.
As for the first two failures, checking for the `content` and `strict` keywords: it looks like we tag those keywords with their own dedicated bit (bits 6 and 7) in our representation: https://searchfox.org/mozilla-central/rev/e6a03adbf7930ae0cf131cc3274c80b2aae74e51/servo/components/style/values/specified/box.rs#1382-1385 I suspect those bits are non-functional aside from preserving those keywords (if they're what was specified) in the computed style. This also means that we don't automatically abbreviate to use those keywords in the computed style if they weren't present in the specified style, though. If you compare these two testcases (check your web console): ``` data:text/html,<div id="foo" style="contain:strict"></div><script>console.log(window.getComputedStyle(foo).contain)</script> ``` ``` data:text/html,<div id="foo" style="contain:size layout style paint"></div><script>console.log(window.getComputedStyle(foo).contain)</script> ``` ...you can see that Firefox uses the longhand form (as-it-was-specified) in the latter case, whereas Chrome produces the shorter `strict` keyword there. https://drafts.csswg.org/css-contain-1/#contain-property has a `PROPOSED CORRECTION 1` block above the definition of the property which asserts that we're (a) *not* supposed to care about whether one of the short keywords were used, and (b) we're supposed to serialize back to a short keyword if it's equivalent (due to the shortest serialization principle). And it links out to this very WPT test as a test for that. I'm not sure the shortest serialization principle is well-defined (see resolution in https://github.com/w3c/csswg-drafts/issues/1564#issuecomment-365680255 ); but also, I suspect this is simple to fix and nice for interop & brevity, so we might as well just fix it.
As for the first two failures, checking for the `content` and `strict` keywords: it looks like we tag those keywords with their own dedicated bit (bits 6 and 7) in our representation: https://searchfox.org/mozilla-central/rev/e6a03adbf7930ae0cf131cc3274c80b2aae74e51/servo/components/style/values/specified/box.rs#1382-1385 I suspect those bits are non-functional aside from preserving those keywords (if they're what was specified) in the computed style. This also means that we don't automatically abbreviate to use those keywords in the computed style if they weren't present in the specified style, though. If you compare these two testcases (check your web console): ``` data:text/html,<div id="foo" style="contain:strict"></div><script>console.log(window.getComputedStyle(foo).contain)</script> ``` ``` data:text/html,<div id="foo" style="contain:size layout style paint"></div><script>console.log(window.getComputedStyle(foo).contain)</script> ``` ...you can see that Firefox uses the longhand form (as-it-was-specified) in the latter case, whereas Chrome produces the shorter `strict` keyword there. https://drafts.csswg.org/css-contain-1/#contain-property has a `PROPOSED CORRECTION 1` block above the definition of the property which asserts that we're (a) *not* supposed to care about whether one of the short keywords were used, and (b) we're supposed to serialize back to a short keyword if it's equivalent (due to the shortest serialization principle). And it links out to this very WPT test as a test for that. I'm not sure the shortest serialization principle is well-defined (see resolution in https://github.com/w3c/csswg-drafts/issues/1564#issuecomment-365680255 and also https://github.com/w3c/csswg-drafts/issues/1564#issuecomment-365683157 ); but also, I suspect this is simple to fix and nice for interop & brevity, so we might as well just fix it.