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

Håkon Wium Lie <howcome@opera.com> wrote on 2010/06/08 4:45:29
> Also sprach Tab Atkins Jr.:
> 
>  > > Couldn't "user swapping" be thought of in terms of an alternate
>  > > stylesheet choice?  This seems far more robust than relying on
>  > > changing writing-mode and expecting everything to "just work" (assuming
>  > > fallback can be dealt with in other ways).
>  > 
>  > If we're going to do that, then we should just bite the bullet and do
>  > a @writing-mode [rtl|ltr|ttb] {} block, like Hakon suggested way back
>  > during the first incarnation of this discussion.
> 
> Let's try to get an overview of the various proposals. In no
> particular order, I see:
> 
> 1) direction-dependent aliases: introduce aliases for properties with
>    top/right/bottom/left in their names. The aliases are not real
>    properties, and they are resolved when the computed value of
>    'writing-direction' is known. For example, 
> 
>       body { margin-before: 10px }
> 
>    is resolved into 
> 
>       body { margin-top: 20px }
> 
>    for lr-tb text. This scheme is described in the current editor's
>    draft:
> 
>      http://dev.w3.org/csswg/css3-text-layout/
> 
> 
> 2) duplicate sets of properties: two parallel sets of properties
>    exist, one physical and one direction-dependent (aka "logical").
>    And then one or several properties to decide which of the two sets
>    to use. For example:
> 
>      body { margin-before: 10px; direction-model: logical }
> 
>    Here are two such proposals:
> 
>      http://lists.w3.org/Archives/Public/www-style/2006Jun/0084.html
>      http://lists.w3.org/Archives/Public/www-style/2002Aug/0396.html
> 
> 
> 3) pseudo-classes: introduce pseudo-classes to select elements based on @dir
>    and/or the initial value of 'writing-mode'. For example:
> 
>      body:ltr { margin: 10px 20px 30px 40px }
>      body:rtl { margin: 10px 40px 30px 20px }
>      body:ttb { margin: 40px 10px 20px 30px }
> 
>    This proposal is sketched here:
> 
>       http://lists.w3.org/Archives/Public/www-style/2010Jun/0190.html
> 
> 4) media queries: like 3), except that media queries are used instead
>    of pseudo-classes:
> 
>    @media (dir: ltr) { body { margin: 10px 20px 30px 40px }}
>    @media (dir: rtl) { body { margin: 10px 40px 30px 20px }}
>    @media (dir: ttb) { body { margin: 40px 10px 20px 30px }}
> 
> 5) alternate style sheets: put the rules for the various writing modes
>    into different style sheets that are selected through the alternate
>    style sheet mechanism in CSS. For example, there could be three files:
> 
>    lrt.css contains:
>      body { margin: 10px 20px 30px 40px }
> 
>    rtl.css contains:
>      body { margin: 10px 40px 30px 20px }
> 
>    ttb.css contains:
>      body { margin: 40px 10px 20px 30px }
> 
>    We would probably need to establish a convention to label style
>    sheets that are meant for vertical mode etc. so that these can be
>    applied automatically based on which "mode" the UA is in.
> 
> ---
> 
> Brief analysis
> 
> All proposals have the potenial to solve the problem at hand: to
> change certain property values when the writing-mode changes and to
> provide graceful fallback values when a UA that does not support
> vertical writing shows the document.
> 
> The proposals uses three distinct mechanisms to solve the problem:
> 
>   1) and 2) adds more properties/aliases on the "right" side
> 
>   3) and 4) adds new types of selectors/queries on the "left" side
> 
>   5) uses alternate style sheets
> 
> The solutions they offer are also different:
> 
>   1) and 2) allows only a distinct set of properties to be set based
>   on writing-mode changes
> 
>   3), 4), and 5) allows any set of properties to be set
> 
> The cost for implementations vary:
> 
>   2) uses more memory than the other as it stores duplicate sets of
>   values
> 
>   1) introduces new complexities in the cascading process; the
>   computed value of 'writing-mode' must be found before cascading can
>   be completed.
> 
>   3) and 4) introduces new functionality (selectors/media queries)
> 
>   5) is implementable without any changes to CSS
> 
> Personally, I'm leaning towards 3) or 4). 5) could also work. I find
> 1) and 2) limiting in the styling they can express, and 2) much too
> expensive in terms of memory used.


I want 1) or 2), plus 3), 4) or 5), as I wrote:
http://lists.w3.org/Archives/Public/www-style/2010Jun/0162.html
 > I believe that basic common styles for multiple writing modes should be
 > able to specify with one stylesheet using logical properties and when
 > we want further results for each writing mode, we should use alternate
 > stylesheets, or perhaps Media Queries querying UA features and/or 
 > user preferences.

The 3), 4) or 5) cannot solve all cases: 
- cannot use in inline style attributes, e.g. style="margin-left: 2em"
  can only be used for a specific writing-mode. 
  (Logical properties e.g. margin-start can be used in inline style.)

- cannot write basic default stylesheet.
  for example, in CSS2.1 Appendix D. Default style sheet for HTML 4:

    h1              { font-size: 2em; margin: .67em 0 }
    h2              { font-size: 1.5em; margin: .75em 0 }
    h3              { font-size: 1.17em; margin: .83em 0 }
    h4, p, blockquote, ul, fieldset, form, ol, dl, dir,
    menu            { margin: 1.12em 0 }
    blockquote      { margin-left: 40px; margin-right: 40px }
    ol, ul, dir,
    menu, dd        { margin-left: 40px }

This only works when writing-mode is lr-tb. If MQ can be used as:
    @media (dir: ltr) {
      ...
    }
    @media (dir: rtl) {
      ...
    }
    @media (dir: ttb) {
      ...
    }

it doesn't work when both horizontal and vertical writing modes are
used in same page.

MS IE supports many writing modes (total 8 writing modes, see:
http://blogs.msdn.com/b/ie/archive/2009/05/29/the-css-corner-writing-mode.aspx )
and seems to have good default style sheet, works in all
writing modes,

I suspect that IE has logical properties internally and
its default style sheet is written with that.

It shows that the capability of CSS is very limited without 
logical properties.


I don't believe the logical properties will be widely implemented
in short-term (possibly only implemented as epub book readers for
Japanese and Chinese contents), but I believe the CSS standards
must be defined for the future.

Håkon said in Tokyo last month, I was very impressed:
  How long will the web last? -- 500 years!

It means the invention of the web, inlcuding HTML and CSS,
can compare with the Gutenberg's invention 500 years ago.

I think the cost for implementations will not be big problem
in such future.

Best regards,

-- 
村上 真雄 (MURAKAMI Shinyu)
http://twitter.com/MurakamiShinyu
Antenna House Formatter:
http://www.antenna.co.jp/AHF/
http://www.antennahouse.com

Received on Tuesday, 8 June 2010 04:14:49 UTC