RE: ISSUE-107 Change Proposal: Replace <object> fallback example

Sorry, Ian - but <object> is _NOT_ restricted to plugins, which is one of the reasons behind this change proposal.

As discussed in a previous thread, a given UA may have native support for a given format/media-type that is specified via an <object> and so no plugin is involved.  Consider Safari on Mac's native support for PDF...

And while on the subject of PDF - it is NOT a proprietary technology - it is an ISO standard (ISO 32000).  However, for many users their access to them (on the web) is via a plugin.  

Bottom line, plugins != proprietary and <object> != plugin.

While you may maintain your own personal opinions concerning plugins, those opinions do NOT belong in a standards document.  If you like them that much - keep them in your WHATWG version...

Leonard

-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Ian Hickson
Sent: Thursday, April 22, 2010 8:45 PM
To: Maciej Stachowiak
Cc: julian.reschke@gmx.de; Lachlan Hunt; public-html
Subject: Re: ISSUE-107 Change Proposal: Replace <object> fallback example

On Thu, 22 Apr 2010, Maciej Stachowiak wrote:
> 
> It seems like some of these examples are not approaches that we should 
> be recommending to authors. In particular:
> 
> > * showing not offering fallback at all
> > 
> > * showing a useless comment typical on the Web, saying that the plugin is
> >  not installed or is disabled, with no proposed alternative
> > 
> > * showing an honest message equivalent to the useless comment mentioned
> >  above (this is the one being objected to)
> 
> What is the purpose of the above three examples? It seems like they 
> would only be helpful as examples of what *not* to do.
> 
> Are there other examples in the spec that illustrate a poor authoring 
> practice?

We're talking about plugins here. There are no good authoring practices, 
only bad ones and worse ones.

Regarding the three bullets above: For the first one, there are times 
where offering no fallback is fine; for example when to reach the page you 
have to have gone through a mechanism that verifies that you have the 
plugin in the first place, or where the plugin is doing nothing but adding 
something decorative. For the second and third, both are bad, and more or 
less equivalent from the user's perspective; however, they are an 
inevitable result of writing content using a proprietary technology. In 
the case of the second bullet point, the example is specifically of an 
author showing off his Java programming skills, so it makes no sense to 
have any other fallback. The introductory text for the example discusses 
the implications of doing this. For the third bullet point, the text is 
self-explanatory regarding the danger of relying on a plugin -- it is in 
fact that explanation that people are objecting to here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 23 April 2010 11:42:42 UTC