Opened 14 years ago

Closed 12 years ago

#455 closed enhancement (fixed)

Add support for selectors to Dojo

Reported by: dojo_trac@… Owned by: anonymous
Priority: high Milestone: 0.9
Component: Core Version: 0.3
Keywords: css selector Cc: pottedmeat@…, alex@…, dojo_trac@…
Blocked By: Blocking:

Description

Add support for CSS-like selectors in Dojo. A couple of libraries that currently do this are:

CSSQuery - http://dean.edwards.name/my/cssQuery/ Prototype - http://mir.aculo.us/articles/2006/01/18/prototype-gets-selector-magic Behavior - http://bennolan.com/behaviour/

It would be really handy and nifty!

Change History (26)

comment:1 Changed 14 years ago by alex

Cc: pottedmeat@… alex@… added
Component: GeneralCore

So there are a couple of questions in play here:

  • should we be really providing CSS selectors? Should we provide some other query syntax instead?
  • what about updating the results?
  • how will this interact with (or be built on?) the current page parser syntax?

comment:2 Changed 14 years ago by Neil Roberts

I don't know if I should be writing up a post on the blog about why I feel so strongly about using CSS selectors to find DOM nodes.

If someone *cough* Alex *cough* thinks it's wise for this to be posted on the blog, I'd be glad to expound on it.

First of all, I want to point out how widely scoped CSS is supposed to be. It's designed with several specific requirements. The main idea is cascading (the C) which is relevant only to page rendering. In the case of narrowing down the DOM, it's so widely scoped that finding a single node is a relatively complex operation. Applying CSS to the render view happens during the drawing of the view, not afterward, so thinking that the two operations are similar is misguided. I guest that's my biggest gripe - the idea that CSS selectors and narrowing the DOM are similar, in any way.

Continuing to touch on scope, CSS selectors will almost always be slow. Unless the user has specifically written the CSS selector to be a narrow operation, a lot of nodes will have to be processed. Instead of users writing a page that facilitates a quick DOM selection (almost always ID based), they learn to depend on something like "div a span" which is a VERY slow operation compared to grabbing a div by ID and then programatically cycling through children.

In terms of speed, even having to parse the CSS is a FURTHER lag that doesn't have to be there. The more complicated the queries that people write: "div a[href ~= host=] span" the slower this parsing will be, and the slower the node location will be.

I've grown quite fond of XPath lately, mostly from working with Jot. This is a selection syntax that is SPECIFICALLY meant for locating a node. Not only that, but the future of browsers is definitely heading toward bringing native XPath queries into the standard BOM toolset. I know that Alex has advocated the idea of having an operation that uses XPath, the idea being that we can support a limited set for browsers that don't yet support XPath that would automatically pass those operations through the native parsers as they become available.

I just want to make it clear that CSS syntax is not meant for defining a node, it's meant for hitting a range of things, at different levels in the tree, with different space between them. While XPath allows this sort of filtering, it's not how XPath is meant to be used. To write a CSS query that creates a focused set of nodes requires effort. To get a CSS query that only grabs 1 level of nodes is even harder still. We need to understand that just because it "seems" to make sense doesn't mean that it does.

comment:3 Changed 14 years ago by skinner

Milestone: 0.3release0.4

comment:4 Changed 14 years ago by ninki

Component: CoreWebsite
Milestone: 0.40.1alpha
Priority: normalhighest
severity: normalmajor
Type: defecttask
Version: 0.30.1

comment:5 Changed 14 years ago by ninki

Component: WebsiteWidgets
Priority: highestlow
severity: majornormal
Type: taskdefect

comment:6 Changed 14 years ago by ninki

Component: WidgetsGeneral
Milestone: 0.1alpha0.3release
Priority: lowhigh
severity: normalmajor
Version: 0.1

comment:7 Changed 14 years ago by viagra

Component: GeneralBuildTools
Milestone: 0.3release0.4
Priority: highhighest
severity: majorblocker
Type: defectenhancement
Version: 0.3

comment:8 Changed 14 years ago by viagra

Component: BuildToolsCore
Milestone: 0.40.9
Priority: highestlow
severity: blockercritical
Version: 0.30.4

comment:9 Changed 14 years ago by cialis

Component: CoreGeneral
Milestone: 0.90.2.1release
Priority: lowhigh
Type: enhancementdefect
Version: 0.4

comment:10 Changed 14 years ago by viagra

Component: GeneralDocumentation
Milestone: 0.2.1release0.9
severity: criticalblocker
Type: defecttask
Version: browserio_package

comment:11 Changed 13 years ago by bill

Component: DocumentationCore
Milestone: 0.90.4
Priority: highnormal
severity: blockernormal
Version: browserio_package0.3

revert spam attack

comment:12 Changed 13 years ago by cialis

Component: CoreWebsite
Milestone: 0.40.9
severity: normalcritical
Type: taskenhancement
Version: 0.3browserio_package

comment:13 Changed 13 years ago by viagra

Component: WebsiteCore
Milestone: 0.90.3release
severity: criticaltrivial
Type: enhancementdefect
Version: browserio_package0.4

comment:14 Changed 13 years ago by phentermine

Component: CoreWebsite
Milestone: 0.3release0.5
Priority: normallowest
severity: trivialminor
Type: defectenhancement
Version: 0.40.3

comment:15 Changed 13 years ago by valium

Component: WebsiteBuildTools
Milestone: 0.50.2.1release
Priority: lowestlow
severity: minornormal
Type: enhancementdefect
Version: 0.30.4

comment:16 Changed 13 years ago by viagra

Milestone: 0.2.1release0.8
Priority: lowlowest
severity: normalcritical
Type: defectenhancement
Version: 0.40.2

comment:17 Changed 13 years ago by cialis online

Component: BuildToolsWebsite
Milestone: 0.80.3.1
severity: criticalblocker
Type: enhancementdefect
Version: 0.20.5

comment:18 Changed 13 years ago by cialis

Component: WebsiteGeneral
Milestone: 0.3.10.9
Priority: lowestnormal
severity: blockermajor
Type: defecttask

comment:19 Changed 13 years ago by viagra

Component: GeneralWidgets
Milestone: 0.90.1release
Priority: normalhigh
Type: taskdefect
Version: 0.51.0

comment:20 Changed 13 years ago by cialis online

Component: WidgetsBuildTools
Milestone: 0.1release0.9
Priority: highhighest
severity: majorminor
Type: defecttask
Version: 1.00.2

comment:21 Changed 13 years ago by cialis online

Component: BuildToolsRoadmap
Milestone: 0.90.2.1release
Priority: highesthigh
Version: 0.2browserio_package

comment:22 Changed 13 years ago by viagra online

Component: RoadmapTestFramework
Milestone: 0.2.1release0.9
Priority: highlowest
severity: minorcritical
Type: taskenhancement
Version: browserio_package1.0

comment:23 Changed 13 years ago by apang

Component: TestFrameworkCore
Milestone: 0.90.4
Priority: lowestnormal
severity: criticalnormal
Version: 1.00.3

revert spam attack

comment:24 Changed 13 years ago by dylan

Milestone: 0.40.5

comment:25 Changed 12 years ago by tk

Cc: dojo_trac@… added

dojo.query() should close this out right? Or am I missing some fundemental aspect of this ticket still?

-Karl

comment:26 Changed 12 years ago by alex

Resolution: fixed
Status: newclosed

Nope, not missing anything. Marking fixed.

Note: See TracTickets for help on using tickets.