W3C home > Mailing lists > Public > public-i18n-cjk@w3.org > July to September 2012

RE: [css3-writing-modes] before/after terminology alternative?

From: Phillips, Addison <addison@lab126.com>
Date: Sun, 23 Sep 2012 13:57:48 -0700
To: Koji Ishii <kojiishi@gluesoft.co.jp>, Glenn Adams <glenn@skynav.com>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, MURAKAMI Shinyu <murakami@antenna.co.jp>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>, "public-i18n-cjk@w3.org" <public-i18n-cjk@w3.org>
Message-ID: <131F80DEA635F044946897AFDA9AC34773A6FB24BF@EX-SEA31-D.ant.amazon.com>
In my opinion, there are two classes of "directional" identifier. Both kinds can be important for certain use cases.

The first sort are the "logical" identifiers, such as "before", "after", "start", and "end". These identifiers are tied to a given page's layout and direction (and were created to help with bidirectional text support). They are the "best practice" to use from an internationalization perspective for most purposes.

The other sort are directional identifiers such as "left", "right", "top", "bottom". These are useful for cases in which one wants explicit stylistic control over position independent of a page's layout or direction. These tend to be deprecated for internationalization purposes, but they have their use, especially in fixed layouts.

The problem here, for me, is that "head"/"foot" are more typical of the second category, while "before"/"after" are of the former. We *want* people to use logical identifiers whenever possible and to use identifiers that remind them that the direction, writing mode, or other changes may cause the interpretation of their style to change accordingly. Start/end and before/after *are* harder to understand for people who are making the assumption that the origin point of their page is always the upper left corner and that layout always proceeds in an horizontal-lr mode. But they are only just harder enough to understand that they remind folks that they are making an assumption (perhaps only exceedingly rarely violated in their lives) that may be incorrect. A small learning bump is definitely required to know what before/after mean in this context.

However, a complication is that, in this case, before/after and head/foot always mean the same thing (unless we suppose a bottom-to-top writing-mode that further contravenes convention and has the page head on the bottom). So...

As an internationalization person, I tend to favor the logical identifiers we already have, acknowledging the compatibility argument and adding that the learning curve imposed is actually a Good Thing (and also a smallish thing).

But I also acknowledge the having a logical identifier for something that doesn't actually change its positional meaning under any currently foreseen circumstance is unnecessarily confusing.

(chair hat on starting here) FWIW, I added this item to the I18N Core WG's agenda for this week.

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.



> -----Original Message-----
> From: Koji Ishii [mailto:kojiishi@gluesoft.co.jp]
> Sent: Sunday, September 23, 2012 5:12 AM
> To: Glenn Adams
> Cc: Tab Atkins Jr.; MURAKAMI Shinyu; fantasai; www-style@w3.org; public-
> i18n-cjk@w3.org
> Subject: RE: [css3-writing-modes] before/after terminology alternative?
> 
> > My position is as follows:
> > • before/after is already used in standard usage in the W3C for the
> >   precise same semantics as are being discussed here, and this has
> >   been the case for at least 10 years
> > • i am not aware of any complaints regarding understanding this usage
> >   for these many years
> > • the claim that before/after is difficult to understand is nothing but
> >   speculation
> > • changing before/after to head/foot in the CSS context introduces a
> >    definite level of new confusion by assigning new names to existing
> >   understood names
> > • XSL-FO and TTML, both of which make use of CSS for keywords and
> >   semantics, will either require modification or exist in a variant form if
> >   one set of names (before/after) is used with XSL-FO and TTML and
> >   another set is used with CSS
> > My conclusion is that compatibility should take precedence over the
> > speculation that somehow these new keywords are easier to understand
> > than the existing keywords.
> 
> I think you agree that CSS has wider audiences than XSL-FO has, so it's not a
> surprise if things that worked good for XSL-FO may not work for CSS.
> 
> The "hard to understand" issue was, if I remember correctly, raised by Sylvain a
> year or so ago, and then a good number of people seem to agree with him on
> the ML. Those are their real opinions, not speculations; they're not saying "may
> be hard for someone" but "is hard for me."
> 
> Saying "hard to understand" is subjective, so not everyone may agree. If you
> change "speculation" to "subjective," it's more understandable. But when a
> good number of people say "hard to understand for me," even if it's subjective
> and even if it's not hard to understand for you, shouldn't we take them into
> account?
> 
> I agree with you that compatibility shouldn't be taken light if no issues arose,
> but unfortunately, an issue arose, and many agreed with it.
> 
> I actually think this is an unfortunate situation. But given the issue is real, what
> else could we do?
> 
> 
> Regards,
> Koji

Received on Sunday, 23 September 2012 20:58:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 23 September 2012 20:58:19 GMT