IE9.js
in [JavaScript]
|
From: "Michael Haufe ("TNO")" on 5 Apr 2010 01:12 On Apr 4, 11:00 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > There is also no ambiguity about an identifier for a class of > elements. 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." If that's really what you mean, > then you need to justify the shared use of id, because it has the same > property. I really have seen no other argument for the classes-for- > CSS-only position in this thread that is not purely circular. > [...] > I understand that you think that. And if in the end it's simply a > matter of your gut instinct, we can simply agree to disagree. But > there seems to be some heat behind the argument against using classes > in this manner. If there is a substantive argument to back it up, I > would really like to hear it. The arguments I made related to the class attribute also apply to the id attribute. These attributes should be used to annotate elements with meaningful and relevant descriptions and nothing more. Annotating elements for any other reason obfuscates. The presentation layer and behavior layer should then be built on top of those names (preferably in a complementary way). See my last message. An example: <span id="fooEmail" class="important email">foo(a)example.com</span> Pretty self explanatory: The id attribute identifies this content specifically. The class attribute describes more generic information about the group. Upon this content the presentation layer can be laid: #fooEmail{ font-style:italic; } ..important{ color:red; } ..email{ font-family:"Courier New" } As well as a behavior layer: addEvent("fooEmail",myFn); HTML5 supposedly offers a better way to separate the semantic concerns through roles or something, but we'll see.
From: Garrett Smith on 5 Apr 2010 01:48 Hans-Georg Michna wrote: > On Sat, 03 Apr 2010 18:40:12 -0400, David Mark wrote: > >> there can only be one class attribute per element > > But you shouldn't need to be reminded that, unlike the id > attribute, the class attribute takes multiple > white-space-separated identifiers. CSS uses each of them, and > JavaScript code can, of course, do that just as well. > 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.... Using zero-width space is going to make the code hard to read, and form feed is uncommon. 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. Although I would generally not use \r as a separator for class, I would not expect the result produced. [1]<http://www.w3.org/TR/html401/struct/global.html#h-7.5.2> [2]<http://www.w3.org/TR/html401/struct/text.html#whitespace> -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 5 Apr 2010 02:57 Garrett Smith wrote: > Hans-Georg Michna wrote: >> On Sat, 03 Apr 2010 18:40:12 -0400, David Mark wrote: >> >>> there can only be one class attribute per element >> >> But you shouldn't need to be reminded that, unlike the id >> attribute, the class attribute takes multiple >> white-space-separated identifiers. CSS uses each of them, and >> JavaScript code can, of course, do that just as well. >> > > 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.... > > Using zero-width space is going to make the code hard to read, and form > feed is uncommon. > > 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. Isn't this post s microcosm of your futility? You regurgitate specs and then fall flat on your face trying to solve a simple problem. That test is ludicrous for a number of reasons. For one, you aren't setting out to test createElement or (for God's sake) innerHTML. It looks just like jQuery's ill-conceived "feature tests". And you didn't state which browser you tested in either. Perhaps it is one of the ones jQuery doesn't "care" about. :) > > Although I would generally not use \r as a separator for class, I would > not expect the result produced. > Neither would I. Testing with My Library[1]:- document.body.className = 'foo\rbar baz'; API.hasClass(document.body, "foo"); Opera 6: true Opera 10.5: true IE8: true IE8 compatibility view: true IE6: true IE5.5: true FF1: true And so on... Try it in Chrome, Safari, Konquerer, a PS3, your phone or whatever and you will almost certainly get the same result (even if you change the UA string). No mammoth object created and discarded and exactly one function call (compared to probably fifty for the jQuery version, each a potential land mine between you and your goal of testing the presence of a class). BTW, your test threw an exception at line 2 (before jQuery was even involved) in Opera 6. Of course, if it hadn't, jQuery would have likely barfed on its appearance at line 3. Why does that matter? Because it bodes well for My Library in IE9, Opera 11, Safari 5, etc. and underscores the fleeting nature of jQuery's observation-based machinations. [1] http://www.cinsoft.net/mylib.html
From: David Mark on 5 Apr 2010 03:01 Scott Sauyet wrote: > David Mark wrote: >> Scott Sauyet wrote: >>> David Mark wrote: > >>> | Clearly a unique identifier can be used for either; however, there >>> | is no ambiguity about what it means in either context (it is simply >>> | a unique identifier). On the contrary, classes are used mostly for >>> | CSS, but also by scripts for any number of purposes (not to mention >>> | ill-advised schemes to add semantic value to static markup). I >>> | really think it would be simpler if people stuck to using classes >>> | for CSS. >>> This does not actually state any argument about why it's all right to >>> use ids for multiple purposes but not all right to use classes in such >>> a manner. >> I think it does. There's no ambiguity about a unique identifier. > > There is also no ambiguity about an identifier for a class of > elements. 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." If that's really what you mean, > then you need to justify the shared use of id, because it has the same > property. I really have seen no other argument for the classes-for- > CSS-only position in this thread that is not purely circular. > > >>> It simply states that classes are being used this way and >>> claims that some of these uses are ill-advised. It advances no >>> arguments at all, ending with the restatement of the point under >>> debate as though it was an actual conclusion. Of course it would be >>> simpler if people stuck to using classes for CSS. It would also be >>> simpler if people never used CSS. It would be simpler if they never >>> used Javascript either. Simpler is not always better. >> It often is and I think it is in this case. > > I understand that you think that. And if in the end it's simply a > matter of your gut instinct, we can simply agree to disagree. But > there seems to be some heat behind the argument against using classes > in this manner. If there is a substantive argument to back it up, I > would really like to hear it. > > >>>> For two, if you have any experience with such, you know >>>> that common class names (or ID's) are key. I really can't imagine what >>>> you are getting at with this question. Neither can I imagine using a >>>> screen style sheet (which is constrained to just one type of screen). >>>> Start with "all" then override as necessary for other media (including >>>> other screen types). >>> This is what I'm getting at: should you use the class "important" to >>> apply to screen, print, and aural media, or should you have a separate >>> "important_screen", "important_print", and "important_spoken"? >> Obviously the former as the latter is insane. >> >>> To me, >>> the answer is obvious. "Important" is meta-data about the content; >>> that should go in the markup. The print/spoken/screen distinction >>> belongs in the CSS. >> Yes, but I don't see how that applies to this discussion. > > I simply don't believe that you're that dense. > > Moreover, below you responded to the connection I made to the question > about using classes for non-CSS reasons.. > > > >>>> But either way, I don't see the connection at all. >>> If the argument is that an assignment to a class through the "class" >>> attribute should have a single purpose, then isn't this use across >>> multiple media just as wrong-headed as using it for JS as well as >>> CSS? If not, what's the difference? >> CSS is CSS. The other stuff is not. > > Is that supposed to be an argument? Your conclusion is the > justification for your conclusion? You might as well stick your > tongue out and chant "Nyah, nyah, nyah, NYAH, nyah!" > To paraphrase Chevy Chase, I'm David Mark and you're not. :) Seriously, you could save us both some time by just listening. It's a long climb...
From: Scott Sauyet on 5 Apr 2010 08:13
David Mark wrote: >Scott Sauyet wrote: >> David Mark wrote: >>> Scott Sauyet wrote: >>>> David Mark wrote: >>>> If the argument is that an assignment to a class through the "class" >>>> attribute should have a single purpose, then isn't this use across >>>> multiple media just as wrong-headed as using it for JS as well as >>>> CSS? If not, what's the difference? >>> CSS is CSS. The other stuff is not. >> Is that supposed to be an argument? Your conclusion is the >> justification for your conclusion? You might as well stick your >> tongue out and chant "Nyah, nyah, nyah, NYAH, nyah!" > To paraphrase Chevy Chase, I'm David Mark and you're not. :) > > Seriously, you could save us both some time by just listening. It's a > long climb... So is that your way of agreeing that you have no rational argument? I've been listening intently to this thread. You could save us a lot of time by clearly stating an argument for your position that is neither circular nor based upon your gut feeling. And while I'm sure that is a long climb for you, it all starts with a single step... -- Scott |