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
