Re: [css-d] Targeting IE8
On Tue, March 11, 2008 6:54 pm, Alan Gresley wrote: So anyone who has empty declarations blocks in there style sheets will have to remove them now. Or they could do the obvious thing and report the bug to Microsoft, or vote for it if it's already been reported, and it will undoubtedly be fixed in the next beta. I have to say once again that I am completely baffled as to why people are acting as if this is a final release. It's the first public Beta of a piece of software which, if the same process with IE7 is any guide, will not be released in a final form for maybe another six months. I expect we will see at least two more Betas before seeing even a Release Candidate. If you find a bug, report it, but don't suggest that people will have to fix anything - the only people with anything to fix at this stage are the IE team, and the only useful contribution one can make to the web development community is to inform them of these issues. http://blogs.msdn.com/ie/archive/2008/03/05/ie8-beta-feedback.aspx Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Targeting IE8
Nick Fitzsimons [EMAIL PROTECTED]
On Tue, March 11, 2008 6:54 pm, Alan Gresley wrote:
So anyone who has empty declarations blocks in there style sheets will
have to remove them now.
Or they could do the obvious thing and report the bug to Microsoft, or
vote for it if it's already been reported, and it will undoubtedly be
fixed in the next beta.
Precisely. Anyway it not as simply triggered as I thought. I think the empty
declarations blocks must be following an import. Test Case.
http://css-class.com/test/bugs/ie/8/empty-declaration-hides-next-ruleset.htm
I have to say once again that I am completely baffled as to why people are
acting as if this is a final release. It's the first public Beta of a
piece of software which, if the same process with IE7 is any guide, will
not be released in a final form for maybe another six months. I expect we
will see at least two more Betas before seeing even a Release Candidate.
I personally not acting in any manner. That's why I leave my pages broken in
IE8. I have just seen one scenario. Since the rule set with empty declaration
must appear between an import and the the following rule set. This could be for
the html or body element. I dare say that if someone did have such a empty rule
set between an import and body, they may report to MS that there site is
broken because all the basic style has been lost. That would be a misguided bug
reporting, one which MS doesn't need.
If you find a bug, report it, but don't suggest that people will have to
fix anything - the only people with anything to fix at this stage are the
IE team, and the only useful contribution one can make to the web
development community is to inform them of these issues.
http://blogs.msdn.com/ie/archive/2008/03/05/ie8-beta-feedback.aspx
Regards,
Nick.
And this is why I am reporting it here. The more people that are aware of the
bug early on, the more people that will vote on the bug. I myself am waiting
for mail to arrived so I can join TechBeta. I can assure you that some in the
IE team are aware of this bug or others that I have found since my pages have
regular visits from Redmond.
I have seen a page break not due to a bug in IE8 but more because IE8 was using
a hack meant for IE7.
*:first-child+html E {display:inline} /* common IE7 fix */
These rules meant for fixing a buggy IE7 may cause a page to break in IE8 which
is a much more standard complaint browser. IE8 is needing the regular style
rules that the other browser are using. I can't really refer to these other
browser as the better browser now because IE8 in most cases is equaling or
bettering these other browsers. Listing another good scenario.
http://css-class.com/test/css/backgrounds/multiple-backgrounds.htm
The CSS is:
background: url(normal.jpg);
background: url(one.png), url(two.png);
Since IE8 is actuality parsing the last declaration it will try to download
this.
domain.com/images/one.png,two.png
instead of this.
domain.com/images/one.png
MS doesn't need reports from people that IE8 is not showing header/banner
images where the real problem is that IE8 is parsing a declaration that it
doesn't understand, thus should drop it and use the normal.jpg.
It was good that I was using a dummy image in a multiple background to serve
Safari the better image or I would never had discovered the real bug. I have
now corrected this so now Safari and Opera now use the better image. :-)
So in summing up, no need to get into frizzle. Just sit back down calmly,
meditate, and then peacefully clean up your style sheets.
For those who have the knowledge to, remove those IE7 targeting hacks from the
main style sheet and import IE7 style from another style sheet. The rest of you
can simply not use hacks, they are dangerous. :-)
Isn't CSS fun!
Alan
http://css-class.com/test/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Targeting IE8 (was: IE8 is better but still slightly broken)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] discuss.org] On Behalf Of Alan Gresley Sent: Monday, March 10, 2008 7:50 AM To: Mark Richards Cc: css-d@lists.css-discuss.org Subject: Re: [css-d] Targeting IE8 (was: IE8 is better but still slightly broken) /*\*//*/ @import url(test-ie8.css); @import(test-ie.css); /**/ @import test-ie; /* For IE5~7/Win */ You seriously feel the above code is more readable, maintainable, and logical compared to this: link rel=stylesheet type=text/css href=/css/style.css !--[if IE 7] link rel=stylesheet type=text/css href=/css/style_ie7.css ![endif]-- !--[if IE] link rel=stylesheet type=text/css href=/css/style_ie.css ![endif]-- Yes I do. I have changed my import slightly. /*\*//*/ @import url(test-ie8.css); @import(test-ie.css); /* IE/Mac */ @import test-ie; /* For IE5~7/Win */ The above code appears on one CSS file. I know exactly what it does. First we have the beginning of the IE/Mac pass band filter. Both IE/Mac and IE8 see /*/ as /**/ so they parse there respective imports. The filter is closed here /* IE/Mac */ and IE7 uses the next import. Only the first import is valid. Anyhow, I was surfing and I have stumbled on to a new IE8 hack. Some list member (Thierry!) has discovered that IE8 doesn't need the beginning /*\*/. I haven't tested but I could just have. /*/ @import url(test-ie8.css); /* IE8 */ @import test-ie; /* For IE5~7/Win */ I find all those linked style sheet redundant. You only need one. Even if you had an extra one for IE, why can't you use the star html (* html) or escapes within the style sheet to target or filter the difference versions of IE? Thierry, come on, share what you discovered. :-) Hi Alan, I shared the position:relative fix for links, but that one is not my finding. I'm pretty sure this ie8 filter is called the Bruno hack ;) -- Regards, Thierry | http://www.TJKDesign.com __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Targeting IE8
Thierry, come on, share what you discovered. :-)
Hi Alan,
I shared the position:relative fix for links, but that one is not my
finding.
I'm pretty sure this ie8 filter is called the Bruno hack ;)
--
Regards,
Thierry | http://www.TJKDesign.com
I have notice a few passing bugs. Take this one that hides rule sets from IE8.
* {}
E {}/* this rule set will be hidden from IE8 */
F {}/* this rule set will be applied by IE8 */
So anyone who has empty declarations blocks in there style sheets will have to
remove them now. Also IE8 tries to download a full string of multiple
background images. I think this is only when two such images are given for one
element. Test case.
http://css-class.com/test/css/backgrounds/multiple-backgrounds.htm
I though they would have fixed all the parsing errors but new ones have crept
in. :-)
Alan
http://css-class.com/
__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Targeting IE8 (was: IE8 is better but stillslightly broken)
Thierry Koblentz wrote: I shared the position:relative fix for links, but that one is not my finding. I'm pretty sure this ie8 filter is called the Bruno hack ;) I guess (and hope) this will be a very short-lived filter, so it can remain unnamed :-) (Btw, it was Ingo that mentioned here that IE8 reads the IE5/Mac band pass filter, simplifying it into a IE8b1 only filter is just a consequence.) Bruno -- Bruno Fassino http://www.brunildo.org/test __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Targeting IE8 (was: IE8 is better but still slightly broken)
-Original Message- Why are you suggesting in the first place to pollute your source with different conditional comments on every single page of a site. That seems like to much work and maintenance for me. Is that what you do? Well, the pages of the sites I work on are generated dynamically, using JSP templates, so for the hundreds of pages there are only about 5 different places where I need to specify what stylesheets are imported, and it's there that the conditional comments are used to include IE-specific sheets. In fact, at runtime the generated page looks on the filesystem and sees if a stylesheet is present and automatically includes the conditional comments or not. So I don't even need to maintain the code, just add and remove sheets. div class=ie6fix!-- this class is only needed for IE6/Win or earlier -- All I have to do is pull that line of code out of that include when IE6 disappears over the horizon (2020). This is the filtering hack I'm now using. And all I need to do is zap a stylesheet file from the disk and it disappears from every single page and from the generated code. Furthermore I don't pollute my source with meaningless class names like ie6fix, instead relying on IE's normal CSS selectors to find objects with class names that are meaningful in general. /*\*//*/ @import url(test-ie8.css); @import(test-ie.css); /**/ @import test-ie; /* For IE5~7/Win */ You seriously feel the above code is more readable, maintainable, and logical compared to this: link rel=stylesheet type=text/css href=/css/style.css !--[if IE 7] link rel=stylesheet type=text/css href=/css/style_ie7.css ![endif]-- !--[if IE] link rel=stylesheet type=text/css href=/css/style_ie.css ![endif]-- It's immediately obvious what the above does, even if you've never seen a conditional comment before. But unless you know 100% all the bugs and limitations of the css parser for every version of every browser, your code is, IMO, illegible. I suppose if you're the only person who ever looks at your own code this isn't an issue, but considering how many people on this list are in charge of maintaining both the CSS AND the HTML, I'd think that conditional comments would get more use, especially if you're already using an external IE-specific stylesheet. I not targeting browsers but filtering the good browsers out of disastrous mess and rescuing others from the abyss. Well, filtering the good browsers is the same as targeting the bad :) . Mark __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Targeting IE8 (was: IE8 is better but still slightly broken)
Mark Richards [EMAIL PROTECTED] Why are you suggesting in the first place to pollute your source with different conditional comments on every single page of a site. That seems like to much work and maintenance for me. Is that what you do? Well, the pages of the sites I work on are generated dynamically, using JSP templates, so for the hundreds of pages there are only about 5 different places where I need to specify what stylesheets are imported, and it's there that the conditional comments are used to include IE-specific sheets. In fact, at runtime the generated page looks on the filesystem and sees if a stylesheet is present and automatically includes the conditional comments or not. So I don't even need to maintain the code, just add and remove sheets. Good answer. In your case my reply is off target. I did go through all that for everyones benefit. Pages can be put together in many different ways and various styles can be fed to particular browsers by various method. Conditional Comments can be problematic to maintained and some beginners will start adding them to every page. Sometimes if it's not a true CCS rendering issue at all but just incorrect understanding of CSS or invalid CSS and markup. div class=ie6fix!-- this class is only needed for IE6/Win or earlier -- All I have to do is pull that line of code out of that include when IE6 disappears over the horizon (2020). This is the filtering hack I'm now using. And all I need to do is zap a stylesheet file from the disk and it disappears from every single page and from the generated code. Furthermore I don't pollute my source with meaningless class names like ie6fix, instead relying on IE's normal CSS selectors to find objects with class names that are meaningful in general. I guess you need proof. I have now removed that meaningless class name from that div. Now let see..., point either IE5 or IE6 at this page (soon to be updated). http://css-class.com/test/bugs/ie/ie-bugs.htm Now observe how various page elements have now disappeared. The navigation and the blue~green strip in the header for instance. Now resize the viewpoint and observe my floated element (Honor roll) drop. Should I just stop supporting for IE6 now and remove all my other hack for it. When I have finished, there will be nothing left. Not quite true some elements will remain. :-) OK, you can zap a file form here or there and all is fixed but what list is this? Does everyone on this list use (I may be mistaken here) PHP? You are answering my question with a scripting solution. Will this help a beginner? My solutions is entirely based on CSS and markup. Please keep solutions on topic. /*\*//*/ @import url(test-ie8.css); @import(test-ie.css); /**/ @import test-ie; /* For IE5~7/Win */ You seriously feel the above code is more readable, maintainable, and logical compared to this: link rel=stylesheet type=text/css href=/css/style.css !--[if IE 7] link rel=stylesheet type=text/css href=/css/style_ie7.css ![endif]-- !--[if IE] link rel=stylesheet type=text/css href=/css/style_ie.css ![endif]-- Yes I do. I have changed my import slightly. /*\*//*/ @import url(test-ie8.css); @import(test-ie.css); /* IE/Mac */ @import test-ie; /* For IE5~7/Win */ The above code appears on one CSS file. I know exactly what it does. First we have the beginning of the IE/Mac pass band filter. Both IE/Mac and IE8 see /*/ as /**/ so they parse there respective imports. The filter is closed here /* IE/Mac */ and IE7 uses the next import. Only the first import is valid. Anyhow, I was surfing and I have stumbled on to a new IE8 hack. Some list member (Thierry!) has discovered that IE8 doesn't need the beginning /*\*/. I haven't tested but I could just have. /*/ @import url(test-ie8.css); /* IE8 */ @import test-ie; /* For IE5~7/Win */ I find all those linked style sheet redundant. You only need one. Even if you had an extra one for IE, why can't you use the star html (* html) or escapes within the style sheet to target or filter the difference versions of IE? Thierry, come on, share what you discovered. :-) It's immediately obvious what the above does, even if you've never seen a conditional comment before. But unless you know 100% all the bugs and limitations of the css parser for every version of every browser, your code is, IMO, illegible. I suppose if you're the only person who ever looks at your own code this isn't an issue, but considering how many people on this list are in charge of maintaining both the CSS AND the HTML, I'd think that conditional comments would get more use, especially if you're already using an external IE-specific stylesheet. And that's why you should comment both your CSS and markup. We know what IE7 and IE8 does with those comments. OK, your perspective is from several people authorizing the code so when answering keep this in mind that there are also those
Re: [css-d] Targeting IE8 (was: IE8 is better but still slightly broken)
-Original Message- From: Alan Gresley Conditional Comments can be problematic to maintained and some beginners will start adding them to every page. Sometimes if it's not a true CCS rendering issue at all but just incorrect understanding of CSS or invalid CSS and markup. I don't see how that problem is different from CSS hacks that import separate stylesheets, actually. Should I just stop supporting for IE6 now and remove all my other hack for it. When I have finished, there will be nothing left. Not quite true some elements will remain. :-) I'm not saying don't target. OK, you can zap a file form here or there and all is fixed but what list is this? Does everyone on this list use (I may be mistaken here) PHP? You are answering my question with a scripting solution. Will this help a beginner? My solutions is entirely based on CSS and markup. Please keep solutions on topic. Ok, I admit that server-side scripting is off-topic, but then so is code-maintenance in general. Personally I would be astonished to find that most people are NOT using some server-side scripting system; who has a totally static website in 2008? And anyway, even if your website IS static, that suggests that there are only a few pages. If you're maintaining a large site without some code generation and templates, I feel sorry for you :) As for helping beginners, I think conditional comments are still a better solution than hacks specifically because they are easier for beginners to understand. Anyone who can grasp a tiny bit of JavaScript, and surely someone who can use the more advanced CSS selectors should be able to understand the syntax of a conditional comment, and won't need to worry about what the hacks are or how they work. And when you first encounter a conditional comment on a page, even if you've never heard of it, you can at least intuit what it does. Not so with a hack. You seriously feel the above code is more readable, maintainable Yes I do. I have changed my import slightly. /*\*//*/ @import url(test-ie8.css); @import(test-ie.css); /* IE/Mac */ @import test-ie; /* For IE5~7/Win */ So in order to be able to use this you need to understand that all three constructs, which look (to me) like they should do the exact same thing, actually work or don't work based on the browser you are using. It's also possible that there are other browsers out there that will read these imports (correctly or incorrectly) depending on what bugs THAT browser has. The above code appears on one CSS file. I know exactly what it does. But no beginner does, and not necessarily every CSS dev either. I know about these hacks from this list, but I'd have to look up what the hacks are for. Hacks are based on doing something WRONG in CSS but having the browser do something RIGHT in response. If the CSS code isn't valid the browser should do NOTHING, but in the case of a hack it does something. Exploiting that error is confusing to people who usually write correct code, expecting that incorrect code will do nothing. I find all those linked style sheet redundant. You only need one. Even if you had an extra one for IE, why can't you use the star html (* html) or escapes within the style sheet to target or filter the difference versions of IE? Because different versions of IE have different features and different bugs, and require different fixes. Separating the fixes required makes it easier to drop support later on, or to fix a bug without possibly breaking the other browsers if they don't have that bug. Anyway it's the same thing as your example: an IE stylesheet for every version that needs it (remember: if I don't need any IE7 fixes I don't have an IE7 sheet and the script doesn't put that comment into the page). Most of my pages have just an IE6 sheet, actually. (Where I work we don't support IE/Mac). And that's why you should comment both your CSS and markup. We know what IE7 and IE8 does with those comments. OK, your perspective is from several people authorizing the code so when answering keep this in mind that there are also those single author. The full spectrum. In my experience even a single author can be confused by his own code later on. Comments help but they're not always there and not always right. Doing things in a clear way from the beginning means less reverse-engineering later. Yes I am targeting. Should I pull those imports out and make those pages look awful for IE/Mac, IE7 and IE8. Please tell me how else I can do this without conditional comment. I'm not saying don't target. We have to target. It's a sad necessity because the browsers all have different capabilities and bugs. I also agree with putting browser-specific fixes into browser-specific sheets. I think it's reasonable to design stuff so that fixes required are kept to a minimum, but sometimes you just have to fix some browser's broken implementation. Naturally you want
Re: [css-d] Targeting IE8 (was: IE8 is better but still slightly broken)
Mark Richards wrote: I'm curious as to why you're targeting various IEs with hacks when conditional comments let you do the same thing? Especially if the hacks are used to import external sheets in the first place, it seems to me it's easier to just use CCs to load browser-specific fix-up sheets in the first place. Mark R I don't do fix ups, I do rescues :-) What may be easier for you is the complete opposite to what is easy for me (well at this precise moment in time that is). Why are you suggesting in the first place to pollute your source with different conditional comments on every single page of a site. That seems like to much work and maintenance for me. Is that what you do? Please take a look at the source of my (old template) which I see offline in my NoteTab. http://css-class.com/test/offline-source.txt In the source you will find this line after the linked style sheet. !--#include virtual=test-style-script.txt -- http://css-class.com/test/test-style-script.txt Now after reading the text in the above include you will possibly now be reconsidering why you have hard coded those conditional comment in the first place. Take a look at my source again which I see offline and look at the tail end of it. In one of those includes is this line of code. div class=ie6fix!-- this class is only needed for IE6/Win or earlier -- All I have to do is pull that line of code out of that include when IE6 disappears over the horizon (2020). This is the filtering hack I'm now using. /*\*//*/ @import url(test-ie8.css); @import(test-ie.css); /**/ @import test-ie; /* For IE5~7/Win */ The second import is for IE/Mac. Please note my message to Alex. IE8 conditional comment will target bundled IE versions. So testing really becomes a mess when using conditional comments. I not targeting browsers but filtering the good browsers out of disastrous mess and rescuing others from the abyss. I have finished the template now and it now appears live. http://css-class.com/test/ Alan http://css-class.com/ __ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
