Computed shortcut styles

[David Mark]

[snip]

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.

Since I know you will ask, I suggest you look at properties and
methods that have been copied from IE. Some are on their way to
becoming standards. The best example is getBoundingClientRect. By
your formula, scripts would have assumed that IE was the only browser
to implement that method. Most of the majors do now and it may well
become a "real" standard.

And yes, the browser developers are very careful to mimic such
properties to a fault. Those guys are really quite predictable. They
do things that are in their own best interest.

What you can never predict are correlations between browser names,
versions and supported features. I thought this Dean guy was the last
person on earth who did not understand this. Are there now two in
that club?

 

[Thomas 'PointedEars' Lahn]

Since I know you will ask, I suggest you look at properties and
methods that have been copied from IE. Some are on their way to
becoming standards. The best example is getBoundingClientRect.

Not `innerHTML'?


PointedEars

 

[David Mark]

Not `innerHTML'?

That's another good one. Then there's offsetParent/Left/Top/Width/
Height, clientLeft/Top/Width/Height, etc. Of course, none are 100%
consistent across browsers (and that's not a justification for browser
sniffing.)

And, of course, Opera has supported currentStyle for some time. It's
mostly useless as Opera has supported getComputedStyle for just as
long (or longer.)

It seems Matt Kruse has "discovered" that feature testing in browser
scripting is not an exact science and that there have to be some
assumptions made at some point (like what a numeric clientLeft
property means.) I guess if it was an exact science, anybody could do
it. You do have to know your history as well. So much for those who
spent the last four years hiding from it.

 

[Matt Kruse]

Matt, I can't agree with you on this one. The only puristic aspect of
sniffing I see is that it usually takes less time to employ, comparing
to a feature test.

When I refer to feature detection as "purist" I mean that it's closer
to an "ideal" approach. So I wouldn't say sniffing is purist at all.

But this "somehow better" feature detection has been actually proven to
be more reliable, efficient, future-proof, etc.;
It's not just a theory

Definitely, in most cases. My argument is that in some cases the line
is not as clear, and I think it's good to look at things differently
sometimes just to challenge our assumptions and to get a new
perspective.

I see sniffing not as some kind of a devilish practice, rather - an
easiest, very brittle and inefficient approach to cross-browser
scripting. Testing particular feature before using it is clearly the
sanest way to go. It's a common sense. Sniffing, on the other hand, is
based on a number of shaky assumptions; assumptions that have been
proven to cause problems. If you are OK with weak assumptions, it's your
choice, but why would you choose it when better means exist?

Consider the existing case of host object bleed-through in IE. I've
not seen a test that can detect it programmatically, but let's say it
exists. Someone could spend hours playing with it, testing it, etc.
The initial test may take a few hundred milliseconds to run when the
page loads. But the end result would be... what? The same exact
browsers would get fixed as currently get fixed with a simple browser
sniff via conditional compilation.

You've replaced one methodology with another that is more
theoretically ideal, but the end result is the _same_. You might argue
that in some obscure case in the future, a browser might exist that
also needs the fix, and it will still work! That's great, but the odds
are that this will never happen, and you've just invested time and
money solving a problem that offers no practical benefits over the
previous approach.

Or let's say a single version of a single browser has a rendering bug.
You know exactly what UA string this browser sends. Checking the
string is very simple and quick. Or you could create an obscure test
case to detect the bug in a general manner, which takes up more time
and adds a lot more code - possibly even introducing side-effects into
the page that may cause other problems (FD tests often need to
manipulate the DOM, so they by definition cannot be as unobtrusive as
a string check). And the end result is that you now have a generalized
test for a case that _still_ only exists in a single version of a
single browser. Pro: Generalized solution that will work for any
browser with the same bug. Con: More bytes, added code logic that may
itself be vulnerable to bugs, time and money spent, and slower
execution speed.

My argument is this - that there may be a case of diminishing returns.
And although FD may be the best choice in almost all cases, don't be
dogmatic about it and never think about the alternatives or the cost/
benefit of solving the generalized test-driven case.

Actually, I believe that if another client implements `currentStyle`,
there's a big chance it will work similar to IE's one. I think Opera
does just that.
What I don't understand is why anyone would choose parsing userAgent
string over a simple - `if (element.currentStyle)`.

Well, I don't think anyone should. I just brought up that example to
show that when we use feature detection, we are still making
assumptions based on the browsers we know about and how we know they
behave. It's more bullet-proof than sniffing, but it's not fool-proof
either. It's just good to maintain some perspective when you have the
dogmatic David Mark's of the world hurling insults at everyone who he
doesn't think is doing it "the right way".

So don't take my post as a recommendation in favor of browser
sniffing. It was just an attempt to be realistic about why feature
detection is a better approach, but still depends on assumptions and
inferences, and why those who still make limited use of sniffing may
actually have some valid arguments that deserve respect and
consideration.

Matt Kruse

 

[David Mark]

When I refer to feature detection as "purist" I mean that it's closer
to an "ideal" approach. So I wouldn't say sniffing is purist at all.

Me either.

Definitely, in most cases. My argument is that in some cases the line
is not as clear, and I think it's good to look at things differently
sometimes just to challenge our assumptions and to get a new
perspective.

That's a fresh take on trolling. Remember, we've had this same
discussion at least six times here.

Consider the existing case of host object bleed-through in IE. I've
not seen a test that can detect it programmatically, but let's say it
exists. Someone could spend hours playing with it, testing it, etc.
The initial test may take a few hundred milliseconds to run when the
page loads. But the end result would be... what? The same exact
browsers would get fixed as currently get fixed with a simple browser
sniff via conditional compilation.

Conditional *comments* are the way to target IE quirks (when
absolutely necessary.) Of course, they don't fit into a monolithic
library.

You've replaced one methodology with another that is more
theoretically ideal, but the end result is the _same_. You might argue
that in some obscure case in the future, a browser might exist that
also needs the fix, and it will still work! That's great, but the odds
are that this will never happen, and you've just invested time and
money solving a problem that offers no practical benefits over the
previous approach.

You are delirious.

Or let's say a single version of a single browser has a rendering bug.
You know exactly what UA string this browser sends. Checking the
string is very simple and quick. Or you could create an obscure test
case to detect the bug in a general manner, which takes up more time
and adds a lot more code - possibly even introducing side-effects into
the page that may cause other problems (FD tests often need to
manipulate the DOM, so they by definition cannot be as unobtrusive as
a string check). And the end result is that you now have a generalized
test for a case that _still_ only exists in a single version of a
single browser.  Pro: Generalized solution that will work for any
browser with the same bug. Con: More bytes, added code logic that may
itself be vulnerable to bugs, time and money spent, and slower
execution speed.

You've got nothing there. Aren't you the one that always demands
"real world" examples?

My argument is this - that there may be a case of diminishing returns.
And although FD may be the best choice in almost all cases, don't be
dogmatic about it and never think about the alternatives or the cost/
benefit of solving the generalized test-driven case.

You like that word "dogmatic", don't you?

Well, I don't think anyone should. I just brought up that example to
show that when we use feature detection, we are still making
assumptions based on the browsers we know about and how we know they
behave. It's more bullet-proof than sniffing, but it's not fool-proof
either. It's just good to maintain some perspective when you have the
dogmatic David Mark's of the world hurling insults at everyone who he
doesn't think is doing it "the right way".

The sheep have been in charge for far too long. See what they have
done to the Web? If you can't, ask a blind person.

[snip]

 

[Matt Kruse]

You like that word "dogmatic", don't you?

Yes. Second only to "pithy".

Matt Kruse

 

[David Mark]

Yes. Second only to "pithy".

Okay. Well, the lesson learned here is that history needs to be a
part of your curriculum when teaching browser scripting. Think about
that the next time you "help" a neophyte hide behind jQuery.

Click?

 

[Garrett Smith]

[...]

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");

That would not be very good, as the "value" might be ambiguous.
getStyleAs would be more appropriate.

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.


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


Wouldn't be so bad if it worked.

That API is very clunky. It requires the developer to know a lot about
the API. I'd rather have an API that lets developer focus on the problem
at hand: Getting a style property from the element in a desirable unit.

Something like: el.getStyleAs('length', 'em') seems much more to the point.

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

What does getComputedStyle have to do with either CSSOM draft?

[...]

 

[David Mark]

David Mark wrote:
On May 12, 5:07 pm, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:

[...]

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");

That would not be very good, as the "value" might be ambiguous.
getStyleAs would be more appropriate.

I've lost track of this conversation.

That API is very clunky. It requires the developer to know a lot about
the API. I'd rather have an API that lets developer focus on the problem
at hand: Getting a style property from the element in a desirable unit.

I suppose. Still would be better if it worked.

Something like: el.getStyleAs('length', 'em') seems much more to the point.



What does getComputedStyle have to do with either CSSOM draft?

I don't like riddles.

 

[Garrett Smith]

[...]

What does getComputedStyle have to do with either CSSOM draft?

I don't like riddles.

So what, you decided that what you were saying about getComputedStyle is
impertinent to either CSSOM WD? Or what?

Garrett

 

[David Mark]

David Mark wrote:
David Mark wrote:
On May 12, 5:07 pm, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:

[...]

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.
What does getComputedStyle have to do with either CSSOM draft?

I don't like riddles.

So what, you decided that what you were saying about getComputedStyle is
impertinent to either CSSOM WD? Or what?

I decided nothing. See above. I barely remember this conversation
and I said nothing in it about CSSOM (you did.)

 

[Garrett Smith]

David Mark wrote:
David Mark wrote:
On May 12, 5:07 pm, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote: [...]



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.
What does getComputedStyle have to do with either CSSOM draft?
I don't like riddles.

So what, you decided that what you were saying about getComputedStyle is
impertinent to either CSSOM WD? Or what?

I decided nothing.

You decided to respond to what I wrote. Nobody forced you.

What you said about CSSOM was a direct response to what I wrote about
it, so, you did say something about it. Just something that didn't make
sense.

See above.

Seeing it.

I barely remember this conversation

and I said nothing in it about CSSOM (you did.)

Barely remember it, huh? It was less than two weeks.

If you put more thought into it in the first place, you might probably
remember a little better . I suppose it could also be a a short-term
memory issue.

This conversation from something of a technical nature to pedantic
discussion about what you did not reply to, starting with the "riddles"
disjunction.

So, you can answer the question or ignore it. Or you can continue with
this childish antics. I probably will just ignore you if you do. In
fact, I think maybe that would be a better approach. I don't think your
responses really deserve my time.

Garrett

 

[David Mark]

David Mark wrote:
David Mark wrote:
David Mark wrote:
On May 12, 5:07 pm, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]
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 thatin a
future css dom spec (not the CSSOM disaster).
Yes, there isn't much "standard" about the current computed style
methods.
What does getComputedStyle have to do with either CSSOM draft?
I don't like riddles.
So what, you decided that what you were saying about getComputedStyle is
impertinent to either CSSOM WD? Or what?

I decided nothing.  

You decided to respond to what I wrote. Nobody forced you.

Ah jeez, you got me there.

What you said about CSSOM was a direct response to what I wrote about
it, so, you did say something about it. Just something that didn't make
sense.

I know what I wrote. It made perfect sense and had nothing to do with
CSSOM. This is what I responded to:

"Few scripted web pages don't use the other "standard" interface..."

If your "other standard interface" is not related to this:

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

....then I don't really care what you are talking about. You had to go
all the way back to this to dredge up something to make you look
clever?

See above.

Seeing it.

I barely remember this conversation


Barely remember it, huh? It was less than two weeks.

So? How many questions do I answer in here in a... day? Are you
kidding? And need to drop the "huh" stuff when addressing me (hint.)

If you put more thought into it in the first place, you might probably
remember a little better . I suppose it could also be a a short-term
memory issue.

You sound drunk. Do you really want to play this game?

This conversation from something of a technical nature to pedantic
discussion about what you did not reply to, starting with the "riddles"
disjunction.

It wasn't a real question.

So, you can answer the question or ignore it. Or you can continue with
this childish antics. I probably will just ignore you if you do. In
fact, I think maybe that would be a better approach. I don't think your
responses really deserve my time.

That's the best damned news I've heard all day.