Categories
Technology Web

Microsoft to world: do as we say

Recovered from the Wayback Machine.

Jeffrey Zeldman writes in support of the Microsoft IE8 meta tag, which we find out is a done deal.

To understand version targeting—which we ought to try to do, since Microsoft intends to implement it and hopes at least some of us will opt in—let us examine two different sets of customers that Microsoft’s browser must satisfy.

Did we really think that A List Apart was rolling the meta tag out earlier in order to gather comments from the community? Perhaps take alternative suggestions? No, this was nothing more than Microsoft working with a few web elite to shove more IE specific nonsense down our throats.

In his newest writing on this topic, Zeldman writes that yes, the meta tag is ugly, but really, what’s the harm?

Still, even if version targeting were merely the tribute Microsoft’s browser engineers had to pay their corporate overlords to retain permission to keep improving IE’s standards compliance, what would be the harm? The meta element is valid, and its use is optional. The HTTP header is easy, and leaves your markup pure.

He also hints at the “goodies” coming in IE8, which if they don’t excite you overmuch it’s because we’ve seen them before: in Firefox, in Safari, and in Opera. He further goes on to say that Microsoft is really only thinking of us with this new form of version targeting.

Today’s IE is light years more compliant than the old versions we struggled with. And Microsoft has promised to improve compliance forever. If we opt in, we can expect the same level of scripting support in IE that we get from the browsers we love. Improved, predictable standards support in all browsers. Isn’t that what we all want?

If we opt in…

Let’s reframe this discussion. I have worked, hard, to get this weblog to serve up XHTML 1.1 strict pages. I have worked, hard, to master both SVG and CSS in order to style the site, as well as provide some of the functionality. I’ve also worked equally hard to make sure that the JavaScript isn’t funky, strange, doesn’t eat up more CPU or memory than necessary, and works in my target browsers. I don’t claim any of my effort is perfect, only that I work hard to ensure my work is clean, accessible, and standard.

How is Microsoft rewarding me for this hard work? By forcing me to add a meta tag, or change the HTTP header. Not to use a standard meta tag that’s meaningful to other browsers, or change the HTTP header in a universally standard way, no. I am asked, once again, to change my web site specifically in order to accommodate IE.

Wow! Did you feel that, too? I just felt a tug on my shoulders, like I was a puppet and someone was pulling my strings.

Zeldman also gave space at A List Apart for a Jeremy Keith, the only person who spoke out against the new IE8 meta tag whose opinion Zeldman seems to respect. Keith says all I want to say, and more.

The reasoning here is that less savvy developers shouldn’t have to worry their little heads about adding one extra line to their documents. Instead, they should be encouraged to continue to write to the quirks of one specific browser version from the market leader. That their documents will “break” in other browsers is not Microsoft’s problem. The counterpoint to this condescending worldview is that standards-aware developers are the ones best placed to add a single line of markup to their documents—though, for some unexplained reason, the instruction for up-to-date rendering (IE=edge) is strongly discouraged.

This strategy is doomed to failure. Standards-aware developers, by their very nature, will object to adding a line of unnecessary markup to their documents just to get one single browser to behave as it should by default.

Keith also asks a very pertinent question: how do we know for sure that civilization, as we know it, is doomed if the meta tag isn’t used? In other words, there’s been a rather breathless assumption on the part of Microsoft that releasing IE8 without this silly meta tag will break vast swatches of the web. Shouldn’t we, instead, see what happens with the beta release of the browser?

I agree with Keith’s suggestion of let’s see what happens. If the web sites Microsoft is so concerned about are intranet sites, the companies that built the crappy site are also the type of companies that won’t upgrade to a new browser version until it’s been released for two years. Frankly, most are probably still using IE6, in which case what IE8 does is moot.

Another assumption by Microsoft (and Zeldman, more’s the pity) is that there are vast numbers of web developers and designers who seemingly don’t read the news, weblogs, design sites, Microsoft’s site, and so on. They must not read because according to Zeldman and Microsoft, they won’t know that Things are Different in IE8 and thus must be protected from themselves. Frankly, I find such assumptions of mass, blanket stupidity and incompetence to be insulting, as well as elitist.

True, there are “bad” sites, but less now than in the past, not the least of which because so much content is now generated from templates rather than created by hand. True, not every site meets some standard of ALA purity, but most designers and developers–and even preachers and school teachers–do the best they can, and that includes keeping up with the changes in both standards and browsers. After all, who does Zeldman think attends all of his company’s A List Apart events?

If, as Keith mentions in his writing, we have a long enough beta period for IE8, this should be sufficient for designers and developers, WYSIWYG tool creators, and preachers and school teachers to implement whatever changes they need in order to remove the IE cruft. Rather than a meta tag, what we needed from Microsoft was clear communication about to expect from IE8. Instead what we’ve received is silence occasionally punctured by vague hints, an ACID2 test graphic, which we now know will fail unless the meta tag is present, and another example of Microsoft asking the web world to adapt to it if we want to move forward.

I am a web developer, not a designer, so perhaps my opinion should be taken with a grain of salt. However, as a web developer, I’m also filled with a sense of unease from what was not said in Zeldman’s writing. We’ve not had any official confirmation from Microsoft that using the HTML5 DOCTYPE will turn on “standards” mode. We’ve also not had any confirmation from Microsoft that it will, finally, support the XHTML MIME type, and that this will also trigger “standards” mode. I wasn’t holding my breath on SVG and MathML, but Microsoft has been abnormally quiet about these specifications, too.

Surely, if any action is going to “break the web”, as Microsoft’s mantra seems to be, it’s the company’s unwillingness to support standards in seeming conflict with its own proprietary Silverlight technologies that is more at risk for “breaking the web” than the use of a silly meta tag or not.

Frankly, if this discussion was only about the addition of a meta tag for versioning, I’m not sure that Zeldman’s audience would be up in arms. However, it’s more than just the new meta tag that’s at stake: it is the very future of the web. A future no longer dominated by any browser. A future where we’re free to truly explore the wondrous tools with which we can build sites, no longer held back by a company that has not acted in good faith, either in the past or, sadly, today.

After reading Zeldman’s and Keith’s postings, I visited the IE weblog. I looked for answers to the questions we asked: about HTML5 triggering standards mode; whether IE8 will support XHTML and SVG; will Microsoft actively participate as part of the X/HTML5 effort; what can we expect from IE8. Nothing. Not a word. Yet we’re supposed to accept, on faith, that this “minor” change to our web pages will be the key to the future?

Microsoft still doesn’t “get it”. Evidently, neither does Zeldman.

Categories
Technology Web

Light grey screen of mild achiness

Recovered from the Wayback Machine.

Jeff Schiller writes:

It turns out, as Shelley has mentioned, that the best developer experience to work on XHTML is also (by far) Opera. Instead of Firefox’s “yellow screen of death” we’re greeted with Opera’s “light grey screen of mild achiness”. Instead of cryptic messages about unexpected tags, the element which failed to be terminated and the tag that broke the XML parsing are highlighted for you.

Jeff just finished creating a new site design that incorporates XHML+SVG. He also did something I didn’t think to do, which was submit a bug to Mozilla for the poor way Firefox manages bad XHTML. Opera really does provide a beautifully graceful way of dealing with bad XML, including an option to re-parse the page as HTML. Even Safari does a better job than Firefox.

Jeff is also using content negotiation with his site, which I don’t use with this site. Because of this decision, my stats show that only 3.9% of page accesses are from IE. I do support content negotiation for my topmost site, which is accessed about 39% of the time with IE. However, I have been recently rethinking my decision to use content negotiation.

I run the risk of losing page views by serving pages up as XHTML. At the same time, though, if more of us did this, I wonder how much this would hasten the demise of browsers that don’t support what is now a fairly mature standard specification?

Sometimes you have to “break the web” in order to save it.

Categories
Web

Google is the new Cloverfield monster

Recovered from the Wayback Machine.

Oh, the horror! Google hijacks 404 pages!

The reality is that the new Google beta toolbar doesn’t hijack the 404 page if the site provides a 404 page or other form of web error handling. I tried the toolbar out this morning, and the only case I found where the Google toolbar provided a search page is the site matching the screenshots below, and the site given in the original post on this topic. The latter site provided a lame looking redirect back to the main page. However, other sites that redirected back to the home page for 404 errors did not have this problem, so the problem seems to be unique to this site.

If you’ve ever seen default 404 error handling, you know it’s basically useless.
[missing image]

Compare that with a page managed by the toolbar.

[missing image]

I would expect a search engine toolbar to provide useful, alternative methods of finding the content if the web site uses default error handling. However, according to Codswallop, Google steals your visitors.

Why is this “helpful” behavior bad? As well as a link to the domain root they provide a prominent search box pre-filled with search terms. The temptation is going to be to hit that search button, effectively taking away your visitor.

I would say any webmaster that doesn’t provide effective error handling pages for 404 errors doesn’t really care about losing visitors, do they?

update

Matt Cutts from Google explained that the toolbar looks for a result larger than 512 bytes. The example page is nothing more a broken HTML page, with a meta refresh and a link, all of which is less than 512 bytes. Those sites that do a direct redirect don’t, of course, return 404 to trigger the toolbar. End of story

.end update

What really surprised me about this story, though, is that if people are so quick to accuse Google of ‘evil’ behavior in an innocuous situations like this, why was the idea of Google helping to bail out Yahoo to keep the latter out of the hands of Microsoft seen as a “good” thing? I would think a search engine monopoly in the hands of Google would be potentially more evil than Google providing useful features for default 404 error handling.

This environment is confusingly inconsistent at times.

Categories
RDF Specs SVG XHTML/HTML

Our bouncing baby markup has growed up

Recovered from the Wayback Machine.

On today’s tenth anniversary of the birth of XML, Norm Walsh writes:

I joined O’Reilly on the very first day of an unprecedented two-week period during which the production department, the folks who actually turn finished manuscripts into books, was closed. The department was undergoing a two-week training period during which they would learn SGML and, henceforth, all books would be done in SGML…My job, I learned on that first day, would be to write the publishing system that would turn SGML into Troff so that sqtroff could turn it into PostScript. “SGML”, I recall thinking, “well, at least I know how to spell it.”

Ah yes. “Unix Power Tools” was formatted as SGML, the one and only book at O’Reilly I worked on that wasn’t in a Word format. I must express a partiality to my NeoOffice, though the SGML system was ideal for cross-referencing and indexing. OpenOffice ODT, or OpenDocument text, will be the most likely format for the next UPT. Just another example of the permanent/impermanence of web trends.

Norm also mentions about HTML5 possibly being the nail in this child of SGML’s coffin, but as I wrote recently, the folks behind HTML5 have solemnly assured us this specification also includes XHTML5. I’d hate to think we’re giving up on the benefits of XHTML just when they’re finally being realized by a more general audience.

Of course, I’m also fond of RDF/XML, which seems to cause others a great deal of pain, the pansies. And I’ve never hidden my SVG fandom and SVG is based in XML. I must also confess to preferring XML over JSON–you know, good enough for granddad, good enough for me. Atom rules. Or is that, Atom rocks? I’m also sure XML has squeezed between the joints of many of my other applications, and I just don’t know it.

Categories
SVG

Graphics tools

I really kick myself now for not including a mention of gnuplot in “Painting the Web”. I had one chapter on graphics and data, and it would have been a nice fit. However, it does need a nice installation environment for the Mac, and that was one of the criteria for including mention of tools.

We’re told that a Mac-specific installation of gnuplot is coming. When it does, I’ll include a link in the graphics tools section of the book’s supplementary site.

Another handy graphical tool is svgfig, which allows you to draw mathematical figures in SVG using Python. This tool should be very simple to install if you have Python installed. Using it, though, does require an understanding of math. Of course.

I would say that 2008 is the year of SVG in addition to the year of semantics. Works for me, though perhaps I should have called my book, “Painting the Semantic Web”.

(Thanks to Michael Bernstein for mention of svgfig)