[PHP] Valideren van een DomDocument als HTML5?

[Xthemes.us]

Hallo,

Ik bouw een html5 pagina op als een DomDocument en dacht dat wel even makkelijk te valideren m.b.v. van de relaxngvalidate functie... nou dat valt dus nog wel tegen. De enige html5 relax bestanden die ik kan vinden zijn blijkbaar geschreven in relaxnc (de compacte variant) in plaats van relaxng. Dit hapt deze functie dus niet.
Er zijn wel applicaties te vinden die relaxng naar relaxnc omzetten maar die zijn blijkbaar niet erg betrouwbaar, aangezien de HTML5 spec nog steeds niet helemaal klaar ligt is dit dan niet ideaal.

Daarnaast wordt er ook gebruik gemaakt van schematron bestanden maar daar zijn wel oplossingen voor te vinden.

Heeft iemand nog een beter idee dan mijn huidige plan? Voorkeur ligt toch wel erg sterk bij lokale oplossingen (geen externe servers raadplegen) en als het kan het vermijden van externe applicaties geschreven in andere talen.

[Verwijderd]

Moest dit zelf ook doen voor mijn stage een tijdje geleden maar heb dit uiteindelijk opgegeven, de relaxjes die er zijn, zijn niet erg betrouwbaar + inderdaad niet om te zetten.

De oplossing die wij hebben gebruikt is gewoon die van w3 gebruiken (geautomatiseerd, dat dan weer wel), maar nog steeds via Selenium. Ze hadden een experimentele API maar die is sinds 2007 volgens mij niet meer geupdate, vandaar Selenium. Je blijft dan wel afhankelijk van w3, waar de HTML5 specs overigens (uiteraard) ook nog experimental zijn.

Waarom MOET het perse intern liggen? Probleem is dat zodra de specs veranderen je hem weer moet gaan updaten. Gewoon w3 gebruiker vermijdt dit probleem.

[Xthemes.us]

De huidige manier van werken in HTML4 laat in de testomgeving altijd alles valideren. Dit gaat snel genoeg om het gewoon bij elke page load te laten doen, Als je er elke keer een externe server bij betrekt gaat de snelheid er wel uit. Daarnaast, mocht het internet er ooit eens uitliggen dan is lokaal werken toch altijd een groot voordeel.

De beste optie op het moment lijkt dan toch om de validatie te laten doen via validator.nu.. maar dan een lokale install op de development server.

In ieder geval bedankt voor je antwoord, Selenium kende ik nog niet.. kan nog wel eens handig voor de bugtracker wezen.

[ Voor 10% gewijzigd door Xthemes.us op 23-09-2011 09:06 ]

[RobIII]

Xthemes.us schreef op vrijdag 23 september 2011 @ 09:04:
De huidige manier van werken in HTML4 laat in de testomgeving altijd alles valideren. Dit gaat snel genoeg om het gewoon bij elke page load te laten doen, Als je er elke keer een externe server bij betrekt gaat de snelheid er wel uit.

Keyword: Asynchroon

[Xthemes.us]

Vandaar ook dat ik het wil vermijden, want asynchroon werkt niet echt met serverside talen, het moet gewoon synchroon gebeuren.

Tenzij ik iets over het hoofd zie (nee javascript/meta refreshende iframes zie ik niet als een oplossing).

[Cartman!]

Wat is precies je doel met de validatie dan?

[Xthemes.us]

Cartman! schreef op vrijdag 23 september 2011 @ 14:56:
Wat is precies je doel met de validatie dan?

Valideren? Tjah, weet ik niet precies wat ik daar op moet zeggen.

[ Voor 13% gewijzigd door Xthemes.us op 26-09-2011 08:53 ]

[sfranken]

Xthemes.us schreef op vrijdag 23 september 2011 @ 14:46:
Vandaar ook dat ik het wil vermijden, want asynchroon werkt niet echt met serverside talen, het moet gewoon synchroon gebeuren.

Tenzij ik iets over het hoofd zie (nee javascript/meta refreshende iframes zie ik niet als een oplossing).

Geef dan alsjeblieft eens een voorbeeld waarom asynchroon niet werkt met serverside talen? Ik dacht dat een techniek als AJAX hier juist voor bedoeld is.

[Xthemes.us]

Omdat je twee keer iets synchroon iets uitvoert, je tweede keer wordt aangeroepen door de client-side. Dat maakt niet plots asynchroon. Serverside creëer je een pagina en dat is het einde van een pagina. Als die pagina eenmaal in je browser staat doe je er vanuit datzelfde proces op de server niets meer, dat is nu eenmaal hoe het web werkt.

Maar goed, laten we niet op de details ingaan wat iedereen als synchroon of asynchroon ziet. Het belangrijke is dat je als dev op f5 moet kunnen drukken en kan zien dat het valide is of niet, zonder daarbij op een tweede request te wachten die soms iets langer op zich laat wachten waardoor je het over het hoofd ziet als je snel bent met het alt tabben.

[sfranken]

hmm, ja als je het zo bekijkt snap ik ineens waarom je dit zo wilt doen. Het nadeel is natuurlijk (zoals je zelf al aandraagt) dat HTML5 nog lang niet "af" is (en dat ook nooit gaat worden als het "rolling release" balonnetje van het W3C werkelijkheid word). Daarom zijn er ook nog geen documenten beschikbaar voor de techniek waar jij mee werkt.

Misschien toch eens kijken naar een AJAX oplossing? Je hebt in mijn ogen mijn vorige vraag niet echt beantwoord waarom je niet met een AJAX call wilt werken. Ongeduld (om even 2 - 5 seconden langer te wachten) is in mijn ogen namelijk geen goede reden.

[Xthemes.us]

Wellicht een verschil in werkwijze? Ik ben erg snel geneigd om een
*type iets* ctrl+s, alt+tab, f5 routine te gebruiken als ik iets aan het uitproberen ben.

Daarnaast kan ik me ook situaties indenken (pagina's bedoeld om te emailen) waarbij javascript gedisabled staat en het request uberhaupt nooit word uitgevoerd.

[edit]
Aanvulling:
De beste methode die ik tot nu toe gevonden heb is om de java validator van validator.nu aan te roepen vanuit PHP. Niet ideaal, maar in ieder geval crossplatform en simpel aan te roepen (is dezelfde validator die het w3c zelf gebruikt trouwens).

[ Voor 32% gewijzigd door Xthemes.us op 26-09-2011 09:49 ]

[sfranken]

Xthemes.us schreef op maandag 26 september 2011 @ 09:42:
Wellicht een verschil in werkwijze? Ik ben erg snel geneigd om een
*type iets* ctrl+s, alt+tab, f5 routine te gebruiken als ik iets aan het uitproberen ben.

Dat heb ik ook maar ik wil niet bij elke change die ik maak kijken of het document nog valid is. Ik heb genoeg vertrouwen in mijn eigen HTML/CSS skills om dit pas op het einde van de dag een keer te doen.

Maar wat je aanhaalt over mail paginas snap ik wel, maar uhm, javascript disabled? Controleer jij dan of een email adres wat je invult wel goed is aan de serverkant via een POST/GET request en nieuwe page load of ga ik hier nu de (ochtend)mist in?

edit
Als je firefox gebruikt kun je het natuurlijk ook met deze mooie plugin doen.

[ Voor 8% gewijzigd door sfranken op 26-09-2011 09:50 . Reden: Bijvoegen van een link ]

[ytterx]

offtopic:

sfranken schreef op maandag 26 september 2011 @ 09:47:
Maar wat je aanhaalt over mail paginas snap ik wel, maar uhm, javascript disabled? Controleer jij dan of een email adres wat je invult wel goed is aan de serverkant via een POST/GET request en nieuwe page load of ga ik hier nu de (ochtend)mist in?

Ik mag hopen dat jij dit ook doet anders heb je nu al een groot beveiliging lek. Met Javascript kan je idd sneller feedback geven aan de gebruiker dat het ingevoerde e-mail adress niet klopt. maar als je vervolgens op je server niet nogmaals checkt kan ik nu al zeggen dat je mogelijk veel e-mail adressen hebt die niet valid zijn.

ontopic:
Ik valideer de pagina's als ik ze maak ongeveer 1 keer per uur meestal zijn dat kleine foutjes.
de HTML 5 standaard is nog niet helemaal compleet dus om zo'n functie te maken moet er om de zoveel tijd de functie worden aangepast om nog mee te gaan met de standaard.

[ Voor 17% gewijzigd door ytterx op 26-09-2011 09:57 ]

[sfranken]

ytterx schreef op maandag 26 september 2011 @ 09:54:
[...]


Ik mag hopen dat jij dit ook doet anders heb je nu al een groot beveiliging lek. Met Javascript kan je idd sneller feedback geven aan de gebruiker dat het ingevoerde e-mail adress niet klopt. maar als je vervolgens op je server niet nogmaals checkt kan ik nu al zeggen dat je mogelijk veel e-mail adressen hebt die niet valid zijn

Tuurlijk laat ik het serverside checken. Ik gebruik het script op de pagina zelf via een AJAX call en dan als je op de submit knop klikt nog een keer (maar dan met meer checks). Die fout heb ik in het verleden gemaakt maar dan stoot je je hoofd en dan leer je daar weer van.

Goed, zo te zien is er ook voor Chrome een extentie beschikbaar al weet ik niet of die al HTML5 slikt

[RobIII]

Wat jij wil is iets als de HTML validator plugin voor Firefox maar dan voor HTML5?

[edit] hierboven is me net voor
Dat kan prima asynchroon en ik zou niet weten waarom je dat niet zou willen.

[ Voor 42% gewijzigd door RobIII op 26-09-2011 10:00 ]

[Xthemes.us]

Gebruik zelf Firefox (en ben er gek mee!), maar in ieder geval 1 van de andere ontwikkelaars gebruikt Chrome.

Ik bedoelde een pagina die gemailed wordt, b.v. een nieuwsbrief. Voor het testen wil ik dan nog wel eens javascript uitzetten (en vergeten weer aan te zetten). Waarschijnlijk een non-probleem aangezien HTML5 waarschijnlijk de komende 20 jaar niet kan worden gebruikt per mail, lang leve Outlook 2007 met de Word HTML engine die nog net HTML3 of iets in die richting snapt. Maar goed javascript vind ik echt geen optie.

Validatie van email-adressen zit hier wel snor trouwens, alles verloopt via classes die al jaren staan als een huis.

[sfranken]

Xthemes.us schreef op maandag 26 september 2011 @ 09:59:
Maar goed javascript vind ik echt geen optie.

Leg dan eens uit waarom alsjeblieft? En zie mijn posts hierboven voor een FF extentie die ook HTML5 doet

[ Voor 12% gewijzigd door sfranken op 26-09-2011 10:02 . Reden: Linkje bijgevoegd ]

[Xthemes.us]

RobIII schreef op maandag 26 september 2011 @ 09:58:
Wat jij wil is iets als de HTML validator plugin voor Firefox maar dan voor HTML5?

Nou nee, ik wil het liefst een relaxng schema (in het niet compact-formaat) voor PHP. Geen client-side gedoe maar gewoon serverside.
Voor HTML4 kon je aan de hand van de DTD's de boel mooi valideren (en dat was lekker vlot als je de DTDs lokaal hebt staan), laat ze nou net de DTD's weggehaald hebben bij HTML5.

[Xthemes.us]

sfranken schreef op maandag 26 september 2011 @ 10:00:
Leg dan eens uit waarom alsjeblieft? En zie mijn posts hierboven voor een FF extentie die ook HTML5 doet

Te traag / gaat op z'n gat als javascript disabled is (site moet ook werken zonder js dus dat komt geregeld voor).

Gebruik zelf Firefox (en ben er gek mee!), maar in ieder geval 1 van de andere ontwikkelaars gebruikt Chrome.

[sfranken]

*mompelt iets over het wijzigen van je bericht als je nog wat wilt zeggen totdat ik me realiseer dat ik hier geen mod ben*

Anyway, als je perse met PHP aan de slag wil maar het er nog niet is kun je 2 dingen doen
1) Het zelf schrijven
2) Wachten tot iemand anders het geschreven heeft.

edit
Traag valt wel mee, dat 't op z'n gat gaat is helaas wel waar ja. Goeie reden

[ Voor 26% gewijzigd door sfranken op 26-09-2011 10:06 . Reden: lees/schrijf snelheid probleem ]

[RobIII]

Xthemes.us schreef op maandag 26 september 2011 @ 10:04:
[...]

Te traag / gaat op z'n gat als javascript disabled is (site moet ook werken zonder js dus dat komt geregeld voor).


[...]

Ik neem aan dat je site voor je eindgebruikers zonder JS moet kunnen werken; ik zie dan ook geen probleem Je kunt voor je ontwikkelaars toch prima JS als vereiste stellen? IMHO maak je 't veel moelijker dan nodig. Ik zie niet wat je eindgebruikers met validatie te schaften hebben?

[ Voor 6% gewijzigd door RobIII op 26-09-2011 10:15 ]

[Xthemes.us]

Ik weet dat ik eigenwijs ben, maar goed. Javascript is vaak 1 van de dingen die ik pas op het einde test, zet ik het uit en maak ik wellicht nog een paar wijzigingen. Dan wil ik natuurlijk niet hebben dat ik het commit (versioning system) terwijl er een div rechstreeks in een ul zit of iets in die richting.

[sfranken]

Ontiwikkel je op Windows of op Ubuntu? Want voor de laatste is een CLI package beschikbaar om HTML paginas te valideren.

[Xthemes.us]

De server draait wel een Linux van de .deb-familietak der Linuxen maar goed, ik zie er uberhaupt niet bijstaan dat dit bedoeld is voor HTML5?
"SGML parser for conformance to official HTML standards"

HTML5 is nog niet echt 'official'.

[sfranken]

Je moet ook niet voor een dubbeltje op de 1e rij willen zitten. HTML5 is nog niet "af" (zoals eerder aangegeven) dus zijn er nog (weinig) tools om HTML5 documenten te valideren op de validator van het W3C na dan (al was dat geen optie, jammer..)