YUI CSS layout versus YUI-ext BorderLayout

[sjivan]

I've often wondered when the YUI CSS layouts would be preferred over the YUI-ext BorderyLayout. I was going to post this in the other thread regarding tables and layouts but figured that it was not directly related to the thread.

My understanding is that the CSS based layouts are more suitable for pages that need to display correctly even when javascript is disabled. For example many sites have static pages (atleast for their main page) and its desirable that a user views this page even when Javascript is turned off. Its not because users might be on a browser that doesn't support javascript, but they might disable Javascript by default (for example I use a Firefox plugin that turns off Javascript by default so stay away from ad scripts etc). An example of such sites could be a designers portfolio page.

The YUI-ext layout makes layouts a breeze and supports some fancy side nav sliding and it really enhances the feel of an app. However it might be more suitable for web applications (as opposed to web sites) where a prerequisite to running the app is to have Javascript enabled. And if the user doesn't have it enabled, a noscript message message to the user stating that JS needs to be enabled can be displayed.

So if I had to build a site that had quite a bit of intro / marketing static content etc and also had functionality to support a rich shopping cart type application, I would probably have CSS based layouts for the static pages and then a login link that caused the user to enter the shopping web app.

I guess even Yahoo mail follows the same style where there main page uses CSS based layouts and then a richer desktop type layout once you enter the new Yahoo mail web app.

Jack, can you share your thoughts on this?.

Thanks,
Sanjiv

[jbowman]

The question really comes down to accessibility. If you go with BorderLayout, people who don't have javascript turned on won't be able to reliably see those pages, without more work done on your part. You'll need an alternative displayed to users without javascript, or since BorderLayout can be built off of existing markup, your original page for the layout is built needs to be readable by non-js enabled browsers.

The second option is a route i'm going to be examining soon, if that fails, then I'm going to try view-generated-sourcing my borderlayout pages to see if I can get a suitable alternative layout that's similar to my js enabled one working.

[schoterson]

That is an excellent point. But I think you might have the solution already, you could in a noscript tag place either a link to a css or an inline style tag with an @import statement that calls the "yui" grids css file. This would in essence show your page using YUI grid layout if js wasn't turned on. Granted you'd need to add the yui classes to your elements as well as specify the .ylayout-inactive-content display and/or visibility = visible.

But it should be possible to have a borderLayout page that displays in a multicolumn layout even when JS is turned off. With this said I haven't completed even a borderLayout page just yet but getting it to display when no JS is available will be something that I'll need to account for and I'll share my experience when available.

[brian.moeskau]

I agree with the previous posters. Ultimately you're just dealing with divs, ids, and css classes in both cases -- Jack's just attaching extra functionality to them. Should be pretty easy to fall back to the regular YUI grid styles without too much effort (I would think, although I haven't tried it myself of course :) )

[sjivan]

Presently the BorderLayout JS is adding the layout classes to the divs. It might be a good practice to add the classes to the divs in the initial static content itself so that stuff displays without JS. I'll give it a shot by viewing the rendered source when the layout is done via JS and then manually add those classes to the static content.

Sanjiv

[tryanDLS]

I think that's going to get cumbersome pretty quick. If you look at the generated HTML, there are a good number of elements that get added on the fly. Now for a simple layout, I'm not saying you couldn't replicate this, but I would think as the codebase evolves you could be in a position of always going back to get your 'by hand' HTML caught up to what the code is building.

[jbowman]

That's where my 10 years of experience as a scripting Sysadmin kicks in :) I'd most likely set up perl scripts to handle the parsing of the yui-ext generated code to dumb it down for static display. However, this is all still "back of the mind" planning. I'm waiting til I have a basic interface running on at least 80% of my site features done before I really start looking into options.

[sjivan]

I think that's going to get cumbersome pretty quick. If you look at the generated HTML, there are a good number of elements that get added on the fly. Now for a simple layout, I'm not saying you couldn't replicate this, but I would think as the codebase evolves you could be in a position of always going back to get your 'by hand' HTML caught up to what the code is building.

Good point. So trying to hand code layout using the YUI-ext CSS classes without Javascript doesnt seem like a good idea. If having the same page display "neatly" without or without JS is a requirement such that if JS is enabled, you want the slcik YUI-ext layouts and if not, a good fallback then schoterson's suggestion seems good. Basically the non JS layouts can be done using YUI's CSS layout framework where the class and divs are clearly documented. However only if JS is disabled should the YUI CSS framework CSS files be included in the noscript. That way the YUI-ext layout and the YUI CSS layouts don't conflict. I don't know if this will even work.. but it seems possible.

Having said this, I'd probably stick with having the "web site" portions layout using the CSS framework and the "web app" portions layout via YUI-ext.