Comment 401 for bug 353877

(In reply to David Baron [:dbaron] (UTC-7) from comment #394)
> Please see comment 288 and comment 379 (which, really, you should have read
> before adding comments here; if people don't read the bug before commenting,
> it will grow too big for anybody deciding what to do about the bug to read
> the comments).

I am familiar with this bug, as I've been following it for more than ten years. I don't see the point in calling out bugspam by adding further bugspam, and replies should really be more constructive than scolding. I'd say the ship has probably already sailed on the size of the comments here.

The problem with a style (CSS :-moz-nth-column()) solution (as mentioned in the W3 bug I linked to) to a content problem, is that:

  1. Content authors are less likely to have access to a site's stylesheet
     than to a site's markup.
  2. It's unmaintainable for separate, centralized stylesheets. Every table
     would need a class or id and changes to the number of columns for any
     table would require splitting it from the class or updating the site
     stylesheet's column styles for that id. What does the WYSIWYG or wiki
     or CMS process look like for this?
  3. Maintaining it closer to the table using inline styles or (perhaps
     eventually) scoped CSS doesn't really have any advantage over the
     align attribute approach, and may have significant disadvantage
     (such as having to update the individual page's style when table
     changes are made).

There's more in the 18026 ticket, although using col element alignment doesn't address much of the problem of using a columns physical position to determine it's appearance either, but in the current absence of a td:numeric selector, a pure markup solution can be important.