- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Fri, 1 Apr 2011 18:14:48 -0400
- To: www-archive@w3.org
This Change Proposal says that there are only two use-cases given in the other Change Proposal, namely Chinese text and misspelled words. In fact, that was only the last point of the extensive Rationale, the remainder of which remains almost entirely unaddressed. The primary use-case for <u> is presentational markup, such as in WYSIWYG editors, or when your client tells you "I want that text underlined over there" and you aren't being paid to give him a lecture on the importance of media independence. The claim that if we make <u> conforming we should also make <font> <big> etc. etc. etc. conforming does not address the extensive rebuttal of this argument that I wrote for the other change proposal (beginning "<u> should not be invalid just because . . ."). I won't repeat it here, but to summarize the most important points: the length savings of <u> are greater than for most of the listed elements; <u> is much more similar to <b> and <i> than to the non-conforming elements listed; and maybe we should make other presentational markup valid, but that can be dealt with in a separate bug/issue and isn't relevant here. (In my view, any presentational tag that's commonly used and is simply a handy shorthand for CSS rules should be made valid. That means <u> and <tt> should be; <blink> should not because it's not commonly wanted, and is arguably extremely unwanted; <font> and <center> and align= should not because they don't follow the CSS model. This position is entirely consistent, and could be achieved by adding just a couple more tags beyond <u>, maybe <tt> and <big>.) The fact is, <b> is presentational markup too. The tag name stands for "bold"; everyone uses it if and only if they want bold text; and the specification says that <b> is to be used for "spans of text whose typical typographic presentation is boldened", so it's defined solely in terms of whether you want it to look bold. Yes, you can quibble that "b { font-weight: normal; font-variant: small-caps }" would be correct according to the official definition, but that's a purely academic point, because nobody in his right mind is going to do that, ever. Just because there might be someone out there who's using <b> (or <i> or <sub> or <sup> or <small> or anything like that) for an effect other than the normal one, and the spec technically allows this, doesn't mean that it's somehow less presentational in the real world. The fact that the definition allows room to use <b> other than for bolding things is not meaningful -- it's playing word games in an attempt to make it not look like it's presentational, because of a long-standing crusade in the web standards community against presentational markup. In *practice* it still means "bold", just like it always did. Presentational markup is not bad per se. Some typographical effects are commonly required but have no particular meaning. Sometimes authors just want some text to be bold or italic or underlined, and don't want to have to reason about *why* they want it in some abstract fashion. WYSIWYG editors are the only way that almost anyone edits any rich-text format, including HTML, because presentation does not require reasoning about anything you can't see before your eyes. Everyone can understand the difference between "this makes things bold" and "this makes things italic". But would *you* be able to tell when you should use something that "represents stress emphasis of its contents" vs. "represents strong importance for its contents", if you didn't already know one was <em> and one was <strong>? So the real use-case here is presentation, and that's a completely valid use-case. Without <u>, we have to use <span style="text-decoration: underline"> or <span class=u> or something like that. Since underlining is one of the commonest stylistic effects available, there's no reason to declare an existing, fully-functioning shortcut verboten. <u> has a demonstrably useful effect, and it results in much shorter markup than equally presentational alternatives. On the other hand, if <b> and <i> are actually semantic and not presentational, then so is <u>. The proposed text closely follows the pattern set by <b> and <i>'s current definitions. Even if it were the case that "a span of text to be stylistically offset from the normal prose" is already represented by <i>, there's no reason given why we can't have two elements with the same semantics. I would like to specifically agree with this quote from the change proposal: "Inconsistent application of rationales leads to very poor language design, confusing authors ("why is X possible but not the almost identical Y?" is a common question in such cases)." Confusing authors is an important concern here, but it's one that speaks in favor of making <u> conforming. Authors are all familiar with word processors and other formatting systems in which bold, italic, and underline are all prominently available right next to each other. Allowing only bold and italics, but not underlining, is sure to be extremely confusing to authors. For the sake of consistency and meeting author expectations, it's important that <b>, <i>, and <u> all have the same conformance status. As far as underlines being confusing on the web because of links, I agree with that, but authors still want them. This is clear when you go to any WYSIWYG web editor, since in my experience, they all have underline buttons. Nobody has provided any reasoning to suggest that making <u> invalid will discourage the use of *underlining* -- if we look at how major web applications are written, it seems much more likely that people will just switch to <span style="text-decoration:bold"> or <span class=u>. I know that when the issue of moving MediaWiki to future HTML versions came up once a few years ago, then-lead developer Brion Vibber said something to the effect of "If some future version of HTML is stupid enough to ban <b>, we'll just automatically rewrite it to <span style='font-weight: bold'> to keep the validator happy." In my experience, this approach is ubiquitous. The application developers who care about validity only care insofar as the validator is happy, and will not be deterred from outputting uglier markup if necessary. Look at how many sites diligently wrote <script type="text/javascript"> for so many years despite the fact that the attribute had no effect in any browser, just because the validator told them to. The same goes for any other useless element or attribute, like <html>/<head> with no attributes, xmlns="", etc., etc. Authors who care about validation are not deterred by having to write longer markup to achieve the same effect. So ruling out <u> will only discourage the use of the <u> element itself, not the use of underlining. Given that underlining will happen anyway, there's no reason to make markup more bloated so that web pages are harder to read. Responding to Ian Hickson's change proposal: "The length savings argument is bogus because the alternative to <u> is not <span style="blablabla"> but simple an appropriate semantic element." This is simply wrong, because the most important use-case under consideration is <u> as a presentational element. No semantic element is appropriate, so the correct alternative is <span>. "The best practice (for accessibility, maintainability, and semantic analysis) is widely recognised to be the separation of semantics and styles, which argues against presentational markup such as in this proposal." No evidence or reasoning is provided to back this statement up. We are not told who has "widely recognised" this, and more importantly, we aren't told why. I would say that it's widely recognized that inline markup has several major disadvantages, and relying primarily on CSS is the only reasonable way to write sites these days, but I dispute the claim that *all* presentational markup is harmful. Moreover, making <u> invalid would not reduce presentational markup, it would just shift people to using <span>, as I explain above. There is no evidence or reasoning provided to support the implicit claim that making <u> invalid will reduce the use of presentational markup. Overall, we have clear author interest in being able to underline text as a purely presentational matter, as suggested by every WYSIWYG editor I can remember seeing. Even if making <u> invalid would actually discourage presentational markup (which it will not), the reasons for wanting to discourage presentational markup so absolutely are entirely theoretical and unsubstantiated. Since it is undisputed that many authors want presentational markup for underlining, there are no grounds for accepting the disputed claim that all presentational markup is bad in the absence of specific evidence or reasoning. Of course, the issue could be reopened at a later date if anyone produces specific evidence or reasoning that <u> will have some kind of negative effect, without having to invoke a disputed general principle.
Received on Friday, 1 April 2011 22:15:42 UTC