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

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

From: MURAKAMI Shinyu <murakami@antenna.co.jp>
Date: Wed, 02 Jun 2010 05:04:39 +0900
To: "L. David Baron" <dbaron@dbaron.org>
Cc: "MURATA Makoto (FAMILY Given)" <eb2m-mrt@asahi-net.or.jp>, Hakon Wium Lie <howcome@opera.com>, www-style@w3.org, Jaeho Lee <jaeho@uos.ac.kr>, Ning Li <ningli@public2.bta.net.cn>, komachi@y-adagio.com, "KOBAYASHI Tatsuo(FAMILY Given)" <tlk@kobysh.com>, Seiichi Kato <seiichik@microsoft.com>, Masanori Kusunoki <Masanori.Kusunoki@microsoft.com>, yjkweon@keris.or.kr, Yong-Sang Cho <zzosang@gmail.com>, Sam Gyun Oh <samoh21@gmail.com>, sblim@sookmyung.ac.kr, speeno@haansoft.com, jungkwon@haansoft.com, sadian@ksa.or.kr, hykim@incube.co.kr, shik@kats.go.kr, mike@w3.org, ishida@w3.org, bert@w3.org, masao@w3.org, phobos chang <phobos.chang@gmail.com>, selena <selena@cmex.org.tw>
Message-Id: <20100602050438.2978.C598BCD7@antenna.co.jp>
"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:
-webkit-margin-start: 2em; margin-left: 3em; 

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)
Antenna House Formatter:
Received on Tuesday, 1 June 2010 20:05:21 UTC

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