Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › WHATWG: Browserhersteller…

Was fehlt?

  1. Thema

Neues Thema Ansicht wechseln


  1. Was fehlt?

    Autor: attitudinized 16.04.18 - 13:13

    Ich vermisse nicht wirklich ein Feature (ja das eine oder andere könnte geschmeidiger sein, da wird sich bei einem historisch gewachsenen Standard nix wesentliches ändern) was fehlt? IMHO ist HTML fertig.

  2. Re: Was fehlt?

    Autor: burzum 16.04.18 - 15:23

    attitudinized schrieb:
    --------------------------------------------------------------------------------
    > Ich vermisse nicht wirklich ein Feature (ja das eine oder andere könnte
    > geschmeidiger sein, da wird sich bei einem historisch gewachsenen Standard
    > nix wesentliches ändern) was fehlt? IMHO ist HTML fertig.

    * Ein gescheites, standardisiertes Kalender- und Zeitwidget das gestylt werden kann und vom Browser gerendert wird.
    * Ein etwas mächtigeres Selectwidget, siehe Select2
    * Eine Standard API für Translations in ECMA Script
    * Eine Standard API für Datum und Zeit (ICU kompatibel) in ECMA Script
    * Ein besseres Handling wie man diesen Wust aus JS zusammenbaut, ein Standard der Bundler wie Webpack und Co überflüssig macht.
    * Feuchter Traum: Etwas C# ähnliches statt ECMA Script. ;) Gut, eventuell reicht ja Web Assembly ;)

    Es ist ein Krampf die Balance aus einem JS-Blob zu dem was eine bestimmte Seite benötigt zu finden und dann auch immer das richtige Zeug zu laden das man gerade braucht. Eine Art Routing Map wie sie SPA-JS-Frameworks verwenden oder auch Frameworks auf Serverseite um eine URL zu mappen. Nur das man sie hier zu einem Set von Libs mappt. Durch diese Map könnte ein Script ideale Bundles bauen und automatisch, ohne das man das Scriptfile explizit angeben muß automatisch laden.

    Ansonsten braucht man für jeden Punkt irgendeine Lib. Und gerade Translations sind hochgradig ÄTZEND! Man nimmt z.B. ein Kalenderwidget das seine eigene Implementierung dafür mitbringt, dann nutzt man Moment.js das wieder eine andere Implementierung hat und die eigene Anwendung nutzt wieder eine eigene Implementierung oder eine der zig Libs dafür. Die Files liegen dann an tausend Orten verstreut, man hat drei Implementierungen und kann nicht mal einfach doppelte Strings (so fern sie vorkommen) zwischen den Libs teilen. Einfach rückständig und scheiße. Warum kann man nicht einfach sagen translations.setRoot('/locales'); und danach wird einfach nach gewählter Sprache z.B. /locales/de_de/main.po geladen? Eine in ECMA Script nativ vorhandene gettext Implementierung wäre ein Traum.

    Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul.



    3 mal bearbeitet, zuletzt am 16.04.18 15:34 durch burzum.

  3. Re: Was fehlt?

    Autor: KrayZee 16.04.18 - 15:58

    burzum hat nette features genannt, die gehen zwar mehr richtung js aber trotzdem relevant.

    wenn man mehr richtung html geht wäre zum beispiel ein templatesystem ganz nett, teile des trees in verschiedene dateien aufspalten und so weiter. dies gibt es zwar schon in einer relativ rudimentären form, man könnte dies jedoch weiter vereinfachen. in kombination mit dem templatesystem dann evtl den domtree ändern ohne diesen komplett neu aufzubauen, so wie es einige frameworks bereits können.

    mit floats und co konnte man früher auf tolle designs erstellen aber es war ne qual, mit flexbox und grid wurde uns die hand gottes gereicht. ich warte nurnoch auf den tag bis man sich keien sorgen mehr machen muss wegen der kompatibilität zu den browsern.

    nativer support für eigene tags wär auch ziemlich nett, man muss sich da immernoch mit workarounds aushelfen. es würde den quellcode viel lesbarer machen.

    dann vllt noch etwas zu css. die priorityrules sind ja mal sowas von quark.

  4. Re: Was fehlt?

    Autor: gab33 16.04.18 - 16:17

    > IMHO ist HTML fertig.

    W3C ≠ HTML (Nicht nur) - denn SVG, CSS und XML, MathML, SSML, XPath uvm. gehören da dazu. Zudem startete vor einigen Tagen WoT (Webstandards für IoT) Working Group.

    Also genug, was Browserhersteller sehr wohl noch interessiert.

    Mit HTML 5.2 gab es dazu auch: `<dialog>`, <style> im <body> - kleine Änderungen die es trotzdem angenehmer machen damit zu arbeiten.

  5. Re: Was fehlt?

    Autor: atarixle 16.04.18 - 16:19

    Win95 war auch fertig. Aber neue Ansprüche führten über viele weitere fertige Produkte zu Windows 10. Alles, was man jetzt mit JS macht, speziell mit JS Frameworks, könnte man in HTML standardisieren.

    HTML ist somit noch nicht fertig.
    Im Gegenteil, es wird nie fertig.

  6. Re: Was fehlt?

    Autor: redmord 16.04.18 - 17:27

    burzum schrieb:
    --------------------------------------------------------------------------------
    > * Ein gescheites, standardisiertes Kalender- und Zeitwidget das gestylt
    > werden kann und vom Browser gerendert wird.

    Inputs könnten generell mehr Aufmerksamkeit vertragen.

    > * Eine Standard API für Translations in ECMA Script

    Was hat der Browser hiermit zu tun? Internationalisierung ist dein persönliches Thema, sollte auch so bleiben. Die Szenarien sind zu unterschiedlich.

    > * Eine Standard API für Datum und Zeit (ICU kompatibel) in ECMA Script

    https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Intl
    Siehe auch: https://formatjs.io/

    > * Ein besseres Handling wie man diesen Wust aus JS zusammenbaut, ein
    > Standard der Bundler wie Webpack und Co überflüssig macht.
    > * Feuchter Traum: Etwas C# ähnliches statt ECMA Script. ;) Gut, eventuell
    > reicht ja Web Assembly ;)

    http://www.typescriptlang.org/
    C#-styligeres ECMA geht nicht. ;-)
    Und ja, WebAssembly wird die feuchten Träume aller JS-Hater werden. :P

    > Es ist ein Krampf die Balance aus einem JS-Blob zu dem was eine bestimmte
    > Seite benötigt zu finden und dann auch immer das richtige Zeug zu laden das
    > man gerade braucht. Eine Art Routing Map wie sie SPA-JS-Frameworks
    > verwenden oder auch Frameworks auf Serverseite um eine URL zu mappen. Nur
    > das man sie hier zu einem Set von Libs mappt. Durch diese Map könnte ein
    > Script ideale Bundles bauen und automatisch, ohne das man das Scriptfile
    > explizit angeben muß automatisch laden.

    Dependency-Management sollte IMHO auch weiterhin zu 100 % in der Hand der Entwickler bleiben.

    > Ansonsten braucht man für jeden Punkt irgendeine Lib. Und gerade
    > Translations sind hochgradig ÄTZEND! Man nimmt z.B. ein Kalenderwidget das
    > seine eigene Implementierung dafür mitbringt, dann nutzt man Moment.js das
    > wieder eine andere Implementierung hat und die eigene Anwendung nutzt
    > wieder eine eigene Implementierung oder eine der zig Libs dafür. Die Files
    > liegen dann an tausend Orten verstreut, man hat drei Implementierungen und
    > kann nicht mal einfach doppelte Strings (so fern sie vorkommen) zwischen
    > den Libs teilen.

    Das obliegt der Community, nicht der Browser-Entwickler. Das ist auch ganz gut so..

    > Einfach rückständig und scheiße. Warum kann man nicht
    > einfach sagen translations.setRoot('/locales'); und danach wird einfach
    > nach gewählter Sprache z.B. /locales/de_de/main.po geladen? Eine in ECMA
    > Script nativ vorhandene gettext Implementierung wäre ein Traum.

    Den "Quasistandard" gibt es doch mittlerweile: https://www.i18next.com/

  7. Re: Was fehlt?

    Autor: burzum 16.04.18 - 20:12

    redmord schrieb:
    --------------------------------------------------------------------------------
    > Was hat der Browser hiermit zu tun? Internationalisierung ist dein
    > persönliches Thema, sollte auch so bleiben. Die Szenarien sind zu
    > unterschiedlich.

    Es geht um die Schnittstelle! Ein allgemeines API, so das ich bei egal welcher Lib die gleiche API und die gleiche Datenstruktur der Übersetzung ansprechen kann. War mein Bespiel mit den Libs nicht klar?

    > > * Eine Standard API für Datum und Zeit (ICU kompatibel) in ECMA Script
    >
    > developer.mozilla.org
    > Siehe auch: formatjs.io

    Intl alleine gibt mir noch kein "last friday at 02:00 am" aus, oder irre ich? Formatjs bietet mir wieder Libs, keinen nativen Standard. Ich hätte gerne eine standardisierte Lösung die quasi data-fns und moment.js und co überflüssig macht in dem sie alles biete was die Libs bieten.

    > www.typescriptlang.org
    > C#-styligeres ECMA geht nicht. ;-)

    Ja, aber schon wieder ein Transpiler der meine Build Config und Dependencies anschwellen läßt.

    > Dependency-Management sollte IMHO auch weiterhin zu 100 % in der Hand der
    > Entwickler bleiben.

    Ich habe nichts anderes behauptet sondern fordere nur eine saubere, standardisierte Lösung dafür statt dem dreckigen Gefrickel das die Sache trotz Tools wie Webpack bleibt. Alleine Webpack2 vs Webpack3. Fontawesome geht z.B. nicht out of the Box mit Webpack3, da mußte man auch erst wieder frickeln.

    > Das obliegt der Community, nicht der Browser-Entwickler. Das ist auch ganz
    > gut so..

    Was ist an einem erweiterbaren Grundgerüst auszusetzen? Die ganzen Kalender der Community sehen eh alle gleich aus vom Grundgerüst her. Wer dann noch immer seine Implemtierung will kann das ja nach wie vor tun. Den restlichen 99% wird das Widget des Browsers / ECMA Script API dazu reichen.

    > Den "Quasistandard" gibt es doch mittlerweile: www.i18next.com

    Ein Quasistandard ist kein Standard. :) Wie du inzwischen gemerkt hast geht es mir um standardisierte APIs. Und wie ich schrieb findest du kaum zwei Libs die das gleiche System für Übersetzungen nutzen. Ich kenne i18next. Das Problem ist aber der eine nutzt i18next, der andere was Hausgemachtest, der nächste gettext-js und darauf der wieder was eigenes. Ich glaube weder moment.js noch eins unserer Vue.js Plugins nutzt I18next oder das Vue Plugin dafür. Auch kein einziges der Jquery Plugins. Das Kalenderscript hat eine eigene Lösung. Zum Kotzen. :)

    Was spricht zum Beispiel gegen etwas wie:

    <link rel="locale" type="gettext" root="/locales" href="app">
    <link rel="locale" type="json" root="/some-plugin/locales" href="some-plugin" locale="de">

    Der Browser läd das Zeug automatisch aus

    http://i18n.com/locales/en_en/app.po
    http://i18n.com/some-plugin/locales/de_de/some-plugin.json

    und stellt den Kram via ein paar Methoden durch die ECMA Script API zur Verfügung?

    i18n.plural('{0} Article', '{0} Articles');

    oder noch geiler, so das man kein JS schreiben müßte:

    <i18n-plural>
    <plural-case>{0} Article</plural>
    <plural-case>{0} Articles</plural>
    </i18n-plural>

    Ash nazg durbatulûk, ash nazg gimbatul, ash nazg thrakatulûk agh burzum-ishi krimpatul.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Landeshauptstadt München, München
  2. trinamiX GmbH, Ludwigshafen
  3. Johann Wolfgang Goethe-Universität Frankfurt, Frankfurt am Main
  4. Fresenius Netcare GmbH, Bad Homburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de
  2. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Yuneec H520: 3D-Modell aus der Drohne
Yuneec H520
3D-Modell aus der Drohne

Multikopter werden zunehmend auch kommerziell verwendet. Vor allem machen die Drohnen Luftbilder und Inspektionsflüge und vermessen. Wir haben in der Praxis getestet, wie gut das mit dem Yuneec H520 funktioniert.
Von Dirk Koller


    Machine Learning: Wie Technik jede Stimme stehlen kann
    Machine Learning
    Wie Technik jede Stimme stehlen kann

    Ein Unternehmen aus Südkorea arbeitet daran, Stimmen reproduzierbar und neu generierbar zu machen. Was für viele Branchen enorme Kosteneinsparungen bedeutet, könnte auch eine neue Dimension von Fake News werden.
    Ein Bericht von Felix Lill

    1. AWS Amazon bietet seine Machine-Learning-Tutorials kostenlos an
    2. Random Forest, k-Means, Genetik Machine Learning anhand von drei Algorithmen erklärt
    3. Machine Learning Amazon verwirft sexistisches KI-Tool für Bewerber

    Google Nachtsicht im Test: Starke Nachtaufnahmen mit dem Pixel
    Google Nachtsicht im Test
    Starke Nachtaufnahmen mit dem Pixel

    Gut einen Monat nach der Vorstellung der neuen Pixel-Smartphones hat Google die Kamerafunktion Nachtsicht vorgestellt. Mit dieser lassen sich tolle Nachtaufnahmen machen, die mit denen von Huaweis Nachtmodus vergleichbar sind - und dessen Qualität bei Selbstporträts deutlich übersteigt.
    Ein Test von Tobias Költzsch

    1. Pixel 3 Google patcht Probleme mit Speichermanagement
    2. Smartphone Google soll Pixel 3 Lite mit Kopfhörerbuchse planen
    3. Google Dem Pixel 3 XL wächst eine zweite Notch

    1. Strategiespiel: Conan Unconquered verbindet Festungsbau und Verteidigung
      Strategiespiel
      Conan Unconquered verbindet Festungsbau und Verteidigung

      Erst eine Burg mit dicken Mauern aus dem Boden stampfen und sie dann gegen anstürmende Armeen verteidigen: Das ist das Konzept des PC-Strategiespiels Conan Unconquered, an dem Petroglyph Games (Command & Conquer) arbeitet.

    2. Raumfahrt: Wie Voyager 2 das Ende des Sonnensystems fand
      Raumfahrt
      Wie Voyager 2 das Ende des Sonnensystems fand

      Eine weitere Raumsonde hat das Sonnensystem verlassen. Die Messdaten von Voyager 2 sind eindeutig. Dabei ist es gar nicht so leicht zu sagen, wo das Sonnensystem eigentlich zu Ende ist.

    3. MySQL-Frontend: Lücke in PhpMyAdmin erlaubt Datendiebstahl
      MySQL-Frontend
      Lücke in PhpMyAdmin erlaubt Datendiebstahl

      Eine Sicherheitslücke im MySQL-Frontend PhpMyAdmin erlaubt es, lokale Dateien auszulesen. Dafür benötigt man jedoch einen bereits existierenden Login.


    1. 17:15

    2. 16:50

    3. 16:35

    4. 16:20

    5. 16:00

    6. 15:40

    7. 15:20

    8. 15:00