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
DOCTYPE - 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 <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.
While I do not want to speak for Hyatt, I believe he is attempting to explain that the composite attribute is a one-for-one modifier of an image.
The problem with using CSS instead of html for composite=”…” is the inability to apply such an attribute to background images or images declared in content: “…”. If you did so on a div with a background image and an image declared in the content, the composite applies to both of the images.
The point of the composite attribute is to be able to discretely control how a single image is composited with underlying graphics. Short of introducing multiple CSS tags (maybe this would be the better solution ?!?), HTML, he argues, was Apple’s next best bet.
Maybe the better solution is to just make dashboard load obj-c bundles and have a plugin architecture so that they are still “light weight” applications. From my understanding the dashboard widgets all run in the same process so having bundles load with obj-c code instead of javascript and html shouldn’t make any real difference. It would also stop those html css purist girls from their crying game and most likely it would save a lot of unneccessary work on Apples part as you would need to have the extension to html full stop. I maybe missing the point to why the widgets use javascript and html, but sometimes the solution to the problem is to have a different solution.
I disagree with the previous poster. I think the decision to have Dashboard widgets be HTML/JavaScript is a great one. The number of people who could program in Objective-C is miniscule compared to those who can code in HTML/JavaScript.
This means we will see many, many more widgets than there would have been. A lot of them will be worthless, but many won’t be.