- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Wed, 31 Dec 2008 16:21:00 -0800
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: www-style@w3.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">   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 UTC