Re: [css3-text-layout] Towards better support of CJK user requirements (was New editor's draft - margin-before/after/start/end etc)

"L. David Baron" <dbaron@dbaron.org> wrote on 2010/06/02 0:40:48
> On Sunday 2010-05-30 08:50 +0900, MURATA Makoto (FAMILY Given) wrote:
> > > There is no consensus in the CSS WG to add the proposed 30 new
> > > properties. 
> > 
> > It was agreed to incorporate them into the next draft. Then, David Hyatt
> > and Boris Zbarsky explained their implementations of the 30 new properties.  
> > Their implementations are very simple and do not appear to have any problems. 
> 
> They are not simple, and they do have problems.  (I say that as the
> person who first implemented *-start and *-end properties in Mozilla
> [1].)

I understand implementing the feature is not simple, but you did and
it works almost sufficiently.

> 
> I mentioned serialization and object model issues in
> http://lists.w3.org/Archives/Public/www-style/2010Jun/0003.html .
> Let me give an example:
>   <!DOCTYPE html>
>   <p id="elem"></p>
>   <script>
>   var p = document.getElementById("elem");
>   p.style.marginLeft="3em";
>   p.style.MozMarginStart="2em";
>   document.write(getComputedStyle(p, "").marginLeft + "<br>");
>     // prints 32px
>   p.style.marginLeft="3em";
>   document.write(getComputedStyle(p, "").marginLeft + "<br>");
>     // prints 48px
>   document.write(p.style.cssText + "<br>");
>     // prints margin-left: 3em; -moz-margin-start: 2em;
>   var attr = p.style.cssText;
>   p.removeAttribute("style");
>   p.setAttribute("style", attr);
>   document.write(getComputedStyle(p, "").marginLeft + "<br>");
>     // prints 32px
>   </script>
> What happens here is that our attempts to preserve order of
> declarations when serializing and to avoid changing order when
> mutating a property already in the declaration (which we want in
> general) are interacting badly with our code to avoid serializing
> the internal *-value and *-source properties, and the interaction
> causes the serialized form of the declaration to mean something
> different from what it actually means (it serializes to
> "margin-left: 3em; -moz-margin-start: 2em;" when the underlying
> declaration is really equivalent to "-moz-margin-start: 2em;
> margin-left: 3em").
> 
> This is fixable, but it requires another set of code (a set we don't
> already have) specifically for these properties.  We won't have
> implementations behaving the same on cases like these unless the
> specification defines the behavior we want.
> 
> 
> I think I support the proposal, but I'm disturbed that it is being
> presented as much simpler than it really is.  If we want to have an
> honest discussion about this proposal, we should be clear about its
> complexity rather than hiding it.  And the difficult parts of
> implementing the proposal should be mentioned in the spec so that we
> solve them once, together, rather than making each implementor solve
> them separately (and differently).

I tested your example with WebKit (with s/Moz/webkit/), the result is:
32px
48px
-webkit-margin-start: 2em; margin-left: 3em; 
48px

It seems correct. I'd like to standardize this behavior.

> 
> The editor's draft specification currently says only:
>   # If both logical and physical properties are specified on the
>   # same element, these corresponding properties are treated as same
>   # property and then normal cascading rules are applied.
> This is ambiguous; it does not describe a mechanism for "treated as
> the same property", and therefore does not describe a single
> interoperable behavior for many cases.

I'll change the wording to: ..., logical properties are converted to
physical properties ...


> 
> In order to be clear about the complexity of the proposal, the
> specification should (1) describe how cascading is to be handled,
> probably by incorporating something like one of the proposals cited
> in http://lists.w3.org/Archives/Public/www-style/2010Jun/0003.html
> and (2) describe whether the longhand properties both proposals
> require are normal properties or are (as they are in Mozilla's
> implementation) a new class of hidden properties and (3) if the new
> properties are hidden, describe the effects of hidden properties on
> the CSS object model.
> 
> -David
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=74880#c60

-- 
ζ‘δΈŠ ηœŸι›„ (MURAKAMI Shinyu)
http://twitter.com/MurakamiShinyu
Antenna House Formatter:
http://www.antenna.co.jp/AHF/
http://www.antennahouse.com

Received on Tuesday, 1 June 2010 20:05:21 UTC