[XHTML] Was kann ich noch tun um Valid zu werden?
-
So nur noch IFRAME und JavaScript. Seit dem richtigen großen DOCTYPE (thx, dachte alle Tags gehören klein geschrieben) ist auch der komische "False Character Data />" bei den META-http-equiv-Tags weg.
Ist es möglich standardkonform ein JavaScript einzubinden?
MfG SideWinder
-
Document-Type auf 1.0 Transitional gestellt und somit die IFRAME wie auch die target="text"-Fehler weg.
Den einzigen Fehler den ich noch habe: Ich habe beim JavaScript type="" nicht angegeben.
Welchen Typ hat ein Javascript?
Ergebnistyp: text/html -> nein
Aufrufende Page: text/php -> nein
JavaScript selbst: application/x-javascript -> neinHilfe
MfG SideWinder
-
text/javascript
-
Danke. Endlich valid
MfG SideWinder
-
SideWinder schrieb:
Und was ist das Ergebnis? Alle Browser zeigen es genauso unterschiedlich an wie vorher und die Mühe war umsonst - leider :(.
wann lernen es die leute?
es soll nicht überall gleich aussehen, sondern überall GUT.schon mal eine nicht valide und eine valide seite auf einem safari 0.6 getestet?
schon mal eine nicht valide seite mit handhelds gerendert?
schon mal eine nicht valide seite mit einem sprachbrowser besucht?niemand hat je behauptet webdesign wäre einfach...
es gibt neben dem standard noch einige kompatibilitaets sachen zu beachten - klar, am anfang ist es schwer, aber wenn man dann mal n paar webseiten erstellt hat, läuft es recht gut.btw:
etwas falsch machen ist immer einfacher als etwas richtig machen.und hau die tabellen und das iframe raus!!!
(2 rufzeichen waren wohl zuwenig)
-
Naja, Shade, valider (X)HTML Code ist noch kein Garant dafür, dass es auf allen gut aussieht bzw. angezeigt werden kann. Es ist nur ein wichtiger Baustein. Man kann aber trotzdem noch eine Menge falsch machen.
-
Es sieht aber nicht überall GUT aus - da liegt ja meistens das Problem. Außerdem wäre mir das ja noch halbwegs egal, aber:
Ich erstelle ein Produkt A das könnte ich in B Zeit erledigen (allerdings nicht 100% am Standard) und in C=2B Zeit erledigen (dafür Standard). Gut, Standard ist immer gut - außerdem wird es dann richtig angezeigt - Fehlanzeige: Man kann Fehler machen und es ist trotzdem das gleiche Ergebnis zu bewundern. Was soll mich dazu bewegen doppelt soviel Zeit daür zu benützen? Die "Valid XHTML 1.0"-Grafik? Wohl kaum...
btw:
etwas falsch machen ist immer einfacher als etwas richtig machen.Klar
und hau die tabellen und das iframe raus!!!
(2 rufzeichen waren wohl zuwenig)Die Tabellen sind bereits raus
. Allerdings kann ich den IFRAME nur rausmachen wenn du mir zeigst wie das ohne PHP funktioniert. hfMfG SideWinder
-
BTW: Der IFRAME wird vom Validator bei XHTML 1.0 Transitional ohne Probleme angenommen. Scheint also standardisiert zu sein...
Jaja, Tabellen sind auch standardisiert und sollen nicht zum Layout verwendet werden (deshalb weg damit und falsch) aber wofür könnte man einen IFRAME sonst RICHTIG verwenden?
Gar nicht? Was macht er dann im Standard?
MfG SideWinder
-
SideWinder schrieb:
Ich erstelle ein Produkt A das könnte ich in B Zeit erledigen (allerdings nicht 100% am Standard) und in C=2B Zeit erledigen (dafür Standard). Gut, Standard ist immer gut - außerdem wird es dann richtig angezeigt - Fehlanzeige: Man kann Fehler machen und es ist trotzdem das gleiche Ergebnis zu bewundern. Was soll mich dazu bewegen doppelt soviel Zeit daür zu benützen? Die "Valid XHTML 1.0"-Grafik? Wohl kaum...
damit die seite auch auf handhelds, sprachbrowsern, blinden-browser, textbrowsern, alten-browsern, etc. auch noch laeuft?
verdammt, sowas nervt!
ja, wozu soll man denn Standard C++ verwenden, wenn ich mit #include<conio.h> und clrscr() doch ganz gut fahre?
Weil irgendwann der punkt kommt, wo du deinen eingeschraenkten sichtbereich verlassen musst -> du musst den code auf linux portieren -> und zack, es haengt hinten und vorne.
das selbe bei webdesign:
du siehst nur IE, Opera und Mozilla. Vielleicht auch noch Netscape, aber das wars schon.
was ist mit Mac (IE, Netscape, Camino, SAFARI), oder Linux (Konqueror) oder anderen ausgefallenen sachen?ich kann ein lied davon singen wieviel wochen arbeit du dann rein steckst bis die seite auch mit ner SAFARI Beta laeuft, nur weil jemand zu faul war 10% mehr zeit zu investieren.
weisst du welche probleme es da geben kann? Opera, Mozilla, Netscape und IE sind extrem fehlertolerant - da kannst du den groessten mist bauen.
aber warte nur bis das auf ner SAFARI Beta laufen muss, oder jemand die seite auf einem handheld betrachten will -> dann ists aus und vorbei. dann musst du grosse teile neu implementieren -> zeit aufwand steigt ins unermessliche.nachtraegliche aenderungen kosten am meisten - also lieber von vornherein alles richtig bauen!
Die Tabellen sind bereits raus
. Allerdings kann ich den IFRAME nur rausmachen wenn du mir zeigst wie das ohne PHP funktioniert.ohne Server Side Script garnicht.
wozu brauchst du dass? ist ein eigenes fenster dafuer vielleicht besser?iframe gibt es im strict modus nicht - sie sind vielleicht nicht sinnlos, schaden aber mehr als sie bringen...
bevor du rummaulst wie schwierig das alles ist:
hey: du hast bis jetzt nur versucht die seite standard konform zu machen - und jetzt schaus dir auf nem Mac Browser an - was machen die mit iframes? (teilweise schlimm - deswegen haben wir den Mac browsern die iframes weggenommen, die bekommen echte frames von uns, damit es vernuenftig aussieht).aber es gibt noch andere schen zu beachten. standard konform zu sein ist der erste schritt: dieser bedeutet lediglich: schnelleres parsen deiner seite (kann bei grossen seiten extrem vorteilhaft sein und es gibt fast keine parser fehler -> kein undefiniertes verhalten)
weiters legt man damit den grundstein um auf andere medien auszuweiten.
aber das visuelle medium ist damit noch nicht 100% fertig -> testen, testen, testen.wenn du jetzt sagst: puh, ist das schwer, dann denk daran: webdesign firmen leben davon soetwas zu verkaufen, wenn es einfach waere, waere es kein grosser markt.
es irgendwie hin 'nudeln' kann jeder, es richtig machen ist arbeit.
-
wenn du dich fragst, was ich mit undefinierten verhalten meine:
siehe dein vorherigen problem "character data not allowed here"-> parser error mit undefiniertem verhalten.
ein browser haette jetzt zB die meta-tags nicht parsen koennen und er haette zB den zeichensatz ignoriert (oder stell dir mal vor er haette das stylesheet uebersprungen)
-
Immer diese alternativen Möglichkeiten meine Seite anzuzeigen...
ja, wozu soll man denn Standard C++ verwenden, wenn ich mit #include<conio.h> und clrscr() doch ganz gut fahre?
Weil irgendwann der punkt kommt, wo du deinen eingeschraenkten sichtbereich verlassen musst -> du musst den code auf linux portieren -> und zack, es haengt hinten und vorne.Warum man Standard C++ verwenden soll? Weil es portabler ist, vor allem wenn es ihne die conio auskommen kann. Aber wenn ich nicht ohne auskomme muss ich auch die windows.h, conio.h verwenden. Und so muss ich diesmal auch Inline Frames verwenden (wobei ich sogar denke, dass ich diesmal genau den Einsatzzewck von Inlineframes erwischt habe...).
ich kann ein lied davon singen wieviel wochen arbeit du dann rein steckst bis die seite auch mit ner SAFARI Beta laeuft, nur weil jemand zu faul war 10% mehr zeit zu investieren.
Nimmt SAFARI Beta nur Standard oder macht der selbst da noch dumm rum? Ein Browser muss auch etwas fehlertolerant sein. Was bringt mir ein Browser mit dem ich 80% der Seiten nicht betrachten kann weil sie nicht Standard sind - das ist ja sinnlos.
Aber im großen und ganzen hab ichs jetzt verstanden ;). Auch wenn ich nicht verstehe warum die IFRAMEs so schlecht sein sollen (außer dem Mac-Problem - aber was kann ich dafür wenn die keinen Standard unterstützen *tztztz* das erinnert mich wieder an ein anderes Thema...).
Ich werds ja eh versuchen alles standardkonform zu machen ;). Nur halt mit XHTML 1.0 Transitional und diesmal nicht mit XHTML 1.1 Strict.
MfG SideWinder
-
Ein Browser muss auch etwas fehlertolerant sein.
Muss er das? Ich weiß, dass der Quirks Mode (also der, der Fehler ausbügeln soll) im Gecko mitlerweile 80% der Größe ausmacht. Die genaue Größe von Gecko kenne ich nicht, sie wird aber weit über ein MB liegen. Nun gibt es aber Systeme, die nicht ganz so verschwenderisch mit Speicherplatz umgehen können, wie der PC. Mein Handy hat z.B. nur 350 kb Speicher. Damit kann man nun auch keine normalen Webseiten betrachten, aber die neuen mit den hochauflösenden Farbdisplays könnten dazu durchaus in der Lage sein, aber diese Systeme werden sicher keinen Platz und keine Rechenresourcen für eine Fehlerkorrektur haben.
Es kann doch nicht sein, dass man für das reine betrachten einer Webseite schon einen P2 400 MHz braucht.
-
Loggy schrieb:
Ein Browser muss auch etwas fehlertolerant sein.
Muss er das? Ich weiß, dass der Quirks Mode (also der, der Fehler ausbügeln soll) im Gecko mitlerweile 80% der Größe ausmacht. Die genaue Größe von Gecko kenne ich nicht, sie wird aber weit über ein MB liegen. Nun gibt es aber Systeme, die nicht ganz so verschwenderisch mit Speicherplatz umgehen können, wie der PC. Mein Handy hat z.B. nur 350 kb Speicher. Damit kann man nun auch keine normalen Webseiten betrachten, aber die neuen mit den hochauflösenden Farbdisplays könnten dazu durchaus in der Lage sein, aber diese Systeme werden sicher keinen Platz und keine Rechenresourcen für eine Fehlerkorrektur haben.
Es kann doch nicht sein, dass man für das reine betrachten einer Webseite schon einen P2 400 MHz braucht.
Nein aber 1MB Speicherplatz ;).
Naja also mit Handys kann man ja bisher nur WAP-Seiten betrachten (wobei ich verstehe, dass die dann natürlich absolut standardkonform sein müssen). Sobald hier auch HTML angeoten wird, wird der Speicherplatz auch schon etwas größer sein ;).
MfG SideWinder
-
ein browser muss nicht fehlertolerant sein.
wie ich schon gesagt habe: im quirks modus ist alles undefiniertes verhalten.
zB wollte der IE am Mac eine tabelle nicht anzeigen, weil eine form kein action attribut hatte...
das ist halt undefiniertes verhalten.
weiss du wieviel schneller es ist im non-quirks mode zu rendern?
1MB speicherplatz reicht aber nur fuer den compliant parser aber sicher nicht fuer den quirks mode.