Ankündigung

Einklappen
Keine Ankündigung bisher.

Framework Ja oder Nein?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #46
    Wie barrierefrei ist das denn eigentlich? (Ernsthafte Frage.) Gibt es da irgendeine clevere Lösung oder ist das mehr oder weniger „wenn du kein JS hast, gibt es halt nichts zu sehen“?

    Kommentar


    • #47
      danke fürs nachhaken.

      lottikarotti, wieso denn nicht mal lynx/wget/curl. nicht nur die grosse suchmaschine will auch markup sehen.

      bei barrierefrei übrigens scheinen mir nicht abgeschosssene frameworks einfacher in der integration:
      https://github.com/gkapkowski/braille

      Kommentar


      • #48
        Hallöchen,

        Zitat von moma Beitrag anzeigen
        lynx
        Ich hatte mal eine Phase (als ich angefangen habe Linux zu nutzen; lange ist's her) in der wollte ich einfach alles über die Konsole machen. Scripten, Musik hören, Surfen, Prozess-Management und sogar ICQ. Das war sicherlich sehr lehrreich, aber mit lynx zu surfen habe ich nach ca. 10 Minuten direkt aufgegeben. Auch kann ich mir nicht vorstellen, dass dieser Browser einen nennenswerten Marktanteil hat.

        Zitat von moma Beitrag anzeigen
        wget/curl
        Da stellt sich mir die Frage, wieso sich jemand Daten von meiner Website/ Applikation mit diesen Tools beschaffen möchte und ob ich das überhaupt will. Bei sinnvollen Anwendungsfällen gibt's doch lieber Zugriff auf einen RESTful-Service, der im Idealfall sowieso schon von der Anwendung genutzt wird.

        Außerdem gibt es da Lösungen wie Prerender.

        Zitat von mermshaus Beitrag anzeigen
        Wie barrierefrei ist das denn eigentlich? (Ernsthafte Frage.) Gibt es da irgendeine clevere Lösung oder ist das mehr oder weniger „wenn du kein JS hast, gibt es halt nichts zu sehen“?
        Zitat von moma Beitrag anzeigen
        bei barrierefrei übrigens scheinen mir nicht abgeschosssene frameworks einfacher in der integration:
        https://github.com/gkapkowski/braille
        Ich habe mich noch nicht allzu intensiv mit diesem Thema auseinandergesetzt, wenn ich ehrlich bin. Auf die Schnelle habe ich das hier finden können: AngularJS Accessibility.

        Viele Grüße,
        lotti
        [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

        Kommentar


        • #49
          Zitat von lottikarotti Beitrag anzeigen
          Da stellt sich mir die Frage, wieso sich jemand Daten von meiner Website/ Applikation mit diesen Tools beschaffen möchte und ob ich das überhaupt will. Bei sinnvollen Anwendungsfällen gibt's doch lieber Zugriff auf einen RESTful-Service, der im Idealfall sowieso schon von der Anwendung genutzt wird.

          Außerdem gibt es da Lösungen wie Prerender.

          Ich habe mich noch nicht allzu intensiv mit diesem Thema auseinandergesetzt, wenn ich ehrlich bin. Auf die Schnelle habe ich das hier finden können: AngularJS Accessibility.

          Viele Grüße,
          lotti
          Schön, dass sich dir eine frage stellt, mit verlaub.
          dass es einen haufen nicht js nutzer gibt, weisst du schon; gut, gehen dich nichts an, versteh ich.

          Prerender ist die lösung, ich nutze request policy, bei mir ist die seite weiss.
          was bitte soll Prerender machen?

          bei deinem angular link hab ich nichts für sehbehinderte endecken können auf die schnelle.

          //OT:
          dient deine antwort nur um consolebenutzer zu diskeditieren?
          ich benutze übrignes gui.

          Kommentar


          • #50
            http://www.punkchip.com/why-support-...ript-disabled/
            [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

            Kommentar


            • #51
              Ich sehe das teilweise etwas differenzierter. Nicht jedes Angebot muss ohne Javascript erreichbar sein. Es gibt Applikationen wie Google Docs (oder ähnliches), die ohne JS nicht laufen würden. Und deshalb denke ich, ist das etwas, dass Angebotsbezogen beurteilt werden muss.
              [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

              Kommentar


              • #52
                Sorry, gerade nicht die Zeit und Lust, das zu paraphrasieren, aber der Thread ist vielleicht ganz interessant: http://www.php.de/off-topic-diskussi...ktiverbar.html

                Dokumentenzentriertes vs. applikationszentriertes Web.

                Mein Problem damit ist vor allem, dass wohl ohne Sinn und Verstand haufenweise Infrastruktur zersägt wird, weil einfach mal überall JavaScript reingepackt wird. So was hat Frontend-Leute im Schnitt aber noch nie interessiert. Irgendwer fegt die Scherben ja immer auf.

                PS: Ich finde da immer ganz faszinierend, dass das Format HTML bei JS-Seiten im Grunde abgeschafft ist. Das wird eigentlich nicht mehr benötigt.


                Edit: Noch kurz zu „barrierefrei“. Ich folge da grob dieser Definition:

                Barrierefreiheit schließt sowohl Menschen mit und ohne Behinderungen als auch Benutzer mit technischen (Textbrowser oder PDA) oder altersbedingten Einschränkungen (Sehschwächen) sowie Webcrawler ein, mit denen Suchmaschinen den Inhalt einer Seite erfassen. Da dies aufgrund der unzähligen weichen, individuell geprägten Barrieren nicht vollständig erreicht werden kann, spricht man auch von barrierearm oder zugänglich.
                - https://de.wikipedia.org/wiki/Barrierefreies_Internet

                Kurzum: Alle. Aussagen wie „Screenreader können JS“ oder „Lynx nutzt niemand“ betrachten immer nur einzelne Aspekte. Es gibt zig Gründe, Webseiten auf HTML-Basis verarbeiten zu wollen. JS zieht da eine riesige Barriere ein, weil du dann nicht mehr ein Tool brauchst, das HTTP spricht und HTML parsen kann, sondern einen JavaScript-Interpreter. Und da fangen die Probleme erst an.

                Ich sehe da ein großes Problem für das offene Web. (Siehe dazu etwa auch die letzten Posts im anderen Thread. „Wir killen den URL.“)

                Kommentar


                • #53
                  Hallöchen,

                  Zitat von moma Beitrag anzeigen
                  Schön, dass sich dir eine frage stellt, mit verlaub. dass es einen haufen nicht js nutzer gibt, weisst du schon; gut, gehen dich nichts an, versteh ich.
                  Das ist etwas kurz gedacht, sorry. Es mag für die gewöhnliche Web-Site oder einen Blog nicht üblich sein voll auf JavaScript zu setzen, weil man mit SEO und Accessibility sicherlich zwei Faktoren hat, die man nicht unterschätzen sollte. Bei geschlossenen Projekten (mein persönliches Steckenpferd) sieht die Sache allerdings ein wenig anders aus. Bei komplexen Back-Office Anwendungen schreiben wir den Kunden bspw. grundsätzlich vor, JavaScript aktivieren zu müssen um die Anwendung verwenden zu können. Das spart schlichtweg Zeit bei der Entwicklung, weil man sich nicht mit Fallbacks herumschlagen muss und den Fokus auf ein interaktives Design richten kann.

                  Sowohl das Bewusstsein als auch das Verständnis dafür ist bei der Kundschaft längst da und wenn man es richtig macht, bekommt man selbst konservative Entscheider dazu überredet den aktuellen Chrome mit aktiviertem JavaScript zu nutzen. So zumindest meine Erfahrung.

                  Dennoch - versteht mich nicht falsch - bin ich ein großer Freund von Progressive Enhancement, allerdings nur dort wo es auch Sinn macht und man die Zeit/ das Geld dafür hat - also bspw. bei einem Blog, einem Online-Shop, whatever.

                  Zitat von moma Beitrag anzeigen
                  Prerender ist die lösung, ich nutze request policy, bei mir ist die seite weiss.
                  was bitte soll Prerender machen?
                  Die Seite scheint gerade offline zu sein. Hier ein Auszug aus dem GitHub-Repo:
                  Zitat von https://github.com/prerender/prerender
                  Behind the scenes, Prerender is a node server from prerender.io that uses phantomjs to create static HTML out of a javascript page. We host this as a service at prerender.io but we also open sourced it because we believe basic SEO is a right, not a privilege!
                  Zitat von moma Beitrag anzeigen
                  bei deinem angular link hab ich nichts für sehbehinderte endecken können auf die schnelle.
                  Damit kratzt man auch nur an der Oberfläche. Wer sich schon mal mit Barrierefreiheit beschäftigt hat, der weiß, dass das nicht trivial ist und da einiges mehr dazugehört. Ich kann euch jetzt aber keine Lösung dafür liefern, da ich diese noch nicht gebraucht habe.

                  Zitat von moma Beitrag anzeigen
                  dient deine antwort nur um consolebenutzer zu diskeditieren?
                  Nein. Ich liebe die Konsole und nutze sie sogar sehr intensiv. Auf meinem Windows-System habe ich sogar Cygwin laufen, weil ich nicht ohne kann. Allerdings gibt es Anwendungsfälle, da ist sie schlichtweg ungeeignet, weshalb u.a. lynx für Web-Entwickler i.d.R. keine Rolle spielt.

                  Zitat von moma Beitrag anzeigen
                  ich benutze übrignes gui.
                  Du Tier! ;D

                  Zitat von ChristianK Beitrag anzeigen
                  Ich sehe das teilweise etwas differenzierter. Nicht jedes Angebot muss ohne Javascript erreichbar sein. Es gibt Applikationen wie Google Docs (oder ähnliches), die ohne JS nicht laufen würden. Und deshalb denke ich, ist das etwas, dass Angebotsbezogen beurteilt werden muss.
                  Kann ich mich so anschließen. Wir haben Projekte laufen, da hört's nach dem Login bspw. auf mit dem Non-JavaScript Support, weil das den Aufwand einfach in die Höhe treiben würde.

                  Viele Grüße,
                  lotti
                  [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

                  Kommentar


                  • #54
                    Wer sich mit Barrierefreiheit und Internet beschäftigt hat wird feststellen das Javascript heutzutage damit weniger zu tun hat, da Screenreader allesamt Javascript können.

                    Das Javascript oder nicht Thema im Bezug auf Barrierefreiheit halte ich für ein missverstandenes Diskussionsnebenziel. Derweil Javascript primär nur DOM verhaltenstreu verändern soll. Screenreader den aktuellen DOM als Resource nutzen.
                    [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                    Kommentar


                    • #55
                      Irgendwelche Backend-Lösungen oder spezialisierte Anwendungen haben in dem Sinne halt nichts mit dem klassischen Web zu tun. Die könnte man auch als Desktop-Anwendung umsetzen. Da ist der Browser nur die UI-/Client-Anwendung der Wahl. Da kann man statt JavaScript meinetwegen auch jede beliebige andere RIA-Technologie nutzen. (Andere Aspekte wie vendor lock-in mal außen vor.)

                      Aber wenn du zum Beispiel schreibst:

                      Zitat von lottikarotti
                      Wofür braucht man heutzutage serverseitig noch Template-Engines? In meinen Projekten gibt es *eine* index.html, den Rest regelt AngularJS clientseitig. DAS ist genial.. *duck-und-weg*
                      Auch wenn es als Scherz gemeint sein sollte. In der Formulierung ist das für mich ziemlich genau das, was zum Beispiel ich kritisiere.[1] „Mach einfach alles mit JS.“ Appifizierte Nachrichtenseiten (also im Grunde ganz ganz klassisch dokumentenbasiert) sind ja zum Beispiel durchaus eine Sache (siehe etwa die Beschreibung im von tr0y verlinkten Artikel).
                      1: Wobei es natürlich auch wenig produktiv ist, diese Entwicklung grundsätzlich als schlecht zu bezeichnen oder abzulehnen.

                      Edit:

                      Zitat von tr0y
                      Das Javascript oder nicht Thema im Bezug auf Barrierefreiheit halte ich für ein missverstandenes Diskussionsnebenziel.
                      Na ja. Dazu habe ich im anderen Thread auch was geschrieben. Der Begriff „Barrierefreiheit“ ist einfach total schlecht gewählt (weil jeder sofort an körperliche Behinderungen denkt, ob das nun dem Begriff gerecht wird oder nicht). OpenWeb oder so wäre mehr sexy, wobei es „open“ auch schon etwas hinter sich hat. Vielleicht so was wie „Engineered Web“. Irgendwas, was nach VW-Lasern klingt, die gleichartige Bauteile noch mal ausmessen und dann dem Wagen zuweisen, bei dem sie optimal passen.

                      Kommentar


                      • #56
                        Joa, das Thema ist riesig: http://www.w3.org/WAI/
                        [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                        Kommentar


                        • #57
                          Dann gibt es noch die Hybriden. Webseiten, die zum großen Teil auf statischen Inhalten fußen und für sehr dynamische Teilbereiche dann Javascript einsetzen. Bei uns gilt das Prinzip, dass deaktivierte Cookies und deaktiviertes Javascript persönliches Pech des Anwenders sind. < 1,5 % weniger Kunden können wir locker verschmerzen, wenn sich im gleichen Moment wesentliche Entwicklungskosten einsparen lassen.

                          Ist im Grunde aber auch nicht bedingt meine Baustelle, da ich auch im allgemeinen mit BackofficeApps zu tun habe.

                          Kommentar


                          • #58
                            JS zieht da eine riesige Barriere ein, weil du dann nicht mehr ein Tool brauchst, das HTTP spricht und HTML parsen kann, sondern einen JavaScript-Interpreter. Und da fangen die Probleme erst an.

                            Ich sehe da ein großes Problem für das offene Web. (Siehe dazu etwa auch die letzten Posts im anderen Thread. „Wir killen den URL.“)
                            @mermshaus,

                            gut, ich hab da jetzt (bei weitem) nicht so viel Ahnung wie du, aber könnte man mit diesem Argument nicht die Nutzung von JS im Allgemeinen wegdiskutieren, da nicht alle Browser über JS Interpreter verfügen?
                            https://github.com/Ma27
                            Javascript Logic is funny:
                            [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

                            Kommentar


                            • #59
                              Aus Interesse, Warum neimand erwähnt CodeIgniter Framework?

                              Kommentar


                              • #60
                                es gibt irgendwo auch mindestens einen "welches framework ist das beste" thread:
                                http://lmgtfy.com/?q=codeigniter+%2Bsite%3Aphp.de
                                da steht dann alles ausführlich drin.

                                Kommentar

                                Lädt...
                                X