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

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

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 31 Dec 2008 16:21:00 -0800
Cc: www-style@w3.org
Message-Id: <C3EDBD83-D44C-466A-8FF3-A5EBC5EE2537@gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>


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
>
> No existing CSS properties work like this, and it would add a good
> bit of implementation complexity to do this.  (Although I think it's
> one of the same issues that makes CSS variables difficult.)
>
> I don't see what actual use cases doing this would help, though.
> (There are lots of cases where specifying unwanted properties causes
> unwanted behavior; I don't see why this one should be different.)

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.

>> 3. Shouldn't "When applied to a table cell" be replaced by "When  
>> applied
>> to a table cell, table column, or table column group"? Is is it
>
> I don't think text-align has any effects on columns or column
> groups.

Yeah, Tab pointed that out too. it just goes to show why I don't use  
COL very often: the 4 CSS properties that work with it seem like such  
a random collection. I thought for sure text-align (and vertical- 
align) would be amongst them, since COL does accept an "align"  
attribute that does affect the text alignment in the TDs (and a  
"valign" property that is equivalent to "vertical-align"). Outside of  
CSS properties, COL tags are useless for setting anything other than  
alignment and width, which are presentational anyway. So if we are  
supposed to use CSS for presentational aspects, then it is certainly  
counter-intuitive that text-align and vertical-align would not work on  
COLs, and that the only previous attribute to be replaced with CSS  
would be width. And that background-color is supported, but not color.

But I suppose that is a separate soapbox issue, and can be ignored now  
for this thread, now that I've got that off my chest.

>> apply text-align: '.' to a TABLE element, should it be inherited by  
>> the
>> TDs of that table? If it is "treated as 'start'", then the TDs would
>> inherit it as 'start' also, wouldn't they?
>
> It should be inherited when it doesn't apply.  We state generally
> that the "Applies To" line in general doesn't affect what is
> inherited unless specified otherwise:
>  # The computed value exists even when the property doesn't apply,
>  # as defined by the 'Applies To' line. However, some properties
>  # may define the computed value of a property for an element to
>  # depend on whether the property applies to that element.
>  --http://www.w3.org/TR/2007/CR-CSS21-20070719/cascade.html#computed-value

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.


>> 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.

Here's a contrived use case of the kind of thing I was imagining:

TD.price { text-align:"." }
TD.rating { text-align:"0" }

<table>
    <tr>
       <td rowspan="2">Thing #1</td>
       <td class="price">$ 45.00</td>
    </>
    <tr>
       <tdclass="rating">0++</td>
    </tr>
    <tr>
       <td rowspan="2">Thing #2</td>
       <td class="price">$ 5,000.00</td>
    </>
    <tr>
       <tdclass="rating">&ensp;&ensp;&ensp;0</td>
    </tr>
    <tr>
       <td rowspan="2">Thing #3</td>
       <td class="price">$ 5.00</td>
    </>
    <tr>
       <tdclass="rating">0++++</td>
    </tr>
</table>


> 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.  
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).

> One of the trickiest issues with implementing text-align: <string>
> is actually its effects on intrinsic width computation.  It
> effectively requires carrying around either two or four additional
> intrinsic preferred widths for table columns:  the intrinsic
> preferred width of string-aligned cells before the alignment point,
> and the same for after the alignment point, and potentially the same
> for intrinsic minimum widths.  Then we'd need to figure out exactly
> how those additional numbers should affect the table's intrinsic
> preferred width, the table's intrinsic minimum width (if at all),
> and the column-balancing algorithm.

Yes, that does sound complicated. I feel your pain.

> We also probably need to specify how text-align: <string> interacts
> with column-spanning cells.

Yeah. You'd have to know what column to associate it with and align  
its contents with that, I would think. And since you may not be able  
to determine that, you would have to probably default to the first  
column of the span.

>
>
> -David
>
> -- 
> L. David Baron                                 http://dbaron.org/
> Mozilla Corporation                       http://www.mozilla.com/
>
Received on Thursday, 1 January 2009 00:21:37 GMT

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