No Clean Feed - Stop Internet Censorship in Australia

thoughts about html

So, there's a coordinated call for feedback on the WHATWG's activities. There's a lot to cover in the call to action, so I'll just start with some thoughts about HTML...

I haven't read the WHATWG HTML 5 and Forms 2 specs "properly", so much as skimmed them. Forgive me, they are big specs with draft status from an as-yet unrecognised group. I don't read W3C specs for fun either ;) So this is mostly off the top of my head, you'll have to excuse me if something is already covered and I've missed it.

Headings and sections

I rather like the XHTML 2 version of headings and sections, as opposed to HTML 5's current system which seems to inherit all the problems of HTML 4 and none of the advantages of XHTML 2.

  • Why limit things to just six heading levels?
  • Why not declare hn as an extensible set of headings?
  • Why use specific headings if you're using sections - just set a heading for each section and let nesting take care of the rest.

I'm not a fan of the W3C's specific example though, since I feel that each section should start immediately with a heading. I'd like to see the strong sections removed. But otherwise this system seems simple and elegant to me (although maybe I'm just weird - I'm aware that's a possibility!):

<body>
<h>This is a top level heading</h>
<p>....</p>
<section>
    <p>....</p>
    <h>This is a second-level heading</h>
    <p>....</p>
    <h>This is another second-level heading</h>
    <p>....</p>
</section>
<section>
    <p>....</p>
    <h>This is another second-level heading</h>
    <p>....</p>
    <section>
        <h>This is a third-level heading</h>
        <p>....</p>
    </section>
</section>
</body>

In anticipation of the argument "documents shouldn't be so big they need more than six levels", I'll simply suggest you go and convince all the world's lawyers and legislators then get back to me :) Besides, it's entirely possible to have more than six levels in a short document that would not be suitable for presentation in multiple web pages.

Better lists

I think <ol>, <ul> and <dl> should all have a <caption> element or a way to explicitly associate a heading. We're grouping information together after all, I think it makes sense to be able to explicitly state what the grouping is all about. It's one of the really useful things you can do with tables.

I also think ordered lists need more sophisticated numbering systems - we should not have to resort to CSS or use invalid code! eg. we should be able to start an <ol> from, say, 11; because 1-10 were on another page. I'm specifically thinking of search results which are commonly split into multiple pages, yet each page should not restart the list count . Currently it's only valid to set the value of each <li>, which is absurd - so the HTML 5 spec's .

Labels for radio button groups

I don't think HTML 4.01 provides a satisfactory method of labelling/captioning a group of radio buttons. Each radio button gets a label; but really the group needs something to describe the purpose of the set of inputs.

You can use a <fieldset> + <legend> combination for short descriptions, but it feels like a hack (not to mention the practicalities of hacking CSS to get browsers to display long legends!).

Captions for images

I'm not quite sure how this could be approached; but I think a visible caption for images would make sense. Hidden text could then be more akin to longdesc than alt. The <object> element provides an excellent model for alternate content, but not a caption.

The cite attribute

While this is ok, I do wonder at the requirement for a URI. How do I choose a URI to cite Shakespeare for example? What one single URI makes sense? Plus long experience shows us that URIs don't live forever - who remembers to check their cite URIs?

So why not an attribute for the name of the person and an attribute for the title of the work they are being quoted from? Sure, there's potential for ambiguity, but don't try to tell me a URI could not lead to a document which talks about ten John Smiths.

<p creator="covenant" work="we want revolution" cite="http://www.google.com.au/search?&q=%22we+want+revolution%22+covenant+lyrics">we want revolution<br />
constant evolution<br />
start your engines blow your fuses<br />
burn the bridges for the future<br />
this is our solution</p>

The <cite> element

<cite> doesn't make any sense to me either, since there's no explicit association with a quote. Take the example from the HTML 5 draft:

<p><q>This is correct!</q>, said <cite>Ian</cite>.</p>

So long as there is only one Q/CITE pair in the entire document, we're ok. After that, we're just guessing - and while a human might guess fairly well, an indexing system has no grasp of human context. So, perhaps a for attribute is in order:

<p><q id="ians-assertation">This is correct!</q>, said <cite for="ians-assertation">Ian</cite>.</p>

The <iframe> element

Why keep <iframe> in HTML 5 when the spec also includes <object>? Straight question. From a quick read, <object> seems to take care of everything that <iframe> can offer.

More...

The HTML 5 spec includes quite a few all-new elements such as <nav>, <x>, <m> and <progress>. Some are relatively logical, but others like <progress> just seem very odd to me. A progress bar is not a permanent content item, it's a temporary state. However I'll save real discussion of these elements for another day.

So what do you think? Join the discussion!

Labels: , , , , , ,

xhtml and css code commenting

Good programming habits make good markup habits too. A few well-placed XHTML and CSS comments can save you a lot of time later on and help your coworkers pick up where you left off... just as it does for programmers!

Complex <div>-based designs can be hard to navigate once the real content is inserted - you find yourself wondering what a specific </div> is actually closing. Even with your text editor's Nifty Bracketing Feature™ it can be time-consuming, plus if you've put a </div> in the wrong place in template-driven site the bracketing might be out of whack anyway.

Garrett Dimon: Closing Divs offers one suggestion which is close to what I've been doing for quite some time now. From the comments it seems a lot of people are yet to embrace code commenting; so I thought I'd show my system as an alternative. No doubt I'm not the only one out there doing this :)

comment your closing elements

I'd say comment your </div>s but sometimes it applies to other elements. No big trick, just put a comment after the closing tag including the id or class name of the element being closed:

<div id="content">
...
</div><!-- end #content -->

Obviously you could leave out the end - you know it's ending something since it's a closing tag - but a tired mind will appreciate the plain English. Plus, if a less experienced developer does the update it will help get them up to speed.

Actually over time I've started leaving out the end; but it's still an option. More important is ensuring you put the comment on the same line as the closing element. It avoids confusion like this real code example I saw recently:

                      </div>

               </div>
        </div>
                                       </div>
                               </div>
<!-- END Content Division -->
                       </div>
<!-- END BOTTOM SECTION -->

Want to bet on which one is the end DIV for the section? :) Is the second comment simply informative, or is it labelling the previous DIV? To aovid confusion, put the comment on the same line and don't put any other elements on that same line.

Don't butt the class/id name up to the comment though, since <!--# is used for SSIs, environmental variables and so on.

Also, don't use multiple dashes inside your comments. Although it might look good to use <-- ----- blah ----- -->, you'll find that some Moz/Gecko browsers interpret any instance of "--" as a closing HTML comment. That means the natty sets of dashes will close your comments and that will Break Stuff™.

indent nested elements

A no-brainer, surely. Indent by one tab for each nesting level:

<div id="wrapper">
    <div id="header">
        <h1>Page Title</h1>
    </div><!-- end #header -->
    <div id="content">
        <div class="post">
            <h2>Post title</h2>
            <p>...</p>
        </div><!-- end .post -->
    </div><!-- end #content -->
    ...
</div><!-- end #wrapper -->

Indenting is not exactly a form of commenting so much as formatting; but it does lay the groundwork for some further commenting later.

css loves comments too

A few well-placed comments in your CSS can save a lot of headaches later on. A quick reminder about the order and nesting of id/class elements will save you reverse engineering that site you published a year ago, just to tweak a margin.

In fact, just separating the groups of definitions may be enough; eg:

/* ---- content ---- */
/* ---- links ---- */

...will help you find what you're looking for as quickly as possible.

If you're retrofitting an existing site, sometimes you won't have the chance to choose the markup; so you might need to remind yourself what's going on in the document:

/* .breadcrumb applies to DIV or P depending on the template */
.breadcrumb {
...
}

I know you'd rather get out there and standardise those templates; but right now, give yourself a break and comment that gotcha :)

If you're handing over a particularly complex design to somebody else, you might throw in an outline:

/* element order:
div#wrapper
  div#header
 h1
  /div#header
  div#content
 div.post
  h2
  p
 /div.post
 div.comments
  p
 /div.comments
  /div#content
  div#navigation
 h2
 ul
  /div#navigation
  div#footer
 p
  /div#footer
/div#wrapper
*/

Some may find this too much bloat for the stylesheet, but a little bloat may be a small price to pay for faster updates. It depends on your priorities. You could put the outline into separate documentation, but how many of us store our documentation as reliably as we store the actual sites? Be honest, now :)

brute force versions

If you're not using a full-featured versioning system like SVN, you can still do some basic version tracking. I find this especially useful for CSS, which tends to be tweaked relatively frequently. A simple number and date will do:

/* v1.1.8 - 2005.11.05 */

Use the appropriate number of version levels for the given site. I've found three levels works for me: a tweak is n.n.n+1; addition of elements and so on get n.n+1; whole new designs are n+1. If you're really keen, working copies can have n.n.nx where x is a-z; eg. 1.1.7a, 1.1.7b. Update the version when you upload to your server. Simple.

don't go crazy

Not everything needs to be commented. In fact, some designs are so simple you don't need to do it. If the closing tag is and will always be within a couple of lines, then common sense says you don't really need to comment it (unless you're into a serious debug exercise). But if the design is complex, or you regularly pass work around within a team or even to another team; then good commenting will help everyone.

Labels: , , , ,

about

Web development and standards, as seen by Ben Buchanan.

subscribe