Older blog entries for dorward (starting at number 53)

On the dangers of opening one's mouth

I am now the primary maintainer of Catalyst::View::ContentNegotiation::XHTML. This is not one of the things I expected to happen when I woke up yesterday morning.

1. Every five seconds, someone is wrong on the Internet, and often they are wrong about content negotiation.

2. A fondness for simple markup rules (as found in XML) combined with a nagging dislike of Appendix C of the XHTML 1.0 specification (which makes the rules complicated again) and an interest in markup validation has led me to find out more than most people about HTTP.

3. I like Perl and I like Catalyst

When you combine these bits of information, it was almost inevitable that I would get myself involved with getting content negotiation Done Right in Catalyst.

The Perl motto is “There’s more than one way to do it” but, thanks to the CPAN, it could easily be “Someone has already done it for you” and so it is useful to think out loud in the Perl community (or to think into an IRC channel in this case).

Just as I was about to start learning how to write a Catalyst View module from scratch, Tomas Doran pointed me at his module, and it was pretty good.

Nothing is perfect though, so I contributed some tests and patches and it was better.

Time passed. Work continued. It got better without me. I took another look at it and found another possible improvement.

It turned out that providing too much help can be a little dangerous.

15:22 < t0m> Dorward: well volunteered, what was your CPAN id again?
15:23 < Dorward> Eeek
15:23 < Dorward> What have I done?!
15:23 < Penfold> made it better
15:23 < Penfold> be porud
15:23 <+mdk> t0m: nice one ++
15:23 < t0m> Made DORWARD primary maintainer of Catalyst::View::ContentNegotiation::XHTML.
15:23 < t0m> Made DORWARD primary maintainer of Catalyst::View::TT::XHTML.

This wasn’t quite how I planned getting my first CPAN commit, but it has made it through the PAUSE queue and should be available at a mirror near you soon.

Please feel free to take a look, give it a try (give Catalyst a try if you aren’t already), and submit comments and bug reports.

Syndicated 2009-09-18 03:47:13 from David Dorward

CSS Class (a phrase I hate)

I keep seeing the term “CSS Class” crop up, but it doesn’t have any official meaning. It doesn’t even have a consistent unofficial meaning. I’ve seen the phrase “CSS Class” applied to mean all of the following:

• HTML class
• CSS class selector
• Any CSS selector
• A CSS rule set

Often it is possible to work out what people really mean, but that isn’t always the case. This is an appeal — if you find yourself saying or writing “CSS Class”, please think about what you actually mean.

Syndicated 2009-09-14 14:27:43 from David Dorward

On combining title and alt on images

Henny mentioned the MAMA results of uses of alt and title text on images.

Opera MAMA early results: of a small sample of 5000 URLs Title and Alt used together in same IMG element 720 times. A pet peeve of mine.

When I queried this she responded:

@dorward No to TITLE + ALT, it duplicates info for some screen reader users http://snipr.com/hzpt8 We’ll check for duplication in next crawl

I can’t imagine any circumstance where the alt text should be the same as the title text — since the alt should be an alternative to the image, the title shouldn’t be able to add any information to that which is already expressed by the image.

If there was duplication, then I’d agree with Henny that it is a bad bit of markup; sometimes repetition can help get an important point across but image metadata is not the place to do this.

Hopefully the duplicate text check crawl that she mentioned will not have a high number of matches (my cynical side is telling me that this isn’t a hope I should cling to). I’ll be keeping an eye out for the results of that.

It does raise a question thought — if alt and title were to both appear on the same image, what should they contain?

Let us see what the specifications have to say about title and alt.

Let’s deal with the alt attribute. This is nice and simple.

HTML 4.01 says that alt is for an alternative to an image for when the image is not available (and is mandatory).

The use of alt text seems obvious enough to me, but perhaps that is because I’ve been writing it for years. The HTML5 draft has a detailed collection of use cases with examples should you be interested. The late Alan Flavell wrote an excellent guide to using alt text some years ago; it includes a wondeful set of examples of what not to do.

So, given that alt is relatively simple. What about the title attribute? HTML 4.01 says that title is for advisory information about an element, but is rather short on detail or examples of what that actually means. Let us look to the HTML5 draft for guidance.

It starts out with the basics, and retreads the ground covered in HTML 4.01.

The title attribute represents advisory information for the element, such as would be appropriate for a tooltip.

We then have some specific guidence for different types of elements, including images.

it could be the image credit or a description of the image

I hadn’t considered using it to provide a credit for the image, but it does seem to be a reasonable idea. It allows, for example, credit to be provided for an image that is used decoratively without breaking into the flow of text.

Using it for a description of the image seems a little odd though. We already have the longdesc attribute (even if we see little support for it in browsers). Why would one use the title attribute instead?

A little examination of HTML5 and I find:

There has been some suggestion that the longdesc attribute from HTML4 should be included. This has been considered and rejected in the past, but if new evidence is found showing the attribute to actually help users rather than harm them, it may be reconsidered.

So, it looks like HTML5 is dropping the attribute that allows a description to be expressed in markup (allowing paragraphs, emphasis and so on) for one which allows simple text strings.

I don’t understand how the attribute is harmful; if anyone has a summary of the reasoning behind this decision, then please let me know.

What other advisory information could be provided about an image?

Ian chipped in with the observation:

@dorward I see title overused more often than underused. Have Read guidelines which said an image without alt should have a title. Erm, no.

I can just about see a use case here. If we read “without alt” to mean “with blank alt text”, then I am reminded of several instances where I have read that screen users complained that their software informed them that there was an image but that as it lacked alt text they had no idea if it was important or not. Given that, I can understand the benefits of:

<img src="example.png" alt="" title="This is a decorative image">

I don’t like it though. It feels too much like a crutch to reassure screen reader users that the author isn’t making the mistakes that some other authors make, and it creates tooltips for many other users who are left wondering why they exist.

Syndicated 2009-05-18 20:40:00 from David Dorward

So Tumbler doesn't let you have a draft revision

My current CMS system involves writing blog entries on Tumblr and then (periodically) importing them onto my real blog. This gives me a convienient way to edit them and a nice preview.

A few days ago, I wrote a brief article about alt text and title attributes. Then I got into some further discussions over it, so I decided to edit it. My edits led me down a path of research involving multiple specifications and commentary and then I put it aside so I could prepare for my guests arriving for Eurovision.

At this stage, I saved my edits as a draft. Unfortunately, this removed the previously published version from Tumblr completely. “Whoops”. Clearly I didn’t understand Tumblr’s system — although I have learned from that mistake.

So, sorry for the broken links that will have appeared. I fully intend to finish my research and get it properly published. I just have some apple pie in the oven that I need to eat first.

Syndicated 2009-05-18 19:26:24 from David Dorward

rmathew, not a problem with the validator's parser, its behaviour is quite correct. The FAQ it links to with the error explains why.

rmathew, on including: use an offline preprocessor such as gcc or Dolt.

On states of CSS/JS: you can make the toggler a link to another page with the same content on it (and return false if the JS runs so that the link isn't followed when the content is revealed on the same page). Another option is to forget about the toggler and let people use scrollbars (which is what they are used to anyway!).

rmathew, take Hixie's rant seriously, and throw in a dose of Appendix C being a complete joke. The guidelines aren't really compatible with HTML, they are compatible, with most, but not all, browsers and depends on a bug in their HTML parsers! (Since in HTML a slash can end a tag, so <br /> actually means a line break followed by a greater than sign!

Browser implementations of XHTML (being served with the correct content type) generally suck too, Firefox turns of incremental rendering for example.

That said, XHTML is a nice language to work in, so you might want to write XHTML and transform it to HTML before it gets to the user (my CMS does that before I upload to the server).

Free copies of Windows? Well, I don't think that's an easy one to arrange.

IIS is not necessary for MSFT/SOA development. To deploy on a public site, it might be. I think that's fair for a company like MSFT to ask for. They have to make money somewhere.

Well fair enough, I didn't really expect anything else. That is Microsoft's business model after all. It just makes the statement:

[DotNetNuke] runs on software that you can get for free from Microsoft

... wrong.

avriettea: So, DotNetNuke runs on "software I can get for free from Microsoft". Excellent, I might take a look at it. How do I get my free copy of Windows and IIS from Microsoft? The page you linked to seemed to assume that people would have those already.

CMS

My CMS is now at a stage where it is capable of generating blog entries and an RSS feed. So I'm moving my blog over there now.

I still have to import all the old material and add a pile of features, but eating my own dogfood will encourage me to move forwards faster.