- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 12 Jun 2009 17:51:10 -0700
- To: Rob Sayre <rsayre@mozilla.com>
- Cc: John Foliot <jfoliot@stanford.edu>, Sam Ruby <rubys@intertwingly.net>, public-html@w3.org
On Fri, Jun 12, 2009 at 4:25 PM, Rob Sayre<rsayre@mozilla.com> wrote: > On 6/12/09 7:16 PM, Jonas Sicking wrote: > > On Fri, Jun 12, 2009 at 3:00 PM, Rob Sayre<rsayre@mozilla.com> wrote: > > > On 6/12/09 5:44 PM, Jonas Sicking wrote > > Well, the question didn't seem to be as much "what good would it be to > abolish <font> from the web". That question seems easy to answer. > > If the answer is "it wouldn't be good", then I agree. What is your answer? > > > In an ideal world, where we actually could abolish <font> from the > web, having people use <span class="..."> would mean that we could > reduce the size of the language (not a huge benefit, but something), > it'd also reduce the size of pages if people used CSS applied to > paragraphs, rather than putting a <font> inside every paragraph. > > > What would http://www.google.com gain? That's a real use case. Of course, I > also mentioned that the wisdom and benefit of CSS depends on how much > context you have control over. If you're submitting a facebook comment, it > buys you basically nothing. Authors won't gain much by us deprecating <font>. Other than when they read HTML tutorials that list all the elements of HTML, or all in a particular category. The cost of a large language is definitely non-zero, even if the implementation cost isn't affected. But what we would gain is removing largely redundant parts of the spec. There is an incredible inertia in getting things removed from the spec, for the same reason that it's incredibly hard to remove a feature from firefox. There's an incredible stop-energy just because something used to be there. Point in case is @summary. There has been an incredible uproar that it was not carried over from HTML 4.But I haven't heard a single person complain that <section>, <article> or <div> doesn't have @summary (though admittedly I might have missed someone). Even though the arguments for keeping it on <table> applies just as well there. If we keep stylistic elements in the language, why should we stop at <font> and @color. Why not add @border-radios on <p> and @text-shadow on all elements? Leaving styling to CSS and just providing a few hooks (<style>, @style, rel=stylesheet, etc) allows us to keep a separation of concerns and let other people deal with styling. > That's a bad answer. People don't care about invalid markup if it works. > http://www.google.com would seem to be example number 1. > > > So what do you propose we do? Not specifically regarding font, but > regarding conformance requirements in general? > > > Keep UA conformance requirements, and write a document for lint tools after > they've competed for a while. imho, the grave concern over preventing typos > looks like a dishonest way of justifying central control. The technical > benefits they might provide are really small, if at all present--it smells > bad. That'd certainly be another way of doing it. The only difference seems to be that instead of us defining here what is valid and what isn't, we'd leave it up to the community. Still doesn't seem to answer Johns concern: "why should we care about validity (conformance)? Google doesn't and it does not seem to be impeding them any. It makes the discussion surrounding @summary et al moot: if I continue to use @summary in an HTML5 the document it's non-conforming. So what? It works for my intended audience, and that trumps some ideal of conformance that seems to be almost meaningless in practice. I get that it is "bad", but what does "bad" get me (vs. what being "good" will get me)?" Just changes if conformance is through lint tool or validator. / Jonas
Received on Saturday, 13 June 2009 00:52:07 UTC