Attribute: height

[makki]

hiermit +2

Diagrammgenerator (oder drraw) sind primär für Malen-nach-Zahlen-Systeme wie (xx) gemacht und gedacht. Das ist langsam und im Kern eigentlich dämlich, weil man die Grafik extra, separat aufs Visu(Layout&Design) anpassen muss (Hier&heute aber halt eine verfügbare Lösung..)

Die Zukunft sehe ich definitiv eher in diagram_XX/flot, der RRDtool-patch ist (in anderer Form aber sollte passen) seit dieser Woche übrigens "upstream" - da muss man halt noch was tun (mehrere, ...) aber das ist IMHO der richtigere Weg..

Makki

[JNK]

So, ich habe das mal vorläufig implementiert. In FF und Chrome geht das gut in den discreet_slim und pure-Designs. Da gibts noch ein Rundungsproblem.

Als Attribut wird dem Widget zusätzlich übergeben: rowspan="3" und das Widget nimmt die Höhe an, die 3 übereinanderliegende <text>-Widgets auch hätten.

Gruss,

der Jan

[JNK]

Nachtrag: Es geht in allen Designs. Ein Problem gibt es nur mit <designtoggle />, weil das nur wohl nur die css-Rules ändert, ich aber nur bei Bedarf (d.h. zur Erzeugungszeit des Widgets) rowspan berechne.

Ich lass mir da was einfallen.

Gibts sonst was, was nicht geht?

[Chris M.]

Ein Problem gibt es nur mit <designtoggle />

Bei dem darfst Du "beliebig" rumfurwerken. Das ist kein offizielles Widget, das ist ein Beispiel, wie man selber eigene Widgets schreiben kann.

(Daher wird die Datei structure_custom.js auch bei einem Paket-Update nicht angefasst. => Änderungen daran bekommen nur Neu-Installationen mit)

Gibts sonst was, was nicht geht?

Hab noch nicht geschaut, hoffe dieses WE dazu zu kommen.

[JNK]

Zum designtoggle: das ist schwieriger als gedacht. Ich hab das jetzt so, dass es im Firebug läuft, ohne Firebug nicht.

Was nach einiger Google-Recherche passiert ist folgendes:

Ich erzeuge mit foo=$('...').appendTo('body') ein Objekt. Danach frage ich dann diverse Eigenschaften davon ab. Das klappt aber nur, wenn das Objekt zum Zeitpunkt der Abfrage bereits gerendert ist.

Kein Problem ist das initial, da ist foo quasi sofort verfügbar. Nach einem Design-Wechsel erfolgt die erste Erzeugung aber offensichtlich so schnell nach dem Wechsel des CSS, dass zum Zeitpunkt der Abfrage foo noch nicht berechnet ist. Im Debugger klappt es, wenn man einen Breakpoint zwischen Erzeugen und Abfragen setzt.

Eine richtige Lösung dafür habe ich noch nicht, falls da jemand eine Idee hat... Alles was Google dazu ausspuckt passt nicht so gut.

Gruß,

Der Jan

P.S.: eine Alternative wäre nicht das CSS-file zu switchen sondern die Seite im neuen Design neu aufzubauen. Aber ich weiß nicht, wie man URL-Parameter aendern kann...


Sent from my iPhone using Tapatalk

[hannes loehr]

Hi,

ist vielleicht nicht die feine englische Art, aber vielleicht würde ein setTimeout von 100ms oder so helfen. Ich hatte heute im Büro auch das Problem, dass ich ein ul-mouseleave abfangen wollte bevor ein leave aus dem ul-li gemacht wird und ich wusste da nichts besseres als einen minimalen Timeout. Hat da jedenfalls funktioniert.

Gruß
Hannes

[JNK]

Sowas in der Art schlägt Google auch vor. ich weiß nur noch nicht genau wo das am besten platziert ist.

Danke, das werd ich mir dann nochmal angucken.


Sent from my iPhone using Tapatalk

[hannes loehr]

Ohne jetzt genau deine Stellen in den Sourcen zu kennen, vielleicht auch mal mit einem JQuery-chaining per .each() versuchen:

$('...').appendTo('body').each(function() {
$(this).css({'height':'40px', 'width':'40px'});
});

[makki]

Problem erkannt, wärs dann nicht einfacher, den mittlerweile existierenden Parameter ?design=XX als Designtoggle anzuhängen, URL aufrufen und gut ists?

Eine Designumschaltung zur Laufzeit ist ja wie schonmal diskutiert nur ein schönes "Demo/Entwicklungs-Feature" nichts für die wirkliche Praxis essentielles..

Makki

[JNK]

Makki: finde ich auch, alles was zur Laufzeit in Abhängigkeit vom Design berechnet wird geht sonst schief. Ich hab nur keine Ahnung wie.

Gruß,

der Jan


Sent from my iPhone using Tapatalk

[JNK]

So, schwere Geburt, geht jetzt aber, einschließlich <designtoggle>, bei mir im FF und Chrome und Win7.

In welchen Widgets wollen wir das haben? Im Augenblick gibts das bei <rsslog> und <image>. Mein Vorschlag: bei <text>, <iframe>, <video>.

Und wie soll sich das Verhalten bei widersprüchlichen Angaben, also wenn z.B. rowspan=4 und height=500px bei einem <image> vorgegeben ist? Wer gewinnt? Meine Präferenz: rowspan gewinnt was die Größe des Widgets angeht, und das Bild wird auf 500px angezeigt und an der Widget-Grenze abgeschnitten (overflow:hidden).

Gruss,

der

Jan

[Chris M.]

Und wie soll sich das Verhalten bei widersprüchlichen Angaben, also wenn z.B. rowspan=4 und height=500px bei einem <image> vorgegeben ist? Wer gewinnt? Meine Präferenz: rowspan gewinnt was die Größe des Widgets angeht, und das Bild wird auf 500px angezeigt und an der Widget-Grenze abgeschnitten (overflow:hidden).

Wie schon geschrieben: die height=500px muss sich IMO auf die Bild-Höhe beziehen.

[JNK]

Wie schon geschrieben: die height=500px muss sich IMO auf die Bild-Höhe beziehen.

Ja, aber was wenn die rowspan-Vorgabe kleiner ist als die height-Angabe? Also das Widget soll sich über drei Zeilen erstrecken, was z.B. nur 300px wären, das Bild aber 500px hoch sein. Soll sich dann das Widget erweitern oder soll das Bild abgeschnitten werden? Im Augenblick ist es so, dass das Bild dann einfach über das Widget hinausragt und das sieht nicht aus.

Gruss,

der Jan

[Chris M.]

Ich finde alles diese Möglichkeiten i.O., also Abschneiden, Widget-Erweitern und Widget-Verlassen.

Der Computer sollte stets sinnvoll und vorhersagbar reagieren. Bei dummen User-Input (zwei widersprüchliche Größen...) darf's auch ein hässliches Ergebnis sein, so lange es nachvollziehbar ist.

(Am schönsten dürfte in diesem Fall jedoch ein Abscheiden sein...)

[JNK]

Oder scroll? Für Webseiten bestimmt nicht schlecht.




Sent from my iPhone using Tapatalk

Edit: Das vergessen wir besser mal. Die System-Scrollbalken sehen in den meisten Designs einfach übel aus.