http://www.w3.org/Bugs/Public/show_bug.cgi?id=9355
Ian 'Hixie' Hickson <ian@hixie.ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #3 from Ian 'Hixie' Hickson <ian@hixie.ch> 2010-04-02 07:56:33 ---
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 reason for not having any presentational markup at all (modulo style="" and
<style>, for which see below) is simple: it is significantly easier to teach an
absolute rule than a complicated one.
This is analogous to how wearing a car seat belt is required in many
jurisdictions regardless of the speed of the vehicles involved. One is far more
likely to be wearing one's seat belt when going at 60kph if one always has to
wear one's seat belt, than if one only has to wear it when going faster than
30kph.
Similarly, with presentational markup, if we say "you can't use <font
face=Courier> when it would be for marking up what is computer code and what
isn't, because that would leave speech browsers in the cold, but you can use
<font face=Times> or <font face=Helvetica> to decide on the style of the
paragraphs because that doesn't have any semantic value", then people are far
more likely to get really confused.
This would argue for removing style="" and <style> as well, as well as <div>,
which is more or less only useful for styling. And indeed, an earlier version
of the draft had neither style="" nor <div>. Unfortunately, the world is not a
perfect place, and there are some use cases for which one needs an escape
hatch. Sometimes one needs <div> to hang some styles on, sometimes one needs
style="" to experiment with a solution when doing rapid application
development. Similarly, <style> is sometimes needed to have a self-contained
spec, because having people use data:text/css,... instead simply leads to
harder-to-maintain documents. So we have them in the spec, but discourage
authors from using them, but we can still pretend that there's a line, because
they're CSS, and CSS is not HTML, and so hopefully it authors will do the right
thing.
(If we had the "subdued errors" concept still, I would argue for having
style="" and <div> flagged as such, but we no longer have that.)
Here are some replied to specific points made:
> The spec lists a lot of obsolete features:
>
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#obsolete>
>
> Some of them are singled out to be obsolete but conforming, but the large
> majority of them are non-conforming. I have seen no clear reason for the
> distinction.
The ones that are obsolete but conforming are the ones that are extremely
common in legacy pages but have no effect, and so are harmless.
> Moreover, in many cases -- e.g., most of the obsolete presentational
> markup -- the non-conforming markup is defined to be canonically equivalent to
> some conforming markup.
I don't think there are any cases where a canonical equivalent is provided; the
spec is just giving suggestions of alternatives that might be more appropriate.
> In fact, in a lot of cases the non-conforming markup is significantly simpler
> or shorter than the conforming markup. For instance, compare <u> to <span
> style=text-decoration:underline>.
Both would be inappropriate. Neither convey any useful semantic. How should the
span be rendered on a braille display or in speech synthesis or on a text
display with no underline capability?
> There can be other benefits too -- once when
> I changed <table border="x"> to use CSS, a user complained that this degraded
> display in his text-based non-CSS browser.
That's presumably a bug in the text-based non-CSS browser, though it's hard to
tell without specifics.
> All this makes some of the
> non-conforming markup *more* attractive from an author standpoint.
I think that's rather a stretch. "All this" is just two arguments ("it's
shorter than using something equally bad" and "it can be more compatible with
text browsers"), neither of which are at all compelling.
> (In some
> cases, using stylesheets rather than inline markup would be easier; but if this
> is a reason to ban presentational markup entirely, we need to ban style=""
> too.)
We more or less do