Friday, October 20th, 2006
YUI BorderLayout: Rich cross browser layouts
Category: Ext
, JavaScript, Library, UI, Yahoo!
Jack Slocum has been Exploring Cross-browser Web 2.0 Layouts with Yahoo! UI.
After realising that almost every desktop application and many of these new web interfaces all start with a common layout, he decided to create a reusable layout manager called BorderLayout in JavaScript.
His requirements were:
- Must be cross-browser - JavaScript errors and inconsistency are unacceptable.
- Must look the same in every browser - Thanks to the Element object and auto box-model adjustments, this was a non-issue.
- Must be fast! - The initial layout and subsequent layouts must be fast and transparent to the user - like a desktop layout manager.
- Must support nested layouts - To really gain the full benefits on BorderLayouts, they need to be able to be nested.
- Must support existing HTML - By supporting existing HTML, unobtrusive purists can support users who have JavaScript turned off by providing an alternate stylesheet.
Here is an example of a fixed navigation and header with splitter and collapse:
JAVASCRIPT:
-
-
var layout = new YAHOO.ext.BorderLayout(document.body, {
-
north: {
-
split:false,
-
initialSize: 35
-
},
-
west: {
-
split:true, -- Can it get any easier?
-
initialSize: 200,
-
titlebar: true,
-
collapsible: true, -- Collapsible
-
minSize: 100,
-
maxSize: 400
-
},
-
center: {
-
autoScroll: true
-
}
-
});
-
layout.beginUpdate();
-
layout.add('north', new YAHOO.ext.ContentPanel('header', {fitToFrame:true}));
-
layout.add('west', new YAHOO.ext.ContentPanel('nav', {title: 'Navigation', fitToFrame:true}));
-
layout.add('center', new YAHOO.ext.ContentPanel('content'));
-
layout.endUpdate();
-
He really thought about this a lot, and has created a very flexible API to create the layout that you need.
4.6 rating from 33 votes
While a neat idea, this is really where CSS should apply. Resizing the first demo in Firefox as an example, you see that the UI lags behind the browser (text doesn’t resize “real-time”) given that window.onresize doesn’t fire until the user slows down or stops resizing enough to “allow” it to catch up. That isn’t a terribly nice UI experience.
It could be argued that CSS has failed in this area (fluid two-column layouts, etc.) and thus JS should be used, but I think scripting layout at this basic level is still less-than-optimal and non-standard, and generally slower than native CSS.
Looking at the more dynamic side, there’s no question that Javascript applies with the “collapsible” property, etc.
Pardon the rant, an interesting experiment nonetheless! :)
I have to disagree with you, only if there was some fluid animation attempted would this be problematic (lack of performance), but it reacts no differently that windows.
Scott, I would have to disagree as well.
For the user, the delayed resize might not be the normal way pages react to resizing but I think I the other usability features make up for it. I doubt there will be any users complaining “The page doesn’t resize constantly while I resize the window!”.
For the developer, to not have to worry about CSS hacks, box-model differences, doc-type differences, etc.. imagine the time you would save and can spend actually implementing the logic for your application.
It’s not for everyone, that I do agree. But I don’t think the resize behavior degrades the users experience enough to offset the things gained, both for the user and the developer.
Jacob, Jack, I agree with your point (er, disagreeing with me? Hey, wait a second! ;) ) ..I commented further on your actual blog (Jack’s) after playing around with the more complicated examples a bit more, and while I don’t like the general idea of using JS for layout, I understand the reasoning and agree that what you’ve done looks like a pretty nice, effective and (most importantly!) worry-free from a development standpoint sort of solution.
I nitpick UI stuff a lot (I imagine as you do the same), and aim to keep things as fast and responsive as possible. Of those, “live redrawing” with resize events is one - but I know Firefox is somewhat annoying in the way it delays those events. It might not be realistic to be constantly re-rendering the UI in responding to resize events also (CPU load), which is understandable.
I completely agree with your points on CSS hacks and other common layout headaches; you’ve done a very good job with that. I really wish we were able to do these kind of layouts without having to rely on Javascript, but this seems to be the way things are going. I’ve started a discussion with some other folks here (Y!) around this, “at what point does JS need to be considered for layout”, etc. Thanks for the inspiration and examples to reference! :)
What is a user that has Javascript disabled supposed to do? I know that there are a small portion of users that do that today, but I would say there are enough of them that it could be a problem.
-
Try disabling Javascript and going back to his example page, it ends up blank. This could be solved with some more Javascript to set the style on those divs instead of doing it in the CSS.
-
Its a nice fluid layout, just has a few quirks :)
Jack may comment, but from his site, he’s noted that someone could have everything look normal if they didn’t have JavaScript. You could probably slap on your DIVs with a ‘normal’ CSS, but with the JavaScript enabled, swap in the intended CSS style along with the layout.
Link Listing - October 22, 2006
YUI BorderLayout: Rich cross browser layouts [Via: Dion Almaer ] ASP.NET AJAX Beta 1 Released [Via:…
[...] More coolio YUI stuff [...]
eebndhsbqks
ufyxizpa fzfyefvi nbmolo efjarfqie
If you want it smaller, i.e. no YUI, and more “web compliant”, check out RUZEE.LayoutManager.
[...] http://ajaxian.com/archives/yui-borderlayout-rich-cross-browser-layouts • • • [...]