OOXML, Microsoft’s new document format which I have written about here and here, appears to have failed to achieve the number of votes necessary for ISO standard fast-track approval. This means that additional review will be required before determining whether the OOXML specification should qualify as an ISO international standard.

While the vote is not yet final, it appears that the specification has already failed to receive the 2/3 majority vote it needed. Of the 41 participating countries, 13 have so far announced “no” votes and 5 have announced that they are abstaining. From the remaining votes, 16 of which are not yet publicly known, the highest possible “yes” count would be 23, although 24 are required for the 2/3 majority among the voting members.

After the results are final, the next step will be to address the comments left by the countries who voted “no, with comments”. After this process, those countries will have the ability to change their votes to “yes” if they believe their comments have been adequately addressed. So this standardization process is still far from over.

Update: The official vote is in, and OOXML fast-track received only 17 “yes” votes out of the 32 countries which cast votes (9 participating countries decided to abstain). This amounts to 53.125%, 5 votes short of the 2/3 majority needed for fast-track approval. Of those 17 “yes” votes, only 6 expressed full satisfaction with the OOXML specification.

In contrast, the OpenDocument Format (ODF, which OOXML was designed to rival) was approved by ISO last year with unanimous “yes” votes.

Of course, Microsoft is spinning the numbers as much as they can, but it seems the technical problems with the OOXML specification are gaining more and more attention due in large part to the scandals surrounding this voting process.

Microsoft and ECMA International will now have a chance to address the concerns that were raised about OOXML, and then the final vote will take place in the last week of February 2008.

Update: Google has issued an official response to the OOXML fast-track vote, strongly agreeing with the decision to not approve it. In the response, Google reiterates a number of the concerns with OOXML and expresses Google’s own positive experience implementing ODF support in its Google Docs service.

Microsoft is attempting to get the International Standards Organization to fast-track the approval of its Office Open XML (OOXML) document format which it developed to compete with the already-established OpenDocument Format (ODF) ISO standard. The Linux Foundation has recently made an official statement urging ISO members to vote “no” on fast-track approval, citing numerous implementation problems and allegations that Microsoft is attempting to use its wealth and business connections to hijack the standardization process.

I’ve written about these document formats before, and many of the technical issues with the 6,000-page OOXML specification have not yet been resolved. Several ISO members have raised concerns about these issues, but the United States, Germany, and Sweden voted to fast-track the approval process anyway.

However, critics have accused Microsoft of bribing ISO members to vote in Microsoft’s favor. Microsoft has admitted to sending e-mails to many of its partners saying that they are “expected” to vote in favor of fast-tracking OOXML, and that they would be rewarded with “market assistance” and “extra support in the form of Microsoft resources”. Many countries that have historically stayed out of the ISO standardization process have suddenly announced plans to vote on OOXML, and there is worry that this change was due to further misconduct by Microsoft, attempting to stack the vote.

The Linux Foundation is a group that develops standards to be used across Linux environments and submits them to international standards bodies like ISO for approval. The Linux Foundation is now worried that corruption will cause ISO to lose credibility in the industry and thus hinder the Linux Foundation’s mission.

The Linux Foundation also reviewed some of the open concerns about the technical merit of OOXML:

• The OOXML specification is extremely lengthy. Based upon all that we have been able to learn, the review period that has been allowed is insufficient to provide confidence that all issues that may need to be resolved before OOXML could meet minimum quality standards. Accordingly, the Linux Foundation believes that adoption of OOXML, after addressing only those issues that have been identified to date, would be unwise.

• That said, there have already been hundreds of issues that have been raised. While some of these issues are minor, many are not. The Linux Foundation believes that OOXML is simply not mature enough at this point to be granted approval as an ISO/IEC standard. Many, but not all, of these issues have been summarized here <http://www.noooxml.org/local–files/arguments/TheCaseAgai…>.

• ISO/IEC standards are supposed to reference other globally adopted standards where those standards exist. In the case of OOXML, many proprietary Microsoft specifications have been referenced. In some cases (e.g., language codes, vector graphics), Microsoft has used its own, internal codes and specifications rather than already existing, publicly available alternatives. This not only violates ISO/IEC rules, but also puts in question whether implementers can fully implement OOXML without infringing intellectual property rights (IPR) of Microsoft. Will those IPRs be available? If so, upon what terms will they be available? The answers to these questions appear to be currently unknown.

• OOXML is specific to Windows and other Microsoft products. It is uncertain whether OOXML-based documents will be easily created, saved, and opened using other operating systems - like Linux - and applications, with or without converters or translators. An international standard should be created in the first instance to be neutral to all operating systems and other products.

The group concludes:

For all these reasons and more, the Linux Foundation calls upon those National Bodies that have not yet cast their votes to vote “No, with comments.” Those comments should reflect their best, neutral, technical judgment, based upon OOXML in its current form. Only by doing so, we believe, can both the future availability of documents, but [sic] the integrity of the standard setting process be assured.

It should be noted that ISO is not considering replacing the OpenDocument standard with OOXML. If OOXML is approved, the two competing formats will exist side-by-side as separate ISO standards, with neither being officially favored.

Update: SiS, the group which represents Sweden in the International Standards Organization, has just announced that its own vote was invalid due to fraud. The vote has been retracted, and SiS has decided that it is too late in the process to issue a replacement vote. More information, including the official statement and a partial translation, is available at this Groklaw post.

Web applications have been all the buzz lately. Traditional desktop applications for e-mail, calendars, and basic word processing have begun losing favor to the online versions you can use in a web browser. Google has so far lead the pack in web application development, and they have recently released a tool which will help take web applications to the next level.

Web applications have several advantages over traditional desktop applications. The data is stored at a central remotely-accessible location, so you can access it from any computer. The application is run within a web browser, so it isn’t dependent on certain operating systems or versions. The “software” itself is typically hosted by the vendor, so security updates and other improvements can be seamlessly deployed by the vendor without any user action or user responsibility. Companies like Google have more safeguards in place to prevent data loss than most users do, in case of hardware failure, cracking attempts, etc. Web applications are usually built on top of the well-established HTML, CSS, and DOM standards which may allow for better accessibility and user control over the presentation.

But along with these benefits, there are also some shortcomings to web applications. The data isn’t in the user’s control, so it may be difficult to manually move data in or out of some web applications. Although desktop applications have equal or higher potential for violating your privacy than web applications, it’s possible for advanced users and tools to monitor and control what your desktop applications are sending across the Internet; with web applications, it’s out of your hands. Software updates are typically done at the vendor’s whim, so you often don’t have the opportunity to review or prevent certain updates. Also, web applications generally require an Internet connection in order to function; if you’re on the road and aren’t near a hotspot, you may be completely unable to access your data.

Google has released an open source browser add-on called Google Gears which will help to address that last shortcoming. Google Gears sets up a local database and API on your own computer which web applications can choose to use for offline storage and functionality.

This is similar to a proposed feature of the upcoming HTML 5 standard, due in 2010, which the developers of the Mozilla Firefox web browser plan to implement natively by the end of 2007. Unfortunately, Google Gears does not use the model proposed in the HTML 5 drafts, so there is currently an issue of two competing standards. This is unusual, since Google usually works closely with Mozilla on contributions like Firefox 2’s fraud protection and Firefox 3’s upcoming malware protection. Whether or not Firefox or any other browser will end up supporting Google Gears’ API natively (without an add-on) is up in the air, and will probably depend on how widely Google Gears gets implemented in web applications, but Mozilla Technology Strategist Mike Shaver said that Mozilla wasn’t about to simply give up on the work already done on supporting the HTML 5 model. It will be possible for a browser to support both models at the same time if the browser developers choose to implement them.

For now, the Google Gears model is the only one of the two currently available to regular users, and it is available as an add-on for the Firefox and Internet Explorer web browsers on Windows, as well as Firefox on Linux and Mac. A Safari version is planned in the future. Google Gears is currently used by Google Reader’s offline mode, and more web applications are expected to adopt it in the future.

Microsoft has begun sending out e-mails urging people to oppose an upcoming California state bill that would promote open interoperability with digital documents. The bill, named “California A.B. 1668 : Open Document Format, Open Source“, would require all state agencies to standardize on XML-based open document standards so that they may be accessible to a wider range of applications and operating systems. The bill also establishes a “procurement preference” for the OpenDocument format (ODF). Microsoft objects to this stated preference and asserts that Microsoft’s own Office Open XML format would be a better candidate.

Here is a basic run-down of both formats:

OpenDocument (formally “OASIS Open Document Format for Office Applications”) was created by the OASIS consortium in May 2005 and is considered the “original” multipurpose open XML document format. It is an ISO and IEC International Standard. Current implementations include the open source OpenOffice.org office suite (which aims to be a complete free replacement for Microsoft Office), StarOffice, Google Docs, AbiWord (an open source word processor), and KOffice (an open source office suite for Linux). Microsoft Office doesn’t yet support it by default, but Microsoft has sponsored an open source project called ODF-Converter which attempts to add support through a plugin. ODF-Converter 1.0 has already been released for Microsoft Word. OpenDocument support is also slated for the next versions of Corel’s WordPerfect and Apple’s TextEdit for the Mac.

Office Open XML is a format created by Microsoft in November 2005 and was made specifically to compete with OpenDocument. Basically, it is just designed more to Microsoft’s liking with consideration for how Microsoft Word works internally, but it is incompatible with OpenDocument. It was standardized by ECMA International and is currently implemented in Microsoft Office 2007 for Windows as the default format. It will be supported in a future version of OpenOffice.org through contributions from Novell, as well as the next versions of Corel’s WordPerfect and Apple’s TextEdit for the Mac. It is not yet supported in any Mac version of Microsoft Office, although support is planned for later this year.

In general, almost every product that has plans to support Office Open XML also plans to support OpenDocument, although the reverse is not true. Despite Microsoft’s claims in the e-mails, OpenDocument definitely has a lot more support than Office Open XML right now outside of Microsoft. Here are links to frequently updated lists of applications which support each document format:

• List of OpenDocument-supporting applications
• List of Office Open XML-supporting applications

It should be noted that although these formats are, at their core, XML formats, they are usually stored in a ZIP structure in order to package the text with any images and other relevant files, and to compress it to a smaller filesize. So to a computer program, these documents look like ZIP files which contain at least one XML file. What this means is that you can’t simply use an XML parser directly on one of these open document files; you have to pull it out of the ZIP first. Unlike Office Open XML, OpenDocument files may exist as a simple XML file, but it’s somewhat rare to find them like this in the wild. That said, ZIP is a pretty well-established standard and it usually isn’t too difficult to get the XML out of these formats. The fact that these documents are wrapped in a ZIP structure isn’t seen to conflict with the proposed bill.

There have been concerns over whether or not Office Open XML is truly an open format. Sun Microsystems and Microsoft (who hold intellectual property rights on OpenDocument and Office Open XML, respectively) have both made covenants not to enforce any relevant patent violations by implementors of their respective formats, but some legal experts believe that Microsoft’s wording doesn’t truly provide any protection from violations of Microsoft’s patents.

Furthermore, Office Open XML has often been referred to as a “Microsoft Office memory dump”, which implies that its design is very specific to how Microsoft Office works internally and isn’t as easily portable to other applications. For example, there are some formatting elements with no open explanation of their function beyond “auto-space like Word 95″ or “line-wrap like Word 6″. These clearly present a problem when other applications want to implement the format without knowing exactly what special algorithm Word 6 used to wrap lines.

My own personal opinion, like that of the proposed California bill, is that OpenDocument is clearly the preferred format for open interoperability among the widest variety of applications. The only problem is Microsoft’s reluctance to natively support it, but in the short time it has been around it has gathered a dominating amount of support elsewhere. The market will probably force Microsoft to support it natively in an upcoming version of Microsoft Office.

Here are some more relevant links:

• OASIS’ OpenDocument site
• Microsoft’s Office Open XML site
• OpenDocument information
• Office Open XML information
• Comparison of OpenDocument and Office Open XML formats
• Comparison of their respective licenses

The second annual CSS Naked Day is coming April 5. This is the day that many sites will intentionally remove their webpage’s stylesheets in an effort to draw attention to something called “semantic markup”.

Before CSS was widely used, most websites used HTML elements and attributes for visual stylistic purposes. <font> tags and nested tables were everywhere, and it made webpage source very difficult to read and maintain.

Once CSS started to obtain enough browser support, web standards experts began promoting the idea of “separation of content and presentation”, where all of the stylistic aspects of the page, such as fonts, colors, and visual layout, were moved to a separate modular CSS stylesheet. This offered many benefits, including significantly reducing bandwidth usage and dramatically improving maintainability of the site design and content.

Unfortunately, many web developers threw out the baby with the bathwater. While they stopped using the purely stylistic elements like <font>, many also stopped using meaningful elements like <p>, <ul>, and <table> where those elements were appropriate. Something known as “divitis” occurred: instead of using HTML elements that presented meaning, many web developers started using the mostly meaningless <div> and <span> elements for almost everything on the page.

The most useful and efficient way to write HTML is to use “semantic markup”. This is the idea of using HTML elements and attributes for what they mean, in order to maximize the understanding of your page by a search engine, accessibility agent, or other “intelligent” web applications. If you have a paragraph, you use a <p> element. If you have a list, you use a <ul> or <ol> element. If you have tabular data such as a spreadsheet, you use a <table> element. Those elements are then styled by a separate stylesheet like before, but the benefit is that a program can now understand the context of your content without needing to see the visual presentation offered by the stylesheet.

A web developer who is well-versed in web standards can often quickly judge the HTML quality of the site simply be turning off the stylesheet and seeing how it appears. In Firefox, you can disable the page’s stylesheet by going to the View menu, then Page Style, and then selecting No Style. (Internet Explorer doesn’t offer a way for the end user to do this.) If the page looks chopped up a bit but still seems to have side-by-side columns for the page sidebars, etc., then it’s probably using presentational markup (which it shouldn’t). If the entire page looks like a big heap of uniform text, no space between paragraphs, no lists, etc., then it’s probably suffering from divitis.

What it should look like (when using semantic markup) is something along the lines of a basic text document in Microsoft Word. The page should be black-on-white, main navigation links should be in simple bulleted lists, paragraphs should be spaced normally, headings should appear large and bold, lower-level headings should be smaller than higher-level headings, and so on. I should mention that just because a page looks like this doesn’t necessarily mean it was written correctly, but it’s usually a good quick indicator for most sites on the Web.

CSS Naked Day is the one day of the year when web developers of many sites will take down their stylesheets and hopefully show something that looks like the above description. It is an effort to bring awareness to semantic markup and the benefits it brings. It will mostly be smaller sites participating in this event, since mainstream websites don’t want to turn off their visitors for something that only interests web developers, but there are already over 1500 websites that have announced their participation at the moment I’m writing this.

It seems like every web development tool is trying to generate XHTML these days. Web design teachers tell their students that HTML is “out” and XHTML is “in”. But is XHTML really the best thing to use? You may be surprised to learn that there isn’t a single major web browser vendor who thinks it is a good idea to use XHTML on a public website, and a growing number of web standards experts agree.

Why? XHTML seems to work, doesn’t it? Actually, if you use XHTML on a public website, most web browsers will simply pretend that you’ve written regular HTML, and they’ll proceed to treat it as such. Internet Explorer, the most widely-used web browser today, doesn’t even support the correct handling of XHTML. And worse, if a program does want to treat the page as real XHTML, it will usually have major problems because of unnoticed differences in real XHTML.

Microsoft posted on its official Internet Explorer blog:

If we tried to support real XHTML in IE 7 we would have ended up using our existing HTML parser (which is focused on compatibility) and hacking in XML constructs. It is highly unlikely we could support XHTML well in this way

Mozilla (creators of Firefox) posted on its web developer FAQ:

If you are using the usual HTML features […] serving valid HTML 4.01 as text/html ensures the widest browser and search engine support.

The Safari development team posted on its official blog:

On today’s web, the best thing to do is to make your document HTML4 all the way. Full XHTML processing is not an option, so the best choice is to stick consistently with HTML4.

Håkon Wium Lie, the CTO of Opera and long-time member of the World Wide Web Consortium which standardized the XHTML language, stated in an interview:

I don’t think XHTML is a realistic option for the masses. HTML5 is it.

(HTML 5 is currently in development under the combined efforts of the World Wide Web Consortium and the Web Hypertext Application Technology Working Group.)

Anne van Kesteren, a web standards expert at Opera, stated in his blog:

I’m an advocate of using XHTML only in the correct way, which basically means you have to use HTML. Period.

Ian Hickson, former Opera employee who was hired over by Google and has served as an editor for World Wide Web Consortium specifications, wrote an article about correct usage of XHTML, concluding:

Authors intending their work for public consumption should stick to HTML 4.01

What do these browser vendors and web standards experts know that the rest of us missed? I explain the issues in the article Beware of XHTML.

HTML (HyperText Markup Language) is the fundamental computer language used to make webpages. It organizes and defines all of the elements of the document structure — such as headings, paragraphs, lists, tables, and links — to give computer-readable context to everything on the page.

Here is what a simple HTML document looks like:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
  <head>
    <title>My First Webpage</title>
  </head>
  <body>
    <p>This is a paragraph.</p>
  </body>
</html>

You’ll notice that a lot of things are surrounded by < and > characters. These are called “tags”. Tags are interpreted by the web browser as the start or end of an element. A “start tag” looks like <tagname> and an “end tag” looks like </tagname>. Everything in between is considered to be inside the element.

Not all elements have end tags. “img”, “input”, “link”, and “meta” are examples of elements that only consist of a start tag because they never have anything inside them. All of the elements I’ll discuss below will have end tags.

Start tags can also have things called “attributes”, like the “lang” attribute you see above in the “html” tag. Attributes tell special information about the element. In this case, it says that the HTML document is written in the English language.

At the top of the example HTML code, you’ll notice a weird sort of tag. Something that begins with a <! is called a “declaration”. Declarations don’t actually define elements, and they never have end tags. The “DOCTYPE” declaration tells the web browser what document language you’re using. In this case, we’re using the “strict” version of HTML 4.01, which is probably the one you should be using for best practices. Another common type of declaration is a comment declaration, which looks like <!-- This is a comment --> and is used to add notes that won’t be displayed on the page.

Let’s go back to the elements. After the DOCTYPE declaration, every HTML document must start with an “html” element. Inside that are always two sections: the head, and then the body. The body is where you’ll find all of the content you see on the page. The head is for additional information to describe the page, such as its title, references to “style sheets” that add the fancy colors and layout the page will use, and so on. But the only thing required in the head is the “title” element. The title text is what you’ll see at the very top of your browser window, the name of your site on a Google search result, etc.

In the body, you have a lot more types of elements available to you, but there are a few that you will be using frequently:

p:

This is a basic paragraph of text. Here is an example:

<p>The HTML language was invented by Tim Berners-Lee and
    was first published as an international standard in
    1993. The grammar of the HTML language was defined in a
    language called SGML, the Standard Generalized Markup
    Language.</p>

<p>XML is another common language whose grammar is defined
    in SGML. Unlike HTML, XML doesn't have its own
    standard set of elements and attributes. Instead,
    other languages are built on top of the XML
    grammar.</p>

The “p” element is used incorrectly on many websites. You should never simply put a <p> at the end of a paragraph, and you shouldn’t have extra <p> tags just for spacing purposes. Extra spacing can be done using style sheets, which you can learn about later. “p” tags should only be used to surround actual paragraphs.

h1, h2, h3, h4, h5, and h6:

These are headings for sections of the page. You can think of the heading structure like a document outline: the main points of the document should use h1, the first sub-level should use h2, and so on. For example:

<h1>City Zoo</h1>

<p>Welcome to the City Zoo! Here you'll find information
    about what to expect in the zoo.</p>

<h2>Animals</h2>

<p>Be on the lookout for the following animals.</p>

<h3>Elephant</h3>

<p>The world's African elephant population is estimated
    to be between 400,000 and 660,000.</p>

<h3>Ostrich</h3>

<p>Because ostriches don't have teeth, they will swallow
    stones that help grind the food in their stomachs.</p>

<h2>Plants</h2>

<p>Here are some exotic plants you may see.</p>

<h3>Banana tree</h3>

<p>Supermarket bananas are called Cavendish bananas and
don't exist naturally. Their existence is currently being
threatened by a variant of the Panama Disease which drove
the previous dominant species of banana to extinction in
the 1950s...</p>

You should never pick a heading element purely based on its font size. The font size of any element may be adjusted in a style sheet.

ul, ol, and li:

These are used for lists. “ul” tags surround an “unordered list”, and “ol” tags surround an “ordered list”. Ordered lists are numbered, while unordered lists simply use bullet points. “li” tags surround the items in the list. Here is an example (recipe from Wikibooks, licensed under GNU FDL):

<h1>Recipe for Oatmeal Stout Brownies</h1>

<h2>Ingredients</h2>

<ul>
  <li>1 cup all-purpose flour</li>
  <li>3/4 cup unsweetened cocoa powder (Dutch-
      processed preferred)</li>
  <li>1/4 teaspoon salt</li>
  <li>6 tablespoons unsalted room temperature
      butter, cut into cubes</li>
  <li>8 ounces dark bittersweet chocolate,
      chopped</li>
  <li>3/4 cup white chocolate chips</li>
  <li>4 large eggs, at room temperature</li>
  <li>1 cup granulated sugar</li>
  <li>1 1/4 cups (10 ounces) Oatmeal Stout beer
      (room temperature)</li>
  <li>1 cup semi-sweet chocolate chips</li>
  <li>1 package (8 ounces) cream cheese,
      softened</li>
  <li>1/3 cup granulated sugar</li>
  <li>1/2 teaspoon vanilla</li>
  <li>1 large egg</li>
</ul>

<h2>Procedure</h2>

<ol>
  <li>Preheat oven to 375°F (190°C).</li>
  <li>Line a 9 x 13-inch baking pan with non-stick foil
      (or grease and flour - or parchment paper; your
      call).</li>
  <li>In a medium bowl, whisk together flour, cocoa
      powder, and salt until evenly combined. Set
      aside.</li>
  <li>Melt butter, bittersweet chocolate, and white
      chocolate chips in a double boiler over very low
      heat, stirring constantly until melted. Remove from
      heat.</li>
  <li>In a large mixing bowl, beat eggs and sugar on high
      speed until light and fluffy, about 3 minutes. Add
      melted chocolate mixture, beating until
      combined.</li>
  <li>Beat reserved flour mixture into melted chocolate
      mixture. Whisk in stout beer. The batter will seem a
      bit thin. Drop semisweet chocolate chips evenly on
      top of batter (some will sink in).</li>
  <li>Pour into prepared baking pan.</li>
  <li>Beat cream cheese in medium bowl with electric
      mixer on medium speed until smooth. Gradually beat
      in sugar. Beat in vanilla and 1 egg just until
      blended.</li>
  <li>Pour cream cheese mixture over brownie batter in
      pan; cut through mixture with knife several times
      for marbled design.</li>
  <li>Bake 25 to 35 minutes on center rack in the oven,
      until a toothpick inserted in the center comes out
      almost clean.</li>
  <li>Let brownies cool, uncovered, to room temperature.
      Dust with confectioners' sugar before serving if
      desired.</li>
</ol>

As with other HTML elements, don’t worry too much about what these list elements look like. Looks can always be changed by style sheets. If you want to add something to your page like a navigation bar — something that is, in concept, a list even if you don’t want it displayed vertically with bullets — you should use a “ul” element and style it later. This is because lots of programs like search engines will actually better understand the page if you use elements for what they mean rather than how they look. In the web design biz, this is called “semantic markup”.

a:

The “a” element (short for “anchor”, for historical reasons) is used to create a link to somewhere else. It should always be used with an “href” (hypertext reference) attribute to tell where the link will go. Here is an example:

<p>For more information about web standards, visit the
    <a href="http://www.w3.org/">W3C site</a>.</p>

In the above example, the user will see the text “W3C site” (typically underlined and blue) which, when clicked, will take the person to http://www.w3.org/.

em and strong:

These give emphasis to a word or phrase. They have the same meaning, except “strong” is meant to indicate stronger emphasis. A typical web browser will display “em” text in italics and “strong” text in bold. If the web browser is configured to read the webpage aloud, “em” text will be spoken with emphasis and “strong” text will be spoken even louder. Here is an example:

<p>The em and strong elements provide <em>meaning</em> and
    <em>context</em>, unlike the i and b elements which
    only change <strong>visual appearance</strong>.

For a complete list of available elements in HTML, see the HTML element index. Elements listed with “L” or “F” in the “DTD” column are not allowed in the “strict” version of HTML we’re using. It’s considered bad practice to use them in any version.

If you want to try out some HTML code of your own, head on over to my webpage test service. Just type the HTML and click “Display” to see the result below.

HTML is not a free-for-all language. While some popular browsers will try to let you get away with errors, you should always be careful that you’re putting your tags in the right places and following the standard rule sets. Luckily, there is a simple free tool to help check that your documents don’t contain HTML errors: the HTML Validator. If you ever come to an HTML support forum for help, this tool is usually the first thing they’ll use. Making sure that your HTML is always valid helps reduce your risk of headaches in the future.

For more information about HTML, see the Wikipedia article on HTML and the Wikibook on learning HTML.

To look at any webpage’s HTML code, right-click somewhere on the page and click “View Source” or “View Page Source”. Keep in mind that there tends to be more poorly-written HTML code on the Web than well-written HTML code, so don’t rely entirely on example.

There is another language called XHTML, based on HTML, which has been used more and more lately. You should avoid XHTML. At this point in time, you must have truly expert knowledge in web standards in order to use XHTML correctly, and then there are major compatibility problems if you do. As a result, almost every XHTML page on the Web has serious overlooked problems that have all but destroyed XHTML’s original goal on the Web. For technical information about the problems with XHTML, see Beware of XHTML.

Feed-based website syndication has become popular in recent years, but there is still a lot of people who haven’t learned about it and the benefits it brings.

Website syndication is a way to read about all of the recent news articles, blog posts, and website updates that interest you all in one place. In a single view, you can read headlines and summaries of articles on all of your favorite news sites and keep up-to-date without having to browse through all of those sites one-by-one every day. It streamlines your reading experience.

To get started with website syndication, you need to get something called a feed reader. Two popular ones are Google Reader and Bloglines. Most of the newest web browsers even have simple feed reading capabilities built-in. For the purposes of this post, I will assume you are starting out with Google Reader.

Once you have your feed reader, you need to look for feeds on your favorite websites. Feeds usually come in either the “RSS” or “Atom” variety. The difference between the two is negligible for most typical subscribers.

Many websites that offer feeds will provide some link on the page itself. You may see a plain text “RSS” or “Atom” link like in the sidebar of this blog; you may see an orange or blue “RSS”, “Atom”, or “XML” button (in this case, XML is just another term for either RSS or Atom); or you may see the standard orange feed icon shown at the top of this article. If you find one of these links, make note of its URL — the web address you see at the bottom of the browser window when you hover your mouse over the link. You can copy it to your clipboard by right-clicking the link and clicking “Copy Shortcut” or “Copy Link Location”.

When you have a feed URL, add it to your feed reader. In Google Reader, this is done by clicking the “Add subscription” button on the left side of the Google Reader screen, then typing or pasting the URL into the box that comes up, and finally clicking the “Add” button.

If you’re using the Firefox web browser, it can help you out with the above process: When you come across a page that offers a feed, an orange feed icon will appear on the right side of your URL bar. Click on the icon. It’ll either bring you to a new page or simply display a small list of available feeds, in which case just choose one. You’ll now be on a page with the text “Subscribe to this page using” and a dropdown list. From that list, pick Google Reader and click “Subscribe Now”. Finally, on the next page click “Add to Google Reader”. You’re now subscribed to the feed.

Once you have subscribed to a feed, your feed reader will automatically check for updates every few minutes. Feeds with updates will be indicated in the left column. You’ll read the feeds much like you read e-mails. Feel free to play around in the feed reader; once you get used to it, it will increase your productivity and make reading your daily news that much more relaxing.

If you just want to subscribe to the Tech Center Current blog for now, here’s a quick button to hurry you along:

The Firefox web browser has just added APNG support to its development versions, meaning it will appear in a future release. APNG is an animated version of the popular PNG image format, solving one of PNG’s main shortcomings to the GIF format. APNG was designed to replace MNG, a different animated PNG format that never took off because its design was seen to be unnecessarily complex. The APNG specification hasn’t yet been finalized, but is expected to be once the PNG group approves a minor change.

Firefox is currently the only major web browser to support APNG. However, applications that support regular PNG have no problem loading the first frame of an APNG file, so there’s little risk in using it today with that in mind.

PNG is a World Wide Web Consortium open standard and has good support in all major browsers except Internet Explorer, which has a few noteworthy bugs: Internet Explorer 6 and below don’t support partial transparency; and Internet Explorer 7 and below don’t correctly support gamma correction, meaning that many PNG images will appear somewhat darker or lighter than they should. Nevertheless, PNG has largely replaced GIF on the Web due to its better compression, fuller color depth, and additional features.

Here are some relevant links:

• APNG Specification
• Firefox APNG development tracking
• PNG Specification

SGML, the Standard Generalized Markup Language, is perhaps the most commonly used document language in existence. It is a metalanguage, meaning it is used to define other sub-languages. Two of the most well-known languages defined by SGML are HTML and XML.

All SGML-based languages have certain things in common:

• They are written using “tags” to define “elements”. Those elements make up the document structure, and elements may exist inside other elements.
• Elements may have “attributes” to provide meta data for the elements. For example, if there is an element for indicating quotations, the element may have an attribute to indicate where the quotation came from.
• The documents must reference something called a Document Type Definition (DTD), usually by using a special “DOCTYPE” declaration at the top of the page. The DTD describes which elements exist in the language, where they may be placed, and what attributes they have.

The first differentiating factor between separate SGML-based languages comes from something called an SGML declaration. The SGML declaration defines which shorthand rules apply in the sub-language, which characters are used to surround tags and other constructs, and various other information that’s important for parsers. You’ll usually never see the SGML declaration in an actual document; it’s usually defined in the document language specification and the SGML parser has the common SGML declarations built in.

In case you want to take a look, here are HTML’s SGML declaration and XML’s SGML declaration, both of which inherit the default SGML declaration values.

HTML and XML are both fairly similar to the default SGML declaration, which is called the “concrete reference syntax”. The following are true in both languages:

• Tags are delimited using “<” and “>” and closed with “</” .
• Character references are delimited using “&” and “;” .
• Attribute values are associated with attribute names by using the “=” character, and the same quotation characters are used around attribute values.
• Declarations begin with “<!” .

But the two languages also have some significant differences:

• Most of HTML’s shorthand rules aren’t available in XML. (It should be noted that most major browsers today only support a few of HTML’s shorthand rules anyway.)
• HTML DTDs may define certain elements as allowing omitted end tags (meaning, for example, the “<p>” tag doesn’t have to have a pairing “</p>” ). If an element is also defined as “EMPTY”, meaning no contents are allowed, the end tag is forbidden (for example, “<br>” is not allowed to have a “</br>” ). However, in XML, start and end tags may never be omitted.
• HTML’s poorly-supported “null end tag” (NET) shorthand construct is written like “<p/This is a paragraph/” , or “<br/” when the end tag is forbidden. XML’s well-supported NET construct is written like “<p/This is a paragraph>” except it is never allowed to have contents when you use it, so it’s actually “<p/>” . Since end tags are never forbidden in XML, you never just have “<br/” ; it’s “<br/>” instead.
• Element and attribute names are case-insensitive in HTML, meaning “<p>” and “<P>” are the same thing. In XML, they are case-sensitive, so you have to use the same capitalization that’s defined in the DTD.
• In HTML, attribute values that begin with a letter and only contain combinations of letters, numbers, “-” , “_” , “:” , and “.” are allowed to be written without quotation marks. In XML, all attribute values must be quoted.
• XML has additional parsing restrictions and the concept of “well-formedness” (explained later).

Another major difference is that, unlike with HTML, there’s no DTD called “XML”. HTML has “HTML Strict”, “HTML Transitional”, and “HTML Frameset” DTDs which share most of the same basic elements, and people usually just call these sets of elements “HTML”. However, XML doesn’t provide any set of elements “out of the box”. XML provides the parsing rules, but other languages are built on top of it. For example, MathML, OpenDocument, OpenSearch, RDF, RSS, SOAP, SVG, and XHTML are all XML languages with their own specific DTDs.

The benefit of XML is that it makes it easier to write parsers. Instead of having to support the full wealth of features SGML offers (which no major web browser even attempts to do), an XML parser only has to support a tiny subset of it in order to parse all of these different XML-based languages. Aside from the SGML rules, XML also has an additional set of restrictions for a document to be “well-formed”. For example, a well-formed XML document isn’t allowed to have a custom SGML declaration in the document itself, it has extra limitations on which constructs may exist where, and certain characters like “<” are simply not allowed as normal text no matter what characters are around it (you can use the character reference “<” instead). This ensures that the document is written in a very predictable way and parsers don’t have to worry about lots of special exception rules everywhere. In order to make sure that documents stay well-formed, an XML parser isn’t supposed to be forgiving of any well-formedness error. If it comes upon any malformed content, it simply quits trying to load the document right then and there.

XHTML was designed to be an XML version of HTML (basically, the HTML elements and attributes using XML document rules). Unfortunately, XHTML has mostly failed to achieve its goal on the Web. Internet Explorer — currently the most widely-used web browser by a large majority — has never actually supported XHTML. Instead, it can only handle XHTML as if it were incorrectly-written HTML, meaning there is no well-formedness checking and a lot of constructs are handled incorrectly. To make matters worse, the World Wide Web Consortium (W3C) who developed XHTML declared that it was okay for websites to send XHTML documents to the browser using the “text/html” content type HTTP header. This HTTP header tells the browser how it should handle the document. In this case, it tells browsers to handle the page not as XHTML, but as regular HTML. So even browsers that correctly support XHTML won’t handle it as such. Because suddenly nothing is checking these pages for well-formedness and correct XML parsing anymore, most webpage authors using XHTML fail to realize that the documents they’re writing can’t even be parsed as XML. This is precisely what the well-formedness rules were designed to prevent. So the idea of a Web standardized on a uniform easy-to-parse document language has now become a distant dream. In response, the W3C has decided to go back to developing HTML again, and a major new version of HTML is currently planned for 2010.