Mandating Standards (was RE: tooltip onfocus)

"Values of the title attribute may be rendered by user agents in a variety
of ways. For instance...  ...agents may speak..."

**MAY**, as in, these are suggestions (perhaps even "recommended best
practices"), but NOT mandated requirements.

I like to use cars as analogies all the time.  In North America it is
recommended that all vehicles have the steering wheel on the left hand side
of the car.  This is a best practice and fits well with the extensive road
system in North America, where cars drive on the right hand side of the
road.  However, in Great Britain (for example) the road system is set so
that cars drive on the left hand side of the road, thus the best place is to
locate the steering wheel on the right hand side of the car, in direct
contravention of the "North American Standard".  Who's right?   More
importantly however is that despite the differences of cars, and even the
awkwardness of using a car intended for one market in the other, you can
still drive a North American Ford Mustang in Great Britain and get from "A"
to "B"... the steering wheel is just on the wrong side.

And so it is with browsers.  The theory is that you can drive any browser
you wish, and, with properly rendered HTML content (akin to properly
rendered gasoline/petrol) the thing works.  Maybe not the way the developer
had envisioned, but it gets you to where you need to go.  They all follow
basic principles, but leave the nitty gritty to the individual
manufacturers.  8 cylinder, 6, 4; front wheel drive, rear wheel drive; four
tires, three tires; air conditioning, convertible, etc.

The user buys the car, WE supply the fuel (HTML or "W3C approved language"
content).

And so, as fuel suppliers, we must be careful that we do not start placing
expectations on the vehicles that are too restrictive, or vice versa, the
manufacturers cannot place too many requirements on the fuel required for
the car to drive; in either instance if we set the requirements too high,
the lack of availability defeats the usefulness.  So too with browsers.  In
a free market society (and I won't get into *that* debate), the user chooses
which browser he/she will use (and I will avoid *that* debate too
thank-you), just as you choose to drive the car currently sitting in front
of your house (assuming that you have a car at all, some people don't, and
rely on other modes of transportation, (other browser agents, such as cell
phones and pdas?)).  And so, these user agents cater to the mainstream
requirements of the population, but leave open the ability to customize (via
plug-ins, Active-X, etc.) to an individual's specific requirements (just as
I can add a towing package to my car if I wish to tow a trailer...).

So, let's look at "sound-on-event".  Providing a method to extend this
functionality to certain user configurations is a useful (and even
beneficial) idea, especially in the context of extending accessibility.
However, insisting that all browsers support a standardized method of
supporting this function is unrealistic... not all user configurations
support (or require) sound.  And so the spec says that *if* you choose (as a
browser manufacturer) to include this functionality, do so this way.
Providing air-conditioning to cars is a useful (and even beneficial)
function, especially in climates that reach high temperatures.  Insisting
that all cars have air-conditioning is simply unrealistic;  setting
standards which state that _should you_ include air-conditioning in your car
it must follow this set of standards is not (i.e.: no CFC's, annual
inspection requirements, etc.).  In both instances however, the manufacturer
must decide if there is a great enough demand, and if they can deliver the
function within the framework of their product.

So too then with W3C standards; the recommendations are there for developers
of both browsers (cars) and content (gasoline/petrol), with few demands but
plenty of (regulated?) options.  Insisting on anything else is unrealistic
IMHO.

(As he steps down of his soapbox...) Just my $0.02

JF


> > It is in a W3C Recommendation (i.e. it's a W3C standard) that if they
> > have a tooltip on mouseover they need to have a tooltip when you key
> > there.
> >
> > Sound on event, in contrast, cannot be done with a W3C standard in HTML
> > (but can in SMIL - HTML is a simple language for documents, and isn't
> > expected to cover everything. The point of developing XML languages
> > like SMIL, SVG, XHTML+SVG+MathML, etc, is to allow more powerful
> > functionality like this...)
>
> <blockquote
> cite="http://www.w3.org/TR/html401/struct/global.html#adef-title">
> <p>
> Values of the title attribute may be rendered by user agents in a
> variety of
> ways. For instance, visual browsers frequently display the title
> as a "tool
> tip" (a short message that appears when the pointing device pauses over an
> object). Audio user agents may speak the title information in a similar
> context. For example, setting the attribute on a link allows user agents
> (visual and non-visual) to tell users about the nature of the linked
> resource:
> </p>
> </blockquote>
>
> tooltip on key is certain contained within "Values of the title attribute
> may be rendered by user agents in a variety of ways." and sound
> on event is
> explicitly given as an example.

Received on Friday, 24 January 2003 09:43:03 UTC