Re: <keygen> element

On Sep 2, 2009, at 4:41 AM, Sam Ruby wrote:

> Maciej Stachowiak wrote:
>> On Sep 2, 2009, at 1:39 AM, Anne van Kesteren wrote:
>>> On Wed, 02 Sep 2009 01:27:16 +0200, Maciej Stachowiak  
>>> <mjs@apple.com <mailto:mjs@apple.com>> wrote:
>>>> I agree with the last two paragraphs. I think the main thing is  
>>>> to provide a good crypto API so we can relegate <keygen> and  
>>>> browser-specific solutions to the dustbin of history.
>>>
>>> If dustbin of history means everyone removes their implementation  
>>> we could remove the documentation as well I suppose. However, if  
>>> Gecko and WebKit keep it I'm sure sites will continue to use it  
>>> for one reason or another and we need to have it documented.
>>>
>>> Another reason to have it in the specification is that the  
>>> implementation details of the element in Presto/Gecko/WebKit are  
>>> quite different.
>> I don't think <keygen> should be removed from anything for now;  
>> that was more of a rhetorical flourish than a specific technical  
>> recommendation. But it probably wouldn't be hard to convince sites  
>> to migrate to a better API if we make one. Someday it may be  
>> possible to completely obsolete it.
>
> Per previous discussion[1], I believe that it is the policy of the  
> editor to remove features that any browser that has notable market  
> share do not intend to support, and then work to come up with  
> solutions that everybody would agree to.
>
> table@summary does something in JAWS and some other UAs, but has  
> issues, the PF Working Group hopes to someday completely obsolete  
> it, isn't described in the spec, and any uses produces a warning.
>
> keygen does something in Gecko and some other UAs, has issues,  
> likely will never be implemented in IE, the HTML WG hopes to someday  
> completely obsolete it, is described in the spec, and uses currently  
> produce no warning.
>
> Per the discussion on issue 53, I believe that table@summary should  
> be described even if is recommended against, but at the very least  
> it seems to me that keygen should get no more favorable treatment  
> than table@summary.  Therefore, if table@summary remains as it is,  
> the description for keygen should be removed, and uses of keygen  
> should produce a warning.

I don't have a comment at this time on whether <keygen> should be  
removed, but this comparison does not seem relevant. They <keygen>  
element is defined here:
http://www.whatwg.org/specs/web-apps/current-work/#the-keygen-element

The summary attribute on table is defined here (next to other  
attributes of the table element):
http://www.whatwg.org/specs/web-apps/current-work/#attr-table-summary

Both definitions include a description of the purpose and a  
description of expected UA behavior. I don't see how you can  
characterize either as "not described". Maybe you could explain what  
part of the <keygen> element definition would have to be removed to  
place it on an equal footing with table@summary.

Furthermore, the reason table@summary produces a warning is not due to  
lack of implementations or implementor refusal, but simply because  
studies seemed to indicate that it leads to poor accessibility  
outcomes. Indeed, there are elements with universal implementation  
support which are rendered completely nonconforming by the spec, such  
as <xmp>.

It seems to me that the inclusion of <keygen> should be decided on its  
own merits, as should any changes to the summary attribute. The  
comparison between the two is not particularly enlightening.

(Note: if <keygen> is removed from HTML5 itself, it should probably go  
in a separate spec, since non-IE browsers do have to implement it and  
interoperability needs to be improved.)

Regards,
Maciej

Received on Wednesday, 2 September 2009 19:12:51 UTC