Re: [css3-writing-modes] a third option for implementing logical properties

David Hyatt wrote:

> > I think the problem with logical properties is not so much one of
> > implementation difficulty but that it creates a confusing authoring
> > model that doesn't completely solve problems related to supporting
> > both vertical and horizontal layout.
> 
> It's an authoring model that you only have to opt into when you need
> to design a layout that can work in multiple directions.

For vertical text layout it's *not* an opt-in model because you need
to somehow deal with display in browsers that only display horizontal
text.  The existing model of top/bottom/left/right is simple, an
author doesn't need to scratch their head to remember, hmm,
'logical-width' is really height in vertical layouts. 

> > in both vertical and horizontal layouts (e.g. images, captions,
> > form elements).
> 
> Form elements are not quite the same as images.  Form elements just
> do a writing-mode reset (similar to how they reset many other
> properties).  If you explicitly put writing-mode on a form control,
> there's no reason why it wouldn't respect the writing-mode (this
> works in IE today at least for some controls like buttons).

My point here is that if there are some elements that don't rotate
within vertical text layouts, then simply flipping box properties
based on the writing mode isn't always going to give you a workable
layout in both vertical and horizontal modes.

> > Unless *all* directionally dependent properties in CSS 2.1 *and*
> > in various CSS3 modules include directional equivalents (e.g.
> > border-radius), authors need some way of defining styles that are
> > dependent on the writing mode of a given element.
> 
> This may in fact be necessary, but that doesn't mean you should
> force authors to duplicate many physical declarations in two
> different blocks.  There is still value in having a logical
> abstraction even if it doesn't cover 100%.  If it covers 90%, that's
> still going to make life much easier for authors.

The new properties effectively make box properties a function of the
writing mode.  Why not define a more general way of making an arbitrary
set of styles dependent on the writing mode?  Especially if we can
avoid the need to define a bazillion new properties that interact
with each other.

Several ideas have been proposed but I think a pseudo-element that's
dependent on the value of writing-mode seems interesting.

  p { margin: 1em 0px; }
  p::writing-mode(vertical-rl) { margin: 0px 1em; }
  
To do the same thing with logical properties you need to write out
all the individual properties because the shorthand is physical-only:

  p { 
    margin: 1em 0px;
    margin-before: 1em;
    margin-after: 1em;
    margin-start: 0px;
    margin-end: 0px;
  }
  
How is this making life easier?

Another interesting thing to point out is that the defaults for
Western text don't really make sense as defaults for Japanese vertical
text.  The margin settings above are the Webkit user agent stylesheet
values.  With logical margins, the 1em top/bottom margins for
horizontal layout become 1em left/right margins for vertical text
layout. But vertical text layout in Japanese generally doesn't include
spaces between paragraphs.  With this model there's no way for user
agent stylesheets to use different defaults for different writing modes.

> > Once you have some mechanism for doing this, logical properties
> > are no longer a necessity, they become syntactic sugar that
> > simplify the
> 
> Extremely valuable syntactic sugar.  Do you really want to add
> hundreds of additional lines to your UA sheet in Gecko?  I feel like
> if you started trying to implement vertical text in Gecko, you would
> quickly realize how badly you need these properties...
>
> These properties are so valuable that they'd end up in WebKit anyway
> even if it's just an implementation detail to make writing the UA
> sheet easier.  That's how much they're needed.  I can't imagine how
> crazy the UA sheet would get to maintain if I had separate blocks
> for every directional possibility for every element.

I looked over Webkit's html.css [1], there appear to be 20 style rules
that define directionally-dependent box properties.  Of those, most set
top/bottom and left/right to the same value, so the vertical writing
modes are the only ones that would be affected.   That doesn't seem
like a huge list of properties that require a lot of maintenance.

> ...and if you need them in the UA sheet for directional abstraction,
> don't you think an author trying to write directionally abstract
> content would need them also?

Directionally abstract in what sense?!?  If someone is designing a
vertical text layout in Japanese do you really think they intend to
use that same layout as a template for an English layout?  Vertical
text layout has lots of features that make it quite distinct from
horizontal text layout, I think limiting authors to a "directionally
abstract" solution is a mistake.

> > But if you add logical properties on top of these, the authoring
> > model gets much more complicated for authors wanting to design
> > layouts with vertical text.  
> 
> No, it gets more complicated for authors wanting to design DUAL
> layouts.  Let's not confuse the two.

Until all browsers in use support vertical text layout, authors designing
layouts that use vertical text will need to consider the rendering in
existing browsers.  So effectively, those authors will be designing
dual layouts.

Regards,

John Daggett

[1] http://trac.webkit.org/browser/trunk/WebCore/css/html.css

Received on Sunday, 24 October 2010 14:16:50 UTC