XUL box model

[beetle]

Not a direct question here

I've just been reading up on/checking out the XUL box model over at xulplanet -- HOLY COW! Why can't CSS's box model be that good?

</tangent>

[brothercake]

Refs?

[beetle]

You betcha (http://www.xulplanet.com/tutorials/xultu/boxes.html)

Of course, browse with Mozilla to see the examples ;)

[jkd]

It is nice, isn't it. :)

Very easy to create flexible, solid UI's with it.

[brothercake]

Hey is this what you used for your SVG sidebar? I wondered about that ...

It does look very sexy indeed; I do sometimes lament slightly how difficult it is to make complex boxed layouts in CSS .... specially compared with how easy it was with tables. Sinful admission I know ... :o

So - can XUL components be embedded in webpages from a namespaced-root, and gecko just natively understands it?

[jkd]

Originally posted by brothercake
Hey is this what you used for your SVG sidebar? I wondered about that ...

It does look very sexy indeed; I do sometimes lament slightly how difficult it is to make complex boxed layouts in CSS .... specially compared with how easy it was with tables. Sinful admission I know ... :o

So - can XUL components be embedded in webpages from a namespaced-root, and gecko just natively understands it?

1. Yes, the sidebar incarnation of my incomplete SVG grapher was layed out with XUL (and spiced up with MathML for equations display) :).

2. CSS3 has some properties that will make layout easier; even with them though some would argue the XUL box model is still better.

3. XUL cannot be embedded in XHTML for reasons I couldn't say authoritively. A limitation of the renderer? Sure. A significant limitation? Definitely not, it doesn't make sense to embed GUI-specific markup into a semantic language. However, XHTML (and any XML - my SVG grapher had both inline SVG and MathML), can be embedded in XUL. Also, you might be able to bind anonymous XUL to XHTML elements by the use of bindings... but that's a little... ummm... not my style. ;)

[brothercake]

Yeah I'm with you - so conceptually, embedding XUL into XHTML is pretty pointless, because XUL is for GUI building; it would be the other way round. Yeah right - Phoenix is written in XUL isn't it? :thumbsup:

I was just fishing for inspiration basically ... I think I'll be playing with this toy :)

[jkd]

Originally posted by brothercake
Phoenix is written in XUL isn't it? :thumbsup:

Yup. Serves excellently as the counter example to the "slowness" ill-informed people associate with XUL. :)

[liorean]

Well, it's a fact that XUL is slower than many other UI toolkits that uses the X-Windows/OS native handling instead. It's not as slow as to be unusable, but it's so slow that you can't have that many moving parts at the same time, or you'll find it cumbersome and slow. You can also see that it requires a far higher minimum processing than any other GUI I know of. (On the other hand, Inform and a few other TUI have the same problems if you try to use them with many moving parts, but are excellent for the more-or-less static way they are used in for example the original Zork series.)

Oh well, as OEone shows, it can be used for efficient window handling too.


(It's not really the XUL that is the weak point - it's the XBL and JavaScript often used together with it. Using XUL with C/C++ makes it much faster, though not really on par with the native handling)

[jkd]

Originally posted by liorean
though not really on par with the native handling)

Well, you can't really expect anything else. XUL operates at a higher level than a native windowing system, and is hence slower. Same deal with anything of the sort.

[brothercake]

for me, a major attraction is that it's XML, rather than a compiled binary format.

[liorean]

Well, that is a plus - but is XML the best human readable format for GUI information? An object structure like JSON would be better, I think. (There's a python based format that I was going to mention, but I forgot the name of it and can't find it in my bookmarks.)

As the case with CSS using it's own much less complicated syntax rules, I think XML isn't the best format for GUI information.

[brothercake]

I think XML is the best format for any kind of information :)

[liorean]

A point on which we disagree - xml has properties that are not wanted for some data:

- It's rather verbose, and even when you gzip it (as is the best standard compression applied to textual data) you find it's rather large. SVG takes somewhat of a hit from this versus binary vector graphics formats, but if you compared XML pixel formats versus JPEG or PNG, you'd find a much larger difference. As such, image data is best described as binaries. Further, the handling of said binary would be much faster than the handling of the XML representing it. Which gives larger both loading and processing times for XML.

- It's strictly serial, and thus not a very good format for a relational database. The existing databases have faster handling, request and response times, and use a format with high base memory consumption but low variable consumption. XML parsing is low in base consumption but high in variable consumption. There are also more effective both hierarchical and object based database formats. These are excellent for storing data that can them be output as XML with a minimum of handling, but XML isn't as good for storing the actual data.

(There are at least two hierarchical database structures that outputs XML that I know of, and both are more effective than XML except for very low amounts of data - and that's not the situation you normally would use a database in, is it?)

- For protocols, you want a minimal base size, an addition of as-small-as-possible headers when describing the data, and as little transformation of content as possible. Add to that the possibility to compress data. XML has some of these capabilities, but it's overhead is far larger than the ASCII-based structure of HTTP, MIME etc. It's also got problems with binary data. (This is getting less and less of a problem, but modems are still in use...)

- It might be verbose, but there are easier-to-read formats that you can use. CSS is an example.

- Postscript, LaTeX and PDF provide better printing document representations than their equivalents in XML with CSS or using the more appropriate XSL-FO (for printing representation, that is). They are also public standards.

In short, when you want machine-close data structures or databases, or when you want as fast processing and little space demand as possible, or better readability/easier syntax, XML isn't the best technology.

If you want a data structure that is parsable in (almost) all environments, from any language, and want to ensure yourself that people can read it, XML is a good choice. The truth is, XML is a general language, and as thus it can't be best for each given specific usage - but for some it's the best (...that has acceptable support).




That said, I think XML is good for many things - especially since many of the other format lacks the validating, referencing, flexibility and self-describing features of the XML set of technologies.

[brothercake]

Well .. I wasn't being entirely serious .. you make some fair points, especially the speed of DB interaction (although sometimes a node structure more accurately describes the data) and binary for image and presentational formats (although SVG .. you know ... it's only the file size that's a problem and that won't always be a problem).

I don't buy into this "verbosity is undesirable because it's slower to parse" thing; process is cheap - servers and clients can get faster, and they will. I basically don't think it matters.