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.
- New DashboardML
- Namespaces in HTML
- Namespaces in XHTML served as text/html
- Namespaces in XHTML served as an XML MIME Type
- 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?
- Adding a proprietary extension to a language which specifically allows this using a special syntax, such as -khtml-composite? Or
- 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
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.