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

Shelley Powers wrote:
> On Sun, Jun 14, 2009 at 6:31 AM, Sam Ruby<rubys@intertwingly.net> wrote:
>> Jonas Sicking wrote:
>>> On Fri, Jun 12, 2009 at 6:07 PM, Rob Sayre<rsayre@mozilla.com> wrote:
>>>>>> 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.
>>>> This entire debate concerns whether "validity" is an important concept.
>>>> In
>>>> the context of exhaustive UA requirements, it certainly isn't. Not that
>>>> it
>>>> ever has been.
>>> Removing the concept of "validity" is certainly an interesting
>>> approach. Though one that I doubt you'd ever get through W3C. I
>>> certainly agree it would remove a lot of rat-hole discussions.
>> If there is consensus, I don't see why it wouldn't fly.
>>
>> Also: it doesn't completely need to go away.  The current document says MUST
>> in places where at best it means SHOULD (at least in the RFC 2119 sense of
>> the word "there may exist valid reasons in particular circumstances to
>> ignore a particular item, but the full implications must be understood and
>> carefully weighed before choosing a different course.")
>>
>> Alternately, the current document contains text that may ultimately be split
>> out.  If the authoring conformance requirements were split out into what the
>> IETF calls a "Best Current Practices" document, those interested in those
>> discussions could proceed separately.
> 
> Just to clarify my own understanding of what you're saying here,
> you're talking about removing most, if not all, of the conformance
> requirements in the HTML5 specification, either completely, or to a
> separate Best Practices guide. Or at least, conformance requirements
> as they may pertain to the use of obsolete, deprecated, or new
> elements and attributes?
> 
> Am I reading your comment correctly, Sam?

While I may not have been explicit as I should have been, the 
alternative you are asking about was meant only to refer to *author* 
conformance requirements.  User agents (in particular browsers) would be 
expected to process <font color="blue"> as specified by the spec. 
Consistently.  And interoperably.  To the point that authors can depend 
on it, whether or not is is considered fashionable this week.

I know for a fact that there are feed readers that strip out style 
attributes because allowing this information through unfiltered was 
proven unsafe by Mark Pilgrim many years ago.  Allowing in a safe subset 
of style attributes is something many of the better feed readers do 
(including Venus).  But the fact remains that <font> reaches more 
readers than @style does.

I also feel that I would be remiss if I did not point out that there are 
other alternatives, which I enumerated in my original email.  I also 
still haven't heard definitively that the text that exists in the 
current draft (in particular, in the section on "Authoring tools and 
markup generators") breaks Mozilla.

> Shelley

- Sam Ruby

Received on Sunday, 14 June 2009 21:12:04 UTC