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

Sam Ruby writes:

> 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.

I don't see how 4 is possible: either the spec includes it in the list
of valid things in HTML 5 or it doesn't -- no ambiguity either way.

Considering how <font color=blue> is used, I don't think the spec should
condone it.  Its use seems to fall into four main categories:

 A  Styling:  The author desires blue text for the site's theme.  The
    blue conveys no semantics, and as such shouldn't be in the document
    at all.  This is better done with CSS.

 B  Highlighting/emphasis:  The author wishes to draw attention to
    particular words or phrases, so uses a different colour to make them
    stand out from the surrounding text.  The blueness is attempting to
    conveying semantics, but won't always succeed: some user-agents
    don't have coloured output; some users can't see colours.

    Whereas using the element specced to have that desired semantic
    (such as <em>, <mark>, <cite>, <kbd>, or <var>) allows all
    user-agents to convey that in an appropriate way.  Authors can still
    style the element to be blue for users with graphical user-agents.

    Admittedly HTML 5 doesn't have elements to convey every possible
    desired nuance, but picking the nearest and using a class is still
    likely to be better than using colours directly:

      http://www.theregister.co.uk/2001/02/01/the_color_of_irony/

 C  Disambiguation:  Different colours are used throughout some text to
    indicate who said what, or otherwise indicate the source.  For
    example, Emma-Jane annotates writes "Emma's comments in red" at the
    top of a document I've created; Macsen then similarly adds his
    comments, in blue.

    I don't think HTML 5 currently has a solution for this.  Perhaps
    something like <ins> or <mark> could be used with a class to
    distinguish the annotators from each other -- but then without the
    CSS that would be lost, with non-CSS user-agents unable to convey
    this distinction to users.

 D  Hiding spoilers:  To avoid users accidentally seeing information
    they don't (yet) want to, such as answers to quiz questions, authors
    make them initially hidden.  One method, which doesn't require any
    scripting, is to set indentical colours (for example blue text on a
    blue background) and tell a user to drag their mouse over the text
    to highlight it and make it readable.

    HTML 5 provides <details> for doing this in a way which can work in
    all user-agents.

In B and D the use of <font color=blue> is harmful, so this use should
be non-conforming.  An author who wishes to comply with HTML 5 should
change their page to use more appropriate elements.  This is different
from existing downplayed errors, where the vestigial forms don't result
in anybody having a worse user experience (and the author may consider
complying to be mere bureaucratic hoop-jumping), for example:

* A different standards-mode-triggering doctype doesn't affect anything.
* <script lang=JavaScript> will still be interpreted as JavaScript for
  all users.
* An <img> won't have a border whether border=0 is specified nor not.

But ... this doesn't necessarily mean <font color=blue> should itself be
non-confirming.  Tables used for layout or <h1> elements used just to
make text bigger are also non-conforming, but obviously the elements are
permitted in the language; that an automated conformance checker may not
be able to detect the non-conforming uses doesn't make them valid.

However <table> and <h1> have uses which can't be achieved in other
ways.  Even if <font color=blue> in category A above is deemed
non-harmful, it's still not the preferred way of achieving that result.
Removing <font color=blue> from HTML in no way restricts what can be
achieved.

So it's often harmful and never needed.  Option 1, conformance error
seems the most appropriate.

Option 2 makes sense if:

* Authors who have current pages with <font color=blue> and use
  conformance checkers to check those pages mostly have non-harmful uses
  of it.
* Those pages are likely to contain other, more serious errors.
* The reporting of <font color=blue> non-conformance so overwhelms the
  other errors that the author fails to spot them, or decides to give up
  on the goal of conforming.

but it has these disadvantages compared with Option 1:

* It apparently condones the harmful uses of <font color=blue> as being
  unimportant.
* It may lead to developers who would have improved their mark-up not to
  bother.
* It muddies the water about what downplayed errors are.  Usability
  advocates would still encourage authors to avoid <font color=blue>,
  which gives the impression that even downplayed errors matter, so
  authors may spend time addressing other downplayed errors -- which
  rather defeats the purpose of having the category.

In practice I suspect many authors will simply replace <font color=blue>
with <span style="color: blue"> either way -- which simply shuts the
conformance checker up without actually improving the usability issues.

On balance I contend Option 1 is more appropriate than Option 2.

That still leaves usage in category C above.  While HTML 5 doesn't seem
to offer a better solution than <font color=blue> for this, that isn't a
good solution either.  About the only advantage it has over using CSS to
provide the colours is that it's more likely to work in feed content:
there are at least some feed readers which strip styles but preserve
<font color=blue>.

But this one not-very-good advantage of a minority usage that itself has
many flaws is not sufficient reason to keep the element.  We possibly
need a better solution for this category, but that's not a reason for
keeping something which is so flawed and harmful.

Smylers

Received on Thursday, 11 June 2009 11:39:18 UTC