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

Groups > comp.lang.javascript > #8971

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

Show all headers | View raw

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

Back to comp.lang.javascript | Previous | Next — Previous 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