IE9.js
in [JavaScript]
|
From: Garrett Smith on 3 Apr 2010 13:16 Michael Haufe ("TNO") wrote: > On Apr 3, 1:09 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > >> Underlying problem? Earlier you wrote that the biggest issue was >> predefined classes. > > Surely by now it should have been made clear from the posts thus far > from myself and others. Repeating the same thing again and again is > getting old, and I'm tired of doing it. You being tired is an excuse, not a reason. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: "Michael Haufe ("TNO")" on 3 Apr 2010 14:57 On Apr 3, 12:16 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > You being tired is an excuse, not a reason. And your inability to read up to this point is inexcusable. On Apr 3, 1:09 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Earlier you wrote that the biggest issue was > predefined classes. Yes, it was a big issue as it was a stupid move by the WG as mentioned, and the spec allowed such bungling up to this point In my interpetation ("For general purpose processing by user agents"). But their backtracking on that move does not change the original argument since I only brought it up as it had built upon the original loose definition. You yourself even promoted this idea: On Mar 29, 1:45 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > A use of semantic class name could be: > > <span class="email">m...(a)example.com</span> > > HTML doesn't provide an EMAIL element. It does provide generic element > and it does provide a way to make that element belong to a class. > > Taking semantic class to the next level would be formalization of > specific class names, such as how to represent email address. On Apr 3, 1:09 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Underlying problem? The point I made about using the class attribute being able to represent anything under the sun is a mistake and that has been brought up numerous times already by more than one person. Mixing purposes is a mistake as it lead to it's own set of problems. I pointed out that the spec should have separated these two concerns. You then mentioned that microformats does this in some degree and Thomas Lahn showed how this is insufficient. David Mark promoted limiting yourself to using it for presentation only. Antony Scriven, I think without realizing it, showed how David's limitation can be unreliable as well: On Apr 2, 6:31 pm, Michael Haufe wrote: > <div class="toolbox">...</div> > > Does "toolbox" tell me what it looks like, or tell me > what it is? There is no way to know from looking at the > code. Do I have to look at the stylesheet, do I have to > look at the other toolboxes to see if there is a common > use? Or is it some combination of both[?] On Apr 2, 1:43 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > And if classes are used purely for CSS, how do those > questions suddenly not still apply? On Apr 2, 3:55 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > In other words, use the class attribute purely for semantics. > Sounds more reasonable to me. --Antony Obviously the same problems apply either way because the attribute has no real meaning on its own and this is by design.
From: Garrett Smith on 3 Apr 2010 15:57 Michael Haufe ("TNO") wrote: > On Apr 3, 12:16 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> You being tired is an excuse, not a reason. > > And your inability to read up to this point is inexcusable. > Posting your presumptions about what I do? I have read every single message in this thread. > On Apr 3, 1:09 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> Earlier you wrote that the biggest issue was >> predefined classes. > > Yes, it was a big issue as it was a stupid move by the WG as > mentioned, and the spec allowed such bungling up to this point In my > interpetation ("For general purpose processing by user agents"). But > their backtracking on that move does not change the original argument > since I only brought it up as it had built upon the original loose > definition. You yourself even promoted this idea: > I did not promote HTML5 predefined classes. I used a microformat as an example of using class to annotate semantic meaning of element. I explained how that microformat could be used by a javascript function that takes a div "hCard", and finds all the hCard elements in it. By following a model that is both (1) semantic, and (2) consistent, the function hCardToJSON(div) can be expected to have consistent results. Thomas pointed out the problems with the design of that microformat and nobody disagreed. THose problems do not, however, refute the value or validity of the argument I proposed which was supported by microformats. | The class in the markup says something about the markup, not the CSS. | The HTML attribute in this case describes what sort of thing it is. That argument still stands and it is still valid. You've mentioned "separation of concerns". That is the very thing I am explaining. > On Mar 29, 1:45 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> A use of semantic class name could be: >> >> <span class="email">m...(a)example.com</span> >> >> HTML doesn't provide an EMAIL element. It does provide generic element >> and it does provide a way to make that element belong to a class. >> >> Taking semantic class to the next level would be formalization of >> specific class names, such as how to represent email address. > > On Apr 3, 1:09 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> Underlying problem? > > The point I made about using the class attribute being able to > represent anything under the sun is a mistake and that has been > brought up numerous times already by more than one person. Mixing > purposes is a mistake as it lead to it's own set of problems. The class attribute represents a way to group elements into classes. The class is not just about CSS. I > pointed out that the spec should have separated these two concerns. You did but you did not give any reason. > You then mentioned that microformats does this in some degree and > Thomas Lahn showed how this is insufficient. Lahn showed problems with implementation of a particular microformat. David Mark promoted > limiting yourself to using it for presentation only. Yeah, so what? Antony Scriven, I > think without realizing it, showed how David's limitation can be > unreliable as well: > Antony reaffirmed the value of semantic meaning of classnames and pointed out the value in communication and process. > On Apr 2, 6:31 pm, Michael Haufe wrote: >> <div class="toolbox">...</div> >> >> Does "toolbox" tell me what it looks like, or tell me >> what it is? There is no way to know from looking at the >> code. Do I have to look at the stylesheet, do I have to >> look at the other toolboxes to see if there is a common >> use? Or is it some combination of both[?] > > > On Apr 2, 1:43 pm, Antony Scriven <adscri...(a)gmail.com> wrote: >> And if classes are used purely for CSS, how do those >> questions suddenly not still apply? > > > On Apr 2, 3:55 pm, Antony Scriven <adscri...(a)gmail.com> wrote: >> In other words, use the class attribute purely for semantics. >> Sounds more reasonable to me. --Antony > > Obviously the same problems apply either way because the attribute has > no real meaning on its own and this is by design. The class attribute groups elements into a class of objects. I do not see the problem in understanding that. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 3 Apr 2010 16:14 Garrett Smith wrote: > Michael Haufe ("TNO") wrote: >> On Apr 3, 1:09 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> >>> Underlying problem? Earlier you wrote that the biggest issue was >>> predefined classes. >> >> Surely by now it should have been made clear from the posts thus far >> from myself and others. Repeating the same thing again and again is >> getting old, and I'm tired of doing it. > You being tired is an excuse, not a reason. Do you ever stop to think that you are the problem. I have and I really think there's something to it.
From: Scott Sauyet on 3 Apr 2010 16:58
Antony Scriven wrote: > On Apr 3, 12:17 am, Michael Haufe wrote: >> On Apr 2, 3:55 pm, Antony Scriven <adscri...(a)gmail.com> > wrote: > >>> In other words, use the class attribute purely for >>> semantics. Sounds more reasonable to me. --Antony >> >> No one promoted this. > > I thought I was paraphrasing Scott in particular and one > side of the argument in general. If not, then I just > promoted it. --Antony Well, if I didn't say that, I should have. To the arguments that an attribute should be used for one thing only, I agree. But that one thing in the case of the class attribute has to do with logically grouping together otherwise unrelated elements. Ideally, this should be done with a term that's meaningful in your context: don't use "toolbox" if it's ambiguous in your environment. That is what the class attribute should be used for. If you then want to style the elements of that group in a particular way, you can add a CSS rule that references your class. If you want to hide those elements as they're not needed in your nifty Web2.0 Rich Internet Application, add some script that selects them using this class name. If you want to annoy the hell out of Thomas Lahn with your amateurish start-up animation on those elements, use them as hooks for this noble purpose. 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. 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? And if it's the latter, what's so different about also using them as hooks for scripting? -- Scott |