Re: <keygen> element

Anne van Kesteren wrote:
> On Sat, 05 Sep 2009 11:51:10 +0200, Lachlan Hunt 
> <lachlan.hunt@lachy.id.au> wrote:
>> What is the justification for making the element conforming to use?
> 
> There is no alternative.

IE seems to have found one.  But perhaps you will simply state "That's 
not what I meant with alternative.", as you did on bug 7480.

Here's the facts as I see them.

HTML4 has no standard way to generate keys.  I could just as easily ask 
"what alternative is there to bb or datagrid?".  All three features have 
advocates.  All three have issues.  None belong in HTML5 at the current 
time.

The current HTML5 draft contains the following:

     Vendor-specific proprietary extensions to this specification are
     strongly discouraged. Documents must not use such extensions, as
     doing so reduces interoperability and fragments the user base,
     allowing only users of specific user agents to access the content
     in question.

     If markup extensions are needed, they should be done using XML,
     with elements or attributes from custom namespaces. If DOM
     extensions are needed, the members should be prefixed by
     vendor-specific strings to prevent clashes with future versions
     of this specification. Extensions must be defined so that the use
     of extensions neither contradicts nor causes the non-conformance
     of functionality defined in the specification.

To me, that appears to be the crucial difference between keygen and 
datagrid.  Based on my discussions, what I gather is that we have what 
originally was a vendor-specific proprietary extension (note: I disagree 
with the perjorative connotations of those words, but lets go with Ian's 
terminology the moment) that some but not all browser vendors have 
reluctantly adopted because it serves a real need.

I believe that HTML5 recommends a course of action for evolving the 
language that we, ourselves, are not willing to follow.  You may see 
this as a game[1], but I see this as fundamental.  Arguing based on 
first principles hasn't caused the spec to change, so lets talk about 
specifics issues, like keygen.

Renaming the element to follow HTML5's advice would address this issue. 
  Marking it as proprietary or obsolete (bug 7480) would address this 
issue.  Defining it in a separate document (bug 7499) would address this 
issue.  Coming up with something better that everyone would be willing 
to adopt (any ideas?) would address this issue.

I don't believe that we will find consensus on retaining keygen as 
currently specified in the HTML5 draft.  What issue do you, Anne, have 
with putting this element in a separate document and clearly indicating 
that it is an optional feature that a number of browser vendors have 
implemented, and new user agents should consider should they happen to 
have similar requirements?

- Sam Ruby

[1] http://krijnhoetmer.nl/irc-logs/whatwg/20090902#l-937

Received on Saturday, 5 September 2009 12:23:27 UTC