Vergesst Browser-Hacks in Contao 2.10

[contao.org]

Die bevorstehende Contao-Version 2.10 enthält ein sehr mächtiges neues Feature, dass CSS-Hacks, Conditional Comments und andere Browserweichen überflüssig macht: Es fügt dem Body-Tag in Abhängigkeit des Betriebssystems und des Browsers verschiedene CSS-Klassen hinzu.

Ganzen Beitrag zu 'Vergesst Browser-Hacks in Contao 2.10' lesen

[Alexander]

Super Sache.

Erstmal .ie6 #wrapper {display: none;} :-D

[backbone]

Ein richtiger Schritt, aber warum selbst eine Umsetzung bauen, wenn es schon gute für Contao gibt?

Wieso wurde hier nicht auf (ähnliche) Integrierung wie bei BrowserCSS von ETES gesetzt? Zumindest die externe Browser.php, welche da die Detection macht, ist sicher etwas ausgereifter als eigener Code.

Außerdem fallen mir bei der Umsetzung gleich 4-5 Dinge auf, die BrowserCSS bereits richtig macht (zumindest in einer neueren Version die ich davon erstellt habe und ETES zukommen lassen habe... Ich hänge die auch hier mal an).
Das sind unter anderem:
- serverseitiges Caching (InsertTag workaround)
- HTTP-Caching (Vary-Header)
- Nichtverwendung von Browser.php aus der Erweiterung browserdetection (http://chrisschuld.com/projects/brow...wser-from-php/)
- Option zur Integration im HTML-Tag (nicht-valide, ist optional, wurde im Ticketsystem von BrowserCSS gewünscht)
- Funktioniert ohne Anpassung der fe_page.tpl (wird über den generatePage-Hook injected)

(jan theofel wollte die neue BrowserCSS version schon vor einer weile ins Repo bringen, aber hat es bisher noch net geschafft)

[FloB]

Abgesehen davon, dass CSS-Hacks bald der Vergangenheit angehören sollten (dank endlich flächendeckend standardkompatibler Browser – eigentlich sollte man jetzt schon darauf verzichten, für IE<9-Korrekturen gibt es die ConditionalComments!), bitte ich um eine Änderung der Ausführungsreihenfolge. In Anbetracht dessen, dass im ungünstigsten Fall bis zu 20 RegEx'e durchgeführt werden, sollten die Abfragen in der Reihenfolge auftreten, mit der in etwa (statistisch gesehen) eine Testreihenfolge erwartet werden kann.

Also (IMO): Bei OS Reihenfolge: Win, Mac, Mobile (Apple, Android, Blackberry, Palm), Unix, Rest (Mobile vllt. sogar höherwertig?), bei Browsern: IE, Fx, Chrome, Safari, Opera, Rest.

Ich möchte folgende Anmerkungen zur Diskussion stellen:

• Was ist mit Robots? Insbesondere Google mag ja Geschwindigkeit und misst diese durchaus im Millisekundenbereich, und zwanzig RegEx'e sind einfach zwanzig zu viel. Außerdem gehen manche Robots "Undercover" an die Arbeit, können so die Browserweiche erkennen und abstrafen (kam schonmal vor).
• Kann man die RegEx'e zusammenfassen, wenn ja, wie, und wie wird dadurch Ausführungszeit und ggf. Speicherverbrauch beeinflusst?
  IMO müsste doch sowas gehn:
  

  ~(MSIE|Firefox|Safari|Blubb)~i

  Das Ergebnis zieht man dann aus $1. Macht aus 10 RegEx'n schonmal einen.
• Die Krücke mit str_replace und __ua__ im Template müsste sich sauberer lösen lassen. $this->class geht ja leider wegen Cache nicht. Aber warum nicht gleich einen InsertTag nutzen? Die werden ja eh schon ausgeführt und eingesetzt, wenn man hier jetzt noch einen mehr einsetzt, sollte das IMO Performance-technisch weniger Auswirkungen haben, als die aktuelle Variante. Müsste man aber mal durchrechnen.

Mir gefällt dieses Feature nicht, da ich befürchte, dass es unsauberes / falsches Verhalten begünstigen kann (hat in den 90ern schonmal zu Problemen geführt). Manche finden es wahrscheinlich ganz nützlich. Insbesondere um spezielle Mobilseiten auszuliefern, gibt es aber mE bessere und sauberere Möglichkeiten (dezidierte Seiten, Media Queries, StyleSheet media).

[backbone]

Die Ausführungsreihenfolge zur KORREKTEN ist nicht trivial zu bestimmen, da manche Browser (zB Opera) etwas im HTTP-Agent mitschicken, was sonst der IE mitschickt etc.
Auf all dies wurde in der von mir genannten externen Klasse beachtet.

Die Ausführungsgeschwindigkeit lässt sich nun mal nicht groß reduzieren in diesem Fall, es sei denn man geht das Risiko ein, einen False-Positive zu haben.
Außerdem Sucht man hier auf Strings die im Schnitt 100-200 Byte lang sind. Das heißt im Worstcase werden 4KiB durchsucht (avg. 1KiB), was im Vergleich zu den InsertTags, das mit einer RegEx auf den Ausgabedokumenten sucht, die im Schnitt bei 10KiB+ liegen.

Die von dir angesprochene mögliche Abwertung durch die Suchmaschine halte ich für nicht möglich. Google bewertet hier inhaltliche Veränderung negativ und interessiert sich nicht für eine CSS-Klasse die sich geändert hat.

ConditionalComments finde ich wesentlich "unsauberer" und funktionieren nur mit IE.

Bezüglich der sauberen Integration: Siehe die von mir angehängte BrowserCSS-Erweiterung, welche vollständig ohne Stringsuchen auskommt (es sei denn es wird gecacht, dann wird die InsertTag Stringsuche genutzt, jedoch keine eigenen RegExe oder str_replace).

[dieselboy]

Prinzipiell finde ich die Entwicklung sehr positiv, die Browserdetection wird den meisten einiges an Arbeit abnehmen (können).

Allerdings gehört m.M.n. noch einiges mehr dazu, wenn ich eine Unterteilung zwischen einer "normalen" Seite und einer Mobilseite haben möchte. Oftmals sollen nicht alle Inhalte und Module, die es auf der normalen Seite gibt, auf der Mobilseite ausgegeben werden. Eine CSS-Definition a la

body.mobile .mod_irgendwas { display:none }

ist hier nicht das gelbe vom Ei, wird der Inhalt doch trotzdem geladen und verursacht Traffic und längere Ladezeiten. Ein zweiter Seitenbaum ist dann trotzdem nötig.

<offtopic>

Was ist mit Robots? Insbesondere Google mag ja Geschwindigkeit und misst diese durchaus im Millisekundenbereich, und zwanzig RegEx'e sind einfach zwanzig zu viel. Außerdem gehen manche Robots "Undercover" an die Arbeit, können so die Browserweiche erkennen und abstrafen (kam schonmal vor).

Prinzipiell stimme ich dir vollkommen zu, aber sollte es nicht eigentlich so sein, dass man eine Seite für einen bestimmten Zweck baut und für die Besucher, und nicht für Google? Wenn ich lese, dass Google Seiten "abstraft", weil Google etwas nicht gefällt, dann ist irgendwo irgendwas schief gegangen! Das ist für mich eine verkehrte Welt. Seit wann lässt man sich von einer Firma sagen, was gut und was schlecht ist?
</offtopic>

[FloB]

Nun, einen gewissen Umstand berücksichtigen ist nicht gleich für einen Browser/Robot optimieren. Generell hat dieselboy natürlich Recht, aber in diesem Fall ist das mE etwas ganz anderes.

Bez. user agent spoofing: Die Ausführungsreihenfolge sollte natürlich auf Basis von breiten statistischen Daten festgelegt werden. Ob da jetzt ein (vergleichsweise) unwichtiger user agent wie Opera in manchen Versionen andere ("falsche") Identifizierungsmerkmale sendet, ist eher irrelevant (außer natürlich für die evtl. falschen Klassen).

Bez. "Google-Problem": Ich kenn den Algorithmus nicht, aber möglich wäre, dass der Bot eine zu anderen Requests verschiedene Checksum herausbekommt, aber keine inhaltlichen Änderungen feststellt, und das allein schon negativ bewertet (Bot fühlt sich "verarscht"). Man könnte ja auch z. B. in externem CSS bestimmte Inhaltsbereiche aus- oder einblenden lassen (eben anhand des festgestellten user agent) und so Bots das präsentieren, was sie (nicht) sehen möchten (alter Trick, wird aber schon lange versucht automatisch zu erkennen). Klar, das ist alles reine Spekulation, aber möglich wäre es, wir wissen eben nicht, wie Bots reagieren. Deswegen bin ich eher gegen solche "überflüssigen" Spielereien (hier eben spezifische Body classes pro user agent*).

* Wenn das per JS umgesetzt wird, z. B. via Modernizr, ist das etwas anderes, da die Bots wohl JS in seltenen Fällen ausführen bzw. in die Wertung miteinbeziehen.

Bez. Geschwindigkeitseinfluss würde ich gerne ein paar Benchmarks sehen, damit wir da nicht blind irgendwas behaupten; meine Anmerkung war nur eine Idee, um noch ein wenig mehr rauszuquetschen und/oder den Code zu vereinfachen (wir wissen ja, Kleinvieh macht auch Mist). Ich hab hier leider zur Zeit keinen Zugriff auf eine nötige Infrastruktur, also wer sich angesprochen fühlt …

[backbone]

google arbeitet sicher nicht auf Checksums, da würds ja schon reichen, wenn ein scheiß Proxy zwischen google und der Website liegt, oder wenn nur ein arbiträrer Zustand im CMS ein zusätzliches Leerzeichen generiert.

Ich finde die frage ist hier nicht "ob" sondern "wie" das feature integriert werden soll. Es kann von mir aus gerne komplett abschaltbar sein.

[FloB]

google arbeitet sicher nicht auf Checksums,

… und wir können noch stundenlang diskutieren und kommen trotzdem nicht weiter .

[backbone]

Deswegen sag ich ja, lass uns lieber über das "wie" reden und nicht über das "ob". Mit einer Option das Feature ganz abzuschalten, kann jeder selber entscheiden...
Fakt ist das in der aktuellen Version HTTP-Caching und serverseitiges Caching nicht funktionieren, was schon mal Mist ist, da es schon was gibt, was beides berücksichtigt.

[Tim G]

@backbone:
warum nicht Eure Variante implementieren?
Browsercss ist eine der wichtigsten Ext. bei mir und bei jedem Projekt dabei.


Sent from my iPhone using Tapatalk

[leo]

Insbesondere Google mag ja Geschwindigkeit und misst diese durchaus im Millisekundenbereich, und zwanzig RegEx'e sind einfach zwanzig zu viel.

Oje, wenn ich so etwas schon lese komme ich aus dem Kopfschütteln gar nicht mehr heraus. Ich hab es spaßeshalber gerade mal gemessen: Die Ausführungszeit für die Ermittlung beträgt auf meinem System im ungünstigsten Fall 0.00007 Sekunden - also sage und schreibe sieben Hundertausendstel Sekunden. Das wird sicherlich einen gewaltigen Unterschied für das Google Ranking machen!

Und wenn ich dann weiter von "Krücken wie str_replace" und "man sollte lieber Inserttags verwenden" lese, obwohl Inserttags intern mit der wesentlich rechenintensiveren Funktion preg_split ersetzt werden, fällt es mir schwer, den Beitrag nicht in die "einfach mal was dagegen sagen, um was gesagt zu haben"-Schublade zu stecken.

Sorry, aber <Ignorierer-Liste an>

[backbone]

@Leo: Ich hoffe, du ignorierst meine (durchaus konstruktive?) Kritik nicht mit :/
Schau dir wenigstens mal die überarbeitete Version von BrowserCSS aus dem Thread hier an. (Nicht die ausm Repo).
Und eine Aussage wie du zur Nutzung der externen Browser.php stehst wär cool.

[FloB]

Oje, wenn ich so etwas schon lese komme ich aus dem Kopfschütteln gar nicht mehr heraus. Ich hab es spaßeshalber gerade mal gemessen: Die Ausführungszeit für die Ermittlung beträgt auf meinem System im ungünstigsten Fall 0.00007 Sekunden - also sage und schreibe sieben Hundertausendstel Sekunden. Das wird sicherlich einen gewaltigen Unterschied für das Google Ranking machen!

Und wenn ich dann weiter von "Krücken wie str_replace" und "man sollte lieber Inserttags verwenden" lese, obwohl Inserttags intern mit der wesentlich rechenintensiveren Funktion preg_split ersetzt werden, fällt es mir schwer, den Beitrag nicht in die "einfach mal was dagegen sagen, um was gesagt zu haben"-Schublade zu stecken.

Sorry, aber <Ignorierer-Liste an>

Sorry, dass dich meine immer destruktiven Beiträge nerven, aber ich habe klar gesagt, dass ich ein paar Anmerkungen in die Diskussion einwerfe, die man untersuchen sollte. Wenn sich meine Befürchtungen einfach widerlegen lassen (wie du es in deinem Beitrag bez. der Geschwindigkeit getan hast), ist das Thema abgehakt (und offensichtlich kenn ich mich im Core nicht so aus wie du, kann also nur Vermutungen anstellen). Wo ist das Problem? Ich versuche Input zu geben, und nicht "gegen" die Vorschläge etwas zu sagen, nur um etwas zu sagen: Dafür ist mir meine Zeit definitiv zu schade.


Edit: Sehr interessant finde ich ja, dass meine Vorschläge in der neusten Revision umgesetzt wurden …

[leo]

Sehr interessant finde ich ja, dass meine Vorschläge in der neusten Revision umgesetzt wurden …

Ich habe ja auch nicht gesagt, dass alle Deine Beiträge Schmarrn sind. Es ist nur die Art und Weise, wie Du die Dinge formulierst. Einen nicht so erfahreren Nutzer verunsichern Aussagen im Sinne von "um Gottes Willen, wie kann man nur solche Krücken verwenden und 20 Regex's ausführen, das wird sich äußerst schlecht auf das Google-Ranking auswirken".

Natürlich soll die Funktion so optimal laufen wie möglich, trotzdem werden 7 Hunderttausendstel Sekunden keine Auswirkung auf das Google-Ranking haben!

[backbone]

So jetzt vertragen sich alle mal wieder

Eine kleine Frage vorweg an leo: Wo willst du egtl. Feedback bezgl. der SVN Revs haben? Im Ticketsystem oder hier im Forum? Gibt leider Kommentarfunktion bei den Revs im Tracker.

Aber noch ein paar kleine Anmerkungen:
Den Vary-Header solltest du mit header($strVary, false) setzen, um zu verhindern, das vohergehende Varys überschrieben werden...
Und ich frag mich immer noch, was der Grund für den Nichteinsatz von Browser.php ist?
Da ich jetzt nicht erst von der aktuellen Rev mir Code in mein Testsystem zusammenschustern möchte, würd ich dich bitten, deine aktuelle Implementierung mit einem FF unter Win zu öffnen. Ich hatte nämlich kürzlich (siehe HTML5 Thread im Entwicklerforum) eine ähnlich "0815"-Implementierung (einfach mal nach "MSIE" im UA-String suchen) und da bei mir FF auch die Klasse vom IE bekommen.

[FloB]

Es ist nur die Art und Weise, wie Du die Dinge formulierst. Einen nicht so erfahreren Nutzer verunsichern Aussagen im Sinne von "um Gottes Willen, wie kann man nur solche Krücken verwenden und 20 Regex's ausführen, das wird sich äußerst schlecht auf das Google-Ranking auswirken".

Ich will hier nicht irgendwelche Panik oder sonstetwas verbreiten. Zugegeben, meine Formulierungen sind meist etwas flapsig (sorry dafür). Dennoch ist das mein Schreibstil. Ich werde in Zukunft darauf achten eindeutiger zu schreiben.

Ich habe aber auch nirgendwo geschrieben, dass sich diese Änderung auf das Ranking auswirkt. Ich habe es nur generell als mögliche Konsequenz hingestellt, v. a. um meine Bedenken ein wenig zu illustrieren. Natürlich wird diese Änderung allein keinerlei spürbaren Auswirkungen auf die Geschwindigkeit oder Speicherverbrauch haben, aber die Masse macht's (der Ausgabecode wird in Contao schon ein paar Mal durch *_replace's gezogen).

Ich bitte dich, in Zukunft niemanden einfach so als Deppen hinzustellen, schon gar nicht wenn sich brauchbares unter diesen Beiträgen finden lässt. Wenn du mit einer Aussage nicht einverstanden bist, widerlege sie einfach und antworte sachlich. Ich bemühe mich immer konstruktive Kritik zu üben und bei einer Problemlösung zu helfen, und ich kann, denke ich mal, behaupten, dass mir das in den meisten Fällen gelingt.

Wenn der Aufwand, den einer betreibt, nicht ansatzweise honoriert wird, wird er es sich beim nächsten Mal zweimal überlegen, ob er wieder Arbeit investiert. Klingt nach beleidigter Leberwurst? Ist aber einfach so.

Ich hoffe, das Thema können wir hiermit als erledigt betrachten.

[andreasisaak]

Begrüße die Funktion und bin froh eine Extension weniger installieren zu müssen die man auch immer seperat aktualisieren muss. Man kann drüber streiten ob solch eine Funktion in den Code gehört - die Frontend Entwickler werden es dir danken

Danke vielmals.

[SunBlack]

Irgendwie bezweifle ich, dass man mit dieser Lösung wirklich Browserhacks los wird. z.B. habe ich bei einer Seite überlegt, die meisten Grafiken durch CSS-Gradients zu ersetzen. Allerdings supporten dies bisher nur FF4, Opera 11.10, Chrome und IE10, da ich von kein anderen Browsern weiß, dass die das supporten (ganzen Mobilebrowsern), ist die Lösung, eine whitelist anzuwenden für die CSS-Anweisungen, anstatt einer Blackbox. Nur lässt sich mit der "neuen" Variante das nicht umsetzen. Ich kann da nicht abfragen, ob ich z.B. den >IE10 bekomme, sondern nur, ob ich eine bestimmte Version bekomme. Das wäre z.B. eine Stelle, wo mir die neue Variante nichts bringen würde. Allerdings sind die Browserweichen auch nicht so optimal, da ich in Contao, soweit ich gerade überblicke, das Stylesheet für die Whitelist duplizieren müsste, da ich nicht für ein Stylesheet mehrere Browser angeben kann.

Von daher mein Vorschlag:
Man kann bei den Stylesheets eigene CSS-Klassen festlegen, welche Flags man erhalten möchte. Also das ich angeben kann, ob ich auf IE9 überprüfen möchte oder auf >IE9 - und für beides eigene Klassennamen festlegen kann. Man könnte alternativ für alle Möglichkeiten eine CSS-Klasse anlegen - aber dann werden es seeeeehr viele Klassen.
Ein andere Idee in diese Richtung: Bei den Stylesheets kann man sich eigene Klassen nach Features zusammenbauen. Sprich das man eigene CSS-Klassen für supportede Features anlegen kann. z.B. könnte ich dann eine eigene Klasse für CSS-Gradients anlegen, für die ich dann angebe, bei welchen Browsern sie angezeigt wird. Wenn dann ein Browser hinzukommt, der CSS-Gradients unterstützt, kann ich an einer zentralen Stelle dann das Feature für diesen Browser aktivieren (bzw. irgendwann auf alle außer diese Browser umstellen) - ohne die CSS anfassen. Sonst müsste ich bei der neuen Lösung für einen neuen Browser, alle Selektoren anfassen, die irgendwo das Feature nutzen.
Und ich glaube nicht das letzteres Feature wirklich dem "light"-Anspruch widersprechen, da Browserweichen eh nur fortgeschrittene brauchen (bisher musste ich bei meinen Websiten nur einmal Browserweichen einsetzen: eine HTML-Wiche für IE6 - allgemein kommt man eigentlich meistens ohne aus).

[leo]

Noch mal der Hinweis, weil es scheinbar einfach nicht gehört wird: Wir waren auf der Suche nach einer Lösung, die ohne JavaScript funktioniert. Ja, Feature-Detection ist exakter als Browser-Detection, benötigt aber JavaScript (z.B. modernizr).

Und die Mehrzahl der Wortmeldungen, vor allem auch in der Diskussion zum Thema HTML5, waren ja so besorgt um die vielen Nutzer, die alle ohne JavaScript unterwegs sind. Ich selbst tue mich zwar auch schwer, zu glauben, dass das Internet ohne JavaScript überhaupt vernünftig funktioniert, habe mich aber der allgemeinen Meinung gebeugt und zusätzliche serverseitige Lösungen eingebaut. Ob man diese im Endeffekt nutzt bleibt jedem selbst überlassen.

[SunBlack]

Noch mal der Hinweis, weil es scheinbar einfach nicht gehört wird: Wir waren auf der Suche nach einer Lösung, die ohne JavaScript funktioniert. Ja, Feature-Detection ist exakter als Browser-Detection, benötigt aber JavaScript (z.B. modernizr).

Aus diesem Grund müsste man bei meiner Idee das im Backend für die jeweiligen Browser aktivieren. Interessant Idee wäre aber, dass man es Serverseitig einstellt, der Browser aber per JS noch aktivieren kann. Sprich im Backend stellt man z.B. ein das Opera und FF CSS-Gradients unterstützen, in dem er dann die Klasse "supportGradients" serverseitig im body einfügt. Nun wird die Seite per IE10 aufgerufen: Die Klasse "supportGradients" ist nicht vorhanden. Aber der Browser könnte jetzt überprüfen, ob er vlt. doch CSS-Gradients supported - wenn ja, fügt er die Klasse "supportGradients" doch noch hinzu.

[andreasisaak]

Ich glaube sowas wäre in einer von dir oder von anderen entwickelten Extension besser aufgehoben. Vielleicht 2% der Nutzer würden es wirklich gebrauchen und es scheint mir schon sehr speziell.

[SunBlack]

Das mit dem JS schon. Aber allgemein finde ich Browserweichen eigentlich was für Erweiterungen sind, da die man viele Seiten durchaus ohne hinbekommt.

[backbone]

Um nochmals Browser.php ins Spiel zu bringen: Diese Erweiterung bietet eine Version-Detection...

@leo: Es ging nicht um die "vielen" User die kein JS haben, sondern einfach um das "Aufzwingen" eines Scripts, was durchaus weitere Implikationen haben könnte.

[teo]

Könnte nützlich sein und ich werde es sicherlich ausprobieren. backbones Erweiterung habe ich auch schon entdeckt, aber noch nicht verwendet. Bisher baue ich immer noch ein wenig PHP-Code in das fe_page.tpl, welches mir dann explizit das mobile oder das 'normale' Style-Sheet lädt. Möchte einfach nicht zu viele CSS-Includes machen oder aufblähen (mit MEDIA-Klammern). Auserdemsieht dann die erzeugte HMTL-Source übersichtlicher aus.

[datenkind]

Nochmal aufwärmen, da ich hier keine Überprüfungsmöglichkeit habe …

Was passiert bei einem Android-Endgerät? Bspw. liefert das HTC Desire einen UA aus, der als Mac OSX 10.5 mit Safari 4 läuft (getestet unter http://whatsmyuseragent.com).

Kann das jemand nachvollziehen bzw. gegenprüfen? Es würden dann ja durchs Sniffen völlig irre Werte zurückkommen.

[BugBuster]

Mozilla/5.0 (Linux; U; Android 2.1-update1; en-gb; HTC Desire Build/ERE27) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17

Sowas? Immerhin steht dort Android.

Ergibt laut Quelltext:

$os = 'android';
$mobile = true;
$browser = 'safari';
$shorty  = 'sf';

Von MAC-OS sehe ich da nichts. Wie ist denn Dein UA?

[datenkind]

Na immerhin. Das Gerät hier spuckt nullkommanix aus, was auf Android (hier Version 2.2) hinweisen würde …

Mozilla/5.0 (Macintosh; U , Intel Mac OS X 10_5_7; en-us) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Safari/530.17

Und nu?

Noch was aus der Software-Info des Gerätes (nur der Vollständigkeit halber):

Android:
2.2

Kernel:
2.6.32.15-gd96fc20
htx-kernel@and18-2 #1

Build-Nr.
2.14.207.2 CL259355 release-keys

Software-Nr:
2.14.207.2

Browser-Version:
WebKit 3.1

[BugBuster]

Wenn ich das richtig lese, ist das Abhängig von deiner Browsereinstellung:

are we aware of HTC Desire 2.2 "user agent dual mode"? Browser settings offer "Mobile view" selection.

Mobile view checked - user agent:
Mozilla/5.0 (Linux; U; Android 2.2; Desire_A8181 Build/FRF91) AppleWebKit/533.1
(KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

Mobile view unchecked - user agent:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) AppleWebKit/530.17
(KHTML, like Gecko) Version/4.0 Safari/530.17

I already have a headache because of this "feature".

[datenkind]

Ah, wow. gut zu wissen. Jetzt geht das.

Führt mich dann doch nur wieder zur Bestätigung (obwohl ich neulich versucht habe, anders zu denken), dass UA-Sniffing vollkommener Blödsinn ist.

[Ria]

Hallo,
ich habe in einem Verein mehrere 100 PC Nutzer/ User mal befragt. Kein Mensch hat Javascript abgeschaltet (Java ja, ist ja auch was anderes). Woher kommt den die Meinung, dies würden viele machen? Ich kenne Niemanden.

Gruss Ria

[MacKP]

Hallo Ria,
das kann man über Statistiken von Besuchern herausbekommen.
Und naja... kommt auch drauf an welche 100 Leute man befragt. Von daher wird deine mini Studie nicht gerade repräsentativ sein.

Viele Grüße

[schman]

"Meistens" wird JavaScript in Unternehmen deaktivieren. Allerdings bin ich der Meinung das JavaScript heutzutage dazugehört, dass ist wie wenn jemand CSS abschalten würde.

[datenkind]

Es gibt auch viele NoScript-User (gibt’s für Firefox und Chrome), wo man explizit erlauben muss, auf welchen Websites JS ausgeführt. Und wenn deine nicht dabei ist, gilt laut Statistik dieser User als User mit deaktiviertem JS.

Tja, alles Dilemma. UA-Sniffing und Feature-Detection sind ja schön und gut, aber ihre Fehleranfälligkeit zwingt halt (was wohl auch gut so ist), Websites zu bauen, die plattformunabhängig sind und auch bei deaktivierten Features funktionieren – nicht unbedingt in vollem Umfang, aber essentiell.

[hofff]

Hallo Leute,

also ich denke hier ähnlich wie die meisten: wer zur heutigen Zeit JavaScript deaktiviert, ist selbst Schuld. Das ist eigentlich so, als wenn man ein Auto mit ABS kauft, es aber deaktiviert. Trotzdem achten wir bei der Erstellung von Webseiten darauf, dass die Seite auch bei abgeschaltetem JS benutzbar bleiben, Featureeinbußen sind aber akzeptiert. Alle wollen die neusten Technologien einsetzen, von Like Buttons über Videos bis hin zu Formular Überprüfungen, lustig animierte Menüs, Imageslider usw., also sollte da auch JS aktiviert sein. Diese Diskussion führt wahrscheinlich nicht wirklich zu einem Ergebnis, deshalb braucht man sie eigentlich auch nicht führen. Fakt ist: für diverse aktuellen Features ist und bleibt JS unverzichtbar!

fg
nicky

--
von meinem iPad mit Tapatalk gesendet.

[wotank]

also ich denke hier ähnlich wie die meisten: wer zur heutigen Zeit JavaScript deaktiviert, ist selbst Schuld.
.

ich denke nicht so.
Diese ganze ist-selbst-schuld-Einstellung ruft bei mir nur Kopfschütteln hervor.
Da denke ich spontan an einen Spruch eines bekannten Webentwicklers und Buchautors:

Es ist nicht der Webentwickler und auch nicht der Programmierer der entscheidet wie sich ein Benutzer durchs Web bewegt. Diese Einstellung entsteht vor Monitoren in einsamen Räumen.

*break*

Das so etwas in den Contao-Core übernommen wird kann ich leider nicht verstehen.
Der Benutzer (oder irgendwelche Software die der Benutzer nutzt) kann den User-Agent-String verändern und wird dann nicht mehr erkannt.
Proxys können evtl. hier ein Problem darstellen (Caching der Seite / Useragent muss nicht zwangsweise korrekt übermittelt werden).

Alles in allem eine meiner Meinung nach unsichere Sache.

Schon die Erweiterung browser.css fand ich deshalb nicht empfehlenswert.

edit.: Hier gibt es ein Podcast wo so ab Min. 45 auf Useragent-Probleme eingegangen wird

[mae]

Wird es eine Möglichkeit geben, dieses "Feature" auch um zu funktionieren?

JavaScript findet trotzdem erst nach $(document).ready (aka. domready) die jeweilige id bzw klasse des body-tags - ich lade meine libraries aber schon vorher nach, für das jeweilige OS zugeschnitten (z.B, json2 für ie6/ie7). Gerne würde ich die UA-Details als Parameter an das Javascript weitergeben. Wird dies möglich sein?

-------

[CODE]

Ergibt laut Quelltext:

$os = 'android';
$mobile = true;
$browser = 'safari';
$shorty  = 'sf';

ist das die contao 2.10 ausgabe ? das ist so leider wenig sinnvoll - $shorty sollte wenn überhaupt, nur webkit, anstatt 'sf' lauten !! und wenn, dann auch nicht "shorty" wtf? irgendwas, sondern eher $engine = 'webkit'.

hier wird ansonsten wieder ein unnötiges contaolingo standarisiert, mit "shorty" tut man niemandem einen gefallen.

der $browser ist im endeffekt auch völlig nebensächlich - wer nach $browser sein css anpasst : herzliches beileid ! im endeffekt spart man sich wesentlich zeit und arbeit, wenn man nur nach $engine hackt:

microsoft = trident
mozilla = gecko
opera = presto
safari = webkit
chrome = webkit

-------

Noch mal der Hinweis, weil es scheinbar einfach nicht gehört wird: Wir waren auf der Suche nach einer Lösung, die ohne JavaScript funktioniert. Ja, Feature-Detection ist exakter als Browser-Detection, benötigt aber JavaScript (z.B. modernizr).

Und die Mehrzahl der Wortmeldungen, vor allem auch in der Diskussion zum Thema HTML5, waren ja so besorgt um die vielen Nutzer, die alle ohne JavaScript unterwegs sind. Ich selbst tue mich zwar auch schwer, zu glauben, dass das Internet ohne JavaScript überhaupt vernünftig funktioniert, habe mich aber der allgemeinen Meinung gebeugt und zusätzliche serverseitige Lösungen eingebaut. Ob man diese im Endeffekt nutzt bleibt jedem selbst überlassen.

Definitiv sinnvoll ! JavaScript ist die Sprache des Browsers.

-------

[Georg]

Masse bürgt nicht immer für die beste Lösung.
Ein kurze Umfrage hier in der Firma ergab, dass die Mehrheit gerne 220 Urlaubstage pro Jahr hätten. ;-))
Polemik Ende!

Wir ALLE haben uns den Schutz von benachteiligten Minderheiten in verschiedene Pflichtenhefte geschrieben.
Nicht nur die deutschen Behörden sind daher gesetzlich verpflichtet ihre Portale entsprechend barrierefrei zu gestalten.

Nicht falsch verstehen: JavaScript wird dabei nicht ausgeschlossen!

Aber die Portale von Behörden müssen dabei z.B. folgende Abnahmekriterien erfüllen:
http://www.bitvtest.de/infothek/arti...avascript.html

Das war der eigentliche Grund, warum ich begann mich mit Contao zu beschäftigen:
die nicht müde werdende Nina (und einige andere), die in Bezug auf Barrierefreiheit immer wieder auf Optimierungen drängen und Leo, den die Hinweise oft nerven (siehe oben), dann aber sein Ohr für dieses Thema zum Glück dennoch immer wieder offen behält.

Das Ergebnis kann sich bisher sehen lassen: alle wichtigen Contao Funktionen gehen auch ohne JavaScript. Und für den Rest der Welt werden mit aktiviertem JS automatisch und nahtlos viele Optimierungen genutzt. Perfekt!

[Goody]

Hallo zusammen,

als noch relative Contao-Anfängerin habe ich erfolgreich von 2.95 auf 2.10.1 manuel upgedatet und wollte mich mit den Neuerungen vertraut machen. Über das Addon "user agent" für Firefox wollte ich mich dann als iPad ausgeben und testen, ob ich dann fürs iPad ein anderes Hintergrundbild verwenden könnte. Die Anweisung in "Vergesst Browser-Hacks in Contao 2.10" (http://tinyurl.com/3wkkspz) hatte ich gelesen. Als Body-Tag bekomme ich dann <body id="top" class="ios safari sf4 mobile">. Änderungen die ich über die CSS-Anweisung .ios #wrapper
{ … } vornehme, werden ausgeführt, aber wenn ich versuche den body-Tag bzw. #top anzusprechen, um z.B. ein anderes Hintergrundbild zu wählen, passiert nichts.

Ich versuchte es mit:
body #top .ios safari sf4 mobile { … }
body #top .ios { … }
body .ios { … }
.ios body { … }
.mobile body { … }

Was wäre die Lösung? Wenn möglich für Laien verständlich.
Danke.
Gruß Goody

[andreasisaak]

Du solltest dir dringend nochmal die CSS-Basics anschauen
Der Fehler liegt darin das du die Anweisungen nicht verkettest:

body#top.ios.safari.sf4.mobile { … }
body#top .ios { … }
body.ios { … }
body.mobile  { … }

Außerdem brauchst du es nicht so genau.
Es reicht schon

body.ios { … }