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

On Sun, Jun 14, 2009 at 4:11 PM, Sam Ruby<rubys@intertwingly.net> wrote:
> 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
>
>

Let me run with this one, a sec, because you all come in and tell I'm
full of beans.

>From the current spec draft:

"Some conformance requirements are phrased as requirements on
elements, attributes, methods or objects. Such requirements fall into
two categories: those describing content model restrictions, and those
describing implementation behavior. Those in the former category are
requirements on documents and authoring tools. Those in the second
category are requirements on user agents."

For FONT, there is no author conformance requirements, because it
looks like this element is either missing, or has been pulled. The
user agent requirements are as follows:

"When a font element has a color attribute, its value is expected to
be parsed using the rules for parsing a legacy color value, and if
that does not return an error, the user agent is expected to treat the
attribute as a presentational hint setting the element's 'color'
property to the resulting color.

When a font element has a face attribute, the user agent is expected
to treat the attribute as a presentational hint setting the element's
'font-family' property to the attribute's value.

When a font element has a pointsize attribute, the user agent is
expected to parse that attribute's value using the rules for parsing
non-negative integers, and if this doesn't generate an error, then the
user agent is expected to use the parsed value as a point length for a
presentational hint for the 'font-size' property on the element.

When a font element has a size attribute, the user agent is expected
to use the following steps to treat the attribute as a presentational
hint setting the element's 'font-size' property:..."

And so on.

If author conformance requirements are dropped, then one could use
FONT, and the onus then is on browsers to fulfill the requirements on
the browser, since there are specific actions the browser must take
for FONT to work. But there would no "non-conforming" stigma, or
conformance test for me using FONT.

The same could be said for Canvas, SVG, and MathML, because these
require certain actions on the part of the user agents. Of course,
these are specifically mentioned in the HTML5 spec, but since author
conformance is not an issue, we could fall back on other tests, such
as current SVG checkers or whatever to check the content. We wouldn't
necessarily have to stuff all this into the HTML5 spec.

However, something like microformats and RDFa don't have user agent
requirements. Not as currently used, and supported. But one could use
both without running into a non-conformance violation. One can use
RDFa regardless, if one is using the XML serialization of HTML5. The
only thing that would matter from an HTML5 point of view is that the
markup used is well formed according to the HTML5 spec.

Then we have to explore outside of the browser box. One does not live
by IE, Firefox, Opera, Safari/Webkit, Chrome, et al, alone. There will
be conflicting requirements for accessibility attributes between
HTML4.01 and HTML5, as things now stand. What was used with HTML4
could still be used with HTML5, and the browsers don't care, because
they would still parse the attributes, make sure the syntax is well
formed, etc. The user agents that would care are a different audience.

I'm wondering if we couldn't have an Accessibility Best Practices
document in addition to a HTML5 "well formed" best practices, and
those user agents specifically interested in accessibility would
follow, and conform to, the accessibility best practices, in addition
to requirements on all uer agents given in the HTML5 spec.

With this approach, the organizations actually tasked with ensuring
that accessibility needs are met would be the ones defining the
conformance criteria -- not people who work for browser companies, and
don't necessarily have a finger in this pie.

Come to that, we could have a Semantic Best Practices that provides
conformance criteria for using microformats and RDFa in a document,
and web pages could conform to it, and the accessibility best
practices, both. As long as there is no conflicting requirements, the
best practices could overlap.

Somewhat related (in concept) example:

Right now my web pages are served up as XHTML, which requires well
formed XML. They're not valid, though, because I'm using SVG and RDFa
together. However, the SVG usage is valid (conforms), as does the RDFa
I use. I test these out individually, to ensure they'll be processed
correctly by interested user agents. I don't have to test the XHTML
directly, because my page would bust if the XHTML is not well formed.
I don't care about any overall "validity", because it brings me
nothing. Not enough to give up my RDFa and SVG.

With this approach, we could also remove the microdata section, and
either have the elements and attributes in a separate best practice
document -- or somehow merge the concepts into one, under the auspices
of the W3C Semantics group. Again, the group given responsibility for
this subject matter area would get authority over the best practices.
Of course, others could come up with competing best practices
documents, but technically, none of this should impact on the HTML5
specification, and the concept of well formed HTML. Frankly, this
isn't unlike what we've had with HTML 4.01 in the past.

All of this would help eliminate a lot of the gatekeeping bottlenecks
we're now hitting, and would help to greatly simplify and tighten up
the HTML5 document. It could also help provide a nice clean separation
between implementation, and subject matter models--complementary to
the CSS specification, and a separation of presentation and document
structure.

Even conformance checkers for the different best practices documents
(models) could be based on overall HTML5 well formed checkers, adding
in the additional functionality to check for specific instances of
elements and attributes. Not unlike what happens with my use of SVG in
XHTML, as compared to my use of RDFa in XHTML.

Most authoring tools support some form of module or plug-in that could
add in the enhanced functionality for RDFa, accessibility, and so on.
They do this now, but with "XHTML 1.1", served up as text/html. And
generally, it works. Well, not SVG, but that's an issue above and
behond web page markup.

OK, tell me I'm full of beans. Because frankly, I don't see anyway
else out of the impasses we keep hitting. Or to avoid the formal
objections that will be filed if we continue the way we're going.

Shelley

Received on Sunday, 14 June 2009 22:27:05 UTC