W3C home > Mailing lists > Public > www-style@w3.org > February 2012

RE: [css3-text] combining transforms

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Sun, 12 Feb 2012 08:06:20 -0500
To: Florian Rivoal <florianr@opera.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0D3297D6BB@MAILR001.mail.lan>
It turned out that there's another reason to prefer keeping the current behavior.

EPUB 3 CSS Profile[1] defines that:
> the EPUB 3 CSS Profile includes the unprefixed text-transform
> property from CSS Text Level 3 using semantics as defined in
> [CSS3Text] and syntax as defined in [CSS3Text-20110412]

So whether we like it or not, UAs that share their rendering engines with EPUB reading systems and that are willing to support viewing EPUB files on the web will need to support 20110412 version of the syntax[2].

If the argument to prohibit combining isn't very strong, I think allowing it would help in terms of interoperability.

[1] http://epub-revision.googlecode.com/svn/trunk/build/30/spec/epub30-contentdocs.html#sec-css-text

[2] http://www.w3.org/TR/2011/WD-css3-text-20110412/#text-transform


Regards,
Koji

-----Original Message-----
From: Koji Ishii [mailto:kojiishi@gluesoft.co.jp] 
Sent: Wednesday, February 08, 2012 1:22 AM
To: Florian Rivoal; www-style@w3.org
Subject: RE: [css3-text] combining transforms

My apologies again. I was confused by combinations and inheritance, I think I now understand what you're talking about, so please allow me to try this again.

I still prefer current syntax since it's easier than making @rules for where it suffices.

Also we need to accept the risk that, when @text-transform was stabilized, put in the spec with "marked at risk", and then dropped during the CR unfortunately, we then simply loose the capability to combine casing and full-width unless we change the spec.


From these two reasons, I prefer to keep the current syntax. These two are not very strong though.


Regards,
Koji

-----Original Message-----
From: Koji Ishii [mailto:kojiishi@gluesoft.co.jp]
Sent: Tuesday, February 07, 2012 4:57 PM
To: Florian Rivoal; www-style@w3.org
Subject: RE: [css3-text] combining transforms

I noticed my last paragraph was broken, sorry about that. Allow me to rephrase.


I understand which order works the best is hard to figure out at this point, but we could take either one which we believe works better from use cases we know today, and add the other order in future if desired. Prohibiting doesn't still make sense to me.




-----Original Message-----
From: Koji Ishii [mailto:kojiishi@gluesoft.co.jp]
Sent: Tuesday, February 07, 2012 4:17 PM
To: Florian Rivoal; www-style@w3.org
Subject: RE: [css3-text] combining transforms

I'm fine not to allow multiple custom transforms together, but I'd like it be usable between predefined and custom, and between casing and full-width.

What you're proposing looks like not to allow them, and @text-transform doesn't help in that regard at all if I understand your wiki correctly.

I understand the order is best at this point, but we could take either, and add the other order in future if desired. Prohibiting doesn't still make sense to me.


-----Original Message-----
From: Florian Rivoal [mailto:florianr@opera.com]
Sent: Tuesday, February 07, 2012 3:36 PM
To: www-style@w3.org
Subject: Re: [css3-text] combining transforms

On Tue, 07 Feb 2012 10:39:05 +0100, Koji Ishii <kojiishi@gluesoft.co.jp>
wrote:

> While I understand the value of @-rule, I don't understand the value 
> of prohibiting combination from your explanations.

I don't want to prohibit combinations. I say we may not need two different mechanisms for combining.

> Let's say an author defined an @-rule to the root element so that the 
> document looks better in vertical flow. Applying "uppercase" to a div 
> canceling the @-rule doesn't make sense. It only makes sense when the 
> @-rule is about case transformation.

When the text-transform property is used to combine two transforms, the order in which they are applied is not under author control. It is predefined for predefined transforms. Without knowing what all transforms that are being combined are, we cannot specify in which order it is best to apply them. Because of that, I don't think the combination mechanism of the text-transform property is adequate to combine predefined transforms with custom transforms, or custom transforms together.

Since the combination mechanism in @text-transform is able to deal with all cases, thanks to leaving the order under author control, I propose that this should be the only mechanism we keep.

  - Florian

Received on Sunday, 12 February 2012 13:09:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:50 GMT