Surprise surprise, google release yet another half baked idea, and techies everywhere bend over and demand that the biggest black object in sight be crammed up their orifices so they can ooh and ahh and generally behave like a bunch of desperate teenagers aching for a fisting.

This time it’s Google code, and I am astounded (though I should be used to this by now) that anyone in their right mind thinks that this is an improvement over anything equivalent that already exists.

What’s odd about this particular offering is that while Google stuff is generally useless and good for eye candy, it’s usually reasonably well executed. In this case it seems like they just rounded up a bunch of apache hippie types and let them futz about with this idea just to stop them from damaging anything important.

Trying out this pile of worthless gunk reveals even more flaws. Really basic stuff that shows that Google apparently has a severe QA engineer shortage, or thinks that for trivial toys like this, it doesn’t matter if it’s halfassed. For example, if a project has ‘Apache License 2.0′ specified, the link doesn’t go to the 2.0 license, but to the generic Apache licenses page.

This sloppiness is prevalent throughout the app. For example, all ‘home page’ type links go to code.google.com, but nothing pointing to the hosting home, code.google.com/hosting. You’d have to go all the way to the top, then drill down to get to the main entry point.

The form validation is also bizarrely crap. On the project creation page, the create project button is disabled unless you have a description and summary > 3 characters. All good and well, but if your project name is just one char, that’s fine, the button is enabled.

The issue tracker is somewhat interesting, I do like the freeform label support, but of course, for the sake of consistency with the rest of the app, it’s useless for any real world projects. There’s no way to add custom tags, so you can’t for example add tags for your specific versions. This of course means that for every single issues posted, the first comment you’ll get back from the developer is ‘err, so what version is this again?’

There’s also the issue of stupid defaulting in the issue tracker. I can click new issue, then click submit. There’s no detection for the default content being specified, so it’s very easy to spam a project with a ton of boilerplate issues.

Shame on you Google, but the real blame here is for all the Google fans who allow them to get away with such tawdry offerings.

 There’s something particularly endearing about standing in the lepers line at a particular session at JavaOne this year. The lepers line, in case you weren’t aware, is for the poor sods who showed up to a session thinking they had registered, when they in fact hadn’t. You stick you card on the cute little reader, and it flashes an angry accusatory red, insisting you have not registered. The nearest usher will then calmly but surely place you in the lepers line, where you get to shuffle about uncomfortabely and look like the dumb bastard who couldn’t figure out how to register, or was too lazy to do so.

Having been one of those rejects twice, I’d argue that the members of the line form a kind of silent (and often not so silent) bond. Sure, we don’t know how to navigate one of the most poorly written webapps for selecting and scheduling sessions, but by god, we’ll give it our best shot.

Pitifully, I managed to attend just one session yesterday (not including my own), so there’s not much to report on that front. However, this JavaOne is, perplexingly….vibrant? There’s a certain energy that seems to have been lacking recently. I’ve noticed more than one person comment on the quality of the talks and topics, and how much fewer of them seem to be pointless fluffy Sun penis wagglage marketing poop.

The linux distribution license thing announced yesterday is worthy of note; it’s always thrilling to see another nail hammered into Apache Harmony’s coffin. Why all the members of that project don’t just crawl into Stallman’s beard and die is a mystery as yet unsolved.

It’ll be at least interesting to see how the content evolves, given that some of the editors (well, one of) can barely string together a coherent sentence, and has the mental acumen of a small pebble

While the question about IE 7 being compliant with CSS 3.0 is premature, we are still anxiously waiting to see how IE 7 measures up with CSS 2.1 compliancy.  Ultimately, while I can hope that it will support some of the standards in CSS 3.0, I still shake my head in amazement that it has taken Microsoft this long to become compliant with the current standards. So I am not going to hold my breath, especially since CSS 3.0 has yet to be released.

Hopefully, since IE 7 has been completely rewritten from the ground up, we can only assume at this point that it can only do a better job this time around, and for CSS 3.0 once it has been released.

There are still many reports around the Web about Internet Explorer bugs, and while I wouldn’t expect that they would fix each and every one of them (why not?), it looks like the vast majority of them are going to be corrected.  Included in the list from MSDN were these for which I couldn’t find a description, and haven’t experienced personally: moving viewport scrollbar outside HTML borders, the 1px border style, and losing the ability to highlight text under the top border.

I would like to point out something in particular about the asterisk selector used to give explicit rules to IE.  The root node selector has long been used to create rules that only work in IE, such as with the use of universal selectors, like the asterisk. In IE 7, since many of the rules that didn’t render correctly had to be addressed, these rules are now evident, unlike in previous versions of IE.  The problem is now created for style sheets that utilize the child selectors or the universal selectors that contain these IE-specific rules, because they will have duplicated or merged rules that were never intended to be used this way.  As you can imagine, this will create a genuine disaster for those coders.

Initially, reports were made by Microsoft that child selectors, pseudo-classes and universal selectors were not going to be supported still in IE 7, but those reports are changing.  We still don’t ultimately know what will be in the final version, as it is still in beta testing, but what we can see is that a massive amount of bugs with regard to CSS are going to be fixed.  While this is good news to most, those that have implemented workarounds may not be so thrilled.

Microsoft has also rethought the way IE handles pseudo-classes.  IE uses a very strict interpretation of pseudo elements in the parser, and this would cause certain constructs to be disregarded. Any pseudo-element had to be the very last thing in the selector in versions prior to IE 7.

The CSS2 specification was interpreted by IE in such a way that there can be only one pseudo-element per selector, and it must appear in the last simple-selector within the selector. Because of IE’s strict interpretation, in the event of any non-whitespace character or token after a pseudo-element, it wouldn’t render correctly, if at all, and an error flag would be thrown into the rule. In IE 7, the error flag is more carefully applied, even though multiple pseudo-elements and pseudo elements in simple selectors beginning a complex selector will still fail.  According to Microsoft, this is still the correct interpretation of the standards regarding pseudo-classes.

There are other issues that IE 7 will support, like fixed positioning and child, adjacent, attribute, and first-child selector tags, fixes for any :hover elements, and background-attachment: fixed on all elements, not just body element.

• Peekaboo bug - This bug occurs when a liquid box has a float inside, and content appears alongside that float.  In Internet Explorer, the box with all its content sometimes just disappears, which then reappears upon scrolling or switching windows.
• Guillotine bug – This is a bug that chops off the bottom part of floated elements when certain links are hovered over, or causes content in a floated element to be chopped off at the bottom.
• Duplicate Character bug - This bug involves multiple floated elements; text characters from the last of the floated elements are sometimes duplicated below the last float.
• Border Chaos – This bug draws parts of the surrounding borders all over the place, even eliminating bits here and there when negative margins for consecutive flowed boxes are used.
• No Scroll bug – IE may not force a scrollbar even if the content is long enough to require one, resulting in hidden content.
• 3 Pixel Text Jog – IE applies a 3px space on text next to a floated element, but corrects itself once a floated element is ended.
• Magic Creeping Text bug – This bug is triggered by nesting one block element inside another, and giving the following styles to the outer element.  When triggered, the bug pushes the text in the inner element, but not the element itself, to the left an amount equal to twice the width of the left border.
• Bottom Margin bug on Hover – In IE, if you use a few anchor tags for a menu that have some vertical distance from each other by using the bottom margin, and on hover want them to change background color, the bug removes the margin of the anchor two places behind it.
• IE/Win Line-height bug – Line-height is incorrectly rendered if the line contains a replaced element.
• Double Float Margin Bug - One of the most common complaints CSS developers have with Internet Explorer is the doubling of margins of a floated element.
• Quirky Percentages in IE – IE chooses to calculate the percentage of a child item based on rendered page flow instead of taking the parent attribute and using that to calculate the percentage.  Because it can’t calculate the percent from an unknown, it “guesses.”
• Duplicate indent – The bug causes in-line elements (images, text) adjacent to a floated div to appear to be indented from their expected location.
• Disappearing List-background – This bug is caused by placing a list with a background set within a floated div that has been relatively positioned, causing the background to display incorrectly.
• Fix width:auto – This bug resulted from prior versions of IE’s lack of support for fixed width positioning.

There has been a lot of hype surrounding the release of Internet Explorer 7. Improvements range from better security issues to customization of user features; but the excitement in some web developers has been prompted by the compliancy standards of CSS that IE 7 embraces.I can also say that an equal number are trying not to vomit at the idea of having to go back and seek out every style sheet they wrote that may break in the light of the new compliancy. Thinking about it makes my head hurt a little, and if you’ve ever written sloppy code (which we all have) or had to delicately balance a design with a few non-compliant hacks, I’m sure you’ll be reaching for the Advil, too.

Internet Explorer, while being one of the first browsers to incorporate support for CSS, has been the last to really get on board in regard to compliancy. CSS developers know that of all the browsers that they need to usually come up with workarounds while coding, Internet Explorer is the most buggy, as well as the most frustrating, and needs the most attention when it comes to CSS. And it is because of these bugs that workarounds have been implemented that may now cause these brilliant CSS hackers to cringe with the fixes incorporated in IE 7.

In the latest version of IE, Microsoft has fixed many of the bugs in IE that create problems for CSS. In this article, I want to look at some of the bugs that IE has contained relating to CSS, what they are, and how version 7 addresses these issues. You can only currently download a copy of IE 7 beta for development purposes if you have an MSDN developer license, but (at the time of this writing) supporters indicate that the release of IE 7 to the public may happen as early as by the end of January, 2006. I was able to get my hands on a copy for development purposes, and I have to say that thus far, I am fairly impressed.

I’m a big supporter of CSS compliant code, and luckily, I’ve never relied upon CSS hacks. Perhaps it is because I have a slight bit of OCD (Obsessive Coding Disorder) where I like my code neat and clean, nicely grouped into like sections and commented accordingly, and don’t ever want to have to think about it again once it’s completed, unless I decided I wanted to change a font color or something. I for one am happy that I won’t have to keep checking my designs in multiple browsers, although I know that currently everyone else in the world that uses IE (besides the beta testers, that is) won’t have a copy of IE 7 just yet.

The following list regarding the bug fixes where CSS is concerned you may have already seen once or twice, but I’ve taken the time to research them a bit and explain to you what they are and what they do to your once happy code. Therefore, my list will be quite different from those you’ve seen, and I’ve compiled the descriptions all into one place for your convenience. The sheer reason for this is that once you read the descriptions, you remember that particular problem, whereas with the sometimes cute or ominous nicknames these bugs have been given, you may not have a clue what Microsoft may have been referring to.

It is harmful to use “* html” because you don’t know whether the issues - real bugs or simple differences in behavior - you are working around will be removed when “* html” goes away. If you DO know this for the particular issue you’re working around, then it is not harmful. If you do NOT know this, then you should use a versioning-capable system like conditional comments, and be prepared that you will have to update your workarounds when the issues are fixed.

That seems entirely sensible. I do think the original posting is highly unclear in this regard. And I do think the vast majority of sites using the * html hack, for instance, know why they are doing so.

I think the point is many web developers posting to this blog expressing confusion at this article, are actually expressing *trust* that the other bugs you’ve fixed, have indeed been fixed. If, as per your excellent previous postings, this there should be no need for sane web developers to start moving to conditional comments, as you yourself note.
I definitely like a previous posters idea of open sourcing ie. perhaps they could run dual versions. standardIE and openIE, a community run project. similar to the regular SUSE versus openSUSE. i think this would make ie a lot better. and it wouldnt take 4 years to come out with a new version. (it was only 1 year between firefox releases)

I also like mozilla’s nightly builds, a new testing build every day. many previous posts on this blog talk about bug fixes, but since there’s no build for us to test, theres only the very limited ie dev staff to test it. i enjoy using the firefox auto-update to download a small 500k update everyday that includes bug fixes and new features. it allows for quicker bug filing and fixing. (most major firefox bugs get fixed in a few hours/minutes).

I doubt Opera, Netscape and Mozilla etc, would all agree to make a change just to support microsoft’s whacky ideas.

IE is also in new development stages, so Microsoft might as well change the ‘legend’ tag’s behaviour while they’re at it - As well as everything else.

I say release a version of IE that addresses the CSS hacks of today, and let the currently hacked implementations break. Sure, there will be a small hiccup while thousands of jobs are created to fix web sites, but the end game sounds sweeter and worth the troubles.

I see a couple of issues in this request of MS that require further study:

How many sites will break if the comments are not used? My guess is the sites affected is a minority. It might be the loudest group, but a minority still.

I see this all the time with software companies, not wanting to break a few eggs.Sure, some people will get upset if you release a version of the software that disrupts the current process, but we’re moving to where the grass is greener. This sounds like an education issue - not an implementation issue.

And finally, shouldn’t the new IE ignore the IE 6 hacks anyways? Isn’t that why they’re called IE 6 hacks?

More important than the empty legend tag thing for me (and I agree with the others, here… displaying an empty tag makes no sense), I hope IE7’s fieldsets display correctly when a background color is present. If that’s intentional behavior, that also doesn’t make sense.

Lots of effort to conform pages to buggy w3c standards.

“Gil”, Microsoft doesn’t own the blog software, it’s community server by Telligent.

YWDRYP: Why don’t all the other browsers change to be like IE? After all, w.r.t. the legend tag, IE is just as compliant as the others are (since the spec doesn’t say what to do with an empty legend tag). And IE has more than 90% of the market share, so clearly the other browsers should be following IE’s lead here.

Since this isn’t a spec compliance issue (the spec is silent in this matter), they should follow the behavior of the dominant browser, and not be different for the sake of being different.

Microsoft should follow examples by other browser makers because they’re already more developed in standards than IE. It would also be easier for IE to change then for all the other browsers makers to make that one change.

Concerning css-hacks for IE6 and IE5, IE7 should behave exactly like other browsers do.
This can’t be such a big problem.

You can’t ask us to change our sites, just because your new browser behaves in a strange way. You/Microsoft will get real hate, if you don’t make IE7 a „real“ browser.

You shouldn’t insist in going your own way by doing things different.
Do things right.

Why do you hide the form at the end of the page?
That’s annoying …

Let’s all petition the leaders of our countries to declare war on their allies. I mean, if we can’t have total world peace, what’s the point of doing it “half way”?

Come on. Lets get serious. If you went to the doctor with 2 broken legs and he told you he could only fix the right one, would you say “if you’re only going to do a half job, don’t bother”? Just because you choose to be stubborn doesn’t make Microsoft’s effort any less important.