Re: DOM style object property names with vendor prefixes

From	"Chris Beall" <Chris_Beall@prodigy.net>
Newsgroups	comp.lang.javascript
Subject	Re: DOM style object property names with vendor prefixes
Date	2014-10-27 20:38 -0400
Organization	minimal
Message-ID	<op.xoez15kttnmj2w@cbealls-imac.local> (permalink)
References	<op.xoeolsddtnmj2w@cbealls-imac.local> <83210457.YLdJyC3XC5@PointedEars.de> <op.xoes9kehtnmj2w@cbealls-imac.local> <2636975.CJeWhIb7Se@PointedEars.de>

Show all headers | View raw

Thomas 'PointedEars' Lahn wrote:

> Chris Beall wrote:
>
>> On Mon, 27 Oct 2014 17:20:22 -0400, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>
> Please do not post attribution novels.

You must be accustomed to very short novels  :-)
In any case, the Opera newsreader includes all that garbage and I have  
been unable to find where it can be turned off.  I deleted the redundant  
part from this post so we don't get side-tracked.

>>> Chris Beall wrote:
>>>> But, for bleeding-edge functions, it often becomes necessary to add
>>>> vendor-specific prefixes.
>>>
>>> But preferably not with client-side DOM scripting.  In general, CSS
>>> properties should be specified in a stylesheet that is merely triggered
>>> with scripting, for example by toggling CSS class names on elements.
>>
>> I've noticed that modifying style sheets seems to be less used, but I'm
>> uncertain as to why modifying element attributes would be preferred.
>
> Not just any attribute, but the “class” attribute.  It was designed for
> that, too.  You can use the “className” and (more recently) the  
> “classList”
> properties to modify it.
>
>> Could you elaborate?
>
> (Do not ask a Yes-or-No question unless you want either Yes or No for an
> answer.)
>
> It is prudent to separate scripts and stylesheets.  There are several
> advantages:
>
> 1. You can switch several stylesheet property values at once that way,
>    context-sensitively.

Agreed, but to date the cases I have dealt with have been confined to one  
or two values.  I am not doing commercial work and my pages tend to be  
simple.

> 2. You can do it as a fallback in case a more complex CSS selector is not
>    supported.

Simplicity has thus far saved me from dealing with complex CSS selectors.

> 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.
  - 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.
  - (specific to me) The various browsers construct the DOM tree  
differently in some cases, one of them being the use of selector  
grouping.  That would confuse the function I use to modify the stylesheet,  
so I don't do that.

>> Usage example: A long list, such as a timeline of events.  Events fall
>> into different buckets, some of which are not mutually exclusive, and
>> these are identified by class names on each list item.  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.  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?

> 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, which isn't quite what I meant by 'hiding'.  So  
I really need to change only one property, display.  As noted above, I am  
typically changing only 1 or 2 properties at a time.  I do see the  
advantage of your approach if, for example, a different skin, changing  
many properties, is being applied.

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

> Or consider a descendant element’s CSS properties changing considerably
> because the classes of an ancestor element changed.  It is much more
> difficult, less efficient, and the result is less intuitive if you  
> scripted
> the style properties directly (BTDT).

Got that.

>>>> 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.  Perhaps I do not yet  
have the correct format of those names within the DOM (case, in  
particular).  As I recall, that was my original concern.

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

>>>
>>> <http://devtoolsecrets.com/> (also in the FAQ)

Thanks again,
   Chris Beall

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