Skip to main content

markpilgrim


markpilgrim

[Original]

Browsers that use modern operating systems more directly deliver better experiences. Browsers that compromise (by spreading across too many OSes and OS versions) face challenges.

We can't decide if we want IE to drive Windows adoption or Windows to drive IE adoption.

The best HTML5 is native to the operating system, so Web sites have the fewest translation layers to pass through.

The browser is part of the OS. The browser has always been part of the OS. We have always been at war with Eastasia.

Native HTML5 support in Windows with IE9 makes a huge difference in what sites can do.

We're really, really sorry about IE6. Not sorry enough to disable Windows activation and allow all the software pirates in China to upgrade, but sorry nonetheless.

Web sites and HTML5 run best when they run natively, on a browser optimized for the operating system on your device.

I think we can all agree to hate XUL.

We're about three weeks into development of IE10, and based on the progress we've made, we want to start engaging the development community now.

Imagine how much progress we could have made if we hadn't ignored the web for ten fucking years.

Native HTML5 ... native HTML5 ... run natively ... most native ... only native ... native graphics ... native ... Native HTML5 ... Native HTML5 ... native and robust ... native applications ... Native implementations ... non-native ... native HTML5 ... native ...

I am high as a kite.

When this post was initially published, I forgot to include the onerror event handler for the HTML5 video element. This caused the video to not play in browsers that don't support MP4/H.264 video. That has been corrected.

The irony of using the phrase "same markup" nine times while delivering different markup to other browsers is entirely lost on me.

The only native experience of the Web and HTML5 today is on Windows 7 with IE9.

We would like HTML5 better if it were spelled "ActiveX."

§



markpilgrim

§



markpilgrim

So there I was, minding my own business, casually browsing MSDN for no reason, when I came across the UNSELECTABLE attribute. This attribute, as MSDN cheerfully points out, "specifies that an element cannot be selected." As in, text selection. With the mouse. Or, presumably, with the keyboard. Or, in case the author decides for you, not at all.

I will note in passing that you turn text selection off by setting the unselectable attribute to on. But that's not the interesting part. This sentence caught my eye:

The UNSELECTABLE attribute is implemented as an expando. Setting the expando property of the document object to false precludes the functionality of all expandos.

"Precludes the functionality." Awesome.

Which led me to this wonderful example of using the expando property:

The following example demonstrates that, by setting the expando property of the document object to false, the document ignores the UNSELECTABLE expando on the span and allows you to select the text.

Breathtakingly awesome.

But wait! What was that implementation note about the unselectable attribute? "The UNSELECTABLE attribute is implemented as an expando." Hmm. "Is implemented as an expando" sounds like one of those boilerplate phrases, like "There is no public standard that applies to this..." Are there other wacky "expando" properties that can be neutralized by setting document.expando? As it turns out, no. The UNSELECTABLE attribute is the only expando property that Internet Explorer recognizes, and therefore the only feature that can be disabled (or, depending how you look at it, re-enabled) by setting document.expando.

To sum up, you can turn text selection off by setting the unselectable attribute to on, and then you can turn text selection back on by setting the document.expando property to false. No other functionality is affected, and it only works in Internet Explorer.

Here's an idea for an April Fool's joke: Microsoft apologizes for treating the web as their own private playground for 12 years, and offers all web developers a token refund and a free t-shirt. Feel free to post ideas for the t-shirt.

§



markpilgrim

Slashdot: HTML Rendering crashing IE. Here's a test page that crashes my Internet Explorer 6.0 SP2 with all patches. Thanks to the wonders of integration, it also crashes any other product using Microsoft HTML rendering libraries. That would include Outlook and Outlook Express, leading the way for a brave new world of Denial-Of-Service-By-Email for people still using Microsoft mail products.

That's not terribly funny. But here's the funny part. Here's the markup that makes it crash:

<html>
<form>
<input type crash>
</form>
</html>

Presumably there are other variations, but that just made my day.

§



markpilgrim

I've been playing with the OBJECT element, which has been around for ages, but was never much used because Netscape 4 didn't support it. I don't care about Netscape 4, but I do care about Internet Explorer for Windows. Here's my problem:

I want to replace the IMG element. Why, you ask? Because I'm a markup wanker who won't leave well enough alone. Also, IMG has been removed from XHTML 2.0, in favor of OBJECT, and I'm wondering if there's a smooth migration path. The question of the day is: Can we start using OBJECT now to replace IMG?

This is old-style markup:

<img src="http://www.diveintomark.link/public/2002/07/beagle-gimli.jpg" alt="A beagle sitting in a woman's lap" width="152" height="160" />

Which produces this image:

A beagle sitting in a woman's lap

This is new-style markup:

<object type="image/jpeg" data="http://www.diveintomark.link/public/2002/07/beagle-gimli.jpg" width="152" height="160">A beagle sitting in a woman's lap</object>

Which produces this image:

A beagle sitting in a woman's lap

I think the parallels speak for themselves. My problem is with Internet Explorer. (There may be other problems with other browsers that I don't know about yet. Leave messages in the comments if you can't see this image at all.) The IMG-based image and the OBJECT-based image look identical in Mozilla and Opera. However, in Internet Explorer for Windows, the OBJECT-based image has internal padding within the OBJECT. Since the image is the same size as the OBJECT, this means we get ugly scroll bars. There is also a visible border around the OBJECT.

Now, I know a little about CSS, but none of the obvious tricks to get rid of this padding or border have worked. Searching Google for information about the OBJECT element is almost fruitless, since object is a very generic term, and all of the examples focus on embedding multimedia or Java objects. For example, here is the MSDN documentation on OBJECT, which notes both a BORDER attribute and a border style property, neither of which removes the visible border, and a full complement of padding style properties, none of which remove the padding.

Basically, nobody actually uses the OBJECT element this way (because IMG is easier and more direct, and also possibly because it doesn't work in Internet Explorer -- that's what I want to find out), but if the W3C gets its way, everyone will in the future.

Update: thanks to several commenters, I have found these references:

Update #2:: in case I'm a wanker who can't leave well enough alone is not a good enough explanation for you, this comment goes into more depth about why I am bothering.

§