[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.javascript

DOM style object property names with vendor prefixes

Chris Beall

10/27/2014 8:31:00 PM

I occasionally use JavaScript to dynamically modify style sheets. This
requires that I know the DOM equivalent of CSS property names. For
example: CSS property name 'animation-duration' becomes DOM name
'animationDuration'. The general conversion formula seems to be: remove
hyphens and capitalize the next letter (camel case).

But, for bleeding-edge functions, it often becomes necessary to add
vendor-specific prefixes. If there's a standard rule for that syntax, I
haven't found it and would appreciate a pointer or two. Example:
'-moz-animation-duration' seems to become 'MozAnimationDuration', but
'-webkit-animation-duration' seems to become 'webkitAnimationDuration',
i.e. a different case pattern. 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.

I would appreciate authoritative references.

Chris Beall
31 Answers

Michael Haufe (\"TNO\")

10/27/2014 9:08:00 PM

0

On Monday, October 27, 2014 3:31:03 PM UTC-5, Chris Beall wrote:
> I occasionally use JavaScript to dynamically modify style sheets. This
> requires that I know the DOM equivalent of CSS property names. For
> example: CSS property name 'animation-duration' becomes DOM name
> 'animationDuration'. The general conversion formula seems to be: remove
> hyphens and capitalize the next letter (camel case).
>
> But, for bleeding-edge functions, it often becomes necessary to add
> vendor-specific prefixes. If there's a standard rule for that syntax, I
> haven't found it and would appreciate a pointer or two. Example:
> '-moz-animation-duration' seems to become 'MozAnimationDuration', but
> '-webkit-animation-duration' seems to become 'webkitAnimationDuration',
> i.e. a different case pattern. 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.
>
> I would appreciate authoritative references.

You can use the browsers' built-in DOM inspectors. For example, in Firefox type document.documentElement in the console then click the reference. In the properties window expand the style object and you'll see a list of properties.

Thomas 'PointedEars' Lahn

10/27/2014 9:20:00 PM

0

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. Also be
aware that you can generate and append those stylesheets with client-side
DOM scripting, should it be necessary:

<http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-2141...

> If there's a standard rule for that syntax, I haven't found it and would
> appreciate a pointer or two. Example: '-moz-animation-duration' seems to
> become 'MozAnimationDuration', but '-webkit-animation-duration' seems to
> become 'webkitAnimationDuration', i.e. a different case pattern.

You can also use the getPropertyValue(), removeProperty(), and setProperty()
methods of the CSSStyleDeclaration interface, which take the original
(hyphenated) CSS property names as arguments:

<http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-CSSStyleDecla...
<http://www.w3.org/TR/2011/WD-cssom-201...
<http://dev.w3.org/csswg/cssom/#the-cssstyledeclaration-int...
<https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleDecla...

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

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

<http://devtoolsecret... (also in the FAQ)

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

Chris Beall

10/27/2014 9:44:00 PM

0

On Mon, 27 Oct 2014 17:07:56 -0400, Michael Haufe (TNO)
<tno@thenewobjective.com> wrote:

> On Monday, October 27, 2014 3:31:03 PM UTC-5, Chris Beall wrote:
>> I occasionally use JavaScript to dynamically modify style sheets. This
>> requires that I know the DOM equivalent of CSS property names. For
>> example: CSS property name 'animation-duration' becomes DOM name
>> 'animationDuration'. The general conversion formula seems to be: remove
>> hyphens and capitalize the next letter (camel case).
>>
>> But, for bleeding-edge functions, it often becomes necessary to add
>> vendor-specific prefixes. If there's a standard rule for that syntax, I
>> haven't found it and would appreciate a pointer or two. Example:
>> '-moz-animation-duration' seems to become 'MozAnimationDuration', but
>> '-webkit-animation-duration' seems to become 'webkitAnimationDuration',
>> i.e. a different case pattern. 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.
>>
>> I would appreciate authoritative references.
>
> You can use the browsers' built-in DOM inspectors. For example, in
> Firefox type document.documentElement in the console then click the
> reference. In the properties window expand the style object and you'll
> see a list of properties.

Yes, that's how I got the answer for Firefox. I've had less success with
the others, probably because I'm unfamiliar with their inspection tools.
I will continue trying, but it seems (to me, anyway) that documentation of
the DOM names should appear right along with that for the vendor's CSS
prefix names, rather than forcing the developer to inspect the resulting
structure.

But thanks for the suggestion.

Chris Beall

Chris Beall

10/27/2014 10:12:00 PM

0

On Mon, 27 Oct 2014 17:20:22 -0400, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

> 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.
Could you elaborate?
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.

> Also be
> aware that you can generate and append those stylesheets with client-side
> DOM scripting, should it be necessary:
>
> <http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-2141...

Yes. I can see the value of that if many style properties are to be
changed. I haven't had the need to do that.

> You can also use the getPropertyValue(), removeProperty(), and
> setProperty()
> methods of the CSSStyleDeclaration interface, which take the original
> (hyphenated) CSS property names as arguments:

That might simplify my life in the future. I'll take a look.

> <http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-CSSStyleDecla...
> <http://www.w3.org/TR/2011/WD-cssom-201...
> <http://dev.w3.org/csswg/cssom/#the-cssstyledeclaration-int...
> <https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleDecla...
>
>> 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.

>
>> 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.
>
> <http://devtoolsecret... (also in the FAQ)
>

Excellent! Thanks you,

Chris Beall

Thomas 'PointedEars' Lahn

10/27/2014 10:46:00 PM

0

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.

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

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

3. A selector can apply to more than one element, so you do not need to
duplicate code, which makes maintenance easier.

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

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;
}

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.

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

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

>>> 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.
>>
>> <http://devtoolsecret... (also in the FAQ)
>
> Excellent! Thanks you,

You're welcome.

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

Andrew Poulos

10/27/2014 10:48:00 PM

0

On 28/10/2014 8:07 AM, Michael Haufe (TNO) wrote:

> You can use the browsers' built-in DOM inspectors. For example, in
> Firefox type document.documentElement in the console then click the
> reference. In the properties window expand the style object and
> you'll see a list of properties.

When I open the console in Firefox its (the browser) is making an
unending number of requests. For example:


"Policy document request to
https://quantserve.com/.well-known/dnt-... returned with status
404" policyCheck.js:146
"Policy document request to
https://youtube.com/.well-known/dnt-... returned with status 404"
policyCheck.js:146
"Policy document request to
https://scorecardresearch.com/.well-known/dnt-... returned with
status 404" policyCheck.js:146
"Policy document request to
https://avatraffic.com/.well-known/dnt-... returned with status
404" policyCheck.js:146
"Policy document request to
https://google.com/.well-known/dnt-... returned with status 404"
policyCheck.js:146
doubleclick.net:443 uses an invalid security certificate.

The certificate is only valid for *.doubleclick.net

(Error code: ssl_error_bad_cert_domain)


What's going on? Why is Firefox calling/running policyCheck.js? Is it
something to do with the add-ons I have loaded?

Andrew Poulos

Chris Beall

10/28/2014 12:38:00 AM

0

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 trigge=
red
>>> 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 =E2=80=9Cclass=E2=80=9D attribute. It=
was designed for
> that, too. You can use the =E2=80=9CclassName=E2=80=9D and (more rece=
ntly) the =

> =E2=80=9CclassList=E2=80=9D
> 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 on=
e =

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 t=
o
> 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 s=
ame =

way, you later have to go back and separate out the style for the =

different elements. Having guessed wrong on several occasions, I tend t=
o =

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 styleshee=
t, =

so I don't do that.

>> Usage example: A long list, such as a timeline of events. Events fal=
l
>> 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 c=
an
>> 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 a=
m
>> 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 =E2=80=9CclassName=E2=80=9D/=
=E2=80=9CclassList=E2=80=9D =

> 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'. S=
o =

I really need to change only one property, display. As noted above, I a=
m =

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 =E2=80=9Chidden=E2=80=9D C=
SS class on the
> element and that would not have changed.

I have discovered that new knowledge appears faster than I can learn, su=
ch =

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 expla=
in.

> Or consider a descendant element=E2=80=99s CSS properties changing con=
siderably
> 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 nam=
es.
>> 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 y=
et =

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 buil=
t
>>> 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, no=
t =

DOM objects. That's not the same as auto-completion, but I'll need more=
=

time to try that.

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

Thanks again,
Chris Beall

Chris Beall

10/28/2014 3:20:00 AM

0

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.

I have adjusted this in the Opera accounts.ini file on the Followup= line,
which I eventually found (on OS X 10.8.5) at
Users/MyUserName/Library/Application Support/Opera/mail/ and using the
parameters documented at
http://www.opera.com/help/tutorials/mail/adva...

What could be more obvious...

Chris Beall

Michael Haufe (\"TNO\")

10/28/2014 5:45:00 AM

0

On Monday, October 27, 2014 5:52:36 PM UTC-5, Andrew Poulos wrote:
> On 28/10/2014 8:07 AM, Michael Haufe (TNO) wrote:
>
> > You can use the browsers' built-in DOM inspectors. For example, in
> > Firefox type document.documentElement in the console then click the
> > reference. In the properties window expand the style object and
> > you'll see a list of properties.
>
> When I open the console in Firefox its (the browser) is making an
> unending number of requests. For example:
>
>
> "Policy document request to
> https://quantserve.com/.well-known/dnt-... returned with status
> 404" policyCheck.js:146
> "Policy document request to
> https://youtube.com/.well-known/dnt-... returned with status 404"
> policyCheck.js:146
> "Policy document request to
> https://scorecardresearch.com/.well-known/dnt-... returned with
> status 404" policyCheck.js:146
> "Policy document request to
> https://avatraffic.com/.well-known/dnt-... returned with status
> 404" policyCheck.js:146
> "Policy document request to
> https://google.com/.well-known/dnt-... returned with status 404"
> policyCheck.js:146
> doubleclick.net:443 uses an invalid security certificate.
>
> The certificate is only valid for *.doubleclick.net
>
> (Error code: ssl_error_bad_cert_domain)
>
>
> What's going on? Why is Firefox calling/running policyCheck.js? Is it
> something to do with the add-ons I have loaded?

I think your browser has something analogous to an STD... I wouldn't be surprised if you have something unwelcome installed in at least your browser(s)

Andrew Poulos

10/28/2014 8:32:00 AM

0

On 28/10/2014 4:45 PM, Michael Haufe (TNO) wrote:
> On Monday, October 27, 2014 5:52:36 PM UTC-5, Andrew Poulos wrote:
>> On 28/10/2014 8:07 AM, Michael Haufe (TNO) wrote:
>>
>>> You can use the browsers' built-in DOM inspectors. For example,
>>> in Firefox type document.documentElement in the console then
>>> click the reference. In the properties window expand the style
>>> object and you'll see a list of properties.
>>
>> When I open the console in Firefox its (the browser) is making an
>> unending number of requests. For example:
>>
>>
>> "Policy document request to
>> https://quantserve.com/.well-known/dnt-... returned with
>> status 404" policyCheck.js:146 "Policy document request to
>> https://youtube.com/.well-known/dnt-... returned with status
>> 404" policyCheck.js:146 "Policy document request to
>> https://scorecardresearch.com/.well-known/dnt-... returned
>> with status 404" policyCheck.js:146 "Policy document request to
>> https://avatraffic.com/.well-known/dnt-... returned with
>> status 404" policyCheck.js:146 "Policy document request to
>> https://google.com/.well-known/dnt-... returned with status
>> 404" policyCheck.js:146 doubleclick.net:443 uses an invalid
>> security certificate.
>>
>> The certificate is only valid for *.doubleclick.net
>>
>> (Error code: ssl_error_bad_cert_domain)
>>
>>
>> What's going on? Why is Firefox calling/running policyCheck.js? Is
>> it something to do with the add-ons I have loaded?
>
> I think your browser has something analogous to an STD... I wouldn't
> be surprised if you have something unwelcome installed in at least
> your browser(s)

Even with all addons disabled Firefox is still calling

http://googleads.g.doubleclick.net/p......
http://www.google-analytics.com/......
http://www.gstatic.com/pub-config/ca-pub-065144857...
http://pagead2.googlesyndication.com/a......

In all it makes 27 calls on launch.

Is it because Google is the default search engine. Though none of my
other browsers (IE, Chrome, Opera...) make any unexpected calls.

Andrew Poulos