oops... accidentally submitted the message while editing.

What I wanted to say:

$(Expression) does not find elements that contain a dot in their id, if you search like $("#foo.bar"). The same is true for the colon, I guess, as it also has a special meaning in the (really great!) jQuery lib.

The paragraph "ID and NAME..." in the original post was copied from

http://www.w3.org/TR/html4/types.html#type-name

The period has special meaning in CSS - which is what jQuery implements. For example, try to write the CSS selector #foo.bar { ... } and it will completely not work. It is strange, though, that the CSS spec does only implement a subset of the HTML ID/NAME spec. Oh well.

The suggestion, up to this point, has been to use '-' instead of '.'.

I implemented a fallback solution for jQuery.Select which tries to use the "foo.bar" as tagname (resp. id value) and if it does not find any matching elements falls back to the usual jQuery behaviour. Unfortunately, I cannot upload files using the "Attach File" button on this page, otherwise I would have posted it, but the patch is quite trivial anyway.

No chance to include such a fallback solution in the standard jQuery lib?

FYI: In css you can escape the dot and the colon, like

#foo.bar { ... }

#foo:bar { ... }

But that's not a solution I'd like to see for jQuery, as this would require changes in some (many?) plugins, that work with ids, at least in the datepicker plugin, that I tried to use with a id that contains a dot.

I want to use jQuery with Java Server Faces (JSF). JSF by default uses colons when naming elements which is not too helpful. ... id="formname:controlid"

I understand that this is currently considered a WONTFIX type bug.

I have come up with a possible workaround for my current issues and would like to know if it is reasonable. I am new to jQuery so this could be a silly thing to do??

The "PLAN" is to use $id() rather than $() when I am only finding a single element by its id.

example... the colon is not treated as part of the id (nothing found)

$("#formname:control").addClass("");

for me: I can change this to use my global $id function instead

$id("#formname:control").addClass("");

/**

$id returns a jQuery object using a 'normal' document.getElementById.

Note that this will return a jQuery object that contains an empty list if

no such object is found.

*/

function $id(el) {

var el = getById(el);

return el? $(el): $([]);

}

function getById(el) {

if (typeof el == 'string') {

if (el[0] == "#") el = el.substring(1);

el = document.getElementById(el);

}

return el;

}

Thanks for your consideration - Rob.

Perhaps we could do a quick id search before breaking it out into different selectors. If it finds an element, return it. Otherwise, do the typical search. It would add a couple of milliseconds to each request that starts with # but maybe worth it.

How about another custom selector as a workaround, something like $("$my:id")

You can always fall back to your custom byID function that returns a jQuery object, but that is more limiting, I can't combine it with following selectors without great effors, eg.

$("$my:id div>ul") is way better then $id("my:id").find("div>ul")

The check-first-for-id-then-fall-back approach has obvious drawbacks:

<form id="form:first">

<div id="form">

Now what does $("#form:first") select? That isn't too unlikely.

@anonymous

I don't see a reason, why that would need any changes in any plugins. if you write

$('#foo.bar')

or

$('#foo:bar')

everything will be as it is. Change it to

$('#foo.bar')

or

$('#foo:bar')

and jQuery can search for IDs with

.

or

:

inside, just as it is with CSS.

I think that using a

}}} as escape character is the best way to solve the problem, since[[BR]]
1. jQuery claims to (mostly) implement CSS selectors and CSS does it that way[[BR]]
2. most existing code that uses jQuery doesn't have a Problem with that change as long as you don't use {{{

as the last character in an ID or classname and append a custom selector to it. In those rare case you simply need to add another {{{}}}.

3. it can easily be implemented in jQuery.

From CSS 2.1 Spec:

In CSS 2.1, a backslash () character indicates three types of

character escapes.

[...]

Second, it cancels the meaning of special CSS characters. Any

character (except a hexadecimal digit) can be escaped with a backslash

to remove its special meaning. For example, """ is a string consisting

of one double quote. Style sheet preprocessors must not remove these

backslashes from a style sheet since that would change the style sheet's

meaning.

http://www.w3.org/TR/CSS21/syndata.html#q6

Thus, I think a selector like "#my:elem" is perfectly valid and that

should be part of jQuery's selector engine.

From Christof Donat via Discuss mailing list

To make the patch to jQuery as small as possible and let most existing code

continue to work: How about something like this: $('#my:elem') selects the

Element with the ID "my:elem" whereas $('#my:elem') selects the Element with

the ID "my" and uses :elem as custom selector. That could be achieved by

simply changing the regular expression, Manfred named to

/^(#.?)(([a-z0-9\\*_-]|\\:)*)/i

Replying to [comment:10 brandon]:

The regex should be:

 /^([#.]?)(([a-z0-9\\*_-]|\\:)*)/i 

Replying to [comment:11 brandon]:

We could very easily just make that "\\." and handle any special character. However, there's a big "gotchya" here. You can't just escape any character. For example: "#foo:bar" becomes just "#foo:bar" since JavaScript auto-escapes strings. You'd have to do: "#foo\\:bar" - which is downright horrible.

That being said, I like the idea of being able to escape the characters - I'm just not sure how it'd work best in practice. Is requiring "#foo\\:bar" acceptable?

Fixed in SVN rev [1578].

Replying to [comment:5 rbygrave]:

if (el[0] == "#")

doesn't work in IE6. I use

if (el.charAt(0) == "#")

instead.

Exactly how was this fixed?