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: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 03 Jun 2010 13:35:55 -0400
Message-ID: <4C07E7FB.2040302@mit.edu>
To: Håkon Wium Lie <howcome@opera.com>
CC: www-style list <www-style@w3.org>
On 6/3/10 1:21 PM, Håkon Wium Lie wrote:
> Let's take one step back. What I'm trying to do is to see if it's
> possible to construct a model where (a) it's possible to use
> direction-dependent property names in CSS, while (b) keeping costs to
> a minimum for implementors.

OK.  I'm on board so far!

> So, I'm trying to see if it's possible to support "margin-start: 10px"
> without adding *-source properties. Also, I'd like for implementations
> to forget about direction-dependent properties/aliases as soon as
> possible. Ideally, this should be done at parse-time, but at that
> point we don't know what the value of 'writing-mode' will end up
> being. So, I think we need to hold only them until the computed value
> of 'writing-mode' is known.

But there's no "the" computed value of writing-mode for a given 
direction-dependent property declaration; that's my problem.  Again:

   * { margin-start: 20px; }

Supporting this requires keeping track of the fact that "margin-start" 
was used indefinitely in at least the data structure representing the 
style rule, since for each element we have to redo the writing-mode 
computation and will in general get different answers for different 

> At that point, we should be able to map settings from
> direction-dependent settings to physical seetings. So, e.g., we can
> map:
>    margin-start: 10px
> to one of these:
>    margin-left: 10px
>    margin-top: 10px
>    margin-right: 10px
> and forget about "margin-start: 10px".

We can't forget about it completely.  We can forget about it _for that 
element_.  That's what Gecko does, for example.  But you can't forget 
about it entirely.

> As you have pointed out in the past [3], specified values need a lot less
> memory than computed values. So, it may be that we can keep them
> around so that scripts can get to them. But, this, may have limited
> value. For example:
>    margin-start: 20px;
>    margin-left: 10px;
> In the example above, knowing the 'margin-start' declaration has
> limited value as it is overridden by the subsequent 'margin-left'
> declaration (assuming ltr).

But "assuming ltr" depends on knowledge of the entire cascade and on 
rules other that this one....  and can differ for different elements the 
rule applies to.

Maybe the issue is that there are more sets of values than we've really 
been talking about.  The complete list, as I see it, is:

1)  Specified values (tied to style rules).
2)  Cascaded values (tied to elements).
3)  Computed values (tied to elements).
4)  Used values (tied to elements).

You can't convert direction-dependent properties in 1 above to 
direction-independent ones, because direction is not known at that 
point.  You can definitely convert them in 4 above.  In 3 above you may 
be able to do it depending on how computed values are defined.  In 2 
above, I think you can if you can in 3.

Gecko's current implementation converts the direction-dependent 
properties to direction-independent ones in 3 (and therefore 4), but not 
1 or 2.  But we also don't store 2 in memory on a permanent basis, so 
it's not a problem for us.

> Therefore, the computed value is more interesting. In David Baron's
> model, 'margin-start' has its own computed value [4].

I'm not sure what in that mail makes you think margin-start has its own 
computed value.  In Gecko's current implementation, there is no separate 
computed value for margin-start, as was mentioned earlier in this thread.

 > I think it's possible to avoid that by mapping the direction-dependent
> properties/aliases to physical properties. So, only the physical
> properties would have computed values -- the direction-dependendt
> properties/aliases could be computed in a lazy fashion based on the
> values of the physical properties and 'writing-mode'.

Agreed.  This is what Gecko does (and what Webkit seems to do, if I 
understand hyatt correctly).

> Now, to come back to your question:
>   >  Hold on.  So I can write "* { margin-start: 20px }" in my CSS, but I
>   >  can't do this in JS?
>   >
>   >     var sheet = document.styleSheets[0];
>   >     sheet.insertRule("* {}", 0);
>   >     sheet.cssRules[0].style.setProperty("margin-start", "20px", "");
>   >
>   >  Why shouldn't I be able to do that?  Why shouldn't I be able to do
>   >  thisElement.style.setProperty("margin-start", "3px", "")?
> I think it should be possible to support this code. However, a mapping
> will have to take place internally so that 'margin-start' is mapped to
> the right physical property, by way of 'writing-mode'.

Sure, when determining computed style.  But not in the specified style.

It sounds like we're more or less in agreement on how this could work, 
fwiw; just disagreeing on the term "specified style" or something...

Received on Thursday, 3 June 2010 17:36:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:47 UTC