IE9.js
in [JavaScript]
|
From: Antony Scriven on 2 Apr 2010 17:22 On Apr 2, 9:57 pm, David Mark wrote: > Scott Sauyet wrote: > > > 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). If you write a CSS rule for .foo and it effects an element with class="foo" I'm not exactly going to be surprised. > 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. Just as a CSS rule targetting a class will only affect that class. A rule that targets .foo isn't going to affect .bar. (Well it might, but `that's a feature, not a bug!') What would annoy me is if several semantically unrelated elements had class="red". That really isn't going to help. Though I don't imagine you'd advocate that either. > Obviously, such issues can be dealt with as they come up, > but can be a pain for large projects (especially > collaborations). In my experience using classes for semantic purposes can help with large projects (especially collaborations). So if this can work both ways then perhaps this is really a project management issue, communication issue, or a programming guidelines issue, rather than some real theoretical problem of using classes for semantic purposes. --Antony
From: Scott Sauyet on 2 Apr 2010 17:31 David Mark wrote: > 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. There is no more ambiguity about what a class attribute means than there is about what an id attribute means. It is simply a group identifier, a tag. Since ids are also mostly used for CSS, but also by scripts for any number of purposes, wouldn't you also recommend that people stuck to using ids 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). But the same is true for an ID when used with a common stylesheet across multiple pages. If you add a new rule, "#intro p {color: red}" because on the pages you're working on need it, you will also affect my page which uses the same stylesheet but had the ID intro assigned for another purpose. And vice versa, if you add a new <div id="intro">...</div> to your page when there is already a CSS rule as specified above, your presentation is affected. By the same logic you're promoting, this should be enough reason to stop using IDs for both CSS and scripting. Personally, I find that absurd. > 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. [ ... ] .... and all its descendants, and possibly its later siblings and their descendants: #intro + div + div p.toolbox {color: red;} -- Scott
From: "Michael Haufe ("TNO")" on 2 Apr 2010 19:03 On Apr 2, 1:43 pm, Antony Scriven <adscri...(a)gmail.com> wrote: > On Apr 2, 6:31 pm, Michael Haufe 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? 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. Does this > > browser treat this element special because its > > a predefined class like the way HTML5 treats some class > > names? These are rhetorical questions of course. > > And if classes are used purely for CSS, how do those > questions suddenly not still apply? Now you're seeing the crux of the issue I think. The problem is that the same questions apply either way which is the problem. > Are you suggesting that > web documents are built solely from a database schema? --Antony I'm saying that the spec should not have have allowed the attribute to mean *anything* the browser feels like.
From: "Michael Haufe ("TNO")" on 2 Apr 2010 19:07 On Apr 2, 2:20 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > 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". So a div with a class "toolbox" means that its a div of the class "toolbox". Yes, that's about all you can tell. > 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. It seems we're just running in circles now.
From: Garrett Smith on 2 Apr 2010 19:12
Michael Haufe ("TNO") wrote: > On Apr 1, 11:14 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> I don't read that at all. The HTML specification does not state that the >> `class` attribute is to limited for CSS. > > Once again, I'm stating that is the problem with it. The HTML 4.01 > spec > states a class is for both styling AND "For general purpose processing > by user agents" > > This is a mistake. Being liberal in what you accept does not make > other conservative in what they give. > That is not a mistake at all. If going to make the conclusions you did, then you're going to have to provide reasons. >> 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. > 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. >> 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. > No disagreement there; the HTML alone should make sense. Something like: <span class="email">nu@1.net</span> - looks like it contains an email address. [...] -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |