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

Groups > comp.lang.javascript > #26013

Re: DOM style object property names with vendor prefixes

Show all headers | View raw

Chris Beall wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Chris Beall wrote:
>>> […] Thomas 'PointedEars' Lahn […] wrote:
>>> Could you elaborate?
>> […]
>> It is prudent to separate scripts and stylesheets.  There are several
>> advantages:
>> […]
>> 3. A selector can apply to more than one element, so you do not need to
>>    duplicate code, which makes maintenance easier.
> 
> True.  My limited experience has shown me that in such cases:
>   - a parent can often be styled, with inheritance operating to minimize
> duplicate code.

Do you mean inheritance of style property declarations?

>   - if you guess wrong about what things will forever be styled in the
>   same way, you later have to go back and separate out the style for the
> different elements.  Having guessed wrong on several occasions, I tend to
> keep them separate to begin with.

Yes, the better solution requires more thinking in advance.

>   - (specific to me) The various browsers construct the DOM tree
> differently in some cases,

That would be surprising.  With *Valid* markup, I have, to my knowledge, 
never gotten different document trees in 14 years of professional Web 
development.  Have you used <http://validator.w3.org/>?

> one of them being the use of selector grouping.

Meaning?

> That would confuse the function I use to modify the stylesheet, so I don't
> do that.

That is a circular reasoning, is it not?  You only have those problems in 
the first place *because* you have been using the equivalent of inline style 
declarations instead of style*sheets*.
 
>>> […]  To allow the user to filter the list, excluding (hiding) items in a
>>> certain bucket, I can either (and I'm sure there are other ways...):
>>>   - find each item in the list with class'X' and change it to class
>>> 'Xprime' (which has been previously styled as display: none)
>>>   - find the CSS style for the specified class and change its display
>>> property to 'none'.
>>> I've chosen the latter, and have detected no downside.

The downside is that the class name does not mean anything anymore.  You 
cannot tell by looking at the element(’s className/classList property) what 
gvisual state it is in; you need to get the computed/style each time, or you 
need a meta-variable to provide that information.  You also need, in the 
best case, to establish a mapping from a selector to a style rule, which you 
otherwise would not.  And you would need to make sure that you modify the 
*relevant* rule, and avoid side-effects (the class/selector needs to be used 
exclusively for filtering), which can be complicated with a not-so-simple 
stylesheet.  So while certainly elegant in a certain way, the result of that 
approach is much less efficient and more error-prone.  It could even be less 
backwards-compatible.

>>> Note that I am changing only a single property in a single DOM object,
>>> rather than changing the class in many DOM objects.
>> Your own deliberations show that with the “className”/“classList”
>> approach you would only change the class of one DOM object as well.
> 
> Um, no.  As stated above, I would have to change the class attribute of
> 'each' element that specifies the target class.  Or did I misunderstand?

We have different approaches at filtering.  I would not modify stylesheets 
for a filter; indeed I do not, see the Features table in the ECMAScript 
Support Matrix (where you can see that the class-name-based approach for 
that is still on my to-do list).

For implementing the class-name-based approach, you would replace

  foo.style.display = "none";
  // …
  foo.style.display = "";

with, e.g.,

  foo.className += " hidden";
  …
  foo.className = foo.className.replace(/(^\s*|\s+)hidden(\s+|\s*$)/g, "");

or

  foo.classList.add("hidden");
  // …
  foo.classList.remove("hidden");

(or wrappers of both).

So there is only one element per item to hide, represented by the object 
referred to by “foo”, with either approach, that needs modification.  Only 
that with the latter, if you would want to set more/different style 
properties, you would not need to write more/different statements.
 
>> Here, one advantage of the former approach is that you can modify the
>> stylesheet to use CSS transitions by replacing
>>
>>   li.hidden {
>>     display: none;
>>   }
>>
>> with, e.g.,
>>
>>   li {
>>     opacity: 1;
>>     width: 42px;
>>     transition: all 0.25s;
>>   }
>>
>>   li.hidden {
>>     opacity: 0;
>>     width: 0;
>>     transition: all 0.25s;
>>   }
> 
> If I've interpreted that correctly, it would cause the list item to
> collapse to the left, gradually fading away in 1/4 second.  But the item
> still would occupy space,

That depends on whether the list is horizontal (floating) or vertical.  For 
a vertical list (default), you could set the height property instead, or 
both properties.  You might also need to set “overflow: hidden”.  It was 
just a quick hack.

The “42px” also is just an example; usually you would use “em” units.  
Unfortunately, you cannot yet have a non-scripted property transition where 
on one end point an animated property has the “auto” value, for example.

> which isn't quite what I meant by 'hiding'.  So I really need to change
> only one property, display.

That depends on whether you want a smooth transition, improving the user 
experience, or not:

<http://www.nngroup.com/articles/animation-usability/>

>> You could then even use, e.g., LESS to make it more obvious and, with
>> mix-ins, be more compatible without writing much more:
>>
>>   li {
>>     width: 42px;
>>     .opacity(1);
>>     .transition(all 0.25s);
>>
>>     &.hidden {
>>       width: 0;
>>       .opacity(0);
>>       .transition(all 0.25s);
>>     }
>>   }
>>
>> And you would not have to change a single line of script code to make it
>> happen, because the script only toggles the “hidden” CSS class on the
>> element and that would not have changed.
> 
> I have discovered that new knowledge appears faster than I can learn, such
> that, on a percentage basis, I know less every day.  In this case I am
> totally mystified by the '&.hidden' notation in the above.  Please
> explain.

In LESS, the ”&” character is a stand-in for the outer selector, so that you 
do not have to repeat it; with the exception of the mix-ins (“.xyz(…)”), the 
LESS code is equivalent to the CSS code I posted earlier.  The possibility 
to implement DRY in stylesheets, because unfortunately CSS does not provide 
the means (yet?), is the key feature of CSS preprocessors like LESS (whose 
name is not a coincidence).

<http://lesscss.org/>
<http://sass-lang.com/>
 
>>>>> When I say 'seems to become' I am referring to the results of
>>>>> experimentation on my part, which may be erroneous and which is
>>>>> complicated by the fact that some browsers don't seem to support
>>>>> modification of vendor-specific values at all.
>>>> Such as?
>>> So far: IE, Chrome, Safari.  I'm probably not using the right DOM names.
>>> More investigation needed.
>> ACK.  I was more interested in the properties whose value appeared to be
>> constant.
> 
> Sorry, I don't follow.  I have had no difficulty modifying W3C-specified
> values, only those that precede them in time as a new function is being
> developed, i.e. those with vendor-specific prefixes.

Yes, and I wondered which properties, whose value did not change, you have 
attempted to change and how.  (Which browser is secondary, and with prefixed 
properties the targeted layout engine can be inferred from the property 
name.)

>>>>> I would appreciate authoritative references.
>>>> Since both are OSS: UTSL.  You can also use the auto-completion built
>>>> into the corresponding developer tools to find out.
> 
> I will look into that.  I did (just) try to use the IE DOM explorer, but
> the format of property names it showed me was that of CSS properties, not
> DOM objects.  That's not the same as auto-completion, but I'll need more
> time to try that.

Indeed, IE (11)’s “DOM Explorer” has been carelessly misnamed by Micro$~1; 
however, using the Console and, for example,

  document.defaultView.getComputedStyle(targetElemObj, pseudoElem_opt)

you can get some of the missing information.

Firebug Lite can fill the gap more nicely.


Please read the FAQ on quoting.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

Thread

DOM style object property names with vendor prefixes "Chris Beall" <Chris_Beall@prodigy.net> - 2014-10-27 16:30 -0400
  Re: DOM style object property names with vendor prefixes "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-10-27 14:07 -0700
    Re: DOM style object property names with vendor prefixes "Chris Beall" <Chris_Beall@prodigy.net> - 2014-10-27 17:43 -0400
    Re: DOM style object property names with vendor prefixes Andrew Poulos <ap_prog@hotmail.com> - 2014-10-28 09:48 +1100
      Re: DOM style object property names with vendor prefixes "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-10-27 22:45 -0700
        Re: DOM style object property names with vendor prefixes Andrew Poulos <ap_prog@hotmail.com> - 2014-10-28 19:31 +1100
          Re: DOM style object property names with vendor prefixes "Chris Beall" <Chris_Beall@prodigy.net> - 2014-10-28 09:59 -0400
          Re: DOM style object property names with vendor prefixes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-10-28 15:26 +0100
          Re: DOM style object property names with vendor prefixes Andrew Poulos <ap_prog@hotmail.com> - 2014-10-31 12:29 +1100
  Re: DOM style object property names with vendor prefixes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-10-27 22:20 +0100
    Re: DOM style object property names with vendor prefixes "Chris Beall" <Chris_Beall@prodigy.net> - 2014-10-27 18:11 -0400
      Re: DOM style object property names with vendor prefixes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-10-27 23:45 +0100
        Re: DOM style object property names with vendor prefixes "Chris Beall" <Chris_Beall@prodigy.net> - 2014-10-27 20:38 -0400
          Re: DOM style object property names with vendor prefixes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-10-28 19:49 +0100
            Re: DOM style object property names with vendor prefixes "Chris Beall" <Chris_Beall@prodigy.net> - 2014-10-28 17:56 -0400
              Re: DOM style object property names with vendor prefixes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-10-29 21:07 +0100
                Re: DOM style object property names with vendor prefixes "Chris Beall" <Chris_Beall@prodigy.net> - 2014-10-30 12:50 -0400
                Re: DOM style object property names with vendor prefixes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-10-30 19:13 +0100
                Re: DOM style object property names with vendor prefixes "Chris Beall" <Chris_Beall@prodigy.net> - 2014-10-30 17:17 -0400
                Re: DOM style object property names with vendor prefixes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-10-31 20:35 +0100
        Re: DOM style object property names with vendor prefixes "Chris Beall" <Chris_Beall@prodigy.net> - 2014-10-27 23:19 -0400
          Re: DOM style object property names with vendor prefixes John Harris <niam@jghnorth.org.uk.invalid> - 2014-10-28 10:11 +0000
            Re: DOM style object property names with vendor prefixes Tim Streater <timstreater@greenbee.net> - 2014-10-28 11:42 +0000
              Re: DOM style object property names with vendor prefixes "Chris Beall" <Chris_Beall@prodigy.net> - 2014-10-28 09:52 -0400
            Re: DOM style object property names with vendor prefixes "Chris Beall" <Chris_Beall@prodigy.net> - 2014-10-28 09:49 -0400
              Re: DOM style object property names with vendor prefixes John Harris <niam@jghnorth.org.uk.invalid> - 2014-10-29 15:48 +0000
          Re: DOM style object property names with vendor prefixes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-10-28 15:54 +0100
        Re: DOM style object property names with vendor prefixes Scott Sauyet <scott.sauyet@gmail.com> - 2014-10-30 08:12 -0700
  Re: DOM style object property names with vendor prefixes Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2014-10-29 15:23 -0200
    Re: DOM style object property names with vendor prefixes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-10-29 21:47 +0100
      Re: DOM style object property names with vendor prefixes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-10-30 07:32 +0100
    Re: DOM style object property names with vendor prefixes "Chris Beall" <Chris_Beall@prodigy.net> - 2014-10-30 10:47 -0400

csiph-web