- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 04 Sep 2009 19:29:23 -0400
- To: Adrian Bateman <adrianba@microsoft.com>
- Cc: Sam Ruby <rubys@intertwingly.net>, Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>, HTML WG <public-html@w3.org>
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. Regards, Maciej
Received on Friday, 4 September 2009 23:30:12 UTC