HTML ist doch richtiges Frickler Zeug.
-
AlleJahre schrieb:
Wenn man da mal ein bisschen mehr machen will, dann funktioniert es mal auf dem und mal auf dem Browser nicht. Können die nix vernünftiges machen.
HTML 3.x sollte überall gleich aussehen
byto schrieb:
denn die W3C Spezifikationen sind schon wohl definiert.
Ja, aber die sind eh gleich für den Schredder, da sie keine Akzeptanz in der Industrie finden. Was nützt einem der tollste Standard, wenn man niemanden findet, der ihn implementiert?
-
naja übertreiben brauchen wir es auch nicht. es ist zwar fakt, dass einige in ihrer eigenen Suppe rühren, dennoch stellt der w3c standard einen doch relativ brauchbaren standard darf.
ohne w3c müsstest du die Internetseite für den IE einemal in Basic (:D) und einmal für den Firefox in C++ schreiben
.Achja, :xmas1:
-
rüdiger schrieb:
Ja, aber die sind eh gleich für den Schredder, da sie keine Akzeptanz in der Industrie finden. Was nützt einem der tollste Standard, wenn man niemanden findet, der ihn implementiert?
Das ist ja wohl lächerlich. Mal davon abgesehen dass das W3C aus der Industrie besteht, kannst du nicht einfach einen Standard - hier offensichtlich HTML - nehmen und dann auf die Akzeptanz der gesamten Organisation schließen. Es gibt genug erfolgreiche Standards des W3Cs wie beispielsweise XML und XSLT um deine Aussage zu widerlegen. Aber mehr noch, jede Standardisierungsorganisation hat den einen oder anderen Standard, der nicht exakt umgesetzt wurde. Sind deshalb alle Standardisierungsorganisationen und Standards für den Schredder?
-
Grüß Euch,
ich bin gerade dabei eine - so finde ich - saubere Lösung umzusetzen:
XHTML 1.0 Strict je nach Accept-Header des Clients als text/html (für die Tagsuppen-Küchenmeister) und einmal als applkication/xhtml+xml per Apache's Content Negotiation. Dazu kommt natürlich noch ein Hack für's Box-Model.
Im großen und ganzen finde ich, dass das W3C mit XHTML zum ersten mal auf einem (annähernd
) richtigen Weg ist. Verschreit es bitte nicht 
Greetz, Swordfish
-
html ist kein pixelgenaues design, dafür war es auch nie gedacht. html gibt lediglich vor, dass es auf allen ausgabemedien "gleich" aussieht. das beinhaltet aber nur grundsätzliche formatierung, nicht etwa zeilenumbrüche oder dergleichen. der standard schreibt nicht vor, wie etwas auszusehen hat, er gibt lediglich vorgaben, wie ein tag zu interpretieren ist.
ob sich ein browser nun dazu entscheidet, <emph> kursiv dazustellen, zu unterstreichen oder womöglich in einer anderen farbe darzustellen, ist ihm grundsätzlich völlig selbst überlassen.
trotzdem haben sich die großen browserhersteller auf eine relativ einheitliche interpretation geeinigt.
-
thordk schrieb:
ob sich ein browser nun dazu entscheidet, <emph> kursiv dazustellen, zu unterstreichen oder womöglich in einer anderen farbe darzustellen, ist ihm grundsätzlich völlig selbst überlassen.
OMG, nein. Genau das soll sich (unter anderem) mit XHTML ja ändern. Nicht auf des Clients Gutdünken kommt es an, sondern auf die gewünschte (vom autor definierte) application von xml+xhtml.
Greetz, Swordfish
-
Naja, wenn Du ein Style für den entsprechenden Client hast, dann bestimmst Du ja die Ausgabe, aber falls nicht bzw. falls Dein Style im Client abgestellt wird, dann sollte der Browser bestimmen, wie's dargestellt wird. Bzw. meine ich mit Browser eher den Benutzer dessen. Der Benutzer sollte entscheiden, ob er z.B. <strong> fett, fett-unterstrichen, oder was auch immer haben will. Ebenso die Schriftgröße und alles andere.
-
Oder kurz gesagt liefert XHTML lediglich die logische Auszeichnung. Wie diese Auszeichnung dann optisch umgesetzt wird ist Sache des User-Agents und nur Sache dessen. Wird z.B. eine Stelle als "hervorgehoben" markiert, kann Browser A die Stelle fett schreiben, Browser B den Text rot färben und Screen-Reader C die Stelle mit besonders starker Betonung vorlesen. Dem Standard ist das wirklich egal, hier geht es nur um die Markierung der Stelle als "hervorgehoben".
Die wirkliche Gestaltungsmöglichkeiten kommen mit CSS ins Spiel. Damit kann man dann zwar und zum Glück keine pixelgenauen aber doch eindeutige optische Angaben definieren. Man arbeitet ja nicht umsonst mit XHTML und CSS
-
css ist schon pixelgenau - aber da microsoft browser überaus fehlerbehaftet sind, kann man das nicht umsetzen, da es sonst zu darstellungsfehlern kommt
-
Ja ok, da hast du schon recht und ich ein "merkwürdiges" Verständnis von pixelgenau. Selbstverständlich kann man Pixel-Angaben in CSS machen, aber die Pixel-Einheit ist bei CSS als eine relative Einheit definiert und keine absolute. Damit ist das, was ein Pixel bedeutet, immer relativ vom Medium abhängig. Dem Standard nach ist überhaupt nicht vorgeschrieben, dass "1 px" einem Bildpunkt entsprechen muss:
The suggested reference pixel is the visual angle of one pixel on a device with a pixel density of 90dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is about 0.0227 degrees.
Damit hat (dein) "pixelgenau" für mich nicht mehr den Absolutheitsanspruch den ich bei (meinem) "pixelgenau" eigentlich erwarte
-
imho müssen representationspixel != bildschirmpixel sein
das würde ja lediglich einer skalierung entsprechen
-
Deshalb arbeitet man ja auch mit Punkten und nicht mit Pixeln. Und ein Punkt ist 1/72 Zoll - also unabhängig von der Bildschirmauflösung. Nur ein bestimmtes OS machts mal wieder falsch
-
r0nny schrieb:
css ist schon pixelgenau - aber da microsoft browser überaus fehlerbehaftet sind, kann man das nicht umsetzen, da es sonst zu darstellungsfehlern kommt
Also ich versuche immer meine seiten in mehreren Browsern zu testen sowie in verschiedenen Auflösungen.
Aber allen kann man es nicht gleich machen,denn dann würde eine Seite nie fertig werden, es sei denn man macht eine Seite ohne irgendwelche Formatierungen.Dennoch versucht W3C einen Standard zu schaffen damit die Browserprogrammierer eventuell auch alles so umsetzen.
Und wie ALLE können nur unser bestes dafür tun, und Seiten so erstellen, damit es zu einem Standard wird.
-
Amen.
Aber an sich stimmt es schon ...
