On X-UA-Compatible

This decision seems to have stricken a chord on many a harp. I for one think Microsoft have considered the options, and chosen the only viable one where they can actually move onwards with implementing standards.

The main priority in releasing a browser is that it renders the majority of the web. The majority of the web today has either a quirks mode or a standards mode triggering doctype - about half of the top sites use standards mode. These standards mode sites generally rely on Mozilla, Safari and Opera to all render them to the best of their standards compliancy. However, they at the same time rely on Internet Explorer to render them the way IE6 and/or IE7 render them. They rely on the HTML parsing, CSS and DOM to behave like it does in IE6/7. They rely on bugs or sometimes a lack of features in IE6/7. In other words, Microsoft can’t fix some bugs or implement new features in Standards Mode because too much live content would break if they did. Also, none of these sites that rely on the bugs and lack of implementation of features have some specific code opting out of getting the newest and best standards support, so if Microsoft makes improvements in standards support, these sites must not be affected.

Microsoft had the choices of either having some opt-in to improved standards support, or not improving standards at all. An opt-out wasn’t an option, because live content isn’t using that opt-out. Now, every angry and disappointed web developer out there, if you look at it that way, which one would you prefer? Standards with an opt-in or no standards at all? Sure, there’s Jeremy’s argument that “Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.”. I’d argue that this was the only solution that was acceptable for Microsoft, and the reason for that is not that Microsoft is trying to make web developer’s lives harder or anything. The reason for that is that most of the live content is coded for Internet Explorer to behave like IE7 does. Do you have any idea how much breakage the web would take if IE8, say, fixed the implementation of getElementById in it’s default mode? Or how much breakage of the web would happen if they fixed their events model to match the W3C DOM2Events spec?

Having to opt-in to the best rendering mode of IE8 is a cheap cost for web developers. And even that opt-in can be eliminated in a few ways. For example, you won’t be locked down to the IE7 handling of your document if you use the HTML5 doctype. Whether that means the HTML5 doctype will be treated as IE-edge or IE8, that remains to be seen, but I’m just saying: this is not a bad choice by Microsoft.

On X-UA-Compatible

This decision seems to have stricken a chord on many a harp. I for one think Microsoft have considered the options, and chosen the only viable one where they can actually move onwards with implementing standards.

The main priority in releasing a browser is that it renders the majority of the web. The majority of the web today has either a quirks mode or a standards mode triggering doctype - about half of the top sites use standards mode. These standards mode sites generally rely on Mozilla, Safari and Opera to all render them to the best of their standards compliancy. However, they at the same time rely on Internet Explorer to render them the way IE6 and/or IE7 render them. They rely on the HTML parsing, CSS and DOM to behave like it does in IE6/7. They rely on bugs or sometimes a lack of features in IE6/7. In other words, Microsoft can’t fix some bugs or implement new features in Standards Mode because too much live content would break if they did. Also, none of these sites that rely on the bugs and lack of implementation of features have some specific code opting out of getting the newest and best standards support, so if Microsoft makes improvements in standards support, these sites must not be affected.

Microsoft had the choices of either having some opt-in to improved standards support, or not improving standards at all. An opt-out wasn’t an option, because live content isn’t using that opt-out. Now, every angry and disappointed web developer out there, if you look at it that way, which one would you prefer? Standards with an opt-in or no standards at all? Sure, there’s Jeremy’s argument that “Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.”. I’d argue that this was the only solution that was acceptable for Microsoft, and the reason for that is not that Microsoft is trying to make web developer’s lives harder or anything. The reason for that is that most of the live content is coded for Internet Explorer to behave like IE7 does. Do you have any idea how much breakage the web would take if IE8, say, fixed the implementation of getElementById in it’s default mode? Or how much breakage of the web would happen if they fixed their events model to match the W3C DOM2Events spec?

Having to opt-in to the best rendering mode of IE8 is a cheap cost for web developers. And even that opt-in can be eliminated in a few ways. For example, you won’t be locked down to the IE7 handling of your document if you use the HTML5 doctype. Whether that means the HTML5 doctype will be treated as IE-edge or IE8, that remains to be seen, but I’m just saying: this is not a bad choice by Microsoft.

On X-UA-Compatible

This decision seems to have stricken a chord on many a harp. I for one think Microsoft have considered the options, and chosen the only viable one where they can actually move onwards with implementing standards.

The main priority in releasing a browser is that it renders the majority of the web. The majority of the web today has either a quirks mode or a standards mode triggering doctype - about half of the top sites use standards mode. These standards mode sites generally rely on Mozilla, Safari and Opera to all render them to the best of their standards compliancy. However, they at the same time rely on Internet Explorer to render them the way IE6 and/or IE7 render them. They rely on the HTML parsing, CSS and DOM to behave like it does in IE6/7. They rely on bugs or sometimes a lack of features in IE6/7. In other words, Microsoft can’t fix some bugs or implement new features in Standards Mode because too much live content would break if they did. Also, none of these sites that rely on the bugs and lack of implementation of features have some specific code opting out of getting the newest and best standards support, so if Microsoft makes improvements in standards support, these sites must not be affected.

Microsoft had the choices of either having some opt-in to improved standards support, or not improving standards at all. An opt-out wasn’t an option, because live content isn’t using that opt-out. Now, every angry and disappointed web developer out there, if you look at it that way, which one would you prefer? Standards with an opt-in or no standards at all? Sure, there’s Jeremy’s argument that “Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.”. I’d argue that this was the only solution that was acceptable for Microsoft, and the reason for that is not that Microsoft is trying to make web developer’s lives harder or anything. The reason for that is that most of the live content is coded for Internet Explorer to behave like IE7 does. Do you have any idea how much breakage the web would take if IE8, say, fixed the implementation of getElementById in it’s default mode? Or how much breakage of the web would happen if they fixed their events model to match the W3C DOM2Events spec?

Having to opt-in to the best rendering mode of IE8 is a cheap cost for web developers. And even that opt-in can be eliminated in a few ways. For example, you won’t be locked down to the IE7 handling of your document if you use the HTML5 doctype. Whether that means the HTML5 doctype will be treated as IE-edge or IE8, that remains to be seen, but I’m just saying: this is not a bad choice by Microsoft.

On X-UA-Compatible

This decision seems to have stricken a chord on many a harp. I for one think Microsoft have considered the options, and chosen the only viable one where they can actually move onwards with implementing standards.

The main priority in releasing a browser is that it renders the majority of the web. The majority of the web today has either a quirks mode or a standards mode triggering doctype - about half of the top sites use standards mode. These standards mode sites generally rely on Mozilla, Safari and Opera to all render them to the best of their standards compliancy. However, they at the same time rely on Internet Explorer to render them the way IE6 and/or IE7 render them. They rely on the HTML parsing, CSS and DOM to behave like it does in IE6/7. They rely on bugs or sometimes a lack of features in IE6/7. In other words, Microsoft can’t fix some bugs or implement new features in Standards Mode because too much live content would break if they did. Also, none of these sites that rely on the bugs and lack of implementation of features have some specific code opting out of getting the newest and best standards support, so if Microsoft makes improvements in standards support, these sites must not be affected.

Microsoft had the choices of either having some opt-in to improved standards support, or not improving standards at all. An opt-out wasn’t an option, because live content isn’t using that opt-out. Now, every angry and disappointed web developer out there, if you look at it that way, which one would you prefer? Standards with an opt-in or no standards at all? Sure, there’s Jeremy’s argument that “Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.”. I’d argue that this was the only solution that was acceptable for Microsoft, and the reason for that is not that Microsoft is trying to make web developer’s lives harder or anything. The reason for that is that most of the live content is coded for Internet Explorer to behave like IE7 does. Do you have any idea how much breakage the web would take if IE8, say, fixed the implementation of getElementById in it’s default mode? Or how much breakage of the web would happen if they fixed their events model to match the W3C DOM2Events spec?

Having to opt-in to the best rendering mode of IE8 is a cheap cost for web developers. And even that opt-in can be eliminated in a few ways. For example, you won’t be locked down to the IE7 handling of your document if you use the HTML5 doctype. Whether that means the HTML5 doctype will be treated as IE-edge or IE8, that remains to be seen, but I’m just saying: this is not a bad choice by Microsoft.

On X-UA-Compatible

This decision seems to have stricken a chord on many a harp. I for one think Microsoft have considered the options, and chosen the only viable one where they can actually move onwards with implementing standards.

The main priority in releasing a browser is that it renders the majority of the web. The majority of the web today has either a quirks mode or a standards mode triggering doctype - about half of the top sites use standards mode. These standards mode sites generally rely on Mozilla, Safari and Opera to all render them to the best of their standards compliancy. However, they at the same time rely on Internet Explorer to render them the way IE6 and/or IE7 render them. They rely on the HTML parsing, CSS and DOM to behave like it does in IE6/7. They rely on bugs or sometimes a lack of features in IE6/7. In other words, Microsoft can’t fix some bugs or implement new features in Standards Mode because too much live content would break if they did. Also, none of these sites that rely on the bugs and lack of implementation of features have some specific code opting out of getting the newest and best standards support, so if Microsoft makes improvements in standards support, these sites must not be affected.

Microsoft had the choices of either having some opt-in to improved standards support, or not improving standards at all. An opt-out wasn’t an option, because live content isn’t using that opt-out. Now, every angry and disappointed web developer out there, if you look at it that way, which one would you prefer? Standards with an opt-in or no standards at all? Sure, there’s Jeremy’s argument that “Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.”. I’d argue that this was the only solution that was acceptable for Microsoft, and the reason for that is not that Microsoft is trying to make web developer’s lives harder or anything. The reason for that is that most of the live content is coded for Internet Explorer to behave like IE7 does. Do you have any idea how much breakage the web would take if IE8, say, fixed the implementation of getElementById in it’s default mode? Or how much breakage of the web would happen if they fixed their events model to match the W3C DOM2Events spec?

Having to opt-in to the best rendering mode of IE8 is a cheap cost for web developers. And even that opt-in can be eliminated in a few ways. For example, you won’t be locked down to the IE7 handling of your document if you use the HTML5 doctype. Whether that means the HTML5 doctype will be treated as IE-edge or IE8, that remains to be seen, but I’m just saying: this is not a bad choice by Microsoft.

On X-UA-Compatible

This decision seems to have stricken a chord on many a harp. I for one think Microsoft have considered the options, and chosen the only viable one where they can actually move onwards with implementing standards.

The main priority in releasing a browser is that it renders the majority of the web. The majority of the web today has either a quirks mode or a standards mode triggering doctype - about half of the top sites use standards mode. These standards mode sites generally rely on Mozilla, Safari and Opera to all render them to the best of their standards compliancy. However, they at the same time rely on Internet Explorer to render them the way IE6 and/or IE7 render them. They rely on the HTML parsing, CSS and DOM to behave like it does in IE6/7. They rely on bugs or sometimes a lack of features in IE6/7. In other words, Microsoft can’t fix some bugs or implement new features in Standards Mode because too much live content would break if they did. Also, none of these sites that rely on the bugs and lack of implementation of features have some specific code opting out of getting the newest and best standards support, so if Microsoft makes improvements in standards support, these sites must not be affected.

Microsoft had the choices of either having some opt-in to improved standards support, or not improving standards at all. An opt-out wasn’t an option, because live content isn’t using that opt-out. Now, every angry and disappointed web developer out there, if you look at it that way, which one would you prefer? Standards with an opt-in or no standards at all? Sure, there’s Jeremy’s argument that “Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.”. I’d argue that this was the only solution that was acceptable for Microsoft, and the reason for that is not that Microsoft is trying to make web developer’s lives harder or anything. The reason for that is that most of the live content is coded for Internet Explorer to behave like IE7 does. Do you have any idea how much breakage the web would take if IE8, say, fixed the implementation of getElementById in it’s default mode? Or how much breakage of the web would happen if they fixed their events model to match the W3C DOM2Events spec?

Having to opt-in to the best rendering mode of IE8 is a cheap cost for web developers. And even that opt-in can be eliminated in a few ways. For example, you won’t be locked down to the IE7 handling of your document if you use the HTML5 doctype. Whether that means the HTML5 doctype will be treated as IE-edge or IE8, that remains to be seen, but I’m just saying: this is not a bad choice by Microsoft.

On X-UA-Compatible

This decision seems to have stricken a chord on many a harp. I for one think Microsoft have considered the options, and chosen the only viable one where they can actually move onwards with implementing standards.

The main priority in releasing a browser is that it renders the majority of the web. The majority of the web today has either a quirks mode or a standards mode triggering doctype - about half of the top sites use standards mode. These standards mode sites generally rely on Mozilla, Safari and Opera to all render them to the best of their standards compliancy. However, they at the same time rely on Internet Explorer to render them the way IE6 and/or IE7 render them. They rely on the HTML parsing, CSS and DOM to behave like it does in IE6/7. They rely on bugs or sometimes a lack of features in IE6/7. In other words, Microsoft can’t fix some bugs or implement new features in Standards Mode because too much live content would break if they did. Also, none of these sites that rely on the bugs and lack of implementation of features have some specific code opting out of getting the newest and best standards support, so if Microsoft makes improvements in standards support, these sites must not be affected.

Microsoft had the choices of either having some opt-in to improved standards support, or not improving standards at all. An opt-out wasn’t an option, because live content isn’t using that opt-out. Now, every angry and disappointed web developer out there, if you look at it that way, which one would you prefer? Standards with an opt-in or no standards at all? Sure, there’s Jeremy’s argument that “Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.”. I’d argue that this was the only solution that was acceptable for Microsoft, and the reason for that is not that Microsoft is trying to make web developer’s lives harder or anything. The reason for that is that most of the live content is coded for Internet Explorer to behave like IE7 does. Do you have any idea how much breakage the web would take if IE8, say, fixed the implementation of getElementById in it’s default mode? Or how much breakage of the web would happen if they fixed their events model to match the W3C DOM2Events spec?

Having to opt-in to the best rendering mode of IE8 is a cheap cost for web developers. And even that opt-in can be eliminated in a few ways. For example, you won’t be locked down to the IE7 handling of your document if you use the HTML5 doctype. Whether that means the HTML5 doctype will be treated as IE-edge or IE8, that remains to be seen, but I’m just saying: this is not a bad choice by Microsoft.

Progress in the W3C

This news should be a boon to you: The W3C HTML WG has finally published first working drafts of the HTML5 - A vocabulary and associated APIs for HTML and XHTML specification and an accompanying HTML 5 differences from HTML 4 document. Here’s your first glimpse at what the successors to XHTML 1 and HTML 4 may look like.

I just want to make something very clear that I apparently failed to make clear in my HTML5, XHTML2, and the Future of the Web article, judging from the comments I got. HTML5 is a specification that does four main things:

• HTML5 defines a vocabulary; being a set of element names, attribute names, allowed attribute values, and allowed content models; and defined semantics for that vocabulary.


• HTML5 defines the DOM which that vocabulary is to parse into.


• HTML5 defines two serialisations for that vocabulary: one XML serialisation that is intended to eventually succeed the XHTML1 specification; and one custom non-SGML HTML serialisation, intended to eventually succeed the HTML4.01 specification.


• Since the HTML serialisation of HTML5 is not an SGML or XML format, HTML5 describes this new serialisation in detail.

I’m saying this to emphasise that HTML5 is not in any way, shape or form the death of XHTML, nor is it intended to “kill off” XHTML. In fact, the next version of XHTML is going to be the XML serialisation of HTML5. The reason the HTML5 spec spends so much more time explaining the HTML format than the XML format is that the XML format is already adequately explained by the XML specification, while the HTML format is not explained anywhere else, and thus has to be explained in it’s entirety in the HTML5 specification.

Digression about the “XHTML” name

There is however the question of the “XHTML” name. One of the main goals of HTML5 is to be compatible with current content today (be that valid HTML and XHTML or invalid tagsoup). That means that the XML serialisation of HTML5 must use the XHTML1.0 namespace of “http://www.w3.org/1999/xhtml”. HTML5 cannot make any changes to the semantics within that namespace if those changes would break live content. It can, however, add semantics to that namespace.

So, to my argument: HTML5 will update and replace the vocabulary of HTML4.01. There are two serialisations of the HTML4.01 vocabulary: The SGML serialisation of HTML4.01 and the XML serialisation of XHTML1.0 and associated “http://www.w3.org/1999/xhtml” namespace for attached semantics. XHTML1.0 is , to quote the subtitle of the specification, “A Reformulation of HTML 4 in XML 1.0″. This is a direct update, and it only comes to reason that the update keeps the name of the serialisations. Further, changing this namespace is NOT an option. This namespace is absolutely required for backwards compatibility.

Also do note that the namespace contains the “XHTML” name, so it would make even less sense to change the name to something else.

XHTML2 on the other hand doesn’t have any backwards compatibility requirements, and indeed does make incompatible changes to the semantics of XHTML. It’s also, unlike the XML serialisation of HTML5, not a reformulation of HTML to XML, but a whole new language. The XHTML2 specification using another namespace than that of XHTML1.0 was not a problem the first three years and using the XHTML1.0 namespace is as far as I can see purely detrimental for adoption of XHTML2 since it makes it impossible for user agents to both support current XHTML1.0 content and new XHTML2.0 content. If you were a browser maker, and had the option to either support an old standard with much live content which also happens to correspond semantically with another format you need to support (HTML) or a new standard with very little content whatsoever, and with no choice in between, which choice would you take? I fail to see how the XHTML2 WG can even be conceived to have more right to the “XHTML” name than the XML serialisation of HTML5. If anything, they should be the ones changing the name to something other than “XHTML”, not the HTML WG.

Progress in the W3C

This news should be a boon to you: The W3C HTML WG has finally published first working drafts of the HTML5 - A vocabulary and associated APIs for HTML and XHTML specification and an accompanying HTML 5 differences from HTML 4 document. Here’s your first glimpse at what the successors to XHTML 1 and HTML 4 may look like.

I just want to make something very clear that I apparently failed to make clear in my HTML5, XHTML2, and the Future of the Web article, judging from the comments I got. HTML5 is a specification that does four main things:

• HTML5 defines a vocabulary; being a set of element names, attribute names, allowed attribute values, and allowed content models; and defined semantics for that vocabulary.


• HTML5 defines the DOM which that vocabulary is to parse into.


• HTML5 defines two serialisations for that vocabulary: one XML serialisation that is intended to eventually succeed the XHTML1 specification; and one custom non-SGML HTML serialisation, intended to eventually succeed the HTML4.01 specification.


• Since the HTML serialisation of HTML5 is not an SGML or XML format, HTML5 describes this new serialisation in detail.

I’m saying this to emphasise that HTML5 is not in any way, shape or form the death of XHTML, nor is it intended to “kill off” XHTML. In fact, the next version of XHTML is going to be the XML serialisation of HTML5. The reason the HTML5 spec spends so much more time explaining the HTML format than the XML format is that the XML format is already adequately explained by the XML specification, while the HTML format is not explained anywhere else, and thus has to be explained in it’s entirety in the HTML5 specification.

Digression about the “XHTML” name

There is however the question of the “XHTML” name. One of the main goals of HTML5 is to be compatible with current content today (be that valid HTML and XHTML or invalid tagsoup). That means that the XML serialisation of HTML5 must use the XHTML1.0 namespace of “http://www.w3.org/1999/xhtml”. HTML5 cannot make any changes to the semantics within that namespace if those changes would break live content. It can, however, add semantics to that namespace.

So, to my argument: HTML5 will update and replace the vocabulary of HTML4.01. There are two serialisations of the HTML4.01 vocabulary: The SGML serialisation of HTML4.01 and the XML serialisation of XHTML1.0 and associated “http://www.w3.org/1999/xhtml” namespace for attached semantics. XHTML1.0 is , to quote the subtitle of the specification, “A Reformulation of HTML 4 in XML 1.0″. This is a direct update, and it only comes to reason that the update keeps the name of the serialisations. Further, changing this namespace is NOT an option. This namespace is absolutely required for backwards compatibility.

Also do note that the namespace contains the “XHTML” name, so it would make even less sense to change the name to something else.

XHTML2 on the other hand doesn’t have any backwards compatibility requirements, and indeed does make incompatible changes to the semantics of XHTML. It’s also, unlike the XML serialisation of HTML5, not a reformulation of HTML to XML, but a whole new language. The XHTML2 specification using another namespace than that of XHTML1.0 was not a problem the first three years and using the XHTML1.0 namespace is as far as I can see purely detrimental for adoption of XHTML2 since it makes it impossible for user agents to both support current XHTML1.0 content and new XHTML2.0 content. If you were a browser maker, and had the option to either support an old standard with much live content which also happens to correspond semantically with another format you need to support (HTML) or a new standard with very little content whatsoever, and with no choice in between, which choice would you take? I fail to see how the XHTML2 WG can even be conceived to have more right to the “XHTML” name than the XML serialisation of HTML5. If anything, they should be the ones changing the name to something other than “XHTML”, not the HTML WG.

Progress in the W3C

This news should be a boon to you: The W3C HTML WG has finally published first working drafts of the HTML5 - A vocabulary and associated APIs for HTML and XHTML specification and an accompanying HTML 5 differences from HTML 4 document. Here’s your first glimpse at what the successors to XHTML 1 and HTML 4 may look like.

I just want to make something very clear that I apparently failed to make clear in my HTML5, XHTML2, and the Future of the Web article, judging from the comments I got. HTML5 is a specification that does four main things:

• HTML5 defines a vocabulary; being a set of element names, attribute names, allowed attribute values, and allowed content models; and defined semantics for that vocabulary.


• HTML5 defines the DOM which that vocabulary is to parse into.


• HTML5 defines two serialisations for that vocabulary: one XML serialisation that is intended to eventually succeed the XHTML1 specification; and one custom non-SGML HTML serialisation, intended to eventually succeed the HTML4.01 specification.


• Since the HTML serialisation of HTML5 is not an SGML or XML format, HTML5 describes this new serialisation in detail.

I’m saying this to emphasise that HTML5 is not in any way, shape or form the death of XHTML, nor is it intended to “kill off” XHTML. In fact, the next version of XHTML is going to be the XML serialisation of HTML5. The reason the HTML5 spec spends so much more time explaining the HTML format than the XML format is that the XML format is already adequately explained by the XML specification, while the HTML format is not explained anywhere else, and thus has to be explained in it’s entirety in the HTML5 specification.

Digression about the “XHTML” name

There is however the question of the “XHTML” name. One of the main goals of HTML5 is to be compatible with current content today (be that valid HTML and XHTML or invalid tagsoup). That means that the XML serialisation of HTML5 must use the XHTML1.0 namespace of “http://www.w3.org/1999/xhtml”. HTML5 cannot make any changes to the semantics within that namespace if those changes would break live content. It can, however, add semantics to that namespace.

So, to my argument: HTML5 will update and replace the vocabulary of HTML4.01. There are two serialisations of the HTML4.01 vocabulary: The SGML serialisation of HTML4.01 and the XML serialisation of XHTML1.0 and associated “http://www.w3.org/1999/xhtml” namespace for attached semantics. XHTML1.0 is , to quote the subtitle of the specification, “A Reformulation of HTML 4 in XML 1.0″. This is a direct update, and it only comes to reason that the update keeps the name of the serialisations. Further, changing this namespace is NOT an option. This namespace is absolutely required for backwards compatibility.

Also do note that the namespace contains the “XHTML” name, so it would make even less sense to change the name to something else.

XHTML2 on the other hand doesn’t have any backwards compatibility requirements, and indeed does make incompatible changes to the semantics of XHTML. It’s also, unlike the XML serialisation of HTML5, not a reformulation of HTML to XML, but a whole new language. The XHTML2 specification using another namespace than that of XHTML1.0 was not a problem the first three years and using the XHTML1.0 namespace is as far as I can see purely detrimental for adoption of XHTML2 since it makes it impossible for user agents to both support current XHTML1.0 content and new XHTML2.0 content. If you were a browser maker, and had the option to either support an old standard with much live content which also happens to correspond semantically with another format you need to support (HTML) or a new standard with very little content whatsoever, and with no choice in between, which choice would you take? I fail to see how the XHTML2 WG can even be conceived to have more right to the “XHTML” name than the XML serialisation of HTML5. If anything, they should be the ones changing the name to something other than “XHTML”, not the HTML WG.

Progress in the W3C

This news should be a boon to you: The W3C HTML WG has finally published first working drafts of the HTML5 - A vocabulary and associated APIs for HTML and XHTML specification and an accompanying HTML 5 differences from HTML 4 document. Here’s your first glimpse at what the successors to XHTML 1 and HTML 4 may look like.

I just want to make something very clear that I apparently failed to make clear in my HTML5, XHTML2, and the Future of the Web article, judging from the comments I got. HTML5 is a specification that does four main things:

• HTML5 defines a vocabulary; being a set of element names, attribute names, allowed attribute values, and allowed content models; and defined semantics for that vocabulary.


• HTML5 defines the DOM which that vocabulary is to parse into.


• HTML5 defines two serialisations for that vocabulary: one XML serialisation that is intended to eventually succeed the XHTML1 specification; and one custom non-SGML HTML serialisation, intended to eventually succeed the HTML4.01 specification.


• Since the HTML serialisation of HTML5 is not an SGML or XML format, HTML5 describes this new serialisation in detail.

I’m saying this to emphasise that HTML5 is not in any way, shape or form the death of XHTML, nor is it intended to “kill off” XHTML. In fact, the next version of XHTML is going to be the XML serialisation of HTML5. The reason the HTML5 spec spends so much more time explaining the HTML format than the XML format is that the XML format is already adequately explained by the XML specification, while the HTML format is not explained anywhere else, and thus has to be explained in it’s entirety in the HTML5 specification.

Digression about the “XHTML” name

There is however the question of the “XHTML” name. One of the main goals of HTML5 is to be compatible with current content today (be that valid HTML and XHTML or invalid tagsoup). That means that the XML serialisation of HTML5 must use the XHTML1.0 namespace of “http://www.w3.org/1999/xhtml”. HTML5 cannot make any changes to the semantics within that namespace if those changes would break live content. It can, however, add semantics to that namespace.

So, to my argument: HTML5 will update and replace the vocabulary of HTML4.01. There are two serialisations of the HTML4.01 vocabulary: The SGML serialisation of HTML4.01 and the XML serialisation of XHTML1.0 and associated “http://www.w3.org/1999/xhtml” namespace for attached semantics. XHTML1.0 is , to quote the subtitle of the specification, “A Reformulation of HTML 4 in XML 1.0″. This is a direct update, and it only comes to reason that the update keeps the name of the serialisations. Further, changing this namespace is NOT an option. This namespace is absolutely required for backwards compatibility.

Also do note that the namespace contains the “XHTML” name, so it would make even less sense to change the name to something else.

XHTML2 on the other hand doesn’t have any backwards compatibility requirements, and indeed does make incompatible changes to the semantics of XHTML. It’s also, unlike the XML serialisation of HTML5, not a reformulation of HTML to XML, but a whole new language. The XHTML2 specification using another namespace than that of XHTML1.0 was not a problem the first three years and using the XHTML1.0 namespace is as far as I can see purely detrimental for adoption of XHTML2 since it makes it impossible for user agents to both support current XHTML1.0 content and new XHTML2.0 content. If you were a browser maker, and had the option to either support an old standard with much live content which also happens to correspond semantically with another format you need to support (HTML) or a new standard with very little content whatsoever, and with no choice in between, which choice would you take? I fail to see how the XHTML2 WG can even be conceived to have more right to the “XHTML” name than the XML serialisation of HTML5. If anything, they should be the ones changing the name to something other than “XHTML”, not the HTML WG.

Progress in the W3C

This news should be a boon to you: The W3C HTML WG has finally published first working drafts of the HTML5 - A vocabulary and associated APIs for HTML and XHTML specification and an accompanying HTML 5 differences from HTML 4 document. Here’s your first glimpse at what the successors to XHTML 1 and HTML 4 may look like.

I just want to make something very clear that I apparently failed to make clear in my HTML5, XHTML2, and the Future of the Web article, judging from the comments I got. HTML5 is a specification that does four main things:

• HTML5 defines a vocabulary; being a set of element names, attribute names, allowed attribute values, and allowed content models; and defined semantics for that vocabulary.


• HTML5 defines the DOM which that vocabulary is to parse into.


• HTML5 defines two serialisations for that vocabulary: one XML serialisation that is intended to eventually succeed the XHTML1 specification; and one custom non-SGML HTML serialisation, intended to eventually succeed the HTML4.01 specification.


• Since the HTML serialisation of HTML5 is not an SGML or XML format, HTML5 describes this new serialisation in detail.

I’m saying this to emphasise that HTML5 is not in any way, shape or form the death of XHTML, nor is it intended to “kill off” XHTML. In fact, the next version of XHTML is going to be the XML serialisation of HTML5. The reason the HTML5 spec spends so much more time explaining the HTML format than the XML format is that the XML format is already adequately explained by the XML specification, while the HTML format is not explained anywhere else, and thus has to be explained in it’s entirety in the HTML5 specification.

Digression about the “XHTML” name

There is however the question of the “XHTML” name. One of the main goals of HTML5 is to be compatible with current content today (be that valid HTML and XHTML or invalid tagsoup). That means that the XML serialisation of HTML5 must use the XHTML1.0 namespace of “http://www.w3.org/1999/xhtml”. HTML5 cannot make any changes to the semantics within that namespace if those changes would break live content. It can, however, add semantics to that namespace.

So, to my argument: HTML5 will update and replace the vocabulary of HTML4.01. There are two serialisations of the HTML4.01 vocabulary: The SGML serialisation of HTML4.01 and the XML serialisation of XHTML1.0 and associated “http://www.w3.org/1999/xhtml” namespace for attached semantics. XHTML1.0 is , to quote the subtitle of the specification, “A Reformulation of HTML 4 in XML 1.0″. This is a direct update, and it only comes to reason that the update keeps the name of the serialisations. Further, changing this namespace is NOT an option. This namespace is absolutely required for backwards compatibility.

Also do note that the namespace contains the “XHTML” name, so it would make even less sense to change the name to something else.

XHTML2 on the other hand doesn’t have any backwards compatibility requirements, and indeed does make incompatible changes to the semantics of XHTML. It’s also, unlike the XML serialisation of HTML5, not a reformulation of HTML to XML, but a whole new language. The XHTML2 specification using another namespace than that of XHTML1.0 was not a problem the first three years and using the XHTML1.0 namespace is as far as I can see purely detrimental for adoption of XHTML2 since it makes it impossible for user agents to both support current XHTML1.0 content and new XHTML2.0 content. If you were a browser maker, and had the option to either support an old standard with much live content which also happens to correspond semantically with another format you need to support (HTML) or a new standard with very little content whatsoever, and with no choice in between, which choice would you take? I fail to see how the XHTML2 WG can even be conceived to have more right to the “XHTML” name than the XML serialisation of HTML5. If anything, they should be the ones changing the name to something other than “XHTML”, not the HTML WG.

Progress in the W3C

This news should be a boon to you: The W3C HTML WG has finally published first working drafts of the HTML5 - A vocabulary and associated APIs for HTML and XHTML specification and an accompanying HTML 5 differences from HTML 4 document. Here’s your first glimpse at what the successors to XHTML 1 and HTML 4 may look like.

I just want to make something very clear that I apparently failed to make clear in my HTML5, XHTML2, and the Future of the Web article, judging from the comments I got. HTML5 is a specification that does four main things:

• HTML5 defines a vocabulary; being a set of element names, attribute names, allowed attribute values, and allowed content models; and defined semantics for that vocabulary.


• HTML5 defines the DOM which that vocabulary is to parse into.


• HTML5 defines two serialisations for that vocabulary: one XML serialisation that is intended to eventually succeed the XHTML1 specification; and one custom non-SGML HTML serialisation, intended to eventually succeed the HTML4.01 specification.


• Since the HTML serialisation of HTML5 is not an SGML or XML format, HTML5 describes this new serialisation in detail.

I’m saying this to emphasise that HTML5 is not in any way, shape or form the death of XHTML, nor is it intended to “kill off” XHTML. In fact, the next version of XHTML is going to be the XML serialisation of HTML5. The reason the HTML5 spec spends so much more time explaining the HTML format than the XML format is that the XML format is already adequately explained by the XML specification, while the HTML format is not explained anywhere else, and thus has to be explained in it’s entirety in the HTML5 specification.

Digression about the “XHTML” name

There is however the question of the “XHTML” name. One of the main goals of HTML5 is to be compatible with current content today (be that valid HTML and XHTML or invalid tagsoup). That means that the XML serialisation of HTML5 must use the XHTML1.0 namespace of “http://www.w3.org/1999/xhtml”. HTML5 cannot make any changes to the semantics within that namespace if those changes would break live content. It can, however, add semantics to that namespace.

So, to my argument: HTML5 will update and replace the vocabulary of HTML4.01. There are two serialisations of the HTML4.01 vocabulary: The SGML serialisation of HTML4.01 and the XML serialisation of XHTML1.0 and associated “http://www.w3.org/1999/xhtml” namespace for attached semantics. XHTML1.0 is , to quote the subtitle of the specification, “A Reformulation of HTML 4 in XML 1.0″. This is a direct update, and it only comes to reason that the update keeps the name of the serialisations. Further, changing this namespace is NOT an option. This namespace is absolutely required for backwards compatibility.

Also do note that the namespace contains the “XHTML” name, so it would make even less sense to change the name to something else.

XHTML2 on the other hand doesn’t have any backwards compatibility requirements, and indeed does make incompatible changes to the semantics of XHTML. It’s also, unlike the XML serialisation of HTML5, not a reformulation of HTML to XML, but a whole new language. The XHTML2 specification using another namespace than that of XHTML1.0 was not a problem the first three years and using the XHTML1.0 namespace is as far as I can see purely detrimental for adoption of XHTML2 since it makes it impossible for user agents to both support current XHTML1.0 content and new XHTML2.0 content. If you were a browser maker, and had the option to either support an old standard with much live content which also happens to correspond semantically with another format you need to support (HTML) or a new standard with very little content whatsoever, and with no choice in between, which choice would you take? I fail to see how the XHTML2 WG can even be conceived to have more right to the “XHTML” name than the XML serialisation of HTML5. If anything, they should be the ones changing the name to something other than “XHTML”, not the HTML WG.

Progress in the W3C

This news should be a boon to you: The W3C HTML WG has finally published first working drafts of the HTML5 - A vocabulary and associated APIs for HTML and XHTML specification and an accompanying HTML 5 differences from HTML 4 document. Here’s your first glimpse at what the successors to XHTML 1 and HTML 4 may look like.

I just want to make something very clear that I apparently failed to make clear in my HTML5, XHTML2, and the Future of the Web article, judging from the comments I got. HTML5 is a specification that does four main things:

• HTML5 defines a vocabulary; being a set of element names, attribute names, allowed attribute values, and allowed content models; and defined semantics for that vocabulary.


• HTML5 defines the DOM which that vocabulary is to parse into.


• HTML5 defines two serialisations for that vocabulary: one XML serialisation that is intended to eventually succeed the XHTML1 specification; and one custom non-SGML HTML serialisation, intended to eventually succeed the HTML4.01 specification.


• Since the HTML serialisation of HTML5 is not an SGML or XML format, HTML5 describes this new serialisation in detail.

I’m saying this to emphasise that HTML5 is not in any way, shape or form the death of XHTML, nor is it intended to “kill off” XHTML. In fact, the next version of XHTML is going to be the XML serialisation of HTML5. The reason the HTML5 spec spends so much more time explaining the HTML format than the XML format is that the XML format is already adequately explained by the XML specification, while the HTML format is not explained anywhere else, and thus has to be explained in it’s entirety in the HTML5 specification.

Digression about the “XHTML” name

There is however the question of the “XHTML” name. One of the main goals of HTML5 is to be compatible with current content today (be that valid HTML and XHTML or invalid tagsoup). That means that the XML serialisation of HTML5 must use the XHTML1.0 namespace of “http://www.w3.org/1999/xhtml”. HTML5 cannot make any changes to the semantics within that namespace if those changes would break live content. It can, however, add semantics to that namespace.

So, to my argument: HTML5 will update and replace the vocabulary of HTML4.01. There are two serialisations of the HTML4.01 vocabulary: The SGML serialisation of HTML4.01 and the XML serialisation of XHTML1.0 and associated “http://www.w3.org/1999/xhtml” namespace for attached semantics. XHTML1.0 is , to quote the subtitle of the specification, “A Reformulation of HTML 4 in XML 1.0″. This is a direct update, and it only comes to reason that the update keeps the name of the serialisations. Further, changing this namespace is NOT an option. This namespace is absolutely required for backwards compatibility.

Also do note that the namespace contains the “XHTML” name, so it would make even less sense to change the name to something else.

XHTML2 on the other hand doesn’t have any backwards compatibility requirements, and indeed does make incompatible changes to the semantics of XHTML. It’s also, unlike the XML serialisation of HTML5, not a reformulation of HTML to XML, but a whole new language. The XHTML2 specification using another namespace than that of XHTML1.0 was not a problem the first three years and using the XHTML1.0 namespace is as far as I can see purely detrimental for adoption of XHTML2 since it makes it impossible for user agents to both support current XHTML1.0 content and new XHTML2.0 content. If you were a browser maker, and had the option to either support an old standard with much live content which also happens to correspond semantically with another format you need to support (HTML) or a new standard with very little content whatsoever, and with no choice in between, which choice would you take? I fail to see how the XHTML2 WG can even be conceived to have more right to the “XHTML” name than the XML serialisation of HTML5. If anything, they should be the ones changing the name to something other than “XHTML”, not the HTML WG.

Deconstructed WP admin theme

WordPress has been a helpful tool. Love it, hate it - it’s free, flexible and approachable by average joe web developers who don’t really write programs (me). There’s much about it I don’t love, but I use it often. One thing that bothers me each time I install it: the default admin theme. I like the look of the WP-Tiger theme better, but it feels less responsive to me (probably because of client-side layout redrawing?). What I’ve really wanted is something super quick to install (a plugin-based theme), something responsive and based on the initial layout, but much cleaner/simpler.

So I’ve made a new admin theme (wp-admin-nate.zip 8K), like WP, it’s free to use and repurpose. All I’ve done here is stripped out the hideous teal color, made all the fonts sans-serif, eliminated the tab-styling and excessive bordering/shadows. The navigation is still tab based, but uses a simple yellow-highlighter approach instead.

You’ll see how simple it is when you crack it open - feel free to modify and post alternate versions in the comments to this page. The upload interface is not modified - that interface is run through an iframe, and is harder (if even possible) to target with CSS only modifications.

To install it, just throw the unzipped folder into your plugins directory (wp-content/plugins/) then activate it in the admin tool. It’ll show up as “Nate’s Admin Style”, but you can rename it by editing the wp-admin-nate.php file.

Unfortunately I can’t offer support for this admin theme, but please feel free to leave comments, post updated versions, etc in the comments to this post.

Deconstructed WP admin theme

WordPress has been a helpful tool. Love it, hate it - it’s free, flexible and approachable by average joe web developers who don’t really write programs (me). There’s much about it I don’t love, but I use it often. One thing that bothers me each time I install it: the default admin theme. I like the look of the WP-Tiger theme better, but it feels less responsive to me (probably because of client-side layout redrawing?). What I’ve really wanted is something super quick to install (a plugin-based theme), something responsive and based on the initial layout, but much cleaner/simpler.

So I’ve made a new admin theme (wp-admin-nate.zip 8K), like WP, it’s free to use and repurpose. All I’ve done here is stripped out the hideous teal color, made all the fonts sans-serif, eliminated the tab-styling and excessive bordering/shadows. The navigation is still tab based, but uses a simple yellow-highlighter approach instead.

You’ll see how simple it is when you crack it open - feel free to modify and post alternate versions in the comments to this page. The upload interface is not modified - that interface is run through an iframe, and is harder (if even possible) to target with CSS only modifications.

To install it, just throw the unzipped folder into your plugins directory (wp-content/plugins/) then activate it in the admin tool. It’ll show up as “Nate’s Admin Style”, but you can rename it by editing the wp-admin-nate.php file.

Unfortunately I can’t offer support for this admin theme, but please feel free to leave comments, post updated versions, etc in the comments to this post.

Deconstructed WP admin theme

WordPress has been a helpful tool. Love it, hate it - it’s free, flexible and approachable by average joe web developers who don’t really write programs (me). There’s much about it I don’t love, but I use it often. One thing that bothers me each time I install it: the default admin theme. I like the look of the WP-Tiger theme better, but it feels less responsive to me (probably because of client-side layout redrawing?). What I’ve really wanted is something super quick to install (a plugin-based theme), something responsive and based on the initial layout, but much cleaner/simpler.

So I’ve made a new admin theme (wp-admin-nate.zip 8K), like WP, it’s free to use and repurpose. All I’ve done here is stripped out the hideous teal color, made all the fonts sans-serif, eliminated the tab-styling and excessive bordering/shadows. The navigation is still tab based, but uses a simple yellow-highlighter approach instead.

You’ll see how simple it is when you crack it open - feel free to modify and post alternate versions in the comments to this page. The upload interface is not modified - that interface is run through an iframe, and is harder (if even possible) to target with CSS only modifications.

To install it, just throw the unzipped folder into your plugins directory (wp-content/plugins/) then activate it in the admin tool. It’ll show up as “Nate’s Admin Style”, but you can rename it by editing the wp-admin-nate.php file.

Unfortunately I can’t offer support for this admin theme, but please feel free to leave comments, post updated versions, etc in the comments to this post.

Deconstructed WP admin theme

WordPress has been a helpful tool. Love it, hate it - it’s free, flexible and approachable by average joe web developers who don’t really write programs (me). There’s much about it I don’t love, but I use it often. One thing that bothers me each time I install it: the default admin theme. I like the look of the WP-Tiger theme better, but it feels less responsive to me (probably because of client-side layout redrawing?). What I’ve really wanted is something super quick to install (a plugin-based theme), something responsive and based on the initial layout, but much cleaner/simpler.

So I’ve made a new admin theme (wp-admin-nate.zip 8K), like WP, it’s free to use and repurpose. All I’ve done here is stripped out the hideous teal color, made all the fonts sans-serif, eliminated the tab-styling and excessive bordering/shadows. The navigation is still tab based, but uses a simple yellow-highlighter approach instead.

You’ll see how simple it is when you crack it open - feel free to modify and post alternate versions in the comments to this page. The upload interface is not modified - that interface is run through an iframe, and is harder (if even possible) to target with CSS only modifications.

To install it, just throw the unzipped folder into your plugins directory (wp-content/plugins/) then activate it in the admin tool. It’ll show up as “Nate’s Admin Style”, but you can rename it by editing the wp-admin-nate.php file.

Unfortunately I can’t offer support for this admin theme, but please feel free to leave comments, post updated versions, etc in the comments to this post.

Deconstructed WP admin theme

WordPress has been a helpful tool. Love it, hate it - it’s free, flexible and approachable by average joe web developers who don’t really write programs (me). There’s much about it I don’t love, but I use it often. One thing that bothers me each time I install it: the default admin theme. I like the look of the WP-Tiger theme better, but it feels less responsive to me (probably because of client-side layout redrawing?). What I’ve really wanted is something super quick to install (a plugin-based theme), something responsive and based on the initial layout, but much cleaner/simpler.

So I’ve made a new admin theme (wp-admin-nate.zip 8K), like WP, it’s free to use and repurpose. All I’ve done here is stripped out the hideous teal color, made all the fonts sans-serif, eliminated the tab-styling and excessive bordering/shadows. The navigation is still tab based, but uses a simple yellow-highlighter approach instead.

You’ll see how simple it is when you crack it open - feel free to modify and post alternate versions in the comments to this page. The upload interface is not modified - that interface is run through an iframe, and is harder (if even possible) to target with CSS only modifications.

To install it, just throw the unzipped folder into your plugins directory (wp-content/plugins/) then activate it in the admin tool. It’ll show up as “Nate’s Admin Style”, but you can rename it by editing the wp-admin-nate.php file.

Unfortunately I can’t offer support for this admin theme, but please feel free to leave comments, post updated versions, etc in the comments to this post.

Deconstructed WP admin theme

WordPress has been a helpful tool. Love it, hate it - it’s free, flexible and approachable by average joe web developers who don’t really write programs (me). There’s much about it I don’t love, but I use it often. One thing that bothers me each time I install it: the default admin theme. I like the look of the WP-Tiger theme better, but it feels less responsive to me (probably because of client-side layout redrawing?). What I’ve really wanted is something super quick to install (a plugin-based theme), something responsive and based on the initial layout, but much cleaner/simpler.

So I’ve made a new admin theme (wp-admin-nate.zip 8K), like WP, it’s free to use and repurpose. All I’ve done here is stripped out the hideous teal color, made all the fonts sans-serif, eliminated the tab-styling and excessive bordering/shadows. The navigation is still tab based, but uses a simple yellow-highlighter approach instead.

You’ll see how simple it is when you crack it open - feel free to modify and post alternate versions in the comments to this page. The upload interface is not modified - that interface is run through an iframe, and is harder (if even possible) to target with CSS only modifications.

To install it, just throw the unzipped folder into your plugins directory (wp-content/plugins/) then activate it in the admin tool. It’ll show up as “Nate’s Admin Style”, but you can rename it by editing the wp-admin-nate.php file.

Unfortunately I can’t offer support for this admin theme, but please feel free to leave comments, post updated versions, etc in the comments to this post.

Deconstructed WP admin theme

WordPress has been a helpful tool. Love it, hate it - it’s free, flexible and approachable by average joe web developers who don’t really write programs (me). There’s much about it I don’t love, but I use it often. One thing that bothers me each time I install it: the default admin theme. I like the look of the WP-Tiger theme better, but it feels less responsive to me (probably because of client-side layout redrawing?). What I’ve really wanted is something super quick to install (a plugin-based theme), something responsive and based on the initial layout, but much cleaner/simpler.

So I’ve made a new admin theme (wp-admin-nate.zip 8K), like WP, it’s free to use and repurpose. All I’ve done here is stripped out the hideous teal color, made all the fonts sans-serif, eliminated the tab-styling and excessive bordering/shadows. The navigation is still tab based, but uses a simple yellow-highlighter approach instead.

You’ll see how simple it is when you crack it open - feel free to modify and post alternate versions in the comments to this page. The upload interface is not modified - that interface is run through an iframe, and is harder (if even possible) to target with CSS only modifications.

To install it, just throw the unzipped folder into your plugins directory (wp-content/plugins/) then activate it in the admin tool. It’ll show up as “Nate’s Admin Style”, but you can rename it by editing the wp-admin-nate.php file.

Unfortunately I can’t offer support for this admin theme, but please feel free to leave comments, post updated versions, etc in the comments to this post.