All posts by Lachlan Hunt

Directory Restructuring

Server-Side

For quite a while now, I’ve been thinking that the original directory structure I chose for my website didn’t quite match my needs. The only problem was, I didn’t want to break any links that already point to existing documents in those directories. The directories I wanted to move were /xhtml/, /css/, /zengarden/ and /script/. I wanted to put zengarden under CSS, and group the XHTML, CSS and Script directories under a single development directory, which I decided to call /dev/.

The solution I found was to move them as described, and use Apache’s Redirect directive from mod_alias. The rules I added to my .htaccess file took this form

Redirect permanent /xxx http://www.lachy.id.au/dev/xxx

Where xxx represents the XHTML, CSS, Script and ZenGarden directories. This directive causes Apache to respond with an HTTP 301 Moved Permanently status code, and the location for the user agent to find the actual resource. The only problem is that I needed to use the full URI, rather than a relative path for the redirection, which means that the same directives won’t work as I wanted for my testing server on my localhost, since any request for http://localhost/css/, for example, will redirect to http://www.lachy.id.au/dev/css/, rather than http://localhost/dev/css/.

So, the problem is solved, and I’ve got a much more appropriate, and hopefully permanent directory structure. This will benefit a lot for my CSS Zen Garden submission, Office 2003, which is listed in the Themes and Look-alikes section. It still uses the old URI, so if it broke, anyone wanting to see my design would be disappointed to see an unstyled document. There are also several other links on various other sites that I know about, and possibly others that I don’t, so it was very important that existing URIs didn’t break.

Hixie’s Ruling and Composite Attribute

MarkUp, Standards

Over the last week, the hot topic of discussion among several bloggers has been the uproar over Safari’s proposed HTML extensions, and Hixie has finally put forward his opinion, which pretty much sums up the reasons why none of the five proposals are any good.

  1. New DashboardML DOCTYPE
  2. Namespaces in HTML
  3. Namespaces in XHTML served as text/html
  4. Namespaces in XHTML served as an XML MIME Type
  5. Replace the XHTML namespace with an Apple namespace

In usual Hixie style, he points out and backs up all the reasons why none of those options are acceptable solutions to Apple‘s extensions, and for the most part, I agree with everything he said. However, the main focus of this post is not for praising Hixie for being the very wise man that he is — maybe another time, but I definately agree that a new DOCTYPE is not a good solution unless it were confined only to the dashboard. As I commented on for one of Eric Meyer’s posts, if Microsoft and Netscape had created their own DTD’s, we’d have no interoperable websites on the net, and it would further encourage the use of proprietary, presentational elements.

One point that Hixie didn’t touch on much, except to say that it was presentational, is the composite attribute. Dave Hyatt discussed this again in response to several people’s comments, including my own, that it should be in CSS, and attempted to explain the reasons behind this unfortunate decision of polluting HTML with additional presentational mark up instead.

He mentions that due to past experience of introducing proprietary extensions to CSS such as -moz-image-region that he invented which, as he claims, was largely derided by the CSS WG, and thus didn’t want to make the same mistake again. Well, my response to this is, which is better?

  1. Adding a proprietary extension to a language which specifically allows this using a special syntax, such as -khtml-composite? Or
  2. Extending a language which does not using the methods mentioned earlier, which as Hixe explained, is not acceptable.

Dave also mentions:

“We didn’t want to introduce a new CSS property, however, because how to composite should be specifiable anywhere you use an image in CSS properties like content, background-image, or list-style-image. However, normal specification of the foreground URL of an img tag is done in theHTMLitself. That meant there was no consistent solution that could be employed.”

I’m struggling to interpret that due to his exceptionally poor grammar – I guess he was in a rush when he wrote it. I think it means that if such a property were added to CSS, then it should apply equally to any image consistently whether it’s in the foreground (eg. <img src="uri"/>) or background, such as using the mentioned CSS properties. Dave, If your reading this, I think some clarification would be useful.

Anyway, I don’t see why such a property would not work. Couldn’t the property be used to determine how any elements content, including any text, images or other content, were rendered? Why can it only apply to foreground images, specifically, the <img/> element?

I’m not exactly sure what visual effect the composite attribute is supposed to achieve – I couldn’t find much documentation on it, and none that I found was related directly to the Dashboard. All I found was about the new Core Image graphics processing system, but it just lists the value names, without actually describing what each does; so some clarification on those would be good too. Perhaps then I might be able to understand Dave’s explanation.

It would seem that none of these extensions have been accepted by the majority of the Blogging community (at least the one’s I read), and none of the proposed solutions are really any good. So, I would have to finish up by agreeing with Hixie. The best way to proceed is to move the discussion to an open discussion list and design some acceptable, interoperable solutions. So let’s get brainstorming people, how could any of these extensions be made to work? I may come up with some more ideas once I more fully understand what exactly these extensions are supposed to do.

Safari’s Pseudo-Solution

MarkUp, Standards, User Agents

In light of the recent backlash against Safari’s HTML extensions, Dave Hyatt has come up with what he considers to be a reasonable solution that addresses most of the concerns and potential solutions raised by many such as Eric Meyer, and Tim Bray.

However, his solution involves extending HTML by adding an xmlns attribute, which is supposed to only be used in real XML, such as XHTML.

Seriously, what is the point of adding it to HTML? Why not just do it correctly with XHTML? I’ve heard the arguments that it’s not as easy to learn, and authors are already familiar with HTML 4.01, but I disagree.

Safari supports XHTML, and since these extensions are aimed at being used in Apple’s new Dashboard, there is no reason to follow the WHAT WG decision to be bugwards-compatible with IE, and thus extend HTML, especially when these additions are presentational, as I discussed earlier, and commented on again in Eric Meyer’s latest post on the topic.

Although Dave Hyatt does mention:

…the benefit comes when you switch to real XML. In the XML implementation, the namespace is completely real and effectively maps to a new language…

I think the Safari team should just go all the way, and implement these extensions purely as an XHTML module. Although, I would prefer that the presentational additions, such as the new composite attribute for the <img/> element were actually done as proprietary extensions to CSS. eg. -safari-composite: source-over;.

In conclusion, this is a quick fix to address recent concerns, which just isn’t quite good enough. It’s a pseudo-solution that’s come out of almost complete laziness to do things correctly!