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

Re: <keygen> element

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 04 Sep 2009 19:29:23 -0400
Cc: Sam Ruby <rubys@intertwingly.net>, Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>, HTML WG <public-html@w3.org>
Message-id: <266DE44D-7AE3-4400-9591-FE9A58B45CE7@apple.com>
To: Adrian Bateman <adrianba@microsoft.com>

On Sep 2, 2009, at 4:16 PM, Adrian Bateman wrote:

> On Wednesday, September 02, 2009 12:12 PM, Maciej Stachowiak wrote:
>> (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.)
> In particular, this is my request. It should be documented but not  
> in HTML5 itself - the HTML5 spec supports loading unknown elements  
> that are defined elsewhere [1]. Since it wasn't included in previous  
> versions of HTML and the desire is not to include it in future  
> versions, not adding it at this stage seems preferable.
> [1] http://dev.w3.org/html5/spec/Overview.html#htmlunknownelement

For what it's worth, I think putting <keygen> in a separate standalone  
spec is a reasonable approach. It is something that all non-IE  
browsers need to have documented. But I think the benefit to content  
authors of IE implementing it would be fairly small. The sites relying  
on this already have dual code paths, and there doesn't seem to be a  
lot of new deployment. That being said, I'm personally ok with it  
being in the main spec.

The other special situation with this element is the fact that it  
seems plausible it could go away entirely in the future, if we  
actually define a better approach for these kinds of things. That's  
because sites using this element in my experience seem pretty flexible  
and willing to change to something better. They also tend to be  
actively maintained by their responsible organizations, since they  
tend to be security-sensitive infrastructure.

Received on Friday, 4 September 2009 23:30:12 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:51 UTC