W3C home > Mailing lists > Public > www-style@w3.org > January 2009

Re: [CSS3] CSS Text Level 3, 6.1: text-align: string

From: L. David Baron <dbaron@dbaron.org>
Date: Wed, 31 Dec 2008 19:41:36 -0500
To: Brad Kemper <brad.kemper@gmail.com>
Cc: www-style@w3.org
Message-ID: <20090101004136.GA14450@pickering.dbaron.org>

On Wednesday 2008-12-31 16:21 -0800, Brad Kemper wrote:
> On Dec 31, 2008, at 12:14 PM, L. David Baron wrote:
>> On Tuesday 2008-12-30 14:36 -0800, Brad Kemper wrote:
>>> 2. Also, I don't know if it has been brought up before or not, but  
>>> when
>>> text-align:<string> is applied to a non-table-cell, shouldn't it  
>>> just be
>>> ignored, instead of being treated as "start"? That seems like it  
>>> would

> Well, I suppose it is not. It just seemed like there should be a way to 
> specify a fallback for when the value didn't apply. But since text-align 
> is inherited, it probably wouldn't be that big of a deal most of the time 
> to set the fallback value on an ancestor object.

That doesn't help.  The string value is still the only thing that
gets through in the "doesn't apply" case.

> OK, thanks; I wasn't aware of that. Given that, could this say "String  
> values for text-alignment do not apply to anything other than table  
> cells" (removing the part about it being treated as 'start')? That way, 
> the non-table-cell would still be free to inherit its text-alignment from 
> its nearest ancestor with a valid value, instead of being forced to be 
> "left". Isn't that the way things normally work if I give some invalid 
> value, such as <div style="text-align:not-valid;"> ? It seems like this 
> would be simpler than having a special built-in 'start' value.

This doesn't work.  'text-align: not-valid' can be ignored long
before we know whether something is a table cell.  But a value that
works some of the time needs to be cascaded through.

If fallback for this case is important, it should be in the value of
the property (e.g., 'text-align: "." right').  That said, I'm not
convince that it's important.

>>> 4. Shouldn't "that also have a character value for 'text-align' will
>>> align" be replaced by "that also have the same <string> value for
>>> 'text-align' will align"? After all, some cells in the column could
>>> align to some other character, couldn't they (if they had a different
>>> class, for instance)?
>> Are there use cases that require this?
> Well, both Tab and I assumed that was the intent anyway, and was just  
> not worded quite right.

I'm not convinced it was.  I could imagine that case not being
considered; the HTML4 spec says a good bit about char alignment but
doesn't mention it.

> Here's a contrived use case of the kind of thing I was imagining:
> TD.price { text-align:"." }
> TD.rating { text-align:"0" }

Seems like TD.rating really just should be text-align: left.

>> It would make implementation
>> a bit more complicated.  Could we instead say that when aligning
>> cells with different text-align: <string> values, implementations
>> should simply align either the start-edge or the end-edge of all the
>> alignment characters?
> I don't know how that would help in getting the desired results.  

Well, it's hard to know what the desired results are without use

> Although I do think that it should perhaps say something like that for  
> what happens if the character is not in the text of the table cell (I  
> haven't tested that, but in the most common use case of decimal  
> alignment, I image end-edge would be preferred, if there is not  
> decimal/period/full-stop character).

Agreed that it needs to say something.  (I vaguely remember brining
that issue up many years ago.)  For that case, the start-edge is
probably preferred, so you get:

I'd also note that how to align the character has to be specified
anyway for the case of different cells that align the same character
in different fonts (where that character has different widths).
(The common realistic case here is probably changes in font-weight.)


L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Thursday, 1 January 2009 00:42:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:23 UTC