W3C home > Mailing lists > Public > public-html@w3.org > June 2009

Re: <font color="blue"> (was ISSUE-32)

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 12 Jun 2009 17:51:10 -0700
Message-ID: <63df84f0906121751v41e95fat70556c5a0dd90f8c@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:04 UTC