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

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

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.

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

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Tuesday, 1 June 2010 15:42:36 UTC