Javascript zorgt voor slechte HTML-validatie

[Lorduh]

Hallo,

Ik probeer mijn bestandje eens door w3.rog HTMl-validatie te halen. Nu stuit ik op een volgend probleem.

code:

# Line 147, Column 42: character "<" is the first character of a delimiter but occurred as data.

            if (document.body.clientWidth < 915)

&#9993;

This message may appear in several cases:

    * You tried to include the "<" character in your page: you should escape it as "&lt;"
    * You used an unescaped ampersand "&": this may be valid in some contexts, but it is recommended to use "&amp;", which is always safe.
    * Another possibility is that you forgot to close quotes in a previous tag.

# Error Line 147, Column 43: XML Parsing Error: StartTag: invalid element name.

            if (document.body.clientWidth < 915)

Het probleem waarover men het heeft:

code:

      <script type="text/javascript">
            if (document.body.clientWidth < 915)
            {
              document.body.style.width = 915;
            }
      </script>

Hij neemt dus die "<" als een fout. Nu ik heb eigenlijk gene idee hoe ik dit netjes kan oplossen.

Ik heb al wat rond gezocht om eventueel dat JS'je te vervangen maar ik vind niet echt een betere oplossing. Het JS'je heeft de bedoeling om min-width in IE6 "mogelijk te maken", dit omdatm ijn lay-out rekbaar is in breedte.

[BalusC]

Zet dat scriptje in een eigen .js bestand dat je via <script src=""> inlaadt. Of declareer je document als HTML ipv XHTML. Je kunt ook ervoor kiezen je nergens druk over te maken

[Snake]

Wikipedia: CDATA

[BarôZZa]

Je kan het ook met CSS oplossen, is een smerig scripttrucje voor in IE.

ff opgezocht (en niet veranderd, maar het moet wel te volgen zijn)

code:

width:expression(document.body.clientWidth > 1000? "950px": "95%" );

dit is dus een max-width. Een min-width kan je dus doen door < te gebruiken.

[ Voor 67% gewijzigd door BarôZZa op 24-04-2008 20:56 ]

[BalusC]

Snake schreef op donderdag 24 april 2008 @ 20:51:
Wikipedia: CDATA

Een CDATA blok om een JS'je heen staat zo smerig. Dan zou ik dat JS gewoon in een separaat bestand zetten en inladen via <script src>.

[Bosmonster]

BalusC schreef op donderdag 24 april 2008 @ 20:55:
[...]

Een CDATA blok om een JS'je heen staat zo smerig. Dan zou ik dat JS gewoon in een separaat bestand zetten en inladen via <script src>.

Hoezo staat dat smerig? Als je XHTML gebruikt moet je je ook aan de XHTML regels houden.

[Snake]

BalusC schreef op donderdag 24 april 2008 @ 20:55:
[...]

Een CDATA blok om een JS'je heen staat zo smerig. Dan zou ik dat JS gewoon in een separaat bestand zetten en inladen via <script src>.

'Staat' ? Wat maakt dat nu uit, het moet valideren, niet mooi staan

[crisp]

Bosmonster schreef op donderdag 24 april 2008 @ 22:35:
[...]


Hoezo staat dat smerig? Als je XHTML gebruikt moet je je ook aan de XHTML regels houden.

en ook de juiste mimetype gebruiken - jammer dat je daarmee ook IE-gebruikers uitsluit

kortom: als je geen XHTML nodig hebt, gebruik dan gewoon HTML

[Juup]

of je gebruikt een &lt; ipv een <.

[TeeDee]

Snake schreef op donderdag 24 april 2008 @ 22:38:
[...]
'Staat' ? Wat maakt dat nu uit, het moet valideren, niet mooi staan

Als we toch geen miepen: valideren _moet_ niet. Als ik een keer op een image geen alt zet, dan is mijn pagina niet valid. Terwijl ik er toch wel 2000% zeker van ben dat hij op elke browser goed weergegeven wordt. (ok, op een text only browser zal het e.e.a. niet helemaal lekker overkomen)

[ Voor 8% gewijzigd door TeeDee op 25-04-2008 15:58 ]

[RobIII]

TeeDee schreef op vrijdag 25 april 2008 @ 15:54:
[...]

Als we toch geen miepen: valideren _moet_ niet. Als ik een keer op een image geen alt zet, dan is mijn pagina niet valid. Terwijl ik er toch wel 2000% zeker van ben dat hij op elke browser goed weergegeven wordt. (ok, op een text only browser zal het e.e.a. niet helemaal lekker overkomen)

Validatie heeft dan ook geen drol met de weergave te maken
Dat het kan helpen bij het opsporen van fouten is iets anders; als je pagina valideert wil dat absoluut niet zeggen dat het altijd en overal hetzelfde rendert.

XHTML is in 99% van de gevallen waar het wordt gebruikt (idd met een verkeerd contenttype) compleet overbodig en wordt meestal alleen maar gebruikt omdat het 'nieuwer' of zelfs 'opvolger' is van "ouderwetse HTML" en omdat het stoer staat/gaaf is

[ Voor 20% gewijzigd door RobIII op 25-04-2008 16:00 ]

[_Thanatos_]

Als het pagina'specifiek is, is dit de nette manier, zéker in XHTML maar voor HTML geldt het evengoed:

HTML:

<script type="text/javascript">
//<![CDATA[
  if (x < 915) { doIets(); } //Verzin maar wat
//]]>
</script>

Overigens kun je je concrete probleem netter oplossen met die css-expression in een aparte IE6-stylesheet, en in je gewone stylesheet een min-width:915px;

[ Voor 9% gewijzigd door _Thanatos_ op 25-04-2008 19:16 ]

[curry684]

RobIII schreef op vrijdag 25 april 2008 @ 15:58:
[...]

XHTML is in 99% van de gevallen waar het wordt gebruikt (idd met een verkeerd contenttype)

XHTML 1.0 Transitional mag gewoon volgens de specs als text/html verstuurd worden, niets mis mee.

[Lorduh]

_Thanatos_ schreef op vrijdag 25 april 2008 @ 19:15:
Als het pagina'specifiek is, is dit de nette manier, zéker in XHTML maar voor HTML geldt het evengoed:

HTML:

<script type="text/javascript">
//<![CDATA[
  if (x < 915) { doIets(); } //Verzin maar wat
//]]>
</script>

Overigens kun je je concrete probleem netter oplossen met die css-expression in een aparte IE6-stylesheet, en in je gewone stylesheet een min-width:915px;

offtopic:
Ik wil me eerst excuseren voor mijn nogal late reactie.

Dat lijkt mij inderdaad het beste, want ik kan zal toch zoiets moeten doen voor IE6 wegens hier en daar nog kleine probleempjes. Toch bedankt allemaal. Als ik er niet uitgeraak horen jullie het wel.

[ Voor 4% gewijzigd door Lorduh op 26-04-2008 21:13 ]

[Borizz]

_Thanatos_ schreef op vrijdag 25 april 2008 @ 19:15:
Als het pagina'specifiek is, is dit de nette manier, zéker in XHTML maar voor HTML geldt het evengoed:

HTML:

<script type="text/javascript">
//<![CDATA[
  if (x < 915) { doIets(); } //Verzin maar wat
//]]>
</script>

Waarom zou je in HTML(4) aangeven dat iets in script tags CDATA is? De content in een script tag is namelijk volgens de HTML specificatie al CDATA in HTML 4. In XHTML bestaat de content uit PCDATA volgens de XHTML specificatie, dus in XHTML zou je het er wel in moeten zetten.

Dit geldt dus enkel voor XHTML..

[daniëlpunt]

Juup schreef op vrijdag 25 april 2008 @ 15:47:
of je gebruikt een &lt; ipv een <.

Ik schat in dat dat niet gaat werken in javascript.

[curry684]

super-muffin schreef op zaterdag 26 april 2008 @ 21:47:
[...]
Ik schat in dat dat niet gaat werken in javascript.

Met een goede parser juist wel in tegenstelling tot de non-escaped variant. Het zijn juist de tag-soup parsers die bij text/html mimetype worden ingeschakeld die allebei acceptabel parsen, met application/xhtml+xml werkt alleen degene met de correcte entity.

[crisp]

curry684 schreef op zaterdag 26 april 2008 @ 23:10:
[...]

Met een goede parser juist wel in tegenstelling tot de non-escaped variant. Het zijn juist de tag-soup parsers die bij text/html mimetype worden ingeschakeld die allebei acceptabel parsen, met application/xhtml+xml werkt alleen degene met de correcte entity.

wrong:

HTML:

<script type="text/javascript">

if (1 &lt; 2) alert('foo');

</script>

geeft toch mooi een "missing ) after condition" parse-error in text/html.

Overigens wordt onder "tag-soup" juist invalid en non-semantic markup verstaan. Je doelt met "tag-soup parser" waarschijnlijk op de lenient error-correctie van HTML-parsers maar niet alle HTML is daarmee natuurlijk tag-soup. Derhalve vind ik een dergelijke aanduiding van HTML-parsers eigenlijk niet helemaal eerlijk, zeker ook gezien de negatieve lading van het woord "tag-soup".

[_Thanatos_]

Waarom zou je in HTML(4) aangeven dat iets in script tags CDATA is? De content in een script tag is namelijk volgens de HTML specificatie al CDATA in HTML 4. In XHTML bestaat de content uit PCDATA volgens de XHTML specificatie, dus in XHTML zou je het er wel in moeten zetten.

Kan zijn, maar het feit blijft dat HTML4 een vreselijke bende is wat betreft parsing (van invalide markup), dus het is alleen maar beter om het er expliciet bij te zetten. Feit is ook dat mijn oplossing werkt en valide is, dus wat is het probleem dan? En als bonus is het ook nog es forwards compatible met XHTML.

[Borizz]

Oké en waarom zou je forward compatible willen zijn met XHTML i.p.v. HTML 5? Sluit je dan ook alvast je empty elements in je HTML document (<br />, <img /> etc.), wat echt ongeldig is in HTML?

In HTML 5 is de inhoud van de script tags ook nog steeds gedefinieerd als CDATA. Dus het is maar net waar je forward compatible mee wilt zijn. Naar mijn mening is dat eerder HTML 5 (zie je de 5..? de opvolger van 4) dan XHTML.

[curry684]

crisp schreef op zondag 27 april 2008 @ 21:04:
[...]

wrong:

HTML:

<script type="text/javascript">

if (1 &lt; 2) alert('foo');

</script>

geeft toch mooi een "missing ) after condition" parse-error in text/html.

Iets zegt me dat dit per browser nog wel verschilt Zuiver gezien moet dit beter parsen dan met < symbolisch.

Overigens wordt onder "tag-soup" juist invalid en non-semantic markup verstaan. Je doelt met "tag-soup parser" waarschijnlijk op de lenient error-correctie van HTML-parsers maar niet alle HTML is daarmee natuurlijk tag-soup. Derhalve vind ik een dergelijke aanduiding van HTML-parsers eigenlijk niet helemaal eerlijk, zeker ook gezien de negatieve lading van het woord "tag-soup".

Ik gebruikte express de term om het verschil tussen strict parsen en 'lenient error corrected parsing' te benadrukken. Hoewel tag-soup in de praktijk natuurlijk beladen is met Frontpage 97 flashbacks e.d. is het natuurlijk dezelfde logica die dat soort sites toonbaar maakt die in dit geval ook snapt dat de < in de JS hoort en geen nieuwe HTML-tag is.

Borizz schreef op donderdag 01 mei 2008 @ 10:50:
het is maar net waar je forward compatible mee wilt zijn. Naar mijn mening is dat eerder HTML 5 (zie je de 5..? de opvolger van 4) dan XHTML.

XHTML gaat gewoon een eigen opvolger krijgen, XHTML 2.0 (zie je de 2..? opvolger van 1). Of je je sites in HTML of XHTML ontwikkelt schrijft voor met welke standaard je forward compatible wil gaan zijn, en die keuze is puur situatieafhankelijk per site of applicatie.

[ Voor 18% gewijzigd door curry684 op 01-05-2008 12:25 ]

[Borizz]

curry684 schreef op donderdag 01 mei 2008 @ 12:23:

[...]

XHTML gaat gewoon een eigen opvolger krijgen, XHTML 2.0 (zie je de 2..? opvolger van 1). Of je je sites in HTML of XHTML ontwikkelt schrijft voor met welke standaard je forward compatible wil gaan zijn, en die keuze is puur situatieafhankelijk per site of applicatie.

Het ging over de stap (of eigenlijk het rekening houden met) van HTML naar XHTML. Wat jij aangeeft is van XHTML(1) naar XHTML2 en ik ben het met je eens dat ook dat een logische stap is.

[crisp]

curry684 schreef op donderdag 01 mei 2008 @ 12:23:
[...]

Iets zegt me dat dit per browser nog wel verschilt Zuiver gezien moet dit beter parsen dan met < symbolisch.

Zowel Firefox, Opera als IE(6) geven een parse error. HTML4 beschrijft het content-model van script (en style) als volgt:

quote: http://www.w3.org/TR/html4/types.html

Although the STYLE and SCRIPT elements use CDATA for their data model, for these elements, CDATA must be handled differently by user agents. Markup and entities must be treated as raw text and passed to the application as is.

Ook in HTML5 is script-content CDATA en worden entities niet geparsed as per spec.

[...]

Ik gebruikte express de term om het verschil tussen strict parsen en 'lenient error corrected parsing' te benadrukken. Hoewel tag-soup in de praktijk natuurlijk beladen is met Frontpage 97 flashbacks e.d. is het natuurlijk dezelfde logica die dat soort sites toonbaar maakt die in dit geval ook snapt dat de < in de JS hoort en geen nieuwe HTML-tag is.

Dat zei ik ook, maar praktisch gezien is er toch een verschil tussen tag-soup parsing en "lenient error correction". Het omgaan met unencoded speciale karakters als < en > in script-content wordt overigens door browsers anders geregeld dan jij hier voorstelt: een script-blok wordt namelijk pas expliciet afgesloten bij het voorkomen van </script (per HTML4 spec overigens al bij </[a-z] maar geen enkele browser doet dat). Voor de rest wordt er niets speciaals gedaan met < of >, enkel in het stricte XML-parsing proces geeft dat (well-formedness) problemen.

[...]

XHTML gaat gewoon een eigen opvolger krijgen, XHTML 2.0 (zie je de 2..? opvolger van 1). Of je je sites in HTML of XHTML ontwikkelt schrijft voor met welke standaard je forward compatible wil gaan zijn, en die keuze is puur situatieafhankelijk per site of applicatie.

Je gaat hier voorbij aan de XML-serialisatie van HTML5, aka XHTML5

Ik voorzie op korte termijn geen ondersteuning voor XHTML2 (dat overigens niet backwards-compatible is met XHTML1.x) door de grote browservendors itt (X)HTML5. Overigens geeft HTML5 ook nog minder reden om gebruik te maken van de XML-serialisatie omdat zelfs embedding van o.a. MathML en SVG gewoon in de HTML-serialisatie mogelijk wordt.

[_Thanatos_]

Borizz schreef op donderdag 01 mei 2008 @ 10:50:
Oké en waarom zou je forward compatible willen zijn met XHTML i.p.v. HTML 5? Sluit je dan ook alvast je empty elements in je HTML document (<br />, <img /> etc.), wat echt ongeldig is in HTML?

In HTML 5 is de inhoud van de script tags ook nog steeds gedefinieerd als CDATA. Dus het is maar net waar je forward compatible mee wilt zijn. Naar mijn mening is dat eerder HTML 5 (zie je de 5..? de opvolger van 4) dan XHTML.

Ten eerste omdat XHTML al een tijdje bestaat en HTML5 nog lang niet en veel slechter correct ondersteund wordt dan XHTML. Ten tweede is de CDATA-notatie van script in HTML5 nog steeds valid, en waarschijnlijk ook nog steeds noodzakelijk.

Laten we vooral geen XHTML/HTML5 war gaan houden, maar ff blijven bij het topic. Feit is gewoon heel simpel dat mijn oplossing werkt, en blijft werken. Hoe overbodig het in theorie ook is.

[Borizz]

Het is zeker valide, maar ik vind niet dat je moet zeggen dat het voor HTML de nette manier is om script te gebruiken aangezien het geen enkele toegevoegde waarde heeft.

[crisp]

_Thanatos_ schreef op donderdag 01 mei 2008 @ 17:14:
[...]

Ten eerste omdat XHTML al een tijdje bestaat en HTML5 nog lang niet en veel slechter correct ondersteund wordt dan XHTML.

Dat durf ik wel te betwisten aangezien er nog altijd een browser is (de meestgebruikte zelfs) die helemaal geen XHTML ondersteund en de HTML parsers in de huidige browsers meer compatible zijn met HTML5 dan met HTML4

Ten tweede is de CDATA-notatie van script in HTML5 nog steeds valid, en waarschijnlijk ook nog steeds noodzakelijk.

In de XML-serialisatie van HTML5 kan je inderdaad CDATA-blokken gebruiken, in de HTML-serialisatie bestaat dat concept niet buiten 'foreign' content als MathML en SVG dus moet je de boel 'hacken' net als in HTML4 (zoals je zelf al aangaf):

HTML:

<script type="text/javascript">
//<![CDATA[

  /* script hier */

//]]> 
</script>

en ja, dit is een hack - in de XML-serialisatie is de textContent van het script-element ook anders dan in de HTML-serialisatie.

Laten we vooral geen XHTML/HTML5 war gaan houden, maar ff blijven bij het topic. Feit is gewoon heel simpel dat mijn oplossing werkt, en blijft werken. Hoe overbodig het in theorie ook is.

Als je het puur doet om als XHTML te valideren zonder van zins te zijn het ook als XHTML te serveren dan is het niet alleen theoretisch overbodig maar ook praktisch overbodig

[BarôZZa]

De cdata-tags commenten in het javascriptje is werkelijk een hele smerige manier.

Sowieso is het de omgekeerde wereld. De bedoeling was juist om nette code te schrijven en de opmaak te scheiden van het document(tenminste, dat lijkt me als je kiest voor XHTML). Dan is javascript gebruiken om je layout aan te passen uberhaubt al een vieze methode. Als je dan ook nog eens vieze hacks toe gaat passen, om de validator voor de gek te houden, dan is het helemaal smerig.

Dan kan je bijna net zo goed je hele layout opbouwen uit tables. Als het maar valideert.

[crisp]

BarôZZa schreef op vrijdag 02 mei 2008 @ 01:36:
[...] De bedoeling was juist om nette code te schrijven en de opmaak te scheiden van het document(tenminste, dat lijkt me als je kiest voor XHTML).

Dat is niet inherent aan XHTML maar exact dezelfde doelstelling van HTML, in ieder geval voor de 'strict' variant. XHTML(1.x) is niets anders dan een andere serialisatie van dezelfde HTML variant...

[BarôZZa]

Als je voor strict kiest wel, maar ik denk dat transitional een stuk meer gebruikt wordt en daar kan je simpelweg makkelijker wegkomen met dingen. dat is nog altijd een erfenis uit het pre-css tijdperk.

Ik snap alleen niet dat als je bewust voor de stricte variant of Xhtml kiest, dat je dan nog steeds vieze code schrijft, puur en alleen om het te valideren. Dat kan nooit de bedoeling zijn.

Sowieso is het controleren van de verstergrootte bij het laden van de site al vreemd. Heb je een kleine venster en maximaliseer je deze, dan zit je met een veel te smalle layout. En wordt het alleen goed weergegeven als je refresht.

[Herko_ter_Horst]

Los van het feit dat JavaScript code niet in je HTML thuis hoort, wat is mis met de "traditionele" aanpak:

code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>
    <title>Script Test</title>
    <script type="text/javascript">
    <!--
        if(1 < 2) {
            alert('Hello World!');
        }
    // -->
    </script>
</head>

<body>
</body>

</html>

Dit valideert (en werkt) prima, ook in HTML 4.01 (en naar ik aanneem ook in XHTML2/5).

Het enige probleem zou hier de JavaScript kant kunnen zijn, omdat ik geen officiele spec heb kunnen vinden die expliciet het gebruik van een HTML comment aan het begin van een script toestaat. De JavaScript 1.2 Guide maakt hier nog wel melding van, maar in de references vind ik het nergens terug.

[ Voor 40% gewijzigd door Herko_ter_Horst op 02-05-2008 10:46 ]

[crisp]

Herko_ter_Horst schreef op vrijdag 02 mei 2008 @ 10:40:
[...]
Dit valideert (en werkt) prima.

Valideert inderdaad prima, maar werkt niet als XHTML

[Herko_ter_Horst]

Dat snap ik niet?

[crisp]

Herko_ter_Horst schreef op vrijdag 02 mei 2008 @ 10:47:
Dat snap ik niet?

Serveer het eens met een XHTML mimetype en kijk wat er (niet) gebeurd in een XHTML-capable browser...

[Herko_ter_Horst]

Aw shucks... Ik had hem met een html extensie vanaf schijf getest. Als ik er .xhtml van maak doet ie het inderdaad niet meer (in FireFox).

Ik zie nu in de XML spec ook waarom: een XML parser is niet verplicht comments door te geven aan de appliciatie (waarbij "de applicatie" in dit geval de JavaScript parser is).

Ok, genoeg geneuzel over work-arounds, zoals al eerder opgemerkt: gewoon doen zoals het hoort (waarom maak je je anders druk om XHTML strict) en de JavaScript naar een extern bestand verhuizen.