In HTML5 kann man eigene Tags definieren, das weiss ich wie das funktioniert. Sie müssen im Namen einen Bindestrich enthalten, so erkennt man sie sofort. Per <xml> kann man beliebige Tags einbinden, sie sind dann aber innerhalb des <xml> defniert. Jetzt bin ich auf eine Seite gestossen die das nicht wie oben macht, ich frage mich wie das funktioniert. Geht mal auf die Seite lichess.org. Spielt ne Partie als unangemeldeter Benutzer gegen den Computer oder jemanden der automatisch zugewiesen wird, psielt keine Rolle. Schaut euch dann im Devtool eures Browsers den Code an und inspiziert die Zugliste. Da steht dann sowas wie <dev clas=...> <move p="..."><index>1</index></move> <move p="...." .... ... </dev> Wie haben die das <move> und <index> definiert?
Gibt viele Wege, sowas zu machen. Hab mal auf der Seite nachgeschaut:
1 | > document.querySelector("index").constructor; |
2 | ƒ HTMLUnknownElement() { [native code] } |
3 | > document.createElement("index").constructor; |
4 | ƒ HTMLUnknownElement() { [native code] } |
Einen custom doctype oder nen custom xml namespace hat es auch nicht, ist halt sowieso HTML5, dort hat man das nicht mehr. Diese "ungültigen"/"unbekannten" Elemente können z.B. mit document.createElement("test"), oder mit x.innerHTML='<test/>', etc. erstellt werden. Bei HTML5 werden die aber sicher nicht validieren, mit custom doctype, oder XHTML und custom schema (bin mir zwar nicht sicher, ob Browser / Validatoren letzteres überhaupt unterstützen), könnte man sowas zumindest validierbar machen. Aber Heutzutage ist das ja eh allen egal... So oder so, würde ich von diesen HTMLUnknownElement Tags abraten. Die HTML5 Alternative, HTML5 Custom Elements, mit dem Bindestrich, kannst du ja schon. Und dann stellt sich natürlich auch immer die Frage, ob man auf sowas nicht komplett verzichten will. Man braucht ja kein custom element / tag, um in JS nen Controller für Elemente/Componenten zu schreiben. Andererseits, wenn alle anfangen würden, HTML5 Web Components voll auszunutzen, mit Shadow DOM und allem, würden wir vielleicht endlich mal den verfluchten Safari los (der ist Mittlerweile der neue IE). Das Problem mit diesen neuen dingen ist halt, sie sind nicht wirklich "stabil", gab schon 1-2 Revisionen. Und, ich hab schon mal den Fehler gemacht, ein Feature zu nutzen, dass von der W3C dann wieder entfernt wurde...
Aha dachte schon da gäbe es inzw. ne andere Variante von der ich noch nie was gehört hätte. Wenn man nat. einfach lustig neue Tags reinklopft ohne sich darum zu scheren ob das validiert, äh ja, kann man auch machen. Ich habe mich sowieso gewundert wozu man hier eigene Tags defiert werden, das ist irgendwie von hinten durch die Brust durchs Auge, komplett überflüssig.
DPA schrieb: > Das Problem mit diesen neuen dingen ist halt, sie sind nicht wirklich > "stabil", gab schon 1-2 Revisionen. Ja das Problem kenne ich. > Und, ich hab schon mal den Fehler gemacht, ein Feature zu nutzen, > dass von der W3C dann wieder entfernt wurde... Siehe WebSQLdatabase später von indexdb abgelöst.
Hm, welchen Sinn haben selbst definierte Tags? Woher soll der Browser wissen, wie er die zu rendern hat?
Mark B. schrieb: > Hm, welchen Sinn haben selbst definierte Tags? Den selben den Funktionen bei Programmiersprachen haben. > Woher soll der Browser > wissen, wie er die zu rendern hat? Indem man das Tag vorher definiert.
html-heinz schrieb: > Mark B. schrieb: >> Hm, welchen Sinn haben selbst definierte Tags? > Den selben den Funktionen bei Programmiersprachen haben. Nun, dafür gibt es doch schon JavaScript. Da braucht man nicht extra noch was in der Richtung erfinden.
Mark B. schrieb: > Nun, dafür gibt es doch schon JavaScript. Da braucht man nicht extra > noch was in der Richtung erfinden. Kommt drauf an was man macht. In Frameworks ist das Gang und Gäbe, für den Anwender dieses schreibt der dann flüssig nur noch die Tags runter und muss nicht im Code zwischen HTML und JS hin und her switchen, was einen schnell nervt und unübersichtlich ist. Zudem kann das dann auch einer nutzen der von JS nicht so den Plan oder gar keine Ahnung hat. Bei einer eigenen Seite wo man gewisse Fragmente nur wenig wiederverwendet sind eigene Tags nat. overkill. Bei Frameworks ist das heute Standard.
DPA schrieb: > würden wir vielleicht endlich mal > den verfluchten Safari los (der ist Mittlerweile der neue IE). Warum? So sehr verbreitet ist der nicht (15% laut Wikipedia) und OSS auch noch. Wie kann das schlecht sein? :D
Reinhard S. schrieb: > DPA schrieb: >> würden wir vielleicht endlich mal >> den verfluchten Safari los (der ist Mittlerweile der neue IE). > > Warum? So sehr verbreitet ist der nicht (15% laut Wikipedia) und OSS > auch noch. Wie kann das schlecht sein? :D Soweit ich weiss ist das nicht OSS. Andernfalls, wo findet man denn den Code? Und die Lizenz ist doch auch keine Freie? Der WebKit teil mag theoretisch OSS sein. Aber Apple scheint da mit seinem Safari immer massiv hinterherzuhinken. Ich hab öfter zeug, das geht überall, ausser in Safari. Und auch wenn es nur 15% sind, die ganzen Apple Fangirls, Fanboys, und Fansonstige, können ziemlich lästig werden. Insbesondere auch, weil die ganzen (Web)designer immer meinen, den Mist nutzen zu müssen. Und dann muss man sich wieder mit Mist herumschlagen, wie z.B. wenn mal wieder nur Safari ein SVG zu klein und im falschen aspect ratio Rendert und Hoch skaliert, statt das richtig zu machen, und solchen mist... Und von deren schlechten Einfluss auf (Web)standards will ich gar nicht erst anfangen, die kochen immer ihr eigenes Süppchen, und versaltzen sie den anderen. Momentanes Beispiel: WebGPU. Alles sagen, hey, machen wir keinen komplizierten neuen Mist, wir haben schon SPIR-V als intermediate Repräsentation für sowas, mit gutem LLVM support. Kommt Apple wieder daher "Machen wir nicht. Wir wollen, dass das auf unseren neuen mist wächst!". Antworten auf Mailinglisten waren in die Richtung "Oh nein, blos nicht!". Ratet mal, wer sich durchgesetzt hat? Richtig, Apple...
Reinhard S. schrieb: > Warum? So sehr verbreitet ist der nicht (15% laut Wikipedia) Nach einer anderen Wikipedia sinds insgesamt gut 20%, und damit Zweiter "direkt" hinter Chrome, und bei den Smartphones alleine gut 30%. Die Chance, daß der mal verschwindet, ist nahezu null. Oliver
DPA schrieb: > Reinhard S. schrieb: >> DPA schrieb: >>> würden wir vielleicht endlich mal >>> den verfluchten Safari los (der ist Mittlerweile der neue IE). >> >> Warum? So sehr verbreitet ist der nicht (15% laut Wikipedia) und OSS >> auch noch. Wie kann das schlecht sein? :D > > Soweit ich weiss ist das nicht OSS. Andernfalls, wo findet man denn den > Code? https://webkit.org/getting-the-code/ > Und die Lizenz ist doch auch keine Freie? Laut Wiki teils LGPL, teils BSD. Und ja, Safari selbst hat auch noch proprietäre Teile. > Der WebKit teil mag theoretisch OSS sein. Aber Apple scheint da mit > seinem Safari immer massiv hinterherzuhinken. Ich hab öfter zeug, das > geht überall, ausser in Safari. Ich als Nutzer kann mich über Safari (auf dem iPad) bisher nicht beklagen. Läuft. Besser als das Mailprogramm... > Und auch wenn es nur 15% sind, die ganzen Apple Fangirls, Fanboys, und > Fansonstige, können ziemlich lästig werden. Glaub ich sofort. Zum Ignorieren sinds dann halt doch etwas viele :) > Insbesondere auch, weil die > ganzen (Web)designer immer meinen, den Mist nutzen zu müssen. Dafür kann Safari aber nun nix. > Und von deren schlechten Einfluss auf (Web)standards will ich gar nicht > erst anfangen, die kochen immer ihr eigenes Süppchen, und versaltzen sie > den anderen. Momentanes Beispiel: WebGPU. Alles sagen, hey, machen wir > keinen komplizierten neuen Mist, wir haben schon SPIR-V als intermediate > Repräsentation für sowas, mit gutem LLVM support. Davon ab sind das Kategorien, wo ich mich frag, was das in einem Browser soll.
Reinhard S. schrieb: > Und die Lizenz ist doch auch keine Freie? > > Laut Wiki teils LGPL, teils BSD. Und ja, Safari selbst hat auch noch > proprietäre Teile. Das es auch freie Bestandteile hat, finde ich, ist ziemlich egal. Ich kann mir selbst den Safari nicht kompilieren, also ist es nicht OpenSource. Sonst könnte man ja jedes Proprietäre Programm, das z.B. eine freie libc oder sonst was nutzt, also unter anderem auch jedes Proprietäre Linux programm, als OSS bezeichnen. Und bezüglich WebKit, Ich kenne Browser (z.B. surf), die eigentlich nichts anderes als das sind, mit denen hab ich weniger Probleme, als mit Safari. Obwohl, auch die hinken in vielerlei hinsicht Firefox und Chrome hinterher, wenn es um neue web/browser features und ähnliches geht... Reinhard S. schrieb: > Davon ab sind das Kategorien, wo ich mich frag, was das in einem Browser > soll. Das gehört in die gleiche Kategorie, wie WebAssembly. Es wird daran gearbeitet, c-code, und teils auch bestehende Programme, im Browser nutzbar zu machen. Ich glaube, dass irgendwann ein kritischer Punkt erreicht werden wird, an dem es möglich wird, ganze Distributionen für den Browser zu übersetzen, es fehlen jetzt schon nurnoch ein zwei sachen dafür. Und sobald es soweit ist, wird das Web auf ein neues wieder ganz anders aussehen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.