[JS] native hashchange support checken

[Clay]

De nieuwste versies van zo'n beetje alle browsers ondersteunen nu native het hashchange event, echter doen oudere dat nog niet. Nou zoek ik een betrouwbare check om de browser te vragen of die het kan of niet, en daar stuit ik op wat problemen;

Dit zegt in Firefox en Safari true, maar errort in IE, en geeft false in Chrome en Opera:

JavaScript:

var canhash = window.hasOwnProperty("onhashchange");

Dit zegt true in Firefox, errort in Opera, en geeft false in alle andere.

JavaScript:

var canhash = onhashchange in window;

Via document.implementation.hasFeature() ben ik ook niet echt verder gekomen, dus ik zit een beetje vast. Weet iemand waar dit zit?

Het is overigens voor zo'n extra'tje dat alles net ff wat mooier maakt, ik ga dan ook niet moeilijk doen met pollers of andere wazige constructies; het is native of niks.

[crisp]

JavaScript:

var canhash = 'onhashchange' in window

lijkt me handiger

of misschien

JavaScript:

var canhash = typeof window.onhashchange != 'undefined';

Check anders even de sourcecode van modernizr; die doet nog een extra check mbv setAttribute en checked ook documentMode (voor IE compat mode).

[ Voor 35% gewijzigd door crisp op 23-08-2010 21:52 ]

[Clay]

Geven beide ook true in IE7, en die kan het toch echt niet

Modernizr had ik gevonden ja, mss toch ff naar kijken dan.

[crisp]

Clay schreef op maandag 23 augustus 2010 @ 22:10:
Geven beide ook true in IE7, en die kan het toch echt niet

native IE7, of IE7 mode in IE8?

Modernizr had ik gevonden ja, mss toch ff naar kijken dan.

Die is vrij straightforward; de basis is wel de 'in' check maar hij checked nog wat corner-cases (waaronder dus IE7 compat mode).

[Clay]

Quote'jes deden wonderen idd Verder moet je IE7 mode in IE8 er idd uitfilteren, en Opera heeft de setAttrribute check nodig.

jeuj

[.oisyn]

Kun je niet ook gewoon doen:

JavaScript:

if (window.onhashchange)

?

undefined evalueert naar false, en een willekeurige functie evalueert naar true.

[ Voor 36% gewijzigd door .oisyn op 23-08-2010 22:51 ]

[crisp]

.oisyn schreef op maandag 23 augustus 2010 @ 22:50:
Kun je niet ook gewoon doen:

JavaScript:

if (window.onhashchange)

?

undefined evalueert naar false, en een willekeurige functie evalueert naar true.

Nee, die check geeft sowieso initieel een falsy waarde in iedere browser. In sommige browsers kan je wel checken of het undefined of NULL is, maar checken met de in-operator is dan betrouwbaarder. Je moet dan echter alsnog een extra check doen voor browsers die eventhandlers niet op die manier al standaard 'zichtbaar' maken voor de DOM.

Good reading: http://perfectionkills.co...without-browser-sniffing/

[.oisyn]

Oh ja, duh, hij moet dan natuurlijk wel geset zijn, en niet zoals bijv. bij XMLHttpRequest dat ie altijd wel ergens naartoe wijst.

[Clay]

hmz, ik herinnerde me ineens ook deze nog; http://code.google.com/in...g/docs/specification.html

Leeft dit een beetje? 't ziet er wel ontzettend handig uit nml.

[crisp]

Clay schreef op dinsdag 24 augustus 2010 @ 13:21:
hmz, ik herinnerde me ineens ook deze nog; http://code.google.com/in...g/docs/specification.html

Leeft dit een beetje? 't ziet er wel ontzettend handig uit nml.

Nog geen behoefte aan gehad; al onze content is ook zonder Ajax wel te bereiken

Het lijkt me meer een workaround voor sites die feitelijk niet de best practice van gelaagd bouwen (progressive enhancement) hebben gevolgd...

[Clay]

Nog geen behoefte aan gehad; al onze content is ook zonder Ajax wel te bereiken

Hmz, het lijkt idd handig, totdat je ermee aan de gang gaat geen enkele link met #! in de href doet meer wat zonder JS natuurlijk. Dan is het misschien leuk als google het kan spideren, maar een echte gebruiker kan niks meer.

De #! notatie an sich lijkt wel meer voor te komen. Facebook b.v. doet er zo te zien ook dynamische href rewrites mee.

[Bosmonster]

Wat dat betreft is die #! methode compleet nutteloos met zicht op progressive enhancement. Want wat je daarvoor over het algemeen juist wilt is normale url's die werken en deze met JS herschrijven.

Maar als je ze met JS herschrijft ziet de crawler ze weer niet volgens mij (en hoeft deze ook niet te zien, de normale urls werken al). Ben wat dat betreft benieuwd wat die Facebook-implementatie hiervan voor zin heeft.

[ Voor 36% gewijzigd door Bosmonster op 25-08-2010 10:55 ]

[Clay]

Waarschijnlijk alleen om de chat open te kunnen houden