mathefritz: Beispiel nicht nachvollziehbar

0 59

Beispiel nicht nachvollziehbar

mathefritz
  • html
  • javascript
  1. 0
    Christian Kruse
    1. 0
      Tabellenkalk
      1. 0
        Christian Kruse
        1. 0
          Tabellenkalk
          • selfhtml-wiki
          1. 0
            Christian Kruse
            1. 0
              Tabellenkalk
              • zu diesem forum
              1. 0
                Christian Kruse
    2. 0
      mathefritz
      1. 1
        Orlok
        • html
        1. 0
          Der Martin
          1. 0
            Gunnar Bittersmann
            1. 0
              Der Martin
            2. 0
              Matthias Apsel
              1. 0
                Gunnar Bittersmann
          2. 0
            1unitedpower
            • css
            • javascript
            1. 0
              Der Martin
              1. 0
                Orlok
                1. 1
                  Gunnar Bittersmann
                  1. 1
                    MudGuard
                  2. 1
                    Regina
                    1. 1
                      Der Martin
                      1. 2
                        Regina
                      2. 0
                        Gunnar Bittersmann
                        1. 0
                          Der Martin
                  3. 0
                    JürgenB
                  4. 0
                    1unitedpower
                    1. 0
                      marctrix
                      1. 0
                        1unitedpower
                        1. 0
                          marctrix
                          1. 0
                            1unitedpower
                            1. 0
                              Der Martin
                              1. 1

                                CSS Houdini

                                Gunnar Bittersmann
                            2. 0
                              marctrix
                              1. 0
                                Gunnar Bittersmann
                                1. 0
                                  marctrix
                                  1. 0
                                    Gunnar Bittersmann
                              2. 0
                                1unitedpower
                                1. 0
                                  marctrix
                                  1. 0
                                    1unitedpower
                              3. 0
                                Gunnar Bittersmann
                                1. 0
                                  marctrix
                                2. 0
                                  1unitedpower
                                  1. 0
                                    marctrix
                                    1. 0
                                      Gunnar Bittersmann
                                      • css
                                      • performance
                                      1. 0
                                        marctrix
                                        1. 0
                                          Gunnar Bittersmann
                                          1. 0
                                            marctrix
                                      2. 0
                                        1unitedpower
                                        1. 0
                                          Gunnar Bittersmann
                                          1. 0
                                            1unitedpower
                      2. 0
                        Der Martin
                        1. 0
                          1unitedpower
                          1. 0
                            Der Martin
                          2. 0
                            marctrix
                        2. 0
                          marctrix
                          1. 0
                            Der Martin
  2. 0

    Beispiel nicht existent

    Auge
    1. 0
      dedlfix

problematische Seite

das hidden = false

im Beispiel in http://wiki.selfhtml.org/wiki/AddEventListener

konnte ich nicht nachvollziehen ( firefox 47.0 ) ; wenn das hidden = false direkt verwendet wird bleibt nur mehr der Text "false" übrig, ein "reload" bleibt erfolglos; einiges Probieren zeigte schließlich daß man void(...) verwenden muß .

<html>
  <head>
    <title></title>
    <meta content="">
    <style></style>
  </head>
  <body>
  
    <span id="h" hidden>versteck</span><br>
    
    <a href="javascript:void(document.getElementById('h').hidden=false);">zeigen direkt</a>
    <br>
    <a href="javascript:document.getElementById('h').hidden=false;">zeigen direkt ohne "voiding"</a>
    <br>
    <a href="javascript:show();">zeigen mit function </a>
    <br>
    <a href="javascript:void(document.getElementById('h').hidden=true);">verstecken</a>
    
    <script> function show(){ document.getElementById('h').hidden=false;}
   </script>
  </body>
</html>
  1. problematische Seite

    Hallo mathefritz,

    das hidden = false

    im Beispiel in http://wiki.selfhtml.org/wiki/AddEventListener

    konnte ich nicht nachvollziehen ( firefox 47.0 ) ; wenn das hidden = false direkt verwendet wird bleibt nur mehr der Text "false" übrig, ein "reload" bleibt erfolglos; einiges Probieren zeigte schließlich daß man void(...) verwenden muß . […]

    In dem von dir verlinkten Beispiel wird - im Gegensatz zu in deinem Code - kein JS-Link verwendet. Worauf möchtest du hinaus?

    LG,
    CK

    1. problematische Seite

      Hallo,

      In dem von dir verlinkten Beispiel

      da ist er unschuldig. Er hatte die URL nicht verlinkt, das habe ich nachträglich gemacht.

      Gruß
      Kalk

      1. problematische Seite

        Hallo Tabellenkalk,

        In dem von dir verlinkten Beispiel

        da ist er unschuldig. Er hatte die URL nicht verlinkt, das habe ich nachträglich gemacht.

        Die „problematische Seite” auch?

        Wie auch immer, ich verstehe es trotzdem nicht. Und ich kann mir auch nicht vorstellen, dass das Code aus dem Wiki ist und habe auch nichts dergleichen gefunden - und wenn doch, dann sollten wir ihn sofort löschen.

        LG,
        CK

        1. problematische Seite

          Hallo,

          Die „problematische Seite” auch?

          Wieso auch? Ich nahm die nicht verlinkte URL aus dem Posting und habe sie als problematische Seite eingetragen.

          Wie auch immer, ich verstehe es trotzdem nicht. Und ich kann mir auch nicht vorstellen, dass das Code aus dem Wiki ist und habe auch nichts dergleichen gefunden - und wenn doch, dann sollten wir ihn sofort löschen.

          Ich war auch verwirrt, dass dort dann die Beispiele ganz anders aussahen.

          Gruß
          Kalk

          1. problematische Seite

            Hallo Tabellenkalk,

            Die „problematische Seite” auch?

            Wieso auch? Ich nahm die nicht verlinkte URL aus dem Posting und habe sie als problematische Seite eingetragen.

            Ah, das ist es, was mir als Information gefehlt hat ;-)

            LG,
            CK

            1. problematische Seite

              Hallo,

              Ah, das ist es, was mir als Information gefehlt hat ;-)

              Das wird in der Versionsansicht ja auch überhaupt nicht angezeigt. Wen sollte man deswegen mal ansprechen, @Christian Kruse?

              Gruß
              Kalk

              1. problematische Seite

                Hallo Tabellenkalk,

                Ah, das ist es, was mir als Information gefehlt hat ;-)

                Das wird in der Versionsansicht ja auch überhaupt nicht angezeigt. Wen sollte man deswegen mal ansprechen, @Christian Kruse?

                Gute Frage, wer das wohl sein mag…? Gibt es hier sowas wie eine Hilfe-Seite oder eine Charta oder so? 😂

                LG,
                CK

    2. problematische Seite

      Danke. naja, es war neu für mich daß man dieses style-feature einfach so setzen kann.
      Die
      Frage die sich jetzt stellt, welche noch?

      1. problematische Seite

        Hallo

        Naja, es war neu für mich daß man dieses style-feature einfach so setzen kann.

        Ursprünglich sah das Anwendungsbeispiel auf der Seite zu addEventListener vor, eine Meldung mittels alert auszugeben, was ich geändert habe, als ich vor nicht allzu langer Zeit zufällig auf der Seite vorbeigekommen bin, denn alert sollte in Beispielen nicht mehr verwendet werden.

        Normalerweise hätte ich den Aufruf von alert einfach durch ein console.log ersetzt, aber da es sich hier um ein live-Beispiel handelt und nicht nur um JavaScript-Code, habe ich die Meldung ins Markup geschrieben und dem Element das Attribut hidden verpasst.

        Das Attribut hidden deswegen, weil die in einem Paragraph-Element hinterlegte Meldung erst nach einer Benutzeraktion inhaltlich relevant wird. Das heißt, die Entscheidung das hidden-Attribut zu setzen war in erster Linie eine inhaltliche Entscheidung und keine Frage der Gestaltung.

        Will sagen, es handelt sich bei hidden nicht um ein style-feature, sondern vielmehr ermöglicht es das Attribut, einem Element eine bestimmte Semantik zu geben, nämlich dass es nicht, nicht mehr, oder noch nicht inhaltlich von Bedeutung ist.

        Die Frage die sich jetzt stellt, welche noch?

        Die Frage stellt sich nicht, wenn man die Trennung der Zuständigkeiten beachtet. Die Gestaltung betreffende Informationen gehören ins Stylesheet und nicht ins Markup.

        Viele Grüße,

        Orlok

        1. problematische Seite

          Hi,

          Die Frage die sich jetzt stellt, welche noch?

          Die Frage stellt sich nicht, ...

          doch, schon - und ich finde sie durchaus legitim. Separation of Concerns ist gut und richtig, aber es ist auch gut zu wissen, dass man mit Javascript eigentlich auf alle Objekteigenschaften einwirken kann. Dabei muss es ja nicht immer um gestalterische Eingriffe gehen; auch die Funktionalität kann so beeinflusst werden, z.B. indem man den Typ eines Formularfeldes oder das Ziel eines Formulars in Abhängigkeit von bestimmten Bedingungen ändert. Ob das jeweils sinnvoll ist, sollte im Einzelfall beurteilt werden.

          Die Gestaltung betreffende Informationen gehören ins Stylesheet und nicht ins Markup.

          Da sind wir uns einig. Und mit Javascript kann man bestimmte Eigenschaften des Elements, z.B. seine Klasse(n) oder die eines Vorfahrenelements, so ändern, dass unterschiedliche Regeln des Stylesheets wirksam werden.

          So long,
           Martin

          --
          Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
          - Douglas Adams, The Hitchhiker's Guide To The Galaxy
          1. problematische Seite

            @@Der Martin

            Separation of Concerns ist gut und richtig, aber es ist auch gut zu wissen, dass man mit Javascript eigentlich auf alle Objekteigenschaften einwirken kann.

            Verbunden mit dem Wissen, dass man mit Javascript nicht auf alle Objekteigenschaften einwirken sollte.

            indem man den Typ eines Formularfeldes […] ändert.

            Zum Beispiel von password auf text, um seine Eingabe kontrollieren zu können.

            Traurig, dass man das immer noch mit JavaScript tun muss, anstatt dass Browser bei jedem <input type="password"> einen Button anbieten, wo der Nutzer die Sichtbarkeit des Passwortes umschalten kann.

            LLAP 🖖

            --
            “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
            Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
            1. problematische Seite

              Hallo,

              Separation of Concerns ist gut und richtig, aber es ist auch gut zu wissen, dass man mit Javascript eigentlich auf alle Objekteigenschaften einwirken kann.

              Verbunden mit dem Wissen, dass man mit Javascript nicht auf alle Objekteigenschaften einwirken sollte.

              natürlich, das meinte ich mit dem Hinweis, dass die Sinnhaftigkeit im Einzelfall geprüft werden solle.

              indem man den Typ eines Formularfeldes […] ändert.

              Zum Beispiel von password auf text, um seine Eingabe kontrollieren zu können.

              Das Beispiel ist mir nicht eingefallen.

              Traurig, dass man das immer noch mit JavaScript tun muss, anstatt dass Browser bei jedem <input type="password"> einen Button anbieten, wo der Nutzer die Sichtbarkeit des Passwortes umschalten kann.

              Ja, das wäre in der Tat wünschenswert.

              Ciao,
               Martin

              --
              Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
              - Douglas Adams, The Hitchhiker's Guide To The Galaxy
            2. problematische Seite

              Hallo Gunnar Bittersmann,

              indem man den Typ eines Formularfeldes […] ändert.

              Zum Beispiel von password auf text, um seine Eingabe kontrollieren zu können.

              Traurig, dass man das immer noch mit JavaScript tun muss, anstatt dass Browser bei jedem <input type="password"> einen Button anbieten, wo der Nutzer die Sichtbarkeit des Passwortes umschalten kann.

              Der IE tut das schon recht lange (schon der Achter abhängig vom BS). Zwar nicht als Button sondern in Form eines Auges am rechten Rand des Inputfeldes. Und iirc kann man das Passwort nur so lange lesen, wie man das Auge anklickt.

              Bis demnächst
              Matthias

              --
              Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
              1. problematische Seite

                @@Matthias Apsel

                Traurig, dass man das immer noch mit JavaScript tun muss, anstatt dass Browser bei jedem <input type="password"> einen Button anbieten, wo der Nutzer die Sichtbarkeit des Passwortes umschalten kann.

                Der IE tut das schon recht lange (schon der Achter abhängig vom BS).

                ’sch weiß.

                Zwar nicht als Button sondern in Form eines Auges am rechten Rand des Inputfeldes.

                Das würde ich schon Button nennen, auch wenn’s keinen Rahmen hat.

                Und iirc kann man das Passwort nur so lange lesen, wie man das Auge anklickt.

                Und das ist es, was das Auge nur halbgut macht. Man kann die Eingabe hinterher überprüfen, aber nicht während der Eingabe.

                LLAP 🖖

                --
                “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
                Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
          2. problematische Seite

            Die Frage die sich jetzt stellt, welche noch?

            Die Frage stellt sich nicht, ...

            doch, schon - und ich finde sie durchaus legitim. Separation of Concerns ist gut und richtig, aber es ist auch gut zu wissen, dass man mit Javascript eigentlich auf alle Objekteigenschaften einwirken kann.

            Eigentlich nicht. Gerade die Schnittstelle zwischen JavaScript und CSS ist lange Zeit vernachlässigt worden. Der Entwicklungsprozess ist zwar offen, die Einstiegshürden aber zu hoch um daraus eine Innovationskultur wachsen zu lassen. Die Weiterentwicklung ist zwischenzeitlich so dermaßen erlahmt, es wäre leichter dem Gras beim Wachsen zuzuschauen. Ich hoffe inständig, dass die CSS Houdini Task Force diese Apathie beenden kann, leider mangelt es dafür noch an Traktion. Die Bemühungen zielen jedenfalls darauf ab, niedrig schichtige Routinen der Rendering-Engines in öffentlichen Schnittstellen verfügbar zu machen. Dadurch wird ein prototypischer Ansatz ermöglicht, der Entwickler(innen) aus ihrer Passivität abholen könnte. Beispielsweise könnte ein(e) Entwickler(in) in Zukunft einen eigenen Layout-Algorithmus ersinnen und mit JavaScript implementieren. Wenn das Projekt Popularität erlangt stehen die Chancen gut, dass Konzepte daraus zurück in den Standard fließen und bald darauf flächendeckend eingesetzt werden können.

            1. problematische Seite

              Hallo,

              Separation of Concerns ist gut und richtig, aber es ist auch gut zu wissen, dass man mit Javascript eigentlich auf alle Objekteigenschaften einwirken kann.

              Eigentlich nicht. Gerade die Schnittstelle zwischen JavaScript und CSS ist lange Zeit vernachlässigt worden.

              jetzt verblüffst du mich. Es gibt eine Schnittstelle zwischen Javascript und CSS? Du meinst, über die Zugriffsmöglichkeiten auf element.style oder das Absuchen des DOM mit querySelector() hinaus? Wenn ja, was soll diese Schnittstelle leisten und wofür könnte sie gut sein?

              Ich habe Javascript bisher immer nur als einen Weg gesehen, mit dem DOM und einzelnen Objekten davon zu interagieren, nicht mit CSS - oder wenn, dann eben nur indirekt.

              Beispielsweise könnte ein(e) Entwickler(in) in Zukunft einen eigenen Layout-Algorithmus ersinnen und mit JavaScript implementieren.

              Ich kann im Moment noch keinen Sinn dahinter erkennen.

              So long,
               Martin

              --
              Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
              - Douglas Adams, The Hitchhiker's Guide To The Galaxy
              1. problematische Seite

                Hallo Martin

                Es gibt eine Schnittstelle zwischen Javascript und CSS? Du meinst, über die Zugriffsmöglichkeiten auf element.style oder das Absuchen des DOM mit querySelector() hinaus?

                Es gibt das CSS Object Model, das eine ganze Reihe an Schnittstellen bereitstellt, die über das Style-Objekt und die Methode querySelector hinausgehen.

                Du kannst dir beispielsweise über document.styleSheets eine Liste der eingebundenen Stylesheets in Form von CSSStyleSheet-Objekten ausgeben lassen, welche wiederum Zugriff auf die dort definierten Regeln gewähren, in Form von CSSRule-Objekten.

                // get CSSStyleSheet object
                const stylesheet = document.styleSheets[0];
                
                // get CSSRule object
                const rule = stylesheet.cssRules[0];
                
                // log value
                console.log(rule.cssText); // maybe: 'body { background-color: blue; }'
                

                Über die Methoden insertRule und deleteRule von CSSStyleSheet-Objekten kannst du einem Stylesheet Regeln hinzufügen oder Regeln löschen.

                // get CSSStyleSheet object
                const stylesheet = document.styleSheets[0];
                
                // get index position
                const index = stylesheet.cssRules.length;
                
                // add rule to stylesheet
                stylesheet.insertRule('h1 { text-align: center; }', index);
                

                Darüber hinaus hast du über die CSSStyleRule-Schnittstelle auch Zugriff auf die einzelnen Regeln und kannst beispielsweise über die Eigenschaft selectorText den Selektor lesen oder neu setzen, wobei letzteres aber wohl im Moment kaum unterstützt wird.

                // get previously added rule
                const rule = stylesheet.cssRules[1];
                
                // log selector
                console.log(rule.selectorText); // 'h1'
                

                Jedenfalls kann natürlich nicht nur auf den Selektor einer Regel zugegriffen werden, sondern es gibt auch die Eigenschaft style, welche ein CSSStyleDeclaration-Objekt zurückgibt, das eine Reihe von Methoden zur Arbeit mit den in der CSSStyleRule definierten Eigenschaften bereitstellt.

                // get previously added rule
                const rule = stylesheet.cssRules[1];
                
                // get property value
                console.log(rule.style.getPropertyValue('text-align')); // 'center'
                

                Also, wie dem auch sei, das ist natürlich nur ein kleiner Überblick, aber du siehst, es gibt durchaus eine ganze Reihe an Anknüpfungspunkten zwischen CSS und JavaScript. Aber sowohl Theorie als auch Praxis lassen hier noch einiges zu wünschen übrig, wie 1unitedpower ja schon andeutete …

                Viele Grüße,

                Orlok

                1. problematische Seite

                  @@Orlok

                  du siehst, es gibt durchaus eine ganze Reihe an Anknüpfungspunkten zwischen CSS und JavaScript.

                  Schön, man kann CSS mit JavaScript ändern.

                  Aber was ist ein sinnvoller Anwendungsfall? Warum sollte man das tun wollen?

                  LLAP 🖖

                  --
                  “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
                  Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                  1. problematische Seite

                    Hi,

                    Aber was ist ein sinnvoller Anwendungsfall? Warum sollte man das tun wollen?

                    um z.B. den User eine Farbe für ein Element auswählen zu lassen.

                    cu,
                    Andreas a/k/a MudGuard

                  2. problematische Seite

                    du siehst, es gibt durchaus eine ganze Reihe an Anknüpfungspunkten zwischen CSS und JavaScript.

                    Schön, man kann CSS mit JavaScript ändern.

                    Aber was ist ein sinnvoller Anwendungsfall? Warum sollte man das tun wollen?

                    Bspw. wg. progressive enhancement und Barrierefreiheit? Ich biete auf meiner Seite mehrere verschiedene Styles an: Z.B. einen mit viel Kontrast, einen für Menschen mit rot-grün-Schwäche, für Kurzsichtige, was auch immer... Wenn JS aktiviert ist, kann der Benutzer ohne ein Neuladen der Seite ausprobieren, welcher Style für ihn am besten geeignet ist oder ihm am besten gefällt. Alle anderen müssen halt den Style wählen und auf die Antwort vom Server warten.

                    Beste Grüße.

                    1. problematische Seite

                      Hallo,

                      Aber was ist ein sinnvoller Anwendungsfall? Warum sollte man das tun wollen?

                      Bspw. wg. progressive enhancement und Barrierefreiheit? Ich biete auf meiner Seite mehrere verschiedene Styles an: Z.B. einen mit viel Kontrast, einen für Menschen mit rot-grün-Schwäche, für Kurzsichtige, was auch immer...

                      das ist gut, aber ...

                      Wenn JS aktiviert ist, kann der Benutzer ohne ein Neuladen der Seite ausprobieren, welcher Style für ihn am besten geeignet ist oder ihm am besten gefällt. Alle anderen müssen halt den Style wählen und auf die Antwort vom Server warten.

                      ... dazu ist die von Orlok beschriebene Schnittstelle aber ein Overkill. Mit Javascript einen großen Teil der CSS-Regeln auszutauschen hieße, dass diese Information im JS stecken muss - und da hat sie aus semantischen Aspekten eigentlich nichts verloren.

                      Stattdessen ist dein Beispiel für mich ein typischer Fall für das Vorhalten verschiedener Styles in einem Stylesheet und das Umschalten z.B. anhand einer Klasse für das body-Element. Noch eleganter wäre sogar das Umschalten zwischen verschiedenen alternativen Stylesheets durch den Browser, aber das kennen vermutlich sehr wenige Nutzer.

                      So long,
                       Martin

                      --
                      Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
                      - Douglas Adams, The Hitchhiker's Guide To The Galaxy
                      1. problematische Seite

                        Hallo,

                        Wenn JS aktiviert ist, kann der Benutzer ohne ein Neuladen der Seite ausprobieren, welcher Style für ihn am besten geeignet ist oder ihm am besten gefällt. Alle anderen müssen halt den Style wählen und auf die Antwort vom Server warten.

                        ... dazu ist die von Orlok beschriebene Schnittstelle aber ein Overkill.

                        Es war ein Beispiel. Ob Overkill oder nicht kommt immer auf den konkreten Anwendungsfall an. Grundsätzlich ist aber doch nichts verwerflich daran, eine der OOP ähnliche Schnittstelle vorzuhalten.

                        Mit Javascript einen großen Teil der CSS-Regeln auszutauschen

                        Ein "großer Teil" (was auch immer das ist) wäre bestimmt eher zweifelhaft, aber davon war nicht wirklich die Rede.

                        hieße, dass diese Information im JS stecken muss - und da hat sie aus semantischen Aspekten eigentlich nichts verloren.

                        Das ist korrekt.

                        Stattdessen ist dein Beispiel für mich ein typischer Fall für das Vorhalten verschiedener Styles in einem Stylesheet und das Umschalten z.B. anhand einer Klasse für das body-Element.

                        Das kann eine Lösung sein, ja. Muss aber nicht und @Gunnar Bittersmann fragte sinngemäß, ob es dafür überhaupt einen sinnvollen Anwendungsfall gibt.

                        Den gibt es (wahrscheinlich). Von @MudGuard bereits angedeutetes Beispiel: Ich habe bereits eine kontrastreiche Version der Seite, die der User auswählen kann. Das ist dem Benutzer aber noch nicht kontrastreich genug (dass ich dann wohl einen Fehler gemacht habe, soll hier nicht interessieren). Daher biete ich ihm zusätzlich an, Vorder- und Hintergrundfarbe selbst auszuwählen. Du möchtest - überspitzt gesagt - nicht ernsthaft 32 Mio zusätzliche Regeln in Dein Stylesheet reinpacken.

                        Noch eleganter wäre sogar das Umschalten zwischen verschiedenen alternativen Stylesheets durch den Browser, aber das kennen vermutlich sehr wenige Nutzer.

                        Natürlich. Aber bis Browser das auch wirklich Zielgruppengerecht und einfach anbieten und Seitenbetreiber es den Browsern auch ermöglichen, wird es noch ewig dauern. Und bis dahin kann man versuchen das Beste daraus zu machen.

                        Und wie gesagt ging es allgemein darum, ob es einen sinnvollen Einsatz geben könnte.

                        Beste Grüße.

                      2. problematische Seite

                        @@Der Martin

                        Noch eleganter wäre sogar das Umschalten zwischen verschiedenen alternativen Stylesheets durch den Browser, aber das kennen vermutlich sehr wenige Nutzer

                        Vor allem kennen das nur sehr wenige Browser. Außer Firefox noch jemand?

                        Elegant? Für eine Seite, ja.

                        Für eine Website besteht dasselbe Problem wie wenn language negotiation nicht das richtige Ergebnis liefert: Die Nutzerin muss auf jeder Folgeseite erneut umschalten.

                        Man sollte „Sonderwünsche“ des Nutzers im Cookie festhalten und den Server bei der Auslieferung von Folgeseiten darauf reagieren lassen, d.h. die Seite mit dem vom Nutzer gewünschten Stylesheet bzw. in der von ihr bevorzugten Sprache darstellen.

                        LLAP 🖖

                        --
                        “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
                        Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                        1. problematische Seite

                          Hallo,

                          Noch eleganter wäre sogar das Umschalten zwischen verschiedenen alternativen Stylesheets durch den Browser, aber das kennen vermutlich sehr wenige Nutzer

                          Vor allem kennen das nur sehr wenige Browser. Außer Firefox noch jemand?

                          ja, Opera. Genutzt habe ich das aber noch nie.

                          Elegant? Für eine Seite, ja.

                          So sehe ich das Konzept alternativer Stylesheets auch eher: Als Möglichkeit, im Einzelfall mal auf ein anderes Design umzuschalten. Nicht als Dauerlösung.

                          Man sollte „Sonderwünsche“ des Nutzers im Cookie festhalten und den Server bei der Auslieferung von Folgeseiten darauf reagieren lassen, d.h. die Seite mit dem vom Nutzer gewünschten Stylesheet bzw. in der von ihr bevorzugten Sprache darstellen.

                          ACK.

                          Ciao,
                           Martin

                          --
                          Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
                          - Douglas Adams, The Hitchhiker's Guide To The Galaxy
                  3. problematische Seite

                    Hallo Gunnar,

                    Schön, man kann CSS mit JavaScript ändern.

                    Aber was ist ein sinnvoller Anwendungsfall? Warum sollte man das tun wollen?

                    im Tabellensortierer sollen die Spaltenüberschriften anklickbar sein. Das kann man beim Anlegen der Tabelle schon vorsehen, es geht aber auch aus dem Script heraus, indem man den Button und das dazugehöhrige CSS per JS erstellt. Siehe im Wiki.

                    Gruß
                    Jürgen

                  4. problematische Seite

                    Schön, man kann CSS mit JavaScript ändern.

                    Aber was ist ein sinnvoller Anwendungsfall? Warum sollte man das tun wollen?

                    Die aufschlussreichere und viel schwierigere Frage ist doch, warum Leute nicht mit CSS arbeiten wollen und was sie ändern würden wenn sie könnten. Es ist zu einfach und wenig zielführend mit erhobenen Zeigefinger auf bad-practices zu verweisen und die Schublade zuzumachen. Niemanden ist geholfen, wenn man die Frustration mit CSS einfach unter den Teppich kehr. Im Gegenteil genau dort muss gegraben werden. Deswegen finde ich CSS Houdini so wichtig, es könnte die Weiterentwicklung von CSS maßgeblich prägen indem man der Basis einen Resonanzkörper gibt. Die bisherigen Möglichkeiten CSS mit JS zu manipulieren reichen dafür nicht aus, man muss darüber hinaus gehen. Es muss die Möglichkeit geschaffen werden mit völlig neuen Ideen für CSS zu experimentieren. Das ist bisher nur in der Theorie möglich, indem man eine Browserengine forkt. Das gehört nicht gerade zum üblichen Skillset eines Webentwicklers oder einer Webentwicklerin. JavaScript schon.

                    1. problematische Seite

                      Hej 1unitedpower,

                      Schön, man kann CSS mit JavaScript ändern.

                      Aber was ist ein sinnvoller Anwendungsfall? Warum sollte man das tun wollen?

                      Die aufschlussreichere und viel schwierigere Frage ist doch, warum Leute nicht mit CSS arbeiten wollen und was sie ändern würden wenn sie könnten.

                      Diese Frage ist keine Frage und jeder kann sie öffentlich beantworten. Bei der Entwicklung von CSS kann man sich ebenso beteiligen, wie bei den anderten Standards.

                      Dass sich nicht jeder mit allen seinen Wünschen gegen alle anderen durchsetzen kann, bedarf wohl keiner Erwähnung?!?

                      Ich sehe hier kein Problem. Im übrigen bin ich persönlich mit der Entwicklung von CSS sehr zufrieden. Die modulare Entwicklung und recht kurzen Update-Zyklen haben die Zeit zwischen einer Idee und der Formulierung eines Wunsches bis zur Implementierung in den meistverbreiteten Browsern dramatisch verkürzt.

                      Okay, Leute fragen ist immer gut. Meistens ist der CSS-Frust aber durch eine gute Schulung zu beheben. Wenn man weiß, wie etwas geht, wird Frust zur Lust!

                      Marc

                      1. problematische Seite

                        Bei der Entwicklung von CSS kann man sich ebenso beteiligen, wie bei den anderten Standards.

                        Man kann aber schlecht den zweiten Schritt vor dem ersten gehen. Die Entstehung eines Features fängt lange vor der Standardisierungsphase an. In dieser frühen Entwicklungsphase braucht man explorative Prototypen, um Ideen zu entwickeln, verschiedene Alternativen durchzuprobieren und ganz allgemein Erfahrung zu sammeln. Browser-Hersteller(innen) machen das tagtäglich, sie kennen sich in ihrer Code-Basis aus und können relativ kostengünstig mit neuen Features experimentieren. Für Nicht-Browser-Hersteller(innen) ist die Hürde um einiges schwieriger zu nehmen. Selbst wenn sie die technischen Herausforderungen meistern können, haben sie es enorm schwer ihr Experiment anschließend anderen Entwickler(inne)n zugänglich zu machen und hinter sich zu vereinen.

                        1. problematische Seite

                          Hej 1unitedpower,

                          Bei der Entwicklung von CSS kann man sich ebenso beteiligen, wie bei den anderten Standards.

                          Für Nicht-Browser-Hersteller(innen) ist die Hürde um einiges schwieriger zu nehmen. Selbst wenn sie die technischen Herausforderungen meistern können, haben sie es enorm schwer ihr Experiment anschließend anderen Entwickler(inne)n zugänglich zu machen und hinter sich zu vereinen.

                          Das ist kein technisches Problem. Browser-Hersteller experimentieren auch nichts in Blaue hinein (jedenmfalls nciht hauptsächlich), sondern aufgrund (angenommener) Nutzerwünsche. Man kann sich also durchaus beteiligen.

                          Aber jemanden hinter sich vereinen, geht halt nur, wenn genügend andere dasselbe Problem haben.

                          Ünbrigens: nicht implementierte Features per JavaScript zu emulieren ist ja vollkommen ok. Zwar nicht schön, aber ok.

                          Oder Polyfills für noch ungenügend unterstützte Standards.

                          Was umgesetzt wird hängt aber wesentlich vom Bedarf derjenigen ab, die sich zu Wort melden. Wenn deinen Bedarf wenige andere teilen oder wenn du dich gar nicht zu Wort meldest, hast du schlechtere Chancen, als ein Bedarf, der von vielen als solcher angenommen und kommuniziert wird.

                          Marc

                          1. problematische Seite

                            Browser-Hersteller experimentieren auch nichts in Blaue hinein (jedenmfalls nciht hauptsächlich), sondern aufgrund (angenommener) Nutzerwünsche. Man kann sich also durchaus beteiligen.

                            Natürlich, und gäbe es ein Userland in CSS könnten sich viel mehr Leute daran beteiligen. Darum geht es doch.

                            Was umgesetzt wird hängt aber wesentlich vom Bedarf derjenigen ab, die sich zu Wort melden. Wenn deinen Bedarf wenige andere teilen oder wenn du dich gar nicht zu Wort meldest, hast du schlechtere Chancen, als ein Bedarf, der von vielen als solcher angenommen und kommuniziert wird.

                            Vielleicht reden wir aneinander vorbei. Mir geht es darum, die Frequenz und die Qualität der Wortmeldungen zu verbessern. Dazu muss man den Engpass in der Kommunikation zwischen Spezifikations-Autor(inn)en, Browser-Hersteller(inne)n und CSS-Nutzer(inne)n aufspüren und beseitigen. CSS Houdini wird von mir und einigen anderen als vielversprechender Kandidat dafür gehandelt. Das ist zumindest mal ein Anfang. Ihr seid aber offensichtlich anderer Ansicht, so deute ich zumindest die Verweise auf den Status Quo und die Seitenhiebe auf die Fachkenntnis der Befürworter dieses Ansatzes. Korrigiere mich, wenn ich mit dieser Einschätzung falsch liege. Wenn nicht, dann erklärt doch bitte mal eure Beweggründe.

                            1. problematische Seite

                              Hallo,

                              Vielleicht reden wir aneinander vorbei.

                              definitiv, ja.

                              Mir geht es darum, die Frequenz und die Qualität der Wortmeldungen zu verbessern. Dazu muss man den Engpass in der Kommunikation zwischen Spezifikations-Autor(inn)en, Browser-Hersteller(inne)n und CSS-Nutzer(inne)n aufspüren und beseitigen. CSS Houdini wird von mir und einigen anderen als vielversprechender Kandidat dafür gehandelt.

                              In deinem früheren Post las sich das so, als unterstellst du, dass viele Fachleute CSS nicht einsetzen wollen. Als Beispiel erwähnst du CSS Houdini. Btw, hättest du mal besser eine Ebene höher verlinkt, da steht wenigstens ansatzweise beschrieben, was die Jungs überhaupt wollen. Ich hatte zumindest noch nie von denen gehört, geschweige denn ihren Zielen.

                              Und daraus lese ich, dass die sehr wohl an CSS interessiert sind, aber die Möglichkeiten davon noch deutlich ausweiten wollen. Das ist der Punkt, wo ich dann mit Schnappatmung an der Piste stehenbleibe und atemlos frage: Wozu das?
                              Für mich ist CSS bereits so leistungsfähig, dass ich aus heutiger Sicht keinen Bedarf für solche Weiterentwicklungen sehe, wie Houdini sie umreißt. Das wirkt für mich ein bisschen wie Daniel Düsentrieb, der sich fragt: Was könnte ich denn heute erfinden?

                              Das ist zumindest mal ein Anfang. Ihr seid aber offensichtlich anderer Ansicht, so deute ich zumindest die Verweise auf den Status Quo

                              Genau. Die Entwicklung in der Technik, vor allem aber in einigen Bereichen der IT, geht mittlerweile so rasend schnell, dass man schon instinktiv anfängt, sich gegen wieder neue Ideen zu wehren - geht mir jedenfalls so.

                              und die Seitenhiebe auf die Fachkenntnis der Befürworter dieses Ansatzes.

                              Wo siehst du welche? Seitenhiebe, meine ich?

                              So long,
                               Martin

                              --
                              Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
                              - Douglas Adams, The Hitchhiker's Guide To The Galaxy
                              1. problematische Seite

                                @@Der Martin

                                CSS Houdini […] was die Jungs überhaupt wollen. Ich hatte zumindest noch nie von denen gehört, geschweige denn ihren Zielen.

                                Damit alle im Bilde sind, worüber wir hier reden: Houdini: Maybe The Most Exciting Development In CSS You’ve Never Heard Of (Philip Walton, Smashing Magazine)

                                (Kam gerade nochmal von Sara Soueidan übern Ticker. Und das auch: Is Houdini ready yet‽)

                                LLAP 🖖

                                --
                                “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
                                Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                            2. problematische Seite

                              Hej 1unitedpower,

                              Browser-Hersteller experimentieren auch nichts in Blaue hinein (jedenmfalls nciht hauptsächlich), sondern aufgrund (angenommener) Nutzerwünsche. Man kann sich also durchaus beteiligen.

                              Natürlich, und gäbe es ein Userland in CSS könnten sich viel mehr Leute daran beteiligen. Darum geht es doch.

                              ??? In die Mailingliste kann sich jeder eintragen.

                              "Jeder kann an der Diskussion teilhaben - und zwar dank der archivierten Mailingliste www-style@w3.org. Sie können sich selbst anmelden."

                              Zitat von https://www.w3.org/Style/CSS/current-work#contribute Es wird also sogar in deutscher Sprache darauf hingewiesen, wie man mitmachen kann...

                              Was umgesetzt wird hängt aber wesentlich vom Bedarf derjenigen ab, die sich zu Wort melden. Wenn deinen Bedarf wenige andere teilen oder wenn du dich gar nicht zu Wort meldest, hast du schlechtere Chancen, als ein Bedarf, der von vielen als solcher angenommen und kommuniziert wird.

                              Vielleicht reden wir aneinander vorbei. Mir geht es darum, die Frequenz und die Qualität der Wortmeldungen zu verbessern.

                              Frequenz ist ja erst mal nur Quantität - die ermöglicht die Mailingliste.

                              Qualität (also ob ein vorgeschlagenes Feature eine Hilfe wäre) liegt ja oft im Auge des Betrachters. Jeder hätte gerne etwas, aber was genau? Darin unterscheiden sich die Anwender.

                              Insofern ist in diesem Falle Qualität wohl nicht der richtige Begriff, weil er Objektivität vorgaukelt, wo es doch eher ein subjektives Empfinden ist, ob ich ein bestimmtes Feature als wichtig erachte.

                              Dazu muss man den Engpass in der Kommunikation zwischen Spezifikations-Autor(inn)en, Browser-Hersteller(inne)n und CSS-Nutzer(inne)n aufspüren und beseitigen.

                              Auch hier: wirklich jeder kann sich in die Mailingliste eintragen. Ich sehe da keinen "Engpass"...

                              CSS Houdini wird von mir und einigen anderen als vielversprechender Kandidat dafür gehandelt. Das ist zumindest mal ein Anfang. Ihr seid aber offensichtlich anderer Ansicht, so deute ich zumindest die Verweise auf den Status Quo und die Seitenhiebe auf die Fachkenntnis der Befürworter dieses Ansatzes.

                              Ich denke nicht, dass man in die vorhandenen rendering Engines eingreifen sollte. Die Browserhersteller sollen für eine standardkonforme Implementierung sorgen.

                              Sicher: der Standardisierungsprozess braucht Zeit. Aber die Ergebnsise sind verlässlich und nach kurzer Zeit bekannt.

                              Vielleicht fehlen mir auch einfach die Beispiele für das, was du vermisst. Habe einen Artikel vom Smashing Magazine über Houdini im Kopf, da geht es z. B. darum einen Hintergrund-Kreis zu zeichnen.

                              Gibt jetzt schon mehrere Methoden dafür (Pseudoelement, absolut positioniert mit niedrigem Z-index oder radial gradient - beide bedeuten weniger Aufwand als die dort gezeigte Lösung. Ist nur ein Beispiel, ich weiß.

                              Aber um es mal konkret zu machen: was vermisst du denn?

                              Korrigiere mich, wenn ich mit dieser Einschätzung falsch liege. Wenn nicht, dann erklärt doch bitte mal eure Beweggründe.

                              Ich habe schlicht keinen Bedarf. Ich musste Layout-Vorschläge extrem selten abändern lassen, weil ich es nciht umsetzen konnte. Manchmal gibt es Fälle, bei denen mehrere Anforderungen miteinander kombiniert werden müssen, so dass sich nicht alle Konflikte auflösen lassen. Das liegt dann aber in der Regel nicht an technischen Beschränkungen, sondern daran, dass sich die Wünsche widersprechen. Insbesondere flexbox hat ganz viele Wünsche auf meiner Liste erfüllt.

                              Marc

                              1. problematische Seite

                                @@marctrix

                                Aber um es mal konkret zu machen: was vermisst du denn?

                                Conical gradients.

                                LLAP 🖖

                                --
                                “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
                                Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                                1. problematische Seite

                                  Hej Gunnar,

                                  Aber um es mal konkret zu machen: was vermisst du denn?

                                  Conical gradients.

                                  Ja, aber ich vermisse die nicht. Das ist genau das, was ich meinte, als ich sagte: Browserhersteller experimentieren auch nciht ins Blaue hinein, sondern nur wenn sie das Gefühl haben, eine ausreichende Menge an Entwicklern hat ein Interesse daran. Lea sagt es ja selber: "he reason conical gradients are still unimplemented, is because very few developers know they exist, so browsers see no demand."

                                  So sehr ich Lea schätze: jeder Entwickler darf sich etwas wünschen, aber umgesetzt wird dann (erst mnal) was viele wünschen...

                                  Marc

                                  1. problematische Seite

                                    @@marctrix

                                    Das ist genau das, was ich meinte, als ich sagte: Browserhersteller experimentieren auch nciht ins Blaue hinein, sondern nur wenn sie das Gefühl haben, eine ausreichende Menge an Entwicklern hat ein Interesse daran.

                                    Ja, es ist leider so, dass Browserhersteller nur das implementieren, wozu sie Lust haben; nicht das, was aus Sicht von Entwicklern oder gar Nutzern wünschenswert wäre. Vier Parteien (Blink (Google, Opera), WebKit (Apple), Mozilla und Microsoft) bestimmen, was Standard wird. Ich finde es schon bedenklich, dass jetzt das standardisiert wird, was schon implementiert ist, anstatt dass implementiert wird, was sich vorher als sinnvoller Standard überlegt wird.

                                    LLAP 🖖

                                    --
                                    “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
                                    Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                              2. problematische Seite

                                ??? In die Mailingliste kann sich jeder eintragen.

                                Aber es tun zu wenige, weil man Ideen halt erstmal entwickeln will, bevor man damit an das Standard-Commitee herantritt. Wir drehen uns im Kreis.

                                Qualität (also ob ein vorgeschlagenes Feature eine Hilfe wäre) liegt ja oft im Auge des Betrachters. Jeder hätte gerne etwas, aber was genau? Darin unterscheiden sich die Anwender.

                                Insofern ist in diesem Falle Qualität wohl nicht der richtige Begriff, weil er Objektivität vorgaukelt, wo es doch eher ein subjektives Empfinden ist, ob ich ein bestimmtes Feature als wichtig erachte.

                                Natürlich steigert sich die Qualitiät, wenn man selber eine Implementierung mitliefern kann, wenn man vorher Gelegenheit hatte Alternativen auszuprobieren, Feedback von der Community einzuholen und sie zu beteiligen.

                                Dazu muss man den Engpass in der Kommunikation zwischen Spezifikations-Autor(inn)en, Browser-Hersteller(inne)n und CSS-Nutzer(inne)n aufspüren und beseitigen.

                                Auch hier: wirklich jeder kann sich in die Mailingliste eintragen. Ich sehe da keinen "Engpass"...

                                Jeder kann, aber viele tun es nicht, oft aus guten Gründen. Es ist zu kurzsichtig die Beteiligung solcher Leute mit einem pedantischen Hinweis auf Mailing-Listen zu ignorieren. Beteiligung kann viele Formen annehmen und gerade jene Leute, die den Wunsch nach besseren Teilnahmebedingungen äußern, haben mit hoher Wahrscheinlichkeit auch Wertvolles beizutragen. Es ist auch zu bequem, die Ausarbeitung der Details und die Implementierungen den Browser-Entwickler(innen) und Spec-Autor(inn)en zu überlassen. Genau da ist nämlich der Engpass.

                                CSS Houdini wird von mir und einigen anderen als vielversprechender Kandidat dafür gehandelt. Das ist zumindest mal ein Anfang. Ihr seid aber offensichtlich anderer Ansicht, so deute ich zumindest die Verweise auf den Status Quo und die Seitenhiebe auf die Fachkenntnis der Befürworter dieses Ansatzes.

                                Ich denke nicht, dass man in die vorhandenen rendering Engines eingreifen sollte. Die Browserhersteller sollen für eine standardkonforme Implementierung sorgen.

                                Die CSS Houdini Task Force gehört selber dem Standard-Committee an. Und das höhere Ziel, das man verfolgt, ist natürlich Community-Errungenschaften verstärkt zurück in die Standards fließen zu lassen.

                                Aber um es mal konkret zu machen: was vermisst du denn?

                                Community-Beteiligung ;) Aber die Antwort wird dich nicht zufriedenstellen. Mir geht es hier nicht um meine eigenen Wunschvorstellungen, sondern um die zahllosen unausgesprochenen Ideen der Community, die in vertaubten Schreibtischschubladen beerdigt werden, weil es keinen Nährboden für sie gibt. Das ist verspieltes Innovationspotenzial.

                                1. problematische Seite

                                  Hej 1unitedpower,

                                  Aber um es mal konkret zu machen: was vermisst du denn?

                                  Community-Beteiligung ;) Aber die Antwort wird dich nicht zufriedenstellen. Mir geht es hier nicht um meine eigenen Wunschvorstellungen, sondern um die zahllosen unausgesprochenen Ideen der Community, die in vertaubten Schreibtischschubladen beerdigt werden, weil es keinen Nährboden für sie gibt. Das ist verspieltes Innovationspotenzial.

                                  Klingt plausibel, aber irgendwie gelingt es mir nicht, dich zu verstehen. Die Community-Beteiligung ist dir zu gering, obwohl sich jeder beteiligen darf. Mit Houdini gibt es weitere Ansätze, wenn ich dich recht verstehe, um noch mehr Leute zur Teilnahme anzuregen. Und was war jetzt noch gleich deine Kritik? Du unterstützt doch Houdini, es gibt Houdini und wo ist der Haken?

                                  Marc

                                  1. problematische Seite

                                    Klingt plausibel, aber irgendwie gelingt es mir nicht, dich zu verstehen. Die Community-Beteiligung ist dir zu gering, obwohl sich jeder beteiligen darf. Mit Houdini gibt es weitere Ansätze, wenn ich dich recht verstehe, um noch mehr Leute zur Teilnahme anzuregen. Und was war jetzt noch gleich deine Kritik? Du unterstützt doch Houdini, es gibt Houdini und wo ist der Haken?

                                    Ich habe hier einigen Missmut über die Weiterentwicklung von CSS wahrgenommen. Deshalb habe ich versucht eure Sorgen zu ergründen und dann hoffentlich zu zerstreuen, indem ich den Überlegungen, die zu CSS Hoidini geführt haben, meine Stimme verliehen habe.

                              3. problematische Seite

                                @@marctrix

                                Aber um es mal konkret zu machen: was vermisst du denn?

                                Transition/Animation von custom properties:

                                foo
                                {
                                  --value: 1;
                                  property: var(--value);
                                  transition: --value 1s;
                                }
                                
                                foo:hover, foo:focus
                                {
                                  --value: 2;
                                }
                                

                                Geht noch nicht, obwohl die Werte numerisch sind.

                                LLAP 🖖

                                --
                                “There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
                                Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                                1. problematische Seite

                                  Hej Gunnar,

                                  Aber um es mal konkret zu machen: was vermisst du denn?

                                  Transition/Animation von custom properties:

                                  That would be nice to have!

                                  Marc

                                2. problematische Seite

                                  Transition/Animation von custom properties:

                                  Wo du schon mit dem Thema anfängst, auch Transitions zwischen symbolischen Werten:

                                  .foo {
                                    height: 0;
                                    transition: height 1s;
                                  }
                                  
                                  .bar {
                                    height: auto;
                                  }
                                  
                                  1. problematische Seite

                                    Hej 1unitedpower,

                                    Transition/Animation von custom properties:

                                    Wo du schon mit dem Thema anfängst, auch Transitions zwischen symbolischen Werten:

                                    .foo {
                                      height: 0;
                                      transition: height 1s;
                                    }
                                    
                                    .bar {
                                      height: auto;
                                    }
                                    

                                    Das vermisse ich tatsächlich sehr!

                                    Warum soll eine Box, die fertig gerendert ist (dessen Höhe der Browser also kennt) nicht zu einer vorgegebenen Größe animiert wechseln können? - Klingt nicht gerade nach rocket science...

                                    Zum Beispiel bei mouse over - oder hat jemand einen Workaround?

                                    Marc

                                    1. problematische Seite

                                      @@marctrix

                                      Zum Beispiel bei mouse over - oder hat jemand einen Workaround?

                                      Klar doch.

                                      height sollte man sowieso nicht animieren.

                                      LLAP 🖖

                                      --
                                      “The best way to help people learn: answer their coding question an hour later, they’ll have likely figured it out by then.” —Todd Motto
                                      Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                                      1. problematische Seite

                                        Hej Gunnar,

                                        @@marctrix

                                        Zum Beispiel bei mouse over - oder hat jemand einen Workaround?

                                        Klar doch.

                                        Das ist gepfuscht ;-)

                                        Bei manchen Anwendungen aber möglich.

                                        height sollte man sowieso nicht animieren.

                                        Zum Zoomen von Bildern auf einem Desktop-Rechner sollte die Power aber reichen... - es gibt schon hübsche Anwendungsfälle, bei denen es Sinn macht.

                                        Auf dem Handy stelle ich die eh schon meistens in fast vollständiger Bildschirmbreite dar.

                                        Marc

                                        1. problematische Seite

                                          @@marctrix

                                          Klar doch.

                                          Das ist gepfuscht ;-)

                                          Du hast auch den Vorläufer gesehen? Der pfuscht aber beim Rausfahren – er bummelt.

                                          LLAP 🖖

                                          --
                                          “The best way to help people learn: answer their coding question an hour later, they’ll have likely figured it out by then.” —Todd Motto
                                          Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                                          1. problematische Seite

                                            Hej Gunnar,

                                            @@marctrix

                                            Klar doch.

                                            Das ist gepfuscht ;-)

                                            Du hast auch den Vorläufer gesehen? Der pfuscht aber beim Rausfahren – er bummelt.

                                            Nein, nicht gesehen - und wird heute wohl auch nichts mehr, weil ich nicht glaube, dass ich mich noch mal an den Desktop begebe... ;-)

                                            Marc

                                            Gesendet von meinem Schlaufernsprechdings

                                      2. problematische Seite

                                        height sollte man sowieso nicht animieren.

                                        Ich nehme an, die Aussage gründet sich auf dem Wissen, dass CSS-Transforms die Layout-Boxen nicht verändern und deshalb keine teuren Reflows nötig werden, wenn man sie animiert. Umgekehrt heißt das aber auch, dass man CSS-Transforms nicht benutzen kann, um Layout-Übergänge zu animieren. Und gerade dabei erscheinen mir weiche Übergange sinnvoll[1]. Auch für CSS gelten im Wesentlichen die selben Performance-Regeln wie in anderen Bereichen: Optimieren auf Verdacht ist selten effektiv, stattdessen kann man nur messen, nachjustieren und erneut messen und die Prozedur wiederholen bis man mit der Performance zufrieden ist.


                                        1. Sagt auch der Material-Design-Guide von Google. ↩︎

                                        1. problematische Seite

                                          @@1unitedpower

                                          Auch für CSS gelten im Wesentlichen die selben Performance-Regeln wie in anderen Bereichen: Optimieren auf Verdacht ist selten effektiv, stattdessen kann man nur messen, nachjustieren und erneut messen und die Prozedur wiederholen bis man mit der Performance zufrieden ist.

                                          Das Problem bei dem Ansatz: Man gibt sich mit etwas zufrieden, weil man auf dem eingeschlagenen Weg nicht mehr weiterkommt, ohne zu wissen, dass es auf anderen Weg mit wenig Aufwand deutlich besser geht.

                                          LLAP 🖖

                                          --
                                          “The best way to help people learn: answer their coding question an hour later, they’ll have likely figured it out by then.” —Todd Motto
                                          Selfcode: sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|
                                          1. problematische Seite

                                            Das Problem bei dem Ansatz: Man gibt sich mit etwas zufrieden, weil man auf dem eingeschlagenen Weg nicht mehr weiterkommt, ohne zu wissen, dass es auf anderen Weg mit wenig Aufwand deutlich besser geht.

                                            Die Reaktion auf eine Messung kann natürlich auch sein, einen anderen Weg einzuschlagen, da sehe ich kein Problem. Zu Beginn kann man sich nur auf Theorie, Glauben, Vermutungen und Erfahrungswerte für einen Weg entscheiden, das sollte dann der Weg des geringsten Widerstandes sein. Danach beginnt die eigentliche Performance-Optimierung, indem man sukzessive Evidenz über die Performance der Lösung und ihrer Alternativen einholt und dort nachbessert, wo Bedarf besteht. Die zweite Phase hat natürlich einen Trainings-Effekt auf die initiale Auswahlphase. Überspringt man diese Phase, ignoriert man potenziell bessere Lösungen und profitiert natürlich auch nicht vom Trainings-Effekt. Das ist das Problem mit dem Glauben.

                      2. problematische Seite

                        Hallo,

                        Die aufschlussreichere und viel schwierigere Frage ist doch, warum Leute nicht mit CSS arbeiten wollen und was sie ändern würden wenn sie könnten.

                        Diese Frage ist keine Frage

                        nein, sie ist zunächst mal eine Behauptung, nämlich dass Leute nicht mit CSS arbeiten wollen. Und ist das so? Okay, vielleicht schon. Und der häufigste Grund ist vermutlich mangelnde Kenntnis.

                        Wenn man weiß, wie etwas geht, wird Frust zur Lust!

                        Nur einfach wissen, wie's geht, reicht nicht immer aus, um Lust zu empfinden. ;-)

                        So long,
                         Martin

                        --
                        Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
                        - Douglas Adams, The Hitchhiker's Guide To The Galaxy
                        1. problematische Seite

                          nein, sie ist zunächst mal eine Behauptung, nämlich dass Leute nicht mit CSS arbeiten wollen. Und ist das so? Okay, vielleicht schon. Und der häufigste Grund ist vermutlich mangelnde Kenntnis.

                          Ist dir wirklich keine fundierte CSS-Kritik bekannt? Das kann ich fast nicht glauben, aber wenn dem so ist, mach ich mir heute Abend gerne die Mühe und suche ein paar lesenswerte Artikel zum Thema heraus. Wenn du zwischenzeitlich selber schon Recherchen anstellen möchtest, dann kann ich dir die Kritik der SASS- und LESS-Communities und natürlich die der CSS Houdini Task Force sehr empfehlen.

                          1. problematische Seite

                            Hallo,

                            nein, sie ist zunächst mal eine Behauptung, nämlich dass Leute nicht mit CSS arbeiten wollen. Und ist das so? Okay, vielleicht schon. Und der häufigste Grund ist vermutlich mangelnde Kenntnis.

                            Ist dir wirklich keine professionelle CSS-Kritik bekannt?

                            nein, aber ich bin auch noch nicht auf die Idee gekommen, nach so etwas zu suchen. Und zwar weil ich selbst an CSS nicht mehr und nicht weniger auszusetzen habe, als an jeder anderen Technik auch.

                            Das kann ich fast nicht glauben, aber wenn dem so ist, mach ich mir heute Abend gerne die Mühe und suche ein paar lesenswerte Artikel zum Thema heraus.

                            Lass es, es wäre Zeitverschwendung, vielen Dank.

                            Wenn du zwischenzeitlich selber schon Recherchen anstellen möchtest, dann kann ich dir die Kritik der SASS- und LESS-Communities und natürlich die der CSS Houdini sehr empfehlen.

                            Interessiert mich ehrlich gesagt gar nicht so sehr, weil ich mich da nicht weiter engagieren oder bis zum Hals reinknien möchte. Für mich ist CSS ein selbstverständlicher Begleiter von HTML, ich komme so einigermaßen damit zurecht (soweit nötig) und würde es auch immer als unverzichtbaren Bestandteil der Webentwicklung kommunizieren.

                            Und das, was ich bisher an Ablehnung erlebt oder gelesen habe, war tatsächlich vor allem von Laien, denen das zu komplex ist, denen man erstmal langsam das Konzept näherbringen muss.

                            So long,
                             Martin

                            --
                            Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
                            - Douglas Adams, The Hitchhiker's Guide To The Galaxy
                          2. problematische Seite

                            Hej 1unitedpower,

                            nein, sie ist zunächst mal eine Behauptung, nämlich dass Leute nicht mit CSS arbeiten wollen. Und ist das so? Okay, vielleicht schon. Und der häufigste Grund ist vermutlich mangelnde Kenntnis.

                            Ist dir wirklich keine fundierte CSS-Kritik bekannt?

                            Die Frage ist wohl eher, ob er diese Kritik teilt. Wie gesagt bin ich mit CSs sehr zufrieden. - Klar will ich mehr, aber die Entwicklung geht voran und es wurde viel gemacht, diese zu beschleunigen.

                            Bis jetzt gelingt es mir aber fast immer Layout-Vorgaben allein mit reinem CSS umzusetzen. Es gibt freilich Grenzen. Aber die gibt es immer - dann muss man auch mal zu einem eigentlich nicht schönen Workaround greifen. Es wird aber immer seltener...

                            Marc

                        2. problematische Seite

                          Hej Der Martin,

                          Wenn man weiß, wie etwas geht, wird Frust zur Lust!

                          Nur einfach wissen, wie's geht, reicht nicht immer aus, um Lust zu empfinden. ;-)

                          Stimmt, erst Übung macht den Meister! ;-)

                          Marc

                          1. problematische Seite

                            Hallo Marc,

                            Wenn man weiß, wie etwas geht, wird Frust zur Lust!

                            Nur einfach wissen, wie's geht, reicht nicht immer aus, um Lust zu empfinden. ;-)

                            Stimmt, erst Übung macht den Meister! ;-)

                            genau, du dachtest bestimmt an Schach. *fg*

                            So long,
                             Martin

                            --
                            Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
                            - Douglas Adams, The Hitchhiker's Guide To The Galaxy
  2. problematische Seite

    Hallo

    Das von dir gezeigte Beispiel existiert auf der verlinkten Seite überhaupt nicht.

    im Beispiel in http://wiki.selfhtml.org/wiki/AddEventListener

    <html>
      <head>
        <title></title>
        <meta content="">
        <style></style>
      </head>
      <body>
      
        <span id="h" hidden>versteck</span><br>
        
        <a href="javascript:void(document.getElementById('h').hidden=false);">zeigen direkt</a>
        <br>
        <a href="javascript:document.getElementById('h').hidden=false;">zeigen direkt ohne "voiding"</a>
        <br>
        <a href="javascript:show();">zeigen mit function </a>
        <br>
        <a href="javascript:void(document.getElementById('h').hidden=true);">verstecken</a>
        
        <script> function show(){ document.getElementById('h').hidden=false;}
       </script>
      </body>
    </html>
    

    Das ist irgendwas anderes, aber kein Beispiel für „addEventListener“. Du fügst überhaupt keinen Eventlistener für irgendein HTML-Element ein.

    Tschö, Auge

    --
    Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
    Wolfgang Schneidewind *prust*
    1. problematische Seite

      Tach!

      Das ist irgendwas anderes, aber kein Beispiel für „addEventListener“. Du fügst überhaupt keinen Eventlistener für irgendein HTML-Element ein.

      Stattdessen missbraucht er da Links, die gar nicht linken sollen und einer davon torpediert dann auch das Vorhaben, indem er eine neue Ressource aufruft, statt auf der Seite zu bleiben.

      dedlfix.