Partager via

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

  • Article

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.

Comments

  • Anonymous
    June 03, 2004
    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.
  • Anonymous
    June 03, 2004
    However, many customers think otherwise :-)
  • Anonymous
    June 05, 2004
    That doesn't make them right though.
  • Anonymous
    June 05, 2004
    Hold on, isn't them who actually pay us? :-) I have heard they are always right ;-)
  • Anonymous
    June 05, 2004
    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.