Category Archives: MarkUp

SGML, (X)HTML, XML and other markup languages.

Hixie’s Ruling and Composite Attribute

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

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!

Exploring Safari’s HTML Tag-Soup Extensions

Like everyone one else, I thought the days of browser vendors adding proprietary extension to HTML was over. Sadly, I was wrong: Safari has decided to join in on the game. They’ve now introduced a <canvas> element as well as a new composite attribute for the <img> element. Not only are both of these presentational attributes, they’ve been added to HTML, while still using the HTML 4.01 doctypes.

Of course, Dave Hyatt attempted to explain with a follow up post the reasons for making these extension to HTML and not using XHTML and adding them with a different namespace. Also, as he points out, others suggested that they should have used SVG, yet fails to explain with any valid reason, except by saying that it would have basically been too difficult and time consuming. IMO, that’s just plain lazy, and I would have expected better from Apple. Sorry Dave, I have to agree with Eric Meyer on this one — this is big a mistake, and I think the Safari team should hang their heads in shame!