1
0
mirror of https://github.com/rkd77/elinks.git synced 2024-11-04 08:17:17 -05:00
elinks/src/dom/sgml
2022-01-26 19:11:13 +01:00
..
docbook [mozjs24] Allow build elinks with g++ 2020-10-05 20:14:55 +02:00
html [mozjs24] Allow build elinks with g++ 2020-10-05 20:14:55 +02:00
rss [mozjs24] Allow build elinks with g++ 2020-10-05 20:14:55 +02:00
xbel [mozjs24] Allow build elinks with g++ 2020-10-05 20:14:55 +02:00
dump.c [dom] casts 2022-01-24 20:24:44 +01:00
dump.h [mozjs24] Allow build elinks with g++ 2020-10-05 20:14:55 +02:00
Makefile DOM: Add simple stack context based utility for dumping DOM trees to SGML 2006-01-30 06:07:16 +01:00
meson.build [meson] meson build scripts. 2020-09-05 22:06:01 +02:00
parser.c [dom] enum dom_stack_flag -> unsigned int 2022-01-26 19:06:38 +01:00
parser.h [dom] enum sgml_parser_flag -> unsigned int 2022-01-26 18:58:23 +01:00
README Elute all DOM-related code and put it in src/dom 2005-12-28 14:05:14 +01:00
scanner.c [dom] enum sgml_token_type -> unsigned int 2022-01-26 19:11:13 +01:00
scanner.h [mozjs24] Allow build elinks with g++ 2020-10-05 20:14:55 +02:00
sgml.c Although aware ELinks doesn't need another sgml/doctype here is DocBook 2006-01-01 23:22:10 +01:00
sgml.h [dom] cast 2022-01-24 19:52:46 +01:00

			SGML DOM tree loader

TODO items:

 - Check if the (HTML) DOM tree has a <base href="<base-uri>"> element that
   should be honoured.

 - Handle optional end tags.

 - The parser and scanner needs to know about the various data concepts of SGML
   like CDATA. It could be the start of DOCTYPE definitions. A generic way to
   create SGML parsers. One obvious place where CDATA would be useful is needed
   is for <script>#text</script> skipping which currently will generate elements
   for [ '<' <ident> ] sequences.

[Excepts from a mail from Apr 18 15:11 2004 to Witold Filipczyk]
-------------------------------------------------------------------------------
> AFAIK when <p> is not closed current code doesn't handle such situation. I'm
> thinking about function "close_tag" which automagically "closes" tags.

The problem with closing tags is to figure out if the end tag is optional. This
information is already available in the sgml_node_info structure via the
SGML_ELEMENT_END_OPTIONAL flag and the sgml_node_info is then part of the
sgml_parser_state structure that is available in the dom_navigator_state's data
member.

When initializating the dom navigator it get's passed an object size which it
uses for allocating this kind of private data.

If you look at add_sgml_element() you will see that it does:

        struct dom_navigator_state *state;
        struct sgml_parser_state *pstate;

        state = get_dom_navigator_top(navigator);
        assert(node == state->node && state->data);

        pstate = state->data;
        pstate->info = get_sgml_node_info(parser->info->elements, node);
        node->data.element.type = pstate->info->type;

Meaning it sets up the sgml_parser state.

Only problem is that I haven't had time to write patches so that the parser
actually uses the state info. It is available as:

	struct sgml_parser_state *pstate = get_dom_navigator_top(navigator)->data;

and then when another element should be generated we just have to check if the
top requires an end tag meaning

	if (pstate->info->flags & SGML_ELEMENT_END_OPTIONAL)

in which case we need to pop_dom_node(navigator) ..

It sounds easy dunno if I have forgotten something. Atleast that is a start and
we could maybe do more clever things. But my goal is to make the parser handle
fairly clean tag soup well. Later we can maybe put in some hooks to improve
really bad tag soup.
-------------------------------------------------------------------------------