4

I am referring to the usage a table for showing tabular data, eg: a spreadsheet, focusing on numbers, that I feel and see in UX that should be right aligned, properly formatted (with same number of decimals) to facilitate sums. For numbers this looks like a borderline case between semantics and formatting, for other kind of data types like dates choosing an alignment is more arbitrary.

I of course agree in using css when possible but css is not always supported or enabled and I see reasons to use align='right' since it gives decent default for when there is no support for css. This happens for example in my version of Lynx or when a browser user disables css to print.

Speculation: perhaps a more semantic attribute like <td number='true'> could do the work also if seen how problematic are 

 <input type='number'>

in HTML5 in respect to localization I would just expect from it to align on right.

I remember also at some point in time was difficult to override align attribute with css (and I remember css designers asking me to remove it from HTML) but this seems not true (anymore?) now

Am I missing something ? I am personally generating align='right' for numbers in my html.

My main question is: is there any reason except the fact that is deprecated to not use ALIGN='right' for properly formatted numbers on an HTML TD ?

Thanks.

Community
  • 1
  • 1
Testo Testini
  • 2,200
  • 18
  • 29
  • "CSS is not always supported or enabled..." What situations have you found where this is the case for modern web browsers? – abiessu Nov 04 '13 at 21:12
  • 1
    @abiessu - He does mention Lynx, which may be a valid use case for his requirements. – admdrew Nov 04 '13 at 21:18
  • @admdrew: ah, missed that, good point – abiessu Nov 04 '13 at 21:23
  • I'd suggest a preferred solution would be to define the alignment on a `` (rather than a ``) in the table for the specific column with `align="right"`, however even in HTML5 this has been removed. I think the presumption is that alignment is a visual, albeit helpful, aspect, not semantic. –  Nov 05 '13 at 01:01
  • @LegoStormtroopr COL as you say is also gone, I used COL but it looks like a dead feature that I think will be for real unsupported soon. About semantics, may be see second answer to unon. – Testo Testini Nov 05 '13 at 17:36
  • @abiessu also the case in which one disables CSS in the browser to print (but may be not so common) and, you never know, perhaps some new (micro?) devices that still have to come. – Testo Testini Nov 05 '13 at 17:37

2 Answers2

2

You sound like you know what you are talking about, so I would say just use align=right. Of course just be aware of the disadvantages of this:

  • more dificult to maintain later. If you have multiple tables and change the alignment you will need to do this for every table
  • search engins may penalise sites that rely heavily on deprecated tags
  • browsers could remove support for deprecated tags in future. They will anounce this in advance though, so of you expect the site to revive ongoing maintainable you will have time to remedy this
Braders
  • 447
  • 2
  • 11
  • Thanks, all valid points. In my use case I generate dynamically the html tables so I will have 'just' to change the code in one place and redeploy, however connecting to your third point, I think it will take at least a decade for that (if). – Testo Testini Nov 05 '13 at 16:51
2

I don’t think that aligning changes the semantics in this example. Certainly, it’s good to align the numbers, but no meaning is changed/lost when they are not aligned. It’s just a little bit harder to read the content. But this is the case for other CSS properties, too.

I wouldn’t use the align attribute. It was obsoleted for a reason ("must not be used by authors", not "should not")

Instead, have a look at Unicode’s figure space (U+2007). If you can’t use this character directly, you could use the character references:

  • hexadecimal: &#x2007;
  • decimal: &#8199; 
<table>
  <tr><td>100000.00</td></tr>
  <tr><td>&#8199;&#8199;&#8199;100.00</td></tr>
</table>
unor
  • 92,415
  • 26
  • 211
  • 360
  • I didn't know of the [figure space] thanks. Nice approach, there is some extra work in determining before a "max. number of ciphers" that suits the case. Could be configured by user or determined reading all the rows. I added your sample to the [question fiddle](http://jsfiddle.net/yTXA4/4/) – Testo Testini Nov 05 '13 at 17:17
  • About semantics, not sure but for me this case is similar, but less evident, to the classic "poetry" example: poetry can be read without new-lines but is not the same, some "magic" is lost. Poets will excuse me but I see something similar for numbers, if you cannot make additions in your mind, some magic is lost. – Testo Testini Nov 05 '13 at 17:27