Ein Lob auf die Pause

[Beat]

Hallo zusammen

Ich habe (krankheitsbedingt) fast 3 Jahre Pause vom Webdesign gemacht. Pausen haben sicher auch ihr Positives.

Hier sind meine positiven Überraschungen.

• kein MSIE 6/7 mehr zu unterstützen
• nur noch XmlHttpRequest.
• nur wenige altenative CSS-Regeln für Browser, die calc nicht verstehen
• Media-Queries und keine Sorgen über Mobiles, Tabletts etc...

Fortschritt existiert. Der Fortschritt besteht nicht in einer Explosion neuer phantastischer Möglichkeiten, sondern in der Anwendungssicherheit höchst sinnvoller Innovationen.

Ich habe einen Chat geschrieben. Und auch wenn MSIE-8 mir immer noch etwas Kopfzerbrechen machte, es hält sich doch in grenzen. Die JS Library ist minimal. Nicht mal alternatves CSS für MSIE ist notwendig.

Ich fühle mich plötzlich in einer Zeit der neuen Einfachkeit frei von Willkür.
Und das dürfte wohl die positive Überraschung einer auferzwungenen Pause als Webworker sein.

Welche Erfahrungen habt Ihr durch Design-Pausen gemacht?

mfg Beat

[T-Rex]

Ich habe (krankheitsbedingt) fast 3 Jahre Pause vom Webdesign gemacht.

Wenn du komplett Arbeitslos warst möchte ich gerne wissen wie du das Finanziert hast. Ich brauch auch eine Pause vom Arbeiten, aber leider auch das Geld für Miete und essen :(.

Gruß
Pausenräuber
T-Rex

[Christian Kruse]

Moin T-Rex,

Ich habe (krankheitsbedingt) fast 3 Jahre Pause vom Webdesign gemacht.

Wenn du komplett Arbeitslos warst möchte ich gerne wissen wie du das Finanziert hast.

Er hat doch „krankheitsbedingt” dazu geschrieben :)

Ich brauch auch eine Pause vom Arbeiten, aber leider auch das Geld für Miete und essen :(.

Krank werden! ;-)

LG,
 CK

[T-Rex]

Hat hmpf...

Krank werden! ;-)

Welche?

Gruß
kranker
T-Rex

[Matthias Apsel]

Om nah hoo pez nyeetz, T-Rex!

Krank werden! ;-)

Ich glaube, das ist keine Option. Trotz des ;-)

Matthias

[T-Rex]

Ich glaube, das ist keine Option. Trotz des ;-)

Wieso? Vielleicht gibt es eine Krankheit die so ca. 1 Monat geht, wo einem kein Arzt helfen kann, die aber von alleine weggeht und die arbeitsunfähig macht. Mir fallen dabei leider nur psychische Leiden ein und da ist man gleich auf der Schiene der Psychiater. Und die ist nicht sonderlich angenehm, da arbeite ich lieber weiter :D.
1 Monat Bauchschmerzen oder Kreislauf, glaubt einem ja auch keiner :(.

Und nein ich nutze das System nicht aus. Ich bin überarbeitet und brauche dringend mal länger Pause, da ich total überspannt bin. Urlaubstage reichen leider nicht... Naja ich sags ja immer wieder, ein Unmenschliches System ist das hier *kotz*.

Gruß
Mensch
T-Rex

[1UnitedPower]

Und nein ich nutze das System nicht aus. Ich bin überarbeitet und brauche dringend mal länger Pause, da ich total überspannt bin. Urlaubstage reichen leider nicht... Naja ich sags ja immer wieder, ein Unmenschliches System ist das hier *kotz*.

Na das klingt doch nach einem Fall für einen Psychotherapeuten. Was hält dich davon ab? Falscher Stolz?

[T-Rex]

Na das klingt doch nach einem Fall für einen Psychotherapeuten. Was hält dich davon ab? Falscher Stolz?

Willst du wirklich jemand provozieren dem du einen Psychotherapeuten empfiehlst? Wieso macht du das? Falscher Stolz?

Gruß
Man ich winke doch, ich winke !!!
T-Rex

[Peter Pan]

Hi!

Und nein ich nutze das System nicht aus. Ich bin überarbeitet und brauche dringend mal länger Pause, da ich total überspannt bin. Urlaubstage reichen leider nicht... Naja ich sags ja immer wieder, ein Unmenschliches System ist das hier *kotz*.

Na das klingt doch

Ich höre nichts..

nach einem Fall für einen Psychotherapeuten.

Nein! Das bedeutet wohl eher, dass der Job zuviel von jemandem fordert - das geht eine Zeit lang "ganz gut", aber man darf das nicht zur Gewohnheit werden lassen. Auch wenn solche Idioten wie diese Unternehmensbrater[sic] durchs Land laufen und mich "Minderleister" schimpfen - ich lasse mich nicht mehr über einen längeren Zeitraum verheizen. Ich habe nur ein Leben und das möchte ich möglichst lange bei maximaler Gesundheit erleben.

Just my 2 cents

off:PP

[Christian Kruse]

Moin Peter,

Nein! Das bedeutet wohl eher, dass der Job zuviel von jemandem fordert - das geht eine Zeit lang "ganz gut", aber man darf das nicht zur Gewohnheit werden lassen. Auch wenn solche Idioten wie diese Unternehmensbrater[sic] durchs Land laufen und mich "Minderleister" schimpfen - ich lasse mich nicht mehr über einen längeren Zeitraum verheizen. Ich habe nur ein Leben und das möchte ich möglichst lange bei maximaler Gesundheit erleben.

Was du mit dir machen lässt, ist doch allein deine Sache. Erst recht in dieser Zeit und unserer Berufssparte und unseren Gesetzen bzgl. Arbeitszeiten.

LG,
 CK

[Peter Pan]

Hi!

Was du mit dir machen lässt, ist doch allein deine Sache. Erst recht in dieser Zeit und unserer Berufssparte und unseren Gesetzen bzgl. Arbeitszeiten.

Ja genau. War da jetzt eine Gegenrede, die ich nicht gerafft habe?

Ich hüpfe nun aus dem Home-Office-Tag ins Wochenende.

off:P'Minderleister'P

[Christian Kruse]

Moin Peter,

Was du mit dir machen lässt, ist doch allein deine Sache. Erst recht in dieser Zeit und unserer Berufssparte und unseren Gesetzen bzgl. Arbeitszeiten.

Ja genau. War da jetzt eine Gegenrede, die ich nicht gerafft habe?

Du schimpfst darüber, wie unmenschlich dein Arbeitgeber sei und wie viel du arbeiten musst. Daraus lässt sich ziemlich einfach ableiten, dass dein bisheriges Arbeitspensum zu viel ist.

LG,
 CK

[1UnitedPower]

nach einem Fall für einen Psychotherapeuten.

Nein!

Ich verstehe diese  Voreingenommenheit gegenüber Psycho-whatever-Menschen nicht. Ein Besuch oder auch eine Therapie bei eines solchen gleichen ist kein sozialer oder gesellschaftlicher Abstieg, geschweige denn beruflicher Selbstmord. Mir hat diese Art der Betreuung bei einem schweren Familien-Unglück sehr geholfen. Und ich bin entsetzt darüber, dass einige Menschen noch versuchen einem das Wort im Munde umzudrehen und die Weiterempfehlung als Beleidigung auslegen. Das ist zumindest meine Interpretation bei einem solch manifestiertem "Nein!" (Ausrufezeichen). Völlig unabhängig vom Zaunpfahl-schwingenden T-Rex, der Thema wohlwollend mit Humor begegnet.

[T-Rex]

Hmpf... Deine "Empfehlung" habe ich in der Tat falsch verstanden.
Es ist halt so, wenn jemand nicht der Gesellschaftsnorm entspricht, dann gilt er meist als krank. Und wenn man krank ist und hilfe braucht, geht man zum Psychologen.
Ich brauche aber keine Hilfe, sondern einfach mal eine Auszeit. Das weiß ich selbst, dazu brauch ich keinen Arzt. In der Vergangenheit gab es Momente in denen ich unfreiweillig arbeitslos war. Da hab ich 1-2 Monate einfach nichts gemacht. Danach war ich voller Saft und Kraft.

Psychologen. Hab zwei geschichten Parat. Zu erst die unschöne. Ein Bekannter, dermitten im Leben steht hatte einen sehr leichten Schlaganfall. Die Ärzte diagnostizierten eine Schizophrenie. Man sprach im jegliche Zurechnungsfähigkeit ab. Er kam in die Klappse und wurde mit Medikamenten zugedröhnt. Der Typ war mitten im Leben. Man hätte mit ihm bei einem Bierchen in einer gemühtlichen Runde gesessen und er hätte dir tolle Sachen über Physik, Chemie und son Zeug erzählt. Er konnte dann nicht mal mehr alleine pinkeln. Erst als seine Frau in mehr oder weniger entführt hatte und die Drogen/Medikamente nachgelassen haben kam er langsam wieder zu sich und hat sich erholt.

Meiner Frau hingegen ist das gleiche passiert wie dir. Ein Schicksaalsschlag nahm ihr beide Eltern. Anfangs hab ich es nicht verstanden (aktuell immer noch nicht so ganz), aber ich weiß, dass der Psychiater ihr hilft. Deshalb bin ich froh das sie in Behandlung ist.

Gibt leider auch Leute die rennen durch die Gegend und empfehlen jeden, denn sie als Spinner halten ein Therapie. Dachte du wärst so einer. Tut mir sehr leid.

Gruß
aufrichtiger
T-Rex

[Christian Kruse]

Moin Beat,

Welche Erfahrungen habt Ihr durch Design-Pausen gemacht?

Weder mache ich Design, noch habe ich eine Pause gemacht ;-) Aber ich sehe die aktuelle Entwicklung ähnlich positiv wie du. Es tut sich mächtig was, und das ist auch gut so™.

Ob der Euphorie sollten wir aber nicht übersehen, dass wir auch noch einen weiten Weg vor uns haben :-)

LG,
 CK

[Siri]

Hallo,

Fortschritt existiert. Der Fortschritt besteht nicht in einer Explosion neuer phantastischer Möglichkeiten, sondern in der Anwendungssicherheit höchst sinnvoller Innovationen.

Also mir geht das alles nicht weit genug, der Fortschritt hinkt und die Umsetzung dauert zu lange. Caniuse wurde ja schon verlinkt.
Insbesondere nervt mich, dass Browser nicht genug Informationen an den Server senden, z.B. auf welchem Endgerät sie sich befinden und welche Möglichkeiten dieses bietet. Aber mit dieser Meinung stehe ich (zusammen mit Gunther) -zumindest im Forum- alleine auf weiter Flur...

Ich kann mir aber vorstellen, dass es nach so langer Zeit überhaupt Spaß macht, wieder zu arbeiten, produktiv und kreativ zu sein!

Viele Grüße
Siri

[Beat]

Insbesondere nervt mich, dass Browser nicht genug Informationen an den Server senden, z.B. auf welchem Endgerät sie sich befinden und welche Möglichkeiten dieses bietet. Aber mit dieser Meinung stehe ich (zusammen mit Gunther) -zumindest im Forum- alleine auf weiter Flur...

Was genau möchtest du denn über meine Browserumgebung wissen?
Ob ich javascript aktiviert habe, ob diverse Plugins betriebsbereit sind?
Nun, du kannst auf meinen Browser vieles testen, und dann entscheiden, was du auslieferst.
Oder du kannst an den Anwender appellieren, er möge sich zwischen einer Javascript-Version oder einer Java Version einer WebApp entscheiden.
Oftmals liefert der Browser ja nicht die richtigen Daten. Das beginnt ja schon bei der Sprachverhandlung auf einem öffentlich zugänglichen Browser. Und ein Browser kann dir zuletzt die Information vermitteln, beim Anwender handele es sich um einen Nerd oder um einen DAU.
Und dass Browser überhaupt gewisse Informationen ungefragt herausrücken, hat eher mit Kompatibilität denn mit Sinn zu tun.

Dein anliegen bleibt mir etwas unverständlich.

mfg Beat

[Siri]

Hallo,

ich weiß nicht ob du Spaß hast die ganzen Diskussionen nachzulesen, aber wenn, dann hier eine kleine Auswahl:

Forum
Forum
Forum
Forum
...

Gunther kämpft oft mit Problem, die mir nicht fremd sind. Will man WebApps entwickeln und ein ähnliches Look&Feel bieten (und damit auch einen gewissen Komfort) wie native Apps, dann wären gewisse Infos hilfreich und zusätzlich könnte man einfach ausliefern, was benötigt wird und müsste nicht pauschal ausliefern und den Rest dem Browser überlassen. Die übertragene Menge spielt dabei natürlich im mobilen Bereich auch eine Rolle und -wer weiß- wenn die Datendrosselung der Telekom kommt auch wieder in anderen Bereichen.
Hierbei spielen zum einen Bilder eine Rolle (kleiner Bildschirm kleine Bilder) zum anderen Javascript Frameworks (TouchecEvents vs MouseEvents), da kommt doch gern einiges zusammen.

Ich weiß natürlich, dass es Informationsfetischisten gibt, die das alles für überflüssigen Quatsch halten, aber ich bin der Meinung, dass aber einer gewissen Komplexität einer Anwendung auch Usability und Design eine Sache "sexy" machen :-)
Der Erfolg der Smartphones zeigt mir, dass der Spieltrieb mindestens eine genauso große Rolle spielt wie der Informationsgehalt selbst.

Viele Grüße
Siri

[molily]

Hallo,

Will man WebApps entwickeln und ein ähnliches Look&Feel bieten (und damit auch einen gewissen Komfort) wie native Apps, dann wären gewisse Infos hilfreich und zusätzlich könnte man einfach ausliefern, was benötigt wird und müsste nicht pauschal ausliefern und den Rest dem Browser überlassen.

Solche Web-Apps sind in 90% der Fälle komplexe JavaScript-Anwendungen. Also können die Feature-Abfragen clientseitig passieren. Dafür gibt es Fertiglösungen wie Modernizr, yepnope und Require.js. Nichts muss pauschal ausgeliefert werden.

Einige der von dir verlinkten Thread habe ich ja kommentiert. Zum Teil halte ich es für unangebracht, mit Feature-Abfragen unterscheiden zu wollen, z.B. zwischen Mouse- und Touch-Eingabe zu unterscheiden. Dies macht nur im Hinblick auf komplexere Gesten Sinn. Da heutige Geräte meist beides können (Maus und Multitouch sind möglich), wäre eher eine Nutzerabfrage sinnvoll.

Mathias

[Siri]

Hallo,

Will man WebApps entwickeln und ein ähnliches Look&Feel bieten (und damit auch einen gewissen Komfort) wie native Apps, dann wären gewisse Infos hilfreich und zusätzlich könnte man einfach ausliefern, was benötigt wird und müsste nicht pauschal ausliefern und den Rest dem Browser überlassen.

Solche Web-Apps sind in 90% der Fälle komplexe JavaScript-Anwendungen. Also können die Feature-Abfragen clientseitig passieren. Dafür gibt es Fertiglösungen wie Modernizr, yepnope und Require.js. Nichts muss pauschal ausgeliefert werden.

Wenn ich clientseitig Abfrage, dann ist es doch schon ausgeliefert. Und muss es denn sein, dass man eben massenweise JS mitliefert um die Unterschiede auszubügeln? Ja, die Dinge sind wie sie sind, aber es könnte doch alles viel einfacher sein bzw. der Aufwand artet dann halt aus. Das sind zuviel Zeit und damit zuviele Kosten für Features, die man bei Apps oder Desktop-Anwendungen für völlig normal hält. Das fängt bei Controls wie dem "Endlosrad" für Zahlen an und endet noch lange nicht bei modalen Dialogen.

Einige der von dir verlinkten Thread habe ich ja kommentiert. Zum Teil halte ich es für unangebracht, mit Feature-Abfragen unterscheiden zu wollen, z.B. zwischen Mouse- und Touch-Eingabe zu unterscheiden. Dies macht nur im Hinblick auf komplexere Gesten Sinn. Da heutige Geräte meist beides können (Maus und Multitouch sind möglich), wäre eher eine Nutzerabfrage sinnvoll.

Ich schätze dein Fachwissen generell und deine Meinung sowieso, auch wenn ich sie in manchen Punkten nicht teilen kann. Wobei ich einfach auch von einer besseren Welt träume. Wie du oben schreibst, wäre es sinnvoller sich mit innovativen Konzepten zu beschäftigen als Lösungen für Dinge zu suchen, die "normal" sind und für diese wieder Extrawürste herstellen zu müssen. Das lähmt und langweilt.

Viele Grüße
Siri

[molily]

Also können die Feature-Abfragen clientseitig passieren. Dafür gibt es Fertiglösungen wie Modernizr, yepnope und Require.js. Nichts muss pauschal ausgeliefert werden.

Wenn ich clientseitig Abfrage, dann ist es doch schon ausgeliefert.

Dem habe ich gerade wiedersprochen. :)

Und muss es denn sein, dass man eben massenweise JS mitliefert um die Unterschiede auszubügeln?

Erstens ist so etwas wie Modernizr und yepnope nicht »massenweise JavaScript«, sondern ein stark begrenztes und zugeschnittenes Script. Zweitens, ja, es muss derzeit sein. Es ist manchmal sauberer, ein Feature mit JavaScript abzufragen, als im CSS oder sonstwo Progressive Enhancement versuchen.

Ja, die Dinge sind wie sie sind, aber es könnte doch alles viel einfacher sein

Auf jeden Fall könnte es einfacher sein. Ich sehe aber nicht, dass es einfacher werden würde, wenn der Browser dem Server mit jedem Request mitteilen würde, welche CSS-Eigenschaft und JavaScript-APIs er in welcher Revision unterstützt. Eine browserseitige Programmiersprache wie JavaScript, die tatsächliche Anwendungsfälle live testen kann, ist da immer irgendwelchen Bekundungen des Browsers überlegen, ein gewisses Feature zu unterstützen.

Grüße,
Mathias

[Siri]

Hallo,

Ja, die Dinge sind wie sie sind, aber es könnte doch alles viel einfacher sein

Auf jeden Fall könnte es einfacher sein. Ich sehe aber nicht, dass es einfacher werden würde, wenn der Browser dem Server mit jedem Request mitteilen würde, welche CSS-Eigenschaft und JavaScript-APIs er in welcher Revision unterstützt. Eine browserseitige Programmiersprache wie JavaScript, die tatsächliche Anwendungsfälle live testen kann, ist da immer irgendwelchen Bekundungen des Browsers überlegen, ein gewisses Feature zu unterstützen.

Nein, darauf will ich auch gar nicht hinaus! Ich stell mir das eher so vor, dass ich an ein Smartphone oder Tablet eine GUI ausgebe, die mit ihrem Verhalten dem Look&Feel des Gerätes entspricht. Da reichen Media-Queries einfach nicht aus (und ich rede jetzt nicht von einer Standard-Webseite vom Malermeister Maier ;-)). Aber um das zu tun, müsste man wissen, was das Gerät ist oder kann. Und sicher liefere ich an einen schönen großen Bildschirm andere Bilder aus, als an einen kleinen. Also, wenn ich könnte.

Die Welt wäre auch einfacher, wenn es technische Element gäbe, z.B.
<dialog onclose="refresh-opener" src="..."></dialog>
<wizard></wizard>
etc.
Die entsprechende Logik könnte im Browser implementiert sein und gut ist, Gestaltung über CSS.
Da werden aber die Puristen Sagen: Nein! HTML darf nur semantisch sein und Inhalt haben! Man muss doch auch an die armen Maschinen denken! Ok! Die könnten das ignorieren und ein Screenreader könnte z.B. mit einer "Zwischenfrage" einen Dialog abbilden.

Oder in Gottesnamen:
.dialog {
   behaviour: popup;
   ...
}
.page {
  new-page: fly-in, left-to-right;
  ...
}

Aber CSS ist zum Designen, nicht für technisches Verhalten gedacht...

Irgendwo fehlen mir in der Konstellation HTML, CSS, Javscript schlicht und ergreifend nicht-sematische Controls (falls man das so sagen kann).

Viele Grüße
Siri

[molily]

Hallo,

Ich stell mir das eher so vor, dass ich an ein Smartphone oder Tablet eine GUI ausgebe, die mit ihrem Verhalten dem Look&Feel des Gerätes entspricht. Da reichen Media-Queries einfach nicht aus (und ich rede jetzt nicht von einer Standard-Webseite vom Malermeister Maier ;-)). Aber um das zu tun, müsste man wissen, was das Gerät ist oder kann. Und sicher liefere ich an einen schönen großen Bildschirm andere Bilder aus, als an einen kleinen. Also, wenn ich könnte.

Ich verstehe nicht, an welchen technischen Merkmalen du das festmachen willst, wenn nicht an Viewport-Größe, Device-Pixel-Ratio usw.

Manche UIs lassen sich nur mit Maus oder Touch sinnvoll bedienen, das kann ich noch nachvollziehen. Viele Spiele erfordern eine Maus, andere erfordern Multi-Touch. Allerdings haben heutige Geräte wie gesagt beide Möglichkeiten, sodass der Browser keine eindeutige Aussage treffen kann. Es muss vor allem dem Nutzer mitgeteilt werden muss, falls Maus oder Touch erforderlich sind.

Die Welt wäre auch einfacher, wenn es technische Element gäbe, z.B.
<dialog onclose="refresh-opener" src="..."></dialog>
<wizard></wizard>
etc.
Die entsprechende Logik könnte im Browser implementiert sein und gut ist, Gestaltung über CSS.
Da werden aber die Puristen Sagen: Nein! HTML darf nur semantisch sein und Inhalt haben!

1. Solche Logik lässt sich bereits mit WAI-ARIA ausdrücken, aber die Gestaltung und die Bedienung ist letztlich noch deinem CSS und JavaScript überlassen.
2. HTML5 führt mit details/summary, menu, @contextmenu und dialog bereits generischen UI-Controls ein. Es ist nur noch nicht auf breite Unterstützung gestoßen.
3. Viele JavaScript-Frameworks, inbesondere für Mobilgeräte, bieten solche UI-Komponenten von Haus aus. Die funktionieren mit vielen Eingabemethoden und Viewport-Größen. In Frameworks wie Angular lassen sich die Komponenten auch so verwenden, wie du es oben demonstrierst.

Mathias

[Siri]

Hallo,

Ich stell mir das eher so vor, dass ich an ein Smartphone oder Tablet eine GUI ausgebe, die mit ihrem Verhalten dem Look&Feel des Gerätes entspricht. Da reichen Media-Queries einfach nicht aus (und ich rede jetzt nicht von einer Standard-Webseite vom Malermeister Maier ;-)). Aber um das zu tun, müsste man wissen, was das Gerät ist oder kann. Und sicher liefere ich an einen schönen großen Bildschirm andere Bilder aus, als an einen kleinen. Also, wenn ich könnte.

Ich verstehe nicht, an welchen technischen Merkmalen du das festmachen willst, wenn nicht an Viewport-Größe, Device-Pixel-Ratio usw.

Das genau ist der springende Punkt! Warum sagt mir der Browser bei der Anfrage nichts darüber?

Manche UIs lassen sich nur mit Maus oder Touch sinnvoll bedienen, das kann ich noch nachvollziehen. Viele Spiele erfordern eine Maus, andere erfordern Multi-Touch. Allerdings haben heutige Geräte wie gesagt beide Möglichkeiten, sodass der Browser keine eindeutige Aussage treffen kann. Es muss vor allem dem Nutzer mitgeteilt werden muss, falls Maus oder Touch erforderlich sind.

Die Welt wäre auch einfacher, wenn es technische Element gäbe, z.B.
<dialog onclose="refresh-opener" src="..."></dialog>
<wizard></wizard>
etc.
Die entsprechende Logik könnte im Browser implementiert sein und gut ist, Gestaltung über CSS.
Da werden aber die Puristen Sagen: Nein! HTML darf nur semantisch sein und Inhalt haben!

1. Solche Logik lässt sich bereits mit WAI-ARIA ausdrücken, aber die Gestaltung und die Bedienung ist letztlich noch deinem CSS und JavaScript überlassen.

Ja, aber warum? Nehmen wir nochmal das Beispiel "Modaler Dialog". Das Verhalten lässt sich doch hinreichend genau definieren. Warum kann das kein browserimmanentes Verhalten sein? Warum extra JS? Und wenn ich Gunther richtig verstehe, wirds eher schlimmer.

2. HTML5 führt mit details/summary, menu, @contextmenu und dialog bereits generischen UI-Controls ein. Es ist nur noch nicht auf breite Unterstützung gestoßen.

Das meine ich mit "Mir geht alles viel zu langsam"

3. Viele JavaScript-Frameworks, inbesondere für Mobilgeräte, bieten solche UI-Komponenten von Haus aus. Die funktionieren mit vielen Eingabemethoden und Viewport-Größen. In Frameworks wie Angular lassen sich die Komponenten auch so verwenden, wie du es oben demonstrierst.

Auch hier stellt sich mir die Frage: Warum sind die Controls kein fester Bestandteil? Was wäre das für ein Aufreger, wenn man Scrollbars, Eingabefelder und Checkboxen mit einem JS-Framework erstellen müsste? Da geht doch was in die falsche Richtung. Oder es ist nicht konsequent durchdacht.

Viele Grüße
Siri

[Gunther]

Hallo Mathias und alle anderen!

Und muss es denn sein, dass man eben massenweise JS mitliefert um die Unterschiede auszubügeln?

Erstens ist so etwas wie Modernizr und yepnope nicht »massenweise JavaScript«, sondern ein stark begrenztes und zugeschnittenes Script. Zweitens, ja, es muss derzeit sein. Es ist manchmal sauberer, ein Feature mit JavaScript abzufragen, als im CSS oder sonstwo Progressive Enhancement versuchen.

Ja, die Dinge sind wie sie sind, aber es könnte doch alles viel einfacher sein

Auf jeden Fall könnte es einfacher sein. Ich sehe aber nicht, dass es einfacher werden würde, wenn der Browser dem Server mit jedem Request mitteilen würde, welche CSS-Eigenschaft und JavaScript-APIs er in welcher Revision unterstützt. Eine browserseitige Programmiersprache wie JavaScript, die tatsächliche Anwendungsfälle live testen kann, ist da immer irgendwelchen Bekundungen des Browsers überlegen, ein gewisses Feature zu unterstützen.

Dem würde ich sofort und uneingeschränkt zustimmen, wenn da nicht die Möglichkeit wäre, dass der User Javascript deaktiviert hat.

Lange Zeit wurde nicht nur hier gebetsmühlenartig gepredigt sein Layout nicht von Javascript abhängig zu machen! Und ich persönlich sehe ich das auch immer noch so, sprich auch der User ohne JS muss eine zumindest halbwegs brauchbare Seite angezeigt bekommen. Und das erhöht quasi den Aufwand weiter, da man dann nicht nur die Unterschiede der verschiedenen Browser "ausbügeln" muss, sondern zusätzlich noch im CSS unterscheiden muss, zwischen JS ja/ nein.

Von den Media Queries einmal abgesehen, gibt es erst seit kurzem das 'CSS Conditional Rules Module Level 3'. Aktuell wird @supports allerdings nur von Opera (12.10), Opera Mobile (14.0) und Firefox Aurora unterstützt. Und selbst wenn es alle gängigen Browser eines Tages unterstützen, wird es noch lange dauern, bis es seine "volle Wirkung" entfalten kann, denn dazu müssen erst alle Versionen, die zwar das entsprechende Modul/ Feature unterstützen, aber nicht @supports, verschwunden sein.

Und mir geht dieser Ansatz, der viel zu spät kommt, auch noch nicht weit genug. Denn Theorie und Praxis sind ja immer zwei verschiedene Dinge. Will sagen, theoretisch könnte man "einfaches & effizientes" CSS schreiben - in der Praxis sieht das aufgrund von unterschiedlichen "Interpretationen" der Spezifikationen und individueller Browserbugs schon ganz anders aus ...!

Von daher plädiere ich seit langem dafür, dass man in CSS einen den 'Conditional Comments' ähnlichen Mechanismus implementiert, der das gezielte Ansprechen bestimmter Engines und Browsern ermöglicht, ohne auf irgendwelche 'Hacks' zurückgreifen zu müssen.

Das könnte dann analog zu den bereits existierenden @-rules z.B. so aussehen:
@browser(chrome 20+) {...}
oder
@engine(webkit) {...}

CSS kommt mir schon geraume Zeit so vor, als würden sich die Entwickler stets an dem Grundsatz:"Warum einfach, wenn es auch kompliziert geht!" orientieren. ;-)

Ich meine spätestens, wenn bei etlichen Websites der Umfang der zugehörigen CSS Datei(en) größer ist als der eigentliche Inhalt, muss man sich doch mal fragen, ob das alles wirklich so "richtig" ist!

In 99% aller Fälle gucken sich User eine Seite in einem Browser an - fertig!
Bei den allermeisten Smartphones hat das Browserfenster eine unveränderliche Größe. Warum muss man solch einem Client dann die anderen 90% des CSS ausliefern, mit denen er nichts anfangen kann!?

Und die Browserhersteller tun ein Übriges ...! So "nötigen" sie einen quasi zu serverseitigem UA-Sniffing, wenn du dem User die Möglichkeit geben willst, auch die sog. Desktopversion der Seite zu sehen. Und ja, das kann aufgrund einer weiteren "Willkür" der Browserhersteller sehr wohl "sinnvoll" sein. Ich spreche von der "willkürlichen" Festlegung der Viewportgröße. Auch hier hat man imho nicht bis zu Ende gedacht.

Ein Beispiel:
Ich besitze ein Smartphone mit einem Full HD Display. Gemäß Browserhersteller ist mein Viewport aber nicht 1080px breit, sondern nur 360px. Und selbst wenn ich die Desktopversion einer Seite anfordere, dann ist mein Viewport immer noch nicht so groß, wie es der eigentlichen Auflösung entsprechen würde, sondern immer noch nur 980px. Wenn ich jetzt das Bild von meinem Smartphone auf einen Monitor oder Fernseher streame, habe ich trotz vlt. 40" Bildschirmdiagonale eine Webseitendarstellung, die gemäß Media Query für 980px bestimmt ist ...!

Und die geplante Abschaffung des zuständigen Meta-Tags, und die Verlagerung ins CSS (@viewport), ist ein Schritt vom Regen in die Traufe ...!

Es gibt also imho mehrere Baustellen:
1. Es müssen neue Möglichkeiten her, effizienteres CSS schreiben zu können.
2. Es müssen Möglichkeiten her, die übermittelte Datenmenge auf das wirklich Erforderliche reduzieren zu können.
3. Es müssen Möglichkeiten her, clientseitig für das Layout relevante Dinge auch ohne JS in Erfahrung bringen zu können.

Wie das letztendlich erreicht wird, ist mir egal! :-P
Nur insbesondere im Bezug auf Punkt 2, sehe ich da eigentlich nur serverseitige Möglichkeiten. Und alles, was nicht mit dem Request mitgeliefert wird, kommt imho zu spät.

Gruß Gunther

[molily]

Hallo,

Lange Zeit wurde nicht nur hier gebetsmühlenartig gepredigt sein Layout nicht von Javascript abhängig zu machen!

Das sollte idealerweise so sein. Wenn es einem nicht auf jeden übertragenen Byte ankommt und man keine Scheu hat, z.B. ein float-/position-CSS immer zu laden, selbst wenn ein JavaScript später ein Flexbox-CSS hinzulädt und ersteres deaktiviert, so ist Progressive Enhancement auch möglich.

Von daher plädiere ich seit langem dafür, dass man in CSS einen den 'Conditional Comments' ähnlichen Mechanismus implementiert, der das gezielte Ansprechen bestimmter Engines und Browsern ermöglicht, ohne auf irgendwelche 'Hacks' zurückgreifen zu müssen.

Das Webdesign hat die letzten 10 Jahre gebraucht, um diese Methode zu überwinden. Die Webstandards-Bewegung hat sich 10 Jahre lang den Mund fusselig geredet beim Kampf gegen browserspezifischen Code und Browser-Abfragen.

Möglich ist das immer noch, sowohl client- als auch serverseitig, und es wird allerorten trotz besseren Wissens getan. Aber jeder, der an der Web-Plattform arbeitet (Webstandards, Browser, Authoring Tools usw.), will diese Methode irgendwann gänzlich begraben.

Ich meine spätestens, wenn bei etlichen Websites der Umfang der zugehörigen CSS Datei(en) größer ist als der eigentliche Inhalt, muss man sich doch mal fragen, ob das alles wirklich so "richtig" ist!

Dann macht der Autor höchstwahrscheinlich etwas falsch – oder das CSS umfasst sinnvollerweise Styles für die gesamte Site, nicht nur für das aktuelle Dokument.

Warum muss man solch einem Client dann die anderen 90% des CSS ausliefern, mit denen er nichts anfangen kann!?

Muss man nicht.

Es ist einfach eine Erfahrung der Performance-Optimierung, dass es einfacher und schneller ist, alles in eine Datei zu packen, anstatt auf einem Gerät mit High-Latency-Internetzugang dutzende Requests abzuschicken, um nur das nötigste zu laden.

Natürlich gibt es elaborierte Modulserver, die HTML/CSS/JS-Pakete schnüren, wie sie der Client gerade braucht. Dann ist auch Lazy Loading problemlos möglich. Allerdings bringt das eine riesige Komplexität mit sich und die gegenwärtigen Webtechniken sind noch nicht darauf ausgelegt.

Und die Browserhersteller tun ein Übriges ...! So "nötigen" sie einen quasi zu serverseitigem UA-Sniffing, wenn du dem User die Möglichkeit geben willst, auch die sog. Desktopversion der Seite zu sehen.

Das verstehe ich nicht.

Und die geplante Abschaffung des zuständigen Meta-Tags, und die Verlagerung ins CSS (@viewport), ist ein Schritt vom Regen in die Traufe ...!

Warum?

1. Es müssen neue Möglichkeiten her, effizienteres CSS schreiben zu können.

Du meinst Sass?

2. Es müssen Möglichkeiten her, die übermittelte Datenmenge auf das wirklich Erforderliche reduzieren zu können.

Du meinst SPDY?

3. Es müssen Möglichkeiten her, clientseitig für das Layout relevante Dinge auch ohne JS in Erfahrung bringen zu können.

Im Gegenteil. Das Problem, Fähigkeiten in Erfahrung bringen zu müssen, sollte in Zukunft vermieden werden. Es müssen Webtechniken entstehen, die in den Browsern erst freigeschaltet werden, wenn W3C Candidate Recommendations existieren. Genau das machen Chrome und Firefox in Zukunft. Keine Vendor-Prefixes mehr, keine verbuggten proprietären Vorab-Implementierungen.

Sicherlich wird es immer noch die Notwendigkeit geben, z.B. zwischen float-/position- und Flexbox-Layout zu unterscheiden. Das geht nicht so einfach ohne Modernizr & yepnope (JavaScript-Featureabfrage und bedingtes Laden von Stylesheets).

Mathias

[Gunther]

Hallo,

Von daher plädiere ich seit langem dafür, dass man in CSS einen den 'Conditional Comments' ähnlichen Mechanismus implementiert, der das gezielte Ansprechen bestimmter Engines und Browsern ermöglicht, ohne auf irgendwelche 'Hacks' zurückgreifen zu müssen.

Das Webdesign hat die letzten 10 Jahre gebraucht, um diese Methode zu überwinden. Die Webstandards-Bewegung hat sich 10 Jahre lang den Mund fusselig geredet beim Kampf gegen browserspezifischen Code und Browser-Abfragen.

Ich sehe das nicht so "dogmatisch" ...! ;-)
Die letzten 10 Jahre haben auch gezeigt, dass es immer Unterschiede zwischen Theorie & Praxis gibt und geben wird. Es nutzt doch herzlich wenig, wenn zwar theoretisch alle (gängigen) Browser 'table display' unterstützen, die Interpretation in der Praxis aber weit auseinander geht! Da wäre es mir zumindest lieber, ich könnte meinen (extra) CSS-Code sehr einfach auf den/ die erforderlichen Browser eingrenzen.

Möglich ist das immer noch, sowohl client- als auch serverseitig, und es wird allerorten trotz besseren Wissens getan. Aber jeder, der an der Web-Plattform arbeitet (Webstandards, Browser, Authoring Tools usw.), will diese Methode irgendwann gänzlich begraben.

Und wann soll das "irgendwann" sein!?
Was lässt dich annehmen, dass das, was die letzten 10 Jahre nicht geklappt hat, in naher Zukunft klappt? Und was machen wir in der Zwischenzeit?

Das ist doch genau eine der Diskrepanzen, von der ich gesprochen habe. Bei der (Weiter-)Entwicklung von CSS werden doch die tatsächlichen Gegebenheiten und Realitäten stur "ignoriert/ übersehen". Und für heutige Problemstellungen jetzt anzufangen Lösungen auf dem gewohnten Weg zu erstellen, dauert bis zu deren praktischen Nutzbarkeit doch viel zu lange. Auch das haben die letzten 10 Jahre hinlänglich genug bewiesen ...!

Und die Browserhersteller tun ein Übriges ...! So "nötigen" sie einen quasi zu serverseitigem UA-Sniffing, wenn du dem User die Möglichkeit geben willst, auch die sog. Desktopversion der Seite zu sehen.

Das verstehe ich nicht.

Was verstehst du daran nicht (siehe auch mein Beispiel bezüglich der Viewportgröße)?

Und die geplante Abschaffung des zuständigen Meta-Tags, und die Verlagerung ins CSS (@viewport), ist ein Schritt vom Regen in die Traufe ...!

Warum?

Weil das das Problem lediglich verlagert (von HTML nach CSS), aber nicht löst ...!

1. Es müssen neue Möglichkeiten her, effizienteres CSS schreiben zu können.

Du meinst Sass?

Nein, meine ich nicht. ;-)
SASS & Co. erleichtern vielleicht das Schreiben, verändern aber nichts an der Tatsache, dass CSS von Hause aus ineffizient ist.

2. Es müssen Möglichkeiten her, die übermittelte Datenmenge auf das wirklich Erforderliche reduzieren zu können.

Du meinst SPDY?

Hmmm ..., I am not quite sure.
Inwiefern hat das etwas mit der eigentlichen Datenmenge zu tun (mal abgesehen davon, dass diese komprimiert wird)? Soweit ich das verstehe, ändert das aber nichts daran, dass jedem CLient trotzdem Unmengen an Daten geschickt werden, die er eigentlich gar nicht braucht, oder?

3. Es müssen Möglichkeiten her, clientseitig für das Layout relevante Dinge auch ohne JS in Erfahrung bringen zu können.

Im Gegenteil. Das Problem, Fähigkeiten in Erfahrung bringen zu müssen, sollte in Zukunft vermieden werden. Es müssen Webtechniken entstehen, die in den Browsern erst freigeschaltet werden, wenn W3C Candidate Recommendations existieren. Genau das machen Chrome und Firefox in Zukunft. Keine Vendor-Prefixes mehr, keine verbuggten proprietären Vorab-Implementierungen.

Sorry, aber das sehe ich anders. Du wirst immer die Notwendigkeit haben, gemäß den unterstützten CSS Fähigkeiten des jeweiligen Browsers im CSS zu unterscheiden. Mit JS ist das auch relativ einfach und in ausreichendem Maße möglich. Nutzt aber nichts, solange wie man dessen Verfügbarkeit nicht mit 100% voraussetzen kann. Und die Umsetzung in CSS (via @supports) hat die bereits weiter oben erwähnten Probleme und reicht vom Umfang der Möglichkeiten her auch bei weitem nicht aus.

Sicherlich wird es immer noch die Notwendigkeit geben, z.B. zwischen float-/position- und Flexbox-Layout zu unterscheiden. Das geht nicht so einfach ohne Modernizr & yepnope (JavaScript-Featureabfrage und bedingtes Laden von Stylesheets).

Hehe ..., fällt dir auf, wie paradox das ist!? ;-)
Wenn ich JS zur Verfügung habe, brauche ich gar kein Flexbox-Layout ...! :-P
Brauchen tue ich es nämlich eigentlich nur dann, wenn eben kein JS verfügbar ist, um bspw. den Effekt der gleich hohen Boxen oder der Änderung der Reihenfolge von Elementen zu erreichen.

Da du schon davon angefangen hast und das imho aktuell ein recht gutes Beispiel ist:
Für Browser, die das Flexbox Modul unterstützen, wollen wir natürlich auch dieses verwenden.
Für andere Browser, die das Flexbox Modul nicht unterstützen, weichen wir auf display:table als Fallback aus. Und wenn du auch noch den IE 7 mit reinnehmen willst, brauchst du noch einen weiteren Fallback.

Jetzt wäre es doch höchst hilfreich, wenn ich in meinem CSS die jeweiligen Browser einfach unterscheiden könnte (ohne JS!), oder nicht?

Und es ist in solchen Fällen eben meist auch nicht damit getan, z.B. nur die jeweilige diplay Eigenschaft zu ändern. Denn oftmals braucht man auch unterschiedliche Werte für andere Eigenschaften, die aber wiederum von allen, oder zumindest mehreren Browsern verstanden werden. Und dann? Dann stehst du ohne z.B. entsprechende Kenntnis über den jeweiligen Browser/ die Engine mit CSS alleine auf dem Schlauch ...!

Und mir ist zur Lösung solcher Probleme (ohne JS) bislang nur UA-Sniffing (und für die IEs CCs) eingefallen ..., aber wenn du andere/ bessere Lösungen kennst ...?

Gruß Gunther

[Christian Kruse]

Moin Siri,

Aber mit dieser Meinung stehe ich (zusammen mit Gunther) -zumindest im Forum- alleine auf weiter Flur...

Sicher nicht.

Das bedeutet aber nicht, dass man nicht positiv bemerken kann, dass sich auch viel getan hat inzwischen :)

LG,
 CK

[Siri]

Hallo,

Das bedeutet aber nicht, dass man nicht positiv bemerken kann, dass sich auch viel getan hat inzwischen :)

Das kann man natürlich und sollte es auch tun!

Ich kenn nur bei mir einen ähnlichen "Aha! Toll-was-sich-getan-hat!"-Effekt um dann etwas ernüchtert festzustellen, dass man heute eben mit verschiedenen Endgeräteklassen kämpft und darauf mit unterschiedlichen Browsern sowie man früher halt mit unterschiedlichen Browsern gekämpft hat. Früher war's die CSS-Weiche heute sind es Media-Queries. Gut das man es kann, aber ist das Fortschritt? Ich würde mich lieber darauf konzentrieren, mir eine schicke Oberfläche auszudenken (inkl. Look & Feel und Usability) als mich darauf konzentrieren zu müssen, wieviel Versionen zu bauen sind um überall zumindest etwas ähnliches zu haben, bei dem der geneigte App-User nicht zu gähnen anfängt.

Viele Grüße
Siri

[molily]

Hallo,

Der Fortschritt besteht nicht in einer Explosion neuer phantastischer Möglichkeiten, sondern in der Anwendungssicherheit höchst sinnvoller Innovationen.

Ich sehe den relevanten Fortschritt ebenfalls nicht in den technischen Möglichkeiten. Neue CSS-Features und JavaScript-APIs sind bloß einzelne Werkzeuge. Die meisten Techniken sind auch abwärtskompatibel einsetzbar, und die Site funktioniert (im nicht-technischen Sinne) trotzdem. Einmal abgesehen von reinen WebGL-Spielen, da wird ein Fallback schwierig.

Der Fortschritt ist für mich das, was das Webdesign und die Software-Entwicklung aus dem explosiven Wachstum der Web-Plattform macht. Beispielsweise:

• Wenn ich Responsive Design, CSS3, SVG, Canvas, WebGL, HTML5-Video usw. habe, wie kann ich die Techniken für nützliches, schönes, beeindruckendes, flüssiges User Interface Design verwenden?
• Wie kann ich meinen Code sinnvoll organisieren, modularisieren, testen, wiederverwenden? Wie sehen
  Best Practices aus und wie kann ich Design Patterns, Frameworks, Metasprachen & Transpiler sinnvoll anwenden?

Viele Sites, die die neuesten Techniken verwenden, sind in dieser Hinsicht eher konservativ und keinesfalls innovativ. Das ist nichts schlimmes, ich kann auch mit neuen Techniken altbewährte Konzepte erfolgreich umsetzen. Interessant wird es, wenn Websites sich z.B. am Look & Feel von nativen Apps versuchen – visuell anspruchsvoll, multimedial und vielseitig bedienbar – oder ganz neue Bedienkonzepte erfinden, die bisher im Web nicht möglich waren.

Mathias