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

Also sprach Boris Zbarsky:

 > It sounds like we're more or less in agreement on how this could work, 

Yes, I think so, too. 

 > > 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.

True, not for a declaration, but each element will have a computed
value for 'writing-mode' (or, in fact, its individual properties).

 > 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 
 > elements.

Yes, we need to remember that declaration until the value of
'writing-mode' is known for all elements.

 > > 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.

You should be able to forget about it when the value of 'writing-mode'
is known for all elements, I believe.

 > > 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.

With "assuming ltr", I only meant that 'margin-start' would be an
alias for 'margin-left' only in ltr.

I agree that we have to do these computations for each element.

 > 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).

That's not the terminology used in the specs. In the specs, the
"specified value" is not tied to style rules. Rather, for every
property/element combination there is a specified value.

  http://dev.w3.org/csswg/css3-cascade/
  http://www.w3.org/TR/CSS2/cascade.html#specified-value

And for the properties in question ('direction' and 'block-flow',
which 'writing-mode' is a shorthand for) the specified value is the
same as the computed value.

  http://dev.w3.org/csswg/css3-text-layout/#direction
  http://dev.w3.org/csswg/css3-text-layout/#block-flow

I think one should convert DDAs before they turn into specfied values.
That is, DDAs should not have specified values -- only properties that
also have computed/used/actual values should have specified values.

To describe how/when DDAs should be resolved, a new step should
probably be added to the pseudo-algorithm described here:

  http://dev.w3.org/csswg/css3-cascade/#input-to-and-output-from-this-module

Something like: "if a property has an alias, resolve it and let it
fight its way through cascading...". Hmm.

 > > 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.

You're right, there's nothing in the example that implies this. 

 > In Gecko's current implementation, there is no separate 
 > computed value for margin-start, as was mentioned earlier in this thread.

Ok, good.

 > > 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-dependent
 > > 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).

Ok. But you remember the declarations, it seems. Consider this example:

  http://people.opera.com/howcome/2010/tests/log.html

When I press "rtl", the padding on the elements switch side. For this
to work, you need to go back to the declarations. I guess you do this.
Ideally, I would have liked to resolve the aliases once and for all.
  
-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Thursday, 3 June 2010 20:34:39 UTC