Als je iemand koffie geeft met die boodschap kan de ander nog wel uitvogelen dat het geen koffie is. Met MIME types en documenten zit dat toch wel ietsje complexer in elkaar, anders waren MIME types overbodig geweest.En ik ben van mening dat een XHTML document altijd XHTML blijft ook al serveer je met het verkeerde mime-type. Feit is dan wel dat je dom bezig bent omdat je de verkeerde mime-type gebruilkt. Je geeft iemand toch geen koffie met de boodschap "chocolademelk".
Verwijderd
Ik leg het nog een keer uit
stel jij hebt op jouw server een map /www. In die map zie je een bestandje 'pagina.wml' of 'pagina.xhtml'. Je opent het bestandje. Je ziet een xhtml doctype. Het bestand is valid xhtml.
Wat is dat bestandje op dat moment volgens jou? Volgens jou is het niets, volgens mij is het 'een xhtml bestand'.
Nu gaan we dat bestand serveren. Iemand vraagt onze webserver op dit bestandje, en aangezien die iemand IE gebruikt, serveren we het met mime-type 'text/html' - wij willen immers geen kansloze purist zijn van wie de website nog maar door 10% van de bezoekers te lezen is. Nu is deze persoon een nogal eigenaardig typje (zijn IE gebruikers meestal) en purist. Hij wil de pagina dus niet in IE bekijken, en surft louter met notepad. Zo kan hij precies zien wat er op die pagina staat. Nadat hij het bestand heeft opgehaald met IE, heeft hij op zijn locale filesystem een bestandje 'pagina.xml' of 'pagina.xhtml' staan. Als hij het opent met notepad, ziet hij een XHTML doctype en een valid XHTML inhoud.
Volgens jou is het nu een HTML bestand. Volgens mij is het nog steeds een XHTML bestand.
Er zijn mensen die beweren dat dit bestandje bij de overdracht vanaf server naar client, indien het mimetype text/html gebruikt wordt, kenmerken kwijt is geraakt. Dit is nonsense. Zodra diegene die het bestandje op die manier gedownload heeft, het op z'n eigen webserver zet, en serveert met het voor XHTML bedoelde mimetype, is alles ineens weer goed. Zouden er kenmerken verloren zijn gegaan bij de overdracht als html, dan zou dat inhouden dat deze 2e server kenmerken heeft toegevoegd. Dat dit niet zo is, zal iedereen beamen. Het bestandje bevatte dus nog steeds alle kenmerken.
Moraal: het is en blijft gedurende de hele overdracht gewoon een .xhtml. Waarom zien we het dan toch niet goed? Omdat de browser het leest als HTML, met een HTML parser. Waarom doet de browser dit? NIET omdat de webserver hem GEDWONGEN heeft dit te doen. Louter omdat de webserver hem vertelde dat het een .html was, en er lokaal de instelling is gemaakt dat .html met een .html parser geopend moet worden.
De browser leest dus het bestand verkeerd. Dat neemt niet weg dat het gewoon nog steeds een xhtml bestand is.
Toch maar weer een analogie er tegenaan gooien. Stel ik ben programmeur. Stel ik programmeer in Delphi. Stel ik heb een applicatie gemaakt, en wil die aan jou versturen. Nu was ik zo blij dat ik klaar was, dat ik mij een stuk in m'n kraag gezopen had, en abusievelijk tegen jou zeg dat ik de applicatie in c# geschreven heb. Ik verstuur dus een .pas aan jou met als mimetype c#.
Wat is het bestand nu als het eenmaal op jouw computer aangekomen is? Volgens jou is het dan een c# bestand. Volgens mij niet. Volgens je c# IDE ook niet. Volgens mij is het nog immer een .pas. Als ik mijn vergissing inzie, en jou vertel dat het geen c# bestand is, maar een delphi/pascal bestand en jij opent het met Delphi, werkt alles ineens weer.
Waarom? Omdat het bestand zelf tijdens de overdracht nooit gewijzigd is, het is nog steeds hetzelfde bestand, met dezelfde kenmerken. Als jij C# gebruikt om het te openen, open jij het verkeerd, maar is het nog steeds een pascal bestand.
Het is echt nonsense te beweren dat het bestand na overdracht ineens c# is (of HTML, om terug te keren naar de normale discussie).
De juiste uitspraak is:
XHTML verstuurd met mimetype text/html is nog steeds XHTML, echter het wordt gelezen als HTML.
[ Voor 5% gewijzigd door Verwijderd op 17-04-2005 16:31 ]
:strip_icc():strip_exif()/u/52966/DSC04760%2520-%2520ProfilePic2%252060x60.jpg?f=community)
Ik denk dat Anne het zo wel aardig heeft verwoord:
Doe jij dat dus ook? Of is de XML syntax de enige reden om XHTML te gebruiken?
Of je daar persé een standaard voor nodig hebt vind ik discutabel, maar ik moet je daar wel gelijk in geven als je bijvoorbeeld gebruik gaat maken van validatie tools.
Ik ga even uit van alle XHTML developers, en dan lijkt het mij toch voor hun meer moeite om de problemen die Ian Hickson aangeeft op te lossen. Geluk voor jou dat jij daar niet zo lang over doet.
Lees mijn opmerking nog eens, en je zult merken dat dit helemaal geen persoonlijke aanval is, zoals jij dit blijkbaar opvat. En even eerlijk: status is hierbij niet van belang.
Wat ik probeer te bereiken: dat XHTML ontwikkelaars onder ogen durven te zien dat ze malformed HTML over het net verspreiden (hierbij geld wel dat de XHTML dus als text/html wordt geserveerd). Bovendien vind ik het "als XHTML ontwikkelaar verbeter ik het web" labeltje dat wel vaker aan XHTML ontwikkelaars wordt gekoppeld dus niet altijd terecht... Dat ik hiermee mensen op de kast jaag is niet een reden om het te gaan ontkennen...
Klopt als een bus. Voor jou, de anderen en ik als mensen.
Maar blijkbaar snap je niet wat er met het browser perspectief wordt bedoeld. Dat is namelijk wat de parser leest, en uiteindelijk op het scherm toont. Wat jij op het scherm ziet met text/html ís HTML, en geen XHTML. Er gaat weldegelijk iets verloren bij text/html, niet in het bestand, maar wel in het geheugen van de browser en dus uiteindelijk ook op het scherm. De HTML parser zal namelijk alle XML functies negeren, en hiervan kun je dus ook geen gebruik maken in de browser.
Hierdoor kunnen er dus veranderingen ontstaan in de weergave, en deze fouten zie je ook terug in de visuele pagina. Wat jij dus dan visueel ziet is HTML, en géén XHTML. Dus wat ís het dan voor de browser?
Hopelijk snap je nu ook dat je nog steeds appels met peren aan het vergelijken bent. Op het menselijk perspectief heb jij gelijk, en op het browser perspectief ik. Het is dus maar net hoe je het bekijkt. Maar je moet deze twee niet door elkaar halen...
Maar ik zal me er maar bij neerleggen dat op code niveau XHTML verzonden als text/html wel XHTML is. Op visualisatie niveau is dit een ander verhaal, maar ik denk dat dit eigenlijk buiten deze discussie staat, omdat dit browser specifiek is.
:strip_icc():strip_exif()/u/43473/crop5e12eeae6a054_cropped.jpeg?f=community)
:strip_exif()/u/3333/pumpkin_avatar.gif?f=community){kind=avatar}
Op dat moment is het niets meer dan platte tekst.:
[...]
Ik leg het nog een keer uit
stel jij hebt op jouw server een map /www. In die map zie je een bestandje 'pagina.wml' of 'pagina.xhtml'. Je opent het bestandje. Je ziet een xhtml doctype. Het bestand is valid xhtml.
Wat is dat bestandje op dat moment volgens jou? Volgens jou is het niets, volgens mij is het 'een xhtml bestand'.
Volgens mij is het dan wederom platte tekst; een representatie van wat misschien wel eens XHTML zou kunnen zijn, maar aangezien we het niet in de juiste omgeving bestuderen weten we dat niet zeker.
En als ik nu eens besluit om het bijvoorbeeld met een XML-mimetype te gaan serveren, dan is het ineens XML geworden; goh wat raar nou
Als ik dubbelklik op een .php wat heb ik dan in mijn text-editor staan? Als ik diezelfde .php oproep in mijn browser, wat is het dan? De textuele representatie van iets maakt het nog niet wat je denkt dat het is; alleen wanneer je het bestudeert in de omgeving waarvoor het bedoelt is kan je met zekerheid uitspraken doen.
Een leeuw zal in een kooitje heel ander gedrag vertonen dan in het wild; aan de hand van de gedragingen in gevangenschap kan je nog geen uitspraken doen over leeuwen in het algemeen, daarvoor zal je op safari moeten gaan.
Intentionally left blank
/u/7685/ruinmytune-60x60.png?f=community)
Heren, wat is voor jullie het voordeel om XHTML code te gebruiken in pagina's?
En liever geen argument alszijnde: jah, want het is nieuwe techniek
En liever geen argument alszijnde: jah, want het is nieuwe techniek
Ace of Base vs Charli XCX - All That She Boom Claps (RMT) | Clean Bandit vs Galantis - I'd Rather Be You (RMT)
You've moved up on my notch-list. You have 1 notch
I have a black belt in Kung Flu.
Verwijderd
Dus als ik een zip bestand open in notepad, is het volgens jou platte tekst? Volgens mij is het dan nog immer een zip bestand.
Nee dan is het nog immer XHTML, echter wordt het gelezen als XMLEn als ik nu eens besluit om het bijvoorbeeld met een XML-mimetype te gaan serveren, dan is het ineens XML geworden; goh wat raar nou
1) het is een nieuwe techniek (:
Heren, wat is voor jullie het voordeel om XHTML code te gebruiken in pagina's?
En liever geen argument alszijnde: jah, want het is nieuwe techniek
)2) een eventuele latere overstap naar full-fledged XML wordt makkelijker gemaakt.
En wat is daar precies harmfull aan? Ziet de eindgebruiker de site niet goed? Werkt de site niet?
Ik durf rustig te zeggen dat zeker meer dan 50% van de 'gewone' HTML's al niet wellformed zijn.
En het is dus uiteindelijk geen malformet HTML, het is uiteindelijk nog steeds XHTML die echter als HTML gelezen wordt.
Als ik een niet frans sprekende rus een frans boek geeft, en 'm dat laat voorlezen, welke taal is dat boek dan in gesteld? Volgens mij nog steeds in het frans, en niet in het russisch.
Jullie verwarren hoe een bestand gelezen wordt met wat het bestand echt is. Hoe het gelezen wordt, bepaald NIET wat het is.
[ Voor 63% gewijzigd door Verwijderd op 17-04-2005 19:05 ]
:strip_icc():strip_exif()/u/90747/vogelklein.jpg?f=community)
Verwijderd
ik gebruik xhtml op de server en gooi daar een hele arsenaal aan xml tools overheen. In het geval van mijn stage verslag wordt de inhoud mbv xsl toegevoegd, ook de index werd zo gedaan. Verder zijn er via de dom afkortingen toegevoegd (had ook via een html dom gekund) en wordt de boel opgesplitst in losse hoofdstukken als daar om gevraagd wordt. Ook het versie beheer zal ik hiermee gaan bijhouden (ins en del met een datum in de class).:
Heren, wat is voor jullie het voordeel om XHTML code te gebruiken in pagina's?
En liever geen argument alszijnde: jah, want het is nieuwe techniek
Browsers die het ondersteunen krijgen xhtml, anders maak ik er voor ik het verzend nog ff html van (door wat replaces uit te voeren op oa. <br /> <img /> <hr /> <link /> en <img />)
verder gebruik ik ook nog mathml, maar dat wordt later dmv javascript in de dom ingevoerd (vertaald vanuit TeX, zodat voor non mathml browsers de TeX code leesbaar blijft). Die js is dus zo geschreven dat ie met zowel een html als xml dom om kan gaan, want IE met mathplayer krijgt html van mij
:strip_exif()/u/2087/osiris_ani.gif?f=community)
Ben ik de enige die vind dat die MIME-type-header en een doctype dubbelop is? Of snap ik 't nu niet?
Overigens vind ik XHTML gewoon fijner dan "normale" HTML, omdat het logischer is op bepaalde punten. Geen losse tags zoals <br>, maar alles afsluiten, al dan niet in dezelfde tag. 't Werkt gewoon logischer en voor de wat "autistischere" nerds is dat ongetwijfeld fijner. Enige feit is dat ik 't vaak verstuur als text/html is omdat er zo'n incompetente browser bestaat die 't correcte niet snapt en ik niet graag "terug" wil stappen op "onlogische" code.
Overigens is de pagina/site in mijn "Homepage"-link wel 100% valid, alleen hebben IE-users daar dus niets aan
Overigens vind ik XHTML gewoon fijner dan "normale" HTML, omdat het logischer is op bepaalde punten. Geen losse tags zoals <br>, maar alles afsluiten, al dan niet in dezelfde tag. 't Werkt gewoon logischer en voor de wat "autistischere" nerds is dat ongetwijfeld fijner. Enige feit is dat ik 't vaak verstuur als text/html is omdat er zo'n incompetente browser bestaat die 't correcte niet snapt en ik niet graag "terug" wil stappen op "onlogische" code.
Overigens is de pagina/site in mijn "Homepage"-link wel 100% valid, alleen hebben IE-users daar dus niets aan
[ Voor 88% gewijzigd door Osiris op 17-04-2005 19:17 ]
Verwijderd
da's natuurlijk geen argument (je was net beter bezig
) Maar ok, ik maak er 1 minuut van:PHP:
1
2
3
4
5
6
7
| function make_html($xml) { $xml = preg_replace('/<\?xml.*?>\s*/','',$xml); //remove prolog and whitespaces following it; $xml = preg_replace('/<!DOCTYPE.*?>\s*/','<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">'."\n",$xml); //replace DTD $xml = preg_replace('/<html.*?>/','<html lang="en">',$xml); //strip html tag $xml = preg_replace('/\/>/','>',$xml); return $xml; } |
ey niet gaan zeuren om de variabelenamen he
op welk punt moet ik dan $html gebruiken ipv $xml
[ Voor 18% gewijzigd door Verwijderd op 17-04-2005 19:34 ]
Verwijderd
Je verhaal toont helemaal niks aan. Als jij aan de browser duidelijk zou weten te maken dat text/gelulinderuimte bij de HTML parser hoort (hoe wou je dat eigenlijk gaan doen?), dan is vanaf dat moment text/gelulinderuimte gelijk aan text/html (ze worden immers gelijk behandeld).
Verder heb ik geen enkele "purist" in dit topic horen zeggen dat XHTML met een text/html mime-type verkeerd gerenderd wordt. Het is geen 100% valid XHTML, maar daar ben je een purist voor
Maar de reden dat het goed gerenderd wordt, is niet omdat de browser herkent dat het XHTML is, maar omdat de HTML parser van de meeste browsers redelijk fout-tolerant is. Dat is het hele punt, niet dat het niet zou werken, maar dat je een fout HTML-bestand stuurt (dat eruit ziet als een XHTML bestand), dat genoeg op een gewoon HTML-bestand lijkt. Daarom werkt het!offtopic:
Als je het nu nog niet begrijpt, ga ik RFC's quoten
Als je het nu nog niet begrijpt, ga ik RFC's quoten
:strip_exif()/u/50656/andre-scholten-avatar.gif?f=community){kind=avatar}
En hoe lang gaan we nog door met het herhalen van dezelfde punten? Elk punt is al een aantal keer genoemd alleen sommigen gaan toch weer opnieuw vanuit een andere hoek het punt benaderen. Zo langzamerhand hebben we alles wel gehoord.... 
[rml]crisp in "[ html/alg] XHTML als text/html, wat is h..."[/rml]
In sommige gevallen is meta-data wel degelijk belangrijk en het is ook gewoon onderdeel van de data. Soms heb je gewoon een label nodig om te kunnen zeggen wat iets is, en een computer heeft dat dan zeker nodig.
Maar nogmaals, en dat is volgens mij het hele punt van deze discussie en waar we volgens mij langs elkaar heenpraten (
), ik bezie XHTML als een techniek, en beoordeel het dan ook in z'n toegepaste vorm - dat is immers waar het uiteindelijk om gaat. Als jouw mooie XHTML document in toegepaste vorm enkel HTML-kenmerken heeft dan zeg ik dat het HTML is (dat wil niet zeggen dat het wel XHTML kan zijn, maar niet op dat moment).Als ik het volgende stukje PHP door een javascript engine heengooi is het op dat moment dan nog wel PHP?
code:
1
2
3
| $a = 10; $b = 20; $c = $a + $b; |
Intentionally left blank
Zolang we nog niet met modder naar elkaar gaan gooien zie ik daar geen bezwaar tegen:
En hoe lang gaan we nog door met het herhalen van dezelfde punten? Elk punt is al een aantal keer genoemd alleen sommigen gaan toch weer opnieuw vanuit een andere hoek het punt benaderen. Zo langzamerhand hebben we alles wel gehoord....
Daarbij is het zo dat juist door het meermalen belichten van de materie vanuit diverse standpunten je gaandeweg beter in staat bent om je eigen standpunt onder woorden te brengen; ik denk dat we wat dat betreft nu al meer bereiken dan in het begin toen we het nog over erwten en erwtensoep hadden
Als je zelf moe wordt van de discussie raad ik je aan gewoon even verder te klikken en de mensen die graag verder willen discuseren hun gang te laten gaan.
Overigens kan ik me hezik's standpunt toch ook wel een beetje voorstellen hoor (je moet je ook kunnen inleven in andermans standpunten wil je daar voor jezelf een oordeel over kunnen vellen), alleen vind ik mijn eigen benadering juister. Dat daar een verschil van mening over blijft kan en mag best, daar heb ik best vrede mee en dan wil ik o.a. hezik best bedanken voor het uiteenzetten van zijn standpunten en meningen. We zijn het dan misschien niet met elkaar eens, maar hebben wel beide op een andere manier over dingen nagedacht en ook nog eens wat discussie-vaardigheden opgedaan
Intentionally left blank
Correct. En het was júist de bedoeling om met XHTML dit tegen te gaan. Met een meer afdwingende standaard (immers, de XML parser zou zijn nek moeten breken over fouten).
Allemaal prachig, maar XHTML heeft wel een hele lelijke "feature" waardoor er nóg ranzigere dingen zijn toegestaan als júist malformed HTML over het net versprijden!
Iets deed daar bij mij een belletje rinkelen...Wat ik jammer vind, is dat XHTML zich conflicteert met de HTML standaard door zichzelf voor te doen als HTML maar dit niet helemaal goed doet, en dit gedag goedkeurt doordat het door de implementaties van de standaard toevallig geaccepteerd wordt... XHTML zou zich gewoon niet met de HTML standaard moeten bemoeien!
Het argument "maar het werkt toch?" vind ik niet bepaald mooi. Ik kan ook met een te brede auto op de weg gaan rijden, want het werkt toch? Iedereen vliegt de berm in voor mij! Totdat iemand het een keer niet doet...
Nee, jij wilt maar niet de twee perspectieven uit elkaar halen, en wakkert maar de hele tijd een onnodige discussie aan. Ik heb al een aantal keren aangegeven dat er twee perspectieven zijn. En dat jij in het ene wel gelijk hebt, maar het ander niet. En dat je appels met peren aan het vergelijken bent. Kun je daar dan nu echt a.u.b. een keer mee ophouden, want ik wordt er een beetje moe van...
En mocht je er dan niet mee eens zijn, probeer dat browser perspectief dan maar aan te vechten met goede argumenten, want tot dusver doe je dit helemaal niet, en maak je een probleem van iets wat helemaal niet bestaat.
Om nog maar eens een uitspraak te quoten:
Dat vind ik wel een gewaagde uitspraak, en wel een zeer zwak argument om de discussie maar af te wimpelen, want zo kun je elk meningsverschil wel oplossen.
Om iets te kunnen geloven zul je toch echt iets van iemand anders moeten aannemen...
Of dat nu van een bron is hier op het forum, of een website, zolang je de kwaliteit maar kan controleren...Sprookjes? Onwaarheden? Verklaar je nader...
Verwijderd
Een verkeerde vergelijking, immers er heeft niemand last van als ik aan IE een xhtml serveer als HTML. Mits ik er voor zorg dat die XHTML er in die representatie ook goed uitziet, is er NIEMAND die er last van heeft. Dat is heel iets anders dan 'iedereen vliegt de berm in voor mij'.
Heb je de topictitel wel eens goed bekeken? Zo nee, voor alle zekerheid:
die hele 'onnodige discussie' is dus het onderwerp van dit topic. Als je daar moe van wordt, moet je naar een ander topic gaan omzien imo, nofi.
Er zijn geen twee perspectieven. Er is er maar eentje. Een bestand is iets, of het is het niet.
We hebben het hier niet over het serveren van halve pagina's toch?
Dus.. als jij deze .php (bestandsnaam crisps.php):
code:
1
2
3
4
5
| <?php $a = 10; $b = 20; $c = $a + $b; ?> |
door een java parser heengooit, is het inderdaad nog steeds PHP
Maar goed, ik had me al een tijdje stilgehouden, en zal dat nu weer gaan doen.. de standpunten zijn inderdaad wel duidelijk, en we gaan het op sommige punten gewoon never nooit niet eens worden
[ Voor 24% gewijzigd door Verwijderd op 17-04-2005 23:13 ]
Natuurlijk zijn er wel twee perspectieven. Je bepaald aan de hand van bepaalde eigenschappen wat iets is. Dat kan de intentie van de auteur zijn, het mime-type, het doctype, de extentie, de syntax, of het XML eigenschappen heeft (zie posts van crisp en Anne) en nog een hele hoop zaken. Er is geen objectieve maatstaf voor. Net zoals we een mens onder de mensen scharen omdat die een bepaalde set eigenschappen heeft. Als jij alleen maar in staat bent om naar een bepaald deel van die eigenschappen te kijken, of alleen maar geïnterresseerd bent in een deel van die eigenschappen (mens / browser verschil), kan het voorkomen dat je iets ander benoemt dan een ander.
edit:
Als jij ((semi)nieuwe) argumenten aandraagt, en ik reageer daar op een ((semi)nieuwe) manier op, hoop ik toch wel dat je reageert, zeker nu deze discussie al zo lang bezig is, en nu toch in enige mate lijkt te vorderen. Iniedergeval zijn de standpunten nu weer wat verder uitgekristaliseert.:
Maar goed, ik had me al een tijdje stilgehouden, en zal dat nu weer gaan doen.. de standpunten zijn inderdaad wel duidelijk, en we gaan het op sommige punten gewoon never nooit niet eens worden
[ Voor 26% gewijzigd door JHS op 17-04-2005 23:18 ]
Verwijderd
Als je mijn reply hebt gelezen en het niet met me eens bent, dan vind ik dat je een enorme plaat voor je kop hebt. Wanneer je namelijk vanuit browser perspectief bekijkt, dan is het wel mall formed html. De browser verwacht html vanwege het content-type: text/html, maar krijgt dat niet. Dan zegt hij: eey, dit is mall formed html. huh? ow, ik kan er nog iets van maken. Doen we dat toch...
Ik vind het nogal vreemd dat je er vanuit gaat dat je deze vraag maar vanuit een richting kan benaderen, je kan een probleem altijd op minimaal twee manieren benaderen. Iets is kort, of iets is niet lang. Iets is hoog of iets is niet laag. etc. Voor de browser is de data die hij toegestuurd krijgt mall formed html aangezien hij HTML verwacht en het niet krijgt. Is dit zo moeilijk te bevatten?
[ Voor 25% gewijzigd door Verwijderd op 17-04-2005 23:27 ]
Verwijderd
De data is inderdaad nog XHTML... maar niet voor de browser... die ziet het als verkeerde HTML. en doctype vertelt volgens mij niet wat het document *is*. Maar dat weet Anne vast beter.
/me gooit er nog een voedsel analogie tegenaan
Als ik jou een boterham met pindakaas geef en zeg; alsjeblieft een boterham met jam. Dan vind jij het toch ook niet raar dat je vreemd opkijkt als je een hap neemt? Voordat jij die hap neemt heb jij gewoon een boterham met jam in je hand, je weet immers niet beter. Dat dat toevallig gelogen is en niet de waarheid is maakt niet uit. Jou waarheid is: ik heb een boterham met jam.
De browsers waarheid is dat hij verkeerde html voor zich heeft, omdat hij gewoon niet weet dat het stiekem xhtml is. Jij had ook kunnen kijken of die boterham toevallig niet iets anders bevatte, maar dat deed je niet. Kortom, voor jou is het nog steeds een boterham met jam, terwijl de waarheid is dat het een boterham met pindakaas is. Zelfde voor de browser.
[ Voor 40% gewijzigd door Verwijderd op 17-04-2005 23:36 ]
Het verplicht andere browserbouwers wel om dezelfde mate van error-correctie als IE gebruikt in te bouwen in hun eigen browsers. Als het om stricte interpretaties gaat is IE natuurlijk niet het juiste meetinstrument, maar helaas wel het meest gebruikte instrument. Dat niemand er last van heeft is dus puur omdat er rekening mee gehouden wordt in browserengines, maar dat maakt het nog niet 'goed' (maar dat is dan weer een puristisch standpunt
)Ik denk dat er wel degelijk 2 perspectieven zijn; bekeken vanuit hoe jij iets bedoelt hebt, en bekeken vanuit hoe het toegepast wordt. Je zegt zelf dat labels niet uitmaken, dus een doctype doet dat ook niet (dus heb ik die in mijn voorbeeld bewust weggelaten). Een mimetype is echter meer dan enkel een label; het zegt ook hoe er mee omgegaan moet worden, daar zijn gewoon afspraken over gemaakt. Een DTD zegt enkel iets over de syntax en de elementen en attributen die toegestaan zijn en in welke context - handig voor validatie, maar verder weinig tot geen toegepaste waarde.
Wie zegt dat ik dat bestand opgeslagen heb met een .php extensie? Laten we zeggen dat het bestand crisp.foo heet en ik helemaal niet hebt gezegd dat het PHP zou moeten zijn. Jij haalt het door een PHP parser en het werkt, dus jij zegt 'het is PHP'. Iemand anders haalt dat bestand door een javascript parser (valid java is het niet[...]
We hebben het hier niet over het serveren van halve pagina's toch?
Dus.. als jij deze .php (bestandsnaam crisps.php):
code:
door een java parser heengooit, is het inderdaad nog steeds PHP
) en dat werkt ook, dus die iemand zegt 'het is javascript'. Tsja, ze hebben beiden gelijk... had ik maar duidelijker moeten zijn, misschien door een mimetype mee te geven...Zolang je maar niet met modder gaat gooienMaar goed, ik had me al een tijdje stilgehouden, en zal dat nu weer gaan doen.. de standpunten zijn inderdaad wel duidelijk, en we gaan het op sommige punten gewoon never nooit niet eens worden
Ik merk wel bij mensen hier in deze discussie dat het soms wat persoonlijker wordt, probeer jezelf op dat vlak aub wat in te houden; het is nergens voor nodig en verzwakt je eigen argumenten.
Intentionally left blank
Jazeker, en het grote probleem van deze topictitel is dat er niet bij staat voor wie dit geldt! Ik ga er van uit dat dit voor de browser geldt, omdat "als text/html" een verwerkingsproces aangeeft. Het mens perspectief heeft eigenlijk geen MIME-type verwerkingsproces, een mens ziet namelijk alleen iets. Maar het browser perspectief wel, omdat deze een response van een webserver verwerkt. Tijdens dit verwerkingsproces gebeurt er iets met dit document, en daar gaat deze duscussie over.
Ik wordt er moe van dat jij niet wilt inzien dat er twee perspectieven zijn. Er is al een aantal keren aangegeven door diverse mensen dat dit dus wel zo is. Maar zolang we het hier niet over eens kunnen worden, vind ik het een onnodige discussie.
Dan interpreteer jij de titel dus anders dan ik...
wat schrijf ik nou, lees toch eens een keertje
daarnaast moet je niet iets verkondingen zonder dat je weet waar je het over hebt.
die doctype beschrijft wat voor document het is, anders was die doctype nogal overbodig
de DTD die in de doctype staat bescrijft hoe de file in elkaar zit, in theorie (dat is waar jullie het de hele tijd over hebben) zou de browser aan de hand van die DTD kunnen bepalen hoe de file behandeld moet worden, wat mag en wat niet mag etc. welke elementen er zijn en welke attributen ze (kunnen) hebben. Kortom het beschrijft dat het een XHTML file is (note: er staat zelfs XHTML in de doctype
)
Verwijderd
Wat fijn dat jij wel de waarheid in pacht hebt en dat jij zomaar kan zeggen dat ik iets verkondig zonder te weten waar ik het over heb. Dank je... Ik zal mijn mond wel houden. Jongens, waarom discussieren we nog? Erkens heeft gelijk... \o/:
[...]
wat schrijf ik nou, lees toch eens een keertje
daarnaast moet je niet iets verkondingen zonder dat je weet waar je het over hebt.
die doctype beschrijft wat voor document het is, anders was die doctype nogal overbodig
de DTD die in de doctype staat bescrijft hoe de file in elkaar zit, in theorie (dat is waar jullie het de hele tijd over hebben) zou de browser aan de hand van die DTD kunnen bepalen hoe de file behandeld moet worden, wat mag en wat niet mag etc. welke elementen er zijn en welke attributen ze (kunnen) hebben. Kortom het beschrijft dat het een XHTML file is (note: er staat zelfs XHTML in de doctype
Een doctype is niet bedoelt om te beschrijven wat het is. Het is een verwerkings instructie voor de SGML parser. Deze is bedoelt om het document te controleren op geldigheid. Net als een XML Schema (XSD) dat doet. Dat je het toevallig kunt gebruiken om te controleren wat het is, maakt nog niet dat het hiervoor gemaakt is.:
[...]
die doctype beschrijft wat voor document het is, anders was die doctype nogal overbodig
Het is namelijk toegestaan om een DTD uit een HTML document te laten...
maar het uitendelijke doel is hetzelfde, je krijgt je uitkomst van je som.:
Wie zegt dat ik dat bestand opgeslagen heb met een .php extensie? Laten we zeggen dat het bestand crisp.foo heet en ik helemaal niet hebt gezegd dat het PHP zou moeten zijn. Jij haalt het door een PHP parser en het werkt, dus jij zegt 'het is PHP'. Iemand anders haalt dat bestand door een javascript parser (valid java is het niet
overigens, als het PHP was geweest dan had je je file begonnen met <?php waarover een javascript parser als het goed is moet struikelen, hetzelfde geld natuurlijk ook andersom.
als we dit terugkoppelen naar het XHTML verhaal, stel een browser krijgt XHTML als text/html en die denkt serieus dat het HTML4 is.
Dan zijn er een paar verschillen (http://www.w3.org/TR/xhtml1/#diffs)
"Documents must be well-formed"
in HTML4 moet je document ook well-formed zijn, ook al maakt het sommige browsers niks uit, maw een browser zal hier geen probleem mee hebben.
"Element and attribute names must be in lower case"
ook hierover zal een browser niet struikelen.
"For non-empty elements, end tags are required"
zal niks uitmaken, een browser zou hier juist blij mee moeten zijn, duidelijkheid waar iets begint en eindigd.
"Attribute values must always be quoted"
juist extra handig, maakt de browser dus ook niks uit, moet hij mee overweg kunnen.
"Attribute Minimization"
ook hier zal een browser geen last van hebben
"Empty Elements"
dit is wellicht een puntje, maar de huidige browsers (die ik ken) maken hiervan geen probleem (standaard doe ik altijd al een spatie voor de sluit slash, bij XHTML maakt dat niet uit)
etc etc
het gaat om het resultaat
terug op de titel van dit topic: het is nogsteeds XHTML, echter als de browser neit weet wat XHTML is, dan zal hij het gewoon als HTML4 _kunnen_ behandelen
Verwijderd
Een DOCTYPE is slechts bedoelt om tussen versies te kiezen, nadat al is vastgesteld om wat voor document het gaat. Bij text/html, verwacht de browser een HTML document. Vervolgens bepaalt de DOCTYPE slechts nog om welke versie van HTML het gaat. Het zou natuurlijk kul zijn om aan de hand van de content te bepalen om wat voor content het gaat. In dat geval zou een content-type meesturen helemaal niet nodig zijn.:
[...]
wat schrijf ik nou, lees toch eens een keertje
daarnaast moet je niet iets verkondingen zonder dat je weet waar je het over hebt.
die doctype beschrijft wat voor document het is, anders was die doctype nogal overbodig
de DTD die in de doctype staat bescrijft hoe de file in elkaar zit, in theorie (dat is waar jullie het de hele tijd over hebben) zou de browser aan de hand van die DTD kunnen bepalen hoe de file behandeld moet worden, wat mag en wat niet mag etc. welke elementen er zijn en welke attributen ze (kunnen) hebben. Kortom het beschrijft dat het een XHTML file is (note: er staat zelfs XHTML in de doctype
Nee, een DTD beschrijft waar de syntax van een document aan moet voldoen, en biedt browsers de mogelijkheid aan de hand van de URI in de DTD om de preciese specificaties daarvan te downloaden en het document daaraan te toetsen. Dat is echter niet verplicht en de meestgebruikte browsers doen dat ook niet. Het zegt verder helemaal niets over hoe het document behandeld dient te worden (XHTML mag immers als HTML behandeld worden, punt is dat het op dat moment praktisch gezien ook gewoon HTML is).:
[...]
wat schrijf ik nou, lees toch eens een keertje
daarnaast moet je niet iets verkondingen zonder dat je weet waar je het over hebt.
die doctype beschrijft wat voor document het is, anders was die doctype nogal overbodig
de DTD die in de doctype staat bescrijft hoe de file in elkaar zit, in theorie (dat is waar jullie het de hele tijd over hebben) zou de browser aan de hand van die DTD kunnen bepalen hoe de file behandeld moet worden, wat mag en wat niet mag etc. welke elementen er zijn en welke attributen ze (kunnen) hebben. Kortom het beschrijft dat het een XHTML file is (note: er staat zelfs XHTML in de doctype
Ik was vorig jaar op safari met Ian Hickson (niet te verwarren met de browser safari aangezien Ian voor Opera werkt, maar ik heb niet zoveel met dikke zingende dames
) en daar hebben we leeuwen bestudeerd in hun natuurlijke omgeving. Ian zei toen tegen mij: 'kijk, dat is nou XHTML'.Nu was ik vorige week in Artis met hezik, en die wees mij toen op een leeuw in een kooi, en zei toen ook tegen mij: 'kijk, dat is nou XHTML'. Ik antwoorde toen: 'Nou, het lijkt meer op onze huiskat' (die overigens Bonk heet).
XHTML is dus meer dan alleen hoe het eruit ziet in textuele representatie. Meer dan enkel een XML-like syntax sausje en een hippe DTD. Ik kijk naar alle eigenschappen van XHTML in een XHTML omgeving en beoordeel dan of het echt XHTML is. Als de toegepaste vorm echter alle eigenschappen van HTML heeft, en de specifieke eigenschappen van XHTML mist dan zeg ik dat het gewoon HTML is.
Natuurlijk kan je XHTML toepassen zonder specifieke XHTML eigenschappen te gebruiken. In dat geval is het ook nog eens volledig identiek aan HTML, of kan het in ieder geval doorgaan daarvoor (dankzij error-correction etcetera), en is enkel de DTD nog maar een leidraad, maar die doet dus niet terzake
Eenmaal toegepast blijft het HTML, en je kan me wel blijven wijsmaken dat de leeuw in het kooitje een wild dier is, ik merk er echter weinig van...
Intentionally left blank
Hmm, ik kan inderdaad niet vinden dat het optioneel is. HEAD en BODY elementen tags zijn wel optioneel. Zonder DTD is een document dus malformed HTML, maar wordt wel door de browsers geaccepteerd. Ik had het dus bij het foute eind, mijn excuses.
[ Voor 2% gewijzigd door bgever op 18-04-2005 00:21 . Reden: haal tags en elementen nog steeds door elkaar... ]
Verwijderd
elementen niet, alleen de tags de elementen zal je wel in de dom terug vinden (zelfde geldt voor tbody bv)
de elementen zal je wel in de dom terug vinden (zelfde geldt voor tbody bv)moet dus gewoon
[ Voor 41% gewijzigd door Verwijderd op 18-04-2005 00:20 ]
waar lees jij dat ik dat niet erken?
slecht voorbeeld, het maakt niet uit hoe het is gemaakt, maar dat het die eigenschappen heeft.
en dat is ook precies wat ik probeer te vertellen
Geen idee, maar zo kwam het zeker op me over
.Natuurlijk maakt het wel uit. Op chemisch niveau heeft gelatine toch echt andere eigenschappen
. Bovendien vind hezik dat het wel uitmaakt: "het is gemaakt als gelatine, dus is het gelatine". Ok, wat betreft dat laatste had ik misschien wel een beter voorbeeld kunnen kiezen, maar ik kom niet zo snel op iets anders...Mooien dat is ook precies wat ik probeer te vertellen
. Zo kwam het echter eerlijkgezegd niet op me over .
[ Voor 23% gewijzigd door JHS op 18-04-2005 08:48 ]
Verwijderd
Een DOCTYPE is een overblijfsel uit de SGML wereld en heeft een aantal voordelen. In text/html documenten kun je er "quirks mode", "almost standards mode" en "standards mode" mee triggeren in browsers. In XML documenten kun je met sommige XHTML doctypes bepaalde entities gebruiken in browsers omdat browsers interne mappers hebben voor bepaalde doctypes.die doctype beschrijft wat voor document het is, anders was die doctype nogal overbodig
http://lxr.mozilla.org/se...src/nsExpatDriver.cpp#205
Doctypes dienen verder geen enkel nut aangezien browsers geen "validating parsers" hebben zoals dat in de SGML tijd nog bestond.
Merk ook op dat in XML het niet uitmaakt of je <b><h2>foo</h2></b> doet. De DOM blijft er zo uitzien en je krijgt geen raar HTML DOM waar <b> wellicht in de H2 beland ofzo.
Verwijderd
Als er al zoiets bestond als malformed HTML zou het nog best "formed HTML" kunnen zijn. Alleen niet valid. Daarnaast is een document zonder DOCTYPE onbetrouwbaar in text/html met de huidige browsers.Hmm, ik kan inderdaad niet vinden dat het optioneel is. HEAD en BODY elementen tags zijn wel optioneel. Zonder DTD is een document dus malformed HTML, maar wordt wel door de browsers geaccepteerd. Ik had het dus bij het foute eind, mijn excuses.
:strip_exif()/u/7759/red_cat.gif?f=community)
De standaard vereist dat er boven een HTML document een HTML DTD moet staan. Immers in de standaard staat:
Zonder HTML DTD is het verloop dus geen geldige HTML volgens de standaard, want om als HTML document betiteld te worden moet je een DTD hebben.
Gezien de browsers het wel slikken, kun je zeggen dat ze "malformed HTML" accepteren... Malformed zegt namelijk niet enkel dat de elementen slecht geformuleerd zijn het zegt gewoon dat het "slecht geformuleerd" is.
Hier weer de vraag, wát is er slecht geformuleerd? HTML, dus de tekst volgens de HTML standaard...
[ Voor 13% gewijzigd door bgever op 18-04-2005 12:34 ]
dus als ik een zip file ter download aanbied met als content-type application/octet-stream, dan kan jij er niks mee want het is gewoon een grote bende met bytes
Verwijderd
De browser kan er niks mee, want in die context is het inderdaad een zooi bytes. Je krijgt dus een download-schermpje. Als het op je harde schijf staat kan je er waarschijnlijk wel wat mee, want een OS gebruikt over het algemeen geen mime-types, maar een ander mechanisme om de inhoud te bepalen:
[...]
dus als ik een zip file ter download aanbied met als content-type application/octet-stream, dan kan jij er niks mee want het is gewoon een grote bende met bytes
precies, en dan komen we terug bij dit topic, ik download een XHTML file welke met text/html wordt verstuurd, jij saved hem op je HD, de file blijft gewoon XHTML:
[...]
De browser kan er niks mee, want in die context is het inderdaad een zooi bytes. Je krijgt dus een download-schermpje. Als het op je harde schijf staat kan je er waarschijnlijk wel wat mee, want een OS gebruikt over het algemeen geen mime-types, maar een ander mechanisme om de inhoud te bepalen
De wereld is ook niet klaar voor je peren... Ik zou het toch wel een vervelende bijsmaak vinden als ik appelflappen krijg met peren er in!
Dat XHTML als text/html wordt geserveerd is niet goed te praten. Dat het toevallig wel werkt, is een ander verhaal...
Peren horen peren te zijn, en appels horen appels te zijn en te blijven. En anders ben je eigenlijk gewoon niet goed bezig...
voor de laatste keer, voor compatibility met oudere browsers mag je gewoon text/html gebruiken, het doet geen afbreuk op het feit dat het XHTML is. Uiteraard dien je er wel van op de hoogte te zijn dat niet elke browser het dan ook als XML gaat parsen, maar dat is het "risico":
Dat XHTML als text/html wordt geserveerd is niet goed te praten. Dat het toevallig wel werkt, is een ander verhaal...
overigens zijn al die vergelijkingen met voedsel gewoon bullshit en kan je gewoon niet op het XHTML verhaal toepassen.
:strip_icc():strip_exif()/u/64489/hoogtevorst.jpg?f=community)
Na het lezen van deze discussie irriteer ik me aan 2 dingen:
[...]
precies, en dan komen we terug bij dit topic, ik download een XHTML file welke met text/html wordt verstuurd, jij saved hem op je HD, de file blijft gewoon XHTML
• Jouw eeuwige
smilie;• Het feit dat deze discussie allang afgelopen is, maar van voren...en naar achteren herhaalt wordt.
PV 4915wp op oost, 2680 wp op west, 1900 wp op zuid. pvoutput - AUX 8 kW bi bloc
Zolang je er geen Content-Disposition veld bij levert met een .zip extensie zal het inderdaad enkel gedownload en gesaved worden met de filename waaronder de browser hem opgevraagd heeft, heb je helemaal gelijk in:
[...]
dus als ik een zip file ter download aanbied met als content-type application/octet-stream, dan kan jij er niks mee want het is gewoon een grote bende met bytes
Nee geen enkele browser zal 'm als XML parsen, tis namelijk text/html en gaat dus de tagsoupprocessor in, dat was geloof ik het hele punt:
[...]
voor de laatste keer, voor compatibility met oudere browsers mag je gewoon text/html gebruiken, het doet geen afbreuk op het feit dat het XHTML is. Uiteraard dien je er wel van op de hoogte te zijn dat niet elke browser het dan ook als XML gaat parsen, maar dat is het "risico"
als ik een smilie wil gebruiken dan doe ik dat:
[...]
Na het lezen van deze discussie irriteer ik me aan 2 dingen
• Jouw eeuwige
• Het feit dat deze discussie allang afgelopen is, maar van voren...en naar achteren herhaalt wordt.
of had je liever 
gezien deze discussie is volgens mij nooit afgelopen, er zijn gewoon 2 fronten, en ja ik irriteer me ook aan het feit dat steeds die appels en peren terug komen, maar dat is niet mijn schuld
dat die browsers dat niet kunnen is hun probleem, niet die van mij, ik hou daar gewoon rekening mee, want volgens mij iedereen (moet) doen die bezig houdt met (X)HTML, rekening houden met de diversiteit aan browsers.:
Nee geen enkele browser zal 'm als XML parsen, tis namelijk text/html en gaat dus de tagsoupprocessor in, dat was geloof ik het hele punt
Maar het punt was juist dat een XHTML file niet meer XHTML zou zijn als je een ander content-type mee geeft. Beetje hetzelfde als die zip file. Als ik die XHTML file ter download aanbied met application/octet-stream en ik geef aan dat het een .xhtml (is dat de extensie? ik gebruik die doorgaands nooit ivm serverside scripts, hmm, zoek ik even op, maar even als voorbeeld
) is dan blijft het gewoon XHTML.
Verwijderd
Hij *mag* zelfs niet de XML parser ingaan volgens de standaard. Degene die text/html er doorheen heeft gedrukt is imho een imbiciel. text/html had nooit in de specs opgenomen moeten worden. Dat geeft inderdaad wat mierenneuk voedsel voor een aantal mensen.:
[...]
Nee geen enkele browser zal 'm als XML parsen, tis namelijk text/html en gaat dus de tagsoupprocessor in, dat was geloof ik het hele punt
Is het voor niets dat de opvolgers van XHTML 1.0 op dit besluit zijn terug gekomen?
PV 4915wp op oost, 2680 wp op west, 1900 wp op zuid. pvoutput - AUX 8 kW bi bloc
Het zal wel aan mij liggen, dat ik het gewoon niet logisch vind dat XHTML als text/html verstuurd mag worden, maar ik heb het dan maar ff voor de duidelijkheid opgezocht zodat we er eens en voor altijd uit zijn.:
[...]
voor de laatste keer, voor compatibility met oudere browsers mag je gewoon text/html gebruiken, het doet geen afbreuk op het feit dat het XHTML is. Uiteraard dien je er wel van op de hoogte te zijn dat niet elke browser het dan ook als XML gaat parsen, maar dat is het "risico"
RFC: The 'text/html' Media Type
Hierin staat overigens ook een interessant stukje over herkenning van XHTML/HTML...
Weer wat geleerd.
Maar ik blijf achter mijn standpunt staan dat het eigenlijk niet zo mooi is dat XHTML als text/html verstuurd mag worden. Maar dat is mijn mening waar niemand zich druk over hoeft te maken. 
Verwijderd
oikoyama, tuuluuk telt jou mening. Ik wil er wel naar luisteren hoor, ook al heb je geen 10k posts
Ik ben het zelfs met je eens. Ja het staat in de standaard. Maar iedereen kan op z'n vingers natellen dat het een ridicule beslissing was.
Ik ben het zelfs met je eens. Ja het staat in de standaard. Maar iedereen kan op z'n vingers natellen dat het een ridicule beslissing was.