reCaptcha en jScrollPane werken niet lekker samen

[Svennetjee]

Hey,

ik zit met een probleem. Ik heb reCaptcha als anti-spam oplossing op mijn site gezet, en nu wil ik custom scrollbalken in mijn divjes regelen met jScrollPane. Nu zit dat elkaar op de een of andere manier flink in de weg.

Wanneer ik een pagina opstart waar én een reCaptcha formuliertje staat én waar jScrollPane op is geladen, laadt de pagina helemaal, tot het DOM ready is, en dan wordt de pagina op de een of andere manier gerefreshed en zie ik alleen maar een geheel witte pagina. De broncode is helemaal leeg.

Hoe ik weet dat het pas gebeurt als het DOM geladen is: als ik aan het eind van het script een die(); er in gooi, wordt alles nog wel gewoon geladen.

Firebug geeft me de volgende melding terug:

Operation is not supported" code: "9

Op internet is er vrij weinig over te vinden, behalve dat het iets te maken kan hebben met een document.write() in XHTML 1.1. Althans dat is wat ik van de enige twee Google resultaten heb begrepen..

Heeft iemand hier ervaring mee, evt. hetzelfde probleem al eens gehad? Hulp zou gewaardeerd worden

Svennetjee

[Bosmonster]

Je hebt het over XHTML 1.1. Heb je het probleem ook met XHTML 1.0 of HTML 4?

[ Voor 68% gewijzigd door Bosmonster op 10-08-2009 10:16 ]

[crisp]

reCaptcha gebruikt inderdaad document.write(). Dat gaat dus niet samen met een document geserveerd als XHTML.

De vraag is dus: is er echt een reden dat je XHTML gebruikt (en blijkbaar ook zo serveert naar bepaalde(?) browsers?

[Svennetjee]

crisp schreef op maandag 10 augustus 2009 @ 10:26:
reCaptcha gebruikt inderdaad document.write(). Dat gaat dus niet samen met een document geserveerd als XHTML.

De vraag is dus: is er echt een reden dat je XHTML gebruikt (en blijkbaar ook zo serveert naar bepaalde(?) browsers?

Ja dat is zo, ondersteunende browsers krijgen de pagina gewoon met de application/xhtml+xml header.

Maar ik heb besloten om jScrollPane er maar gewoon af te halen. Als ik een flash filmpje in het scroll gedeelte zette dat groter was dan het scroll gedeelte zelf, dan overlapte dat gewoon..

[crisp]

Svennetjee schreef op maandag 10 augustus 2009 @ 12:03:
[...]


Ja dat is zo, ondersteunende browsers krijgen de pagina gewoon met de application/xhtml+xml header.

Dat impliceert dus dat je niet-ondersteunende browsers gewoon een text/html content-type header stuurt en dus feitelijk geen gebruik maakt van zaken waar XHTML voor benodigd is. Waarom zou je dan nog XHTML gebruiken ipv HTML aangezien je je daarmee enkel maar beperkt en je het jezelf enkel lastig maakt (content-type negotiation doen, risico op YSOD)?

Maar ik heb besloten om jScrollPane er maar gewoon af te halen. Als ik een flash filmpje in het scroll gedeelte zette dat groter was dan het scroll gedeelte zelf, dan overlapte dat gewoon..

uhm, het lijkt me juist dat reCaptcha de "Operation not supported" error oplevert

[Svennetjee]

crisp schreef op maandag 10 augustus 2009 @ 12:21:
uhm, het lijkt me juist dat reCaptcha de "Operation not supported" error oplevert

Dat doet het dus uiteindelijk niet. En dat vond ik al zo vreemd..

[_Thanatos_]

De vraag is dus: is er echt een reden dat je XHTML gebruikt (en blijkbaar ook zo serveert naar bepaalde(?) browsers?

De vraag is ook: waarom gebruik je een captcha? Je weet dat het hartstikke intrusive en error-prone is. Ik zou gewoon een simpele vraag stellen waar maar 1 mogelijk antwoord op bestaat, zoals "wat is 2+5?"

Bovendien, je afvragen of XHTML de goede keus is, kun je ook omdraaien:
Waarom zou je HTML4 gebruiken

[ Voor 14% gewijzigd door _Thanatos_ op 11-08-2009 00:36 ]

[crisp]

_Thanatos_ schreef op dinsdag 11 augustus 2009 @ 00:35:
[...]

De vraag is ook: waarom gebruik je een captcha? Je weet dat het hartstikke intrusive en error-prone is. Ik zou gewoon een simpele vraag stellen waar maar 1 mogelijk antwoord op bestaat, zoals "wat is 2+5?"

En wat is zo'n vraag dan anders dan een captcha? En hoe is dat moeilijker te kraken dan bijvoorbeeld de hier genoemde reCaptcha?

Bovendien, je afvragen of XHTML de goede keus is, kun je ook omdraaien:
Waarom zou je HTML4 gebruiken

1) browser-support (IE ondersteunt geen XHTML)
2) geen draconische error-handling
3) support voor dynamische markup insertion tijdens het renderen (vnl veel 3rd party API's die daarop bouwen)
4) meer mogelijkheden tot 'minification' van de syntax

om maar een paar redenen te noemen

[_Thanatos_]

crisp schreef op dinsdag 11 augustus 2009 @ 01:25:
En wat is zo'n vraag dan anders dan een captcha? En hoe is dat moeilijker te kraken dan bijvoorbeeld de hier genoemde reCaptcha?

Je bent volgens mij intelligent genoeg om te begrijpen dat ik met een captcha natuurlijk een plaatje met scheve letters bedoel. Dat het technisch niet dat hoeft te zijn, moge duidelijk zijn. En nee, het is niet moeilijker te kraken, en daar gaat het ook niet om.

Enerzijds gaat het erom de spambots een drempel hoog genoeg op te werpen dat ze het niet meer de moeite waard vinden. Bij drukke sites zal die drempel hoger moeten zijn bij minder drukke sites. Anderzijds gaat het erom de gebruiker niet of zo min mogelijk lastig te vallen. Er zijn manieren om de gebruiker helemaal niet lastig te vallen, bijv met een random veld dat leeg moet zijn. Maar een eenvoudige(re) manier is een dergelijke vraag stellen, een die iedereen kan beantwoorden maar voor een spambot te moeilijk is of teveel moeite kost.

1) browser-support (IE ondersteunt geen XHTML)
2) geen draconische error-handling
3) support voor dynamische markup insertion tijdens het renderen (vnl veel 3rd party API's die daarop bouwen)
4) meer mogelijkheden tot 'minification' van de syntax

1) Daar heb je gelijk in, maar dat hoeft geen nadeel te zijn als je voor IE eventjes een uitzondering maakt. Fluitje van een cent voor een gemiddelde coder.
2) Dat wil ik juist wel. Als ik iets fout doe, wil ik niet dat de beol krakend vastloopt of in elkaar baggert. Ik wil dan gewoon weten waar de typfout zit. Foute html is fout, en wat mij betreft hoeft een browser dat niet te proberen te interpreteren. Als ik iets fout zeg, ga jij ook niet proberen te interpreteren wat ik dan misschien wel bedoelde.
3) Daar hebben we DOM voor. Dat 3rd parties op achterhaalde derrie bouwen, is hun probleem. DOM is een elegante, failsafe manier om je document te manipuleren en document.write is error-prone, onduidelijk, en slecht onderhoudbaar.
4) Minification door tags niet af te sluiten misschien, maar gzip/deflate lost dat verschil voor 99,9% al op. Ik zou niet al teveel moeite steken in die 0,1% extra minifaction die HTML4 oplevert, maar wel in de >50% die gzip/deflate kan opleveren.

En dan zeg ik nog over de voordelen van XHTML als taal.

[ Voor 36% gewijzigd door _Thanatos_ op 11-08-2009 21:57 ]

[crisp]

_Thanatos_ schreef op dinsdag 11 augustus 2009 @ 21:43:
[...]

Je bent volgens mij intelligent genoeg om te begrijpen dat ik met een captcha natuurlijk een plaatje met scheve letters bedoel. Dat het technisch niet dat hoeft te zijn, moge duidelijk zijn. En nee, het is niet moeilijker te kraken, en daar gaat het ook niet om.

Enerzijds gaat het erom de spambots een drempel hoog genoeg op te werpen dat ze het niet meer de moeite waard vinden. Bij drukke sites zal die drempel hoger moeten zijn bij minder drukke sites. Anderzijds gaat het erom de gebruiker niet of zo min mogelijk lastig te vallen. Er zijn manieren om de gebruiker helemaal niet lastig te vallen, bijv met een random veld dat leeg moet zijn. Maar een eenvoudige(re) manier is een dergelijke vraag stellen, een die iedereen kan beantwoorden maar voor een spambot te moeilijk is of teveel moeite kost.

Ik ben het met je eens dat captcha's voor mensen gewoon een nuisance zijn en dat het inderdaad slim is om eerst te kijken of je niet op een minder ubtrusieve manier een bepaalde mate van spam-bescherming kan creëeren. Echter kan ik dat niet beoordelen voor topicstarter. Hier zitten we ook al te denken om onze eigen captcha te gaan vervangen door reCaptcha voor de tweakblogs aangezien we hier en daar al geautomatiseerde spam zijn tegengekomen

[...]

1) Daar heb je gelijk in, maar dat hoeft geen nadeel te zijn als je voor IE eventjes een uitzondering maakt. Fluitje van een cent voor een gemiddelde coder.

Er zitten toch nog wel wat pitfalls in; de gemiddelde coder zal bijvoorbeeld niet zo snel bedenken dat je bij content-type negotiation ook moet denken aan Vary headers. Daarbij ben ik van mening dat als je al zo makkelijk een uitzondering kan maken voor MSIE je waarschijnlijk ook gewoon alle andere browsers HTML kan sturen. Bespaart je zelfs die (al dan niet kleine) moeite

2) Dat wil ik juist wel. Als ik iets fout doe, wil ik niet dat de beol krakend vastloopt of in elkaar baggert. Ik wil dan gewoon weten waar de typfout zit. Foute html is fout, en wat mij betreft hoeft een browser dat niet te proberen te interpreteren. Als ik iets fout zeg, ga jij ook niet proberen te interpreteren wat ik dan misschien wel bedoelde.

Toch wel; als jij een typfout maakt (zo schreef je hier "beol" wat waarschijnlijk "boel" moest zijn) dan probeer ik toch je post te interpreteren, of zal ik voortaan alle posts met spelfouten of typfouten ook maar negeren?
Foute HTML is meestal niet fataal, en daarbij hoef jij geen fout te maken in je markup: als je te maken hebt met user-input, 3rd part content en/of black-box (vaak non-XML-based) (pre)processing dan ligt een YSOD altijd op de loer, en daar wil je je bezoeker niet mee opzadelen. Het POSTen van een null-byte naar een XHTML-gebaseerde site die user-input ook weer terug-echoed is vaak genoeg...

3) Daar hebben we DOM voor. Dat 3rd parties op achterhaalde derrie bouwen, is hun probleem. DOM is een elegante, failsafe manier om je document te manipuleren en document.write is error-prone, onduidelijk, en slecht onderhoudbaar.

Maar voor elke site is de DOM weer anders. Als jij advertenties aanbied aan verschillende sites dan geef je een 'tag' die men op de plek waar ze een banner willen tonen kunnen neerzetten. Die 'tag' haalt meestal een extern script op die vervolgens mbv document.write de markup voor de banner injecteert. Snel en simpel. Ik zie daar zo gauw geen ander (beter) alternatief voor (iframes zijn ook niet zaligmakend).

Externe scriptjes die DOM-manipulaties gaan doen geven overigens de meeste problemen (komen we hier regelmatig tegen bij pop-over ads e.d.).

4) Minification door tags niet af te sluiten misschien, maar gzip/deflate lost dat verschil voor 99,9% al op. Ik zou niet al teveel moeite steken in die 0,1% extra minifaction die HTML4 oplevert, maar wel in de >50% die gzip/deflate kan opleveren.

Het is ook niet het sterkste punt, maar voor high-traffic sites kan het toch nog aardig wat schelen. Ik ben in ieder geval blij dat ik niet bij elke img- of inputtag zo'n loze / hoef te typen

[Bosmonster]

@_Thanatos

Dan ga je ervanuit dat een som oplossen voor iedereen even eenvoudig is. Iedere vorm van captcha (typ een reactie in op een vraag, of dat nu een afbeelding is of een som maakt hierin niks uit), heeft dezelfde issues. Je vraagt een zinloze, potentieel voor die persoon lastige, vraag.

En wat betreft de (X)HTML issue, tja. Dacht dat inmiddels wel duidelijk was dat als je geen X-based backend gebruikt XHTML een nogal zinloze standaard is om te gebruiken. Al was het alleen maar doordat IE het in z'n geheel niet ondersteunt.

Als je perse slashes wilt gebruiken om je tags af te sluiten (want daar komt de discussie uiteindelijk meestal op neer raar genoeg...) pak dan een HTML5 doctype en leef je uit.

[ Voor 42% gewijzigd door Bosmonster op 12-08-2009 09:48 ]

[_Thanatos_]

XHTML en HTML hebben dus zo hun voor- en nadelen. Ik zie meer voordelen in mijn situaties bij XHTML en jij, crisp meer in HTML. Dat is denk ik wel duidelijk uit je post

Die 'tag' haalt meestal een extern script op die vervolgens mbv document.write de markup voor de banner injecteert. Snel en simpel. Ik zie daar zo gauw geen ander (beter) alternatief voor (iframes zijn ook niet zaligmakend).

Laatste pmerking dan: we hebben ook innerHTML. Dat is weliswaar niet standaard, maar het breekt niet de XHTML DOM en alle browsers ondersteunen het. Een 3rd party script hoef je dus alleen maar een ID te voeren van de container waar ze de banner/counters/polls/feeds/whatever in moeten gieten.

Bosmonster, het is zeker niet zinloos om XHTML te gebruiken, ook zonder X-based backend. Het verdient mijn persoonlijke voorkeur, en eventuele nadelen zie ik niet als nadelen, dus zinloos is het zeker niet.

En HTML5 wordt nog door geen enkele browser ondersteund (en terecht - het is een draft), dus je uitleven zal moeilijk gaan

[crisp]

_Thanatos_ schreef op woensdag 12 augustus 2009 @ 23:01:
[...]

Laatste pmerking dan: we hebben ook innerHTML. Dat is weliswaar niet standaard, maar het breekt niet de XHTML DOM en alle browsers ondersteunen het. Een 3rd party script hoef je dus alleen maar een ID te voeren van de container waar ze de banner/counters/polls/feeds/whatever in moeten gieten.

Dat is dus alweer een handeling extra, en dit soort dingen werken dan alsnog niet:

JavaScript:

document.getElementById('banner').innerHTML = '<script src="bannerloader.js" type="text/javascript"><\/script>';

en dat is wel hoe veel banners worden geserveert: de 'tag' doet een request naar de bannerboer, en die serveert weer de nodige resources voor de banner zelf (die vaak zijn aangelevert door media-bedrijven, en zelf ook weer document.write gebruiken).
Kortom: niet haalbaar in de huidige banner-wereld...

Bosmonster, het is zeker niet zinloos om XHTML te gebruiken, ook zonder X-based backend. Het verdient mijn persoonlijke voorkeur, en eventuele nadelen zie ik niet als nadelen, dus zinloos is het zeker niet.

Zonder X-based backend heb je dus geen enkele garantie of controle over de wellformedness van je output...

En HTML5 wordt nog door geen enkele browser ondersteund (en terecht - het is een draft), dus je uitleven zal moeilijk gaan

Waar Bosmonster op doelt is dat de slash voor empty elements in HTML5 is toegestaan, en het je vrij staat nu al een HTML5 doctype te gebruiken (dat levert in geen enkele browser problemen op) en te valideren tegen de HTML5 specificatie. Over het algemeen zal wat valide HTML4.01 of XHTML1.x is ook gewoon als HTML5 valideren (dankzij backwards compatibility).