LESS löst die scheiß Probleme mit Vendor Prefixes

[King Lui*]

Wer less nicht kennt liest bitte hier: lesscss.org

In Less kann ich alle Befehle die ein Vendor Prefix erfordern, in ein Mixin packen, bsp.:

.box-shadow(@params) {
-webkit-box-shadow: @params;
-moz-box-shadow: @params;
-ms-box-shadow: @params;
-o-box-shadow: @params;
box-shadow: @params;
}

.sampleClass {
.box-shadow(2px);
}


wird geparsed zu:

.sampleClass {
-webkit-box-shadow: 2px;
-moz-box-shadow: 2px;
-ms-box-shadow: 2px;
-o-box-shadow: 2px;
box-shadow: 2px;
}

[Gungosh]

Das ist praktisch, wird aber die Schnarchnasen auch nicht aufwecken...

Warum sind Vendor-Präfixe eigentlich erforderlich? Könnten Browser nicht von vornherein den Original-Attributnamen unterstützen, auch wenn ein Attribut noch nicht standardisiert ist?

Was übersehe ich bei dieser dummen Frage? :-)

_____________________________
<loriot>Ach was?</loriot>

[LH]

Gungosh schrieb:
--------------------------------------------------------------------------------
> Das ist praktisch, wird aber die Schnarchnasen auch nicht aufwecken...
>
> Warum sind Vendor-Präfixe eigentlich erforderlich? Könnten Browser nicht
> von vornherein den Original-Attributnamen unterstützen, auch wenn ein
> Attribut noch nicht standardisiert ist?
> Was übersehe ich bei dieser dummen Frage? :-)

Weil sich der Standard manchmal noch ändern kann, und man dann nicht eine falsche Syntax mal unterstützt haben will. Sonst arbeitet das gleiche Keyword auf einmal anders, bzw. braucht andere Parameter, das kann zu unvorhergesehenen Problemen führen.
Ihre eigenen, mit prefix Versehenen, Keywords würden hingegen ja nicht mehr einfach geändert, selbst wenn der Standard am Ende unterschiedlich ist.

Allerdings: oft kommt das nicht gerade vor.

[Mingfu]

Gungosh schrieb:
--------------------------------------------------------------------------------
> Warum sind Vendor-Präfixe eigentlich erforderlich? Könnten Browser nicht
> von vornherein den Original-Attributnamen unterstützen, auch wenn ein
> Attribut noch nicht standardisiert ist?

Es gab in der Vergangenheit mehrere Fälle bei denen Browser-Hersteller vor der Standardisierung ein Attribut unterschiedlich interpretiert haben. Das gäbe dann ein schönes Chaos, wenn das dann unter dem gleichen Namen von jedem Browser unterschiedlich interpretiert wird. Da wäre man wieder auf dem Niveau von Browserweichen für den Internet Explorer vor mehreren Jahren angekommen...

Auch war es in der Vergangenheit in mehreren Fällen so, dass Browserhersteller für den gleichen Sachverhalt verschiedene Namen verwendeten. Dann würde also für jeden Browser ein anderer Attributname nötig sein, um die gleiche Darstellung zu erreichen - da hätte man auch nichts gewonnen.

Nein, das ist schon vollkommen in Ordnung, dass die Browserhersteller nicht standardisierte Attribute mit einem browserspezifischen Präfix versehen. Der Fehler liegt hier allein bei den Webdesignern, bei niemandem sonst. Nicht standardisierte Attribute sollten für normale Webentwicklung einfach tabu sein. Die kann man für Studien, Demonstrationen oder Tests einsetzen - im Produktiveinsatz haben sie aber nichts zu suchen.

[zZz]

geschmacksfrage, ich verwende lieber Sass

http://sass-lang.com/

[Sprachwissenschaftler]

Hm, darf ich mal fragen, inwieweit dass die "scheiß Probleme mit Vendor Prefixes" löst? Im geparsten CSS stehen sie doch immer noch?!

[ruamzuzler]

Mingfu schrieb:
> Nein, das ist schon vollkommen in Ordnung, dass die Browserhersteller nicht
> standardisierte Attribute mit einem browserspezifischen Präfix versehen.
> Der Fehler liegt hier allein bei den Webdesignern, bei niemandem sonst.
> Nicht standardisierte Attribute sollten für normale Webentwicklung einfach
> tabu sein. Die kann man für Studien, Demonstrationen oder Tests einsetzen -
> im Produktiveinsatz haben sie aber nichts zu suchen.

Das ist ja das Problem, sie sind ja im Produktiveinsatz und Tools wie Less beflügeln den Trend auch noch.
Die Lösung ist den Browserherstellern wohl zu einfach:
Statt auf die Schnarchnasen beim W3C zu setzen, sollten sie sich an den runden Tisch setzen, Verhalten und Syntax ausschnapsen und dann ohne Prefixe so umsetzen, dann gibt es auch kein Problem.
Es ist mehr als lächerlich, dass die Definition von so trivialen Dingen wie runden Ecken mehrere Jahre dauern.

[ruamzuzler]

Sprachwissenschaftler schrieb:
--------------------------------------------------------------------------------
> Hm, darf ich mal fragen, inwieweit dass die "scheiß Probleme mit Vendor
> Prefixes" löst? Im geparsten CSS stehen sie doch immer noch?!

Das Problem ist insoweit gelöst, als der ignorante Webentwickler nicht an alle Prefixes denken muss, das mach stellvertretend Less

[Sprachwissenschaftler]

Soso, und wenn ich als Webentwickler

.box-shadow(@params) {
-webkit-box-shadow: @params;
-o-box-shadow: @params;
box-shadow: @params;
}

.sampleClass {
.box-shadow(2px);
}

schreibe kümmert sich LESS/SASS darum, dass die fehlenden Vendor Prefixes eingefügt werden?

[Gungosh]

Okay, verstehe, danke :-)

Mingfu schrieb:
--------------------------------------------------------------------------------
> [...]
> Der Fehler liegt hier allein bei den Webdesignern, bei niemandem sonst.
> Nicht standardisierte Attribute sollten für normale Webentwicklung einfach
> tabu sein. Die kann man für Studien, Demonstrationen oder Tests einsetzen -
> im Produktiveinsatz haben sie aber nichts zu suchen.

Jupp.

Ich selbst hab grad wieder von "border-radius" umgestellt auf Grafiken, damit auch XP-IE-User "runde Ecken" sehen.
Ziemlich lästige Entscheidung von MS, CSS3 im IE8 nicht vollständiger zu supporten.

_____________________________
<loriot>Ach was?</loriot>

[Mingfu]

ruamzuzler schrieb:
--------------------------------------------------------------------------------
> Es ist mehr als lächerlich, dass die Definition von so trivialen Dingen wie
> runden Ecken mehrere Jahre dauern.

Man kann es aber auch andersherum sehen: Erfordern runde Ecken wirklich ein sofortiges Handeln? Das ist nun nichts, was lebensnotwendig ist. Mit derartigem Eye-Candy kann man doch wirklich warten bis er eventuell mal einheitlich spezifiziert ist. Auch mit eckigen Ecken kann eine Website funktionieren, lesbar und übersichtlich sein.



1 mal bearbeitet, zuletzt am 30.04.12 11:32 durch Mingfu.

[dabbes]

Der faule Webentwickler wird weder die Prefixe richtig benutzen, noch less richtig verwenden ;-)

Zweites Problem: Der Webentwickler wird i.d.R. einmal für eine Tätigkeit bezahlt, dann ist das Projekt online, sollte sich einige Monate später was ändern, wird meistens die Website ja nicht mehr angepasst.

[DASPRiD]

Deshalb lieber entweder CSSCrush (serverseitig: http://the-echoplex.net/csscrush/ ) oder Prefix-Free (clientseitig: http://leaverou.github.com/prefixfree/ ) einsetzen, und garnicht mehr über Prefixe oder ähnliches nachdenken.

[anonym]

ruamzuzler schrieb:
--------------------------------------------------------------------------------
> Die Lösung ist den Browserherstellern wohl zu einfach:
> Statt auf die Schnarchnasen beim W3C zu setzen, sollten sie sich an den
> runden Tisch setzen, Verhalten und Syntax ausschnapsen und dann ohne
> Prefixe so umsetzen, dann gibt es auch kein Problem.
> Es ist mehr als lächerlich, dass die Definition von so trivialen Dingen wie
> runden Ecken mehrere Jahre dauern.

das gibts schon und nennt sich whatwg. da sitzen zumindest die entwickler von webkit, gecko und presto drin und diskutieren den ganzen kram.

aller paar jahre mach das w3c da dann mal nen standart draus...

[King Lui*]

wenn man less benutzt und dann zu doof ist sich vollständige mixins zu schreiben ist man selbst schuld, man kann genug mixins.less bei google finden wo alles drinne ist