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

Groups > comp.lang.javascript > #26044

Re: DOM style object property names with vendor prefixes

Show all headers | View raw

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

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

Thread

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

csiph-web