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

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

From: Håkon Wium Lie <howcome@opera.com>
Date: Mon, 7 Jun 2010 21:45:29 +0200
Message-ID: <19469.19545.166994.841362@gargle.gargle.HOWL>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: John Daggett <jdaggett@mozilla.com>, MURAKAMI Shinyu <murakami@antenna.co.jp>, Boris Zbarsky <bzbarsky@mit.edu>, www-style list <www-style@w3.org>, Hakon Wium Lie <howcome@opera.com>
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.

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Monday, 7 June 2010 19:46:23 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:28 GMT