Weblog about markup & style by Anne van Kesteren

HREF - part 1

Since I don’t really have the time to set up a link weblog and it doesn’t seem to be really easy using wordpress, I’ll use link dumps like other weblogs do. (I provided some titles.)

4/28/2004 4:48 pm · Comments (0) · Links

Document layers

What if sites were build up in layers? How many layers would you need? Imagine you could decide how it worked. Currently, people are pushing each other to separate structure from style, which is quite easy to do. Just use the LINK element and learn HTML (beware, you probably don’t know it). Separating behavior and structure is possible as well, albeit more difficult in my opinion. Adding a simple onclick behavior from outside the document requires you to use ‘onload’, which makes things more complicated, since a user could have used ‘onload’ for something else. You can of course work around all these limitations, but a CSS approach would be easier, definitely.

Another thing that I find strange is that we have to use the SCRIPT element rather than something like rel=behavior. For XML documents it would be nice to have a <?xml-behavior?> processing instruction to add scripting to documents. Currently you can only add scripting if the client supports the XHTML namespace. In such cases, you can use xhtml:script, which feels like a hack (and actually is, since you rely on namespace knowledge that isn’t really necessary at all).

A third layer would be a layer of semantics. This could be added to same way as the behaviors to documents. Defining semantics is especially useful for search engines. Google knows HTML semantics and elements, but isn’t aware of you custom element HEADER. If you could define the semantic meaning of such an element, just like you can add style to an element, clients would not have problems with it.

(The current proposed version of XBL will have the problem that it relies on CSS:


I and Daniel Glazman had some discussion about this on IRC a while ago. The main problem was that someone could use XBL to calculate all the costs of bought products, but that it wouldn’t work anymore if someone switched CSS of.)

3:02 pm · Comments (3) · Thoughts



4/26/2004 3:26 pm · Comments Off · General

‘min-height’ in Safari

As you might know, Safari 1.2, doesn’t support min-height. While some people don’t really care about the Mac (like me, although I would want one) and others do I found a solution after I gave up. A person, who doesn’t see that much value in web standards, made a comment about the Safari failure (the complete site was readable, only visually not the same as Mozilla) and concluded that my CSS knowledge wasn’t sufficient. Of course, I didn’t like that comment and started thinking how he would have solved the problem which led me to tables, obviously.

I immediately thought of how I hate the CSS table model and directly after that I saw how it could solve my problem. Read these lines:

In CSS 2.1, the height of a cell box is the maximum of the table cell’s ‘height’ property and the minimum height required by the content (MIN). A value of ‘auto’ for ‘height’ implies a that the value MIN will be used for layout.

All I had to do to make min-height work cross-browser, was using something else:


Internet Explorer will ignore the display property (actually, it treats it like display:block;) and will handle height as min-height, since IEs handling of height is stupid.

All other browsers, including Safari (see the support charts) will make the DIV element behave like a table-cell (and create some anonymous elements around it), which makes the rules of the quote apply and everyone is happy!

4/24/2004 1:41 pm · Comments (4) · Style

Semantics versus structure

(Safari should support min-height so I can hack around for business pages. I think I’ll drop support for Safari 1.2 for that particular site. Dave Winer notices the Google + Blogger/Atom effect (after Matt, obviously). I have been using IRC for some time now, any Dutch people who are willing to join irc.mozilla.org/mozilla.nl for no particular reason? Note that the channel might not always be available and that we already have two member, me and Bas.)

To the point. Probably everyone who works or tries web standards has to make the simple choice. Choosing elements for the structural aspects or their semantic ones. Quite a simple example of an element, which is often being abused from a semantic point of view is the definition list and child elements (more precisely: the relationship between DT and DD). While everyone reading the specifications can read what their purpose is:

Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. The term is given by the DT element and is restricted to inline content. The description is given with a DD element that contains block-level content.

People, including myself, are using the structurally “defined” relation between DT and DD, while ignoring the semantical relationship. You could read SimpleBits: Numbered List Pairs for examples. It might be clear, or not, that we do that on purpose. Abusing the semantic value of some elements for structural benefit. Note that those semantic values are very loosely defined by HTML 4.01 and free for interpretation, which is what I and other people, are doing.

Using a DIV element with an appropriate CLASS attribute value, not ‘left’, ‘blue’ or any other presentational hint as you see on a lot of sites, feels a bit like a hack to me. While other people seem to really like that element, I try to avoid them as much as possible, using elements that are structurally “better”. So basically I see the web in different layers (like Photoshop I assume): structure, semantics, styling, behavior (yes, that is the order I prefer). It would be nice when the W3C released a CSS-alike language to define semantics. Behavior can be added as XBL though it relies to much on CSS in my humble opinion.

4/22/2004 9:03 pm · Comments (1) · Thoughts

You need a degree to understand them

David Emberton (source):

These days, the rebel youth aren’t so busy admiring Marx as they are giving each other tutorials on how to use XHTML Strict.

CSS are public, free and future-proof. Sounds great until you realise that: a) you need a degree to understand them; b) Microsoft doesn’t care about them; and c) they suck.

4/18/2004 8:21 pm · Comments (8) · General

The ABBR attribute

HTML 4.01 states:

This attribute should be used to provide an abbreviated form of the cell’s content, and may be rendered by user agents when appropriate in place of the cell’s content. Abbreviated names should be short since user agents may render them repeatedly. For instance, speech synthesizers may render the abbreviated headers relating to a particular cell before rendering that cell’s content.

My question, should a user agent always use it? If not, when would it be appropriate? Should it be implanted like:


Last question: should I use it for abbreviating week days?

4/17/2004 6:18 pm · Comments (5) · Thoughts

Image semantics

In this little write-up I will refer to document structures using CSS selectors. If you don’t fully understand it let the Selectoracle explain it to you, though I think everyone can follow it easily.

Moose made me think about image semantics when we were discussing object>h1 versus h1>object in a thread about one of his experiments. While I wanted to nest the OBJECT element inside the header element for practical purposes:

But actually, the image itself has semantics. These semantics are not defined by the elements around it, but by the image (maybe the file) itself. A simple search engine can’t extract those semantics from the image (I wonder if any software could) and therefore it needs a fallback; are you beginning to see the object>h1 picture?

If you think about this a little longer you are starting to realize that h1>img “doesn’t make sense” either (I’m putting quotes around that, this stuff is badly under defined, everyone can have their own interpretation/opinion about it), which leads to another reason to “dislike” the IMG element. We still have to use it though and since there isn’t any bot (that I know of) that can read both the semantics of HTML and images, I don’t think there is any problem, besides that it is “incorrect”.

Jukka K. Korpela wrote in an e-mail to www-style that an image has semantic meaning, like I stated above (After all, a logo (as a specific appearance, specified by image data) is content rather than stylistic variation.) and therefore, it should probably not be expressed using the content property, which is now proposed for CSS3 (my model, my model :-) (note that it may change any time anywhere)). And although he might be correct from a semantic point of view, having the content property gives document authors many options like having multiple style sheets (you might think of a print and screen logo). Personally, I love the CSS method: nl{content:url(nav.svg)}.

4/16/2004 11:25 pm · Comments (2) · Thoughts

Page 23

Ok, lets try it (lines 4-7) (details):

Student: Kan het zijn dat sommige mensen - ik weet niet precies hoe ik het zeggen moet - dat er zich in sommige mensen meer werkzame essentie beweegt en manifesteert dan in andere, ook al zijn ze zich totaal niet van hun essentie bewust?

5:04 pm · Comments (4) · General


Not very interesting, but I think I need one. A small guideline for comments. There are still people who don’t understand Tag all may not contain raw character data. I agree I could have chosen a better name for the wrapper element, but the name chosen back then by Simon was fine with me.

The idea is that you must (defined in some RFC) use a block level element and can’t start typing without adding a P element to name a simple example.

Another idea is that you use BLOCKQUOTE or Q instead of quotation marks (I can’t require it (same as must, see the RFC), unfortunately).

I will add a link to this “stupid” entry from the comment form, maybe you can add some suggestions here to make it less “stupid” (they don’t have to be related to my ridiculous commenting system).

4/15/2004 5:19 pm · Comments (6) · General