homepage Welcome to WebmasterWorld Guest from 54.224.202.109
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Visit PubCon.com
Home / Forums Index / Browsers / Microsoft Internet Explorer
Forum Library, Charter, Moderator: open

Microsoft Internet Explorer Forum

    
browser detection & spoofing
sssweb




msg:4597805
 8:44 pm on Jul 30, 2013 (gmt 0)

I want to deliver browser-specific stylesheets and have been getting strange errors with IE conditional comments, so am looking for a work-around. Question re spoofing that browsers sometimes use to identify as something they're not:

If say, a non-IE browser spoofs as IE, is it okay to assume that the browser is signalling that it renders like IE, and therefore it's okay to deliver an IE stylesheet?

In other words, is it safe to rely on UA-string browser detection to deliver stylesheets?

 

DrDoc




msg:4597817
 9:11 pm on Jul 30, 2013 (gmt 0)

Conditional comments are really the safest and best way to target IE.

Rather than looking for a different solution, let's try to fix whatever errors you are experiencing. Perhaps if you post a (brief) code snippet highlighting how you currently deliver the stylesheet to IE, along with the error you are experiencing ...

brotherhood of LAN




msg:4597818
 9:30 pm on Jul 30, 2013 (gmt 0)

>a non-IE browser spoofs as IE, is it okay to assume that the browser is signalling that it renders like IE

I'd say it just signals that if you mess around with something, you may break it ... and it's not your responsibility to have to accommodate these eventualities. I can't think there'd be many cases where someones user agent has been changed deliberately without the person knowing the possible consequences and the ability to change it back.

sssweb




msg:4597836
 10:30 pm on Jul 30, 2013 (gmt 0)

@BoLAN - I tend to agree; this only came up because of the conditional comment problems.

@DrDoc: concoms targeting IE work fine, but non-IE concoms cause strange URI requests to go to the server. I've tried 3 formats, all with the same results:

<![if !IE]>
THIS IS NOT IE
<![endif]>

<!--[if !IE]>-->
THIS IS NOT IE
<!--<![endif]-->

<!--[if !IE]><!-->
THIS IS NOT IE
<!--<![endif]-->

Code inside the comments is:

<link rel="stylesheet" href="/includes/non-IE.css" type="text/css" media="all" />

The error is a bad URI request and "page could not be found"; the URI varies depending on the rest of the code on the page, but invariably begins with "/inc" (the first 4 chars of my stylesheet path). That's followed by anywhere from 1-25 chars from the rest of the page, with spaces & <tags> URL-encoded. These chars often, but not always, start at a logical break in my code (e.g. a tag, =, or "), though sometimes they start completely randomly in the middle of a word, then continue until it hits either a " or a > not preceded by a slash (i.e. />, as in <br />). Here are some sample errors:

/inc=
/ince=
/inccript (from tag <script>)
/include%3Cspan%20class= ( /include<span class= )
/inctoggleClass(

Sometimes the chars are in the <head> code, sometimes in <body>. Here are some of the longest (w/o the URL-encoding):

/include<br /><br /><br /><img class=

/incOn === 2) return;(isOn < 2) ? isOn++ : isOn = 0;switch(isOn) {case 1:sets = {animation: 3, easing:
That's from a js fn, stopping at: "

This one may give some clues:
/inc-- Full-Column start --><div class=
That's the only time it didn't stop at >, probably because it reads as a comment tag.

It's obvious that it's mangling the concom code, but for I see no logic as to where it starts up after those first 4 chars. Sometimes it's way down the page.

As I said, it usually starts with /inc, but once it was:
/ine=

My page header is:

<!doctype html>

<html lang=en-US>
<head>
<Meta http-equiv="X-UA-Compatible" content="IE=Edge" />
<Meta http-equiv="Content-type" content="text/html; charset=utf-8" />

I'm using the utf-8 char set but I don't see why that should be an issue.

I've googled this and can't seem to find the issue anywhere else.

Bet you're sorry you asked!

[edited by: phranque at 11:27 pm (utc) on Jul 30, 2013]
[edit reason] disable graphic smileys [/edit]

DrDoc




msg:4597839
 10:44 pm on Jul 30, 2013 (gmt 0)

Ah, now I understand.

Typically, what I do, is serve one general stylesheet to all browsers. Then, if necessary, I use a Conditional Comment to serve an alternate stylesheet (containing only overrides) to those IE versions that need it.

Are you uploading your file directly via FTP, or through a CMS or similar means? Many CMSs have severe issues when parsing comments.

lucy24




msg:4597859
 11:32 pm on Jul 30, 2013 (gmt 0)

is it okay to assume that the browser is signalling that it renders like IE

No, but it's not your problem, because browser spoofing does not happen by accident. The UA string that you see is simply what the user sends your server. You have no control over what happens at their end-- for example, they might have turned off scripting or image display, or might be using a custom stylesheet to override the site's settings.

sssweb




msg:4597995
 12:34 pm on Jul 31, 2013 (gmt 0)

@DrDoc - that's basically what I do; I have a couple stylesheets universal to all browsers, then deliver the few browser-specific styles via separate sheets & conditional comments. I've done this for a long time with no problems.

But you seem to be saying to serve up ALL styles in the universal sheets, then do OVERRIDES for IE (thus avoiding the need for non-IE stylesheets) -- is that what you mean? Are you suggesting that as best practice or work-around for my bug? How do I do that, using '!important' designations? Not sure I like the idea of putting out two styles for things, one "right" and one "wrong" and relying on the browser to get the right one; would rather just serve up one correct style.

I upload via FTP, so that's not it. I will try digging into archived versions to see what went wrong.

@Lucy - thanks; thought that might be the case.

sssweb




msg:4598030
 2:22 pm on Jul 31, 2013 (gmt 0)

Update:

1. My archived version of this file, when everything worked fine, is exactly the same as my current one, which started showing this bug about a week ago.

2. I ran the page about 20 times this morning and only got the error once, despite the fact that no code changes were made from yesterday.

Could something else be going on?

3. In a separate but related point, I found this note on Microsoft's developer site [msdn.microsoft.com ]:

"Support for conditional comments has been removed in Internet Explorer 10 standards and quirks modes for improved interoperability and compliance with HTML5. This means that Conditional Comments are now treated as regular comments, just like in other browsers. This change can impact pages written exclusively for Windows Internet Explorer or pages that use browser sniffing to alter their behavior in Internet Explorer."

I'll leave it to others to comment on the wisdom of that.

DrDoc




msg:4598115
 4:20 pm on Jul 31, 2013 (gmt 0)

All browsers on the market are smart enough to handle overrides fine. The last rule (assuming specificity and the selector itself is equal) is always used.

And, yes, I would say that's best practice. In your HTML code, you first reference the default stylesheet, the one with styles for compliant browsers. After, you load a smaller stylesheet which "fixes" things in IE.

For example:

default.css
#mydiv { 
height: 200px;
padding: 10px 5px;
width: 100px;
}
oldie.css
#mydiv { 
height: 220px;
width: 110px;
}


As for IE dropping support for Conditional Comments -- this is good. IE10 is to be considered a compliant browser. No need to serve overrides anymore. That, and many "fixes" which blanket-target IE tend to break things in compliant renderings. So, yeah, this is definitely a good move. That, and older IE have issues with versions greater than 9.9999 anyway.

sssweb




msg:4598230
 9:41 pm on Jul 31, 2013 (gmt 0)

Thanks, I'll take your advice. In the meantime, I seem to have stumbled on the fix. I re-ordered my stylesheets in the same sequence they were awhile back and the error is gone (for now at least).

Any idea why this should matter? FYI, per instruction I found somewhere on the internet, all my stylesheets begin with '@charset "utf-8";' to accomodate my utf-8 encoding. Other than that, they're pretty standard.

DrDoc




msg:4598232
 9:46 pm on Jul 31, 2013 (gmt 0)

Yes, stylesheet order matters (in general).

If the HTML parsing error is gone (again, depending on whether you use FTP or a CMS), the order could also play a part.

lucy24




msg:4598249
 11:05 pm on Jul 31, 2013 (gmt 0)

all my stylesheets begin with '@charset "utf-8";' to accomodate my utf-8 encoding

Encoding really shouldn't affect your stylesheets except in the rare case where the CSS itself contains non-ASCII characters. Can't think of any place this would occur except in a {content: blahblah;} declaration.

Stylesheets are normally read in the order loaded. Functionally it's as if you had one big file, with later rules overriding earlier rules if there's a conflict. So if you have a general stylesheet and a directory- or page-specific one, let the general styles load first.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Browsers / Microsoft Internet Explorer
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved