[xhtml/xml] &lt;script&gt; tag met &gt; en &lt; geldig of niet?

zondag 27 juli 2003 20:47

Software Architect

Werkt hier

Nee, dat is javascript en aangezien dat netjes tussen de script-tags staat is dat gewoon correct. Die validator van je is dus gewoon fout bezig,, de w3c-validator heeft dus de boel goed geaccepteerd.

Dit heeft verder niets met php en/of P&W te maken, het gaat om die javascript en aangezien dat gewoon correct is verder sluit ik je topic maar af.

[ Voor 28% gewijzigd door ACM op 27-07-2003 16:42 ]

Acties:

zondag 27 juli 2003 21:00

Software Architect

Werkt hier

Goed dan Soultaker

Soultaker stuurde de topicstarter een mailtje met een wel aardig discussie punt over XML/XHTML. Ik laat het aan Soultaker over om dat hier te posten, maar dat is de reden dat ie weer open is.
Alvast ter voorbereiding van die discussie heb ik de titel gewijzigd, daar ie op deze manier de lading beter dekt. Ik ben er alleen nog niet uit of het beter in P&W (vanwege xml) of in W&G (xhtml) kan

Acties:

Verwijderd

Het lijkt mij W&G. Ik dacht dat xml ook in W&G zat, maar ik weet het ook niet hoor. ACM zal het wel weten.
De fout die jij krijgt: je moet de inhoud in script tags 'escapen' met cdata sections. De parser moet dan dat gedeelte negeren.
http://www.w3schools.com/xml/xml_cdata.asp

zondag 27 juli 2003 21:03

Acties:

jochemd

http://www.w3.org/TR/xhtml1/#h-4.8

* jochemd vind deze mooier

[ Voor 59% gewijzigd door jochemd op 27-07-2003 21:06 ]

zondag 27 juli 2003 21:06

Acties:

zondag 27 juli 2003 21:13

Ik zal het probleem even samenvatten. Het gaat erom dat de W3C validator een document als het volgende accepteert:

XML:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="nl" xml:lang="nl" xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>test</title>
  </head>  
  <body>
    <p> < </p>        <!-- regel 9 -->
  </body>  
</html>

Maar een XML parser als RXP niet! Dat komt omdat die "<" op regel 9 volgens de XML standaard niet mag voorkomen tussen tags:

In the content of elements, character data is any string of characters which does not contain the start-delimiter of any markup.

Het feit dat het hier om script-tags in een XHTML-document gaat zou irrelevant moeten zijn, omdat dit betrekking heeft op het "welformed" zijn van een XML-document. Dit is een voorwaarde voor "valid" zijn van een XML-document, dus de specifieke inhoud van de tags (die aan de hand van een DTD gecontroleerd worden) zou niet relevant moeten zijn. De W3C validator gaat hier inderdaad consequent mee om (<script> en <p> zijn uitwisselbaar, wat dat betreft).

De vraag is nu, in hoeverre de W3C Validator de (hun eigen!) XHTML standaard volgt. Ik gebruik meestal RXP om mijn XHTML documenten te controleren en dat kan inderdaad ook, aangezien RXP stricter lijkt te zijn dan de W3C Validator. Ik ging er echter vanuit dat het omgekeerde ook zou gelden: een document dat door de W3C Validator geaccepteerd wordt, zou ook door RXP (of een andere standards-complian RXP parser) geaccepteerd moeten worden. Het hele idee achter XHTML was nu juist, dacht ik, dat alle XML validators dezelfde documenten accepteerden en verwerpen. Dat lijkt op deze manier dus niet het geval! De vraag is nu: wat is nu correct? Is die losse < toegestaan of niet?

Ik kan me moeilijk voorstellen dat de W3C Validator zoiets simpels fout doet (het is tenslotte hun standaard) maar anderzijds kan ik me ook moeilijk voorstellen dat gangbare XML parsers dit fout doen. De enige mogelijke verklaring lijkt mij een verschil in XML en XHTML standaarden, maar dat vind ik ook vreemd. Hoe zit dat dus?!

Wat documentatie:
• De XHTML specificatie
• Commentaar bij de W3C Validator over script-tags
• De XML standaard

[ Voor 24% gewijzigd door Soultaker op 28-07-2003 00:49 ]

Acties:

zondag 27 juli 2003 22:20

Verwijderd schreef op 27 juli 2003 @ 21:00:
De fout die jij krijgt: je moet de inhoud in script tags 'escapen' met cdata sections. De parser moet dan dat gedeelte negeren.
http://www.w3schools.com/xml/xml_cdata.asp

Dat klopt (had ik de TS inmiddels ook gemailed

) maar er is ook de mogelijkheid om comment tags om de JavaScript code heen te zetten. Het vervelende is dat allebei niet ideaal is: comments zouden door een XML parser weggefiltered kunnen worden, maar die CDATA tag wordt niet door een SGML parser (wat de gangbare niet-XML compliant HTML browsers zijn) geïnterpreteert. Die komt dus in de Java code terecht, die dan onuitvoerbaar wordt.

Gebruik van de CDATA tag is dus in principe te prefereren, vanuit theorethisch oogpunt, maar dan verlies je de backward compatibility met SGML parsers, die je voor de rest wel goed kunt behouden (door op geschikte plekken whitespace te plaatsen). Ik zou zeggen dat het gebruik van comment tags op dit moment iets meer portable is, maar ik heb daar geen formele bewijzen voor.

Acties:

Verwijderd

Soultaker,

Er is een hack voor backward compatibility, hoewel niet aan te raden:
http://doxdesk.com/personal/posts/wd/20010911-cdata.html

Verder kan ik niets anders zeggen dan dat ik het ook vreemd vind dat dat voorbeeldje van jou mag volgens de w3c validator. Wie o wie heeft het antwoord?

zondag 27 juli 2003 23:23

Acties:

Verwijderd

Beide validators geven dezelfde warning, alleen bij de W3C validator is dit niet duidelijk genoeg. Of eigenlijk, W3C keurt het document toch eigenlijk goed.

In de XHTML recommendation wordt niet goed duidelijk gemaakt of het nu mag of niet. De XML recommendation is er wel duidelijk over. Het mag niet.

Ik vind dat validators een dikke vette error moeten genereren. Overigens zouden XHTML documenten altijd ook geldige XML documenten moeten zijn. Dit is niet zo. Bij een XML document is een XML declaration verplicht. Bij XHTML wordt het door de validator toegestaan om die weg te laten.

Ik vind beide zaken best onbegrijpelijk...

maandag 28 juli 2003 00:01

Acties:

maandag 28 juli 2003 00:07

Verwijderd schreef op 27 July 2003 @ 23:23:
In de XHTML recommendation wordt niet goed duidelijk gemaakt of het nu mag of niet. De XML recommendation is er wel duidelijk over. Het mag niet.

Ik dacht dat de XHTML specificatie gefundeerd was op de XML specificatie (aangevuld met de HTML4 standaard). Dat valt dus tegen.

Ik vind dat validators een dikke vette error moeten genereren. Overigens zouden XHTML documenten altijd ook geldige XML documenten moeten zijn. Dit is niet zo. Bij een XML document is een XML declaration verplicht. Bij XHTML wordt het door de validator toegestaan om die weg te laten.

Ik vind beide zaken best onbegrijpelijk...

Mja, vond ik dus ook. Wat is dan nog het nut van XHTML4? Dan kun je eigenlijk net zo goed HTML4 gebruiken, want als je je best doet is dat ook wel XML-compliant te krijgen. Je kunt er nu in ieder geval niet vanuit gaan dat je XHTML4 documenten met een XML tool kunt processen, omdat niet gegarandeerd wordt dat ze aan de XML standaard voldoen...

Acties:

maandag 28 juli 2003 00:54

Software Architect

Werkt hier

waarschijnlijk is xhtml1 bedoeld als een soort "eerste aanzet" tot een xml-versie van html?

Acties:

maandag 28 juli 2003 01:03

ACM schreef op 28 July 2003 @ 00:07:
waarschijnlijk is xhtml1 bedoeld als een soort "eerste aanzet" tot een xml-versie van html?

Dat kan ik uit de documentatie niet afleiden.

What is XHTML?
[..]

XHTML family document types are XML based, and ultimately are designed to work in conjunction with XML-based user agents.

[..]

XHTML 1.0 (this specification) is the first document type in the XHTML family. It is a reformulation of the three HTML 4 document types as applications of XML 1.0 [XML]. It is intended to be used as a language for content that is both XML-conforming and, if some simple guidelines are followed, operates in HTML 4 conforming user agents. Developers who migrate their content to XHTML 1.0 will realize the following benefits:

• XHTML documents are XML conforming. As such, they are readily viewed, edited, and validated with standard XML tools.

[..]

Dit suggereert dus dat geldige XHTML documenten ook geldige XML documenten zouden moeten zijn. Kan ik concluderen dat de W3C validator dus niet strict genoeg is en ongeldige documenten accepteert? Dat lijkt me namelijk wel een bug report waard...

Verwijderd schreef op 27 July 2003 @ 23:23:
Bij een XML document is een XML declaration verplicht. Bij XHTML wordt het door de validator toegestaan om die weg te laten.

Dat is wel te verklaren uit de Portability Guidelines waarin aangeraden wordt de XML declaration weg te laten om compatibiliteit met SGML parsers te behouden. Ook in de XML specificatie staat:

Prolog and Document Type Declaration

[Definition: XML documents should begin with an XML declaration which specifies the version of XML being used.]

[..]
EBNF:
1
prolog ::= XMLDecl? Misc* (doctypedecl Misc*)?

Het wordt dus aangeraden de XML declaratie toe te voegen ("should") maar het is niet verplicht ("must"). Een warning zou in zo'n geval misschien op z'n plaats zijn, maar het is dus correct dat een document zonder XML declaratie wordt geaccepteerd.

[ Voor 30% gewijzigd door Soultaker op 28-07-2003 01:09 ]

Acties:

maandag 28 juli 2003 01:11

The what goes where now?

Verwijderd schreef op 27 July 2003 @ 16:38:
Hoe moet ik er geldige xhtml van maken? ik heb < al proberen te vervangen met
code:
1
&lt;
maar als ik dat doe draait het menu niet meer.

Het elegantst lijkt mij om een externe .js file te includen, zoals workaround A in de door Martijn22 aangedragen link.

Soultaker schreef op 27 July 2003 @ 21:06:
Het feit dat het hier om script-tags in een XHTML-document gaat zou irrelevant moeten zijn, omdat dit betrekking heeft op het "welformed" zijn van een XML-document. Dit is een voorwaarde voor "valid" zijn van een XML-document, dus de specifieke inhoud van de tags (die aan de hand van een DTD gecontroleerd worden) zou niet relevant moeten zijn.

Inderdaad.

De vraag is nu, in hoeverre de W3C Validator de (hun eigen!) XHTML standaard volgt.

Blijkbaar niet ver genoeg. De gegeven voorbeelden zijn duidelijk in strijd met de XML standaard, en toch keurt de validator ze niet af.

aangezien RXP stricter lijkt te zijn dan de W3C Validator. Ik ging er echter vanuit dat het omgekeerde ook zou gelden: een document dat door de W3C Validator geaccepteerd wordt, zou ook door RXP (of een andere standards-complian RXP parser) geaccepteerd moeten worden.

Je spreekt jezelf tegen

Als RXP alles accepteerd dat de W3C validator ook accepteert, hoe kan de RXP validator dan ooit stricter zijn?

De vraag is nu: wat is nu correct? Is die losse < toegestaan of niet?

Nou nee, de XML definitie is daar dus vrij duidelijk over: het mag niet.

Ik kan me moeilijk voorstellen dat de W3C Validator zoiets simpels fout doet (het is tenslotte hun standaard)

Tsja, validators zijn ook niet heilig, al is dit idd behoorlijk slordig...

Verwijderd schreef op 27 July 2003 @ 23:23:
In de XHTML recommendation wordt niet goed duidelijk gemaakt of het nu mag of niet. De XML recommendation is er wel duidelijk over. Het mag niet.

Maar aangezien XHTML een reformulation van HTML 4.01 in XML is (eigen woorden van W3C), moeten XHTML documenten altijd geldige XML zijn.

Bij een XML document is een XML declaration verplicht. Bij XHTML wordt het door de validator toegestaan om die weg te laten.

Dat lijkt me dan wederom een tekortkoming in de validator

Soultaker schreef op 28 July 2003 @ 00:01:
Ik dacht dat de XHTML specificatie gefundeerd was op de XML specificatie (aangevuld met de HTML4 standaard). Dat valt dus tegen.
...
Je kunt er nu in ieder geval niet vanuit gaan dat je XHTML4 documenten met een XML tool kunt processen, omdat niet gegarandeerd wordt dat ze aan de XML standaard voldoen...

Zoals boven al gezegd: XHTML is gewoon XML (specifiek: XHTML meer dan een opmaak-taal, in een XML container).

Je kunt XHTML dus gewoon met een XML parser lezen, maar dan moet het wel valid XHTML zijn en niet iets dat XHTML beweert te zijn maar dat niet is. Brakke validators helpen in dit scenario niet echt helaas.

Acties:

crisp

Devver

Pixelated

even een zijstapje:

code:

1	if ((x <= x1) \|\| (x >= x2) \|\| (y >= y2)) { eval('document.all["subMenu'+sel+'"].style.visibility="hidden"') }

ik zie eval (bah) en ik zie document.all (bah); dat wil zeggen dat je 1) een oud script te pakken hebt en 2) dat dit (dus) niet in alternatieve browsers gaat werken zoals Mozilla, en 3) het gebruik van eval mij al verteld dat dit script ook niet zo best geprogrammeerd is...

ter verduidelijking: de meeste browsers ondersteunen tegenwoordig het DOM model, waardoor document.all eigenlijk alleen nog maar noodzakelijk is voor IE4 ondersteuning. Als je dan IE4 wilt ondersteunen, dan moet je eigenlijk ook NS4 ondersteunen daar deze browser tegenwoordig nog een groter marktaandeel heeft dan IE4.
Persoonlijk zou ik het DOM-only houden, en zou de bovenstaande code herschreven kunnen worden naar:

code:

1
2
3

if ((x <= x1) || (x >= x2) || (y >= y2))  {
  document.getElementById('subMenu'+sel).style.visibility='hidden';
}

[ Voor 41% gewijzigd door crisp op 28-07-2003 01:20 ]

Intentionally left blank

maandag 28 juli 2003 01:19

Acties:

maandag 28 juli 2003 09:45

deadinspace schreef op 28 July 2003 @ 01:03:
Het elegantst lijkt mij om een externe .js file te includen, zoals workaround A in de door Martijn22 aangedragen link.

Inderdaad, dat raadt de W3C zelf ook aan in de compatibility guidelines over Embedded Style Sheets and Scripts.

Je spreekt jezelf tegen

Als RXP alles accepteerd dat de W3C validator ook accepteert, hoe kan de RXP validator dan ooit stricter zijn?

Ja ja, ik bedoelde natuurlijk dat er documenten zijn die RXP niet accepteert, maar de W3C validator wel. Andersom gaat 't vermoedelijk inderdaad wel goed. Maar dat betekent dus dat de W3C Validator ongeschikt is om te verifiëren of een document aan de standaard voldoet.

Zoals boven al gezegd: XHTML is gewoon XML (specifiek: XHTML meer dan een opmaak-taal, in een XML container).

Je kunt XHTML dus gewoon met een XML parser lezen, maar dan moet het wel valid XHTML zijn en niet iets dat XHTML beweert te zijn maar dat niet is. Brakke validators helpen in dit scenario niet echt helaas.

Ok, dan is het dus het beste om mensen voortaan aan te raden om de tools van de Web Design Group (nooit van gehoord, trouwens) te gebruiken, want die doen het blijkbaar beter dan die van het W3C. Ik zal ze eens een mailtje sturen over die Validator. Misschien hebben ze een goede reden waarom het werkt zoals het werkt of kunnen ze 't anders aanpassen.

Acties:

Verwijderd

Topicstarter

crisp schreef op 28 July 2003 @ 01:11:
ik zie eval (bah) en ik zie document.all (bah); dat wil zeggen dat je 1) een oud script te pakken hebt en 2) dat dit (dus) niet in alternatieve browsers gaat werken zoals Mozilla, en 3) het gebruik van eval mij al verteld dat dit script ook niet zo best geprogrammeerd is...

Heb je nog suggesties voor een goed dropdown menu? Alles wat ik vind zijn
a) slechte scripts
b) grote scripts (qua filesize)
c) scripts die ik zelf niet kan ombouwen zodat de door de validator komen
d) een combinatie van bovenstaande

(nee, ik heb niet genoeg kennis om zelf wat te bouwen)

maandag 28 juli 2003 09:49

Acties:

mbravenboer

StB: Heb je nog suggesties voor een goed dropdown menu?

Het hangt er vanaf wat je goed noemt. Naar mijn maatstaven is dit de allerbeste:
http://www.jdrowell.com/2003/03/13/CSS2_Menus

Maar ja, als je menuutjes ook in browsers moeten werken die niet meer de moeite nemen om bij te blijven (lees: IE), is deze oplossing vast niet wat jij goed zou noemen.

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment

maandag 28 juli 2003 17:20

Acties:

maandag 28 juli 2003 20:59

The what goes where now?

Verwijderd schreef op 27 juli 2003 @ 23:23:
Overigens zouden XHTML documenten altijd ook geldige XML documenten moeten zijn. Dit is niet zo. Bij een XML document is een XML declaration verplicht. Bij XHTML wordt het door de validator toegestaan om die weg te laten.

Ik heb het even opgezocht, maar je zit ernaast; een XML declaration is niet verplicht. Ja, dat verraste mij ook een beetje

Zie http://www.w3.org/TR/REC-xml#NT-prolog :

code:

1
2
3

Prolog
[22]    prolog    ::=   XMLDecl? Misc* (doctypedecl Misc*)?
[23]    XMLDecl   ::=   '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>'

Let op het vraagteken achter "XMLDecl", wat aangeeft dat dat element optioneel is

Soultaker schreef op 28 July 2003 @ 01:19:
Ok, dan is het dus het beste om mensen voortaan aan te raden om de tools van de Web Design Group (nooit van gehoord, trouwens) te gebruiken, want die doen het blijkbaar beter dan die van het W3C.

Of beiden... Je source door twee validators gooien kan ook geen kwaad

Ik zal ze eens een mailtje sturen over die Validator. Misschien hebben ze een goede reden waarom het werkt zoals het werkt of kunnen ze 't anders aanpassen.

Da's sowieso geen slecht idee.

Acties:

maandag 28 juli 2003 23:34

deadinspace schreef op 28 juli 2003 @ 17:20:
Ik heb het even opgezocht, maar je zit ernaast; een XML declaration is niet verplicht. Ja, dat verraste mij ook een beetje

Dan had je de thread beter moeten volgen, want ik had dat al voor je uitgezocht.

Je source door twee validators gooien kan ook geen kwaad

Dat vind ik eigenlijk niet acceptabel. De XHTML standaard is juist zo duidelijk gedefinieerd dat alle validators dezelfde antwoorden zouden moeten geven. Het is dan een beetje onzin om maar weer de grootste gemene deler te gebruiken omdat een aantal validators niet goed geïmplementeerd zijn.

Overigens heb ik nog even met de W3C validator zitten spelen en wat blijkt: hij vind de fout wel, maar negeert 'm. Als het document om een andere reden malformed is, laat 'ie de fout namelijk wel zien, maar als het de enige fout is, dan accepteert 'ie het hele document zonder verdere opmerkingen.

Dit gedrag verschilt trouwens met het document type: bij XHTML 1.0 Strict is de fout wel kritiek, maar bij XHTML 1.0 Transitional (waar ik eerst mee testte) blijkbaar niet! Ik denk dat dat dus het enige verschil in de foutafhandeling is. Het lijkt er dus op dat dit verschil bewust gemaakt is. Ik kan er in de officiële documentatie echter niets over vinden.

Acties:

dinsdag 29 juli 2003 01:10

The what goes where now?

Soultaker schreef op 28 July 2003 @ 20:59:
Dan had je de thread beter moeten volgen, want ik had dat al voor je uitgezocht.

Hmmz, overheen gelezen

Dat vind ik eigenlijk niet acceptabel. De XHTML standaard is juist zo duidelijk gedefinieerd dat alle validators dezelfde antwoorden zouden moeten geven.

Je hebt wel gelijk met je statement, maar je geeft zelf de clue ook al weg: zouden moeten.

Parsers hebben net als alle andere software bugs, en dit is er één van.

Het is dan een beetje onzin om maar weer de grootste gemene deler te gebruiken omdat een aantal validators niet goed geïmplementeerd zijn.

Mwah, het is een bescherming tegen de bugs van één enkele parser. Als jouw code door tien verschillende, onafhankelijke validators heenkomt, dan is de kans dat jouw code daadwerkelijk goed is groter dan als je hem maar door één validator haalt.

Onzin zou ik het dus niet willen noemen. Teveel moeite? Misschien, maar geen onzin.

Overigens heb ik nog even met de W3C validator zitten spelen en wat blijkt: hij vind de fout wel, maar negeert 'm.

Nou zeg je wel iets over mij, maar zelf lees je de thread ook maar half

Zo schreef Cheatah:

Verwijderd schreef op 27 July 2003 @ 23:23:
Beide validators geven dezelfde warning, alleen bij de W3C validator is dit niet duidelijk genoeg. Of eigenlijk, W3C keurt het document toch eigenlijk goed.

En dat zie je ook meteen als je de URL naar de W3C validatie van StB's code volgt:

# Note: ...
# Line 35, column 8: character "<" is the first character of a delimiter but occurred as data
# Note: ...

Als het document om een andere reden malformed is, laat 'ie de fout namelijk wel zien, maar als het de enige fout is, dan accepteert 'ie het hele document zonder verdere opmerkingen.

Nee, hij maakt er dus wel een opmerking over

Dit gedrag verschilt trouwens met het document type: bij XHTML 1.0 Strict is de fout wel kritiek, maar bij XHTML 1.0 Transitional (waar ik eerst mee testte) blijkbaar niet! Ik denk dat dat dus het enige verschil in de foutafhandeling is. Het lijkt er dus op dat dit verschil bewust gemaakt is. Ik kan er in de officiële documentatie echter niets over vinden.

Hmm, dat lijkt me dan ook een bug (of eigenlijk dezelfde bug), aangezien XHTML 1.0 nog altijd XHTML 1.0 is. Het moet gewoon valid XML zijn, de gebruikte flavor (strict/transitional/frameset) heeft afaik alleen invloed op de toegestane elements.

[ Voor 4% gewijzigd door deadinspace op 28-07-2003 23:36 ]

Acties:

dinsdag 29 juli 2003 10:54

deadinspace schreef op 28 July 2003 @ 23:34:
Onzin zou ik het dus niet willen noemen. Teveel moeite? Misschien, maar geen onzin.

Laat ik het dan zo zeggen: ik weiger dat als oplossing te accepteren. Daar is XHTML niet voor ontworpen. Dan kan ik net zo goed op de oude manier te werk gaan: HTML code kloppen en dan checken in IE en NN of het er een beetje fatsoenlijk uitziet. (Dat moet nu toch nog steeds.)

Nou zeg je wel iets over mij, maar zelf lees je de thread ook maar half

Ik ben me er van bewust dat dat allemaal gezegd was.

Dat ontken ik toch ook niet?

Nee, hij maakt er dus wel een opmerking over

Nee, dat is niet waar. Als hij geen fatale fout vind, maakt de W3C Validator (waar ik het over had) geen opmerkingen over de niet-fatale fout ("<" in de tekst).

Hmm, dat lijkt me dan ook een bug (of eigenlijk dezelfde bug), aangezien XHTML 1.0 nog altijd XHTML 1.0 is. Het moet gewoon valid XML zijn, de gebruikte flavor (strict/transitional/frameset) heeft afaik alleen invloed op de toegestane elements.

Vreemd dat die bug dan wel in de Transitional maar niet in de Strict validator zit...

Acties:

Verwijderd

hmm... mag > wel? anders kun je x <= x1 natuurlijk omschrijven naar x1 >= x

dinsdag 29 juli 2003 12:38

Acties:

dinsdag 29 juli 2003 15:23

The what goes where now?

Soultaker schreef op 29 July 2003 @ 01:10:
Laat ik het dan zo zeggen: ik weiger dat als oplossing te accepteren. Daar is XHTML niet voor ontworpen.

Daar kan ik me iets bij voorstellen, maar dat is nog altijd de utopiaanse aanpak die ervanuit gaat dat er geen bugs in de software zitten bijvoorbeeld

Ik ben me er van bewust dat dat allemaal gezegd was. Dat ontken ik toch ook niet?

Da's flauw natuurlijk... Ik herhaalde iets, zonder te weten dat het al gezegd was. Jij herhaalt iets.

Om het over dezelfde boeg te gooien: ik heb toch ook nooit ontkend dat de informatie in mijn post al gezegd was?

Nee, dat is niet waar. Als hij geen fatale fout vind, maakt de W3C Validator (waar ik het over had) geen opmerkingen over de niet-fatale fout ("<" in de tekst).

Jawel, hij maakt er wel een opmerking over, zie het volgende plaatje:
Afbeeldingslocatie: http://gemini.luon.net/~marcelm/tmp/w3c-validator.png

Hij bestempelt het misschien niet als niet-fatale fout (dat heb ik ook nooit beweerd), maar hij maakt er wel een opmerking over.

Vreemd dat die bug dan wel in de Transitional maar niet in de Strict validator zit...

Misschien hebben ze de strict validator met opzet stricter gemaakt hierin, ook al strookt dat niet met de standaard. Niet direct een programmeer-bug, maar meer een denk-bug dus.

Acties:

dinsdag 29 juli 2003 15:49

deadinspace schreef op 29 juli 2003 @ 12:38:
Da's flauw natuurlijk... Ik herhaalde iets, zonder te weten dat het al gezegd was. Jij herhaalt iets.

Toen ik dat schreef dacht ik in alle eerlijkheid dat die hele melding nooit verscheen en dat de constatering dat dat wel gebeurde als er een andere (fatale) fout in het document zat, nieuw was. (Ik begreep Cheatah's opmerking toen ook niet goed.)

Maar, jij zegt terecht:

Jawel, hij maakt er wel een opmerking over, zie het volgende plaatje:
[afbeelding]
Hij bestempelt het misschien niet als niet-fatale fout (dat heb ik ook nooit beweerd), maar hij maakt er wel een opmerking over.

Ik had dus niet goed uit m'n doppen gekeken, want ik had daar elke keer mooi overheen gelezen. Die melding had ik niet bewust gezien. Mijn fout dus, sorry.

Misschien hebben ze de strict validator met opzet stricter gemaakt hierin, ook al strookt dat niet met de standaard. Niet direct een programmeer-bug, maar meer een denk-bug dus.

Mja, dat lijkt me ook.

Verwijderd schreef op 29 juli 2003 @ 10:54:
hmm... mag > wel? anders kun je x <= x1 natuurlijk omschrijven naar x1 >= x

Jahoor, dat mag wel.

Die truc gaat voor ampersands natuurlijk niet op (of je moet 'and' mogen gebruiken voor '&' en '&&'). Het beste is dan toch om met externe scripts te werken (ondanks de overhead), waar mogelijk.

[ Voor 16% gewijzigd door Soultaker op 29-07-2003 15:25 ]

Acties:

dinsdag 29 juli 2003 15:55

Software Architect

Werkt hier

Externe scripts hebben weer wel het nadeel dat ze minder handig on-the-fly op maat gegereneerd kunnen worden (wat ik nog wel eens wil doen/gedaan heb).
Magoed, ik ben dan ook nooit echt een superstrikte xhtml gebruiker geweest, meestal is het "wel enigszins xhtml" maar nooit zo extreem als zou moeten

Acties: