 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / CSS / January 2005A stylesheet for IE, another one for web browsers
Hi, Once I was happy with my new deezign[1], I noticed how bad it breaks in IE (all versions I tried). Since IE7[2] didn't give acceptable results, I wrote a simplified style that I would fetch to IE. How to do it is the point of my post. I am using for now conditional comment[3] (clean) to give IE its CSS, and a IE parsing bug[4] (not clean) to hide the real CSS from IE: <!--[if IE]> <link rel="stylesheet" type="text/css" href="site-IE.css"> <script src="navbar.js" type="text/javascript"></script> <![endif]--> <style type="text/css"><!-- @import url(site.css) all; --></style> I am wondering whether a better method exists, especially one that would: * not rely on a IE bug to hide the CSS file * not break HTML validation (no <![if !IE]>...<![endif]>) * provide good browsers with the two alternative stylesheets * deal with several CSSes: all pages include (by SSI) site.css (or site-IE.css), but some also include pro.css (resp. pro-IE.css), some others perso.css (or perso-IE.css) (if I read the specs correctly, <link rel="alternate stylesheet" ...> cannot fulfill this requirement) A method that solves just one of the four points above would already be great! [1] http://yo.dan.free.fr/ [2] http://dean.edwards.name/IE7/ [3] http://msdn.microsoft.com/workshop/author/dhtml/overview/ccomment_ovw.asp [4] http://www.phoenity.com/newtedge/hide_css_ie/ PS: I take this post as an opportunity to thank those who ansered my newbie questions a while ago, and to thank everyone who intervenes in this forum: you are definitely helping more than one person when you answer one question! (I have been lurking for quite a while, as obviously many others do.)  SignatureDaniel Déchelotte http://yo.dan.free.fr/ Daniel Déchelotte <maitre_yodan@fr.club-internet.invalid> writes: > I am using for now conditional comment[3] (clean) to give > IE its CSS, and a IE parsing bug[4] (not clean) to hide [quoted text clipped - 14 lines] > others perso.css (or perso-IE.css) (if I read the specs correctly, > <link rel="alternate stylesheet" ...> cannot fulfill this requirement) I have no idea whether this would work (don't have IE handy), but what does IE make of something like this: <!--[IF IE]> <![IF !IE]> <![endif]--> baz <!--[IF IE]> <![endif]> <![endif]--> -- for everything else it's just baz surrounded by a pair of comments? SignatureJón Fairbairn Jon.Fairbairn@cl.cam.ac.uk Jón Fairbairn a écrit : | Daniel Déchelotte <maitre_yodan@fr.club-internet.invalid> writes: | [quoted text clipped - 19 lines] | <![endif]> | <![endif]--> It does exactly what one would hope! Thanks for the tip. As for my 4th wish above, I have just read this article[1] from ALA that states "[...] these style sheets can also be grouped together by giving them identical title attributes.". Almost obvious, but I have already implemented an alternate (and brain-dead) solution, based on many files and even more @import's. ;-) [1] http://www.alistapart.com/articles/alternate/ Quick answer to logic_earth, who wrote: | I suggest making a stylesheet that works in all the latest browsers. So | you don't have to do such hacks. If you can't do it then you should | practice more and change how you layout the elements. I agree all the more that this is a personal website and I don't have to make it HR-friendly for another two years, so my requirements were: * perfect in FF/Mozilla (latest version) * very good in Opera (latest version) * useable in IE in its latest, patched, version * don't care about the rest (well, not really) and I will add an "About this site" page. Unfortunately, because of the graphical design I had in mind, I ran into the famous "extend a DIV to 100% of the content or the viewport height, whichever is taller" problem, and the related bugs (I chose a solution that uses fixed positioning). Also, pure CSS menus require some specific work for IE. So I settled for a simplified style for IE, because, as is, it was a pain to browse my site with IE. And since it is merely a personal website, I can afford not to change the layout just for IE. SignatureDaniel Déchelotte http://yo.dan.free.fr/ In message <20050109204121.4ea113e5.maitre_yodan@fr.club-internet.invalid>, Daniel Déchelotte <maitre_yodan@fr.club-internet.invalid> writes >| >not rely on a IE bug to hide the CSS file I don't know if it helps any, but I have set up a style sheet in php. The .php script can sniff the browser and generate a style sheet that differs in just the necessary ways. (It can also propagate color/colour changes through the css, which si why I did it). You need to start it with... <?php header("Content-type: text/css"); and then go on to generate the rest, or it is not recognised by some browsers. Regards Ian SignatureIan - posting to a Newsgroup. Please remove everything to reply. >The .php script can sniff the browser No it can't. SignatureSpartanicus > >The .php script can sniff the browser > > No it can't. Well, it can, but if it smells fish it can't know whether it is fish. SignatureJón Fairbairn Jon.Fairbairn@cl.cam.ac.uk >> >The .php script can sniff the browser >> >> No it can't. > >Well, it can, but if it smells fish it can't know whether it >is fish. Then please tell me which browser I'm using: +++GET 2+++ GET /TR/REC-CSS2/ HTTP/1.1 User-Agent: Code to W3C standards and stop that idiotic browser sniffing (My OS; U) [en] SignatureSpartanicus > >> >The .php script can sniff the browser > >> [quoted text clipped - 9 lines] > User-Agent: Code to W3C standards and stop that idiotic browser sniffing > (My OS; U) [en] Well, yes; but there are other considerations. And you *could* take the view that if the client agent tells lies, then it deserves whatever the server sends it. Of course, the original statement would better have said something like "the .php script can sniff what the client agent says it is, if anything". But what conclusion do we draw from that observation? The HTTP spec reminds us (see RFC2616 section 14.43) that this header is optional, and could be used for statistical purposes (I've no argument with that, as long as one understands its [un]reliability and doesn't draw untenable conclusions from the results); for tracing of protocol violations (yup), or for "tailoring responses to avoid particular user agent limitations". Now, this last is the one that I have a problem with, in the present context. My *hunch* is that the RFC authors were thinking in terms of modifying the *HTTP protocol response* to avoid certain user agent limitations of HTTP support - you might recall stanzas of this kind in Apache configurations: SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 But if, on the other hand, you're using this to vary not just the protocol response but even the contents of the actual response body, then you have a server-negotiated response body which varies according to the user-agent string - thus, your negotiated response shall include a "Vary: User-Agent" header, and this is very hostile to cacheability. (Mark Nottingham's tutorial applies - not that I'd need to tell -you- that!). If, on the other hand, you send a carefully-designed *static* response, which capitalises on some known shortcoming of the affected browser, then you can be sure that it will have its intended effect no matter what untruths the browser might tell in its user-agent string, and *without* the slightest harmful effect on other users. Examples of this general idea are the "hiding advanced CSS from browsers" techniques discussed at http://w3development.de/css/hide_css_from_browsers/ Then again, there's MSIE's conditional comments wibble, which - as long as one confines oneself to the subset that is decent HTML syntax, seems to me to be OK as a practice, even if the very idea can be rated as pandering to something that's determined not to support published interworking specifications. So, in conclusion, my argument against server-varied response documents depending on user-agent string are not merely that it's unreliable in practice, but that it can cause degraded performance to a wide range of users, with possibly serious degradation for those who are behind a cache server proxy. [UA sniffing] >The HTTP spec reminds us (see RFC2616 section 14.43) that this header >is optional, and could be used for statistical purposes (I've no [quoted text clipped - 7 lines] >modifying the *HTTP protocol response* to avoid certain user agent >limitations of HTTP support I know little about HTTP, but afaik HTTP protocol support of the UA doesn't matter if the connection is via a proxy, only the proxy's HTTP protocol support matters. Afaik proxies are not required or supposed to alter the UA string, making UA sniffing for the purpose of avoiding limitations in UA HTTP protocol support fundamentally flawed. SignatureSpartanicus > [UA sniffing] > [quoted text clipped - 11 lines] > > I know little about HTTP, I fear that we're headed to far off-topic for this group, and would do better to get our ideas peer-reviewed on a group that deals with servers; but at least let me say this much... > but afaik HTTP protocol support of the UA doesn't matter if the > connection is via a proxy, only the proxy's HTTP protocol support > matters. Good point. The client agent talks HTTP to the proxy; the proxy talks HTTP to the origin server; but the two transactions are quite separate, even though the UA header will normally be passed-through (possibly modified). In any realistic implementation, any UA-dependent modification of the HTTP transaction details would be a downgrading to some older or simpler procedure that was thought to be more reliably implemented, albeit maybe less efficient etc. This would do the proxy no harm, even if the proxy didn't in fact need the downgrading for the reason that you've rightly pointed out. > Afaik proxies are not required or supposed to > alter the UA string, Actually, there -is- a convention for the proxy to make itself known by means of "via" detail appended to the agent string. Google suggests http://www.philosophe.com/audience/sample_agent_log.html for examples (look for user agent strings with "Via" in them). But I see that our campus proxy (squid) is no longer doing this: instead, it's adding HTTP Via: and X-Forwarded-For: headers, and leaving the user agent alone. Certainly there's no -requirement- for a modification, or for any other extra information. Indeed, the whole point of privacy proxies would be to -remove- such otherwise-informative details!! > making UA sniffing for the purpose of avoiding > limitations in UA HTTP protocol support fundamentally flawed. Less than ideal, I agree: but still feasible, I'd say. Of course, the whole idea is to avoid a known bug *by using some other conforming option of the protocol*. It would be crazy to implement a fixup method which *relied* on some known bug or shortcoming of a particular user agent. hope this makes sense > >> >The .php script can sniff the browser > >> [quoted text clipped - 9 lines] > User-Agent: Code to W3C standards and stop that idiotic browser sniffing > (My OS; U) [en] Smells like fish to me. I've no idea whether it is fish though. I think you missed the joke :-( SignatureJón Fairbairn Jon.Fairbairn@cl.cam.ac.uk >> >> >The .php script can sniff the browser >> >> [quoted text clipped - 13 lines] > >I think you missed the joke :-( Responses on usenet that are not supposed to be taken serious are best delineated by adding an emoticon. I read it as "you can find out the browser used, but it may not be correct". This is not correct since as Alan pointed out the User-Agent header is optional, and the string may not contain a reference to a UA at all. SignatureSpartanicus > >> >> >The .php script can sniff the browser > >> >> [quoted text clipped - 6 lines] > Responses on usenet that are not supposed to be taken > serious are best delineated by adding an emoticon. Sorry. I thought the idea of a browser smelling fishy was silly enough on its own (particularly since the most common confounding habit is to disguise sweet smelling browsers with fish :-) > I read it as "you can find out the browser used, but it > may not be correct". Ah. I meant "you can sniff all you like but the smell you get doesn't tell you about the browser.". SignatureJón Fairbairn Jon.Fairbairn@cl.cam.ac.uk >Daniel Déchelotte <maitre_yodan@fr.club-internet.invalid> writes: >> I am using for now conditional comment[3] (clean) to give >> IE its CSS, and a IE parsing bug[4] (not clean) to hide >> the real CSS from IE: [...] >> I am wondering whether a better method exists, especially one that would: >> * not rely on a IE bug to hide the CSS file [...] >I have no idea whether this would work (don't have IE >handy), but what does IE make of something like this: [quoted text clipped - 9 lines] >-- for everything else it's just baz surrounded by a pair of > comments? As reported, at least by Daniel, this CC attempt is "working" but it also made me think a bit about what is really happening inside IE in that case. Let's structure the "code" a bit at first. 1. <!--[IF IE]> 2. <![IF !IE]> 3. <![endif]--> 4. baz 5. <!--[IF IE]> 6. <![endif]> 7. <![endif]--> I have always assumed that IE's CC evaluation is based on some form of standard principle, similar to how conditional execution would take place in any other "programming language". In which case I can not see how that CC "code snip" could hide 'baz' from IE in the first place. Let's send this to IE under that assumption of mine. Line 1 will be evaluated to a BOOLEAN TRUE status. Line 2 will start a new evaluation, which will at first 'push' the TRUE running value from Line 1 on the stack to make room for a new running value, which will be FALSE this time. Line 3 "should" be the 'endif' statement for Line 2 which, when evaluated, "should" 'pop' the stack to bring back the original TRUE value from Line 1 as the running value. /In which case/ Line 4. with its 'baz' lies fully open for interpretation by IE. After that, Line 5. and Line 6. becomes "dummies" for IE and finally Line 7 will close the evaluation started in Line 1. I do fully agree with the statement that this "code snip" will present 'baz' fully undisturbed to real browsers, that part is not a problem. But in order for it to work as expected in IE we need to assume that the FALSE running value, that comes out of the evaluation in Line 2, will also prohibit IE from evaluating Line 3? In which case it will also not evaluate the 'baz' in Line 4 of course. But then, why should it evaluate Line 5? Line 6? or even Line 7? It would be really good, from a practical standpoint, to find a reliable way to exclude some CSS from IE all together, but I can not make the ins and outs of the presented "code", as seen in the light of a report that it really does "work" as expected? What gives? SignatureRex > As reported, at least by Daniel, this CC attempt is "working" but it > also made me think a bit about what is really happening inside IE in [quoted text clipped - 7 lines] > 6. <![endif]> > 7. <![endif]--> A possible sane explanation: 1. Conditional comments are used in a preprocessor way 2. The if/endif matching respects the type of the comment ("downlevel-hidden" vs. "downlevel-revealed") Line 1 gives true Look for an endif. Output everthing inbetween. Output line 4 Line 5 gives true Look for an endif. Output everthing inbetween. Results in 8. <![IF !IE]> 9. baz 10. <![endif]> Parse again. Line 8 gives false Skip to endif Martin Bialasinski a écrit : | > As reported, at least by Daniel, this CC attempt is "working" but it | > also made me think a bit about what is really happening inside IE in [quoted text clipped - 15 lines] | [...] | Parse again. That bit seems unlikely to me (for efficiency purposes). I agree with point 2 (if/endif matching), but I think the "preprocessor way" thing is wrong. This is my guess: Line 1: enter comment (depth 1) to be evaluated, look for an <![endif]--> to close it. 2: enter comment (depth 2) to be hidden, look for an <![endif]> to close it. 3-5: hidden 6: close comment of depth 2 7: close comment of depth 1 To make a point for my case, here is some simplified code that still works: 1. <!--[if IE]> 2. <![if !IE]> 3. < --> 4. <p>Read by browsers, ignored by IE 5. <!-- > 6. <![endif]> 7. <![endif]--> (no need for conditional comment parts at lines 3 and 5) See it in action at http://yo.dan.free.fr/test_CC.html Oh, wait, that does *not* invalidate your explanation. ;-) Still, I think mine is more likely. :-P SignatureDaniel Déchelotte http://yo.dan.free.fr/ Daniel Déchelotte wrote: > I agree with point 2 (if/endif matching), but I think the "preprocessor > way" thing is wrong. This is my guess: [quoted text clipped - 17 lines] > > (no need for conditional comment parts at lines 3 and 5) I've never seen whatever information Microsoft provides about how "conditional comments" *should* work and I don't have IE here to test with but, assuming that this was implemented in some vaguely rational manner (which I admit is a big assumption), shouldn't this simple code work: <!--[if !IE]--> <p>read by browsers, ignored by IE <!--[endif]--> Real browsers would either ignore the "conditional comments" or, if they're crazy enough to implement this crock, at least realize that they're not IE; IE would process the "conditional comments" and skip the content because it *is* IE. Am I confused? Dave Dave Anderson a écrit : | Daniel Déchelotte wrote: | [quoted text clipped - 15 lines] | <p>read by browsers, ignored by IE | <!--[endif]--> Nope, and it breaks strangely, as IE displays everything, including the comments! Well, as proprietary as they are, CCs follow a syntax, described at the page I gave in my original post (reference [3]). ;-) In an attempt to summarize the thread, the minimum code would be: <!--[if IE]> ... IE specific code here ... <![if !IE]>< --> ... non-IE code here ... <!-- ><![endif]><![endif]--> W3C and Microsoft compliant, if not terribly legible. SignatureDaniel Déchelotte http://yo.dan.free.fr/ On Wed, 12 Jan 2005 17:53:14 +0100, Daniel Déchelotte <maitre_yodan@fr.club-internet.invalid> wrote: >Dave Anderson a écrit : >| Daniel Déchelotte wrote: >| ...shouldn't this simple code work: >| >| <!--[if !IE]--> >| <p>read by browsers, ignored by IE >| <!--[endif]--> >Nope... [...] >In an attempt to summarize the thread, >the minimum code would be: [quoted text clipped - 6 lines] > >W3C and Microsoft compliant, if not terribly legible. Thanks for the investigation guys. I'm saving this thread for a new entry in the ciwas authoring FAQ. SignatureRex Apologies for delayed followup. > >Daniel Déchelotte <maitre_yodan@fr.club-internet.invalid> writes: > >> I am using for now conditional comment[3] (clean) to give [quoted text clipped - 38 lines] > place in any other "programming language". In which case I can not see > how that CC "code snip" could hide 'baz' from IE in the first place. When I wrote it, I didn't have chance to check it on IE. Not knowing how IE really works, I chose something that would work under two of the numerous possibilities, namely a macro-preprocessor and cautious bracket matching. (I don't even know whether IE interprets nesting of conditional comments; after all, if IE inside if not IE is a little bit strange). Given the more likely cautios bracket matching, the code would be interpreted like this: > 1. <!--[IF IE]> -- (1) > 2. <![IF !IE]> -- (2) > 3. <![endif]--> -- non-matching endif (because of the "--" > 4. baz > 5. <!--[IF IE]> -- nested conditional > 6. <![endif]> -- matches (2), so error recovery closes the nested conditional, and then (2) > 7. <![endif]--> -- closes (1) > [quoted text clipped - 5 lines] > > What gives? I think the above is a plausible explanation. However, even Daniel Déchelotte's neater version of the code cannot be relied upon. The *only* thing we can assume will work in future versions of IE is the invalid (from an html point of view) syntax given in Microsoft's description of conditional comments. After all, it would have been perfectly possible for them to have chosen a syntax something like this: <!--[IF IE]> stuff to be processed by IE, cannot contain comment sequences. <![else]--> stuff to be processed by non-IE <!--[endif]--> or handle the not IE case thus: <!--[IF !IE]--> stuff to be processed by non-IE <!--[endif]--> I disdain to comment on whether their choice reflects <del>malice</del><ins>sound commercial practice</ins> or language design incompetence. SignatureJón Fairbairn Jon.Fairbairn@cl.cam.ac.uk I suggest making a stylesheet that works in all the latest browsers. So you don't have to do such hacks. If you can't do it then you should practice more and change how you layout the elements. .oO(logic_earth) >I suggest making a stylesheet that works in all the latest browsers. Quite hard to do with IE. >So >you don't have to do such hacks. I don't consider conditional comments as hacks. They are well defined to work in IE without side effects in other browsers. >If you can't do it then you should >practice more and change how you layout the elements. There are too many things where IE simply fails or really screws things up. Using CCs is a rather clean way to provide workarounds if necessary. Micha > I suggest making a stylesheet that works in all the latest > browsers. So you don't have to do such hacks. You mean stylesheets with CSS-hacks that exploit bugs in IE's CSS parser to work around IE bugs? |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.