nicht angemeldet
Gründe - Code auf 4.01 Strict-Niveau zu bringen
Hy,
für uns Spezies mag die Frage, warum eine Seite (mindestens) nach Html 4.01 Strict codiert sein sollte, einfach zu beantwortensein - Stichwort "wohlgeformt", Stichwort "browserübergreifend gleiche Darstellung" usw.
und überhaupt: der Ehrgeiz ...
Andererseits werden sehr viele Seiten gerade aus Kompatibilitätsgründen auf Transitional-Niveau belassen ---
Welche Argumente würdet Ihr bei einem Kunden anbringen, eine bestehende Transitional-Seite (gegen Bares natürlich) auf Strict-Niveau zu bringen ... ich höre da oft den Satz: "ist mir egal, ob die Sache standardkonform ist, Hauptsache es funktioniert und ist günstig."
Ich helfe mir da gelegentlich mit der Notlüge, dass die Browser missbilligte Tags nicht mehr sehr lange unterstützen werden ...
Wie verfahrt Ihr in derartigen Fällen ?
Mit Grüßen Rolf
-
Hallo!
für uns Spezies mag die Frage, warum eine Seite (mindestens) nach Html 4.01 Strict codiert sein sollte, einfach zu beantwortensein - Stichwort "wohlgeformt", Stichwort "browserübergreifend gleiche Darstellung" usw.
Wohlgeformt ist IMHO XHTML, aber nicht HTML:
und überhaupt: der Ehrgeiz ...
Andererseits werden sehr viele Seiten gerade aus Kompatibilitätsgründen auf Transitional-Niveau belassen ---
Nicht aus Kompatibilitätsgründen, sondern aus Kostengründen. Die Seite läuft doch, wieso also umstellen.
Welche Argumente würdet Ihr bei einem Kunden anbringen, eine bestehende Transitional-Seite (gegen Bares natürlich) auf Strict-Niveau zu bringen ... ich höre da oft den Satz: "ist mir egal, ob die Sache standardkonform ist, Hauptsache es funktioniert und ist günstig."
Ich als Kunde würde das auch sagen! Er hat doch schon für die Seite bezahlt, also wieso soll er noch einmal bezahlen.
Ich helfe mir da gelegentlich mit der Notlüge, dass die Browser missbilligte Tags nicht mehr sehr lange unterstützen werden ...
Völliger Quatsch. Der fragt bei einem anderem Fachmann nach, der ihm dann sagen wird, dass "missbilligte Tags" bis zum jüngsten Gericht unterstützt werden. Dann wird er auch noch sagen, dass es egal ist ob eine Webseite strict oder transitional ist, Hauptsache sie ist valide.
André Laugks
--
Die Frau geht, die Hilti bleibt! -
Tachchen!
Das Argument für "strict" ist IMHO die Anzeigesicherheit bei CSS-Layouts.
Dieses Argument wird aus meiner Sicht nicht nur hinfällig, sondern ins
Gegenteil verkehrt, wenn man sich an Tabellenlayouts versucht/versuchen muss.
_Dort_ liegt aus meiner Sicht die Anzeigesicherheit paradoxerweise eher im
Bereich transitional.Darum würde ich mich auch von grundsätzlichen Argumentationen pro und contra
"strict" distanzieren und die Argumentation eher auf das Feld "CSS-Layouts"
lenken ... und dort dann ganz unzweifelhaft Strict-Doctypes bevorzugen.Gruß
Die schwarze Piste
-
Hallo,
Ich helfe mir da gelegentlich mit der Notlüge, dass die Browser missbilligte Tags nicht mehr sehr lange unterstützen werden ...
Wie verfahrt Ihr in derartigen Fällen ?
sehr clever, dem Kunden was aufschwätzen, was er gar nicht braucht.
wenn du damit glücklich wirst.gruss
--
no strict;
no warnings;
Der natürliche Feind der Festplatte ist der Teppich, der sich gerne mal elektrisch aufläd und der Festplatte eine wischt.
Kluge Leute sind auch nur Menschen. -
Hi,
ich würde kein Geld exta für Umstellung verlangen, bzw. keine Umstellung vornehmen, wenn der Kunde es nicht ausdrücklich wünscht, bzw. es keine Schwierigkeiten mit der aktuellen Version gibt.
Bei einer Neugestaltung, bzw. Relaunch, sieht das schon anders aus. Da sowieso eine Überarbeitung ansteht, kann man dem sauberen Quellcode gleich mitverkaufen, bzw. berücksichtigen...
MfG
Danny-
habe d'ehre
Bei einer Neugestaltung, bzw. Relaunch, sieht das schon anders aus. Da sowieso eine Überarbeitung ansteht, kann man dem sauberen Quellcode gleich mitverkaufen, bzw. berücksichtigen...
Fuer Dich ist sauberer, fehlerfreier Code ein Mehrwert den Du Dir vergueten laesst?
man liest sich
Wilhelm-
So direkt war das nicht gemeint.
Naja, es kommt darauf an. Eine nahezu perfekt durchgestylte, gut benutztbare Seite mit validem Code ist sicherlich mehr Wert als irgend ein wild zusammengeschustertes WYSIWYG-Produkt, das von Browsern nur aufgrund der hohen Fehlertoleranz dargestellt wird und evtl. gar nicht mehr funktioniert, falls z.B. ein Plugin fehlt...
Wenn man das dann dem Kunden gut erläutert und auf Vor/Nachteile aufmerksam macht, warum dann nicht ggf. extra vergüten lassen, falls der Kunde die "saubere" Variante bevorzugt?
Gleiches gilt für voll barrierefreie Seiten, z.B. für öffentliche Einrichtungen. Handarbeit vom Profi hat eben seinen Preis, wo ist das Problem?
MfG
Danny-
hi,
Wenn man das dann dem Kunden gut erläutert und auf Vor/Nachteile aufmerksam macht, warum dann nicht ggf. extra vergüten lassen, falls der Kunde die "saubere" Variante bevorzugt?
wenn das "saubere coden" doch eh als reines nebenprodukt deiner arbeit abfällt - warum dann dafür extra kassieren wollen?
Handarbeit vom Profi hat eben seinen Preis
den preis vom profi? oder _ihren_?
*scnr*gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
Hi,
wenn das "saubere coden" doch eh als reines nebenprodukt deiner arbeit abfällt - warum dann dafür extra kassieren wollen?
Nein, es fällt leider nicht immer autom. als "Nebenprodukt" ab. Schön wär's...
Weil z.B. immer öfter CMS verwendet werden sollen/müssen und deren Plugins nicht unbedingt standardkonform sind, bzw. nicht solchen Code erzeugen. Um eine Out-Of-The-Box-Funktionalität des CMS dann "sauber" umzustricken, ist oft viel Aufwand nötig, weshalb ggf. extra kassiert werden _muß_, sofern z.B. bei einer öffentlichen Einrichtung einwandfreier Code und Barrierefreiheit gefordert und ein best. CMS bevorzugt wird...
den preis vom profi? oder _ihren_?
Ihren... ;)
MfG
Danny
-
-
habe d'ehre
Gleiches gilt für voll barrierefreie Seiten, z.B. für öffentliche Einrichtungen. Handarbeit vom Profi hat eben seinen Preis, wo ist das Problem?
Ich kommunizierte kein Problem, ich stellte nur eine Frage.
man liest sich
Wilhelm
-
-
-
-
Moin!
für uns Spezies mag die Frage, warum eine Seite (mindestens) nach Html 4.01 Strict codiert sein sollte, einfach zu beantwortensein - Stichwort "wohlgeformt", Stichwort "browserübergreifend gleiche Darstellung" usw.
Nein. Diese Antworten sind mit der gestellten Frage nicht verbunden.
HTML kann genausogut nach 4.01 transitional "wohlgeformt" sein, und es bietet auch problemlos browserübergreifend dieselbe "gleiche Darstellung", wie 4.01 strict.
und überhaupt: der Ehrgeiz ...
In deinem Fall würde ich behaupten, dass ausschließlich Ehrgeiz im Spiel ist.
Andererseits werden sehr viele Seiten gerade aus Kompatibilitätsgründen auf Transitional-Niveau belassen ---
Transitional IST NICHT BÖSE. Unvalide Seiten sind tendentiell böse, aber wenn eine Seite bewußt transitional benutzt und validiert, ist alles bestens.
Welche Argumente würdet Ihr bei einem Kunden anbringen, eine bestehende Transitional-Seite (gegen Bares natürlich) auf Strict-Niveau zu bringen ... ich höre da oft den Satz: "ist mir egal, ob die Sache standardkonform ist, Hauptsache es funktioniert und ist günstig."
Den Kunden interessiert es auch nicht, welche Technik dahintersteht und ob irgendeine andere Technik minimal bessere Ergebnisse bringt, wenn er durch diese besseren Ergebnisse keinen Vorteil hat.
Und Fakt ist, dass er durch den Austausch von Transitional nach Strict keinerlei Vorteil hat, weil das Resultat sich durch 0,0% Darstellungsunterschied auszeichnet.
Ich helfe mir da gelegentlich mit der Notlüge, dass die Browser missbilligte Tags nicht mehr sehr lange unterstützen werden ...
Wenn du lügen mußt, um deinen Kunden das Geld aus der Tasche zu ziehen, dann sollten deine Kunden mal ihre Geschäftsbasis mit dir überprüfen. Kann sein, dass du demnächst weniger Kunden hast.
Wie verfahrt Ihr in derartigen Fällen ?
Eine Webseite nur des Zweckes willen von Transitional auf Strict oder von HTML auf XHTML umzustellen bringt dem Kunden nichts, sondern kostet ihn nur.
Sowas lohnt sich nur, wenn man die Seiten ohnehin im Rahmen eines Relaunches komplett überarbeitet.
Folglich solltest du deinen Kunden lieber einen Relaunch verkaufen. Dabei kann man nämlich noch viele andere tolle Gimmicks mit einfließen lassen, die den Preis (und nur darum scheint es dir ja zu gehen) jeweils nochmal ein wenig nach oben treiben. Wie gesagt: Den Kunden interessiert die Technik nicht, er will nur, dass es funktioniert. Und solange es bei ihm alles funktioniert, ist er nicht gewillt, den Ehrgeiz eines Webworkers mit viel Geld teuer zu bezahlen, davon aber keinerlei Nutzen zu haben.
- Sven Rautenberg
-
Hy,
stellvertretend auch für die anderen Reaktionen:
NATÜRLICH - eine Umstellung von Transitional auf Strict macht (wenn überhaupt) nur im Rahmen eines Relaunches und nicht als eigenständige Aktion Sinn - war mir so selbstverständlich, dass ich diesen Punkt gar nicht erst erwähnt habe!
Trotzdem muss ich doch noch mal nachfragen: wenn es denn praktisch egal ist - so der Haupttenor der Antworten - Transitional oder Strict zu codieren(Hauptsache valide!)- warum dann überhaupt Strict codieren - warum soll ich dann bei neuen Projekten nicht bei Transitional bleiben.
Und hier beissen sich einige Antworten doch ein bischen in den Schwanz, oder?
Mfg Rolf
P.S. Wer sagt, dass Browser bis in alle Ewigkeiten missbilligte Dags unterstützen ? Wissen oder Vermutung ?
-
Hi,
P.S. Wer sagt, dass Browser bis in alle Ewigkeiten missbilligte Dags unterstützen ? Wissen oder Vermutung ?
Eine einfache Schlußfolgerung:
1. Es gibt zahlreiche HTML-Render-Engines - auch als Open Source.
2. HTML wird nicht mehr weiterentwickelt.
3. Selbige Engines lassen sich für HTML-Dokumente also bis zum Sanktnimmerleinstag verwenden.Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Hallo,
- Selbige Engines lassen sich für HTML-Dokumente also bis zum Sanktnimmerleinstag verwenden.
Das setzt voraus, dass die Engines auch gewartet werden; rechtfertigt die Anzahl der Seiten das nicht mehr, wird *gerade* bei OpenSource-Projekten der Code irgendwann rausfliegen - wenn sich naemlich niemand mehr findet, der vorhandene Fehler beseitigt oder der den Code bei Aenderungen der internen Schnittstellen anpasst.
Gruss
Thomas-
Hi there,
- Selbige Engines lassen sich für HTML-Dokumente also bis zum Sanktnimmerleinstag verwenden.
Das setzt voraus, dass die Engines auch gewartet werden; rechtfertigt die Anzahl der Seiten das nicht mehr, wird *gerade* bei OpenSource-Projekten der Code irgendwann rausfliegen - wenn sich naemlich niemand mehr findet, der vorhandene Fehler beseitigt oder der den Code bei Aenderungen der internen Schnittstellen anpasst.
Naja, ich denke, die Dramatik hält sich in Grenzen; es ging ja um html, da hast Du ja nicht wirklich ein Schnittstellenproblem, ausserdem, wer sagt, daß ein stricte Seiten davon nicht betroffen sein können? Darum ging's ja ursprünglich...
-
Hallo,
Naja, ich denke, die Dramatik hält sich in Grenzen; es ging ja um html, da hast Du ja nicht wirklich ein Schnittstellenproblem, ausserdem, wer sagt, daß ein stricte Seiten davon nicht betroffen sein können? Darum ging's ja ursprünglich...
Klar wird das auch 'stricte' Seiten betreffen - aber da ist die Motivation eines Entwicklers wohl um einiges hoeher. Und die Grenzen der Dramatik sind schnell erreicht - gibt's einen Browser, der heute HTML 3.2 vollstaendig unterstuetzt?
Kuemmert das noch irgendjemanden?Gruss
Thomas-
Hi,
Und die Grenzen der Dramatik sind schnell erreicht - gibt's einen Browser, der heute HTML 3.2 vollstaendig unterstuetzt?
Gibt es einen "HTML-4-Browser", der das nicht tut?
Und wird man, wenn HTML 3.2 unterstützt wird, jemals noch etwas an der 3.2-Unterstützung ändern müssen?
Gibt es gängige Browser, die wirklich und vollkommen HTML 4.01 strict unterstützen? Bzw. gibt es einen Browser, der CSS 1 und/oder CSS 2 vollständig unterstützt?
Kuemmert das noch irgendjemanden?
Vermutlich jeden HTML-Autor, der mit Dreamweaver & Co. arbeitet. >;-> (SCNR)
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Hallo,
Gibt es gängige Browser, die wirklich und vollkommen HTML 4.01 strict unterstützen? Bzw. gibt es einen Browser, der CSS 1 und/oder CSS 2 vollständig unterstützt?
Bei CSS1 bin ich mir nicht sicher, bei allen anderen lautet die Antwort natuerlich nein. Aber wenn Du an einem Browser arbeitest: beseitigst Du noch Fehler in der HTML 3.2 Implementierung? Implementierst Du noch fehlende Sachen, die in HTML 4 nicht mehr drin sind?
Gruss
Thomas-
Hi,
Bei CSS1 bin ich mir nicht sicher,
IIRC: Selbst das nicht.
Aber wenn Du an einem Browser arbeitest: beseitigst Du noch Fehler in der HTML 3.2 Implementierung? Implementierst Du noch fehlende Sachen, die in HTML 4 nicht mehr drin sind?
Angesichts der geringen Seitenzahl in XHTML 1.0/"echtem" HTML 4.01 (und deren prinzipielle Nähe zu HTML 4) sowie der weiten Verbreitung von "HTML-3.2-Elementen", würde es mich sehr "verwundern", wenn dies nicht geschehen würde. =:-o (wie war das noch? Nur ca. 4% aller Seiten sind valide?)
Ich sehe auch nur HTML-Browser - keine HTML-4.01-Browser. Und es wäre mehr als töricht, wenn man die Fähigkeit zur Abwärts- und Aufwärtskompatibilität, die man HTML generell und explizit in die Wiege gelegt hat, durch unnötige Einschränkungen bei der Browserrogrammierung konterkarieren würde.
Gleichwohl: Mir - und so manchem anderen hier - könnte es egal sein. Meine Seiten lassen sich mit jedem Browser nutzen - egal welche HTML-Version er (ggf. auch exklusiv) unterstützt. Nur: Diese Seiten sind nicht relevant. Das "Problem" sind Milliarden von Seiten, die weniger kompatibel gecodet sind, aber trotzdem betrachtet werden können sollten. ;-)
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Hallo.
Das "Problem" sind Milliarden von Seiten, die weniger kompatibel gecodet sind, aber trotzdem betrachtet werden können sollten. ;-)
Auf diese läppischen 96% könnte ich gut verzichten. Haben die überhaupt einen Nutzen, der darüber hinausgeht, Suchmaschinenbetreibern neue Indizierungsrekorde melden zu lassen?
MfG, at-
Hi,
Auf diese läppischen 96% könnte ich gut verzichten. Haben die überhaupt einen Nutzen, der darüber hinausgeht, Suchmaschinenbetreibern neue Indizierungsrekorde melden zu lassen?
Vermutlich sprach Bill Gates extra von "Information at your fingertips" und nicht von "Information in valid documents at your fingertips". ;-)
Gruß, Cy - Content rulez - baer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Hallo.
Vermutlich sprach Bill Gates extra von "Information at your fingertips" und nicht von "Information in valid documents at your fingertips". ;-)
Ja, Bill Gates, der große Internet-Guru. Dank seines
<abbr>-untauglichen Browsers kennt der vermutlich noch nicht einmal den Unterschied zwischen _M_icro_S_oft und _M_ultipler _S_klerose. -- Gut, wer einmal unter einem von beiden gelitten hat, kann auch eine Unterscheidung vermutlich auch verzichten, aber ...
MfG, at
-
-
-
-
-
-
- Selbige Engines lassen sich für HTML-Dokumente also bis zum Sanktnimmerleinstag verwenden.
-
-
Hallo Rolf.
P.S. Wer sagt, dass Browser bis in alle Ewigkeiten missbilligte Dags unterstützen ? Wissen oder Vermutung ?
Die Browserhersteller werden sich hüten, veraltete Tags bzw, verschandelte Konstrukte eben solcher nicht mehr zu unterstützen.
Für jede invalide Seite, die sich der Browser weigert, darzustellen, verlieren die Browserhersteller einen Kunden. Denn diesen kümmert es meist nicht, warum die Seite nicht dargestellt wird, sondern nur, welcher Browser sie darstellen kann.
Gruß, Ashura
--
Selfcode: sh:( fo:) ch:? rl:( br:^ n4:& ie:{ mo:) va:) de:> zu:) fl:( ss:| ls:[ js:|
Try it: Become an Opera Lover in 30 days-
Hallo,
Die Browserhersteller werden sich hüten, veraltete Tags bzw, verschandelte Konstrukte eben solcher nicht mehr zu unterstützen.
Warum sollten Sie? Gibt es einen Browser, der HTML 3.2 vollstaendig unterstuetzt? Hat das bis jetzt bei einem Browser zum Verlust von Marktanteilen gefuehrt?
Die meisten Seiten, die heute noch HTML 3.2 sind, werden entweder nicht mehr aktualisiert (sind also vom Inhalt her veraltet) oder sind typische Lieschen Mueller Seiten - wechselst Du Deinen Browser, weil er solche Seiten nicht so anzeigt, wie sich das irgendjemand mal gedacht hat?
Für jede invalide Seite, die sich der Browser weigert, darzustellen, verlieren die Browserhersteller einen Kunden. Denn diesen kümmert es meist nicht, warum die Seite nicht dargestellt wird, sondern nur, welcher Browser sie darstellen kann.
Die einzige mir bekannte Firma, die mit einem Browser Geld verdient, ist Opera.
Die Kohle machen sie wohl teilweise im embedded-Bereich; und da ist Code, den man wegen 'veraltet' rausschmeissen kann, bares Geld.Gruss
Thomas-
Hallo Thomas.
Warum sollten Sie? Gibt es einen Browser, der HTML 3.2 vollstaendig unterstuetzt?
Von vollständiger Unterstützung war hier nie die Rede.
Ich sagte lediglich, dass es der Tod für einen Browser sein kann, wenn er veraltete Tags (und meinetwegen auch Dokumententypdeklarationen) _überhaupt nicht mehr_ unterstützt,Hat das bis jetzt bei einem Browser zum Verlust von Marktanteilen gefuehrt?
Das nicht. Aber das Gegenteil ist der Fall. Der IE ist z. T. so enorm verbreitet, weil er nahezu jeden Müll schluckt.
Das große Erwachen kommt dann bei den Leuten, die sich ihr Fabrikat einmal in einem anderen Browser anschauen. ("Was? Das gibt es auch?")- wechselst Du Deinen Browser, weil er solche Seiten nicht so anzeigt, wie sich das irgendjemand mal gedacht hat?
Ich nicht. Aber für die Marktprognose bei den Browserherstellern dürfte dieser Aspekt durchaus relevant (wenn auch nicht die tragende Rolle) sein.
Die einzige mir bekannte Firma, die mit einem Browser Geld verdient, ist Opera.
So gesehen auch M$, da der IE im Umfang bei Windows-OS enthalten ist. (Was ja auch nicht kostenfrei ist.)
Die Kohle machen sie wohl teilweise im embedded-Bereich; und da ist Code, den man wegen 'veraltet' rausschmeissen kann, bares Geld.
Könntest du das ein wenig näher erläutern?
Gruß, Ashura
--
Selfcode: sh:( fo:) ch:? rl:( br:^ n4:& ie:{ mo:) va:) de:> zu:) fl:( ss:| ls:[ js:|
Try it: Become an Opera Lover in 30 days-
hi,
Die Kohle machen sie wohl teilweise im embedded-Bereich; und da ist Code, den man wegen 'veraltet' rausschmeissen kann, bares Geld.
Könntest du das ein wenig näher erläutern?
viel zu erläutern gibt's doch da gar nicht :-)
opera bietet nicht nur den "normalen" browser für den desktop an, sondern eben auch browser-lösungen für PDAs, smartphones, handy etc. - und ist auf diesem gebiet auch m.W. auch ziemlich erfolgreich.
da ein handy aber weitaus weniger arbeitsspeicher und prozessorkapazitäten hat als (d)ein hyper-gamer-PC, muss hier natürlich auch um einiges schonender mit den ressourcen umgegangen werden. also ist es in dem sektor nur von vorteil, wenn man codesegmente, die nur zum interpretieren veralteten HTMLs dienen, aufwendige fehlererkennungsroutinen etc. weitgehend entsorgen, und somit das endprodukt schlanker halten kann.
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
Hallo wahsaga.
opera bietet nicht nur den "normalen" browser für den desktop an, sondern eben auch browser-lösungen für PDAs, smartphones, handy etc. - und ist auf diesem gebiet auch m.W. auch ziemlich erfolgreich.
Das war mir bewusst.
Ich hatte offensichtlich Thomas' Aussagen falsch verstanden.da ein handy aber weitaus weniger arbeitsspeicher und prozessorkapazitäten hat als (d)ein hyper-gamer-PC, (...)
Woher kennst du die Leistung meines PCs? ;))
also ist es in dem sektor nur von vorteil, wenn man codesegmente, die nur zum interpretieren veralteten HTMLs dienen, aufwendige fehlererkennungsroutinen etc. weitgehend entsorgen, und somit das endprodukt schlanker halten kann.
Da stimme ich zu. IMHO könnte dieses Denken auch gerne bei den "großen" Browsern umgesetzt werden, um die Webseitenersteller ein wenig anzustacheln, saubereren Code zu schreiben.
Gruß, Ashura
--
Selfcode: sh:( fo:) ch:? rl:( br:^ n4:& ie:{ mo:) va:) de:> zu:) fl:( ss:| ls:[ js:|
Try it: Become an Opera Lover in 30 days
Meine Browser: Opera 7.54 | Firefox 1.0.2 | Lynx 2.8.3 | Netscape 4.7 | IE 6.0
-
-
-
-
Nur mal als Hintergrund-Info, die aktuelle Realität sieht leider so aus:
Etwa 95% aller Webseiten der Welt sind "invalide", streng genommen also fast alles mehr oder weniger Datenmüll, selbst die von Microsoft, eBay und Google (sogar über 50 Fehler auf der Startseite) !!!-
Hi there,
Etwa 95% aller Webseiten der Welt sind "invalide", streng genommen also fast alles mehr oder weniger Datenmüll,
Naja, es ist nicht jede invalide Seite automatisch "Datenmüll", ein klitzklitzekleinwenig kommt es auch noch auf den Inhalt an, oder?
selbst die von Microsoft ...
naja, das ist ja nun wirklich kein Wunder, die bauen auf ihren eigenen Seiten absichtlich proprietären Dreck ein, damit sich andere Browser besonders schwer tun...
-
-
Tachchen!
Trotzdem muss ich doch noch mal nachfragen: wenn es denn praktisch egal ist - so der Haupttenor der Antworten - Transitional oder Strict zu codieren(Hauptsache valide!)- warum dann überhaupt Strict codieren - warum soll ich dann bei neuen Projekten nicht bei Transitional bleiben.
Bei neuen Projekten wirst du als guter Webdesigner auch im Kundeninteresse
darauf drängen, semantisch brauchbare Seiten abzuliefern/abliefern zu dürfen._Dort_ wirst du mit strictem (cooles Wort) Doctype deutlich weiter kommen
und ihn von Ausnahmefällen abgesehen auch kommentarlos benutzen.Gruß
Die schwarze Piste
-
Bei neuen Projekten wirst du als guter Webdesigner auch im Kundeninteresse
darauf drängen, semantisch brauchbare Seiten abzuliefern/abliefern zu dürfen.Also - was denn nun! Transitional-Seiten sind doch semantisch brauchbare Seiten (aus Kundensicht allemal) - ODER DOCH NICHT ?
-
Moin!
Also - was denn nun! Transitional-Seiten sind doch semantisch brauchbare Seiten (aus Kundensicht allemal) - ODER DOCH NICHT ?
Die Brauchbarkeit der Semantik entscheidet sich nicht am DOCTYPE.
Transitional erlaubt Dinge wie <font> zur Schriftformatierung. Das ist vollkommen unsemantisch und deshalb böse, aber man muß es ja nicht verwenden. Wer nur deshalb Transitional nutzt, um valide target-Attribute in Links zu verwenden, ansonsten aber semantisch sinnvoll auszeichnet und Strict erfüllen würde, der schreibt mit Sicherheit besseres HTML, als wenn jemand wie irre Strict benutzt, dort aber nur alle <font> durch entsprechend formatierte <span> ersetzt hat.
- Sven Rautenberg
-
N'abend!
Verstanden und akzeptiert ! :)
-
Tachchen!
Also - was denn nun! Transitional-Seiten sind doch semantisch brauchbare Seiten (aus Kundensicht allemal) - ODER DOCH NICHT ?
Sie können es sein, müssen es aber ebenso wie Strict-Seiten nicht.
Tabellenlayouts (als prominentestes Beispiel) wären problemlos valide zu
erstellen ... unter jedem Doctype. Aber semantisch ist das ziemlicher Unsinn.Semantic Markup hat nur in Randbereichen etwas mit dem Doctype zu tun.
Gruß
Die schwarze Piste
-
-
-
Moin!
Trotzdem muss ich doch noch mal nachfragen: wenn es denn praktisch egal ist - so der Haupttenor der Antworten - Transitional oder Strict zu codieren(Hauptsache valide!)- warum dann überhaupt Strict codieren - warum soll ich dann bei neuen Projekten nicht bei Transitional bleiben.
Welche HTML-Variante du benutzt, ist in der Tat vollkommen irrelevant. Das wirst du mit keinem Kunden diskutieren müssen, bzw. dahingehend wird es in 99% aller Fälle keinerlei Vorgaben geben, selbst bei den Unternehmen, bei denen eine strenge CI-Polizei über alles wacht, was externe Webdienstleister so produzieren.
Warum also Strict benutzen? ... Hattest du da nicht was gesagt von wegen "Ehrgeiz"?
Zugegeben: Wenn's den Kunden nicht die Bohne interessiert, man es mit ihm also nicht diskutiert und somit der beste Adressat dieser "Ich bin toll, bitte klatschen"-Botschaft wegfällt, dann bleiben als Motivationsgründe für den Umstieg auf Strict eigentlich nur zwei übrig:
1. Man will sich selbst weiterentwickeln.
2. Man will sicherstellen, keine mißbilligten Tags und Attribute mehr zu verwenden und alle Formatierung nur noch mit CSS realisieren - der Validator würde dann derartige Dinge sofort anmeckern, so dass man wirklich nur noch CSS zur Formatierung einsetzen muß.Strict bildet also eine HTML-Untermenge validatortauglich so ab, dass entsprechend Interessierte den kompletten Schritt hin zu CSS-Formatierung gehen können und bei der Fehler- bzw. Gewohnheitenbehebung von einer objektiven Instanz auf die Finger geschaut kriegen.
- Sven Rautenberg
-
Hallo,
meinen Kunden ist es wurscht, ob ich strict oder sonst was arbeite, die wollen, das ich gut arbeite. Wie ich das für mich definiere hat die nicht zu interesieren, die müssen am Ergebnis schauen, ob sie mir glauben oder, nach Ablieferung, besser nicht geglaubt hätten.
Bei einem Relaunch oder einer Erstellung einer Seite gibt es n gegen unendlich spannende Dinge, die ich mit meinen Kunden bespreche, aber das verwendete "markup" gehört sicherlich nicht dazu. Womit verplemperst Du denn die Energie Deiner Kunden?
Chräcker
-
habe d'ehre
Bei einem Relaunch oder einer Erstellung einer Seite gibt es n gegen unendlich spannende Dinge, die ich mit meinen Kunden bespreche, aber das verwendete "markup" gehört sicherlich nicht dazu.
Genau wegen solcher technischen Abschweifungen bin ich bei Vorbesprechungen nicht mehr dabei. Nicht, dass ich jetzt ueber "strict" und "transitional" schwafeln wuerde (interssiert eh kein Sch..), aber ich "langweilte" immer alle mit der zu sehr technischen Sicht der Dinge. ;-) Ergo: Schuster bleib bei deinen Leisten.
Womit verplemperst Du denn die Energie Deiner Kunden?
Naja, soweit ging es dann auch nicht. Allerdings gibt es auch Kunden, die sehr wohl den Link zur heiligen Kuh kennen. :-) Und den auch nutzen. Da sollte man dann schon gewappnet sein.[1]
man liest sich
Wilhelm[1] Hey Du, da wird ein "&" angemeckert, die Seite entspricht nicht dem Standard, ich zahle nicht.
-
Hallo,
Naja, soweit ging es dann auch nicht. Allerdings gibt es auch
Kunden, die sehr wohl den Link zur heiligen Kuh kennen. :-) Und
den auch nutzen. Da sollte man dann schon gewappnet sein.[1]ja aber das muß ich doch mit dem Kunden nicht vorher abklären, ob ich schlampig arbeiten darf oder nicht. Mit "schlampig" meine ich nicht "nicht-strict" sondern "nicht begründbar". Oder wie machen das Eure Leute? "jetzt noch was wichtiges: legen Sie wert auf eine stricte Version oder dürfen wir fonts verwneden? Und wie stehts mit der Semantik"?
(Browserkompatibilät bei JS-Wünschen etc gehören natürlich ins Vorgespräch, aber da belaste ich den Kunden auch mit so wenig Details wie möglich und so wenig wie er fordert....)
Und wenn ich (was ich in der Tat mache) streckenweise mir doch kleine Schlampigkeiten erlaube, dann stehe ich im zweifelsfrei nacher dafür auch gerade. Denn dann hätte ich den Kunden von Anfang falsch eingeschätzt. Sagen wir, was jetzt wirklich rein hypothetisch ist, ich würde für Cheatah eine Seite basteln, wüste ich doch, was ich besser lassen sollte ;-)
Aber: ich gebe zu, das meine Kunden das in der Tat noch nie interesiert hat, was sicherlich auch an dem "Gemenge" von Mensche liegt, die auf meine Seiten anspringen. Die Techniker (jenseits der Webbranche) sind es seltener....
Chräcker
-
habe d'ehre
"jetzt noch was wichtiges: legen Sie wert auf eine stricte Version oder dürfen wir fonts verwneden?
Das solche Dinge nicht mehr verwendet werden baucht man auch nicht zu diskutieren, versteht sich von selbst.
(Browserkompatibilät bei JS-Wünschen etc gehören natürlich ins Vorgespräch, aber da belaste ich den Kunden auch mit so wenig Details wie möglich und so wenig wie er fordert....)
Die Details werden dann wichtig, wenn die JS-Wuensche tief in die Funktionalitaet greifen. Da wird dann bei uns schon versucht auf einen Verzicht hinzuarbeiten. (ich weiss gar nicht, wann ich das letzte Mal etwas umfangreicheres mit JS gemacht habe)
Und wenn ich (was ich in der Tat mache) streckenweise mir doch kleine Schlampigkeiten erlaube, dann stehe ich im zweifelsfrei nacher dafür auch gerade.
Versteht sich von selbst. Was ich sagen wollte: Wegen eines unmaskierten "&" in einer URL muss man nicht gleich den Megaaufstand anzetteln. (weiter letzter Absatz)
Sagen wir, was jetzt wirklich rein hypothetisch ist, ich würde für Cheatah eine Seite basteln, wüste ich doch, was ich besser lassen sollte ;-)
.... da gibt es ja ein "wunderschoenes" Fruehwerk. :-)
Aber: ich gebe zu, das meine Kunden das in der Tat noch nie interesiert hat, was sicherlich auch an dem "Gemenge" von Mensche liegt, die auf meine Seiten anspringen. Die Techniker (jenseits der Webbranche) sind es seltener....
Gut, unsere groesseren Sachen spielten sich frueher immer bei IT-Firmen ab. Da sitzen dann schon oefter externe "Berater" und Programmierer rum, die nix besseres zu tun haben, als den ersten Prototyp gleich durch den Vali zu jagen und in manch elitaerer NG grosskotzig ueber "Monkeys" in der Webszene zu palavern.
man liest sich
Wilhelm
-
-
-
-
-
Hi there,
Welche Argumente würdet Ihr bei einem Kunden anbringen, eine bestehende Transitional-Seite (gegen Bares natürlich) auf Strict-Niveau zu bringen ... ich höre da oft den Satz: "ist mir egal, ob die Sache standardkonform ist, Hauptsache es funktioniert und ist günstig."
Wie verfahrt Ihr in derartigen Fällen ?
Ich geb' dem Kunden recht und erhalte den Auftrag im Gegensatz zu jenem, der mit dem Kunden streitet. Eine bestehende Seite umzubauen ist imho ohnehin ein Blödsinn.
Stell' Dir einmal die Frage, was der Kunde davon hat, daß der Programmierer voll Stolz seinen "strict valid" Button anbringen kann und warum der Kunde das bezahlen soll. Ich denke, wenn Du Dir diese Frage beantwortet hast, dann ist die Frage, wie Du es dem Kunden erklärst, na sagen wir es einmal mit einem hier im Forum gerne gebrauchten Adjektiv, einfach irrelevant.Was anderes ist bei einer Programmierung, da würd' ich mir vom Kunden sicher nichts d'reinreden lassen.
Aber sieh es einmal so: für viele Kunden (diejenigen, die einen gut gehenden Webshop betreiben, einmal ausgenommen) ist eine Webseite eigentlich so wichtig und nötig wie ein Schlag auf den Hinterkopf. Ich halte es für falsch, den Kunden, wenn er für etwas, was er meist nicht braucht, auch noch mit Details zu belasten, die ihn ohnehin nicht interessieren.
-
Hallo.
für uns Spezies mag die Frage, warum eine Seite (mindestens) nach Html 4.01 Strict codiert sein sollte, einfach zu beantwortensein - Stichwort "wohlgeformt", Stichwort "browserübergreifend gleiche Darstellung" usw.
Mit "strict" hat es zwar nichts zu tun, aber "valide" und "wohlgeformt" könnten schon eher die Stichworte sein, nämlich dann, wenn in absehbarer Zeit eine Weiterverarbeitung der Inhalte mittels XML/XSLT und/oder DOM ansteht.
MfG, at