IE9.js
in [JavaScript]
|
From: Hans-Georg Michna on 5 Apr 2010 08:51 On Sun, 04 Apr 2010 22:48:19 -0700, Garrett Smith wrote: >In the html `class` attribute[1], multiple class names must be separated >by white space characters[2]. From section 9.1 White space: > >| ... In HTML, only the following characters are defined as white space >| characters: >| >| * ASCII space ( ) >| * ASCII tab (	) >| * ASCII form feed () >| * Zero-width space (​) >| >| Line breaks are also white space characters.... Thanks for the reminder. In http://winhlp.com/wxnet.htm , which underwent a radical jqueryectomy last night (and survived in best shape), I now use, for example, the expression: /\bcollapsed\b/.test(p.className) to test whether the class contains "collapsed". I guess this would always work, but since I have full control over the HTML here, I know that each class entry begins and ends either with a space or with the beginning or end of the entire class string. I guess, this may well be the best way to test. Removal and addition is another matter, but can also be done with relatively simple regular expressions, so there is no urgent need for extra code. For example, to remove: p.className = p.className. replace(/(^|\s+)collapsed($|\s+)/g, " "); I'm not sure whether \s+ catches the more exotic white-space stuff, but it probably does. This code pays for its simplicity with the fortunately insignificant ugliness that a space remains in the very beginning or end of the class string when you remove the first or last identifier. >A class match function that not excludes any of these characters risks >failure. AIUI, a carriage return "\r", or "\u000d" should be a valid >separator for two class tokens. Testing that hypothesis on the jQuery >javascript library: > > var x = document.createElement("div"); > x.innerHTML = "<span class='foo\rbar baz'>hey</span>"; > jQuery(x.firstChild).hasClass("foo"); > >Result: false. Hm, how can any programmer worth his salt possibly bungle this up? I believe all functions in JavaScript that recognize white-space, like the regexp expressions \b and \s, recognize \r as white-space. You'd have to go out of your way to put such a defect in there. Does jQuery, like Microsoft, now also suffer from the kid-programmers syndrome, the over-exuberant, but inexperienced school-leavers? Here's the jQuery-free code, which is not even significantly longer: var x = document.createElement("div"); x.innerHTML = "<span class='foo\rbar baz'>hey</span>"; /\bfoo\b/.test(x.firstChild.className); Result: true, as expected. Hans-Georg
From: Scott Sauyet on 5 Apr 2010 09:22 Hans-Georg Michna wrote: > On Sun, 4 Apr 2010 21:00:09 -0700 (PDT), Scott Sauyet wrote: >> Your argument seems to run something like this: "We should >> use the class attribute only for CSS, because otherwise we don't know >> if it's being used for CSS or not." > > What would be the best alternative, assuming one decides not to > use the class attribute for JavaScript grouping purposes? I'm not sure. Those arguing against "class" don't seem to object to "id", although I can't understand their differentiation of the two. In that case, perhaps the idea is to make sure that your markup is structured so that you can always find what you want with combinations of getElementById and getElementsByTagName. I personally would not suggest that; the intended JS should not influence the structure of the markup; and in many environments, the markup structure is beyond your control. > In http://winhlp.com/wxnet.htmI simply added an entirely new > attribute, "relevance", to many elements for such a purpose, in > this case not for grouping, but for some kind of valuation. > > What's the problem with this approach? There probably isn't any general issue with this unless you care about validation. Unknown attributes won't validate. And that fact might at a minimum make it harder to get help from knowledgeable people in online discussions, who often will insist on a page that validates before they dig deeply into an issue. That may or may not be a factor for you. -- Scott
From: "Michael Haufe ("TNO")" on 5 Apr 2010 10:14 On Apr 5, 8:22 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > Hans-Georg Michna wrote: > > On Sun, 4 Apr 2010 21:00:09 -0700 (PDT), Scott Sauyet wrote: > >> Your argument seems to run something like this: "We should > >> use the class attribute only for CSS, because otherwise we don't know > >> if it's being used for CSS or not." > > > What would be the best alternative, assuming one decides not to > > use the class attribute for JavaScript grouping purposes? > > I'm not sure. Those arguing against "class" don't seem to object to > "id", although I can't understand their differentiation of the two. > In that case, perhaps the idea is to make sure that your markup is > structured so that you can always find what you want with combinations > of getElementById and getElementsByTagName. I personally would not > suggest that; the intended JS should not influence the structure of > the markup; and in many environments, the markup structure is beyond > your control. > > > Inhttp://winhlp.com/wxnet.htmIsimply added an entirely new > > attribute, "relevance", to many elements for such a purpose, in > > this case not for grouping, but for some kind of valuation. > > > What's the problem with this approach? > > There probably isn't any general issue with this unless you care about > validation. Unknown attributes won't validate. And that fact might > at a minimum make it harder to get help from knowledgeable people in > online discussions, who often will insist on a page that validates > before they dig deeply into an issue. That may or may not be a factor > for you. http://groups.google.com/group/comp.lang.javascript/msg/2d1544e8cc7d2a25
From: Hans-Georg Michna on 5 Apr 2010 10:25 On Mon, 5 Apr 2010 06:22:04 -0700 (PDT), Scott Sauyet wrote: >Hans-Georg Michna wrote: >> What would be the best alternative, assuming one decides not to >> use the class attribute for JavaScript grouping purposes? >I'm not sure. Those arguing against "class" don't seem to object to >"id", although I can't understand their differentiation of the two. >In that case, perhaps the idea is to make sure that your markup is >structured so that you can always find what you want with combinations >of getElementById and getElementsByTagName. I personally would not >suggest that; the intended JS should not influence the structure of >the markup; and in many environments, the markup structure is beyond >your control. id doesn't cut it, because (a) you cannot give multiple elements the same id, and (b) the id is often already used to find particular elements. Often it may be possible to use a different approach, like giving an ID to an enclosing element, then pick out its children. But sometimes the grouped elements are sprinkled across the page, they may not be siblings, they may not even wear the same tag names. >> In http://winhlp.com/wxnet.htmI simply added an entirely new >> attribute, "relevance", to many elements for such a purpose, in >> this case not for grouping, but for some kind of valuation. >> >> What's the problem with this approach? >There probably isn't any general issue with this unless you care about >validation. Unknown attributes won't validate. And that fact might >at a minimum make it harder to get help from knowledgeable people in >online discussions, who often will insist on a page that validates >before they dig deeply into an issue. That may or may not be a factor >for you. I guess it is a factor. We need a few joker attributes, but we don't have them. The only one we do have is class. There are a few somewhat crazier alternatives, such as using part of the id attribute value, like the first or last n characters, with n being a fixed, predefined number. Sounds uglier than class though. Even crazier would be to put extra elements, perhaps invisible ones, next to the ones to be grouped. And even these would have to be marked somehow. No, I don't think I like those alternatives much. I'll probably stick to class in the few cases where such grouping is needed. Hans-Georg
From: Scott Sauyet on 5 Apr 2010 11:00
Hans-Georg Michna wrote: > There are a few somewhat crazier alternatives, such as using > part of the id attribute value, like the first or last n > characters, with n being a fixed, predefined number. Sounds > uglier than class though. I've had to resort to something like that on rare occasions where the only markup I was allowed to touch was the id. I then structured the id: "part1-part2-part3" and had to search the document for all elements with, for instance, part2 = "xyz". It was very ugly and slow. > Even crazier would be to put extra elements, perhaps invisible > ones, next to the ones to be grouped. And even these would hav > to be marked somehow. That strikes me as pretty well worthless. > No, I don't think I like those alternatives much. I'll probably > stick to class in the few cases where such grouping is needed. That's how I feel too. But the people on the other side of the argument seem pretty vehement. I'd really love to hear if they have rational arguments for their position. -- Scott |