CSS XHTML alles kaputt, könnte heuln
0 0 
molily
0 Das geht auch einfacher...
0
CSS XHTML alles kaputt, könnte heuln
Gunnar BittersmannJungens, ich brauche Eure Hilfe!!
Ich hab eine so schöne Internetseite gehabt. Nur leider zu spät erst den ********* Internet Explorer angemacht. Da ging natürlich null. Aber den Fehler hatte ich gefunden. Es mußte rein:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr">
Weiß nicht, warum, war aber so.
Jetzt hat sich nur leider (einheitlich in beiden Browsern) das Aussehen komplett verändert. Es scheint, als ob der die styles gar nicht mehr lesen kann. Hatte auch alles regelkonform mit /* <![CDATA[ */ ... /* ]]> */ ausgeklammert, aber der erkennt die Angaben nicht mehr.
Woran liegt denn das??? Vorher hatte es doch auch so schön geklappt. Buuuh.
-
Jungens, ich brauche Eure Hilfe!!
Ich hab eine so schöne Internetseite gehabt. Nur leider zu spät erst den ********* Internet Explorer angemacht. Da ging natürlich null. Aber den Fehler hatte ich gefunden. Es mußte rein:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr">Das du ein ltr willst, kann ich verstehn. Dass du XHTML willst, da setzt mein Verständnis aus.
Weiß nicht, warum, war aber so.
Jetzt hat sich nur leider (einheitlich in beiden Browsern) das Aussehen komplett verändert. Es scheint, als ob der die styles gar nicht mehr lesen kann. Hatte auch alles regelkonform mit /* <![CDATA[ */ ... /* ]]> */ ausgeklammert, aber der erkennt die Angaben nicht mehr.
Woran liegt denn das??? Vorher hatte es doch auch so schön geklappt. Buuuh.Siehe oben. XHTML ist die nutzloseste Strategie, es sei denn man will andere XML Sprachen inline nutzen. Und das will man echt nur für ganz spezielle MSIE freie Zonen. Dazu bedarf es ein bisschen mehr als deine Tax-Xoupe-Anweisung.
mfg Beat
-
Hallo,
da setzt mein Verständnis aus.
Ja.
XHTML ist die nutzloseste Strategie, es sei denn man will andere XML Sprachen inline nutzen.
Nein.
Mathias
-
Egal, bums. Es lag wirklich an ein paar Ungenauigkeiten: Mal hier "px" vergessen, mal da eine Höhenangabe vergessen. Das erklärt mir zwar jetzt nicht dieses DOCTYPE-Dings, aber das ist egal.
Danke Euch!!!
-
Egal, bums. Es lag wirklich an ein paar Ungenauigkeiten: Mal hier "px" vergessen, mal da eine Höhenangabe vergessen. Das erklärt mir zwar jetzt nicht dieses DOCTYPE-Dings, aber das ist egal.
Dann solltest du ganz schnell damit anfangen dir anzulesen was den der DOCTYPE ist, welche es gibt und warum es unterschiedliche sind.
Dieses Verständnis ist wichtig, um a) die Webhistorie besser zu verstehen und zu verstehen warum welcher Browser dann und wann Probleme mit diesem oder jenem hat. -
Mahlzeit Peterchen,
Egal, bums. Es lag wirklich an ein paar Ungenauigkeiten: Mal hier "px" vergessen, mal da eine Höhenangabe vergessen.
Da kannst Du mal sehen, wie wichtig es ist, validen Code zu schreiben.
Das erklärt mir zwar jetzt nicht dieses DOCTYPE-Dings, aber das ist egal.
http://de.selfhtml.org/html/allgemein/grundgeruest.htm#dokumenttyp@title=Nicht? Woher soll ein Browser wissen, was Du ihm vorsetzt, wenn Du ihm nicht sagst, um was es sich handelt? Es gibt verschiedene (X)HTML-Standards, also solltest Du auch angeben, nach welchem Du Deine Seiten gebaut hast. Dann hat ein Browser eine Referenz, an die er sich halten kann und nach der er die Seite rendern kann.
MfG,
EKKi--
sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
-
-
Hallo!
da setzt mein Verständnis aus.
Ja.
XHTML ist die nutzloseste Strategie, es sei denn man will andere XML Sprachen inline nutzen.
Nein.
Das unterschreibe ich.
Eine Frechheit XHTML dafür verantwortlich zu machen. ;)Viele Grüße
Thorsten--
ie:( fl:( br:< va:) ls:& fo:) rl:° n4:° ss:) de:> js:| ch:? sh:( mo:| zu:)
-
-
Das du ein ltr willst, kann ich verstehn. Dass du XHTML willst, da setzt mein Verständnis aus.
Das du nicht verstehst warum XHTML so schön sein kann, da setzt dann mein Verständnis aus...
Siehe oben. XHTML ist die nutzloseste Strategie, es sei denn man will andere XML Sprachen inline nutzen. Und das will man echt nur für ganz spezielle MSIE freie Zonen. Dazu bedarf es ein bisschen mehr als deine Tax-Xoupe-Anweisung.
Aha. Daher beschäftigen sich zwar nur einige Tausend von Fachhleuten mit der Weiterentwicklung von Technologien und Standarts und der Herr erachtet es als Nutzlos.
Ich sag dir was Nutzlos ist. Entwickler die darauf bestehen, dass ihr geliebtes Tabellenlayout, welches es immer schon gab... auch weiterhin existiert...
Und wo wir schon dabei sind. CSS? Eigentlich nutzlos man kann doch auch einfach die guten alten Tags nehmen.
XML? Was ist das. Ein billiger Abklatsch von HTML ;)-
Das du ein ltr willst, kann ich verstehn. Dass du XHTML willst, da setzt mein Verständnis aus.
Das du nicht verstehst warum XHTML so schön sein kann, da setzt dann mein Verständnis aus...xhtml 1.0 als text/html hat gegenüber html 4.01 keinen nennenswerten vorteil, das ist ein hartes faktum
als application/xml oder application/xhtml+xml bietet xhtml signifikante vorteile, ist aber im internet exploder gänzlich unbrauchbar
Aha. Daher beschäftigen sich zwar nur einige Tausend von Fachhleuten mit der Weiterentwicklung von Technologien und Standarts und der Herr erachtet es als Nutzlos.
damit hat er aber recht, siehe oben: xhtml ist momentan unbrauchbar und eine ästhetik-sache für freaks (ich schreibe meine seiten auch in xhtml 1.0, aber liefere sie als text/html aus - dadurch habe ich, bis auf den schöneren code und die theoretische parsebarkeit als xml keinen vorteil)
Ich sag dir was Nutzlos ist. Entwickler die darauf bestehen, dass ihr geliebtes Tabellenlayout, welches es immer schon gab... auch weiterhin existiert...
tabellenlayout hat nichts mit xhtml zu tun
Und wo wir schon dabei sind. CSS? Eigentlich nutzlos man kann doch auch einfach die guten alten Tags nehmen.
du hast es nicht verstanden - bezüglich tags: http://meiert.com/de/publications/articles/20060924/
XML? Was ist das. Ein billiger Abklatsch von HTML ;)
nein xml ist eine teilmenge von sgml - xml hat mit html nur gemeinsame wurzeln, ist aber kein derivat von html
-
XML? Was ist das. Ein billiger Abklatsch von HTML ;)
nein xml ist eine teilmenge von sgml - xml hat mit html nur gemeinsame wurzeln, ist aber kein derivat von htmlIch danke dir dafür, dass du den Unterschied zwischen "Strategie" und "Sprache" in meinen Worten erkannt hast.
Es ist mir in der Tat fern, XML zu kritisieren. Wir haben aber ganz einfach keinen hinreichenden Support um application/xhtml+xml an Browser auszuliefern. So bleibt XML primär eine Sprachgattung, die ihre Vorzüge in internen Abwicklungen, oder in Testszenarien geniesst.
Persönlich arbeite ich derzeit an einem Dokument
<?xml version="1.0" encoding="iso-8859-15" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN" "http://www.w3.org/2002/04/xhtml-math-svg/xhtml-math-svg-flat.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:svg="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:lang="en" >Aber das Dokument ist nicht für einen öffentlichen Gebrauch vorgesehen. Dafür werden die Einschränkungen zu gross sein:
XML Unterstützung, Javascript Unterstützung.
Um solche Konstrukte gebrauchsfähig zu machen, muss man etliche Portierungen vornehmen, und wird dennoch nicht _den_ verbreiteten Browser ansprechen können.
Selbst die Erkennung der XML Eigenschaft via Content-negotiation beim Server ist alles andere als verlässlich.Ein Grund, warum XHTML überhaupt als (serverseitig) content-type: text/html "funktioniert", liegt darin, dass Browser heute den SGML Standard nicht mehr voll unterstützen. Sonst wäre solcher Quellcode wohl mit > > > > durch jedes <br /> übersäht.
mfg Beat
-
Hallo,
Wir haben aber ganz einfach keinen hinreichenden Support um application/xhtml+xml an Browser auszuliefern.
Ja, und? Who cares? Fehlender Support für application/xhtml+xml spricht gegen application/xhtml+xml, nicht gegen XHTML an sich.
Ein Grund, warum XHTML überhaupt als (serverseitig) content-type: text/html "funktioniert", liegt darin, dass Browser heute den SGML Standard nicht mehr voll unterstützen.
Kein Browser hat je SGML hinreichend unterstützt. Es gibt m.W. keinen Browser der Geschichte, der XHTML nicht verarbeiten kann, weil er SGML genau nimmt. Ach, Moment, da war mal irgendein Lynx-ähnlicher (ich glaube, Links), der einen strengen SGML-Parsing-Modus hat. Der ist aber standardmäßig ausgeschaltet. Auch, damit HTML-Tag-Soup überhaupt verarbeitet werden kann.
Mathias
-
Ja, und? Who cares? Fehlender Support für application/xhtml+xml spricht gegen application/xhtml+xml, nicht gegen XHTML an sich.
ja, aber bis auf die wohlgeformtheit des dokuments bleibt dann bei xhtml 1.0 nicht mehr viel übrig, was vorteile gegenüber html 4.01 bieten könnte ;)
ob die wohlgeformtheit nun, wenn man das ganze nicht als xml ausliefert, sondern als standardkonformes html, ein vorteil ist oder nicht, darüber lässt sich streiten - für mich ist es wie gesagt zumindest eine sache der ästhetik
-
Hallo,
bis auf die wohlgeformtheit des dokuments bleibt dann bei xhtml 1.0 nicht mehr viel übrig
Es bleibt übrig, dass es XHTML ist, und XHTML ist XML, daraus ergibt sich die Verarbeitbarkeit als XML und daraus alle Vorteile.
(Bestechende Logik, nicht?)
Wenn ich eine solche Verarbeitung im Browser nicht habe, dann funktioniert die Einbindung von Markup aus anderen Namensräumen nicht (nicht prinzipiell, aber in den derzeitigen Browsern).Mathias
-
Wenn ich eine solche Verarbeitung im Browser nicht habe, dann funktioniert die Einbindung von Markup aus anderen Namensräumen nicht (nicht prinzipiell, aber in den derzeitigen Browsern).
das ist mir durchaus klar - aber die einbindung von xml-daten aus anderen namensräumen ist kein "nicht nennenswerter" vorteil sondern eben der signifikante vorteil von xhtml als xml im vergleich zu html - aber das funktioniert eben nur prinzipiell und es ist praktisch unbenutzbar - eine lösung die nicht breitgefächtert funktioniert, ist imo unbrauchbar
wenn ich xhtml mit eingebettetem mathml verwende, und das das ganze nur in 20% der browser funktioniert und ich sowieso serverseitig eine grafik generieren muss, kann ich gleich für alle browser eine grafik generieren und auf mathml verzichten
-
Hallo,
die einbindung von xml-daten aus anderen namensräumen ist kein "nicht nennenswerter" vorteil sondern eben der signifikante vorteil von xhtml als xml im vergleich zu html
Ja, das ist der große Vorteil von XHTML auf der Browserseite.
wenn ich xhtml mit eingebettetem mathml verwende, und das das ganze nur in 20% der browser funktioniert und ich sowieso serverseitig eine grafik generieren muss, kann ich gleich für alle browser eine grafik generieren und auf mathml verzichten
Das spricht erstmal gegen eingebettetes MathML-Markup, man kann durchaus object-Elemente schachteln, sodass sie eine MathML-Ressource einbinden und als Fallback eine Vektor-, dann als Fallback eine Pixelgrafik. ;)
Mathias
-
Das spricht erstmal gegen eingebettetes MathML-Markup, man kann durchaus object-Elemente schachteln, sodass sie eine MathML-Ressource einbinden und als Fallback eine Vektor-, dann als Fallback eine Pixelgrafik. ;)
wenn du 2 fallback-varianten als arbeitserleichterung siehst, möchte ich nicht wissen, was es für dich heisst, dass etwas langsam aber sicher unnötig kompliziert wird :)
-
Hallo,
wenn du 2 fallback-varianten als arbeitserleichterung siehst
Sinnvollerweise sind diese Fallback-Varianten generierbar.
Wenn ich ohnehin eine Pixelgrafik erstellen muss, werde ich die Formel selbst nicht pixeln, sondern in irgendeinem einem Formel-Editor erstellen. Dass der MathML als Format benutzt bzw. als Exportformat unterstützt, liegt nicht fern (vermute ich mal, praktisch kenne ich mich in dem Bereich nicht aus). Und SVG ist auch nicht abwegig (OpenOffice Math kann das m.W.).
Insofern finde ich mein Beispiel gar nicht so abwegig.Mathias
-
wenn du 2 fallback-varianten als arbeitserleichterung siehst
Insofern finde ich mein Beispiel gar nicht so abwegig.ja, abwegig ist es sicher nicht - aber es erfordert dennoch (wenn wahrscheinlich auch nicht viel) mehr aufwand, da diese fallbackroutinen ja auch irgendwer programmieren muss ;)
-
-
-
-
-
-
-
-
-
xhtml 1.0 als text/html hat gegenüber html 4.01 keinen nennenswerten vorteil, das ist ein hartes faktum
Doch, ich kann XHTML 1.0 mit einem XML-Parser testen, der mir mehr Ungewolltes liefert, als das ein Tag-Soup-Parser (für HTML 4.01) kann.
damit hat er aber recht, siehe oben: xhtml ist momentan unbrauchbar und eine ästhetik-sache für freaks (ich schreibe meine seiten auch in xhtml 1.0, aber liefere sie als text/html aus - dadurch habe ich, bis auf den schöneren code und die theoretische parsebarkeit als xml keinen vorteil)
Was spricht dagegen, die Seiten für Browser, die application/xhtml+xml verstehen, auch als solche auszuliefern?
--
Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:|-
Doch, ich kann XHTML 1.0 mit einem XML-Parser testen, der mir mehr Ungewolltes liefert, als das ein Tag-Soup-Parser (für HTML 4.01) kann.
siehe unten - die theoretische parsebarkeit als xml - ich mach das öfter, dass ich mit flash eine xhtml seite (welche als text/html ausgeliefert wird) per xml/dom-funktionen einlese - somit lassen sich relativ barrierefrei flash-slideshows erstellen:
<object> <img /> <img /> <img /> </object>das flash liest hierbei einfach die bilder im object-element ein und stellt sie als slideshow dar, wer kein flash hat, sieht die bilder auf gewöhnlichem weg
Was spricht dagegen, die Seiten für Browser, die application/xhtml+xml verstehen, auch als solche auszuliefern?
nichts - das ist ja auch problemlos möglich, sofern im http-request die nötigen informationen hinterlegt sind)
wie gesagt - der praktische nutzen ist aber imho äusserst begrenzt und praktisch nicht vorhanden
-
Hallo,
der praktische nutzen ist aber imho äusserst begrenzt und praktisch nicht vorhanden
Also in meiner Praxis ist er vorhanden, und wie du in deinem Posting dargelegt hast, ist er es in deiner Praxis auch. Schön, dann sind wir uns ja einig.
Mathias
-
Also in meiner Praxis ist er vorhanden, und wie du in deinem Posting dargelegt hast, ist er es in deiner Praxis auch. Schön, dann sind wir uns ja einig.
ich habe ja nie behauptet, dass der nutzen nicht vorhanden ist - dieser angesprochene nutzen lässt sich auch durch einen andere methoden abbilden
das angesprochene flashbeispiel: mit javascript/dom die kinder des object-elements auslesen und an flash übergeben für die bilderslideshow - dafür brauche ich kein xhtml, das geht auch mit html 4.01
wenn mir jemand ein wirklich enorm revolutionäres xml-feature bzw ein feature von xhtml nennen kann, welches ich in jedem browser nutzen kann, dann revidiere ich meine meinung bezüglich "nicht nennenswert" auf "äusserst sinnvoll" ;)
-
Hallo,
das angesprochene flashbeispiel: mit javascript/dom die kinder des object-elements auslesen und an flash übergeben für die bilderslideshow - dafür brauche ich kein xhtml, das geht auch mit html 4.01
Na, dann ist die andere Lösung offenbar sogar schlechter. Wenn man von Seiten des (X)HTML-Dokuments, das das Flash einbindet, mit dem Flash kommuniziert, dann erübrigt es ist natürlich, dass das Flash dieses Dokument noch einmal selbst parst.
wenn mir jemand ein wirklich enorm revolutionäres xml-feature bzw ein feature von xhtml nennen kann, welches ich in jedem browser nutzen kann
Entweder du hast bisher noch nicht eine Diskussion zum Thema hier oder anderswo verfolgt (kein Vorwurf) oder meine Argumentation war nicht deutlich genug:
Für mich ist es nur ein kleines Problem, dass die verbreiteten *Browser* XHTML nicht hinreichend verarbeiten können und man es deshalb größtenteils sein lässt. Das rüttelt nicht daran, dass unzählige weitere »Stellen« das Dokument als XML verarbeiten können: Beim Schreiben / bei der automatisierten Generierung und Veränderung, bei der Weitergabe und beim Auslesen, bei der Überprüfung und Fehlerkorrektur.Mathias
-
Entweder du hast bisher noch nicht eine Diskussion zum Thema hier oder anderswo verfolgt (kein Vorwurf) oder meine Argumentation war nicht deutlich genug:
ich habe schon unzähige diskussionen zu dem thema verfolgt und deine argumentation ist auch verständlich - ich gehe in dem fall aber von meinen einsatzgebieten aus
Für mich ist es nur ein kleines Problem, dass die verbreiteten *Browser* XHTML nicht hinreichend verarbeiten können und man es deshalb größtenteils sein lässt. Das rüttelt nicht daran, dass unzählige weitere »Stellen« das Dokument als XML verarbeiten können: Beim Schreiben / bei der automatisierten Generierung und Veränderung, bei der Weitergabe und beim Auslesen, bei der Überprüfung und Fehlerkorrektur.
natürlich sehe ich die vorteile der automatisierten weiterverarbeitung - für mich haben sich die vorteile allerdings noch nicht wirklich rauskristallisiert - bez ich hab sie vielleicht einfach noch nicht benutzt
für syndikation ist atom/rss da und ob ich aus meinem cms xhtml, html oder latex generiere, ist mir eigentlich egal, da es in allen fällen ein striktes regelwerk gibt
-
-
-
-
-
Was spricht dagegen, die Seiten für Browser, die application/xhtml+xml verstehen, auch als solche auszuliefern?
Mit welcher glorreichen Methode realisierst du das?
mfg Beat
-
Was spricht dagegen, die Seiten für Browser, die application/xhtml+xml verstehen, auch als solche auszuliefern?
Mit welcher glorreichen Methode realisierst du das?
vermutlich über content negotiation - ist aber auch nur bedingt zuverlässig, sowohl bei der auswahl der sprache ausauch bei der bestimmung sämtlicher anderer informationen, wie etwa den akzeptierten content-type
falsche einstellungen, vorkonfigurierte eingestellungen, einstellungen auf einem fremden rechner usw
-
Hallo,
vermutlich über content negotiation - ist aber auch nur bedingt zuverlässig, sowohl bei der auswahl der sprache ausauch bei der bestimmung sämtlicher anderer informationen, wie etwa den akzeptierten content-type
falsche einstellungen, vorkonfigurierte eingestellungen, einstellungen auf einem fremden rechner usw
Häh?
Entweder der Browser gibt im Accept-Header seine Fähigkeiten korrekt wieder, oder er tut es nicht. DAS ist tatsächlich anzuzweifeln.
Aber was sollen denn »falsche Einstellungen« sein? Wenn der Benutzer an dem Header frickelt? Das wäre schon mutwilliges kaputtmachen. Selbst schuld, wenn der Browser dann alle Webserver belügt.
Vorkonfigurierte Einstellungen - was soll das meinen?
Einstellungen auf einem fremden Rechner - häh?Der Accept-Header soll die eingebauten Fähigkeiten des Browsers wiedergeben. Die haben nichts mit irgendwelchen »Einstellungen« zu tun. Natürlich kann ein User mit genügend »krimineller Energie« ;-) den Header fälschen und in den Browser-Interna herumfuckeln, aber dann gilt das SSKM-Prinzip.
Ehrlich gesagt habe ich den Eindruck, dass du hier massig FUD verbreitest.
Mathias
-
Entweder der Browser gibt im Accept-Header seine Fähigkeiten korrekt wieder, oder er tut es nicht. DAS ist tatsächlich anzuzweifeln.
von etwas anderem habe ich auch nicht gesprochen - natürlich sind nicht die informationen ansich anzuzweifeln, sondern ob die informationen korrekt sind oder nicht
Aber was sollen denn »falsche Einstellungen« sein? Wenn der Benutzer an dem Header frickelt? Das wäre schon mutwilliges kaputtmachen. Selbst schuld, wenn der Browser dann alle Webserver belügt.
da muss der benutzer nichtmal etwas dafür können - es gibt sicher genug plugins, die an einem browser herumfrickeln und der benutzer bekommt nix davon mit - ich möchte garnicht wissen, was es da alles gibt
Vorkonfigurierte Einstellungen - was soll das meinen?
Einstellungen auf einem fremden Rechner - häh?das betrifft vor allem die das content-negotiation-problem bez. der sprachen - wenn ich als österreicher in einem internetcafe in der schweiz sitze und einen italienischen browser vor mir habe, der in der bevorzugten sprache fr_CH eingestellt hat, dann hilft mir die automatische sprachvereinbahrung nix
Der Accept-Header soll die eingebauten Fähigkeiten des Browsers wiedergeben. Die haben nichts mit irgendwelchen »Einstellungen« zu tun.
mein fehler - ich hatte mit accept header sämtliche accept-felder zusammengefasst ;)
im übrigen kann ich in meinem browser (firefox) in about:config problemlos einstellen, was ich übermitteln will, die defaulteinstellungen finden sich unter network.http.accept.default
zeichencodierung (accept-charset) und sprache (accept-language) sind dinge die etwas mit der benutzereinstellung oder voreinstellung zu tun haben
Ehrlich gesagt habe ich den Eindruck, dass du hier massig FUD verbreitest.
ich habe den eindruck, dass du den finger ab und an zu locker am abzug hast - aber das lässt sich ausbauen, vielleicht wird mal ein guter revolverheld aus dir :D
traue niemandem, deinem benutzer am wenigstens - und informationen, die vom browser kommen, sollst du noch weniger trauen
im falle der akzeptierten mime-typen ist das mit hoher wahrscheinlichkeit etwas übertrieben, dennoch ist die sache nicht 100%ig zuverlässig
-
Der Accept-Header soll die eingebauten Fähigkeiten des Browsers wiedergeben. Die haben nichts mit irgendwelchen »Einstellungen« zu tun.
mein fehler - ich hatte mit accept header sämtliche accept-felder zusammengefasst ;)Der Fehler ist verständlich, HTTP ist hier nicht einheitlich, wenn der Accept-Header konsequent benannt worden wäre, hieße er Accept-Type.
--
Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:|
-
-
-
-
Was spricht dagegen, die Seiten für Browser, die application/xhtml+xml verstehen, auch als solche auszuliefern?
Mit welcher glorreichen Methode realisierst du das?Das geht theoretisch mit jeder Methode, die Request-Header lesen kann und (die Informationen daraus zugrunde legend) die Response-Header manipulieren kann. Kommt im Accept-Header application/xhtml+xml vor, so kann man auch application/xhtml+xml ausliefern, sonst wird text/html gesendet.
Beim Apache beispielsweise im .htaccess-Kontext so (ungetestet):<FilesMatch "\.html$"> SetEnvIf Accept "application/xhtml\+xml" xhtml=true Header set Content-Type "application/xhtml+xml" env=xhtml </FilesMatch>--
Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:|-
Das geht theoretisch mit jeder Methode, die Request-Header lesen kann und (die Informationen daraus zugrunde legend) die Response-Header manipulieren kann. Kommt im Accept-Header application/xhtml+xml vor, so kann man auch application/xhtml+xml ausliefern, sonst wird text/html gesendet.
Beim Apache beispielsweise im .htaccess-Kontext so (ungetestet):<FilesMatch ".html$">
SetEnvIf Accept "application/xhtml+xml" xhtml=true
Header set Content-Type "application/xhtml+xml" env=xhtml
</FilesMatch>Die Methode ist mir geläufig, erfasst aber nur jene browser, welche application/xhtml+xml senden, und missachtet, dass sie dabei einen üblen Wert senden. Weiter wird das hier auf .html Dokumente angewendet. Wir wissen, was geschieht, wenn man mit firefox ein html Dokument lokal speichert mit dieser Endung. mfg Beat -- Woran ich arbeite: [X-Torah](http://www.elcappuccino.ch/cgi/tok.pl?extern=1-pub-com3306-1) <°)))o>< ><o(((°>o-
<FilesMatch ".html$">
SetEnvIf Accept "application/xhtml+xml" xhtml=true
Header set Content-Type "application/xhtml+xml" env=xhtml
</FilesMatch>> Die Methode ist mir geläufig, erfasst aber nur jene browser, welche application/xhtml+xml senden, und missachtet, dass sie dabei einen üblen Wert senden. Natürlich erfasst es nur jene Browser, denn nur bei denen kann ich mir sicher sein, dass sie application/xhtml+xml auch verstehen. Was meinst du mit "üblen Wert"? > Weiter wird das hier auf .html Dokumente angewendet. Wir wissen, was geschieht, wenn man mit firefox ein html Dokument lokal speichert mit dieser Endung. FilesMatch enthält Direktiven, die auf Dateien wirken. Das muss nichts mit der Adresse der Ressource zu tun haben. Besonders hartgesottene Zeitgenossen verschicken natürlich echte HTML-4.01- und XHTML-1.0-Dokumente, je nach Request-Header. -- Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin. Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:|-
<FilesMatch ".html$">
SetEnvIf Accept "application/xhtml+xml" xhtml=true
Header set Content-Type "application/xhtml+xml" env=xhtml
</FilesMatch>> > Die Methode ist mir geläufig, erfasst aber nur jene browser, welche application/xhtml+xml senden, und missachtet, dass sie dabei einen üblen Wert senden. > Natürlich erfasst es nur jene Browser, denn nur bei denen kann ich mir sicher sein, dass sie application/xhtml+xml auch verstehen. Was meinst du mit "üblen Wert"? Ich meine damit den q value Du müsstest die Browser auf ihre Praxis hin kontrollieren. <http://www.webdevout.net/articles/beware-of-xhtml#content_negotiation> Es ist nur ein Punkt mehr, der permanenter Kontrolle bedarf. Darum bezweifle ich content-negotiation als ein wirklich hinreichend taugliches Konzept in dieser Problematik. mfg Beat -- ><o(((°> ><o(((°> <°)))o>< ><o(((°>o-
Ich meine damit den q value
Dieser Parameter gibt ja lediglich an, was der Browser lieber hätte, ich kann trotzdem etwas anderes anbieten.
Du müsstest die Browser auf ihre Praxis hin kontrollieren.
http://www.webdevout.net/articles/beware-of-xhtml#content_negotiation
Es ist nur ein Punkt mehr, der permanenter Kontrolle bedarf.Ich sehe da nichts, was meiner Methode wirklich entgegensteht. Safari und Konqueror kriegen text/html, weil sie application/xhtml+xml nicht explizit senden, aber das schadet ja nicht. Der Firefox 2 und drunter rendert Seiten langsamer, wenn sie als application/xhtml+xml gesendet werden, ärgerlich, aber kein Weltuntergang, zumal dessen Anteil sinkt und der von Firefox 3 steigt.
Darum bezweifle ich content-negotiation als ein wirklich hinreichend taugliches Konzept in dieser Problematik.
Es ist aber ein taugliches Konzept.
--
Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:|-
Hallo,
Firefox 2 und drunter rendert Seiten langsamer, wenn sie als application/xhtml+xml gesendet werden
Warum tut er das?
Mathias
-
Firefox 2 [...] langsam[...]
Warum tut er das?ich würde sagen "works as designed" - firefox ist prädestiniert dazu, langsam zu sein - wer einen schnellen browser mit gecko sucht, sollte sich k-meleon ansehen ;)
<vermutung art="schlecht gehaessig">xul ist ein furchtbar schlimmer ressourcenfresser - wenn der xml-parser schon damit beschäftigt ist, die benutzeroberfläche zu lesen, wird er für die eigentliche webseite nicht mehr viel übrig haben ;)</vermutung>-
Meine Firefoxe sind auch immer langsam. Aber was will man auch erwarten, wenn nach dem Parsen nochmal ein paar Erweiterungen über die Seite rutschen? ;-)
--
Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:|
-
-
Firefox 2 und drunter rendert Seiten langsamer, wenn sie als application/xhtml+xml gesendet werden
Warum tut er das?Warum er das tut, weiß ich nicht, gelesen habe ich es bei Firefox and other problems (ein Teil der Seite, von dem Beat einen anderen Teil verlinkt hat). Das Problem ist wohl, dass er erst parst (und auf Wohlgeformtheit prüft) und dann rendert, während bei der Tag-Soup-Variante gerendert wird, sobald der erste (zu rendernde) Sourcecode da ist.
P.S.: "Das Format Ihres Postings scheint unsauber zu sein (z. B. keine Zeilenumbrüche, keine Satzzeichen, alles klein geschrieben oder ähnliches). Solche Postings sind ungern gesehen, da sie oft schwer zu lesen sind. Sind Sie sicher, dass Sie so posten möchten?"
Würde ich jedesmal, wenn ich es sehe, 10 Cent kriegen, wäre ich reich.--
Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:|-
Hallo,
Das Problem ist wohl, dass er erst parst (und auf Wohlgeformtheit prüft) und dann rendert, während bei der Tag-Soup-Variante gerendert wird, sobald der erste (zu rendernde) Sourcecode da ist.
Ach so, klar. Danke.
Mathias
-
-
-
-
-
-
-
-
-
-
@@suit:
xhtml 1.0 als text/html hat gegenüber html 4.01 keinen nennenswerten vorteil, das ist ein hartes faktum
Nein, das ist Quatsch. Für Webautoren bringt XHTML 1.0 einige Vorteile.
Live long and prosper,
Gunnar--
Erwebsregel 208: Manchmal ist das einzige, was gefährlicher als eine Frage ist, eine Antwort.-
Nein, das ist Quatsch. Für Webautoren bringt XHTML 1.0 einige Vorteile.
vorteile, die man dank der mangelhaften unterstützung der browser nicht voll ausnutzen kann - es gibt zwar einige vorteile, das habe ich ja auch gesagt - aber xhtml als text/html bringt imo keine NENNENSWERTEN vorteile
-
Hallo,
Ich will weitere harte Facta hören!
aber xhtml als text/html bringt imo keine NENNENSWERTEN vorteile
Welche Vorteile bringt denn XHTML als appliation/xhtml+xml?
Mathias
-
@@suit:
Nein, das ist Quatsch. Für Webautoren bringt XHTML 1.0 einige Vorteile.
vorteile, die man dank der mangelhaften unterstützung der browser nicht voll ausnutzen kann
Ich hatte von Vorteilen für *Webautoren* gesprochen. Gern nochmal: für *Webautoren*. Was sollte der Browser eines Nutzers damit zu tun haben?
Live long and prosper,
Gunnar--
Erwebsregel 208: Manchmal ist das einzige, was gefährlicher als eine Frage ist, eine Antwort.-
Ich hatte von Vorteilen für *Webautoren* gesprochen. Gern nochmal: für *Webautoren*. Was sollte der Browser eines Nutzers damit zu tun haben?
welche vorteile hat man als webautor - ich meine vorteile, bei deinen man nicht 2 workarounds und eine ersatzvariante für alte browser braucht ;)
sprich vorteile im sinn von "arbeitserleichterung"
ich bin äusserst kundenorientiert - ein vorteil ist für mich nur ein vorteil, wenn er weniger arbeit bedeutet (= weniger kosten für den kunden) oder wenn er die benutzbarkeit erhöht (= ein vorteil für den kunden, weil der endkunde mehr freude mit der webseite hat)
-
@@suit:
welche vorteile hat man als webautor
http://forum.de.selfhtml.org/archiv/2006/9/t136260/#m885165, weitere Links in http://forum.de.selfhtml.org/archiv/2007/2/t147284/#m961973
Live long and prosper,
Gunnar--
Erwebsregel 208: Manchmal ist das einzige, was gefährlicher als eine Frage ist, eine Antwort.-
http://forum.de.selfhtml.org/archiv/2006/9/t136260/#m885165, weitere Links in http://forum.de.selfhtml.org/archiv/2007/2/t147284/#m961973
ok, verstehe - du meinst, autoren, die sich keine "komplizierten regeln" merken wollen oder können
wenn man syntaktisch richtiges html oder xhtml schreibt, spielt das keine rolle - das ist aber jetzt auch nicht wirklich kracher-feature welches die welt verbessert ;)
-
Hallo,
du meinst, autoren, die sich keine "komplizierten regeln" merken wollen oder können
wenn man syntaktisch richtiges html oder xhtml schreibt, spielt das keine rolleNein! Bitte lies Gunnars Postings nochmal. Man kann völlig korrektes HTML schreiben und es ist mitunter praxisuntauglich. Und dass HTML lasch bzgl. optionale Tags ist und dadurch Fehler schwer zu finden sind, hat auch wenig mit »komplizierten Regeln« zu tun, die man sich einfach so merken sollte. Die »Einfachheit« von XHTML bedeutet nicht nur, dass weniger Regeln existieren, sondern vor allem, dass diese konsequent sind.
Der Witz ist doch, dass sich niemand beim Schreiben von HTML dieser komplizierten Regeln bedient und die Möglichkeiten auseizt, sondern z.B. alle Tags explizit notiert. Also automatisch XHTML-ähnliche Syntax schreibt. Das gilt als guter Stil, ist aber kein technisches Erfordernis und deswegen ist es superschwer, Fehler zu finden, wenn man »aus Versehen« ein abseitiges HTML/SGML-Feature nutzt. XHTML verhindert genau dies, indem es die Möglichkeiten auf genau eine begrenzt, die Regel damit vereinfacht und Alternativen »verbietet«.
Dass du dich also so despektierlich über die als faul oder unfähig angenommenen Autoren äußerst, ist völlig fehl am Platze. Es wäre überhaupt nicht erstrebenswert, dass Webautoren obskure SGML-Regeln, HTML-Ausnahmen und -Alternativschreibweisen lernen. Kein Lehrbuch lehrt dies und ich würde es auch niemandem zumuten. Aber man kommt ab und zu mit ihnen in Konflikt und es ist in HTML schwer, einen guten Stil durchzuhalten. Denn die Tag-Soup-Parser der Browser sind fehlertolerant, HTML/SGML wiederum ist lax und inkonsequent und lässt praxisuntaugliche Schreibweisen als korrekt durchgehen.Mathias
-
Hallo,
du meinst, autoren, die sich keine "komplizierten regeln" merken wollen oder können
wenn man syntaktisch richtiges html oder xhtml schreibt, spielt das keine rolleNein! Bitte lies Gunnars Postings nochmal. Man kann völlig korrektes HTML schreiben und es ist mitunter praxisuntauglich. Und dass HTML lasch bzgl. optionale Tags ist und dadurch Fehler schwer zu finden sind, hat auch wenig mit »komplizierten Regeln« zu tun, die man sich einfach so merken sollte. Die »Einfachheit« von XHTML bedeutet nicht nur, dass weniger Regeln existieren, sondern vor allem, dass diese konsequent sind.
das ist mir klar - in sgml sind viele dinge möglich (OMITTAG und SHORTTAG im besonderen), die zwar valide sind, aber dennoch zu fehlern führen können, weils an der browserunterstützung fehlt - aber darauf wird man idr durch den validator hingewiesen und erhält ein warning ausgespruckt
Dass du dich also so despektierlich über die als faul oder unfähig angenommenen Autoren äußerst, ist völlig fehl am Platze.
das habe ich so auch nicht - ich verstehe deine argumentation - aber diese lässt sich auch auf andere bereiche projezieren - sauberer code ist essentiell wichtig - javascript ist, in vielen fällen mit den strichpunkten nicht so genau, soweit ich weiss nur erforderlich, wenn man mehrere dinge in einer zeile tut - dennoch ist es für mich selbstverständlich, dass ich am zeilenende einen strichpunkt setze
selbstverständlich ist es für mich auch, dass ich valides html 4.01 schreibe und alle elemente mit öffnenden und schließendem tag auszeichne (natürlich mit den üblichen ausnahmen) das schließende tag weglassen ist in den meisten fällen möglich und führt in den meisten browser auch zu keinen fehlern, aber es gehört dennoch zum guten stil, einfach ordentlichen und vor allem menschenlesbaren code zu schreiben
von der seite betrachtet ist xhtml natürlich besser, weil der autor quasi dazu gezwungen wird, ordentlichen code zu schreiben und gar keine potentiellen fehler machen kann - aber das betrachte ich eben auch nicht als "super feature" sondern quasi als selbstverständlichkeit
-
-
-
-
-
Nein, das ist Quatsch. Für Webautoren bringt XHTML 1.0 einige Vorteile.
vorteile, die man dank der mangelhaften unterstützung der browser nicht voll ausnutzen kann
Ich hatte von Vorteilen für *Webautoren* gesprochen. Gern nochmal: für *Webautoren*. Was sollte der Browser eines Nutzers damit zu tun haben?XHTML als XML validieren bringt mir als Autor derzeit keinen Vorteil, ganz im Gegenteil zu HTML oder XHTML als HTML.
mfg Beat
-
Hallo,
XHTML als XML validieren bringt mir als Autor derzeit keinen Vorteil, ganz im Gegenteil zu HTML oder XHTML als HTML.
Häh?
XHTML als HTML validieren? Häh? XHTML kann kein valides HTML sein. HTML stammt aus dem SGML-Universum und dessen SGML-Deklaration verunmöglicht XHTML-Syntax.
XHTML kann man nur als das validieren, was es ist, als XML. Und dann kann man es DTD-validieren oder Schema-validieren. Letzteres ermöglicht eine viel genauere Überprüfung der Standardkonformität, erstere kann nicht mal die XML-Konformität wirklich prüfen (zumindest, solange kein vernünftiger XML-Parser, sondern nur ein aufgebohrter SGML-Parser verwendet wird, wie beim W3C-Validator). Das bringt dem Autor durchaus einen Vorteil, weil HTML-Validierung viele Fehler nicht findet und SGML-Eigenheiten durchgehen lässt, die von verbreiteten Browsern nicht verstanden werden.Ich habe echt keine Lust, jede Woche dasselbe zu erzählen, also bitte: Lest das Archiv! Das Thema wurde hier schon fünftausend Mal durchgekaut und deine Schnellschüsse scheinen mir nichts als uninformiert zu sein.
Mathias
-
-
-
-
-
Hallo,
xhtml 1.0 als text/html hat gegenüber html 4.01 keinen nennenswerten vorteil
Argumente scheinen für dich genausowenig wie für Beat »nicht nennenswert«.
Auf dem Niveau lohnt es sich nicht zu diskutieren.Ma - Das ist ein Faktum - thias
-
Argumente scheinen für dich genausowenig wie für Beat »nicht nennenswert«.
Auf dem Niveau lohnt es sich nicht zu diskutieren.ich habe in einem anderen ast diese "nicht nennenswerten" vorteile schon beschrieben, da ich selbst darauf gekommen, bin, dass eine argumentationslose diskussion (auch wenns schon 100x durchgekaut wurde) zu nichts führt
es gibt ein paar coole dinge, die man mit einem wohlgeformten dokument anstellen kann eine flash-seite oder ein flash-menü oder sonstiges, welches sich die informationen aus dem dokument holt, in welchem es selbst eingebettet ist - das ist imho die optimallösung für "barrierefreie" flashinhalte
aber wie gesagt, das ist für mich kein signifikanter unterschied sonder eine kleine spielerei am rande
-
-
-
-
-
Hallo,
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr">Weiß nicht, warum, war aber so.
Du solltest nichts einfach so tun, ohne zu wissen, warum. ;) Da sind unerwartete Resultate vorprogrammiert.
Was für einen DOCTYPE hattest du denn vorher benutzt? Keinen?
Dieser sollte jedenfalls den standardkonformen Modus anschalten (Stichwort DOCTYPE-Switch).Jetzt hat sich nur leider (einheitlich in beiden Browsern) das Aussehen komplett verändert. Es scheint, als ob der die styles gar nicht mehr lesen kann.
Dann zeige uns die betreffende Seite mal. Stelle sie am besten onlineund verlinke sie hier. Ohne sich das genauer anzusehen, kann man nur spekulieren, woran es liegen könnte.
Vermutlich handelt es sich um einen Codefehler, der im standardkonformen Modus nicht mehr übersehen wird. HTML und CSS solltest du ohnehin mit den jeweiligen W3C-Validatoren auf Korrektheit prüfen.
Mathias
-
Jungens, ich brauche Eure Hilfe!!
Ich hab eine so schöne Internetseite gehabt. Nur leider zu spät erst den ********* Internet Explorer angemacht. Da ging natürlich null. Aber den Fehler hatte ich gefunden. Es mußte rein:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr">Also, gemeint ist "sich alles für den IE 7 (7.0.5730.13) kaputt machen" geht "einfacher":
<IRONIE>
Einfach im <head><script src="my.js" type="text/javascript" />statt
<script src="my.js" type="text/javascript"></script>und schon wird der Blick des Betrachters aufs (hoffentlich ansprechende) Hintergrundbild nicht mehr durch unnützen Content blockiert...
</IRONIE>;-)
*SCNR*
Grüsse
Solkar
-
Mahlzeit Peterchen,
Weiß nicht, warum, war aber so.
http://de.selfhtml.org/html/allgemein/grundgeruest.htm#dokumenttyp@title=Darum.
Jetzt hat sich nur leider (einheitlich in beiden Browsern) das Aussehen komplett verändert.
Sicher. Vorher war es nur Buchstabensalat - jetzt ist es mehr oder weniger valides (X)HTML.
MfG,
EKKi--
sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|