A: divide exposed features of layout (CSS?) into "programmer available" and "unavailable".
as bz already said, this is a good idea... would you like to suggest a separation?
One CSS suggestion is have a view of useful properties for each of HTML/XUL. <frameset>, table, and list styles need not bleed into XUL. But I'm wary of suggesting that ad-hoc because one dialect is probably complicated enough, warts and all.
A better *high level* layout suggestion is back in AOM/XPFE land: systematic design and support for a table of documentation like this:
Item Available
----------------------------------------------------------
XUL builder view XPCOM dirty subframes sub-box batch
tag object object boxObject markable styles update<box> N N N N Y N ... <scrollbox> N N Y N N N ... <sample> Y Y Y Y N Y <tree> Y Y Y Y Y Y <listbox> N N Y N N N <template> Y Y N N N N
That is roughly accurate today, but AFAIK, these types of concepts have never been given a formalised support statement like this. Neither has such a table generalised into a strategy. Nor has it been considered which tags should have which formal support above, or what a single consistent architecture for supporting/expanding this table should be.
B: keep the idea of a frame because its easy for learners.
Frames are one of the hardest concepts in mozilla.
I'm not saying they be available technology, just that that be available as a useful explaination. That is valuable.
In my other post I pointed out that the answer to the question: "what XUL element can be styled" is "framed ones".
C: make some rules to ensure frames/widgets are implemented with a degree of uniformity in the DOM/XPCOM.
Argh. I mean design rules, not style rules.
What do you mean? Frames are *not* DOM objects or XPCOM objects. Most widgets are implemented with CSS/XBL, though some have extra C++ glue. Have you got a specific example of a rule in this category?
As Boris said, I have a high-level view of layout manipulation.
D: provide a special frame that programmers can learn on.
Learn what?
learn high level layout concepts like builders; see previous post.
F: treat XPFE JS programmers as first class users of the
layout engine in terms of priorities.
They already are first-class users... we implement two entire browser UIs in XUL, a chat client, mail, JS debugger, and numerous other utilities; isn't that enough? What in particular do you think needs to be done to make XPFE users "first class priorities"?
Improve their XPCOM/AOM high level interfaces that indirectly manage changes to the current layout. Improve them to be less confusing, more orthogonal and better reflect underlying concepts where appropriate.
Somehow E got lost; which is rename command controllers to something ele. That is not layout, but it would also reduce confusion for learners, since controller=MVC=GUI rendering.
thanks for links.
- Nigel.
_______________________________________________ Mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
