Adding undefined attributes to html elements

I do this:

[code]<textarea id="story" name="story" cols="50" rows="10" maxlength="5000"></textarea>[/code]

and in my js form validation:

[code]if (story.value.length > story.maxlength) {[/code]
[code]alert("Please limit the story length to " + story.maxlength + " characters. Sorry.");[/code]

It seems logical to me. For one thing, maxlength should be an attribute of textarea, and I don't know why browsers don't choose to honor it anyway. So using it adds forward compatibility. But more than that, it seems like the html is the place where I should be defining attributes of elements, even if those attributes are only meaningful in my own scripts. If I end up with multiple textareas in a form, this approach will lead to the cleanest code.

But...I still feel odd about it. It confuses my text editor, and it's potentially misleading to a human. You see the html tag and assume either that the attribute works on its own, or that I've messed up.

dhromed

Only a subset of all possible attributes of any HTML element end up as object properties in an element object in Javascript's DOM. It's pretty arbitrary, and essentially a holdover from earlier days.

All element objects in a DOM implementation, however, possess the method getAttribute("attrname"), which will reliably return what you're after.

I also see you're relying on elements with IDs automatically being converted to variables in javascript. Only IE does that, and it's pretty stupid behaviour. So I advise you use document.getElementById("story"). But maybe you're elaready doing this, as you've posted only a short snippet. :)

PJH

Another thing to be wary of, is that this is a client side hint - you will still need to enforce any limits on the server-side code.

blakeyrat

I honestly don't understand the problem here.

dhromed, PJH: I know these things (and yes, I'm using document.getElementById("story") in that code; if there were more than one, I'd loop through all textarea children of the form). Except are you saying that document.getElementById("story").maxlength might not work in all browsers? That, I didn't realize.

The main point was to ask if anyone had a readability objection to my adding an undefined or unsupported attribute to an element, to be referenced in javascript. It seems expedient but questionable. These two things:

[code]<textarea maxlength="50">[/code]

[code]<input type="text" maxlength="50"/>[/code]

look like they should behave the same way, but they don't.

PJH

@HonoreDB said:

The main point was to ask if anyone had a readability objection to my adding an undefined or unsupported attribute to an element, to be referenced in javascript. It seems expedient but questionable.

Both HTML and JS have the ability to insert comments. Do so. This should address the main concern in your first post.

blakeyrat

@HonoreDB said:

The main point was to ask if anyone had a readability objection to my adding an undefined or unsupported attribute to an element, to be referenced in javascript.

That's what attributes are for.

@HonoreDB said:

These two things:

<font face="Lucida Console" size="2"><textarea maxlength="50"></font>
<font face="Lucida Console" size="2"><input type="text" maxlength="50"></font>
look like they should behave the same way, but they don't.

Well, that point I agree with. Even more important, why the hell does the TEXTAREA (and SELECT for that matter) tag even exist, when every other variation of INPUT is specified by the type attribute?

I mean, does it make sense to have:
<INPUT type="text">
<INPUT type="password">
<INPUT type="radio">
<TEXTAREA>

So you're pointing out a minor WTF which piggy-backs on a huge WTF.

But that's what you get when the file format was congealed instead of designed.

blakeyrat

@HonoreDB said:

Except are you saying that document.getElementById("story").maxlength might not work in all browsers? That, I didn't realize.

I don't believe there's anything in DOM saying that will (or even should) work, so correct code would use getAttribute().

Determining whether it does actually work in any given browser I leave as an exercise for the reader. (But I'm virtually certain it works in IE.)

@HonoreDB said:

For one thing, maxlength should be an attribute of textarea

What's that supposed to mean? Either it is, or it isn't. And in this case, it isn't.

@blakeyrat said:

@HonoreDB said:
Except are you saying that document.getElementById("story").maxlength might not work in all browsers? That, I didn't realize.

I don't believe there's anything in DOM saying that will (or even should) work, so correct code would use getAttribute().

Determining whether it does actually work in any given browser I leave as an exercise for the reader. (But I'm virtually certain it works in IE.)

Just checked. Doesn't work in Safari or Firefox. Whoops.

Spectre, I meant "should" in the sense of "it would have been a good idea, and if the specs are ever revised it will be added."

Nandurius

I don't like approach because you're introducing an attribute that's not part of the DTD. This may cause parsing errors that the browser may or may not ignore (depending on the doctype of the document and render engine.)

I prefer writing HTML as XML (XHTML) whenever possible, but I also mainly work with JSF, which supports and enforces this at the framework level.

My solution to this would be to define the maximum length in the javascript glue rather than on the component. Here's some pseudocode of how this might work with jQuery and a length limiting jQuery 'plugin'.

<textarea id="story" />
<script ...>
jQuery("#story").limitLength(5000);
</script>

blakeyrat

@Nandurius said:

I don't like approach because you're introducing an attribute that's not part of the DTD. This may cause parsing errors that the browser may or may not ignore (depending on the doctype of the document and render engine.)

Bouldercrap. Even if the standard was loosely-enough-worded that it made failing on unrecognized attributes even possible in the first place (which I highly doubt), no browser on Earth would do it because it would break thousands or millions of sites.

The DOM contains functions designed solely to create, remove, generally work with tag attributes, whether predefined or not. Now, nobody's going to claim the DOM is good (or even not shit), but that's one thing it definitely gets right.

@Nandurius said:

I prefer writing HTML as XML (XHTML) whenever possible,

Oh, you're one of those people. That explains a lot.

dhromed

@HonoreDB said:

The main point was to ask if anyone had a readability objection to my adding an undefined or unsupported attribute to an element, to be referenced in javascript. It seems expedient but questionable. These two things:

Absolutely no problem at all. I do it all the time. It's very transparent and therefore good practice.

dhromed

@Nandurius said:

I don't like approach because you're introducing an attribute that's not part of the DTD.

I really don't care at all. HTML is the data/structure part and JS is the behaviour part. I keep data out of my JS as much as possible. That said, I did write a prototype javascript validator that allows one to combine some standard HTML with a set of JS hashmaps and the whole deal validates input as specificied in the JS. So exceptions may apply. YMMV. Choose on a practical case-by-case basis rather than standardista dogma.

Also, +1 on using jQuery.

PSWorx

@blakeyrat said:

Bouldercrap. Even if the standard was loosely-enough-worded that it made failing on unrecognized attributes even possible in the first place (which I highly doubt), no browser on Earth would do it because it would break thousands or millions of sites.

I agree with you that this is how it should work. Still, please show me the thousands and millions of sites that are using custrom HTML attributes. From what I've seen, encoding custom stuff in JS is still the most robust and pragmatical approach, even if it's hideously ugly.

Also, I've not researched or tried this in any way, but weren't problems with custom attributes one of the reasons Microformats invented all their creative hoops to store data at the most unlikely places imagineable?

Finally, a more sensible theoretical reason against custom attributes is that the HTML5 guys at some time might decide they needed the attribute for something. Which is why you generally should use the custom data attributes. Though I don't think it matters in this case since the only purpose that could be reasoneably applied to the maxlength attribute of a textarea is probably the max length of a textarea.

blakeyrat

@PSWorx said:

From what I've seen, encoding custom stuff in JS is still the most robust and pragmatical approach, even if it's hideously ugly.

Possibly true-- it really depends. For my purposes, I need to write the custom stuff at run-time, so I'm using JS anyway. I don't develop websites, I develop a product in JS that gets attached to already-existing websites, so I'm kind of weird in that I don't have control over what the web server spits out at all.

@PSWorx said:

Also, I've not researched or tried this in any way, but weren't problems with custom attributes one of the reasons Microformats invented all their creative hoops to store data at the most unlikely places imagineable?

I don't know who/what Microformats is, what they invented, or why. Maybe you could elaborate until this sentence makes sense to somebody who can't read your mind?

@PSWorx said:

Finally, a more sensible theoretical reason against custom attributes is that the HTML5 guys at some time might decide they needed the attribute for something. Which is why you generally should use the custom data attributes.

But custom data attributes is exactly what we're talking about! The only difference is that the HTML5 guys say "preface it with 'data' so we won't stomp over it".

@PSWorx said:

Finally, a more sensible theoretical reason against custom attributes is that the HTML5 guys at some time might decide they needed the attribute for something.

They've already did: [url]http://www.w3.org/TR/html5/the-button-element.html#attr-textarea-maxlength[/url].

PSWorx

@blakeyrat said:

I don't know who/what Microformats is, what they invented, or why. Maybe you could elaborate until this sentence makes sense to somebody who can't read your mind?

You don't have to read my mind, just the media. Basically, they are a "new" (= around since c.a. 2005) "pragmatic" approach to the old "Semantic Web" idea. The basic idea is to get away from the idea of a unified meta-language and instead develop a set of small data formats for specific purposes that can be embedded into HTML. (And with "embedding" they basically mean "~~abuse~~ redefine arbitrary HTML elements as hiding places for machine readeable data"...)

The idea of reviving the semantic web is pretty cool I admit and they seem to be sucessful - but IMO they are just ugly as hell and by design completely non-extensible. If you want to solve the specific problem a microformat is designed for, go ahead, but god have mercy with you if you want to do so arcane and academical things as, say, combine two microformats in the same HTML page or not check the whole spec for reserved css class names(!) that might conflict with your HTML document...

@Spectre said:

They already did... HTML5 suxx0rs, It's too late

That's of course both correct but I don't see why in this case. Them adding maxlength to textarea seems pretty sensible to me. (And, by the way, makes this whole topic obsolete, since HonoreDB didn't even use a custom attribute. In fact, he can now congratulate himself on being spec-compliant before the spec was.)

@PSWorx said:

@Spectre said:
They already did... HTML5 suxx0rs, It's too late
That's of course both correct but I don't see why in this case. Them adding maxlength to textarea seems pretty sensible to me. (And, by the way, makes this whole topic obsolete, since HonoreDB didn't even use a custom attribute. In fact, he can now congratulate himself on being spec-compliant before the spec was.)

Well, the suxx0rs part was sort of a general statement (you know, [url=http://tvtropes.org/pmwiki/pmwiki.php/Main/TheyChangedItNowItSucks]they changed it, now it sucks[/url]).

pjt33

@PSWorx said:

I agree with you that this is how it should work. Still, please show me the thousands and millions of sites that are using custrom HTML attributes.

Any site written in ASP.Net which uses the built-in validators, to start with.