Intent to Implement and Ship: Make CSSOM APIs append rather than replace slots in the declaration block
60 views
Skip to first unread message
Emilio Cobos Álvarez
May 15, 2018, 7:32:26 AM5/15/18
to blink-dev, Rune Lillesveen, taba...@google.com
Contact emails:
Emilio Cobos Álvarez (emi...@chromium.org, emi...@mozilla.com)
Spec:
https://drafts.csswg.org/cssom/#set-a-css-declaration
Summary:
We change the behavior of the CSSOM APIs when the property to set is
already specified to append to the declaration block instead of
replacing the slot.
For example, if you had:
<div id="test" style="color: red; padding: 10px;"></div>
And you did:
test.style.color = "green";
Before the change you'd get:
<div id="test" style="color: green; padding: 10px;"></div>
And afterwards:
<div id="test" style="padding: 10px; color: green;"></div>
Motivation:
The reasoning for this is that the current behavior interacts very
poorly with logical properties and mutation events / mutation observers
of the style attribute. There's a lengthy discussion and CSSWG
resolution in:
https://github.com/w3c/csswg-drafts/issues/1898
As for the motivation for me submitting this patch to Blink, see below.
Risks:
Interoperability and Compatibility:
Regarding support from other vendors, this was resolved in a CSSWG F2F
with members from all vendors in the room actively participating in the
discussion, so I'd say all vendors publicly support this.
Firefox implemented this change already in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1415330
Which is currently in Firefox Beta.
This change has some risk though, and one broken website was reported in
Firefox because of this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1460295
That website mutates the style attribute in a DOMSubtreeModified event
callback, triggering itself more mutations that before (contrary to the
spec) weren't fired.
This is my main motivation for submitting the change. I fear that Gecko
would need to back out this change or cope with a few webcompat bugs if
other engines like Blink don't adopt the spec resolution soon as well,
and I don't see any other way to make the interactions between logical
properties and CSSOM sound.
Note, though, that that particular website wouldn't be broken on Blink /
WebKit anyways because Blink doesn't support the DOMAttrModified event /
doesn't fire DOMSubtreeModified when an attribute changes (only when
it's added / removed), as it can be seen in
https://bug1460295.bmoattachments.org/attachment.cgi?id=8975780. I'm
trying to sort out what the right thing to do there is on Gecko's side.
My intention is to submit a WebKit patch too if this intent goes well.
In general I think that the risk is low over-all, and we haven't heard
of more breakage than that particular case, which wouldn't affect Blink.
But I think it was worth to point that out.
Ergonomics:
This is an existing and commonly used API, and its behavior is closer to
what authors would expect in cases where logical properties are involved.
Debuggability:
No changes in devtools or similar should be needed.
Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes, tests for this spec and implementation change were added in
https://github.com/w3c/web-platform-tests/pull/10354.
Other related tests were added in
https://github.com/w3c/web-platform-tests/pull/10429.
Requesting approval to ship?
Yes
Thanks for reading,
-- Emilio
Emilio Cobos Álvarez (emi...@chromium.org, emi...@mozilla.com)
Spec:
https://drafts.csswg.org/cssom/#set-a-css-declaration
Summary:
We change the behavior of the CSSOM APIs when the property to set is
already specified to append to the declaration block instead of
replacing the slot.
For example, if you had:
<div id="test" style="color: red; padding: 10px;"></div>
And you did:
test.style.color = "green";
Before the change you'd get:
<div id="test" style="color: green; padding: 10px;"></div>
And afterwards:
<div id="test" style="padding: 10px; color: green;"></div>
Motivation:
The reasoning for this is that the current behavior interacts very
poorly with logical properties and mutation events / mutation observers
of the style attribute. There's a lengthy discussion and CSSWG
resolution in:
https://github.com/w3c/csswg-drafts/issues/1898
As for the motivation for me submitting this patch to Blink, see below.
Risks:
Interoperability and Compatibility:
Regarding support from other vendors, this was resolved in a CSSWG F2F
with members from all vendors in the room actively participating in the
discussion, so I'd say all vendors publicly support this.
Firefox implemented this change already in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1415330
Which is currently in Firefox Beta.
This change has some risk though, and one broken website was reported in
Firefox because of this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1460295
That website mutates the style attribute in a DOMSubtreeModified event
callback, triggering itself more mutations that before (contrary to the
spec) weren't fired.
This is my main motivation for submitting the change. I fear that Gecko
would need to back out this change or cope with a few webcompat bugs if
other engines like Blink don't adopt the spec resolution soon as well,
and I don't see any other way to make the interactions between logical
properties and CSSOM sound.
Note, though, that that particular website wouldn't be broken on Blink /
WebKit anyways because Blink doesn't support the DOMAttrModified event /
doesn't fire DOMSubtreeModified when an attribute changes (only when
it's added / removed), as it can be seen in
https://bug1460295.bmoattachments.org/attachment.cgi?id=8975780. I'm
trying to sort out what the right thing to do there is on Gecko's side.
My intention is to submit a WebKit patch too if this intent goes well.
In general I think that the risk is low over-all, and we haven't heard
of more breakage than that particular case, which wouldn't affect Blink.
But I think it was worth to point that out.
Ergonomics:
This is an existing and commonly used API, and its behavior is closer to
what authors would expect in cases where logical properties are involved.
Debuggability:
No changes in devtools or similar should be needed.
Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes, tests for this spec and implementation change were added in
https://github.com/w3c/web-platform-tests/pull/10354.
Other related tests were added in
https://github.com/w3c/web-platform-tests/pull/10429.
Requesting approval to ship?
Yes
Thanks for reading,
-- Emilio
Emilio Cobos Álvarez
May 15, 2018, 7:39:35 AM5/15/18
to blin...@chromium.org
Oh, this is tracked in [1] and patch is at [2], btw.
[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=782407
[2]: https://chromium-review.googlesource.com/c/chromium/src/+/1054867
[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=782407
[2]: https://chromium-review.googlesource.com/c/chromium/src/+/1054867
Tab Atkins
May 15, 2018, 2:15:34 PM5/15/18
to emi...@mozilla.com, blink-dev, fut...@chromium.org
LGTM, this is a necessary fix
On Tue, May 15, 2018 at 4:32 AM Emilio Cobos Álvarez <emi...@mozilla.com>
wrote:
On Tue, May 15, 2018 at 4:32 AM Emilio Cobos Álvarez <emi...@mozilla.com>
wrote:
Rune Lillesveen
May 15, 2018, 4:48:15 PM5/15/18
to Tab Atkins, emi...@mozilla.com, blink-dev
non-owner lgtm
Rune Lillesveen
Daniel Bratell
May 16, 2018, 11:02:10 AM5/16/18
to Tab Atkins, Rune Lillesveen, emi...@mozilla.com, blink-dev
LGTM1.
I wish there was some way to determine the risk, but I can't think of one beside letting it out in the wild.
/Daniel
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeRbjD%3D0mO-cJtXTq7_OSGv5X1FZsec-33YBz-UiryHhSg%40mail.gmail.com.
--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */
Yoav Weiss
May 17, 2018, 4:18:18 AM5/17/18
to Daniel Bratell, Tab Atkins, Rune Lillesveen, emi...@mozilla.com, blink-dev
On Wed, May 16, 2018 at 5:02 PM Daniel Bratell <bra...@opera.com> wrote:
LGTM1.I wish there was some way to determine the risk, but I can't think of one beside letting it out in the wild.
Is it possible to ship this as an experiment and track e.g. script responsiveness and/or long tasks in order to evaluate the risk here?
Do you have minutes from that discussion? (Or other public artifacts that indicate all vendors supporting this)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zi331lnzrbppqq%40cicero2.linkoping.osa.
Emilio Cobos Álvarez
May 17, 2018, 8:05:25 AM5/17/18
to Yoav Weiss, Daniel Bratell, Tab Atkins, Rune Lillesveen, blink-dev
On 05/17/2018 10:18 AM, Yoav Weiss wrote:
>
> On Wed, May 16, 2018 at 5:02 PM Daniel Bratell <bra...@opera.com
>
> __
> LGTM1.
>
> I wish there was some way to determine the risk, but I can't think
> of one beside letting it out in the wild.
>
>
> Is it possible to ship this as an experiment and track e.g. script
> responsiveness and/or long tasks in order to evaluate the risk here?
>
>
>
> /Daniel
>
> On Tue, 15 May 2018 22:48:00 +0200, Rune Lillesveen
> <fut...@chromium.org <mailto:fut...@chromium.org>> wrote:
>
> non-owner lgtm
>
> On Tue, May 15, 2018 at 8:15 PM Tab Atkins <taba...@google.com
> <mailto:taba...@google.com>> wrote:
>
> LGTM, this is a necessary fix
> On Tue, May 15, 2018 at 4:32 AM Emilio Cobos Álvarez
> <emi...@mozilla.com <mailto:emi...@mozilla.com>>
>
> I wish there was some way to determine the risk, but I can't think
> of one beside letting it out in the wild.
>
>
> Is it possible to ship this as an experiment and track e.g. script
> responsiveness and/or long tasks in order to evaluate the risk here?
>
>
>
> /Daniel
>
> On Tue, 15 May 2018 22:48:00 +0200, Rune Lillesveen
> <fut...@chromium.org <mailto:fut...@chromium.org>> wrote:
>
> non-owner lgtm
>
> On Tue, May 15, 2018 at 8:15 PM Tab Atkins <taba...@google.com
> <mailto:taba...@google.com>> wrote:
>
> LGTM, this is a necessary fix
> On Tue, May 15, 2018 at 4:32 AM Emilio Cobos Álvarez
> <mailto:emi...@chromium.org>, emi...@mozilla.com
> <mailto:emi...@mozilla.com>)
https://github.com/w3c/csswg-drafts/issues/1898#issuecomment-342556321
I thought this was talked about in the Berlin F2F in April this year,
but I can't find any related minutes, so maybe I'm misremembering or it
was an informal conversation...
-- Emilio
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeRbjD%3D0mO-cJtXTq7_OSGv5X1FZsec-33YBz-UiryHhSg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeRbjD%3D0mO-cJtXTq7_OSGv5X1FZsec-33YBz-UiryHhSg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeRbjD%3D0mO-cJtXTq7_OSGv5X1FZsec-33YBz-UiryHhSg%40mail.gmail.com
>
>
>
>
> --
> /* Opera Software, Linköping, Sweden: CEST (UTC+2) */
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
>
>
>
> --
> /* Opera Software, Linköping, Sweden: CEST (UTC+2) */
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to blink-dev+...@chromium.org
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zi331lnzrbppqq%40cicero2.linkoping.osa
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zi331lnzrbppqq%40cicero2.linkoping.osa?utm_medium=email&utm_source=footer>.
>
Philip Jägenstedt
May 17, 2018, 12:50:50 PM5/17/18
to Emilio Cobos Álvarez, Yoav Weiss, Daniel Bratell, Tab Atkins, Rune Lillesveen, blink-dev
We discussed this in the API owners weekly review meeting today. (Present: Alex, Yoav, Daniel, Chris, Ojan, Rick, me)
Regarding logical and physical properties, the web compat risk and performance regression risk, as far we can judge them, seem low enough to just try the change and be on the lookout for for regressions and being eager to revert.
However, we're not sure if there are any implications for shorthand properties, i.e. the order of setting elm.style.margin and elm.style.marginTop or similar. After a bit of experimenting it appears as though CSSStyleDeclaration doesn't store these separately, so the problem cannot happen. Is that right?
Are there any other cases than logical and physical properties where the order can matter? For example, properties which are aliases?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/834988a7-3e9e-035b-dfce-bb1c99f59047%40mozilla.com.
Chris Harrelson
May 17, 2018, 3:47:18 PM5/17/18
to Philip Jägenstedt, emi...@mozilla.com, Yoav Weiss, Daniel Bratell, Tab Atkins, Rune Lillesveen, blink-dev
Also, as I understand it, the most-used logical properties in Chrome are actually webkit-prefixed ones. (e.g. -webkit-margin-start is on 4.6% of pages). Therefore the compat impact of this change for Chrome is not necessarily going to be the same as it was for Firefox.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeTkpDfUpCvVQ%3D5aMRfEJunVBcNcDLuU2%2BmKrCFwN5CBQ%40mail.gmail.com.
Emilio Cobos Álvarez
May 18, 2018, 4:12:07 AM5/18/18
to Philip Jägenstedt, Yoav Weiss, Daniel Bratell, Tab Atkins, Rune Lillesveen, blink-dev
On 05/17/2018 06:50 PM, 'Philip Jägenstedt' via blink-dev wrote:
> We discussed this in the API owners weekly review meeting today.
> (Present: Alex, Yoav, Daniel, Chris, Ojan, Rick, me)
>
> Regarding logical and physical properties, the web compat risk and
> performance regression risk, as far we can judge them, seem low enough
> to just try the change and be on the lookout for for regressions and
> being eager to revert.
>
> However, we're not sure if there are any implications for shorthand
> properties, i.e. the order of setting elm.style.margin and
> elm.style.marginTop or similar. After a bit of experimenting it appears
> as though CSSStyleDeclaration doesn't store these separately, so the
> problem cannot happen. Is that right?
longhands separately. Once they're expanded there should not be any
difference as setting all the longhands separately.
That being said it's not clear to me what the problem you're asking
about here would be. Setting (non-logical) shorthand and longhands would
have the same effect, so regardless of ordering setting margin then
marginTop or vice-versa would have the same effect on styling and layout
as before.
Note that margin is only a shorthand for the physical margin properties,
same for padding and all the other common shorthands. I can't think of
any logical shorthand off the top of my head whose subproperties have
physical counter-parts.
> Are there /any/ other cases than logical and physical properties where
> the order can matter? For example, properties which are aliases?
Aliases should go away as well once in the declaration (once set, the
alias becomes the aliased property), the effect is the same as setting
the aliased property. So setting logical aliases would have the same
effect as setting the logical aliased property (as expected).
I don't think anything besides logical properties (and their respective
aliases) are affected in that sense.
-- Emilio
>
> On Thu, May 17, 2018 at 2:05 PM Emilio Cobos Álvarez <emi...@mozilla.com
> <mailto:emi...@mozilla.com>> wrote:
>
>
>
> On 05/17/2018 10:18 AM, Yoav Weiss wrote:
> >
> > On Wed, May 16, 2018 at 5:02 PM Daniel Bratell <bra...@opera.com
> <mailto:bra...@opera.com>
> > <mailto:bra...@opera.com <mailto:bra...@opera.com>>> wrote:
> >
> > __
> > LGTM1.
> >
> > I wish there was some way to determine the risk, but I can't think
> > of one beside letting it out in the wild.
> >
> >
> > Is it possible to ship this as an experiment and track e.g. script
> > responsiveness and/or long tasks in order to evaluate the risk here?
> >
> >
> >
> > /Daniel
> >
> > On Tue, 15 May 2018 22:48:00 +0200, Rune Lillesveen
> > <fut...@chromium.org <mailto:fut...@chromium.org>
> >
> > __
> > LGTM1.
> >
> > I wish there was some way to determine the risk, but I can't think
> > of one beside letting it out in the wild.
> >
> >
> > Is it possible to ship this as an experiment and track e.g. script
> > responsiveness and/or long tasks in order to evaluate the risk here?
> >
> >
> >
> > /Daniel
> >
> > On Tue, 15 May 2018 22:48:00 +0200, Rune Lillesveen
> > <fut...@chromium.org <mailto:fut...@chromium.org>
> <mailto:fut...@chromium.org <mailto:fut...@chromium.org>>> wrote:
> >
> > non-owner lgtm
> >
> > On Tue, May 15, 2018 at 8:15 PM Tab Atkins
> <taba...@google.com <mailto:taba...@google.com>
> > <mailto:taba...@google.com
> >
> > non-owner lgtm
> >
> > On Tue, May 15, 2018 at 8:15 PM Tab Atkins
> <taba...@google.com <mailto:taba...@google.com>
> <mailto:taba...@google.com>>> wrote:
> >
> > LGTM, this is a necessary fix
> > On Tue, May 15, 2018 at 4:32 AM Emilio Cobos Álvarez
> > <emi...@mozilla.com <mailto:emi...@mozilla.com>
> <mailto:emi...@mozilla.com <mailto:emi...@mozilla.com>>>
> >
> > LGTM, this is a necessary fix
> > On Tue, May 15, 2018 at 4:32 AM Emilio Cobos Álvarez
> > <emi...@mozilla.com <mailto:emi...@mozilla.com>
> > wrote:
> >
> > > Contact emails:
> >
> > > Emilio Cobos Álvarez (emi...@chromium.org
> <mailto:emi...@chromium.org>
> > <mailto:emi...@chromium.org
> >
> > > Contact emails:
> >
> > > Emilio Cobos Álvarez (emi...@chromium.org
> <mailto:emi...@chromium.org>
> > <mailto:emi...@mozilla.com <mailto:emi...@mozilla.com>>)
> > <mailto:blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeRbjD%3D0mO-cJtXTq7_OSGv5X1FZsec-33YBz-UiryHhSg%40mail.gmail.com
> >
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeRbjD%3D0mO-cJtXTq7_OSGv5X1FZsec-33YBz-UiryHhSg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> >
> >
> >
> >
> > --
> > /* Opera Software, Linköping, Sweden: CEST (UTC+2) */
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "blink-dev" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>
> >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeRbjD%3D0mO-cJtXTq7_OSGv5X1FZsec-33YBz-UiryHhSg%40mail.gmail.com
> >
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeRbjD%3D0mO-cJtXTq7_OSGv5X1FZsec-33YBz-UiryHhSg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> >
> >
> >
> >
> > --
> > /* Opera Software, Linköping, Sweden: CEST (UTC+2) */
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "blink-dev" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to blink-dev+...@chromium.org
> > <mailto:blink-dev+...@chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zi331lnzrbppqq%40cicero2.linkoping.osa
> >
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zi331lnzrbppqq%40cicero2.linkoping.osa?utm_medium=email&utm_source=footer>.
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/834988a7-3e9e-035b-dfce-bb1c99f59047%40mozilla.com.
>
> >
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zi331lnzrbppqq%40cicero2.linkoping.osa
> >
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zi331lnzrbppqq%40cicero2.linkoping.osa?utm_medium=email&utm_source=footer>.
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/834988a7-3e9e-035b-dfce-bb1c99f59047%40mozilla.com.
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeTkpDfUpCvVQ%3D5aMRfEJunVBcNcDLuU2%2BmKrCFwN5CBQ%40mail.gmail.com
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeTkpDfUpCvVQ%3D5aMRfEJunVBcNcDLuU2%2BmKrCFwN5CBQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Daniel Bratell
May 18, 2018, 4:56:44 AM5/18/18
to Philip Jägenstedt, Emilio Cobos Álvarez, Yoav Weiss, Tab Atkins, Rune Lillesveen, blink-dev
On Fri, 18 May 2018 10:11:59 +0200, Emilio Cobos Álvarez
<emi...@mozilla.com> wrote:
>
>
> On 05/17/2018 06:50 PM, 'Philip Jägenstedt' via blink-dev wrote:
>> We discussed this in the API owners weekly review meeting today.
>> (Present: Alex, Yoav, Daniel, Chris, Ojan, Rick, me)
>>
>> Regarding logical and physical properties, the web compat risk and
>> performance regression risk, as far we can judge them, seem low enough
>> to just try the change and be on the lookout for for regressions and
>> being eager to revert.
>>
>> However, we're not sure if there are any implications for shorthand
>> properties, i.e. the order of setting elm.style.margin and
>> elm.style.marginTop or similar. After a bit of experimenting it appears
>> as though CSSStyleDeclaration doesn't store these separately, so the
>> problem cannot happen. Is that right?
>
> Setting a shorthand is roughly the same as setting each of the expanded
> longhands separately. Once they're expanded there should not be any
> difference as setting all the longhands separately.
>
> That being said it's not clear to me what the problem you're asking
> about here would be. Setting (non-logical) shorthand and longhands would
> have the same effect, so regardless of ordering setting margin then
> marginTop or vice-versa would have the same effect on styling and layout
> as before.
What we wondered during the meeting (none of us present deeply familiar
<emi...@mozilla.com> wrote:
>
>
> On 05/17/2018 06:50 PM, 'Philip Jägenstedt' via blink-dev wrote:
>> We discussed this in the API owners weekly review meeting today.
>> (Present: Alex, Yoav, Daniel, Chris, Ojan, Rick, me)
>>
>> Regarding logical and physical properties, the web compat risk and
>> performance regression risk, as far we can judge them, seem low enough
>> to just try the change and be on the lookout for for regressions and
>> being eager to revert.
>>
>> However, we're not sure if there are any implications for shorthand
>> properties, i.e. the order of setting elm.style.margin and
>> elm.style.marginTop or similar. After a bit of experimenting it appears
>> as though CSSStyleDeclaration doesn't store these separately, so the
>> problem cannot happen. Is that right?
>
> Setting a shorthand is roughly the same as setting each of the expanded
> longhands separately. Once they're expanded there should not be any
> difference as setting all the longhands separately.
>
> That being said it's not clear to me what the problem you're asking
> about here would be. Setting (non-logical) shorthand and longhands would
> have the same effect, so regardless of ordering setting margin then
> marginTop or vice-versa would have the same effect on styling and layout
> as before.
with this system) was what the effect would be if you had
<div style="margin-top: 10px; margin: 20px">
and set .style.marginTop, whether that was also "broken" and whether it
would change behaviour with your patch.
I checked now and this seems to be a non-problem already.
You will get a <div style="margin: 30px 20px 20px"> from setting
marginTop. No shadowing, and as little extra in the style argument as
possible.
> I don't think anything besides logical properties (and their respective
> aliases) are affected in that sense.
better what the limit of the risks are. There is a risk, but I feel it's
worth taking it to remove some surprising behaviour, but we also need to
be prepared to back out if there are signs of web breaking.
/Daniel
Philip Jägenstedt
May 18, 2018, 7:20:54 AM5/18/18
to Daniel Bratell, Emilio Cobos Álvarez, Yoav Weiss, Tab Atkins, Rune Lillesveen, blink-dev
Thanks Emilio for the further explanation and Daniel for the margin experimenting to confirm the non-problem.
Here I was going to say that the current behavior is interoperable and longstanding and point to https://jsbin.com/rotogup/1/edit?html,output, and that this should make us quick to revert if there's trouble. But, there's a surprise here. Stable versions of Chrome, Firefox and Safari pass this test, and doesn't change the order. But Edge actually fails the test, not because it changes the order, but because the initial order doesn't match the order of setting the properties.
Now slightly off topic, but is the serialization order well defined, and is there an existing test in WPT that fails only in Edge for this?
This inconsistency actually helps to reduce the risk of the change, because exact serialization order apparently wasn't totally reliable to begin with.
LGTM2 to attempt this change. If there are regressions, please circle back to this thread, they might reveal something interesting that should cause us to reconsider.
Chris Harrelson
May 18, 2018, 12:27:32 PM5/18/18
to Philip Jägenstedt, Daniel Bratell, emi...@mozilla.com, Yoav Weiss, Tab Atkins, Rune Lillesveen, blink-dev
LGTM3
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcUXCXqSFmj46fTQFn90-DqwExxLSn6oX2DBsy4Jr6chQ%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages