dolphinling’s weblog

This is a list of markup changes I would make to languages on the web, if I were all-powerful and able to push them through, and backwards compatibility weren’t an issue:

• Specs would be written so their content models ignored elements from other namespaces. For example, when html 4 says <!ELEMENT UL - - (LI)+ -- unordered list -->, I can do <ul><foo:bar><li>blah</li></foo:bar></ul> and all is good and well and valid.
• Forms would be a separate namespace from documents. See my previous post.
• Navigation/branding/other template-type things would be their own namespace. See again my previous post.
• ins and del would have their own namespace.
• New namespaces would be easy to generate, and it would be easy to make machines (partially) understand them, without needing those machines to be updated at all. See my post on this topic.

More to come… this post was mostly inspired by the ins/del thing.

Reading back over the first item… is that really what I want? And just say if authors do something like <html:em><grammar:paragraph>text text</grammar:paragraph></html:em> it’s their problem? Or do I really just want some way to say “this element doesn’t affect content models”?

Blah, this is my third time writing my post, and I’m not really feeling writerly right now, so I’m just going to say what I need to quickly and get it over with.

Basically, the “Markup / Style / Behavior” split that everyone always talks about is wrong. The split really should be Document / Presentation / Application. Presentation is split into Styling—CSS—and for lack of a better word Branding—templates, a spec for which is yet to be developed. Application is split into UI—Forms—and (again for lack of a better word) Programming—client-side or server-side, or one as a fallback for the other.

Because of this I’m not really happy with any of the specs currently out there or currently being developed, with the one exception of CSS, which fits nicely into Presentation: Styling. I first started noticing this with WF2, which, although it’s one of the closest to being good, extremely bugged me by having the template attributes apply to all HTML elements, instead of just fieldsets like I said it should. I haven’t read the WA1 spec enough to comment well on it, but from passively reading the mailing list I get the vague impression that it fails to stay in one category in a bunch of ways. I haven’t read any of XFORMS, but from what I’ve heard of it it sounds like it has not only that problem but plenty of others.

Actually the first sentence of that last paragraph is wrong. XML is okay, since it doesn’t give any of the categories, it just standardizes markup. The Document, Style: Branding, and Application: UI categories will all be markup based, and having a standard markup is good. Javascript I’m only just becoming familiar with, but it seems like a good fit for Application: Programming (client-side). That’s not saying those don’t have other problems, just that as far as I can tell they’re not fundamentally flawed in the way I’m discussing.

Going to end this before I start rambling, since like I said I really don’t feel like writing, so much so that I’m not even going to proofread. So.

Reasoning for paragraph 2 left as an excersize for the reader. (Basically, this whole post is telling you what to think, you have to figure out why to think that.)

I’m currently getting more blog spam than email spam, so if you post a comment please also email dolphinling@delphiforums.com as it’s less likely to get lost that way.