21 XML, DTDs, Oh My!

Sounds like we all agree that we need a markup language that is flexible — something extensible. Yeah! And eXtensible markup language. Then we just need something that allows us to define the custom types in our documents. A document type definition.

Boy it’d be great if this “XML” language existed along with support for “DTDs”…

If we all stopped this absurd argument over which HTML 5 tags are worthwhile and moved to full XML support styled using current CSS techniques we could stop versioning the markup language used to structure the web.

The only downside is that without a standard set of markup tags you make spidering the web much more challenging and open the doors to “What the hell are you doing?! Why is there a <footer_for_the_homepage_with_red_border> tag?!”

posted at 01:16 pm on January 6, 2009 by Michael Thompson

22 Untitled

“Any solution that isn’t backward compatible won’t be widely adopted by developers for fear of excluding readers. It will quickly wither on the vine.”

This can’t be true, or else every standard in the world would eternally be stuck on version 1.0.

I just watched Nicole Sullivan’s presentation “Design Fast Websites (Don’t Blame the Rounded Corners)”, and her comments on the difficulties of maintaining a site with an under-reliance on class/id attributes (using the right building blocks) makes these new HTML5 tags look pretty pointless.

Maybe I’ve just outgrown the navel-gazing side of being a standardista, but I’m tired of articles discussing and debating the perfect evolution of HTML. HTML hasn’t really evolved since 4.01 because 4.01 is really, really good, and really lets you do 99.99% of what you could want. (A few HTML5 things might be useful, like cleaning up embedded media tags.) CSS still has room to grow, but CSS3 might finally catch up to the completeness of 4.01.

Future growth in web dev isn’t in new standards or design, it’s entirely in information architecture and usability of sites that aggregate lots of data. I think that’s why ALA articles have seemed kind of boring and off-point lately — it’s really hard to write about a dev process that is so specific to each implementation.

posted at 01:20 pm on January 6, 2009 by Dave Nielsen

23 Untitled

I wouldn’t bet the future of the web on IE6, IE7, and even IE8. All other browsers (Safari, Chrome, Opera, Firefox, etc) will support these new tags very soon after they are finalized. It’s not really a browser war this time, its more like a giant, dying, thrashing elephant. IE’s death is imminent, at least in its current incarnation, but it keeps trying.

With Google now redirecting IE6 users to download Firefox or Chrome, I predict that IE6 will soon disappear. And once IE8 is out, Microsoft will be pushing that. IE7 will be the forgotten middle child. The sad part is IE8 doesn’t support styling these new tags either. So, maybe after going through two major (and not painless for the user) upgrades with out any real benefits, users might get sick of it. Even corporations might.

posted at 02:44 pm on January 6, 2009 by Steven Simmons

24 WAI ARIA

One of the only coherent articles on HTML5 I’ve read, very well done.

I do agree that while we’re waiting for HTML5 to finish (in the next 10 or 20 years) we need something in place to keep things moving forward. I’m not sure that creating another attribute is the answer.

I’m not completely sure, but attributes like “role” seem to hold a glimpse of WAI ARIA support. Is that accurate? I haven’t heard much about it since WDN08. If it is, I think that would be a nice way to integrate greater web-app accessibility. Otherwise, I wouldn’t be sold on creating another attribute that IE6 won’t support just for the sake of doing it. The end result of no backwards compatibility may not be worth it at this point in browser evolution.

Great read though.

my2cents

posted at 03:01 pm on January 6, 2009 by Tim Wright

25 The problem is solved, and the solution is RDFa

It’s interesting to note that except for Mark Birbecks comment, noone mentions RDFa. Maybe the RDFa community need to reach out better to Web UI designers. I would encourage everyone to take a look at it as it solves the problems mentioned in the article in a very flexible and non-intrusive way. For more background information, including a discussion of and comparison with microformats, please see Manu Spornys post from a few months back: http://blog.digitalbazaar.com/2008/08/23/html5-rdfa-and-microformats/

posted at 03:16 pm on January 6, 2009 by Staffan Malmgren

26 Discussion on #whatwg

This article has been talked about on #whatwg today:

• http://krijnhoetmer.nl/irc-logs/whatwg/20090106#l-310

• http://krijnhoetmer.nl/irc-logs/whatwg/20090106#l-512

Many other subjects are discussed, so be prepared to skip large portions. :)

What are the practical problems affecting users which “add more attributes” would solve but which class and id do not? The article states about a dozen times there’s an essential need for something like this, but gives no examples showing why.

posted at 04:31 pm on January 6, 2009 by Ben Millard

27 The big mistake was DTD

The current solution to extendeing (X)HTML are custom DTDs. However, that’s not good enough. RDFa is kind’a good, but not exactly “it” in my book, mainly because “it” too uses XML namespaces.

I think the main reason why “(X)HTML with a custom DTD” has never appeared to be appealing is because of the DTD switch – custom DTDs (AFAIK) run in quirks mode. This alone is enough reason why no one would use a custom DTD.

Namespaces exist in XHTML (since it’s based on XML), and they are just the perfect mechanism to add elements to the vocablulary without having a definitive standard. The problem with namespaces though (and THE reason why they haven’t been picked up) is that DTD is not namespace aware, so if you want to use namespace, you have to previously create a new DTD that includes the elements from the namespace and (what’s really funny for me) declare the xmlns:prefix attribute wherever you need to put it. That’s not exactly “plug-and-play”…

The problem is PARTIALLY solved by XML Schema. The problem is the XHTML schema (even the 1.1 schema!!!) doesn’t allow elements from other namespaces to appear inside XHTML documents. In addition, the W3C validator doesn’t validate by Schema, but by DTD.

A very simple solution that I would do if it was up to me, and which is forward compatible (and if you use the new elements with care, it can also be backdraw compatible) is to create an XHTML 1.2 schema that will allow ANY element to appear ANYWHERE in an XHTML document, as long as it is from another namespace.

There is already a Schema validator at W3C, though a separated one. Let’s just switch the markup validator to the Schema validator (when the documents are parsed in XML mode that is), add the XHTML 1.2 schema as a possible choise, and it’s done. Ideally, the validator may include a list of “known namespaces” that are governed by W3C, and upon encountering others, it MAY issue a warning (but no error!) that the element may not be rendered properly everywhere.

The possible problem in this case becomes the fact that XHTML 1.2 documents will have to either:
-run in text/html in quirks mode (since there’s no DTD)
-use the new MIME type (which always runs in strict mode, and thanks to the namespace will be rendered even without a DTD)
-use content negotiation to choose between XHTML 1.0 served as text/html (and with tons of JavaScript to mimic the lost functionality) and XHTML 1.2.
That last one is probably what’s best for the real world, but it’s actually not as hard as it may sound. It’s very easy to use PHP or any other server side language to switch MIME types, and using XSLT to convert the extension elements to XHTML 1.0 elements + JavaScript is also a possiblity or something like PHP’s XMLReader if you’re not finding XSLT fancy.

As far the draconian handling of the new MIME type goes – I’m sick of hearing this argument over and over again when it’s just not valid in the real world (despite the fact it’s reffered to as a “real world problem”)!!! When you know XHTML, you won’t make silly mistakes like that, and if you do, you’ll correct them in an instant. If your content is managed by someone else, they’ll be entering the content from a CMS. It’s the CMS’s responsibility to validate the input before it ever gets displayed to users, so if the author is not XHTML savvy, he’ll see the error, not his viewers. Ideally, he won’t even see the error – the CMS will attempt to be “HTML”-ish by trying to guess what the author meant, and use THAT for viewers instead of the original. And if you leave your non (X)HTML savvy customers to manually edit their (X)HTML files, you’re just not a professional web dev to begin with!

Phew… if you were able to read ALL of this comment, thank you.

posted at 04:42 pm on January 6, 2009 by Vasil Rangelov

28 Extensible HTML

Yes, I too think the best possible solution is to make HTML extensible. This is a point I’ve tried to make to the HTML5 group before, but without apparent effect.

Core HTML should be something less than HTML4, with a well-defined extension mechanism. Browsers would commonly load a set of extensions equivalent to HTML4, for existing web pages. Application writers could define new (application) semantics and override stock behaviors.

In fact, when you look at the most advanced current practice, this is what authors are doing now, though limited and awkward.

There are folk who want to use declarative markup to describe dynamic behavior – and as long as this is so we are pretty much screwed. Dynamic behavior is too various. The attempt yields massive markup but cannot cover all present or future possibilities. Better to go the other direction – reduce declarative markup to a minimum (in the standard) and allow for well-defined extensions.

HTML is good enough as a starting point. Existing browsers can – perhaps enough for the interm – be used in this fashion. Small changes in near-future browsers could go a long way to help.

The HTML5 standard is far larger than it needs to be, but we’re stuck as long as the standard lacks extensibility, and declarative markup is used (more than minimally) to define dynamic behavior.

posted at 05:01 pm on January 6, 2009 by Preston Bannister

29 Why treat IE as handicapped?

The main issue here is that we’re treating IE as though it has some special problems or concerns as opposed to other browser vendors. Webkit (Safari, Chrome), Mozilla, and Opera are all keeping up with the curve. Somehow they’ve managed to put together some semblance of support for HTML5 very quickly and get their new browsers adopted quickly.

It doesn’t matter how this happens. Safari is Apple mandated, Chrome is auto-updated by Google and Opera and Firefox have auto-update suggestions. It’s not a question of why can’t old IE users upgrade, but why MS won’t coerce them to do so. They could easily mandate that all IE’s be up to date.

MS is simply not interested in doing so. Who cares if we’re backward compatible with IE6? If we all start breaking the web for IE6 users, it will eventually fall into disuse. The reason IE6 still exists is because we’re still coding for it.

posted at 05:25 pm on January 6, 2009 by brad dunbar

30 Vocabularies

Yes, we like extensibility, of course. And RDFa is a good way to go. But vocabularies of attributes will continue to be created, and will continue to evolve, as long as our needs continue to expand. That means always. None of us will ever be able to keep up with the expanding dictionary of possible attributes and qualifiers and their intricate levels of implied meaning. An intelligent system of matching relative synonyms intuitively by degree is going to be more useful than an increasingly complex set of attribute definitions.

posted at 06:14 pm on January 6, 2009 by M. David Green