[XHTML] Was kann ich noch tun um Valid zu werden?
-
Mal sehen, einige davon kenn ich, mit einigen davon kann ich aber auch nichts anfangen:
SideWinder schrieb:
Line 43, column 88: there is no attribute "TARGET" (explain...). ...ernes/extnews.php?clan=19927" target="text"> ^
Du versuchst doch nicht etwa, eine Frame-Seite zu erstellen? So etwas geht mit XHTML1.1 (entspricht HTML strict) nicht.
Line 221, column 105: cannot generate system identifier for general entity "offset" ...ervice3.de/onlinecount.php?id=c22827&offset=5&style=1" type="text/js">Ihr Bro ^
Versuchs mal mit & statt &
21: <bodY>
Ist das Absicht?
-
SideWinder schrieb:
146: <a href="http://dynclan.net/dynclan/members/index.php?clan=19927" target="_blank">
Die Entscheidung, ob ein neues Fenster aufgemacht werden soll, gebuehrt einzig und allein dem Besucher der Seite!
-
1. Nein ich habe nicht vor eine Frameseite zu bauen benötige aber einen IFRAME auf der Seite.
Das läuft so ab: Das Aussehen und die Daten von bestimmten Dingen (zB Memberliste) werden nämlich im Dynclan gespeichert (www.dynclan.net). Von dort kann ich die Seite fix und fertig abrufen (anpassen kann ich sie auch dort). Nur sehe ich da keinen anderen weg außer einen Inline Frame.
2. Das mit dem _target ist mir schon klar. Nur leider ist es derzeit so, dass ich zB um in den IFRAME verlinken zu können ein target brauche! Die "_blank"-Targets kann man allerdings raus geben stimmt.
3. body habe ich geändert.
@echter Troll: Nein geht nicht, da wie bereits gesagt, die Homepage nur offline existiert.
Da sind aber nun immer noch genügend Fehler - zB diese komischen Fehler mit dem "False Charater Data".
MfG SideWinder
-
So ich habe nun alle Fehler beseitigt, außer:
- Dem komischen />-Fehler nach Meta-Tags mit "http-equiv"-Angabe -> gehört da kein abschließendes Tag?
- IFRAME-Fehler
- Beim JavaScript-Counter fehlt ihm type als Attribut und dafür ist language zuviel. Allerdings sobald ich type angebe zeigt er es nicht mehr an. Was muss ich da für ein JavaScript angeben?
- Edit: Auch die target-Fehler beim Verlinken in den IFRAME sind natürlich noch da.
Welche XHTML-Version unterstützt Frames? Auf der Homepage w3.org habe ich nur bei HTML 4.01 eine Frameset-Version gefunden, bei XHTML 1.1 allerdings nichts derartiges...
MfG SideWinder
-
XHTML 1.0 Transitional. Bei 1.1 gibts nur strict, und demzufolge auch keine Frames.
-
Habe zwar keine Ahnung warum die unbedingt jetzt keine Inline-Frames anbieten, aber mir egal. Werde ich eben eine Versionsnummer zurückgehen.
MfG SideWinder
-
SideWinder schrieb:
Habe zwar keine Ahnung warum die unbedingt jetzt keine Inline-Frames anbieten
weil frames boese sind?
iframes sind nicht so boese wie echte frames, aber nur weil etwas nur n bisschen boese ist, ist es trotzdem boese.
tu dir einen gefallen und verwende keine frames.
-
Alternativ kann man ganz schnell ein Script schreiben, was die andere Seite einliest, den Header und "Footer" wegschnippelt und dann in dem gewünschten Dokument ausgibt.
-
Hallo? Es gibt aber genügend Probleme in denen Inline-Frames nützlich sind! Erstens benötige ich wie gesagt die Seite von Dynclan die mir direkt HTML-Code zurückliefert und zweitens muss ich den auch noch in das DIV in der Mitte bekommen.
Also brauch ich nunmal target (weil der User will standardmäßig sicher nicht, dass es in einem neuen Fenster geöffnet wird).
Also brauch ich nunmal einen Inline-Frame damit ich dort den Inhalt der anderen Seite anzeigen kann.
@Loggy: Wie kann man in PHP den Code dieser Seite in einen String bekommen? Wie rufe ich da die Seite auf damit der Code als String zurückgeliefert wird?
BTW: Der Validator ist mir ab jetzt egal. Statt einen tollen guten Standard zu schaffen haben es die vom W3-Team geschafft, dass ich nun mehr Probleme habe als vorher :(.
MfG SideWinder
-
inhalt in einen string bekommen geht per POST anfrage an den anderen server...
schreib DOCTYPE gross
das problem liegt daran, dass du keinen validen doctype angibst, und da haengt der parser dann irgendwann...
zugegeben, ist nicht gut vom w3c validator - aber mit folgendem doctype ist alles OK:<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
btw:
tables sind nicht zum layouten da!!und nur weil du etwas falsch machst, heisst es noch lange nicht das w3c, der xhtml standard, oder sonstwer schlecht ist.
-
Okay DOCTYPE groß.
Shade Of Mine schrieb:
btw:
tables sind nicht zum layouten da!!und nur weil du etwas falsch machst, heisst es noch lange nicht das w3c, der xhtml standard, oder sonstwer schlecht ist.
Ein Rufzeichen pro Satz ist völlig ausreichend.
Na gut am Rand hätte man DIV nehmen sollen, werde ich ändern.
Ich habe nicht behauptet, dass die schlecht sind. Aber seit ich versuche standardkonforme Seiten zu schreiben brauch ich 3 Mal soviel Zeit für eine Seite und habe einen ganzen Haufen Probleme die ich ohne nicht hätte.
ZB die Fehler die gar nicht wegzubekommen sind: http://validator.w3.org/check?uri=www.sidewindershome.net%2Fnew%2Findex.php(vielleicht sind sie ja dann mit großem DOCTYPE weg).
Edit: Direkt den Link zum Validator eingefügt statt einfach nur der normalen Adresse.
Und was ist das Ergebnis? Alle Browser zeigen es genauso unterschiedlich an wie vorher und die Mühe war umsonst - leider :(.
MfG SideWinder
-
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. hf
MfG 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.