So the short of it is that <tree> and <template> are poorly documented and need a decent howto, and possibly a redesign of the interfaces they expose to XPFE programmers.
improve design/enhancement over howto, please.
Like I said in my previous post, though, <tree> and <template> are very much special-cases; the vast majority of layout work is not focused on those tags (nor, indeed, on XUL at all).
True. My remarks are focussed on this specific area. I've no desire to comment on HTML, etc.
The design's primary goal should be to be usable once learned (since there is no way to help that along). The secondary goal, agreed, is to be learnable, but decent documentation should help there...
Got that documentation. Better tech would be good too (my thesis).
Is that me personally, layout programmers, or people who actually use those APIs (i.e. XPFE programmers)?
[ .. who should look at APIs .. ] Rather, anyone wondering what the fuss is all about.
It was intended to be pejorative. The point of an API is to enable people to do things. If an API is failing to do that, it needs fixing.
Ok, just a little respect for the work already done here.
Agreed. None of the information you have mentioned John as needing to
know involves the going to lxr or indeed knowing anything about the internal implementation of frames (eg does he really need to know about the ways trees cache style contexts? Does he really need to know about the precise details of how scrolling in trees is implemented, once that happens? No. He needs to know how to use the tree APIs to present his data).
You're right; No. Except if a few sentences would clarify further the bits he works with more directly, if those bits happen to be slaves to particularly central implementation concepts. Such sentences are motherhood statements like "everything's an object". They're comforting and confidence building, especially if they're also technically correct.
Perhaps you and I just disagree on where the boundaries of the layout engine lie and what changes would be considered "layout changes".... Changes to the public tree APIs are _not_ "layout changes" unless they actually involve changing how the guts of trees work, for example.
Yep. My initial A-F hopes were all quite high level. Probably what got me into trouble in the first place. To me, XBL/XPCOM interfaces are the coal face of mozilla; that's where most programmers are likely to do work in future. When I see lower-level layout concepts poking up in code, I say that the higher level layout activities need to be decribed by something going on at the lower level.
To try and summarise me, the HTML DOM does not contain many features that are architecturally related to layout (high or low). The XUL AOM, which is less polished, does. That area is hard to learn, possibly harder to learn than necessary. "frame" is a good starting point for ignorant beginners to go from, but alas, frame is a pure layout concept, which the AOM does not reflect. Hence a can of worms opens.
- N.
_______________________________________________ Mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
