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 (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/
[css-d] Targeting IE8 (was: IE8 is better but still slightly broken)
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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan Gresley Sent: March 6, 2008 18:57 To: [EMAIL PROTECTED] Cc: css-d@lists.css-discuss.org; 'Bruno Fassino'; [EMAIL PROTECTED] Subject: Re: [css-d] IE8 is better but still slightly broken Thierry Koblentz wrote: I agree with Nick here. The band pass filter will be fixed in later beta. Currently I think you can use this approach (untested). imho, the fact that the band pass filter will be fixed or not is irrelevant, because in any case I won't have anything more to do. It is working *now* and it will be working tomorrow. Why should I leave that page broken when I know there is an easy, *safe* and quick fix? -- Regards, Thierry | http://www.TJKDesign.com You are correct in once sense and that why I suggested the import method to separate all versions of IE. Remember hacking IE8 to render correctly hides the bugs in the first place. I have many broken pages because IE8 is using my IE7 targeting hacks. Now I have to remove all these hacks from my main style sheet and now feed IE7 it's style via invalid import hacks. I don't know what hacks you have used Thierry but I do understand what I must do for my site but certain pages must remain broken to support any test cases that I do prepare. I not saying not to hack for IE8. I was just showing a way of using the band pass filter to feed IE8 the correct style with either broken or unbroken rendering. I myself will let IE8 render however it decides to render. 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/ __ 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/
