- From: MURAKAMI Shinyu <murakami@antenna.co.jp>
- Date: Sat, 13 Oct 2012 11:55:19 +0900
- To: Koji Ishii <kojiishi@gluesoft.co.jp>
- Cc: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Glenn Adams <glenn@skynav.com>, Tab Atkins Jr. <jackalmage@gmail.com>, Asmus Freytag <asmusf@ix.netcom.com>, Sylvain Galineau <sylvaing@microsoft.com>, "liam@w3.org" <liam@w3.org>, koba <koba@antenna.co.jp>, "www-style@w3.org" <www-style@w3.org>, fantasai <fantasai.lists@inkedblade.net>, "public-i18n-cjk@w3.org" <public-i18n-cjk@w3.org>
Koji Ishii <kojiishi@gluesoft.co.jp> wrote on 2012/10/12 15:53:43 > Agreed, I meant it's 2B, should this be edited to be more clear? > > I'm actually +1 to Liam on this one, so my personal opinion is 1B+2B+3C+4A. My opinion is 1B+2B+3A(or 3B, see comments)+4B. Some comments: > > 1A. before/after are hard to understand > > 1B. not hard to understand 1B. I understand the words start, end, before, and after as before something start something end something after something, it is obvious that the before/after are outer side and start/end are inner side, and blocks are outer things and inlines are inner things. > > 2A. before/after needs to memorize which axis it indicates > > 2B. head/tail doesn't better describe axis, should use other terminologies > > if this is the motivation ('head/tail'? You probably mean 'head/foot' - the CSSWG's 2012-05-30 decision was) 2B. > > 3A. Against any changes because of backward compatibility with XSL-FO > > and TTML > > 3B. terminology changes are ok as long as models are compatible > > 3C. the compatibility is lower priority than improving 3A(or 3B). "models are compatible" (3B) is not clear to me. If this means that the terms in property names and values are compatible and use improved terminology in the description, I will support this. I like 'block-before' and 'block-after' as improved terminology in descriptions, but I don't like 'caption-side: block-before', 'padding-block-after', etc. (it should be 'caption-side: before' and 'padding-after'.) I also think that 'element-before' and 'element-after' may be good descriptive terminology for understanding the ::before and ::after pseudo-elements, but we cannot change the syntax to ::element-before and ::element-after obviously. I support XSL-FO/TTML compatible keywords start/end/before/after and I support the 'start', 'end', 'block-before', and 'block-after' as more understandable terminology in the description. (For 'start/end', I don't think we need any change) > > > > 4A. Split logical directions as it is too controversial at this point > > and the demand is lower than other features in writing-modes > > 4B. splitting doesn't make sense 4B. Without logical direction terminology, the CSS Writing Modes spec will be difficult to understand. I hope CSSWG can agree keeping start/end/before/after keywords and improving terminology in descriptions (block-before, block-after). Regards, Shinyu Murakami Antenna House Koji Ishii <kojiishi@gluesoft.co.jp> wrote on 2012/10/12 15:53:43 > Agreed, I meant it's 2B, should this be edited to be more clear? > > I'm actually +1 to Liam on this one, so my personal opinion is 1B+2B+3C+4A. > > > Regards, > Koji > -----Original Message----- > From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp] > Sent: Friday, October 12, 2012 3:31 PM > To: Koji Ishii > Cc: Glenn Adams; Tab Atkins Jr.; Asmus Freytag; MURAKAMI Shinyu; Sylvain Galineau; liam@w3.org; koba; www-style@w3.org; fantasai; public-i18n-cjk@w3.org > Subject: Re: [css3-writing-modes] css-logical (was before/after terminology alternative? > > I think you should definitely add Liam's proposals for property names (block-before, inline-after,...). > > Regards, Martin. > > On 2012/10/12 15:06, Koji Ishii wrote: > > +1 to discuss again, although I don't think they're new information. Head/tail has some semantic problems not only in Japanese but globally because of its ambiguity as Liam pointed out, and that was already identified in my understanding. > > > > But it's true that more perspectives were provided at ML than we discussed at conf call. So far, opinions we see are: > > > > 1A. before/after are hard to understand > > 1B. not hard to understand > > > > 2A. before/after needs to memorize which axis it indicates > > 2B. head/tail doesn't better describe axis, should use other terminologies > > if this is the motivation > > > > 3A. Against any changes because of backward compatibility with XSL-FO > > and TTML > > 3B. terminology changes are ok as long as models are compatible > > 3C. the compatibility is lower priority than improving > > > > 4A. Split logical directions as it is too controversial at this point > > and the demand is lower than other features in writing-modes > > 4B. splitting doesn't make sense > > > > Did I miss any opinions? > > > > > > Regards, > > Koji > > > > ---------- > > From: Glenn Adams [mailto:glenn@skynav.com] > > Sent: Thursday, October 11, 2012 9:10 PM > > To: Tab Atkins Jr. > > Cc: Koji Ishii; Asmus Freytag; MURAKAMI Shinyu; Sylvain Galineau; > > "Martin J. Dürst"; liam@w3.org; koba; www-style@w3.org; fantasai; > > public-i18n-cjk@w3.org > > Subject: Re: [css3-writing-modes] css-logical (was before/after terminology alternative? > > > > > > On Thu, Oct 11, 2012 at 9:30 AM, Tab Atkins Jr.<jackalmage@gmail.com> wrote: > > On Wed, Oct 10, 2012 at 6:19 PM, Glenn Adams<glenn@skynav.com> wrote: > >> Due to my own fault, I failed to object at the time the WG made that > >> resolution. At this point, I will need to raise an FO unless it can > >> be agreed to revert that earlier decision. Which is easier? Doing an > >> FO process or reverting? > > Given that you'll apparently object to Koji's suggested compromise as > > well, it doesn't matter very much. > > > > I would like to remind that we have at least two new pieces of information that weren't available when the WG made its resolution: > > > > (1) evidence that head/tail has some semantic problems in Japanese; > > (2) evidence of a prior expressed intent to maintain or enhance a > > single underlying formatting model between CSS, XSL-FO, and (by > > extension) other specs that derive from these (e.g., TTML); > > > > Given this new information, I would suggest we put the question back on the table at the upcoming F2F to attempt to obtain a final, acceptable resolution.
Received on Saturday, 13 October 2012 02:55:48 UTC