June 25, 2001

3:28 PM

CSS behavior tagand HTML Component files are some of the new bits that Microsoft has proposed to the standards boards and which are already implemented in recent versions of IE. Of course, I only discovered them by poking around in microsoft.com's source. What do you think of these tools? It looks like it will make Web apps more powerful and application like.
posted by benbrown (20 comments total)

There are two types of menus on the MSDN site, both of which use an XML file to build their structure and an HTC file to define the behavior of the elements. Looks like with a bit of simple coding, you can have nice structured menus, drop shadows, and access to all sorts of nifty functionality that was previously hard to get at.

Has anyone played with these new things?
posted by benbrown at 3:31 PM on June 25, 2001

Looks interesting, indeed. However, after some quick clicking around in those menus, I did manage to crash IE5.5, and only after anout 30 sec of use. Is this really their live site? It's slow and kinda grumpy for me, same for anyone else?
posted by Hackworth at 3:56 PM on June 25, 2001

I will, next year, when the pages finish downloading.
posted by dhartung at 3:58 PM on June 25, 2001

I have mixed feelings about using stuff like this. It happened all throughout the browser wars. <DIV> tags and <LAYER> tags, anyone?

All this does is deviate further from standards and right now, that pisses me off.
posted by fooljay at 3:59 PM on June 25, 2001

Except DIV was always standard. MS was on the side of the angels there, for once.
posted by rodii at 4:08 PM on June 25, 2001

The greatest irony of standards-compliance wars is that "standards" are determined by a committee made up of people from MS, NS, and many other tech firms.

So, when a company fails to implement an industry standard, they are really just ignoring agreements they didn't vote for in committee. When they do implement standards, they are just following the consensus they happen to agree with.

This kind of lobbying happens both inside and outside of standards-setting boards. There's nothing scientific about the W3C. It just has the advantage of being bipartisan.
posted by rschram at 4:21 PM on June 25, 2001

It is remarkably slow. You'd think that MS would want to give easy and quick access to their development libraries and references. But no, I've always found it hard to find documentation on IE javascript and whatnot. Especially now since, as mentioned, it takes about 2 minutes to load and render one of those pages.

I'm wondering if it has to do with those new menu things or the fact that their CSS files are like, thousands of lines long. The HTML source is just the tip of the iceberg when you load one of those pages...
posted by benbrown at 4:29 PM on June 25, 2001

i couldn't tell you what i think about them, that MSDN page crashed my IE.
posted by afx114 at 4:29 PM on June 25, 2001

As I understand it, this doesn't add any new capabilities that couldn't be scripted before, but simply makes it easier to manage web sites that use them.

Why would I want to put a lot of time into this stuff when only a subset of my audience is going to even see it? (Is there any real chance the W3C is going to look with favor on this and make it a standard?)

If the goal is to bring application-like UI functionality to web pages, well, the road to bloatware hell is paved with well-intentioned patches like this.

Embrace and extend: stay tuned for the next exciting episode.
posted by anewc2 at 4:47 PM on June 25, 2001

Oddly enough MSDN crashed MS IE 5.5 for me, but my Mozilla 0.9.1 worked like a charm. Now that is standards.
posted by vanderwal at 5:39 PM on June 25, 2001

Why would I want to put a lot of time into this stuff when only a subset of my audience is going to even see it? (Is there any real chance the W3C is going to look with favor on this and make it a standard?)

Unfortunately, Microsoft IE makes up a vast majority of the browser's. That's a large subset. Secondly, the problem with owning such a huge percentage of the market share is that any outside governing body is useless. You (and your shee^H^H^H^Husers) set the standard. The W3C is nothing more than a really really slow yes man now.
posted by fooljay at 6:13 PM on June 25, 2001

learn a bit more about web standards at webstandards.org.

I think the Ms stuff is interesting, but implementation of a feature in one browser does not equal implementation we can all use as a practical matter. See also: blink, layer, ilayer, marquee, embed, nobr, and activex content without correlate plug-in versions.
posted by artlung at 10:56 PM on June 25, 2001

What? Blink isn't supported on all platforms!!

I believe we can thank Jamie Zewinksi for that bit of HTML irrelevance
posted by fooljay at 2:05 AM on June 26, 2001

So, MS implements it in IE and THEN suggests it to the W3C for standards approval?

Ahemmm...
posted by Succa at 6:07 AM on June 26, 2001

The BLINK tag was invented by Lou Montulli while at Netscape. He also created Lynx and cookies, according to his web site.
posted by rcade at 6:22 AM on June 26, 2001

Succa, that was the way of things - img started as a proprietary, browser-specific add-in - but it was useful, and now we use it, and it even appears in the w3c specs.

There's a natural tension in the html specifications between simply noting what's out there in browsers, and between dictating what should be out there. The w3c attempts to not dictate specs, but also not to be a rubber stamp. It's a hard thing to maintain.
posted by artlung at 7:55 AM on June 26, 2001

"Behaviors" seem likely (given the existing history) to be as problematic security-wise as ActiveX has been. Not that my constant paranoia about IE necessarily constitutes a valid reason not to add new features to HTML... *8)
posted by davidchess at 7:56 AM on June 26, 2001

Agree with david. Behaviours are one more way of hiding executable content (JavaScript) in places people don't expect executable content (CSS). As with javascript: URLs, this can only cause security goofs, not only with browsers but also with everyone's web sites. (If daveadams can post funny CSS tricks to mefi, I guess he can now post malicious JavaScript too.)

Behaviours are nothing more than an attempt to exploit the usefulness of CSS selectors for something other than CSS. Now W3C have unbound the spec for selectors from CSS itself, there is no reason to have behaviours in CSS. And in any case, I *much* prefer the model of having a script bind to elements it's interested in through addEventListener in the DOM2 events model. Much better separation of scripting from content and style, plus works better with multiple behaviours. If only there were a getElementsByArbitraryAttribute, so you could select a list of elements to bind to by class.

Behaviours have been sitting on the CSS3 back burner for years now and I very much hope they stay there indefinitely.
posted by BobInce at 9:36 AM on June 27, 2001

I think behaviors make good sense from an abstract point of view. I would love to trigger events with the CSS class mechanism instead of having to embed a listener in every element. The security problems, obviously, need to be solved; it seems like your approach would have the same problems, though, Bob.
posted by rodii at 9:45 AM on June 27, 2001

Behaviours are one more way of hiding executable content (JavaScript) in places people don't expect executable content (CSS).

Most people don't know anything about what parts of a Web site are executable and which aren't to begin with, so I don't see this as a tremendous drawback.
posted by kindall at 11:00 AM on June 27, 2001