nicht angemeldet
Gunnar Bittersmann
suit
Gunnar Bittersmann
suit
suit
Gunnar Bittersmann
suit
Hallo Forum,
ich möchte die Telefonnummern im XHTML-Content so formatieren, dass sie von Smartphones als solche automatisch erkannt werden. Funktionerende Formate für mein iPhone herauszufinden war relativ leicht, denn welche Formate richtig erkannt werden kann ich mit der Hardware selbst und mit dem iPhone-Simulator auf meinem Entwicklungssystem einfach ausprobieren. Mit Android-Geräten wird's schwieriger, denn ich habe keine Hardware, sondern nur den Emulator unter Eclipse und dort wird erstmal keine der unterschiedlich formatierten Telefonnummern erkannt.
Dafür kann ich mir mehrere Ursachen vorstellen:
1. Die automatische Telefonnummernerkennung ist eine Einstellung im OS oder im Browser, die im Emulator per default deaktiviert ist - Das kann ich mir eigentlich nicht vorstellen, denn ein Emulator soll ja möglichst nah an der Realität sein.
2. Es gibt gar keine automatische Telefonnummernerkennung unter Android und man muss tatsächlich den Quelltext anpassen (<a href="tel:) - Auch das kann ich mir eigentlich nicht vorstellen, weil ich selbst diese Funktionalität ganz nützlich finde.
Hat sich mal jemand mit der Materie befasst und kann mir sagen, was zu tun ist und wie ich testen kann?
danke für Tipps und
beste gruesse,
heinetz
@@heinetz:
nuqneH
ich möchte die Telefonnummern im XHTML-Content so formatieren […]
man muss tatsächlich den Quelltext anpassen (<a href="tel:)
Was spräche denn aus deiner Sicht gegen die standardisierte Auszeichnung?
Qapla'
@@heinetz:
nuqneH
ich möchte die Telefonnummern im XHTML-Content so formatieren […]
man muss tatsächlich den Quelltext anpassen (<a href="tel:)Was spräche denn aus deiner Sicht gegen die standardisierte Auszeichnung?
Es spricht nichts dagegen und alles dafür. Es bedeutet aber in meinem Fall eine andere Aufgabenstellung:
Es geht hier um ca. 900 bestehende Unterseiten, auf denen sich potentiell Telefunnummern befinden und die durch ca. 20 Redakteure mittels CMS editiert werden. Diese Inhalte werden dann in der Desktop- und der mobilen Version angezeigt.
gruss,
heinetz
Hai
Es geht hier um ca. 900 bestehende Unterseiten, auf denen sich potentiell Telefunnummern befinden und die durch ca. 20 Redakteure mittels CMS editiert werden. Diese Inhalte werden dann in der Desktop- und der mobilen Version angezeigt.
Cron job der die datenbank regelmässig nach telefonnummern grept und entsprechend ändert wenns kein <a href="tel:"> gibt?
/entropie
Hai
Es geht hier um ca. 900 bestehende Unterseiten, auf denen sich potentiell Telefunnummern befinden und die durch ca. 20 Redakteure mittels CMS editiert werden. Diese Inhalte werden dann in der Desktop- und der mobilen Version angezeigt.
Cron job der die datenbank regelmässig nach telefonnummern grept und entsprechend ändert wenns kein <a href="tel:"> gibt?
/entropie
Ja, da gibt's sicher mehrere Überlegungen und entsprechend Ansätze. Was ich schwierig finde, ist die Tatsäche, dass der Content durch die Redakteure mit einem WYSIWYG-Editor gepflegt wird. Und zwar der selbe Content, der gleichermassen für Desktop- und mobile Version der Site verwendet wird. Es müsste also bewusst, eine Telefonnummer zum Link gemacht werden, damit der gewünschte Effekt auf dem Smartphone eintritt. Dieser Link führte allerdings im Desktop-Browser zu einem Fehler.
Man müsste also einen Automatismus bauen, der aus einem als Telefonnummer identifizierten String beim Aufruf je nach Client (mobil oder Desktop) entweder einen Link macht, oder nicht.
Und die standartisierte Auszeichnung zur Laufzeit durch einen Automatismus vorzunehmen, würde ich lieber den Browser machen lassen, als es händisch zu bauen.
gruss,
heinetz
@@heinetz:
nuqneH
Dieser Link [
<a href="tel:…">] führte allerdings im Desktop-Browser zu einem Fehler.
Von was für einem Fehler sprichst du?
Auch bei Desktop-Geräten sind 'tel'-Links sinnvoll; per Click könnte man das (DSL-)Modem die Telefonnummer wählen lassen und den Hörer erst abnehmen, wenn die Verbindung steht.
Es liegt an dir, 'tel'-Links und 'href'-Links unterschiedlich zu stylen.
Qapla'
@@heinetz:
nuqneH
Dieser Link [
<a href="tel:…">] führte allerdings im Desktop-Browser zu einem Fehler.Von was für einem Fehler sprichst du?
Auch bei Desktop-Geräten sind 'tel'-Links sinnvoll; per Click könnte man das (DSL-)Modem die Telefonnummer wählen lassen und den Hörer erst abnehmen, wenn die Verbindung steht.
Ich hatte tatsächlich nur gelesen, dass der Link zu einem Fehler führt und konnte mir auch nichts anderes sinnvolles vorstellen. Schande auf mein Haupt aber für sinnvoll halte ich es tatsächlich nicht, denn ich kann mir nicht vorstellen, dass der gemeine Surfer, mit seinem Desktoprechner irgendwen anrufen möchte. Selbst ich guck erstmal nur blöd, wenn der Klick auf den Link unter OS X Safari den Microsoft Communicator startet und schliesse die Applikation schnell wieder.
Es liegt an dir, 'tel'-Links und 'href'-Links unterschiedlich zu stylen.
Sicher, woran denkst Du dabei?
Qapla'
Hallo,
Es liegt an dir, 'tel'-Links und 'href'-Links unterschiedlich zu stylen.
Sicher, woran denkst Du dabei?
Ich könnt mir jetzt zB nen Telefonhörer-Smbol vorm Link vorstellen (ähnlich wie das oft den Pfeilen bei externen Verweisen gemacht wird/wurde)
martachen
مرحبا
Es liegt an dir, 'tel'-Links und 'href'-Links unterschiedlich zu stylen.
Sicher, woran denkst Du dabei?
mfg
@@Gunnar Bittersmann:
nuqneH
Es liegt an dir, 'tel'-Links und 'href'-Links unterschiedlich zu stylen.
'tel'-Links und 'http…'-Links, grmpf.
Qapla'
مرحبا
Es geht hier um ca. 900 bestehende Unterseiten, auf denen sich potentiell Telefunnummern befinden und die durch ca. 20 Redakteure mittels CMS editiert werden.
Wenn du die Nummern an einer stelle zentral speicherst, könntest du zumindest eine Fehlerseite ausgeben, wenn jemand eine Tel-Nummer klickt, die dann im Browser zu einer fehlerseite führt. Oder verstehe ich hier das Problem grundlegend falsch?
mfg
@@heinetz:
nuqneH
ich möchte die Telefonnummern im XHTML-Content so formatieren […]
man muss tatsächlich den Quelltext anpassen (<a href="tel:)Was spräche denn aus deiner Sicht gegen die standardisierte Auszeichnung?
Vorweg: ich Zeichne sämtliche Telefonnummern nach RFC 3986 aus - funktioniert einwandfrei, dauert aber meistens nicht lange bis der Kunde über kaputte Links "Unbekannter oder nicht unterstützter Adressentyp." jammert oder sich beklagt, dass die Telefonnummer nicht in der in Österreich übliche Klammer-Schreibweise steht.
Daraufhin fängt man das Mobiltelefon der Wahl raus, surft einen Mitbeweber an der das nicht hat und fingert die Telefonnumer an - die Nummer erscheint im Display und eine 0 zu viel steht drin und man kann die Nummer nicht wählen.
Dass man mit dem Desktop-Browser nicht telefonieren kann, ist dann schnell vergessen.
Die einzige alternative wäre das proprietäre Schema "callto:" zu verwenden, damit die Links z.B. an Skype durchgereicht werden - aber warum sollte man das tun? Soll Skype das Problem lösen und lieber mal das tel-Schema registrieren.
@@suit:
nuqneH
Vorweg: ich Zeichne sämtliche Telefonnummern nach RFC 3986 aus
Und dabei verwendest du die Schreibweise "tel:+498932168"?
oder sich beklagt, dass die Telefonnummer nicht in der in Österreich übliche Klammer-Schreibweise steht.
In den Elementinhalt des a-Elements kannst du doch schreiben, was du willst. <a href="tel:+498932168">(089) 32 16 8</a>
die Nummer erscheint im Display und eine 0 zu viel steht drin und man kann die Nummer nicht wählen.
??
Qapla'
Und dabei verwendest du die Schreibweise
"tel:+498932168"?
Ich verwende die E.123-Notation mit Bindestrichen statt den Leerzeichen, das ist ebenfalls mit RFC 3986 zu vereinbaren und wird dort sogar so als Beispiel verwandt
oder sich beklagt, dass die Telefonnummer nicht in der in Österreich übliche Klammer-Schreibweise steht.
In den Elementinhalt des a-Elements kannst du doch schreiben, was du willst.
<a href="tel:+498932168">(089) 32 16 8</a>
Das ist richtig, davon sprach ich nicht.
die Nummer erscheint im Display und eine 0 zu viel steht drin und man kann die Nummer nicht wählen.
??
Wenn du die Nummer _nicht_ verlinkst und z.B. schreibst +43 (0) 123 / 45 67 89 wird die Telefonnummer ohne Verlinkung als +430123456789 erkannt (zumindest von allen iOS-Geräten unterschiedlichster Evolutionsstufen) - da ist dann eine Null zu viel.
Jetzt gibts also 2 Kunden:
Lösung: <a href="tel:+43-123-456789">+43 (0) 123 / 45 67 89</a>
Lösung: +43-123-456789
Wobei Lösung #2 den Nachteil hat, dass sie auf vielen ordentlichen Browsern nicht funktioniert, weil ein kein Link einfach kein Link ist
Allerdings hat Lösung #2 den signifikaten Vorteil, dass man z.B. Fax-Nummern nicht klicken/anrufen kann, was unter iOS kein Problem ist.
Die Empfehlung an meine Kunden ist daher idR. folgendes um deren Kontaktinformationen auszuzeichnen (#1 für Telefonnummern und #2 für Fax-Nummern):
Der Martin <div class="tel">
<span class="type">Tel</span>.:
<a class="value" href="tel:+43-123-456789">+43-123-456789</a>
</div>
<div class="tel">
<span class="type">Fax</span>:
<span class="value">+43-123-456789-99</span>
</div>
Im Fließtext selbst kann man die dann ebenfalls problemlos verlinken, sofern man TYPO3 geringfügig patcht, da das tel:-Schema nicht enthalten ist und der default-Handler aktiviert wird, und ein unsinniges http:// davorstellt.
localconf.php wird hierfür mit dieser Zeile ergänzt:
$TYPO3_CONF_VARS['SC_OPTIONS']['tslib/class.tslib_content.php']['typolinkLinkHandler']['tel'] = '';
Das ersetzt den Linkhandler durch "nichts" und die Eingabe geht leer (allerdings ohne Validierung) durch - ist ein schneller dreckiger fix, die deluxe-Variante wäre noch ein Syntax-Check :)
Damit deckt die meisten relevanten Anwendungsfälle ab - mit Ausnahme von Skype, aber da soll Microsoft wie gesagt lieber mal anstatt callto: das Standardkonforme tel:-Schema registrieren. Im MSDN gäb' es da sogar einen Artikel dazu.
Hi!
Wenn du die Nummer _nicht_ verlinkst und z.B. schreibst +43 (0) 123 / 45 67 89 wird die Telefonnummer ohne Verlinkung als +430123456789 erkannt (zumindest von allen iOS-Geräten unterschiedlichster Evolutionsstufen) - da ist dann eine Null zu viel.
Jetzt gibts also 2 Kunden:
- ich will, dass die Nummer gut aussieht - auch wenn ich irgendwelche absurden oder antiken nicht-(mehr-)?Normen erfülle
Lösung:
<a href="tel:+43-123-456789">+43 (0) 123 / 45 67 89</a>
- ich will, dass beim Klicken der Nummer auf einem Desktop-Gerät kein "Weiß nicht, wie er mit diesem Protokoll umgehen soll"-Verweis kommt
Lösung:
+43-123-456789Wobei Lösung #2 den Nachteil hat, dass sie auf vielen ordentlichen Browsern nicht funktioniert, weil ein kein Link einfach kein Link ist
Allerdings hat Lösung #2 den signifikaten Vorteil, dass man z.B. Fax-Nummern nicht klicken/anrufen kann, was unter iOS kein Problem ist.
Die Empfehlung an meine Kunden ist daher idR. folgendes um deren Kontaktinformationen auszuzeichnen (#1 für Telefonnummern und #2 für Fax-Nummern):
<div class="tel">
<span class="type">Tel</span>.:
<a class="value" href="tel:+43-123-456789">+43-123-456789</a>
</div>
<div class="tel">
<span class="type">Fax</span>:
<span class="value">+43-123-456789-99</span>
</div>
>
Hmmm ..., damit hast du aber in Desktop-Browsern ja genau das Problem, welches du 2) vermeiden wolltest.
Ich sehe die "Lösung" eher in "UA Sniffing", um zwischen Mobile und Desktop zu differenzieren und die Links entsprechend zu generieren, bzw. zu de-/aktivieren.
Gruß Gunther
Hmmm ..., damit hast du aber in Desktop-Browsern ja genau das Problem, welches du 2) vermeiden wolltest.
Das ist aber das geringere übel und man kann es dem Kunden schlüssig erklären indem man einfach Kurz das Telefon rausfängt :)
Ich sehe die "Lösung" eher in "UA Sniffing", um zwischen Mobile und Desktop zu differenzieren und die Links entsprechend zu generieren, bzw. zu de-/aktivieren.
"Mobile" und "Desktop" zu unterscheiden ist absoluter Unsinn - ist ein Netbook jetzt ein Desktop- oder ein Mobilgerät? Ist ein Surface-Tablet jetzt ein Notebook oder ein Tablet? Ist es Mobil oder nicht? Kann man damit telefonieren oder nicht?
Die einzig halbwegs vernünftige Lösung ist zu prüfen, ob ein bestimmtes Protokoll registriert ist oder nicht - im Internet Explorer ist das sehr unzuverlässig über die protocolLong-Eigenschaft möglich - allerdings lieft das stellenweise auch für nicht registrierte aber bekannte Protokolle ein Ergebnis, z.B. wenn das Schema registriert und wieder entfernt wurde, kennt er dessen langen Namen aber es gibt keine Zuordnung mehr zu einer Anwendung.
Unter Firefox kann man das recht einfach prüfen: man erstellt ein iframe-Element mit src und dem zu testenden Schema und wertet dessen Namen aus (try/catch) - wenn dieser "NS_ERROR_UNKNOWN_PROTOCOL" ist, zeigt Firefox grade die "Firefox weiß nicht, wie diese Adresse geöffnet werden soll [...]"-Seite an - das funktioniert recht zuverlässig.
Für Opera und Safari wird das wohl ähnlich funktionieren, die zeigen beide ebenfalls eine Fehlerseite die sich ggf. auswerten lässt - hab' ich grade nicht getestet.
Chrome selbst tut hingegen nichts, der ignoriert den Request einfach - bei Eingabe direkt in die Adresszeile wird eine Google-Suche ausgeführt.
Die Lösung kann also so aussehen:
Es gibt Links mit dem tel-Schema die durch JavaScript nachträglich wieder entfernt werden, wenn das tel-Schema _explizit_ nicht registriert ist - in anderen Fällen "ist registriert", "weiß nicht", "kann nicht ermittelt werden" oder "nicht sicher" bleiben sie stehen und führen ggf. zu Fehlerseiten.
Hi!
Hmmm ..., damit hast du aber in Desktop-Browsern ja genau das Problem, welches du 2) vermeiden wolltest.
Das ist aber das geringere übel und man kann es dem Kunden schlüssig erklären indem man einfach Kurz das Telefon rausfängt :)
Ich sehe die "Lösung" eher in "UA Sniffing", um zwischen Mobile und Desktop zu differenzieren und die Links entsprechend zu generieren, bzw. zu de-/aktivieren.
"Mobile" und "Desktop" zu unterscheiden ist absoluter Unsinn -
So würde ich das nicht sehen - ich habe es nur nicht präzise genug formuliert ...
ist ein Netbook jetzt ein Desktop- oder ein Mobilgerät? Ist ein Surface-Tablet jetzt ein Notebook oder ein Tablet? Ist es Mobil oder nicht? Kann man damit telefonieren oder nicht?
... denn letzteres gilt es zu prüfen, was serverseitig durchaus in gewissen Grenzen möglich ist.
Die einzig halbwegs vernünftige Lösung ist
Nein! Denn grundsätzlich steht man hier wieder vor der generellen Frage:
"Progressive Enhancement vs. Graceful Degredation"
Die Lösung kann also so aussehen:
Es gibt Links mit dem tel-Schema die durch JavaScript nachträglich wieder entfernt werden, wenn das tel-Schema _explizit_ nicht registriert ist - in anderen Fällen "ist registriert", "weiß nicht", "kann nicht ermittelt werden" oder "nicht sicher" bleiben sie stehen und führen ggf. zu Fehlerseiten.
Das wäre dann eine (der möglichen) Lösung(en) für graceful Degredation ...!
Übrigens gibt es einen weiteren der "berüchtigten" Meta-Tags, der sowohl unter Android, als auch iOS die automatische Erkennung von Telefonnummern deaktiviert:
<meta name="format-detection" content="telephone=no" />
Ich sag' es ja immer wieder: Vieles wäre wesentlich einfacher, wenn die schei.. Browser gewisse Infos per (X)-HTTP-Header liefern würden ...!
Gruß Gunther
"Mobile" und "Desktop" zu unterscheiden ist absoluter Unsinn -
So würde ich das nicht sehen - ich habe es nur nicht präzise genug formuliert ...
Schlechte Ausrede :)
ist ein Netbook jetzt ein Desktop- oder ein Mobilgerät? Ist ein Surface-Tablet jetzt ein Notebook oder ein Tablet? Ist es Mobil oder nicht? Kann man damit telefonieren oder nicht?
... denn letzteres gilt es zu prüfen, was serverseitig durchaus in gewissen Grenzen möglich ist.
Die Grenzen sind etwa so wie die Staatsgrenzen zwischen Italien und Österreich, die seit 1919 (Vertrag von Saint-Germain) nach der Wasserscheide der Gletscher bestimmt werden - da kanns schon mal sein, dass du im Frühling auf eine italienische Hütte gehst und im Sommer aus einer österreichischen rauskommst ohne das Gebäude je verlassen zu haben :p
Die einzig halbwegs vernünftige Lösung ist
Nein! Denn grundsätzlich steht man hier wieder vor der generellen Frage:
"Progressive Enhancement vs. Graceful Degredation"
Das ist eine Akademische Frage - ob man die Links nun erst später hinzufügt oder nachträglich entfert hat nichts damit zu tun ob wie man erkennt, ob ein Client dieses Feature potentiell unterstützt.
Die Lösung kann also so aussehen:
Es gibt Links mit dem tel-Schema die durch JavaScript nachträglich wieder entfernt werden, wenn das tel-Schema _explizit_ nicht registriert ist - in anderen Fällen "ist registriert", "weiß nicht", "kann nicht ermittelt werden" oder "nicht sicher" bleiben sie stehen und führen ggf. zu Fehlerseiten.
Das wäre dann eine (der möglichen) Lösung(en) für graceful Degredation ...!
Wenn man progressive enhancement nimmt, wirds halt nachträglich hinzugefügt - wo ist das Problem?
Übrigens gibt es einen weiteren der "berüchtigten" Meta-Tags, der sowohl unter Android, als auch iOS die automatische Erkennung von Telefonnummern deaktiviert:
<meta name="format-detection" content="telephone=no" />
Das ist nicht richtig - format-detection ist ein Webkit-Feature welches die Erkennung in _bestimmten_ Webkit-Browsern unterdrückt, damit schließst du schon mal potentiell Opera Mini aus, ältere Opera-Mobile-Versionen und Firefox ohnehin.
Ich sag' es ja immer wieder: Vieles wäre wesentlich einfacher, wenn die schei.. Browser gewisse Infos per (X)-HTTP-Header liefern würden ...!
Was haben derartige Informationen im HTTP-Header verloren? Solche Informationen müssen nachträglich per API abgerufen werden können, wenn man sie tatsächlich benötigt aber nicht schon pauschal per HTTP zumal ja nichtmal gewährleistet ist, dass ein Dokument überhaupt per HTTP übertragen wird.
"Mobile" und "Desktop" zu unterscheiden ist absoluter Unsinn -
So würde ich das nicht sehen - ich habe es nur nicht präzise genug formuliert ...
Schlechte Ausrede :)
Find' ich nicht ...! ;-)
Denn wenn du Javascript mal außen vor lässt, gibt es de facto keine Möglichkeit festzustellen, ob der jeweilige User gerade ein Gerät verwendet, welches in der Lage ist, eine Telefonverbindung (aus dem Link) aufzubauen, oder nicht - Punkt!
Einzig kann man "versuchen", serverseitig das entsprechende Gerät (Modell) zu identifizieren und daraus dann den Rückschluss ziehen.
ist ein Netbook jetzt ein Desktop- oder ein Mobilgerät? Ist ein Surface-Tablet jetzt ein Notebook oder ein Tablet? Ist es Mobil oder nicht? Kann man damit telefonieren oder nicht?
... denn letzteres gilt es zu prüfen, was serverseitig durchaus in gewissen Grenzen möglich ist.
Die Grenzen sind etwa so wie die Staatsgrenzen zwischen Italien und Österreich, die seit 1919 (Vertrag von Saint-Germain) nach der Wasserscheide der Gletscher bestimmt werden - da kanns schon mal sein, dass du im Frühling auf eine italienische Hütte gehst und im Sommer aus einer österreichischen rauskommst ohne das Gebäude je verlassen zu haben :p
Danke für den Geschichtsunterricht - allerdings verstehe ich den Zusammenhang nicht.
Die einzig halbwegs vernünftige Lösung ist
Nein! Denn grundsätzlich steht man hier wieder vor der generellen Frage:
"Progressive Enhancement vs. Graceful Degredation"Das ist eine Akademische Frage - ob man die Links nun erst später hinzufügt oder nachträglich entfert hat nichts damit zu tun ob wie man erkennt, ob ein Client dieses Feature potentiell unterstützt.
Auch das sehe ich etwas anders ... ;-)
Für mich hat das eher etwas mit "Usability" 8im weiteren Sinn) zu tun, als "nur" eine akademische Frage zu sein. Und wenn überhaupt, dann ist es noch eine Frage, welcher Philosophie man sich eher anschließt.
Die Lösung kann also so aussehen:
Es gibt Links mit dem tel-Schema die durch JavaScript nachträglich wieder entfernt werden, wenn das tel-Schema _explizit_ nicht registriert ist - in anderen Fällen "ist registriert", "weiß nicht", "kann nicht ermittelt werden" oder "nicht sicher" bleiben sie stehen und führen ggf. zu Fehlerseiten.
Das wäre dann eine (der möglichen) Lösung(en) für graceful Degredation ...!
Wenn man progressive enhancement nimmt, wirds halt nachträglich hinzugefügt - wo ist das Problem?
Kein JS ...! :-P
Übrigens gibt es einen weiteren der "berüchtigten" Meta-Tags, der sowohl unter Android, als auch iOS die automatische Erkennung von Telefonnummern deaktiviert:
<meta name="format-detection" content="telephone=no" />Das ist nicht richtig - format-detection ist ein Webkit-Feature welches die Erkennung in _bestimmten_ Webkit-Browsern unterdrückt, damit schließst du schon mal potentiell Opera Mini aus, ältere Opera-Mobile-Versionen und Firefox ohnehin.
Gut, dann formuliere ich es anders: Damit verhindert man die automatische Erkennung von (evt.) Telefonnummern unter iOS im Mobile Safari.
BTW: AFAIK gibt es dieses Feature eh in keinem Android Browser.
Ich sag' es ja immer wieder: Vieles wäre wesentlich einfacher, wenn die schei.. Browser gewisse Infos per (X)-HTTP-Header liefern würden ...!
Was haben derartige Informationen im HTTP-Header verloren? Solche Informationen müssen nachträglich per API abgerufen werden können,
Was für eine API?
wenn man sie tatsächlich benötigt aber nicht schon pauschal per HTTP zumal ja nichtmal gewährleistet ist, dass ein Dokument überhaupt per HTTP übertragen wird.
Deine "Spezialfälle" sind mir ehrlich gesagt wurscht! Meine Webseiten werden immer per HTTP übertragen.
Und ich finde das bisherige Konzept, jedem erstmal pauschal "Alles" auszuliefern, damit sich dann der jeweilige Client das raussuchen kann, womit er auch etwas anfangen kann, ist langsam aber sicher "überholt", bzw. verursacht viel zuviel unnötigen Traffic.
Wenn der anfragende Browser dem Server bereits mitteilen würde, welche "Features" er denn beherrscht, dann könnte dieser ihm auch nur das ausliefern, was gebraucht wird. Insofern sehe ich da durchaus einige Vorteile, welche solche Infos im Header enthalten wären.
Deine Javascript Basteleien sind imho nur "Krücken", um ein Problem an einer Stelle zu lösen, die dafür denkbar ungeeignet ist - immer vorausgesetzt JS ist überhaupt verfügbar.
Die Telefonnummern sind ja nur ein kleiner Teil (SMS, Kontakte etc.) ...!
Und dann gibt es auch Geräte, die zwar durchaus Daten und SMS beherrschen, aber keine Telefonverbindungen.
Gruß Gunther
Hallo,
Ich sag' es ja immer wieder: Vieles wäre wesentlich einfacher, wenn die schei.. Browser gewisse Infos per (X)-HTTP-Header liefern würden ...!
das tun sie doch - sie liefern genau die Informationen, die auf HTTP-Ebene notwendig oder sinnvoll sind, etwa Accept-Language oder Accept-Encoding. Informationen, die eigentlich eine wesentlich höher angesiedelte Protokoll-Ebene betreffen, haben da IMO nichts verloren.
Was haben derartige Informationen im HTTP-Header verloren? Solche Informationen müssen nachträglich per API abgerufen werden können,
Was für eine API?
Eine, die für den jeweiligen Zweck geschaffen wird/wurde. Beispielsweise Media Queries in CSS. Damit will ich nicht sagen, dass das Thema der Telefonnummern bereits auf dieser Ebene gelöst werden könnte - aber sollte.
Und ich finde das bisherige Konzept, jedem erstmal pauschal "Alles" auszuliefern, damit sich dann der jeweilige Client das raussuchen kann, womit er auch etwas anfangen kann, ist langsam aber sicher "überholt", bzw. verursacht viel zuviel unnötigen Traffic.
Solange sich das "mehr" an Traffic im Bereich von wenigen hundert Bytes oder ein paar kB bewegt, finde ich das durchaus noch in Ordnung.
Die Telefonnummern sind ja nur ein kleiner Teil (SMS, Kontakte etc.) ...!
Ja, aber all das spielt sich auf einer wesentlich höheren Protokollebene ab als HTTP.
Ciao,
Martin
Hallo,
Ich sag' es ja immer wieder: Vieles wäre wesentlich einfacher, wenn die schei.. Browser gewisse Infos per (X)-HTTP-Header liefern würden ...!
das tun sie doch - sie liefern genau die Informationen, die auf HTTP-Ebene notwendig oder sinnvoll sind, etwa Accept-Language oder Accept-Encoding. Informationen, die eigentlich eine wesentlich höher angesiedelte Protokoll-Ebene betreffen, haben da IMO nichts verloren.
Was haben derartige Informationen im HTTP-Header verloren? Solche Informationen müssen nachträglich per API abgerufen werden können,
Was für eine API?Eine, die für den jeweiligen Zweck geschaffen wird/wurde. Beispielsweise Media Queries in CSS. Damit will ich nicht sagen, dass das Thema der Telefonnummern bereits auf dieser Ebene gelöst werden könnte - aber sollte.
Die primäre Frage ist doch, *wo* will ich diese Informationen haben, bzw. wo nützen sie mir für welche Zwecke etwas! Und hier sehe ich halt Vorteile darin, solche Informationen bereits serverseitig zur Verfügung zu haben.
Bei deinem Vorschlag werden diese Informationen erst clientseitig verfügbar, womit wir wieder bei dem Punkt wären, dass jedem pauschal "Alles" geschickt werden muss, nur damit er sich dann das herauspickt, was für ihn relevant ist.
Und solange es keine Möglichkeiten gibt, das Markup zu bearbeiten/ anzupassen, außer mit Javascript, ist man auf der Clientseite zumindest "sehr eingeschränkt" in seinen Möglichkeiten.
Und ich finde das bisherige Konzept, jedem erstmal pauschal "Alles" auszuliefern, damit sich dann der jeweilige Client das raussuchen kann, womit er auch etwas anfangen kann, ist langsam aber sicher "überholt", bzw. verursacht viel zuviel unnötigen Traffic.
Solange sich das "mehr" an Traffic im Bereich von wenigen hundert Bytes oder ein paar kB bewegt, finde ich das durchaus noch in Ordnung.
Ich kann das zwar nicht wirklich einschätzen, aber ich könnte mir gut vorstellen, dass der "vermeidbare Traffic" wesentlich höher ist. Wenn ich mir alleine angucke, was an Cookies hin & her geschickt wird ...!
Die Telefonnummern sind ja nur ein kleiner Teil (SMS, Kontakte etc.) ...!
Ja, aber all das spielt sich auf einer wesentlich höheren Protokollebene ab als HTTP.
Das mag ja alles sein, aber wer sagt denn, dass man es nicht auch auf eine andere Ebene verlagern kann?
Ich sehe da halt durchaus diverse Vorteile, wenn der anfragende Client dem Server gleich auch etwas über seine "Fähigkeiten & Umfeld" mitteilt. Und nachdem heutzutage das Gros aller Seiten eh schon dynamisch generiert wird, dürfte eine "Anpassung", bzw. ein "Umstieg" auf die neuen Gegebenheiten nicht sonderlich aufwändig sein.
Eine Bemerkung noch zu deinem Vorschlag, solche Dinge ebenfalls per CSS zu realisieren:
CSS ist bereits aktuell so "aufgebläht", dass mit jedem neuem Feature das Risiko "unerwünschter Nebeneffekte" drastisch ansteigt. Die Zahl der Bugs in den einzelnen Engines steigt stetig. Und solange man keine "sinnvolle" Möglichkeit einer einfachen und sicheren "Logik" in CSS etabliert, werden CSS Dateien zukünftig noch umfangreicher und damit noch unübersichtlicher und schwerer Wartbar, als sie das ohnehin schon sind. Ich meine, wenn bei etlichen Seiten mittlerweile der Umfang der CSS-Datei(en) den der eigentlichen Inhaltsdateien übersteigt, sollte man sich doch auch mal fragen, ob das so alles noch "richtig" läuft. Hinzukommt, dass Neurungen im CSS teils eine gefühlte Ewigkeit brauchen, bis sie tatsächlich mal praktisch eingesetzt werden können. Das bisherige Entwicklungstempo ist schlicht und ergreifend zu langsam im Vergleich zu dem Tempo in den anderen (verbundenen) Bereichen. Ein "typisches" Beispiel dafür ist für mich etwa die aktuelle Diskussion, wie man das Problem mit den Rastergrafiken für die "Retina-Displays" löst. Wenn du bei der Sache mit den Telefonnummern tatsächlich auf eine CSS basierte Lösung setzen möchtest, wann glaubst du, wäre eine solche verfügbar? Wahrscheinlich existiert bis dahin die aktuelle Problemstellung schon gar nicht mehr ...!
Das alles sind u.a. Gründe, warum ich denke, dass wir "flexibler" an solche Probleme herangehen sollten, damit "brauchbare Lösungen" wesentlich zeitnaher realisiert werden.
Und die Browser "wissen/ kennen" ja all die Informationen, die wir so gerne auch hätten - nur "verraten" sie sie uns nicht (zumindest nicht alle). Und unter dem o.g. Gesichtspunkt, halte ich die Einführung zusätzlicher Header für eine der einfachsten Lösungen. Und ehrlich gesagt finde ich den Aspekt "was auf welche Ebene gehört" dabei ziemlich "nebensächlich". ;-)
Gruß Gunther
@@Gunther:
nuqneH
Hinzukommt, dass Neurungen im CSS teils eine gefühlte Ewigkeit brauchen, bis sie tatsächlich mal praktisch eingesetzt werden können. Das bisherige Entwicklungstempo ist schlicht und ergreifend zu langsam im Vergleich zu dem Tempo in den anderen (verbundenen) Bereichen. Ein "typisches" Beispiel dafür ist für mich etwa die aktuelle Diskussion, wie man das Problem mit den Rastergrafiken für die "Retina-Displays" löst.
Da verwechselst du gerade was.
In CSS ist das Problem bereits gelöst:
foo { background-image: url(bar) }
@media (min-resolution: 2dppx) { foo { background-image: url(bar@2x) } }
In *HTML* ist es noch ungelöst.
Qapla'
PS: Präfix-Varianten sind in http://css-tricks.com/snippets/css/retina-display-media-query/ nachzulesen.
Ein "typisches" Beispiel dafür ist für mich etwa die aktuelle Diskussion, wie man das Problem mit den Rastergrafiken für die "Retina-Displays" löst.
In *HTML* ist es noch ungelöst.
Was hat die Pixeldichte mit HTML zu tun?
@@suit:
nuqneH
Was hat die Pixeldichte mit HTML zu tun?
Dass du je nach dieser verschiedene Bilder für img-Elemente ausliefern möchtest. Und ja, das hat eigentlich nichts mit HTML zu tun. Aber aus verschiedenen Gründedn sträuben sich (Frontend-)Webentwickler, serverseitige Techniken in Betracht zu ziehen.
Qapla'
@@Gunnar:
nuqneH
Hinzukommt, dass Neurungen im CSS teils eine gefühlte Ewigkeit brauchen, bis sie tatsächlich mal praktisch eingesetzt werden können. Das bisherige Entwicklungstempo ist schlicht und ergreifend zu langsam im Vergleich zu dem Tempo in den anderen (verbundenen) Bereichen. Ein "typisches" Beispiel dafür ist für mich etwa die aktuelle Diskussion, wie man das Problem mit den Rastergrafiken für die "Retina-Displays" löst.
Da verwechselst du gerade was.
In der Tat! Da ist es wohl aufgrund der späten Stunde mit mir durchgegangen ...!
Ich dachte an das Einbinden von Images im Markup, was dann natürlich kein Beispiel für die teils langsame Entwicklung von CSS ist. ;-)
Wobei für mich eben aber genau dieser Fall eben ein gutes Beispiel dafür ist, wie "eingefahren" die Denkweise vieler "Entwickler" ist, indem man "krampfhaft" versucht, solche Probleme mit HTML zu lösen. Wobei du ja selber schon festgestellt hast, wie "praktisch" (und einfach) es sich serverseitig lösen ließe. Und das "beruhigt" mich ehrlich gesagt, denn normalerweise erhält man auf diese Vorschläge hin so Reaktionen wie die von suit oder Martin ...! ;-)
Gruß Gunther
Und das "beruhigt" mich ehrlich gesagt, denn normalerweise erhält man auf diese Vorschläge hin so Reaktionen wie die von suit oder Martin ...! ;-)
Was soll das jetzt heissen?
Hast du eine praktische Lösung für das Problem unbekannter Schemata die sich auf einem Web lösen lässt?
Welches Scheme von einem Browser unterstützt wird hat im HTTP-Header (Accept) weder im Request noch im Response etwas verloren, da der Browser selbst oft garnicht dafür zuständig ist.
Wenn das mailto:-Schema registriert ist, muss es nicht unbedingt der Browser sein der es bearbeitet - was nutzt es also dem Browser diese information zu kennen?
Unter Android ist es sogar so, dass nichtmal das http-Scheme direkt vom Browser verarbeitet wird - das erledigt das OS und reicht es dann erst an eine App weiter - man wird (wenn man das möchte) sogar jedes mal gefragt was er jetzt damit tun soll.
Darum ist für die Lösung dieses Problems der HTTP-Header völlig unpraktikabel - ebenso ist das Kaum ein Ding, welches man per CSS lösen müsste - es hat mit der Formatierung nur bedingt etwas zu tun. Wäre vielleicht aber ganz cool wenn es einen "unknow-scheme"-Attribut-Selektor gäbe, den man auf Attribute anwenden kann, deren Wert ein URI sein muss - das betrifft aber nur die Darstellung, da wären sie trotzdem noch - es muss wie schon von Martin und mir festgestellt eine API her die soetwas regelt, die man befragen kann und die einem sagt ob und was das System mit dem genannten Scheme-Werten etwas anfangen kann oder nicht.
Der Internet-Explorer stellt dies wie schon gesagt per JavaScript grundlegend zur Verfügung - aber eben nicht mit "ja/nein" sondern nur über eine Krücke oder einen Umweg.
Meiner bescheidenen Meinung nach ist das weder ein Problem von HTML, noch HTTP noch CSS.
Hi!
Und das "beruhigt" mich ehrlich gesagt, denn normalerweise erhält man auf diese Vorschläge hin so Reaktionen wie die von suit oder Martin ...! ;-)
Was soll das jetzt heissen?
Das was ich geschrieben habe - dass die meisten Leute der Meinung sind, dass das keine "geeignete" Lösung ist - aus welchen Gründen auch immer.
Hast du eine praktische Lösung für das Problem unbekannter Schemata die sich auf einem Web lösen lässt?
Welches Scheme von einem Browser unterstützt wird hat im HTTP-Header (Accept) weder im Request noch im Response etwas verloren, da der Browser selbst oft garnicht dafür zuständig ist.
Wenn das mailto:-Schema registriert ist, muss es nicht unbedingt der Browser sein der es bearbeitet - was nutzt es also dem Browser diese information zu kennen?
Unter Android ist es sogar so, dass nichtmal das http-Scheme direkt vom Browser verarbeitet wird - das erledigt das OS und reicht es dann erst an eine App weiter - man wird (wenn man das möchte) sogar jedes mal gefragt was er jetzt damit tun soll.
Erstens rede ich nicht nur von Schemes, und zweitens ist es völlig egal, wer oder was letztendlich dafür zuständig ist. Es ist Sache des Browsers diese Dinge über seine "Betriebsumgebung" zu wissen - tut er letztendlich ja auch. Nur leider behält er dies größtenteils für sich, oder lässt sich diese Dinge erst clientseitig entlocken.
Darum ist für die Lösung dieses Problems der HTTP-Header völlig unpraktikabel - ebenso ist das Kaum ein Ding, welches man per CSS lösen müsste - es hat mit der Formatierung nur bedingt etwas zu tun. Wäre vielleicht aber ganz cool wenn es einen "unknow-scheme"-Attribut-Selektor gäbe, den man auf Attribute anwenden kann, deren Wert ein URI sein muss - das betrifft aber nur die Darstellung, da wären sie trotzdem noch - es muss wie schon von Martin und mir festgestellt eine API her die soetwas regelt, die man befragen kann und die einem sagt ob und was das System mit dem genannten Scheme-Werten etwas anfangen kann oder nicht.
Sorry, aber scheinbar reden wir aneinander vorbei. Deine API-Lösung ist doch wieder eine rein clientseitige Geschichte, und das halte ich schon vom Grundsatz her für "nicht hilfreich"!
Hilfreich wäre es, wenn der Browser bereits dem Server mitteilen würde, "womit" er etwas anfangen kann, damit er anschließend auch nur das geliefert bekommt.
Ich verstehe auch ehrlich gesagt nicht, wo du da den großen Unterschied zu bereits existierenden Headern, wie dem Accept Language Header siehst!?
Du würdest es ja vermutlich auch nicht für sinnvoll erachten, jedem Client alle 5 Sprachvarianten auszuliefern, damit er sich dann die passende raussucht, oder?
Und wie sich in jüngster Vergangenheit herausgestellt hat, gibt es aufgrund der verschiedensten neuen Geräte auch eine Vielzahl neuer Funktionalitäten, die größtenteils Unterschiede im Markup erfordern würden.
Der Internet-Explorer stellt dies wie schon gesagt per JavaScript grundlegend zur Verfügung - aber eben nicht mit "ja/nein" sondern nur über eine Krücke oder einen Umweg.
Solange Javascript deaktivierbar ist, ist das für mich keine "brauchbare" Lösung! Zumal damit das "Problem" jedem Alles auszuliefern in keinster Weise beseitigt wird.
Meiner bescheidenen Meinung nach ist das weder ein Problem von HTML, noch HTTP noch CSS.
Das ist doch auch völlig egal, wessen Problem das ist. Letztendlich hat man als Autor das Problem, dass man nicht in der Lage ist, jedem User die bestmögliche Usability zu liefern.
Und von daher sollte eine möglichst schnelle und einfache Lösung für das Problem her ...!
Zu den Dingen, die imho interessant zu wissen wären, gehören u.a.
Und ggf. auch Infos darüber, welche CSS Module unterstützt werden.
Gruß Gunther
Hallo,
Sorry, aber scheinbar reden wir aneinander vorbei. Deine API-Lösung ist doch wieder eine rein clientseitige Geschichte, und das halte ich schon vom Grundsatz her für "nicht hilfreich"!
Hilfreich wäre es, wenn der Browser bereits dem Server mitteilen würde, "womit" er etwas anfangen kann, damit er anschließend auch nur das geliefert bekommt.
Ich verstehe auch ehrlich gesagt nicht, wo du da den großen Unterschied zu bereits existierenden Headern, wie dem Accept Language Header siehst!?
Du würdest es ja vermutlich auch nicht für sinnvoll erachten, jedem Client alle 5 Sprachvarianten auszuliefern, damit er sich dann die passende raussucht, oder?
Die angezeigte Sprache und wie mit verschiedenen Schemes umgegangen werden kann sind zwie ganz verschiedene paar Schuhe. Das erste hat rein was mit dem Inhalt bzw der zugänglichkeit zu diesem zu tun, das zweite eher nicht. auch ohne tel-scheme kann ich diese Nummer noch verwenden, mobil notfalls über copypasta udn aufn desktop mittles copypasta v0.5 (selber ins Telefon tippseln). Mit einem russischem Text kann ich erstmal nüschts anfangen.
Solange Javascript deaktivierbar ist, ist das für mich keine "brauchbare" Lösung! Zumal damit das "Problem" jedem Alles auszuliefern in keinster Weise beseitigt wird.
Meiner bescheidenen Meinung nach ist das weder ein Problem von HTML, noch HTTP noch CSS.
Das ist doch auch völlig egal, wessen Problem das ist. Letztendlich hat man als Autor das Problem, dass man nicht in der Lage ist, jedem User die bestmögliche Usability zu liefern.
Und von daher sollte eine möglichst schnelle und einfache Lösung für das Problem her ...!
Wird das wirklich genutzt eine Telefonnummer, die mitten auf der Seite steht einfach anzuklicken und anzurufen? und wie willst du fax und telefonnummern bzw bei letzteren unterscheiden ob anrufen oder simsem (grad bei dem TV-Quizen sind das auch meist verschiedene nummern, auch bei der Telekom gibts da verschiedene Nummern zB bei der HotSpot-Freischaltung)
Da hätte für mich noch die meiste Usability wenn eine Telefonnummer auf ne VCard verlinkt wird, damit sollte jedes "telefonie-programm" mit umgehen können und ich kann immer noch entscheiden ob telefonieren simsen oder faxen
Zu den Dingen, die imho interessant zu wissen wären, gehören u.a.
- Pixelratio (wäre hilfreich für Images im Quelltext)
- GPS/ Geolocation, sprich ob Standortdaten verfügbar sind oder nicht
- Art der Verbindung
- Telefonie
- SMS
Bis auf ersteres hat nichts davon was auf Servern zu suchen, insbesondere das zweite geht schon in Richtung Stasi 4.0. Und selbst wenn es diese Header mal geben sollte können diese alle manipuliert werden und du als Autor hast wieder das Problem.
Gruß Gunther
martachen
Hallo,
Sorry, aber scheinbar reden wir aneinander vorbei. Deine API-Lösung ist doch wieder eine rein clientseitige Geschichte, und das halte ich schon vom Grundsatz her für "nicht hilfreich"!
Hilfreich wäre es, wenn der Browser bereits dem Server mitteilen würde, "womit" er etwas anfangen kann, damit er anschließend auch nur das geliefert bekommt.
Ich verstehe auch ehrlich gesagt nicht, wo du da den großen Unterschied zu bereits existierenden Headern, wie dem Accept Language Header siehst!?
Du würdest es ja vermutlich auch nicht für sinnvoll erachten, jedem Client alle 5 Sprachvarianten auszuliefern, damit er sich dann die passende raussucht, oder?
Die angezeigte Sprache und wie mit verschiedenen Schemes umgegangen werden kann sind zwie ganz verschiedene paar Schuhe.
Das kommt ganz auf die Betrachtungsweise an ...! ;-)
Das erste hat rein was mit dem Inhalt bzw der zugänglichkeit zu diesem zu tun, das zweite eher nicht. auch ohne tel-scheme kann ich diese Nummer noch verwenden, mobil notfalls über copypasta udn aufn desktop mittles copypasta v0.5 (selber ins Telefon tippseln). Mit einem russischem Text kann ich erstmal nüschts anfangen.
Es geht auch nicht darum, dass du die Nummer ansonsten nicht angezeigt bekommen sollst, sondern darum, ob sie als Link mit dem entsprechenden Scheme ausgezeichnet wird oder nicht.
Das ist doch auch völlig egal, wessen Problem das ist. Letztendlich hat man als Autor das Problem, dass man nicht in der Lage ist, jedem User die bestmögliche Usability zu liefern.
Und von daher sollte eine möglichst schnelle und einfache Lösung für das Problem her ...!
Wird das wirklich genutzt eine Telefonnummer, die mitten auf der Seite steht einfach anzuklicken und anzurufen? und wie willst du fax und telefonnummern bzw bei letzteren unterscheiden ob anrufen oder simsem (grad bei dem TV-Quizen sind das auch meist verschiedene nummern, auch bei der Telekom gibts da verschiedene Nummern zB bei der HotSpot-Freischaltung)
Indem du nur solche (Ruf)Nummern entsprechend verlinkst ...!
SMS ist ein eigenes Scheme und funktioniert genauso wie 'mailto'.
Da hätte für mich noch die meiste Usability wenn eine Telefonnummer auf ne VCard verlinkt wird, damit sollte jedes "telefonie-programm" mit umgehen können und ich kann immer noch entscheiden ob telefonieren simsen oder faxen
Das hat nichts mit dem eigntlichen Problem zu tun, da du hier schon einen Schritt weiter bist. Es geht ja darum, zu wissen, ob ein Client überhaupt etwas mit einem bestimmten Scheme anfangen kann, um ihm nur dann entsprechend ausgezeichnete Links zu servieren (und wenn nicht eben als Text).
Zu den Dingen, die imho interessant zu wissen wären, gehören u.a.
- Pixelratio (wäre hilfreich für Images im Quelltext)
- GPS/ Geolocation, sprich ob Standortdaten verfügbar sind oder nicht
- Art der Verbindung
- Telefonie
- SMS
Bis auf ersteres hat nichts davon was auf Servern zu suchen,
Das ist wieder die "alte Leier" ohne eine vernünftige Begründung, bzw. Argumente.
BTW: Wer entscheidet denn, was etwas auf der Serverseite zu suchen hat, und was nicht?
insbesondere das zweite geht schon in Richtung Stasi 4.0.
Sorry, aber das ist doch Unsinn. Jede App mit Standortdiensten greift auf solche Informationen zurück. Schließlich ist es ja Sache des Users, die Infos freizugeben oder nicht.
Und selbst wenn es diese Header mal geben sollte können diese alle manipuliert werden und du als Autor hast wieder das Problem.
Ja, und Javascript und CSS können deaktiviert werden, der UA String kann "manipuliert" werden und, und und ...!
Persönlich halte ich vieles davon für "überflüssige Relikte", die aus einer Zeit stammen, zu der sie sinnvoll/ erforderlich waren. Inzwischen gehört ein Großteil davon abgeschafft/ geändert!
Aber ich teile deine Ansicht trotzdem nicht. Denn in all diesen Fällen (der Manipulation irgendwelcher Angaben) liegt "das Problem" nicht beim Autor, sondern beim User!
Gruß Gunther
@@Der Martin:
nuqneH
das tun sie doch - sie liefern genau die Informationen, die auf HTTP-Ebene notwendig oder sinnvoll sind, etwa Accept-Language oder Accept-Encoding.
Alle? Nein! Ein von gewünschter Bildauflösung bevölkerte Angabe hört nicht auf, dem HTTP-Header Widerstand zu leisten.
Hach, responsive Images wären so einfach, wenn es eine solche Angabe im HTTP-Header gäbe. Dann könnte man die Technik dafür verwenden, die dafür geschaffen wurde: content negotiation.
Und die Angabe der gewünschter Bildauflösung müsste natürlich dynamisch sein: nicht nur nach Bildschirmauflösung, sondern auch je nach gerade bestehender Netzverbindung, Akkuzustand, noch zur Verfügung stehendem Datenvolumen (hallo Drosselkom), …
Qapla'
@@Gunnar Bittersmann:
nuqneH
Hach, responsive Images wären so einfach, wenn es eine solche Angabe im HTTP-Header gäbe. Dann könnte man die Technik dafür verwenden, die dafür geschaffen wurde: content negotiation.
Qapla'
@@suit:
nuqneH
Wenn du die Nummer _nicht_ verlinkst und z.B. schreibst +43 (0) 123 / 45 67 89 wird die Telefonnummer ohne Verlinkung als +430123456789 erkannt
SISO-Prinzip: shit in, shit out.
Die Schreibweise Landeskennzahl – eingeklammerte Null war noch nie sinnvoll, IMHO.
Qapla'
Wenn du die Nummer _nicht_ verlinkst und z.B. schreibst +43 (0) 123 / 45 67 89 wird die Telefonnummer ohne Verlinkung als +430123456789 erkannt
SISO-Prinzip: shit in, shit out.
Die Schreibweise Landeskennzahl – eingeklammerte Null war noch nie sinnvoll, IMHO.
Versuch das einem Tiroler zu erklären, der ein Hotel betreibt :)
@@suit:
nuqneH
Die Schreibweise Landeskennzahl – eingeklammerte Null war noch nie sinnvoll, IMHO.
Versuch das einem Tiroler zu erklären, der ein Hotel betreibt :)
Aber du weißt doch, wie man richtige Daten aufhübschen kann. (Wobei die Schönheit im Auge des Tiroler Betrachters liegt.)
<span class="tel-intl">+43</span> <span class="tel-natl">123 / 45 67 89</span>
.tel-intl::after { content: " (0)" }
Qapla'
Aber du weißt doch, wie man richtige Daten aufhübschen kann. (Wobei die Schönheit im Auge des Tiroler Betrachters liegt.)
<span class="tel-intl">+43</span> <span class="tel-natl">123 / 45 67 89</span>
.tel-intl::after { content: " (0)" }
Das ist zwar eine Lösung, aber nicht wirklich eine Lösung - ich bevorzuge "wir erklärem ihm, wie man es _richtig_ macht" :)
Der Vorteil ist, dass mein Chef aus dem Zillertal stammt und Tirolern automatisch ein gutes Verhältnis hat - das ist irgend so ein Ding unter denen :p
ola Forumsbesucher,
- Es gibt gar keine automatische Telefonnummernerkennung unter Android und man muss tatsächlich den Quelltext anpassen (<a href="tel:) - Auch das kann ich mir eigentlich nicht vorstellen, weil ich selbst diese Funktionalität ganz nützlich finde.
Mir ist eine automatische Telefonnummererkennung auch nur unter dem iPhone bekannt. Ich finde die Variante mit dem TEL besser. Es zeichnet eindeutig aus, dass es eine Telefonnummer ist und auch angerufen werden ->will<-.
Dadurch, dass es zich verschiedene Arten gibt eine Telefonnummer aufzuschreiben (hier: USA vs. Deutschland z.b.) "könnten" theoretisch auch Zahlen als Telefonnummer interpretiert werden, die eigentlich keine darstellen soll, sondern nur so aussieht - aus welchem Grund auch immer.
mfg,
Rolfi
ola Forumsbesucher,
- Es gibt gar keine automatische Telefonnummernerkennung unter Android und man muss tatsächlich den Quelltext anpassen (<a href="tel:) - Auch das kann ich mir eigentlich nicht vorstellen, weil ich selbst diese Funktionalität ganz nützlich finde.
Mir ist eine automatische Telefonnummererkennung auch nur unter dem iPhone bekannt. Ich finde die Variante mit dem TEL besser. Es zeichnet eindeutig aus, dass es eine Telefonnummer ist und auch angerufen werden ->will<-.
Dadurch, dass es zich verschiedene Arten gibt eine Telefonnummer aufzuschreiben (hier: USA vs. Deutschland z.b.) "könnten" theoretisch auch Zahlen als Telefonnummer interpretiert werden, die eigentlich keine darstellen soll, sondern nur so aussieht - aus welchem Grund auch immer.mfg,
Rolfi
Ok, ich war einfach davon ausgegangen, dass es diesen Automatismus nicht nur bei Apple gibt. Wenn dem tatsächlich nicht so ist, muss ich neu darüber nachdenken.
Hi there,
- Es gibt gar keine automatische Telefonnummernerkennung unter Android und man muss tatsächlich den Quelltext anpassen (<a href="tel:) - Auch das kann ich mir eigentlich nicht vorstellen, weil ich selbst diese Funktionalität ganz nützlich finde.
Was ist so schlimm daran, ein bestimmtes Protokoll oder in dem Fall besser Kommunikationsgerät als solches auszuzeichnen? Zumal Du ja dann alle Möglichkeiten der Welt hast, Telefonnummern durch enstprechende Styles nach Deinen Vorstellungen zu gestalten.
Diese Raterei, irgendwelche nach Zahlen aussehende Characterkombinationen für Telefonnummern zu halten, halte ich eher generell für falsch. Ein Kunde bspw. hat sich bei mir "beschwert", daß irgendwelche Zahlen auf seiner HP immer blau und mit einem davorgestelltem "S" dargestellt werden. Hat Tage gedauert bis ich draufgekommen bin, daß das offenbar irgendein "Skype-plugin" in seinem Internetexporer verursacht hat...