molly.com
Wednesday 21 December 2005
star html poll comments
This page is to take comments on positioniseverything.net’s poll regarding * html implementation in IE7.
Filed under: general
Posted by: Molly | 15:28 | Comments (99)
skip to the content
If IE7 would continue supporting the ‘* html’ hack, while fixing the ‘Expanding Box Problem’ all layouts using the HollyHack-StarHtml combo would break (make elements 1% high).
If IE7 stops supporting StarHtml while a few bugs remain that require Layout only a few sites will break.
What we need is a specific way to target IE7 for the (hopefull) rare cases where Layout is still required.
Historically, the number of working hacks tends to be proportional to the problems in a browser. However, we now face the possibility that a major new browser will remove the workarounds without fixing the reason for the workarounds.
I suppose we could move the hacks into a conditional style sheet, but it means having three major sets of code: IE 5-6, IE 7, and standards based.
One site we did a while ago is a veritable a-z of reasons to use the * html hack. Ok, it’s a complicated design, but a useful test case?
http://www.number10.gov.uk/styles/nomensa.css
New versions of Opera, Safari & Firefox have come out since this was launched with no problem… I’m not quite so hopeful for IE 7.
I have been told by Marcus Mielke of Microsoft, that IE7 will NOT fix the expanding box problem. If that were going to happen, the Holly hack would be IE7’s mortal enemy, and would have to be eliminated.
Quote:
One site we did a while ago is a veritable a-z of reasons to use the * html hack. Ok, it’s a complicated design, but a useful test case?
http://www.number10.gov.uk/styles/nomensa.css
—————————
Oh my! I feel your pain, Alastair. That CSS is definetly going to need a CC job. Oy.
I wont be affected at all if the Star-HTML hack stops working! But I feel sorry for all the people who it does affect.
IMHO, the * html hack *must not* be retained under any circumstances. The information given in the poll does not provide any argument for retaining it at all, it only provides an argument for not retaining it if the expanding box bug were fixed. Now that we know it won’t be, the decision of keeping or removing the * html hack is not affected by it at all. If it were retained, yet the bugs it were actually used to address (i.e. the layout bug, min-width, etc.) were also fixed, then we would have serious problems. I cannot stress enough that * html *MUST NOT* be retained.
BTW, my last statement only applies under standards mode. I couldn’t care less what they do with quirks mode.
Yes, the expanding box problem is a pain in the arse. Enough of a pain that you have to wonder why Microsoft hasn’t addressed it sooner, or why they aren’t addressing it with this release, but that is an argument for another time.
Regardless of that however, the larger problem lies in things like this whole poorly documented, little known “has layout” issue. Yes, MS has been forthcoming with more information on this particular issue, but it is exactly these quirky, hidden, proprietary things like “has layout” that are causing the ulcers and migraines.
For now, until there is a publicly available beta release for developers to work with all the rest of us can do is wait and see if MS fulfills its own prophecy in that with the fixing of IE they will in turn break the internet.
Quote:
“IMHO, the * html hack must not be retained under any circumstances. The information given in the poll does not provide any argument for retaining it at all, it only provides an argument for not retaining it if the expanding box bug were fixed. Now that we know it won’t be, the decision of keeping or removing the * html hack is not affected by it at all. If it were retained, yet the bugs it were actually used to address (i.e. the layout bug, min-width, etc.) were also fixed, then we would have serious problems. I cannot stress enough that * html MUST NOT be retained.”
Some bugs will be fixed, that’s true, but many others will remain, so the need to induce layout will still be needed. Also, as long as the expanding box problem still exists, the Holly hack fix is totally harmless, even if IE7 were to eliminate layout entirely.
Given that retaining the hack has no serious down-side issues in IE7, and does avoid causing lots of extra unpaid work for people, I don’t see why the hack has to be killed at this time. Sure, it would be wonderful if IE was totally compliant and such hacks were gone, but that is not presently the case.
When Vista arrives, it will presumably not have the layout effects, and then eliminating the hack would only affect those who have continued to use it for minor special tweaking. Such tweaking is not really necessary to have complex layout in IE, so there is no pressing need to accomodate legacy coding of that kind.
Between now and then, PIE and other sites will be educating coders that using the Star-HTML hack for easy tweaking may come back to bite them later, so hopefully by the time of Vista’s advent the potiential pain from that source will be greatly reduced.
IMO, I’d rather they just get rid of it. Its non-standard behavior, and its quite easy to get around it not being there. Conditional comments. Server-side script. Personally, I never use or teach others about parsing hacks. In the end it’s a bug, and we all know that sooner or later bugs get fixed. I really don’t think doing a conditional comment style sheet is much more work and it keeps all that non-interoperable, junk CSS quarantined.
Quote:
“IMO, I’d rather they just get rid of it. Its non-standard behavior, and its quite easy to get around it not being there.”
That’s a point I’d pick up on, complex layouts are not easy when it comes to working around IE. Take this for example:
http://positioniseverything.net/articles/onetruelayout/example/rounded
13 counts on the * html hack. That’s not a critisism, it’s necessary for complex layouts that work across the mani browsers.
There are things you have to put in for IE that are not needed for other browsers, and are actually harmful for standards compliant browsers.
If IE7 does not fix the reasons for the hack, the best way forward would be to leave the hack as a useful filter. Unless there’s a valid alternative?
It’s not a question of what’s easier in the future; I will never use the Star-HTML hack again, you can be sure. The problem is all those client’s sites, and my own pages, that I will have to deal with, for no other reason than an arbitrary choice by MS to “do the right thing.” I happen to think that they are ignorant of what the real situation is, and their choice is the wrong one.
Big John, the issue is not quite as simple as you make it out to be. Your argument for retaining * html is entirely dependant upon the condition that the substutite styles contained within the rule are also subject to the existing IE6 broken interpretation.
Given the example of * html { height: 1%; } (now that we know the expanding box bug won’t be fixed), this is indeed the case, but insert any other substitute CSS for any other bug and you have serious problems if that specific bug has been fixed.
Personally, * html is one of the only hacks I ever use these days (most of my CSS is hack free) and I *only ever* use it to solve ‘min-height’ (because of the expanding box bug) and the layout related bugs (for which the holly hack was devised).
Since ‘min-height/width’ will be supported and most (even if not all) layout bugs will be fixed in IE7, my CSS is unlikely to suffer majorly (if at all) with the transition to IE7 regardless of whether * html is supported or not. But even if it does suffer, that’s the risk we all take every day by using hacks at all and, yes, I would prefer not to, but until the corporate world learns to accept more significant graceful degradation in IE6, we have no choice.
But we must remember one major point Tantek promotes is that hacks should only ever target obsolete browsers. By intentionally continuing to support * html in IE7, that rule is being majorly and very likely irreperably FUBARed.
* html *MUST* remain IE6 and earlier (and IE7 quirks), so that the rule about hacks only targetting obsolete browsers is retained. I agree that * html must be killed eventually, but as long as IE6 retains significant market share, it is a necessary evil, which is why it *MUST NOT* apply in IE7 (standards mode).
I have more to say on this issue, but I think I’ll blog about it on my own blog later. It’s a very complicated issue.
On the issue of IE7 fixing most layout bugs, that is certainly what MS claims, but the beta so far only fixes the Peekaboo and Guillotine bugs. Even if they fix every bug on their list, the fact is that there are many dozens of bug variants caused by lack of layout. I see a new one almost every week.
I find it difficult to believe that the need for layout fixing will be mostly removed while the basic layout rendering continues to exist. It would be wonderful if that was so, but my experience tells me to be wary.
I’m with Lachlan and some others here. Keeping the * html hack is insane. It is, so far, the only good news for me that it wouldn’t work anymore in IE7.
1/ pages that use that filter: are we sure we still need it in the future?
2/ pages that use that filter: OK, I’ve some stable code for IE 6, I can attempt to fix the mess in IE 7 without worrying about IE 6.
3/ scanning mailing lists and so, most people use hte star html hack to serve the ‘holly hack’, with a percentage height. Has anybody ever realised that serving {height:1%} to a selector will *never* affect the height of a box, according to css 2.1? (except if that box is absolute positioned or if the parent box has a height specified). Essentially adding the * html hack to it is useless in many cases.
Beside, there are more ways to induce ‘layout’ when needed, and I’m in no doubt that there are way more important issues to work on than dealing with that little * html thingie. Conditional Comments rule, btw.
Chris Wilson, if you happen to read this, you have my full support for removing the * html thing out of IE 7
So, when we get the next IE7 beta (in which they’ve claimed to have fixed much more than those 2 bugs), we’ll see what bugs are still present and what still needs fixing.
Then, and only then, will we be able to determine what hacks are required and what hacks aren’t, but intentionally making hacks intended for, and *only tested in*, IE5/6 also apply to IE7 when an unknown number of them either will or will not need to be applied is insane.
Why take the risk of sending intentionally broken CSS rules to a browser with mostly unknown bugs/fixes in the hope that they a) don’t cause any other issues and b) they still manage to work around the few bugs carried over from IE6?
Quote:
“Then, and only then, will we be able to determine what hacks are required and what hacks aren’t, but intentionally making hacks intended for, and only tested in, IE5/6 also apply to IE7 when an unknown number of them either will or will not need to be applied is insane.
Why take the risk of sending intentionally broken CSS rules to a browser with mostly unknown bugs/fixes in the hope that they a) don’t cause any other issues and b) they still manage to work around the few bugs carried over from IE6?”
I honestly don’t understand this reasoning. I don’t see anyone asking for a new hack. I just want the old Holly hack to remain in place while it is still needed. Since IE7 still expands boxes and still has the layout problem, the Holly hack will behave exactly the same in IE7 as in all the earlier versions. If the hack is kept, nothing new will happen.
Also, the Holly hack is not “broken CSS,” by any stretch. It uses a valid selector to feed a valid height, and it so happens that IE/Win sees those things differently than other browsers, It is IE that is broken, and this version is not going to change that fact very much.
If IE/Win does not need layout to fix a bug, then nothing is harmed by having it, unless it is used on a block element directly following a float. But layout fixing is virtually never needed in that situation. At least I have never seen such a case.
As to the last issue, I did not, nor am I now advocating continued use of the Star-HTML hack. This issue only concerns already-existing web code that would have to be repaired only because of MS’s decision. Can you give me any clear arguments for removing the hack in IE7, other than pointing out possible risks inherent for hacks in general?
Suppose they do retain the hack, what actual known problems might arise, and how would they compare to the issue I am bringing up? I’m prepared to be convinced, but I need somthing concrete to think about, not “what-ifs” that may or may not happen. I know for a fact that the current track will lead to a big pain in the neck for me and quite a few others.
Take every CSS2/2.1 rule in the specs and count every possible workaround for making IE6 play along and imitate each of those.
Expect a small number of those IE-only workarounds to be fed through a ‘* html’ hack. Expect a small percentage of those workarounds to be in conflict with the improved standard-compliance that the IE-team have projected.
Sum: thousands of targeted fixes that hits the wrong target – found on millions of existing sites. Another hack needed just to keep those targeted hacks from backfiring when IE7 is released. All this because you want to keep the ‘* html’ hack in place for one, single, fix that can be so easily replaced if it’s needed for IE7.
It won’t be my problem, but the ‘* html’ hack has to go. If not, then the next IE will indeed break the web. Sounds like fun
IMO, IE6 (in standard mode) is quite compliant in most rendering areas. It was IE5 and IE5.5 that had the serious little flaws all over the place. When IE6 appeared, it fixed a large number of these nagging little issues, while also introducing neb layout-related bugs like the Peekaboo.
My thinking is that any Star-HTML hacks written for IE variances other than those caused by layout, will have been designed to fix IE5.x, and not IE6. The IE7 beta is not showing any real rendering differences from IE6.
MS has enough trouble dealing with security and fixing the slew of real bugs that appeared in IE6. Why would they be tinkering with minor rendering effects that were almost entirely corrected in IE6 anyway? Even if they did, there isn’t that much wrong with IE6’s rendering, unless layout is involved. Poeple savvy enough to use the Holly hack are usually savvy enough to design in ways that don’t need variance hacks sprinkled all over the CSS.
I believe layout drives most current use of the Star-HTML hack. Maybe I’m wrong, but I view a large number of web stylesheets every week, and I’m not seeing Star-HTML hacks that would harm IE7, unless it renders radically differently than IE6, and it isn’t, so far. I do however, see very many sites using the Holly hack, and every one of them would break if the hack is killed.
“The IE7 beta is not showing any real rendering differences from IE6.”
Good to know that IE7 is just a security-update. Then we can ignore IE7 completely, and wait for IE8, 9 or 10 before checking anything. By then the IE-hacks would have become such an integrated part of web design that they can’t ever be fixed. One more opportunity lost.
I’m finding the logic being tossed around here pretty confusing. Humor me for a sec and see if the following statement makes any sense:
Statement A:
“IF IE7 retains any IE legacy rendering bugs AND IF IE7 is immunized from the Star-HTML Hack, THEN IE7 will incorrectly render many websites that use the Star-HTML Hack to work around IE legacy rendering bugs.”
Is my logic sound? If not, you can stop reading now. Thanks for your time! If Statement A is logically sound, then an obvious subsequent statement can be proposed:
Statement B:
“IF IE7 *fixes all* IE legacy rendering bugs AND IF IE7 is not immunized from the Star-HTML Hack, THEN IE7 will correctly render all websites that use the Star-HTML Hack to work around IE legacy rendering bugs.”
Statement B would be logically sound (assuming Statement A is logically sound) because IE7 would ignore kludges that use the Star-HTML Hack.
A reasonable conclusion could be that if Microsoft is planning on immunizing IE7 from the Star-HTML hack, then it should also plan on removing every IE legacy rendering bug from IE7 as well.
As a point of clarification for my last post:
“IE7 is immunized from the Star-HTML Hack” means that IE7 does not have the parsing bug that allows the Star-HTML Hack to work.
“IE7 is not immunized from the Star-HTML Hack” means that IE7 retains the parsing bug that allows the Star-HTML Hack to work.
Legacy rendering bugs should be kept out of the equation, as those are ‘quirks mode’ bugs and should rather not be touched since almost the entire web rely on at least some of them.
It is when we’re dealing with ’standard compliant mode’/”Strict mode” that a really good clean-up is needed and standards should be implemented as close to 100% as humanly possible for that old engine.
Rules that IE6 does understand (buggy or not) are already being used to make IE6 render close to what other browsers do when they are given standard rules that IE6 does not understand. That’s why the IE-team wants web developers to stop using hacks and “clever workarounds”, so they can go on fixing things and bring IE7 up to specs.
Thus, the question is what will be rendered when new rules and old fixes served via a ‘* html’ hack are competing for attention in IE7. Chances are the result will be pretty chaotic at times.
Not so if IE7 is “immunized” from the ‘* html’ hack and brought up to specs at the same time, although I’m sure the result will still be anything but standard-compliant in many cases.
There’s only a few solutions to this.
1: IE7 is just an update of IE6 without any real improvements, and all hacks are working as before. No need to check rendering since nothing much has changed. The IE7-team can leave the job right now.
2: IE7 is improved to the point where it doesn’t need any of the old workarounds. That means close to 100% of CSS1/2/2.1 and a thorough clean-up – which includes getting rid of the ‘Layout’ behavior. Plenty of work ahead for the IE7-team.
3: IE7 is improved half way between 1 and 2 and will break sites all over the web, regardless of what happens to the ‘* html’ hack. Chances are that this is what we’ll get, but I hope not.
Georg said:
“Legacy rendering bugs should be kept out of the equation, as those are ‘quirks mode’ bugs and should rather not be touched since almost the entire web rely on at least some of them.
It is when we’re dealing with ’standard compliant mode’/”Strict mode” that a really good clean-up is needed and standards should be implemented as close to 100% as humanly possible for that old engine.”
A reasonable clarification of purpose and scope, to be sure.
However, are there not certain rendering bugs in IE that persist even when the browser is standards-compliant mode? And don’t web developers sometimes use the Star-HTML Hack to work around said rendering bugs?
Certainly, there must be at least one. Let’s take, for example, the Box Model Problem. PIE recommended using the Tan Hack as a kludge (http://www.communitymx.com/content/article.cfm?page=2&cid=E0989953B6F20B41), and I, for one, complied. Unfortunately, the Tan Hack exploits the Star-HTML Hack.
The ‘* html’ hack has been used to feed exclusive styles to IE5+ win and Mac for years. Mostly followed by more selectors/hacks to target the right version. One can only imagine which one of all these combinations that may end up in IE7 in ’standard compliant mode’ if the ‘* html’ gets through.
It is time to cut the losses and get rid of the ‘* html’ hack for good in ’standard compliant mode’.
PIE wrote:
“What we need before we can begin converting Microsoft, is some hard data. Perhaps there aren’t that many people who will be affected, eh? Who knows? Well, there are ways to find out, and one of them is by taking a poll.”
If you are really interested in finding out how many sites will be affected, a much more reliable method would be to spider several thousand (or million) sites looking for * html in the CSS. The object would be to determine what percentage of sites use * html. You could go farther and examine (perhaps programmatically) the CSS of those that do use it, to answer your own question.
Microsoft would be far more likely to be concerned if you could show that * html is used on a significant percentage of web sites today. Such info would be based on real-world coding practices, which MS could, presumably, verify on their own.
That’s a good idea! Is there a way to do that? Can the css BE spidered or searched?
Quote:
“One can only imagine which one of all these combinations that may end up in IE7 in ’standard compliant mode’ if the ‘* html’ gets through.”
I’m having trouble imagining any likely combination of code that would cause trouble in IE7, with the hack still in place. Can you be more specific?
Q:
“I’m having trouble imagining any likely combination of code that would cause trouble in IE7, with the hack still in place. Can you be more specific?”
A:
Only when I’ve had the chance to rip apart a finished version of IE7 – with the ‘* html’ hack still working. Until then my imagination is no better than anyone else’s on what might get through.
‘* html>body some_selector’ comes to mind.
‘* html some_selector {property: value; property/**/:value; propert\y: value’;} is another well documented version.
I do know for a fact that none of the above will get through if the ‘* html’ hack is prohibited from working in IE7 Strict mode, and that sounds more assuring than anything else I can imagine.
I prefer to deal with IE7 on its own when it arrives – without having to care about any old IE-hacks. I’m not the least afraid that I won’t find a way in to that rendering-engine if/when I need one.
Quote:
“* html>body someselector comes to mind.”
Wouldn’t that selector be unreadable by all current browsers? Who would use it?
Quote:
“* html someselector {property: value; property/**/:value; propert\y: value;}”
I have seen such usage, but let’s look at it. Assuming that IE7 continues to read the “* html” part, what then would prevent it from reading the rest? Both of those internal hacks are valid syntax, and IE6 has no problem with them under any conditions.
While I can’t prove IE7 won’t regress and start reading those constructions incorrectly, it’s seems rather unlikely that MS would allow syntax reading errors that they previously fixed to creep back into later IE versions.
I have to correct myself; the first selector above could be used to feed rules only to IE/mac. It’s not a hack construction I have ever seen on the web, but I suppose someone might have used it somewhere.
In such a case, I will admit that IE7 might get values that it doesn’t need, but all such cases I’m aware of have employed the safer and more useful comment-based machack:
/*\*/
styles only for IE/Mac
/* */
That browser is the only one that is able to read the above styles, and the hack is reversable too. Also, it does not risk breakage in future browsers as the child hack clearly did.
Anyone who knows about the star-child construction is likely to also know about the good old machack, and will tend to prefer it for its superiority.
Sorry, the blog comments seem to have eaten some of my hack-comments! Here’s a link to an explaination instead:
http://www.sam-i-am.com/work/sandbox/css/mac_ie5_hack.html
I quote part of a reply comment from someone in the IE Blog regarding the ommission of the * html hack.
“From here on out it’s either get the rendering engine perfect or go back on their word and continue letting * html do what we’ve used it for even in IE7 standards mode”
I must say i couldn’t agree more, if removing the * html bug renders the site as it’s intended to be WITHOUT any conditional comments, then, THAT is the way to go.
The blog ate some of my example too, but my real examples are working well in today’s IE. I use them for non-critical testing, and they are part of [http://www.dithered.com/css_filters/css_only/index.php] which means that some web developers may actually pick them up and use them.
I know perfectly well how to separate IEMac from the rest of the IE family, and also how to keep old IE from new ones – regardless of how many parsing bugs, and other bugs, they may have. I’m afraid that knowledge is a lot weaker across the web, and it won’t be any better if some “convenient” hacks are left un-fixed.
Whether it’s one type of hacks that need to be fixed or it’s another one, is more or less irrelevant as I see it. IE7 will cause some problems no matter what.
The more hack-induced problems that get fixed with the arrival of IE7, the less problems will have to be dealt with later. Those who won’t deal with this now should rather ask the IE7 team to not release anything but a new IE6 with security-fixes and nothing else. In fact; they’ll get just that since IE7 will handle DTD-less designs just as well/bad as before. That’s the only “hack” weak designs/designers will ever need.
Myself, I want to see an improved version of IE so the web can at least move a small step forward. Just the thought of keeping any bugs because their presence are convenient at the moment, is completely absurd – to me.
My goodness, what a storm in a teacup. Whilst I’ve used the star-html hack in the past, it’s not the best way to do it! Seriously.
IE provides its own set of nice, if a bit quirky, conditional comments you can use to feed it an IE-only stylesheet or even stylesheets based on versions of the browser right back to IE5!
So if you’re still using the star-html hack, you’re very naughty indeed.
“My goodness, what a storm in a teacup.”
That’s the only kind of storms we can create out here. We call them “discussions”.
Of course
The conditional comments are in place when needed at all sites I have created, but that doesn’t help anyone else’s sites/work. It doesn’t help the projected progress of Internet Explorer either, in case you have missed the point.
Have a look around the web and see how many “naughty” designers there are behind all those sites. You’ll find plenty, and many of them will have to adjust their work to suit IE7, no matter what.
I a bit confused, maybe its because I’m still a student in this field. Never the less, why are we so concerned that IE won’t support our hacks. They are HACKS after all and should be avoided in the first place. I’m more concerned that IE still won’t fix the reason we need to hack in the first place. I’m annoyed that IE is focusing its attention on making it “standards compliant” without fixing the bugs. I’d rather see a browser that maybe doesn’t support 100% of the latest features but what it does support IT GETS CORRECT. Its easy to get around a non-supported feature but with a true bug we have no other choice but to hack.
So here’s where I stand on this. If IE fixes the underlying problems by all means get rid of the hacks, until then we need SOMETHING (hacks) to make it behave.
My position is that IE7 will NOT be free of the layout hassle,
and the most commonly used method to trigger layout is going be
made to fail arbitrarily in IE7, causing a lot more difficulty
than leaving it in would do. We don’t need this hack to die now,
but in Vista, when the need for it will also die. If it is done
that way, the transition will be almost painless, unlike what is
about to happen.
As for the hack being naughty, it became known well before the existence
of conditional comments did. Okay, maybe all coders should have instantly
switched to CC’s then, but that didn’t happen, and even if it had, there
would still be a lot of sites with the Holly hack.
If IE7 was really going to be fixed properly, I would be rooting for the
end of that hack, but it’s not, and layout is still needed. Suggesting that
many people should do a pile of extra site repair work just because hacks
are “wrong” does not cut any ice with me. Let IE be made even close to the
other browsers in compliance, and I will join the coding purity crowd. Not before.
Facts regarding IE7:
We’ve been told that the layout problems will not be solved.
We’ve been told that (parts of) CSS2/2.1 will be implemented.
We’ve been told that IE7 will have bugs.
Which parts, if any, of what we’ve been told that’ll be true and/or mean anything to web developers, is completely “in the blue”. It will probably remain there till long after IE7 has been released.
It’s arbitrary, indeed.
Since IE is only “worst in class” when it comes to compliance, no web developer can really claim to belong to a “purity crowd”. An “avoid problems crowd” may exist though. Also, there are apparently a number of “my way or noway crowds” around. All of the before mentioned crowds are probably well founded, so they’ll probably all come out on top one way or another, no matter what. Thus, no big deal.
It is maybe because I don’t see it as such a big deal that I rather see that the IE7 team get rid of as many bugs and bug-reliant hacks as humanly possible – now. It’s about time.
I can see Big John’s reasoning for leaving * html in IE7 at this stage, though ultimately it must be removed.
All of these problems would go away if IE7 was going to be as standards compliant as Firefox, Opera etc. Presumably it won’t be because of fear of breaking the millions of sites that were written for IE.
Unfortunately we are stuck with the certainty that IE7 will be a halfway house and as a result we will have to go back and fix any problems that show up in legacy code.
Dear Microsoft,
Internet Explorer is a web browser. At the very least I would hope that version 7 of your product will support the basic standards of the web before you consider releasing it. Some would argue that failure to support standards is like selling a car without support for braking. I’m certain many of your users won’t notice the flaw, but web developers who are already overly-annoyed with having to support version 6 may be less likely to try as hard with version 7 should it fail to support minimal standards. The release of any major browser has ramifications that reach many years into the future. Learn from past mistakes. You need to be very, very careful moving forward.
Sincerely,
Hopeful
If Microsoft fixes CSS parsing bugs we rely on for using as filters, without also fixing the rendering bugs that make using those filters necessary, I will take issue with that. Seriously. Especially if Microsoft knows about it, as I’m sure they do.
Isn’t this exactly what we anticipated as our worst nightmare?
Is it just me? The holly hack totally wrecks the layout in Safari 2.0.2.
Is there a way to suse the height:1% aand make it work in Safari?
I’ve personally never used any hack other than * html ever. Never needed to.
If IE7 respects the standards enough and ignores my *html rules then whatever I used *html for should not be a problem in IE7.
But overall I really wish they would just push back the release of IE7 until its level of CSS support was at least equal to Firefox.
I was rading one forum post that pointed out the vast majority of problems for IE can only be solved by a complete rebuild from the ground up. Anything else is just lipstick on a pig…, window dressing fi you will.
I can’t help but feel Microsoft has forgotten where they came from… when they were young and hungry for market share… and wanted to put out the best possible product… or when Bill Gates himself crashed winows 98 at Comdex in Chicago…
My point being, as the “tallest hog at the trough” so to speak, Microsoft should do the complete ground up rebuild and get to the same level of standards support as Opera and Firefox. Otherwise its all lipstick on a pig…
Alos, this way, when the world calls their data centers in India, the telephone people there have a job with all the overtime they can handle and all they have to remember is “We’re sorry sir, but we now fully support web standards. Once you’re site complies with web standards all should be right witht he world.”
As “THE” software giant, Microsoft should feel obligated to be in the forefront of promoting and complying with the standards…
There will always be browser bugs, so why not introduce browser id in css?
Maybe something like this:
Rule applying to IE 7 only:
#ie7 html p {color:blue}
Rule applying to Firefox 1.5 only:
#ff1.5 html p {color:blue}
make IE disregard * html, make it support min-height/width, make it render the correct height model and all problems are gone…
whatever they do to IE7, they should make it without hacks, living up to the described standards
whatever they do with IE6: they should not change it there (if they’d still be working on some sort of IE6 update, as if…
), so that sites with the hacks in it will be rendered correctly in IE7 and IE6
I have only two websites that I work on, both fairly simple. I’m getting really annoyed with MS’s refusal to make their brower standards compliant. I plan to put a footer on my web pages that says, “Microsoft has had cronic security and standards compliance problems with Internet Explorer. Version 7 shows no sign of correcting this. We recommend using either Firebox or Opera for browsing the Web.” and put links in to their sites.
That said, it is time for Microsoft to ditch the IE codebase and start over, even if it means that they ship with an IE that is semi-patched to sort of work, in addition to a standards compliant browser.
As yourself this, which position do you think MS would like to be in?
1. Total standards compliancy, which would ultimately make other browsers a lot more competitive but is a small price to pay for the future of the web.
2. Proprietry code only compatible with IE and due to IE’s dominance, coders are force to abandon standards as there’s not enough support for it.
As a web design instructor at Mohave Community College in Arizona (where, incidentally, I had the pleasure of Big John dropping by my classes on occasion to hang out and/or offer CSS expertise), I moved from teaching tables to pure CSS within two semesters. (No small feat considering the antiquated textbooks and curriculum specifications as set forth by the college.)
And as a designer, I developed a deep appreciation for John and Holly’s contributions with regard to complex CSS layouts. However, designing sites on a regular basis for paying customers forced me to give serious thought to keeping things as absolutely simple as possible, including, in some cases, rethinking the design if it requires considerable hacking in order to fly in ALL browsers across ALL platforms and OS’s.
In the back of my mind is always that nagging suspicion of what might happen when Microsoft changes the way IE behaves — for better or worse. It’s not that I don’t like staying busy; it’s that I don’t like rebuilding things that already work, just so they’ll work differently.
Having said that, I must say ‘thanks’ to John and Holly Bergevin, and to all those in the development community who continue the ongoing effort to (a) educate designers who are not yet using CSS; and (b) educate one of the world’s largest software developers who is not yet fully awake and smelling the coffee.
Dane Ronnow