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

Groups > comp.lang.javascript > #26029

Re: DOM style object property names with vendor prefixes

Show all headers | View raw

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.

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