- From: Mike Sherov <mike.sherov@gmail.com>
- Date: Tue, 13 Mar 2012 08:29:54 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style@w3.org
- Message-ID: <CAD1Dv_Ld52CVJ1ab9YVw8vvgkHQExEvNz_oikBNrak9XbokfrA@mail.gmail.com>
Thanks for the response, Tab. I'm glad you've convinced yourself :-) . For
the sake of argument though, and to attempt to convince others, allow me to
speak to this statement:
> Keeping that invariant, though, means that in this case the author has to
handle box-sizing themselves to get the "real" width of the box.
I would argue that when an author sets the box-sizing to border-box, they
are giving up the right to call content width the "real" width. If they
want the content width, they have to do the augmentation. This argument is
just the opposite of "if it didn't return the round-trippable value, they'd
have to augmentation to get it". In this case, maintaining the
round-trippable invariant seems like the more *useful* use case from what
I've seen in trying to fix bugs in jQuery that come from this issue.
On Mon, Mar 12, 2012 at 8:51 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:
>
> On Mar 12, 2012 5:33 PM, "Mike Sherov" <mike.sherov@gmail.com> wrote:
> >
> > >> On Thu, 16 Jun 2011 06:09:46 +0200, Boris Zbarsky <bzbarsky@mit.edu>
> wrote:
> > >> Or to put this in testcase terms:
> > >>
> > >> <style>
> > >> body { width: 200px; }
> > >> div { width: auto; box-sizing: border-box; padding: 10px; }
> > >> </style>
> > >> <body><div></div></body>
> > >>
> > >> The question is whether getComputedStyle for 'width' on the div
> should
> > >> return 180px or 200px (neither of which is the CSS 2.1 computed
> value;
> > >> the former is the used width and the latter is what would work for
> > >> round-tripping).
> > >
> > > Per the specification that should be 180px. Not sure it is worth
> special
> > > casing box-sizing.
> > >
> > > http://dev.w3.org/csswg/cssom/#dom-window-getcomputedstyle
> > > http://dev.w3.org/csswg/cssom/#resolved-value
> > >
> > >
> > >> Note also https://bugzilla.mozilla.org/show_bug.cgi?id=520992(which
> > >> seems to be the only Gecko bug report related to this I've found).
> > >>
> > >> -Boris
> >
> > I know this is raising an old issue, but it seems as if the resolved
> value (which is used by getComputedStyle) for width should return a
> round-trippable value. In fact, I believe that implicit in the definition
> of resolved value is the concept that the value should be round-trippable.
> In the case of width, it gets a bit weird, because the meaning of width
> changes based on box-sizing. What's more is that all browsers save for
> Firefox currently implement the round-trippable value.
> >
> > This issue can be resolved in 1 of 2 ways:
> > 1. special case width for box-sizing, as Anne previously said "not sure
> it is worth special casing".
> > 2. add a requirement to "resolved values" that specifies a resolved
> value as being round-trippable.
> >
> > I haven't done any research to this besides the the firefox bug linked
> above, and the jQuery ticket I'm working on that inspired me to write this
> email: http://bugs.jquery.com/ticket/11004 . I've opened a ticket in
> hopes to get this addressed:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16316
>
> I'm not sure I agree, but I don't disagree either.
>
> It seems weird to break the invariant that "el.style.foo =
> getComputedStyle(el).foo;" is a no-op (modulo rounding/precision issues,
> perhaps).
>
> Keeping that invariant, though, means that in this case the author has to
> handle box-sizing themselves to get the "real" width of the box.
>
> However, I think a good argument can be made that this isn't meant to be a
> reliable API for that. We have getBoundingBox() for that, and in the future
> will have more advanced/usable variants for getting data like the size of
> the content box.
>
> So, I think I've convinced myself that the best option is to maintain the
> round-trip invariant, as you suggest, and get Firefox to change here.
>
> ~TJ
> On Mar 12, 2012 5:33 PM, "Mike Sherov" <mike.sherov@gmail.com> wrote:
>
>> >> On Thu, 16 Jun 2011 06:09:46 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> >> Or to put this in testcase terms:
>> >>
>> >> <style>
>> >> body { width: 200px; }
>> >> div { width: auto; box-sizing: border-box; padding: 10px; }
>> >> </style>
>> >> <body><div></div></body>
>> >>
>> >> The question is whether getComputedStyle for 'width' on the div should
>> >> return 180px or 200px (neither of which is the CSS 2.1 computed value;
>> >> the former is the used width and the latter is what would work for
>> >> round-tripping).
>> >
>> > Per the specification that should be 180px. Not sure it is worth special
>> > casing box-sizing.
>> >
>> > http://dev.w3.org/csswg/cssom/#dom-window-getcomputedstyle
>> > http://dev.w3.org/csswg/cssom/#resolved-value
>> >
>> >
>> >> Note also https://bugzilla.mozilla.org/show_bug.cgi?id=520992 (which
>> >> seems to be the only Gecko bug report related to this I've found).
>> >>
>> >> -Boris
>>
>> I know this is raising an old issue, but it seems as if the resolved
>> value (which is used by getComputedStyle) for width should return a
>> round-trippable value. In fact, I believe that implicit in the definition
>> of resolved value is the concept that the value should be round-trippable.
>> In the case of width, it gets a bit weird, because the meaning of width
>> changes based on box-sizing. What's more is that all browsers save for
>> Firefox currently implement the round-trippable value.
>>
>> This issue can be resolved in 1 of 2 ways:
>> 1. special case width for box-sizing, as Anne previously said "not sure
>> it is worth special casing".
>> 2. add a requirement to "resolved values" that specifies a resolved value
>> as being round-trippable.
>>
>> I haven't done any research to this besides the the firefox bug linked
>> above, and the jQuery ticket I'm working on that inspired me to write this
>> email: http://bugs.jquery.com/ticket/11004 . I've opened a ticket in
>> hopes to get this addressed:
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16316
>>
>> I welcome any and all feedback.
>>
>> --
>> Mike Sherov
>> Lead Developer
>> SNAP Interactive, Inc.
>> Ticker: STVI.OB
>>
>>
--
Mike Sherov
Lead Developer
SNAP Interactive, Inc.
Ticker: STVI.OB
Received on Tuesday, 13 March 2012 12:30:53 UTC