Musings

Tracked by bug 271261. First draft of the new material is attached to the bug.

(BTW, the @code@ tag seems to be not working with the Textile text filter here…)

Sorry. We’re still using Textile 1.0 here. I wrote to Brad Choate about fixing Textile 2.0 to work with MathML content, but I never heard back.

Personally, I prefer Markdown these days. And John Gruber answers his emails.

…but with XHTML I have to use CreateContextualFragment, which, paradoxically, doesn’t work with the application/xhtml+xml MIME.

Yet another case for Gez’s list? It’s equally as non-Standard as innerHTML, albeit less-widely used.

Cool!

Though, for an even better-tasting browser experience, you could download the MathPlayer plugin, and then IE/6 will handle, not just XHTML, but MathML as well.

Does that send the doc down the tag soup code path? Parsing application/xhtml+xml with a tag soup parser is very wrong.

And, indeed, it turns out that this hack is a fraud: it tricks IE into thinking a document of type application/xhtml+xml is actually of type text/html.

Thus the document gets sent to the tag-soup parser, exactly as Henri and James feared.

This is, at best, useless. At worst, it is dangerous, if the user assumes, mistakenly, that the document has been parsed by IE’s XML parser.

Factoid: The FIR thing mentioned on Mike Davidson’s page actually removes the element it replaces. Since this typically means a heading element, this technique has the property of removing all the heading semantics from a document just before a UA has the opportunity to put them to use. It would be funny if the alternative (display:none) wasn’t so blindingly obvious as to imply that no one using the technique has any idea what the point of document semantics is or indeed who might make use of those semantics (i.e. not just users without javascript/flash).

I’m stunned.

You mean they don’t just do a {whatever}.style.display="none" ?? …[checks the source of the latest version] … Damnit! You seem to be right:

Document semantics? We don’t need no steenkin’ semantics!

Hint: Fire up Opera. Go to the main page of my blog. Try navigating it using the S and W keys. Now try the same thing on your blog.

(I believe there’s an extension for Mozilla, and various IE add-ons that achieve the same thing, but Opera comes with this functionality built in.)

Any questions?

when I fire up your blog in Opera, I receive a popup window (?!) telling me that IE doesn’t support MathML. I’m not sure why you’d want this to come up for Opera users. If you’re using a user agent sniffer to sniff for IE, it’s easy to tell when Opera is masquerading as IE, as it apparently is in this case.

Opera doesn’t support MathML either, so it is not unreasonable to inform them that my site’s functionality is broken for them, too.

I probably could be more discriminating about customizing the message for the UA that is actually being used. But it’s Opera Software ASA that decided to spoof IE, not me. I think their users ought to be given a hint about that.

Also, when I click around to other pages, I receive another popup window prompting me to download the IE version of the MathML plugin every time.

You should only receive that second popup once (unless you have cookies disabled).

Also, with regards to the S and W keys… fair enough. Not an important feature to me, and not one that I think 99.9% of the world uses, but if you use it and you can’t use it on my site, then I guess it’s technically a shortcoming of my site. I can live with that though.

There are a dozen other reasons why good document semantics can be helpful to your users (and conversely, why deliberately stripping out those semantics is bad for your users).

But I’m not going to argue the point. You’ll probably just tell me that those “features” aren’t important to you either.

Also, keep in mind that my site has not been converted over to sIFR yet. Until the release version of sIFR 2.0 comes out (very soon), it still uses the old IFR code.

The Javascript code I read in sIFR 2.0RC1 seemed to remove the header. Mark says I misread it. If so, I apologize.

In any case, I trust that the final release of sIFR 2.0 will not remove, turn into semantically-meaningless <span>s, or display:none the “replaced” <hn> elements.

Yeah, I’m not a big Opera fan either, and it’s ok to let them know their browser doesn’t support MathML, but to fully denigrate them to the status of IE users is a bit harsh :) .

You are absolutely right. I will look into doing a bit more sophisticated job of browser detection.

Safari doesn’t support MathML either and I don’t subject Safari users to dunning popups. Opera users deserve at least the same treatment.

My objective of increasing the percentage of readers using MathML-capable browsers from the current 40% (Sep 2004 figures) to 70% is not really advanced by sending incomprehensible dunning notices to Opera users. (Both because they’re incomprehensible and because I have too few Opera users to make a difference.)

sIFR is designed to give you rich typography while leaving your document structure and HTML/XHTML completely untouched. As Mark pointed out, that is exactly what it does.

I got a chance to reread the sIFR source code (planes are great for that) and can confirm that it does do the right thing.

I musta been sleepy when I read the code last night, but my erroneous reading was (erroneously) ‘confirmed’ by opening up your blog in Mozilla’s DOM inspector.

I’m glad to hear you’ll be upgrading from whatever it is you’re running now to sIFR in the near future.

What counts is not what the orginal (X)HTML markup looked like, but what the DOM tree looks like after all the Javascript rewriting is done. That’s what the UA actually uses. As this little Opera example shows, functionality can be lost if you strip out semantics at the DOM-scripting level, as your current setup does.