(I am the original reporter.)

To clarify, bug 915 in a Mozilla bug number: https://bugzilla.mozilla.org/show_bug.cgi?id=915

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?

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.

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.

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

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

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

Created attachment 1050 [details]
Column alignment test/example

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

(In reply to comment #3)
> OK, try this one: http://webcoder.info/test/sqldata.html

Which cells do you want right-aligned?

(In reply to comment #10)
> Which cells do you want right-aligned?

In this case, the rightmost two, but examples for each could be useful.

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.

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.

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.

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


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

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.

(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!

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

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

This bug was cloned to create bug 18026 as part of operation convergence.

Mass move to "HTML WG"

Mass move to "HTML WG"

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: No spec change.
Rationale: This is already possible in CSS, as has been previously
described on this bug.