nicht angemeldet
Der Martin
Der Martin
Der Martin
molily
Der Martin
molily
molily
Hallo,
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Testtitle>
</head>
<body>
<form>
<h3>Login:</h3>
<h5>User</h5>
<p><input type="text" name="user" /></p>
<h5>Pass</h5>
<p><input name="pass" type="password" /></p>
<p><input type="submit" value="login" /></p>
</form>
</body>
</html>
existiert eine Möglichkeit alles proportional gross, bildschirmfüllend, ausser html5, auf einem Smartphone zu zeigen? Und umgekehrt gibt es sowas auch für Webseiten?
Ich habe zwar ein wenig gebingt und gegoogelt und gefunden:
<meta name="viewport" content="width=device-width; height=device-height; />
Das löst mein Problem natürlich, doch nur mit HTML5 kompatiblen mobilen Browsern, so wie ich das verstanden habe, testen konnte ich es leider nicht.
Aber zumindest mit HTML5 fähigen mobilen Browsern funktioniert das großartig, daher frage ich mich warum ich mich mit Webseiten für PC immer so schwer tue, vielleicht gibt es dafür ja auch etwas vergleichbares, anstatt alles einzeln anpassen zu müssen?
Gruss
Nikko
Das löst mein Problem natürlich, doch nur mit HTML5 kompatiblen mobilen Browsern, so wie ich das verstanden habe, testen konnte ich es leider nicht.
Gibt es denn noch, für dich relevante, Browser die kein HTML5 können?
Ich wüsste keine Möglichkeit, dein Problem mit "alten" Mitteln zu lösen.
Hallo,
Gibt es denn noch, für dich relevante, Browser die kein HTML5 können?
Ich wüsste keine Möglichkeit, dein Problem mit "alten" Mitteln zu lösen.
ok, das ist schon mal gut zu wissen, also brauche ich bei Handys keine Rücksicht zu nehmen, weil die dann wohl größtenteils HTML5 beherrschen, danke.
Dann noch mal zu Punkt2, gibt es so eine Metaangabe auch für Webseiten damit diese sich komplett dem Viewport anpassen?
Gruss
Nikko
ok, das ist schon mal gut zu wissen, also brauche ich bei Handys keine Rücksicht zu nehmen, weil die dann wohl größtenteils HTML5 beherrschen, danke.
hmm, bei meinem Tablet scheint das nicht zu funktionieren. Ist doch im Grunde auch nur ein übergroßes Handy. Mache ich da etwas falsch?
Hi,
ok, das ist schon mal gut zu wissen, also brauche ich bei Handys keine Rücksicht zu nehmen, weil die dann wohl größtenteils HTML5 beherrschen, danke.
hmm, bei meinem Tablet scheint das nicht zu funktionieren. Ist doch im Grunde auch nur ein übergroßes Handy. Mache ich da etwas falsch?
ja, du ordnest einer Gruppe von Geräten (Smartphones, Tablets) eine Sonderstellung zu, die sie zumindest in diesem Punkt nicht haben. Die Mobil-Browser versuchen ja nach Möglichkeit, sich ebenso wie ihre Desktop-Kollegen zu verhalten, und nur in ganz wenigen Fällen (z.B. Bedienung, Touch/Multitouch vs. Maus) von dieser Maxime abzuweichen.
Ciao,
Martin
hmm, bei meinem Tablet scheint das nicht zu funktionieren. Ist doch im Grunde auch nur ein übergroßes Handy. Mache ich da etwas falsch?
Von welchem Tablet redest du? Fabrikat? Browser?
Mathias
Von welchem Tablet redest du? Fabrikat? Browser?
Samsung Note N8020, Browser Chrome, aktuelle Version(weiss nicht welche, aber Autoupdate)
Hi,
existiert eine Möglichkeit alles proportional gross, bildschirmfüllend, ausser html5, auf einem Smartphone zu zeigen? Und umgekehrt gibt es sowas auch für Webseiten?
findest du es denn erstrebenswert, ein Login-Formular mit zwei Eingabefeldern und einem Submit-Button auf einem 23"-Monitor bildschirmfüllend darzustellen? Selbst "fensterfüllend" wäre mit üblichen Browser-Fenstergrößen bei Desktop-Systemen schon nicht wirklich wünschenswert.
Skaliere doch diese Elemente mit sinnvollen Werten in em, damit beziehst du dich auf die Schriftgröße; wenn du es ganz geschickt anstellst, dann sogar so, dass die Default-Schriftgröße des Browsers als Basis gilt (mit einem bestimmten Faktor multipliziert, wenn's denn sein soll).
<meta name="viewport" content="width=device-width; height=device-height; />
Das löst mein Problem natürlich, doch nur mit HTML5 kompatiblen mobilen Browsern, so wie ich das verstanden habe, testen konnte ich es leider nicht.
Ich bin nicht der Meinung, dass dein Ansinnen etwas mit HTML 5 zu tun haben müsste.
Ciao,
Martin
Hallo,
findest du es denn erstrebenswert, ein Login-Formular mit zwei Eingabefeldern und einem Submit-Button auf einem 23"-Monitor bildschirmfüllend darzustellen? Selbst "fensterfüllend" wäre mit üblichen Browser-Fenstergrößen bei Desktop-Systemen schon nicht wirklich wünschenswert.
du hast natürlich recht, aber da ist der HandyTag ja schon ein Stück weiter durch: maximum-scale=1.4; initial-scale=1.0;
Skaliere doch diese Elemente mit sinnvollen Werten in em, damit beziehst du dich auf die Schriftgröße; wenn du es ganz geschickt anstellst, dann sogar so, dass die Default-Schriftgröße des Browsers als Basis gilt (mit einem bestimmten Faktor multipliziert, wenn's denn sein soll).
So in etwa mache ich es ja bisher, daher die Frage das ganze zu vereinfachen wie beim besagten HandyTag.
Gruss
Nikko
Hi,
findest du es denn erstrebenswert, ein Login-Formular mit zwei Eingabefeldern und einem Submit-Button auf einem 23"-Monitor bildschirmfüllend darzustellen? Selbst "fensterfüllend" wäre mit üblichen Browser-Fenstergrößen bei Desktop-Systemen schon nicht wirklich wünschenswert.
du hast natürlich recht, aber da ist der HandyTag ja schon ein Stück weiter durch: maximum-scale=1.4; initial-scale=1.0;
hä? Was soll das sein? Wann war denn der Handy-Tag? Den habe ich wohl verpasst.
Ich weiß nicht, in welchem Kontext du den obigen Code notieren willst. CSS ist es nicht (obwohl derartige Dinge genau dort eigentlich hingehören). Ich würde den Sinn mangels besseren Wissens so interpretieren: "Setze den Skalierungsfaktor zunächst auf 1.0 (100%), und erlaube Zoom bis 1.4 (140%)."
Falls ich damit richtig liege und Mobil-Geräte das wirklich so interpretieren: Sinnvoll finde ich das nicht.
So long,
Martin
Hallo,
hä? Was soll das sein? Wann war denn der Handy-Tag? Den habe ich wohl verpasst.
હેલો
Falls ich damit richtig liege und Mobil-Geräte das wirklich so interpretieren: Sinnvoll finde ich das nicht.
<meta name="viewport" content="width=device-width, minimum-scale=1.0, maximum-scale=2.0">
Das macht, was du vermutest. und das ist durchaus Sinnvoll, da ohne diese Angabe Seiten komplett in den kleinen Viewport gequetscht werden (sofern sie nicht Smartphone-optimiert ist), mit dieser Angabe sieht man sie in „Normaler“ Grösse, ohne das sie verkleinert wird, was deutlich besser ist. maximum-scale=2.0 erlaubt das weitere zoomen. Wenn man 1.0 notiert, kann User die Seite nicht zoomen.
બાય
Hallo,
Falls ich damit richtig liege und Mobil-Geräte das wirklich so interpretieren: Sinnvoll finde ich das nicht.
<meta name="viewport" content="width=device-width, minimum-scale=1.0, maximum-scale=2.0">Das macht, was du vermutest. und das ist durchaus Sinnvoll, da ohne diese Angabe Seiten komplett in den kleinen Viewport gequetscht werden (sofern sie nicht Smartphone-optimiert ist)
was heißt hier "gequetscht"? Eine der Stärken von HTML und CSS ist doch, sich flexibel an das Ausgabemedium anzupassen. Ich bin davon ausgegangen, dass die Darstellung auf einem Smartphone mit, sagen wir, 320px breitem Display genauso aussieht, als würde ich das Browserfenster auf meinem Desktop-PC auf 320px zusammenschieben - außer dass das Smartphone vielleicht eine kleinere Default-Schriftart hat (vielleicht 12px anstatt 16px).
mit dieser Angabe sieht man sie in „Normaler“ Grösse, ohne das sie verkleinert wird, was deutlich besser ist.
Das sollte eigentlich der Normalfall sein, ohne dass man es extra spezifiziert.
Ciao,
Martin
Hallo,
was heißt hier "gequetscht"? Eine der Stärken von HTML und CSS ist doch, sich flexibel an das Ausgabemedium anzupassen. Ich bin davon ausgegangen, dass die Darstellung auf einem Smartphone mit, sagen wir, 320px breitem Display genauso aussieht, als würde ich das Browserfenster auf meinem Desktop-PC auf 320px zusammenschieben - außer dass das Smartphone vielleicht eine kleinere Default-Schriftart hat (vielleicht 12px anstatt 16px).
nein so ist es eben nicht und genau das macht diese metaangabe so genial. Denn handydisplays sind sehr unterschiedlich und bei so einer kleinen Fläche nahezu unmöglich allen recht zu machen.
Bei meinem Beispiel habe ich ohne den Metatag Minieingabefelder und vom Gesamtbild mal ganz zu schweigen.
mit dieser Angabe sieht man sie in „Normaler“ Grösse, ohne das sie verkleinert wird, was deutlich besser ist.
Das sollte eigentlich der Normalfall sein, ohne dass man es extra spezifiziert.
Nein, nicht der Normalfall, aber ein kleiner Metatag ist ja nicht kompliziert, deshalb würde ich mir wünschen das gäbe es auch für den PC.
હેલો
was heißt hier "gequetscht"?
Ohne die Angabe siehst du eine Seite so, wie du sie in einem Grossen Viewport sehen würdest. Nur ist das eben kein Grosser Viewport, sondern ein winziger.
So sieht deine Seite aus, nur musst du dir das Bild auf dem kleinen Bildschirm eines S4 vorstellen. Wenn du das Screenshot nicht ok findest, lösche ich es unverzüglich wieder.
Das sollte eigentlich der Normalfall sein, ohne dass man es extra spezifiziert.
Nicht im Chrome auf einem Galaxy s4, da werden Seiten ohne diese Angabe teilweise bis zur unlesbarkeit verkleinert. Diese Angabe macht aber auch nur Sinn, wenn man sein CSS noch etwas für Mobile Geräte anpasst.
Bis vor kurzem machte ich das mittels media-query:
@media screen and (max-width: 600px) {
}
Damit erwischt man aber den Galaxy nicht im „Querformat“.
Mit
@media screen and (max-width: 640px) {
}
Kann man die Seite zumindest für ein Galaxy anpassen, oder besser, für alle neuen Chrome-Versionen auf kleinen Smartphones.
બાય
n'Abend ...
was heißt hier "gequetscht"?
Ohne die Angabe siehst du eine Seite so, wie du sie in einem Grossen Viewport sehen würdest. Nur ist das eben kein Grosser Viewport, sondern ein winziger.
dann ist das Murks im Grundkonzept. Da war ja schon das ogo fortschrittlicher, das ich eine Zeitlang benutzt habe. Das Ding war primitiv, hat aber trotz seines winzigen Displays mit 240px Breite die meisten Seiten ordentlich angezeigt. Dabei war aber der Default-Modus eine 1:1-Abbildung, das Gerät verhielt sich also wie ein herkömmlicher Browser mit entsprechend kleinem Fenster. Eine Art Fullsize-Mode, in dem die gesamte Webseite stark verkleinert angezeigt wurde, gab's jeweils auf Wunsch.
Das sollte eigentlich der Normalfall sein, ohne dass man es extra spezifiziert.
Nicht im Chrome auf einem Galaxy s4, da werden Seiten ohne diese Angabe teilweise bis zur unlesbarkeit verkleinert.
Also Murks im Konzept, wie gesagt.
Ciao,
Martin
Ich bin davon ausgegangen, dass die Darstellung auf einem Smartphone mit, sagen wir, 320px breitem Display genauso aussieht, als würde ich das Browserfenster auf meinem Desktop-PC auf 320px zusammenschieben
Das ist schon mindestens seit 2007 (erstes iPhone, Mobile Safari) nicht mehr der Fall – also seit dem Durchbruch von Smartphones überhaupt. Wobei Opera Mobile und andere Mobilbrowser schon vorher einen Auto-Zoom enthielten. Durch ein kleines 320px-mal-356px-Fenster ohne Skalierung wäre das Web unbedienbar.
Mathias
Hallo,
Durch ein kleines 320px-mal-356px-Fenster ohne Skalierung wäre das Web unbedienbar.
Keineswegs. Das ging vorzüglich. Sogar noch kleiner.
Ciao,
Martin
Durch ein kleines 320px-mal-356px-Fenster ohne Skalierung wäre das Web unbedienbar.
Keineswegs. Das ging vorzüglich. Sogar noch kleiner.
Deswegen hat sich dieses Modell auch durchgesetzt und alle rennen heutzutage mit diesen wunderschönen Ogos herum. Nicht.
Erst mit Zooming bzw. mit virtuellen Viewports, Meta-Viewport-Tags und Media Queries ist das bestehende Web mobil ordentlich bedienbar geworden. Unter anderem deshalb war das iPhone der Durchbruch für Smartphones generell. Vorher war Webdesign für Mobilgeräte nicht ernsthaft möglich.
Aber es hat wenig Sinn, über Techniken zu diskutieren, die seit über 6 Jahren breiter Standard bei allen relevanten Mobilgeräten/-browsern sind, und du sie 2013 auf den ersten Blick als »Murks im Grundkonzept« abtust. Hast du schon einmal ein modernes Smartphone oder Tablet bedient?
Mathias
Hallo,
existiert eine Möglichkeit alles proportional gross, bildschirmfüllend, ausser html5, auf einem Smartphone zu zeigen?
Was verstehst du unter HTML5? Wieso löst HTML5 dein Problem?
Ich habe zwar ein wenig gebingt und gegoogelt und gefunden:
<meta name="viewport" content="width=device-width; height=device-height; />
Das löst mein Problem natürlich, doch nur mit HTML5 kompatiblen mobilen Browsern, so wie ich das verstanden habe, testen konnte ich es leider nicht.
Die Unterstützung von <meta name="viewport"> hat nichts mit »HTML5« zu tun – was auch immer man darunter versteht. <meta name="viewport"> ist bis dato eine proprietäre Apple-Erfindung, wird aber neben Mobile Safari und Chrome für iOS auch von Opera Mobile, dem Android-Browser, Chrome für Android und dem Internet Explorer ab Windows Phone 7 unterstützt. D.h. alle relevanten Mobilbrowser.
Daneben befindet sich eine @viewport-CSS-Regel in der Standardisierung, welche einige Browser auch schon mit Präfix unterstützen.
Desktop-Browser ignorieren die Viewport-Angabe m.W. komplett. Das hat historische Gründe. Sie fahren vergleichsweise hohe Auflösungen. Mobilgeräte hatten anfangs kleine Viewports (gemessen nach Hardware-Pixeln, auch Device-Pixel genannt), verwendeten also einen größeren virtuellen Viewport (gemessen nach CSS-Pixeln). Dadurch werden bestehende Sites, die für eine Viewport-Breite von 980 Pixel »optimiert« sind, sinnvoll herunterskaliert. <meta name="viewport"> wurde als Opt-In eingeführt, damit für kleine Viewports optimierte Websites diese Auto-Skalierung ausschalten bzw. steuern konnten.
Seit dem ersten iPhone, das <meta name="viewport"> eingeführt hatte, verdoppelte bzw. verdreifachte sich die Hardware-Auflösung. Heutige 5-Zoll-Smartphones haben teilweise schon 1920 mal 1080 Pixel, verwenden aber immer noch dieselben virtuellen Viewport-Breiten.
Zudem kam das Device-Pixel-Verhältnis ins Spiel, welche diesen Skalierungsfaktor ausdrückt (üblich sind derzeit 1.5, 2 und 3). Das ist im Grunde auch eine Maßnahme zur Abwärtskompatibilität mit Websites, die den virtuellen Viewport auf die device-width/device-height gesetzt haben.
Lange Rede, kurzer Sinn: Für Desktop-Browser gibt es dieses Chaos nicht. (Von »Retina«-Bildschirmen, die ein Device-Pixel-Verhältnis von > 1 haben, einmal abgesehen.) Man kann eine Site höchstens mit CSS-Transformationen skalieren. Es ist wahrscheinlich eine JavaScript-Logik nötig, um den korrekten Zoomfaktor zu berechnen.
Grüße,
Mathias
Hallo,
Was verstehst du unter HTML5? Wieso löst HTML5 dein Problem?
nein, HTML5 löst mein Problem nicht, sondern bietet diesen metatag an, soch dachte ich zumindest aufgrund der gefunden Webseiten zu dem Thema. Aber anscheinend gibt es das schon länger, wenn ich deiner folgenden Ausführung folge.
Die Unterstützung von <meta name="viewport"> hat nichts mit »HTML5« zu tun – was auch immer man darunter versteht. <meta name="viewport"> ist bis dato eine proprietäre Apple-Erfindung, wird aber neben Mobile Safari und Chrome für iOS auch von Opera Mobile, dem Android-Browser, Chrome für Android und dem Internet Explorer ab Windows Phone 7 unterstützt. D.h. alle relevanten Mobilbrowser.
Das hat m. mir ja schon erläutert.
Lange Rede, kurzer Sinn: Für Desktop-Browser gibt es dieses Chaos nicht. (Von »Retina«-Bildschirmen, die ein Device-Pixel-Verhältnis von > 1 haben, einmal abgesehen.) Man kann eine Site höchstens mit CSS-Transformationen skalieren. Es ist wahrscheinlich eine JavaScript-Logik nötig, um den korrekten Zoomfaktor zu berechnen.
Chaos? Genau das Gegenteil empfinde ich mit diesem Meta(handy)tag.
Es finden sich hier im Forum hunderte Threats zum Thema Seite an Bildschirm anpassen, ich experimentiere selbst immer viel damit und muss doch oft Kompromisse akzeptieren, mit diesem Tag wäre das Ganze ein Klacks.
http://davidbcalhoun.com/2010/viewport-metatag
http://html5-mobile.de/blog/meta-viewport-fuer-mobile-anpassen
Gruss
Nikko
Lange Rede, kurzer Sinn: Für Desktop-Browser gibt es dieses Chaos nicht.
Chaos? Genau das Gegenteil empfinde ich mit diesem Meta(handy)tag.
»Chaos« bezog sich auf die historische Entstehung von virtuellen Viewports und der Device-Pixel-Ratio. Ich habe damit versucht zu erklären, warum es virtuelle Viewports auf Desktops nicht gibt, jedoch eine Device-Pixel-Ratio > 1.
Warum <meta name="viewport"> nützlich ist, habe ich ja auch geschrieben.
Mathias
Hallo Mathias,
»Chaos« bezog sich auf die historische Entstehung von virtuellen Viewports und der Device-Pixel-Ratio. Ich habe damit versucht zu erklären, warum es virtuelle Viewports auf Desktops nicht gibt, jedoch eine Device-Pixel-Ratio > 1.
Warum <meta name="viewport"> nützlich ist, habe ich ja auch geschrieben.
ok dann habe ich das anders verstanden bzw. verstehe ich teilweise vielleicht immer noch so. Du meinst für Desktop-PC wäre das nicht nötig weil es diese Vielfalt an Auflösungen und Größen, wie bei Handys nicht gibt?
Falls dem so ist, sehe ich das anders, wie mir z.B. mein Tabletversuch eben schmerzhaft gezeigt hat. Es wäre doch schön nicht mehr jedes kleine Element mit Größsenangaben vollzuspicken und dann noch seperate CSS für jedes Medium zu schaffen. Ein wirklich flexibeles gummiartiges Design für alle Ausgabemedien. Eine enorme Arbeitserleichterung.
Gruss
Nikko
ok dann habe ich das anders verstanden bzw. verstehe ich teilweise vielleicht immer noch so. Du meinst für Desktop-PC wäre das nicht nötig weil es diese Vielfalt an Auflösungen und Größen, wie bei Handys nicht gibt?
Natürlich gibt es eine enorme Vielfalt bei Desktop-PCs. Man kann auch darüber streiten, ob ein Viewport-Tag nicht auch für Desktop-Browser sinnvoll wäre – als generelle Skalierungstechnik. Fakt ist, dass noch keine starke Notwendigkeit dafür gab, einen solchen einzuführen.
Der Viewport-Tag ist aus einer ganz bestimmten historischen Situation entstanden: Ein Desktop-Rechner war das verbreitetste Webzugangsgerät mit üblicherweise zwischen 800 und 1280 Pixel Viewport-Breite. Sämtliche Websites waren nicht etwa anpassungsfähig, sondern »optimiert«, d.h. festgezurrt auf eine Breite von 980 Pixeln. (Schon 2006 argumentierte ich gegen diese Praxis.)
Unter diesen Gegebenheiten wollte Apple das bestehende Web auf das iPhone bringen und gleichzeitig Anpassungen speziell für kleine Viewports ermöglichen. Also erfanden sie den virtuellen Viewport von 980px auf einem 320px-Gerät und den Viewport-Tag, um die Skalierung zu steuern. Der Viewport-Tag entstand also in Abgrenzung vom Desktop, weil für Desktop-Auflösungen optimierte Websites zuerst da waren.
Es wäre doch schön nicht mehr jedes kleine Element mit Größsenangaben vollzuspicken und dann noch seperate CSS für jedes Medium zu schaffen. Ein wirklich flexibeles gummiartiges Design für alle Ausgabemedien. Eine enorme Arbeitserleichterung.
Die gegenwärtige Leitidee ist Responsive Design. Klar, Media Queries ist eine der wichtigsten Techniken. Wenn man Media Queries intelligent einsetzt, so braucht man kein separates CSS für jedes Medium.
Es gibt noch weitere Techniken, um Anpassungsfähigkeit zu erreichen. Spaltenlayouts können Prozentwerte verwenden, oder auch Floats, die automatisch untereinander springen. Mit dem neuen CSS3-Layoutmodul Flexbox lassen sich anpassungsfähige Layouts auch ohne viel Media Queries bauen.
Man kann auch mit em- bzw. rem-Werten arbeiten und die Basisschriftgröße skalieren. Wie bei der Skalierung durch eine CSS-Transformation ist dazu ggf. eine JavaScript-Logik nötig.
Mathias
Hallo,
(Schon 2006 argumentierte ich gegen diese Praxis.)
sehr schöner, lesenswerter Artikel.
nur zur Info: diese Seite hat Probleme im IE und meldet Sicherheitshinweise
Du hast einige Möglichkeiten aufgezeigt, wohin die Reise gehen könnte, danke. Eines haben aber leider alle diese Varianten gemein, sie sind relativ aufwendig im direkten Vergleich zu dem simplen "HandyTag". Aber gut, meine Frage ist beantwortet, es gibt leider nichts vergleichbares für den Desktop.
Gruss
Nikko
હેલો
es gibt leider nichts vergleichbares für den Desktop.
Du kannst Media-Queries nutzen, die sind doch ziemlich einfach.
/* main.css */
body {
/* ... */
}
@media screen and (max-width: 800px) { /* Vermutlich Tablet */
}
@media screen and (max-width: 640px) { /* Vermutlich Smartphone */
}
Mit einigen weiteren Selektoren kannst du noch weiter ins Detail gehen. Bspw. noch mit „min-width“ für sehr Grosse Viewports usw.
બાય
Hallo Mathias!
Der Viewport-Tag ist aus einer ganz bestimmten historischen Situation entstanden: Ein Desktop-Rechner war das verbreitetste Webzugangsgerät mit üblicherweise zwischen 800 und 1280 Pixel Viewport-Breite. Sämtliche Websites waren nicht etwa anpassungsfähig, sondern »optimiert«, d.h. festgezurrt auf eine Breite von 980 Pixeln.
Letzteres kann ich so nicht "in meiner Erinnerung" finden ...! ;-)
Zuerst haben sich fixe Breiten von 800px eingebürgert, die später, als man quasi 1024 x ... als Standard-Auflösung bei den Monitoren angesehen hat, von 960px Breite abgelöst wurden (siehe u.a. auch die damalige Masse an Gridsystemen à la '960').
Unter diesen Gegebenheiten wollte Apple das bestehende Web auf das iPhone bringen und gleichzeitig Anpassungen speziell für kleine Viewports ermöglichen. Also erfanden sie den virtuellen Viewport von 980px auf einem 320px-Gerät und den Viewport-Tag, um die Skalierung zu steuern. Der Viewport-Tag entstand also in Abgrenzung vom Desktop, weil für Desktop-Auflösungen optimierte Websites zuerst da waren.
Also imho sind diese 980px mehr als willkürlich ..., zumal bspw. 320px x 3 ja auch 960px und eben nicht 980px ergibt.
Und genau an dieser Stelle haben "wir" dann die Chance verpasst, doch noch den bereits seit Jahren existierenden Medientyp 'Handheld' endlich zu nutzen ...! Danke Apple - toll gemacht!
Gruß Gunther
Hallo,
Letzteres kann ich so nicht "in meiner Erinnerung" finden ...! ;-)
Nachdem ich meinen eigenen Artikel aus dem Jahr 2006 gelesen habe, muss ich dir Recht geben. ;) Die Viewports waren damals wohl insgesamt kleiner als ich dachte.
Zuerst haben sich fixe Breiten von 800px eingebürgert, die später, als man quasi 1024 x ... als Standard-Auflösung bei den Monitoren angesehen hat, von 960px Breite abgelöst wurden (siehe u.a. auch die damalige Masse an Gridsystemen à la '960').
980 war durchaus möglich und verbreitet. 960 wurde für Gridsysteme gewählt, weil es sich so schön ganzzahlig teilen ließ (durch 2, 3, 4, 5, 6, 8). Den Viewport 980px breit zu machen, ergab schon Sinn.
Und genau an dieser Stelle haben "wir" dann die Chance verpasst, doch noch den bereits seit Jahren existierenden Medientyp 'Handheld' endlich zu nutzen ...! Danke Apple - toll gemacht!
Wieso haben wir das verpasst?
Der Sinn von Apples Maßnahme war, das ganze, gleiche Web aufs Handy zu bringen. Kein Web, das umformatiert, serialisiert, umgefärbt usw. wurde. Das hat funktioniert, das hat sich durchgesetzt; alle mobilen Webbrowser arbeiten heute so. Erst später entstanden anpassungsfähige, für Mobilgeräte optimierte Sites. Noch längst sind nicht alle Sites entsprechend angepasst.
Dass das iPhone bestehende Websites vollwertig anzeigt, schloss aus, dass es sich als »handheld« identifiziert. Ohnehin sind Media Queries, die die Viewport-Größe abfragen, viel allgemeiner und flexibler als solche, die bloß den Medientyp abfragen.
Von screen und print abgesehen sind Medientypen ein großer Reinfall gewesen. Das war langfristig auch gut so. Geräte, auf die handheld zutreffen würde, haben genauso wenig miteinander gemeinsam wie Geräte, auf die screen zutrifft.
Um einen Vergleich zu bemühen: Medientypen sind die Browserabfragen, Viewport-Abfragen sind die Feature-Abfragen unter den Media Queries.
Mathias
Hallo Mathias!
980 war durchaus möglich und verbreitet. 960 wurde für Gridsysteme gewählt, weil es sich so schön ganzzahlig teilen ließ (durch 2, 3, 4, 5, 6, 8). Den Viewport 980px breit zu machen, ergab schon Sinn.
Ja - welchen? ;-)
Was ist an 980px "sinnvoller" als bspw. an 960px (der damals "populärsten" fixen Breite)?
Und genau an dieser Stelle haben "wir" dann die Chance verpasst, doch noch den bereits seit Jahren existierenden Medientyp 'Handheld' endlich zu nutzen ...! Danke Apple - toll gemacht!
Wieso haben wir das verpasst?
Die Begründung lieferst du ja schon selber im nächsten Absatz.
Der Sinn von Apples Maßnahme war, das ganze, gleiche Web aufs Handy zu bringen. Kein Web, das umformatiert, serialisiert, umgefärbt usw. wurde. Das hat funktioniert, das hat sich durchgesetzt; alle mobilen Webbrowser arbeiten heute so. Erst später entstanden anpassungsfähige, für Mobilgeräte optimierte Sites. Noch längst sind nicht alle Sites entsprechend angepasst.
Dass das iPhone bestehende Websites vollwertig anzeigt, schloss aus, dass es sich als »handheld« identifiziert.
Sehe ich nicht so. Auf den Media Type 'Handheld' zu reagieren, muss ja nicht automatisch/ zwangsläufig bedeuten deshalb nicht (auch) auf 'Screen' zu reagieren.
So hätte man imho beides haben können, nämlich die "ordentliche" Darstellung bereits existierender Seiten *und* eine Möglichkeit, spezielle Styles für den "Gerätetyp" zu definieren. Letzteres ist durch das Vorgehen nun endgültig passé ...!
Ohnehin sind Media Queries, die die Viewport-Größe abfragen, viel allgemeiner und flexibler als solche, die bloß den Medientyp abfragen.
Warum immer diese "entweder oder" Mentalität.
Die wahre Power liegt imho eh nur in der Kombination aller vorhandenen Optionen.
Von screen und print abgesehen sind Medientypen ein großer Reinfall gewesen. Das war langfristig auch gut so. Geräte, auf die handheld zutreffen würde, haben genauso wenig miteinander gemeinsam wie Geräte, auf die screen zutrifft.
Der ersten Aussage stimme ich voll zu. Aber woran liegt das?
Zum einen daran, dass "vorausschauende" Implementationen in CSS keinen Sinn machen, weil CSS immer nur dann verwendet wird, wenn es auch tatsächlich Ver-/ Anwendung findet.
Und zum anderen daran, dass die Unterscheidung der Medientypen an den Erfordernissen der Praxis vorbei geht. Viel interessanter wären ggf. Unterscheidungen wie "Keyboard", "Mouse" und "Touch".
Mir fällt jetzt auch nur ein halbwegs gelungenes Beispiel für eine entsprechende Umsetzung ein: AFAIR verwendet der letzte "echte" Opera (also mit Presto Engine) im normalen Fenstermodus "Screen", während er (Existenz vorausgesetzt) im Vollbildmodus "Projection" anwendet.
Um einen Vergleich zu bemühen: Medientypen sind die Browserabfragen, Viewport-Abfragen sind die Feature-Abfragen unter den Media Queries.
ACK, und Javascript[1] schließt die Defizite beider ...! :-P
Denn leider sind beide "Techniken" bei weitem (noch) nicht so weit "ausgereift", um allen Anforderungen in der Praxis gerecht zu werden.
Gruß Gunther
[1] Wenn ich mich recht erinnere, hast du vor kurzem ja selbst hier irgendwo geschrieben, dass Javascript Support heutzutage quasi unerlässlich ist - sehe ich genauso, denn aktuell gibt es zumindest für einige Dinge keine Alternative.
Hallo!
Auf den Media Type 'Handheld' zu reagieren, muss ja nicht automatisch/ zwangsläufig bedeuten deshalb nicht (auch) auf 'Screen' zu reagieren.
Die Frage ist, was ist ein Handheld-Gerät und welche Styles würde ich vergeben?
Unter Handheld würde fallen:
iPhone 1 mit 320×480
HTC Hero mit 320×480
BlackBerry Bold mit 360×480
iPhone 5 mit 640×1136
Nokia Lumia 920 mit 768×1280
iPad mit 1024×768
iPad 4 mit 2048×1536
Galaxy Tab mit 1280×800
Surface Pro mit 1920×1080
usw.
Diese Geräte unterscheiden sich teilweise wie Tag und Nacht (Hardware, Bedienung, Software/OS/Browser). Ich wüsste nicht, mit welchen Styles ich all diese sinnvoll ansteuern könnte.
Die wahre Power liegt imho eh nur in der Kombination aller vorhandenen Optionen.
Welche »Power« würde mir media=heldheld denn geben, die ich nicht schon durch Featureabfragen habe?
Mir fällt jetzt auch nur ein halbwegs gelungenes Beispiel für eine entsprechende Umsetzung ein: AFAIR verwendet der letzte "echte" Opera (also mit Presto Engine) im normalen Fenstermodus "Screen", während er (Existenz vorausgesetzt) im Vollbildmodus "Projection" anwendet.
Das ist auch das einzige Beispiel, was mir einfällt – und ich halte es eher für misslungen. Ganz davon abgesehen, dass das ein Alleingang von Opera war. Nun war Opera immer schon ein »Randgruppenbrowser«, hat aber wichtige technische Impulse gegeben. Diese Umsetzung von media=projection hat aber sonst kein Browser aufgegriffen. Und seit Opera 15 ist sie gänzlich tot, soweit ich das sehe.
Aber zur Umsetzung selbst: Damit waren Präsentationen möglich, die im Vollbildmodus aus einzelnen Slides bestehen und im Normalmodus aus vertikal scrollbarem Inhalt.
Warum? Da werden so viele Annahmen gemacht, die in der Realität nicht stimmen:
Annahme 1: Wenn ich präsentiere bzw. mir Präsentationen ansehe, nutze ich den Vollbildmodus.
Annahme 2: Wenn ich präsentiere bzw. mir Präsentationen ansehe, so navigiere ich die Präsentation seitenweise (paged).
Annahme 3: Wenn ich nicht im Vollbildmodus bin, z.B. wenn ich die Präsentation erstelle oder sie in einem einfachen Browserfenster ansehe, will ich den Inhalt linearisiert sehen und ihn gewohnt scrollen (continuous).
Annahme 4: Die beiden Darstellungsweisen unterscheiden sich grundsätzlich (screen und projection sind disjunkt).
Diese Annahmen treffen oftmals zu, aber nicht in jedem Fall. Ich will nicht immer den Vollbildmodus nutzen, weder beim produzieren noch beim konsumieren. Nicht alle Präsentationen bestehen aus »Slides«, von denen immer nur eine sichtbar ist. Ich will ggf. die meisten Styles zwischen projection und screen teilen (gut, kann ich mit @media screen, projection {…} auch).
Lange Rede, kurzer Sinn: Es gibt viele Präsentationsframeworks für HTML/CSS/JavaScript, aber keines hat den projection-Medientyp so verwendet, wie er gedacht war. Weil es völlig unflexibel wäre. Die meisten Präsentationen, die online stehen, werden nicht im Vollbildmodus konsumiert, und sind trotzdem »paged media«. Viele Präsentationen werden nicht im Vollbildmodus gehalten und sind »paged« oder »continous«.
Mathias
Hallo!
Mir fällt jetzt auch nur ein halbwegs gelungenes Beispiel für eine entsprechende Umsetzung ein: AFAIR verwendet der letzte "echte" Opera (also mit Presto Engine) im normalen Fenstermodus "Screen", während er (Existenz vorausgesetzt) im Vollbildmodus "Projection" anwendet.
Warum? Da werden so viele Annahmen gemacht, die in der Realität nicht stimmen:
Annahme 1: Wenn ich präsentiere bzw. mir Präsentationen ansehe, nutze ich den Vollbildmodus.
Annahme 2: Wenn ich präsentiere bzw. mir Präsentationen ansehe, so navigiere ich die Präsentation seitenweise (paged).
Annahme 3: Wenn ich nicht im Vollbildmodus bin, z.B. wenn ich die Präsentation erstelle oder sie in einem einfachen Browserfenster ansehe, will ich den Inhalt linearisiert sehen und ihn gewohnt scrollen (continuous).
Annahme 4: Die beiden Darstellungsweisen unterscheiden sich grundsätzlich (screen und projection sind disjunkt).Diese Annahmen treffen oftmals zu, aber nicht in jedem Fall. Ich will nicht immer den Vollbildmodus nutzen, weder beim produzieren noch beim konsumieren. Nicht alle Präsentationen bestehen aus »Slides«, von denen immer nur eine sichtbar ist. Ich will ggf. die meisten Styles zwischen projection und screen teilen (gut, kann ich mit @media screen, projection {…} auch).
Lange Rede, kurzer Sinn: Es gibt viele Präsentationsframeworks für HTML/CSS/JavaScript, aber keines hat den projection-Medientyp so verwendet, wie er gedacht war. Weil es völlig unflexibel wäre. Die meisten Präsentationen, die online stehen, werden nicht im Vollbildmodus konsumiert, und sind trotzdem »paged media«. Viele Präsentationen werden nicht im Vollbildmodus gehalten und sind »paged« oder »continous«.
Scheinbar denken wir hierbei an völlig unterschiedliche Anwendungsfälle ...! ;-)
Beispiel:
Ich leite das Bild von meinem Smartphone an einen Beamer. Dieser wirft das Bild auf eine Leinwand, die eine Diagonale von 50" hat. Im Browser (auf dem Smartphone) greift jetzt aber eine MQ für eine Viewportbreite von 320px!
Und du hast keine Möglichkeit, etwas anderes zu erreichen.
Da sehe ich den Ansatz von Opera schon durchaus positiver als du. Ob jetzt das "Umschalten in den Vollbildmodus" die ideale Variante ist oder nicht, sei mal völlig offen. Zumindest gibt es aber überhaupt eine Möglichkeit.
Gruß Gunther