Jquery selector a[href^=.] werkt niet in IE7

vrijdag 8 april 2011 16:34

Acties:

0 Henk 'm!

Topicstarter

Ik loop alweer tegen een probleem aan met IE7. Dit keer is het namelijk dat deze selector geen elementen vindt in IE7 en wel in FF:

JavaScript:

1	$("div#div a[href^=i/full/]").click(function (e) { e.preventDefault; });

Ik weet zeker dat het aan de selector ligt. Als ik het laatste stuk weg laat ([href^=i/full/]), wordt de functie namelijk wel op alle anchors uitgevoerd bij klikken. In FF werkt het gewoon naar behoren. Als ik .css("border", "1px solid red") toevoeg, dan komt er geen rode lijn, dus is het sowieso de selector.

Ondertussen heel het internet al afgezocht, maar ik kan nergens iets nuttigs vinden. Mis ik iets? Is dit een bug in IE? Of jQuery?

vrijdag 8 april 2011 16:50

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Jquery
Javascript

If you wish to use any of the meta-characters ( such as !"#$%&'()*+,./:;<=>?@[\]^`{|}~ ) as a literal part of a name, you must escape the character with two backslashes: \\.

http://api.jquery.com/category/selectors/

En/of tussen quotes plaatsen. API volgen is wel handig soms

[ Voor 108% gewijzigd door Bosmonster op 08-04-2011 16:52 ]

vrijdag 8 april 2011 17:17

Acties:

0 Henk 'm!

GWTommy

Topicstarter

Ik wil niet heel vervelend doen, maar dat haalt niks uit. Dat had ik al geprobeerd. Vergeten in de OP te zetten.. Sorry

vrijdag 8 april 2011 17:20

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Jquery
Javascript

IE past URL's aan in href (checken op URL is dus ook geen handige manier). Die zal dus waarschijnlijk beginnen met http://

Waarom geen class hangen aan die links?

[ Voor 24% gewijzigd door Bosmonster op 08-04-2011 17:21 ]

vrijdag 8 april 2011 17:24

Acties:

0 Henk 'm!

GWTommy

Topicstarter

Ook geen verschil.
Die laatste / is inderdaad niet van belang, maar zoals de selector al doet aangeven, is die slash niet het einde van de url (het gaat om foto's telkens).
Dit is maar één voorbeeld. Ik heb zo vele selectors die niet willen, ook sommige waar het een gruwelijk gedoe is om het nu nog te gaan ombouwen. En in principe zou dit toch gewoon moeten werken aangezien FF wel wil.

vrijdag 8 april 2011 17:37

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Jquery
Javascript

http://forum.jquery.com/t...-ie-vs-standards-browsers

Dat is wat ik bedoel.

IE geeft de volledige URL terug en niet de inhoud van de HREF. Dus http://... en je selector mislukt.

Je zou *= kunnen proberen.

[ Voor 42% gewijzigd door Bosmonster op 08-04-2011 17:39 ]

vrijdag 8 april 2011 20:02

Acties:

0 Henk 'm!

8088

NaN

GWTommy schreef op vrijdag 08 april 2011 @ 17:17:
Dat had ik al geprobeerd.

Wat precies? Escapen of de quotes?

JavaScript:

1
2
3

$('div a[href^="i/full/"]').click(function(e){
    e.preventDefault();
});

Bovenstaande werkt in IE 7 (en 8).

Bosmonster schreef op vrijdag 08 april 2011 @ 17:20:
IE past URL's aan in href (checken op URL is dus ook geen handige manier). Die zal dus waarschijnlijk beginnen met http://

Net even getest, maar

JavaScript:

1	alert($('div a[href^="i/full/"]').attr('href'));

geeft naar aanleiding van

HTML:

1
2
3

<div>
    <a href="i/full/lol.html">hi</a>
</div>

keurig i/full/lol.html terug. Neemt niet weg dat selecteren op class een stuk efficiënter is.

Do you seek to engage in or have you ever engaged in terrorist activities, espionage, sabotage, or genocide?

vrijdag 8 april 2011 21:49

Acties:

0 Henk 'm!

GWTommy

Topicstarter

Ik had er over heen gelezen over dat het http:// er nog voor plakt. (file:// in mijn geval)

Ben dus maar begonnen met het ombouwen. Wat een werk. Gelukkig heeft DW een find+replace functie, scheelt al een hoop

vrijdag 8 april 2011 22:18

Acties:

0 Henk 'm!

_Thanatos_

Ja, en kaal

DW

Het kan er trouwens mee te maken hebben dat je met file:// werkt, want afaik zou jQuery het href-attribuut over alle browsers moeten normaliseren.

日本！🎌

zaterdag 9 april 2011 00:34

Acties:

0 Henk 'm!

GWTommy

Topicstarter

Ik ben net klaar met alles ombouwen. Nu werkt alles netjes.
Ik kan dus niet meer testen of het te maken had met file://

zaterdag 9 april 2011 01:19

Acties:

0 Henk 'm!

8088

NaN

Waarom niet? Paginaatje om te testen is toch zo gemaakt? Overigens zal het sowieso door file:// niet werken, aangezien ^= naar het begin van de string kijkt. Dus dan zul je de eerder genoemde *= moeten gebruiken.

Voorbeeldje:

HTML:

<!DOCTYPE html>
<html>
    <head>
        <script src="http://code.jquery.com/jquery-1.5.js"></script>
        <title>selectz0r</title>
    </head>
    <body>
        <div>
            <a href="file://i/full/test.html">anchor</a>
        </div>
        <script>
            $('div a[href*="i/full/"]').click(function(e){
                e.preventDefault();
            });
            alert($('div a[href*="i/full/"]').attr('href'));
        </script>
    </body>
</html>

[ Voor 47% gewijzigd door 8088 op 09-04-2011 01:21 ]

Do you seek to engage in or have you ever engaged in terrorist activities, espionage, sabotage, or genocide?

zaterdag 9 april 2011 11:04

Acties:

0 Henk 'm!

GWTommy

Topicstarter

Ik bedoelde dat ik al genoeg tijd had verdaan met deze irritante bug in IE.

zondag 10 april 2011 09:11

Acties:

0 Henk 'm!

Makkelijk

Het is op zich geen bug, jQuery (of eigenlijk Sizzle) doet nou eenmaal dingen waarvoor javascript niet per se bedoeld is. Als je een stuk of wat attribute selectors doet (en zéker met een * er in) en dan in firebug profiled hoeveel % CPU er door selectors wordt gebruikt dan schrik je. Mijn eigenlijk beleid met selectors is dat ik ze alleen maar met live handlers gebruik. Dan zijn ze namelijk een stuk sneller.

Badieboediemxvahajwjjdkkskskskaa

zondag 10 april 2011 19:49

Acties:

0 Henk 'm!

R4gnax

Jquery
Javascript

Heel het probleem wat hier besproken wordt kan vermeden worden door gebruik te maken van een rel attribuut op de relevante links:

JavaScript:

1	$("#div a[rel='full'").click(function(e){ e.preventDefault(); /* ... */ });

Het is waarschijnlijk ook een stuk sneller uit te voeren dan matches op het href attribuut (wat bijna altijd aanwezig is op links). Nog sneller zou het zijn om gewoon van een class gebruik te maken:

JavaScript:

1	$("#div a.full").click(function(e){ e.preventDefault(); /* ... */ });

Overigens moet je ook nooit "div#div" als selector gebruiken, maar gewoon "#div". Het eerste geval is veel duurder om uit te voeren en jQuery / Sizzle bevat geen logica die dit soort foutjes voor je weg optimaliseert.

Makkelijk schreef op zondag 10 april 2011 @ 09:11:
Het is op zich geen bug, jQuery (of eigenlijk Sizzle) doet nou eenmaal dingen waarvoor javascript niet per se bedoeld is.

Je, meent het ?

Makkelijk schreef op zondag 10 april 2011 @ 09:11:
Als je een stuk of wat attribute selectors doet (en zéker met een * er in) en dan in firebug profiled hoeveel % CPU er door selectors wordt gebruikt dan schrik je. Mijn eigenlijk beleid met selectors is dat ik ze alleen maar met live handlers gebruik. Dan zijn ze namelijk een stuk sneller.

Selectors met live handlers zijn net zo langzaam. Ze gebruiken onder de kap dezelfde API, wat voor moderne browsers neerkomt op een dunne schil om querySelectorAll heen. Tenminste, zolang je geen constructies gebruikt die daarmee niet afgehandeld kunnen worden door de browser implementatie. Buiten een paar shortcircuits voor simpele selectors op basis van element ID bevat Sizzle namelijk geen query optimizer om queries op te delen in zo efficient mogelijk af te handelen deelproblemen. Dat wil zeggen dat de complete query ineens door querySelectorAll afgehandeld moet kunnen worden, anders wordt voor de complete query het fallback (emulatie) pad gebruikt.

zondag 10 april 2011 20:21

Acties:

0 Henk 'm!

Makkelijk

R4gnax schreef op zondag 10 april 2011 @ 19:49:
Heel het probleem wat hier besproken wordt kan vermeden worden door gebruik te maken van een rel attribuut op de relevante links:
JavaScript:
1
$("#div a[rel='full'").click(function(e){ e.preventDefault(); /* ... */ });
Het is waarschijnlijk ook een stuk sneller uit te voeren dan matches op het href attribuut (wat bijna altijd aanwezig is op links). Nog sneller zou het zijn om gewoon van een class gebruik te maken:
JavaScript:
1
$("#div a.full").click(function(e){ e.preventDefault(); /* ... */ });
Overigens moet je ook nooit "div#div" als selector gebruiken, maar gewoon "#div". Het eerste geval is veel duurder om uit te voeren en jQuery / Sizzle bevat geen logica die dit soort foutjes voor je weg optimaliseert.

[...]

Je, meent het ?

[...]

Selectors met live handlers zijn net zo langzaam. Ze gebruiken onder de kap dezelfde API, wat voor moderne browsers neerkomt op een dunne schil om querySelectorAll heen. Tenminste, zolang je geen constructies gebruikt die daarmee niet afgehandeld kunnen worden door de browser implementatie. Buiten een paar shortcircuits voor simpele selectors op basis van element ID bevat Sizzle namelijk geen query optimizer om queries op te delen in zo efficient mogelijk af te handelen deelproblemen. Dat wil zeggen dat de complete query ineens door querySelectorAll afgehandeld moet kunnen worden, anders wordt voor de complete query het fallback (emulatie) pad gebruikt.

Nouja, live handlers worden volgens mij gewoon op het document getriggered en met behulp van bubbling wordt gekeken of het element waarop je het event hebt gebind getarget is. Dat is toch een andere manier van matchen lijkt me?

En over de vriendelijke 'je... meent... het', ik was in de veronderstelling dat href een attribuut is waarvoor selectors nooit bedoeld waren. Kennelijk mag het wel, het blijft een vreemd concept om het te doen.

Badieboediemxvahajwjjdkkskskskaa

maandag 11 april 2011 10:18

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Jquery
Javascript

Waarom zou je altijd event delegation gebruiken? Lijkt me juist nogal overkill.

maandag 11 april 2011 10:33

Acties:

0 Henk 'm!

_Thanatos_

Ja, en kaal

Nouja, live handlers worden volgens mij gewoon op het document getriggered en met behulp van bubbling wordt gekeken of het element waarop je het event hebt gebind getarget is. Dat is toch een andere manier van matchen lijkt me?

Bijna

Live handlers worden gezet op de context van je selectie. Het tweede argument van de $() aanroep met selector dus zegmaar. Als je die niet meegeeft, dan is dat document. Maar daarom wordt ook door jQuery zelf aangeraden om bij live handler *altijd* een context mee te geven, om performance-redenen die hopelijk duidelijk zijn.

[ Voor 7% gewijzigd door _Thanatos_ op 11-04-2011 10:34 ]

日本！🎌

maandag 11 april 2011 10:36

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Jquery
Javascript

Er wordt ook geadviseerd heel live() niet te gebruiken, maar daarvoor de nieuwe delegate() te gebruiken.

Bij live kun je namelijk geen context opgeven en bubbelt alles naar het document. Delegate is de nieuwe context-sensitive versie.

Live handlers worden gezet op de context van je selectie.

Niet dus.

[ Voor 54% gewijzigd door Bosmonster op 11-04-2011 10:39 ]

dinsdag 12 april 2011 09:15

Acties:

0 Henk 'm!

R4gnax

Jquery
Javascript

Bosmonster schreef op maandag 11 april 2011 @ 10:36:
[...]
Niet dus.

Toch wel: vanaf jQuery 1.4 maakt live() onder de kap gebruik van delegate() en kan het live event gebonden worden aan de context v/d selector i.p.v. de document root.

JavaScript:

// Live bind:
$(".foo", context).live("click", handlerFn);

// Is equal to delegated bind:
$(context).delegate(".foo", "click", handlerFn);

dinsdag 12 april 2011 09:43

Acties:

0 Henk 'm!

Bosmonster

*zucht*

Jquery
Javascript

Dat maakt live() alleen nog maar zinlozer. (en mogen ze de documentatie wel eens updaten

)

The handler passed to .live() is never bound to an element; instead, .live() binds a special handler to the root of the DOM tree.

dinsdag 12 april 2011 12:16

Acties:

0 Henk 'm!

R4gnax

Jquery
Javascript

Bosmonster schreef op dinsdag 12 april 2011 @ 09:43:
Dat maakt live() alleen nog maar zinlozer. (en mogen ze de documentatie wel eens updaten )

[...]

Live isook zinloos. Mettertijd gaan live() en tegenhanger die() dan ook een deprecated status krijgen, wanneer het vervangende delegate() en undelegate() genoeg ingeburgerd zijn. Daarom wordt er nu actief geadviseerd om deze vervangers te gaan gebruiken.

Wat betreft out-of-date API documentatie; daar is een categorie voor beschikbaar in de jQuery bug tracker. (Ja echt...) Je kunt er dus even een bug voor inschieten, als je wilt.

Onderwerpen