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

Groups > comp.lang.javascript > #26055

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

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