Archive for July, 2007

Broken pages discussions part 4

Monday, July 30th, 2007

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.

Broken pages discussions part 3

Monday, July 30th, 2007

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.

Broken pages discussions part 2

Monday, July 30th, 2007

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.

Broken pages discussions part 1

Monday, July 30th, 2007

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.

Broken pages & CSS layouts part 4

Monday, July 30th, 2007

For everyone asking who is going to pay for the ‘additional work’ IE 7 is going to create, well, go talk to who pays your bills now — your customers! Are you honestly suggesting that you want all future versions of IE to be as badly broken as IE 6? As painful as it may be, the answer is to get everyone using a standards compliant browser as quickly as possible.

Is Microsoft responsible for this whole mess? Sure, it has a big share of the blame. But remember this whole thing started before ANYONE was compliant with ANY standards. Remember the browser war? It wasn’t as though everyone’s favorite (Netscape) was standards compliant either. It was a battle and all browsers were trying to figure out what customers really wanted; everyone was looking for an advantage.

If MS had a little more forsight it would probably have realized there isn’t any money in the browser anyway and since it dominates the OS market it would end up being the dominant browser regardless of the competition. It could have saved the world a lot of money, but Microsoft didn’t have the foresight to see that and instead, we have a mess. It may have been the only company that could have prevented the mess but it surely wasn’t the only one that caused it.

We also need to differentiate between the ‘bugs’ and the ‘differences’. Bugs need to be fixed. The “differences” need “alignment”. If the spec isn’t specific enough, we’re going to have problems. Everyone’s favorite suggestion here is to have Microsoft change their decision and make it comply with Firefox’s behavior. I wouldn’t mind seeing that happen. But from the other perspective, IE is still far and away the dominant browser; maybe the other browsers should change the way they handle it? Or maybe someone should figure out which way is better and create a standard!

Some hacks are going to be problematic and there is nothing anyone can do about it. Software changes…we hope it improves and in this case, we hope it becomes standards compliant. The process of doing so will cause us all a lot of pain — this fact of life was ensured way back when MS didn’t commit to a standards compliant browser back from day one. When nobody else did either.

Go ahead, beat them up about not being any smarter than their competition on that issue. I’m going back to work.

Broken pages & CSS layouts part 3

Monday, July 30th, 2007

The only way I can see such hacks causing problems is if IE7 is only half fixed so that either it doesn’t see the hacks but still needs them do to shoddy style rules handling or so that it gets the rules right so that it doesn’t need the hacks, but still reads the hacks anyway due to improper selector rule handling. If both the style rules and the selector rules handling are fixed, there’s no problem, right?

I suppose it’s therapeutic to give everybody an outlet to complain about Microsoft as a corporation. Unfortunately there’s the whacko calling them “capitalistic” as if that’s a bad thing. I thought the problem was when companies *abuse* the system. Oh well.

I wish the signal-to-noise ratio was a bit higher, but between the noise there’s been plenty of good discussion about better ways to handle this problem in CSS.

I think a lot of us agree that display: none would be a more universal way to address the quirky treatment of legend. Since IE’s handling doesn’t technically violate the specification, we should fix it for ALL browsers who handle it IE’s way, not just for IE as a conditional comment would do.

With all due respect to the IE team (and I’m obviously addressing the developers here — not Bill Gates himself), I think we either need more testcases (like the legend element on Slashdot) or a copy of IE7 in our hands. Hacking CSS is a practical consideration, not some sort of science.

I often use the child selector to avoid ‘real’ rendering bugs in IE5/6. Rendering differences are a reality and are something designers and developers needs to advise their clients about.
I’ll be continuing to use the child selector to get around IE5-6 bugs that have been fixed in IE7. And so far it looks like that I’ve dodged a bullet by implementing it in the past for bugs that IE7 seems to have fixed.

So the advice should sound more like; “Only write workarounds for bugs and not for rendering differences.” And make sure your fix is CSS compliant. Remember, your pages will look differently from browser to browser to expect otherwise is folley.

How about you just make IE 7 ignore these hacks like other ’standards compliant’ browser? IE 7 sounds like a job creator… conditional CSS is a total PITA.

Play with the sample code that is posted above by adding some background colors to each element. I think you will agree that IE6 (and IE7?) handling of the legend tag is ugly. If you specify a legend in IE, the background color of the fieldset “escapes” the grouping frame and looks very ugly. In Firefox it stays inside the frame. IE’s interpretation may be within the spec but it does not yield nice looking web pages.

Broken pages & CSS layouts part 2

Monday, July 30th, 2007

It looks quite like a designer’s hybris to assume that non-support of a major browser would change anything on market share. Web design is about serving customers, not about changing markets.

If your site, or the one of your employer/customer breaks, it’s you who’s getting blamed and asked to fix it. If you blame it on IE, then this doesn’t change a thing. Just fix it or get lost. Contrary to your belief web designers are not the center of the universe.

IE7 already works very well with most sites *because* it is more standard compliant, and due to security reasons and MS marketing it’s share will be relevant pretty soon after release.

Aside from the fact that it’s very funny to see MS people ask the community to please remove all the hacks they had to put in to get their pages to render on previous IE versions (really, I laughed out loud) I would like to point out that THE REASON we have all these hacks is the giant marketshare of IE 5 and 6.

Given Joe Public’s upgrade path (many are STILL using 5.5, or even 5.0 by the looks of my logs) I don’t expect IE7 to become mainstream for a long long time to come, and with Firefox reaching maturity and Opera becoming free as in beer it might never happen.

To expect people to fix their pages because you’re creating what is destined to become another niche browser (yes, I’m talking ’bout IE7)…well, you don’t get out much, do you?

If I were you I’d go the MS way and code in CSS-hack-hacks, because hell will freeze over before the community will work with you on this one.

As others have pointed out, it’s a little odd to make this request now when most web developers don’t even have the ability to test their code on IE7. Release the IE7 public beta and I’m sure many of us will jump on this request.

Broken pages & CSS layouts part 1

Monday, July 30th, 2007

CSS hacks are the most ingenious, cleanest and most of the time only way to cope with well-known CSS bugs in IE 5 and 6 like the box model bug, the three pixel jog, the double margin bug, the guillotine bug etc.

The Slashdot <legend> example is about something not specified in the HTML spec and someone decided to target this with a CSS hack. There might be better solutions but to conclude that CSS hacks are evil, is just a sign of utmost ignorance.

I’m sure, that IE7 would have not fixed all bugs. Conditional comments are helpfull, but I prefere to provide a special CSS file for all IEs and use CSS hacks inside to separate the versions. It’s not performant, to use multiple CSS files instead and other authors may use only one CSS file (at media screen). Therefore, and because Microsoft fixes only security bugs in a major version of IE, CSS hacks are quite necessary.

Of course the child-selector cannot be used as a CSS hack any more, but what about * html? I see no reason to fix this bug, because it’s only used as CSS hack. Leave this bug and we have the choice, to change our CSS for IE 7 using the child selector for bugs already fixed in IE 7 and the star-html hack for bugs still remained.

Otherwise we have to find out a new bug for a new CSS hack - but why? We should change our CSS now. You should see the advantage of using a well known CSS hack instead of creatng a new hack when IE7 will be published.

Well, I do appreciate that you work on the IE standard issues and I do also appreciate that you try to inform web designers that this will break some and which hacks.

I would strongly suggest to create a document describing the best practice for web designers to deal with these issues.

CSS debates part 5

Sunday, July 29th, 2007

Mostly, I think it is very good, that you are working on making the IE7 more standards compliant. I don’t think oit is a big deal, because the issue about hacks possibly not working in the future are obvious and have been referred to in countless tutorials. For my part I’ve handled it the other way around and refused to implement hacks. My motto was nice design for those that can do it, but only content for the browsers that can’t. That means that future IE7 users maybe won’t have to wonder anymore, why the design is a bit quirky. And that’s a good thing.

All these IE hacks had to be implemented because Microsoft didn’t come up with a decent web browser. Now where their share on the browser market starts to shrink a tiny little bit they want us to remove to exactly these hacks they have caused themselves. Who’s gonna pay for all this? - As you might have guessed, webdevelopers and their customers.
Microsoft - shame on you!

I hope this is just a joke! I can’t even cout up all the hours I’ve spent in the past ‘fixing’ perfectly good code so that IE can render it somewhat. Now you’re asking me to recode? Let’s put it this way: For the past 1.5 years I’ve told my developers to code corretly. The browsers that understand the code (Firefox) render it correctly. All others don’t to some degree.
This time it’s up to YOU to get your act together. We don’t code for a browser anymore. I don’t see the reason to.

But let’s look on the bright side…
I’m using PNG hacks to allow IE 5.5 + 6 to display PNGs with full alpha channel transparency. Yeah, allright, IE7 can now display alpha channels out of the box. Not only comes this feature WAY too late, but also am I NOT going to remove the hack, no matter how f*cked up PNGs will be displayed in IE7, I don’t even care if it crashes. IE 5+6 visitors are far more important to me than those few IE7 beta crackheads.

I really hope IE7 does not become the common browser.
You can’t just demand that I do the same amount of webdesign work, that I already had to do because you f*cked up all previous IE versions concerning CSS, again.

Sorry Microsofties, too sad you’ll probably never learn it.

CSS debates part 4

Sunday, July 29th, 2007

Regarding the recommendation of using conditional comments, a friend of mine recommended instead that people apply their browser-specific CSS fixes using JavaScript. That would reduce the amount of clutter that needs to be downloaded every time a page is refreshed.
First of all JS has a great amount of incompatibilities itself so this isn’t an option.

Secondly, Not only nerds or people with disabilities have JS deactivated. Look at the download counter of “No-Script” for FireFox which blocks all JS as long as you don’t add the site to your whiteliste. This is very helpful because many sites just do a lot of the ugliest stuff with JS or just disturbing things. JS isn’t HTML and shouldn’t be needed for displaying something. Forcing not only css hacks, written in css, but instead css hacks written in JS. This is not only the same stuff we dealing with right now, it is much worse.

Comment Querys? That would be exactly the same problem. Not near any standard and would require an additional skill from those who don’t know JS or other program languages. This would undermine the goal to be standard conform from the beginning. Doing this only IE can do isn’t the way to go. Everyone who designed a website should know this.

(X)HTML and CSS are different things. (X)HTML to order information and CSS to edit display information, nice formatting and all this neat stuff we love in standard conform browsers. JS is a script languages which CAN be used to do neat stuff to but shouldn’t, under absolutely no circumstances be required for a website to be displayed the way it should on its own.

Now come on everybody. The goal for standard compatibilities is not only because it sounds nice. It is because this helps web developers greatly with their work, it helps people without JS or SQL skills to do a site that works. Without having to read through the half of the web searching why one browser decides to display something completely different just for the sake of being the first who introduced it. With that point taken IE would have to do a whole lot of stuff different. JS hacks or additional non standard object are exactly the opposite way.