Attribute: height

[JNK]

Hallo zusammen,

was soll das Attribut bei einem Widget eigentlich ausdrücken? Ich bin gerade am rss-Plugin und mir ist aufgefallen, dass height nicht - wie ich dachte - die Höhe des Widgets sondern die Höhe des Feeds angibt. Das heisst, das Widget ist dann 200px+label+border/margin/padding.

Wenn man ein image (in meinem Fall das Meteogramm) mit Höhe 200 px angibt und das RSS-Plugin auch mit 200px, dann sind die beiden unterschiedlich hoch, wenn einer von beiden ein Label hat, der andere aber nicht. Wirklich intuitiv finde ich das nicht (abgesehen davon, dass <div actor> beim image dann komischerweise 205.5px hoch ist und beim RSS-Plugin 200px, aber da arbeite ich dran).

Wie sollen wir das handhaben?

gruss,

der Jan

[Chris M.]

Height nur beim RSS-Widget oder allgemein?

(Beim Image-Widget sagt Height etwas über die Größe des Bildes. Das würde ich ungern undefinieren, da ich das am intuitiefsten empfinde...)

[JNK]

Aber schoen wäre zumindest, wenn <div actor> die entsprechende Höhe hätte, sonst ist vernünftiges alignen nahezu unmöglich.

Gruß,

der Jan


Sent from my iPhone using Tapatalk

[greentux]

Naja, wenn irgendwo steht, das height halt die Höhe des Widgets ist, hat man sich beim ersten Mal Bild einfügen auch daran gewöhnt.
Ich denke, man will ja eine halbwegs optisch ansprechende Struktur erzeugen. Das geht nur, wenn man weiß, wie groß die Widgets dann im Endeffekt sind. Sonst ist man nur am Basteln.

Interessant fände ich, wenn man eine Art Schachbrett über den Screen legt und Widgets dann immer n-fache der einzelnen Kacheln sein müssen. Damit sieht es optisch meistens ansprechend aus.

[JNK]

Sowas in der Art hatte ich für den verstorbenen jsonviewer programmiert. Man könnte z.B. Attribute wheight und wwidth einfügen, die für die Standardwidgets 1 sind und dann eben doppelt, dreifach,... hohe Widgets ermöglicht. Default würde man dann sowas wie auto einführen, d.h. das Widget passt sich dem Inhalt an (wie bisher).

Das ist etwas tricky, weil je nach Auflösung und Browser die Widgets unterschiedlich hoch sind und man das wegen der margins und paddings nicht so ohne weiteres im CSS hardcoden kann. Aber zumindest für FF und Chrome lässt sich das lösen.

Dann könnte height so bleiben wie es ist und dann quasi sowas wie contentheight bedeuten.

Gruß,

der Jan




Sent from my iPhone using Tapatalk

[Chris M.]

Naja, wenn irgendwo steht, das height halt die Höhe des Widgets ist, hat man sich beim ersten Mal Bild einfügen auch daran gewöhnt.

Ne, nicht ganz.

Die Höhe und Breite eines Bildes ist deshalb besonders, da es auf diesen Wert skaliert wird. Daher wird man diesen Wert - so man ihn setzt und nicht auf die Automatik vertraut - ganz bewusst wählen und an der Bild-Größe orientieren, nicht an der Widget-Größe. (U.a. auch um zu verhindern, dass das Bild auf 101% skaliert wird, was insb. bei Grafen grässlich aussieht)

Die Widget-Größe ist etwas anderes.

Die Sympathien für das "Schachbrett" hege ich auch. (Und ich hatte sogar insgeheim gehofft, dass mit der Veröffentlichung ein fähiger Web-Designer sich dieses Themas annimmt. Das gilt auch für die Spalten, hier würde ich unbedingt Richtung 960er gehen wollen - nur mit variabler Spaltengrundbreite...)

Zur Widget-Größe: was wir eigentlich brauchen ist eine Art "colspan" und "rowspan"...
Durch die 2D/3D Erweiterung bekommen wir aber die universelle Möglichkeit um hier weiter zu kommen. Neben der x/y/z-Position könnte man nämlich in das <layout>-Element auch Höhe/Breite bzw. Colspan/Rowspan abbilden.

[greentux]

Ich kann mir gerade nicht sooo viele Anwendungsfälle für Bilder vorstellen Aber ja, dann skalierts auf 101%. Wenn ich jetzt aber weiß, die die Berechnung läuft, kann ich das doch wieder auf 100% bringen.
Ggf. kann der Editor das dann auch "nebenher".

Aber zwei Argumente sind natürlich auch nicht schön.

[Robert_Mini]

Ich kann mir gerade nicht sooo viele Anwendungsfälle für Bilder vorstellen

Diagramme vom WG Diagrammgenerator lassen sich am einfachsten so einbinden. Dabei betrifft dieses Thema auch die Breite.
lg Robert

[Chris M.]

Ich kann mir gerade nicht sooo viele Anwendungsfälle für Bilder vorstellen Aber ja, dann skalierts auf 101%. Wenn ich jetzt aber weiß, die die Berechnung läuft, kann ich das doch wieder auf 100% bringen.

So einfach ist das nicht.

Ein Photo/Webcam hat - außer Schärfeverlust - kein großes Problem mit der Skalierung.
Bei Grafen, wie aus dem Diagrammgenerator, oder http://www.yr.no/place/Germany/Bavaria/Holzkirchen~2899676/avansert_meteogram.png oder eines der unzähligen anderen dynamisch aktualisierten Grafiken im Netz (Unwetterzentrale, ...) sieht's richtig doof aus, wenn die Anzeige nicht exakt die Bildgröße trifft.

Und per Hand kannst Du's nicht immer auf 100% bringen, da wir hier - bewusst! - Größen mischen. D.h. manche Angaben sind in Pixeln (bzw. in "em" was sich auf die aktuelle Schriftgröße bezieht), manche relativ ("100%") und - hier kommt der Konflikt - manche in Bildschirmgröße (wie Millimeter), da wir ja ein Touch-Interface bauen und Finger nicht skalieren.
D.h. was pixelexakt auf einem Bildschirm aussehen kann, kann auf einem anderen schon leicht verschoben aussehen wenn man nur die Widget-Größe angibt (es müssen nur die dpi anders sein).

Das ist übrigens auch der Grund, warum man die Einheit selbst im Attribut hinzufügen muss. Ich kann nämlich nicht pauschal beantworten, ob dieses Bild einfach 100% einnehmen soll (wie vermutlich die Webcam) oder pixelexakt (wie ein Graf).

Ggf. kann der Editor das dann auch "nebenher".

Den Editor kann man sicherlich erweitern Hilfestellungen zu geben - das oben angerissene prinzipielle Problem wird der nicht lösen können.

Aber zwei Argumente sind natürlich auch nicht schön.

Die schocken mich nicht. Wer sagt denn, dass man beide ausfüllen muss?
Und wenn man eine Situation hat, wo man beide ausfüllt würde man Prinzip bedingt nicht mit einem auskommen

[greentux]

Ich habe mir jetzt mal den Wetterlink genommen und sowohl in Firefox als auch in Chrome geladen. Danach das Fenster geändert, so dass er das Bild skaliert (bleibt nicht fix, sondern skaliert tatsächlich).

Ich habe jetzt nicht den Eindruck, dass es skaliert komisch aussieht.
Warum nutzt man den Diagrammeditors, wenn man das rrd-plugin nutzen kann?

Und oben hatte ich mich vertan. Zwei Argumente sind natürlich auch schön - sollte es heissen.

[JNK]

Colspan und rowspan gefällt mir gut. ich könnte das für rowspan auch mal implementieren, colspan habe ich noch nicht probiert.


Sent from my iPhone using Tapatalk

[Robert_Mini]

Warum nutzt man den Diagrammeditors, wenn man das rrd-plugin nutzen kann?

Das ist relativ einfach: mit dem Diagrammeditor kann man relativ leicht ein hübsches Diagramm mit mehreren Datenreihen, beliebiger Farbwahl für Hintergrund, Linien, Gitternetz, Achsenbeschriftung, etc. gestalten.

Das Diagramm Widget unterstützt derzeit nur eine Datenreihe und das Design des Diagramms weitesgehend fix.Auch hinsichtlich Kompatibilität sehe ich ein png vom Diagrammeditor einfacher. Das Diagramm der CV hat im Moment kleinere Probleme zB. wird die Achsenbeschriftung am Smartphone falsch dagestellt (Schrift liegt mit falschem Umbruch über der Achse...).

Nachdem ich ohnehin überzeugt bin, dass eine Smartphone Visu einen anderen Inhalt hat als eine große Visu, hab ich auch kein Problem damit im Aufruf verschiedene Größen für das Diagramm zu hinterlegen.
lg Robert

[greentux]

Dann sollte man ggf. das rrd Plugin verbessern
Aber ich verstehe was Du meinst. Das ist das, was bei mir drraw mit annähernd 50 Diagrammen + History macht. Aber eben nicht auf der Visu...

[JNK]

Zu colspan und rowspan gabs keine Kommentare mehr, wird das gewünscht?

Wäre dann zunächst in einzelnen Widgets/Plugins verfügbar, die damit auch was anfangen können (also image, rsslog etc., aber nicht switch oder info) mit möglichst viel gemeinsamen Code.

Falls das allgemein als überflüssig erachtet wird, würde ich mir den Coding-Aufwand allerdings auch ersparen.

Gruss,

der Jan

[greentux]

definitiv +1!