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


Groups > comp.lang.javascript > #8954

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

From "J.R." <groups_jr-1@yahoo.com.br>
Newsgroups comp.lang.javascript
Subject Re: David Mark's Daily Javascript Tips - Volume #3 - Tip #8 - How to Compute Styles
Date 2011-12-07 00:14 -0200
Organization Aioe.org NNTP Server
Message-ID <jbmi5l$44n$1@speranza.aioe.org> (permalink)
References <dbc6cca4-9596-496b-acaf-e98eb06cf721@n6g2000vbg.googlegroups.com>

Show all headers | View raw


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.)

Back to comp.lang.javascript | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web