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.
Well, they think in terms of the things they can see, which are indeed the visible representations of the layout objects. What matters is the behavior they observer, which follows the rules in the CSS specification or in the XUL documentation. No changes to the back end should change any of this behavior....
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 ...
What are people trying to learn, exactly? Perhaps if you gave some examples of this, it would be easier to see what problem we are trying to solve?
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.
<tree> and <template> are very much special cases (especially <template>) which tie very deeply into the guts of XUL. Understanding how they work is neither necessary for using them, not for creating custom tags via XBL bindings (eg <tabbrowser>).
Note that you can _either_ have a "special" frame (like <tree>) or an XBL binding (like <tabbrowser>) but not both (an XBL binding will preempt the frame).
It would establish principles like builders, renderers, views and mozilla's treatment of MVC.
I'm not familiar with MVC, to be truthful, so I don't know how it's relevant here....
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.
Yes, but the impact is strictly defined by a third party and thus any changes made in layout should have no effect on them.....
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.
Actually, you can. This is precisely the point of good API design. Now it may be that the APIs in question are badly designed... Again, the question is not whether an XPFE programmer can learn about frames -- lxr.mozilla.org covers that angle. The question is why he would need to.
Although the world is infinitely complex, small portions of it can be easy.
Only as long as you don't pay much attention, in my experience.
The bits of layout that poke up into XPFE programmers' experience should be easy, whether they're explicit or implied.
Again, these portions are already defined in existing specifications....
It'd really help if you could provide some concrete examples of instances of the problem you are trying to solve.
-Boris
_______________________________________________ Mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
