W3C home > Mailing lists > Public > www-style@w3.org > June 2010

Re: [css3-text-layout] New editor's draft - margin-before/after/start/end etc.

From: L. David Baron <dbaron@dbaron.org>
Date: Mon, 31 May 2010 20:47:12 -0700
To: MURAKAMI Shinyu <murakami@antenna.co.jp>
Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, David Hyatt <hyatt@apple.com>, www-style list <www-style@w3.org>
Message-ID: <20100601034712.GB5099@pickering.dbaron.org>
On Thursday 2010-05-27 09:29 +0900, MURAKAMI Shinyu wrote:
> Boris Zbarsky <bzbarsky@MIT.EDU> wrote on 2010/05/27 4:32:35
> > In mozilla's implementation, *-start and *-end are effectively converted 
> > into *-left and *-right as needed when determining computed values. 
> > There is no separate computed value for *-start and *-end.  A specified 
> > value like "*-start: inherit" in treated as either "*-left: inherit" or 
> > "*-right: inherit" depending on the directionality of the thing doing 
> > the inheriting.  But the value inherited will obviously depend on the 
> > directionality of the parent, if the parent itself had a "*-start" 
> > specified.
> > 
> > All of which sounds similar to what you describe for webkit.
> 
> All of which sounds similar to what I want :-)
> 
> I don't want separate computed values for logical and physical
> properties. See:
> 
> http://dev.w3.org/csswg/css3-text-layout/#logical-prop
> | The computed value of a logical property affects the computed value 
> | of the corresponding physical property, and vice versa.

This is slightly different from what Boris describes (that is, what
Mozilla implements), where the logical properties do not have a
computed value (so it does not make sense to talk about "the
computed value of a logical property").

I'd also note that there are two different proposals for how the
cascading of logical + physical properties should work.  My original
proposal was:
  http://lists.w3.org/Archives/Public/www-style/2002Sep/0049.html
which is quite similar to what is implemented in Mozilla (for -start
and -end properties):
  https://bugzilla.mozilla.org/show_bug.cgi?id=74880
Elika had a different proposal here:
  http://lists.w3.org/Archives/Public/www-style/2006Jun/0084.html

Getting serialization (of complete declarations) and object model
access (especially mutation) correct for split logical/physical
properties is not easy (especially under rules that don't allow the
hidden *-source properties to be specified); I suspect Mozilla still
has quite a few bugs in this regard.  How these things should behave
should probably be specified in any document introducing these new
properties.

I'd also note that the number of pieces of information that need to
be stored and cascaded separately for the full
before/after/start/end set of properties is substantial.  In
particular, it transforms:
  margin-top
  margin-bottom
  margin-left
  margin-right
into:
  margin-top
  margin-bottom
  margin-left
  margin-right
  margin-before
  margin-after
  margin-start
  margin-end
  margin-top-*-tb-source
  margin-top-tb-*-source
  margin-top-bt-*-source
  margin-bottom-*-tb-source
  margin-bottom-tb-*-source
  margin-bottom-bt-*-source
  margin-left-lr-*-source
  margin-left-rl-*-source
  margin-left-*-rl-source
  margin-left-*-lr-source
  margin-right-lr-*-source
  margin-right-rl-*-source
  margin-right-*-rl-source
  margin-right-*-lr-source
(All the *-source properties technically only require 2 bits of
storage, though:  one bit to say whether or not the property is
specified, and the other to say whether its value is 'physical' or
'logical'.  That's not how they're implemented in Mozilla, though,
since we want to benefit from existing cascading code that operates
on more generic data types.)

So, really, it's 90 new properties (the 18 new above, but for
margin, padding, border-style, border-width, and border-color), or
perhaps 130, if you also count new shorthands separately.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Tuesday, 1 June 2010 03:47:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:28 GMT