IEBlog

How hard would it have been to summarize on the blog?

The following are outlined as known partial/none implementations, but are planned (*cough* roadmapped) for IE8 Final.

CSS Selectors:

:active

:focus

:hover

font-weight:

word-spacing:

ruby-[align|position|overhang]:

content:

counter-increment:

counter-reset:

quotes:

empty-cells:

bottom:

display:

left:

right:

top:

z-index:

(printing)

orphans:

page-break-after:

page-break-before:

page-break-inside:

widows:

cursor:

That's it folks!

So if you see it in the list, cross your fingers that it gets fixed by RTM time, if it isn't in the list, be sure to enter a bug (or ask someone who has access to enter it), and prey that it gets the attention it deserves.

PS This kind of roadmap thing, would have been great to get say... 6-9 months ago... sorta like other browsers inform their developers.

While I appreciate the feedback, it is a pity that there will not be more items that were not implemented in beta that will make it to final.

Is there a time-frame for when the rest of the "no" items will turn to "yes"?

Can you clarify what part of CSS 2.1 will not be fully implemented in IE8 final?

No offense but the language in your post is quite awful. It's the kind of language one would use for some sort of customer notice, not for a blog entry to (supposedly) peer developers and project managers. Perhaps a little less "you, the developer community" and a little more substance like the first comment provided would be a good start.

ooh, this is a handy resource.

@Rag: Our goal is to be CSS 2.1 Complete by final release, so ideally all features in the CSS 2.1 specification will be implemented at that point.

So, you guys are not in the race for ACID3 ? Opera is claiming 100/100 , WebKit is at 98/100. How is IE doing ?

And what about the CSS3 opacity property?

I don't see the point in Acid3, it just came out and theres barely anything that uses the features it tests.

CSS2 on the other hand, was long, long overdue. I'd rather have complete, bug/glitch/quirk free CSS2.1 support then half-assed CSS3 support only thrown in to punch the numbers on a test.

By the way, something I've been meaning to ask. Does IE8 still use Trident as its base, or did you guys made a new engine?

@Arieta,

Attitude like this is the reason why CSS2.1 support is long long overdue.

Acid3 tests some of the abilities what are very useful when developing contemporary web apps. It is not about CSS3 only.

Btw, how do you know that css3 support in opera or webkit is half-assed?

I don't find that "CSS Compatibility and Internet Explorer" article really helpful. Knowing that option "x" is supported or not is nice, but the main problem I see with IE8 is the differences it shows in rendering compared to IE7 and FF2/3. Among other things there are differences with margins (IE8 seems to add linebreak-like margins to several elements) and with the way floating inline list elements are handled. What looks exactly the same in IE7 and FF (and thus seems to be "right") is suddenly different in IE8. Unfortunately, telling if this is a bug or the way that MS developers interpreted the spec is impossible. So, I would rather prefer to see an article that describes the differences in handling of already supported elements over the proposed support of new elements.

Still no nth-child support.  No rgba() either, so I'm assuming opacity is still out as well.  That's too bad, since those are two of the nice ones.

Guess after all the good news we were up for a reality check.

The bottom line is: even in its final release version that is only due in late 2008, IE8 will support NONE of the CSS3 features people truly care about.

Compared to what the competition is accomplishing with their vastly inferior resources, that is a real shame.

@Arieta,

I agree with most of what you said, I'd prefer full CSS 2.1 compliance to passing the Acid3 test any day. But one thing I am interested in that is required to pass the Acid3 test is the "text-shadow" property. Acid3 may be the impetus for the Gecko developers to FINALLY implement it (hey, it's only been nine years...), and a similar implementation from the IE developers would pretty quickly give us support across all of the major browsers at the rate we're going.

I'd also like to see XHTML support in IE8, as IE is the only major browser left without any support, but I've all but given up on that.

Opacity and rgba() is missing.

crop() doesn't work.

nth-child would be useful.

...and don't forget DOM2 is not just the core. DOM2 Events are most important.

Other than that it looks pretty good - welcome to 2005! :D

@Doug Stamper and @Harel Williams

"Our goal is to deliver complete, full CSS 2.1 support in the final IE8 product."

Dean Hachamovitch, General Manager Internet Explorer, March 5th 2008

Complete, full CSS 2.1 support must mean and must imply correct implementation, no CSS 1/CSS 2.1 bugs (spec. violations). That's an importantissimo issue we all should be notified of, informed about.

There are now and still *many* CSS bugs (documented, testcase-ed, reproducible, clearly explained, etc) with IE 8 beta 1. IE 8 beta 1 still fails many tests coming from Ian "Hixie" Hickson evil testsuite.

The MSDN2 "CSS Compatibility and Internet Explorer" webpage claims that letter-spacing CSS 2.1 property, :first-letter, :first-line CSS 2.1 pseudo-elements are supported in IE 8 beta 1. Several people (including myself) are saying that these are *not* supported at all or that they do *not* work at all in IE 8 beta 1. Could you clarify this info and also confirm that these CSS 2.x properties and pseudo-elements will work as they should in IE 8 final?

Also, it's obvious and unanimously confirmed that IE 8 beta 1 has problems with rendering of list-style-image, vertical-align and rgb().

Again, full and complete CSS 2.1 support must mean and must imply correct implementations and very few (close to none) bugs.

Note that some tests are possibly parsed and rendered correctly but then IE 8 beta 1 has painting, redraw or reflow bugs (and one can notice those when reloading, resizing viewport, highlighting/selecting with mouse).

Best regards,

Gérard Talbot

Opera Passes the Acid3 Test!

http://my.opera.com/desktopteam/blog/2008/03/26/opera-and-the-acid3-test

I want IE8 to pass the test, too!!!

Opera doesn't exactly pass the test yet, read the description text on the Acid 3 test page.

The MSDN2 "CSS Compatibility and Internet Explorer" webpage gives a "yes" to visibility but collapse value is not supported at all.

Also, that document gives box-sizing "yes" but the property is ms-box-sizing rather. Question is if CSS 3 box-sizing and not just ms-box-sizing will be supported in IE 8 final.

Other questions.

1- What are Microsoft's plans regarding full and complete support for HTML 4.01? There are still a few attributes and elements unsupported and there are several bugs still unfixed. HTML 4 is a web standard and has been around for longer time than CSS 2.x.

2- Will there be an IE 8 beta 2 release?

3- Will there be an IE 8 beta 3 release before final release of IE 8?

Regards,

Gérard Talbot

@KS

"IE8 is the differences it shows in rendering compared to IE7 and FF2/3. Among other things there are differences with margins (IE8 seems to add linebreak-like margins to several elements)"

IE 7 had quite buggy support for adjoining margin collapsing and for floated elements. In IE 8 beta 1, all of the tests regarding margin collapsing show a correct implementation in IE 8 beta 1. Regarding floats, as far as I know, only 1 or 2 issues still need to be addressed. Margin collapsing and float were in everyone's list of IE 6+ bugs-that-must-be-fixed 2 years ago.

Visit my webpage, in particular bugs #34, #35, #36, #37, #84, #85 for margins.

CSS 2.1 appendix D suggests margin: 1.12em 0 for <p> which is what IE 8 b1 does. HTML tab and Layout tab in Developer Tools will show the margin values and will confirm these values.

Regards, Gérard

CSS rect() shape requires commas as values separators, but IE accept only spaces.

"I don't see the point in Acid3, it just came out and theres barely anything that uses the features it tests."

There is barely anything that uses it because no browser supported it yet, now they do. Problem is: most designers still can't use these useful features because the browser with the biggest marketshare doesn't support them.

Microsoft: please GIVE UP on Trident, you guys have fallen too far behind the rest, you're holding back the web. Why not use WebKit for IE8 ? Or are you just having a bad case of not-invented-here syndrome ?

In the document you provided you have said that IE8 Beta1 supports "direction" and this is so WRONG. IE8 Beta1 isn't supporting direction and i've test it with CSS based Arabic site (direction: rtl;) and the result was a mess. please correct the mistake.

thanks

Thanks for the information.

How about providing a similar page for JavaScript/DOM support IE 8?

Please add support for the following (W3C Recommendation since 13 November, 2000):

http://www.w3.org/TR/DOM-Level-2-Events/

Please add the complete values for the content-property. We need content:none; and content:normal; !

Yours sincerelly

Ich

I know some won't like it but having css 3 column support would be a god send for me, I'm always having to apply some hack either javascript or server side implement columns for dynamic content and it's been something I've been banging on about having in forums even before it made it into the css3 spec :-D

I'm testing IE8 Beta (8.0.6001.17184) and the big problem in their software is speed.

IE8 is very slow (on slow machines?), two or three pages open and the computer is unusable.

Some bugs of IE7 continues, Texts over images on some pages, and slow loadings.

I think the microsoft puts powerful workstations (Two Xeons, 16gb ram...) available to programmers, who forget that the rest of the world uses crap hardware.

Claiming that IE7 had "partial" support for white-space is a bit misleading.

The only "desired" white-space option developers are looking for, is a "pre" option, for tags that aren't pre tags.

considering this didn't work at all in IE6, and IE7, I hardly consider this to be a "partial" implementation.

I have yet to test it in IE8, which claims 100% fixed... but I'll keep my glass half full while I think about it.

Please, please, use regular gecko interpretation. Safari does, Firefox does, compatibility fixes would be gone forever. Go to W3C, apologize and make a good browser. Devs now have to go through the pain of making everything IE6, 7 and 8 compatible and they don't event react like each other. I've seen IE8 ignore <center> elements. Wow.

Microsoft,

Please rethink your priorities on the release release of Internet Explorer and support more standards. (XHTML 1.1, DOM Level 2, DOM Level 3

various XML standards, SVG, JScript 1.8, CSS3, APNG). You are again falling behind.

Acid3 is your and our web "experience index".

Compared to the surprise MS gave when they announced IE8 passes Acid2, IE8 now again feels boring since the only improvement IE really had made is wrt CSS2 and bugs. I know that the Acid tests are not everything (you will surely publish an article soon why Acid3 isn't everything), but you are still not supporting standards that were ratified years ago. Not one bit of support for XHTML, XForms, SVG, DOM3).

I can't wait for beta 2. I'm expecting improved standards support and fixes.

Not sure if this is correct place but it is CSS related. In all IE version so far page 'backgrounds', which just so happens to be all images generated by CSS, have been set NOT TO PRINT as default.

You know the one I mean, in Tools > Options > Advanced > Printing > Print Background Color & Images (Default set to no)

Please could this be set to print backgrounds & colors as the default in IE8, provide an easy way to disable it if you are concerned about users ink costs etc, but please turn it on as default for the simple reason that more images are becoming CSS based and don't show on prints of web pages.

I've read the list of implemented stuff. I'd like to add some personal informations.

IE8b1 support for :before and :after is partial, as you can't specify a background image nor can you use an image as material for the 'content' attribute. I guess this comes from the build having lousy image handling, (slowdowns on alpha-enabled PNG display) - incidental, but still wrong: as long as IE8 Final does correct the matter, it's no big deal (compared with all the stuff already said).

For Acid3, IE would need:

- XML 1.0 compliance (msxml3 isn't XML compliant)

- actually support MIME types in HTTP content negotiation properly (application/xhtml+xml shouldn't trigger a download dialogue, it should return a failure to negotiate content to the server)

- SVG 1.2 Full support (but we know how much MS likes SVG)

- CSS 3 support (enough said)

- proper W3C DOM 2 compliance (W3C event model, where you can do node-level event capturing and bubbling)

- proper ECMAscript support (with a garbage collector that actually works).

It would be nice if code samples provided by MS could be correct ECMAscript too, as I've renounced using them due to incorrectness or dangerous shortcuts used: '==' doesn't work as well as '===' to compare exact values, short conditional value (condition?value1:value2) forms shouldn't be used all over to replace IFs, not to say anything about proprietary properties used all over the place (cssText used every time the badly supported setAttribute('style','settings') could be used), and all...

I wonder, BTW, will setAttbitute('style','settings') be correctly supported in the future?

As an aside, all current browsers apart from IE use CSS box model as native, with a compatibility mode; under IE8, native mode is (still) Quirks mode with 'compatibility' mode started when a trigger activates it.

In short, to pass Acid3, IE would need to be rewritten, from the ground up, without reusing any of the Trident code.

...

Keep dreaming, as IE 8 will barely pass Acid2 (yes, I consider that not triggering OBJECT fallback from an ActiveX element that fails to load is a design failure, thus Acid2 doesn't succeed when the test is passed on an URL other than the one hard set in the code).

Mitch 74

@Mitch:

<<it should return a failure to negotiate content to the server)>>

HTTP offers no such concept.  

Beyond just that limitation, Content-Negotiation has never really worked in practice.

ACID3 has nothing to do with garbage collection.

<<In short, to pass Acid3, IE would need to be rewritten, from the ground up, without reusing any of the Trident code.>>

Oops... now everyone knows you're clueless.

Obviously the priority is to get CSS 2.1 right, but it is dissapointing that more effort isn't being put into CSS 3 features, and various other standards.  It seems that Internet Explorer is not making any progress in catching up with the other browsers on standards support.  

If Microsoft had wanted to, Im sure they could have given the IE Team enough resources to make IE8 standards supportcome close to Firefox, Safari etc, but they don't seem to think it's worth it.

First off, thanks for posting this preliminary doc.

NO CSS 3 psuedo-classes?  No CSS 3 psuedo-elements? CSS 3 borders and layout? border-radius?

Please, set your sights higher. Do what it takes.

Delay IE8.  Please postpone the release of IE8 to implement CSS 3.  

Help set the bar.  That's all I ask.

CSS 3.... please?

Do what it takes.  Postpone the release of IE8.  Help set the bar.

border-radius -- save us the extra ridiculous markup/[script]/[images] for rounded-corners!

It's quite amusing that the biggest software company in the world is so far behind in such a essential and standard piece of technology.

Forget CSS3, it looks like half of CSS 2.1 will still be missing when this thing gets out the door. I had a terrible sinking feeling when I read this list, I'm kind of disappointed with what we'll eventually get. Thankfully FF3 will be out in June so I can stick with that.

I would like to retract my previous comment....it seems the only issue here is actually my inability to read!!!

today i find some time to install the ie8 ,but after i open some google application,the cpu usage get high;so i use the process explorer kill the application,but the parent process restart 4 new process(maybe the page count),i kill them one by one but the parent process can't be killed,so i logout but after login i find the process is still there ,i found there is a thread named  vmnetsrv.sys can't be unload, you can check the page here:

http://sdhjl2000.googlepages.com/01.JPG

http://sdhjl2000.googlepages.com/02.jpg

Yeah, go ahead and stick with your FF3 resource hog :>

http://www.firefoxmyths.com

Whatever pleases you :>

@Jote:

Please inform yourself before posting incorrect things:

* http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/

* http://ajaxian.com/archives/firefox-3-memory-usage

I can't wait for beta 2. I'm expecting improved standards support and fixes.

I would like to retract my previous comment....it seems the only issue here is actually my inability to read

Are there plans to allow IE8 users to resize text that is defined in px?

something is messed up with posting...

if you post a large comment, the system redirects you to the main page and ignores your comment.

small comments are ok.

(sorry if this becomes a repost, but I didn't see it added as a comment)

Bugs I've noticed in IE8 Beta One so far:

-----------------------------------------

1.) Still can't set .innerHTML of a select element.

2.) Trying to set an event like: myElem.setAttribute( 'onclick', 'alert(this.nodeName);'); doesn't work.  It does set the value of the attribute but it won't register the event handler.  (This applies to any event, keyboard, mouse or load triggered)

(posts over 512 characters are not being accepted)

4.) Getting the 'style' attribute on a select element doesn't work.  It returns an Object, not a String.

5.) Setting 'defaultchecked' attribute fails on a checkbox element.

6.) Setting 'defaultchecked' attribute fails on a radio element.

Please consider delaying IE8 until significant standards progress is made.  Try downloading the latest webkit nightly and Firefox 3b4 and compare them to IE8 b1.  IE 8 doesn't make significant standards progress and is filled with bugs (Rendering just falls apart on experts-exchange.com for example).

Also, please make IE6 available as a stand-alone browser.  EVERY GOVERNMENT AGENCY I KNOW IS REFUSING IE7 INDEFINATELY!  Throw them (and those of us who have to deal with it) a bone.

7.) Trying to set the .innerHTML of a table element throws an "Unknown runtime error", then fails to render the remainder of the page.  (if you want to not accept certain HTML markup, that's fine, but it should just skip that content, indicate the error, and CONTINUE loading the page)

8.) trying to set the 'cellpadding' attribute on a table fails.

9.) trying to set the 'cellspacing' attribute on a table fails.

Please please support multipart/x-mixed-replace it will make dynamic web apps much easier and less resource intensive.  It was originally invented > 10 years ago so its not exactly an new and untested technology.

Thank you (although I doubt we will see it soon)

10.) setting the .innerHTML of a fieldset, to include a legend element does not place the legend label inside the borderline of the fieldset, but rather displays it as a nested block element within the fieldset.

11.) Doh! (#10 above) has nothing to do with DOM operations, the actual rendering of the HTTPResponse HTML content fails!

12.) The default border radius rounding (3px in IE6), (5px in IE7) now is (ZEROpx in IE8) - please fix this directly or support CSS3 border-radius property properly.

13.) Setting the 'style' of a select element (via object.style.cssText = ...) (due to bug #4 above) causes the drop arrow of the select element to render as a Windows 2000 "gray" square non-rounded arrow button.

Whew! thats a lot for now.  When I start testing my applications I'm sure I will find more bugs.

BTW is there an ETA on Beta 2? and does any developer at MSFT know if any of the bugs outlined above are fixed in the next Beta?

thanks, jason W

Are there plans to support styling of input elements with the type="file" attribute in IE8?

14.) Attempting to select text content inside a textarea element is completely messed up if it was populated with textareaObj.innerHTML = 'plain string of text content';  With an ***insane*** ammount of luck, you might actually be able to select the text you intend to select.

This worked perfectly fine in IE6, and IE7.

@Mark: considering IE8b1 in Edge Super Uber Standards Mode exhibits layout bugs and box placement bugs that I could confirm present in IE 5.01 (the Win2k edition, still supported, current basis for Quirks mode), I think it's a pretty big clue that IE8 is, STILL, using the Trident code base for its layout engine. Strike one.

Considering it STILL can't negotiate content correctly (it accepts '*/*', but can't parse application/xhtml+xml, or incorrectly parses 'text/plain' as 'text/html'), it STILL can't read application/javascript or application/ECMAscript sourced files, I'd say its support for HTTP 1.1 is still as low as before. Strike 2.

forcing the loading of an XHTML 1.1 document with application/xml MIMEtype makes IE use its existing XML parser (yes, it does have one - it only displays the XML document tree, but it works), which; like under IE 5,6 and 7, fails to parse the XHTML 1.1 DTD. Strike 3.

What happens when you negotiate a connection? The browser requests a resource, saying what it accepts; IE accepts '*/*', wich is equivalent to '*/*',q=1 (everything, fully) - but supports (at best) 'text/html',q=0.9 and 'application/xml',q=0.7. So, the server thinks IE will support application/xhtml+xml, which IE fails to parse - you get a download prompt, like with IE 5, 6 and 7. Strike 4.

Oh, and still no XHTML support. Strike 5.

I don't have any script code handy to try to modify the DOM of a document before the DOM is done loading (this triggered a complete Trident failure in previous versions), but I bet you it's still unsupported.

So, I feel pretty justified in saying that IE 8 still uses Trident as a rendering engine, and that said engine still uses the MS box model to compute object dimensions and positions before applying shims to (try to) respect the CSS box model, and that it retains enough failings and quirks common with previous versions of IE to hint at IE 8 not being a 'complete rewrite'.

I formulated the sentence really badly: what I wrote is wrong, as HTTP being a on/off protocol, once the server has sent the resource it forgets about the transaction, so there is, you are right thanks for pointing it out, no error reporting to the server, and it isn't part of the HTTP protocol - it is not necessary with UAs that faithfully report what they can support, as actual transmission is handled by TCP/IP.

I actually meant to say that, and this is the way the IE devs justify themselves:

Accessing an external document is done by loading another instance of Trident as an ActiveX control, the external document uses a different base address than the main document, so an error is triggered and the resource isn't loaded, but Trident as a control stays running - preventing object fallback.

With a matching URL, the control loads, tries to get the resource, fails, and closes, triggering object fallback in the main document.

Long story short: if an ActiveX control could report to the browser it failed to do what it was set to do, the browser could decide to close it; it doesn't. So, IE fails to load a resource, but doesn't know it, so it doesn't trigger object fallback, so it doesn't pass the test.

As far as I know, other browsers also prevent cross-domain scripting exploits, but don't fail the test here; so yes, I consider that Acid2 fails under IE 8.

The following bug(s) are on XP (might be on Vista or 2K3 also)

15.) when you click on an input type="button", the button appears depressed until the mouse leaves the button footprint. (regression from IE6/7 behavior (button pops up after click))

(uggh! that "undeclared" post size limit is REALLY anoying!)

16.) when you click on a _button_ element, type="button", the button appears depressed until the mouse moves 1px in any direction. (regression from IE6/7 behavior (button pops up after click))

17.) Internet Explorer 8 still doesn't handle (render) GIF89a encoded images (with a color depth of 32 bits) - shows a broken image placeholder only.

Dear Microsoft,

CSS 2.1 also requests, that only files labeled with the text/css media type are allowed to be parsed. Are you aware of this? Does it count to your roadmap of CSS 2.1?

Can you clarify what part of CSS 2.1 will not be fully implemented in IE8 final?

Although it has nothing to do with this post, I believe JasonW is referring to a GIF89a animation consisting of a series of images, each with its own Local Color Table and (most likely) zero delay between the display of each image. The images can overlap and use transparent pixels to preserve colors from previous frames, or the images can be small and just line up adjacent to each other. Both are mentioned in the Graphics Interchange Format article on Wikipedia. IE (even IE6) already supports both formats, so I don't know what he's referring to that doesn't work. Note that for lossless encoding of true-color images, there are more efficient options like PNG (also supported by IE) and JPEG2000 (not supported, but should be).

@Jote

As Jeria pointed out, you're misinformed. Firefox myths is not only outdated but also full of lies.

Also, see:

http://www.firefoxfables.com/

http://cybernetnews.com/2008/03/26/cybernotes-browser-performance-comparisons/

Wow shocked to see that Opera have already got a public build that passes Acid 3 100/100. Although I am glad that we are now getting info about IE8, I think this news highlights how far IE is behind the other browsers. All the back patting for the IE8 passing Acid 2 now looks a bit premature, a lot to catch up! But I would happy if IE8 had SVG and proper event handling.

@Mike: Don't jump the gun.

Acid2 and Acid 3 have a totally different focus. IE8 does the CSS parts of Acid3 pretty well, but horribly lacks the Scripting parts. Even if IE8's focus were only CSS, that's really great.

Acid3 sucks. It should NOT BE the GOAL to pass Acid 3.

@Mike Brown, Re: Jason W., "17.) Internet Explorer 8 still doesn't handle (render) GIF89a encoded images (with a color depth of 32 bits) - shows a broken image placeholder only."

Only IE can't render the valid GIF file (#3) on this page.

http://members.home.nl/bilbo23/balloons.html

Firefox loads it fine.

Safari loads it fine.

Opera loads it fine.

IE chokes on it.

@Gerald - OK, I see now. That page of GIFs has nothing to do with 32-bit color in the sense of exceeding the 8-bit limits on color components (R,G,B intensities) or color table size (max 256 colors per frame), so calling it a "32-bit" GIF confused me. The GIF that fails in IE uses a Global Color Table containing 4 "8-bit" colors, each color described as a trio of 8-bit RGB intensities, with the 4 * 8 meaning "32 bits", I guess.

The reason it fails is because the GIF has bad data in it. It says (in bytes 9-12) that the image is supposed to be rendered in a 1x1 pixel area, but it later describes frames that are 127x137. The spec does not say what a decoder should do in the event of such an error. IMHO it's reasonable to refuse to render it. The decoders you tested are apparently more forgiving and just ignore the global size.

I figured this out by looking at the GIF in a hex editor, and reading parts of the GIF89a spec & a site that describes the Netscape extension for animation. When I fixed the bad bytes (the 9th byte should be 7F and the 11th should be 89), the GIF rendered fine in IE.

Microsoft guys -

*WHEN* are we gonna get a bug-tracking database again? I just don't understand why, why, why Microsoft doesn't realize that those of us who really want to help (and *not* spout anti-M$ FUD - we really, truly, want to help) need a bug-tracking database so that we can contribute bug reports.

It's ridiculous that this blog is the only place to report bugs in your product. WE WANT TO HELP - give us a tool to HELP YOU - FOR FREE!

Anyway, here's a bug report:

****** BEGIN BUG REPORT *****

One of the DOM connectivity improvements in IE8 was that the 'navigator.onLine' property was supposed to show 'true' or 'false', not just based on whether the user selected 'Work Offline' or not, but based on whether the network was active or not, as detailed towards the bottom of this page:

http://msdn2.microsoft.com/en-us/library/cc304129(VS.85).aspx

However, when I test that property, it shows 'true' even though I've taken my network connection offline by disabling the network adaptor via the Control Panel (note that I have *not* selected Work Offline in the browser - I just went and disabled the connection). The expected behavior would be for this property to toggle back and forth between 'true' and 'false' based on the state of the network.

****** END BUG REPORT ******

Anyway, please help yourselves by helping us help you. We really do want to help.

Cheers,

- Bill

Microsoft guys -

One last note, here's my environment:

Windows XP SP2 - IE version 8.0.6001.17184

Cheers,

- Bill

@ajo

Acid 3 sucks.

Wow with an argument like that, why would any browser vendor want to implement it!

My point is the fact that opera already has a build that scores 100/100 shows how far IE8 is behind.

Personally my own interest is that IE8 should support SVG. The applications I am writing depend on vector graphics. It is possible to use VML, but at this stage why should I should I be using this for one browser only. All the rest have support SVG to some degree, is so much to expect IE8 to include it. I have invested a great deal of time learning html, javascript etc and do not want to have learn flash, silverlight or proprietary plugin based languages.

Please confirm yes or no. Is SVG support included!

Microsoft guys -

Ok, so now I see the note in the online / offline detection feature that says that the dynamic updating of that property and the online/offline events will only work on Vista... sigh...

Let me be the first, but not the last (I can assure you) to formally request that the work be done to make this work for XP as well...

Cheers,

- Bill

i have a problem with Scissors screen caputre of Windows Vista  and IE 8.

i tested IE 8 in 2 PC and have this problem

Hi,

I'm testing IE8 for a couple of weeks now and the only annoying bug is related to the fieldsets. Not only the legend is inside the borderline but it seems that fieldsets inside an embedded frame don't recognize the frame borders. I get some pages with enormous width. Furthermore some option widgets are not rendered when the iframe is changed from display:'none' to display: 'block' by javascript. When I click on the position where the widget should be it becomes visible.

I don't care about test suites as I try to build web pages using only features supported by the majority of the browsers. It's most important that these basic features are rendered identically or at least very similar by all browsers. This was not the case with IE7 but has improved for IE8. For sure it would be nice if IE8 would support some of the more advanced features as IE8 is the limiting step at the moment. But I hope that there will more in the final version. :-)

@William Edney:

I've reported this bug in the IE Feedback Site.

You can track it with this URL (#336135).

https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=336135

Unfortunately, membership to enter bugs is limited to a small set of developer/testers (this still needs to be fixed)

I didn't read your "Vista-only" comment until after submitting the Issue Ticket. :-(

That said, I totally agree that it shouldn't depend on the OS at all.

Considering most users are avoiding Vista like the plague, XP support is very important.

Unfortunately the link you gave is behind a login screen...

Looks like they do not want anyone to see just how many of these new features do not behave as documented.

i have a problem with Scissors screen caputre of Windows Vista in IE 8 BETA .

When I try to capture a screen from IE 8, all slow slows

i tested IE 8 in 2 PC and have this problem

@billybob: Re: "link you gave is behind a login screen"

Hmmm, appears you are right... that is unfortunate because this is info that almost every developer should have access to.

Having access would allow everyone to see that issues like changing the type attribute of a form element has been officially squashed.

e.g. HTMLInputElement.setAttribute('type','hidden');

Will fail in IE8, even though they fixed the .setAttribute('att','value'); (for the most part in IE8 standards mode)

:-(

Oh well, all we can hope is that they open this resource to everyone.

IE8 doesn't provide us with any form of transparency. I hoped this was a slip up and you do write in your white paper that you will consider adding a few CSS3.0 features if there is a large demand for it.

So naturally I figured you would add the opacity property (or at least reintroduce the filters), since this is one of the most requested features on the beta feedback site. However I can see you closed this issue, and are not planning to add this until a future version. I simply couldn't believe my eyes when I saw that. Not only are you breaking the web, but you make it impossible for us to fix it again by removing key functionality from the browser. We cannot wait for IE9 with this! (opacity is also an integral part of your own stuff like maps.live.com, Outlook Webaccess, ASP.NET Webparts, SharePoint etc. etc.)

I can confirm that :first-line and :first-letter are completely broken in ie8 beta1 (a regression wrt ie7), as mentioned by Gérard.

Test case:

==

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>

<title>Test first-line / first-letter</title>

<style type="text/css">

#id1:first-letter { font-style:italic; }

#id2:first-line { font-style:italic }

#id3:first-letter{ font-style:italic; }

#id4:first-line{ font-style:italic }

#id5:first-letter, element { font-style:italic; }

#id6:first-line, element { font-style:italic }

#id7:first-letter , element { font-style:italic; }

#id8:first-line , element { font-style:italic }

</style>

</head>

<body>

<p id="id1">Paragraph 1 should have a italic initial P.</p>

<p id="id2">Paragraph 2 first line (only) should be italic<br />para contd.</p>

<p id="id3">Paragraph 3 should have a italic initial P.</p>

<p id="id4">Paragraph 4 first line (only) should be italic<br />para contd.</p>

<p id="id5">Paragraph 5 should have a italic initial P.</p>

<p id="id6">Paragraph 6 first line (only) should be italic<br />para contd.</p>

<p id="id7">Paragraph 7 should have a italic initial P.</p>

<p id="id8">Paragraph 8 first line (only) should be italic<br />para contd.</p>

</body>

</html>

==

Note: the exact distribution of whitespace is critical in the css fragment for this to be a thorough test (retesting the ie6 failures on css syntax no-whitespace-in-selector error cases).

Best,

Cecil Ward.

@Morten re:opacity

I think because IE has a hack to use the filter() "property" in CSS, they have shelved plans to use opacity properly.

I get the hunch that they don't want to support opacity properly because if they do, sites that code it correctly for IE8 and all other browsers will fail in IE6 and IE7 (which are still MSFT's main focus)

If I had the choice, the 2 CSS features I would want added to IE8 would be:

opacity

border-radius

These 2 properties alone would make coding for IE8 tolerable. Until then, IE always gets served up a "not-so-sexy" version of a page, while everyone else enjoys smooth curves, and layered opacities.

@Jason W.

For your bug #1: I logged a ticket here.

https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=336252

@Jason W

Bug #2 was previously filed here:

https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=332237

@Jason W.

Bug #4 is tracked here:

https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=336253

@Jason W.

I copied your report for bug #7 and filed it in connect.  You can view it here:

https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=336254

@Jason W.

Bugs 8 and 9 are traceable here:

https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=336256

(I combined them since they were very similar)

@Jason W. / @Guki

Bugs #10, #11, #12 (fieldsets) can now be tracked here:

https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=336258

This is definitely a regression in IE8, as they rendered fine in previous versions.

i have a problem with Scissors screen caputre of Windows Vista in IE 8 BETA .

i have a problem with Scissors screen caputre of Windows Vista in IE 8 BETA .

it would be great if IE 8(also IE 7) to export favorites in unicode format. Currectly it exportes in ANSI format, which corrupts the characters in different languages(e.g. when both traditional and simplified Chinese character found in the favorites' name).

Also when it imports the bookmark file that generated by Firefox, it stops and says "Error converting bookmarks" when it hits Chinese characters in it. It is nice to fix it too.

Please Microsoft.

Don't rush IE8 out before you realy realy meet the standards.

When IE7 was released most web-developers thought that the pain of debuging pages in 2 different "standards" was over but instead we got 3 "standards" to debug!

(And since you have to run IE6 on anoter/virtual machine when you've installed IE7 this problem is even worse!)

Adding IE8 to that list would realy be a pain in the ass, especialy since it takes forever to push a product like this to the masses.

The browser usage according to W3Schools for february 2008 is 27% for IE7 and 30% for IE6.

If IE8 would be delivered in the same rate we would have to create websites for 4 different "standards" right up to the next century. Unless IE8 follows the real standard ofcourse :)

So please, make IE8 work orderly once and for all so the masses finaly get a browser that follows the real standard.

Tool bar, menu bar, address bar, icons bars,  why cant they be movable and customizable?  I don't understand why Microsoft keeps on ignoring this critical flaw.  All these bars must be customizable and movable like they were in IE 6, 5 , 4 and 3.  There so many complaints about this yet Microsoft has not addressed this. To me it's like Microsoft is this little kid with his fingers in his ears, shaking his head from side to side crying, "I can't hear you, I can't hear you." Come on Microsoft get off your tookus and address this, PLEASE!!!!    

Great resource thanks - I'm not overly concerned about css3 support, I'm more concerned about why my styles are falling over and what subset of css is supported in the browsers I have to support. Frankly that normally consists of IE versions and everything else. Plus with non-IE browsers there is an assumption that the user is sufficiently savvy to be able to pull down a more recent version if required to address an issue. Due to IE being the default browser on most users' PCs it is the browser of choice by the ingenuous and installing a more recent version is often not an easy option. Windows Update goes some way to addressing this but I'm still seeing IE4 useragent strings showing up in the logs.

@Howard re: Opacity

You are wrong. Not even the filter attribute that we have in previous versions all the way back to IE5.5 is supported in IE8, so there is absolutely no way to apply opacity to an element in IE8, and judging from the connect site, there won't be (Microsoft closed the issue stating that they would consider it for a future version). Whaaaaat???

Also see http://www.sharpgis.net/post/2008/03/31/IE8-will-be-the-only-browser-not-to-support-opacity.aspx

Do you plan to support more CSS than IE7?

@ William Edney

You can apply to be a technical beta tester.  Write to ieso@microsoft.com and tell us why you are a great beta tester.  Check out Kellie's post for more info:

http://blogs.msdn.com/ie/archive/2008/03/05/ie8-beta-feedback.aspx

@ billybob

It's true the link requires login.  You can register to the connect web site with your email address to see all the feedback reported there.  Anyone can login to the site to see feedback submitted by others.

@Bac

Why on earth would you want someones email just to view bug reports?  Mozilla's bug tracker is public and you only need a login to report a new bug.  Why don't you try to be more like them?

We develop enterprise web-applications some major international companies. More and more of our customers switch to alternative browsers because they have a more feature rich user experience.

We can't fully support IE  anymore because its incompatibility to web standards has doubled/tripled development time.

Additionally we get more and more requests to replace older IE 5/6 only web-applications.

From the requests we get from our customers we can say that full SVG and almost full CSS3 (n-th selectors!) support is a must have for up coming browsers.

@billybob

At this time, MS Connect requires a Windows Live login for any actions on the site.

We will pass your feedback on to the MS Connect Team.

Kristen

Domain Highlighting will ‘disappear’ if the user hovers over or clicks in the Address Bar. This lets you edit, copy or paste a URL without being distracted by the highlighting.

seems really cool new feature is IE8 available?

Requiring login to view bugreports is a big problem, because it will prevent search engines from finding bug reports. (And no I don't really want a live login)

@Martin

https://connect.microsoft.com/robots.txt

User-agent: *

Disallow:

Sitemap: http://connect.microsoft.com/ConnectSiteMapIndex.xml

Search engines, who needs them?

User-agent: *

Disallow:

Does allow robots full access according to

http://www.robotstxt.org/robotstxt.html

I think the logic is that nothing is mentioned as disallowed, and thus anything is allowed.

When I was cooding to the win32 api, google was the only thing that keept my sanity. Rather ironic that Google saved my windows software, but this is off topic so I will just stop here, hoping the team responsible for the bug database gives read-access to anyone.

my ie7 's acid3 note was 5/100.

how much will have ie8 ? 10? 11?

seriously, you say you IE8 will fully support CSS2.1... so how long will we have to wait for having a good CSS3 IE ? 10 years ?

Julien-- ACID3 is about ECMAScript, not CSS.  CSS3 isn't even a standard yet.

Good you are looking at your first CSS 3 features, but for a full-version increment you are setting the bar very very low.

Opacity and border-radius will save people money, time and electricity - do it for mother Earth if not for pride.

I'm sorry for beeing so rude with you. That was not kind from me. Really. But please understand I'm working since wednesay on a simple thing : I wrote a simple javascript code whose goal is to change the attribute of an element. this is the code of the button that calls the function :

<input type="button" name="bout" value="Switch" onClick="changeAttribute()">

When you click on the button, it changes the display of several page's elements.

it perfectly works in Firefox, and other navigators... except IE. Well, to be honest it works in IE only when the cursor is not anymore in the button's parent area.

So I hoped that this problem would be solved in IE8 but...no, there's still that bug. Hope that you will work on that. Have a nice day.

@Julien: RE onClick issue.

It looks like the graphical glitch that Jason W pointed out affects the scripting as well.  (see #15 above)

"by Jason W

The following bug(s) are on XP (might be on Vista or 2K3 also)

15.) when you click on an input type="button", the button appears depressed until the mouse leaves the button footprint. (regression from IE6/7 behavior (button pops up after click))

"

ok, thank you. I really hope that nobody will use IE7 or IE6 when IE8 will be released, or that they will use the red panda software.

that's so hard to develop a cute site with 30.7% of dummies who are still using IE6...or 7 :-)

Hi,

just another annoying bug in IE 8 Beta 1:

I have a input type="text" element on my webpage. The tabindex is set to 1 but the cursor is not placed inside the textfield. Even clicking on the empty textfield doesn't help. I have to use the tab key to get the cursor into the field.

Regards

Guki