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

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  
using.)

>
> 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.

Regards,
Maciej

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