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

> We're talking about plugins here.

Right, a point of open extensibility for html5.
The examples should just highlight actual operational considerations 
for the element.
The idea is to present info that helps explain how the behavior is to 
be implemented by UAs and applied by an author. All the other various 
use cases that don't explain how the fallback procsss works are 
distracting.
About the present replcement example being considered, I dont see the 
connection with the <script> following the <object>. Sur eht thing may 
be scriptable, but what has that to do with showing the fallback 
process?
Best Regards,
Joe

----- Original Message ----- 
From: "Ian Hickson" <ian@hixie.ch>
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: "Julian Reschke" <julian.reschke@gmx.de>; "Lachlan Hunt" 
<lachlan.hunt@lachy.id.au>; "public-html" <public-html@w3.org>
Sent: Thursday, April 22, 2010 5:44 PM
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 03:25:16 UTC