Favorite books
These are a few of my favorite books.
The Belgariad
Five books by David and Leigh Eddings.
The Hitchhiker’s Guide to the Galaxy
A trilogy of five books by Douglas Adams.
This is a simple sample.
HTML documents consist of a tree of elements and text. Each element is denoted in the source by a start tag, such as "body", and an end tag, such as "/body". (Certain start tags and end tags can in certain cases be omitted and are implied by other tags.) Tags have to be nested such that elements are all completely within each other, without overlapping:This is very wrong!
This is correct.
This specification defines a set of elements that can be used in HTML, along with rules about the ways in which the elements can be nested. Elements can have attributes, which control how the elements work. In the example below, there is a hyperlink, formed using the a element and its href attribute: simple Attributes are placed inside the start tag, and consist of a name and a value, separated by an "=" character. The attribute value can remain unquoted if it doesn’t contain space characters or any of " ' ` = < or >. Otherwise, it has to be quoted using either single or double quotes. The value, along with the "=" character, can be omitted altogether if the value is the empty string. HTML user agents (e.g., Web browsers) then parse this markup, turning it into a DOM (Document Object Model) tree. A DOM tree is an in-memory representation of a document. DOM trees contain several kinds of nodes, in particular a DocumentType node, Element nodes, Text nodes, Comment nodes, and in some cases ProcessingInstruction nodes. The markup snippet at the top of this section would be turned into the following DOM tree: * DOCTYPE: html * html * head * #text: ⏎␣␣ * title * #text: Sample page * #text: ⏎␣ * #text: ⏎␣ * body * #text: ⏎␣␣ * h1 * #text: Sample page * #text: ⏎␣␣ * p * #text: This is a * a href="demo.html" * #text: simple * #text: sample. * #text: ⏎␣␣ * #comment: this is a comment * #text: ⏎␣⏎ The document element of this tree is the html element, which is the element always found in that position in HTML documents. It contains two elements, head and body, as well as a Text node between them. There are many more Text nodes in the DOM tree than one would initially expect, because the source contains a number of spaces (represented here by "␣") and line breaks ("⏎") that all end up as Text nodes in the DOM. However, for historical reasons not all of the spaces and line breaks in the original markup appear in the DOM. In particular, all the white space before head start tag ends up being dropped silently, and all the white space after the body end tag ends up placed at the end of the body. The head element contains a title element, which itself contains a Text node with the text "Sample page". Similarly, the body element contains an h1 element, a p element, and a comment. ---------------------------------------------------------------------- This DOM tree can be manipulated from scripts in the page. Scripts (typically in JavaScript) are small programs that can be embedded using the script element or using event handler content attributes. For example, here is a form with a script that sets the value of the form’s output element to say "Hello World" Each element in the DOM tree is represented by an object, and these objects have APIs so that they can be manipulated. For instance, a link (e.g., the a element in the tree above) can have its "href" attribute changed in several ways: var a = document.links[0]; // obtain the first link in the document a.href = 'sample.html'; // change the destination URL of the link a.protocol = 'https'; // change just the scheme part of the URL a.setAttribute('href', 'http://example.com/'); // change the content attribute directly Since DOM trees are used as the way to represent HTML documents when they are processed and presented by implementations (especially interactive implementations like Web browsers), this specification is mostly phrased in terms of DOM trees, instead of the markup described above. ---------------------------------------------------------------------- HTML documents represent a media-independent description of interactive content. HTML documents might be rendered to a screen, or through a speech synthesizer, or on a braille display. To influence exactly how such rendering takes place, authors can use a styling language such as CSS. In the following example, the page has been made yellow-on-blue using CSS.This page is just a demo.
For more details on how to use HTML, authors are encouraged to consult tutorials and guides. Some of the examples included in this specification might also be of use, but the novice author is cautioned that this specification, by necessity, defines the language with a level of detail that might be difficult to understand at first. 1.9.1. Writing secure applications with HTML This section is non-normative. When HTML is used to create interactive sites, care needs to be taken to avoid introducing vulnerabilities through which attackers can compromise the integrity of the site itself or of the site’s users. A comprehensive study of this matter is beyond the scope of this document, and authors are strongly encouraged to study the matter in more detail. However, this section attempts to provide a quick introduction to some common pitfalls in HTML application development. The security model of the Web is based on the concept of "origins", and correspondingly many of the potential attacks on the Web involve cross-origin actions. [ORIGIN] Not validating user input Cross-site scripting (XSS) SQL injection When accepting untrusted input, e.g., user-generated content such as text comments, values in URL parameters, messages from third-party sites, etc, it is imperative that the data be validated before use, and properly escaped when displayed. Failing to do this can allow a hostile user to perform a variety of attacks, ranging from the potentially benign, such as providing bogus user information like a negative age, to the serious, such as running scripts every time a user looks at a page that includes the information, potentially propagating the attack in the process, to the catastrophic, such as deleting all data in the server. When writing filters to validate user input, it is imperative that filters always be safelist-based, allowing known-safe constructs and disallowing all other input. Blocklist-based filters that disallow known-bad inputs and allow everything else are not secure, as not everything that is bad is yet known (for example, because it might be invented in the future). For example, suppose a page looked at its URL’s query string to determine what to display, and the site then redirected the user to that page to display a message, as in: If the message was just displayed to the user without escaping, a hostile attacker could then craft a URL that contained a script element: http://example.com/message.cgi?say=%3Cscript%3Ealert%28%27Oh%20no%21%27%29%3C/script%3E If the attacker then convinced a victim user to visit this page, a script of the attacker’s choosing would run on the page. Such a script could do any number of hostile actions, limited only by what the site offers: if the site is an e-commerce shop, for instance, such a script could cause the user to unknowingly make arbitrarily many unwanted purchases. This is called a cross-site scripting attack. There are many constructs that can be used to try to trick a site into executing code. Here are some that authors are encouraged to consider when writing safelist filters: * When allowing harmless-seeming elements like img, it is important to safelist any provided attributes as well. If one allowed all attributes then an attacker could, for instance, use the onload attribute to run arbitrary script. * When allowing URLs to be provided (e.g., for links), the scheme of each URL also needs to be explicitly safelisted, as there are many schemes that can be abused. The most prominent example is "javascript:", but user agents can implement (and indeed, have historically implemented) others. * Allowing a base element to be inserted means any script elements in the page with relative links can be hijacked, and similarly that any form submissions can get redirected to a hostile site. Cross-site request forgery (CSRF) If a site allows a user to make form submissions with user-specific side-effects, for example posting messages on a forum under the user’s name, making purchases, or applying for a passport, it is important to verify that the request was made by the user intentionally, rather than by another site tricking the user into making the request unknowingly. This problem exists because HTML forms can be submitted to other origins. Sites can prevent such attacks by populating forms with user-specific hidden tokens, or by checking Origin headers on all requests. Clickjacking A page that provides users with an interface to perform actions that the user might not wish to perform needs to be designed so as to avoid the possibility that users can be tricked into activating the interface. One way that a user could be so tricked is if a hostile site places the victim site in a small iframe and then convinces the user to click, for instance by having the user play a reaction game. Once the user is playing the game, the hostile site can quickly position the iframe under the mouse cursor just as the user is about to click, thus tricking the user into clicking the victim site’s interface. To avoid this, sites that do not expect to be used in frames are encouraged to only enable their interface if they detect that they are not in a frame (e.g., by comparing the window object to the value of the top attribute). 1.9.2. Common pitfalls to avoid when using the scripting APIs This section is non-normative. Scripts in HTML have "run-to-completion" semantics, meaning that the browser will generally run the script uninterrupted before doing anything else, such as firing further events or continuing to parse the document. On the other hand, parsing of HTML files happens incrementally, meaning that the parser can pause at any point to let scripts run. This is generally a good thing, but it does mean that authors need to be careful to avoid hooking event handlers after the events could have possibly fired. There are two techniques for doing this reliably: use event handler content attributes, or create the element and add the event handlers in the same script. The latter is safe because, as mentioned earlier, scripts are run to completion before further events can fire. One way this could manifest itself is with img elements and the load event. The event could fire as soon as the element has been parsed, especially if the image has already been cached (which is common). Here, the author uses the onload handler on an img element to catch the load event:
If the element is being added by script, then so long as the event
handlers are added in the same script, the event will still not be missed:
However, if the author first created the img element and then in a
separate script added the event listeners, there’s a chance that the load
event would be fired in between, leading it to be missed:
1.9.3. How to catch mistakes when writing HTML: validators and conformance
checkers
This section is non-normative.
Authors are encouraged to make use of conformance checkers (also known as
validators) to catch common mistakes. The W3C provides a number of online
validation services, including the Nu Markup Validation Service.
1.10. Conformance requirements for authors
This section is non-normative.
Unlike previous versions of the HTML specification, this specification
defines in some detail the required processing for invalid documents as
well as valid documents.
However, even though the processing of invalid content is in most cases
well-defined, conformance requirements for documents are still important:
in practice, interoperability (the situation in which all implementations
process particular content in a reliable and identical or equivalent way)
is not the only goal of document conformance requirements. This section
details some of the more common reasons for still distinguishing between a
conforming document and one with errors.
1.10.1. Presentational markup
This section is non-normative.
The majority of presentational features from previous versions of HTML are
no longer allowed. Presentational markup in general has been found to have
a number of problems:
The use of presentational elements leads to poorer accessibility
While it is possible to use presentational markup in a way that
provides users of assistive technologies (ATs) with an acceptable
experience (e.g., using ARIA), doing so is significantly more
difficult than doing so when using semantically-appropriate
markup. Furthermore, even using such techniques doesn’t help make
pages accessible for non-AT, non-graphical users, such as users of
text-mode browsers.
Using media-independent markup, on the other hand, provides an
easy way for documents to be authored in such a way that they are
"accessible" for more users (e.g., users of text browsers).
Higher cost of maintenance
It is significantly easier to maintain a site written in such a
way that the markup is style-independent. For example, changing
the color of a site that uses