expertenaustausch > comm.* > comm.infosystems.www.authoring.misc

Andreas Borutta (12.11.2010, 18:05)
Moin,


bietet ein Skript (12KB) an, welches es erlaubt, einige
CSS3-Eigenschaften (wie z.B. border-radius) auch mit IE 6-8
einzusetzen.

Wie bewertet ihr den Ansatz?
Besitzt jemand Erfahrung damit und kann etwas zur Stabilität bzw. zu
Fallstricken sagen?

Andreas
Arno Welzel (12.11.2010, 22:58)
Am 2010-11-12 17:05, schrieb Andreas Borutta:

>
> bietet ein Skript (12KB) an, welches es erlaubt, einige
> CSS3-Eigenschaften (wie z.B. border-radius) auch mit IE 6-8
> einzusetzen.
> Wie bewertet ihr den Ansatz?


Na ja... ein knapp 100 KB großes JavaScript-Monster, das selbst
komprimiert noch fast 28 KB braucht, nur um runde Ecken zu bekommen.

> Besitzt jemand Erfahrung damit und kann etwas zur Stabilität bzw. zu
> Fallstricken sagen?


Ich würde darauf verzichten. CSS3 ist ohnehin noch nicht allgemein
üblich und auch bei anderen Browsern nur durch Workarounds nutzbar,
indem man "-moz-" oder "-webkit-" vor die entsprechenden
CSS-Eigenschaften schreibt.
Andreas Borutta (13.11.2010, 01:20)
Arno Welzel schrieb:

> Na ja... ein knapp 100 KB großes JavaScript-Monster, das selbst
> komprimiert noch fast 28 KB braucht, nur um runde Ecken zu bekommen.


Komprimiert ausgeliefert sind es laut FAQ nur 12KB.
Das scheint mir eine zu vernachlässigende Größe zu sein.

Ich kann jedenfalls Markup-Layout nicht leiden und würde - so das
Ganze stabil liefe - einer solchen Variante den Vorzug geben.

>> Besitzt jemand Erfahrung damit und kann etwas zur Stabilität bzw. zu
>> Fallstricken sagen?

> Ich würde darauf verzichten.


Für meine eigenen Sites halte ich das ebenso.

Andreas
Thomas 'PointedEars' Lahn (13.11.2010, 09:09)
Andreas Borutta wrote:

> Arno Welzel schrieb:
> Komprimiert ausgeliefert sind es laut FAQ nur 12KB.
> Das scheint mir eine zu vernachlässigende Größe zu sein.


Woher willst Du wissen, dass der UA gzip unterstützt? Woher willst Du
wissen, was bei der tatsächlichen Übertragungsgeschwindigkeit und einem
evtl. Volumentarif zuviel ist? Eben.

Ich hab' mir das Script noch nicht angesehen; meine Kristallkugel sagt mir
aber, dass dort Browser-Sniffing verwendet wird. Und spätestens da sollten
bei Dir die Alarmglocken klingeln.

> Ich kann jedenfalls Markup-Layout nicht leiden und würde - so das
> Ganze stabil liefe - einer solchen Variante den Vorzug geben.


Im Web gilt: Womit Du als Autor gut leben kannst, ist _nicht_ der Maßstab!
Das solltest Du inzwischen aber wissen.

PointedEars
Thomas 'PointedEars' Lahn (14.11.2010, 01:41)
Thomas 'Ingrid' Lahn wrote:

> Andreas Borutta wrote:
> Woher willst Du wissen, dass der UA gzip unterstützt? Woher willst Du
> wissen, was bei der tatsächlichen Übertragungsgeschwindigkeit und einem
> evtl. Volumentarif zuviel ist? Eben.
> Ich hab' mir das Script noch nicht angesehen; meine Kristallkugel sagt mir
> aber, dass dort Browser-Sniffing verwendet wird. Und spätestens da
> sollten bei Dir die Alarmglocken klingeln.


Ich habe mir nun die gezeigte Lösung angesehen und kann meine *allgemeine*
Empfehlung dagegen zurückziehen: Es werden dort per .htc Behaviors
definiert; die .htc-Dateien lassen sich somit über Conditional Comments
einbinden, wodurch an dieser Stelle kein Browser-Sniffing nötig ist.
Ausserdem handelt es sich bei der sog. "Komprimierung" nicht um
Komprimierung (z.B. gzip), sondern um sog. Minimierung (hauptsächlich
Entfernung von Whitespace). D.h. der Sourcecode ist *unkomprimiert* "nur"
23 KiB gross; mit gzip-Unterstützung auf Clientseite würde er noch kleiner
sein. (Allerdings lässt sich nur mit Mühe überprüfen, ob die minimierte
Version dem Originalcode funktionell entspricht.)

Eine Empfehlung für diese Lösung kann ich Dir aber auch nicht geben.

Erstens bleibe ich dabei, dass man im Web möglichst wenig Annahmen über die
Laufzeitumgebung des Benutzers treffen sollte; was bei DSL auf dem PC
Peanuts sind, sieht bei einem mobilen Volumentarif (einen solchen dürften
die meisten Mobilnutzer haben) schon ganz anders aus. Dies sowohl was die
Grösse und damit in Zusammenhang stehen die Downloadzeit betrifft, als auch
die Darstellungskomplexität (bei Mobilgeräten ist die Downloadzeit grösser,
weil die Verbindungen eher langsam sind; dafür darf die
Darstellungskomplexität nicht zu hoch sein, weil die Geräte nicht so
leistungsfähig sind wie ein PC bzw. falls sie eine vergleichbare Leistung
böten, der Akku schneller leer wäre).

Zweitens lässt mich der Quelltext doch etwas an der Kompetenz des Autors
zweifeln (hier gibt es also ? leider ? mal wieder kaum Überraschungen).
Beispiel:

var PIE = window['PIE'];

if( !PIE ) {
PIE = window['PIE'] = {
CSS_PREFIX: '-pie-',
STYLE_PREFIX: 'Pie',
CLASS_PREFIX: 'pie_'
};

Es sollte allgemein bekannt sein, dass in MSHTML Elemente mit Namen oder ID
als Eigenschaften das window-Objekts abgebildet werden. Dies trifft
natürlich auch auf Elemente mit Namen oder ID "PIE" zu; in diesem Fall
führte diese Zuweisung an window['PIE'] (am Anfang des Scripts) bereits zu
einem Laufzeitfehler, wenn es ein solches Element im Dokument gäbe. Dabei
ist diese fehlerträchtige Duplikation völlig unnötig: Man könnte sich
einfach die Initialisierung bei der Deklaration der Variablen `PIE' sparen,
deren Wert abfragen und die Variable falls nötig initialisieren.

Browser-Sniffing (navigator.userAgent) habe ich zum Glück nicht gefunden,
jedoch sinnfreie Objekt-Inferenz:

// Detect IE6
if( !window.XMLHttpRequest ) {
PIE.isIE6 = true;

// IE6 can't access properties with leading dash, but can without it.
PIE.CSS_PREFIX = PIE.CSS_PREFIX.replace( /^-/, '' );
}

// Detect IE8
PIE.ie8DocMode = element.document.documentMode;
PIE.isIE8 = !!PIE.ie8DocMode;

Der Autor mag zum Beispiel einmal erklären, was das Vorhandensein von
`XMLHttpRequest' (JScript) mit dem Rendering-Modus (MSHTML) zu tun haben
soll. Und warum er das nicht besser über Conditional Comments löst. Mir
erschliesst sich diese "Logik" jedenfalls nicht.

Der Color-Datentyp ist nett, aber unsinnig implementiert. Weshalb speichert
er nicht per Setter (so wie ich) einfach die Werte der Farbkomponenten und
den Alpha-Wert? Stattdessen wird *jedes Mal* der Farbstring geparst und das
Ergebnis in *dieselbe* Eigenschaft geschrieben. Nur gut, dass es in .htc-
Scripts keine konkurrenzierenden Zugriffe gibt ? Moment, es gibt sie!

<PUBLIC:ATTACH EVENT="onresize" FOR="element" ONEVENT="update()" />
<PUBLIC:ATTACH EVENT="onresize" FOR="window" ONEVENT="update()" />
<PUBLIC:ATTACH EVENT="onmove" FOR="element" ONEVENT="update()" />

Ich könnte den Quelltext noch weiter sezieren, aber das wäre hier off-topic.
Zusammenfassend genügt es wohl zu sagen, dass der Ansatz ohne mindestens
ein teilweises Rewrite bestenfalls fehlerträchtig ist. Wohl auch ein Grund,
weshalb das noch "Beta" ist.

PointedEars
Thomas 'PointedEars' Lahn (14.11.2010, 01:45)
Thomas 'Ingrid' Lahn wrote:

> Thomas 'Ingrid' Lahn wrote:
> Ich habe mir nun die gezeigte Lösung angesehen und kann meine *allgemeine*
> Empfehlung dagegen zurückziehen: Es werden dort per .htc Behaviors
> definiert; die .htc-Dateien lassen sich somit über Conditional Comments
> einbinden, wodurch an dieser Stelle kein Browser-Sniffing nötig ist.
> Ausserdem handelt es sich bei der sog. "Komprimierung" nicht um
> Komprimierung (z.B. gzip), sondern um sog. Minimierung (hauptsächlich
> Entfernung von Whitespace). D.h. der Sourcecode ist *unkomprimiert* "nur"
> 23 KiB gross; mit gzip-Unterstützung auf Clientseite würde er noch kleiner
> [?]


Korrektur: Die minimierte PIE.htc hat _27.6 KiB_ (so wie Arno schrieb).
In der FAQ stünde also ? sofern korrekt zitiert ? in jedem Fall
Unsinn/Irrelevantes.

PointedEars
Andreas Borutta (14.11.2010, 01:57)
Thomas 'PointedEars' Lahn schrieb:

>>>>>


> Ich habe mir nun die gezeigte Lösung angesehen und kann meine *allgemeine*
> Empfehlung dagegen zurückziehen: Es werden dort per .htc Behaviors
> definiert; die .htc-Dateien lassen sich somit über Conditional Comments
> einbinden, wodurch an dieser Stelle kein Browser-Sniffing nötig ist.


[...]

Vielen Dank für Dein ausführliches Posting und die Bewertung.

Andreas
Thomas 'PointedEars' Lahn (14.11.2010, 13:07)
Andreas Borutta wrote:

> Thomas 'PointedEars' Lahn schrieb:
> [...]
> Vielen Dank für Dein ausführliches Posting und die Bewertung.


Gern geschehen. Hoffentlich berücksichtigst Du aber auch

>> Eine Empfehlung für diese Lösung kann ich Dir aber auch nicht geben. [?]


bei Deiner Entscheidung.

PointedEars
Andreas Borutta (14.11.2010, 15:47)
Thomas 'PointedEars' Lahn schrieb:

> Gern geschehen. Hoffentlich berücksichtigst Du aber auch


Sie fließt mit ein, klar.

Besonders Dein Argument "Leistungsfähigkeit von Mobilgeräten und
Darstellungskomplexität" hat Gewicht.

Ich kann jedoch nicht beurteilen, ob es für den Nutzer wahrnehmbare
(tm) Performanceunterschiede gibt, wenn eine Seite einmal runde Ecken
via Grafiken plus Präsentationsmarkup und das andere Mal via
"border-radius" und pie.htc darstellen muss.

Über den Einzelfall hinaus mag ich an solchen Ansätzen, dass solche
Werkzeuge (mal angenommen sie laufen stabil) die Verbreitung von CSS3
beschleunigen können, weil sie die Hürde für die Autoren herabsetzen,
entsprechende Gestaltvarianten einzusetzen.

Die Nachbildung von CSS3 via Präsentationsmarkup und mehr oder weniger
aufwändigem CSS2 macht wohl kaum einem Autor Freude.

Andreas
Thomas 'PointedEars' Lahn (19.11.2010, 23:29)
Andreas Borutta wrote:

> Thomas 'PointedEars' Lahn schrieb:
> Sie fließt mit ein, klar.
> Besonders Dein Argument "Leistungsfähigkeit von Mobilgeräten und
> Darstellungskomplexität" hat Gewicht.
> Ich kann jedoch nicht beurteilen, ob es für den Nutzer wahrnehmbare
> (tm) Performanceunterschiede gibt, wenn eine Seite einmal runde Ecken
> via Grafiken plus Präsentationsmarkup und das andere Mal via
> "border-radius" und pie.htc darstellen muss.


Das kannst Du dir anhand der technischen Spezifikationen aber leicht
ausrechnen.

> Über den Einzelfall hinaus mag ich an solchen Ansätzen, dass solche
> Werkzeuge (mal angenommen sie laufen stabil) die Verbreitung von CSS3
> beschleunigen können, weil sie die Hürde für die Autoren herabsetzen,
> entsprechende Gestaltvarianten einzusetzen.


Sie eliminieren aber auch bzw. reduzieren stattdessen den Bedarf für
Benutzer, sich einen mehrheitlich standardkonform arbeitenden Browser zu
besorgen (bzw. besorgen zu lassen), der CSS3 nativ unterstützt, und führen
in diesem Fall sogar dazu, dass immer mehr *aktuelle* Websites nur noch mit
clientseitigem Scripting überhaupt nutzbar sind, was dann meist zu Lasten
der Interoperabilität geht. Ganz so einfach wie Du es Dir vorstellst, ist
die Sache also nicht.

> Die Nachbildung von CSS3 via Präsentationsmarkup und mehr oder weniger
> aufwändigem CSS2 macht wohl kaum einem Autor Freude.


Kommt darauf an. Deswegen aber lässt Mann[tm] das meist und teilt $KUNDE
mit: "Dieser Browser kann das leider nicht bzw. es ist nicht möglich, das so
zu programmieren" ($KUNDE würde den Unterschied nicht verstehen), "dass es
wirklich überall funktioniert." Es sei denn, $KUNDE zahlt für die
Optimierung.

PointedEars
Ähnliche Themen