IE9.js
in [JavaScript]
|
From: Scott Sauyet on 2 Apr 2010 15:20 Michael Haufe ("TNO") wrote: > On Apr 2, 12:22 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > >> Whether or not the specs are relevant, there is still no argument >> presented for the point in question: Why should we not use the >> "class" attribute for non-CSS purposes? > > Because meaning and meaningful are two different things. > > <div class="toolbox">...</div> > > Does "toolbox" tell me what it looks like, or tell me what it is? At the risk of actually answering a rhetorical question, I'll bite. It should tell you that this DIV element is of the class "toolbox". Now, if such toolbox elements should have a certain style applied to it, include some ".toolbox" rules in your CSS. If there are certain start-up animations to apply to toolbox elements, use some DOM searching technique to apply them to all "toolbox" elements. If you have a toolbox microformat extraction tool, run it against this element. -- Scott
From: Scott Sauyet on 2 Apr 2010 15:38 Michael Haufe ("TNO") wrote: > On Apr 1, 11:14 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> I do not see a strong reason for limiting class to be only about styles. > > The separation of concerns. An attribute should have one primary > purpose with other purposes built upon it otherwise you are forced to > understand not only that element, but also its context in the markup > and, god-forbid according to what the spec says, potentially the > browser as well. So, I'm curious, how do you apply this to the "id" element. Do you use it only for CSS, only for Javascript, or do you use it for both? If the latter, how do you justify the discrepancy? >> I do not see why an element that belongs to a class must have CSS >> styles. The thinking behind giving something a class is, for me, to >> group it into a class. > > The logical relationships between data (grouping) should not be > tightly bound with the presentation of that data. How is what Garrett describes a tight binding with presentation? He is describing a logical grouping of elements in a way that perhaps cannot be done with the containment hierarchy. There is no mention at all of presentation. But if there is presentation associated with this group, that same class name is the obvious place to hang the style information. -- Scott
From: David Mark on 2 Apr 2010 16:45 Scott Sauyet wrote: > Michael Haufe ("TNO") wrote: >> On Apr 2, 12:22 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: >> >>> Whether or not the specs are relevant, there is still no argument >>> presented for the point in question: Why should we not use the >>> "class" attribute for non-CSS purposes? >> Because meaning and meaningful are two different things. >> >> <div class="toolbox">...</div> >> >> Does "toolbox" tell me what it looks like, or tell me what it is? > > At the risk of actually answering a rhetorical question, I'll bite. > It should tell you that this DIV element is of the class "toolbox". Which tells you nothing at all.
From: Antony Scriven on 2 Apr 2010 16:55 On Apr 2, 8:20 pm, Scott Sauyet wrote: > Michael Haufe ("TNO") wrote: > > > On Apr 2, 12:22 pm, Scott Sauyet > > <scott.sau...(a)gmail.com> wrote: > > > > Whether or not the specs are relevant, there is still > > > no argument presented for the point in question: Why > > > should we not use the "class" attribute for non-CSS > > > purposes? > > > Because meaning and meaningful are two different > > things. > > > <div class="toolbox">...</div> > > > Does "toolbox" tell me what it looks like, or tell me > > what it is? > > At the risk of actually answering a rhetorical question, > I'll bite. It should tell you that this DIV element is of > the class "toolbox". > > Now, if such toolbox elements should have a certain style > applied to it, include some ".toolbox" rules in your CSS. > If there are certain start-up animations to apply to > toolbox elements, use some DOM searching technique to > apply them to all "toolbox" elements. If you have > a toolbox microformat extraction tool, run it against > this element. In other words, use the class attribute purely for semantics. Sounds more reasonable to me. --Antony
From: David Mark on 2 Apr 2010 16:57
Scott Sauyet wrote: > Michael Haufe ("TNO") wrote: >> On Apr 1, 11:14 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >>> I do not see a strong reason for limiting class to be only about styles. >> The separation of concerns. An attribute should have one primary >> purpose with other purposes built upon it otherwise you are forced to >> understand not only that element, but also its context in the markup >> and, god-forbid according to what the spec says, potentially the >> browser as well. > > So, I'm curious, how do you apply this to the "id" element. Do you > use it only for CSS, only for Javascript, or do you use it for both? > If the latter, how do you justify the discrepancy? 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. > > >>> I do not see why an element that belongs to a class must have CSS >>> styles. The thinking behind giving something a class is, for me, to >>> group it into a class. >> The logical relationships between data (grouping) should not be >> tightly bound with the presentation of that data. > > How is what Garrett describes a tight binding with presentation? He > is describing a logical grouping of elements in a way that perhaps > cannot be done with the containment hierarchy. Because it has the potential for a presentational side effect. If you add a new class to one of the associated style sheets, the logical group's presentation is affected (perhaps unintentionally). There is no such ambiguity for ID's as adding a CSS rule for an ID will only affect a single element with that ID. Obviously, such issues can be dealt with as they come up, but can be a pain for large projects (especially collaborations). |