e7o.de » // blog

Über dieses Blog...

»Wenn ich einmal alt bin, werde ich nur nörgeln — das wird ein Spaß!«

Tipps und Tricks, aber auch Kritik - breit gefächert von Technik bis hin zum Design, manchmal (oder immer öfter) auch Politik.

Feeds

Interessant gefunden? Mitlesen? Vollständige Beiträge per Feed.

RSS 2, Atom

Zur Weiterverarbeitung oder zum Einbauen für Ihre Homepage: CSV, JavaScript

Durchsuchen

Tipp: AND & && OR | || XOR - ! NOT ( )

Kategorien

Archiv

Einträge im März 2010

Mo	Di	Mi	Do	Fr	Sa	So
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

Beiträge im Archiv zeigen

CSS: Feste Spaltenbreite für Navigation

Von e7 am 07.02.2010, 19:52 in der Kategorie Zwischendurch... mit den Tags float sauber trennung design layout css html. Kompletten Eintrag zeigen

Aus der Kategorie „zu wenig Befehle in CSS und vor allem doofer IE“.

Stark vereinfachtes HTML:

<html> <body> <div id="content"> Lorem Ipsum und lauter so Zeugs… </div> <ul id="navigation"> <li><a href="1.htm">Link 1</a></li> <li><a href="2.htm">Zweiter</a></li> <li><a href="3.htm">Am Schluss</a></li> </ul> <div id="footer">Copyright oder so</div> </body> </html>

Problemstellung: Die Navigation soll links neben dem Inhalt stehen, der Footer drunter — egal, was länger ist: der Inhalt oder eben die Navigation. Weitere Bedingung ist, dass der Inhalt keine Breitenangabe bekommt, also weder 75% oder 300px oder sonst was. right und andere CSS-Angaben sind tabu, es soll ja zumindest ansatzweise im IE > 6 dargestellt werden. Und natürlich kein überflüssiger HTML-Code in Form von <div> um die Sache klatschen, die Navigation soll im HTML auf jeden Fall nach dem Inhalt bleiben etc.

Auf der Suche nach einer Lösung bin ich auch mal wieder über YAML gestolpert — ich nutz das Zeugs nicht, ich bastel normalerweise selbst. Dann weiß ich wenigstens, was ich wo hab und weiß auch, dass nicht viel überflüssiges dabei ist. Aber zum Anregungen holen… warum nicht?

Dummerweise hat Yaml zwar was in die Richtung, aber man muss — damit die Lösung funktioniert — immer eine Breite für den Inhalt angeben. Also entweder 75% — was die Navigation zu 25% verdonnert — oder ein Pixelwert, was für den Inhalt gerade überhaupt nicht geht. Aber Navigation mit festem Pixelwert, daneben den Inhalt von festen Pixelwert bis zum rechten Rand geht nicht. position:absolute klappt nicht, wenn die Navigation (oder der Inhalt, je nach Optimierung) kürzer ist — auch keine Lösung also.

Gut, dass ich im Hinterkopf noch die Wikipedia habe, die genau so ein Design umsetzt, das ich mir vorstelle. Aus den vielen CSS-Dateien und HTML-Code mal abstrahiert, was die denn da so machen:

<div style="width: 100%; float: right; margin-left: -150px;"> <div style="margin-left: 200px;"> Mitte </div> </div> <div style="width: 150px;"> links</div> <div id="footer“ style="clear: both;">unten</div>

Klappt eigentlich wie's sollte — allerdings ist da oben nun wieder ein unschönes, aus HTML-Sicht betrachtet überflüssiges <div>, was ich eigentlich vermeiden wollte.

Sieht fast so aus, als gäbe es da keine wirklich gute Lösung, oder?

UPDATE Der Fall anders herum ist auch gerade aufgetreten: Ich benötige rechts eine Sidebar, die eine feste Breite hat, links soll sich der Inhalt auf dem restlichen Platz verteilen. Dabei soll die Sidebar nach dem Inhalt im HTML-Code auftauchen; leider lässt sich auch hier ein Extra-Element nicht vermeiden:

<div style="margin-right: 230px;"> <div style="float: left; width: 100%;"> Links: Inhalt, beliebig groß </div> <div style="float: right; margin-right: -220px; width: 200px;"> Rechts: Sidebar, feste Breite </div> </div>

Auch das funktioniert erstaunlicherweise wieder mit dem IE7 ohne spezielle Anpassungen.

Das Schimpfen auf falsch interpretierte Standards...

Von e7 am 05.02.2009, 12:00 in der Kategorie Kopfschüttelnd... mit den Tags bug standard rfc header html http bashing firefox mozilla gecko. Kompletten Eintrag zeigen

Was ist der Unterschied zwischen den folgenden beiden Zeilen?

header(„Content-Disposition: attachment; filename=\"blubb\"“);
header(„Content-Disposition: filename=\"blubb\"; attachment“);

Ganz einfach: die erste Zeile funktioniert, die zweite nicht. Und jetzt die große Preisfrage: Warum ist das so? Eigentlich ist diese Frage noch viel leichter zu beantworten: Es ist so definiert. RFC 2183 gibt nähere Auskunft:

disposition := „Content-Disposition“ „:“
disposition-type
*(„;“ disposition-parm)

Daraus wird eigentlich relativ klar ersichtlich, dass disposition-type (also inline oder attachment) zuerst steht und anschließend die optionalen Parameter auftauchen — was ja soweit auch logisch und nachvollziehbar ist.

Nächste Preisfrage: Wo stehen diese Angaben? Auch ganz einfach: im HTTP-Header.

Nun ist mir allerdings eben die tolle Seite vb-fun.de über den Weg gelaufen. Das Design ähnelt (vor allem in den drei Farbrechtecken oben links) einer berühmten Frontpage-Vorlage und lässt auch dadurch eine gewisse Microsoft-Verbundenheit vermuten. Nun les ich allerdings in deren Downloadhinweisen folgendes:

Bei einigen Software-Firewalls (Norton) und Browsern (z.B. Opera, Mozilla) ist die Übergabe des HTTP-Referrers standardmäßig abgeschaltet.

Ich wüsste nicht, dass mein Mozilla seine HTTP-Requests standardmäßig ohne Referrer bildet. Es gibt Extensions, die das möglich machen, aber default — nein. Soweit allerdings nicht so schlimm — was man nicht einsetzt, kennt man nicht so gut. Vielmehr ist mir das Gecko-Bashing aufgefallen:

Dies passiert, wenn Sie Browser wie den Mozilla oder Firefox einsetzen. Leider ignorieren diese von Ihrer Fangemeinde so hochgelobten Browser beharrlich den HTML-Standard.
Nach diesem Standard gibt es sogenannte HTML-Header. Unser Script versendet gemäß dieses Headers ein Zip-Archiv. Leider sehen die vorgenannten Browser das allerdings etwas anders. Benennen Sie die erhaltene Datei einfach in die von Ihnen angeforderte *zip-Datei um. Beispiel (Datei „Tip.pl“ erhalten, umbenennen in z.B. „tip0210.zip“)

Und jetzt zum Vergleich das, was das Script wirklich sendet:

HTTP/1.1 200 OK
Date: Thu, 05 Feb 2009 10:34:31 GMT
Server: Apache/1.3.37 (Unix)
Content-Disposition: filename="Wellen.zip"; attachment
Content-Length: 55877;
Keep-Alive: timeout=3, max=100
Connection: Keep-Alive
Content-Type: application/octet-stream;
PK(und-jetzt-ca-55875-Bytes)

Wenn wir uns jetzt an unser allgemeines Grundwissen sowie meine vorher aufgeführten Punkte erinnern, könnte es einem dämmern, warum Firefox den HTML-Standard ignoriert.

Erstens: Die Informationen über die Datei befinden sich im HTTP-Header und nicht im HTML-Header. Also kann folglich eigentlich kein Browser die Angaben nach HTML-Standard befolgen — zusätzlich ist das ganze ja eigentlich eine ZIP-Datei.

Zweitens: application/octet-stream ist zwar alles, aber kein ZIP. Funktioniert unter Windows zwar genauso, widerspricht allerdings der Aussage „Unser Script versendet gemäß dieses Headers ein Zip-Archiv.“

Drittens: Wären wir bei der Reihenfolge der Angaben in Content-Disposition. Nachdem hier disposition-type mit filename=irgendwas angegeben ist, kennt das natürlich kein korrekter Browser.

Jetzt ist noch die Frage, warum es im Internet Explorer klappt. Sicher nicht, weil er irgendwelche Standards beachtet. Wohl eher, weil der Internet Explorer alles versucht zu interpretieren…

Mal schauen, wie die von vb-fun.de reagieren. Entweder das Problem löst sich wie von selbst, oder es wird fröhlich weitergebasht. Die Zeit läuft :)

Edit, 13.10 Uhr: Das Problem scheint behoben zu sein, zumindest wird mir jetzt in SeaMonkey der richtige Dateiname angezeigt. Der Satz auf der Website hat sich verkürzt in: Dies kann passieren, wenn Sie Browser wie den Mozilla oder Firefox einsetzen. Das ging ja richtig schnell, wenn auch noch das Stichwort Firefox enthalten ist…

Gecko-Engine mit Textschatten...

Von e7 am 02.09.2008, 16:14 in der Kategorie Gut zu wissen... mit den Tags schatten gecko seamonkey html css. Kompletten Eintrag zeigen

Gerade bin ich ins Stutzen gekommen: Verschwommener Text, so ein Schatten hinter der Überschrift? In der Regel wird der betreffende Text einfach zweimal ins HTML gesetzt, und dann ist nix verschwommen… Scheinbar beherrscht die Gecko-Engine inzwischen die CSS-Eigenschaft text-shadow und keiner hats mitbekommen… Getestet mit SeaMonkey vom 13. August. FF 3.0.1 kanns noch nicht. Auf jeden Fall merken und beobachten :)

Alle Nachrichten finden Sie im Archiv.