Comments on: Extended Dash

By: Lachy’s Log » Blog Archive » Hixie’s Ruling and Composite Attribute

Lachy’s Log » Blog Archive » Hixie’s Ruling and Composite Attribute — Thu, 24 Feb 2005 08:46:34 +0000

[...] hat 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 [...]

By: J Christopher

J Christopher — Tue, 13 Jul 2004 13:43:31 +0000

Dave has now done a test implementation of adding a default namespace for Dashboard widgets, using the namespace URI http://www.apple.com/2004/xhtml-extended/.

It was pointed out to me via e-mail that XHTML is perfect for this [...] except for Dave’s statement that the Dashboard widgets won’t be using XHTML.

These two statements seem contradictory. If they don’t intend to use XHTML in Dashboard widgets, shouldn’t they use “http://www.apple.com/2004/html-extended/”? I understand that the namespace URI doesn’t point to an actual document, but all the more reason to correct this now, right?

By: The Web Kit

The Web Kit — Sat, 10 Jul 2004 17:04:53 +0000

Extending HTML
As a Mac user, I’ve been closely following news concerning the state of web browsers on the Macintosh platform, and particularly news concerning my two favorite browsers, Safari and OmniWeb. Like a number of other web enthusiasts, I was concerned…

By: Lachy's Log

Lachy's Log — Sat, 10 Jul 2004 05:40:38 +0000

Safari’s Pseudo-Solution
Seriously, what is the point of adding it to HTML? Why not just do it correctly with XHTML? The Safari team should just go all the way, and implement these extensions purely as an XHTML module… this is a quick fix to address recent concerns, which ju…

By: James

James — Sat, 10 Jul 2004 05:26:46 +0000

From the XML point of view, re-namespacing the entire XHTML vocabulary seems like a bigger compatibility issue, since a namespace aware XML processor should treat “http://www.w3.org/1999/xhtml h1″ elements as being distinct from “http://www.apple.com/2004/xhtml-extended/ h1″ elements, for instance. So rather than just creating a small number of new element types, we have a whole host of new ones.

I know that he says that in an XHTML document you’d define an “apple” namespace prefix and only use it for elements and similar, but if Safari recognises all the other elements under this namespace, we could end up with pages on the web that display okay on Safari, but are unformatted on other browsers because it appears to be in a different XML dialect.

From the HTML perspective, it doesn’t seem like such a big deal, since the namespace declaration will simply be ignored. And if a future HTML spec is incompatible with these extensions, it provides a way to tell what the author intended.

By: ubiquitous minghong - My Blogger

ubiquitous minghong - My Blogger — Sat, 10 Jul 2004 04:08:00 +0000

Please extend the web correctly
Dave Hyatt is an open person who listens to comments. But unfortunately he seems to misunderstood the suggestions.

On his previous blog post, he mentioned 2 ways to extend the (X)HTML:

* Namespace mechanism
* New DOCTYPE declaration

…

By: Lachlan Hunt

Lachlan Hunt — Sat, 10 Jul 2004 02:36:29 +0000

I think the idea of using a new DOCTYPE is quite good, but I completely disagree when the purpose is to extend the language with presentational elements and attributes. is quite clearly presentational. Why couldn't they use to include a pre-written applet or other control that can do exactly what canvas is supposed to, or if not, then it should definately be included with a seperate namespace in a XHTML or other XML document. As for the compisite attribute for the element, I can only assume it's something presentational that should definately go into a stylesheet, such as CSS. Although, I don't particularly like proprietary CSS extensions, they're better than HTML because they don't pollute the markup, so they could always add it with their user agent prefix. eg. -safari-composite: whatever; (or whatever their prefix is). If Microsoft and Netscape had done what you are suggesting Safari do by creating a new DOCTYPE, where would we be now? We'd have millions of websites using MSIEML or NSML, and neither docuement would work well in the other browser, because of all the extra presentational elements and attributes that we may have ended up with (in addition to the ones we already have). Whether this would be better or worse than the current sitution we're in (ie. most sites either don't use a doctype, or many of those that do don't validate against it) is debatable, but I think it would be worse because it would further encourage authors into believing that using presentational markup was acceptable. I stand by what I said in my recent blog posting, Exploring Safari's ~~HTML~~ Tag-Soup Extensions, in that the Safari team should hang their heads in shame over these extensions. However, if they were semantic extensions that actually contributed to the structure of the widget, then I might not be so against them, it's just that they're clearly presentational, and thus should not be included in a semantic language.

By: Justin Makeig

Justin Makeig — Sat, 10 Jul 2004 01:06:25 +0000

The notion that XML namespaces are too difficult for the average HTML coder is hyperbole, if you ask me. Namespaces are vital in any language/environment that allows for reuse and extension (think: Java packages). However, given that any conceivable implementation will most likely be built using a DTD, there is little utility in using namespaces. DTDs are namespace-agnostic by design. Pseudo-namespaces can be fudged by creating elements with semi-colons in their names. My advice would be to move toward an XML Schema to define gadgets. A custom schema would allow Apple engineers to create a lean and mean HTML-like vocabulary, without the vagaries of any current X/HTML implementations. The rendering engine that would consume these XML instances could be significantly simplified from the current "what would Netscape 4 do?" methodology. More importantly, however, schemas can be built for reuse, meaning that you or I could design our own sub-vocabularies by extension or composition of the base Apple vocabulary. Dashboard is an amazing opportunity to move toward a better world with truly extensible and reusable components where there's no such thing as "quirks mode". Apple must take some leadership, rather than undermining the progress toward standards we have already made.

By: ken

ken — Fri, 09 Jul 2004 23:00:27 +0000

This is a possible suggestion for Dave – there’s no version number in his proposed identifier. Maybe it’d be safer to have one.

By: Hixie's Natural Log: Extending HTML

Hixie's Natural Log: Extending HTML — Wed, 30 Nov -0001 00:00:00 +0000

[...] There are other problems with DOCTYPEs. Eric unintentionally
reminded me of one when he said:

IBM
already does something like this, having created an “IBM XHTML 1.1 [...]