Comments on: Don’t read this

By: Oliver

Oliver — Sun, 09 Dec 2007 10:17:29 +0000

I think at least some of the drag and drop stuff actually comes from matching IE :(

I could be wrong though, it may only be the JS api to drag and drop that comes from IE, but i vaguely recall that it was only the ability to set a drag image that was unique to WebKit.

By: Justin

Justin — Tue, 04 Dec 2007 14:41:57 +0000

OH SNAP IT IS ON LIKE DONKEY KONG!

By: bill

bill — Tue, 04 Dec 2007 14:31:32 +0000

You make a damn fine point Mark. Particularly this line:

“WebKit is used heavily in many non-browser contexts on Mac OS X. Mail, Dashboard, iChat, Adium, Help, etc all use WebKit to display content in their own way. Clients such as Mail cannot enable JavaScript for security reasons and yet need control over elements of the behaviour of HTML that they display”

If only the page that had started me off on the tirade to begin with had explained it so clearly perhaps I wouldn’t have gotten upset to begin with. I retract my hatred of WebKit for that reason.

You do know now though that you’ve made me look like a moron on my own website so I do have to fight you. You’ve been forewarned Mr. Rowe. MORTAL ENEMIES!

By: Mark Rowe

Mark Rowe — Sat, 24 Nov 2007 09:04:31 +0000

The CSS specification makes allowances for vendor-specific keywords and property names such as those you are complaining about. There are several reasons why a CSS property may have the “-webkit-” prefix. The two most common are that it may be present in a draft of the CSS specification and thus subject to change in the future, or it may be a proposed addition to a future CSS specification, such as the recent CSS transformation properties. The purpose of the prefix here is to give fair warning to content authors that make use of the property that it is not standard and is subject to change. This allows content authors to experiment with CSS properties which are still in flux.

Two other reasons exist that you may not have considered: properties that are designed to aid in WebKit’s use in non-browser applications, and properties designed to assist in the implementation of the WebKit engine. As you may know, WebKit is used heavily in many non-browser contexts on Mac OS X. Mail, Dashboard, iChat, Adium, Help, etc all use WebKit to display content in their own way. Clients such as Mail cannot enable JavaScript for security reasons and yet need control over elements of the behaviour of HTML that they display. Others such as iChat, Adium, and Dashboard may desire behaviour which helps their web-based portions behave like a native application with minimal effort on the applications behalf.

Further, in Safari 3 common form elements such as text fields, text areas, buttons, and checkboxes are all rendered by the WebKit engine rather than using native NSView-based controls like in previous versions. The rendering of these elements, and many others, is specified via a CSS stylesheet yet there is no standard way to specify properties that are needed to control the appearance of these elements.

These are exactly the reasons that the CSS specification allows for vendor-prefixed properties and keywords. If you still feel inclined to hate on WebKit, keep in mind that IE and Mozilla have theirs too.

By: Justin

Justin — Fri, 23 Nov 2007 14:29:56 +0000

That last line was brilliant.

It’s funny that they explicitly state in their intro that the goal of css is to separate style from structure. Then they proceed to pollute that by mixing behavior with style (in a completely proprietary way at that). Disgusting.

I’m sure their argument is that they do support standards, but provide a superset of them to allow for richer applications that use webkit. But you’re absolutely right, anything being styled with css was obviously structured with markup, and therefore should be scriptable. No reason to provide a ridiculous attribute like that. I’ll shut up now.