Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #8952 > unrolled thread

David Mark's Daily Javascript Tips - Volume #3 - Tip #8 - How to Compute Styles

Back to article view | Back to comp.lang.javascript

Contents

  David Mark's Daily Javascript Tips  - Volume #3 - Tip #8 - How to Compute Styles David Mark <dmark.cinsoft@gmail.com> - 2011-12-06 15:28 -0800
    Re: David Mark's Daily Javascript Tips  - Volume #3 - Tip #8 - How to Compute Styles "J.R." <groups_jr-1@yahoo.com.br> - 2011-12-07 00:14 -0200
      Re: David Mark's Daily Javascript Tips - Volume #3 - Tip #8 - How to Compute Styles David Mark <dmark.cinsoft@gmail.com> - 2011-12-07 10:01 -0800
    Re: David Mark's Daily Javascript Tips - Volume #3 - Tip #8 - How to Compute Styles David Mark <dmark.cinsoft@gmail.com> - 2011-12-06 18:34 -0800

#8952 — David Mark's Daily Javascript Tips - Volume #3 - Tip #8 - How to Compute Styles

How to Compute Styles

In a word, don't.  The recommendation followed by the browser vendors
is long-winded and vague and historically browsers have varied in
their interpretations.  The variety of results that must be parsed to
derive meaning is a huge burden to bear and most applications don't
need to compute any styles (let alone all possibilities!) in the first
place.

var getStyleComputed;

// No "float" styles
// Requires camel-case style names
// Fades away in IE 8- and compatibility modes

if (document.defaultView && document.defaultView.getComputedStyle) {
          getStyleComputed = function(el, style) {
            return document.defaultView.getComputedStyle(el, null)
[style];
          };
}

What's missing?  Can't handle "float" as it is a reserved word
(property is "cssFloat" or "styleFloat", depending on
implementation).  That's easy enough to detect, but how often do you
need to compute the float style?

Add a line during development:-

if (document.defaultView && document.defaultView.getComputedStyle) {
          getStyleComputed = function(el, style) {

            if (style == 'float') {
              throw new Error('RTFM! The "float" style is not
supported by this rendition!');
            }

            return document.defaultView.getComputedStyle(el, null)
[style];
          };
}

...and remove on release.

Note that this function requires camel-case style names, not
hyphenated.  That will save you a keystroke/byte.  ;)

Add another line during development:-

if (document.defaultView && document.defaultView.getComputedStyle) {
          getStyleComputed = function(el, style) {

            if (style.indexOf('-') != -1) {
              throw new Error('Camel-case style names, please.');
            }

            if (style == 'float') {
              throw new Error('RTFM! The "float" style is not
supported by this rendition!');
            }

            return document.defaultView.getComputedStyle(el, null)
[style];
          };
}

...and remove on release.

Instead of adding additional logic for your users to *download*,
simply corral your developers prior to release.

if (getStyleComputed) {
  // Put app that must compute styles here
}

But what of IE8 and under?  At this point, you have to consider what
this function is to be used for.  There's not a chance in hell in
creating a general-purpose getComputedStyle emulation for legacy IE
versions (which lack the required host method).  And no, that fact has
not stopped the library ninjas from trying to outdo each other, year
after year, on this front.  Even worse, these teetering piles of hacks
are often tangled up with other library functionality (e.g. jQuery's
height/width methods).  The situation is a mess that can only be
cleaned up by starting over from scratch (as jQuery is rumored to be
contemplating).

Historically, the primary use of such "cross-browser" wrappers has
been to support scripted effects.  Well, scripted effects are dead
these days (somebody tell jQuery) and even if you need to offer
fallback effects for legacy IE versions, you don't need a cross-
browser getComputedStyle wrapper.  You just need to concentrate on
whatever handful of styles your current project must animate.

Left, top, right, bottom, height, width and borders can all be easily
figured without a getComputedStyle dependency. Margins can be figured
in some contexts, but who would need to do such a thing?  And I can
hear it now: what about padding?!  Unless you are doing something very
wrong, you should never need to compute the padding.  Granted, that's
exactly what jQuery's height/width methods try to do.  :(

Here are solutions for size and position:-

http://www.cinsoft.net/size.html
http://www.cinsoft.net/position.html

Borders should be an easy exercise if you have been following along;
yes, even the right and bottom borders.  But why would your script be
interested in such styling, unless it is going to do scripted effects
involving borders?

I've been using the CSS3 transitions/animations for some time now.
I've seen Opera, then Firefox (and finally IE 10) reproduce what
Webkit started and have been quite pleased with the consistency and
performance.  It takes little or no code to use those features.  So
use them and stop worrying about computed styles.

Take out effects, computing styles, queries, and all of the other
topics covered so far in this series and what is there left for a
script like jQuery to do; other than take up space?  Pretty hard to
believe that ostensibly experienced developers are now trying to build
a "mobile framework" on top of jQuery.  All I can figure is they have
no idea what is in that script.  For them, I guess it's all about
marketing a name.  :(

http://www.cinsoft.net/
http://twitter.com/cinsoft
http://jsperf.com/browse/david-mark

[toc] | [next] | [standalone]

#8954

On 06/12/2011 21:28, David Mark wrote:
> How to Compute Styles
>
> In a word, don't.  The recommendation followed by the browser vendors
> is long-winded and vague and historically browsers have varied in
> their interpretations.  The variety of results that must be parsed to
> derive meaning is a huge burden to bear and most applications don't
> need to compute any styles (let alone all possibilities!) in the first
> place.
>
> var getStyleComputed;
>
> // No "float" styles
> // Requires camel-case style names
> // Fades away in IE 8- and compatibility modes
>
> if (document.defaultView&&  document.defaultView.getComputedStyle) {
>            getStyleComputed = function(el, style) {
>              return document.defaultView.getComputedStyle(el, null)
> [style];
>            };
> }
>
> What's missing?  Can't handle "float" as it is a reserved word
> (property is "cssFloat" or "styleFloat", depending on
> implementation).  That's easy enough to detect, but how often do you
> need to compute the float style?
>
> Add a line during development:-
>
> if (document.defaultView&&  document.defaultView.getComputedStyle) {
>            getStyleComputed = function(el, style) {
>
>              if (style == 'float') {
>                throw new Error('RTFM! The "float" style is not
> supported by this rendition!');
>              }
>
>              return document.defaultView.getComputedStyle(el, null)
> [style];
>            };
> }
>
> ....and remove on release.
>
> Note that this function requires camel-case style names, not
> hyphenated.  That will save you a keystroke/byte.  ;)
>
> Add another line during development:-
>
> if (document.defaultView&&  document.defaultView.getComputedStyle) {
>            getStyleComputed = function(el, style) {
>
>              if (style.indexOf('-') != -1) {
>                throw new Error('Camel-case style names, please.');
>              }
>
>              if (style == 'float') {
>                throw new Error('RTFM! The "float" style is not
> supported by this rendition!');
>              }
>
>              return document.defaultView.getComputedStyle(el, null)
> [style];
>            };
> }
>
> ....and remove on release.
>
> Instead of adding additional logic for your users to *download*,
> simply corral your developers prior to release.
>
> if (getStyleComputed) {
>    // Put app that must compute styles here
> }
>
> But what of IE8 and under?  At this point, you have to consider what
> this function is to be used for.  There's not a chance in hell in
> creating a general-purpose getComputedStyle emulation for legacy IE
> versions (which lack the required host method).  And no, that fact has
> not stopped the library ninjas from trying to outdo each other, year
> after year, on this front.  Even worse, these teetering piles of hacks
> are often tangled up with other library functionality (e.g. jQuery's
> height/width methods).  The situation is a mess that can only be
> cleaned up by starting over from scratch (as jQuery is rumored to be
> contemplating).
>
> Historically, the primary use of such "cross-browser" wrappers has
> been to support scripted effects.  Well, scripted effects are dead
> these days (somebody tell jQuery) and even if you need to offer
> fallback effects for legacy IE versions, you don't need a cross-
> browser getComputedStyle wrapper.  You just need to concentrate on
> whatever handful of styles your current project must animate.
>
> Left, top, right, bottom, height, width and borders can all be easily
> figured without a getComputedStyle dependency. Margins can be figured
> in some contexts, but who would need to do such a thing?  And I can
> hear it now: what about padding?!  Unless you are doing something very
> wrong, you should never need to compute the padding.  Granted, that's
> exactly what jQuery's height/width methods try to do.  :(
>
> Here are solutions for size and position:-
>
> http://www.cinsoft.net/size.html
> http://www.cinsoft.net/position.html
>
> Borders should be an easy exercise if you have been following along;
> yes, even the right and bottom borders.  But why would your script be
> interested in such styling, unless it is going to do scripted effects
> involving borders?
>

I like to the way emile.js, by Thomas Fuchs, deals with retrieving / 
modifying an element's style: 
<https://github.com/kangax/emile/blob/master/emile.js> - that's the 
Kangax's fork. It is very clever indeed because the normalize() function 
puts the browser to do the hard work for the code by means of a dummy 
element (parseEl).


> I've been using the CSS3 transitions/animations for some time now.
> I've seen Opera, then Firefox (and finally IE 10) reproduce what
> Webkit started and have been quite pleased with the consistency and
> performance.  It takes little or no code to use those features.  So
> use them and stop worrying about computed styles.
>

Wonderful! But CSS3 is still a work in progress:
<http://www.w3.org/Style/CSS/current-work.en.html>


> Take out effects, computing styles, queries, and all of the other
> topics covered so far in this series and what is there left for a
> script like jQuery to do; other than take up space?  Pretty hard to
> believe that ostensibly experienced developers are now trying to build
> a "mobile framework" on top of jQuery.  All I can figure is they have
> no idea what is in that script.  For them, I guess it's all about
> marketing a name.  :(

Unfortunately, John Resig has got a lot of spare time to dedicate to his 
creation, so that JQuery would hardly die in the near future...
<http://ejohn.org/blog/next-steps-in-2011/>

-- 
Joao Rodrigues (J.R.)

[toc] | [prev] | [next] | [standalone]

#8971 — Re: David Mark's Daily Javascript Tips - Volume #3 - Tip #8 - How to Compute Styles

On Dec 6, 9:14 pm, "J.R." <groups_j...@yahoo.com.br> wrote:
> On 06/12/2011 21:28, David Mark wrote:
>
>
>
>
>
>
>
>
>
> > How to Compute Styles
>
> > In a word, don't.  The recommendation followed by the browser vendors
> > is long-winded and vague and historically browsers have varied in
> > their interpretations.  The variety of results that must be parsed to
> > derive meaning is a huge burden to bear and most applications don't
> > need to compute any styles (let alone all possibilities!) in the first
> > place.
>
> > var getStyleComputed;
>
> > // No "float" styles
> > // Requires camel-case style names
> > // Fades away in IE 8- and compatibility modes
>
> > if (document.defaultView&&  document.defaultView.getComputedStyle) {
> >            getStyleComputed = function(el, style) {
> >              return document.defaultView.getComputedStyle(el, null)
> > [style];
> >            };
> > }
>
> > What's missing?  Can't handle "float" as it is a reserved word
> > (property is "cssFloat" or "styleFloat", depending on
> > implementation).  That's easy enough to detect, but how often do you
> > need to compute the float style?
>
> > Add a line during development:-
>
> > if (document.defaultView&&  document.defaultView.getComputedStyle) {
> >            getStyleComputed = function(el, style) {
>
> >              if (style == 'float') {
> >                throw new Error('RTFM! The "float" style is not
> > supported by this rendition!');
> >              }
>
> >              return document.defaultView.getComputedStyle(el, null)
> > [style];
> >            };
> > }
>
> > ....and remove on release.
>
> > Note that this function requires camel-case style names, not
> > hyphenated.  That will save you a keystroke/byte.  ;)
>
> > Add another line during development:-
>
> > if (document.defaultView&&  document.defaultView.getComputedStyle) {
> >            getStyleComputed = function(el, style) {
>
> >              if (style.indexOf('-') != -1) {
> >                throw new Error('Camel-case style names, please.');
> >              }
>
> >              if (style == 'float') {
> >                throw new Error('RTFM! The "float" style is not
> > supported by this rendition!');
> >              }
>
> >              return document.defaultView.getComputedStyle(el, null)
> > [style];
> >            };
> > }
>
> > ....and remove on release.
>
> > Instead of adding additional logic for your users to *download*,
> > simply corral your developers prior to release.
>
> > if (getStyleComputed) {
> >    // Put app that must compute styles here
> > }
>
> > But what of IE8 and under?  At this point, you have to consider what
> > this function is to be used for.  There's not a chance in hell in
> > creating a general-purpose getComputedStyle emulation for legacy IE
> > versions (which lack the required host method).  And no, that fact has
> > not stopped the library ninjas from trying to outdo each other, year
> > after year, on this front.  Even worse, these teetering piles of hacks
> > are often tangled up with other library functionality (e.g. jQuery's
> > height/width methods).  The situation is a mess that can only be
> > cleaned up by starting over from scratch (as jQuery is rumored to be
> > contemplating).
>
> > Historically, the primary use of such "cross-browser" wrappers has
> > been to support scripted effects.  Well, scripted effects are dead
> > these days (somebody tell jQuery) and even if you need to offer
> > fallback effects for legacy IE versions, you don't need a cross-
> > browser getComputedStyle wrapper.  You just need to concentrate on
> > whatever handful of styles your current project must animate.
>
> > Left, top, right, bottom, height, width and borders can all be easily
> > figured without a getComputedStyle dependency. Margins can be figured
> > in some contexts, but who would need to do such a thing?  And I can
> > hear it now: what about padding?!  Unless you are doing something very
> > wrong, you should never need to compute the padding.  Granted, that's
> > exactly what jQuery's height/width methods try to do.  :(
>
> > Here are solutions for size and position:-
>
> >http://www.cinsoft.net/size.html
> >http://www.cinsoft.net/position.html
>
> > Borders should be an easy exercise if you have been following along;
> > yes, even the right and bottom borders.  But why would your script be
> > interested in such styling, unless it is going to do scripted effects
> > involving borders?
>
> I like to the way emile.js, by Thomas Fuchs, deals with retrieving /
> modifying an element's style:
> <https://github.com/kangax/emile/blob/master/emile.js> - that's the
> Kangax's fork. It is very clever indeed because the normalize() function
> puts the browser to do the hard work for the code by means of a dummy
> element (parseEl).

I don't follow, but that looks like a large, monolithic, computed
style wrapper.  Who needs such a thing?

>
> > I've been using the CSS3 transitions/animations for some time now.
> > I've seen Opera, then Firefox (and finally IE 10) reproduce what
> > Webkit started and have been quite pleased with the consistency and
> > performance.  It takes little or no code to use those features.  So
> > use them and stop worrying about computed styles.
>
> Wonderful! But CSS3 is still a work in progress:
> <http://www.w3.org/Style/CSS/current-work.en.html>

Almost everything on that site is a work in progress, but the browser
vendors have their own competition going.  And when it comes to adding
special effects with "CSS3", they either work or they do nothing
(which is often an acceptable fallback for the older/lesser browsers).

>
> > Take out effects, computing styles, queries, and all of the other
> > topics covered so far in this series and what is there left for a
> > script like jQuery to do; other than take up space?  Pretty hard to
> > believe that ostensibly experienced developers are now trying to build
> > a "mobile framework" on top of jQuery.  All I can figure is they have
> > no idea what is in that script.  For them, I guess it's all about
> > marketing a name.  :(
>
> Unfortunately, John Resig has got a lot of spare time to dedicate to his
> creation, so that JQuery would hardly die in the near future...
> <http://ejohn.org/blog/next-steps-in-2011/>

It's already dead and 2011 is over.  All they can do is start over at
this point and I think they'll find that most of what defined jQuery
is no longer useful.  I mean, who needs a scripted query engine that
is incompatible with the Selectors API?  Certainly don't need scripted
effects either.  What's left?  A horrible attribute/property interface
that has caused only confusion?  An "addEvent" wrapper that doesn't
even set the - this - object for the listeners and leaks memory in IE?

It's almost like they've accomplished nothing over the last five
years.  All that is left is the name.  Designers love it (and they are
welcome to it).  Developers who've done their homework know it is has
always been poison.  But then you have the in-between types who
profess to be "expert" developers, but recommend jQuery anyway because
they want to appear sociable.  :)

[toc] | [prev] | [next] | [standalone]

#8956 — Re: David Mark's Daily Javascript Tips - Volume #3 - Tip #8 - How to Compute Styles

On Dec 6, 6:28 pm, David Mark <dmark.cins...@gmail.com> wrote:
> How to Compute Styles
>
> In a word, don't.  The recommendation followed by the browser vendors
> is long-winded and vague and historically browsers have varied in
> their interpretations.  The variety of results that must be parsed to
> derive meaning is a huge burden to bear and most applications don't
> need to compute any styles (let alone all possibilities!) in the first
> place.
>
> var getStyleComputed;
>
> // No "float" styles
> // Requires camel-case style names
> // Fades away in IE 8- and compatibility modes
>
> if (document.defaultView && document.defaultView.getComputedStyle) {
>           getStyleComputed = function(el, style) {
>             return document.defaultView.getComputedStyle(el, null)
> [style];
>           };
>
> }
>
> What's missing?  Can't handle "float" as it is a reserved word
> (property is "cssFloat" or "styleFloat", depending on
> implementation).  That's easy enough to detect, but how often do you
> need to compute the float style?
>
> Add a line during development:-
>
> if (document.defaultView && document.defaultView.getComputedStyle) {
>           getStyleComputed = function(el, style) {
>
>             if (style == 'float') {
>               throw new Error('RTFM! The "float" style is not
> supported by this rendition!');
>             }
>
>             return document.defaultView.getComputedStyle(el, null)
> [style];
>           };
>
> }
>
> ...and remove on release.
>
> Note that this function requires camel-case style names, not
> hyphenated.  That will save you a keystroke/byte.  ;)
>
> Add another line during development:-
>
> if (document.defaultView && document.defaultView.getComputedStyle) {
>           getStyleComputed = function(el, style) {
>
>             if (style.indexOf('-') != -1) {
>               throw new Error('Camel-case style names, please.');
>             }
>
>             if (style == 'float') {
>               throw new Error('RTFM! The "float" style is not
> supported by this rendition!');
>             }
>

And how about:-

              if (el.style.display == 'none') {
                throw new Error('Element not in layout. Cannot compute
styles.');
              }

...as any calling code that passes an element that is not part of the
layout (presumably removed by the script) is clearly making a
mistake.  Computed styles have no meaning in that context.

Best to fail immediately so the developer can follow the stack trace
back to the offending code.

Again, remove such "scaffolding" on deployment, at which time should
be rendered no-ops anyway (else testers missed something).

And, of course, some libraries and frameworks will try like hell to
make sense out of such illogical situations, shielding the developers
from fundamental misunderstandings in their own code.  They call it
being "forgiving".  In general, it's just stupid to write an API like
that.  For browser scripting, it's certainly ill advised and writing
things like UI widgets with such a "forgiving" API is madness.

And that's where the lists of "approved" browsers creep in, to let
developers know these monoliths  can't possibly be expected to work in
anything but the last five or six browsers tested.  They just have no
idea beyond that (and refuse to find out).  Anything else, past or
future, is your own problem; you saw the browser icons when you
downloaded the library.  :(

>             return document.defaultView.getComputedStyle(el, null)
> [style];
>           };
>
> }

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web