Posts in the Browsers Category

To paraphrase Tim Bray, I had thought I’d said enough about the Dashboard and its markup, but when Dave Hyatt says he’s interested in hearing your thoughts, out loud you think.  Dave’s interest in my thoughts was sparked by Ian Hickson‘s post about extending HTML, where he raised objections to all the technical proposals made thus far and advocated working with the WHAT WG before adding anything new.  So let me first establish my baseline for my thinking on the subject, both past and present:

Dashboard will happen, and will be present in Tiger, and will have at least the features described thus far.  All that remains is to advocate for interoperability with standards.

That isn’t some sort of admission of defeat: I’m really looking forward to the Dashboard.  I think it’s a great thing.  I think it shows how, with just a little bit of extension, the standards we already know can be used in compelling and useful ways, and for that matter how standards can yield powerful applications on their own.  The baseline assumption I make above is a way of establishing the parameters for my discussions of the subject.  It helps keep me focused.

In order to keep things clean, I proposed an approach centering around a new DOCTYPE, and Tim Bray proposed another revolving around namespacing.  Ian pointed out the technical flaws in all of our suggestions.  Strictly speaking, Ian’s right: there are technical problems with each of the proposed solutions.  In the world of pragmatic standards, though, what’s important is making things work as necessary to get the job done.  Thus my approach.  You haven’t heard me complain about the addition of contenteditable to the Web Core’s DOM, for example.  Why would I?  Dave’s right to add it.

It seems that both Tim and Ian felt that creating a new DOCTYPE was a poor idea; one reason was that it would mean recreating the entirety of HTML in DashboardML, with elements bearing the same name and given (presumably) the same semantics.  I don’t really see why that’s a problem, since it’s already been done once before, for a little number we call XHTML.  Now, it might very well be a better idea to create WHATML instead of DashboardML.  That’s fine with me; in fact, I mentioned that as a possibility in my proposal.  The actual name and home of the new language doesn’t much matter to me, although I should point out that whoever is responsible for the new language, it’s going to require either a new DOCTYPE or some kind of namespacing solution.  If Apple’s additions can be accepted by the WHAT WG in time to get Dashboard shipped with Tiger, then great.  If not, they’ll have to move ahead without that imprimatur.  My goal is to advocate that they do so in a standards-friendly way.

In response to my comment that I thought Dashboard would be better off as XML instead of HTML, because that way you can make up whatever markup is needed, Ian said:

So let me get this right. It’s ok to send proprietary non-standard markup over the Web, so long as the angle brackets are XML angle brackets and not HTML angle brackets?

In a word, yes.  That’s what the W3C has been telling us for a while now, so why would I think otherwise?  Sure, the W3C publishes new stuff using XML and it’s all been thoroughly vetted and worked over and generally committeed to death, and that’s great.  But XML makes it possible to invent any markup language you like.  So far as I can tell, that’s kind of its point.  As long as things are well-formed, you’re good; if you’re both well-formed and valid, then angels descend from the markup heavens to sing your praises.

HTML is a well-defined, long-understood (almost-)SGML application.  Changing it willy-nilly is like making up new words to add to English.  (Hey, did you see that roopyrastic article in last month’s Scientific American?)  On the other hand, if you create a new XML language, then you’ve gone the Esperanto route.  The language is as valid as you say it is, and it is a whole new thing, but at least you’re not polluting an existing language with stuff you made up.

So with XML, anyone can make up anything and release it into the wild.  It might be argued that to send new XML languages flying around the public Web is a technological rebirth of the Tower of Babel, to which I would respond, “What else did you think was going to happen?”  In fact, it’s been happening for a while, as the widespread use of RSS will attest.  I haven’t noticed that being a major problem for anyone, and in fact you can combine RSS and CSS to display them in a browser.  That doesn’t seem to be a problem either.

Besides, all of the XML-centric solutions, flawed or not, were excluded by Dave from the outset when he said that Dashboard widgets needed to be HTML, not XML.  The reason given was to lower the entry barrier for would-be widget developers.  I personally don’t agree with that perspective, as I believe anyone skilled enough to create a decent widget will find XHTML (or even namespacing) syntax the least of their concerns.  My disagreement isn’t terribly relevant, though, since I’m not the one defining the way Dashboard widgets work.

As for the concern that adding new stuff to HTML will leave it free of semantics and confuse everyone, I don’t accept that at all.  The semantics that exist in HTML, XHML, and so on exist because we’ve collectively agreed on what they mean.  I don’t mean that we all held a big convention and voted on the meaning of h2.  The HTML specification defined what h2 means semantically, and the rest of us (authors, editors, search engines, etc.) tacitly agreed to go along with that definition.  The same thing can happen again—and, in RSS, already has.  RSS defines its own semantics, and everyone’s agreed to go along with its definitions.  It helps that the elements are given obvious names like description, of course.  RSS also has a title element for every entry in the feed.  Yet nobody, so far as I know, has gotten those title elements confused with HTML’s title element.

So now what?  Now the team at Apple keeps pushing forward to make Dashboard the best product it can be while still making it as easy to develop for as possible.  Fortunately, Dave is willing to publicly discuss how that will be accomplished, which is nothing short of amazing (although totally in keeping with what I know of Dave).  He has also said Apple is willing to submit their additions to the WHAT WG for discussion.  I honestly don’t know what more one could ask for at this juncture.  There is every opportunity to work with Apple (rather than protesting against it) to make sure that Dashboard widgets interoperate with the Web’s foundations… or at least don’t cause unnecessary problems.  Apple is listening.  It’s up to us to talk with them, understanding their needs and limitations while making clear our concerns and suggestions.

Despite my complete lack of time and reluctance to add still more mail to my bulging Inbox, I may well have to subscribe to the WHAT WG public mailing list.

• Dashboard Again was published on Thursday, July 15th, 2004.
• It was assigned to the Browsers and Standards categories.
• There have been eighteen replies.

It’s been interesting to see the back-and-forth over Dashboard the past few days.  Dave‘s posts have been greatly illuminating, and I belatedly discovered Tim Bray‘s initial reaction and further thoughts on the topic.  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/.  That doesn’t (yet?) point to an actual document, but that’s okay; URIs don’t have to refer to a specific resource.  They just have to be unique.  This is in contrast to URLs, which in theory have to point to something that actually exists.  Although clearly reality has a long way to go before it catches up with that theory.

As Dave points out, his approach not only makes it possible for HTML to be extended without breaking with existing standards, it also provides a handy “pay attention to the Dashboard stuff” trigger and it opens a clear path toward supporting XML-based widgets in the future.  This is all kinds of cool, and I can’t see any real drawbacks.  If you do, let Dave know, or comment on this post; I’ll collect them (since Dave doesn’t presently have commenting on his site) for his review.

Despite it being Dave’s second choice, the “create a new DOCTYPE” idea is something I want to discuss in a little more detail, if only to illustrate how it can work.  Here’s a markup example of an amazingly stupid and useless widget using a hypothetical DashboardML DTD.

<!DOCTYPE html SYSTEM
  "http://www.apple.com/dtd/2004/dashboardml-10.dtd">
<html>
<head>
<title>myWidget</title>
<style type="text/css">
body {background: aquamarine;}
</style>
<script type="text/javascript">
function startup() {
  alert('Happy!  Joy!');
}
</script>
</head>
<body onload="startup();">
<canvas blah="foo" yadda="baz">
<h1>Widget!</h1>
<div class="main">
<p>So cool.</p>
<p>So fine.</p>
</div>
<img src="yar.gif" composite="punchout" alt="Yar!">
<p id="footer">copyleft nobody</p>
</body>
</html>

By referring to a DTD defining a language that looks just like HTML except for the canvas element and composite attribute, along with any other additions, the markup stays free of explicit namespacing and works the way authors already expect.  It really is that simple.  IBM already does something like this, having created an “IBM XHTML 1.1 Transitional” DTD that’s used throughout their Web presence.  The comments at the top of the DTD file explain how it’s different than regular old XHTML, but the executive summary is that it permits some old table-and-spacer-era markup hacks in an XHTML environment.  If you run an IBM-XHTML compliant document through a validator that loads and uses IBM’s DTD to check over the document’s markup, then the document will validate.  The same thing could be done for Dashboard—or for any other project, really.  That’s the beauty of it.  We aren’t constrained to HTML any more, nor even to XHTML.  We’re only constrained by what clients will support… as always.

(It was pointed out to me via e-mail that XHTML is perfect for this, because it’s already modularized so all you have to do is tack on another module.  That would be quite true, except for Dave’s statement that the Dashboard widgets won’t be using XHTML.)

The other potential problem with my suggestion, according to Dave, is that the DOCTYPE is used to pick a rendering mode in current browsers.  Dave says he doesn’t want to restrict widget authors to one mode or the other.  Now, I’d personally have no problem forcing all widgets to be rendered in standards mode, but that’s probably just my inner purist talking.  If it were important to allow quirks mode, then create a transitional DashboardML DOCTYPE that triggers it; use the default (above) for triggering standards mode.  This would be consistent with current DOCTYPE switching schemes.

Regardless, at this point, I think we’re pretty well assured that things are headed in the right direction.  That’s very much thanks to Dave’s openness and genuine interest in doing the right thing, not to mention his swift response times.  Where things go from here, we’ll see, both at Surfin’ Safari and (I expect) by way of submissions to and work by the WHAT WG—which itself will be the subject of a post in the near future.

• Extended Dash was published on Friday, July 9th, 2004.
• It was assigned to the Browsers, Mac, and Standards categories.
• There have been ten replies.

Now we know more about Dashboard, and according to Dave, the widgets are indeed HTML, not XML.  Fortunately, hastily-applied bandages kept my ruptured vein from killing me.  As for my TiBook, some quick squeegee work saved the display, but now the keys are kind of sticky.  How’s that for an image?

As most people who know me are aware, I’m very much a real-world kind of guy.  That side of me is in favor of what’s being done to make Safari and the Dashboard more useful.  The additions to HTML and the DOM are indeed minimal—so far.  I’m sure the first few proprietary extensions to IE/Win were minimal, too.  After all, it’s just a tag called MARQUEE.  What’s one more element?

I also recognize that HTML is far too limited for anything except simple document structuring.  It doesn’t have interesting controls like sliders, and it certainly doesn’t provide any joy for people who want irregular shapes.  SVG does provide such things, but Dave’s point about it being a huge task to implement is understandable.  If only Quartz had been based on SVG instead of another technology… but there’s no sense crying about spilled milk under the bridge now, I suppose.

Of course, the theorist in me is quivering in outrage.  The browser-wars veteran isn’t too thrilled either.  For years, we heard Microsoft and Netscape say things like “standards are secondary to customer demands” and “standards aren’t as useful as the cool new proprietary features we’re adding”.  These things need not be inimical to standards support.  They should not require a breaking of standards.

As I observed previously, making Dashboard widgets be XML would solve the problem, or at least could fairly easily.  Dave says that won’t happen:

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

I agree about namespaces being confusing; the only reason I have any comfort level with them is because we had to define multiple namespaces for the XML format we used on DevEdge, and I made enough mistakes using them that I eventually came to understand them.  Sort of.  To an author who’s only ever seen HTML or even XHTML, they would likely be very annoying.  I’d like to point out, though, that I suggested not namespacing everything, but creating a whole new DashboardML that used a whole bunch of elements that looked and acted the same as XHTML, with whatever additions were needed.  Thus the beginning of the document (after the DOCTYPE) might look something like this:

<html xmlns="http://www.apple.com/2004/dashboardml">
<head>
<title>This is an example</title>
</head>

So instead of pointing to the XHTML namespace URI, you point to the DashboardML namespace URI.  The end result is that you can have a document that looks exactly like XHTML, except for the additions (composite and so on).  It seems like it would be fairly simple to do, but again, I can’t say that with any authority.

So let’s assume that, for whatever reason, the above approach isn’t possible within the Tiger timeframe.  There is another way, one I mentioned briefly in my last post.  That would be to create a new DTD for DashboardML, one that’s a direct copy of the HTML 4.01 DTD with the needed additions.  It could look like this:

<!DOCTYPE html SYSTEM "http://www.apple.com/dtd/2004/dashboardml-10.dtd">

That would point to a DTD that defines DashboardML.  DashboardML would be exactly like HTML 4.01 (or whatever version they wanted) in every respect except for the additions of the canvas element and the composite attribute.  The advantage is that they can add more things if needed, and not pollute the HTML space.  Since Apple’s working with the WHAT WG to get these things accepted, then perhaps the WHAT WG should host the DTD.  Then it might look something like:

<!DOCTYPE html SYSTEM "http://www.whatwg.org/dtd/2004/whatml-10.dtd">

The URI could be anything, so long as it pointed to an actual DTD.  I don’t even care where it lives, so long as it lives somewhere.  I should also point out that this would need to be done even if the widgets were XML, as opposed to an HTML-like language.  Either way, they keep Dashboard extensions out of the HTML space.

Why should we even bother?  One word: validation.  By providing a DTD that defines the markup language being used to create the widgets, validation becomes a snap.  That’s important, because with validation, widget authors can keep their markup clean.  It will help them with their development efforts.

Here’s another reason to bother: reducing confusion.  “But Eric, a new DOCTYPE will increase confusion!” you might be thinking.  Maybe at first, although overall I doubt it will.  The confusion-reducing aspect is that when widgets get published on the Web—and they will be published on the Web—there will be an obvious indication that the markup is not traditional HTML, but something really close to it.  Browsers can then do what they’ve always done: handle what they understand, and ignore what they don’t.

It’s been argued that Dashboard widgets are intended for a closed environment, and not to sit out on the Web.  True, but that won’t change anything.  Within a week of their appearing in the WWDC build of Tiger, Dashboard widgets appeared on the public Web (they’ve since been pulled offline).  This won’t exactly tail off as more widgets are built.  If anything, we’ll see more and more widgets getting out into the wild—for example, when people find a widget they like and adapt it for use on their public sites.  The calendar is the most obvious example that comes to mind.  In order to keep things straight, widgets need to have their own DOCTYPE.  If nothing else, it will provide a convenient explanation when someone throws a widget onto their site and it breaks in other browsers.  (“Yeah, see, that uses DashboardML and only Safari supports it…”)

Over at the WaSP, Anders Pearson wrote:

Overall, though, it’s not that big a deal. Safari does an excellent (not perfect) job of supporting the various HTML, XHTML, and CSS specs as they’re written and ultimately, that’s what’s most important. If developers don’t want to use the extensions, they don’t have to.

As long as these extensions happen within a new document type, then I agree.  Allowing them to operate within any document bearing a W3C DOCTYPE would be a big, big mistake.

• DashboardML was published on Thursday, July 8th, 2004.
• It was assigned to the Browsers, Mac, and Standards categories.
• There have been four replies.

A lot of people have been saying it for years.  Within the last day or so, Scott Andrew said it.  Then Meryl said it.  Now I hear that the Department of Homeland Security says it, or so it would seem (I couldn’t find corroborating information on the DHS site).

Security is becoming more and more important, especially given the rise in organized attacks that exploit holes in IE and Windows, not to mention Outlook Express (known around the Meyer house as Virus Express).  It’s definitely worth looking into switching to another browser, if you haven’t already done so, and to strongly recommend the same to people you know.  Firefox is most often mentioned as a suitable replacement, and it will even import bookmarks, cookies, and settings from IE.

Of course, you may get pushback that Explorer is required for this site or that one.  Just point out that they can do 99% of their browsing in Firefox, and only launch Explorer for those few sites that need it.  After all, it isn’t like IE will be unavailable—they couldn’t get rid of it even if they wanted to do so.

Update: not only has CNN run a story along these same lines, but they mentioned Porter by name.  Way to go, dude!  Now when do I get namechecked by the news media?  <pout type="smirking" />

• Exploring Other Alternatives was published on Friday, July 2nd, 2004.
• It was assigned to the Browsers category.
• There have been five replies.

c|net seems to have injected a note of disbelief into its headline “AOL plans to revitalize Netscape?” and I suppose they could be forgiven if that was intentional.  My read on the situation is that AOL is going to put their efforts into the portal; the fact that the positions are in Columbus, Ohio, the site of their Compuserve division, was my primary tip-off.  Apparently there will be a new version of the Netscape browser this summer, based on Mozilla 1.7, but that to me bespeaks a piggyback strategy.  They’ll employ enough coders to wrap the Netscape/AOL chrome around Mozilla, and call it macaroni.  Not that this is a bad approach.  I just expect that it means Netscape isn’t about to re-enter the browser development space, nor will they be asking me if I’d like my old job back.  I’d love to be wrong, but I get the sense that they’re going to chase eyeballs.

Enough about my former employer; let’s have me talk for a bit.  I did just that with Russ Weakley of Maxdesign and the Web Standards Group, and the result is now available for your enjoyment, or for your frustration if you’re of certain persuasions.  Font-size zealots of all kinds, I’m looking in your direction.

There was more stuff I was going to talk about, but a severe cold/stomach bug/allergy condition has my brain operating at about one-fifth its usual speed.  Maybe it’ll come back to me tomorrow.  The only reason I’m even typing this entry is that I accidentally took a daytime medication instead of the nighttime equivalent, so now instead of sleeping off the illness I’m propped up in bed snuffling my way through it.  Bleah.

• Cold Comfort was published on Wednesday, April 21st, 2004.
• It was assigned to the Browsers and Interviews categories.
• There have been no replies.

Ever since the day after Carolyn came home, our cat Gravity has mostly ignored Carolyn’s presence.  We’d been somewhat concerned that there would be hostility between them in the months to come, which wouldn’t really end well because Gravity still has claws.  Those concerns are now, for the most part, erased.  This afternoon, we discovered that not only has Gravity gotten used to Carolyn’s presence, but now regards her as a part of the family.

We know this because Gravity left Carolyn a gift—a freshly killed mouse, lying on the floor right next to the bassinet where Carolyn sleeps during the day.    From what I understand, this is typically how mother-cats feed their children, and start training them to hunt for their own food.  I wished there were some way to communicate to Gravity that she could have her hunting spoils back, since Carolyn’s fairly well fed even without rodent supplements.  When you think about all this, it’s really rather touching, in a morbid way.  Kat and I both got a pretty good laugh out of it.

Of course, then I had to dispose of the carcass.

So Safari 1.2 is out, and of course was released just two days after I changed designs.  So the fix for the first-letter bug that occurred with “Thoughts From Eric” in the previous design is in place, but you can’t see it working here.  On the other hand, my recently constructed test page demonstrating Safari 1.1’s bugs with :hover and generated content show that 1.2 fixed the problem.  So, that’s cool.

What is even cooler is John Gruber’s in-depth exploration of the OmniWeb beta.  The “tabbed” interface, although not what I personally think of as tabbed, is still a welcome addition; I’ve found that I basically can’t live without tabs.  (I do a sweep of all my regularly read blogs by opening them all in tabs, via a bookmark group.)  What sounds really outstanding, though, is OmniWeb’s workspaces and site-specific preferences.  It’s probably enough for me to tolerate the obsolescence of the rendering engine, which is equivalent to Safari 1.0, but we’ll see.  You should see, too—go read John’s review of the browser, which is comprehensive and detailed.  Truly excellent.

Complete topic shift: back in September, Molly was aghast at the Quizno’s television commercial featuring an adult male human suckling at the teat of a wolf.  Well, their new ad campaign has launched, and if anything it’s more wrong.  Sure, it’s a complete ripoff of the Spongmonkeys, mostly because it turns out the same guy did both.  Warning: if you follow the Spongmonkeys link, I am not responsible for any psychological damage you may suffer, but it is very much like the commercial.

Is it just me, or are commercials in general getting a lot weirder of late?

• Love, Feline Style was published on Tuesday, February 3rd, 2004.
• It was assigned to the Browsers, Carolyn, Humor, and Mac categories.
• There have been no replies.

The e-mail backlog has finally forced me to do something I’ve long resisted: the site now has an FAQ.  I thought about calling it a QAF (Questions Frequently Asked) or maybe an FRE (Frequently Received E-mails).  But in the end the weight of tradition got me to go with the traditional nomenclature.  If you’re thinking of sending me e-mail, please read the FAQ first to see if the answer is there.  As much as I love correspondence, I just can’t keep up any more.  In fact, I couldn’t even before Carolyn arrived, and so now I’m doubly unable to keep up.  Hopefully the FAQ will help, just a bit.  Thanks for your collective understanding.

This is truly excellent: arbitrary-element hovering in IE/Win.  In other words, stuff like pure CSS menus and such can actually be used in real-world designs, thus reaping the benefits of dramatically reduced markup weight.  The approach the behaviors take reminds me a lot of what we did to get the Netscape DevEdge menus working in IE/Win, except we did it in JavaScript, which may have made our technique a little weightier on the back end.  Either way, they’re both excellent solutions.

There’s a lot more gold to mine in the behaviors/script/structural markup vein, I suspect; the melding of IE-specific behaviors with lightweight scripts and CSS could lead us to a great many advances in standards-oriented design.  While it would be nice to see IE advancing so that we didn’t need these kinds of solutions, at least they exist.  Here’s my short, off-the-cuff wishlist for things for which we can hopefully use behaviors to replicate CSS2 functionality:

• Support for generated content; counters would be a truly awesome bonus
• Fixing the box model in versions of IE previous to IE6
• Better (read: more smoothly scrolling) support for fixed-position elements and fixed-attachment backgrounds than current scripts provide

I think there’s a way to use behaviors to get alpha-channel support in PNGs, too.  Can anyone confirm that?  If not, it’s something to investigate.

Now on to slightly more surreal matters.  Sure, I’m fairly well known as an expert in CSS and Web standards, and some of you know that I do a weekly Big Band-era radio show, but how many of you were aware of my career as a shoe designer?  Doug Bowman wrote to let me know that Matt Haughey had spilled the beans, so I’ll own up to it here.

Okay, not really.  But if you go to the Medium Footwear site, wait for the Flash interface to load, hit “Collections,” and then click anywhere on the splash page, you’ll see—and I swear that, like Dave Barry, I am not making this up— the Eric Meyer Collection.  There are nine different models, and the really funny punchline to the whole affair is this: guess which of those shoe styles I like enough to consider buying?  As it turns out, the “Structuralist” design.  Seriously.

• Running Just To Stay In Place was published on Monday, January 5th, 2004.
• It was assigned to the Browsers, CSS, and Humor categories.
• There have been no replies.

This completely and utterly rocks.  I’m going to set up a Virtual PC drive just to try it out.  But Matt Haughey’s question is worth considering: why didn’t we know about this sooner?

• One System, Many Explorers was published on Thursday, November 6th, 2003.
• It was assigned to the Browsers and Standards categories.
• There have been no replies.