Burningbird

Ah, reading this is like a breath of fresh air. I'm glad I'm not the only one who thinks that the list you mentioned is full overly-technical complex terms for what are basically simple ideas. I can't but feel that the reason why Backbase would be going out of their way to try to convince people that Ajax is some kind of rocket science is so that they can hawk their particular library/framework to developers with a pat on the head as they say "there, there, don't you go worrying your little head about that nasty complicated Ajax stuff."

One small point: Hijax isn't a library or a framework, it's just an idea (a laughably simple one, really).

I'm in complete agreement with the premise for your book. It sounds like it will be great. I can't wait to get my hands on a copy.

While there are certainly horrible uses of HTML extensions, there are also times when using them is the right thing to do — e.g., when you need to introduce genuinely new semantics.

HInclude was one of those; after talking to a few different people, I came to the conclusion that overloading a class wasn't the right thing to do. A new element indicates that there are new semantics, and the fallback mode for implementations that don't understand works well, thanks to the advice that HTML gives.

Does it validate? No. Do I care? Not terribly; while validation is good for telling you how to know how to use a vocabulary that the validator understands, saying that anything outside of that scope isn't allowed is going too far. If we don't allow any new extensions in HTML, we'll be stuck with procedural JavaScript on the Web for a long, long time.

(And yes, I'm aware of Modularization in XHTML; until it's widely implemented and comprehensible to average Web developers, I'm not too interested).

Cheers,

Shelley, I agree with you about making valid HTML, which is why using javascript 'decorator' scripts is such a good idea. If the javascript library looks for certain classes to transform, and uses valid fallback markup, that is a good way to proceed. Your dock-emulator example before would benefit from that, falling back to a list for javascript-less browsers (not a criticism of you, more of Dojo for it's non-HTML extensions).
What are your concerns about overloading class? As class can have a space-separated list of classes, this is a very flexible way to allow enhanced markup, which is why microformats make such use of it.
By letting a element have multiple classes, you can use javascript extensions as mixins, just as you can with CSS. Similarly, you can use the containment possibilities of classes to effectively pass the contained elements to the javascript decorator.

A lot to chew on here, and most of it out of my depth. But I wouldn't throw away hostory so easily:

There is no contract with the users that history or back button or any such is ‘required’ in order for a web application to be successful.

As a user, I'd argue that, although I don't have a contract, I do have a fairly strong expectation that the back (and forward) button behaves in a reasonable and consistent way — and that way is usually "how the rest of the web works".

Breaking that expectation is likely to annoy me, even if there are good reasons for it. To take your slideshow example: yes, back to back out of the entire slideshow makes a lot of sense at the intellectual level — I went to look at some media, and now I'm done with it.

But at the reptilian level, I can pretty much guarantee that at some point I'm likely to reflexively press the Back button to back up to a slide that took my fancy. Dumping me out of the entire show is going to be annoying; and I'll be even more annoyed when I press Forward to go back in and find that I've lost my place in the slideshow and am back at the first slide.

Changing the rules at this point is changing 10+ years of mental models and habits: it's tough and there'd better be a damn good reason for it.

The hubris in the quote cited at the article — "teach users not to use the Back button" — resonates hard with me. I've used a number of online banking sites over the years which take this attitude: having decided that the Back button presents a security risk, they punish me for using it by throwing up a chastising message and forcing me back to a login page. Goddamnit, how hostile!

But now my knee is well and truly jerked,

What is required is that one understands how people might use the application and then respond accordingly.

I strongly suspect that "how I use the application" depends a lot on "how I perceive the application". If it feels like a web page, I'm likely to try to use it like a web page: hence my frustrating online banking experiences. I followed a link like I would on a web page; but when I try to go back, oops, wrong model.

Conversely, Google Spreadsheets feels like a desktop app, so that's how I use it. I couldn't tell you what it does in response to the Back button because I've never had the impulse to press it.

I think there's a simple duck test here: if you look like a web page, you should quack like one.

Jeremy, good catch on Hijax. It's a good idea and example.

Mark, we've had procedural JavaScript for years now, and we've managed to create some pretty nice stuff. But extended HTML is one thing that got us into problems in years past, so I hate to see us going that direction again.

Kevin, not sure how the use of class would have allowed me to use the Dojo library extension for fisheye and still allowed the page to validate? In this case, the library expected the custom attributes. I suppose I could have used a class and used this to designate which elements to add the custom attributes to–but seems even more complicated.

Overloading class: this is a way of adding keywords to an element, but not necessarily a way of adding keyword=value to an element.

Would be interested in yours and Mark's response to each other's comments, too.

James, good point on looking like a web page and acting as such. But something like a slideshow that has a next/back arrow is pretty common, and most folks know this is 'content in a page'. Flickr's slideshow is an example of this. I don't think people expect this to have a 'back' button for each slide. I do think that people would like to go to each individual picture, or perhaps have the slideshow remember where they were last time they visited the page.

Now, if I create what looks like five separate web pages, and traverse through them, but they're all actually the same web page changed with each click, I would expect to have 'back' button behavior. But my Ajax effects rarely try to emulate completely separate page — I would rather just load a new page.

Well, HInclude looks like a bad way of reimplementing JAH to me. Or indeed iframes. JAH lets you include an HTML fragment, iFrames a page.
Class lets you mark an element for special treatment. How to do keyword=value depends on whether you want the keywords and values human-readable or not. If you want keywords and values human-readable, use <dl>. If you just want values human-readable use a span with a class. Of course, there may be more semantic elements in HTML you can use for any given case. Have a look at the microformats examples for pre-existing thought on this.
Working within the constraints of HTML is a bit more work, but I agree that it is worth it.

Extended HTML elements like BLINK got us into trouble because vendors used their market share to push their own tags into the language without coordination. Comparing that with adding new elements that are supported by a JavaScript implementation is totally apples and oranges.

Compared to the continuing security and interoperabilty nightmare that is JavaScript, that was a picnic. Yes, there's nice stuff out there, but it's pretty steeply taxed.

With HInclude, I wanted to show that there's a way to introduce new functionality with JS, but allow the implementation to be moved into the client later, if warranted. This approach definitely isn't for everything, but I think it has a place.

Let's look at the practical trade-offs, rather than wave hands about standards goodness. By defining an element, HInclude:

1) Lost the ability to be called valid by HTML validators. But, if you're willing to ignore two or three errors, you can still find other problems on your page.

2) Gained the possibility of being declarative markup directly supported by the browser if enough people want it, and vendors listen.

If I had chosen to do it as a microformat, those aspects would be roughly reversed. It's a judgement call as to which of them is more valuable.

HOWEVER, what HInclude does isn't microformats are for; when you're adding new content from an external source to the page at load time, you're doing something fundamentally different than saying "use this style here" or "this is an address."

Consider - if we didn't yet have an IMG element, would your recommendation be to add support for it as a special class attribute, or by overloading an A tag with a javascript URI?

There is an element for it, it's <iframe>. If you don't want to do it that way, you can load a javascript that does a document.write() . If you don't want to do it that way, you can use the JAH technique. All of these work and are valid HTML.
So your "I must invent a new element for this 'cos it is so innovative and cool" is wrong on all counts.

Kevin, I don't know how to refute such a comprehensive and well-reasoned argument, so I'll just leave it there.

Cheers,

Jumping back into this thread…

Kevin, using something like dl makes no sense, because you're mixing your metadata and your data. There really is no graceful way of doing key=value pairs with microformats. That's not a 'bad', it's just that's not their space.

Mark, I must confess with the modern browsers, I don't have many interoperability problems. A few challenges now and then, but that's about it. Security is always an issue, but I never push the sandbox and watch my user input. As long as the browsers fix their flaws, that will have to do.

I'm not sure how either of these have anything to do with hInclude. You're emulating server-side includes using JavaScript, and I can't see what this buys, Mark. What is the need that this fulfills that would justify breaking web pages?

Shelley, that's why talking about this in the abstract is a mistake. Lets pick a concrete example and consider how to do it - we can revisit the Dock menu thingy if you like, though that was a rather trivial example.
What is data and what is metadata depends on the content and the context. If you have a series of key/value pairs where both the keys and values make sense in text to humans (say, a credits list for a film) <dl> is fine - this is part of the XOXO spec.
If you have a case where the values are human readable, but the keys are for machines, use the "class on container" technique - see hCard for examples of this.
If you have a case where neither key or value makes sense to the humans, only the script, use JSON (ie express them in <script>)
That leaves the case where the keys make sense and the values don't - the <abbr> design pattern could work there.

Kevin, you say that was a 'trivial' example, but you're not telling me how microformats is a better way than what I used to convert the Dojo fisheye effect into valid page content.

Perhaps you can do an example, link it here. That's usually worth a dozen comments.

I'm happy to see you arguing against the continued obfuscation of both AJAX and HTML. I do think the class attribute was intentionally designed to classify HTML nodes for processing by user agents via JavaScript, but certainly there's room for unnecessary complication there by putting information in the class attribute that isn't really a class.

If you're all going to continue referring to the Dojo dock thing in your comments, one of you might want to link to it. I only have a vague recollection of what that was, and I'm sure anyone new here is completely lost.

Oops, though I had Scott. Here tis.

As for observer/registration, is it that we want all blur events triggered in the page to be funneled through an event handler for the form submit button that checks to see if it can now enable itself? Or blur events for the target fields? That’s doable, but seems overly process intensive. I would think a better approach would be to have the form submit button enabled, and then when the form is submitted, use Ajax (JavaScript) to test if required fields are filled in and then direct the person’s attention to what’s missing. Then event handling is simplified and the only time the process is invoked is when the form is submitted, not when each field is filled in.

There are specific cases, such as an autocomplete text box or chained select boxes, where firing an event when the value of the individual element is changed is the proper behaviour and the observer pattern is useful. I have a specific instance of both in an application I'm currently working on. Our data abstractors have to enter the drugs that a patient is currently on. There are too many drugs to be listed in a single select box, so we created an autocomplete textbox (a'la Google Suggest). This allows our users to enter in new drugs that are not in the system yet, but still allows them to pick the correct drug from our predefined list.

Since certain drugs are measured only in specific units, we can chain the "units" select box to the drug value textbox. When a certain drug is entered into the text box, the correct units will be automatically selected for the user. When you are entering thousands of drugs, little steps end up saving a lot of time. The observer pattern is at the heart of most client-side data entry applications and it makes sense to transition it to web applications.

However, automatically filtering the onBlur event for all elements on a page just to check for nulls seems a bit silly. It seems best to do it at submit time as you said.

Shelley, see the summary of my XTech talk for the use case. In a nutshell, it's the evolution of what we were trying to do with ESI at Akamai; doing it in the intermediary was the best we could offer then, but the browser is the right place for it.

You say "breaking Web pages," but it's really just breaking validation, which is a very different thing. I think validation has a place, but it shouldn't have the last word in the evolution of the Web. YMMV.

Making sure a page is valid is just one step in making sure that the page performs as expected–more or less–in all browsers and in all circumstances, tomorrow as well as today. It's not a perfect process, and even when a page validates it may not be 100% valid. But it's a start.

There might be cases where both accessibility and valid markup are sacrificed in order to provide some experience, such as creating a Word tool online. No loss, really, because there are other options for people. But if we begin a practice of not worrying about this 'little' bit of invalid markup, or that little bit of non-standard JS, and so on, then next thing you know, we're back in the old days of posting notes on our sites that people have to use Firefox 2.13 to read it (and have this turned on, and cookies enabled, and so on). This just when we were finally starting to see relatively consistent pages across platforms and browsers.

The web started out sloppy and chaotic and then began to grow up. Do you see it now entering an age of early senility, where it again becomes sloppy and chaotic?

Shelley - your comment hits the heart of the matter; the question is whether you consider the Web grown up, or still in need of maturation.

I absolutely agree that pages should be designed for the long term, and validation is a valuable way to get to that goal. My only objection to it is when validation is used to argue against extensions that might, in the long term, make the Web more mature, functional and declarative.

I know that most people consider HTML done, so this isn't a mainstream view. I'll try to write more on my blog soon.