Re: May have to do with "column layout" WAS:RE: Proposal of alternative to CSS3 box-sizing property

Manos Batsis wrote:

> Hallo Rod,
>
> Thanks for the reply. To tell you the truth, I like your approach better
> (I always use shorthands my self). I don't know if this is in the
> current working draft proposal (?) though and I can't check thanks to
> some maintenance/upgrade procedures on my LAN.
>
> But although your syntax is what I would also prefer using, it has some
> disadvantages. One of them may be backwards compatibility, because you
> are changing the syntax of "width" or "height" directly. It may be quite
> possible that a browser may not be able to interpret the attribute at
> all using this additional "outside". In short, an additional attribute
> set like "include-width" and "include-height" is cleaner and easier to
> apply over a transition period (witch of course is constant these days)
> among browsers.

    This is by design.
    It would not be good for legacy UAs to pick up the length (or percent)
and apply it without also performing the adjustment implied by the "outside"
modifier. The extant CSS3 Box-sizing property is flawed in this respect --
as a new property, legacy UAs may do just that.

    The reasoning is this: The coded length with the Outside modifier or
with the Box-sizing property is intended to specify the length of something
more than the content-width. If a UA were to apply that coded length to the
content-width, this would very likely cause the box dimensions to be larger
than intended (due to margin, border, padding).
    Perhaps an analogy would show the problem more clearly. Imagine that the
country of Slobovia adopts a length measure called "inch", but they make it
25% smaller than the US inch. For whatever reason, attempting to accommodate
this development, the W3C decide to add a new property called "Inch" with
values "US" and "Slob", US being the default. The new property value will
designate which "inch" standard to use. Can you see how legacy UAs would be
using the wrong units? They would be using Slobovian inches as US inches; A
value of 1.25in (slob) would be treated as 1.25in (US) instead of its true
equivalent of 1.0in (US).
    Now see the difference if this were specified as a modifier ("slob") to
extant lengths. A specification of "1.25in slob" would be ignored by legacy
UAs because of the presence of the  "slob" junk. The effect: that particular
property reverts to "auto", a much better outcome, and likely to render
closer to the intent.

    Has that clarified matters, or merely muddied the waters!

-R.

Received on Sunday, 17 June 2001 14:38:32 UTC