Re: Issue 30 (Was: RE: Getting HTML5 to Recommendation in 2014)

Hi Adrian,

Why don't we set aside the abstract process questions for a second and focus on how the plan could apply here:

On Sep 20, 2012, at 1:55 PM, Adrian Roselli <Roselli@algonquinstudios.com> wrote:

> 
>> That is why we are floating the compromise solution of extension spec as the
>> path forward. I would appreciate your input on the merits of that
>> compromise (is it sensible? can you live with it?) rather than just debating
>> whether we should press forward instead.
> 
> I'm trying to understand the process, but couched in that is the idea that I do not like an extension spec to address issues like this.
> 
> Adding a brand new element or attribute, sure. Probably a good fit for <picture>, for example.
> 
> Re-instating an element or attribute that existed in a prior release? No, I think that gap leads to confusion and more of an excuse for both developers and browser makers to fail to support it in any way. If it's on the ropes now, it's doomed to failure if it comes out as an extension.
> 
> Bear in mind -- my understanding of extension spec is just what I have gleaned by reading other posts on the list since this new approach was proposed...barely 24 hours ago.


Let's imagine these were the available options:

1) longdesc is added back to the main HTML5 spec.
2) longdesc is defined by and published as a separate extension specification.
3) longdesc is not added back to anything.

What is your preference order among these options (no need to justify, for the moment)? 

You indicate that #2 is not your top preference, but can you live with it? Particularly if key accessibility experts support this approach

Let's say you had a 50/50 chance of getting #1 or #3. Would you then consider #2 a livable alternative?

Regards,
Maciej

Received on Thursday, 20 September 2012 23:30:51 UTC