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


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:


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:


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

  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.


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

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:38 UTC