From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <008901bff79e$885c3160$02a7b6c3@lucid.proweb.net> From: "Matt" To: , <9fans@cse.psu.edu> References: <397F24FA.2FDAF786@yahoo.com> Subject: Re: [9fans] Gecko based web browser Date: Thu, 27 Jul 2000 08:43:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: eb140ea8-eac8-11e9-9e20-41e7f4b1d025 ----- Original Message ----- From: "James G. Stallings II" To: <9fans@cse.psu.edu> Sent: 26 July 2000 18:50 Subject: Re: [9fans] Gecko based web browser > 'scuse me for butting in on a tired thread, but has anyone considered a > divorce from contemporary browser technology? > > Something, perhaps, that retrieved the content via the http protocol and > left the display and formatting to the user's disretion? well if you've read my comments on the subjkect you'll know I agree with you there the document should be retrieved and mounted and then the rendering engine attached content creation tools such as Dreamweaver are increasingly using Javascript to control pages. Designers, esp. the newer ones, are quite happy to use script all over the place and I think that the web will become increasingly unusable to non-script enabled browsers. I've just started at a new web design shop and many of the designers there don't even know about text only browsers and as such don't always design their sites to degrade gracefully. I hope to educate my new co-workers. Anyway my point is that version 4 browsers are beyond simple html display any any development of a browser had better take CSS-p and css-2 into account if it's from scratch. As i mentioned mounting the document and having the DOM exposed as a FS would be good and any links could be followed and added to the FS see http://www.w3.org/DOM/ if you want to see the spec but a snippet : 1.1.1. The DOM Structure Model The DOM presents documents as a hierarchy of Node objects that also implement other, more specialized interfaces. Some types of nodes may have child nodes of various types, and others are leaf nodes that cannot have anything below them in the document structure. The node types, and which node types they may have as children, are as follows: Document -- Element (maximum of one), ProcessingInstruction, Comment, DocumentType DocumentFragment -- Element, ProcessingInstruction, Comment, Text, CDATASection, EntityReference DocumentType -- no children EntityReference -- Element, ProcessingInstruction, Comment, Text, CDATASection, EntityReference Element -- Element, Text, Comment, ProcessingInstruction, CDATASection, EntityReference Attr -- Text, EntityReference ProcessingInstruction -- no children Comment -- no children Text -- no children CDATASection -- no children Entity -- Element, ProcessingInstruction, Comment, Text, CDATASection, EntityReference Notation -- no children The DOM also specifies a NodeList interface to handle ordered lists of Nodes, such as the children of a Node, or the elements returned by the Element.getElementsByTagName method, and also a NamedNodeMap interface to handle unordered sets of nodes referenced by their name attribute, such as the attributes of an Element. NodeLists and NamedNodeMaps in the DOM are "live", that is, changes to the underlying document structure are reflected in all relevant NodeLists and NamedNodeMaps. For example, if a DOM user gets a NodeList object containing the children of an Element, then subsequently adds more children to that element (or removes children, or modifies them), those changes are automatically reflected in the NodeList without further action on the user's part. Likewise changes to a Node in the tree are reflected in all references to that Node in NodeLists and NamedNodeMaps.