Computed shortcut styles

[David Mark]

I see this getting discussed to death until the end of time.

1. Unlike other modern browsers, IE does not have any way to retrieve
computed styles

2. IE does have a way to retrieve cascaded styles

3. A wrapper to smooth this over is easy, but will only be consistent
for a subset of rules and cases.

4. Shortcuts (e.g. margin, padding) aren't in the consistent subset
(for any cases.)

I would think that #4 would be obvious as passing a shortcut to
getComputedStyle makes no sense at all. Yes, some browsers will give
it their best shot, but that is their problem. Just don't do it.

Of course...

http://groups.google.com/group/jquery-dev/browse_thread/thread/eb564e528ac8933d#

Yes, as usual, jQuery takes an inconsistency and turns it into a
disaster (an exception.) Rather than pointing out the inherent
pointlessness of these cases, the developers are trying to come up
with new magic spells. They'll be back to sniffing the UA string
before you know it.

Also as usual, the root of the problem is sloppy code. You'd think
these guys would tire of tripping over bugs. These broken functions
(all of them?) aren't very long or complicated (or fast, efficient,
readable, etc.), yet here's this entire sub-culture refusing to read
and understand the code they rely on every day. Where are the "many
eyes" that ostensibly view this "well tested" BS every day? Wasn't
that the argument four years ago?

What I want to know is who is paying these neophytes to ponder old
problems created by scripts they chose and to ignore all of the issues
that could easily be fixed (or avoided.) The amount of time spent
going around in circles in those jQuery forums is obscene. Then there
are the upgrades and testing reboots every few months. All because
the equally clueless developers could never quite figure out "browser
magic" and the users are sure that jQuery is the only way to counter
it. There must be some way to communicate to these people that they
have everything backwards.

Nobody over there seems interested in the - attr - method's futility
either. It's like there is something in the water. Or maybe it is
all the bad books?

 

[Thomas 'PointedEars' Lahn]

I see this getting discussed to death until the end of time.

1. Unlike other modern browsers, IE does not have any way to retrieve
computed styles

2. IE does have a way to retrieve cascaded styles

That sounds like a false dichotomy. The CSS Specification does not define
"cascaded styles". It does define Cascaded Style Sheets and the computed
value of a style sheet property which is the result of following the cascade
according to rule specificity. AFAIK, MSHTML has both the `currentStyle'
and `runtimeStyle' properties to retrieve that value. Am I wrong?

3. A wrapper to smooth this over is easy, but will only be consistent
for a subset of rules and cases.

4. Shortcuts (e.g. margin, padding) aren't in the consistent subset
(for any cases.)

Then that's a bug.

I would think that #4 would be obvious as passing a shortcut to
getComputedStyle makes no sense at all.

IBTD. What you call "shortcuts" are valid CSS ("shorthand") properties. Of
course they have a computed value.

Yes, some browsers will give it their best shot, but that is their problem.

I beg your pardon?

Just don't do it.

Please elaborate.


PointedEars

 

[David Mark]

That sounds like a false dichotomy.  The CSS Specification does not define
"cascaded styles".  It does define Cascaded Style Sheets and the computed
value of a style sheet property which is the result of following the cascade
according to rule specificity.  AFAIK, MSHTML has both the `currentStyle'
and `runtimeStyle' properties to retrieve that value.  Am I wrong?



Then that's a bug.

Of course not. Think about it.

IBTD.  What you call "shortcuts" are valid CSS ("shorthand") properties..  Of
course they have a computed value.

Shortcut, shorthand or whatever. It makes no sense to try to compute
them. Some browsers don't bother, which makes the most sense.

I beg your pardon?

See above.

Please elaborate.

What is there to elaborate? Don't do it. Live happily ever after.

 

[Thomas 'PointedEars' Lahn]

Of course not. Think about it.

BTDT. Same result.

Shortcut, shorthand or whatever. It makes no sense to try to compute
them. Some browsers don't bother, which makes the most sense.

I don't see any Valid arguments here, just opinion.


PointedEars

 

[David Mark]

That sounds like a false dichotomy.  The CSS Specification does not define
"cascaded styles".  It does define Cascaded Style Sheets and the computed
value of a style sheet property which is the result of following the cascade
according to rule specificity.  AFAIK, MSHTML has both the `currentStyle'
and `runtimeStyle' properties to retrieve that value.  Am I wrong?

Yes (sorry, I missed this on the previous reply.) 100% wrong.
"Cascaded styles" are verbatim, not computed in any way.

Try this in various browsers:

#someelement {

margin: 2em 3px 1em 0

}

The only consistent entry is IE, because all versions return the rule
as it appears in the style sheet.

Of the four styles expressed in shorthand, two can be handled
consistently cross-browser. The other two require "Dean Edwards
Awesome Hack" (which doesn't work very well) to convert to pixel
units.

Obviously, the documentation for any function that wraps these two
disparate methods must define appropriate arguments (shorthand is the
first thing to rule out.)

The trouble is, as usual, that the authors of these "major libraries"
have no idea what they are doing. See also: attributes, properties,
memory leaks, feature testing, etc. How many major library authors
does it take to solve decade-old problems (or to figure out that they
don't need to be solved?) Obviously the release of IE8 was the
tipping point for such futility in browser scripting, but these
idiotic movements are marching on like nothing happened.

At least they finally got the message about the UA string. Trouble
is, I can see where they are going to want it back before long (some
are still arguing that it is necessary.)

[snip]

 

[David Mark]

BTDT.  Same result.



I don't see any Valid arguments here, just opinion.

See my other reply as I missed your question about IE's "cascaded
styles." That should help. If not, think about what sort of script
would need a computed shorthand style and realize that it is never
going to work in IE.

 

[SteveYoungTbird]

I see this getting discussed to death until the end of time.

erm, nobody is discussing it at c.l.j. You have just started a new
thread about it in case you didn't notice.

Of course...

http://groups.google.com/group/jquery-dev/browse_thread/thread/eb564e528ac8933d#

Yes, as usual, jQuery takes an inconsistency and turns it into a
disaster (an exception.)

Oh, I see, it's just another excuse to start your insistent jquery
bickering. Why do you have to do it here?

snip>

Nobody over there seems interested in the - attr - method's futility
either. It's like there is something in the water. Or maybe it is
all the bad books?

Well.........oh what's the use.

Steve.

 

[Thomas 'PointedEars' Lahn]

Yes (sorry, I missed this on the previous reply.) 100% wrong.

According to *your* terminology.

"Cascaded styles" are verbatim, not computed in any way.

Again, only according to your terminology. In fact, the CSS Specification
does not say what unit a computed style needs to use. So what you call a
"cascaded style" is in fact the computed style. However, it would appear
that all(?) UAs but MSHTML have adopted the quasi-standard (that W3C DOM
Level 2 CSS does _not_ define) to use pixel as unit of length.

Try this in various browsers:

#someelement {

margin: 2em 3px 1em 0

}

The only consistent entry is IE, because all versions return the rule
as it appears in the style sheet.

Utter nonsense.

Of the four styles expressed in shorthand, two can be handled
consistently cross-browser.

The computed style is not supposed to be cross-browser as it is defined to
be dependent on the user agent.


PointedEars

 

[David Mark]

erm, nobody is discussing it at c.l.j. You have just started a new
thread about it in case you didn't notice.

Who said anyone was discussing it here. I did start a new thread and
perhaps it will likely echo everywhere else (as usual.)

<snip>




Oh, I see, it's just another excuse to start your insistent jquery
bickering. Why do you have to do it here?

It's not bickering. It's a whole bunch of people wasting a whole lot
of time and money on nonsense. Mind your own business.

Well.........oh what's the use.

I agree on that one. What were *you* thinking? Perhaps an excuse to
get attention?

 

[David Mark]

According to *your* terminology.
Nope.


Again, only according to your terminology.  In fact, the CSS Specification
does not say what unit a computed style needs to use.  So what you calla
"cascaded style" is in fact the computed style.

Don't be stupid (and confusing to others.)

 However, it would appear

that all(?) UAs but MSHTML have adopted the quasi-standard (that W3C DOM
Level 2 CSS does _not_ define) to use pixel as unit of length.

There you go. The W3C doesn't matter in this case. That comes up a
lot in browser scripting.

Utter nonsense.

Try it and see. And how do you not know this?

The computed style is not supposed to be cross-browser as it is defined to
be dependent on the user agent.

What a worthless thing to say (at least in this context.) Never mind
what some "standard" says about getComputedStyle. The fact is that
the behavior is consistent (except for IE), provided you don't do
something ill-advised (like try to compute shorthand styles.) None of
this is close to news.

 

[Thomas 'PointedEars' Lahn]

David Mark replied to a cancelled and deleted posting:

Nope.

You're reading too fast for me

I need to think this over.


PointedEars

 

[David Mark]

David Mark replied to a cancelled and deleted posting:





You're reading too fast for me

Sorry. I'm not trying to be confusing. I thought you understood
about IE's ridiculous currentStyle/runtimeStyle/pixelStyle/whatever
nonsense. Granted, it shouldn't come up much.

I need to think this over.

I'm sure we can come to an agreement that IE's BS isn't close to
computed styles and that jQuery is foolishly (and clumsily) trying to
account for this in their usual scatter-shot manner.

 

[Garrett Smith]

Don't be stupid (and confusing to others.)

However, it would appear

There you go. The W3C doesn't matter in this case. That comes up a
lot in browser scripting.


Try it and see. And how do you not know this?

By "all versions return the rule", I think you meant: "In all versions
of IE, someelement.computedStyle.margin will return the rule as it
appears in the style sheet."

This is true, if nothing else appears in the cascade between the
"someelement" element and that rule.

What a worthless thing to say (at least in this context.) Never mind
what some "standard" says about getComputedStyle. The fact is that
the behavior is consistent (except for IE), provided you don't do
something ill-advised (like try to compute shorthand styles.) None of
this is close to news.

Yes, and the specification is not clear on what exactly should happen
when trying to read shorthand properties. It mostly says, for shorthand
property values:

| Computed value: see individual properties

For background, Gecko, for a while, would return an intransitive value.
That value could be something like "inherit inherit inherit inherit
inherit" (I can't remember how many times "inherit" was there).

It would be nice if it worked, but it doesn't. The thinking "It should
work (if somebody does XXX)" can lead to making the attempt to do XXX
"work". It is one of those indicators to a response that you provided
earlier: "Don't do that".

The library code should not expect that the user will try to obtain
shortcut values. I'm guilty of that, too and I think I should take a
look at removing that.

But it really should work!

There should also be properties on Element:-

computedStyle
cascadedStyle
absoluteStyle

as well as a converter, getValueAs("length", "em"), to interpolate
values between "10em" and "640px".

var lenEm = el.getValueAs("length", "em");
var lenPx = el.getValueAs("length", "px");

This would provide a simpler interface than the current clunkiness
(which does not work reliably):-

var view = document.defaultView,
body = document.body;
var style = view.getComputedStyle(body, '');
var prop = style.getPropertyCSSValue('width');
var value = prop.getFloatValue(CSSPrimitiveValue.CSS_EMS);

What a pain. All that code, and it doesn't even work!

OTOH, if a new interface were to be created, it could be made to work.
Few scripted web pages don't use the other "standard" interface, so it
can probably be deprecated to be "optional" or something like that in a
future css dom spec (not the CSSOM disaster).

This has come up a few times on the w3c's "www-style" list, but no
implementation has decided to improvise on these ideas and no spec
author has decided to write a formal specification of this idea.

Garrett

 

[David Mark]

By "all versions return the rule", I think you meant: "In all versions
of IE, someelement.computedStyle.margin will return the rule as it
appears in the style sheet."

This is true, if nothing else appears in the cascade between the
"someelement" element and that rule.

Yes. That is why I have always referred to it as the "cascaded
style", which may have no standard definition, but aptly describes the
result.

Yes, and the specification is not clear on what exactly should happen
when trying to read shorthand properties. It mostly says, for shorthand
property values:

| Computed value:       see individual properties

To me, they should either return null or throw an exception.

For background, Gecko, for a while, would return an intransitive value.
That value could be something like "inherit inherit inherit inherit
inherit" (I can't remember how many times "inherit" was there).

If we are talking about padding or margins, I assume it was four.

That is just the sort of madness that jQuery is now considering. As
if they have time to ponder such nonsense; what with the memory leaks
and other atrocities in 1.32.

It would be nice if it worked, but it doesn't. The thinking "It should
work (if somebody does XXX)" can lead to making the attempt to do XXX
"work". It is one of those indicators to a response that you provided
earlier: "Don't do that".

Yes, but I still can't imagine an app that would to compute and then
concatenate styles to recreate a shorthand form. That's one of my
major complaints about the "major libraries." They've wasted four
years tracking down fleeting discrepancies that didn't matter at all.
Writing a cross-browser script for one document is hard enough (though
less so today.) Writing a general-purpose script for any document and
context, real or imagined, is a virtually impossible task. Small
wonder these efforts have fallen so far short of the mark.

After three years, the jQuery developers have seemingly learned
nothing about "smoothing over" browser differences. They can't even
get their brains around IE5+, dismissing obvious clues to its behavior
as "browser magic." What have the users learned, except the
approximate frequency with which new jQuery bugs are introduced?

I'm still wondering who is stupid enough to pay for all of these
wasted, repetitive motions. Can nobody figure out that constant
upgrades are poison? They are a very good indication of lack of
foresight and poor testing as well (think Windows service packs.)
"Many eyes" and "well tested" are myths, pure and simple.

The library code should not expect that the user will try to obtain
shortcut values. I'm guilty of that, too and I think I should take a
look at removing that.

Exactly and same with me, though I doubt I will do it. It's just one
bad idea in a largely ill-conceived script.

But it really should work!

But who needs it?

There should also be properties on Element:-

computedStyle

Sure, why not.

cascadedStyle

Most could do without it.

absoluteStyle
?


as well as a converter, getValueAs("length", "em"), to interpolate
values between "10em" and "640px".

var lenEm = el.getValueAs("length", "em");
var lenPx = el.getValueAs("length", "px");

Interesting. Or you could use "Dean Edwards' Awesome Hack", as seen
in jQuery. For those of you watching at home, do not accept hacks
from Dean Edwards.

This would provide a simpler interface than the current clunkiness
(which does not work reliably):-

var view = document.defaultView,
     body = document.body;
var style = view.getComputedStyle(body, '');
var prop = style.getPropertyCSSValue('width');
var value = prop.getFloatValue(CSSPrimitiveValue.CSS_EMS);

Yes, that is right out (at least for the foreseeable future.)

What a pain. All that code, and it doesn't even work!

Wouldn't be so bad if it worked.

OTOH, if a new interface were to be created, it could be made to work.
Few scripted web pages don't use the other "standard" interface, so it
can probably be deprecated to be "optional" or something like that in a
future css dom spec (not the CSSOM disaster).

Yes, there isn't much "standard" about the current computed style
methods.

This has come up a few times on the w3c's "www-style" list, but no
implementation has decided to improvise on these ideas and no spec
author has decided to write a formal specification of this idea.

Maybe somebody will eventually, but we may all be writing scripts for
Flash by then. Most of the interested parties today are working on
dead-end projects like jQuery.

 

[David Mark]

As I understand from the discussion in jQuery group, the main use case
being mentioned is copying styles from one element to another:

someElement.style.margin = getStyle(someOtherElement, 'margin');

Yes, IIRC such an ill-advised pattern was proposed as justification
for more hacking.

If that's the case, I can see how `getStyle` returning "combined" values
can be useful (as long as returned value is of a valid syntax for a
value of an assignment, e.g. - "5px 10px 5px 0").

 From what I can see, they do realize that it's a potential can of worms
to open.

It's a real can of worms that's been opened and its contents
examined. It should be thrown away at the design stage.

The re-invention of such useless "wheels" by jQuery is a recurring
pattern as the project seems to trudge on in a parallel universe.
They lead to endless patches, complications and incompatibilities,
which are typically blamed on "browser magic", the earth being flat or
whatever, which reinforces the dependency on jQuery. It's a vicious
circle that is easily broken by loading the script into a text editor
and realizing that it isn't anything you should want or need
(certainly not in 2009.)

[...]

Interesting.  Or you could use "Dean Edwards' Awesome Hack", as seen
in jQuery.  For those of you watching at home, do not accept hacks
from Dean Edwards.

What exactly is wrong with that "hack"?

Do the quotes indicate it is not a hack? In the context of jQuery,
its haphazard introduction leads to uncaught exceptions. I don't know
what the original looks like. Certainly it is a pattern that is
easily avoidable and advisable to avoid.

 

[David Mark]

What would you recommend as a replacement?

I recently had to do something similar - copy styles of one element onto
another. It was a drag'n'drop interface, and dynamically created clone
of an element had to look fully identical to the original one (and
positioned on top of each other). The problem was that clone was not
contained within the same parent element and so wouldn't be affected by
the same cascade. I had to get computed styles of an original element
and "copy" them onto clone (so that they looked identical in padding,
margin, border, etc.)

Sounds like the design painted you into a corner.

It's a real can of worms that's been opened and its contents
examined.  It should be thrown away at the design stage.

Copying style seems to be an issue here (as one of jQ devs mentioned). I
don't see why else someone would want a shorthand value. It might be
better to provide `copyStyles` helper (or something similar):

copyComputedStyles(fromEl, toEl, ['marginTop', 'left', 'textAlign']);

Much better. But it is "coolness" that the library authors are
after. Don't know if this fits into their "concise" API.

[...]

Do the quotes indicate it is not a hack?  In the context of jQuery,
its haphazard introduction leads to uncaught exceptions.  I don't know
what the original looks like.  Certainly it is a pattern that is
easily avoidable and advisable to avoid.

Oh, you're talking about an error that jQuery has. I thought there was
some problem in hack's logic itself.

Not exactly. That was your cue to produce the original. I'd be glad
to take a second look at it. IIRC, it does have problems apart from
those intrinsic to such end-arounds.

 

[David Mark]

David Mark wrote:
[...]
As I understand from the discussion in jQuery group, the main use case
being mentioned is copying styles from one element to another:
someElement.style.margin = getStyle(someOtherElement, 'margin');
Yes, IIRC such an ill-advised pattern was proposed as justification
for more hacking.
What would you recommend as a replacement?
I recently had to do something similar - copy styles of one element onto
another. It was a drag'n'drop interface, and dynamically created clone
of an element had to look fully identical to the original one (and
positioned on top of each other). The problem was that clone was not
contained within the same parent element and so wouldn't be affected by
the same cascade. I had to get computed styles of an original element
and "copy" them onto clone (so that they looked identical in padding,
margin, border, etc.)

Sounds like the design painted you into a corner.

Something like that

The reason I couldn't put clone into the same container (as it is
usually done in similar drag/drop cases) is because containing element
had "overflow: scroll;" (it was a scrollable panel in a sidebar with
small thumbnails). Dragging clone out of the "overflow: scroll"
container would obviously "hide" it the moment it crossed container
borders, which is not what I needed; I needed to "drop" clone on the
main panel. Therefore, on "mousedown", I had to create a clone, insert
it into a `document.body`, make it absolute, set its left/top to
computed left/top of original element, and clone styles to prevent any
visual side effects from element not being under the same cascade.

Yes, it did feel like a hack, but that was a real use case which I don't
think I could have designed out of the system (as it was the core of UI
itself that required this workaround).

I did copy styles manually, though, by hardcoding properties which
needed to be copied (margin, padding, textAlign, etc.). I'm not very
happy with that "solution", as it's not flexible; any changes in the
thumbnails' design will require to modify script as well. A smart
generic solution would scale much better.

If you have control of both the script and the style sheet(s), you
should be able to avoid the inheritance issue. You should be able to
encapsulate your list of styles in a class as well.

But if a coupling between script and style makes for the best
solution, then don't worry about what happens when and if you re-do
the style sheet. Just document the relationship. These huge
Javascript projects often get bogged down worrying about future
maintenance. Many never see daylight as a result.

If that's the case, I can see how `getStyle` returning "combined" values
can be useful (as long as returned value is of a valid syntax for a
value of an assignment, e.g. - "5px 10px 5px 0").
 From what I can see, they do realize that it's a potential can ofworms
to open.
It's a real can of worms that's been opened and its contents
examined.  It should be thrown away at the design stage.
Copying style seems to be an issue here (as one of jQ devs mentioned).I
don't see why else someone would want a shorthand value. It might be
better to provide `copyStyles` helper (or something similar):
copyComputedStyles(fromEl, toEl, ['marginTop', 'left', 'textAlign']);

Much better.  But it is "coolness" that the library authors are
after.  Don't know if this fits into their "concise" API.

Oh, that should be easy! You just need to overload `css` to be able to
accept an element. `css` would then copy styles from that element onto
the receiver. Concise and no need to introduce another method!

$(toEl).css(fromEl);

I assume you are kidding. Function "overloading" is not usually a
good idea in Javascript (certainly not if host objects are involved.)

[...]
What exactly is wrong with that "hack"?
Do the quotes indicate it is not a hack?  In the context of jQuery,
its haphazard introduction leads to uncaught exceptions.  I don't know
what the original looks like.  Certainly it is a pattern that is
easily avoidable and advisable to avoid.
Oh, you're talking about an error that jQuery has. I thought there was
some problem in hack's logic itself.

Not exactly.  That was your cue to produce the original.  I'd be glad
to take a second look at it.  IIRC, it does have problems apart from
those intrinsic to such end-arounds.

I'd like to look at it too. Can't remember how it works off the top of
my head.

I can. Like most of that guy's stuff, it's a novelty item. Using
anything like that in production should be career suicide, but that
doesn't seem to be the case at the moment (just blame any subsequent
problems on IE.)

 

[David Mark]

If you have control of both the script and the style sheet(s), you
should be able to avoid the inheritance issue.  You should be able to
encapsulate your list of styles in a class as well.

But if a coupling between script and style makes for the best
solution, then don't worry about what happens when and if you re-do
the style sheet.  Just document the relationship.  These huge
Javascript projects often get bogged down worrying about future
maintenance.  Many never see daylight as a result.

Yeah. That's what I ended up doing - documented style declaration.

[...]

I assume you are kidding.  Function "overloading" is not usually a
good idea in Javascript (certainly not if host objects are involved.)

Yes, of course I was kidding

Oh good. Thought we'd lost you there.

[...]

I can.  Like most of that guy's stuff, it's a novelty item.  Using
anything like that in production should be career suicide, but that
doesn't seem to be the case at the moment (just blame any subsequent
problems on IE.)

I remember I tried conviencing Dean not to sniff in his latest base2.js.
<http://groups.google.com/group/base2-js/browse_thread/thread/472b32aa...>

A month ago, no less.

In the end he removed only few of them, but didn't seem to understand
the brittleness of that approach, and said he was being pragmatic.

He's a bigger fool than I thought.

 

[Matt Kruse]

I remember I tried conviencing Dean not to sniff in his latest base2.js.
<http://groups.google.com/group/base2-js/browse_thread/thread/472b32aa...>
In the end he removed only few of them, but didn't seem to understand
the brittleness of that approach, and said he was being pragmatic.

I read the thread, and I do agree with some of the points he made. I
do think that feature detection is kind of a "purist" approach and
some people recommend it simply because it is the "right" way to do
things even without demonstrating why it's "better" or why the current
approach is bad beyond simply "in theory, it could break someday".
Similar to those who naively recommend using XHTML because it is
somehow "better" and "purer" than HTML.

Just as an example, consider what he says about currentStyle.

Your argument: If getComputedStyle doesn't exist, don't rely on a
browser check for IE to use currentStyle - check for currentStyle and
use it if it exists! It's browser-agnostic!

His argument: currentStyle is non-standard anyway. If another browser
supported it, it may not work the same anyway. Assuming it works like
IE is no more browser-agnostic than UA sniffing!

I think his argument has some merit. In order to really use
currentStyle in a browser-agnostic way, you _cannot_ assume that it
works the way it does in IE. You would have to test by using it in the
way you expect it to work, inspect the results, and see if it behaved
correctly. Only then would you be able to trust it. And even then,
_only_ in the exact case you tested!

But the truth is, using feature detection, most people would do:

if (...getComputedStyle...) { ... }
else if (...currentStyle...) { ... }

This logic is based off the assumption that if currentStyle exists,
then it behaves as we know it does in IE _because that is the only
case we know of_. So we're not really being browser agnostic. We're
making an assumption based on:
1. We know what browsers support currentStyle
2. We know how it behaves in those browsers
3. If currentStyle exists, we can assume in behaves in that way

Now, this may be better than browser sniffing, but at least recognize
that both approaches rely on knowledge about the set of browsers being
used. The only way either approach works is because we know what
browsers exist in the wild, and we can't come up with any cases where
this logic will break.

The goal of cross-browser scripting is to reduce the number of
assumptions being made by checking for functionality. But in some
cases, abandoning browser sniffing in favor or feature detection is
just switching to a different set of assumptions that may or may not
be less fragile. IMO.

Matt Kruse

 

[David Mark]

I read the thread, and I do agree with some of the points he made. I
do think that feature detection is kind of a "purist" approach and
some people recommend it simply because it is the "right" way to do
things even without demonstrating why it's "better" or why the current
approach is bad beyond simply "in theory, it could break someday".
Similar to those who naively recommend using XHTML because it is
somehow "better" and "purer" than HTML.

Complete, unadulterated horseshit. No parallel at all. You know much
better than this.

It is ironic that most people using UA sniffing seem to prefer XHTML
transitional.

Just as an example, consider what he says about currentStyle.

Your argument: If getComputedStyle doesn't exist, don't rely on a
browser check for IE to use currentStyle - check for currentStyle and
use it if it exists! It's browser-agnostic!
So?


His argument: currentStyle is non-standard anyway. If another browser
supported it, it may not work the same anyway. Assuming it works like
IE is no more browser-agnostic than UA sniffing!

Did you get kidnapped by aliens? You don't know it is IE and you
certainly don't know when IE will decide to drop this property. The
client doesn't want to call you years later to update your browser
sniffing.

I think his argument has some merit. In order to really use
currentStyle in a browser-agnostic way, you _cannot_ assume that it
works the way it does in IE. You would have to test by using it in the
way you expect it to work, inspect the results, and see if it behaved
correctly. Only then would you be able to trust it. And even then,
_only_ in the exact case you tested!

So what? It's a far sight better than looking at the browser name.

But the truth is, using feature detection, most people would do:

if (...getComputedStyle...) { ... }
else if (...currentStyle...) { ... }

This logic is based off the assumption that if currentStyle exists,
then it behaves as we know it does in IE _because that is the only
case we know of_. So we're not really being browser agnostic. We're
making an assumption based on:
 1. We know what browsers support currentStyle
 2. We know how it behaves in those browsers
 3. If currentStyle exists, we can assume in behaves in that way

Now, this may be better than browser sniffing, but at least recognize

Of course it is and you should pick the best choice.

that both approaches rely on knowledge about the set of browsers being
used. The only way either approach works is because we know what
browsers exist in the wild, and we can't come up with any cases where
this logic will break.

Nobody said any of this is perfect.

The goal of cross-browser scripting is to reduce the number of
assumptions being made by checking for functionality. But in some
cases, abandoning browser sniffing in favor or feature detection is
just switching to a different set of assumptions that may or may not
be less fragile. IMO.

Your opinion is worthless (as usual.)