RE: [css3-writing-modes] The writing-mode property: existing implementations and naming

> On 06/22/2011 06:34 PM, Sylvain Galineau wrote:
> > As you know, the writing-mode property was originally defined in CSS3
> > Text many years ago [1]. It defined both block and text direction
> > using a set of values like lr-tb for Latin scripts or tb-rl for
> > Japanese. The property acted as a shorthand for the direction and block-
> progression properties.
> >
> > This was implemented in IE5 and has been supported since; it was,
> > unfortunately, implemented without a vendor prefix.
> >
> > The CSS3 Writing Modes spec now redefines writing-mode to define block
> > flow direction only. It also defines a writing mode as 'determined by
> > the writing-mode, direction and text-orientation properties'[2].
> >
> > I see two issues here.
> >
> > First, naming. Given the scope of the feature and the module name, I
> > would expect writing-mode to be a shorthand that completely defines a
> > writing mode, not part of it. This seems to have been its function and
> > intent in the original drafts. So I'd expect a writing-mode to be
> > defined by, say, the block-progression and text-orientation
> > properties, or using the writing-mode shorthand to set both at once.
> >
> > It just seems odd to have a property called 'writing-mode' that only
> > defines part of what a writing mode is.
> >
> > Second, existing implementations. The writing-mode property
> > implemented by IE5+ has seen a fair amount of use. Not always for the
> > exact purpose the feature was intended for e.g. to rotate text
> > sideways for purely esthetic reasons. But it's there. During our Kyoto
> > f2f we talked of other legacy features that were also been implemented
> > and thus should be deprecated instead of redefined. Specifically, new
> > semantics should use a new property name and the existing property would
> be called out as deprecated. This seems a similar scenario.
> >
> > Although if the new writing-mode could be a shorthand with semantics
> > that map closely to its original values then it may be possible to
> > address both issues at once.
> >
> > Thoughts ?
> Filed as ISSUE-183:
> So, the original writing-mode property, as implemented in IE6, didn't
> touch 'direction', actually. Neither does the writing-mode property
> defined in SVG.
> The definitions in the draft currently are compatible with IE6 and SVG
> implementations, just not with IE8's implementation.
> Given that, and given that vertical text and bidi are so rarely mixed
> together, I can't imagine anyone, aside from someone writing testcases,
> using it unprefixed and expecting it to change the 'direction' property.
> So I don't think that changing behavior from the 2003 CR will break
> anything. (Given the implementation legacy, it seems just as likely to
> unbreak things.)

We're crossing wires here. I never said we made writing-mode change
direction. My post refers to : writing-mode being implemented based
on an older draft, an issue for which we chose to deprecate for another
property (word-wrap, if I recall). Then to my expectation that this 
property would be a shorthand that defines a writing-mode fully (as it
was originally intended). Those are not overlapping issues, they're 
different comments. My expectation of what writing-mode should mean
is not related to any implementation; it's a suggestion of what it
should be based on both its name and history.

> With regards to making 'writing-mode' a shorthand that sets 'direction'
> per IE8, there are two problems with this
>    - it's incompatible with how 'writing-mode' is defined in SVG
>    - it encourages authors to unwittingly mess with the bidi settings of
> the document (These problems were explained at TPAC last year as part of
> the rationale for the current syntax. [1])
> So in conclusion, I don't think the property definitions should change.

Given that your new proposal is also incompatible with writing-mode as 
defined by SVG I don't see how that could settle the issue. You're proposing
a definition of writing-mode that not only clashes with existing implementations
and that defined by SVG. This makes the compatibility issue even larger and 
suggests writing-mode is not the name we want to use. 

> I can see a reason to tweak the terminology and/or the module title,
> though, if you have better suggestions.
> I'm closing this issue as No Change for now. Please let me know if this is
> acceptable.

No, I don't think this resolves it.

> [1]
> ~fantasai

Received on Thursday, 23 June 2011 22:35:03 UTC