arsd.dom

The main document interface, including a html or xml parser.

There's three main ways to create a Document:

If you want to parse something and inspect the tags, you can use the [this|constructor]:

// create and parse some HTML in one call
auto document = new Document("<html></html>");

// or some XML
auto document = new Document("<xml></xml>", true, true); // strict mode enabled

// or better yet:
auto document = new XmlDocument("<xml></xml>"); // specialized subclass

If you want to download something and parse it in one call, the [fromUrl] static function can help:

auto document = Document.fromUrl("http://dlang.org/");

(note that this requires my arsd.characterencodings and arsd.http2 libraries)

And, if you need to inspect things like <%= foo %> tags and comments, you can add them to the dom like this, with the [enableAddingSpecialTagsToDom] and [parseUtf8] or [parseGarbage] functions:

auto document = new Document();
document.enableAddingSpecialTagsToDom();
document.parseUtf8("<example></example>", true, true); // changes the trues to false to switch from xml to html mode

You can also modify things like [selfClosedElements] and [rawSourceElements] before calling the parse family of functions to do further advanced tasks.

However you parse it, it will put a few things into special variables.

[root] contains the root document. [prolog] contains the instructions before the root (like <!DOCTYPE html>). To keep the original things, you will need to [enableAddingSpecialTagsToDom] first, otherwise the library will return generic strings in there. [piecesBeforeRoot] will have other parsed instructions, if [enableAddingSpecialTagsToDom] is called. [piecesAfterRoot] will contain any xml-looking data after the root tag is closed.

Most often though, you will not need to look at any of that data, since Document itself has methods like [querySelector], [appendChild], and more which will forward to the root [Element] for you. Group: core_functionality

This represents almost everything in the DOM and offers a lot of inspection and manipulation functions. Element, or its subclasses, are what makes the dom tree. Group: core_functionality

Specializes Document for handling generic XML. (always uses strict mode, uses xml mime type and file header)

An option type that propagates null. See: Element.optionSelector Group: implementations

A collection of elements which forwards methods to the children. Group: implementations

A proxy object to do the Element class' dataset property. See Element.dataset for more info.

Do not create this object directly. Group: implementations

Proxy object for attributes which will replace the main opDispatch eventually Group: implementations

for style, i want to be able to set it with a string like a plain attribute, but also be able to do properties Javascript style. Group: implementations

This might belong in another module, but it represents a file with a mime type and some data. Document implements this interface with type = text/html (see Document.contentType for more info) and data = document.toString, so you can return Documents anywhere web.d expects FileResources. Group: bonus_functionality

. Group: bonus_functionality

. Group: core_functionality

Group: implementations

. Group: implementations

Group: implementations

. Group: implementations

. Group: implementations

. Group: implementations

. Group: implementations

. Group: implementations

. Group: implementations

There are subclasses of Element offering improved helper functions for the element in HTML. Represents a HTML link. This provides some convenience methods for manipulating query strings, but otherwise is sthe same Element interface.

Please note this object may not be used for all <a> tags. Group: implementations

Represents a HTML form. This slightly specializes Element to add a few more convenience methods for adding and extracting form data.

Please note this object may not be used for all <form> tags. Group: implementations

Represents a HTML table. Has some convenience methods for working with tabular data. Group: implementations

Represents a table row element - a Group: implementations

Represents anything that can be a table cell - or html. Group: implementations

This is thrown on parse errors. Group: implementations

This is used when you are using one of the require variants of navigation, and no matching element can be found in the tree. Group: implementations

The html struct is used to differentiate between regular text nodes and html in certain functions

Easiest way to construct it is like this: auto html = Html("<p>hello</p>"); Group: core_functionality

ditto

Represents a parsed CSS selector. You never have to use this directly, but you can if you know it is going to be reused a lot to avoid a bit of repeat parsing.

.

This is probably not useful to you unless you're writing a browser or something like that. It represents a computed style, like what the browser gives you after applying stylesheets, inline styles, and html attributes. From here, you can start to make a layout engine for the box model and have a css aware browser.

This probably isn't useful, unless you're writing a browser or something like that. You might want to look at arsd.html for css macro, nesting, etc., or just use standard css as text.

The idea, however, is to represent a kind of CSS object model, complete with specificity, that you can apply to your documents to build the complete computedStyle object.

This is kinda private; just a little utility container for use by the ElementStream class.

This is the lazy range that walks the tree for you. It tries to go in the lexical order of the source: node, then children from first to last, each recursively.

.

This delegate is called if you call Element.computedStyle to attach an object to the element that holds stylesheet information. You can rebind it to something else to return a subclass if you want to hold more per-element extension data than the normal computed style object holds (e.g. layout info as well).

The default is return new CssStyle(null, element.style);