Slashdot Mirror

You really shouldn't use tables for layout, and in fact, it violates the HTML specification for tables. Tables are for presenting tabular data, not layout. Using them for layout, expect breakage (not to mention, your code is completely invalid HTML).

I'd start there, and you might see an improvement in the results you get from your PDA users.

First, yup. Pre-fetch FAQ.

Second, XHTML 2.0 is being developed, which will radically change things. Make your suggestions known now.

Finally, I believe that's what SVG is for. Mozilla has some support for SVG, but it's not enabled in regular builds, IIRC.

Andreesen adding the IMG tag was a big mistake, and a very bad implementation of embedding media. The OBJECT tag is what we should have had all along.

He also complained about Mozilla's vaunted "standards compliance." His exact words: "Mozilla invents its own standards, and it's the only one to comply to them."

For the most part, this is only true if your friend believes that the W3 is a subsidiary of AOL. Needless to say, it isn't, and in fact many of the standards which Mozilla follows (While IE only sorta follows) were written by groups that included representatives from Microsoft. A partial list of the (real, non-Mozilla invented) standards that Mozilla enforces can be found here.

Isn't javascript "write once, run anyware" kinda stuff?

It'd be nice, wouldn't it.

JavaScript is a Netscape invention, always has been. As such, Netscape did write its own standard and is the only one to comply with it. However, there IS a real standard known as ECMAScript that Moz and IE both do a reasonably good job of supporting. Unfortunately, this does not cover everything. ECMAScript can be thought of as defining the 'core' of what scripting on browsers is often used for.

Beyond the core are the areas of scripting that make up the buzzword-compliant DHTML (Dynamic HTML, a fancy way of saying JS, CSS, and HTML)

This is where cross-browser scripting gets hairy. The standards used for manipulating documents dynamically are collectively defined by the W3 as the DOM, or Document Object Model, which has many uses outside of HTML, but we'll stick to its HTML uses for now. Unfortunately, some of the more advanced elements of the DOM are still in a drafting phase, and as such are not ready to be used as standards. Meanwhile, browsers implement support in their own ways, lacking any sort of rules to adhere to. It's my hope that as these drafts are finalized into W3 Recommendations, that MS will include support for them as I know Mozilla will. Until then, browser detection will continue being a way of life for advanced client side scripting.

He also complained about Mozilla's vaunted "standards compliance." His exact words: "Mozilla invents its own standards, and it's the only one to comply to them."

For the most part, this is only true if your friend believes that the W3 is a subsidiary of AOL. Needless to say, it isn't, and in fact many of the standards which Mozilla follows (While IE only sorta follows) were written by groups that included representatives from Microsoft. A partial list of the (real, non-Mozilla invented) standards that Mozilla enforces can be found here.

Isn't javascript "write once, run anyware" kinda stuff?

It'd be nice, wouldn't it.

JavaScript is a Netscape invention, always has been. As such, Netscape did write its own standard and is the only one to comply with it. However, there IS a real standard known as ECMAScript that Moz and IE both do a reasonably good job of supporting. Unfortunately, this does not cover everything. ECMAScript can be thought of as defining the 'core' of what scripting on browsers is often used for.

Beyond the core are the areas of scripting that make up the buzzword-compliant DHTML (Dynamic HTML, a fancy way of saying JS, CSS, and HTML)

This is where cross-browser scripting gets hairy. The standards used for manipulating documents dynamically are collectively defined by the W3 as the DOM, or Document Object Model, which has many uses outside of HTML, but we'll stick to its HTML uses for now. Unfortunately, some of the more advanced elements of the DOM are still in a drafting phase, and as such are not ready to be used as standards. Meanwhile, browsers implement support in their own ways, lacking any sort of rules to adhere to. It's my hope that as these drafts are finalized into W3 Recommendations, that MS will include support for them as I know Mozilla will. Until then, browser detection will continue being a way of life for advanced client side scripting.

XDocs is only competition to the rarely utilized PDF Forms technology, not to PDF entirely. OfficeXML + XDocs does compete somewhat with PDF + PDF Forms.

What is more interesting is that W3C is close to finalizing a candidate recommendation called XForms, and XDocs appears to be very similar in its goals and the requirements it fulfills.

I had been working on a COM server-side XForms processor for my former employer until recently. The goals of a server-side processor are mostly to automate many mundane tasks of web application development: data binding and validation. There are other interesting open source server-side XForms or XForms-inspired processors in Java: chiba.sf.net and Apache Cocoon.

Here is a Mozilla bugzilla feature request. However, I currently do not have the bandwidth to work on a Mozilla version independently due to other Free Software project committments. It would be interesting to combine with some recent achievements in Mozilla embedded WYSIWYG editing like xopus2.

Because of the past and current history of Microsoft everyone has knee-jerk reaction to condone anything they do. I am not a big MS fan myself, but sometimes you just have to wait and see. Just because an enitity can be perceived as being bad, it doesn't stop them from doing things that are out of character.

Two good things that have come out from MS are SOAP (XML over RPC) and RTF.

A PDF style document in XML is a good thing as in theory it makes a more understandable document format than the current PDF format. If it supports SVG, then it will be an good bonus.

The ultimate fear is that Microsoft will make a brilliant alternative to PDF, but you will have to pay for the specs, though in theory this shouldn't be too much of an issue as the XSL should be published to verify the integrity of XDoc documents. Lacking XSL or specs you could reverse engineer the format, though avoid doing this in the USA, because of the DMCA. Though until XDoc is released all this is all speculative FUD.

PDF has the lead, though how much XDoc makes up for the late start is yet to be seen. BTW there is nothing stopping Adobe from releasing their PDF printer driver for free.

isn't this what the XForms spec is for? why do we need a proprietary MS solution to do the exact same thing?

Since Adobe itself is heavily into SVG, it (SVG) is positioned to become the leading display document format. This is, in some ways, ironic, because most people think of SVG as an image format.

Consider:

1. Autotrace will generate PS (PDF's older brother) and SVG (among other things)
2. FOP will generate document output as PS, PDF, and SVG (among other things).
3. Most vector graphics programs for Linux have some SVG support, and Sodipodi uses SVG as its native document format. Open/StarOffice will generate SVG as well.

XDocs sounds more like a competitor to xforms xforms is a new standard, but looks promissing

store just a URL on the device where drivers can be downloaded from.

URLs are not guaranteed to be stable, even when the company follows the W3C's rules. Even Tim BL admits that "Pretty much the only good reason for a document to disappear from the Web is that the company which owned the domain name went out of business or can no longer afford to keep the server running" or had the domain forcibly taken from them in UDRP arbitration. Personal computer peripheral manufacturers do go out of business.

var trEl = document.getElementById("myTR");

trEl.style.display = "none";

trEl.style.display = "table-row";

Well... I don't know if someone else has already pointed these things out, and I don't have time to go through and read all 6800 posts, so I'll just voice a few complaints about PHP.

I use PHP because that's all that's available on my web hosting service other than cgi. I could use the cgi-bin but then all my URLs would start with cgi-bin/, which would suck.

PHP is nice for doing database query stuff, and it's nice for simplifying your pages (for instance if there's a standard block of HTML you want in your pages and don't want to have to copy it all the time or re-compile a bunch of static HTML files), but as I've used it, I've come across a few problems.

1) This one is really annoying. Certain pre-defined variables (I'm not sure which, maybe only user-inputted data) are pre-slashed. So if a user inputs the string 'My name is "Jon"', you get it as 'My name is \"Jon\"'. WTF is up with that? That's not what he said! I can't find the reason for this or anything else about it in the documentation (maybe it's there somewhere, but I can't find it).

2) Every time a page is loaded, it has to be re-parsed, as well as any included scripts that it uses. This is very inefficient.

3) It's a real pain to include scripts that are in different directories which include other scripts, because they will try to open them relative to the location of the original page.

I (and it seems other people do, too, guessing from the user-submitted documentation on PHP.net)have to use nasty hacks to get around these problems all the time.

As far as alternatives go, right now I'm a big fan of Python. It has lots of useful libraries, and the language is very elegant (sp?). The one thing I don't like about it is that every time you access a variable, it has to look up the name in a dictionary (I think).

Unfortunately I couldn't get mod_python to work. I'm writing my own web server (in Python), instead, so that I don't have to deal with all of the Apache/PHP problems I've had. Looked at Medusa, but that seemed a little too complicated for what I was doing.

I actually don't care much about the syntax of the language I use (as long as it's not too unreasonable). What's important to me is that I can use an elegant, efficient runtime in which I don't pay for things I don't use, and that I get a useful standard library. I think I'll be happier when I can use mod_parrot :-D

I'm still stuck with PHP on my real site, though (as opposed to my personal box that I play with).

You should also be using divs and spans over tables. Tables are deprecated.

See http://www.w3.org/MarkUp/forms -- and there's already an IE plugin that does it.

• What is the Document Object Model?
  The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. This is an overview of DOM-related materials here at W3C and around the web.
  
  Why the Document Object Model?
  "Dynamic HTML" is a term used by some vendors to describe the combination of HTML, style sheets and scripts that allows documents to be animated. The W3C has received several submissions from members companies on the way in which the object model of HTML documents should be exposed to scripts. These submissions do not propose any new HTML tags or style sheet technology. The W3C DOM WG is working hard to make sure interoperable and scripting-language neutral solutions are agreed upon.
  

• What is the Document Object Model?
  Editors:
  Philippe Le Hégaret, W3C
  Lauren Wood, SoftQuad Software Inc. (for DOM Level 2)
  Jonathan Robie, Texcel (for DOM Level 1)
  
  Introduction
  The Document Object Model (DOM) is an application programming interface (API) for valid HTML and well-formed XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. In the DOM specification, the term "document" is used in the broad sense - increasingly, XML is being used as a way of representing many different kinds of information that may be stored in diverse systems, and much of this would traditionally be seen as data rather than as documents. Nevertheless, XML presents this data as documents, and the DOM may be used to manage this data.
  
  With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model, with a few exceptions - in particular, the DOM interfaces for the XML internal and external subsets have not yet been specified.
  
  As a W3C specification, one important objective for the Document Object Model is to provide a standard programming interface that can be used in a wide variety of environments and applications. The DOM is designed to be used with any programming language. In order to provide a precise, language-independent specification of the DOM interfaces, we have chosen to define the specifications in Object Management Group (OMG) IDL [OMG IDL], as defined in the CORBA 2.3.1 specification [CORBA]. In addition to the OMG IDL specification, we provide language bindings for Java [Java] and ECMAScript [ECMAScript] (an industry-standard scripting language based on JavaScript [JavaScript] and JScript [JScript]).
  
  
  What the Document Object Model is not
  This section is designed to give a more precise understanding of the DOM by distinguishing it from other systems that may seem to be like it.
  
  
• The Document Object Model is not a binary specification. DOM programs written in the same language binding will be source code compatible across platforms, but the DOM does not define any form of binary interoperability.
• The Document Object Model is not a way of persisting objects to XML or HTML. Instead of specifying how objects may be represented in XML, the DOM specifies how XML and HTML documents are represented as objects, so that they may be used in object oriented programs.
• The Document Object Model is not a set of data structures; it is an object model that specifies interfaces. Although this document contains diagrams showing parent/child relationships, these are logical relationships defined by the programming interfaces, not representations of any particular internal data structures.
• The Document Object Model does not define what information in a document is relevant or how information in a document is structured. For XML, this is specified by the XML Information Set [XML Information set]. The DOM is simply an API to this information set.
• The Document Object Model, despite its name, is not a competitor to the Component Object Model [COM]. COM, like CORBA, is a language independent way to specify interfaces and objects; the DOM is a set of interfaces and objects designed for managing HTML and XML documents. The DOM may be implemented using language-independent systems like COM or CORBA; it may also be implemented using language-specific bindings like the Java or ECMAScript bindings specified in this document.
• 
  
  
  Where the Document Object Model came from
  The DOM originated as a specification to allow JavaScript scripts and Java programs to be portable among Web browsers. "Dynamic HTML" was the immediate ancestor of the Document Object Model, and it was originally thought of largely in terms of browsers. However, when the DOM Working Group was formed at W3C, it was also joined by vendors in other domains, including HTML or XML editors and document repositories. Several of these vendors had worked with SGML before XML was developed; as a result, the DOM has been influenced by SGML Groves and the HyTime standard. Some of these vendors had also developed their own object models for documents in order to provide an API for SGML/XML editors or document repositories, and these object models have also influenced the DOM.
  

• What is the Document Object Model?
  The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. This is an overview of DOM-related materials here at W3C and around the web.
  
  Why the Document Object Model?
  "Dynamic HTML" is a term used by some vendors to describe the combination of HTML, style sheets and scripts that allows documents to be animated. The W3C has received several submissions from members companies on the way in which the object model of HTML documents should be exposed to scripts. These submissions do not propose any new HTML tags or style sheet technology. The W3C DOM WG is working hard to make sure interoperable and scripting-language neutral solutions are agreed upon.
  

• What is the Document Object Model?
  Editors:
  Philippe Le Hégaret, W3C
  Lauren Wood, SoftQuad Software Inc. (for DOM Level 2)
  Jonathan Robie, Texcel (for DOM Level 1)
  
  Introduction
  The Document Object Model (DOM) is an application programming interface (API) for valid HTML and well-formed XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. In the DOM specification, the term "document" is used in the broad sense - increasingly, XML is being used as a way of representing many different kinds of information that may be stored in diverse systems, and much of this would traditionally be seen as data rather than as documents. Nevertheless, XML presents this data as documents, and the DOM may be used to manage this data.
  
  With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model, with a few exceptions - in particular, the DOM interfaces for the XML internal and external subsets have not yet been specified.
  
  As a W3C specification, one important objective for the Document Object Model is to provide a standard programming interface that can be used in a wide variety of environments and applications. The DOM is designed to be used with any programming language. In order to provide a precise, language-independent specification of the DOM interfaces, we have chosen to define the specifications in Object Management Group (OMG) IDL [OMG IDL], as defined in the CORBA 2.3.1 specification [CORBA]. In addition to the OMG IDL specification, we provide language bindings for Java [Java] and ECMAScript [ECMAScript] (an industry-standard scripting language based on JavaScript [JavaScript] and JScript [JScript]).
  
  
  What the Document Object Model is not
  This section is designed to give a more precise understanding of the DOM by distinguishing it from other systems that may seem to be like it.
  
  
• The Document Object Model is not a binary specification. DOM programs written in the same language binding will be source code compatible across platforms, but the DOM does not define any form of binary interoperability.
• The Document Object Model is not a way of persisting objects to XML or HTML. Instead of specifying how objects may be represented in XML, the DOM specifies how XML and HTML documents are represented as objects, so that they may be used in object oriented programs.
• The Document Object Model is not a set of data structures; it is an object model that specifies interfaces. Although this document contains diagrams showing parent/child relationships, these are logical relationships defined by the programming interfaces, not representations of any particular internal data structures.
• The Document Object Model does not define what information in a document is relevant or how information in a document is structured. For XML, this is specified by the XML Information Set [XML Information set]. The DOM is simply an API to this information set.
• The Document Object Model, despite its name, is not a competitor to the Component Object Model [COM]. COM, like CORBA, is a language independent way to specify interfaces and objects; the DOM is a set of interfaces and objects designed for managing HTML and XML documents. The DOM may be implemented using language-independent systems like COM or CORBA; it may also be implemented using language-specific bindings like the Java or ECMAScript bindings specified in this document.
• 
  
  
  Where the Document Object Model came from
  The DOM originated as a specification to allow JavaScript scripts and Java programs to be portable among Web browsers. "Dynamic HTML" was the immediate ancestor of the Document Object Model, and it was originally thought of largely in terms of browsers. However, when the DOM Working Group was formed at W3C, it was also joined by vendors in other domains, including HTML or XML editors and document repositories. Several of these vendors had worked with SGML before XML was developed; as a result, the DOM has been influenced by SGML Groves and the HyTime standard. Some of these vendors had also developed their own object models for documents in order to provide an API for SGML/XML editors or document repositories, and these object models have also influenced the DOM.
  

• What is the Document Object Model?
  The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. This is an overview of DOM-related materials here at W3C and around the web.
  
  Why the Document Object Model?
  "Dynamic HTML" is a term used by some vendors to describe the combination of HTML, style sheets and scripts that allows documents to be animated. The W3C has received several submissions from members companies on the way in which the object model of HTML documents should be exposed to scripts. These submissions do not propose any new HTML tags or style sheet technology. The W3C DOM WG is working hard to make sure interoperable and scripting-language neutral solutions are agreed upon.
  

• What is the Document Object Model?
  Editors:
  Philippe Le Hégaret, W3C
  Lauren Wood, SoftQuad Software Inc. (for DOM Level 2)
  Jonathan Robie, Texcel (for DOM Level 1)
  
  Introduction
  The Document Object Model (DOM) is an application programming interface (API) for valid HTML and well-formed XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. In the DOM specification, the term "document" is used in the broad sense - increasingly, XML is being used as a way of representing many different kinds of information that may be stored in diverse systems, and much of this would traditionally be seen as data rather than as documents. Nevertheless, XML presents this data as documents, and the DOM may be used to manage this data.
  
  With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model, with a few exceptions - in particular, the DOM interfaces for the XML internal and external subsets have not yet been specified.
  
  As a W3C specification, one important objective for the Document Object Model is to provide a standard programming interface that can be used in a wide variety of environments and applications. The DOM is designed to be used with any programming language. In order to provide a precise, language-independent specification of the DOM interfaces, we have chosen to define the specifications in Object Management Group (OMG) IDL [OMG IDL], as defined in the CORBA 2.3.1 specification [CORBA]. In addition to the OMG IDL specification, we provide language bindings for Java [Java] and ECMAScript [ECMAScript] (an industry-standard scripting language based on JavaScript [JavaScript] and JScript [JScript]).
  
  
  What the Document Object Model is not
  This section is designed to give a more precise understanding of the DOM by distinguishing it from other systems that may seem to be like it.
  
  
• The Document Object Model is not a binary specification. DOM programs written in the same language binding will be source code compatible across platforms, but the DOM does not define any form of binary interoperability.
• The Document Object Model is not a way of persisting objects to XML or HTML. Instead of specifying how objects may be represented in XML, the DOM specifies how XML and HTML documents are represented as objects, so that they may be used in object oriented programs.
• The Document Object Model is not a set of data structures; it is an object model that specifies interfaces. Although this document contains diagrams showing parent/child relationships, these are logical relationships defined by the programming interfaces, not representations of any particular internal data structures.
• The Document Object Model does not define what information in a document is relevant or how information in a document is structured. For XML, this is specified by the XML Information Set [XML Information set]. The DOM is simply an API to this information set.
• The Document Object Model, despite its name, is not a competitor to the Component Object Model [COM]. COM, like CORBA, is a language independent way to specify interfaces and objects; the DOM is a set of interfaces and objects designed for managing HTML and XML documents. The DOM may be implemented using language-independent systems like COM or CORBA; it may also be implemented using language-specific bindings like the Java or ECMAScript bindings specified in this document.
• 
  
  
  Where the Document Object Model came from
  The DOM originated as a specification to allow JavaScript scripts and Java programs to be portable among Web browsers. "Dynamic HTML" was the immediate ancestor of the Document Object Model, and it was originally thought of largely in terms of browsers. However, when the DOM Working Group was formed at W3C, it was also joined by vendors in other domains, including HTML or XML editors and document repositories. Several of these vendors had worked with SGML before XML was developed; as a result, the DOM has been influenced by SGML Groves and the HyTime standard. Some of these vendors had also developed their own object models for documents in order to provide an API for SGML/XML editors or document repositories, and these object models have also influenced the DOM.
  

• What is the Document Object Model?
  The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. This is an overview of DOM-related materials here at W3C and around the web.
  
  Why the Document Object Model?
  "Dynamic HTML" is a term used by some vendors to describe the combination of HTML, style sheets and scripts that allows documents to be animated. The W3C has received several submissions from members companies on the way in which the object model of HTML documents should be exposed to scripts. These submissions do not propose any new HTML tags or style sheet technology. The W3C DOM WG is working hard to make sure interoperable and scripting-language neutral solutions are agreed upon.
  

• What is the Document Object Model?
  Editors:
  Philippe Le Hégaret, W3C
  Lauren Wood, SoftQuad Software Inc. (for DOM Level 2)
  Jonathan Robie, Texcel (for DOM Level 1)
  
  Introduction
  The Document Object Model (DOM) is an application programming interface (API) for valid HTML and well-formed XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. In the DOM specification, the term "document" is used in the broad sense - increasingly, XML is being used as a way of representing many different kinds of information that may be stored in diverse systems, and much of this would traditionally be seen as data rather than as documents. Nevertheless, XML presents this data as documents, and the DOM may be used to manage this data.
  
  With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model, with a few exceptions - in particular, the DOM interfaces for the XML internal and external subsets have not yet been specified.
  
  As a W3C specification, one important objective for the Document Object Model is to provide a standard programming interface that can be used in a wide variety of environments and applications. The DOM is designed to be used with any programming language. In order to provide a precise, language-independent specification of the DOM interfaces, we have chosen to define the specifications in Object Management Group (OMG) IDL [OMG IDL], as defined in the CORBA 2.3.1 specification [CORBA]. In addition to the OMG IDL specification, we provide language bindings for Java [Java] and ECMAScript [ECMAScript] (an industry-standard scripting language based on JavaScript [JavaScript] and JScript [JScript]).
  
  
  What the Document Object Model is not
  This section is designed to give a more precise understanding of the DOM by distinguishing it from other systems that may seem to be like it.
  
  
• The Document Object Model is not a binary specification. DOM programs written in the same language binding will be source code compatible across platforms, but the DOM does not define any form of binary interoperability.
• The Document Object Model is not a way of persisting objects to XML or HTML. Instead of specifying how objects may be represented in XML, the DOM specifies how XML and HTML documents are represented as objects, so that they may be used in object oriented programs.
• The Document Object Model is not a set of data structures; it is an object model that specifies interfaces. Although this document contains diagrams showing parent/child relationships, these are logical relationships defined by the programming interfaces, not representations of any particular internal data structures.
• The Document Object Model does not define what information in a document is relevant or how information in a document is structured. For XML, this is specified by the XML Information Set [XML Information set]. The DOM is simply an API to this information set.
• The Document Object Model, despite its name, is not a competitor to the Component Object Model [COM]. COM, like CORBA, is a language independent way to specify interfaces and objects; the DOM is a set of interfaces and objects designed for managing HTML and XML documents. The DOM may be implemented using language-independent systems like COM or CORBA; it may also be implemented using language-specific bindings like the Java or ECMAScript bindings specified in this document.
• 
  
  
  Where the Document Object Model came from
  The DOM originated as a specification to allow JavaScript scripts and Java programs to be portable among Web browsers. "Dynamic HTML" was the immediate ancestor of the Document Object Model, and it was originally thought of largely in terms of browsers. However, when the DOM Working Group was formed at W3C, it was also joined by vendors in other domains, including HTML or XML editors and document repositories. Several of these vendors had worked with SGML before XML was developed; as a result, the DOM has been influenced by SGML Groves and the HyTime standard. Some of these vendors had also developed their own object models for documents in order to provide an API for SGML/XML editors or document repositories, and these object models have also influenced the DOM.
  

• What is the Document Object Model?
  The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. This is an overview of DOM-related materials here at W3C and around the web.
  
  Why the Document Object Model?
  "Dynamic HTML" is a term used by some vendors to describe the combination of HTML, style sheets and scripts that allows documents to be animated. The W3C has received several submissions from members companies on the way in which the object model of HTML documents should be exposed to scripts. These submissions do not propose any new HTML tags or style sheet technology. The W3C DOM WG is working hard to make sure interoperable and scripting-language neutral solutions are agreed upon.
  

• What is the Document Object Model?
  Editors:
  Philippe Le Hégaret, W3C
  Lauren Wood, SoftQuad Software Inc. (for DOM Level 2)
  Jonathan Robie, Texcel (for DOM Level 1)
  
  Introduction
  The Document Object Model (DOM) is an application programming interface (API) for valid HTML and well-formed XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. In the DOM specification, the term "document" is used in the broad sense - increasingly, XML is being used as a way of representing many different kinds of information that may be stored in diverse systems, and much of this would traditionally be seen as data rather than as documents. Nevertheless, XML presents this data as documents, and the DOM may be used to manage this data.
  
  With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model, with a few exceptions - in particular, the DOM interfaces for the XML internal and external subsets have not yet been specified.
  
  As a W3C specification, one important objective for the Document Object Model is to provide a standard programming interface that can be used in a wide variety of environments and applications. The DOM is designed to be used with any programming language. In order to provide a precise, language-independent specification of the DOM interfaces, we have chosen to define the specifications in Object Management Group (OMG) IDL [OMG IDL], as defined in the CORBA 2.3.1 specification [CORBA]. In addition to the OMG IDL specification, we provide language bindings for Java [Java] and ECMAScript [ECMAScript] (an industry-standard scripting language based on JavaScript [JavaScript] and JScript [JScript]).
  
  
  What the Document Object Model is not
  This section is designed to give a more precise understanding of the DOM by distinguishing it from other systems that may seem to be like it.
  
  
• The Document Object Model is not a binary specification. DOM programs written in the same language binding will be source code compatible across platforms, but the DOM does not define any form of binary interoperability.
• The Document Object Model is not a way of persisting objects to XML or HTML. Instead of specifying how objects may be represented in XML, the DOM specifies how XML and HTML documents are represented as objects, so that they may be used in object oriented programs.
• The Document Object Model is not a set of data structures; it is an object model that specifies interfaces. Although this document contains diagrams showing parent/child relationships, these are logical relationships defined by the programming interfaces, not representations of any particular internal data structures.
• The Document Object Model does not define what information in a document is relevant or how information in a document is structured. For XML, this is specified by the XML Information Set [XML Information set]. The DOM is simply an API to this information set.
• The Document Object Model, despite its name, is not a competitor to the Component Object Model [COM]. COM, like CORBA, is a language independent way to specify interfaces and objects; the DOM is a set of interfaces and objects designed for managing HTML and XML documents. The DOM may be implemented using language-independent systems like COM or CORBA; it may also be implemented using language-specific bindings like the Java or ECMAScript bindings specified in this document.
• 
  
  
  Where the Document Object Model came from
  The DOM originated as a specification to allow JavaScript scripts and Java programs to be portable among Web browsers. "Dynamic HTML" was the immediate ancestor of the Document Object Model, and it was originally thought of largely in terms of browsers. However, when the DOM Working Group was formed at W3C, it was also joined by vendors in other domains, including HTML or XML editors and document repositories. Several of these vendors had worked with SGML before XML was developed; as a result, the DOM has been influenced by SGML Groves and the HyTime standard. Some of these vendors had also developed their own object models for documents in order to provide an API for SGML/XML editors or document repositories, and these object models have also influenced the DOM.
  

• What is the Document Object Model?
  The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. This is an overview of DOM-related materials here at W3C and around the web.
  
  Why the Document Object Model?
  "Dynamic HTML" is a term used by some vendors to describe the combination of HTML, style sheets and scripts that allows documents to be animated. The W3C has received several submissions from members companies on the way in which the object model of HTML documents should be exposed to scripts. These submissions do not propose any new HTML tags or style sheet technology. The W3C DOM WG is working hard to make sure interoperable and scripting-language neutral solutions are agreed upon.
  

• What is the Document Object Model?
  Editors:
  Philippe Le Hégaret, W3C
  Lauren Wood, SoftQuad Software Inc. (for DOM Level 2)
  Jonathan Robie, Texcel (for DOM Level 1)
  
  Introduction
  The Document Object Model (DOM) is an application programming interface (API) for valid HTML and well-formed XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. In the DOM specification, the term "document" is used in the broad sense - increasingly, XML is being used as a way of representing many different kinds of information that may be stored in diverse systems, and much of this would traditionally be seen as data rather than as documents. Nevertheless, XML presents this data as documents, and the DOM may be used to manage this data.
  
  With the Document Object Model, programmers can build documents, navigate their structure, and add, modify, or delete elements and content. Anything found in an HTML or XML document can be accessed, changed, deleted, or added using the Document Object Model, with a few exceptions - in particular, the DOM interfaces for the XML internal and external subsets have not yet been specified.
  
  As a W3C specification, one important objective for the Document Object Model is to provide a standard programming interface that can be used in a wide variety of environments and applications. The DOM is designed to be used with any programming language. In order to provide a precise, language-independent specification of the DOM interfaces, we have chosen to define the specifications in Object Management Group (OMG) IDL [OMG IDL], as defined in the CORBA 2.3.1 specification [CORBA]. In addition to the OMG IDL specification, we provide language bindings for Java [Java] and ECMAScript [ECMAScript] (an industry-standard scripting language based on JavaScript [JavaScript] and JScript [JScript]).
  
  
  What the Document Object Model is not
  This section is designed to give a more precise understanding of the DOM by distinguishing it from other systems that may seem to be like it.
  
  
• The Document Object Model is not a binary specification. DOM programs written in the same language binding will be source code compatible across platforms, but the DOM does not define any form of binary interoperability.
• The Document Object Model is not a way of persisting objects to XML or HTML. Instead of specifying how objects may be represented in XML, the DOM specifies how XML and HTML documents are represented as objects, so that they may be used in object oriented programs.
• The Document Object Model is not a set of data structures; it is an object model that specifies interfaces. Although this document contains diagrams showing parent/child relationships, these are logical relationships defined by the programming interfaces, not representations of any particular internal data structures.
• The Document Object Model does not define what information in a document is relevant or how information in a document is structured. For XML, this is specified by the XML Information Set [XML Information set]. The DOM is simply an API to this information set.
• The Document Object Model, despite its name, is not a competitor to the Component Object Model [COM]. COM, like CORBA, is a language independent way to specify interfaces and objects; the DOM is a set of interfaces and objects designed for managing HTML and XML documents. The DOM may be implemented using language-independent systems like COM or CORBA; it may also be implemented using language-specific bindings like the Java or ECMAScript bindings specified in this document.
• 
  
  
  Where the Document Object Model came from
  The DOM originated as a specification to allow JavaScript scripts and Java programs to be portable among Web browsers. "Dynamic HTML" was the immediate ancestor of the Document Object Model, and it was originally thought of largely in terms of browsers. However, when the DOM Working Group was formed at W3C, it was also joined by vendors in other domains, including HTML or XML editors and document repositories. Several of these vendors had worked with SGML before XML was developed; as a result, the DOM has been influenced by SGML Groves and the HyTime standard. Some of these vendors had also developed their own object models for documents in order to provide an API for SGML/XML editors or document repositories, and these object models have also influenced the DOM.
  

The Web is a shared information space; GET is its designated means of making a safe, side-effect free request for retrieving a represntation of a resource.

This isn't debatable; it's enshrined in the protocol --

9.1.1 Safe Methods

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".

15.2 Attacks Based On File and Path Names

Implementations of HTTP origin servers SHOULD be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators.

and by the W3C's Architectural Principles of the World Wide Web (in progress) --

Representation retrieval is safe: Agents do not incur obligations by retrieving a representation.

Reuters did nothing wrong, because it isn't the act of linking to an object that makes it available on the Web (and doing so is still, in most reasonable people's minds, protected; see the deep linking issue). Rather, it's the act of, well, making it available, by exposing an interface that understands GET and other HTTP methods as appropriate.

After all, a protocol is, in a very real sense, a contract. If they had wanted to make the resource available but restrict access to it, they could have used HTTP authentication or even cookie authentication; in either case, they have control over who gets an authentication token. GETing a URI is not illegally obtaining access, because a URI in the request-line is an identifier, nothing else.

It's very likely that the publishers were using software that they didn't understand fully, and that is poorly designed, by making assumptions about the nature of the Web and how resources on it are accessed (i.e., "people only use browsers to navigate the Web").

The Web is a shared information space; GET is its designated means of making a safe, side-effect free request for retrieving a represntation of a resource.

This isn't debatable; it's enshrined in the protocol --

9.1.1 Safe Methods

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".

15.2 Attacks Based On File and Path Names

Implementations of HTTP origin servers SHOULD be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators.

and by the W3C's Architectural Principles of the World Wide Web (in progress) --

Representation retrieval is safe: Agents do not incur obligations by retrieving a representation.

Reuters did nothing wrong, because it isn't the act of linking to an object that makes it available on the Web (and doing so is still, in most reasonable people's minds, protected; see the deep linking issue). Rather, it's the act of, well, making it available, by exposing an interface that understands GET and other HTTP methods as appropriate.

After all, a protocol is, in a very real sense, a contract. If they had wanted to make the resource available but restrict access to it, they could have used HTTP authentication or even cookie authentication; in either case, they have control over who gets an authentication token. GETing a URI is not illegally obtaining access, because a URI in the request-line is an identifier, nothing else.

It's very likely that the publishers were using software that they didn't understand fully, and that is poorly designed, by making assumptions about the nature of the Web and how resources on it are accessed (i.e., "people only use browsers to navigate the Web").

Oh, that's right, you only have to design for IE now. Silly me, I forgot that all the other browsers are dead. That, or maybe, they all render DHTML exactly the same now? (HAHAHA)

(Well, maybe Lynx is dead, it's web page seems to be down...)

figure out if any DHTML techniques have become standards.

DHTML means manipulation of the HTML DOM through ECMAScript. The HTML DOM is a W3C Recommendation, and ECMAScript is a European international standard.

15.1.3 Encoding Sensitive Information in URI's Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From information. Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead

It can handle multiple codecs simultaneously, doing real-time mixing of sources and maintaining synchronization defined at the application layer (thus making it capable of supporting SMIL). That narrows the field significantly.

Rob Lanphier
Helix Community Coordinator

Things will only change if you actually do something about it. I *always* complain if I have the time, I will mail the webmaster and point out that there is an HTML standard, point them at a dodgy validation of their site via validator.w3.org, and point out that they lose money, one way or another.

So get off your ass, knock up a form letter, keep it handy, and complain!

The future is partly in your hands.

A lot standard exist; whether they are useful depends on the platform you are targeting and/or the architecture of your product. You've shared nothing about either, so I'll just point you at some general standards that you may find helpful, or as sample design patterns that may bring you closer to your goal. Check out the OSD specification at the Web Consortium's main site. An XML-based software description language, it's raison d'etre is electronic delivery of software. I know Microsoft used the format at one point, and I know of at least one other company that architected their product to use the OSD language for software installation as well. An alternative to the OSD model is Sun's Java Web Start, tailored to automatic installation of software for the Java platform. If you still need to roll your own, may I suggest that you consider the package format used in the Debian GNU/Linux distribution as a good design pattern to follow? Because the format exposes extensive amounts of meta-data in each package, a complete array of tools exist to automatically resolve, download, and install dependencies--one of the major benefits of using Debian as a Linux platform. Finally, if you are a member of the ACM, their online Digital Library will no doubt have extensive information, as would the IEEE online resources (again, membership required). A free resource similar to those of the ACM and IEEE that I often find helpful is Citeseer. Hope some of those help!

"the XSLT spec is largely a MS invention."

How do you figure that? The first XSLT draft lists only one MS employee as a contributor and neither of the two editors work for MS - one's Jim Clark, don't think he ever worked for MS, the other, Stephen Deach was working for Adobe.

There is already a msxml.dll file in windows... It is used by Internet Explorer to parse xslt documents in a non-standard way, driving me nuts ...and forcing me (again) to program websites for two (sometimes three) platforms instead of one.

"Just look at an HTML file exported form Word2k. I would not call that compatible with any HTML I've ever learned"

The trick is, does it validate to W3C specs? Last time I checked, though it was a disaster to look at, it did indeed validate.

I frequently receive Word and Excel documents that need to be presented on the web. Generally I leave them as-is, storing them in a document management system and just serving metadata via the web, but on occasion I do a conversion. Though the HTML output from Word 2k is ugly, it is machine readable (for parsing and cleaning) and perfectly compliant.

The Australian government has legislation (Disability Discrimination Act 1992) and guidelines in place regarding accessibility for websites. A list of policies is available at Website Accessibility - Australia.

In Bruce Lindsay Maguire v Sydney Organising Committee for the Olympic Games (SOCOG), the Human Rights And Equal Opportunity Commission found for the complainant, Bruce Lindsay Maguire, and ordered the SOCOG to modify the website. Of particular interest is the quote "In Ms Treviranus' view, if accessibility had been considered by the respondent when the site was being developed it could have been totally achieved in less than 1 percent of the time consumed in the site's development". Further details on the case are available.

Sometime you have to put extra text within tables that seeing person does not need, however to make the screen reader make sense you need this extra text.

Yes, write valid HTML and use alt properties that are meaningful. Even better, use the right tag for the job. Don't use tables for layout. Use CSS, which has been a W3C recommendation since 1996. Mark up the content according to it's purpose (striving for a more semantic web). Support web standards, including standards-compliant browsers.

Sometime you have to put extra text within tables that seeing person does not need, however to make the screen reader make sense you need this extra text.

Yes, write valid HTML and use alt properties that are meaningful. Even better, use the right tag for the job. Don't use tables for layout. Use CSS, which has been a W3C recommendation since 1996. Mark up the content according to it's purpose (striving for a more semantic web). Support web standards, including standards-compliant browsers.

Plum Voice Portals uses Linux for their VoiceXML IVR platform. As far as I know they are one of the few companies that use linux for VoiceXML telephony systems.

Granted, but what about images?

I'm not sure what your point is. It would be easy to have XML describing the images, something like:

<Image>
<Source>images/tux.jpg</Source>
<Description>Linux Mascot</Description>
</Image>

So one of the transforms takes the description and generates an ALT tag for it.

Alternatively, binary images can be stored in the SVG XML format, and then converted to JPG or other formats by Cocoon.

Plus, it doesn't solve the problem of having so many includes to make everything completely dynamic that it doesn't slow down.

It actually does a pretty good job at this, because it caches things once they've been dynamically generated.

what do you think would happen if the feds mandated a HTML-ADA spec???

Maybe it would look a lot like the guidelines, checklists and techniques specified by the World Wide Web Consortium that Tim Berners-Lee has been advocacting since he invented the web? Indeed, the same level of accesibility that HTML 1.0 was designed to promote?

HTML was designed specifically to separate content from presentation, so that a wide variety of display devices could be used to access the same information. When too many people started breaking the rules to get the right look, W3C introduced style sheets to allow formatting without breaking the data. Most web pages I view look just fine in w3m in an xterm, tables and all. Add a braille viewer, and you're doing well. Or, for the unwashed masses, I've heard that a braille display with IE works too.

what do you think would happen if the feds mandated a HTML-ADA spec???

Maybe it would look a lot like the guidelines, checklists and techniques specified by the World Wide Web Consortium that Tim Berners-Lee has been advocacting since he invented the web? Indeed, the same level of accesibility that HTML 1.0 was designed to promote?

HTML was designed specifically to separate content from presentation, so that a wide variety of display devices could be used to access the same information. When too many people started breaking the rules to get the right look, W3C introduced style sheets to allow formatting without breaking the data. Most web pages I view look just fine in w3m in an xterm, tables and all. Add a braille viewer, and you're doing well. Or, for the unwashed masses, I've heard that a braille display with IE works too.

what do you think would happen if the feds mandated a HTML-ADA spec???

Maybe it would look a lot like the guidelines, checklists and techniques specified by the World Wide Web Consortium that Tim Berners-Lee has been advocacting since he invented the web? Indeed, the same level of accesibility that HTML 1.0 was designed to promote?

HTML was designed specifically to separate content from presentation, so that a wide variety of display devices could be used to access the same information. When too many people started breaking the rules to get the right look, W3C introduced style sheets to allow formatting without breaking the data. Most web pages I view look just fine in w3m in an xterm, tables and all. Add a braille viewer, and you're doing well. Or, for the unwashed masses, I've heard that a braille display with IE works too.

what do you think would happen if the feds mandated a HTML-ADA spec???

Maybe it would look a lot like the guidelines, checklists and techniques specified by the World Wide Web Consortium that Tim Berners-Lee has been advocacting since he invented the web? Indeed, the same level of accesibility that HTML 1.0 was designed to promote?

HTML was designed specifically to separate content from presentation, so that a wide variety of display devices could be used to access the same information. When too many people started breaking the rules to get the right look, W3C introduced style sheets to allow formatting without breaking the data. Most web pages I view look just fine in w3m in an xterm, tables and all. Add a braille viewer, and you're doing well. Or, for the unwashed masses, I've heard that a braille display with IE works too.

Why would you have to maintain dual websites? The changes necessary to make your site accessible to the blind are generally such simple things as using ALT tags for images and make your HTML valid. In fact, the ALT tag has been required (i.e. NOT optional) since at least HTML 4.01.

So really, 90% of the work of making your web site accessible to the blind involves just doing what you should be doing anyway.

Disclaimer: I work for the state of New York at Cornell University and am/will be responsible for several sites that must, by either state, federal, or sponsor mandate, be accessible.

Disclaimer disclaimer: I haven't started yet. :P

I'm surprised that there's been no mention of this yet, but there already are government standards for web site accessibility. They are not enforceable standards (unless you're a govt. agency), but they are quite thorough, and from the research I've done, about 85% of it is simply common sense and good web design practice anyway, with only a few additional considerations. IBM also has an accessibility initiative, as does w3c. Maintaining dual sites is certainly not required, and unless you're the sort of designer that puts flash in everything, it shouldn't be an enormous stretch to conform with them. (But then, it shouldn't be an enormous stretch to conform with w3c HTML standards either. Shoulda coulda woulda.)

Some links:
http://www.section508.gov -- Federal accessibility initiative.

http://www.w3.org/TR/WAI-WEBCONTENT/ -- W3C Initiative

http://www-3.ibm.com/able/accessweb.html -- IBM Accessibility checklist

I suppose, in a perfect world, we wouldn't need the courts to tell us that we have to do things like this. I suspect that it is in most companies' best interests to have a site that everyone can use and from which everyone can make purchases. Even if the ADA lost, it's not exactly good press for your company when you have to go to court against them in the first place.

(I'm not saying that I disagree with the ruling; don't really have a qualified opinion on whether or not these standards should be law.)

What's wrong with this standard?

These proposals have been around since at least June 2001, when the W3C published their Requirements document for what was then called XML Blueberry and has since become XML 1.1.

And the complaints date from then as well... Elliote Rusty Harold complained almost as soon as the Requirements document and the first Working Draft were published. He makes a number of good points that highlight just how unnecessary XML 1.1 actually is. This link is actually him quoting himself for the time - the original post is probably available on the W3C forums, but I'm far too lazy to look.

There is no case to be made because there's no requirement that millions upgrade their browsers. The beauty of the various *ML standards is that you don't have to use 'em if they aren't important to you. For example, even though XHTML has superseded HTML4 as a stamdard. it hasn't obsoleted it. In fact, the XML 1.1 Candidate Recommendation page itself is still written in HTML 4.01, (although the W3C's homepage has been revised to XHTML.) And Slashdot gets by with still using HTML 3.2. Those people (e.g. Mongolians) who need to use XML 1.1 or to access it will find themselves upgrading sooner, the rest of us will eventually receive an upgrade along with the latest Security Update Of The Week.

There is no case to be made because there's no requirement that millions upgrade their browsers. The beauty of the various *ML standards is that you don't have to use 'em if they aren't important to you. For example, even though XHTML has superseded HTML4 as a stamdard. it hasn't obsoleted it. In fact, the XML 1.1 Candidate Recommendation page itself is still written in HTML 4.01, (although the W3C's homepage has been revised to XHTML.) And Slashdot gets by with still using HTML 3.2. Those people (e.g. Mongolians) who need to use XML 1.1 or to access it will find themselves upgrading sooner, the rest of us will eventually receive an upgrade along with the latest Security Update Of The Week.

how do i write links and italics and so on?

Normal HTML tags. The ones you may use are listed below the submit/preview buttons when you're writing your post. Most are on the format <XX> where XX is a combination of letters describing what you want. E.g. <b>bold</b> makes the text bold.
Have a look at some HTML Tutorial or check out w3's HTML pages.

how do i write links and italics and so on?

Normal HTML tags. The ones you may use are listed below the submit/preview buttons when you're writing your post. Most are on the format <XX> where XX is a combination of letters describing what you want. E.g. <b>bold</b> makes the text bold.
Have a look at some HTML Tutorial or check out w3's HTML pages.

how do i write links and italics and so on?

Normal HTML tags. The ones you may use are listed below the submit/preview buttons when you're writing your post. Most are on the format <XX> where XX is a combination of letters describing what you want. E.g. <b>bold</b> makes the text bold.
Have a look at some HTML Tutorial or check out w3's HTML pages.

Thanks for the tip, I was under the impression that <p></p> was also "The Right Way" in HTML 4. And reading the spec I get the impression that it was intended that way (end tag optional, cannot contain block-level elements). But you are absolutely right that only XHTML enforces this use of the tag.

I do think it makes a lot more sense the way XHTML has it. But that is also to be expected, since XHTML has had the chance to learn from the mistakes of the past.