Re: <keygen> element

Sam Ruby wrote:
> Anne van Kesteren wrote:
>> I'm assuming by "issue" you mean the objection raised to <keygen> by 
>> Microsoft.
>>
>> On Sat, 05 Sep 2009 14:22:25 +0200, Sam Ruby <rubys@intertwingly.net> 
>> wrote:
>>> Renaming the element to follow HTML5's advice would address this issue.
>>
>> This would not address the issue unless you mean to also remove the 
>> element from HTML5. However it is pretty clear that browsers cannot 
>> rename the element so I'm not sure why this is being suggested.
>>
>>> Marking it as proprietary or obsolete (bug 7480) would address this 
>>> issue.
>>
>> Even obsolete elements still need to be supported by browsers so this 
>> is not a solution to the issue for Microsoft.
> 
> OK, but proprietary would.  And coming up with a better term than 
> proprietary would be even better.
> ...

(replying to a somewhat random mail in this thread...)

I think it's very good thing to document <keygen>; this helps people who 
need it (*), and implementors.

(*) And yes, people *do* need it. Last year my colleagues needed in a 
project where IE and Firefox compatibility was required; <keygen> solved 
the problem for Firefox; and for IE we used the ActiveX approach. As far 
as I recall back then we had to special case Win XP vs Vista; dunno 
whether it was an incompatible change or a useful new feature.

Whether it's optional or required, and whether it's in HTML5 or in a 
stand-alone spec doesn't make a bug difference to me; what's essential 
is that the information is there, and the element is implemented 
consistently.

And yes, working out a better approach that would work interoperably in 
future browsers would be a good thing as well; but it's something we 
won't get done this year (I assume).

Of course if we come the conclusion that <keygen> can be defined 
somewhere else, we should also look at other candidates, be it 
microdata, @ping, whatever.

BR, Julian

Received on Saturday, 5 September 2009 14:37:29 UTC