Certainly, IE has had excellent features in the past. If they were the first with XSLT support first, good for them. It was also a brilliant move to create XmlHttpRequest.

But it’s not about what IE has gotten in the past; it’s about what IE needs to get now.

Currently IE’s CSS support is effectively crap. Workarounds have to be written for just about anything; they have a broken implementation of CSS 1 and part of a broken implementation of CSS 2, as well as the tremendous number of security problems brought about by ActiveX.

Firefox has excellent CSS 1 and CSS 2 support (as does Opera), as well as a significant portion of the unfinished CSS 3 standard, and ActiveX just isn’t in there, providing truly top-notch security. Firefox is also implementing SVG.

IE7 looks to fix a lot of the CSS bugs; it also looks like the Vista version will solve all the security problems in one fell swoop. I’m very pleased by this; I’m a little concerned that IE 7 doesn’t have *enough* CSS fixes (I would appreciate some CSS3 features), but some is better than none, and the fixes they *have* made seem to go a long way toward getting IE 7 up to the same level as Firefox and Opera.

However, IE7 is missing SVG support, and I’m skeptical as to the security enhancements on XP. I also note that Firefox is extremely extensible (I don’t know about Opera; I don’t use it), which is something the IE seems to lack. I look forward to any improvements MS makes on extensibility.

I don’t see me un hacking my css any time soon. I doubt very seriously that nobody will be able to find hacks that target IE7 for one thing. And if IE7 is as CSS savvy as you’d have us believe it’ll respond to the current set of hacks in the same way as Firefox and Safari currently do and IE6 will still be affected by the previous generation of hacks for another thing.

I’ll tell you what, I’ll begin unhacking my css when you guys make a version of IE7 beta publically available.

Hi, I cant claim to understand everything you talk about here. But I am just starting to learn how to use internet related software better. For years I have just been pointing and clicking, and thats about all.

Finally, something I like to hear from Microsoft. “We’re starting to see the first round of sites and pages breaking due to the CSS fixes we have made.” Translated from web browser developer, it says “we’re making web developers’ lives easier.”

Firefox sucks period. You idiots who think MS is the evil are a joke. MS makes the right decisions when standards are wrong and does it the right way. It’ll be here when FF is dead and gone. IE thanks for the inner HTML property!! Thanks for .parent element, thanks for .Children. Anyone mention how every browser copied inner HTML? Anyone mention XLST support from the go that was once again copied by others? The list goes on..AJAX IE had it back in the day man where was FF and Opera? IE7 rules so far and when they are done FF and Opera will be coping them and implementing every feature IE came out with. Nickel and Dime software here today gone tomorrow.

It seems to me that, if the new browser IS in fact standards compliant, then the hacks will just pass them by, as they do Safari, Firefox and the other compliant browsers.

I don’t think I’m going to ‘de-hack’ anything until Microsoft lets us know that, say, 90% of their users have migrated to the new browser. After all, the whole point behind the hacks was to make the CSS work for the 90% of the audience who were using a non-compliant browser.

To me, I think my life is become more troublesome now that there are no longer any techniques to treat each browser differently.

It is understood among the majority that the way pages are rendered depends on the browser. I see in Firefox I must specify a height in a div tag that has another (set of) div tag(s) with content in it or else the div tag border shrinks to the smallest height possible (which is not encompassing all that lies inside).

To me, the hacks were not exactly hacks and the bugs were not bugs. It was part of the way browsers worked. If rendering of every browser is not the same, then each browser should have a unique code to it.

You all should look into going all-CSS. The web community has made a lot of advances in the past 10 years. It’s great that Microsoft is going to help us out again. Unfortunately IE fell off the priorities list after Netscape was crushed. Happily, IE seems to be a priority again, and we’ll be able to do even more cool stuff with CSS.

If you don’t have IE 7 yet, then just catalogue the hacks you’re using so at least you know where they are when you do get IE 7 to play with.

IE 6 is not going away anytime soon (it took more than 3 years for IE 6 to knock IE 5.5 below 50%), so we’re still going to need hacks. We just need to be smart about managing them. If we’re not, well, we, and the businesses we build sites for, will be very sad.

Oh, and the blustering about not supporting IE 7? That’s funny. I don’t think you have a choice if you want to remain in the industry. I for one hope that IE 7’s adoption rate is 10X faster than IE 6’s so I can stop supporting it (because browser’s don’t return from the dead, you know).

It’s a good thing that IE is moving towards better standards-compliance, but, as others have stated, asking us to rewrite our code while IE 7 is still unaccessible to must of us is ridiculous. As responsible software engineers, you could do thousands of sites a big favor (as a compensation for all the rendering bugs IE 6 and its predecessors had brought onto us), and refrain from releasing this browser until all previously hack-worthy bugs have been fixed.

If the suddenly “standards-compliant” IE 7 would ignore our hacks that exploit bugs of IE 6, then should it not render everything correctly? A half-fix is not a fix. It’s much the same as it was with “application/xhtml+xml”. You opted out because you could not support it reliably, and while many (including me) were disappointed, it was the right thing to do. Please either fix every bug where the hacks’ ignorance by IE 7 would cause errors, or don’t expect web developers to frantically start looking for techniques that might break an immature closed-source proprietary browser that is currently used only by a few hundred people.

Yes, it’s a step in the right direction, but you’re still wearing the right shoe on the left foot. Until you correct the shoes, your steps will remain crooked.

If you use CSS hacks to work around standards compliance bugs, then the only thing I’ll say is that isn’t a good versioning strategy - but when you use them to work around issues that AREN’T related standards compliance issues then you are asking for that to break.

As for the other calls to “action”, well, perhaps I’ll respond to those on my own blog.

I did some google-ing on this some time ago. It appears that the idea has been suggested several times on CSS mailing lists, and systematically rejected (mainly on the ground that it would encourage browser-specific code).

I agree that aligning your standard-mode implementation on the consensus of other browsers would be a good idea. On the short term, it’ll avoid some problems for web developpers. On the longer term, it’ll allow a future standard to resolve the issue.

However, I’d like to point out that web page that rely on undefined behaviors are intrinsically broken. Maybe you can get IE to behave like Firefox or Opera, but it doesn’t mean that any standard compliant will behave in the same way. Designing Firefox-only websites is no better than IE-only. Moreover, in some other gray areas, there may not be a consensus between other web browsers.

As a CSS developer I’m well aware of which hacks I’ve used where and why, and as far as I can tell nothing will break with the arrival of IE7.

I presume this post is a preemptive strike so that IE’s critics won’t be able to say “IE 7 Launched; Internet Breaks”. But if you’ve done what you say you’ve done this won’t happen. I’m very pleased that the ‘* html’ hack has been removed ‘casue all my pages would go bad without it. What you seem to be saying here, though, is: “we haven’t quite fixed the layout, so you need to check out other ways of hacking IE”. Before we’ve even seen it.

I trully believe you ought to consider bringing forward the release of Beta 2 - even if it’s only Beta 1 with the CSS changes (and slate a Beta 3 relase for December with the other stuff). I can’t be the only one who wants to check my sites in IE7, but none of us are going to rewrite a single line of CSS til we’ve seen it.

I know it’s not an ‘ie-hack’ but it’s a bit of a hack anyway and it standards compliant browsers it relies greatly or proper parsing and implementation of css’ :after and the IE hack side of it relies on IE’s incorrect box model always expanding to enclose floated contents.

I think a number of you are missing the point. The problem, as I see it, is that many web designers have gone and used particular hacks to hide or show rules for IE, when the hack is a totally separate symptom unrelated to the issue they’re trying to work around.

It’s fine to work around bugs in a specific version of IE - but you’re not versioning that or allowing us to not break your content while moving our standards compliance forward.

As for me I’ll probably be CSS hacking for a couple more years. One of the main reasons I’ll be doing this is because it’s quite easy, it can fix problems easy with a well written hack. Secondly, Netscape and IE Mac have annoying CSS bugs; also because of compatibility.  When a browser updates they often fix the display bugs with the parser bugs, which makes for only a small number of updates needed instead of writing a whole new CSS file.

But, I wish I could say I’m surprised by some of the negative feedback and people still wanting to use IE hacks in their stylesheets but I’m not.
This is all relatively simple, which is also the message I took out of this post.

IE conditional comments provide a neat way of organizing ALL your IE hacks so if you need to hack IE, use conditional comments. Why do it any other way?
Lets just accept the differences between IE and the other browsers and get over it! IE 7 is a significant step forward towards a more standards compliant rendering experience and as Joel pointed out, this is not an example of an IE bug, simply a rendering issue between IE 7 and other browsers.

Some people may complain and say “what about people that don’t have JavaScript installed/enabled”? I imagine that the only browsers that are in that demographic are speech browsers, search engines or customized by paranoid techies.

I consider myself to be quite open-minded. I guess Slashdot is using an IE6 CSS bug to work around the IE rendering difference, but the CSS bug is fixed so in IE7 Slashdot’s code doesn’t know to apply the rendering adjustment.

It would be nice if IE7 (in strict mode, at least) would follow the implementation of other browsers in cases where something is unspecified and the other browsers have come to an apparent consensus. Such cases aren’t technically bugs, but that doesn’t really matter if we have to write a hack for it anyway.

IE6 and other browsers don’t reserve vertical space for other empty elements like paragraphs, so it seems like a bit of a special case to do so for legends, but I guess we have to live with it.

A CSS hack I’ve used a bit is writing _height to mean min-height in IE, but I haven’t seen anything mentioned about the underscore hack or the implementation of height and min-height.

Has the IE-Team ever considered implementing the conditional comments feature for CSS documents, too?
I understand that you can achieve the same if you just embed the aforementioned piece of code in your (X) HTML document. But the point is that this may not be an option for every project out there and having all your CSS Code in one place can be very advantageous at times or simply be convenient.

Internet Explorer 7 users have made a definite stand-out for cleaning up existing CSS hacks in their pages for IE7. It is has been their policy since IE6 that under quirks doc type, they will not make any behavioral changes so that existing pages will continue to render unmodified, but under the strict doc type, they want to change behavior to be as compliant as possible with the web standards.

For IE7, they introduced CSS functionality and cleaned up their parser bugs.

Walking severely into a CSS hack trap is quite easy. For example, just clean HTML with a full complement of CSS. You should notice the strange behavior with their search box being moved into the footer of their page. As a result, the legend tag is empty. IE6 and IE7 reserve white space for the empty legend tag. The HTML 4.01 spec does not specify what should happen in this case. The legend element is required according to the HTML valuator, so Slashdot did the right thing to put an empty element in the page.

Ideally IE 6 keeps getting the height wrong and ignoring the child selector. But IE7 understands the child selector, and properly overrides the height and applies the min-height. I suppose IE6 will ignore the style because it doesn’t understand the child selector, and it won’t affect any of the other browsers who apparently have the equivalent behavior. Actually, the best fix would be to remove the empty legend tag since it’s not serving any purpose, or put content in it.

But I don’t understand why you would want to use browser-specific code in this specific case. Since the problem is that the standard doesn’t specify a standard behavior in the case, it seems natural to explicitly request a behavior for all browsers.

Slashdot isn’t trying to work around a bug in IE; they are trying to work around a rendering difference between IE and the rest of the world. The spec doesn’t define how an empty legend should be rendered, and IE chose a different path than other browsers. Since the spec doesn’t define it, different rendering is not a bug.

Creating a CSS Toolshed submission can be achieved step by step. Making each developer to submit their designs to the working class environment can be a real stimulation for real world simulation websites. Now, I’m really sure many fanatic developers can’t wait to lay their hands on creating on the perfect design and submitting it to the CSS Toolshed.

Well, people find time to produce 12341 wallpapers for deviant art, or create yet another CSS layout that repeats mistakes others have made before instead of goggling a bit before plunging into it.

People also have time to ask questions that have been answered countless times on a mailing list, added to the Wiki and coming up as the first 20 results in Google.

Right now I consider the biggest problem of CSS that everybody wants to start something on their own rather than contributing to a centralized repository.

The “happy cock” layout took me one hour while riding the train home, and by re-using the skeleton CSS selectors it should now be pretty easy to come up with something in a short period of time.

Basically, for creating a CSS Toolshed submission, you’ll need to include all the necessary images, even more templates containing almost all elements of the building block gallery and pre-fined CSS selectors with all the content elements.

However, it seems a bit more idealistic in terms of time and resources that’s required to attack something at this scale. Let’s face it; (perhaps speaking for myself) developers are enthusiastic about projects only if they can foresee a visible outcome within a ‘realistic’ time-frame. Perhaps this is the sole reason why products like zen garden managed to break through.

A common reason for sites being inaccessible is the general ignorance among CMS developers. Very few seem to actually understand what accessibility (or web standards, for that matter) is. Because of that ignorance, which seems to be particularly widespread among enterprise-level CMS vendors, most CMSs have an inaccessible admin interface that is used to publish inaccessible websites.

I always make sure that whatever CMS I use, I will at least allow the published content to be accessible and standards compliant. But the admin interface used to publish content is a different matter.

We rarely even touch that, for several reasons:Understanding the mish-mash of nested tables, 20th century HTML, and JavaScript dependencies that most CMS admin interfaces consist of is near impossible.

Messing around with the admin interface is asking for trouble when it’s time to upgrade the CMS.It isn’t really our job, unless a CMS vendor pays us to do what they should have done from the beginning.

So, are there any options if you want a CMS that has an accessible admin interface? Perhaps.

When it comes to commercial alternatives, I am not aware of any CMS whose admin interface even comes close to being accessible. But obviously I haven’t used them all (which I doubt any single person has).

If you happen to know of any accessible commercial options, please speak up.

Maintaining the code in projects that have been in the hands of several people before you is almost always a pain. Trying to make sense of the front-end code used by a CMS is, in my experience, always a huge time-waster. Cleaning up HTML, CSS, or JavaScript created by people who don’t know HTML, CSS, or JavaScript is another non-favourite pastime of mine.

The reason all those things are no fun is very often code bloat. We’ve all seen it, and we’ve all been guilty of creating it.

Nevertheless, what causes code bloat? Code solutions include failure to specialize, lack of a front end build process, bad or non existent documentation, maintenance without using the right tools, wrong perception of time needed to accustom ourselves to a project.

Most of your bloating things may come from timing constraints. Working on a whole css on a project, you’ll end up with links to 3 style sheets and a few embedded modifications of it.

Some code bloat is inevitable, but other times it is entirely avoidable. My life would be a lot easier if people had any idea how to write best practice maintainable CSS and XHTML — let alone valid code. Some of the things I’ve seen would make The Daily WTF seem tame.

Specialization is vital. Front-end developers, i.e. people who concentrate on writing XHTML and CSS, are vital. It’s a bit of a joke to expect back-end developers or graphic designers to know all of the ins and outs of valid, semantic and accessible markup. The field is just too complex nowadays for people not to specialize.

Developers think that HTML and JS are very simple and never (only in some exceptions) try to enhance their skills.

Let’s hope for the best.

So as Intel was designing Viiv, Kim planned similar marketing campaigns around those two names with the same requirements as Centrino. The message was supposed to be: Viiv is the ultimate digital home PC, or vPro is the ultimate business PC.

In Viiv’s case, Intel wanted PC shoppers to associate that brand with the perfect multimedia PC, with plenty of performance for media decoding, networking chips that streamed movies around the home, and smart software that makes all this as easy as setting the clock on the VCR.

Later, Intel would unveil services branded to work with Viiv PCs and big-screen TVs.

The problem is that people haven’t shown wide interest in using PCs this way. And those who have are generally savvy enough to know what kind of performance and software they need without having to match little colored stickers on PCs to software applications and services.

The Viiv name is strange, of course.

PC buyers just don’t understand what makes a Viiv PC a Viiv PC, Baker said. Whereas Centrino stuck in buyers’ minds as wireless networking, Viiv never offered PC users anything they really wanted or that they couldn’t get elsewhere.

People understand Core as a brand because it represents Intel’s best available processor, Baker said.