On Feb 26, 9:15 am, RobG <rg...@iinet.net.au> wrote:
> Further, complex CSS selectors tie your code to the page layout -
> isn't the idea to separate the two?
I don't agree. As a rule it ties your code to the *classes*, and
possibly to the hierarchical (and, one would hope, logical) structure
of the page. As long as you are using HTML and not XML, this seems to
me to be an extremely good way of expressing the semantics of
elements. Agreed, classes were originally devised for CSS, but they've
come far beyond that.
In any case, I don't see what you are contrasting this with: if you
use getElementByTag and it's friends you've still to traverse the
structure in the DOM, i.e. the page layout.
> Lastly, they encourage rubbish like: tagName#someID, which is used in
> style rules because it helps the developer, but using it in a script
> selector is just plain dumb.
> I can understand the use of selectors for prototyping or small things
> where speed is irrelevant, but using them as a fundamental strategy to
> get large sets of elements doesn't make sense. Write a function to do
> it using standard host methods, it will perform much faster and be
> easier to work with.
Ummm... isn't that like saying "Use high level languages by all means,
but for serious work, you should write assembler functions"?
never want to subject myself to into a usable language.
I have recently had unwrap a CSS selection (select by class name)
because I found that while it ran well on FF, it took a ridiculous
amount of time on IE6. (As far as I can tell, IE hasn't got a 'find by
class name'). But to me that is like having to descend to low-level
programming to get round a hardware bug.
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to
For more options, visit this group at