- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Fri, 12 Oct 2012 21:39:23 -0700
- To: MURAKAMI Shinyu <murakami@antenna.co.jp>
- Cc: Koji Ishii <kojiishi@gluesoft.co.jp>, "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>
Can we just introduce 'mapping' property and consider things like margin-left, margin-right, etc. as logical properties? So this: div { margin: 0 100px 0 10px; mapping: left-to-right margin padding border; } will be rendered as: margin-left: 100px; margin-right: 10px; Benefits: 1. web designers who are not familiar too much with right to left concept may still do their design. Someone who will need to port it to rtl for example will add :dir(rtl) { mapping: ... } rules. 2. We don't need to pollute property namespace by additional properties. 3. This approach handles as properties defined by shortcuts (margin) as atomic properties like margin-left. 4. we don't need all these after,before,start,end,etc. interpretation nightmare. Yes, the 'mapping' changes directional properties interpretation but it is easy for example for RTL to imagine that style author is looking to the window surface from back side. So margin-left for him will be rendered on the right of window surface. The same is for ttb-rtl writing systems - the top is right side of the window. Semi-formal definition of the 'mapping' mapping: ( 'left-to-right' | 'top-to-right' ) ( 'margin' || 'padding' || 'border' || 'background-position' || 'all' ) + 'inherit' -- Andrew Fedoniouk. http://terrainformatica.com On Fri, Oct 12, 2012 at 7:55 PM, MURAKAMI Shinyu <murakami@antenna.co.jp> wrote: > 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 04:39:51 UTC