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

Quoting Sam Ruby <rubys@intertwingly.net>:

>
> So, as a first step, can I get people to express opinions on which of
> the following should apply to <font color="blue">:
>
> 1) It's a conformance error, such as it is today in HTML 5.
> 2) It's a a downplayed error at it represents vestigial markup.
> 3) It's conformant.
> 4) The HTML 5 spec should be silent on this matter.
>

So first off, 4) doesn't make much sense to me. I assume that you do
not mean that the HTML 5 spec should not define UA behavior when it
encounters <font> elements? That would defeat one of the main points
of HTML 5 from the point of view of implementers which is to define
the required behaviour in the face of real-world markup. That
interpretation would be totally unacceptable to me.

If you intend just that HTML 5 say nothing about if the element should
be used by authors, that would (currently) make it non-conforming by
default. Changing that would be a substantially bigger change to the
spec than just being silent in this case because it would also imply
that <xyz> was conformant. I assume it is not this bigger change that
we are supposed to be discussing. It could be explicitly mentioned
that <font> existed and that the draft did not take a position on its
conformance but, apart from being somewhat odd, that seems to violate
the "be silent" part of the condition.

That said, my preference if for 1 or 2 followed by 3. Specifically I
have no strong opinion about whether the error be "downplayed" or not
(I don't think that's a very useful concept in the spec since it is
basically a UI concern for conformance checkers and so can be left up
to their authors) but I do think it should be non-conforming. I'm
not sure if it goes beyond the scope of the question to advance
reasons *why* I hold that opinion, but in extremely condensed form, I 
think <font> has low utility since it can be replaced by easy CSS and 
CSS is needed to so more advanced things so it not not a large burden on 
authors to also require it where <font> could be used. I think most uses 
of <font> result in pages with poor externalities i.e. pages that do not 
work so well for users other than those that the original author was 
specifically targeting (AT users, search engines, people trying to 
screen scrape, etc.). Authors also report that using CSS instead of 
<font> results in pages with better maintainability. Given that the 
disadvantages of <font> seem to outweigh the advantages, making it 
non-conforming has the advantage of making the language smaller and thus 
easier to learn and of helping people QA their pages (e.g. new users who 
hear about validation but learn by copy and paste) find out that they 
are likely doing something wrong.

The main disadvantage of making <font> non conforming seems to be that 
wysiwyg editors have a hard time producing non-presentational markup and 
that said editors have to roundtrip documents that contain existing 
<font> elements. To take the latter point first, editors have to 
roundtrip documents containing <xyz> elements, not just <font>. 
Therefore any requirement that editors always produce conforming markup 
seems untenable. For editing new documents, <font>being non conforming 
may or may not encourage editors to produce code that does not suffer 
from the disadvantages of <font> described above. However the argument 
"some editors might still produce markup with the problems <font> has" 
seems insufficient to keep it conforming in the face of reasons not to 
do so.

Received on Thursday, 11 June 2009 09:07:18 UTC