Interesting... I've been wondering lately if, like you say, five to ten years from now, how complicated [or sophisticated] web mark-up language will become. I don't know much about XUL but I keep imagining something along the lines of PostScript -- a language far too complicated for most designers to actually hand-code to layout their pages -- and they'll rely on QuarkXPress-like or WYSIWYG page layout applications and tools for design.

And I often wonder what the digital print world would have been like if, back in the day, graphic designers had to learn to code in PostScript...

Interesting... I've been wondering lately if, like you say, five to ten years from now, how complicated [or sophisticated] web mark-up language will become. I don't know much about XUL but I keep imagining something along the lines of PostScript -- a language far too complicated for most designers to actually hand-code to layout their pages -- and they'll rely on QuarkXPress-like or WYSIWYG page layout applications and tools for design.

And I often wonder what the digital print world would have been like if, back in the day, graphic designers had to learn to code in PostScript...

Menus in JS aren't to cool.

But there are two ways to deal with them,
the first one is Eric Meyer's CSS-only menus (http://www.meyerweb.com/eric/css/edge/menus/demo.html - and this is really cool if you have a CSS2-compliant browser)

The second one is what the BarML Project ( http://barml.mozdev.org/installation.html ) is trying to achieve - an XML language that describes the menu, included to a HTML file via the LINK tag.
After installing the Mozilla add-on just go to http://barml.b7.pl/tr/barml1/ and Mozilla will add a new toolbar with the menu created with BarML.

(http://barml.b7.pl/tr/barml1/ is in Polish only, but this link is here only for demonstration. The project has just started and they haven't translated the specs into English yet, but try looking at the examples ("Przyklady")).

What, you don't like it? So invent something different that does what you want.

Oops... you already did. Sorry.

May I lick your boots now?

A lot of the elements of which you speak have been written. The problem is that they only work in IE/Win or Mozilla. Erik Arvidsson & Emil A Eklund have written several excellent widgets for using on a webpage. Check out WebFX. (Note, I haven't gotton the page to work properly on any Mac browser)

I agree, and I think I wrote it more than once on my blog, with your comments. About precise positioning and flexing, did you see http://daniel.glazman.free.fr/weblog/position__new.html ? This proposal can do all what you want.

hey, where'd my url go? http://webfx.eae.net

Dave, right on man!

One thing you didn't mention: although I know a lot of people "hate" Flash because of some kind of stigma that it had back in the day, it is eminently useful for complex widgets like dropdown menues and other UI elements (NOT for dorky animations and "splash" screens). It has the advantage of being completely portable, it's built into QuickTime and platform independant (same on a Mac as on a cellphone as a windows machine).

I agree with most of your points, although I still think we really must move away from all the tags in web pages. Seperation of style and content is really important. Especially when this next big thing in design comes along and everyone is stuck trying to seperate their content from all the style.

Most CSS problems I've had (and I used to hate CSS, now I can't live without it) stemmed from not understanding how it really works. I kinda doubt that's a problem with you, but the majority of people I've talked to who can't make it go really don't understand how it works. Get past that and things become much easier (and for the "I shouldn't have to learn anything new" crowd, if you really think that way, man are you in the wrong business).

I'm also not sure about your comments on the Navigator window. I do exactly that sort of layout in my CMS editor and it works fine in IE 5.0+ and all versions of Mozilla since 1.0 (I don't have any older versions around to test it with). It's just CSS and some DOM manipulation. Okay, that's not pure CSS, but the Mozilla UI is done with JS, right? Yes, I'm aware that you guys probably had constraints that I don't, but it *is* possible to do such things.

I think the biggest problem the web has as far as layout goes (and a lot of CSS' problems seem to come from trying to deal with this) is that people want to be able to treat it like print. It's not print; it has odd constraints that print doesn't have (your page can resize arbitrarily) and odd abilities print doesn't have (someone with poor eyesight can't tell a magazine page to display in a larger font). As long as people keep trying to shoehorn ideas from a different medium into this one, they'll continue be frustrated.

I just took a look at XUL and damn I wish that format was available for webdesign. It would be so great.

As for Flash, it has two obvious downsides: you can't "copy & paste" together a flash file (you can't automate flash content creation easily) and as far as I know it still costs money to use the full version of the authoring tools for it.

I plan to implement XBL and the XUL layout primitives in Safari eventually (once more pressing bugs have been fixed and there's time to think about fun stuff like this).

Dave writes: Another huge problem with CSS and HTML: why can't you make popups? ... For example, a basic menu should allow you to move diagonally into submenus without dismissing the menu.

If you consider XHTML2 to be a modularization framework based on XML then the styling is abstracted out into CSS, the semantics into the XHTML2 namespace modules and tags, and the behavior into XML Events (DOM2 events with XML syntax instead of IDL), and XForms.

The following markup expresses an hierarchical selection. A desktop use agent would reasonably express this as a widget with slide-out menus, but a voice browser or small screen device can choose a different, more appropriate way to present it. CSS can always be used for styling.
<select1 ref="flavor">
  <label>Flavor</label>
  <choices>
    <label>Old Favorites</label>
    <item>
      <label>Vanilla</label>
      <value>vanilla</value>
    </item>
    <item>
      <label>Chocolate</label>
      <value>chocolate</value>
    </item>
  </choice>
  <choices>
    <label>Fruity</label>
    <item>
      <label>Mango</label>
      <value>mango</value>
    </item>
    <item>
      <label>Rapsberry</label>
      <value>raspberry</value>
    </item>
  </choice>  
</select1>

When I say "popup", I mean "DHTML menus" and not "dropdown list widgets." The former are not widgets and are not expected to map to the native widget on a user's platform. The latter is a widget and would e.g., in Safari map to an Aqua control.

The appopriate analog in XHTML2 would be the <nl> tag or even just the <ul> tag. (I frankly see no reason for the <nl> tag to exist.)

You also need control over how the popup appears, e.g., which can be done with an anchor specification scheme (this is how XUL does it).

In Mozilla, popup is represented as a display type, but I believe it would be better to represent it with a new position property value, e.g.,

li > ul { position: popup }

As for the person who said "Yes, I could do the Navigator window using DOM calls", that defeats the whole point. It should be possible to make such a simple layout without using script.

Glazman, you are right that your proposal can do the Navigator layout.

Also, in order to really get rid of all the DHTML layer frameworks on the Web, you have to be able to support popups that can contain arbitrary markup. I'm not only talking about simple hierarchical menu structures when I say, "The Web needs popups."

I mean that the Web needs the ability to display first-class layers filled with arbitrarily-styled markup that can also expand outside the confines of the browser window (in the way that tooltips and application menus can).

As a scripter who wasted way too many man-years in the tarpits of cross-browser CSS + JS + DOM, I can't describe how liberating it was to discover that, with Flash MX targeting the Flash 6 Player, one can create Flash programs (SWFs) solely from Actionscript. There's no need to use the costly, obnoxious Flash authoring tool except to compile SWF files. But compiling SWFs can also be done in Ming, a free, open source, cross-platform library (which includes PHP, Perl, Ruby wrappers) whose latest 0.3a release handles Flash 6 Actionscript with nary a hitch.

It's entirely feasible to write an Actionscript program to implement a drag'n'drop Flash layout GUI (with reusable skinnable 100% Actionscripted widgets) that runs in the Flash player and spits out commands to Ming to compile standalone Flash movies. A bit more scripting and you can have an XML dialect that uses Actionscript's native XML parser to generate Flash UI layouts from markup, all without recourse to the Macromedia authoring environment.

Re CSS: Claus Wahlers (Mozquito) has implemented possibly the most complete, standards-conforming XHTML CSS renderer, entirely in Actionscript. At present his Deng library is far too slow to be a practical alternative to standard browsers, but Macromedia might conceivably be motivated by his example to include CSS and XHTML in the next FMX release. CSS advocates could do worse than mount a campaign to induce MM's corporate strategists to have a bash at it.

A slight digression, but I have never understood why Mac browsers use pop-up menus everywhere, whereas Windows one use dropdowns with type-ahead.
If a popup menu doesn't fit onscreen, it is useless. The most egregious ones are zip code or country lists, as satirized here:
http://www.dropdownusa.com/
A little browser intelligence goes a long way here - as you know how many items are in the list, you could pick the correct widget to display to make the user's task easiest (pop-up menu for <7 items,dropdown with typeahead fro more).

"Popups, trees, ... these are all obviously needed on the Web"

This assertion makes me uneasy. I am not convinced that UI widgets inside the browser window should mimic the UI widgets outside the browser. That way lies madness - the widgets inside will look the same as or similar to the widgets outside, but not necessarily behave in the same fashion. The web-widgets could act in the same manner as the OS-widgets on the client's computer - but then the designer loses control over the design. The web-widgets could act in the same manner as the widgets for a particular OS - but then the users of other OSes will be irritated, frustrated and confused. The web-widgets could act in a lowest-common-denominator fashion - but then ALL users will be irritated, frustrated and confused.

I think it's an overloading problem: should "web pages" be slightly interactive analogs to the printed page, or should they be what end-users perceive as "applications"? IMHO, the problem should be split into two different spaces.

In the early days of the internet, it was all about speed, since connections were slow and bandwidth was low. Now that more users have fast connections, an alarming trend has appeared: "Why NOT make it look >exactly< like our printed media?!" - one answer: "It's the WEB!" Breaking out of the print paradigm is going to be really hard for some folks, impossible for many. The concept of 'less is more' seems to have gone by the wayside. With luck, it will return.

Back in the day, about 8 years ago, we predicted that with several browsers on several platforms that it would be impossible to faithfully reproduce an artist's layout with adequate fidelity, and we gambled on the advent of high speed net access and came out with QuarkImmedia. For dozens of reasons it was a colossal flop, but the main one was that it wa proprietary and it was ahead of its time.

It's folly to bank either on increasing bandwidth or on standards being adopted after the fact, What would be really nice is if Microsoft would start testing their browser and get it up to snuff in the rendering department. Safari and Mozilla both do a wonderful job by comparison, Then again it's wrong to bank on Microsoft doing anything, as they will only do what suits them. Considering what the market looks like (ie most people use MSIE) I feel we are working on standards which will be rarely used if MSIE screws them up.