The WHATWG has a blog! As written in the initial post:
The aim of this blog is to keep the public informed about the development of (X)HTML 5, the WHATWG, and related topics, and get feedback from those who do not wish to participate directly in the mailing list.
This article has been written on behalf of the Web Hypertext Application Technology Working Group (WHATWG) and has been cross posted on The Web Standards Project, Molly.com and 456 Berea Street.
There’s been a lot of discussion about the W3C’s recent decision to continue the development of HTML around the web lately. Blog posts, and messages that have been sent to mailing lists or posted on forums, revealed many questions and misconceptions about the future of HTML (including HTML 5 and XHTML 2), the WHATWG and the W3C’s new HTML Working Group.
Some people asked for new features; others were wondering if formerly deprecated elements would return; some had comments and criticisms about the decision itself, the WHATWG or W3C process; and a few raised concerns about the WHATWG and W3C ignoring the needs of particular groups. The WHATWG, who are in the process of developing the next version of HTML (called HTML 5), feel that it’s important to not only listen to all of this feedback, but to actively seek it out and respond so that we can develop a language that meets your needs.
There are many ways in which you can participate. The most direct approach is to make your voice heard by subscribing to the mailing list. However, not everyone has the time to participate, or keep up with the high volume of messages sent to that list. Some people feel that the current drafts of HTML 5 (Web Applications and Web Forms) are rather daunting. Others feel that because they can’t afford the substantial W3C membership fees, they wouldn’t be listened to anyway.
If, for any reason, you feel that you either cannot participate, or would be uncomfortable in doing so, that certainly doesn’t mean you shouldn’t be heard. The WHATWG needs to hear from you and wants to know what you think about HTML.
Any questions, comments, criticisms, complaints or feature requests are welcome. Now is the time to speak up. No comment is too dumb; no question is too hard or too simple; no criticism is too harsh. If you have anything at all to say, we are listening.
Please leave a comment or post a link to an article that you have written. You will be heard and we will try to respond.
I frequently come across people who aren’t aware of the problems with using
scripts inside XHTML documents. One of these problems is particularly fatal
because it can cause a well-formedness error, but it’s not seen as
an issue when documents are served as text/html.
The problem is with the use of special characters like ampersands (&), less-than
(<) and greater-than signs (>). Only the first
2 of those are actually fatal, but it’s good practice to escape the latter as
well.
Note: This is not an issue if you use external scripts in a separate file, which is usally a better alternative anyway, but there are times when including scripts in the page itself is useful.
To illustrate the problem, here are some examples. The following is fine in HTML 4, but not in XHTML.
<script type="text/javascript">
if (a && b) {
// Oops! Ampersands cause well-formedness error in XHTML!
}
</script>For XHTML, that would need to be written like this.
<script type="text/javascript"><![CDATA[
if (a && b) {
}
]]></script>Or this:
<script type="text/javascript">
if (a && b) {
// Oops! JavaScript syntax error in text/html
}
</script>But now, when served as text/html (not XML), both the CDATA section
and the escaped ampersands are going to cause JavaScript syntax errors. You
can comment them out like this:
<script type="text/javascript">//<![CDATA[
if (a && b) {
}
//]]></script>But it’s easier to just admit you’re not using XHTML and use HTML instead.