View Full Version : Unobstrusive scripting

23 Feb 2007, 3:42 AM
Hello there,

I just discovered Ext (from the JQuery side of things) and I'm amazed at the good overall quality of code and the amount of resources available. Congratulations to the developers!

I have a question regarding one of the examples, the complex layout. It seems that each <div> in the XHTML code has a class="ylayout-inactive-content", which makes the contents of the page invisible when JavaScript is not activated. My question is: is this attribute compulsory? Why does the markup have to contain special classes?

Thinking "unobstrusive JavaScript", I'd prefer these classes to be added at runtime by the BorderLayout object... This way, the page would keep usable is JavaScript is not enabled. Or am I missing something?

23 Feb 2007, 4:33 AM
They are not required. They are only there to hide the content while the page is loading.

Another option is to not include the layout related CSS if JS is disabled. If it is enable, document.write the <link... in the header.

23 Feb 2007, 6:22 AM
Great! Does that mean that you had unobstrusiveness in mind when you designed the library? Can a page built with Ext objects (not only the BorderLayout object) still be usable when JavaScript is disabled?

23 Feb 2007, 10:20 AM
I wasn't involved with the design process, so I won't speak for Jack's thoughts in that regard. I would say what you're contemplating isn't a viable option for anything but the simplest HTML pages, in my opinion. While you could certainly layout your HTML to reflect what the layout might look like without using the library, I don't think that buys you a whole lot. For example, assume you want to build a page that looked like the Complex Layout sample - header, footer, and 3 vertical panes in the middle. You could do that with plain HTML/CSS. However, that alone should bring to mind all the serious challenges you would face without adding Javascript. For example, keeping header/footer fixed height and tied to top/bottom of the frame, while scaling the center panes when the browser window is resized or the content is longer than the available height. Sure, there are solutions to that without JS, but they're not pretty and in most cases they rely on CSS hacks to work cross browser. Now, imagine that you need to display an input form to gather user login. where does that fit in your layout? Sure you could have started with a login page and then redirected to the layout page - that defeats a major benefit of Ajax frameworks - one page; no form submit/postback; rich UI.

As another example, consider a grid that displays customer data. Using the framework, the data (only) is retrieved from the server and the layout is built clientside - all the HTML for rows, headers, footers, paging, etc. Without JS, you'd have to build that completely serverside. If you were using ASP.Net and databinding to a DataTable, it's a completely different implementation. Even if you were a magician with CSS, you'd have an almost impossible task to achieve the same rendered appearance. given the relative lack of control you have over how .Net renders a grid. Additionally any custom rendering you wanted to do in the grid, say for example making negative numbers red instead of green, would have to be done in 2 codebases. Without JS you'd end up losing a portion of the .Net grid functionality and every action would require a page submit and recreation/retransmission of the grid on the server. You get none of the benefit of Ajax. You're increasing the number of server roundtrips, increasing the amount of data transmitted because you're rebuilding entire pages, and putting more of the processing load on the server (where it's at a premium).

While there will always be a debate of Javascript vs no Javascript and accessibility/unobtrusiveness, the reality is that the demand for rich UI web applications that look/feel like a desktop apps, brings with it the required use of Javascript. I'm not saying that you should build web pages that work on only a JS-enabled browser, excluding readers,cellphones, etc. But I think that you accomplish this by intelligent separation of UI from business logic/data retrieval on the server side, so that you can serve multiple targets without trying build a single monster that works in all cases.

As a point of illustration to see what you'd be attempting to do by hand without JS, look at the HTML for one of the sample layouts. Then, using something like WebDeveloper or Firebug, look at the generated HTML after the page is built by Ext. Ask youself if you'd like to undertake building and maintaining that by hand.

In the end, it comes down to different goals. Ext is a Javascript framework used to build rich UI web applications, as opposed to things like .Net or IBM Websphere which are application development platforms that target multiple client devices, without necessarily pushing the boundaries of what's possible on the higher end of the device scale.

Boy, that was a long-winded response :)