Ist Number Formatting mit CSS möglich?

[TS]

Hello,

kann man mittels CSS ohne JavaScript Number Formatting betreiben?

So soll z. B. 1560734 als 1.560.734 dargestellt werden, oder vielleicht sogar 1.560.734,00.

Glück Auf
Tom vom Berg

[Felix Riesterer]

Lieber TS,

CSS-only kann das nicht.

Liebe Grüße

Felix Riesterer

[TS]

Hello lieber Felix,

CSS-only kann das nicht.

Ich habe schon befürchtet, dass sich bei CSS und HTML in dieser Angelegenheit noch nichts geändert hat. Zumindest habe ich nur eine Menge Postings im Web gefunden, die das auch sagten. Die waren aber alle älter. Und die Hoffnung stirbt angeblich doch zuletzt. Einige behaupteten auch, dass diese Formatierung nicht Sache von CSS wäre. Dann wäre es aber eine Grundaufgabe von HTML und passenden Tags und Attributen.

Das bringt mich erneut auf die Frage, an welcher Stelle man dauernölen müsste, damit HTML nebst CSS endlich allgemeinbrauchbar wird.

Glück Auf und Frohe Ostern Tom vom Berg

[Felix Riesterer]

Lieber TS,

Dann wäre es aber eine Grundaufgabe von HTML und passenden Tags und Attributen.

richtig. Etwas in der Art <number>1234567</number>, das dann mit CSS-Eigenschaften verunstaltet werden kann. Aber für so etwas gibt es ja schon sinnvolle Einrichtungen, wie z.B. die locale. Möglicherweise sollte man diese für Darstellungseigenschaften heranziehen.

Das bringt mich erneut auf die Frage, an welcher Stelle man dauernölen müsste, damit HTML nebst CSS endlich allgemeinbrauchbar wird.

Überhaupt nicht! Es ist bereits allgemeinbrauchbar. Deine Ansprüche gehen vielleicht in die falsche Richtung, was allgemeinbrauchbar bedeutet. Wenn Du in einer Webapplikation Zahlen gemäß der locale des Users anzeigen lassen möchtest, dann müsstest Du diese via HTTP-Header ermitteln und Deine Ausgaben entsprechend zusammenstellen. Keine Aufgabe von CSS, sondern von Dir!

Liebe Grüße

Felix Riesterer

[Der Martin]

Hallo Felix,

Dann wäre es aber eine Grundaufgabe von HTML und passenden Tags und Attributen.

richtig. Etwas in der Art <number>1234567</number>, das dann mit CSS-Eigenschaften verunstaltet werden kann. Aber für so etwas gibt es ja schon sinnvolle Einrichtungen, wie z.B. die locale. Möglicherweise sollte man diese für Darstellungseigenschaften heranziehen.

und das ist, soweit ich das erkenne, wieder nur mit Javascript möglich, weil HTML und CSS völlig locale agnostic sind.

In deinem obigen hypothetischen Beispiel müssten dann sämtliche Eigenschaften wie Zifferngruppierung, Dezimalpunkt/Komma und Tausender-Trennezichen als Defaults die Werte haben, die sich aus dem locale ergeben, könnten aber mit CSS überschrieben werden.
Ob das sinnvoll ist. wäre wieder eine andere Frage, denn die Nutzer stellen sich ja nicht einfach zum Spaß ihre locales so ein, wie sie es gewöhnt sind bzw. haben möchten.

Das bringt mich erneut auf die Frage, an welcher Stelle man dauernölen müsste, damit HTML nebst CSS endlich allgemeinbrauchbar wird.

Überhaupt nicht! Es ist bereits allgemeinbrauchbar.

Ja, aber leider nicht "lokalisiert".

Deine Ansprüche gehen vielleicht in die falsche Richtung, was allgemeinbrauchbar bedeutet. Wenn Du in einer Webapplikation Zahlen gemäß der locale des Users anzeigen lassen möchtest, dann müsstest Du diese via HTTP-Header ermitteln und Deine Ausgaben entsprechend zusammenstellen. Keine Aufgabe von CSS, sondern von Dir!

Das sehe ich anders; ich bin da ganz Toms Meinung: Das sollte Aufgabe der Client-Software sein.

Live long and pros healthy,
 Martin

[Felix Riesterer]

Lieber Martin,

Das sollte Aufgabe der Client-Software sein.

und wenn nun die Client-Software in ihren HTTP-Headers mitteilt, welche locale der User haben möchte, erfüllt sie ihre Aufgabe denn dann nicht bereits?

Liebe Grüße

Felix Riesterer

[Der Martin]

Hallo Felix,

Das sollte Aufgabe der Client-Software sein.

und wenn nun die Client-Software in ihren HTTP-Headers mitteilt, welche locale der User haben möchte, erfüllt sie ihre Aufgabe denn dann nicht bereits?

nein, nicht so wie ich mir das vorstelle. Ich finde, TS bringt es ganz gut auf den Punkt: Die Server-Browser-Schnittstelle sollte Daten in einem neutralen Format übermitteln, und der Browser übernimmt die Formatierung derselben in die Darstellung, die auf dem Client-System eingestellt ist. Umgekehrt entsprechend. So ähnlich wie bei der SQL-Schnittstelle.

Nur ist das mit HTML nicht ohne weiteres realisierbar, weil HTML a priori erstmal nur Text überträgt und keine Auszeichnung für Datentypen wie z.B. Zahlen kennt (außer als Typ beim input-Element). Ein time-Element zur Auszeichnung von Datum und/oder Uhrzeit gibt es zwar, es wird aber meines Wissens so gut wie gar nicht benutzt.

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Der Martin

und das ist, soweit ich das erkenne, wieder nur mit Javascript möglich

Hold my beer.

Wichtig dabei dürfte sein, Screenreadern die Zahl ohne Tausendertrennzeichen zu geben; die kommen nur bei visueller Ausgabe. Das heißt getrennte Elemente:

<span class="visually-hidden">121045</span>
<span aria-hidden="true">121.045</span>

(mit den bekannten CSS-Angaben fürs visuelle Verstecken)

Für die Datümer hab ich die Lokalisierung gleich mal mitgemacht.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Der Martin]

Moin,

und das ist, soweit ich das erkenne, wieder nur mit Javascript möglich

Hold my beer.

und inwiefern trägt das nun der Tatsache Rechnung, dass mein locale das Datum im ISO-Format vorsieht, und Zahlen nicht mit einem Punkt, sondern einem \xA0 als Tausender-Trennzeichen? Davon weiß das Intl-Object anscheinend nichts. Andere Anwendungen (Fateimanager, Mailclient, sogar die Konsole) aber schon ...
Aaah, du hast locale fest auf "de" gesetzt. Mal eben auf en_DE geändert ... Okay, das sieht schon besser aus! Jetzt müsste man nur noch das tatsächlich auf dem System verwendete locale abfragen (können).

Aber eben doch nur mit JS.😜

<span class="visually-hidden">121045</span>
<span aria-hidden="true">121.045</span>

(mit den bekannten CSS-Angaben fürs visuelle Verstecken)

Doppelten Content? Und das schlägst ausgerechnet du vor? Ich bin enttäuscht. DRY!

Live long and pros healthy,
 Martin

[Matthias Apsel]

Hallo Der Martin,

<span class="visually-hidden">121045</span>
<span aria-hidden="true">121.045</span>

Doppelten Content? Und das schlägst ausgerechnet du vor? Ich bin enttäuscht. DRY!

Im Quelltext steht ja nur <span class="number">121045</span>. Oder meinst du,

<span class="number">121<span aria-hidden="true">.</span>045</span>

sei sinnvoller?

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Der Martin

und inwiefern trägt das nun der Tatsache Rechnung, dass mein locale das Datum im ISO-Format vorsieht, und Zahlen nicht mit einem Punkt, sondern einem \xA0 als Tausender-Trennzeichen? Davon weiß das Intl-Object anscheinend nichts. […]

Jetzt müsste man nur noch das tatsächlich auf dem System verwendete locale abfragen (können).

Yep. Das wäre in der Tat nützlich. Nicht gleiche Formatierung für alle, sondern jedem Nutzer seine bevorzugte.

Keine Ahnung, wie/ob man mit JavaScript an die Einstellungen des OS rankommt (bzw. die des Browsers, und ob der Browser die vom OS übernimmt).

<span class="visually-hidden">121045</span>
<span aria-hidden="true">121.045</span>

Doppelten Content? Und das schlägst ausgerechnet du vor? Ich bin enttäuscht. DRY!

Ich wiederhole mich nicht. Die Daten sind ja jeweils nur einmal vorhanden:
<td class="number">121045</td>.

Die Verdopplung erfolgt durch eine Automatik. Wie willst du verschiedene Repräsentationen (visiuelle, Screenreader) sonst erreichen, wenn nicht durch Aufarbeitung der Daten, d.h. Verdopplung?

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Der Martin]

Hallo Gunnar,

Jetzt müsste man nur noch das tatsächlich auf dem System verwendete locale abfragen (können).

Yep. Das wäre in der Tat nützlich. Nicht gleiche Formatierung für alle, sondern jedem Nutzer seine bevorzugte.

Keine Ahnung, wie/ob man mit JavaScript an die Einstellungen des OS rankommt (bzw. die des Browsers, und ob der Browser die vom OS übernimmt).

ich habe dazu vorhin schon die Suchmaschine meiner Wahl befragt, aber mit ein paar Minuten Stöbern auch nichts in der Richtung gefunden.

Doppelten Content? Und das schlägst ausgerechnet du vor? Ich bin enttäuscht. DRY!

Ich wiederhole mich nicht. Die Daten sind ja jeweils nur einmal vorhanden:
<td class="number">121045</td>.

Die Verdopplung erfolgt durch eine Automatik.

.. die aber in deinem Beispielscript nicht drin ist? Habe ich jedenfalls nicht gesehen.

Wie willst du verschiedene Repräsentationen (visiuelle, Screenreader) sonst erreichen, wenn nicht durch Aufarbeitung der Daten, d.h. Verdopplung?

Ich frage mich gerade, ob Screenreader Zahlen (auch Datums- und Zeitangaben) nicht automatisch korrekt (localized) vorlesen, wenn sie im lokal üblichen Format notiert sind. Dann wäre die Doppelung gar nicht nötig.
Aber das ist, wie ich kürzlich schon einmal festgestellt habe, nicht meine Baustelle. Muss sie auch nicht. Das sollen die wissen, die es auch umsetzen.

Live long and pros healthy,
 Martin

[Matthias Apsel]

Hallo Der Martin,

Die Verdopplung erfolgt durch eine Automatik.

.. die aber in deinem Beispielscript nicht drin ist? Habe ich jedenfalls nicht gesehen.

for (let element of document.querySelectorAll('.number')) {
	const value = parseFloat(element.textContent);
	if (!Number.isNaN(value)) {
		element.innerHTML = `
			<span class="visually-hidden">${value}</span>
			<span aria-hidden="true">${new Intl.NumberFormat(locale).format(value)}</span>
		`;
	}
}

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Der Martin

Jetzt müsste man nur noch das tatsächlich auf dem System verwendete locale abfragen (können).

Keine Ahnung, wie/ob man mit JavaScript an die Einstellungen des OS rankommt (bzw. die des Browsers, und ob der Browser die vom OS übernimmt).

ich habe dazu vorhin schon die Suchmaschine meiner Wahl befragt, aber mit ein paar Minuten Stöbern auch nichts in der Richtung gefunden.

Beim Rumprobieren bin ich zufällig auf folgendes gestoßen:

Locale	Datum	Zahl
x	2020-04-08	110698
xx	8.4.2020	110.698
xxx	8.4.2020	110.698
xxxx	2020-04-08	110698

Bei ein- und vierbuchstabigen (ungültigen?) Locales wird nicht umformatiert.

Bei zwei- und dreibuchstabigen unbekannten(?) Locales wird deutsch formatiert. Jedenfalls bei mir. Wirkt hier die Locale vom Betriebssystem?

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Der Martin]

Hallo,

Beim Rumprobieren bin ich zufällig auf folgendes gestoßen:

Locale	Datum	Zahl
x	2020-04-08	110698
xx	8.4.2020	110.698
xxx	8.4.2020	110.698
xxxx	2020-04-08	110698

Bei ein- und vierbuchstabigen (ungültigen?) Locales wird nicht umformatiert.

das kann ich bestätigen.

Bei zwei- und dreibuchstabigen unbekannten(?) Locales wird deutsch formatiert.

Das jedoch nicht.

Wirkt hier die Locale vom Betriebssystem?

Nur teilweise. Bei xx und xxx bekomme ich ein britisches Datum (10/04/2020) und Zahlen mit einem Punkt als Tausender-Trennzeichen. Das passt zu en_GB, und das nimmt mein Firefox (bzw. Pale Moon, die sind sich einig) wohl als Default.
Die Systemeinstellung wäre aber en_DE (selbstgebaut) mit 2020-04-10 und einem NBSP als Tausender-Trennzeichen.

Da pupst also noch irgendwas anderes dazwischen.

Live long and pros healthy,
 Martin

[TS]

Hello @Der Martin,
hello @Gunnar Bittersmann,

wenn Ihr beide euch nun schon mal did Zeif nehmt, in did Tiefe zu gucken, dann versucht doch bitte auch, die Rahmenbedingungen herauszufinden.

• welches OS
• welche Distribution
• welche Landeseinstellungen für Sprache und Tastatur
• welche Browserversion
• welche Landeseinstellungen
• •••

Mir fehlt dafür leider die Expertise, aber dann wären Eure Forschungen wirklich Gold wert ;-)

Ich lese Euch jedenfalls sehr interessiert mit.

Beim Rumprobieren bin ich zufällig auf folgendes gestoßen:

Locale	Datum	Zahl
x	2020-04-08	110698
xx	8.4.2020	110.698
xxx	8.4.2020	110.698
xxxx	2020-04-08	110698

Bei ein- und vierbuchstabigen (ungültigen?) Locales wird nicht umformatiert.

das kann ich bestätigen.

Bei zwei- und dreibuchstabigen unbekannten(?) Locales wird deutsch formatiert.

Das jedoch nicht.

Wirkt hier die Locale vom Betriebssystem?

Nur teilweise. Bei xx und xxx bekomme ich ein britisches Datum (10/04/2020) und Zahlen mit einem Punkt als Tausender-Trennzeichen. Das passt zu en_GB, und das nimmt mein Firefox (bzw. Pale Moon, die sind sich einig) wohl als Default.
Die Systemeinstellung wäre aber en_DE (selbstgebaut) mit 2020-04-10 und einem NBSP als Tausender-Trennzeichen.

Da pupst also noch irgendwas anderes dazwischen.

Live long and pros healthy,
 Martin

Glück Auf
Tom vom Berg

[Der Martin]

Hi Gunnar,

Beim Rumprobieren bin ich zufällig auf folgendes gestoßen:

solange du nicht Rum probierst, ist alles gut. :-)

Bei zwei- und dreibuchstabigen unbekannten(?) Locales wird deutsch formatiert. Jedenfalls bei mir. Wirkt hier die Locale vom Betriebssystem?

Zufällig beim Probieren festgestellt: Gib als locale einen Leerstring an, dann wirken die korrekten systemweiten Einstellungen. Zumindest bei mir.

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Bei zwei- und dreibuchstabigen unbekannten(?) Locales wird deutsch formatiert. Jedenfalls bei mir. Wirkt hier die Locale vom Betriebssystem?

Zufällig beim Probieren festgestellt: Gib als locale einen Leerstring an, dann wirken die korrekten systemweiten Einstellungen. Zumindest bei mir.

Bei mir nicht. Jedenfalls nicht auf CodePen; da wird ein Uncaught RangeError: Incorrect locale information provided gemeldet.

Was aber geht: const locale = undefined; (was dem Aufruf von Intl.NumberFormat().format(value) ohne Locale-Parameter entspricht.

Und das hab ich auch in der Spec gefunden: DefaultLocale (): “… locale identifier for the host environment's current locale.” 💯

Vielleicht steht das Verhalten bei grammatikalisch korrekten, aber nicht sinnvollen Locale-Angaben wie xx und xxx da auch irgendwo beschrieben.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Jetzt müsste man nur noch das tatsächlich auf dem System verwendete locale abfragen (können).

Yep. Das wäre in der Tat nützlich. Nicht gleiche Formatierung für alle, sondern jedem Nutzer seine bevorzugte.

Keine Ahnung, wie/ob man mit JavaScript an die Einstellungen des OS rankommt (bzw. die des Browsers, und ob der Browser die vom OS übernimmt).

Jetzt ja.

☞ Abkürzung

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Hold my beer.

Pils, Alt, Weizen, Ale, Kölsch (ist das Bier?), Dunkles, Lager, … – für jeden Geschmack was dabei:

Locale	Darstellung	Anmerkung
de	121.045	entspricht wohl de-DE
de-AT	121 045
de-BE	121.045
de-CH	121’045
de-DE	121.045	wie de
de-LI	121’045	wie de-CH

Das Datumsformat ist bei allen de-*-Locales gleich: 10.4.2020.

Anders bei en-*, da ist das Zahlenformat gleich: 121,045. Aber das Datumsformat unterschiedlich:

Locale	Darstellung	Anmerkung
en	4/8/2020	entspricht wohl en-US
en-AU	08/04/2020
en-CA	2020-04-08	Die Kanadier sind so schlau‽
en-GB	08/04/2020
en-NZ	8/04/2020
en-US	4/8/2020	wie en
en-ZA	2020/04/08

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[TS]

Hello lieber Felix,

Das bringt mich erneut auf die Frage, an welcher Stelle man dauernölen müsste, damit HTML nebst CSS endlich allgemeinbrauchbar wird.

Überhaupt nicht! Es ist bereits allgemeinbrauchbar. Deine Ansprüche gehen vielleicht in die falsche Richtung, was allgemeinbrauchbar bedeutet. Wenn Du in einer Webapplikation Zahlen gemäß der locale des Users anzeigen lassen möchtest, dann müsstest Du diese via HTTP-Header ermitteln und Deine Ausgaben entsprechend zusammenstellen. Keine Aufgabe von CSS, sondern von Dir!

Das sehe ich überhaupt nicht so!

Daten sollten stets in einem international verständlichen und sortierbaren Raw-Format ausgetauscht werden und die Formatierung (Anordnung, Sequenzierung, Gültigkeitsbereiche, ...) durch HTML und die Darstellungsart (Farbe, Form, Größe, Position, ...) durch CSS geregelt werden. Und das sollte mMn sowohl für den Hinweg (Erfassung), als auch für den Rückweg (Ausgabe) einheitlich geregelt sein.

Und für Dialogfelder sollten die Browser automatisch ein Dirty-Flag erzeugen, wenn die entsprechenden Dialogfelder geändert wurden. Damit müsste das Backend (neben anderen Regeln) dann nur noch diese Parameter überprüfen.

Und weil dies im Prinzip so einfach möglich wäre umgesetzt zu werden, verstehe ich nicht, warum es keine ernsthaften Bestrebungen hierfür gibt.

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

Daten sollten stets in einem international verständlichen und sortierbaren Raw-Format ausgetauscht werden

Einverstanden.

Nur - der Browser fordert vom Server keine Daten an. Sondern Dokumente. Und für diese kann er per Header eine Sprache anfordern.

Accept-Language: de-DE

Also eigentlich keine Sprache, sondern ein locale, das auch Formatierungsregeln für Datums- und Zahlentypen beinhaltet.

Von Hypertext-Konzept her liegt der Job damit beim Server. Dass man das Konzept angesichts moderner und leistungsfähiger Browser erweitern könnte, ist eine andere Frage, aber das ist bisher nicht passiert.

Dein Annölziel wäre das W3C. Schreibe einen Draft für das CSS Modul Numeric Formatting Level 1 und reiche ihn ein 😀

Rolf

[TS]

Hello,

H

Dein Annölziel wäre das W3C. Schreibe einen Draft für das CSS Modul Numeric Formatting Level 1 und reiche ihn ein 😀

Wir haben doch inzwischen herausdiskutiert, dass es Aufgabd vom HTML sein müsste. :-)

Aber dafür sind sie wohl auch zuständig, oder?

Den Request sollte man dann aber vorher noch genauer spezifizieren.

Glück Auf
Tom vom Berg

[Auge]

Hallo

Dein Annölziel wäre das W3C. Schreibe einen Draft für das CSS Modul Numeric Formatting Level 1 und reiche ihn ein 😀

Wir haben doch inzwischen herausdiskutiert, dass es Aufgabd vom HTML sein müsste. :-)

Haben wir das? Ich persönlich halte MudGuards Ansatz, die im HTML-Dokument angegebene Sprache des Dokuments zur Formatierung per CSS zu nutzen, für zielführender. Gunnar B. hat hier im Forum schon mehrfach ein Beispiel zur sprachabhängigen Angabe von Anführungszeichen gebracht, dass ich passenderweise nicht wiederfinde. Ich hab's aber schon einmal selbst wo eingebaut. <rumkram /> Na bitte.

Anführungszeichen für die deutsche Sprache:

:lang(de) {
quotes:"\201E" "\201C" "\201A" "\2018";
}

Das ließe sich meiner Meinung nach bestens adaptieren, wenn es denn in CSS passende Eigenschaften gäbe.

Tschö, Auge

[Der Martin]

n'Abend,

Wir haben doch inzwischen herausdiskutiert, dass es Aufgabd vom HTML sein müsste. :-)

Haben wir das?

( ) Ja
( ) Nein
(o) Vielleicht

Ich habe schon den Überblick verloren, wer hier welchen Standpunkt vertritt.

Ich persönlich halte MudGuards Ansatz, die im HTML-Dokument angegebene Sprache des Dokuments zur Formatierung per CSS zu nutzen, für zielführender.

Ja. Und zwar ja mit aber.

Gunnar B. hat hier im Forum schon mehrfach ein Beispiel zur sprachabhängigen Angabe von Anführungszeichen gebracht, dass ich passenderweise nicht wiederfinde. Ich hab's aber schon einmal selbst wo eingebaut. <rumkram /> Na bitte.

Anführungszeichen für die deutsche Sprache:

:lang(de) {
quotes:"\201E" "\201C" "\201A" "\2018";
}

Aber damit "gewinnt" wieder die vom Seitenautor für die jeweilige Sprache präferierte Notation, und nicht die vom Nutzer in seinem locale festgelegte. Wo bleibt da wieder der Wille des Endanwenders? - Genau, auf der Strecke.
Dass die Anführungszeichen jetzt nur ein Platzhalter-Beispiel sind, ist mir klar.

Solche autorseitigen Festlegungen dürften IMO nur greifen, wenn auf dem Client-System für die entsprechende Sprache nichts festgelegt ist.

Live long and pros healthy,
 Martin

[MudGuard]

Hi,

Aber damit "gewinnt" wieder die vom Seitenautor für die jeweilige Sprache präferierte Notation, und nicht die vom Nutzer in seinem locale festgelegte. Wo bleibt da wieder der Wille des Endanwenders?

in seinem user.css

cu,
Andreas a/k/a MudGuard

[Der Martin]

Hallo,

Aber damit "gewinnt" wieder die vom Seitenautor für die jeweilige Sprache präferierte Notation, und nicht die vom Nutzer in seinem locale festgelegte. Wo bleibt da wieder der Wille des Endanwenders?

in seinem user.css

nope. Auch wenn wir hier nur über hypothetische Geschichten diskutieren: Warum sollte ich Dinge, die ich schon systemweit festgelegt habe, in der Konfiguration einzelner Anwendungen (hier: Browser) nochmal wiederholen? Das passt nicht ins DRY-Prinzip.
Applikationen haben sich an systemweite Festlegungen zu halten, auch ohne dass man es jeder einzelnen Applikation extra vorbetet.

Live long and pros healthy,
 Martin

[Auge]

Hallo

Aber damit "gewinnt" wieder die vom Seitenautor für die jeweilige Sprache präferierte Notation, und nicht die vom Nutzer in seinem locale festgelegte. Wo bleibt da wieder der Wille des Endanwenders?

in seinem user.css

nope. Auch wenn wir hier nur über hypothetische Geschichten diskutieren: Warum sollte ich Dinge, die ich schon systemweit festgelegt habe, in der Konfiguration einzelner Anwendungen (hier: Browser) nochmal wiederholen? Das passt nicht ins DRY-Prinzip.
Applikationen haben sich an systemweite Festlegungen zu halten, auch ohne dass man es jeder einzelnen Applikation extra vorbetet.

Wer bitte ändert sein Browserstylesheet oder legt sich ein explizites user.css? Es wäre aber überhaupt kein Problem, den Browser diese Angabe vom System übernehmen, quasi erben zu lassen.

Tschö, Auge

[Auge]

Hallo

Anführungszeichen für die deutsche Sprache:

:lang(de) {
quotes:"\201E" "\201C" "\201A" "\2018";
}

Aber damit "gewinnt" wieder die vom Seitenautor für die jeweilige Sprache präferierte Notation, und nicht die vom Nutzer in seinem locale festgelegte. Wo bleibt da wieder der Wille des Endanwenders? - Genau, auf der Strecke.

Ich weiß nicht, ob das überhaupt ein Problem ist. Ich gehe davon aus, dass der Browser (vielleicht durch vom System geerbte Regeln) entscheidet, welche Darstellung gewählt wird und nicht der Seitenautor händisch festlegt, wie die Zahlen dargestellt werden. Und selbst wenn das so wäre, na und?

Entscheidend ist hier meiner Meinung nach nicht die Präferenz des Seitenbesuchers, sondern die Sprache des Dokuments. Wenn die Sprache deutsch ist (eventuell mit zusätzlicher Angabe des Landes), dann soll die Formatierung der Zahlen auch den Regeln der deutschen Sprache (eventuell mit zusätzlicher Angabe des Landes) folgen.

Solche autorseitigen Festlegungen dürften IMO nur greifen, wenn auf dem Client-System für die entsprechende Sprache nichts festgelegt ist.

Das dürfte in vielen Fällen der Fall sein.

Tschö, Auge

[TS]

Hello Auge,

Dein Annölziel wäre das W3C. Schreibe einen Draft für das CSS Modul Numeric Formatting Level 1 und reiche ihn ein 😀

Wir haben doch inzwischen herausdiskutiert, dass es Aufgabd vom HTML sein müsste. :-)

Haben wir das? Ich persönlich halte MudGuards Ansatz, die im HTML-Dokument angegebene Sprache des Dokuments zur Formatierung per CSS zu nutzen, für zielführender. Gunnar B. hat hier im Forum schon mehrfach ein Beispiel zur sprachabhängigen Angabe von Anführungszeichen gebracht, dass ich passenderweise nicht wiederfinde. Ich hab's aber schon einmal selbst wo eingebaut. <rumkram /> Na bitte.

Anführungszeichen für die deutsche Sprache:

:lang(de) {
quotes:"\201E" "\201C" "\201A" "\2018";
}

Das ließe sich meiner Meinung nach bestens adaptieren, wenn es denn in CSS passende Eigenschaften gäbe.

Sollte CSS wirklich für die Datenstrukturierung zuständig sein? Das sollte doch nach meinem Verständnis HTML tun. CSS kann dan den Aspekt bestimmen, also, ob der Tausenderpunkt rund oder eckig, rot oder grün dargestellt wird. Und wie groß die Zahlen erscheinen.

Nach meinem Verständnis sollte der Server die Daten weitestgehend im Rawformat liefern, HTML zeichnet sie aus und strukturiert sie, und CSS übernimmt Form und Farbe.

Ob jetzt bereits in der HTML-Schicht mittels Attributen und lokalen Spracheinstellungen entschieden werden sollte, ob es ein Punkt, ein Komma oder ein halbes Leerzeichen sein muss, oder ob CSS did endgültige Darstellung entscheidet, darüber bin ich mif noch nicht ganz im Klaren.

Zumindest sollten die Metainformationen (Attribute) auch schon in der reinen HTML-Darstellung, also ohne CSS, zur Verfügung stehen und der Browser sie berücksichtigen.

Glück Auf
Tom vom Berg

[Gunnar Bittersmann]

@@Auge

Gunnar B. hat hier im Forum schon mehrfach ein Beispiel zur sprachabhängigen Angabe von Anführungszeichen gebracht, dass ich passenderweise nicht wiederfinde. Ich hab's aber schon einmal selbst wo eingebaut.

Seit einiger Zeit schon muss man das nicht mehr selbst einbauen. Die Browser haben das bereits in ihren Browserstylesheets. WebKits und Chromia unterscheiden sogar zwischen Deutschland/Österreich einerseits und der Schweiz andererseits. Traumhaft

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Traumhaft

En français de France, les guillemets sont comptés comme des ponctuations hautes, et en tant que telles appellent l’usage d’espaces insécables après le guillemet ouvrant et avant le guillemet fermant.

Der Edge (unten) macht es richtig, Firefox nicht.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Der Edge (unten) macht es richtig

Von welchem Edge sprichst du? EdgeHTML-Edge oder Chromium-Edge?

Edge auf macOS macht es genauso wie alle anderen falsch.

Edge auf macOS setzt auch genauso wie Chrome fürs Niederländische “” (Default?) anstatt „”.
Firefox setzt ‘’.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Von welchem Edge sprichst du? EdgeHTML-Edge oder Chromium-Edge?

EdgeHTML 18.18363

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Eine weitere Stelle, wo EdgeHTML besser war als Chromium, und es die Edge-Entwickler (noch) nicht geschafft haben, das in Chromium rüberzuretten.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[Gunnar Bittersmann]

@@Rolf B

Dein Annölziel wäre das W3C.

„Annölziel“! 🤣

Schreibe einen Draft für das CSS Modul Numeric Formatting Level 1 und reiche ihn ein 😀

AFAIS war das mal im Gespräch. Da der Link http://wiki.csswg.org/ideas/content-formatting nicht mehr funktioniert, werden wir wohl nie erfahren, wie die Diskussion ausgegangen ist.

🖖 Stay hard! Stay hungry! Stay alive! Stay home!

[MudGuard]

Hi,

Wenn Du in einer Webapplikation Zahlen gemäß der locale des Users anzeigen lassen möchtest, dann müsstest Du diese via HTTP-Header ermitteln

wäre die locale des Users überhaupt das richtige? Müßte sich das nicht eher nach der Sprache des Inhalts richten?

Sprich: bei lang="de" für's betroffene Element wird für Pi 3,14159… angezeigt, bei lang="en" dann 3.14159…

cu,
Andreas a/k/a MudGuard

[Der Martin]

Hallo,

Wenn Du in einer Webapplikation Zahlen gemäß der locale des Users anzeigen lassen möchtest, dann müsstest Du diese via HTTP-Header ermitteln

wäre die locale des Users überhaupt das richtige? Müßte sich das nicht eher nach der Sprache des Inhalts richten?

das wäre auch ein Aspekt, über den man nachdenken könnte.

Sprich: bei lang="de" für's betroffene Element wird für Pi 3,14159… angezeigt, bei lang="en" dann 3.14159…

Für "normale" Leute bestimmt vernünftig. Für Deppen wie mich dagegen, die auch im Deutschen einen Dezimalpunkt und ein Blank als Tausender-Trennzeichen haben wollen, und das Datum generell im ISO-Format, und die sich deshalb extra ihre eigene locale en_DE.UTF-8 basteln ... 😎

Live long and pros healthy,
 Martin