Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: DOM style object property names with vendor prefixes Date: Tue, 28 Oct 2014 19:49:37 +0100 Organization: PointedEars Software (PES) Lines: 223 Message-ID: <2808896.X0fOSNMZzN@PointedEars.de> References: <83210457.YLdJyC3XC5@PointedEars.de> <2636975.CJeWhIb7Se@PointedEars.de> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: solani.org 1414522179 21412 eJwFwYkRwDAIA7CVeGycjFO4sv8IkZjlNUKxwOVuCmb4ZUkG2/vqmPDd6cBhb2RT4z1ORDz8fxAD (28 Oct 2014 18:49:39 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Tue, 28 Oct 2014 18:49:39 +0000 (UTC) User-Agent: KNode/4.14.1 X-User-ID: eJwNy8kBwDAIA7CVcDkzDoF6/xFa/eUaiEkLD3M6xWftqbJ9Y1qvk5pQMe7GkYNSyc5/Sd5ueIk9IMA4wPADPx0Ukw== Cancel-Lock: sha1:C1yW5N8NvUe3yY6b4U4pkkHelS0= X-NNTP-Posting-Host: eJwFwQkBACAIBLBKIN8RR0D6R3AzcfYOdXO1te0iujffziC19MHiVAOZLMNPQhFCvN0B3fMBKhERFQ== Mail-Copies-To: usenet@PointedEars.de Xref: csiph.com comp.lang.javascript: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 ? > 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: >> 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). >>>>> 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: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not Cc: me. / Bitte keine Kopien per E-Mail.