[whatwg] Thoughts on HTML 5

[Tab Atkins Jr.]

On Mon, Dec 15, 2008 at 8:36 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> On Mon, Dec 15, 2008 at 8:02 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>>> You're not Nicholas. We don't know if that is what Nicholas expects
>>> his HTML to do or if he is expecting something else. In absence of an
>>> example, I can't do much more than guess. I cannot expect your
>>> assumptions to be correct.
>>
>> Well, of course, but you sent the message to the entire group, so you
>> should be ready for answers from the whole group.  ^_^
>>
>>> You've not stated how creating invalid HTML can "control scripts".
>>> Having an interest in scripting, I would like to know how this works.
>>
>> Dude, come on.  You're trying to poison the dialogue here.  The point
>
> Instead of a complaining about my intentions, why don't you post an
> example that shows the problem (demonstrate need), how the problem is
> overcome (the invalid HTML solution), and what browsers actually do?

Sorry, I thought I was demonstrating it, but I guess I was being too
general.  An example I know of off the top of my head is the jQuery
Validation plugin[1].  If you can uniquely identify the elements in
your form (either through #id or other structural means) and can place
scripts (not always possible for end-users of a CMS application or
something), you can tell the plugin exactly how to validate each form
element when you first invoke it, through the script.

If either of these are false, though, you can instead place the
attributes on the element itself, and the script will read them off
while it's executing.  Many of the common ones can be easily and
usefully embedded in @class (giving an element a class of required,
frex, can also help with styling), but using the more complex
validation routines in @class requires you to embed JSON, which is a
horrible hack (as the parser doesn't recognize this and just tokenizes
it as multiple oddly named classes).  The script reads the entire
class attribute as a string and parses this effectively, but it can
have unintended consequences.

Instead, you can embed these more complex routines in custom
attributes.  jQuery has a plugin that allows easy access to these in a
cross-browser way (the Metadata plugin[2]).  Doing this allows you to
embed complex validation instructions on the elements themselves in an
easily human-readable and human-writable format, with an absolute
minimum of side-effects (generally, *no* side effects).

> I've seen code that has invalid attributes. These attributes won't
> always have the same effect as the author wanted them to. Not all
> authors expect the same thing from their invalid HTML.
>
> Recent c.l.js discussions have included examples of page author using
> a named element where that element does not support the name
> attribute, e.g. <span name='fred'>. The author had expected the
> element to be included with getElementsByName, but it wasn't. (not the
> first time someone has expected nonstandard behavior from an
> attribute). I've seen other uses of invalid HTML that did what the
> author wanted to in most cases.

This is (one reason) why I objected to using the blanket term "invalid
HTML", because it covers far more than what we're talking about here.
*I*, and Nicholas I'm sure, are referring solely to using *custom*
attributes.  In this example, you're talking about hacking an existing
attribute, and being surprised at the outcome.  (I find it likely that
the author was trying to use @name as a replacement for @class, hoping
to lean on the already-implemented getElementsByName function rather
than rolling his own getElementByClass).

>> As to how custom attributes can help control scripts, look into any
>> decent javascript plugin.  Many of them utilize some form of metadata
>
> What is a javascript plugin?
>
> The <param> element is designed for associating data with a plugin,
> such as a swf movie. Is this an allusion?

I apologize; I thought the term was widespread enough.  When using
things like the jQuery library, additional scripts built on top of it
are termed 'plugins'.


In general, though, the case for custom attributes is identical to the
case for JS expando attributes, which *have* been around for a long
time.  It can be very useful for a script to store arbitrary data on
an element, and the simplest way to do this in many cases is by
creating a new expando attribute.  Custom attributes is nothing more
than a way to embed this information in the static HTML as well, so
that it can be authored and carried around independently of the
script, or provide good 'initial values' to the script.

And again, as stated previously, this discussion *has* already been
settled.  We have the data-* attributes as an officially blessed way
to provide custom attributes on HTML, and as a recommended way to add
expando attributes via JS.  What I'm talking about is only 'invalid
HTML' in HTML4 - it's perfectly valid html5 now.

1: http://bassistance.de/jquery-plugins/jquery-plugin-validation/
2: http://dev.jquery.com/view/trunk/plugins/metadata/jquery.metadata.js

~TJ