Thanks Boris.
The difficulty with learning is that the main constraint is not communicating what's technically correct, but communicating something that will usefully penetrate the learners' mind.
[ .. chop .. ]
A: divide exposed features of layout (CSS?) into "programmer available" and "unavailable".
In other words divide up CSS extensions into those that XPFE programmers should be allowed to use (eg -moz-opacity) and those that they should not touch (eg the -moz-table-outer pseudo-element)?
This seems like a reasonable suggestion
Yay. I've said something reasonable. Phew.
B: keep the idea of a frame because its easy for learners.
"frame" as in "layout object"? I don't think the idea of a layout object is going anywhere anytime soon...
Yay.
C: make some rules to ensure frames/widgets are implemented with a degree of uniformity in the DOM/XPCOM.
Frames are typically not accessible via the DOM or via XPCOM at all. They are private objects of the layout engine. The DOM nodes are accessible, and the frames may react to changes in the DOM nodes, of course.
I accept that, however learners still think in terms of frames when they try to understand what the effect is of their use of the DOM/XPCOM. I accept that such frames are not *typically* accessible, but that is a two edged sword, because lack of access in easy tags makes hard tags harder to learn. Therefore ...
D: provide a special frame that programmers can learn on.
Learn what on?
Such a frame with an associated tag/XBL object would let coders learn principles at work in the harder tags like <tree> and <template> that aren't content-related. That special frame would have just trivial content requirements of its own.
It would establish principles like builders, renderers, views and mozilla's treatment of MVC.
F: treat XPFE JS programmers as first class users of the layout engine in terms of priorities.
How are they users of the layout engine at all? That is, where do they interact directly with the layout engine?
I'm not implying they do interact *directly*, just that they are end-users on whom the layout system has *some* impact.
Obviously various XUL objects are more direct, but they also stem partly from layout. In non-API terms, XPFE programmers are not insulated from layout concepts. Not at all. Such programmers manipulate two sets of symbols: 1. the concrete APIs they have available (with perhap no frame concept) and 2. a set of symbols for the understanding they hold in their heads. That second set definitely includes frames.
In particular I'm speaking for non-embedded(XPFE) learner programmers, who occassionally are exposed to: frame and frame-like artifacts of the layout engine
When this happens, it's a bug -- XPFE programmers should not need to know anything about frames.
You can't stop internal information leaking out. Some fancy philosophy/semiotics applies here. If you try to completely hide the frame concept, but still implement in terms of frames, then that concept will re-appear as an emergent idea. I'm not saying users should explicitly have frame API access; just that the concept is valuable, knowable and unquenchable. It will remain so as long as the underlying implementation implies it.
some aspects of layout are quite confusing to beginners/learners.
This will be the case no matter what design. The ugly truth is that layout is complicated (see eg the code that handles column widths in tables...)
Although the world is infinitely complex, small portions of it can be easy. The bits of layout that poke up into XPFE programmers' experience should be easy, whether they're explicit or implied.
The case is well established for cleaning up past code that has proved less than ideal in retrospect. The same case applies to the tangle that is the adoption/learning process.
This poorly revealed brain-dump of mine is an attempt on my part to point out some obstacles holding Mozilla back, and some potential solutions.
regards, Nigel.
_______________________________________________ Mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
