- From: <bugzilla@jessica.w3.org>
- Date: Mon, 30 Jan 2012 20:07:04 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15100 Ian 'Hixie' Hickson <ian@hixie.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEW --- Comment #17 from Ian 'Hixie' Hickson <ian@hixie.ch> 2012-01-30 20:07:00 UTC --- > 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). -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 30 January 2012 20:07:06 UTC