Der Stand der Dinge

Seit 3 Wochen habe ich mich nun sehr intensiv mit OXID CE befasst, vor allem dem Bereich “Templating”.

Ich möchte daher mal so eine Art [B]subjektive Bestandsaufnahme[/B] machen…

Erfreulicher Weise kann ich sagen, dass ich da doch recht weit voran gekommen bin.

Dank der [B]weisen Entscheidung[/B] von OXID eSales, für das Templating “Smarty” zu verwenden, kann man in dieser Zeit, auch als OXID-Neuling (aber erfahrener Template- und Shop-Entwickler im xtCommerce/Gambio-Umfeld) doch [B]sehr weit [/B]kommen!

(Ein Zustand, der in dieser Zeit z.B. mit Magento [B]auf keinen Fall[/B] erreichbar ist, weil die m.E. (auch) das Templating total “verkackt” haben. Tatsächlich habe ich Magento deshalb nach einer Woche, ziemlich verärgert, in die Tonne getreten. Warum jemand Magento verwendet, wenn er z.B. OXID haben kann, werde ich nie begreifen…)

Ziel meiner Aktivitäten war es, das OXID-Templating so anzupassen, dass es, für mich als Template-Entwickler, (wesentlich) einfacher und flexibler handhabbar ist, und man einem OXID-Shop auf den ersten, zweiten und dritten Blick nicht ansieht, dass es ein OXID-Shop ist. (Was man vielen OXID-Shops ja leider sofort ansieht.)

Unter http://oxid.powertemplate.de kann man sich den derzeitigen Stand meiner Bemühungen mal ansehen…

(Auch gedacht als Anregung, was man mit dem OXID-Shop so alles anstellen kann. So überladen mit Funktionen würde man sicher keinen Shop designen, das ist auch mehr als eine Plattform für Designkonzepte und ein Sammelsurium von Shop-Technologien, die ich mal ausprobiert und implementiert habe, zu betrachten. Und fertig ist das auch noch nicht, mehr “Work in progress”. Es gibt da noch viele Ideen über weitere Funktionen… (z.B. eine scrollbare Newsbox))

Dieses Shop-Template basiert auf dem Standard-OXID-Template, allerdings (per CSS und Code-Änderungen) stark adaptiert, und graphisch hochwertig designed.

Die wesentlichen Änderungen sind:

[ul]
[li]Die textorientierten [B]Boxen-Header[/B] und [B]Buttons [/B]sind durch individuelle Grafiken ersetzt.worden. (Das ist zwar sehr viel aufwändiger als das bisherige Konzept, aber damit hat man doch viel mehr Designspielraum.)[/li][li]Die [B]Positionierung der “Boxen”[/B] wurde total überarbeitet und flexibilisiert. (Um einen “Box” an eine beliebige Stelle der Seite zu plazieren (linke Navi, rechte Navi, Header) muss man nicht mehr in den Template-Code eingreifen, sondern das geschieht über eine Konfigurationsdatei.)[/li][li]Bilder werden beim “Überfahren” mit der Maus per “[B]CSS-Flyout[/B]” vergrößert.[/li][li]Informationen, die bei OXID in “Boxen” waren, wurden (alternativ) in den Contentbereich der Detailseite verlagert (Cross-Sells, Also-Purchased, Zubehör)[/li][li]Informationen, die bei OXID im “Contentbereich” waren, wurden (alternative) als (scrollbare) Boxen konzipiert (Bestseller, Neue Produkte, Dauerbrenner)[/li][li]Es ist ein [B]Bild-“Fader”[/B] vorhanden, im oberen Banner-Bereich werden beliebig viele Banner über einen “Fader” zufällig rotiert. (Die verwendeten Bilder passen nicht alle zu dem Design.)[/li][li]Es ist ein “[B]Produkt-Karusell[/B]” vorhanden (“Flash-Rotator”). (Eine Flash “3D-Tag-Cloud” habe ich hier auch noch 'rumliegen… Das ist so etwas: http://www.juranaut.de/3d-tag-cloud )[/li][li]Das “Schnäppchen” wurde um einen “[B]Live-Shopping[/B]”-Aspekt erweitert. Mit Countdown-Zähler und Anbindung an die OXID-Bestandsverwaltung, so dass das nur so lange verkauft werden kann, wie ein Lagerbestand vorhanden ist.[/li][li]Es wurde eine [B]“Rückruf”-Funktion[/B] (mit Kalender) eingebaut (erreichbar über die “Rückruf”-Grafik rechts oben).[/li][li]Der verkleinerte [B]Warenkorb [/B]oben hat ein “[B]CSS-Flyout[/B]” erhalten, in dem der Warenkorb-Inhalt detaillierter angezeigt wird. (Etwas in den Warenkorb legen, und mit der Maus über den Warenkorb fahren.)[/li][li]Die “[B]Checkout-Steps[/B]” wurden grafisch ansprechend gestaltet, sieht einfach professioneller aus. (Etwas in den Warenkorb legen, und Warenkorb aufrufen).[/li][li]Es wurde ein “[B]Cart-Cross-Marketing[/B]” implementiert. Dabei werden beim Aufruf des Warenkorbs Listen mit [B]Zubehör[/B]-, “[B]Cross-Selling[/B]”-, “[B]Also-Purchased[/B]”- und [B]Ähnlichen[/B]-Produkten für [B]alle[/B] im Warenkorb befindlichen Produkte angezeigt, um dem Besteller Ideen für weitere Einkäufe an die Hand zu geben, die zu seinen bisher eingekauften Produkten passen. So etwas wird von Verkaufs-Profis wärmstens empfohlen, und wird z.B. auch von Amazon ausgiebig genutzt! (Produkte in den Warenkorb legen, und Warenkorb aufrufen.)[/li][li]Unter http://oxid.powertemplate.de/Geschenke/Original-BUSH-Beach-Radio.html kann man dann ein Konzept der Produkt-Detail-Darstellung mit Hilfe von “[B]Tabs[/B]” sehen. Damit kann man die Detail-Information wesentlich [B]übersichtlicher und Platz sparender strukturieren[/B]. (Im “Mehr Bilder”-Tab werden natürlich beim “Hovern” (mit CSS-Flyouts) auch wieder die Zoom-Bilder angezeigt.)[/li][li]Es gibt eine “[B]Google-Analytics[/B]” Schnittstelle, auch für die GA [B]eCommerce[/B]-Features! (Dabei werden auch die Details der Bestellungen an GA übermittelt, was auch wieder viele interessante eCommerce-Statistiken ermöglichst.)[/li][/ul]
Diese Änderungen konnten alle(!) ohne Eingriffe in den OXID-Core realisiert werden, so dass diese “update-fest” sind.

Nun müssen “nur” noch die diversen Produktlisten anders designed werden, dann ist die Verwandlung des OXID-Templates perfekt, und auch unsere OXID-Shop-Templates werden dann unseren Qualitätsvorstellungen genügen.

Neben diesen sichtbaren Änderungen gibt es noch eine Menge interner Änderungen am OXID-Templating, vor allem mit dem Ziel, die Strukturierung der Seiten wesentlich zu vereinfachen (z.B. welche “Boxen” verwende ich, wo kommt welche “Box” hin usw., ohne noch in den Template-Code eingreifen zu müssen).

Ich verwende jetzt z.B. nur noch [B]eine einzige Template-Layout-Definitionsdatei[/B] ("_index.tpl"), in der die Seiten-Struktur [B]vollständig [/B]und [B]übersichtlich[/B], mit [B]allen [/B]Elementen, beschrieben wird. (Und die Seiten-Struktur nicht mehr in mehreren Template-Dateien definiert wird ("_header.tpl", “_left.tpl”, “_right.tpl”, “_footer.tpl”).)

Wobei ich mich da von xtCommerce/Gambio habe inspirieren lassen, weil ich deren Templating-Konzept immer noch für recht gelungen und übersichtlich erachte. (Aber das ist vermutlich doch irgendwie Geschmacksache…)

Dieses Thema werde ich im “Entwickler”-Forum noch mal genauer ausführen, vielleicht ja auch als Anregung an die OXID-Entwickler…

ja, nich schlecht, kann man sich auf jeden Fall Anregungen holen

Bei mir ist das Template ziemlich “zerrissen”. Der Contentbereich ist erst nach langem scrollen ganz unten sichtbar.

[QUOTE=roland76;9307]Bei mir ist das Template ziemlich “zerrissen”. Der Contentbereich ist erst nach langem scrollen ganz unten sichtbar.[/QUOTE]
Nun, das wird daran liegen, dass das bisher nur mit FireFox getestet wird…

Die anderen Browser, insbesondere die IEs, wollen da oft speziell gebeten werden.

Das sind aber i.d.R. ein paar wenige browser-spezifische CSS-Definitionen.

Mit welchem Browser bist Du unterwegs?

Setze IE7 ein.

Finde das “Live-Shopping”-Feature ganz interessant…hab Dir mal 'ne PN geschickt!

wenn ich mich nicht irre war genau das eines der features für die version 4 (stand doch in diversen presseberichten)

@oxid wüßte gerne warum das nicht mehr “auftaucht”

[QUOTE=roland76;9312]Setze IE7 ein.[/QUOTE]
Ja, das ist so ein übler Bursche, der nix richtig schnallt…

Der von Dir beschriebene Effekt dürfte dem fehlerhaften Boxenmodell der IE < Version 8 zu verdanken sein.

Der IE 8 sollte das richtig verstehen, und alle anderen aktuellen Browser (Opera, Chrome, Safari).

Obwohl der eine oder andere hin und wieder doch auch besonders gebeten werden will.

Aber wie schon gesagt, das ist nur ein temporäres Problem, weil ich derzeit mit dem FF entwickle.

Das sind nur Kleinigkeiten, die ausgebügelt werden.

zu den bildern in der rechten spalte ist immer noch der text sichbar, wenn man versehentlich markiert bzw. Strg+A drückt zum “gucken” was so alles versteckt ist…

Hast ganz schön coole Sachen verbaut. Respekt!

[QUOTE=avenger;9330]Ja, das ist so ein übler Bursche, der nix richtig schnallt…

Der von Dir beschriebene Effekt dürfte dem fehlerhaften Boxenmodell der IE < Version 8 zu verdanken sein.

Der IE 8 sollte das richtig verstehen, und alle anderen aktuellen Browser (Opera, Chrome, Safari).

Obwohl der eine oder andere hin und wieder doch auch besonders gebeten werden will.

Aber wie schon gesagt, das ist nur ein temporäres Problem, weil ich derzeit mit dem FF entwickle.

Das sind nur Kleinigkeiten, die ausgebügelt werden.[/QUOTE]
So, habe mich nun mal dran gemacht, dem IE klar zu machen was Sache ist…

Er braucht halt immer noch etwas Nachhilfe, ist halt etwas behindert, der Arme.

Was beim IE<8 nicht funktioniert, ist das CSS-Flyout der Bilder. Das ist Folge des notorischen “[B]z-Index-Bugs[/B]”, weil beim IE dadurch die Flyout-Bilder [B]hinter [/B]statt vor den anderen angezeigt werden.

http://oxid.powertemplate.de/

Auch Opera, Safari und Chrome zeigen das jetzt richtig, da war auch noch der eine oder andere CSS-Mod erforderlich.

FireFox ist wirklich ein Super-Browser, der macht genau das, was man (per CSS) ihm sagt.

Hatte noch keinen Fall, dass der was falsch gemacht hätte.

Ich nehme an, das war wieder der IE?

Da ich bei meinem Umbau von den Text-Buttons und -Boxen-Headern zu deren grafischen Varianten nicht die ganzen Templates ändern wollte, habe ich das per CSS gemacht.

Bei den Browsern außer dem IE 7 geht das, indem man für ein betroffenes Element “color:transparent” oder “font-size:0px” definiert. Dann verschwindet der Text.

Nicht so der IE 7, das versteht er wieder mal nicht.

Beim IE 7 mache ich daher die störenden Texte jetzt mit einem kleinen Javascript “platt”.

Der IE vor Version 8 ist eine (unverdiente) Strafe für alle Web-Entwickler.

Warum verbietet den bloß keiner???

Hast ganz schön coole Sachen verbaut. Respekt!
Ja, auch einem OXID-Shop kann man coole Tricks beibringen.

Und da geht noch mehr…

Wenn man sich erst mal im Objektmodell des Shops und den Templates zurecht gefunden hat, geht das erfreulich einfach von der Hand.

Die OXID-Entwickler habe da einen sehr guten Job gemacht.

Hallo avenger,

ersteinmal Kompliment - Seite sieht super aus.

Ich würde gern bei mir auch ein Produkt-Karussell einbauen. Kannst Du mir bitte sagen, wie`s funktioniert bzw. was ich dazu brauche ?

Danke und ein Gruß aus Dresden

Dirk

[QUOTE=QuickCom;9658]Hallo avenger,

ersteinmal Kompliment - Seite sieht super aus.

Ich würde gern bei mir auch ein Produkt-Karussell einbauen. Kannst Du mir bitte sagen, wie`s funktioniert bzw. was ich dazu brauche ?

Danke und ein Gruß aus Dresden

Dirk[/QUOTE]
Als erstes braucht man ein Flash-Modul, das das Karussell realisiert (einlesen einer XML-Datei mit den Bildinformationen und diese als Karussell darstellen.

Dann natürlich ein PHP-Programm, das diese XML-Datei aus den Produktdaten erstellt (Zufallsprodukte).

Meine Lösung basiert auf einer osCommerce-Contribution, die ich nach xtCommerce portiert hatte, und jetzt eben zu OXID.

[QUOTE=avenger;9249]Das “Schnäppchen” wurde um einen “[B]Live-Shopping[/B]”-Aspekt erweitert. Mit Countdown-Zähler und Anbindung an die OXID-Bestandsverwaltung, so dass das nur so lange verkauft werden kann, wie ein Lagerbestand vorhanden ist.[/QUOTE]
Den “[B]Live-Shopping[/B]”-Aspekt habe ich stark verbessert.

Er ist jetzt ein eigenständiges Element, über eine Konfigurationsdatei [B]konfigurierbar[/B], unabhängig von dem bisher dafür verwendeten „[B]Schnäppchen[/B]“, und kann zusätzlich dazu verwendet werden.

Und neben dem “[B]Tagesangebot[/B]” gibt es jetzt auch den “[B]Happy-Hour[/B]”-Modus!

[B]Konfiguriert werden kann[/B]: Datum, Artikel-Nr. des Angebots-Artikels, der Angebotspreis und die maximale Bestellmenge („0“ wenn ohne Begrenzung)….

Der normale Preis wird beim Beginn des Tagesangebots auf den Angebotspreis gesetzt, der UVP erhält den zuvor gültigen Preis, damit OXID das auch alles richtig berechnen kann… (Am Ende des Angebotszeitraums wird der alte Preis wiederhergestellt.)

Ebenso wird der zu Beginn verfügbare Lagerbestand als Referenzwert (=100%) gespeichert, so dass die prozentuale Lagerbestandsanzeige funktionieren kann. Der aktuelle Lagerbestand bezogen auf diesen Referenzwert steuert dann die prozentuale Anzeige.

Zusätzlich wird beim Preis die “[B]Ersparnis in %[/B]” angezeigt

[B]Das sieht jetzt so aus:[/B]

Wenn man [B]nicht [/B]das den ganzen Tag gültige “[B]Tagesangebot[/B]” machen will, kann man alternativ auch den “[B]Happy-Hour[/B]”-Modus verwenden, bei dem das Angebot nur für eine (oder mehrere) Stunde(n) gilt. (Dieser Zeitraum ist natürlich auch zusätzlich konfigurierbar.)

Natürlich auch hier mit “Countdown”-Zähler für die verbleibende Restzeit…

[B]Das sieht dann so aus:[/B]

[B]Die Lagerbestands-Anzeige hat noch eine Besonderheit…[/B]

Da es einigermaßen dumm aussehen würde, wenn beim “Live-Shopping” gar nichts abverkauft würde, kann man einen [B]zeitabhängig reduzierten[/B] Lagerbestand anzeigen lassen… (Wenn der aktuelle geringer ist, wird natürlich dieser angezeigt.)

So verringert sich der Lagerbestand über die Angebots-Laufzeit stetig, auch wenn nix oder weniger verkauft würde…

Muss ja nicht gleich jeder sehen, dass da nix läuft!

[QUOTE=avenger;9249]Das “Schnäppchen” wurde um einen “[B]Live-Shopping[/B]”-Aspekt erweitert. Mit Countdown-Zähler und Anbindung an die OXID-Bestandsverwaltung, so dass das nur so lange verkauft werden kann, wie ein Lagerbestand vorhanden ist.[/QUOTE]
Eine Sache habe ich vergessen:

Es gab eine ganze Reihe von Anfragen nach den Modulen “Produkt-Karussell” und “Live-Shopping”, die ich bisher mit dem Hinweis, dass die nur im Rahmen meines Templates funktionieren, nicht bedienen konnte.

Mittlerweile habe ich das aber stärker entkoppelt, so dass ich die wohl auch in bestehende Templates einbauen kann…

Wer also daran interessiert ist, möge sich noch mal per PM bei mir melden.

rein optisch find ich die seite echt ansprechend, aber technisch hat die meiner meinung nach noch überholungsbedarf. Du hast da unglaublich viele Requests drin, das könnte man auf ein minimum reduzieren. Die generelle Größe der seite ist auch kritisch, ~750 kb ist schon etwas happig, aber da die Seite sehr grafiklastig ist ist das noch verkraftbar.

einer validierung hält das template auch nicht stand, grade weil du elemente wie marquee einsetzt und auch sonst ein paar kleinere glitches drin hast. Ich würde das, wenn ich schon HTML Strict als DOCTYPE angebe, auch zusehen das ich diesem standard entspreche. Ansonsten arbeite ich persönlich immer mit HTML 4.01 Transitional. Korrektes HTML ist nicht nur eine Frage der Optik, sondern auch von SEO und Barrierefreiheit.

Nur als konstruktive Kritik, aussen sicherlich hui, innen etwas pfui :wink:

Nun, was erwartest Du?

Wenn ich von den langweiligen Textheadern und Textlinks Abschied nehme, und dafür individuelle Grafiken verwende, dann müssen diese Grafiken halt auch geladen werden, es gibt halt nix umsonst…

Und Funktionen wie “Fader”, “Produkt-Karussell”, “Live-Shopping”, Bildvergrößerung per CSS-Flyout" erhöhen den Bedarf, Grafiken zu laden weiterhin.

Und da vieles davon ab dem 2 Ladevorgang aus dem Cache geladen wird, ist das absolut nicht dramatisch.

Wichtig ist der subjektive Eindruck, wie lange ein solche Seite lädt.

Und da gibt es m.E. nix zu bemängeln, selbst auf einer “Shared Hosting”-Präsenz bei all-inkl.

Wen sollte so was interessieren???

Ich sagte schon mal, dass solche Überlegungen so etwa auf Platz 1.000 meiner “ToDo”-Liste kommen.

Und so lange sich die wirklich erfolgreichen Shop-Betreiber wie Amazon und ebay 1.500 bzw. 300 Validierungsfehler auf ihrer Seite erlauben, weil die das offenbar auch als ein “non-issue” betrachten, erlaube ich mir, das Thema “Validierung” einfach zu ignorieren.

Ich betreibe keine technologische Onanie!

Wichtig ist, dass die Browser mich verstehen, und nicht der “w3c Validator”…

Auch die OXID AG sieht dieses Nicht-Thema, richtiger Weise, auch recht entspannt:

http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fdemoshop.oxid-esales.com%2Fprofessional-edition%2F&profile=css21&usermedium=all&warning=1&lang=de

Was verleitet Dich zu dieser Aussage???

Die Google-Robots und die Browser verstehen selbst kaputtestes (X)HTML noch richtig.

Was also kleine HTML- und CSS-Probleme mit SEO und Barrierefreiheit zu tun haben sollen erschließt sich mir nicht wirklich…

Nur als konstruktive Kritik, aussen sicherlich hui, innen etwas pfui
Deine Einschätzung “innen etwas pfui” muss ich doch ganz entschieden zurückweisen…

Außer diesen völlig unwichtigen Validierugsproblemen gibt es m.E. nix, was eine solche Einschätzung rechtfertigen würde.

Was also kleine HTML- und CSS-Probleme mit SEO und Barrierefreiheit zu tun haben sollen erschließt sich mir nicht wirklich…

Standards sind dazu da das alle sie einhalten und sind absolut wichtige Bestandteile eines offenen Webs. Eben damit jeder Browser alles richtig anzeigt ist es unabdingbar Standards einzuhalten. Dies ist im Moment leider nur bei HTML komplett möglich, aber bei CSS geht durch den Release des IE 8 und dessen standardkonforme Interpretation von CSS 2.1 auch der Weg in diese Richtung.

Stell dir mal vor der Google Robot spidert über deine Seite, stößt auf das Marquee element, und überspringt dieses, weil er es nicht kennt da es ein nicht im HTML Standard vorkommendes Element ist. Dann wird kein einziger Link im Live-Shopping gespidert. Wenn das mit Javascript gelöst wäre, wäre das zwar auch nicht ganz barrierefrei, aber zumindest bestünde dort nicht die gefahr das Screenreader oder eben Robots das Element ignorieren. Das ist nur ein Beispiel, ich weiss nicht genau was der Google Robot mit kaputtem HTML anstellt, ich vermute allerdings das er das nicht gerade honoriert, das die Syntax kaputt ist. Grade Google achtet stark auf die Einhaltung von Webstandards, das vertritt man auch nach aussen und dafür ist man auch bekannt.

Das hat absolut nichts mit technologischer Onanie zu tun, sondern einfach mit offenem Barrierefreiem Web. Bei CSS ist das was anderes, das ist nur layout, die Struktur allerdings ist in HTML realisiert und das ist es worauf es Robots und Screenreadern ankommt. Zudem können HTML Fehler auch zu darstellungsfehlern führen, wie zum beispiel das ein browser in den Quirks Modus zurück geworfen wird und sich anders verhält als sonst.

Und so lange sich die wirklich erfolgreichen Shop-Betreiber wie Amazon und ebay 1.500 bzw. 300 Validierungsfehler auf ihrer Seite erlauben, weil die das offenbar auch als ein “non-issue” betrachten, erlaube ich mir, das Thema “Validierung” einfach zu ignorieren.

Amazon und eBay sind aber nicht deine Kunden, amazon und ebay sind so große namen das sie allein schon wegen der gigantischen Relevanz so hoch in Google stehen. Die Kunden die von dir ein Template möchten, sind nicht amazon und ebay, und da ist jeder Link den Google “frisst” bares geld.

Wichtig ist, dass die Browser mich verstehen, und nicht der “w3c Validator”…

Dann schau mal wer im W3 Consortium so sitzt. Du findest dort alle Browserhersteller wieder und mittlerweile hält sich sogar Microsoft an die Standards und entfernt proprietäre erweiterungen (siehe IE 8)

Nachtrag vom Samstag:

Ich sagte das das bei CSS nicht ganz so kritisch ist, das vermittelt einen falschen eindruck. Wenn man sich im CSS auch an den Standard hält, hat man zumindest mit IE 8, Firefox, Chrome, Opera und Safari eher wenig probleme. Für die älteren IE Versionen gibt aber auch mittel und wege.

[QUOTE=csimon;10019]Standards sind dazu da das alle sie einhalten und sind absolut wichtige Bestandteile eines offenen Webs. Eben damit jeder Browser alles richtig anzeigt ist es unabdingbar Standards einzuhalten. Dies ist im Moment leider nur bei HTML komplett möglich, aber bei CSS geht durch den Release des IE 8 und dessen standardkonforme Interpretation von CSS 2.1 auch der Weg in diese Richtung.[/QUOTE]
Dir browser zeigen das ja richtig an…

[QUOTE=csimon;10019]Stell dir mal vor der Google Robot spidert über deine Seite, stößt auf das Marquee element, und überspringt dieses, weil er es nicht kennt da es ein nicht im HTML Standard vorkommendes Element ist. Dann wird kein einziger Link im Live-Shopping gespidert. Wenn das mit Javascript gelöst wäre, wäre das zwar auch nicht ganz barrierefrei, aber zumindest bestünde dort nicht die gefahr das Screenreader oder eben Robots das Element ignorieren. Das ist nur ein Beispiel, ich weiss nicht genau was der Google Robot mit kaputtem HTML anstellt, ich vermute allerdings das er das nicht gerade honoriert, das die Syntax kaputt ist. Grade Google achtet stark auf die Einhaltung von Webstandards, das vertritt man auch nach aussen und dafür ist man auch bekannt.[/QUOTE]
Von den Google Programmierkünsten hälts Du wohl nicht viel.

Warum um alles in der Welt sollte der Robot alles innerhalb eines nicht-Standard-Tags ignorieren???

Das ist doch mutwillig an den Haaren herbeigezogen!

Robots arbeiten wie Browser: sie bauen das DOM (Document Object Model) der Seite auf. Und schauen sich dann die Inhalte der einzelnen HTML-Nodes an, ob da ein für sie interessanter Tag ist. Und selbst wenn ein nicht standardisierter oder einfach falsch geschriebener Tag gefunden wird, dann wird der einfach ignoriert, und weiter geht die Untersuchung.

Google hat sicher keinen “Strafmodus” für nicht-standard oder falsche Tags. Sonst dürfte keine einzige ebay-Auktion und kein einziges Amazon-Angebot im Index sein.

[QUOTE=csimon;10019]Das hat absolut nichts mit technologischer Onanie zu tun, sondern einfach mit offenem Barrierefreiem Web. Bei CSS ist das was anderes, das ist nur layout, die Struktur allerdings ist in HTML realisiert und das ist es worauf es Robots und Screenreadern ankommt. Zudem können HTML Fehler auch zu darstellungsfehlern führen, wie zum beispiel das ein browser in den Quirks Modus zurück geworfen wird und sich anders verhält als sonst.[/QUOTE]
Hat es doch. Die Browser sind ja so verständnisvoll…

Wenn das HTML natürlich so kaputt ist, dass der Browser nix mehr versteht, ist das etwas anderes.

Aber wir diskutieren ja im Moment darüber, ob man nicht-standard-Tags, die alle Browser verstehen (wie z.B. MARQUEE) verwenden soll oder nicht.

[QUOTE=csimon;10019]Amazon und eBay sind aber nicht deine Kunden, amazon und ebay sind so große namen das sie allein schon wegen der gigantischen Relevanz so hoch in Google stehen. Die Kunden die von dir ein Template möchten, sind nicht amazon und ebay, und da ist jeder Link den Google “frisst” bares geld.[/QUOTE]
Wenn die Browser und Robots das kaputte HTML von Amazon und ebay nicht verstehen würden, könnte auch die “gigantischen Relevanz” der beiden nicht erreichen, dass eine eBay-Auktion oder Amazon-Angebot richtig dargestellt wird, oder es in den Google-Index schafft.

[QUOTE=csimon;10019]Dann schau mal wer im W3 Consortium so sitzt. Du findest dort alle Browserhersteller wieder und mittlerweile hält sich sogar Microsoft an die Standards und entfernt proprietäre erweiterungen (siehe IE 8)

http://www.w3.org/Consortium/Member/List[/QUOTE]
Natürlich sind die alle da drin. Um dann bei jedem Release ihrer Browser wieder ein paar proprietäre Schmankerln einzubauen…

[B] Wie gehen denn die orthodoxen Standard-Verfechter eigentlich mit dem “HTML5”-Problem um?[/B]

“HTML5” ist einige Jahre von der Akzeptanz als Standard entfernt (man redet da tatsächlich vom Jahr [B]2020(!)[/B]).

Nun ist es aber so, dass die Browser teilweise schon einige in HTML5-Drafts niedergelegte HTML5-Elemente verwenden. ( http://radar.oreilly.com/2009/05/google-bets-big-on-html-5.html ).

Und in spätestens 2 bis 3 Jahren werden alle Browser den HTML-5-Vorschlag komplett implementieren…

Der orthodoxe Standardgläubige darf ja dann bis 2020 diese schönen neuen Funktionen nicht verwenden, oder darf er?

Weil, nach Deiner Interpretation, er ja sonst aus dem Google-Index fallen würde (“SEO-Probleme”), oder Menschen mit Beeinträchtigungen keine der HTML5-verwendenden Seiten mehr besuchen könnten (“Barrierefreiheit”). (Und überhaupt die Welt sonst untergeht.)

[B]Natürlich wird das nicht so sein.[/B]

Die Browser und die Robots werden das weit vor 2020 alles verstehen.

Standards entstehen ja auch oft “ex post”, also hinterher.

Jemand denkt sich was Tolles aus (z.B. Javascript von Netscape, das MARQUEE-Tag von Microsoft, die AJAX-Technologie von Microsoft), alle anderen finden das gut, und bauen es in ihre Produkte ein.

Javascript hat es mittlerweile zum Standard geschafft, die AJAX-Technologie bis heute nicht! Und jeder benutzt die AJAX-Technologie ohne Ende. Was man, wenn man Deiner Argumentation folgt, ja gar nicht dürfte…

Aber, pragmatisch, wie die meisten Menschen sind, sagt man sich da: coole Funktion, alle Browser können das, also nix wie her damit!

(Bevor ich es vergesse: das beliebte MARQUEE-Tag hat es in den Vorschlag zu HTML5 geschafft! ( http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete-features.html#the-marquee-element-0
http://www.w3.org/TR/css3-box/#marque ) Es wird zwar als “obsolet” eingestuft, aber wohl nur, weil in CSS3 eine besser geeignete Vorgehensweise definiert ist. ( http://www.w3.org/TR/css3-box/#marque ) Aber es wird dann vermutlich den Rang eines Standard-Elementes haben.)

Auch der PC selbst ist ja nur ein Quasi-Standard (“Industrie-Standard”): IBM hat ihn definiert, und alle haben ihn ganz schnell adoptiert.

Oder auch der schnelle WLAN 802.11n Standard-Vorschlag. Alle Hersteller verwenden ihn, viele packen noch ein paar proprietäre Verbesserungen dazu, und keiner sagt: das dürft ihr aber nicht…

Warum machen die das? Nun, wohl weil es dem technologische Fortschritt dient!

Wenn ich so die orthodoxen Verfechter von “Nur-Standard-HTML” und “Nur-tabellenfreie-Seiten” höre, die quasi den Zusammenbruch des Web heraufbeschwören, wenn man wagt, dagegen zu verstoßen (und dazu immer die Knüppel “SEO-Probleme” und “Barrierefreiheit” in der Tasche haben, ohne auch nur annäherungsweise einen Beleg für die Richtigkeit ihrer Behauptung liefern zu können), fällt mir immer die Analogie zu den orthodoxen Juden und Muslimen ein.

Auch die legen, ihrem “Standard” (Altes Testament, Koran) [B]buchstäblich[/B] folgend, oft Verhaltensweisen an den Tag, die den aufgeklärteren Mitbürgern irgendwie fast lächerlich erscheinen. (z.B. dass eine Jüdin unbedingt eine Perücke, oder eine Muslima dieses Ganzkörperkondom (genannt “Burka”) tragen muss.)

Nun sage ich ja ganz und gar nicht, dass man Standards nicht einhalten sollte.

Natürlich sollte man das, aber man sollte sich [B]keinesfalls [/B]davon einengen lassen.

Wenn es bessere und/oder attraktivere “[B]Industriestandards[/B]” gibt, dann nix wie her damit!

Und: Die Web-Welt wird aber nicht untergehen, wenn man das tut.

Mich ärgert einfach die Chuzpe, mit der, warum auch immer, ganz schlimme Konsequenzen in den Raum gestellt werden, wenn man etwas flexibler an die Dinge heran geht, und von der “reinen Lehre” abweicht. Und das, ohne auch nur annäherungsweise diese angedrohten Konsequenzen irgendwie belegen zu können.

[B] Also, Leute, lasst Euch da nicht irre machen:[/B]

Google und die Browser bleiben Eure Freunde, auch wenn Eure Seite nicht-standard (oder gar schlicht falsche) Elemente enthält.

Oder ein MARQUEE-Tag oder die AJAX-Technologie verwendet.

So, und das war mein letztes Posting zu diesem Thema, weil csimon und ich da wohl nie zu einem Konsens gelangen werden…

[QUOTE=avenger;10116]So, und das war mein letztes Posting zu diesem Thema, weil csimon und ich da wohl nie zu einem Konsens gelangen werden…[/QUOTE]
Einer muss noch sein…

Will ja nicht den [B]Beweis[/B] schuldig bleiben, dass Browser (und Robots) keinerlei Probleme mit [B]nicht-standard [/B]oder gar [B]falschen [/B]Tags haben…

In folgender Seite wird der Tag “kaputt” verwendet, der weder [B]standard [/B]noch [B]richtig [/B]ist…

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="de">
<html>
    <head>
        <meta name="GENERATOR" content="Microsoft FrontPage 6.0">
        <meta name="ProgId" content="FrontPage.Editor.Document">
        <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
        <style type="text/css">
        #kaputter_tag {
            position:absolute;
            top:100px;
            left:100px;
            border:1px solid black;
            padding:10px;
        }
        </style> 
        <title>Kaputter Tag</title>
    </head>
    <body>
        <kaputt id="kaputter_tag">
            <h1>Das ist ein H1 in einem kaputten Tag</h1>
            <a>Das ist ein Link in einem kaputten Tag</a>
            <p>
                Das ist ein Bild in einem kaputten Tag <img src="http://www.oxid-esales.com/files/logo-claim-header.png" alt="" />
            </p>
        </kaputt>
    </body>
</html>

FireFox rendert die Seite wie folgt:

Wir sehen, dass wir nichts sehen!

Diese falsche Seite wird absolut perfekt dargestellt, man kann das “kaputt”-Tag auch ganz normal stylen.

Und FireBug zeigt im unteren Bild-Drittel die Dokumenten-Struktur (DOM) so an, wie wir das auch bei einem richtigen Tag (z.B. “div”) statt “kaputt” erwarten würden.

[B]Ergo:[/B]

“[B]Nicht-Standard[/B]” oder [B]falsche[/B] Tags beeindrucken einen Browser (und einen Robot) überhaupt nicht!

Die Behauptung, dass z.B. ein “[B]Marquee[/B]”-Tag bewirken würde, dass alles innerhalb dieses Tags keine Berücksichtigung mehr finden würde, ist somit [B]schlicht und einfach frei erfunden und falsch[/B]!

[B]Q.E.D.[/B]