[XML] Oudere browsers

[jsiegmund]

Hoe werken jullie met oudere browsers in combi met XML? Ik heb een site gemaakt voor iemand die met XML/XSL werkt, en was daar wel tevreden over. Nu had ik netjes getest op Mozilla, IE en NS, en leek het allemaal prima te werken. Blijkt dat het op MACs onder Safari niet ok werkt, en onder Win95 pc's ook niet. Ik neem aan dat dat aan de parser ligt die die browsers hebben. Een oplossing is natuurlijk om bijvoorbeeld PHP te laten parsen, dan is het probleem al aardig opgelost.

Hoe lossen jullie zoiets op? Je kunt natuurlijk ipv

code:

IE6 

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> 
<xsl:output method="html"/> 
<xsl:template match="/">

ook dit gebruiken:

code:

IE5 

<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"> 
<xsl:template>

om ook oudere browsers een kans te gunnen, maarja; dan raak je wel weer een hoop mogelijkheden kwijt. Parsen jullie altijd serverside, of zijn er nog andere oplossingen?

[curry684]

Als het om de verschillen tussen browsers gaat heb je een clientside probleem, en dan hoort het dus in Webdesign & Graphics

[Verwijderd]

XSLT doe je server side. XML heeft client side geen voordelen boven XHTML: uitleg. En XHTML heeft geen voordelen boven HTML (voornamelijk omdat Internet Explorer het niet ondersteund).

[jsiegmund]

Waarom kun je dan je XSL file als een stylesheet includen in je XML?? Die opbouw werkt precies hetzelfde als wanneer je bijvoorbeeld een CSS include, en het parsen daarvan laat je ook gewoon door de browser afhandelen.
Waarom het een wel, en het ander dan weer niet?

[Verwijderd]

Omdat je XML ook server side kunt laten parsen? Dan werkt het nog steeds hetzelfde hoor... En heb je het over XSLT of over XSL-FO? De laatste wordt sowieso niet ondersteund door browsers en met de eerste kun je geen eens een pagina stijlen, alleen van de ene markup taal in de andere transformeren.

Maar desondanks heeft het gewoon geen zin. Google kan je niet geparste XML wel lezen, maar daar haalt het geen semantiek uit, omdat het de waarde van bijvoorbeeld het HEADER element niet kent, van het H1 element daarentegen kent het donders goed de waarde en indexeert deze ook daarnaar.

Lees ook: Never send content in proprietary formats over the wire.

[jsiegmund]

Heb het over XSLT, XSL-FO ken ik niet.

Ik zie wel in dat het misschien handiger is HTML te sturen, ware het niet dat webservers dit vaak weer niet kunnen. Site staat geparkeerd op ruimte waar PHP het begrip XSL nog nooit gehoord heeft. Dus dan wordt het mailen met de beheerder met de vriendelijke vraag dat er toch maar op te gooien.
Zie trouwens net dat het parsen met PHP ook maar te wensen over laat... krijg in ieder geval een heel ander resultaat dan de parsers van IE / Mozilla, ook niet echt handig dus. Wat word dan server-side als dé manier beschouwd om je XML/XSL om te gooien naar een (w3 valide) XHTML pagina?

[Verwijderd]

XSLT kan erg handig zijn om door middel van XPath informatie snel uit een XML bestand te halen en te sorteren, maar dan wordt denk ik eerder Java of C of iets dergelijks gebruikt in plaats van PHP. (Daar heb ik in ieder geval meer over gelezen.) En dat uiteraard in combinatie met een op de server geinstalleerde parser.

Maar weet je zeker dat XML wel een voordeel is? Of gebruik je het omdat je er leuke dingen over hebt gehoord?

[Skinkie]

makkelijkst is eerst te checken of de client het ondersteund, zonee door sablotron/libxml2 heen anders een redirect naar de XML pagina.

[flashin]

In PHP5 werkt het wel gewoon goed hoor, en als je geen speciale lib tot je beschikking hebt kun je ook altijd voor dit kiezen:
http://www.anter.com.ua/myXML/

[Verwijderd]

Ik zie het 'makkelijke' gedeelte niet helemaal. Het vereist een extra check, welke hoogstwaarschijnlijk aan de kant van de server gebeuren moet. Checks zijn altijd onzeker.

Redirects zijn vervelend. Zeker als je ze op deze manier gebruikt worden. Stel je redirect iemand door naar '/xml/' niet echt een URI die een prijs zou winnen, maar het is dan sowieso al een suboptimale oplossing. Iemand kopieert de link en geeft hem via e-mail door aan iemand anders. Die eigenlijk beter '/' had kunnen krijgen, omdat zijn browser, Opera, geen XSLT ondersteund.

[Johnny]

Opera, Safari en Konquerer ondersteunen het helemaal niet, MSIE 5.5 heel erg slecht.

De enige plaats waar ik het clients-ide gebruik is de webspace van m'n school waar geen server-side scripting beschikbaar is, maar ik toch wilde patsen met mijn 1337 web-development vaardigheden.

Speciaal daarvoor heb ik ook een client-side XMLcheck geschreven in JavaScript die kan detecteren of een browser client-side XML transformaties ondersteunt.

[jsiegmund]

En dan nog blijft de vraag; hoe parse je dan serverside? Alle servers waar mijn pagina's draaien zitten nog op PHP4.3.x en ik merk toch dat die implementatie erg te wensen overlaat.

[Verwijderd]

Had je mijn vraag ook nog gelezen? Die over de relevantie van XML?

Als de implementatie op je server te wensen over laat. Je geen toegang hebt tot een parser of betere script/programmeer talen, waarom zou je je er dan nog mee bezig houden op dit moment?

[jsiegmund]

Ik heb al een mailtje gestuurd of ze misschien kunnen upgraden naar PHP5 met DOM XML, dus dat horen we dan vanzelf.
De rede dat ik in eerste instantie voor XML heb gekozen is het sublieme scheiden van data en opmaak, zodat ik geen problemen krijg met mensen die de site onderhouden. Die mogen aan het opmaak gedeelte niet komen, en werken dus alleen de content filetjes zo af en toe bij. Ik heb ze netjes aangeleerd om elke keer even een validiteits-check te doen, dus dan kan het nooit fout gaan; superhandig dat XML
Ik ben nog redelijk nieuw in dit domein, maar weet wel wat ik handig vind en wat niet. En XML/XSL is handig; dus wil ik het graag gebruiken, en ook nog op een zo correct mogelijke manier. Ben alleen even aan het rondneuzen hoe anderen dat doen. Vond het wel handig dat je serverside niet veel meer hoeft te doen, nu blijkt dat serverside parsen toch een betere optie is; dus ga ik even kijken hoe ik dat het beste voor elkaar krijg. Niet met PHP4.3.x blijkbaar, dus eens kijken hoe happig ze zijn op een upgrade.

Even een kleine offtopic vraag; met wat voor een doctype kun je een XSL valideren? Ga morgen proberen een fatsoenlijk XML Schema te bouwen, maar hoe doe je dat voor je XSL stylesheet? Wil graag "This page is valid" zien in W3, zodat ik in ieder geval weet dat ik geen fouten gemaakt heb, dus dat evt. onvolkomenheden ergens anders aan liggen.

[ Voor 15% gewijzigd door jsiegmund op 09-08-2004 21:26 ]

[flashin]

Heb je ook uberhaupt mijn reactie gelezen?

Ik denk overigens niet dat je hoster zo even naar php 5 wilt upgraden, dit duurt bij de meeste providers toch nog wel even een paar versies eer dit gebeurt.

ot vraagje:
Je hebt gewoon progs die dat voor je kunnen checkken geloof ik.
/me zoekt

[ Voor 41% gewijzigd door flashin op 09-08-2004 21:36 ]

[Verwijderd]

Uiteraard kun je XSLT beter serverside transformeren, daar je ook de results ervan kunt cachen, maar ook clientside heb ik er toch redelijk grappige zaken mee kunnen doen, zoals een treeview bouwen

[jsiegmund]

flashin schreef op 09 augustus 2004 @ 21:35:
Heb je ook uberhaupt mijn reactie gelezen?

Ik denk overigens niet dat je hoster zo even naar php 5 wilt upgraden, dit duurt bij de meeste providers toch nog wel even een paar versies eer dit gebeurt.

ot vraagje:
Je hebt gewoon progs die dat voor je kunnen checkken geloof ik.
/me zoekt

Uiteraard, maar hoe minder niet-standaard dingen, hoe beter. Heb qua hosts wel goed verschil gemerkt, over het algemeen zijn de dure altijd erg up-to-date, of gewillig om te upgraden, en de budget versies maakt het niet zoveel uit ofzo... Opzich logisch, maar jammer.. ach ik betaal er niet voor; heb m'n eigen server waarop ik kan draaien wat ik wil, maar die is slechts voor test-doeleinden hier.

[w3news]

Verwijderd schreef op 09 augustus 2004 @ 16:53:
XSLT doe je server side. XML heeft client side geen voordelen boven XHTML: uitleg. En XHTML heeft geen voordelen boven HTML (voornamelijk omdat Internet Explorer het niet ondersteund).

Mozilla en Opera ondersteunen dit bijvoorbeeld prima, en heeft dan duidelijk voordelen.
Daarbij kun je voor IE een alternatief geven, in gewoon text/html
Jammer dat Opera XSL (nog) niet xsl ondersteund, want dit is een prachtige taal als je er ervaring mee hebt.
Dan had ik gedacht om via JS xml te laden, maar dit is me nog niet gelukt (wel in IE en Moz), volgens mij is dit ook niet mogelijk, heel jammer van opera, zo kun je via client-side weinig doen met xml bestanden.

Mijn oplossing is:
XML+XSL
en dan de xml een css meegeven, zodat ook zonder xsl kan.
Het heeft minder mogelijkheden via css, maar dan kun je alles wel bekijken.
Zo kan via IE, Moz en Opera met XML werken via client-side methode.

[JeromeB]

iCe01 schreef op 09 augustus 2004 @ 21:23:
Even een kleine offtopic vraag; met wat voor een doctype kun je een XSL valideren?

Heb ik iets gemist ofzo?

[disjfa]

Ik moet het ook even kwijt. Maar vanaf php 3.0.6 kan je degenlijk php pasen server side dus waarom zou je dat client side willen als dat niet te makkenlijk is voor de meeste normale browsers

php 5 maakt xml parsen niet een stuk makkenlijker hoor

[w3news]

disjfa schreef op 10 augustus 2004 @ 01:23:
Ik moet het ook even kwijt. Maar vanaf php 3.0.6 kan je degenlijk php pasen server side dus waarom zou je dat client side willen als dat niet te makkenlijk is voor de meeste normale browsers

php 5 maakt xml parsen niet een stuk makkenlijker hoor

Waarom soms niet server-side?
Als je lokaal het wilt gebruiken, of de je geen php kan gebruiken op je server.

[Grijze Vos]

Of omdat je daar veel serverside parsetijd mee kunt besparen, of omdat je dan XML kunt cachen en direct outputten. Dat zijn al 2 redenen die me snel invallen.

[Verwijderd]

Mozilla en Opera ondersteunen dit bijvoorbeeld prima, en heeft dan duidelijk voordelen.

Noem ze. En citeer alsjeblieft niet het W3C, maar noem een aantal voordelen waar je ook direct voordeel aan hebt.

Daarbij kun je voor IE een alternatief geven, in gewoon text/html

Ooit wel is gedacht aan compatibility? Op het moment dat je het zo oplost heb je een ander probleem. CSS. De manier waarop CSS toegepast wordt verschilt, zo kun je in HTML (text/html) het BODY element stijlen en je complete canvas wordt gepaint, in XML (application/xml) moet je het root element stijlen.

Jammer dat Opera XSL (nog) niet xsl ondersteund, want dit is een prachtige taal als je er ervaring mee hebt.

Je bedoelt XSLT. XSL wordt gebruikt als afkorting voor XSL-FO. Waarom zou Opera zoiets moeten ondersteunen? Het heeft praktisch bijna geen voordelen.

Mijn oplossing is:
XML+XSL en dan de xml een css meegeven, zodat ook zonder xsl kan.

Waarom dan XSLT (ik neem dat je XSLT bedoelt) gebruiken. Het voordeel is weg als het ook met CSS kan.

Zo kan via IE, Moz en Opera met XML werken via client-side methode.

En heeft Google het nakijken.

[Verwijderd]

De rede dat ik in eerste instantie voor XML heb gekozen is het sublieme scheiden van data en opmaak, zodat ik geen problemen krijg met mensen die de site onderhouden.

Dat voordeel heeft HTML ook. (Niet dat ik XML met HTML wil vergelijken ofzo.)

Even een kleine offtopic vraag; met wat voor een doctype kun je een XSL valideren?

DOCTYPEs zijn niet belangrijk. Zeker niet met complexere XML structureren e.d. Het enige waar een DTD handig voor kan zijn zijn entiteiten, maar die uitvinding kun je beter links laten leggen imho. Eventueel kun je kijken naar RelaxNG.

[Verwijderd]

Verwijderd schreef op 10 augustus 2004 @ 07:45:
Noem ze. En citeer alsjeblieft niet het W3C, maar noem een aantal voordelen waar je ook direct voordeel aan hebt.

Daar waar nodig de cpu kracht nodig voor de transformatie neerleggen bij de client, waar deze beschikbaar is. Tevens kun je vanaf dat moment met een reeds geladen XSLT transformaties blijven uitvoeren op nieuwe XML content, en op alle wijzigingen in de XML content. Je hebt niet de callbacks naar je server toe.

En heeft Google het nakijken.

Het ligt eraan tot hoever ze de prioriteiten hebben liggen qua ondersteuning. De nieuwe Safari, de Mozilla familie en de huidige IE versies bieden ondersteuning voor xmlHttp, missende ondersteuning in bijvoorbeeld Opera (die wel het xmlHttp object kent, maar vervolgens niets teruggeeft, en xml documenten wegens missende ondersteuning van createDocument), kun je dan nog patchen van xmlHTTP naar xmlRPC of de gebruikelijke iframes.

Ik kan me voorstellen dat ze als technology company liever kiezen voor het gebruik van nieuwe technologiën of iig nieuwere methodieken, dan blijven vasthouden aan oudere technieken, meer bandbreedte verbruik en load, en support voor een minimaal aantal gebruikers ervoor terug (de Opera gebruikers).

Imo is het best wel klunzig dat Opera zo eigenwijs xmlHttp blijft negeren. Ze hebben hun prioriteiten vast ook ergens anders liggen, maar op zich is xmlHttp echt een godsgeschenk voor een nieuwe manier van web ui.

[ Voor 8% gewijzigd door Verwijderd op 10-08-2004 09:08 ]

[Verwijderd]

Verwijderd schreef op 10 augustus 2004 @ 07:45:
[...]
En heeft Google het nakijken.

Ik snap niet helemaal waar je deze wijsheid vandaan haalt. Het is een argument dat waar kán zijn, maar niet per definitie waar ís. Wie weet zoekt google geavanceerder dan wij denken. Misschien hebben de robots van Google wel een xslt parser die een xml document met xml-stylesheet PI's kan transformeren en die output opslaat.
Ik sluit niet uit, dat Google wel een dozijn bakken heeft staan die alleen xslt transformaties uitvoert...

[ Voor 5% gewijzigd door Verwijderd op 10-08-2004 09:52 ]

[André]

Verwijderd schreef op 10 augustus 2004 @ 09:51:
[...]


Ik snap niet helemaal waar je deze wijsheid vandaan haalt. Het is een argument dat waar kán zijn, maar niet per definitie waar ís. Wie weet zoekt google geavanceerder dan wij denken. Misschien hebben de robots van Google wel een xslt parser die een xml document met xml-stylesheet PI's kan transformeren en die output opslaat.
Ik sluit niet uit, dat Google wel een dozijn bakken heeft staan die alleen xslt transformaties uitvoert...

Zoiets is natuurlijk heel simpel te testen

[Verwijderd]

Als Google zo geavanceerd was, zou het vast wel XHTML ondersteunen. Niet dus. Daarnaast zijn er diverse sites gebaseerd op XML die door middel van XSLT omgetoverd worden in HTML. Wat je op Google vindt is de inhoud die in het XML document staat plus een linkje naar een HTML versie die opgeslagen is op een van de servers van Google.

Gordijnstok, xmlHttp is inderdaad zeer leuk om mee te spelen en waarschijnlijk ook zeer handig om toe te passen in projecten waar je serverload e.d. wilt beperken. Het enige probleem wat ik ermee heb is dat je afhankelijk wordt van JS voor de data die je communiceert. In een "gesloten" omgeving, zoals een intranet, of het niet publieke deel van een extranet kan het perfect. Aangezien je daar gewoon bepaalde eisen kunt stellen aan software en eventueel zelfs aan hardware (processorkracht etc.). Publiekelijk wordt dat alleen een stuk lastiger (en komt het neer op rendement :-)).

[Grijze Vos]

Zo moeilijk is het niet om IE6.0 en FireFox te detecteren en daar XML te sturen, en anders gewoon serverside die XML om te zetten met XSLT en je XHTML te sturen.

Aangezien googlebot zich niet voordoet als een browser is het niet moeilijk om dat te realiseren, en het heeft imho toch echt wel voordelen.

[w3news]

Verwijderd schreef op 10 augustus 2004 @ 07:45:
[...]
Je bedoelt XSLT. XSL wordt gebruikt als afkorting voor XSL-FO. Waarom zou Opera zoiets moeten ondersteunen? Het heeft praktisch bijna geen voordelen.
[...]
Waarom dan XSLT (ik neem dat je XSLT bedoelt) gebruiken. Het voordeel is weg als het ook met CSS kan.
[...]

XSL is niet zelfde als XSL-FO, maar is algemene naam, van XSLT en XSL-FO, maar ik bedoel XSLT ja.
Voordat XSL-Fo en XSLT was bedacht, was ik al bezig met XSL.
Daarom zeg ik nog altijd XSL ipv XSLT.
En omdat XSK-Fo vrijwel niet wordt gebruikt, kun je netzo goed XSL zeggen, maar XSLT is wel duidelijker, ik zal dat in vervolg zeggen

Maar met CSS kun je gewoon te weinig, daarom gebruik ik XSLT, en heb ik de XML vormgegeven met CSS zodat opera gebruikers de tekst nog wel mooi kunnen bekijken en zo, maar je zit gewoon met beperkingen.
En omdat Mozilla en IE gewoon het grootste percentage hebben, gebruik ik toch XSLT voor normaal gebruik.
Mijn website is intussen al 50% mozilla bezoekers. (gezien van ruim 400 ip's)
W3schools zit nu op 14.6%.
Opera zit bij mij op 0.2% (en misschien ben ik dat dit wel eens uitprobeerd met opera)
Bij w3schools op 2.2%

Dat betekent dus dat opera vrij klein is, maar je moet er wel rekening mee houden.
Van 1000 personen gebruiken dus wel 22 opera die w3schools bezoeken.
Bij mij maar 2 op de 1000.

[Verwijderd]

Het was een algemene term en nu wordt er volgens mij meer XSL-FO dan XSLT mee aangeduid, maar dat hangt er ook vast vanaf wat je leest en waar. XSLT en/of XSL-FO gebruiken is iig consequenter.

Met XSLT kun je trouwens niet "vormgeven" dus om te zeggen dat XSLT meer kan dan CSS...

Heb je er ook rekening mee gehouden dat Opera zich standaard identificeert als Internet Explorer en mensen bijna nooit hun standaard opties veranderen? (Zeker niet dit soort opties.)

[Verwijderd]

Verwijderd schreef op 10 augustus 2004 @ 09:58:
Gordijnstok, xmlHttp is inderdaad zeer leuk om mee te spelen en waarschijnlijk ook zeer handig om toe te passen in projecten waar je serverload e.d. wilt beperken. Het enige probleem wat ik ermee heb is dat je afhankelijk wordt van JS voor de data die je communiceert.

Zeker, je wordt geheel afhankelijk zelfs van javascript, daar heb je gelijk in. En eigenlijk juich ik dat toch best toe, daar er eindelijk gebruik wordt gemaakt van de mogelijkheden die er worden geboden op het web en eigenlijk al heel lang beschikbaar zijn. Het is net als met semantiek, het is netjes om je code op te bouwen naar waar de tags voor bedoeld zijn. Zoiets valt ook weer te zeggen over xmlHttp, het is netjes om gegevens die je reeds hebt niet nogmaals op te halen. CSS files worden gecached, JS files ook, maar je ziet nog te vaak dat complete datastructuren wederom opnieuw gerenderd worden per request, zonde.

Soms moet je als bedrijf offers maken, en ik denk dat Google dat hier heeft gedaan. Ik vermoed dat ze Opera ondersteuning best in de interne meetings hebben behandeld, het zijn toch techneuten. Maar kijkend naar het gMail verkeer (ik doel hierbij op gebruik van xmlHttp in gMail), vermoed ik dat ze een sommetje hebben gemaakt van zoveel procent IE met ondersteuning, zoveel procent Mozilla met ondersteuning, en dit levert ons een besparing van zoveel load, en bandbreedte op en dat scheelt weer in de kosten, zeker gekeken naar de hoeveelheid gebruikers van gMail en het aantal gemiddelde hits per client. Deze zal namelijk in een email applicatie best hoog liggen, even lezen, even replyen, even forwarden, even status wijzigen, moven, etc.

Ik heb natuurlijk geen cijfers en dat valt ook lastig te vergelijken in de praktijk zonder een accesible versie maar ik denk dat de besparingen nog schrikbarend hoog zijn. Iets wat Google zeker in de gaten moet houden als gMail de HotMail concurrent wordt. Ik denk met het oogpunt op Opera usage <> Bandbreedte besparing, het rendement heel hoog is, en hoger wordt naarmate gMail meer gebruikers krijgt. Zodra Opera xmlHttp ingebouwd heeft pik je dat ook nog is mee.

[w3news]

Verwijderd schreef op 10 augustus 2004 @ 10:23:

Met XSLT kun je trouwens niet "vormgeven" dus om te zeggen dat XSLT meer kan dan CSS...

Ik laadt in XSLT natuurlijk ook een CSS mee.
ZO heb ik een XML bestand voor de gegevens.
XSLT om alles goed te verwerken.
CSS om kleurtjes en afmetingen te geven
en JS om extre effecten er in te verwerken. (en extra XML bestanden op te roepen)

En ik weet het dat Opera vaak als IE staat, maar dan kun je nog zien dat het Opera is, en niet IE.
Maar ik weet dat er veel onenigheid is over Opera statestieken, de ene kan wel Opera wel echt zien, ook al in standaard instellingen, de andere niet.
http://www.w3news.org/versie.html kun je zien dat het wel goed mogelijk is om opera echt als opera er uit te filteren. (userAgent)
Ik weet niet hoe W3schools het doet, maar mijn werkt dacht ik wel goed.

[Verwijderd]

Verwijderd schreef op 10 augustus 2004 @ 10:23:
Met XSLT kun je trouwens niet "vormgeven" dus om te zeggen dat XSLT meer kan dan CSS...

Ik denk dat hij bedoelt dat je met XSLT de structuur van je data kunt aanpassen aan de weergave. Dat is met CSS niet mogelijk (op :before en :after constructies na).