Surfin' Safari

Front Page  -  Technorati

Ian Hickson comments on Apple's HTML extensions and points out that all of the solutions suggested so far are inappropriate. I'll be eagerly awaiting the responses of both Tim and Eric to this entry.

Ian also takes Apple to task for inventing new tags without discussing them in a standards forum first. I think Ian has gotten his wires crossed a bit. For whatever reason, he (and others) are equating a beta release of Tiger with a shipping release of Tiger. Until Apple actually ships Tiger, then we have not yet extended HTML. What you see in the Tiger beta is a proposal. The syntax of these tags is not frozen, as is evidenced by the fact that I'm willing to move them into a completely different namespace! The documentation delivered to Dashboard authors during WWDC even warns that the syntax of these tags has not yet been finalized.

To criticize Apple for not discussing the syntax of tags prior to releasing a piece of beta software is unfair. We are willing to discuss these elements in an open forum like the WHAT-WG. You can see our proposal for canvas and for the new form controls, since we released the complete source of these extensions in WebCore-146, and anyone can download it to view the current APIs. I believe we are being quite open in our process regarding these extensions.

Several people questioned the presentational aspect of the composite attribute. In an earlier blog entry I had mentioned we would like to ultimately standardize our extensions. This attribute is an exception. We are aware that this functionality should be in CSS rather than in the HTML itself.

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. Examples of such properties are content, background-image, and list-style-image. However, normal specification of the foreground URL of an img tag is done in the HTML itself... so there was no consistent solution that could be employed.

Ideally you'd like the composite operation to be part of the image value, just as you might like cropping (indicating a sub-region of the image to use) to be part of the image value, but you are prevented from doing this with the img tag by the fact that a portion of the image value, the URL, is specified in the HTML itself.

It made little sense to invent a new CSS property that would only apply to this tag just to specify the compositing operation when the better way to do this from a purist CSS perspective would be more fundamental, affecting any place where a URL value could be used to represent an image.

I invented -moz-image-region in CSS to solve a similar problem in Mozilla (the sub-region problem), and this property was largely derided by the CSS WG, and so I knew better than to repeat the same mistake with a -khtml-composite property.

Ok, here is what I have implemented to handle the four HTML extensions that Apple has made so far. I implemented Eric Meyer's default namespace proposal.

In HTML, in order for Safari or other Web Kit applications to recognize the new extensions, you must declare a default namespace on your root html element. This namespace's value at the moment is:

http://www.apple.com/2004/xhtml-extended/

Feedback on the above namespace identifier is welcome, if you think there's a better choice. Note that in HTML this namespace support isn't real. The default namespace declaration is all that will be checked, and it will act as a global switch that will just turn on all the HTML extensions.

However, 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, Apple Extended XHTML, that has all the functionality of XHTML plus the extensions. In other words, in XML you can declare the namespace for real, use it with prefixes, use it only on canvas tags to keep the rest of the doc pure XHTML, etc.

I have not yet committed this solution, because I want to see if this meets with public approval first. Please trackback with suggestions and/or amendments.

I received more feedback on our HTML extensions, and some people made some good suggestions for how Safari should handle extensions to HTML. There were essentially three good ideas that were pointed out to me (along with a host of really bad ones).

Tim Bray suggested namespacing the extensions we've made to HTML. Eric Meyer suggested this as well. The idea would be that you could feed your HTML with the namespace declaration to an HTML parser and it would essentially have namespace support and understand how to handle the namespaced content. This is my favorite of the suggestions, since the namespace could effectively be hacked and only allowed on the root element. This seems like a minor cut-and-paste requirement to impose on Dashboard authors that want to use the new tags and attributes.

A second suggestion was to make a special DTD. I don't like this suggestion as much, since doctypes are used for setting browser modes, and I don't want to impose a particular mode on Dashboard widget authors.

A third suggestion was to restrict these tags and attributes only to Dashboard. This seems reasonable on the surface but would be difficult to do in practice, and besides, as I stated before, we actually are submitting these extensions to WHAT-WG for review anyway. This means the intent is for them to find their way into HTML eventually.

I'll look into what it would take to implement the first suggestion. It sounds to me like people will be satisfied with such a solution. I do wonder what to do with the new values to the type attribute on the input element. Search and range are new values to an already-existing attribute, and so I'm not sure how to mollify people on this one. Breaking those out into new attributes not only makes little sense to me, since it allows for a contradictory type clash (by specifying multiple attributes), but it also would complicate the code in WebCore that routinely switches on the type of the input element.

Going forward, I'm curious what the reaction will be as WHAT-WG works to further extend HTML. Assuming that the W3C has really decreed HTML4 to be obsolete, what happens when a proposal is made by multiple browser vendors to extend it? If the W3C rejects it, should the browser vendors be forced to keep their content namespaced forever? I guess we'll cross that bridge when we come to it.

A few people have written me expressing concern over the extensions that Apple has made to HTML in order to support Safari RSS and Dashboard. I wanted to explain what we've done and hopefully clear up any confusion.

Let's start by talking about the contenteditable attribute and drag and drop. I bring these up first because what we implemented is exactly compatible with WinIE. In the case of contenteditable, we have no choice regarding syntax. We have received many bugs to support already-deployed systems that use contenteditable, and so we are constrained syntactically. Had we gone our own route, we still wouldn't work with the Web pages that use it, and it would be unrealistic to expect all of those Web sites to modify their systems simply to support Safari. This is especially true if you consider that Web sites frequently deploy systems that they didn't write in the first place, and so they wouldn't know how to modify them anyway.

Drag and drop is a similar situation. Web sites use it, and so we need to support it. We already support dozens of WinIE-invented properties, many of which are incredibly useful and well-specified, so I'm a bit confused as to why contenteditable and drag and drop are creating any stir at all. These attributes are no different from innerHTML or offsetWidth and offsetHeight or innerText or oncontextmenu or any one of the other WinIE extensions that Safari has supported since its first beta 18 months ago.

We have a phrase we like to use here on the Safari team, and that's "real-world standards compliance." What that means is that where possible we attempt to be fully compatible with the W3C standards, but we also want to support the real-world standards, i.e., extensions that for better or worse have become de facto standards. If you really do believe we should not have implemented contenteditable, then you are simply out of touch with reality.

As for the Dashboard extensions that involve changing HTML, there are exactly four of them. We've tried to keep the number to a minimum, but this functionality was required in order to build the gadgets. Let me outline them again:

(1) Slider controls. This is not only used by Dashboard but also by Safari RSS, and so this feature cannot be restricted only to the Dashboard.
(2) Search fields. Again, this feature is used by Dashboard and Safari RSS.
(3) The new composite attribute on the img tag. This feature is used only by Dashboard.
(4) The canvas tag. This feature is used only by Dashboard.

The principal complaint seems to be that we should not be polluting HTML. However, I'm not sure what we should have done instead. I can outline some of your suggestions and explain why we discarded them.

First, it was suggested that the widgets be written in XML rather than HTML and that all of the new tags and attributes be namespaced. However, this would have dramatically increased the complexity of crafting Dashboard widgets. People know how to write HTML, but most of those same people have never written an XML file, and namespaces are a point of confusion.

In addition there are technical hurdles to the use of XML. Every modern browser, including Mozilla and Safari, is much worse at XHTML than at HTML. People tend to foolishly gloss over the transition from one to the other, thinking that code you write for one will "just work" when you switch to XHTML. That simply isn't true. If you look at XHTML in both Mozilla and Safari and compare it to HTML, you'll see that it's slower, non-incremental, and generally buggier than HTML.

An example of a feature that won't "just work" when moved from HTML to XHTML is editing. The serialization model is totally different for XHTML, and HTML elements that have to be written out when you get the raw markup must know to do so using XML-style syntax in XHTML documents. Editing must be able to serialize namespaces, and ideally even preserve the namespace prefixes that were used at various points in the document as well as the use of default namespaces as set up by the author. Right off the bat I've outlined a challenging editing feature that only exists in the XHTML world. There are many more examples of these kinds of problems.

The perfect example of a widget that combines editing with HTML extensions is the Stickies widget. We simply could not have moved this widget to XHTML without doing an enormous amount of XML work.

A second complaint leveled against us was over the canvas tag, namely that it should have been done using SVG. My response to this is simple. Go to the w3c Web site and print out the SVG specification. Twenty minutes later, after you've killed a few dozen trees, then maybe you'll have an appreciation for why this wasn't practical.

Remember that SVG would have forced the use of XHTML, which had all the problems outlined above. Now add to that time the amount of work that would be required to get even a rudimentary SVG implementation going. Now factor in the time it would have taken to make that implementation perform well enough when compared with a programmatic counterpart like the canvas. Canvas only took a handful of days to implement. SVG would take months to implement.

In other words, in an ideal world where we had two years to craft Dashboard, maybe we could have used XHTML and SVG, but we aren't living in that ideal world. We can basically manage only one "huge" layout engine feature in a development cycle, and given our developer feedback the choice of HTML editing as the feature to focus on this cycle was clear. We would still love to implement SVG and XSLT and other great technologies in the future, but we simply can't do everything at once.

Finally we have submitted all of our extensions to the WHAT-WG for review. The slider in particular is already in the Web Forms draft. It is our hope that these HTML extensions will ultimately be standardized by a working group, but I wanted to emphasize that we are working with other browser vendors such as Opera and Mozilla to ensure that these extensions are implementable in those browsers and that these extensions can be standardized. We are not simply off "doing our own thing."

Another extension we made to HTML is a new element called the canvas. This element is essentially an image element that supports programmatic drawing. The way it works is that you can invoke a method called getContext on the canvas and then you have access to a whole range of 2d drawing calls. This element is how the hands of the Dashboard clock are drawn in HTML. The canvas fully participates in CSS styling too, so you can give it borders or background images while still painting the foreground content programmatically.

In addition to the canvas element, we've also introduced a new attribute onto the img element. The composite attribute allows you to control how an image gets composited. The default is source-over, which is how images are normally composited on the Web, but now we've introduced other values for more complex compositing operations. Especially in the Dashboard with its transparent windows, these other compositing operations become useful, since you can use this feature to "punch holes" to the desktop, allowing for all sorts of wild irregular shapes.

The new WebCore also supports HTML editing. You can specify editable regions in a page using the contenteditable attribute (which maps to a CSS property behind the scenes, so you can even set that property in your user stylesheets if you want to get crazy). We've also added a selection object so that you can get the current selection, and of course support for execCommand so that you can perform operations on the selection. And yes, so that you can actually tell what you're doing stylistically, getComputedStyle is now also supported.

One reader of my previous entry (in the trackbacks) expressed concern that only Dashboard widget apps could execute native code. Well, we have an answer to that as well. You see, we're working with other browser vendors to extend the plugin API to add scriptability. See this link for more information. This means you can obviously execute native code from within any WebKit application's Web pages through the use of scriptable plugins.

Todd Dominey writes about Dashboard in his blog and asks some questions that I'd like to clear up.

A Dashboard widget is a bundle that contains a principal HTML file and any supporting code that the widget requires (be it CSS, JS, images, or native code). A widget can add an optional interface to native code, written in Objective-C, that can be bound into JavaScript and made accessible from the HTML document's JS window object.

In other words, an address book widget could inject a property called "addressBook" into the JS window object of an address book widget's HTML document, and then expose methods and properties on that object that can be invoked from the JS. This effectively allows you to execute native code through the use of this special type of plugin.

The "native code as a service accessible from JS" model should be familiar to anyone who has used XPCOM with XUL. It's essentially the same idea. Extensions to the Firefox browser that contain native code can expose that native code to script as an XPCOM service, and then that object can be obtained from JS and have methods/properties invoked.

Again, when viewed from a certain perspective, this is a competitive Web browser feature that has been fused with Expose. These widgets that might otherwise have had to be inside the browser window as sidebar panels or toolbars have been set free by the brilliant idea of using Expose.

Anyway, some points about this model.
(1) The native plugin code must be owned by root. This means that in order for a Dashboard widget that contains one of these special types of plugins to execute that code, you have to enter a root account password (to chown the plugin code). This plugin code cannot execute, therefore, without the widget being "blessed" just as an application that you might install on your system must be.
(2) This plugin will not be present in Safari or other WebKit applications, and is only accessible from Dashboard.
(3) The dashboard object is also exposed on the JS window object of the HTML document and has methods for "meta-functions" that the Dashboard can execute.

As for many of the animations, fades, slides, etc in the widgets themselves., they simply look so damn cool because of Safari's rich support for CSS3 used in conjunction with DHTML. Do you know what I talked about at WWDC? Image replacement. Sliding doors. Using opacity to create fade effects. CSS3 text truncation. Web standards. All of which are being used to full effect in Dashboard widgets. Our standards support has grown so rich and our engine has become so smooth at effects that people are constantly mistaking pure JS/DHTML/CSS stuff that people are doing for something fancier. I've heard "That's HTML?!" several times in the past week.

Now it is true that we have made many extensions to WebCore, but only in places where there are holes in HTML that must be filled. And even then, we have tried to implement compatible models or to design so that our enhancements could be standardized in the future.

For example, the new WebCore supports all of WinIE's drag events, and that's how drag and drop is done in the Dashboard. So at the same time we added this rich support to WebCore, we also added support for a feature that can now be used in Web pages in a compatible fashion with WinIE. We started with a compatible base and enhanced drag and drop to allow you to dynamically set the drag image and even enhanced CSS with a new drag pseudo-class so that you could re-resolve style on the element while it's being dragged, but at the core, we made sure to pick a practical starting point.

In other examples, we added support for new slider widgets and search field widgets (wrapping NSSlider and NSSearchField respectively). HTML is missing these widgets, and so we had to add them so that Dashboard widgets could use them. But even there we did so in a way that is designed to be compatible with other browsers.

I haven't had a chance to talk about this, but I thought I'd again start by briefly clearing up a point of confusion. Safari RSS is not the name of the entire Safari browser on Tiger. It is the name of the RSS/Atom feature in Safari itself. If you pull down the About information in Safari on Tiger, you'll see that the version is 2.0.

One of the new features added to WebCore is an HTML wrapper for the Cocoa NSSearchField, which means you will be able to use this control in your Web pages and Dashboard widgets.

The syntax is:

<input type="search">

The incremental attribute can be used to control whether or not the search is performed as you type.

The placeholder attribute can be used to set the greyed placeholder text in the control.

The autosave attribute allows you to specify an autosave name for your search results in the dropdown. What's cool about the autosave is that it's global, which means that two Web sites could put up a search field with an autosave name of google and then they would share the search results. (Since the actual result values are not accessible to the page there is no privacy violation.)

The results attribute allows you to specify how many results should be displayed in the dropdown.

The search DOM event fires at the precise time the search should be performed and obeys the heuristic for the control, so you don't have to trap key and click events at all. You can use the onsearch attribute on the control to respond when the search happens.

When submitted, the search control will save the submitted result, so that the user can select it from the dropdown when returning to the page.

In addition the search control is a subclass of NSTextField and also supports all of the functionality of the text input element, so you can make it readonly, set a maxlength, etc.

The search control will also even degrade gracefully in other browsers, since they won't recognize the unknown type and so will just use a text field instead.

If you have the 1.3 preview for Panther or are playing with Tiger, you can try this feature out. It works in both.