Hi,
I post this message to discuss the HTML module design issue here.
HTML model is the last step before we start to integrate the libDOM
with Netsurf. Generally, this model is used to provide many convenient
ways to access the HTML document model. After look over the spec, I
propose the following general design for this module.
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.
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.
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";
Based on the above two consideration, I think we may leave the
convenient properties in HTML model out. We can just import these
properties into Javascript in future directly.
That's all my proposal, any advice are welcomed, thanks a lot!
Regards!
Bo
