IE9.js
in [JavaScript]
|
From: Hans-Georg Michna on 4 Apr 2010 14:20 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. Reminds me of the funny thing I experienced when I came into a project in the company I now work for, only to find that the bunch of programmers all didn't know this, so they always tried to make do with just one entry in each class attribute. I first stumbled over some strange-looking contraptions, thought, why the heck did they do this, and it took me a while to realize that they all, indeed, didn't know that you can write more than one entry into the value of the class attribute. You can perhaps imagine what the entire HTML/JSP mess looks like, given that level of knowledge. When I activated the validators in eclipse, they showed thousands of errors and more than 20,000 warnings. Hans-Georg
From: David Mark on 4 Apr 2010 15:35 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. No, I don't need to be reminded of that. :) > > Reminds me of the funny thing I experienced when I came into a > project in the company I now work for, only to find that the > bunch of programmers all didn't know this, so they always tried > to make do with just one entry in each class attribute. Yikes. > > I first stumbled over some strange-looking contraptions, > thought, why the heck did they do this, and it took me a while > to realize that they all, indeed, didn't know that you can write > more than one entry into the value of the class attribute. Well, they shouldn't be developing Web pages then. > > You can perhaps imagine what the entire HTML/JSP mess looks > like, given that level of knowledge. I can imagine. > When I activated the > validators in eclipse, they showed thousands of errors and more > than 20,000 warnings. Par for the course. :)
From: Scott Sauyet on 4 Apr 2010 21:23 David Mark wrote: > Scott Sauyet wrote: >> I feel I haven't gotten satisfactory answers about the differences >> with the "id" attribute, but I want to ask another along the same >> lines. > > What is wrong with the answer(s) you've received thus far? Actually, the only answer I recall was yours: | 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. 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. >> For those who are suggesting that the class attribute be used >> only for CSS, do you believe it's acceptable to use a single class >> attribute for screen, projection, and aural stylesheets, or should you >> have separate class attributes for each? > > That's a silly question. For one, there can only be one class attribute > per element. Right, but I'll bet that you knew what I meant: should you have for each media type a distinct string in the space separated list of strings that makes up the attribute? > 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"? 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. >> And if it's the latter, >> what's so different about also using them as hooks for scripting? > > I assume you mean the former. (?) Correct. Sorry. > 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? -- Scott
From: David Mark on 4 Apr 2010 22:24 Scott Sauyet wrote: > David Mark wrote: >> Scott Sauyet wrote: > >>> I feel I haven't gotten satisfactory answers about the differences >>> with the "id" attribute, but I want to ask another along the same >>> lines. >> What is wrong with the answer(s) you've received thus far? > > > Actually, the only answer I recall was yours: > > | 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. > 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. > > >>> For those who are suggesting that the class attribute be used >>> only for CSS, do you believe it's acceptable to use a single class >>> attribute for screen, projection, and aural stylesheets, or should you >>> have separate class attributes for each? >> That's a silly question. For one, there can only be one class attribute >> per element. > > Right, but I'll bet that you knew what I meant: should you have for > each media type a distinct string in the space separated list of > strings that makes up the attribute? See below. :) > > >> 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. > > >>> And if it's the latter, >>> what's so different about also using them as hooks for scripting? >> I assume you mean the former. (?) > > Correct. Sorry. > > >> 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.
From: Scott Sauyet on 5 Apr 2010 00:00
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!" -- Scott |