http://www.w3.org/TR/html401/interact/forms.html#adef-name-FORM
This is still in use because it's the easiest/fastest way of getting
an array with the selected options server-side. There is no simpler
alternative.
- ricardo
On Mar 3, 12:53 am, mkmanning <michaell...@gmail.com> wrote:
> That argument's been raging for a while :)
>
> There appear to be two halves, those that say 'CDATA', so any text is
> OK, and those that read the next part of the spec "For some HTML 4
> attributes with CDATA attribute values, the specification imposes
> further constraints on the set of legal values for the attribute that
> may not be expressed by the DTD" which is followed by id/name token
> restrictions, which I'll grant is poorly structured and open to
> debate.
>
> And then there's the third half that just says 'browsers allow it so
> who cares' :P
>
> <rant>
> CDATA means characters from the document character set, which includes
> tabs, spaces, character entities like copyright, ampersand, etc.; I
> suspect most people would probably be uncomfortable including them in
> an input's name attribute though.
>
> My main gripe with this still stands, and I'll try to articulate it
> better:
>
> I work primarily clientside, mostly writing JavaScript; I started as a
> designer, then went on to HTML and CSS, then to working on the server-
> side. I've written server-side code in Perl, Java, C# and Python, I
> work with different frameworks as a freelancer, very often RoR.
> (Fulltime I'm currently writing js in a .NET shop, although I have a
> niche position of building specialty apps in Python on appengine along
> with UI work).
>
> When I write a standards compliant, semantic XHTML page, I can drop it
> into a webapp in Python, post a form to the server and process the
> results, with no problems at all. I can take that exact same XHTML
> file and drop it in a webapp in a Java Servlet container and have it
> behave exactly the same, posting and processing on the server, with NO
> CHANGES to the markup.
>
> My contention is that (most) people aren't using attribute names on
> their inputs like name="foo[]" because they like to; it is being
> imposed on them by the server-side framework they've chosen. Thus I
> stand by my original statement that ANY server side framework (and
> that includes frameworks developed for the languages I mentioned
> above), is deficient if it 'requires' the markup be structured a
> specific way.
>
> I've personally experienced developers using [] in a name, and then
> trying to access it with JavaScript, only to get tripped up by the
> fact that [] has a direct meaning in JavaScript; why make life harder
> if you don't have to?
>
> </rant>
>
> I don't think this debate is going to end unless some new information
> comes to light, but in deference to keeping the topic of these posts
> to jQuery, I will promise to not bring this up again (nobody's giving
> me any nickels anyway).
>
> On Mar 2, 7:03 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>
> > On Mar 2, 6:51 pm, mkmanning <michaell...@gmail.com> wrote:
>
> > > HTML 4 spec section 6.2 says, "ID and NAME tokens must begin with a
> > > letter ([A-Za-z]) and may be followed by any number of letters,
> > > digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and
> > > periods (".")."
>
> > The NAME attribute is CDATA, not ID or NAME.
>
> >http://lmgtfy.com/?q=name+attribute+cdata+id+token
> > ;)
>
> > Matt Kruse
