- From: <bugzilla@jessica.w3.org>
- Date: Sun, 09 May 2010 00:36:12 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9688
Summary: ormat, as in "for HTML, ... (this does not apply to
XHTML)". This specification uses the term document to
refer to any use of HTML, ranging from short static
documents to long essays or reports with rich
multimedia, as well as to fully-fledged interactiv
Product: HTML WG
Version: unspecified
Platform: Other
URL: http://www.whatwg.org/specs/web-apps/current-work/#ter
minology
OS/Version: other
Status: NEW
Severity: normal
Priority: P3
Component: HTML5 spec (editor: Ian Hickson)
AssignedTo: ian@hixie.ch
ReportedBy: contributor@whatwg.org
QAContact: public-html-bugzilla@w3.org
CC: mike@w3.org, public-html@w3.org
Section: http://www.whatwg.org/specs/web-apps/current-work/#terminology
Comment:
ormat, as in "for HTML, ... (this does not apply to XHTML)". This
specification uses the term document to refer to any use of HTML, ranging from
short static documents to long essays or reports with rich multimedia, as well
as to fully-fledged interactive applications. For simplicity, terms such as
shown, displayed, and visible might sometimes be used when referring to the
way a document is rendered to the user. These terms are not meant to imply a
visual medium; they must be considered to apply to other media in equivalent
ways. When an algorithm B says to return to another algorithm A, it implies
that A called B. Upon returning to A, the implementation must continue from
where it left off in calling B. 2.1.1 Resources Last call for comments
#resources Tests: 0 Demos: 0 Latest Internet Explorer beta: no support
whatsoeverLatest Firefox trunk nightly build: no support whatsoeverLatest
WebKit or Chromium trunk build: no support whatsoeverLatest Opera beta or
preview build: no support whatsoeverJavaScript libraries, plugins, etc: no
support whatsoever 2009-10-23 Hixie The specification uses the term supported
when referring to whether a user agent has an implementation capable of
decoding the semantics of an external resource. A format or type is said to be
supported if the implementation can process an external resource of that
format or type without critical aspects of the resource being ignored. Whether
a specific resource is supported can depend on what features of the resource's
format are in use. For example, a PNG image would be considered to be in a
supported format if its pixel data could be decoded and rendered, even if,
unbeknownst to the implementation, the image also contained animation data. A
MPEG4 video file would not be considered to be in a supported format if the
compression format used was not supported, even if the implementation could
determine the dimensions of the movie from the file's metadata. What some
specifications, in particular the HTTP and URI specifications, refer to as a
representation is referred to in this specification as a resource. [HTTP]
[RFC3986] The term MIME type is used to refer to what is sometimes called an
Internet media type in protocol literature. The term media type in this
specification is used to refer to the type of media intended for presentation,
as used by the CSS specifications. [RFC2046] [MQ] A string is a valid MIME
type if it matches the media-type rule defined in section 3.7 "Media Types" of
RFC 2616. In particular, a valid MIME type may include MIME type parameters.
[HTTP] A string is a valid MIME type with no parameters if it matches the
media-type rule defined in section 3.7 "Media Types" of RFC 2616, but does not
contain any U+003B SEMICOLON characters (;). In other words, if it consists
only of a type and subtype, with no MIME Type parameters. [HTTP] The term
HTML MIME type is used to refer to the MIME types text/html and
text/html-sandboxed. A resource's critical subresources are those that the
resource needs to have available to be correctly processed. Which resources
are considered critical or not is defined by the specification that defines
the resource's format. For CSS resources, only @import rules introduce
critical subresources; other resources, e.g. fonts or backgrounds, are not.
2.1.2 XML Last call for comments #xml Tests: 0 Demos: 0 Latest Internet
Explorer beta: not applicableLatest Firefox trunk nightly build: not
applicableLatest WebKit or Chromium trunk build: not applicableLatest Opera
beta or preview build: not applicableJavaScript libraries, plugins, etc: not
applicable 2009-10-23 Hixie To ease migration from HTML to XHTML, UAs
conforming to this specification will place elements in HTML in the
http://www.w3.org/1999/xhtml namespace, at least for the purposes of the DOM
and CSS. The term "HTML elements", when used in this specification, refers to
any element in that namespace, and thus refers to both HTML and XHTML
elements. Except where otherwise stated, all elements defined or mentioned in
this specification are in the http://www.w3.org/1999/xhtml namespace, and all
attributes defined or mentioned in this specification have no namespace.
Attribute names are said to be XML-compatible if they match the Name
production defined in XML, they contain no U+003A COLON characters (:), and
their first three characters are not an ASCII case-insensitive match for the
string "xml". [XML] The term XML MIME type is used to refer to the MIME types
text/xml, application/xml, and any MIME type whose subtype ends with the four
characters "+xml". [RFC3023] 2.1.3 DOM trees Last call for comments
#dom-trees Tests: 0 Demos: 0 Latest Internet Explorer beta: not
applicableLatest Firefox trunk nightly build: not applicableLatest WebKit or
Chromium trunk build: not applicableLatest Opera beta or preview build: not
applicableJavaScript libraries, plugins, etc: not applicable 2009-10-23 Hixie
The term root element, when not explicitly qualified as referring to the
document's root element, means the furthest ancestor element node of whatever
node is being discussed, or the node itself if it has no ancestors. When the
node is a part of the document, then the node's root element is indeed the
document's root element; however, if the node is not currently part of the
document tree, the root element will be an orphaned node. When an element's
root element is the root element of a Document, it is said to be in a
Document. An element is said to have been inserted into a document when its
root element changes and is now the document's root element. Analogously, an
element is said to have been removed from a document when its root element
changes from being the document's root element to being another element. A
node's home subtree is the subtree rooted at that node's root element. When a
node is in a Document, its home subtree is that Document's tree. The Document
of a Node (such as an element) is the Document that the Node's ownerDocument
IDL attribute returns. When a Node is in a Document then that Document is
always the Node's Document, and the Node's ownerDocument IDL attribute thus
always returns that Document. The term tree order means a pre-order,
depth-first traversal of DOM nodes involved (through the parentNode/childNodes
relationship). When it is stated that some element or attribute is ignored,
or treated as some other value, or handled as if it was something else, this
refers only to the processing of the node after it is in the DOM. A user agent
must not mutate the DOM in such situations. The term text node refers to any
Text node, including CDATASection nodes; specifically, any Node with node type
TEXT_NODE (3) or CDATA_SECTION_NODE (4). [DOMCORE] A content attribute is
said to change value only if its new value is different than its previous
value; setting an attribute to a value it already has does not change it.
2.1.4 Scripting Last call for comments #scripting-0 Tests: 0 Demos: 0 Latest
Internet Explorer beta: not applicableLatest Firefox trunk nightly build: not
applicableLatest WebKit or Chromium trunk build: not applicableLatest Opera
beta or preview build: not applicableJavaScript libraries, plugins, etc: not
applicable 2009-10-23 Hixie The construction "a Foo object", where Foo is
actually an interface, is sometimes used instead of the more accurate "an
object implementing the interface Foo". An IDL attribute is said to be
getting when its value is being retrieved (e.g. by author script), and is said
to be setting when a new value is assigned to it. If a DOM object is said to
be live, then the attributes and methods on that object must operate on the
actual underlying data, not a snapshot of the data. The terms fire and
dispatch are used interchangeably in the context of events, as in the DOM
Events specifications. The term trusted event is used as defined by the DOM
Events specification. [DOMEVENTS] 2.1.5 Plugins Last call for comments
#plugins Tests: 0 Demos: 0 Latest Internet Explorer beta: not applicableLatest
Firefox trunk nightly build: not applicableLatest WebKit or Chromium trunk
build: not applicableLatest Opera beta or preview build: not
applicableJavaScript libraries, plugins, etc: not applicable 2009-10-23 Hixie
The term plugin refers to a user-agent defined set of content handlers used by
the user agent that can take part in the user agent's rendering of a Document
object, but that neither act as child browsing contexts of the Document nor
introduce any Node objects to the Document's DOM. Typically such content
handlers are provided by third parties, though a user agent can also designate
built-in content handlers as plugins. A user agent must not consider the
types text/plain and application/octet-stream as having a registered plugin.
One example of a plugin would be a PDF viewer that is instantiated in a
browsing context when the user navigates to a PDF file. This would count as a
plugin regardless of whether the party that implemented the PDF viewer
component was the same as that which implemented the user agent itself.
However, a PDF viewer application that launches separate from the user agent
(as opposed to using the same interface) is not a plugin by this definition.
This specification does not define a mechanism for interacting with plugins,
as it is expected to be user-agent- and platform-specific. Some UAs might opt
to support a plugin mechanism such as the Netscape Plugin API; others might
use remote content converters or have built-in support for certain types.
[NPAPI] Browsers should take extreme care when interacting with external
content intended for plugins. When third-party software is run with the same
privileges as the user agent itself, vulnerabilities in the third-party
software become as dangerous as those in the user agent. 2.1.6 Character
encodings Last call for comments #character-encodings Tests: 0 Demos: 0
Latest Internet Explorer beta: not applicableLatest Firefox trunk nightly
build: not applicableLatest WebKit or Chromium trunk build: not
applicableLatest Opera beta or preview build: not applicableJavaScript
libraries, plugins, etc: not applicable 2009-10-23 Hixie The preferred MIME
name of a character encoding is the name or alias labeled as "preferred MIME
name" in the IANA Character Sets registry, if there is one, or the encoding's
name, if none of the aliases are so labeled. [IANACHARSET] An
ASCII-compatible character encoding is a single-byte or variable-length
encoding in which the bytes 0x09, 0x0A, 0x0C, 0x0D, 0x20 - 0x22, 0x26, 0x27,
0x2C - 0x3F, 0x41 - 0x5A, and 0x61 - 0x7A, ignoring bytes that are the second
and later bytes of multibyte sequences, all correspond to single-byte
sequences that map to the same Unicode characters as those bytes in
ANSI_X3.4-1968 (US-ASCII). [RFC1345] This includes such encodings as
Shift_JIS, HZ-GB-2312, and variants of ISO-2022, even though it is possible in
these encodings for bytes like 0x70 to be part of longer sequences that are
unrelated to their interpretation as ASCII. It excludes such encodings as
UTF-7, UTF-16, GSM03.38, and EBCDIC variants. The term Unicode character is
used to mean a Unicode scalar value (i.e. any Unicode code point that is not a
surrogate code point). [UNICODE] 2.2 Conformance requirements Last call for
comments #conformance-requirements Tests: 0 Demos: 0 Latest Internet Explorer
beta: not applicableLatest Firefox trunk nightly build: not applicableLatest
WebKit or Chromium trunk build: not applicableLatest Opera beta or preview
build: not applicableJavaScript libraries, plugins, etc: not applicable
2009-10-23 Hixie All diagrams, examples, and notes in this specification are
non-normative, as are all sections explicitly marked non-normative. Everything
else in this specification is normative. The key words "MUST", "MUST NOT",
"REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
the normative parts of this document are to be interpreted as described in
RFC2119. For readability, these words do not appear in all uppercase letters
in this specification. [RFC2119] Requirements phrased in the imperative as
part of algorithms (such as "strip any leading space characters" or "return
false and abort these steps") are to be interpreted with the meaning of the
key word ("must", "should", "may", etc) used in introducing the algorithm.
This specification describes the conformance criteria for user agents
(relevant to implementors) and documents (relevant to authors and authoring
tool implementors). Conforming documents are those that comply with all the
conformance criteria for documents. For readability, some of these conformance
requirements are phrased as conformance requirements on authors; such
requirements are implicitly requirements on documents: by definition, all
documents are assumed to have had an author. (In some cases, that author may
itself be a user agent — such user agents are subject to additional rules,
as explained below.) For example, if a requirement states that "authors must
not use the foobar element", it would imply that documents are not allowed to
contain elements named foobar. User agents fall into several (overlapping)
categories with different conformance requirements. Web browsers and other
interactive user agents Web browsers that support the XHTML syntax must
process elements and attributes from the HTML namespace found in XML documents
as described in this specification, so that users can interact with them,
unless the semantics of those elements have been overridden by other
specifications. A conforming XHTML processor would, upon finding an XHTML
script element in an XML document, execute the script contained in that
element. However, if the element is found within a transformation expressed in
XSLT (assuming the user agent also supports XSLT), then the processor would
instead treat the script element as an opaque element that forms part of the
transform. Web browsers that support the HTML syntax must process documents
labeled with an HTML MIME type as described in this specification, so that
users can interact with them. User agents that support scripting must also be
conforming implementations of the IDL fragments in this specification, as
described in the Web IDL specification. [WEBIDL] Unless explicitly stated,
specifications that override the semantics of HTML elements do not override
the requirements on DOM objects representing those elements. For example, the
script element in the example above would still implement the
HTMLScriptElement interface. Non-interactive presentation user agents User
agents that process HTML and XHTML documents purely to render non-interactive
versions of them must comply to the same conformance criteria as Web browsers,
except that they are exempt from requirements regarding user interaction.
Typical examples of non-interactive presentation user agents are printers
(static UAs) and overhead displays (dynamic UAs). It is expected that most
static non-interactive presentation user agents will also opt to lack
scripting support. A non-interactive but dynamic presentation UA would still
execute scripts, allowing forms to be dynamically submitted, and so forth.
However, since the concept of "focus" is irrelevant when the user cannot
interact with the document, the UA would not need to support any of the
focus-related DOM APIs. User agents with no scripting support Implementations
that do not support scripting (or which have their scripting features disabled
entirely) are exempt from supporting the events and DOM interfaces mentioned
in this specification. For the parts of this specification that are defined in
terms of an events model or in terms of the DOM, such user agents must still
act as if events and the DOM were supported. Scripting can form an integral
part of an application. Web browsers that do not support scripting, or that
have scripting disabled, might be unable to fully convey the author's intent.
Conformance checkers Conformance checkers must verify that a document conforms
to the applicable conformance criteria described in this specification.
Automated conformance checkers are exempt from detecting errors that require
interpretation of the author's intent (for example, while a document is
non-conforming if the content of a blockquote element is not a quote,
conformance checkers running without the input of human judgement do not have
to check that blockquote elements only contain quoted material). Conformance
checkers must check that the input document conforms when parsed without a
browsing context (meaning that no scripts are run, and that the parser's
scripting flag is disabled), and should also check that the input document
conforms when parsed with a browsing context in which scripts execute, and
that the scripts never cause non-conforming states to occur other than
transiently during script execution itself. (This is only a "SHOULD" and not a
"MUST" requirement because it has been proven to be impossible. [COMPUTABLE])
The term "HTML validator" can be used to refer to a conformance checker that
itself conforms to the applicable requirements of this specification. XML
DTDs cannot express all the conformance requirements of this specification.
Therefore, a validating XML processor and a DTD cannot constitute a
conformance checker. Also, since neither of the two authoring formats defined
in this specification are applications of SGML, a validating SGML system
cannot constitute a conformance checker either. To put it another way, there
are three types of conformance criteria: Criteria that can be expressed in a
DTD. Criteria that cannot be expressed by a DTD, but can still be checked by a
machine. Criteria that can only be checked by a human. A conformance checker
must check for the first two. A simple DTD-based validator only checks for the
first class of errors and is therefore not a conforming conformance checker
according to this specification. Data mining tools Applications and tools that
process HTML and XHTML documents for reasons other than to either render the
documents or check them for conformance should act in accordance with the
semantics of the documents that they process. A tool that generates document
outlines but increases the nesting level for each paragraph and does not
increase the nesting level for each section would not be conforming.
Authoring tools and markup generators Authoring tools and markup generators
must generate conforming documents. Conformance criteria that apply to authors
also apply to authoring tools, where appropriate. Authoring tools are exempt
from the strict requirements of using elements only for their specified
purpose, but only to the extent that authoring tools are not yet able to
determine author intent. However, authoring tools must not automatically
misuse elements or encourage their users to do so. For example, it is not
conforming to use an address element for arbitrary contact information; that
element can only be used for marking up contact information for the author of
the document or section. However, since an authoring tool is likely unable to
determine the difference, an authoring tool is exempt from that requirement.
This does not mean, though, that authoring tools can use address elements for
any block of italics text (for instance); it just means that the authoring
tool doesn't have to verify that when the user uses a tool for inserting
contact information for a section, that the user really is doing that and not
inserting something else instead. In terms of conformance checking, an editor
has to output documents that conform to the same extent that a conformance
checker will verify. When an authoring tool is used to edit a non-conforming
document, it may preserve the conformance errors in sections of the document
that were not edited during the editing session (i.e. an editing tool is
allowed to round-trip erroneous content). However, an authoring tool must not
claim that the output is conformant if errors have been so preserved.
Authoring tools are expected to come in two broad varieties: tools that work
from structure or semantic data, and tools that work on a
What-You-See-Is-What-You-Get media-specific editing basis (WYSIWYG). The
former is the preferred mechanism for tools that author HTML, since the
structure in the source information can be used to make informed choices
regarding which HTML elements and attributes are most appropriate. However,
WYSIWYG tools are legitimate. WYSIWYG tools should use elements they know are
appropriate, and should not use elements that they do not know to be
appropriate. This might in certain extreme cases mean limiting the use of flow
elements to just a few elements, like div, b, i, and span and making liberal
use of the style attribute. All authoring tools, whether WYSIWYG or not,
should make a best effort attempt at enabling users to create well-structured,
semantically rich, media-independent content. Some conformance requirements
are phrased as requirements on elements, attributes, methods or objects. Such
requirements fall into two categories: those describing content model
restrictions, and those describing implementation behavior. Those in the
former category are requirements on documents and authoring tools. Those in
the second category are requirements on user agents. Similarly, some
conformance requirements are phrased as requirements on authors; such
requirements are to be interpreted as conformance requirements on the
documents that authors produce. (In other words, this specification does not
distinguish between conformance criteria on authors and conformance criteria
on documents.) Conformance requirements phrased as algorithms or specific
steps may be implemented in any manner, so long as the end result is
equivalent. (In particular, the algorithms defined in this specification are
intended to be easy to follow, and not intended to be performant.) User
agents may impose implementation-specific limits on otherwise unconstrained
inputs, e.g. to prevent denial of service attacks, to guard against running
out of memory, or to work around platform-specific limitations. There is no
implied relationship between document conformance requirements and
implementation conformance requirements. User agents are not free to handle
non-conformant documents as they please; the processing model described in
this specification applies to implementations regardless of the conformity of
the input documents. For compatibility with existing content and prior
specifications, this specification describes two authoring formats: one based
on XML (referred to as the XHTML syntax), and one using a custom format
inspired by SGML (referred to as the HTML syntax). Implementations may support
only one of these two formats, although supporting both is encouraged. The
language in this specification assumes that the user agent expands all entity
references, and therefore does not include entity reference nodes in the DOM.
If user agents do include entity reference nodes in the DOM, then user agents
must handle them as if they were fully expanded when implementing this
specification. For example, if a requirement talks about an element's child
text nodes, then any text nodes that are children of an entity reference that
is a child of that element would be used as well. Entity references to unknown
entities must be treated as if they contained just an empty text node for the
purposes of the algorithms defined in this specification. 2.2.1 Dependencies
Last call for comments #dependencies Tests: 0 Demos: 0 Latest Internet
Explorer beta: no support whatsoeverLatest Firefox trunk nightly build: no
support whatsoeverLatest WebKit or Chromium trunk build: no support
whatsoeverLatest Opera beta or preview build: no support whatsoeverJavaScript
libraries, plugins, etc: no support whatsoever 2009-10-23 Hixie This
specification relies on several other underlying specifications. XML
Implementations that support the XHTML syntax must support some version of
XML, as well as its corresponding namespaces specification, because that
syntax uses an XML serialization with namespaces. [XML] [XMLNS] DOM The
Document Object Model (DOM) is a representation — a model — of a document
and its content. The DOM is not just an API; the conformance criteria of HTML
implementations are defined, in this specification, in terms of operations on
the DOM. [DOMCORE] Implementations must support some version of DOM Core and
DOM Events, because this specification is defined in terms of the DOM, and
some of the features are defined as extensions to the DOM Core interfaces.
[DOMCORE] [DOMEVENTS] In particular, the following features are defined in
the DOM Core specification: [DOMCORE] Attr interface CDATASection interface
Comment interface DOMImplementation interface Document interface
DocumentFragment interface DocumentType interface DOMException interface
Element interface Node interface NodeList interface ProcessingInstruction
interface Text Last call for comments #text Tests: 0 Demos: 0 Latest Internet
Explorer beta: no support whatsoeverLatest Firefox trunk nightly build:
incomplete supportLatest WebKit or Chromium trunk build: incomplete
supportLatest Opera beta or preview build: no support whatsoeverJavaScript
libraries, plugins, etc: no support whatsoever 2009-10-23 Hixie interface
createDocument() method getElementById() method insertBefore() method
childNodes attribute localName attribute parentNode attribute tagName
attribute textContent attribute The following features are defined in the DOM
Events specification: [DOMEVENTS] Event interface EventTarget interface
UIEvent interface click event DOMActivate event target attribute The following
features are defined in the DOM Range specification: [DOMRANGE] Range
interface deleteContents() method selectNodeContents() method setEnd() method
setStart() method collapsed attribute endContainer attribute endOffset
attribute startContainer attribute startOffset attribute Web IDL The IDL
fragments in this specification must be interpreted as required for conforming
IDL fragments, as described in the Web IDL specification. [WEBIDL] Except
where otherwise specified, if an IDL attribute that is a floating point number
type (float) is assigned an Infinity or Not-a-Number (NaN) value, a
NOT_SUPPORTED_ERR exception must be raised. Except where otherwise specified,
if a method with an argument that is a floating point number type (float) is
passed an Infinity or Not-a-Number (NaN) value, a NOT_SUPPORTED_ERR exception
must be raised. JavaScript Some parts of the language described by this
specification only support JavaScript as the underlying scripting language.
[ECMA262] The term "JavaScript" is used to refer to ECMA262, rather than the
official term ECMAScript, since the term JavaScript is more widely known.
Similarly, the MIME type used to refer to JavaScript in this specification is
text/javascript, since that is the most commonly used type, despite it being
an officially obsoleted type according to RFC 4329. [RFC4329] Media Queries
Implementations must support some version of the Media Queries language. [MQ]
URIs, IRIs, IDNA Implementations must support the semantics of URLs defined in
the URI and IRI specifications, as well as the semantics of IDNA domain names
defined in the Internationalizing Domain Names in Applications (IDNA)
specification. [RFC3986] [RFC3987] [RFC3490] This specification does not
require support of any particular network protocol, style sheet language,
scripting language, or any of the DOM specifications beyond those described
above. However, the language described by this specification is biased towards
CSS as the styling language, JavaScript as the scripting language, and HTTP as
the network protocol, and several features assume that those languages and
protocols are in use. This specification might have certain additional
requirements on character encodings, image formats, audio formats, and video
formats in the respective sections. 2.2.2 Extensibility Last call for
comments #extensibility Tests: 0 Demos: 0 Latest Internet Explorer beta: no
support whatsoeverLatest Firefox trunk nightly build: no support
whatsoeverLatest WebKit or Chromium trunk build: no support whatsoeverLatest
Opera beta or preview build: no support whatsoeverJavaScript libraries,
plugins, etc: no support whatsoever 2009-10-23 Hixie HTML has a wide number of
extensibility mechanisms that can be used for adding semantics in a safe
manner: Authors can use the class attribute to extend elements, effectively
creating their own elements, while using the most applicable existing "real"
HTML element, so that browsers and other tools that don't know of the
extension can still support it somewhat well. This is the tack used by
Microformats, for example. Authors can include data for inline client-side
scripts or server-side site-wide scripts to process using the data-*=""
attributes. These are guaranteed to never be touched by browsers, and allow
scripts to include data on HTML elements that scripts can then look for and
process. Authors can use the <meta name="" content=""> mechanism to include
page-wide metadata by registering extensions to the predefined set of metadata
names. Authors can use the rel="" mechanism to annotate links with specific
meanings by registering extensions to the predefined set of link types. This
is also used by Microformats. Authors can embed raw data using the <script
type=""> mechanism with a custom type, for further handling by a inline or
server-side scripts. Authors can create plugins and invoke them using the
embed element. This is how Flash works. Authors can extend APIs using the
JavaScript prototyping mechanism. This is widely used by script libraries, for
instance. Authors can use the microdata feature (the item="" and itemprop=""
attributes) to embed nested name-value pairs of data to be shared with other
applications and sites. Vendor-specific proprietary user agent extensions to
this specification are strongly discouraged. Documents must not use such
extensions, as doing so reduces interoperability and fragments the user base,
allowing only users of specific user agents to access the content in question.
If such extensions are nonetheless needed, e.g. for experimental purposes,
then vendors are strongly urged to use one of the following extension
mechanisms: For markup-level features that can be limited to the XML
serialization and need not be supported in the HTML serialization, vendors
should use the namespace mechanism to define custom namespaces in which the
non-standard elements and attributes are supported. For markup-level features
that are intended for use with the HTML syntax, extensions should be limited
to new attributes of the form "_vendor-feature", where vendor is a short
string that identifies the vendor responsible for the extension, and feature
is the name of the feature. New element names should not be created. Using
attributes for such extensions exclusively allows extensions from multiple
vendors to co-exist on the same element, which would not be possible with
elements. Using the "_vendor-feature" form allows extensions to be made
without risk of conflicting with future additions to the specification. For
instance, a browser named "FerretBrowser" could use "ferret" as a vendor
prefix, while a browser named "Mellblom Browser" could use "mb". If both of
these browsers invented extensions that turned elements into scratch-and-sniff
areas, an author experimenting with these features could write: <p>This
smells of lemons! <span _ferret-smellovision _ferret-smellcode="LEM01"
_mb-outputsmell _mb-smell="lemon juice"></span></p> Attribute names starting
with a U+005F LOW LINE character (_) are reserved for user agent use and are
guaranteed to never be formally added to the HTML language. Pages that use
such attributes are by definition non-conforming. For DOM extensions, e.g.
new methods and IDL attributes, the new members should be prefixed by
vendor-specific strings to prevent clashes with future versions of this
specification. All extensions must be defined so that the use of extensions
neither contradicts nor causes the non-conformance of functionality defined in
the specification. For example, while strongly discouraged from doing so, an
implementation "Foo Browser" could add a new IDL attribute "fooTypeTime" to a
control's DOM interface that returned the time it took the user to select the
current value of a control (say). On the other hand, defining a new control
that appears in a form's elements array would be in violation of the above
requirement, as it would violate the definition of elements given in this
specification. When vendor-neutral extensions to this specification are
needed, either this specification can be updated accordingly, or an extension
specification can be written that overrides the requirements in this
specification. When someone applying this specification to their activities
decides that they will recognize the requirements of such an extension
specification, it becomes an applicable specification for the purposes of
conformance requirements in this specification. User agents must treat
elements and attributes that they do not understand as semantically neutral;
leaving them in the DOM (for DOM processors), and styling them according to
CSS (for CSS processors), but not inferring any meaning from them. When
support for a feature is disabled (e.g. as an emergency measure to mitigate a
security problem, or to aid in development, or for performance reasons), user
agents must act as if they had no support for the feature whatsoever, and as
if the feature was not mentioned in this specification. For example, if a
particular feature is accessed via an attribute in a Web IDL interface, the
attribute itself would be omitted from the objects that implement that
interface — leaving the attribute on the object but making it return null or
throw an exception is insufficient. 2.3 Case-sensitivity and string
comparison Last call for comments #case-sensitivity-and-string-comparison
Tests: 0 Demos: 0 Latest Internet Explorer beta: not applicableLatest Firefox
trunk nightly build: not applicableLatest WebKit or Chromium trunk build: not
applicableLatest Opera beta or preview build: not applicableJavaScript
libraries, plugins, etc: not applicable 2009-10-23 Hixie Comparing two strings
in a case-sensitive manner means comparing them exactly, code point for code
point. Comparing two strings in an ASCII case-insensitive manner means
comparing them exactly, code point for code point, except that the characters
in the range U+0041 to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL
LETTER Z) and the corresponding characters in the range U+0061 to U+007A (i.e.
LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are considered to also match.
Comparing two strings in a compatibility caseless manner means using the
Unicode compatibility caseless match operation to compare the two strings.
[UNICODE] Converting a string to ASCII uppercase means replacing all
characters in the range U+0061 to U+007A (i.e. LATIN SMALL LETTER A to LATIN
SMALL LETTER Z) with the corresponding characters in the range U+0041 to
U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z). Converting a
string to ASCII lowercase means replacing all characters in the range U+0041
to U+005A (i.e. LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z) with the
corresponding characters in the range U+0061 to U+007A (i.e. LATIN SMALL
LETTER A to LATIN SMALL LETTER Z). A string pattern is a prefix match for a
Posted from: 122.29.51.230
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 9 May 2010 00:36:15 UTC