Re: <keygen> element

Julian Reschke wrote:
> 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.

I'd change the last part of the sentence to "those that implement the 
element implement it 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.

The key point isn't "somewhere else" but optional.  If <keygen> were 
defined separately but normatively referenced in a way that was still 
mandatory, the document would still not reflect reality.

Nobody is suggesting that keygen should not be documented at all.

The current draft indicates that keygen support is required.  That is 
the part that is controversial.

By Last Call, we need to have consensus on this issue.

> BR, Julian

- Sam Ruby

Received on Saturday, 5 September 2009 15:20:07 UTC