Archive for the ‘Comment’ Category

Anatomy of html

Thursday, October 23rd, 2008

A mark of any group is their shared language; and a mark of any group involved in a craft is the technical precision of their language. Brick layers, dentists, lithographers and chefs all know what each other mean when they refer to a particular item. Web professionals are no different. Most of the people working on and with the web, however, are not web professionals; even some who should be are not. For those of you who are, what I am about to describe is blindingly obvious. So you can stop reading now.

A few years ago I embarked on a mission to educate the team in my day job. I got them all to refer to all the bits that make up HTML and CSS by the correct names, This was done partly so they could explain to me what they want, partly because I am a neurotic labeller, but mostly because they wanted to be professionals in their field and so needed to use the language correctly. Things, and teams, change and just this week, for the first time in over two years, I heard someone who would consider himself a web professional use the term alt tags.

There are no alt tags

Never were.

Anyone involved in web production who refers to image elements’ alternate text attribute as alt tags is a moron.

The basic unit of HTML is an element. A tag is part of an element. An element Starts with an opening tag. This is the angle-bracket stuff, and ends with a closing tag. The element is everything between the opening tag and the closing tag including the tags themselves. Self closing elements don’t have a closing tag and the element is equivalent to the tag.

Note I stated that an element is everything from the < of the opening tag to the > of the closing tag - inclusive. Therefore an element can (and often does) contain other elements. The DTD describe the allowed content for each element. For the purposes of the rest of this rant I will describe elements which require a closing tag as per the HTML 4 DTD. The accompanying image outlines all this in much clearer fashion so I apologise to anyone who cannot view it. Those of you who choose not to view it can just deal.

A representation of the parts of an HTML element

A representation of the parts of an HTML element

The opening tag may contain attributes. An attribute consists of name/value pairs represented as the name, equals sign and value, white space is ignored. In HTML 4 some attributes may be entered as singletons; that is as a name only with the value implied, I don’t consider this good practice but there is no reason not to do it. Attribute values ought to be quoted. This is required in XHTML. In HTML quotes are optional for single word values; this is really bad practice and you ought to quote all attribute values. An image’s alternate text is an attribute. Some attributes are required by certain doctypes, the alternate text attribute of an imgage element being one such required attribute.

There are some restrictions on attribute values but these are often specific to certain attributes. For example the id attribute’s value should not start with a numeric. Some parsers seem to expect some attributes in a particular order. The W3C HTML validator seems to chuck a wobbly if an image element’s opening tag has something other than a source attribute as the first attribute. This is not strictly required.

A (non-self-closing) HTML element usually contains child nodes. These may be other elements or text nodes (which is just text and is usually referred to as text except by weird DOM-nerds). White space only text nodes usually exist within a DOM tree but can be ignored for most cases except when traversing the tree.

Some elements are restricted in what they can contain as child nodes. An unordered list element, for example, may only contain list item elements as its child nodes and (in HTML 4.01) a fieldset element must contain a legend element. There are some general rules of thumb to make this a little clearer (these rules omit the possible existance of whitespace text nodes withing the DOM tree):

  • inline elements must not contain block elements;
  • block elements except the paragraph element (<p></p>) may contain other block elements;
  • ordered and unordered list elements must contain list item elements as their immediate descendents;
  • definition list elements must contain definition term and definition data elements as their immediate descendents;
  • select elements must contain option elements or option group elements as their immediate descendents and option group elements may only contain option elements;
  • uou cannot nest forms (which stuffs up many ASP applications) or textareas;
  • use your common sense!

Pointless protests?

Wednesday, July 30th, 2008

Today in Amnesty International Australia’s online day of protest against internet repression in China. A wonderfully long name for a silly little gag. Whoop de doo!

Except this is important.

Given that people are imprisoned, tortured or murdered for political activity on an almost daily basis in China is the freedom to do what I am currently doing all that important? Well, how do we know when other (more important?) rights are expunged, violated, swept away etc? Do we rely on Xinhua to tell us?

I was in a cab recently. The taxi driver was interested in what I do for a living and was instantly skeptical about ‘rights’ (mix rights with charity and I am immediately labelled a rabid lefty by most people I meet). My point was simple: how often do you complain about the Government? Daily? Weekly? Never - all politicians are wonderful altruistic models of humanity who do a brilliant job?

The point is, if you don’t like what pollies do you can complain. At worst maybe occasionally you will find yourself being ridiculed on today tonight. You won’t (in Australia) usually find yourself in prison or getting a bullet to the back of the head (we are discussing politicians here - police officers are a different matter).

So express yourself and make all the noise you can. Because you can. Which is a right worth fighting whining for!

Content counts

Sunday, June 24th, 2007

When was the last time you put out a product brochure or press release without thinking about what it said?

When you create a prospectus or sales brochure you get the copy written by a professional - either in-house or a contracted copywriter. Do you put that amount of care into the copy on your web site? If so, well done you can ignore the rest.

Your web site may be the first contact a potential business partner or customer has with you. It should get far more readers than your paper material. So you should put at least as much resource into getting the copy right.

Web copy is different from print copy. It works differently. People interact with it differently. It needs to behave in many ways unique to this medium; not many brochures get syndicated and refactored for delivery on other brochures in real time without you knowing it do they?

Your copy must stand alone. It carries your message. It sells your property, fills your leases and shifts your units. If it doesn’t do the job sitting typed on a side of A4 it won’t do it on your web site - no matter how cool your designer thinks s/he is.

Make sure the copy for your site does what you need it to do, wherever you get it. Only then think about enhancing the message with design. Once that is done you have the core of a web site, so start improving conversion through experimentation and structure. Once all of that is done you can think about web toys. By then you may not want them.

WYSIWYG - ha!

Tuesday, June 12th, 2007

online editor
an early editor built for edsys

It is a little known fact that I wrote one of the earliest JavaScript WYSIWYG editors for IE4. It sucked. But it was better than anything else available at the time. It even did tables and forms (wow, I hear you ironise, but this is going back 6 or 7 years).

The little embedded WYSIWYG editor tries to make the transition from nasty word processors to nasty web pages easy for people. They fail pretty much without exception. Part of the problem is that browser implementation sucks; part is that website and CMS developers suck (yep, that’s me); and part is that content producers are lazy hacks.

The main issue though is that online what you see is never what you get. And nor should it be. Even if all browsers rendered HTML and CSS according to a properly written and unambiguous specification we would still have variation in appearance. Screen resolution, default fonts, viewport size, other types of user agents, user style sheets, the list is endless.

What can we do? Well first of all, live with it. Variation is not just inevitable it is a good thing. Make content clear and free of formatting so it can be refactored and rendered by all sorts of user agents. Get CSS to do its job. Use something like Markdown or Textile instead of a WYSIWYG editor and live with the limitations.

What can content producers do? Write well using language for emphasis, source appropriate media and structure your content for maximum impact. This makes the silly formatting tricks which are the province of the WYSIWYG editor unnecessary. Plan your content and introduce some consistency; this helps usability as well as making the publishing process easier. Finally, learn just a little bit of whatever flavour of (X)HTML your site uses. The content producers at AIA use a small subset of XHTML 1.0 and hand code almost everything. They are writers not web developers. They know enough to get the job done, rather than enough to be dangerous.