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

Sorry, not a member of HTML WG, so can't reply directly:

Your question:

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.

Note: I'm not asking for general principles or how to apply the above
answer to any other question.  It is quite possible that there might be
some who feel that font should be a conformance error and summary should
be conformant, or vice versa, or that the spec should address one but
not the other.  I'm simply asking about the color attribute on the font
element at this time.

-----

You're asking for simple assertions where none exist.

How deprecation and obsolete elements are handled today:

FONT was deprecated in HTML 4, which means that it could be made 
obsolete in HTML5. Because FONT was deprecated, if you used FONT with 
HTML 4.01 strict, you would get validation errors. You could use it with 
HTML 4.01 transitional. If FONT is made obsolete in the next version of 
HTML, HTML 5, then the policy is that there's no guarantee that the item 
will be supported by user agents. That it would be invalid to use the 
element with the newer version of HTML is a given.

If we consider that a "downplayed error" is the HTML WG's redefinition 
of deprecation,  and "conformance error" seems to be a redefinition of, 
and expansion of, obsolete, then  the use of FONT is , minimally, a 
"downplayed error" because FONT was deprecated in HTML 4. It could also 
be a "conformance error", if the working group moves to obsolete the item.

However, the behavior demanded of "conformance" is different than the 
behavior that had been demanded with validation. Previous specifications 
have stated that deprecated elements must be supported by user agents, 
though the use of the item can generate a validation error. If the 
element is made obsolete in a future generation of the specification, 
it's use is invalid, and people are warned that it may no longer be 
supported by user agents. However, no demands on how user agents handle 
the obsolete item are made. The W3C basically warns folks that there is 
no guarantee of support for obsolete elements.

With the new June 3rd addition to the HTML 5 specification that demands 
active non-support for elements/attributes not specifically mentioned in 
the spec, user agents are now told that they must not support 
non-existent (never existed, or previously existed but now obsolete)  
elements and attributes. According to the HTML 5 spec, FONT could then 
be non-conformant, which means, if I read the HTML 5 spec correctly, 
user agents _must not_ support the element.

However, this does not align with past practices associated with the 
HTML specifications. From the HTML 4.01 specification:

"This specification does not define how conforming user agents handle 
general error conditions, including how user agents behave when they 
encounter elements, attributes, attribute values, or entities not 
specified in this document. "

That has been replaced with, as you pointed out:

"Note: There is no implied relationship between document conformance
requirements and implementation conformance requirements. User agents
are not free to handle non-conformant documents as they please; the
processing model described in this specification applies to
implementations regardless of the conformity of the input documents."

And

"Authoring tools and markup generators must generate conforming
   documents. Conformance criteria that apply to authors also apply to
   authoring tools, where appropriate."

Frankly, I find this unacceptable.

How to fit all of this into your options list: both option 1 and 2 are 
valid choices, as FONT can continue as a deprecated element (or 
"downplayed error" if we must), or it can be made obsolete in this 
iteration of HTML. However, I choose option 4, as it is the only way to 
ensure a smooth transitioning of behavior between HTML specifications.

Shelley

Received on Tuesday, 9 June 2009 13:05:00 UTC