Bug Tracker

Opened 12 years ago

Closed 9 years ago

#2856 closed feature (fixed)

[attr~=value] filter does not match CSS spec for the [attr~=value] selector

Reported by: Johnnie Owned by:
Priority: major Milestone: 1.2.4
Component: selector Version: 1.2.3
Keywords: Cc:
Blocked by: Blocking:

Description

The [attr~=value] filter is not listed on the API page, but, if used, produces the same results as the [attr*=value] filter.

To match the CSS spec for the same notation, E[foo~="warning"] should match "any E element whose 'foo' attribute value is a list of space-separated values, one of which is exactly equal to 'warning'."

Under the current implementation, E[foo~="warning"] would match any E element whose 'foo' attribute contained the string 'warning', whether or not it was a separate word. E.g., it would match an E element with a 'foo' attribute whose value was 'stormwarning'.

Basically, [attr~=value] is supposed to implement .class-like behavior for arbitrary attributes.

All that's necessary to correct the problem is to replace line 347 of selector.js

(type == "*=" || type == "~=") && z.indexOf(m[5]) >= 0) ^ not )

with the following:

type == "*=" && z.indexOf(m[5]) >= 0 ||
type == "~=" &&  (" "+z+" ").indexOf(" " + m[5] +" ") >= 0  ) ^ not )

Note: Ticket 2640 asks for the proper behavior as an enhancement, but behavior that produces different results than the CSS spec seems like a bug, to me.

Change History (2)

comment:1 Changed 9 years ago by dmethvin

Component: coreselector

comment:2 Changed 9 years ago by dmethvin

Resolution: fixed
Status: newclosed
Type: bugfeature

This was implemented correctly in 1.3 with Sizzle.

Note: See TracTickets for help on using tickets.