Mein Dank an das Forum
fireeye
- meinung
Mein Projekt ist zwar noch nicht gänzlich abgeschlossen, aber der erreichte Fortschritt läßt Freude aufkommen.
Z.Zt. hab ich über 300 Textobjekte (davon 1 x CCS und der Rest zu etwa gleichen Teilen HTML und Javascript). Alle Teile weisen W3C-Compliance auf!
Ich teste auf Mac OSX mit FF, Mozilla, Netscape, Opera und IE. Heute konnten auch die Tests auf Windows/Windows NT5.0 mit IE und FF erfolgreich bestanden werden.
Für die sichtbare Darstellung bin ich OHNE Browserweichen ausgekommen, nur für IE in Windows ist eine kleine Browserweiche nicht zu umgehen, da IE für den URL-String die Pfadangaben mit dem Backslash abtrennt, anders als bei FF und Co.
Ich verwende Frames für den Seitenaufbau mit geschachtelten Framesets, auch die Interaktion zwischen den Frames macht keine Probleme.
Die Navigation ist komplett in Javascript realisiert, ein hierachisches Menü mit 4 Ebenen, auf- und zuklappbar und mit insgesamt über 1300 Einträgen. Der Menüzustand wird in einem Cookie gespeichert.
Der Seitenaufbau ist trotz großer Grafikanteile hervorragend (< 1 Sekunde).
IE hat mir einige Probleme bei Javascript bereitet, andere Browser waren da gnädiger, aber auch diese IE-Probleme sind alle gelöst.
Was bleibt, ist noch die Erstellung einiger Textseiten (ca. 20) mit Grafikeinbindungen.
Schade nur, daß man das Projekt nicht öffentlich bewundern kann, da es als technische Dokumentation in einem größeren Unternehmen dient.
Ich habe in dem Forum viel gelesen und viel gelernt.
Manche Diskussionen hab ich geführt - nicht immer zur Freude der absoluten Insider.
Manche Anregung habe ich aufgreifen können, die mir bei der Lösung behilflich waren.
Und ich habe hier gute Hinweise bekommen, bestimmte Irrwege nicht zu verfolgen.
Gruß f
Ketzerische Frage:
Wenn das Projekt "nur" als technische Dokumentation in einem Unternehmen dient, warum dann so viel Aufwand treiben um das Ding W3C normgerecht aufzubauen?
Ich meine damit nicht das man die Sachen schlampig coden sollte, aber wenn ich der Auftraggeber von so einer Doku wäre, würde ich mich einen ******dreck drum kümmern ob das Ding zu irgend einem Standard konform ist, zumal es doch eh überrall gleich aussieht... (Aus der Sicht eines Außenseiters gesprochen)
Hi,
Ketzerische Frage:
Wenn das Projekt "nur" als technische Dokumentation in einem Unternehmen dient, warum dann so viel Aufwand treiben um das Ding W3C normgerecht aufzubauen?Ich meine damit nicht das man die Sachen schlampig coden sollte, aber wenn ich der Auftraggeber von so einer Doku wäre, würde ich mich einen ******dreck drum kümmern ob das Ding zu irgend einem Standard konform ist, zumal es doch eh überrall gleich aussieht... (Aus der Sicht eines Außenseiters gesprochen)
a: ist das mal sportiver Ehrgeiz
b: man kann davon augehen, das irgend jemand das Ding irgendwann einmal pflegen wird, bemeckert wird dann so oder so nach dem Motto, warum hat der das so gemacht? Und jetzt schon dafür auch noch den Beleg für schlechte handwerkliche Qualität liefern?
c: Sollte zum jetztigen Zeitpunkt jemand die W3C-Compliance testen, so werd ich keinen Satz rote Ohren bekommen.
d: und noch vieles mehr....
Gruß f
Hallo fireeye,
a: ist das mal sportiver Ehrgeiz
Das war bei mir am Anfang auch so, und das ist auch gut so.
Später macht man das reflexartig, ich habe mir z.B. angewöhnt,
alle Tags beim Tippen sofort wieder zu schließen, zu jedem
" sofort ein zweites zu notieren (bei Attributen) etc...
Wenn man das lange genug macht dann strebt die Anzahl der Fehler
gegen null (ich müsste mal LaTex lernen, dann kann ich das viel
cooler mit einer Formel ausdrücken ;-)).
Gruß
Alexander Brock
Hallo Alexander,
(ich müsste mal LaTex lernen, dann kann ich das viel
cooler mit einer Formel ausdrücken ;-)).
Als kleiner Tipp:
Wenn du OpenOffice.org installiert hast und dort den Formeleditor ein wenig verwendest, lernst du automatisch LaTeX kennen. Die Formeln und Befehle sind zwar nicht identisch zu LaTeX (z.B. fehlt der Backslash für die Befehle), aber ansonsten ist das eine richtig gute Sache.
Gute Nacht
Marc Reichelt || http://www.marcreichelt.de/
Hej,
ich habe mir z.B. angewöhnt, alle Tags beim Tippen sofort wieder zu schließen, zu jedem " sofort ein zweites zu notieren (bei Attributen) etc...
Diese Reflexe werden dir mehr als dienlich sein wenn du anfängst
mal LaTeX zu lernen
Was sich da z.T. für ein Klammerwald auftut ist schon pervers. Wer nicht konsequent alles was geöffnet wird - bevor es gefüllt ist - auch wieder schließt, wird viele, viele schöne Stunden mit den kryptischen Ausgaben des Compilers verbringen. ;-)
Beste Grüße
Biesterfeld
Hi Biesterfeld
ich habe mir z.B. angewöhnt, alle Tags beim Tippen sofort wieder zu schließen, zu jedem " sofort ein zweites zu notieren (bei Attributen) etc...
Diese Reflexe werden dir mehr als dienlich sein wenn du anfängst
mal LaTeX zu lernen
Was sich da z.T. für ein Klammerwald auftut ist schon pervers. Wer nicht konsequent alles was geöffnet wird - bevor es gefüllt ist - auch wieder schließt, wird viele, viele schöne Stunden mit den kryptischen Ausgaben des Compilers verbringen. ;-)
Es ist völlig unerheblich, ob als Script oder in anderen Programmiersprachen gecodet wird. In traditionellen Programmiersprachen ist es ein MUSS, sich über Klammerungen im Klaren zu sein, HTML ist dagegen in mancher Hinsicht leider sehr gnädig, aber deswegen sollte man den eigenen Stil trotzdem nicht aufgeben. Code der mit Compilern übersezt wird, sollte IMMER eine gute Strukturierung/Texteinrückungen/Kommentare/Klammerungen aufweisen, da Tabs oder Leerzeichen bzw. Kommentare für das fertige Compilat keine Rolle spielen. Bei HTML-Scripten ist das was anders, da zählt jedes Zeichen bei der Übertragung.
Ich habe mir bei HTML/Javascript zur Angewohnheit gemacht, hier genauso zu verfahren, wie bei Compilersprachen. Ich teste den Entwurf solange, bis ein einwandfreies Ergebnis zustande gekommen ist. Erst dann hebe ich unter BBEdit für einen Absatz die Struktuierung auf (bei Javascript nur insoweit, daß keine unerwünschten Seiteneffekte entstehen können - aber das versteht sich von selbst), mache also für einen bestimmten Absatz eine Zeile daraus, das spart Tabs bzw. Leerzeichen und erhöht die Geschwindigkeit beim Seitenaufbau. Der scheinbare Verlust der inneren Struktur eines Absatzes ist zu verkraften, da BBEdit über ausgezeichnete Editier- und Such-Feature verfügt. Wesentlich hierbei ist, daß sich dieser Prozeß der Destrukturierung im Bedarfsfalle unter BBEdit wieder rückgängig machen läßt, sofern voher eine einwandfreie Strukturierung vorgelegen ist.
Manche Code-Schnippsel, die hier im Forum veröffentlich werden, beweisen, daß sehr viel geschustert wird, ohne auch nur ein Mindestmaß an handwerklichen Fähigkeiten anzuwenden. Leider!!!
Gruß f
Hallo fireeye,
Bei HTML-Scripten ist das was anders, da zählt jedes Zeichen bei der Übertragung.
Ein Ketzer, er hält HTML für eine Scriptsprache!
Nagelt ihn an ein Kreuz!
</ironie>
Ich liefere für alle br:] ordentlich Strukturierten XHTML-Code aus,
und schreibe ebenfalls reflexartig
<?php
ob_start('ob_gzhandler');
header('Content-Type: text/html; charset=UTF-8');
?>
an den Anfang jeder Datei, die der Browser zu Gesicht bekommt,
da interessieren mich die paar Leerzeichen, die mit komprimiert
werden müssen herzlich wenig.
Gruß
Alexander Brock
Hallo Alexander
Ein Ketzer, er hält HTML für eine Scriptsprache!
Nagelt ihn an ein Kreuz!
</ironie>
hast ja recht, Applescript ist schon was anderes :-)
an den Anfang jeder Datei, die der Browser zu Gesicht bekommt,
da interessieren mich die paar Leerzeichen, die mit komprimiert
werden müssen herzlich wenig.
Reiner Text wird jedenfalls mindestens mit 55% komprimiert bei der Übertragung, oder sogar noch besser. Bei JPEG oder GIF is da nicht mehr viel drin, allenfalls 3% wenn ich die Zahl noch richtig im Hinterkopf habe.
Gruß f
Hallo fireeye,
Reiner Text wird jedenfalls mindestens mit 55% komprimiert bei der Übertragung, oder sogar noch besser. Bei JPEG oder GIF is da nicht mehr viel drin, allenfalls 3% wenn ich die Zahl noch richtig im Hinterkopf habe.
Reiner Text hängt AFAIK ein bischen von der Wortwahl etc. ab,
und stärker von der Sprache, bei JPEG, GIF und PNG sollten
es aber weit unter 3% sein.
Gruß
Alexander Brock
Hallo Alexander,
Reiner Text hängt AFAIK ein bischen von der Wortwahl etc. ab,
und stärker von der Sprache, bei JPEG, GIF und PNG sollten
es aber weit unter 3% sein.
LZ77 und Huffman-Codierung sag ich nur :-) wird bei jeder Inet-Übertragung angewendet :-)
Gruß f
Hallo Biesterfeld,
Was sich da z.T. für ein Klammerwald auftut ist schon pervers. Wer nicht konsequent alles was geöffnet wird - bevor es gefüllt ist - auch wieder schließt, wird viele, viele schöne Stunden mit den kryptischen Ausgaben des Compilers verbringen. ;-)
Das durfte ich gerade bei PHP erfahren, ich habe ein ~260 Zeilen langes
8-dimensionales Array, mit ~4 Fehlern, ich habe 2h gebraucht, diese zu finden :-(
Als Konsequenz mach ich mir jetzt Gedanken darüber, ob ich das Ganze auch
mit einem 4-dimensionalen Array hinbekomme :-)
Gruß
Alexander Brock
Hi,
Für die sichtbare Darstellung bin ich OHNE Browserweichen ausgekommen, nur für IE in Windows ist eine kleine Browserweiche nicht zu umgehen, da IE für den URL-String die Pfadangaben mit dem Backslash abtrennt, anders als bei FF und Co.
Das wäre mir neu. AFAIR macht dies nur der IE <3 bei lokalen Zugriffen.
Darüberhinaus "normalisiere" ich die Pfade aber ggf. (in JS, PHP, ...), d.h., ich ersetze die (theoretisch möglichen) "" eines Pfades durch ein "/".
Gruß, Cybaer
Hi Cybaer
Für die sichtbare Darstellung bin ich OHNE Browserweichen ausgekommen, nur für IE in Windows ist eine kleine Browserweiche nicht zu umgehen, da IE für den URL-String die Pfadangaben mit dem Backslash abtrennt, anders als bei FF und Co.
Das wäre mir neu. AFAIR macht dies nur der IE <3 bei lokalen Zugriffen.
Darüberhinaus "normalisiere" ich die Pfade aber ggf. (in JS, PHP, ...), d.h., ich ersetze die (theoretisch möglichen) "" eines Pfades durch ein "/".
Manchmal sieht man vor lauter Wald, die Bäume nicht mehr... ;-)
Klar doch, Brett vorm Kopp :-((
Danke für den Tipp, damit kann ich ganz auf Browserweichen verzichten!!
Gruß f