 |
 | 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 / JavaScript / April 2006Should UA string spoofing be treated as a trademark violation?
I wandering about the common proctice of some UA's producers to spoof the UA string to pretend to be another browser (most often IE). Shouldn't it be considered as a trademark violation of the relevant name owner? If I make a whisky and call it "Jack Daniels", I most probably will have some serious legal problems. "Mozilla" partially appeared because NCSA stopped them from using "Mosaic" in the UA string. Is it some different situation with the current spoofing? P.S. And no, I am not starving for browser sniffing. But the stats impact is obvious. > I wandering about the common proctice of some UA's producers to spoof > the UA string to pretend to be another browser (most often IE). [quoted text clipped - 9 lines] > P.S. And no, I am not starving for browser sniffing. But the stats > impact is obvious. It seems that this problem would be of concern mainly to Microsoft, and Microsoft has plenty of good lawyers and usually will use them for the least little copyright violation they see. I would thus guess that either there is not a copyright violation or Microsoft considers this problem unimportant. Of course copyright laws can vary somewhat around the world, and they are not enforced very well in some countries. I am quite willing to leave the copyright aspects of this "problem" to Microsoft. However, I think that every browser variation should have a unique ID number assigned by an international agency, and that any browser should be blocked from the web that does not have such an ID. This would allow meaningful browser detection on the rare occasions that it is really needed - for example the browser has a bug that other browsers do not have. Howover, I am sure that this is wishful thinking on my part, just as is a requirement that all new pages be blocked from the web unless they completely validate at the W3C html and css validators. > > I wandering about the common proctice of some UA's producers to spoof > > the UA string to pretend to be another browser (most often IE). <snip> > It seems that this problem would be of concern mainly to Microsoft, and > Microsoft has plenty of good lawyers and usually will use them for the > least little copyright violation they see. I would thus guess that > either there is not a copyright violation or Microsoft considers this > problem unimportant. Don't be silly, Microsoft couldn't take action against anyone as they virtually invented UA string spoofing, and every browser they have released since IE 4 has spoofed Netscape 4 (hence 'Mozilla/4.0' at the start of their UA string). It was Microsoft's action in spoofing Netscape that resulted in the change between HTTP 1.0 and 1.1 where the latter no longer specifies the UA header as a source of information, only suggests that it could be used as such. By the time HTTP 1.1 was written the horse had long since bolted. > ... , and that any browser should be blocked from the web > that does not have such an ID. At which point the people writing the browsers you have never heard off, and would so assume are incapable of anything, start spoofing browser IDs. We just end up back where we are now, with lots of people wasting their time thinking about browser IDs in the same way people have been wasting their time assuming that user agent strings could be a source of information. > This would allow meaningful browser detection on the rare occasions > that it is really needed Many more people declare a need for browser detection than are actually capable of coming up with some example where feature detection could not answer the question if asked. > - for example the browser has a bug that other > browsers do not have. Don't all browsers have a bug that other browsers do not have? But most significant bugs can be tested for without browser detection. If you think otherwise you are welcome to suggest a concrete example and see if it can't be feature detected. > Howover, I am sure that this is wishful thinking <snip> Yes it is. Richard. > Don't all browsers have a bug that other browsers do not have? But most > significant bugs can be tested for without browser detection. If you > think otherwise you are welcome to suggest a concrete example and see > if it can't be feature detected. To not be nasty - but exclusively as a "burden of proof": The current SVG Cairo engine used in Firefox 1.5.x cannot render textpaths under Windows 98. Even more nasty: it just stops SVG rendering on the first occurence of textpath. It is mentioned on Mozilla's site but doesn't help on a practical run. While the SVG Cairo support itself can be detected by if (document.implementation.hasFeature('org.w3c.dom.svg', '1.0')) for Windows 98 adjustments I have to sniff for "Win98" in UA's string. Though this sample is not perfectly "clear" as I'm sniffing for OS, not UA. >> ... suggest a concrete example >> and see if it can't be feature detected. > > To not be nasty - but exclusively as a "burden of proof": > > The current SVG Cairo ... <snip> That is not a concrete example, it is a hearsay report from the most unreliable source available. Richard. > > The current SVG Cairo ... > <snip> > > That is not a concrete example, it is a hearsay report You imply that I do not use SVG but just making up a problem? It is not clear how did you come up to this conclusion - unless you think yourselve telepathic. Here is the feature detection block I'm currently using, and believe me I did not make it just to post it here: ... /** * Feature detection block. */ /*@cc_on @*/ /*@if (@_jscript_version >= 5.5) if (document.namespaces['v'] == null) { document.namespaces.add('v','urn:schemas-microsoft-com:vml','#default#VML'); } SVL.UA = 'IE'; SVL.VL = 'VML'; @elif (@_jscript) SVL.UA = 'IE'; @else @*/ if (document.implementation) { if (window.opera) { SVL.UA = 'Opera'; SVL.VL = 'SVG'; } else if (document.implementation.hasFeature('org.w3c.dom.svg', '1.0')) { SVL.UA = 'Gecko'; SVL.VL = 'SVG'; } else if ((window.netscape)&&(window.netscape.security)) { SVL.UA = 'Gecko'; } else { /*NOP*/ } } /*@end @*/ ... >> > The current SVG Cairo ... >> <snip> >> >> That is not a concrete example, it is a hearsay report > > You imply that I do not use SVG but just making up a problem? I do not imply that that you don't "use" SVG, I stated that your assertion was a hearsay report form the most unreliable source available. > It is not clear how did you come up to this conclusion - > unless you think yourselve telepathic. There is no need for telepathy, all I have to do is observer that:- 1. You don't understand javascript sufficiently well to understand the code that you write yourself. 2. You write bug-filled, convoluted, difficult to maintain, even dangerous code, disregarding conventions and still failing to fully address the applicable situation. 3. You are unwilling to take the advice of others on how to better understand javascript, even when those individuals are the ones capable of explaining the hows and whys of javascript. 4. You are incapable of comprehending technical explanations of javascript, or engaging in the process of formatting questions asking for clarification of what you don't understand. 5. You resist evidence and demonstrations that you are wrong far beyond the point where any rational observer would accept reality. 6. When you find yourself in a minority of one in a technical discussion involving many genuine experts on a subject you prefer to conclude that everyone else is wrong and you alone are the only person who really understands the technology. 7. You author code on a basis of mystical incantation, including things 'because they work' but without any understanding of what they actually do or ability to explain why you are using them. 8. You declare things to be 'bugs' because you don't like/understand them when they are actually completely normal and expected (even technically specified). 9. You don't understand computers (even to the extent of seeing why the bit widths of data and address registers have nothing to do with the precision of number representations in computer systems). 10. You bury your head in the sand whenever you are faced with the possibility that things could be done better, or how they might be done better. 11. You spend time testing browsers and end up knowing less about them than when you started. 12. You don't understand logic. 13. You follow irrational though processes to false conclusions and then maintain that you are correct in the face of any arguments. 14. You see relevance in the irrelevant and unrelated, but can never justify it, preferring to characterise those who see the irrelevant as irrelevant as beyond understanding. 15. The majority of your statements are too incoherent to convey meaning. 16. When your statements are clear enough to convey meaning the majority are irrational, technically false or made up off the top of your head. 17. You use English terms outside of their accepted meanings and apply those incorrect meaning to your interpretation of English. 18. You use technical language outside of its specified meaning. 19. You are incapable of consistently creating well-formed Usenet posts. 20. You tend to regard people pointing out your inadequacies as personally motivated rather than the reasoned responses to your own misguided actions/behaviour that they actually are. And given the above, when you make a statement that something is so it would not be sensible for anyone to conclude that it is so, and even if it were so it would be more reasonable to attribute it to shortcomings in the programmer than anything else. I.E. if you are not capable of rendering something sufficiently concrete that it can be reproduced by others then it makes more sense to disregard it as just more irrational ravings from your deranged mind. > Here is the feature detection block ... <snip> That is not a feature detection block, and is till irrelevant to the 'issue' you mentioned. Richard. > 1. You don't understand javascript sufficiently well to understand > the code that you write yourself. <snip> Rather strong statement from a person who just recently learned how to add <script> elements to the page (see the relevant thread) ;-) > > 1. You don't understand javascript sufficiently well to understand > > the code that you write yourself. [quoted text clipped - 4 lines] > > ;-) Is there a troll convention going on in the UK this weekend :-). Just look at the post history of some of the trolls responding to this thread, and you will see that they treat everyone in the same rude, troll-like way. The best tactic likely is just to ignore them. Most see them for what they are. Since some of the trolls appear to have far too much free time, as indicated by their many and often extremely long and rude posts to this group and others, perhaps they need something more productive to keep them busy and to avoid boredom. Since several appear to be in the UK, I would like to suggest a useful project for them. The Queen has a web site at http://www.royal.gov.uk/output/Page1.asp . Of course the Queen would hire someone to write her pages. If you take the noted url to the W3C validator, you find many errors, including some javascript ones. It would seem the Queen should deserve a site that validates perfectly. Perhaps some of the UK trolls could correct the code in the site and contact a member of the royal household staff to explain the problem and how it could be corrected. The Queen appears to be a very nice and polite lady in her public speeches. Usenet trolls could benefit greatly by studying the Queen's speeches in details. >> > 1. You don't understand javascript sufficiently well to understand >> > the code that you write yourself. [quoted text clipped - 6 lines] > > Is there a troll convention going on in the UK this weekend :-). If there was, most certainly you would be there, would you not? > Just look at the post history of some of the trolls responding to this > thread, I can see only one, maybe two trolls here. Certainly they are not called Richard, Michael, or Lasse, as those people are in fact invaluable contributors to this newsgroup, who have made their points well. While "cwdjrxyz" and the like are not at all, and they have not. > [...] > Since some [...] appear to have far too much free time, as > indicated by their many and often extremely long and rude posts > to this group and others [...] This is a technical Usenet discussion group, its more serious contributors trying to come up with (for some people hard) technical facts; not some cuddle script-kiddie Web forum, its members telling you what you want to hear, that you may be used to. If you can't stand the heat, stay out of the kitchen. <URL:http://jibbering.com/faq/> Score adjusted PointedEars > At which point the people writing the browsers you have never heard > off, and would so assume are incapable of anything, start spoofing > browser IDs. We just end up back where we are now, with lots of people > wasting their time thinking about browser IDs in the same way people > have been wasting their time assuming that user agent strings could be > a source of information. Of course you are right. So the international agency that assigns browser IDs would have to have the ability to enforce the standards and heavily fine or otherwise penalize browser writers who violate them. On a more general level, we have to have international and national standards for broadcasting radio and TV to avoid chaos. However the situation on the web has approached anarchy in many respects, resulting in unnecessary problems for both the writers of web pages and users. The technical control of radio and TV broadcasting on an international and national basis is not perfect, and a few rogue countries have jammed broadcasts from time to time, for example. However, in my opinion, the situation is far better in the broadcast field than it now is on the web. I am only talking about enforcement of technical standards. I do not think that regulation of content standards is a good thing in most cases, although there could be rare exceptions. The problem here is that what is acceptable in one society may not be so in another. A good example is China. Both Google and Yahoo have recently attracted the attention of the US Congress, and others, concerning giving personal information about users that the Chinese official demand. In some cases such information has apparently been used to jail people who do not agree with some official Chinese policy - in other words, a political "crime". That is apparently the price of their doing business in China, but there are many who highly object on a moral basis and claim that if giving personal information is the cost of doing business in China, then the company should not operate there. >> At which point the people writing the browsers you have never >> heard off, and would so assume are incapable of anything, [quoted text clipped - 8 lines] > the standards and heavily fine or otherwise penalize browser > writers who violate them. That is fine so long as it cuts both ways and any web author who is caught excluding a browser because it identifies itself is subject to equivalent fines and penalties. Anything short of that and you are inviting a browser monopoly that would not be in the public interest. <snip> > .... I am only talking about enforcement of technical > standards. <snip> Aren't you the 'cwdjrxyz' who blew his credibility in alt.html by championing a content negotiation script that disregarded the mechanism laid out in the HTTP 1.1 specification and actually failed so badly that it would send XHTML to browsers that explicitly declared their rejection of it:- <news:1137381054.967347.74620@f14g2000cwb.googlegroups.com> I don't think I will have much regard for any assertions you may make in favour of technical standards until after I have seen some evidence that you follow them yourself. Richard. > >> At which point the people writing the browsers you have never > >> heard off, and would so assume are incapable of anything, [quoted text clipped - 30 lines] > favour of technical standards until after I have seen some evidence that > you follow them yourself. I do not see what bringing up an unrelated reference to another group has to do with this. You quote only one post in a very long thread. In summary I use a php include to force a browser to accept true xhtml 1.1 if it reports it will accept it at all in the header exchange. It is up to the browser maker to decide if they want to allow true xhtml using the mime type for xhtml+xml or not. If they do not allow it then my php include reverts to html 4.01 strict. If I did not do that, my pages would not work on IE6! Thus I do not send xhtml to browsers that do not indicate that they will accept it! In some cases the browser says it will accept either the mime type for true xhtml or the mime type for html. In some of these cases it says it prefers html. In that case I have found that the common browsers that will accept both html and true xhtml, but "prefer" html, work just fine if you force the xhtml path in the header exchange. My guess is that some browser makers specify that they prefer html just to be on the safe side. One should not confuse a "preference" for the browser with the code that can be used to indicate that preference in the header exchange, if a browser writer so wishes. In addition a few lesser used browsers do not indicate what they will accept in the header exchange, although they sometimes really will accept true xhtml just as well as well as html. Apple's Safari comes to mind here. In that case, I err on the safe side and use html 4.01 strict, because browser detection of some of these browsers is not safe because they can spoof another browser. I now have dozens of pages served as described above, and they all validate perfectly as xhtml 1.1 or html 4.01 strict at the W3C depending on what path is selected by the header exchange. Furthermore, the pages work properly for the xhtml 1.1 or html 4.01 strict path selected by the header exchange I use. You can see several such pages by going to http://www.cwdjr.info/media/playersRoot.php . [snipped quote] Seems that you still don't know how to trim quoted posts. >> Aren't you the 'cwdjrxyz' who blew his credibility in alt.html by >> championing a content negotiation script that disregarded the [quoted text clipped - 10 lines] > I do not see what bringing up an unrelated reference to another group > has to do with this. I think Richard made his point rather well: one cannot pontificate about enforcing standards unless one is willing to implement them oneself. > You quote only one post in a very long thread. Readers are welcome to view the rest of the thread, I'm sure; Google's archived it all. However, what other insight do you expect them to gain? It wasn't just me that told you that you were wrong, but that others did, too? > In summary I use a php include to force a browser to accept true > xhtml 1.1 Which you shouldn't. > if it reports it will accept it at all in the header exchange. That isn't the test you use at all. It's quite obvious from inspecting its behaviour that all you do is look for the mere mention of the string, application/xhtml+xml, as a substring of the Accept header value (and a substring match is patently wrong). You make no effort to parse the header whatsoever, and this is plain for all to see: <http://www.cwdjr.info/media/phpPage.txt> > It is up to the browser maker to decide if they want to allow true > xhtml using the mime type for xhtml+xml or not. Indeed, which is why quality values can be used to indicate not only preference for a certain media type, but an explicit rejection of it as well. If you had read and understood sections 14.1 and 3.9 in RFC 2616, you would know this. > If they do not allow it then my php include reverts to html 4.01 > strict. But it doesn't. If a browser explicitly states that it cannot accept XHTML, you'll serve it anyway. > If I did not do that, my pages would not work on IE6! You only send HTML to IE 6 because it doesn't include application/xhtml+xml in its Accept header value, not because your negotiation mechanism is written correctly. > Thus I do not send xhtml to browsers that do not indicate that they > will accept it! Repeating something false does not make it true. > In some cases the browser says it will accept either the mime type > for true xhtml or the mime type for html. In some of these cases it > says it prefers html. In that case I have found that the common > browsers that will accept both html and true xhtml, but "prefer" > html, work just fine if you force the xhtml path in the header > exchange. There would be little point in advertising the ability to process XHTML if in fact the user agent can't. However, that doesn't mean there isn't a reason to prefer another media type. > My guess is [...] Your guess is irrelevant. One does not incorrectly implement HTTP based on a guess. Though a rigid interpretation of quality values is not a requirement, it is strongly recommended and you are clearly in no position to override that recommendation. [snip] > You can see several such pages by going to > http://www.cwdjr.info/media/playersRoot.php . That isn't much there of which one should be proud. I see a useless document title, a broken and superfluous meta element, poor use of class attributes, badly chosen structural elements, and a very fetching uneven white border. Mike  SignatureMichael Winter Prefix subject with [News] before replying by e-mail. a lot. I find most of your discussion without merit, and consider it just another troll post. I am not going to waste my time on you again. Bye. >> <snip> >> > .... I am only talking about enforcement of technical [quoted text clipped - 15 lines] > I do not see what bringing up an unrelated reference to > another group has to do with this. It is a thread that demonstrates someone who is apparently keen to stress their championing of technical standards disregarding RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1), which just happens to be one of the most pivotal technical standards that exists for the Internet. I particularly enjoyed the point in the tread where Michael Winter proposed you actually read RFC 2616 and you declared (in considerable length) that you didn't take technical advice from people posting to Usenet and instead would get your advice through technical and computing journals. While everyone observing the conversation knew full well that if going through technical journals was a worthwhile practice at all it must inevitable lead you all the way back to RFC 2616, as that is the applicable technical standard for content negotiation. You had spent your residual credibility in the group by the end of that post. > You quote only one post in a very long thread. Anyone who cares will be able to reference the thread form any single message ID within it. > In summary I use a php include to force a browser to accept > true xhtml 1.1 if it reports it will accept it at all in the > header exchange. It was precisely the fact that you were not doing that, but instead serving XHTML to any UA that included the character sequence "application/xhtml+xml" in its Accept header, that was the reason for the criticism you received in that thread. Because, as anyone familiar with the technical standards for content negotiation, as laid out in RFC 2616, already knows, a UA may include the character sequence "application/xhtml+xml" in its Accept header in order to express its absolute rejection of the MIME type (and that is without even considering that it may include the sequence in a way that expresses a string preference for text/html or some other type). Content negotiation is the subject of formal technical specification and your simplistic efforts do completely disregard that specification, to the extent that your system is capable of doing the opposite of what it should do and serving XHTML to a UA that reports that it cannot accept it. > It is up to the browser maker to decide if they want to > allow true xhtml using the mime type for xhtml+xml or not. Yes, and their mechanism for doing that is providing an HTTP Accept header that conforms with RFC 2616's specification for an Accept header. And it is the responsibility of the person writing software to do content negotiation to interpret that Accept header in accordance with the technical specification, rather than making up their own rules based on superficial observations of few actual Accept headers. > If they do not allow it then my php include reverts to > html 4.01 strict. It can only do that if you are aware of what constitutes 'not allow' as laid down in RFC 2616. > If I did not do that, my pages would not work on IE6! Thus > I do not send xhtml to browsers that do not indicate that > they will accept it! But the consequence of your implementation was that you will also send XHTML to browser that do assert that they do 'not allow' it. That is poor, and it is in disregard for the applicable technical specification. > In some cases the browser says it will accept either the > mime type for true xhtml or the mime type for html. And it may express a preference for one or the other. For a while Opera expressed a preference for text/html, which was fair enough as their XHTML could not sensibly be scripted at the time, only rendered, so HTML was the better content type to accept. Your script would have pushed XHTML at it regardless because it had no conception of the specified mechanism for content negotiation. And for other browsers in the same situation your scrip is still delivering the inferior choice when it could send the superior. > In some of these cases it says it prefers html. In that case > I have found that the common browsers that will accept both > html and true xhtml, but "prefer" html, work just fine if you > force the xhtml path in the header exchange. Interworking specifications are not about what works in 'common browsers', they are about creating systems that deliver acceptable outcomes for everyone. after all you are the one proposing that UAs identify themselves so you can know the uncommon browsers when they show up, yet you are only acting to accommodate the 'common browsers' regardless of how well the uncommon browses conform to the applicable technical specification that you would rather disregard. > My guess is that some browser makers specify that they > prefer html just to be on the safe side. I think that Opera made their choice thinking that the user may prefer the option of functional scripts to broken ones. Browser manufactures may also think that the user may prefer progressive rendering to only having access to a page's contents once the page had fully loaded, or that a user may prefer the output of an old and well tested/debugged HTMP parser to a brand new, hardly tested and experimental XHTML parser. The browser manufacturers are in a good position to judge the relative acceptability of various content types in their browsers, and have a specified mechanism to express it in their Accept headers. It doesn't make sense to put that aside because superficial testing does not expose any manifestations. > One should not confuse a "preference" for the browser with > the code that can be used to indicate that preference in > the header exchange, if a browser writer so wishes. That doesn't make sense. > In addition a few > lesser used browsers do not indicate what they will accept in [quoted text clipped - 5 lines] > > I now have dozens of pages served as described above, And because you serve them without any regard for the RFC 2616 specified content negotiation mechanism any statement you may make about the 'enforcement of technical standards' will be hypocrisy. > and they all validate perfectly as xhtml 1.1 or html 4.01 strict > at the W3C depending on what path is selected by the header > exchange. Furthermore, the pages work properly for the xhtml 1.1 > or html 4.01 strict path selected by the header exchange I use. ... There is little point talking of a "header exchange" if the UAs are sending headers in accordance with RFC 2616 and you are interpreting them in accordance with superficial rules derived from a few observations and a lot of blanket assumptions. It is not an exchange, let alone negotiation, if you are not even talking the same language. Richard. a lot. I find most of your discussion without merit, and consider it just another troll post. I am not going to waste my time on you again. Bye. cwdjrxyz said the following on 4/14/2006 11:48 AM: > Bye. Promise? SignatureRandy comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ > [almost the same as in > news:1145029374.748968.111010@u72g2000cwu.googlegroups.com] Please do your practises in self-reflection elsewhere. Score adjusted PointedEars SignatureIf one person calls you a donkey, laugh at them; if several people do, who write quite reasonable articles most of the time, you better find yourself some green pastures to graze. -- saying in de.ALL (translated) Richard Cornford said the following on 4/14/2006 9:59 AM: <snip> >> You quote only one post in a very long thread. > > Anyone who cares will be able to reference the thread form any single > message ID within it. I read the entire thread based on that one reference and it was because I needed the laugh I got from reading it. I can now, safely, add cwdjrxyz to the people in the VK File. He was half way there but that thread finished it. SignatureRandy comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ > I can now, safely, add cwdjrxyz to the people in the VK File. VK File ? It sounds really scary. May you explain? > Of course you are right. So the international agency that assigns > browser IDs would have to have the ability to enforce the standards and > heavily fine or otherwise penalize browser writers who violate them. Wow! Like 10 year in jail for not supporting XHTML? :-) Form a W3C International Police Corp exempted from the national legislatures? "You browser doesn't support RegExp properly! On the wall, bastards!" :-) You you mean "technical" standards (like cryptography strength, proper UA string reporting etc.) then maybe... But I still tend to believe that it can be better handled on the particular country level. > That is apparently the price of their > doing business in China, but there are many who highly object on a > moral basis and claim that if giving personal information is the cost > of doing business in China, then the company should not operate there. I'm aware of China - search engines story and finding it very sad. But it is OT of UA's features. It was made by IP tracking - which is a core feature of WWW used by governments even in many countries against of their own citizens. Think of Carnivore (USA), SORM2 (Russia), some very interesting organizations acting under EUCD in EU. > Don't all browsers have a bug that other browsers do not have? But > most significant bugs can be tested for without browser detection. If > you think otherwise you are welcome to suggest a concrete example and > see if it can't be feature detected. I'm curious to know if there is a way to feature-detect the need for an "iframe shim" behind a DIV. In IE on windows, as I'm sure you know, select lists and other controls always render on top of other elements, regardless of z-index values. This is commonly solved by placing an empty iframe behind the element, which effectively blocks the control from showing through. This problem only applies to IE on Windows. While there doesn't seem to be any problem with adding the iframe for other browsers, it would ideally not be done if not necessary. What feature-detection could be used to determine the need for the iframe shim? It would be possible to feature-detect other things that are known to exist only in IE on Windows, but it's generally not a good practice to infer feature X based on the existence of feature Y. Thoughts? SignatureMatt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com > What feature-detection could be used to determine the need for the iframe > shim? IE-specific "specifics" usually solved by using JScript pre-processor: ... /*@cc_on @*/ /*@if (@_jscript) var fixNeeded = true; @else @*/ var fixNeeded = false; /*@end @*/ It is possible to imagine that some UA producer will implement exactly the same pre-processor and instruct it to tell that it is Internet Explorer running JScript. It is possible - but this already goes beyond the power of any developer - and beyond any acceptable behavior. And "semantically" :-) it is not a "yaky UA sniffing". I do not sniff anything: I just place a piece of code and let it to be executed by any UA capable to handle it (ignored otherwise). With SVG programming I still need more UA sniffing because Opera and Gecko SVG implementations are too different in some important aspects to treat them equally. Here the biggest challenge was from Opera: this browser became really determined to be undetectable out of IE. As soon as some feature check was found, they cover it by a bogus "cork" in the next upgrade. I really was running out of ideas until I found windows.opera object (where they keep their a la GreaseMonkey functions). The only thing bothers me now in my nightmares :-) that if some new wannabe bastard desides to pretend to be Opera rather than IE or Gecko. I tranquilize myself by thinking that it's highly doubtful - though yet possible. >> What feature-detection could be used to determine the need for the >> iframe shim? > IE-specific "specifics" usually solved by using JScript pre-processor: That is not feature-detection. > /*@cc_on @*/ > /*@if (@_jscript) > var fixNeeded = true; > @else @*/ > var fixNeeded = false; > /*@end @*/ Further, this doesn't check for Windows vs. Mac, since the problem doesn't occur on Mac. SignatureMatt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com > >> What feature-detection could be used to determine the need for the > >> iframe shim? [quoted text clipped - 11 lines] > Further, this doesn't check for Windows vs. Mac, since the problem doesn't > occur on Mac. Oh, you need Mac check too? Here we are: /*@cc_on @*/ /*@if (!@_mac) var fixNeeded = true; @else @*/ var fixNeeded = false; /*@end @*/ Alternatively: /*@cc_on @*/ /*@if (@_win32) var fixNeeded = true; @else @*/ var fixNeeded = false; /*@end @*/ (I guess it is secure to disregard a possibility of Windows 3.x ;-) You need JScript.Net check maybe? /*@cc_on @*/ /*@if (@_jscript_version >= 7) var lang = 'JScript.Net'; @elif (@_jscript_version < 7) var lang = 'JScript'; @else @*/ var lang = 'JavaScript'; /*@end @*/ To not run over and over :-) here are all conditions you can check: @_win32 True if running on a Win32 system. @_win16 True if running on a Win16 system. @_mac True if running on an Apple Macintosh system. @_alpha True if running on a DEC Alpha processor. @_x86 True if running on an Intel processor. @_mc680x0 True if running on a Motorola 680x0 processor. @_PowerPC True if running on a Motorola PowerPC processor. @_jscript Always true. @_jscript_build Contains the build number of the JScript scripting engine. @_jscript_version Contains the JScript version number in major.minor format. Enjoy! > I really was running out of ideas until I found > windows.opera object (where they keep their a la GreaseMonkey > functions). The user.js-functions are new, but I believe window.opera has been in Opera since the earliest Javascript capable Opera browsers. > The only thing bothers me now in my nightmares :-) that if > some new wannabe bastard desides to pretend to be Opera rather than IE > or Gecko. I tranquilize myself by thinking that it's highly doubtful - > though yet possible. The reason browsers try to look like other browsers is to twart annoying programmers that refuse to let pages work on them, even though they implement all the features that are needed. As long as programmers use browser detection as a white-list of browsers that are allowed to work on their page, browser makes will try to prevent their browser from being excluded (usually for no good reason). If the programmers used feature detection instead, then they won't need to know what browser it is, only what features are available. A completely new but feature complete browser would work with old pages then. Using browser detection as a white-list, it would be unnecessarily excluded. /L SignatureLasse Reichstein Nielsen - lrn@hotpop.com DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html> 'Faith without judgement merely degrades the spirit divine.' > I wandering about the common proctice of some UA's producers to spoof > the UA string to pretend to be another browser (most often IE). [quoted text clipped - 6 lines] > > Is it some different situation with the current spoofing? From a technical (and probably a realistic) standpoint, it probably isn't really relevant. Especially considering that the greatest impact UA spoofing has is to raise the statistical % usage of IE - and I'm sure Microsoft isn't too concerned about that. From a theoretical legal standpoint, you're probably right. > I wandering about the common proctice of some UA's producers to spoof > the UA string to pretend to be another browser (most often IE). Is it common? How many browsers, by default, spoof others? > Shouldn't it be considered as a trademark violation of the relevant > name owner? On the face of it, yes. However, whether it could be held to be so in a court is quite another matter. I am not a lawyer, but as anyone with a business that sells products it designs and makes itself, I have an interest in knowing about trademark and copyright law as applicable in my own jurisdiction. In regard to trademark, the primary question is whether its use will confuse consumers into thinking a product is from one company when in fact is is from another. A case in point is Apple Corps and Apple Computer, though there are aspects of that case related to the logo also. The second issue is the damages that might arise - loss of sales because consumers bought the 'wrong' product, leveraging another company's good will, loss of reputation because the second company's faulty products reflected on the first, and so on. In regard to user agent spoofing, I don't think any of the above can be shown. Consumers don't identify browsers by looking at the UA string, so it can't be a factor in their decision of which browser to use. If you can't prove that, end of case. A more tenuous link could be shown if certain user agent strings were required to make sites work properly (the original reason for doing it). It might then be shown that this has some effect on consumer choice, but the obvious conclusion here is inappropriate discrimination by the site. The UA has the defence of acting as it did to overcome that discrimination. To go further and try to link it back to trademark violation is a very long bow to draw. > Is it some different situation with the current spoofing? Yes, because the UA string is not a factor in consumer choice of which browser to use. SignatureRob >> I wandering about the common proctice of some UA's producers to spoof >> the UA string to pretend to be another browser (most often IE). > > Is it common? How many browsers, by default, spoof others? Almost all other than Netscape 2-4. IE6's user-agent string (on my computer) is: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50215) The initial Mozilla/4.0 is a spoof of Netscape 4. The remaining data can be used to discover that it actually isn't Netscape 4 by servers that know what to look for, while those that don't know will be spoofed. Most people have forgotten that this is how, and where, spoofing started :) FireFox's is: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 It claims to be Mozilla/5.0, which it isn't. It's perhaps acceptable, since it's in the general family of browsers reporting that name. I don't remember what Opera's default is any more. It used to be an IE-spoof. Mine is set to report as Opera, and I only very rarely have problems with that (I still spoof for MSDN) (And, also IANAL, I agree on the arguments against it being trademark violation) /L SignatureLasse Reichstein Nielsen - lrn@hotpop.com DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html> 'Faith without judgement merely degrades the spirit divine.' > I don't remember what Opera's default is any more. It used to be an > IE-spoof. The latest Opera 8.54 default is Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; en) Opera 8.54 (with different OS and language of course for different users) I presume it currently holds the record of spoofing :-) by claiming three browsers at once. At least they mention the real one now (Opera) too but AFAIK it is a rather recent improvement. > (And, also IANAL, I agree on the arguments against it being trademark > violation) It claims to be able to handle the content which it cannot handle: say it cannot draw VML graphics, initialize ActiveX objects and use behaviors. I understand that it is always possible to serve some generic all-in-one script to sniff the real situation client-side and act accordingly. But since when server-side content preparation became an illegal technique? It is very often that the requested page doesn't exists at all - but being prepared out of raw data per call. > > I don't remember what Opera's default is any more. It used to be an > > IE-spoof. [quoted text clipped - 17 lines] > an illegal technique? It is very often that the requested page doesn't > exists at all - but being prepared out of raw data per call. Opera is quite unique in many ways in addition to spoofing user agents. So far as I know, it does not use actual ActiveX (unless you add unofficial plugins that float around from time to time), and Opera has been very anti-ActiveX, at least in the past. Yet, for the last few upgrades, Opera will run the WMP9 and 10 media player if you use only a Microsoft ActiveX object to code for the media playing. I have no idea what Opera is doing to get this to work - hopefully someone knows. Of course there have been ActiveX plugins for the WMP only for Netscape, Mozilla and Firefox in the past, but you had to download them, and the mentioned browser writers tended to discourage this. The reason for an ActiveX plugin for the WMP is that some only write for IE using an ActiveX object and do not bother to write a path for most other browsers that do not come with ActiveX. Since I work with quite a bit of media, I have noted something else interesting at the server of my host. You of course get records of the user agent for visiting browsers. However these days you often get a record of the visit of a player, such as the WMP, Real, etc. Actually some of the modern media players are now running about 3 times the byte size of a small browser such as Opera or Firefox. Part of this complexity is due to inclusion of new features for selling and protecting media. > The latest Opera 8.54 default is > Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; en) Opera 8.54 > (with different OS and language of course for different users) > I presume it currently holds the record of spoofing :-) by claiming > three browsers at once. At least they mention the real one now (Opera) > too but AFAIK it is a rather recent improvement. I don't think so ... but let me check. Yep, Opera 3.62 reports: Mozilla/4.0 (Windows NT 5.1;US) Opera 3.62 [en] i.e., spoofing Netscape 4 to the uninitated, but revealing itself to be Opera to those who knows that it exists. > It claims to be able to handle the content which it cannot handle: say > it cannot draw VML graphics, initialize ActiveX objects and use > behaviors. My IE can't initialize most ActiveX objects either. Still, that should be handled by content negotiation, not feature inference from the user-agent string. It wouldn't have been spoofed to begin with, if people hadn't abused it. > I understand that it is always possible to serve some generic > all-in-one script to sniff the real situation client-side and act > accordingly. But since when server-side content preparation became > an illegal technique? It never was ... but people refusing to serve content to a browser that can understand it, just because they don't recognize its name, have made the bed they now lie in (if that's an idiom in English). /L SignatureLasse Reichstein Nielsen - lrn@hotpop.com DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html> 'Faith without judgement merely degrades the spirit divine.' > It never was ... but people refusing to serve content to a browser > that can understand it, just because they don't recognize its name, > have made the bed they now lie in (if that's an idiom in English). You've made the bad you sleep in it. :-) Point taken. > > The latest Opera 8.54 default is > > Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; en) Opera 8.54 [quoted text clipped - 9 lines] > i.e., spoofing Netscape 4 to the uninitated, but revealing itself to be > Opera to those who knows that it exists. I dug up several properties for Opera 7.21 from 2003 from some of my backups. In case anyone needs the information for several other current browsers in 2003, I can provide that also. The information was obtained on a Windows XP OS. ______________________________________________________________________ Opera 7.21 appCodeName=Mozilla appMinorVersion= appName=Microsoft Internet Explorer appVersion=4.0 (compatible; MSIE 6.0; Windows NT 5.1) userAgent=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.21 [en] vendor - NN6 up only=undefined vendorSub - NN6 up only=undefined document.all object support=true getElementById object support=true java support=true Height=768 Width=1024 Available Height=738 Available Width=1024 Color Depth=32 bit innerWidth=1022 innerHeight=584 clientHeight=584 clientWidth=1022 language for NN & Opera=en language for IE & relatives=en IE4 browser language or IE5 up op. sys.lang=en Presistent cookies enabled?=true CPU Class(IE4+)=undefined On Line(IE4+)?=undefined Operating System(NN6+)=undefined Platform=Win32 Product Name(NN6+)=undefined Product Version(NN6+)=undefined Operating System Language(IE4+)=undefined User Profile(IE3+)=undefined document.body.clientWidth object support=true document.body.clientHeight object support=true document.body object support=true window.innerHeight object support=true _____________________________________________________________________ >>> I wandering about the common proctice of some UA's producers to spoof >>> the UA string to pretend to be another browser (most often IE). [quoted text clipped - 15 lines] > It claims to be Mozilla/5.0, which it isn't. It's perhaps acceptable, since > it's in the general family of browsers reporting that name. Safari on PowerPC is: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/XX (KHTML, like Gecko) Safari/YY And on Intel: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/XX (KHTML, like Gecko) Safari/YY <URL:http://developer.apple.com/internet/safari/faq.html#anchor2> where XX and YY are appropriate version numbers. With the debug menu enabled, it takes a second to change it to any of a number of strings, including Netscape 4, 6, 7, IE 5 Mac, IE 6 Windows, even Konqueror 3. There is still one site that, when I log in, reports: "This site is not optimised for Netscape 6. We recommend you use Microsoft Internet Explorer Version 6.0 or Netscape 4.77 or 4.78." I ignore the warning and everything works as expected. Stumbled across this site that appears to have a fairly exhaustive list of UA strings: <URL:http://www.pgts.com.au/pgtsj/pgtsj0208c.html> SignatureRob > Safari on PowerPC is: > > Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/XX (KHTML, like > Gecko) Safari/YY Wow! Opera is moved on the second place in the spoofing context. Mozilla KDE Gecko Safari I just love this part: "like Gecko" - what a hell does it suppose to mean? Almost but no sigars? That sustains my old idea that some UA strings are being prepared under sever toxic influence. Now if would be cool to see the Konqueror string. To become the winner it should be now something like "(KHTML, like Safari) close to Gecko almost MSIE". :-) >> Safari on PowerPC is: >> >> Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/XX (KHTML, like >> Gecko) Safari/YY > I just love this part: "like Gecko" - what a hell does it suppose to > mean? Almost but no sigars? Most likely that some induhviduals out there are checking for the occurence of the string "Gecko" in the user-agent string before allowing browser to use their site. An again they got what they asked for. > That sustains my old idea that some UA strings are being prepared > under sever toxic influence. Hardly. There's a logic to it, although a quite twisted one. It's cops an robbers - every time someone tries to use the user-agent string inappropriately, the browser makers change it so that their browser still matches. /L SignatureLasse Reichstein Nielsen - lrn@hotpop.com DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html> 'Faith without judgement merely degrades the spirit divine.' > >> Safari on PowerPC is: > >> [quoted text clipped - 3 lines] > > I just love this part: "like Gecko" - what a hell does it suppose to > > mean? Almost but no sigars? After rethinking I agree with you that it is not stupid: I also think that it is exact on the topic of this thread. This is the same as say <http://www.microsoft.com> - try to use it for anything but Microsoft, Inc. But just add "my" and it becomes your private business right away: <http://www.mymicrosoft.com> <http://www.coca-cola.com> -no way; <http://www.my-coca-cola.com> - my way. AppleWebKit/XX (KHTML, Gecko) - too dangerous AppleWebKit/XX (KHTML, like Gecko) - so sue me "like Gecko", "almost Firefox", even "not MSIE". Stincky- but so far legally secure I guess. > Hardly. There's a logic to it, although a quite twisted one. It's > cops an robbers - every time someone tries to use the user-agent > string inappropriately, the browser makers change it so that their > browser still matches. I would go for this logic if new browsers would be *exact* functional equivalents of UA's they are spoofing. I mean they can have better usability and as many extra features as they want: but the functionality of the spoofed browser must be implemented in full and in all details. But it is not this way: so far mostly these are narrowed implementations with a set of their particular bugs and rendering twists. Yet they want to be served by the same server-side content prepared for much more capable UA: and if they chock on it (no surprise) they propose to "Report brocken site". I may be biased but something is wrong with this picture. VK said the following on 4/16/2006 4:27 PM: Your quoting is incorrect, RobG nor you wrote the below, Lasse did. >> Hardly. There's a logic to it, although a quite twisted one. It's >> cops an robbers - every time someone tries to use the user-agent [quoted text clipped - 3 lines] > I would go for this logic if new browsers would be *exact* functional > equivalents of UA's they are spoofing. Stop trying to determine the UA and start testing for features and that becomes a moot point, as any and all arguments about the validity of UA strings are. SignatureRandy comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ > I would go for this logic if new browsers would be *exact* functional > equivalents of UA's they are spoofing. I mean they can have better > usability and as many extra features as they want: but the > functionality of the spoofed browser must be implemented in full and in > all details. If most pages required that, I could accept it as a requirement. But pages that exclude browsers by browser detection are usually created by people with less than perfect grasp of browser scripting. They are likely to just use the same few features that everybody else on the web are using, and that new browsers do support. Think as a browser creator: If 100 pages exclude your browser, you would rather spoof a browser that they include and have 90 of them work perfectly and 10 of them break while running. It's better service for your users (90 more pages that work), and users of non-IE browsers are likely to, rightly, blame the page writer for errors anyway. > But it is not this way: so far mostly these are narrowed > implementations with a set of their particular bugs and rendering > twists. Why should they be any different from the existing browsers (except that they actually support the core W3C standards, unlike IE). Everything on top of that is bonus features which should only be used after detecting the feature, not just the browser. > Yet they want to be served by the same server-side content > prepared for much more capable UA: and if they chock on it (no > surprise) they propose to "Report brocken site". I may be biased but > something is wrong with this picture. If you take Opera as an example, they always identify themselves as Opera. Any page that still fails must be unaware of, or deliberatly ignoring, that their page doesn't work. Reporting the page as broken allows Opera Software to test if the page fails due to a bug in the browser or due to being badly written. If the latter, they can contact the site owner and report it (along with the message that at least on Opera user wanted to use their site and couldn't). /L SignatureLasse Reichstein Nielsen - lrn@hotpop.com DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html> 'Faith without judgement merely degrades the spirit divine.' Ref. Should UA string spoofing be treated as a trademark violation? As a support for my point of view expressed in this thread, where Opera was mentioned among the most "nasty offenders". Either they read this and agreed on it, or they came to the same conclusion independently, but: <http://www.opera.com/docs/changelogs/windows/900b1/> (freshly listed on opera.com): Changelog : HTTP ... Changed default UserAgent string to identify as Opera. ... P.S. Now it's time to take care of Safari and Konqueror ;-) VK said the following on 4/22/2006 8:52 AM: > Ref. Should UA string spoofing be treated as a trademark violation? > > As a support for my point of view expressed in this thread, where Opera > was mentioned among the most "nasty offenders". Either they read this > and agreed on it, or they came to the same conclusion independently, > but: You can rest assured they didn't change it based on this thread. > <http://www.opera.com/docs/changelogs/windows/900b1/> (freshly listed > on opera.com): [quoted text clipped - 5 lines] > > P.S. Now it's time to take care of Safari and Konqueror ;-) No, it's time to stop browser detecting, object detecting instead, and then it is a moot issue *what* the UA string says. SignatureRandy comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ > No, it's time to stop browser detecting, object detecting instead, and > then it is a moot issue *what* the UA string says. I raised a point in this thread to answer Richard's request for examples of cases where browser sniffing would ever be needed. No one replied. I think there are cases where browser sniffing is justified, even if not completely accurate. I'd like to be proven wrong ;) SignatureMatt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com > > No, it's time to stop browser detecting, object detecting instead, and > > then it is a moot issue *what* the UA string says. [quoted text clipped - 3 lines] > there are cases where browser sniffing is justified, even if not completely > accurate. I'd like to be proven wrong ;) I gave you some already. And for IFRAME also if you want to cover that AOL Browser without conditional comments support. But it is just a play-bye. What about XSLT documents? For browsers (Firefox, Camino, Opera 9.0a or higher, Safari 2.1 or higher, IE 6 or higher) I want to serve normal .xml data for client-side transformation. For sub-standard crap it is needed to say at least some condolensences - in HTML. Or even someone got shifted on the XHTML basis: wouldn't it be nice to serve to XHTML happily unaware browsers "text/html" instead of "application/xtml+xml" ? There are other cases (how many do you need? :-) >> No, it's time to stop browser detecting, object detecting >> instead, and then it is a moot issue *what* the UA string [quoted text clipped - 3 lines] > for examples of cases where browser sniffing would ever be > needed. No one replied. Probably in part because we have discussed the subject before and your re-raising the same question implies that you were not interested in the responses you got last time:- 1. As the issue applies to all Windows browsers that employ the native Windows select GUI component to represent HTML select elements the problem has nothing to do with IE as such but instead determining whether the particular UA is using that component. Which may be detectable in some environments as that component is notorious for not accepting particular CSS assignments and its refusal to accept them may have manifestations in the DOM. 2. It is only worth considering not using the IFRAME even when it is not necessary if its use is harmful, and branching in the creation of the IFRAME also means having two sets of, for example, positioning code. It may be simpler to just employ the IFRAME anyway. And having done that you will have a generally available hidden IFRAME on hand for doing asynchronous background loading; see it as an opportunity rather than a problem. 3. The IFRAME shim is not the only technique for handling the burn through issue. > I think there are cases where browser sniffing is justified, > even if not completely accurate. I'd like to be proven wrong ;) Trying to justify something that doesn't work (to the extent of being catastrophically wrong in worst cases) is hardly a reasonable response to finding that the more reliable alternative cannot cover 100% of cases. Richard. > Probably in part because we have discussed the subject before and your > re-raising the same question implies that you were not interested in > the responses you got last time:- I've not seen previous replies on the topic. > 1. As the issue applies to all Windows browsers that employ the native > Windows select GUI component to represent HTML select elements I'm not sure that is true. A browser could easily be written in Windows using native controls which do not overlap other objects in the page. It is merely a side-effect of bad programming in IE that is at fault. > the > problem has nothing to do with IE as such but instead determining > whether the particular UA is using that component. I believe that is a false statement. > Which may be > detectable in some environments as that component is notorious for not > accepting particular CSS assignments and its refusal to accept them > may have manifestations in the DOM. But that is a case where you are testing one feature and then inferring another. > 2. It is only worth considering not using the IFRAME even when it is > not necessary if its use is harmful It cannot be assumed that there is no browser where using the iframe would be a problem, but it would probably be a safe assumption AFAIK. > 3. The IFRAME shim is not the only technique for handling the burn > through issue. True, but it seems to be the best, IMO. >> I think there are cases where browser sniffing is justified, >> even if not completely accurate. I'd like to be proven wrong ;) > Trying to justify something that doesn't work (to the extent of being > catastrophically wrong in worst cases) is hardly a reasonable response > to finding that the more reliable alternative cannot cover 100% of > cases. I'm talking only about the cases which cannot be covered by the more reliable alternative. SignatureMatt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com > I'm not sure that is true. A browser could easily be written in Windows > using native controls which do not overlap other objects in the page. It is > merely a side-effect of bad programming in IE that is at fault. "Super Z of form elements" (now called "firing through" I guess) is an age old problem first introduced with DHTML itself. It was common for both NN 4.x and IE 4.x. Later fixed in IE 5.2, reintroduced in IE 5.5, fixed, reintroduced - so the same version line might have it or not depending on the minor version. The core issue here is that systemwise form elements (in Windows at least) are not parts of the page graphics context. They are graphics peers painted separately atop of the page context and anchored to the indicated page points. The closest analogy would be a transparent touch screen with form elements painted and placed atop of your monitor screen. One can reveal this "hidden misery" by making a big element reach form and scrolling it on a slow machine. You'll see form elements being late from the page content itself (labels, text, graphics etc.) and then "jumping" all together to the new position. Thus in order to let a page content to be atop of a form element, the only way is to "place another touch screen atop of the existing one". Until DirectX got mature it was simply impossible - and even now it is a tricky task. Personally I hate Super Z issue, and it was a headache since 1998 for everyone. And I really thing that in so many years IE should switch long ago on build-in DHTML widgets instead of torturing the legacy peers with DirectX. But I may not know all issues. VK said the following on 4/24/2006 5:03 AM: >> I'm not sure that is true. A browser could easily be written in Windows >> using native controls which do not overlap other objects in the page. It is [quoted text clipped - 5 lines] > fixed, reintroduced - so the same version line might have it or not > depending on the minor version. "Super Z"? Are you trying to create new terms? The problem comes when you try to do something that the browser does differently and you start trying to change the default behavior. SignatureRandy comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ > "Super Z"? Are you trying to create new terms? No, just using the old one (as I mentioned). But if one likes "firing through" better then it's totally fine - it is descriptive enough. >> "Super Z"? Are you trying to create new terms? > No, just using the old one (as I mentioned). But if one likes "firing > through" better then it's totally fine - it is descriptive enough. I've never heard of either term. We must run in different circles. SignatureMatt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com Matt Kruse said the following on 4/24/2006 1:19 PM: >>> "Super Z"? Are you trying to create new terms? >> No, just using the old one (as I mentioned). But if one likes "firing >> through" better then it's totally fine - it is descriptive enough. > > I've never heard of either term. We must run in different circles. VK's circle is square though :) SignatureRandy comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ > Matt Kruse said the following on 4/24/2006 1:19 PM: > >>> "Super Z"? Are you trying to create new terms? [quoted text clipped - 4 lines] > > VK's circle is square though :) Guys, you may call it even "foobar effect" if you like. As no name of Array is involved here, I'm very relaxed :-) firing through, firing through, firing through... OK, I'll remember now. Doesn't change the reason of this graphics glitch though - nor its presence in some environments. VK said the following on 4/24/2006 2:38 PM: >> Matt Kruse said the following on 4/24/2006 1:19 PM: >>>>> "Super Z"? Are you trying to create new terms? [quoted text clipped - 10 lines] > now. Doesn't change the reason of this graphics glitch though - nor its > presence in some environments. Who said it was a "glitch" though? It works/behaves exactly like it was intended to do. It may be undesirable effects but it's not a glitch :) SignatureRandy comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ > Who said it was a "glitch" though? It works/behaves exactly like it was > intended to do. It may be undesirable effects but it's not a glitch :) So then there are no design bugs/glitches? Only implementation problems get those labels? ;-) Kevin N. > firing through, firing through, firing through... OK, I'll remember > now. ... despite it is kind of misleading for the effect nature: it implies that your DHTML *is* on the top but a nasty form element is firing through it. Technically it is just opposite: form elements are always on the very top, on its own rendering layer, and your DHTML is sliding below it. This is why even z-index:1000 doesn't help - because it's still z-index of the page's rendering layer. The only way is to add the 3rd rendering layer atop of both and do stuff there (window, iframe). So the older term is better IMHO. firing through, firing through, firing through... I remember. >> Probably in part because we have discussed the subject >> before and your re-raising the same question implies >> that you were not interested in the responses you got >> last time:- > > I've not seen previous replies on the topic. They were responses to a post of yours. >> 1. As the issue applies to all Windows browsers that employ >> the native Windows select GUI component to represent HTML >> select elements > > I'm not sure that is true. As you wish. <snip> >> the problem has nothing to do with IE as such but instead >> determining whether the particular UA is using that component. > > I believe that is a false statement. If you say so. >> Which may be detectable in some environments as that component >> is notorious for not accepting particular CSS assignments and >> its refusal to accept them may have manifestations in the DOM. > > But that is a case where you are testing one feature and then > inferring another. The principle that you test as close to the issue as possible stands, even if it is not always possible to test a feature that has a genuine one-to-one relationship with the issue. Still, I doublet that a viable test would be found. >> 2. It is only worth considering not using the IFRAME even >> when it is not necessary if its use is harmful > > It cannot be assumed that there is no browser where using the > iframe would be a problem, but it would probably be a safe > assumption AFAIK. I am certain that, for example, Opera 6 would have a problem with positioned IFRAMES, but I doubt that Opera 6's limited dynamic capabilities would pass testing for other required features. However, the technique is better suited to Intranet and specific web applications that the public Internet so I don't really see that as an issue. >> 3. The IFRAME shim is not the only technique for handling >> the burn through issue. > > True, but it seems to be the best, IMO. It is the simplest (much less need to be interested in determining exact positions and sizes), but it is the appeal of simplicity that encourages me to use the IFRAME anyway as that makes the creation and positioning code simpler as well. >>> I think there are cases where browser sniffing is justified, >>> even if not completely accurate. I'd like to be proven wrong ;) [quoted text clipped - 5 lines] > I'm talking only about the cases which cannot be covered by the > more reliable alternative. When considering alternatives I tend to consider how wrong an alternative that has the potential to be wrong is capable of being. Browser detection on the public Internet is capable of being utterly wrong, even to the extent of being catastrophically wrong and making the script itself the barrier to a site being useable to a visitor. BrowserHawk, as mentioned in a recent thread is an excellent example; it Identifiers my IE 6 as Opera running on an unknown operating system and then spits out a series of script errors and grinds to a halt. It is the direct result of its authors assuming the truth of a fundamentally false premise and so not thinking about the consequences of being wrong, and because of the script errors the failure of their code is never obvious because it never gets to report back. (and of course VK was the only person willing to admit to using it, as damming a condemnation of a strategy as anyone would need.) Richard. >>> 1. As the issue applies to all Windows browsers that employ >>> the native Windows select GUI component to represent HTML >>> select elements >> I'm not sure that is true. > As you wish. Not as I wish, just reality ;) >> I'm talking only about the cases which cannot be covered by the >> more reliable alternative. [quoted text clipped - 3 lines] > wrong, even to the extent of being catastrophically wrong and making > the script itself the barrier to a site being useable to a visitor. True. But it can also be used to fix small errors and quirks which will not have a negative impact on any functionality for any mis-identified user, but will make the style or functionality better for those who are correctly identified. > BrowserHawk, as mentioned in a recent thread is an excellent example; Something along the same lines that should be mentioned is ASP.NET from Microsoft. I don't work with it, but my exposure to it leads me to believe that it does extensive browser-capability "detection" based on the user agent header and serves various levels of rich content as a result. I got into an argument with a .NET developer when I said that this was surely a flawed way to determine what content to serve. His response was along the lines of "Microsoft is the software giant and surely employees more experts in these fields than anyone you know. Don't you think they would know the best way to do it? We've built .NET apps before and we've never had a single complaint." It's hard to argue against cases like this, where a huge software company uses the "wrong approach" yet does it with overwhelming success for the vast majority of users. SignatureMatt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com >>>> 1. As the issue applies to all Windows browsers that >>>> employ the native Windows select GUI component to [quoted text clipped - 3 lines] > > Not as I wish, just reality ;) So you are saying that form controls did not burn through on, for example, Windows Netscape 4 and Opera <= 6? That the issue only ever applied to versions of IE browsers and browsers that embed IE? >>> I'm talking only about the cases which cannot be covered >>> by the more reliable alternative. [quoted text clipped - 9 lines] > any mis-identified user, but will make the style or functionality > better for those who are correctly identified. No, the extent to which your 'small error or quirks' are problems is the extent to which applying a 'fix' to a browser miss-identified as one needing a fix is likely to case a problem. >> BrowserHawk, as mentioned in a recent thread is an excellent >> example; [quoted text clipped - 4 lines] > "detection" based on the user agent header and serves various > levels of rich content as a result. Yes, it seems perverse that the company that suffered from misguided browser detection to the extent that they were forced to introduce UA string spoofing in order to get a foothold in the market should then go on to formalise that bad practice in their own framework. Especially as the consequence of their actions was the change in the specification of a UA header from HTTP 1.0 to 1.1, where the latter defines a UA header as little more than any arbitrary sequence of ASCII characters of indefinite length; so not a source of information at all. > I got into an argument with a .NET developer when I said > that this was surely a flawed way to determine what content > to serve. His response was along the lines of "Microsoft is > the software giant and surely employees more experts in these > fields than anyone you know. Don't you think they would know > the best way to do it? .NET developers; charmingly naive ;-) > We've built .NET apps before and we've > never had a single complaint." I like this "it must be OK because nobody ever complains" attitude. Jim is right, web related QA is generally abysmal. One of my favourite stories to date was an individual who vigorously protested that pop-up blocking was not a real issue on the internet because he had never received a single complaint about his site not working because of a pop-up blocker, but when you looked at his site the feed-back form was presented in a javascript dependent pop-up window. But who is going to complain anyway; if a web site is so broken that you cannot buy something on it you go to the next, and the same goes when looking for information. As you know I sometimes purchase buy computer parts, and in February a UK web-retailer of computer parts missed the opportunity of taking a couple of thousand pounds off me because they have a shopping cart that makes invalid assumptions about the IE browser I was using (in this case that it would run ActiveX). Presumably they think that their (I assume .NET because of the .aspx extensions) code works, and I was not going to tell them otherwise, just move on to the next site. It is much easier for a web developer to crate a site that receives no complaints than to create a site that doesn't warrant any. > It's hard to argue against cases like this, I don't know, you could point out that there is no formal basis for the assumption that the UA header is a source of information, that in practice many are completely indistinguishable, that even the distinguishable ones are amenable to user modification, etc. You could go on to point out that Microsoft clearly does not employ competent web developers, else MSDN would not kick out so many "parentElement.parentElement is null or not an object" errors on IE6 (Microsoft developers who cannot even cope with IE specific code running on a default installation of IE6 are hardly to be regarded as competent). And, of course that if Microsoft never made mistakes in their web related development we would not have seen a procession of security fixes and service packs for IE. > where a huge software company uses the "wrong approach" > yet does it with overwhelming success for the vast > majority of users. But we both know that you cannot accurately quantify those numbers over HTTP, that 'overwhelming' and 'vast' are convenient opinions that cannot be substantiated (except to the extremely gullible). My question is who is making these business decisions; did the business managers really say that it was OK to design out the potential for 5-20% of the resulting turnover because the web developers wanted to make decisions based on an assumption that has no formal technical basis? I don't think |
Enable EMail Alerts
Start New Thread
Reply to this Message