Welcome to WebmasterWorld Guest from 54.162.50.232

This page requires javascript to function properly. It seems that your browser does not have Javascript enabled. Please enable Javascript and press the Reload/Refresh button on your browser.

Forum Moderators: open

Message Too Old, No Replies

browser detection & spoofing

sssweb

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

Preferred Member

joined:Nov 10, 2005
posts:387
votes: 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

9:11 pm on July 30, 2013 (gmt 0)

Senior Member

drdoc is a WebmasterWorld Top Contributor of All Time

joined:Mar 15, 2002
posts:6807
votes: 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

9:30 pm on July 30, 2013 (gmt 0)

Senior Member from GB

brotherhood_of_lan is a WebmasterWorld Top Contributor of All Time

joined:Jan 30, 2002
posts:4864
votes: 13

>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

10:30 pm on July 30, 2013 (gmt 0)

Preferred Member

joined:Nov 10, 2005
posts:387
votes: 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]>


THIS IS NOT IE



THIS IS NOT IE


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

10:44 pm on July 30, 2013 (gmt 0)

Senior Member

joined:Mar 15, 2002
posts:6807
votes: 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

11:32 pm on July 30, 2013 (gmt 0)

Senior Member from US

lucy24 is a WebmasterWorld Top Contributor of All Time

joined:Apr 9, 2011
posts:13823
votes: 483

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

12:34 pm on July 31, 2013 (gmt 0)

Preferred Member

joined:Nov 10, 2005
posts:387
votes: 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

2:22 pm on July 31, 2013 (gmt 0)

Preferred Member

joined:Nov 10, 2005
posts:387
votes: 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

4:20 pm on July 31, 2013 (gmt 0)

Senior Member

joined:Mar 15, 2002
posts:6807
votes: 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

9:41 pm on July 31, 2013 (gmt 0)

Preferred Member

joined:Nov 10, 2005
posts:387
votes: 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

9:46 pm on July 31, 2013 (gmt 0)

Senior Member

joined:Mar 15, 2002
posts:6807
votes: 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

11:05 pm on July 31, 2013 (gmt 0)

Senior Member from US

joined:Apr 9, 2011
posts:13823
votes: 483

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.