W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: <keygen> element (was RE: Implementor feedback on new elements in HTML5)

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 01 Sep 2009 16:27:16 -0700
Cc: Adrian Bateman <adrianba@microsoft.com>, HTMLWG WG <public-html@w3.org>
Message-id: <D37DDB78-9D82-4457-B5C2-5F3FBD933BE8@apple.com>
To: Jonas Sicking <jonas@sicking.cc>

On Sep 1, 2009, at 3:34 PM, Jonas Sicking wrote:

> I can fully understand microsoft being unwilling to implement this. I
> think the reason it's in the spec isn't really because anyone likes
> it, but rather because it's a feature a new webbrowser would need to
> implement in order to be "compatible with the web".
> However, I wonder if implementing <keygen> would actually help a
> newcomer. The problem is that I think this is one area where pages do
> so much browser detection that it's unlikely that any newcomer will
> work out of the box.

I think it would help. A number (though probably not all) of the pages  
that use <keygen> use it as the last resort, or allow manual override  
of some sort (for example, the VeriSign page I linked does no browser  
detection at all, it just asks the user to pick what browser they are  

> One thing we could do is to add a note that this feature is known to
> be bad and is intended to be deprecated as soon as alternative
> proposals arise. That would give any UA a pretty good story for not
> implementing the feature for now.
> Hopefully this won't be a problem for microsoft either way. Before
> <keygen> is becomes the last holdout for HTML5 compliance in a
> microsoft product I hope that there are alternative proposals that can
> replace <keygen>, allowing us to deprecate it. (Not because the former
> is far away, but because I hope the latter happens soon).

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.

Received on Tuesday, 1 September 2009 23:27:58 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:56 UTC