Dashboard needs to be as easy as possible, that is one of apple’s goals, most web designers have no idea about namespaces and doctypes sadly, and really it doesn’t matter because this doesn’t have anything to do with the general internet, it’s apple using existing technology in a different way on the local level. The programs can use Cocoa programming too, and ::gasp:: other browsers/platforms don’t support that. “APPLE IS DESTROYING THE WEB!!111!!” Give me a break, this isn’t for the general internet, no one will use it for the general internet and it’s not a concern, anything Dave/Apple does to appease people is more than gratious of them. And on top of that, any of this that is going to be used on the web is being submitted for WHAT so that they can be ratified and used.

Also, yes reality check… Dashboard is not out, it’s not here now, and there is plenty of time for things to be refined, implemented and smoothed. It just seems to me that every blog I read has someone ranting and raving about how evil this is, and how none of Dave’s solutions are good enough and whatnot when really… in the grand scheme of things… none of it matters. Take a step back people, stop being idealogical fundamentalists and look at what’s going on, sure in concept it’s something to freak out and get up in arms about, but in reality it’s not going to do any harm whatsoever.

I’ve seen many people comparing this to the browser wars, marquee etc but no one is talking about what real damage this could cause… because there isn’t any, and people need to sit back and realise that.

When the WHAT decided to launch a new HTML dialect in the face of a module-based XHTML variant, I thought I had them figured out. If we cannot work with the coolest browser A, let’s have a retro movement that will give browser B and C time to catch up. Make it digestible below the level of abstraction needed to understand the concept of a namespace and call it “power to the people”. Claim further support from radical advocates of prominence in public forums by denouncing official working groups. Invent the wheel _without_ scripting technologies to make it innovative and glamourous. All in all, a sensible strategy for promoting browsers with inadequate XML support. But things are going downhill rather fast from here. So, who get’s to be the default namespace? We can put our companys name in the namespace and claim all of HTML for ourselves or we can forget about namespaces alltogether and leave the problem for future generations to solve. We can entertain the idea of a new HTML doctype with no restrictions to future tags and if we hurry, we can invent the canvas tag before the next guy. Forget that XML and namespaces are intended to deal with this very situation, they are far too complex for the human mind to comprehend. There may be an explosive growth in Firefox extensions using XML, XBL, XHTML, RDF and custom namespaces, but kids nowadays would rather trust extension authors that aren’t quite clever enough to prefix their tags. With all the “technical hurdles to the use of XML” in modern browsers, we’re simply better off using HTML instead of any old XUL rendering engine. Somehow it appears to me that these guys aren’t battling Microsoft – with recent developments, they even appear to be battling eachother. Not the browser war I’d hoped for, but oh! Don’t mention the war, right? I’ve lost focus on these developments, but one thing seems increasingly clear: If browser technology B and C had a working XML rendering engine with namespace support _none_ of this would even be an issue. It would be a trivial task! And namespace aware specifications such as XHTML, XHTML2, SVG, XBL2, XSLT, Xforms would _still_ be hip with the happening people. Enough “bitter irrational semantics over namespaces” already, but hey.

Really Eric, i think this is all just coming down to wasted deliberation, Apple/Hyatt’s can’t please everyone and i think the namespace solution is the perfect one semantics aside. Really, people need to stop getting so worked up about this, at first i was glad to see people stand up, and i still am, but now that he’s looking into solutions and taking in feedback i think it’s on the right path.

What i’d really like to see is some entires on what people are going to do with it, i can’t wait to see what you and Zeldman and others come up with.

Oh and is anyone else suprised he hasn’t chimed in on dashboard at all yet?

My point was that if Dashboard is not standards-based, it might make switching platforms that much harder for folks like me. considering Apple’s great investment in the “Switch” advertising campaign, you’d think that they’d bend over backwards to make switching simpler, not harder, like any other company that is working hard for my business… (You know the rest; thanks for the repost!)

I’m wondering if the Dashboard app could/will be/considered for/be ported to the Windows desktop. I’m assuming it would be, considering its core language: it wouldn’t seem to be that hard if it were in HTML/XHTML/XML. If it were standards-based, as Eric would like it to be, then porting it would be easier.

If not, it just may make the job for those of us about to switch platforms thatbend over backwards to make it simpler, not harder, like any other company that is working hard for my business, be it an insurance company, investment broker — whatever (and I’m really picky about my investment broker!).

Eric, I know you’d rather play with your daughter; I would, too. But (sorry for beginning a sentence with “but”) your input is essential to the resolution of this argument. Please: keep it up!

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…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.

Don’t get me wrong–I’m all for XHTML, but this is a matter of practicality. When a user sees a Dashboard widget, he doesn’t care (or even notice) if it’s built with state-of-the-art markup. He does notice if it’s slow and buggy.

Also, I’m entirely confident that Apple will make every effort to make their extensions part of the standards–standards are Apple’s friend on the web, and they’d be wise to drum up support for these new (cool) features among other up-and-coming browser vendors. Ben Hammersley has recently written that the browser wars are about to begin again, and this time, maybe it’ll be Apple, Mozilla, and Opera touting support for cool new standards–not Microsoft and IE 3.

It’s frustrating when nobody seems to be bringing up the pertinent point of “why HTML?” Widgets being shown on a desktop seem to have very little in common with hypertext documents. What does HTML bring to the table? The experience developers have with <h1>, <cite>, etc seems to have zero relevence to building desktop widgets.

Even if there were some relevence, what happens in the next iteration? It’s one element type now, but what happens when Apple decides that an extra couple of element types are needed? Will we end up with lots of documents that are sort-of-HTML-with-a-lot-of-Apple-element-types-in? It really seems to stink of the old browser wars, but most people don’t seem to want to say it directly for fear of offending somebody “on our side”, as opposed to the Microsoft camp. The front page of webstandards.org mentions that some people have concerns, but concludes “Overall, though, it’s not that big a deal.” What a joke, coming from an organisation that claims to promote the use of standards!

That’s time I could have spent playing with my daughter!

Amen! I don’t know enough about XML, DOCTYPE, or namespacing to either agree or disagree with your proposals, Eric, but your efforts to clarify these issued for the rest of us are always appreciated.

I also think that a major case of double standards is in effect here. If Microsoft were introducing new element types and trying to pollute HTML with them, everyone would be up in arms about it. But because it’s the “underdog”, everyone seems to be turning a blind eye. It’s not about who implements it, it’s the technology that matters!

RSS defines its own semantics, and everyone’s agreed to go along with its definitions.

If the mess of including hypertext in RSS is any indication, I don’t think it’s all that fair to say that the semantics defined by RSS have at all been agreed-upon—at least not to any acceptably reliable degree.