Features Download
From: David J Mark <staff <at> cinsoft.net>
Subject: Re: IE8 compatibility mode and dijit.sniff
Newsgroups: gmane.comp.web.dojo.devel
Date: Saturday 10th October 2009 19:43:10 UTC (over 8 years ago)
Hash: SHA1

If everyone will step up with their favorite browser detection issues,
we can get through this pretty quickly.  :)

Most (but not quite all) of the answers to the scripting side are in the
branch.  Most of what is not there can be found in a script I published
called My Library (and will be copied over to Dojo when I have the
time).  Flash comes to mind.  It's out of print, so let me know if you
want a copy.

As for the CSS, as mentioned, the first step is to go through the themes
and remove all of these classes named after browsers.  Then run the unit
tests.  Then address the problems directly, one at a time.  You can
still use classes on the HTML element, just don't name them after
browsers (e.g. bodyisroot for the various viewport issues).

Yes, without design changes, there will be a couple that require
(multiple) object inferences (much better than sniffing the UA string).
They are always IE-related in my experience. For example, when to use
IFrame shims.  I wouldn't normally use such things at all, but for a
general-purpose dialog widget that must hover over any document in IE6,
there's no choice.  And it may not be deemed desirable to use
conditional comments in a framework, but then we are asking for multiple
includes for each widget anyway.  ;)

And I really think it would be better to advise newcomers about the
dangers of quirks mode, rather than enabling them to sort of use it
(nothing is really guaranteed in quirks mode, except the preservation of
bugs in previous versions).  Same goes for invalid markup:


That's the standard CLJ response for invalid examples.  I would distill
the useful information and put it in the docs.  :)

As for the extra attributes in Dijit examples, those are less worrisome
(never heard of a browser that wouldn't discard unknown attributes), but
they make catching *other* validation errors extremely difficult.  By
the same token, failure to run check-ins through JSLint (or the like)
makes it hard to spot typos, implied globals, etc.


David J Mark wrote:
> Jared Jurkiewicz wrote:
>> That's along the lines of my questions/concerns too on this.  I think
>> it's a great idea if we can get away from browser sniffing, but to be
>> honest I don't know how to detect the 'feature' that say, IE does
>> something strange/wrong with CSS or other rendering issues.
>> For example:
>> IE6:
>> This was a problem in the Grid.   The grid builds rows with a sort
>> direction icon.   The icon is constructed as a tag on the 'left' but
>> floated right.  It also has padding.  On IE6, and IE6 alone (7, 8 are
>> fine), the img was floated fine, but the padding was not.  So when the
>> icon is added, you got indents on the left that were unintended and
>> looked horrible, because the padding didn't float over with the image.
>>   This was worked around with the dj_ie6 selector to kill padding in
>> that case.
> A pixel off in IE6?  Not a problem.  Conditional comment or change the
> CSS slightly (will be a recurring theme throughout).
>> Another example:
>> IE:
>> In non-quirks mode, to remove scroll bars on the document (say to
> Standards mode?  BTW, doesn't make any sense to not use standards mode.
>  I know that lots of people do, but that doesn't mean we have to support
> them.
>> expand a node to full viewport and make it look like it is the
>> document), you have to set overflow to 'hidden' on both the  and
>>  tag, otherwise you get scrollbars.   No other browser requires
>> that.   In Quirks mode you don't.   Again, how do I detect that
>> 'feature' and deal with it?
> Misdiagnosed.  The way to determine if the outermost rendered element is
> the body (quirks mode in some browsers) or the documentElement (this
> century browsers in standards mode) is to check document.compatMode.  If
> it is missing (IE5 and Safari 2), you check
> document.documentElement.clientWidth === 0 (indicates the body is the
> target) or assume the documentElement.  You con't even have to worry
> about the last two.  There is already a flag for the first check
> (isQuirks or something like that).
> BTW, that one is in the CLJ FAQ.  :)
>> I'm not trying to be a pain, I'd love to get away from browser
>> sniffing ...
>> but I'm at a loss as to how to do it for rendering bugs
>> like the ones mentioned above.  What is your advice for dealing with
>> such issues that would avoid knowing the underlying browser?
> You aren't being a pain.  You are doing exactly what you should be doing
> (considering these hacks on a case by case basis).  Address the problems
> directly and you will be amazed at how quickly the sniffs go away (until
> none are left).  I've worked this process on dozens of sniff-laden sites
> and apps.  Undefeated to this day (meaning I left no sniffs behind).  :)
> Once you change your way of thinking, this issue is behind you...
>> -- Jared
>> On Wed, Oct 7, 2009 at 5:56 AM, sam foster 
>>>> Sniffs typically represent problems that were misdiagnosed or glossed
>>>> over.  They can't last as they link features/quirks to specific
>>>> (think about that).
>>> I've yet to see a comprehensive alternative to the .dj_{browser} css
>>> class hooks that sniff.js provides on the documentElement. Its a
>>> least-bad strategy that is at least clear in its intention. I cant
>>> think of a way to confirm a particular CSS feature is supported and
>>> behaves as intended without inferring it from the browser UA and
>>> rendering mode. Using conditional comments to selectively include a
>>> stylesheet are yet more browser sniffing. Comment hacks and filters
>>> are likewise distanced from the actual feature you are testing for,
>>> are brittle and can fragment style rules that belong together in one
>>> stylesheet
>>> A lot of box model discrepancies can be worked around by being careful
>>> with your markup, but that too isnt always an option. And this is not
>>> just an IE problem, we have rules in dijit and the themes handling
>>> oddness in all the other browsers. In the end it works out to be
>>> useful to /say what you mean/ in your selectors, with rules defining
>>> the optimal, and sniff-prefixed selectors to define the exceptions.
>>> That relies on populating the dojo.is{browser} properties, which
>>> brings us back to browser detection. Maybe we need a
>>> conditional-comment-like .dj_lteIE7. Or is there a better way to
>>> characterise the CSS deficiencies that isnt linked to a specific
>>> browser that we can use? We already have the box model hooks e.g.
>>> .dj_contentBox. Its possible that some rules could/should be using
>>> them rather than the .dj_ie qualifiers
>>> If you have a better solution or just ideas we can explore I'd love to
see them
>>> /Sam
>>> _______________________________________________
>>> dojo-contributors mailing list
>>> [email protected]
>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>> _______________________________________________
>> dojo-contributors mailing list
>> [email protected]
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
dojo-contributors mailing list
[email protected]

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

CD: 3ms