1 Posted by Peter Michaux on 8 April 2007 | Permalink

I don't think that the on* attributes should be removed from HTML until the window.onload problem is solved. Unfortunately this problem isn't solved. Not even close to solved and the partial solutions are conceptually complicated.

http://peter.michaux.ca/article/553

I agree with the idealism of separating content and behavior but only after the technical obstacles are removed.

If we could attach on* handlers with CSS style selectors like in a CSS stylesheet does then maybe that would be a solution.

2 Posted by rob larsen on 8 April 2007 | Permalink

I think looking at the current state of affairs and declaring that we shouldn't make good choices going forward is a mistake. Yes, the current state of things with the the window.onload problem is imperfect, but none of the current browsers are going to have anything to do with HTML5 anyway (we're a while away from a specification and a while away after that for actual implementations,) so why not make the right choices now?

And to my mind, removing the on* attributes is certainly a right choice.

3 Posted by Peter Michaux on 8 April 2007 | Permalink

Rob,

I agree that we need a new way to add the on* attributes but we need that before the on* attributes are deprecated. CSS selectors might work.

I think that for consistency this would mean deprecating the style attribute also to enforce separation of content and presentation.

4 Posted by Tino Zijdel on 8 April 2007 | Permalink

Sorry, you lost me here. On the one hand you are proposing to deprecate inline event-handlers for the purpose of forcing clean seperation of structure and behavior (although I very much doubt if that will have any real-life effect since the 'amateurs' will keep on using them and browsers will have to keep supporting them), but on the other hand you are proposing to add attributes to store data within the structure related to... behavior?

5 Posted by Greg Reimer on 8 April 2007 | Permalink

I also like the idea of css-like selectors for adding behavior layers. Style sheets, behavior sheets. In fact, that's sort of what :hover already is.

6 Posted by rob larsen on 8 April 2007 | Permalink

"I agree that we need a new way to add the on* attributes but we need that before the on* attributes are deprecated."

At the pace the w3c moves, we're a long way away from an actual recommendation (scheduled for q3 2010) and an even longer way away from an implementation so
I think the thing to hope for here would be a message (in the form of a draft recommendation) from the HTML working group saying "we're deprecating on*" lighting a fire on the script side to sort the issue out.

7 Posted by Brian LePore on 9 April 2007 | Permalink

I'm sorry if this starts to sound off topic but hear me out and you'll see my point.

I really don't see why we are pushing a new version of HTML. Wasn't XHTML meant to be the next evolution of HTML? I am aware that HTML5 is shaping up to be more in line with classic HTML than XHTML2. What are the fundamental differences between the two that each is trying to solve? I ask because we really need to know what they hope to achieve in order to figure out what should be in the next version of each of them. If we can't find any reason for each of them besides to made additions to the Web, then having both just doesn't cut it for me. While HTML5 looks more in line with the classic web, pushing that instead of the next version of XHTML makes it sound like standards advocates were wrong when they initially pushed it.

If possible XHMTL2 and HTML5 should try and agree on some things that would be the same for each of them. I'm certain browser developers would appreciate it if we could attempt to keep them somewhat in line with each other as each will likely mean the creation of a new rendering mode for them to deal with. For both HTML5 and XHTML2 modes browser makers should be able to start with their standards mode and move on from there.

8 Posted by Lachlan Hunt on 9 April 2007 | Permalink

Could you please elaborate on the use cases for the custom script data attribute? What would you use it for that can't be handled well with class and/or rel? (links to previous scripts that could have used it would be a good start)

What would you call it? We can't use data="" because that would clash with <object data="">. Maybe info=""?

9 Posted by Scott on 9 April 2007 | Permalink

I agree that we need to ditch the inline event handlers, but sticking them in CSS is not the answer IMHO. We want to separate behavior from structure, so likewise behavior should be separate from presentation.

And of course if we ditch the inline event handlers, we should ditch the style attribute too. Classitis will become a bigger problem as a result.

I haven't joined the HTML 5 WG either because, like Brian, I have hesitations about another HTML version when the future was supposed to be XHTML. I still think that it is. XHTML is more well-formed that HTML, even when served as text/html. People go so far as to say that they consider it harmful, but I can't agree with a statement like that when you consider HTML allows improper nesting and other bad practices. The browser may not enforce XHTML well-formedness in text/html mode, but the validator does. Absolutely nothing enforces well-formedness in HTML, period. I use XHTML because it forces people to write higher quality code that is easier to maintain.

Regardless, here's what I'd like to see from HTML5: allow the img element to optionally contain a caption element.

10 Posted by Arjan Eising on 9 April 2007 | Permalink

@ Tino:
That's exactly what I thought when I read it.
Also, your point of 'support by browsers for compatibility' needs to be discussed within the working group, as this this will not be good for the next version of HTML.

11 Posted by Jon Barnett on 9 April 2007 | Permalink

The two suggestions are not contradictory. The extra bits that authors put in their HTML for scripting are actually part of the data, but not part of the data the user needs to see. So, yes, the data helps behavior, but that's not its only purpose.

12 Posted by Koen Willems on 10 April 2007 | Permalink

I was thinking about the suggestion to introduce a footnote-tag.
In fact, footnotes represent an annotation, related to some information elsewere in the documents text. In books they are normally printed at the bottom of a page.
The problem on websites is: we have very long pages. Often users have to scroll down a page to read a footnote. And than they have to scroll back and try to find back the place in the document they were actually reading.
So instead of putting footnotes at the bottom of a webpage, it would be more convenient to have the related information in the actual viewport.

My first thoughts were: 'Let's have an annotation-tag', which could, -of course-, be placed at the bottom of a page, but also elsewhere.
Considering that I must admit: 'What's wrong with the title-attribute?' See: http://www.w3.org/TR/html4/struct/global.html#h-7.4.3

My conclusion: just forget about footnotes; they should not be used on the internet.

13 Posted by Barney Carroll on 10 April 2007 | Permalink

I'm pretty certain one of HTML5's key policies is 'deprecate as little as possible'. Good practice is not so much of an interest compared to 'add loads of new elements to make complex features easy to create'.

<footnote> will almost certainly come out of it - although to be honest such a concept (as relating to structure in the context of a 'page') is a little outdated and even counter-productive when it comes to internet publishing.

But I think XHTML2 (far more sensible an idea as far as I reckon) will deal with get rid of the action attributes.

The expansion of metadata we currently have to pack into the rel attribute is an excellent idea, but you'd need to elaborate on exactly what you would want to see achieved here. More human-readable description? More values that can be read and processed by the user agent?

Would be good to hear your thoughts. Also, why do you think HTML5 is more worth hoping for than XHTML2? It's an important debate, I think your thoughts on it wouldn't go amiss.

14 Posted by ppk on 11 April 2007 | Permalink

Tino and Lachlan: I added more information to point 2.

I also renamed footnote to note.

15 Posted by Sander on 13 April 2007 | Permalink

I'm not in favour for deprecating all inline event handlers right away. Not using them is a best practice, but should not yet have to be enforced I think.
And just like inline CSS is can be very handy for testing/debugging.

16 Posted by Tino Zijdel on 13 April 2007 | Permalink

PPK: as for point 2 ofcourse a lot of this is already taken into account in WF2.0. Furthermore I just disagree that class should only be used for CSS, I think it makes a great candidate for defining behavorial classes. WA1.0 defines class to be an attribute to be used for extensions; I don't think we should solely restrict it's usage to styling.

WA1.0 also defines some predefined classes that have some semantic meaning, such as class="note" ;)

17 Posted by Dean Edwards on 13 April 2007 | Permalink

You're right about the volume it is overwhelming. Most of the contributors to the list are doing their job. That's right, they get paid to submit email after email to the HTML list. Us mortals cannot hope to keep up.

18 Posted by Greg Reimer on 13 April 2007 | Permalink

"I agree that we need to ditch the inline event handlers, but sticking them in CSS is not the answer IMHO."

I don't think anybody's suggesting we should mix behavior and presentation. Rather, they're asking for a declarative, CSS-like syntax for attaching behavior to elements.

div.content a:link { onclick: function(e){...}; }

Not CSS, just inspired by it. If I understand correctly.

19 Posted by Neil Donald on 18 April 2007 | Permalink

I like some of the ideas - perhaps as well as a css and js files linked to a page there should be a behaviours file which references event handlers and DOM elements.

ie.

#btnSubmit onClick
{
call changeBtnText('Clicked')
}

20 Posted by William Wedin on 11 May 2007 | Permalink

A little late to the party, but I was pretty psyched about the element in XHTML 2.0. Would be very useful for poetry, scripts, and addresses. The navigation list element was nifty and simple, and I'd like to see a generalized version of , for associative lists that don't quite warrant a table.
Also, the "behavior sheets" idea has been tossed around for a while, and there's actually a pretty good implementation floating around out there. Just one little onload and you're golden.

21 Posted by Ian Hickson on 5 June 2007 | Permalink

For the #2 item in your list, could you send me some example use cases? As in, actual pages where you've run into the need for this? I need to have a better idea of how this kind of thing is to be used for before updating the spec, to make sure the needs are fully addressed.

You can send the use cases to me directly ([email protected]) or to any of the mailing lists I'm on ([email protected] or [email protected] for example).

Thanks!