On Sun, 2009-08-09 at 22:02 +0800, Bo Yang wrote:
> 1. Change the parser wrapper structure now. In HTMLDocument, there are
> methods like HTMLDocument.open, HTMLDocument.write, which are used for
> writing some string to DOM. This require the HTMLDocument must know
> its parser. But our in the structure of libDOM, the parser is created
> before the Document and it is the parser creating the document, I
> think this should be changed.
>
> The HTMLDocument will get created firstly and it has a parser
> within it. It is the client of HTMLDocument who is responsible for
> passing corresponding parser to HTMLDocument. This mean, we will have
> a function like:
>
> dom_html_document_create(dom_alloc, void *, lwc_context *, parser *, ....);
>
> In the future, the Netsurf will create a Parser according the HTTP
> response header's content type (text/html to create a hubbub parser,
> and text/xml to create a libxml parser), and pass it to the
> HTMLDocument to create a one instance of it. And then, the loading and
> parsing starts.
Please flesh this proposal out more, with specific APIs etc. Then we'll
have more idea if it's sane.
> 2. There are some methods in HTML module, which is used to manipulate
> the UI related stuff such as focus()/select(). But, libDOM is designed
> to deal with content model only, and I don't think it is a good thing
> to put any UI related code into it. So, to deal with this kind of
> method. I propose to use a function pointer table like:
>
> struct ui_handler {
> dom_exception (*element_focus)(dom_node *element);
> dom_exception (*element_select)(dom_node *element);
> dom_exception (*element_blur)(dom_node *element);
> }
>
> The client of HTMLDocument should provide this table when it create a
> HTMLDocument.
Sounds fine. LibCSS does something very similar.
> 3. The remain part of HTML module are content focus methods and
> various properties.
>
> For methods, just implement them. For properties, I divide them into
> two parts according their type. For non-DOMString type properties,
> just implement them. But for DOMString type, I think maybe we can just
> do nothing. The reason are:
>
> 1. All DOMString properties can be accessed through
> "setAttribute/getAttribute";
> 2. HTML model spec said, the model is introduced "to provide
> convenience mechanisms, where appropriate, for common and frequent
> operations on HTML documents". For language like Javascript, which
> support property, it is convenient to support this properties. But to
> C language, I don't think it provide any more convenience than
> "getAttribute/setAttribute";
I have no great objection to deferring implementation of these
properties to specific language bindings. As you say, there's little
added convenience over the core attribute accessors.
That said, if any of these properties do magical stuff as a side-effect,
then perhaps they should be implemented.
J.
