Frage zum Wiki-Artikel „@-Regeln“

[nix]

Warum findet man unter „Kombination verschiedener @-Regeln“ nicht auch etwas zu and, or, not? and wird ja (wenigstens?) in den Beispielen verwendet. Aber erwähnt … gefunden habe ich dazu, abseits der Beispiele, nichts. (Was auch deshalb problematisch ist, weil „Allerweltsbegriffe“ sich sowieso, außerhalb eines „Inhaltsverzeichnises“, kaum finden lassen.)

Und dazu, damit es leichter rutscht, gleich noch etwas Senf: im Gegensatz zum CSS-:not() verlangen diese Operatoren (wenigstens Firefox und Safari sind sich da einig) zwingend nach Whitespace „drum herum“. Also nicht

@supports not(hyphens:auto) {} /* oder */ @supports not(hyphens) {}
@supports not(block-size) {} /* und/oder */ not(block-size:1lh) {}
… /* ich weiß: da ⇈ ist ein Bonus-Fehler drin */

sondern

@supports not (hyphens:auto) {} /* oder */ @supports not hyphens:auto {}
@supports not block-size:1lh {}
…

Und wenn’s nur wäre, weil „die da“ dazu auch kein Wort verlieren.

Aber daß man da anscheinend großen Wert auf ein genaues Hinschauen bei den Schrift-Features legt … na, damit wird das bunte Darstellen aller Inhalte auch nicht abgestellt. Aber über ein User-Stylesheet mit vielen !important drin kann man schon mal nachdenken. Die große Font-Kontrolle (incl. integrierter Datenweitergabe an Google: IP-Adresse hat am/um …) anstelle des behauptetem Abstellen des Pixelgenau …

Und was man mit @supports selector(…) (tatsächlich diesmal ohne Whitespace?) Sinnvolles … man wird sehen.

BTW: schon gewußt? Wenn „Google der Kreditkarte keine Telefonnummer zuordnen kann“, ist es Essig mit dem Online-Kauf mit eben dieser Karte. — Gut, die Fehlermeldung trifft den Sachverhalt vielleicht nicht genau, so etwas kennt man ja von Compiler-Fehlermeldungen. Aber daß es dazu eine gut ausgearbeitete Seite mit der Fehlermeldung gibt, spricht IMO Bände!

[Matthias Scharwies]

Servus!

Warum findet man unter „Kombination verschiedener @-Regeln“ nicht auch etwas zu and, or, not?

Wir haben nicht genügend Manpower!

and wird ja (wenigstens?) in den Beispielen verwendet. Aber erwähnt … gefunden habe ich dazu, abseits der Beispiele, nichts. (Was auch deshalb problematisch ist, weil „Allerweltsbegriffe“ sich sowieso, außerhalb eines „Inhaltsverzeichnises“, kaum finden lassen.)

Bitte melde dich im Wiki an und erstelle einen Artikel mit Beispiel in deinem Benutzernamensraum.

Dann können wir gemeinsam überlegen, wo man den integrieren und gut erreichbar verlinken kann.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

ich hab mal bei @supports etwas verbessert. An der von Nix genannten Stelle nicht, wie schon begründet.

Rolf

[Rolf B]

Hallo nix,

"die da" verlieren ab hier eine Menge Worte über not, and und or. Inclusive Beispielen. Das Whitespace hinter dem not ist dort nicht erwähnt, richtig, aber immerhin steht es in allen Beispielen.

:not() ist auch kein CSS Operator. Sondern eine Pseudoklasse in Funktionsnotation, und bei denen muss die Klammer direkt dahinter stehen. Ich nehme an, dass der not-Operator in den @-Bedingungen das Space braucht, um den CSS Parser nicht zu komplex werden zu lassen. Das ist auch bei den + und - Operatoren in der calc() Funktion so.

Die formale Syntaxbeschreibung sagt übrigens, dass

@supports not block-size:1lh {}

falsch ist, da steht nämlich <supports-in-parens> als Syntaxelement. Und das ist eins von diesen:

• ( <supports-condition> )
• <supports-feature>
• <general-enclosed>

In Option 1 stecken die Klammern explizit drin, das ist auch nur der rekursive Rückbezug, dass Bedingungen Teil einer größeren Bedingung sein können.

Option 2 ist ein Forward zu <supports-decl>, warum auch immer, und <supports-decl> ist als ( <declaration> ) definiert. Also: Klammern.

Option 3 ist entweder ( <any-value>? ) - also ein beliebiger Wert in Klammern, oder <function-token> <any-value>? ). Hier ist der einzige Punkt, wo ein "<support-in-parens>` nicht mit einer Klammer beginnt. Es muss aber ein function token sein, und dessen Definition endet mit einer linken Klammer. Im übrigen schreibt die Spec, dass Option 3 in Stylesheets nicht zu verwenden ist, sondern für die Zukunft reserviert sei. Diese Zukunft tritt mit @supports selector() ein - das ist ein function token und wird in Level 4 der Spec beschrieben.

block-size:1lh ist dagegen eine "Declaration", auch wenn die Spec das nicht zu einer weiteren Syntaxdefinition verlinkt. In MDN steht's. Wir sind also bei Option 2, und demnach braucht es Klammern.

Wenn Du den Artikel verbessern möchtest, bist Du herzlich willkommen, dich im Wiki zu anzumelden (unangemeldete Edits haben wir abgeschaltet, weil zuviel Müll reinkam) und dich ans Werk zu machen. Matthias oder ich sehen das dann als "unkontrollierte Änderung" und segnen das entweder ab, verbessern es oder schmeißen es wieder raus 😉. Heißt: Wenn Du Dir unsicher bist, ob dein Werk was taugt, erstelle erstmal eine Kopie des Artikels oder Artikelteils in einer Unterseite deines Benutzer-Raums (zum Beispiel /wiki/Benutzer:nix/@supports) und bitte um Peer Review.

Rolf

[nix]

… :not() ist auch kein CSS Operator …

Stimmt. Aber bislang die „gefundendste“ Stelle hier. Und immerhin ja doch irgendwie verwandt.

Die formale Syntaxbeschreibung sagt übrigens, dass

@supports not block-size:1lh {}

falsch ist, da steht nämlich <supports-in-parens> als Syntaxelement. Und …

ein Stücken weiter oben, gleich vor The and operator:

Note: There is no need to enclose the not operator between two parentheses at the top level. To combine it with other operators, like and and or, the parentheses are required.

Das Mißverständnis, würde ich sagen, liegt nahe.

[Rolf B]

Hallo nix,

da fällst Du einer Verwechslung zum Opfer.

@supports not (warp:8) sind Klammern um den Operanden. Die sind immer nötig.

@supports (not (warp:8)) sind - zusätzlich - Klammern um den NOT Operator. Die sind in diesem Fall nicht nötig.

@supports not (warp:8) and (catch-mechanism:grappler) ist hingegen syntaktisch falsch. Es muss @supports (not (warp:8)) and (catch-mechanism:grappler) heißen. Dann unterstützt Du die NX-01 Enterprise.

Oder sinnvoller formuliert:

@supports (not (grid-template-columns: subgrid)) and (grid-template-rows: masonry) identifiziert Browser, die zwar kein Subgrid können, aber dafür Masonry-Layout (benannt nach dem Aussehen einer Ziegelmauer mit versetzten Steinreihen)

Rolf

[nix]

Da steht allerdings

@supports not (not (transform-origin: 2px))

Und die Formulierung sagt (scheint zu sagen?), daß da mindestens ein paar Klammern zu viel drin steckt. Nehmen wir also ein Paar „auf Verdacht“ weg, dann bleibt

@supports not not (transform-origin: 2px)

[Rolf B]

Hallo nix,

Nachtrag: An der von Dir verlinkten Stelle gehört eine Auslassung über and/or/not und Whitespaces gar nicht hin. Denn an dieser Stelle geht's nur um das Schachteln mehrerer @ Regeln.

Hinweise zur Syntax der @media oder @supports-Bedingungen gehören zu der jeweiligen @-Regel. Allerdings steht unter @supports auch nichts dazu…

Bei @media steht einiges, es ist aber nicht 1:1 auf @supports übertragbar. In @media ist ein not ohne nachfolgende Klammern zulässig und negiert die ganze Regel (es sei denn, ich hab das damals in der Spec falsch verstanden und falsch aufgeschrieben). In @supports scheint mir das nicht erlaubt.

Bei @media hat sich offenbar auch wieder einiges getan - damals hatte ich Level 3 der Spec für die Syntax und die kannte noch kein OR, mittlerweile gibt's aber wohl auch eine alternative Syntax, in der man OR verwenden, aber keinen Media Type angeben kann. Das muss ich erstmal studieren.

Rolf

[nix]

Nachtrag: An der von Dir verlinkten Stelle gehört eine Auslassung über and/or/not und Whitespaces gar nicht hin.
…
Hinweise zur Syntax der @media oder @supports-Bedingungen gehören zu der jeweiligen @-Regel. Allerdings steht unter @supports auch nichts dazu…

Stimmt. Bin eine Zeit lang hier herumgeirrt und dann hier stehen geblieben. Weil da, soweit ich das gesehen habe, die größte „Konzentration Zusammmenhänge“ zu sehen war.

Und: es hat sich schon wieder was getan? Ja wer soll denn von all dem jemals etwas benutzen? Man kommt mit dem Hinterherlesen nicht nach, enteckt laufend was anderes, was man probiert ist schnell „explosiv“ … und wer mag bei all der Umgestaltung noch glauben, daß die heute geschriebenen Zeilen morgen von den Browsern noch gelesen werden? Wegen dieser heiligen Kompatibilität? Kann sein. Aber dann bringen die, auch wegen mancher Erleichterung („<DOCTYPE html> genügt“), gezwungenermaßen noch mehr Sprengstoff mit.

Wenn ich jetzt auch noch an das eine oder andere Browser-Problem denke (egal, welcher „von den beiden“ jetzt vielleicht Recht hat oder nicht, mindestens einer muß daneben liegen …), fällt mir nur noch „Featuritis“ ein. Und die hat, vor Jahren, dafür gesorgt, daß ich in eine RIchtung nichts mehr melde. „WFM“ kam als Antwort, obwohl das Problem IMHO ohne Beispiel zu verstehen war („wenn ein hovern die klickbare Fläche eins Links umgestaltet, ist der ggf. nicht mehr zu treffen“). Und dann kam ja schon die nächste Browser-Version mit vielen neuen Features … Wie war das doch? All die 1000 Augen, welche diese BASH-Lücke über mindestens 20 Jahre nachweislich gepflegt haben …?

[Gunnar Bittersmann]

@@nix

Und: es hat sich schon wieder was getan?

CSS ist wohl diejenige Webtechnologie, bei der sich am meisten tut.

Ja wer soll denn von all dem jemals etwas benutzen?

Jede^[1], die modernes Webdesign umsetzt.

Man kommt mit dem Hinterherlesen nicht nach

Na so viel tut sich nun auch wieder nicht.

enteckt laufend was anderes

Wer sagt denn, dass Frontend-Enwicklung langweilig sein müsse?

und wer mag bei all der Umgestaltung noch glauben, daß die heute geschriebenen Zeilen morgen von den Browsern noch gelesen werden?

Natürlich werden sie. (So wie die vor 25 Jahren geschriebenen Zeilen auch.) Es sei denn, du verwendest entwegen allen Warnungen noch experimentelle Features, die sich noch ändern können. Die sind aber hinter Featureflags, also eh nicht für Webseiten für die Allgemeinheit zu verwenden.

Fun fact: Ich bin gerade dabei, zum ersten Mal container queries produktiv einzusetzen. Wird aber auch Zeit!

Aber dann bringen die, auch wegen mancher Erleichterung („<DOCTYPE html> genügt“), gezwungenermaßen noch mehr Sprengstoff mit.

Keine Ahnung, was du eigentlich sagen willst.

🖖 Живіть довго і процвітайте

---

1. Männliche Webentwicklerinnen sind mitgemeint. ↩︎

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Jede, die modernes Webdesign umsetzt.

Männliche Webentwicklerinnen sind mitgemeint.

s.a. https://twitter.com/OrthoDel/status/1691817282400305159

---

Fun fact: Ich bin gerade dabei, zum ersten Mal container queries produktiv einzusetzen. Wird aber auch Zeit!

Not so funny: Der Unit-Test schlägt fehl, weil der Parser (vue-jest) mit @container nicht klarkommt. (Wir haben Template, Script und Style zusammen in einer Vue-Datei pro Komponente.)

Hat jemand eine Idee, wie das zu beheben wäre? (Update auf Vue 3 ist gegenwärtig noch keine Option.)

🖖 Живіть довго і процвітайте

[Matthias Scharwies]

Servus!

Und: es hat sich schon wieder was getan?

Ja, da hat @Rolf B schon was zu den vielen Modulen von CSS gesagt.

Ja wer soll denn von all dem jemals etwas benutzen? Man kommt mit dem Hinterherlesen nicht nach, enteckt laufend was anderes, was man probiert ist schnell „explosiv“ …

Ich persönlich verwende nur ca. 15 HTML-Elemente (bei h3 hört's auf, außer em und strong gibt's keine Textauszeichnung) und einen kleinen Bruchteil der mittlerweile ca. 300 CSS-Eigenschaften.

Im WebDesign gilt wie auch anderswo oft der Grundatz Less is more!

und wer mag bei all der Umgestaltung noch glauben, daß die heute geschriebenen Zeilen morgen von den Browsern noch gelesen werden?

Deswegen würde ich bei solchen, nur durch einige Browser unterstützten features eben noch warten. Das heißt ja nicht, dass man zurück zum Tabellenlayout gehen muss.

SELFHTML hat das Problem, dass ein frisch angelegter Artikel zu neuen Features öfters umgeschrieben werden muss - wartet man mit dem Artikel, wird das Fehlen ebendessen angeprangert.

Wegen dieser heiligen Kompatibilität? .....

Ich weiß nicht, was ich dir weiter empfehlen kann.

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

Ich persönlich verwende nur ca. 15 HTML-Elemente

4 sind schon obligatorisch: html, head, title, body. meta braucht man auch zweimal.h1 sollte auch so gut wie immer auf einer Webseite sein (und zwar genau einmal).

a (was wäre das Web ohne Links?) und p (du hast doch Text?), zur Texthervorhebung erwähntest du em und strong.

img (was wäre das Web ohne Katzenbilder?) und wenn man’s gut machen will auch picture und source.

Du hast eine Navigation? nav, ul, li.

Ein Formular? form, label, input, button.

Eine Tabelle? table, thead, tbody, tr, th, td.

Zum Gruppieren und wenn nichts anderes passt div und span.

script, style, externes Stylesheet mit link.

Damit sind wir schon beim Doppelten der von dir genannten Anzahl. Und haben noch keine Struktur: main, header, footer, section, article.

Fun fact: Vor einiger Zeit kam mal ein Quiz übern Ticker, wo es darum ging, alle HTML-Elementtypen aufzuschreiben, die einem so einfallen. Ich glaub, ich kam über 100, und mir fehlten immer noch einige.

---

Im WebDesign gilt wie auch anderswo oft der Grundatz Less is more!

Das ist Unsinn. Es gilt wie auch anderswo oft der Grundatz Verwende das richtige Werkzeug für den jeweiligen Zweck!

---

und wer mag bei all der Umgestaltung noch glauben, daß die heute geschriebenen Zeilen morgen von den Browsern noch gelesen werden?

Deswegen würde ich bei solchen, nur durch einige Browser unterstützten features eben noch warten.

Worauf? Auf Godot?

Von progressive enhancement hat du noch nie gehört?

„Die Grundfunktionalität zu erstellen dauert nicht allzu lange. Wenn man das getan hat, kann man seine Zeit damit verbringen, mit den neusten und großartigsten Browsertechnologien zu experimentieren; sicher in dem Wissen, dass selbst wenn diese noch nicht weitgehend unterstützt werden, man den Fallback ja bereits hat.“ — Jeremy Keith (mehr davon)

🖖 Живіть довго і процвітайте

[Matthias Scharwies]

Servus!

@@Matthias Scharwies

Ich persönlich verwende nur ca. 15 HTML-Elemente

...

Damit sind wir schon beim Doppelten der von dir genannten Anzahl. Und haben noch keine Struktur: main, header, footer, section, article.

Ich würde in deine Auflistung eben noch em und strong als nützlich reinbringen. Aber schon bei main, article und section würde ich - gerade angesichts der Diskussionen anno dunnemals - nur eins -wenn überhaupt einsetzen.

Fun fact: Vor einiger Zeit kam mal ein Quiz übern Ticker, wo es darum ging, alle HTML-Elementtypen aufzuschreiben, die einem so einfallen. Ich glaub, ich kam über 100, und mir fehlten immer noch einige.

Du bist so schlau - ich bewunder dich!

---

Im WebDesign gilt wie auch anderswo oft der Grundatz Less is more!

Das ist Unsinn. Es gilt wie auch anderswo oft der Grundatz Verwende das richtige Werkzeug für den jeweiligen Zweck!

Ja, aber man muss den Hintergrund nicht einfärben, jedem Text einen Schatten und eine Unterstreichung geben. Das weißt du auch, bist aber der Geist, der stets verneint.

Das ist genau das Problem: Wir wissen nicht genau, was nix vorhat - er probiert rum und versucht die komplexesten Dinge zusammenzuwerfen und gibt dann den Browsern die Schuld.

Und du sagst ihm jetzt indirekt: mach weiter so!

---

und wer mag bei all der Umgestaltung noch glauben, daß die heute geschriebenen Zeilen morgen von den Browsern noch gelesen werden?

Deswegen würde ich bei solchen, nur durch einige Browser unterstützten features eben noch warten.

Worauf? Auf Godot?

Von progressive enhancement hat du noch nie gehört?

Doch! Aber ich habe vor 3 Jahren mit subgrid experimentiert. Da habe ich dann mangels Browserunterstützung 2 grids verschachtelt, anstatt zwei verschiedene Layouts anzulegen.

Genau so mit container queries - tolle Sache für fluide Typografie, für die vielbeschworenen Cards nur mit zusätzlichen divs machbar. Da würde ich auch lieber bei Grid bleiben.

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

Ja, aber man muss den Hintergrund nicht einfärben

Doch, sonst schaut man ja ins Innere des Monitors. 🤪

bist aber der Geist, der stets verneint.

So steht’s in meinem Profil.

Verwende das richtige Werkzeug für den jeweiligen Zweck!

Das ist genau das Problem: Wir wissen nicht genau, was nix vorhat - er probiert rum und versucht die komplexesten Dinge zusammenzuwerfen und gibt dann den Browsern die Schuld.

Und du sagst ihm jetzt indirekt: mach weiter so!

Mitnichten. Ich sage: Ohne Zweck taugt das beste Werkzeug nichts.

Und daran krankt das Wiki IMHO an vielen Stellen: Es werden Werkzeuge vorgestellt und für Beispiele Zwecke an den Haaren herbeigezogen, anstatt von einem bestimmten Zweck pro Tutorial auszugehen und die jeweils dafür erforderlichen Werkzeuge zu beschreiben.

Und dass immer, wenn nix nix versteht, die Browser schuld wären, würde ich auch nicht unterschreiben.

Genau so mit container queries - tolle Sache für fluide Typografie, für die vielbeschworenen Cards nur mit zusätzlichen divs machbar. Da würde ich auch lieber bei Grid bleiben.

?? Ich sehe in dem Zusammengewürfelten keinen Zusammenhang.

Container queries werden von allen gängigen Browsern unterstützt.

Am ehesten sind alte Browserversionen wohl auf Smartphones anzutreffen, wo Browser nur zusammen mit dem Betriebssystem upgradet (geupgradet? upgegradet?) werden.

Macht aber nichts. Wenn man den Mobile-first-Ansatz verwendet, bekommen Smartphones das Layout für schmale Container. Container queries greifen bei größeren Containerbreiten, also eher auf größeren Geräten. Und wenn Container queries nicht unterstützt werden, dann wird halt das Layout für schmale Container dargestellt. Nicht optimal, aber immer noch alles les- und bedienbar.

(Erwähnte ich schon, dass es kaum eine Entschuldigung gibt, auf Desktopgeräten seinen Browser nicht aktuell zu halten?)

🖖 Живіть довго і процвітайте

[nix]

Verwende das richtige Werkzeug für den jeweiligen Zweck!

Das ist genau das Problem: Wir wissen nicht genau, was nix vorhat - er probiert rum und versucht die komplexesten Dinge zusammenzuwerfen und gibt dann den Browsern die Schuld.

Na ja — ich schau’ mir all diese neuen Werkzeuge an und stelle bei so ziemlich jedem fest, daß „es“ immer nur ein Stück weit tut, wonach es aussieht. Was ich da bastle ist ja nicht mal wirklich wichtig (sonst hätte ich das mit der neuen Werkzeugkiste längst sein lassen!). Aber irgendjemand muß es doch versuchen. Jedenfalls, wenn da nicht „für Max Headroom“ entwickelt wird. Und das mit den Browsern: das CSS ist jetzt fast doppelt so lang. Wegen diversesr @supports drin, welche dem Safari an diesen und jenen Stellen z. B. cqb anbieten. Und dem Firefox Prozente. Das mit sqrt() und round() zähle ich ja nicht mal mit. Übermäßig ähneln sich die Darstellungen aber trotzdem nicht. Und wenn dann z. B. in einem Browser beim gleichen Quelltext selbst mit massigen @supports-Weichen nur einen schmalen Strich am Bildschirmrand zeigt, während der andere etwas abliefert, das doch so ähnlich aussieht, wie ich mir das mit dem Kontrollieren von Größen incl. der cq-Dingens vorgestellt hätte — dann sehe ich, „lt. Murphy“, drei Möglichkeiten: der eine Browser machts falsch, der andere, beide, einer von beiden mit mit zu sammen … alle können jedenfalls irgendwie nicht das gleiche meinen.

Und du sagst ihm jetzt indirekt: mach weiter so!

Mitnichten. Ich sage: Ohne Zweck taugt das beste Werkzeug nichts.

Hmmmja … aber wer wäscht heute noch mit so etwas? Dabei war sogar so etwas mal ganz neu und … Dingens und so.

…

(Erwähnte ich schon, dass es kaum eine Entschuldigung gibt, auf Desktopgeräten seinen Browser nicht aktuell zu halten?)

Och, ein wenig Lynx oder so, täte manchen Leuten schon gut. Geräteherstellern, welche meinen, eine Schicki-Micki-Oberfläche rechtfertigt jedes Ausbremsen der Nutzer, beispielsweise.

[Auge]

Hallo

Am ehesten sind alte Browserversionen wohl auf Smartphones anzutreffen, wo Browser nur zusammen mit dem Betriebssystem upgradet (geupgradet? upgegradet?) werden.

„Aktualisiert“, einfach nur „aktualisiert“. Warum kann keiner mehr in der deutschen Sprache überaus gängige Begriffe benutzen und stottert sich statt dessen irgendwas denglisches zurecht?

Mann, mann, mann. Brech' dir bloß nicht die Füße.

Tschö, Auge

[Fred]

Moin

Warum kann keiner mehr in der deutschen Sprache überaus gängige Begriffe benutzen und stottert sich statt dessen irgendwas denglisches zurecht?

Die Anglizismen in der deutschen Sprache sind ein no-go. 😉

Fred

[Rolf B]

Hallo Fred,

aber dennoch macht es für Developer Sinn, einen Modus Operandi zu finden, wie man sich am Ende des Tages auf eine verständliche Begriffswelt commiten kann!

🤔🙄 Rolf 😜

[Gunnar Bittersmann]

@@Auge

upgradet (geupgradet? upgegradet?)

„Aktualisiert“, einfach nur „aktualisiert“. Warum kann keiner mehr in der deutschen Sprache überaus gängige Begriffe benutzen und stottert sich statt dessen irgendwas denglisches zurecht?

Da will ich mal mit der Zeit gehen und dann kommst du mit so’m antiquitierten Zeugs daher. 😊 Mit Recht.

🖖 Живіть довго і процвітайте

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Fun fact: Vor einiger Zeit kam mal ein Quiz übern Ticker, wo es darum ging, alle HTML-Elementtypen aufzuschreiben, die einem so einfallen.

Vadim Makeev hat das Ding gerade in seinem Vortrag erwähnt, den ich gerade schaue.

Ich glaub, ich kam über 100, und mir fehlten immer noch einige.

114 sind’s.^[1]

🖖 Живіть довго і процвітайте

---

1. gegenwärtig ↩︎

[nix]

Ja wer soll denn von all dem jemals etwas benutzen? Man kommt mit dem Hinterherlesen nicht nach, enteckt laufend was anderes, was man probiert ist schnell „explosiv“ …

Ich persönlich verwende nur ca. 15 HTML-Elemente (bei h3 hört's auf, außer em und strong gibt's keine Textauszeichnung) und einen kleinen Bruchteil der mittlerweile ca. 300 CSS-Eigenschaften.

Na ja, aber man muß erst mal herausfinden, mit was man denn da „rummachen“ will. Auch die eine oder andere Änderung muß mal mit rein (z. B. üb’ ich jetzt, inline-size anstelle von width zu verwenden). Und: wenn nur zwei oder drei Leute in diesem Internet … Aber so kommt man, über kurz oder lang, ja doch damit in Kontakt.

und wer mag bei all der Umgestaltung noch glauben, daß die heute geschriebenen Zeilen morgen von den Browsern noch gelesen werden?

Deswegen würde ich bei solchen, nur durch einige Browser unterstützten features eben noch warten. Das heißt ja nicht, dass man zurück zum Tabellenlayout gehen muss.

Das verkürzt die Nutzungsdauer aber noch mehr!

Wegen dieser heiligen Kompatibilität? .....

Ich weiß nicht, was ich dir weiter empfehlen kann.

Na ja, ich dachte da irgendwie an Hardware: der der 65C02 war ein 6502, der Z80 war ein 8080, der Apple IIgs war auch ein ][ (und pfiff ein fröhlich Liedchen, wenn er die Amiga sah …), ein 68050 ein 68000, … Sprich: ein neues HTML mit von Anfang an geregelter Infrastruktur, Logik, (da dürfen gerne alle mitspielen, die nicht nur ihr eigenes Ding sehen wollen) … und mit sich nicht mehr tatsächlich verändernden Anforderungen, was den aktuellen Wildwuchs angeht. Also: ein Bruch, bei dem niemand hängen bleibt, aber „es geht um die Kurve“. Ich denke, das würde eine echte Chance sein.

BTW: 68000 und größer. Erinnert mich an einen Werbeaufsteller aus den frühen 16-Bit-Zeiten. Wenn die Leute nicht nach Namen sondern mit Textverständnis geschielt hätten, sie hätten verstanden, daß intel damit den 8086 zur 8-Bit-CPU erklärt hatte …

[Rolf B]

Standards

Rolf

[nix]

Bärte!