Welcome to MSDN Blogs Sign in | Join | Help

Where to put design-time stuff in HTML pages or my rant about W3C

My biggest complaint about W3C is that they made HTML standard non-extensible. I am a tool developer and we often need to store design-time settings somewhere. Settings may be per document or per element. Examples: grid size and visibility, snap to grid settings, locked/moveable element, 2D or flow panels, etc. It is not that bad for per-document settings since META element can be employed. However, it will only work for per-document settings. IE supports expando (i.e. custom) attributes and that's what we used to employ in VS HTML Editor before Whidbey. For example, ms_positioning in VS 2003. Users had difficulties validating pages with custom attributes since expandos make page incompatible with W3C validator. We abandoned expandos in Whidbey. Instead, all settings are now per application since we don't store anything in the document. Settings get written to the registry, see HKCR\Software\Microsoft\Visual Studio\8.0\HTML Editor.

In XHTML I can declare a namespace, such as vs: and use it for custom attributes. This approach, however, is incompatible with HTML 4.01 which does not allow namespaces. In Web Forms we could theoretically store design-time stuff in server-side comments such as <%-- --%>. But this won't work for plain static HTML pages. We could use HTML comments <!-- -->, but this means we would have to employ different mechanisms for different file types. That would obviously bloat our code, not mentioning increased number of bugs. And what if one day user decides to change static .htm file into dynamic .aspx page?

CSS 1.0 is not better either. CSS 2.1 at least introduces vendor-specific extensions, but that's too late for us since what we are going to do with CSS1?

I wish people would think about development tools when they were designing a new standard or file format. I have great respect to creators of TIFF format that allows private fields. These fields greatly simplify document workflow since one can store a whole bunch of additional information there.

Published Thursday, June 03, 2004 11:34 PM by Mikhail Arkhipov (MSFT)
Filed under:

Comments

# re: Where to put design-time stuff in HTML pages or my rant about W3C

HTML is not supposed to be a format that supports what you want it to support. If you need those features (precise control over layout) then you're using the wrong tool for the job and would be much better off with lets say PDF than HTML.
Friday, June 04, 2004 7:10 AM by Jerry Pisk

# re: Where to put design-time stuff in HTML pages or my rant about W3C

However, many customers think otherwise :-)
Friday, June 04, 2004 7:36 AM by Mikhail Arkhipov (MSFT)

# re: Where to put design-time stuff in HTML pages or my rant about W3C

That doesn't make them right though.
Saturday, June 05, 2004 10:29 AM by Jerry Pisk

# re: Where to put design-time stuff in HTML pages or my rant about W3C

Hold on, isn't them who actually pay us? :-) I have heard they are always right ;-)
Saturday, June 05, 2004 10:36 AM by Mikhail Arkhipov (MSFT)

# re: Where to put design-time stuff in HTML pages or my rant about W3C

To a point yes. But once they realize they've been wrong you're going to loose them. Look at McDonald's, all their super-sizing was based on customer feedback. You need to realize that customers do not know what they want, that's your job to find out. If they tell you they want a feature it's because somebody told them they wanted, not because they actually want (and need) it. If somebody tells you they need to be able to publish a fixed layout document, like a newspaper or a book using HTML you need to tell them they're trying to use HTML to do something it wasn't designed for (and therefore cannot easily do), not to force HTML to do things it wasn't supposed to do. It's like listening to people that want to run a web server on Windows 98 - it's just not going to happen, it is the wrong tool for the job.
Sunday, June 06, 2004 12:48 AM by Jerry Pisk
New Comments to this post are disabled
 
Page view tracker