Good for the Goose

Well, at the risk of not adding anything useful to the debate:

It does sound a bit odd to me. What are web standards all about if you can just make up new ones on a whim. Well, perhaps not a whim, just when ever you really need to.

And another thing… just so you can validate? Of course you can validate your own made up DTD, but what’s the point in that? Won’t help me sleep better.

The difference between browsers adding features and you using a custom DTD is that your DTD will work on any modern browser (at least theoretically), because you’re the one adding the features - if the browser works correctly, it should realise there are other elements to parse. Of course, this is far from guaranteed…. for my part, I think it’s actually a good idea to customise the DTD. After all, there’s no need to make somebody’s browser load elements that you never use; that’s just a waste of their bandwidth (albiet a small one). Besides, with the advent of XHTML, you’re now essentially using XML, and nearly everybody creates a custom DTD for that.

In short, I think it makes perfect sense.

The big power of XML consists exclusively in that it’s a data storage completly defined by the designer. This should be extended to XHTML. While XHTML should be more semantic, I do agree that it should be standardization bodies that would extends the notions involved.

All in all, custom DTDs are, as far as I can tell, the perfect compromise between the standardization bodies and individual users. Unfortunatelly, these lose semantic power. For example, if I was going to create a bot that would search the net for <address> tags to create a spamming list for snail-main :-) that would relly on standard HTML, but if someone marks addresses with <physical_location> what is a poor spammer to do?

does creating your own DTD work on all browsers?

I agree, I think it is up to the designer to code the way he wants to code. Nobody is going to ever have to look at the code except the coder/designer.

As long as it don’t not break anything and it provides more customization, I think it makes sense.

Instead of adding class=”happybox” you could create a happybox tag and save a few bites of characters

The main thing that should be a concern: is the document independent? When designers extend the markup does so in such a way that any standards-compliant browser can figure it out. The definitions are there, the behaviors are there.

However, when a browser vendor adds custom markup, the custom definitions and behaviors might not even be with a DTD and some JavaScript; it forces other browser vendors to either accept the change or reject it, and if, say, Internet Explorer is the browser making the changes, the choice is an unfortunate no-brainer (assuming the feature sees somewhat widespread use).

Hm… put a comment in the code about it? For my part, my coding isn’t determined by how easily noobs will be able to use it. Since the majority of my stuff is CSS-based, that elminates most of the noobs anyhow. You certainly couldn’t claim the complex site you’re running here is designed to be noob-friendly. Admittedly, I used ideas from other people a lot during my early days, but I’m not going to design just for them. If they’re serious about it, they’ll either figure out the cause of the problem, or they’ll find another way to do it.

What would be interesting to know, is if by using a custom DTD, can you actually send it as contenttype application/xhtml+xml ? And what if you’re custom DTD completely rearranges every XHTML element such that [b] is now the new [a]? Should a custom DTD be supplied with a full CSS file that describes how every element should be rendered?

I don’t know the answer to any of these questions as I’m no XML guru by any means.

…if browser vendors should not take liberties with custom tags and attributes, shouldn’t individual developers adhere to the same principle?

I think there is a clear distinction between developers and browser makers here: an individual developer creating a custom DTD for his web application doesn’t hurt anybody - his document is valid XML and is displayed in an almost similar fashion as ‘normal’ XHTML documents. When a browser maker adds proprietary flavors to its browser, the story is different, though. The problem here is that proprietary tags and attributes are often linked to specific browser behaviors, on which certain developers will start relying in order to achieve special effects; by doing this, they ignore the device independence principle—certain types of content are only viewable on specific devices, leading to, indeed, vendor lock-in.

An interesting example thereof is the DoCoMo (Japan’s biggest mobile carrier) mobile browser, which works with i-XHTML spec reveals for instance the existence of an ijar attribute, which hooks in on one of DoCoMo’s proprietary i-applications.

What I’m left wondering is, if browser vendors should not take liberties with custom tags and attributes, shouldn’t individual developers adhere to the same principle? Instead of having two to three big players creating non-standard additions to an existing standard, we have the possibility of hundreds or thousands of different strains of “valid” XHTML evolving independently.

Yes: that’s the great promise of XML, and XHTML is an XML language. The potential explosion of markup languages has been inherent in XML from Day One. The XML proponents will tell you that’s not a problem, because a real XML user agent will accept any well-formed markup and style it according to your CSS/XSL:FO/DSSSL/whatever instructions. And they’re right, within that world. If Web browsers were full XML user agents, it wouldn’t matter who invents what language for themselves.

The Gecko family (Mozilla, Firefox, et.al.) actually is pretty close to being a full XML user agent. You can feed them any arbitrary markup (even in an XHTML document!) and style it directly. You can throw in a happybox element and write CSS to make it appear however you like.

So the answer from the XML gang is: no, developers shouldn’t adhere to that principle; they never should have been forced into a crappy, limited vocabulary like HTML in the first place.

From my perspective, I share your concerns, but they’re largely driven by the limitations of today’s browsers. Arbitrary markup is something of a minefield right now, although the ALA article at least shows how you could take advantage of it without breaking browsers.

I think being able to write custom DTD can be a real time saver.

Ask any Web Developer about what is the biggest pain in developing web application. Answer will always be: Input Data Verification

You have to do it and it’s repetitive and tedious.

You know why ASP.NET is so popular? One of the reasons is: it makes Input Data Verification a child’s play.

ASP.NET uses Server Controls to achieve this Verification Nirvana which we can achieve using custom DTD. How?

You define custom attribute for your tags which are more or less standard. Like

Required MinLength MaxLength RegularExpression EmailAddress PreCondition

Once these tags are standardized, you can have a single piece of JavaScript and PHP (or Perl or Python) code which will do verification of Input data based on these additional attributes. And this whole validation can be automated! Designer doesn’t need to put those boring PHP code in their design to incorporate validation! Both designer and developer can now concentrate on what is more important i.e. Designing great looking site and Coding Application logic, respectively.

I am going to spend sometime over this weekend and see if I can come up with some code which demonstrates this.

JD

Sorry to be a bore, but I think there are accessibility issues with using custom elements. If the major market share browser can’t understand happybox, what the hell is a screen reader supposed to make of it?

HTML obviously isn’t perfect, but at least it’s a standard markup. Just because you can get your happybox to validate, doesn’t mean it’s semantic, or that any particular program will understand it’s meaning. What about people who have custom stylesheets to display content how they want, or that have CSS disabled, can anyone say;

This XML document does not appear to have any style associated with it. Please read this code

Obviously there are areas where custom DTD would have benefits, ALA article for example. But there is a big difference between adding a required attribute, & marking up your blog entries as [entry] & [entry-heading].

I think marking up blog entries like that would make it much easier for designers trying to remember how their structure is with what classes and id’s.

Too bad one cannot describe the meaning of their new tags; give a definition to a tag an a tag is for a link, so a happybox tag could be for boxes that display happy information!!

The only reason any device (browser, screen reader, pda, phone) can tell a means link is because it’s a standard. Writing a custom DTD to state that happybox means div, or that [entry-heading] means h3 is just pointless.

Do this server side, convert your XML to xhtml, then you can have the benefits of more meaningful structure, and nobody but web developers get near it, especially not pda/mobile phones, they are in enough of a mess already!

To remark to steven, custom tags at this point are not meant for a browser t odo anything with. In fact they likely will and should ignore them. Custom tags can be used to give semantic meaning for OTHER types of clients, or for use with javascript..

I didn’t read all the other comments, but…

When it comes to XHTML, I’m way more concerned with well-formedness than I am with validity. A well-formed XHTML document can be thrown into a parser and I can access its DOM without a hitch. That’s the beauty of it all! A lot of flavors of XML don’t even bother with DTDs or Schemas to do simple tasks, further solidifying the argument that well-formed beats validity.

Of course, in certain cases, validity is important and thus shouldn’t be overlooked, but so long as we’re on the topic of web pages, go for well-formed first.

Also, since browsers have been known to rely on DTDs to determine parsing types (standards mode, quirks mode, etc.), I’d argue against creating a custom DTD. Add your attributes and be done. If you really care about validity, I’d suggest the XML namespacing route over the DTD route any day of the week.

Most of the discussion about custom attributes and JavaScript triggers usually comes back to good old form validation. For those interested, Mozilla just released a beta version of its InfoPath.

I think a point we’re missing is the semantics (and lack of them) when using custom tags.

p is a “paragraph”, ul is an unnumbered list. There needs to be some sort of standard for what is what, or someone reading the tag happybox is gonna have to take an educated guess what it’s structural purpose is. (Who’s going to guarantee that everyone who uses custom DTDs also uses sensible tagnames? - it’s like the scriptkiddy thing of naming classes ‘hahaha’ and ‘lookatthis’, and changing file extensions so you can get addresses like http://mydomain.com/index.myd). For most purposes, XHTML will suffice.

Similarly - what happens when you decide that the happybox is annoying and so you’re gonna make it an angrybox? Whereas before you just changed the .box styles, now you actually have to change the structural markup or it looks stupid.

Using custom DTDs may be nice in proprietary solutions but I don’t think it’s worth the effort for the greater part of the web.

…what happens when you decide that the happybox is annoying and so you’re gonna make it an angrybox? Whereas before you just changed the .box styles, now you actually have to change the structural markup…

Interesting point. Perhaps it’s a matter of sensibility; maybe giving an item like box a descriptive name (like redbox, greenbox, bigbox, smallbox, happybox, or angrybox) just isn’t sensible (however valid and well-formed). Then again, what would you call it?

I’d call it a div

I’d call it a div

Touche´

I believe that standards are written and put in place to allow these kinds of language extensions. People aren’t just “mkaing up” their own standards. Their are adhering to W3C specifications to modularize their code, which is a good thing. Also, DTDs will be obsolete soon with the new XML-based “DTD” a.k.a Schema. This will make things like your custom markup for rollovers easier. My main point is here, as long as the standards are followed people will have access to your content the way you want them to see it.

I would just like to make everyone aware that I might go and copyright happybox.

;)

cool design! fucking good man!

I think the important thing to keep in mind is that an XHTML page is an XML document first and foremost, and XML was designed to be extensible. XHTML is simply a namespace for XML that defines a standard for how browsers display given tags, and the onus is on the browser vendor s to support the standard correctly, not on the developer to only use that particular DTD. Using a custom DTD is a perfectly valid and standards compliant solution to the problems outlined in the original article; as long as browser vendors respect the standards, there won’t be any problems.

I think the problem has always been browsers implementing their own tags before implementing standards (eg ns4 using layer instead of div), which forced developers to fork their markup to cater for different browsers. It is a little different now that HTML is 99% supported across current browsers.

The W3C is not innovating HTML fast enough IMHO, so I wouldn’t mind if, say, IE7 gave us new tags, like perhaps copyright or date. Mozilla etc can style these tags right now so cross browser compatability is less of a problem.

As for developers implementing new tags/atts… when doing so, developers need to keep in mind that their new extensions will most likely only ever be meaningful to its particular application. Eg. img osrc= might mean something to the javascript on the site, but will mean nothing to bots like Google and will be out of date, if say, the W3C standardises a different attribute to do the same thing. One thing developers can do to combat this is see if other developers have used a particular naming scheme in the past for the same thing. This would create de-facto standards, much in the way div id=\"content\" became one.

I think there’s a touch of arrogance in looking at your (your client’s…) site in isolation. We’re not developing standalone applications, our work is adding to the larger web of sites/pages/whatever - and for me that’s a really important reason for sticking to a standard: underneath all the different aesthetic styles is a common, agreed standard to which we we work.

I can make up my own version of English and provide my readers with an jEnglish to English Dictionary, I might even improve on some words (that whole ‘ough’ pronunciation thing has had it coming for a long while). The question is why would I want to, and in whose interests would it be in?

The web is defined by its underlying language and technology, making piecemeal changes to your own tiny corner of it just because you can - or if we’re being generous here: because it saves a little time in development - kind of misses the point of what the web’s all about.

Also, Steven Urmston raised an interesting point: what are the accessibility implications of a custom DTD?

I think both Justin and Adrian are missing the point. You can not compare XML to a language like English. English would be better compared to something like C, Where re-arranging syntax or functions would be absurd. One of the key features of XML is its ability to scale and meet the demands of your current project. Whether it be adding rollover functionality to links or storing graphing statistics. As was stated earlier by Mateo, “an XHTML page is an XML document first and foremost, and XML was designed to be extensible”. Which, I believe, is the most accurate definition I have read in a while.

But XML isn’t XHTML - which is what I thought we were discussing here. XML is fantastic, but the stuff I want to be sending to the browser is XHTML: XHTML which is understood by whoever has to work with my code (be they a UA or my successor).

And the point about English is I think, sound - once you start moving away from the standard which defines something you’re creating something else. Yes, we could use browsers to render all sorts of things (l33tML, anyone?), but ultimately in whose interests is it for us to be doing that?

Although you could point out there’s no such thing as a standard for English, only common-usage…

This is a great idea…

I believe the question to ask ourselves is “does this make it better for the user?” If screen readers cannot interpret custom tags, then perhaps we limit ourselves to custom attributes to start. If a ‘required’ attribute eliminates a fresh page load and replaces it with a simple alert box, a jump-to-field and a highlight behavior, then use it.

I have faith in the web development community at large to work out problems and find sensible, appropriate methods of doing things (thanks, ALA). Some developers/producers will misuse the idea in the same way that tables are misused all over the web, it happens. However, as we’re collectively sorting ourselves out, we’re all getting better. We know not to use things like “leftColumn” for IDs, but instead “nav.”

I believe the same would happen with people using custom DTDs. “Required” would probably become a very popular custom attribute, but we would generally frown on the “IsRed” attribute. The more people begin using it, the more exercised it will become, and consequently, the better it will be.

I believe custom attributes and tags are a great way to use the extensibility that xml/xhtml gives us.

Though, there are some problems that needs to be solved before we really can use it. I can think of a few: 1) browsers need to handle the xml content-type correctly - using xhtml as content-type doesn’t make sense if the content isn’t using an xhtml dtd.

2) browsers (or any web-browsing devices) need to be able to read any well-formatted piece of xml document, and either (if a dtd/schema is given and the document is valid) parse the document according to the dtd/schema, or (if no dtd/schema is given) read out all the plain text in the document (that is, the contents of the tags, not the attributes), maybe formatted by given stylesheets.

I will need to make a few experiments before I know what negative impact custom tags will have on my usual visitors and browsers. If the negative impact is low, maybe I will start to use custom dtds even when the (1) and (2) aren’t fulfilled.

That’s just what I think, I will enjoy coming back here a few times to see what other commentators has written. Please excuse my bad english, this is not my mother tongue. I hope what I write is at least understandable.

I believe that standards are written and put in place to allow these kinds of language extensions. People aren’t just “mkaing up” their own standards. Their are adhering to W3C specifications to modularize their code, which is a good thing. Also, DTDs will be obsolete soon with the new XML-based “DTD” a.k.a Schema. This will make things like your custom markup for rollovers easier. My main point is here, as long as the standards are followed people will have access to your content the way you want them to see it.

Sisecam Yelken ve Kürek Kulübü