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

Groups > comp.lang.javascript > #25991 > unrolled thread

DOM style object property names with vendor prefixes

Back to article view | Back to comp.lang.javascript

Contents

  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

Page 1 of 2  [1] 2  Next page →

#25991 — DOM style object property names with vendor prefixes

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

[toc] | [next] | [standalone]

#25993

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.

[toc] | [prev] | [next] | [standalone]

#25995

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

[toc] | [prev] | [next] | [standalone]

#25998

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-policy.txt returned with status 
404" policyCheck.js:146
"Policy document request to 
https://youtube.com/.well-known/dnt-policy.txt returned with status 404" 
policyCheck.js:146
"Policy document request to 
https://scorecardresearch.com/.well-known/dnt-policy.txt returned with 
status 404" policyCheck.js:146
"Policy document request to 
https://avatraffic.com/.well-known/dnt-policy.txt returned with status 
404" policyCheck.js:146
"Policy document request to 
https://google.com/.well-known/dnt-policy.txt 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

[toc] | [prev] | [next] | [standalone]

#26001

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-policy.txt returned with status 
> 404" policyCheck.js:146
> "Policy document request to 
> https://youtube.com/.well-known/dnt-policy.txt returned with status 404" 
> policyCheck.js:146
> "Policy document request to 
> https://scorecardresearch.com/.well-known/dnt-policy.txt returned with 
> status 404" policyCheck.js:146
> "Policy document request to 
> https://avatraffic.com/.well-known/dnt-policy.txt returned with status 
> 404" policyCheck.js:146
> "Policy document request to 
> https://google.com/.well-known/dnt-policy.txt 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)

[toc] | [prev] | [next] | [standalone]

#26002

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-policy.txt returned with
>> status 404" policyCheck.js:146 "Policy document request to
>> https://youtube.com/.well-known/dnt-policy.txt returned with status
>> 404" policyCheck.js:146 "Policy document request to
>> https://scorecardresearch.com/.well-known/dnt-policy.txt returned
>> with status 404" policyCheck.js:146 "Policy document request to
>> https://avatraffic.com/.well-known/dnt-policy.txt returned with
>> status 404" policyCheck.js:146 "Policy document request to
>> https://google.com/.well-known/dnt-policy.txt 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/pagead/ads?...
http://www.google-analytics.com/__utm.gif?...
http://www.gstatic.com/pub-config/ca-pub-0651448570352947.js
http://pagead2.googlesyndication.com/activeview?...

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

[toc] | [prev] | [next] | [standalone]

#26010

Andrew Poulos wrote:

> 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-policy.txt returned with
>>> status 404" policyCheck.js:146 "Policy document request to
>>> https://youtube.com/.well-known/dnt-policy.txt returned with status
>>> 404" policyCheck.js:146 "Policy document request to
>>> https://scorecardresearch.com/.well-known/dnt-policy.txt returned
>>> with status 404" policyCheck.js:146 "Policy document request to
>>> https://avatraffic.com/.well-known/dnt-policy.txt returned with
>>> status 404" policyCheck.js:146 "Policy document request to
>>> https://google.com/.well-known/dnt-policy.txt 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/pagead/ads?...
> http://www.google-analytics.com/__utm.gif?...
> http://www.gstatic.com/pub-config/ca-pub-0651448570352947.js
> http://pagead2.googlesyndication.com/activeview?...
>
> 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

If you have the Privacy Badger add-on installed, you might want to read
https://github.com/EFForg/privacybadgerfirefox/issues/225
which has recently been 'fixed'.

And please, in the future, start your own thread, with a meaningful  
Subject, when introducing a new topic, rather than piggy-backing on an  
unrelated open thread.

Chris Beall

[toc] | [prev] | [next] | [standalone]

#26011

Andrew Poulos wrote:

> 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-policy.txt returned with
>>> status 404" policyCheck.js:146
>>> […]
> 
> […]
> Is it because Google is the default search engine. Though none of my
> other browsers (IE, Chrome, Opera...) make any unexpected calls.

With Google being your default search engine, you could have used it.

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

[toc] | [prev] | [next] | [standalone]

#26058

On 28/10/2014 7:31 PM, Andrew Poulos wrote:
> 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-policy.txt returned with
>>> status 404" policyCheck.js:146 "Policy document request to
>>> https://youtube.com/.well-known/dnt-policy.txt returned with status
>>> 404" policyCheck.js:146 "Policy document request to
>>> https://scorecardresearch.com/.well-known/dnt-policy.txt returned
>>> with status 404" policyCheck.js:146 "Policy document request to
>>> https://avatraffic.com/.well-known/dnt-policy.txt returned with
>>> status 404" policyCheck.js:146 "Policy document request to
>>> https://google.com/.well-known/dnt-policy.txt 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/pagead/ads?...
> http://www.google-analytics.com/__utm.gif?...
> http://www.gstatic.com/pub-config/ca-pub-0651448570352947.js
> http://pagead2.googlesyndication.com/activeview?...
>
> 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.

I manually updated the addon "Privacy Badger Firefox" from 0.2.2 to 
0.2.3 and the calls to unexpected web sites have stopped. I don't 
remember where I got 0.2.2 from but I got 0.2.3 directly from the EFF 
web site.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#25994

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

> 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-CSSStyleDeclaration>
<http://www.w3.org/TR/2011/WD-cssom-20110712/>
<http://dev.w3.org/csswg/cssom/#the-cssstyledeclaration-interface>
<https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleDeclaration>

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

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

[toc] | [prev] | [next] | [standalone]

#25996

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

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-CSSStyleDeclaration>
> <http://www.w3.org/TR/2011/WD-cssom-20110712/>
> <http://dev.w3.org/csswg/cssom/#the-cssstyledeclaration-interface>
> <https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleDeclaration>
>
>> 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://devtoolsecrets.com/> (also in the FAQ)
>

Excellent!  Thanks you,

Chris Beall

[toc] | [prev] | [next] | [standalone]

#25997

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

You're welcome.

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

[toc] | [prev] | [next] | [standalone]

#25999

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

[toc] | [prev] | [next] | [standalone]

#26013

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.

[toc] | [prev] | [next] | [standalone]

#26014

Thomas 'PointedEars' Lahn wrote:

> Chris Beall wrote:
(snip)
> Do you mean inheritance of style property declarations?

Yes.

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

I will agree with 'better under certain circumstances'.  I suspect you  
encounter those circumstances more often than I do.  Fair enough.

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

Often.  Sometimes not often enough.  And things change over time, but I  
have seen:
- If a CSS selector uses multiple class names, IE reverses their order in  
the DOM selectorText.
So if the CSS selector is .foo.bar, an attempt to find it in the DOM  
selectorText will fail, unless you search for .bar.foo
And I have been told (http://www.quirksmode.org/dom/changess.html#link4),  
but did not extensively research,
that some more complex selectors, such as groups, may be split into  
multiple rules within 'your browser', which I interpreted to mean 'the DOM  
as built by your browser'.

>> one of them being the use of selector grouping.

> Meaning?

a comma-separated list of selectors that share the same declarations.
http://www.w3.org/TR/CSS21/selector.html#grouping

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

Hmmm, seems linear to me.  I chose to go down a certain path (which is not  
the one that you prefer) and I'm sticking with it.  There are always  
consequences, but these are MY consequences.

(snip interesting but no longer relevant.  See way below.)
>
> We have different approaches at filtering.

Both valid.  I'll study yours further, but it is unrelated to this thread.

(snip)
>> 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:

This would lead us into philosophy of the user experience.  In this case I  
believe the user wants an instant response, not artistry.  I have used  
smooth transitions elsewhere, to good (IMO) effect.  I feel they are  
almost never a good idea except in response to a user action (although my  
current issue is related to just such an exception...)

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

Looks thoughtful.  I've bookmarked it.

>>> You could then even use, e.g., LESS

Suggestion: When using an acronym for the first time, spell it out in  
full, followed by the acronym within parentheses.  I interpreted this as a  
word, uppercased for emphasis, and hence did not understand the subsequent  
syntax.

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

animation_duration
and it turns out the change was being made, but not acted upon as I  
expected (more below)

> Please read the FAQ on quoting.

I'm familiar with the guidelines.  It is sometimes difficult to determine  
what of the foregoing discussion remains relevant.  I've tried to be more  
parsimonious this time.

CHANGE OF DIRECTION

As a result of testing, I have determined that I am, in fact, able to  
modify animation_duration within a specific CSS directive, so this topic  
is logically closed.  I was misinterpreting the reason for my symptom.

BUT, the modification, driven by <body onload=...>, does not take effect  
on the page as initially displayed, except in Firefox.  I will open a new  
thread shortly, with a live testcase.  The issue now seems to be related  
to the timing environment within which JavaScript executes, rather than  
anything in the language itself, but we shall see.

I do appreciate the responses to date.

Chris Beall

[toc] | [prev] | [next] | [standalone]

#26029

Chris Beall wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Chris Beall wrote:
> (snip)
>> Do you mean inheritance of style property declarations?
> 
> Yes.

OK, but surely you are aware that not all property values are inherited.  
Inheritance in CSS is formally specified, but can be unintuitive at times.

>>>   - (specific to me) The various browsers construct the DOM tree
>>> differently in some cases,
> […]
> - If a CSS selector uses multiple class names, IE reverses their order in
> the DOM selectorText.
> So if the CSS selector is .foo.bar, an attempt to find it in the DOM
> selectorText will fail, unless you search for .bar.foo
> And I have been told (http://www.quirksmode.org/dom/changess.html#link4),

Based on previous experience, I would advise greater care with statements on 
quirksmode.org.  Less than with w3schools.com, but still.

> but did not extensively research, that some more complex selectors, such
> as groups, may be split into multiple rules within 'your browser', which
> I interpreted to mean 'the DOM as built by your browser'.

I see.  But does that not show *again* that this/your current approach is 
inefficient, and unreliable at best?

I also do not think that style rules are part of the document tree.
 
>>> one of them being the use of selector grouping.
>> Meaning?
> 
> a comma-separated list of selectors that share the same declarations.
> http://www.w3.org/TR/CSS21/selector.html#grouping

ACK.  So you can also not modify the declarations of a ruleset without 
checking that it does not consist of grouped selectors, so that the 
modification would not have side-effects.  And if you wanted to, you would 
need to add a new rule (which could be impossible or hard to do), copying 
the declarations, and modifying the copied declaration.  But such rulesets 
are, in practice, more the rule than the exception (no pun intended) because 
of DRY.
 
>>> 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*.
> 
> Hmmm, seems linear to me.  I chose to go down a certain path (which is not
> the one that you prefer) and I'm sticking with it.  There are always
> consequences, but these are MY consequences.

Here is another approach that I think is superior to the other two (your 
current one and my first one) when it comes to *category*-based filtering.  

You can have the category name/identifier as class name on the corresponding 
(descendant) items, and you can have a selector that displays only those 
items that are enabled by the corresponding class in the ancestor/parent 
element.  That way you only need to modify the class name/list of the 
ancestor/parent if you wanted to change the items that are displayed, based 
on their class:

  ul.filtered.foo li.foo {
    /* or block, or transitions */
    display: list-item;
  }

But since items should not be hidden by default (think of NoScript & 
friends), it should be

  ul.filtered.no-foo li.foo {
    /* or transitions */
    display: none;
  }

With the latter approach, you could hide all items of category “foo” with 
the one-liner

  ul.className += " no-foo";

assuming that “ul” refers to the ancestor/parent element (here: an “ul” 
element).

>> We have different approaches at filtering.
> 
> Both valid.  I'll study yours further, but it is unrelated to this thread.

It is a common misconception, probably originating from bulletin boards on 
the Web, that a (Usenet) thread must not deal with more than one subject, 
and that for a new subject a new thread must be started, regardless how much 
connected it is with the original thread.

Instead, thread drift is normal, and if the subject of discussion changes 
considerably, the Subject header field value can and should be adjusted as 
follows:

  foo
  '- Re: foo
     '- bar (was: foo)
        '- Re: bar      

Several newsreader applications have built-in support for that approach in 
that they trim the “(was: …)” part automagically when replying.

>>>> You could then even use, e.g., LESS
> 
> Suggestion: When using an acronym for the first time, spell it out in
> full, followed by the acronym within parentheses.

Not feasible or useful (in Usenet).  There is no particular “first time” 
there to begin with.

> I interpreted this as a word, uppercased for emphasis,

Not recommended in Usenet, firstly because it means shouting instead (which
is considered impolite), and secondly because of misunderstandings of this 
kind.

The recommendations for text formatting in Usenet are: *bold/emphasized*, 
_underline/corrected_, and /italic/ (I use the last one for foreign words; 
there are others who use it for emphasis).  At least the Mozilla(/5.0)-based 
newsreaders implement it that way.

> and hence did not understand the subsequent syntax.

When someone knows CSS it can be assumed by now that at least the 
*existence* of LESS is common knowledge to them (it will be hard to find 
employment in Web development if you do not know what it is).  Especially 
here as there is an ECMAScript-based variant of LESS both server-side, for 
Node.js, and client-side.
 
> (snip)
>> 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.)
> 
> animation_duration
> and it turns out the change was being made, but not acted upon as I
> expected (more below)
> 
>> Please read the FAQ on quoting.
> 
> I'm familiar with the guidelines.  It is sometimes difficult to determine
> what of the foregoing discussion remains relevant.  I've tried to be more
> parsimonious this time.

You can trim, but you also can summarize quotes, using the “[summary]” 
notation.  I am somewhat forced not to quote too much because the well-
maintained server that I am using (news.solani.org) most of the time does 
not allow to post more quoted lines than new ones (I have not found out yet 
what the exact rules are), which is actually a Good Thing most of the time.  
Time is even more precious than bandwidth by now.
 
> As a result of testing, I have determined that I am, in fact, able to
> modify animation_duration within a specific CSS directive, so this topic
> is logically closed.  I was misinterpreting the reason for my symptom.
> 
> BUT, the modification, driven by <body onload=...>, does not take effect
> on the page as initially displayed, except in Firefox. 

There is no built-in “animation_duration” property in any common DOM 
implementation, so this cannot work.  (The Worst Case Scenario for an 
attempt to write it is an unrecoverable runtime error caused by a failed 
attempt to augment a host object.)

“animation-duration” translates to “animationDuration” aso. in scripts.  
Incidentally, today I have written (for a simplistic media query parser)
a very simplistic translator for that.  Basically, it is:

  var scriptedProperty = cssProperty.replace(/-(.)/g, function (m, p1) {
    return p1.toUpperCase();
  });

> I will open a new thread shortly, with a live testcase.

I would prefer not to have to read it; see above.

> The issue now seems to be related to the timing environment within which
> JavaScript executes, rather than anything in the language itself, but we
> shall see.

To prevent script-kiddies from wreaking havoc with a document, a window, or 
the browser as a whole, certain statements are not executed in a “load” 
event listener, and there may not even be a corresponding hint in the 
Console.

Mozilla-based browsers are particularly paranoid^Wrestrictive on such 
matters.  Recently I have discovered that they do not play() an “audio” 
element when the call is triggered from a timeout.

> I do appreciate the responses to date.

Noted.

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

[toc] | [prev] | [next] | [standalone]

#26044

Thomas 'PointedEars' Lahn wrote:

> Chris Beall wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
(snip)
> OK, but surely you are aware that not all property values are inherited.
> Inheritance in CSS is formally specified, but can be unintuitive at  
> times.

Yes and I agree.

(snip)

> Based on previous experience, I would advise greater care with  
> statements on
> quirksmode.org.  Less than with w3schools.com, but still.

I try to use care with statements from any source, including myself.  With  
regard to the reversal, by IE, of multiple class names, I verified it via  
experiment (around about IE 6, as I recall) and coded to compensate (two  
lines added).  It is possible this is no longer necessary, but even if so  
it would take longer to verify that IE has changed than purging the dead  
code would gain.

>> but did not extensively research, that some more complex selectors, such
>> as groups, may be split into multiple rules within 'your browser', which
>> I interpreted to mean 'the DOM as built by your browser'.
>
> I see.  But does that not show *again* that this/your current approach is
> inefficient, and unreliable at best?

It has been reliable for several years, cross-browser.  The current issue  
was confined to vendor-prefixes, which I usually avoid.  Since I now  
believe I have identified the correct naming syntax, even that issue is  
gone, leaving me with a totally-unrelated issue of timing of load-time DOM  
modification vs. initial rendering.

> I also do not think that style rules are part of the document tree.

If that were true, my modification of style rules would not work at all,  
but it does.
On Firefox, using Firebug, I see the following (greatly abridged)  
structure:
document
- styleSheets
-- 0 (and probably others, per length at this level)
--- cssRules
---- 0 (and probably others, per length at this level)
----- style
------ many many style property names and values, which can be modified  
and are acted upon by the UA

>
>>>> one of them being the use of selector grouping.
>>> Meaning?
>>
>> a comma-separated list of selectors that share the same declarations.
>> http://www.w3.org/TR/CSS21/selector.html#grouping
>
> ACK.  So you can also not modify the declarations of a ruleset without
> checking that it does not consist of grouped selectors, so that the
> modification would not have side-effects.

I do not have to check because I do not usually use grouped selectors and  
certainly not when I plan to modify the properties beneath them.

(snip)
> Here is another approach that I think is superior to the other two (your
> current one and my first one) when it comes to *category*-based  
> filtering.
>
> You can have the category name/identifier as class name on the  
> corresponding
> (descendant) items, and you can have a selector that displays only those
> items that are enabled by the corresponding class in the ancestor/parent
> element.  That way you only need to modify the class name/list of the
> ancestor/parent if you wanted to change the items that are displayed,  
> based
> on their class:
>
>   ul.filtered.foo li.foo {
>     /* or block, or transitions */
>     display: list-item;
>   }
>
> But since items should not be hidden by default (think of NoScript &
> friends), it should be
>
>   ul.filtered.no-foo li.foo {
>     /* or transitions */
>     display: none;
>   }
>
> With the latter approach, you could hide all items of category “foo” with
> the one-liner
>
>   ul.className += " no-foo";
>
> assuming that “ul” refers to the ancestor/parent element (here: an “ul”
> element).

I *think* I followed that, but I'm still not clear on the advantage.   
Perhaps that's because long ago, when I started modifying my list, I saw  
the need for a function, which I then wrote.  As a result, if I want to  
hide all the list items of class 'foo', I make a one-line call to that  
function.  An advantage for me is that no elaborate CSS selectors are  
needed and the function call provides concise documentation of what I am  
doing, helpful if I ever need to revise it.

I suspect the key difference in our approaches is that I am doing very  
simple things and you, apparently, are doing rather complex ones.

(snip)
> It is a common misconception, probably originating from bulletin boards  
> on
> the Web, that a (Usenet) thread must not deal with more than one subject,
(snip)

My preference derives from fora on something called VNET, which predates  
the web.  Keeping things to one subject helps to provide focus, especially  
for someone researching after-the-fact discussions.  As far as I can tell,  
there are very few 'must's on USENET.

>> Suggestion: When using an acronym for the first time, spell it out in
>> full, followed by the acronym within parentheses.
>
> Not feasible or useful (in Usenet).  There is no particular “first time”
> there to begin with.

How about 'first time within a thread'?  Again, while this may introduce  
some redundancy, I have found it helpful when trying to read a 4-year-old  
thread, outside the context of others from the period.

(snip)

> The recommendations for text formatting in Usenet are: *bold/emphasized*,
> _underline/corrected_, and /italic/ (I use the last one for foreign  
> words;
> there are others who use it for emphasis).  At least the  
> Mozilla(/5.0)-based
> newsreaders implement it that way.

Yes, but not everyone uses those and I had no way of knowing if you were  
among those who do not.  It is an unfortunate coincidence that the  
position of the word allowed for easy mis-interpretation.

>> and hence did not understand the subsequent syntax.
>
> When someone knows CSS it can be assumed by now that at least the
> *existence* of LESS is common knowledge to them (it will be hard to find
> employment in Web development if you do not know what it is).  Especially
> here as there is an ECMAScript-based variant of LESS both server-side,  
> for
> Node.js, and client-side.

Anything can be assumed.  It is always risky.  In this case your  
assumption was incorrect.  FYI, I am not seeking employment.

(snip)
> You can trim, but you also can summarize quotes, using the “[summary]”
> notation.
(snip)

I'll try to remember that.  I was not aware of it.  I have noticed that  
some people don't like to have their original words altered.

>
>> As a result of testing, I have determined that I am, in fact, able to
>> modify animation_duration within a specific CSS directive, so this topic
>> is logically closed.  I was misinterpreting the reason for my symptom.
>>
>> BUT, the modification, driven by <body onload=...>, does not take effect
>> on the page as initially displayed, except in Firefox.
>
> There is no built-in “animation_duration” property in any common DOM
> implementation, so this cannot work.

I apparently did not properly communicate what I was doing.  If you *do*  
decide to read the other thread referred to below, you can look at the  
testcase page that I provided there.

(snip)
>> I will open a new thread shortly, with a live testcase.
>
> I would prefer not to have to read it; see above.

Your choice.

Chris Beall

[toc] | [prev] | [next] | [standalone]

#26047

Chris Beall wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Chris Beall wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>> Based on previous experience, I would advise greater care with
>> statements on quirksmode.org.  Less than with w3schools.com, but still.
> 
> […] With regard to the reversal, by IE, of multiple class names, I
> verified it via experiment (around about IE 6, as I recall) and coded to
> compensate (two lines added).  It is possible this is no longer necessary,
> […]

I have tested something similar with IE 8 today (we have still customers 
using it) and at least the Developer Tools show multiple adjacent class 
selectors in different order than in the source code.  They appear to be 
sorted alphanumerically.
 
>>> but did not extensively research, that some more complex selectors, such
>>> as groups, may be split into multiple rules within 'your browser', which
>>> I interpreted to mean 'the DOM as built by your browser'.
>> I see.  But does that not show *again* that this/your current approach is
>> inefficient, and unreliable at best?
> 
> It has been reliable for several years, cross-browser.

For a distinct subset of stylesheets only.  I prefer general, reusable 
approaches that work in the target environments regardless how the code 
operated on is written.  I am not alone there.  And that is not because
I *am* doing commercial work; I do not-for-profit Web development in my
free time as well.  Working full-time, free time has become even more 
precious; I do not want to waste it on code rewrites.

>> I also do not think that style rules are part of the document tree.
> 
> If that were true, my modification of style rules would not work at all,
> but it does.

Your logic is flawed.

> On Firefox, using Firebug, I see the following (greatly abridged)
> structure:
> document
> - styleSheets
> -- 0 (and probably others, per length at this level)
> --- cssRules
> ---- 0 (and probably others, per length at this level)
> ----- style
> ------ many many style property names and values, which can be modified
> and are acted upon by the UA

I think it is a specious argument that uses solely the *display* of 
information in *one* browser with *one* extension to define a technical 
term.

>> […]  So you can also not modify the declarations of a ruleset without
>> checking that it does not consist of grouped selectors, so that the
>> modification would not have side-effects.
> 
> I do not have to check because I do not usually use grouped selectors and
> certainly not when I plan to modify the properties beneath them.

What does your response have to do with my argument?
 
>> But since items should not be hidden by default (think of NoScript &
>> friends), it should be
>>
>>   ul.filtered.no-foo li.foo {
>>     /* or transitions */
>>     display: none;
>>   }
>>
>> With the latter approach, you could hide all items of category “foo” with
>> the one-liner
>>
>>   ul.className += " no-foo";
>>
>> assuming that “ul” refers to the ancestor/parent element (here: an “ul”
>> element).
> 
> I *think* I followed that, but I'm still not clear on the advantage.

It is supposed to work everywhere (where both client-side scripting and CSS 
are supported and enabled), and it does not require elaborate code to do so.

> Perhaps that's because long ago, when I started modifying my list, I saw
> the need for a function, which I then wrote.  As a result, if I want to
> hide all the list items of class 'foo', I make a one-line call to that
> function.

It is a common fallacy to assume that abstracting complexity away removes it 
from the equation.  You have actually increased total complexity because the 
function call has a (considerable) price, too.  Script profilers are 
contained in several modern in-browser developer tools, so you do not have 
to take anyone’s word for it.
 
> I suspect the key difference in our approaches is that I am doing very
> simple things and you, apparently, are doing rather complex ones.

I have been adressing *your* use-case (as you presented it here).  Besides, 
I cannot think of anything simpler than filtering a list by category with 
regard to the use of CSS class names, except simple one-element-specific 
property changes.

>>> Suggestion: When using an acronym for the first time, spell it out in
>>> full, followed by the acronym within parentheses.
>> Not feasible or useful (in Usenet).  There is no particular “first time”
>> there to begin with.
> 
> How about 'first time within a thread'?

AISB, there is no particular “first time” in Usenet.  When the posting in 
which a term was explained had expired, what then?  One would have to repeat 
the explanation in every posting to make sure that such an (incredibly lazy) 
reader would not have to consult the archives.

And, in fact, most things have been asked before, and *are* available in 
public archives which you should read before posting.  You are simply asking 
for too much here.

> Again, while this may introduce some redundancy, I have found it helpful

“*Some* redundancy”? :->  Do you really think what you are asking has never 
been asked (here) before?

> when trying to read a 4-year-old thread, outside the context of others
> from the period.

There you have it.  RTFM, STFW.
 
>> The recommendations for text formatting in Usenet are: *bold/emphasized*,
>> _underline/corrected_, and /italic/ (I use the last one for foreign
>> words; there are others who use it for emphasis).  At least the
>> Mozilla(/5.0)-based newsreaders implement it that way.
> 
> Yes, but not everyone uses those

Hence “at least”.

> and I had no way of knowing if you were among those who do not.

The newsreader that I am using is irrelevant; the *plain-text* formatting is 
used for displaying a posted, primarily not composing a to-be-posted 
message, by several newsreaders.

> It is an unfortunate coincidence that the position of the word allowed for
> easy mis-interpretation.

I do not think a *careful* reader *willing to do some research* could have 
misunderstood.  There is an “e.g.” in there, after all.  However, English is 
not my native language, so I *might* be mistaken.
 
>>> and hence did not understand the subsequent syntax.
>> When someone knows CSS it can be assumed by now that at least the
>> *existence* of LESS is common knowledge to them (it will be hard to find
>> employment in Web development if you do not know what it is).  Especially
>> here as there is an ECMAScript-based variant of LESS both server-side,
>> for Node.js, and client-side.
> 
> Anything can be assumed.  It is always risky.  In this case your
> assumption was incorrect.  FYI, I am not seeking employment.

And JFYI: This is not a support forum, it is a place for technical 
discussions; help is a (welcome) by-product of them.  *You* are the one who 
seeks information from more experienced people this way.  So it is *your* 
task to word questions and read answers carefully, and ask about all things 
that you do not understand (using the appropriate medium).  It is _not_ my 
or anyone else’s tasks to answer in a form that is easily understandable to 
you, to anticipate your wishes, or to foresee your misinterpretations.

IOW: It is simply not practical and too much to ask for to explain 
everything in advance.  This is all our free time, and you are getting 
decades of accumulated knowledge and experience for free here.  You get
what you paid for.  TINSTAAFL.
 
>> You can trim, but you also can summarize quotes, using the “[summary]”
>> notation.
> 
> I'll try to remember that.  I was not aware of it.  I have noticed that
> some people don't like to have their original words altered.

Hence the rectangular brackets.

<http://www.catb.org/~esr/faqs/smart-questions.html>

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

[toc] | [prev] | [next] | [standalone]

#26055

Thomas 'PointedEars' Lahn wrote:

> Chris Beall wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Chris Beall wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>> Based on previous experience, I would advise greater care with
>>> statements on quirksmode.org.  Less than with w3schools.com, but still.
>>
>> […] With regard to the reversal, by IE, of multiple class names, I
>> verified it via experiment (around about IE 6, as I recall) and coded to
>> compensate (two lines added).  It is possible this is no longer  
>> necessary,
>> […]
>
> I have tested something similar with IE 8 today (we have still customers
> using it) and at least the Developer Tools show multiple adjacent class
> selectors in different order than in the source code.  They appear to be
> sorted alphanumerically.

Good to know, thanks.  In my only current usage there are only two classes  
involved, hence only two possible orderings.

>>>> but did not extensively research, that some more complex selectors,  
>>>> such
>>>> as groups, may be split into multiple rules within 'your browser',  
>>>> which
>>>> I interpreted to mean 'the DOM as built by your browser'.
>>> I see.  But does that not show *again* that this/your current approach  
>>> is
>>> inefficient, and unreliable at best?
>>
>> It has been reliable for several years, cross-browser.
>
> For a distinct subset of stylesheets only.  I prefer general, reusable
> approaches that work in the target environments regardless how the code
> operated on is written.  I am not alone there.  And that is not because
> I *am* doing commercial work; I do not-for-profit Web development in my
> free time as well.  Working full-time, free time has become even more
> precious; I do not want to waste it on code rewrites.

I understand your position.

>>> I also do not think that style rules are part of the document tree.
>>
>> If that were true, my modification of style rules would not work at all,
>> but it does.
>
> Your logic is flawed.

Perhaps.  But if I want to dynamically change style and I then modify the  
DOM tree, within the document branch, and the rendered style changes  
correspondingly, I believe I've drawn a reasonable conclusion.  And I  
showed how I reached it...

>> On Firefox, using Firebug, I see the following (greatly abridged)
>> structure:
>> document
>> - styleSheets
>> -- 0 (and probably others, per length at this level)
>> --- cssRules
>> ---- 0 (and probably others, per length at this level)
>> ----- style
>> ------ many many style property names and values, which can be modified
>> and are acted upon by the UA
>
> I think it is a specious argument that uses solely the *display* of
> information in *one* browser with *one* extension to define a technical
> term.

Yes, I realize the risk of relying on any tool display when seeking  
Truth.  So I may not have found Truth, but I have found something that  
works, which I deem to be a good second best.

>>> […]  So you can also not modify the declarations of a ruleset without
>>> checking that it does not consist of grouped selectors, so that the
>>> modification would not have side-effects.
>>
>> I do not have to check because I do not usually use grouped selectors  
>> and
>> certainly not when I plan to modify the properties beneath them.
>
> What does your response have to do with my argument?

Only that the necessary checking is done, almost instantly, in my head,  
because I know what I have already done, i.e. not used group selectors,  
and so while your statement is true, in my simplified environment it is  
not significant in evaluating the merits of one method over another.

>>> But since items should not be hidden by default (think of NoScript &
>>> friends), it should be
>>>
>>>   ul.filtered.no-foo li.foo {
>>>     /* or transitions */
>>>     display: none;
>>>   }
>>>
>>> With the latter approach, you could hide all items of category “foo”  
>>> with
>>> the one-liner
>>>
>>>   ul.className += " no-foo";
>>>
>>> assuming that “ul” refers to the ancestor/parent element (here: an “ul”
>>> element).
>>
>> I *think* I followed that, but I'm still not clear on the advantage.
>
> It is supposed to work everywhere (where both client-side scripting and  
> CSS
> are supported and enabled), and it does not require elaborate code to do  
> so.
>
>> Perhaps that's because long ago, when I started modifying my list, I saw
>> the need for a function, which I then wrote.  As a result, if I want to
>> hide all the list items of class 'foo', I make a one-line call to that
>> function.
>
> It is a common fallacy to assume that abstracting complexity away  
> removes it
> from the equation.  You have actually increased total complexity because  
> the
> function call has a (considerable) price, too.  Script profilers are
> contained in several modern in-browser developer tools, so you do not  
> have
> to take anyone’s word for it.
>
>> I suspect the key difference in our approaches is that I am doing very
>> simple things and you, apparently, are doing rather complex ones.
>
> I have been adressing *your* use-case (as you presented it here).   
> Besides,
> I cannot think of anything simpler than filtering a list by category with
> regard to the use of CSS class names, except simple one-element-specific
> property changes.
>
>>>> Suggestion: When using an acronym for the first time, spell it out in
>>>> full, followed by the acronym within parentheses.
>>> Not feasible or useful (in Usenet).  There is no particular “first  
>>> time”
>>> there to begin with.
>>
>> How about 'first time within a thread'?
>
> AISB, there is no particular “first time” in Usenet.  When the posting in
> which a term was explained had expired, what then?  One would have to  
> repeat
> the explanation in every posting to make sure that such an (incredibly  
> lazy)
> reader would not have to consult the archives.
>
> And, in fact, most things have been asked before, and *are* available in
> public archives which you should read before posting.  You are simply  
> asking
> for too much here.
>
>> Again, while this may introduce some redundancy, I have found it helpful
>
> “*Some* redundancy”? :->  Do you really think what you are asking has  
> never
> been asked (here) before?

That would be my request for "DOM equivalent of CSS property names".

I have no idea, but I looked several places before coming here and did not  
find the answer to the Subject.  And, throughout this thread, no one has  
provided it.  If such an answer existed and was known, a one-line pointer  
to it would be a courteous response.  If not, then advice leading to joint  
discovery of the answer would be helpful.


>>> The recommendations for text formatting in Usenet are:  
>>> *bold/emphasized*,
>>> _underline/corrected_, and /italic/ (I use the last one for foreign
>>> words; there are others who use it for emphasis).  At least the
>>> Mozilla(/5.0)-based newsreaders implement it that way.
>>
>> Yes, but not everyone uses those
>
> Hence “at least”.
>
>> and I had no way of knowing if you were among those who do not.
>
> The newsreader that I am using is irrelevant; the *plain-text*  
> formatting is
> used for displaying a posted, primarily not composing a to-be-posted
> message, by several newsreaders.

I was not referring to your newsreader.  I was referring to your use, or  
not, of the *emphacis* notation.  Some people don't know about it; some  
do, but don't use it.  I now know that your both know and use it.

>
>> It is an unfortunate coincidence that the position of the word allowed  
>> for
>> easy mis-interpretation.
>
> I do not think a *careful* reader *willing to do some research* could  
> have
> misunderstood.  There is an “e.g.” in there, after all.  However,  
> English is
> not my native language, so I *might* be mistaken.

e.g. is a Latin abbreviation.  Your native language is irrelevant here.   
And I think if you review the original wording you see that its presence  
does not remove the ambiguity.

>>>> and hence did not understand the subsequent syntax.
>>> When someone knows CSS it can be assumed by now that at least the
>>> *existence* of LESS is common knowledge to them (it will be hard to  
>>> find
>>> employment in Web development if you do not know what it is).   
>>> Especially
>>> here as there is an ECMAScript-based variant of LESS both server-side,
>>> for Node.js, and client-side.
>>
>> Anything can be assumed.  It is always risky.  In this case your
>> assumption was incorrect.  FYI, I am not seeking employment.
>
> And JFYI: This is not a support forum, it is a place for technical
> discussions; help is a (welcome) by-product of them.  *You* are the one  
> who
> seeks information from more experienced people this way.

I am well aware of that, having often been on the other side of such  
interchanges.

> So it is *your*
> task to word questions and read answers carefully, and ask about all  
> things
> that you do not understand (using the appropriate medium).  It is _not_  
> my
> or anyone else’s tasks to answer in a form that is easily understandable  
> to
> you, to anticipate your wishes, or to foresee your misinterpretations.
>
> IOW: It is simply not practical and too much to ask for to explain
> everything in advance.  This is all our free time, and you are getting
> decades of accumulated knowledge and experience for free here.  You get
> what you paid for.  TINSTAAFL.

>>> You can trim, but you also can summarize quotes, using the “[summary]”
>>> notation.
>>
>> I'll try to remember that.  I was not aware of it.  I have noticed that
>> some people don't like to have their original words altered.
>
> Hence the rectangular brackets.
>
> <http://www.catb.org/~esr/faqs/smart-questions.html>
>

I am quite familiar with all of the above.  If you go back to my original  
post, I believe you will find that it meets all of the recommended  
criteria.  It does not state that I had looked elsewhere first, but I had.
Having volunteered, as you did here, many times, I'm aware of the best way  
to ask questions and the infrequency with which it occurs.  If I see an  
inept question, I make an upfront decision either to not participate, or  
to take the time to hand-hold the questioner to a final resolution.  You  
choose differently, as is your right.

I see no point in my continuing to participate in this thread as:
   - I believe I have determined the answer to my original inquiry.
   - I have started a separate thread to discuss a second issue which arose  
during testing.
   - That second issue has also been resolved within the limited scope of  
my immediate interest (which excludes Opera).

You will therefore now have an opportunity to have the last word.
It's been interesting.

Chris Beall

[toc] | [prev] | [next] | [standalone]

#26062

JFTR.

Chris Beall wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Chris Beall wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> The recommendations for text formatting in Usenet are:
>>>> *bold/emphasized*,
>>>> _underline/corrected_, and /italic/ (I use the last one for foreign
>>>> words; there are others who use it for emphasis).  At least the
>>>> Mozilla(/5.0)-based newsreaders implement it that way.
>>>
>>> Yes, but not everyone uses those
>>
>> Hence “at least”.
>>
>>> and I had no way of knowing if you were among those who do not.
>>
>> The newsreader that I am using is irrelevant; the *plain-text*
>> formatting is
>> used for displaying a posted, primarily not composing a to-be-posted
>> message, by several newsreaders.
> 
> I was not referring to your newsreader. I was referring to your use, or
> not, of the *emphacis* notation.  Some people don't know about it; some
> do, but don't use it.  I now know that your both know and use it.

Your subtle attempt to single me out here is misguided, unsuccessful, and 
above that not appreciated at all.  The first rule of participation in 
Usenet, in *any* culture or subculture really, is to get yourself informed 
about it *in advance*.  Those who neglect to do so will be facing 
difficulties of the kind you experienced.  As for Usenet, there are many 
tutorials, none of them written by me, that explain the use of this plain-
text formatting, and that and why you should avoid using all-caps text 
instead of them.  I would be surprised if the FAQ of/for this newsgroup 
(whatever you prefer) would not at least indirectly refer to one of them.

>>> It is an unfortunate coincidence that the position of the word allowed
>>> for easy mis-interpretation.
>>
>> I do not think a *careful* reader *willing to do some research* could
>> have misunderstood.  There is an “e.g.” in there, after all.  However,
>> English is not my native language, so I *might* be mistaken.
> 
> e.g. is a Latin abbreviation.

*In English*, the language I have been using for presenting the example, it 
is an abbreviation *derived from* Latin (meaning «exempli gratiā» – 
literally, “free example”) which translates to “for example”.  My knowledge 
of English and Latin is certainly incomplete, but I know *that*.

I am not aware of another contemporary language that uses it in this way.  
(Certainly my native language, German, does not.)  Are you?

> Your native language is irrelevant here.

If English were my native language, then naturally I would be more aware of 
mistakes I had made in the wording of a sentence written in English.

> And I think if you review the original wording you see that its presence
> does not remove the ambiguity.

Which ambiguity?  “You could then even use, for example, less to make it 
more obvious …”, where “less” means the opposite of “more”, does not make 
any sense.  Why should I name “use less” as an example?  What would be the 
other possibility that did not serve as example – “more”, or something like 
that?  That would not make sense either.

So Occam’s Razor suggests that “LESS” *could not* have been meant as an 
emphasized “less”.  Therefore, it *must* have meant something else.

When I am logged out at Google (so that my previous visits become irrelevant 
to the result sort order), the first result of a search for “LESS” (and even 
“less”) is <http://lesscss.org/>.

From that I conclude that you have not searched.  As you have not searched, 
you have not found a problem with the sentence when interpreted in your (the 
wrong) way.  As you have found no problem, but you are a native speaker of 
English, you could not have it read carefully.  And ISTM that you are now 
winding around the admission of that fact.

F'up2 poster

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web