This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 15100 as part of operation convergence. Originally filed: 2011-12-07 16:11:00 +0000 ================================================================================ #0 contributor@whatwg.org 2011-12-07 16:11:05 +0000 -------------------------------------------------------------------------------- Specification: http://www.w3.org/TR/html5/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: § 4.9 Today, right-aligning a numeric table column is much more work than it should be. Most browsers honor the alignment specified for the col element, but Mozilla seems to have drawn a line in the sand, claiming the HTML standard and the CSS standard conflict, leaving bug 915 unfixed for 13 years (and presumably forever). This means the best we can currently do, cross-browser, is to add a class to every numeric td element (in environments where the CSS is modifiable) or add alignment styling to each numeric td element, crazily bloating the size of large tables either way. One possible solution to the problem could just be the introduction of a tn (table numeric datum) element, with the expectation that the content be right-aligned. This makes cross-browser tables with a great deal of numeric data much smaller, and has the potential of allowing Mozilla & lightweight & mobile browsers (that have trouble rendering cells that inherit style from two parents) a simpler way to display tables using pure markup. Posted from: 216.229.170.227 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0 ================================================================================ #1 Brian Lalonde 2011-12-07 16:15:01 +0000 -------------------------------------------------------------------------------- (I am the original reporter.) To clarify, bug 915 in a Mozilla bug number: https://bugzilla.mozilla.org/show_bug.cgi?id=915 ================================================================================ #2 Ian 'Hixie' Hickson 2011-12-07 23:02:30 +0000 -------------------------------------------------------------------------------- Right-aligning a numeric column is easy — typically one line of CSS. Do you have a concrete example of a Web page with a numeric column so I can show that it is easy? ================================================================================ #3 Brian Lalonde 2011-12-07 23:07:48 +0000 -------------------------------------------------------------------------------- OK, try this one: http://webcoder.info/test/sqldata.html Can you show me how to accomplish this in a cross-browser way? The col element won't work in Mozilla. The :nth-child pseudo-selector won't work because of the rowspans. ================================================================================ #4 Tab Atkins Jr. 2011-12-08 09:04:10 +0000 -------------------------------------------------------------------------------- This behavior is a consequence of the CSS table model: http://www.w3.org/TR/CSS2/tables.html#columns I have no idea where you got your information that "most" browsers honor text-align on columns - *no* current browser does, to the best of my knowledge. I believe the last browser that did was IE6, because its table model wasn't based on CSS. The problem that you cite is being solved in Selectors 4 with the :col() and :nth-col() pseudoclasses: http://dev.w3.org/csswg/selectors4/#table-pseudos Thus, there is nothing for HTML to do. ================================================================================ #5 David Carlisle 2011-12-08 09:14:16 +0000 -------------------------------------------------------------------------------- without commenting on how col alignments should work, I'd note that html5 already introduces another markup suitable for highly numeric tables, namely <math><mtable>.... ================================================================================ #6 Brian Lalonde 2011-12-08 16:12:28 +0000 -------------------------------------------------------------------------------- (In reply to comment #4) > I have no idea where you got your information that "most" browsers honor > text-align on columns - *no* current browser does, to the best of my knowledge. > I believe the last browser that did was IE6, because its table model wasn't > based on CSS. I stand corrected (I thought WebKit did this as well), but we're both a bit wrong on this point. Current Opera, and IE (at least through version 8) both support the align attribute on the col element (IE also honors the text-alignment of the col element for the cells in that column). > The problem that you cite is being solved in Selectors 4 with the :col() and > :nth-col() pseudoclasses: http://dev.w3.org/csswg/selectors4/#table-pseudos I hadn't seen that yet. That, if supported, should be a big help in a few years. > Thus, there is nothing for HTML to do. The CSS selector approach works well enough when new style rules can be injected into content. For bug comments or forums or other environments that may not allow new styles, a markup solution that provided a semantic clue of a column's broad data type would still be more practical. (In reply to comment #5) That seems a bit like an abuse of MathML that may not be terribly reliable, though I could be wrong. ================================================================================ #7 David Carlisle 2011-12-08 16:20:31 +0000 -------------------------------------------------------------------------------- > That seems a bit like an abuse of MathML Not sure why you'd consider that abuse. Putting numeric data, including numeric tables, into web pages is its main reason for existing. I edit that spec and I wouldn't feel abused if you used it that way:-) > that may not be terribly reliable If you mean that it may not be implemented everywhere, that's true but its implementation status is known/detectable and any new markup has a greater problem that it isn't implemented anywhere. ================================================================================ #8 Brian Lalonde 2011-12-08 16:53:21 +0000 -------------------------------------------------------------------------------- Created attachment 1050 [details] Column alignment test/example ================================================================================ #9 Brian Lalonde 2011-12-08 16:54:40 +0000 -------------------------------------------------------------------------------- (In reply to comment #7) > If you mean that it may not be implemented everywhere, that's true but its > implementation status is known/detectable and any new markup has a greater > problem that it isn't implemented anywhere. Fair point. However, if I'm going to display a list of financial transactions, it seems reasonable to provide semantic clues to the renderer that the transaction description and amount columns are of fundamentally different types, and have different rendering expectations. Does MathML provide a way to render the description column left-aligned and the amount column right-aligned? Even if it did, I've already got a pragmatic (though suboptimal) solution that has a better reach (decorating each cell). Honestly, I'd like to see a C printf-style (or .NET String.Format or XPath format picture) format specifier supported by the col element (or at the CSS level), so each table datum could be separated from the presentation entirely, and provided in a more compact/direct way, though I doubt there's much appetite for this. I'm guessing a simple semantic number cell element would have broad appeal, though. ================================================================================ #10 Ian 'Hixie' Hickson 2011-12-09 22:14:22 +0000 -------------------------------------------------------------------------------- (In reply to comment #3) > OK, try this one: http://webcoder.info/test/sqldata.html Which cells do you want right-aligned? ================================================================================ #11 Brian Lalonde 2011-12-10 07:06:18 +0000 -------------------------------------------------------------------------------- In this case, the rightmost two, but examples for each could be useful. ================================================================================ #12 Ian 'Hixie' Hickson 2011-12-14 00:29:37 +0000 -------------------------------------------------------------------------------- Well with the way the table is done right now, the following rule would do what you want: td + td + td + td { text-align: right; } That doesn't seem like "much more work than it should be". And it'll be even easier once CSS selectors for tables are implemented. The reason I asked is that honestly, I wouldn't have thought you'd want the dates right-aligned, and I would have thought you'd want the numbers in the fourth column right-aligned but no the text. To get that effect would need classes on each cell; a <col> attribute wouldn't work. ================================================================================ #13 Brian Lalonde 2011-12-14 00:51:12 +0000 -------------------------------------------------------------------------------- Created attachment 1051 [details] A more complex alignment challenge Try and align the the last two columns in all current browsers without decorating each cell. ================================================================================ #14 Brian Lalonde 2011-12-14 01:06:43 +0000 -------------------------------------------------------------------------------- The columns I was talking about were for the URL I gave, not the simplified test file I attached later. I've attached the original (more complex) alignment challenge. As you can see, the rowspans make selecting by sibling position (td + ... + td or td:nth-child(n)) impossible. The proposed future CSS selector :nth-col() could simplify this for situations where CSS selectors may be applied, but there isn't really a way to add that to a forum post or a wiki or other user-contibuted content (or CMS body content) that only allows markup, so that reduces it's viability. > To get that effect would need classes on each cell; a <col> attribute wouldn't work. That depends on the browser (Opera and IE do align by column), but you are correct, as a cross-browser solution, it fails. Which is my point. Decorating each cell is a pretty suboptimal solution. Since we are already decorating each cell, why not provide a semantic element that at least provides a hint to the renderer as to the fundamental type of the data. A semantic element would be far more concise (<tn> rather than <td class=n>), and wouldn't require an external style rule to work. Not only would this achieve the practical goals of reducing the size and allowing the browser to align the column correctly, it might also allow for more appropriate sorting of that column or other operations that require better type awareness. ================================================================================ #15 Ian 'Hixie' Hickson 2012-01-28 18:07:00 +0000 -------------------------------------------------------------------------------- (In reply to comment #14) > > I've attached the original (more complex) alignment challenge. If you just want the last two columns right-aligned, the CSS I gave above would still work, even with the rowspans in that example. I agree that it's theoretically possible that there be tables where you'd need something more complicated where if you could just style columns directly it would be more convenient, but my overall point is that the cases where simple CSS can't handle it are far and few between, rare enough that it doesn't make sense to optimise the language for those cases. > The proposed future CSS selector :nth-col() could simplify this for situations > where CSS selectors may be applied Indeed. It could also be extended to support classes or other selectors, as in: col.numeric // td { text-align: right } I recommend contacting the CSS WG if that's something that is of interest. (The '//' combinator has in the past been proposed for "has a semantic relationship to".) > but there isn't really a way to add that to > a forum post or a wiki or other user-contibuted content (or CMS body content) > that only allows markup, so that reduces it's viability. In such a context you can just define a class value for the styles you want and let users use that. This is the same as how HTML doesn't offer a way to change the colour of text, even though sometimes the preferred way to indicate a particular semantic is colour. > > To get that effect would need classes on each cell; a <col> attribute wouldn't work. > > That depends on the browser I was specifically talking about the case where you wanted the numbers right-aligned but not the dates. <col> can't even do that theoretically. > Since we are already decorating each cell, why not provide a semantic element > that at least provides a hint to the renderer as to the fundamental type of the > data. A semantic element would be far more concise (<tn> rather than <td > class=n>), and wouldn't require an external style rule to work. There's a number of ways of doing this within a site (e.g. class values, data-* attributes, the <data> and <time> elements); if this is something that gets a lot of adoption, it would make sense to provide a more formal solution. But in practice I haven't seen this kind of thing much. More objective research would be useful. Status: Rejected Change Description: no spec change Rationale: The provided examples can be handled easily with CSS. Adding a feature to HTML to do this would be non-trivial and isn't justified by its cost-benefit ratio. ================================================================================ #16 Brian Lalonde 2012-01-28 23:28:48 +0000 -------------------------------------------------------------------------------- (In reply to comment #15) Reopening because I believe there was some misunderstanding. I'll try to clarify. I see that your CSS does work for the example, but it would be particularly fragile. Adding a column between or after those two, with any differing alignment needs, would break it. :nth-col() would be more durable in the face of rowspans, but still requires keeping the CSS in perfect sync with the markup. The '//' combinator allows some decoupling of presentation from position, but requires CSS support, and provides no numeric semantics, by which I mean potential support for localized presentation (commas & decimals), numeric sorting, database import, advanced indexing & querying, &c. > In such a context [user-generated content] > you can just define a class value for the styles you want and > let users use that. This is the same as how HTML doesn't offer a way to change > the colour of text, even though sometimes the preferred way to indicate a > particular semantic is colour. I was speaking as a user, not as the sysadmin. All of these solutions require nontrivial CSS control. User-authors of forum posts, wikis, other user-contributed content, and even emails, rarely have access to directly manage the CSS. > > Since we are already decorating each cell, why not provide a semantic element > > that at least provides a hint to the renderer as to the fundamental type of the > > data. A semantic element would be far more concise (<tn> rather than <td > > class=n>), and wouldn't require an external style rule to work. > > There's a number of ways of doing this within a site (e.g. class values, data-* > attributes, the <data> and <time> elements); if this is something that gets a > lot of adoption, it would make sense to provide a more formal solution. Decorating each cell is exactly the "work" I'm referring to: <td align=right> - The only one that works in user-contrib contexts, WYSIWYG editors, and most emails. Presentational markup. No built-in numeric semantics. <td class=n> - The current solution for site admin contexts. Verbose, and no built-in semantics. Requires add'l CSS support. <td data-type=n> - No built-in semantics. Requires add'l CSS support. <td><data value=999.99>999.99 - Still no semantics, and redundant. vs. <tn> - Built-in numeric semantics AND formatting. Efficiently terse. Would the benefits of a more formal solution (supporting highly granular datatypes such as various date and time levels, booleans, durations, &c.) to support localized presentation and sorting be worthwhile? I'm not sure the expectations for those types are as consistent. > But in practice I haven't seen this kind of thing much. More objective research would > be useful. I'm a bit incredulous that you haven't seen much use of numeric data in tables that the author (who may not control the CSS for the site) wishes to be right-aligned (is this culture-dependant?), with the hope that the browser will be just aware enough of the broad datatype to better display it (and maybe more). It's possible I've misunderstood your statement. More objective research would certainly be useful, especially if it presents any statistical findings as tabular data with numeric columns! ;) As always, thanks for your time! ================================================================================ #17 Ian 'Hixie' Hickson 2012-01-30 20:07:00 +0000 -------------------------------------------------------------------------------- > I see that your CSS does work for the example, but it would be particularly > fragile. Adding a column between or after those two, with any differing > alignment needs, would break it. Show me a site where this is a real problem. Unless there's a compelling case to be made that this problem exists a lot, we shouldn't address it. > :nth-col() would be more durable in the face of rowspans, but still requires > keeping the CSS in perfect sync with the markup. The '//' combinator allows > some decoupling of presentation from position, but requires CSS support, and > provides no numeric semantics, by which I mean potential support for localized > presentation (commas & decimals), numeric sorting, database import, advanced > indexing & querying, &c. The "numeric semantics" are already present in the page, by virtue of the data being numeric. That's machine-detectable. I don't see "keeping the CSS in perfect sync with the markup" as being a problem. If you really find this difficult you can just put the CSS in a scoped <style> block before the table. > All of these solutions require nontrivial CSS control. We're talking here about a few lines of CSS to set classes on TD elements. That _is_ trivial. > User-authors of forum posts, wikis, other user-contributed content, and even > emails, rarely have access to directly manage the CSS. They don't need to manage it, they just need to know the classes that site has available. > Decorating each cell is exactly the "work" I'm referring to: > > <td align=right> - The only one that works in user-contrib contexts, > WYSIWYG editors, and most emails. Presentational markup. No built-in numeric > semantics. Only "works" as far as you can style the alignment. In practice, what you really want is decimal alignment, precise control over padding, etc. In non-CSS environments, UAs can already automatically style numeric cells, so it doesn't help them. In CSS environments, CSS gives you more control for less work. > <td class=n> - The current solution for site admin contexts. Verbose, and > no built-in semantics. Requires add'l CSS support. No more or less verbose than align="", and yet gives more power in CSS environments, without taking anything away from non-CSS environments. > <td data-type=n> - No built-in semantics. Requires add'l CSS support. Same as class="". > <tn> - Built-in numeric semantics AND formatting. Efficiently terse. The backwards-compatibility story here is terrible (it wouldn't work in any existing browser, and would cause serious difficulties due to the changes it requires in the parser). Plus, it would be insufficient. What if the content isn't numeric but is of the form "foo - bar" and you want to align on the hyphen, say? > Would the benefits of a more formal solution (supporting highly granular > datatypes such as various date and time levels, booleans, durations, &c.) to > support localized presentation and sorting be worthwhile? I'm not even convinced there's a real problem here, so it's unclear that any solution is worthwhile. :-) > > But in practice I haven't seen this kind of thing much. More objective research would > > be useful. > > I'm a bit incredulous that you haven't seen much use of numeric data in tables > that the author (who may not control the CSS for the site) wishes to be > right-aligned (is this culture-dependant?), with the hope that the browser will > be just aware enough of the broad datatype to better display it (and maybe > more). It's possible I've misunderstood your statement. I meant that I haven't seen people marking up their tables to indicate which bits are numeric, which bits are dates, etc. Sure, people use align="", but they can use CSS just as easily in the vast majority of cases (more easily, even). ================================================================================ #18 Brian Lalonde 2012-01-31 05:48:21 +0000 -------------------------------------------------------------------------------- (In reply to comment #17) > Show me a site where this is a real problem. Unless there's a compelling case > to be made that this problem exists a lot, we shouldn't address it. I couldn't find a single production site using the td + td + ... approach! Everyone is decorating each cell. There must be a reason for this. Here's a few I found quickly: Wikipedia suggests align="right" or embedding a two-cell table in each numeric cell for the integer part and the fractional part of the number! http://en.wikipedia.org/wiki/Help:Table#Decimal_point_alignment http://en.wikipedia.org/wiki/Usage_share_of_web_browsers (align="right") Compass: "Experience cleaner markup without presentational classes." http://compass-style.org/examples/compass/tables/all/ td class='numeric' Google Analytics is right-aligning the entire table, then left-aligning text columns http://www.google.com/analytics/ table class="Yb" (.Yb td aligned right, td.so aligned left) Yahoo! Finance http://finance.yahoo.com/ td id="yui_3_3_0_2_1327965860085641" (styling individual IDs!) CNN Money http://money.cnn.com/data/markets/ td class="wsod_aRight" Amazon.com Order history td align="right" BankOfAmerica.com transactions td class="trans-balance-cell TL_NPI_Amt" Woot! account history qty td align="right" NumericaCU.org transactions td align="RIGHT" StackOverflow.com reputation page (leftmost column) td class="rep-cell" What does your bank use? > The "numeric semantics" are already present in the page, by virtue of the data > being numeric. That's machine-detectable. Loop through each cell in the table to determine which columns are numeric? That seems a pretty inefficient methodology! > I don't see "keeping the CSS in perfect sync with the markup" as being a > problem. If you really find this difficult you can just put the CSS in a scoped > <style> block before the table. This was discussed some time ago in StackOverflow, where the td + td + ... approach didn't gain much traction: http://stackoverflow.com/questions/1332406/better-way-to-right-align-text-in-html-table IE6 was at least part of the reason then, I think. But it was described as hackish. Even if you nail down the first td with :first-child so the selector doesn't "slide", the moment you change a column of td into th, or reposition the columns, you (your toolset) must remember to update the CSS, where possible. Even when scoped CSS is supported by browsers, I suspect it'll be disallowed to users on most sites out of security or branding concerns. Positional CSS selectors seem to violate the DRY principal. What happens when you've defined this behavior in a single CSS file across multiple tables and pages, then want to change one or more tables? > They don't need to manage it, they just need to know the classes that site has > available. That's assuming the site has created such a class, and wants to support it. > In practice, what you > really want is decimal alignment, precise control over padding, etc. No, I think just decimal alignment. Something like <col align=char>, but functional, and semantically attached to the data rather than maintained elsewhere. > In non-CSS environments, UAs can already automatically style numeric cells, so > it doesn't help them. I'm not familiar with this. Examples? > The backwards-compatibility story here is terrible (it wouldn't work in any > existing browser, and would cause serious difficulties due to the changes it > requires in the parser). Agreed. Adding an element, especially one that ruins backward compatibility should be avoided. However, there seems to be a widespread need for this functionality. > Plus, it would be insufficient. What if the content isn't numeric but is of the > form "foo - bar" and you want to align on the hyphen, say? That seems to be a strawman. How often does this come up, compared to numeric data? Examples? > I meant that I haven't seen people marking up their tables to indicate which > bits are numeric, which bits are dates, etc. Sure, people use align="", but > they can use CSS just as easily in the vast majority of cases (more easily, > even). Numbers have very specific expectations, dates and other types don't. If you have widespread examples of numeric data tables that don't decorate each cell, then I'm likely in error. Otherwise, the evidence I've provided would seem to suggest that there's an itch out there. ================================================================================
I agree that there's an itch, I'm just saying that class="" handles the itch fine. That sites seem to be doing exactly that (as you documented) seems to support my case. (By "non-CSS environments" I mean browsers that don't implement CSS, search engines, etc. I don't have any examples, I'm just saying that those tools can trivially do what you're asking for without any new attributes.)
(In reply to comment #1) Just to clarify, I'm not saying it isn't possible, only that decorating each cell with a CSS class is more work than it should be. It's bulky, inconsistent, nonportable, and requires infrastructure that is rarely there for content pulled from external sources or participatory content. I'm trying to figure out why you were initially sympathetic to avoiding inline attributes if those are an acceptable solution? I may have misread you humoring me, I guess. Your non-CSS examples still seem to need to sample cell/column to detect numeric data, which seems presumptuous. Am I missing the semantic denotation that marks these cells? I urge you to reconsider the WONTFIX.
(Reopening for a reasonable appeal.) Please, re-check the list. Nearly half of the sites use align="right". If this solution is the future, if <tn> is more a more difficult implementation than <footer> (for example), just un-deprecate align="right", then. It's ridiculously bulky, but at least it works reliably. CSS classes have no portability. Since HTML content just isn't monolithic documents from a single source anymore, but data dynamically amalgamated from many sources (and HTML email clients with lousy CSS support), an "every site/author for itself" approach to seems remiss of a standards body for something so archetypically basic as numeric cells.
(In reply to comment #2) > > Just to clarify, I'm not saying it isn't possible, only that decorating each > cell with a CSS class is more work than it should be. It's the same amount of work as align=right, which authors do now. If you want to avoid it, you can trivially do so by the CSS lines that I've already documented. > It's bulky, inconsistent, nonportable, > and requires infrastructure that is rarely there for content > pulled from external sources or participatory content. None of these seem to be true. > I'm trying to figure out why you were initially sympathetic to avoiding inline > attributes if those are an acceptable solution? Both are acceptable solutions. Personally I would recommend selectors, as it's concise and simple. Since you documented that people generally annotate every cell, I pointed out that that is also possible. > I may have misread you humoring me, I guess. If you read me as humouring you at all then you misread me. I have just been trying to understand the problem, and determine whether they are already addressed or not, so that we don't add redundant features. I am certainly sympathetic to your needs, I just think the ones that have been expressed so far are all trivially handled already. > Your non-CSS examples still seem to need to sample cell/column to detect > numeric data, which seems presumptuous. Am I missing the semantic denotation > that marks these cells? I'm not sure to what you refer here. > Please, re-check the list. Nearly half of the sites use align="right". I'm not sure what point this makes. They use an attribute on cells, just as I have said is possible. They don't _need_ to, because there's a shorter simpler CSS solution. > If this solution is the future, if <tn> is more a more difficult implementation > than <footer> (for example), just un-deprecate align="right", then. What does align=right do that a class does not? (A class does lots that align=right does not; e.g. gives you control over padding, which in my experience is critical to getting good results, as well as allowing proper decimal alignment, etc). > It's ridiculously bulky, but at least it works reliably. So do classes. > CSS classes have no portability. Not sure what you mean. You can put the style sheet right next to the table with scoped styles.
> > It's [CSS numeric cell class usage] bulky, inconsistent, > > nonportable, and requires infrastructure that is rarely there for content > > pulled from external sources or participatory content. > None of these seem to be true. If you'll indulge me just a bit further, I think I can make this case. 1. nonportable No one uses the same class name, so content isn't portable. If I publish a blog post with CSS classes for cell alignment, numeric cells will not display correctly in RSS readers (such as Google Reader). Aggregated and transplanted content will almost always break CSS-defined numeric cells. 2. inconsistent There's a pretty even split between those using align=right and those using CSS cell classes. 3. infrastructure Today, I'm not aware of a CMS or blogging site or WYSIWYG tool or comment system or wiki that supports numeric cell CSS classes by default. If I want to post a table of statistical or timing data to StackOverflow.com, for example, I must use align=right. This is not a big surprise, due to #1. 4. bulky Both CSS-decorated cells and align=right are bulky. In the sense that XSL-FO is bulky. I think we're in agreement there. But CSS isn't the optimal tool for columns specifically because there is no cascade on columns. Positional selectors aren't a serious option because they need to be defined independently for each individual table. I've never seen anything that leads me to believe any publishing software or tool chain will provide synchronization between individual table column styles and the central style definition store. I also haven't even seen any system that would assign each table an id and auto-apply styles to cells based on their column position or update positional selectors when a column is added or deleted. I've only ever seen buttons for align=right, and (rarely) a CSS class selector. We're years from scoped CSS, so that isn't a near-term workaround to support positional selectors. But, again, there's a reason no one is doing this. I guess we've already covered this. I've found accounting.js, http://josscrowcroft.github.com/accounting.js/ , but this is a javascript workaround to a markup problem. The story for aggregated and transplanted content is even worse for this approach. So today's choice still comes down to align=right, which works everywhere but is bulky and NOT SUPPORTED in HTML 5, or class=someNumClass which only works where it was originally published and has very little tool support. * What should political blogs, publishing statistical polling data, be using to align their tables of numbers correctly in feeds, and that paste into emails correctly? * What should financial sites be doing to display transactional and rate data in online banking and promotional pages so that nontechnical copyrighters can maintain the content without resorting to nonstandard markup? * How should spreadsheets and databases export tables and reports to HTML? Perhaps encouraging browser vendors to implement <col> alignment is one possible solution. It seems like they've had plenty of opportunity for that, though. Maybe your suggestion of detecting simple numeric content and automatically aligning accordingly is the way to go. Localized numeric data could be a little complicated and expensive to parse, though. But it has a much better transitional period than a <tn> element, of course. Is this a possibility? Again, thank you for your time. I regret that my inexpert communication may have wasted too much of it already.
> No one uses the same class name, so content isn't portable. > If I publish a blog post with CSS classes for cell alignment, numeric cells > will not display correctly in RSS readers (such as Google Reader). > Aggregated and transplanted content will almost always break CSS-defined > numeric cells. Sure, but this is exactly the kind of thing that scoped style sheets are intended to address. > There's a pretty even split between those using align=right and those using > CSS cell classes. I don't understand what point this makes. > Today, I'm not aware of a CMS or blogging site or WYSIWYG tool or comment > system or wiki that supports numeric cell CSS classes by default. > If I want to post a table of statistical or timing data to > StackOverflow.com, for example, I must use align=right. > This is not a big surprise, due to #1. It's not really clear to me why you have to use anything at all. Why aren't they automatically detecting numeric cells and styling them accordingly? > Both CSS-decorated cells and align=right are bulky. In the sense that XSL-FO > is bulky. I think we're in agreement there. Sure. Scoped stylesheets and a targetted selector can solve this in a few lines of code, in some cases just one line of code. > But CSS isn't the optimal tool for columns specifically because there is no > cascade on columns. The lack of CSS features isn't an argument for adding HTML features. It's an argument for adding CSS features. > Positional selectors aren't a serious option because they need to be defined > independently for each individual table. I don't see why that's not serious. > I've never seen anything that leads me to believe any publishing software or > tool chain will provide synchronization between individual table column > styles and the central style definition store. Sure. That's why we use scoped style sheets for this. > I also haven't even seen any system that would assign each table an id and > auto-apply styles to cells based on their column position or update > positional selectors when a column is added or deleted. There's also nobody who supports <tn>. People not doing something isn't necessarily an argument for it being a bad idea. :-) > We're years from scoped CSS, so that isn't a near-term workaround to support > positional selectors. Whatever solution we adopt here, if it's new syntax, is "years from" now. I don't see why this would be a problem either. There are solutions that work today already (e.g. classes). > Maybe your suggestion of detecting simple numeric content and automatically > aligning accordingly is the way to go. > Localized numeric data could be a little complicated and expensive to parse, > though. The <data> element may help with this (providing a way to encode the raw numeric data, separate from its presentation — this will be needed for sortable tables anyway). Fundamentally, the problem is: - authors want to style cells that contain numeric data - authors don't want to add markup to every numeric cell manually, at least not more than is required to give the numeric value in the first place Given just this, it seems to me the best solution is a CSS one — a way to specifically target numeric cells, with "numeric" being defined in some way based on the markup. Would a pseudo-class that matches numeric cells work? td:data-numeric { text-align: right } ...? This would match cells like: <td>0.1234</td> <td>123456</td> <td><data value="0.1234">0,1234</data></td> <td><data value="123456">123,456</data></td> Are there other types that need styling specially? Between the above (CSS detecting the type of data in an element), the '//' combinator (to go from a column to all its cells in the selector), and CSS features on the 'content' property to do localisation, it seems to me we would have all the bases covered. But these would really be CSS features, not HTML. > Again, thank you for your time. I regret that my inexpert communication may > have wasted too much of it already. Not at all. I apologise likewise that I am not able to find a solution that makes us both happy right now. :-)
(In reply to comment #6) Again, scoped stylesheets is one approach (albeit a possibly quite contentious one http://www.webdirections.org/blog/on-the-abominable-proposed-html5-scoped-attribute-for-style-elements/ ), but even if it were available now (or even soon), it still requires counting columns one way or another, which makes for less maintainable code. > > There's a pretty even split between those using align=right and those using > > CSS cell classes. > > I don't understand what point this makes. Just that there is no single workaround currently working for everyone. For whatever reason, one single, current, standard solution has not emerged. > It's not really clear to me why you have to use anything at all. Why aren't > they automatically detecting numeric cells and styling them accordingly? That's a good question. But requiring every system developer to act rationally and with full foresight may not be effective. > > But CSS isn't the optimal tool for columns specifically because there is no > > cascade on columns. > > The lack of CSS features isn't an argument for adding HTML features. It's an > argument for adding CSS features. There has been more than a dozen years of finger-pointing between the markup and style side of the column cascade issue, just based on https://bugzilla.mozilla.org/show_bug.cgi?id=915#c27 > > Positional selectors aren't a serious option because they need to be defined > > independently for each individual table. > > I don't see why that's not serious. For the same reason CSS eschews style="" attributes in favor of selectors. General rules are easier to maintain than rules for each individual column of each individual table. > > I also haven't even seen any system that would assign each table an id and > > auto-apply styles to cells based on their column position or update > > positional selectors when a column is added or deleted. > > There's also nobody who supports <tn>. People not doing something isn't > necessarily an argument for it being a bad idea. :-) That's fair. > > Maybe your suggestion of detecting simple numeric content and automatically > > aligning accordingly is the way to go. > > Localized numeric data could be a little complicated and expensive to parse, > > though. > > The <data> element may help with this (providing a way to encode the raw > numeric data, separate from its presentation — this will be needed for > sortable tables anyway). I love this idea! > Fundamentally, the problem is: > > - authors want to style cells that contain numeric data > - authors don't want to add markup to every numeric cell manually, at least > not more than is required to give the numeric value in the first place > > Given just this, it seems to me the best solution is a CSS one — a way to > specifically target numeric cells, with "numeric" being defined in some way > based on the markup. > > Would a pseudo-class that matches numeric cells work? > > td:data-numeric { text-align: right } > > ...? I love this idea, too! And I don't think they're mutually-exclusive. Both sound like excellent approaches! > This would match cells like: > > <td>0.1234</td> > <td>123456</td> > <td><data value="0.1234">0,1234</data></td> > <td><data value="123456">123,456</data></td> > > Are there other types that need styling specially? > > Between the above (CSS detecting the type of data in an element), the '//' > combinator (to go from a column to all its cells in the selector), and CSS > features on the 'content' property to do localisation, it seems to me we > would have all the bases covered. But these would really be CSS features, > not HTML. The HTML5 spec could potentially recommend the default styles for cells, i.e. td>data, td:data-numeric { text-align: right } > > Again, thank you for your time. I regret that my inexpert communication may > > have wasted too much of it already. > > Not at all. I apologise likewise that I am not able to find a solution that > makes us both happy right now. :-) Thanks for your indulgence. I'm quite encouraged by these methods!
The first step, then, is probably to get a selector to match elements whose contents are numeric, or that matches <data> elements whose values are numeric. Tab: Do you know if this is something that is plausible in the medium term? What we really need is "semantic" psuedo-classes that the host language (HTML in this case) can define, much like we do with the form control pseudos. Brian: I doubt we could change the default styles, since that would affect existing pages. But we can make it easy to provide new styles in author sheets.
(In reply to comment #8) > Brian: I doubt we could change the default styles, since that would affect > existing pages. But we can make it easy to provide new styles in author > sheets. That's fair. Thanks!
(In reply to comment #8) > The first step, then, is probably to get a selector to match elements whose > contents are numeric, or that matches <data> elements whose values are > numeric. > > Tab: Do you know if this is something that is plausible in the medium term? > What we really need is "semantic" psuedo-classes that the host language > (HTML in this case) can define, much like we do with the form control > pseudos. No, this is basically equivalent to the :contains() pseudoclass that got punted out of Selectors 3 for performance concerns. We could maybe put it into the complete profile for Selectors 4, but it wouldn't go in the fast profile that CSS Selectors uses, so it wouldn't solve your problem.
Nah, it wouldn't need to be as slow as :contains(). The idea is that you'd have some specific psuedo-classes like :numeric, which, like :link, would be defined by the host language. So then HTML would say "this <td> is :numeric", but *|*:numeric wouldn't be expensive because it would only maybe match on <td>s, and whether it did match or not would be trivially cacheable as just a property of the cell.
(In reply to Ian 'Hixie' Hickson from comment #11) > Nah, it wouldn't need to be as slow as :contains(). The idea is that you'd > have some specific psuedo-classes like :numeric, which, like :link, would be > defined by the host language. So then HTML would say "this <td> is > :numeric", but *|*:numeric wouldn't be expensive because it would only maybe > match on <td>s, and whether it did match or not would be trivially cacheable > as just a property of the cell. Okay, I see it's a bit different, but I'd still like to get some implementor interest in actually implementing this before I put it in anywhere.
Certainly.
Reassigning to CSS for now; please reassign back to me once there's enough implementor interest that the relevant pseudo-class has been added.