Beiträge von dekonstruktiv

    Diese Einstellung müsste im Backend des Hosts oder in der entsprechenden Webmail-Applikation (des Hostings) zu finden sein, denke ich.
    Wenn eine Signatur per Standard "am Server" eingestellt wird, müsste diese beim Versenden eingebunden werden,
    auch wenn man sie während des Schreibens nicht sieht.

    Natürlich lebt jede Methode von optimalen Gegebenheiten wie gescheiten Resets und gründlicher Struktur, nicht wahr?
    Und Anforderungen die wir nicht kennen hinzu zu dichten tut auch nicht viel zur Sache, keiner der Lösungen ist viewportübergreifend sicher,
    besonders wenn das Layout unbekannt ist.


    Ich sagte nicht dass es falsch gelöst sei, sondern dass das eigentliche Problem einfach übergangen wurde.

    Das ist mal so semi-korrekt gelöst und erklärt...
    Originalcode funktioniert nicht, da float das Element nach der table-cell Definition
    wieder in einen besonderen block-Element Zustand versetzt - lookie


    Ich sehe kein Problem ein fieldset oder ähnliche wrappings als Tabelle zu verkleiden,
    es wäre die sichere Variante - die Wahl der Methode ist natürlich Zielgruppenabhängig.



    // edits: ORRR!

    Ich lege hierfür in jedem Projekt eine Klasse mit dieser clearing-Methode an um diese an Elternelemente zu vergeben.
    Grundsätzlich gibt es in nahezu jedem Layout Elemente, die so korrigiert werden müssen, selbst wenn es optisch nicht auffällig wie in einem ul mit gefloateten li.
    Das Snippet (wenn auf lt IE8 geschissen wird) sieht dann so aus:

    Code
    1. .clearfix:before, .clearfix:after { content: ""; display: table; }
    2. .clearfix:after { clear: both; }
    3. .clearfix { *zoom: 1; }


    Es gibt eine weitere Methode dem Elternelement overflow: hidden zu vergeben, welche ich für kurzsichtig halte, da dieser spezielle block-Element Zustand durch eine fixe Höhe die Funktionalität der Kinderelemente behindert - auch wenn sie funktioniert. So viel zu best practice.

    ich arbeite garnicht mehr mit <div>s. Die brauch man gar nicht mehr.


    Und mit welchem tollen HTML5-Element definierst du einen einfachen Container der als Stylingelement für Konturen oder Schatten dienen soll?
    Dein persönlicher Entwicklungsstil sollte nicht auf Behauptungen beruhen, lies besser die W3C specs und verwandte Artikel : )


    Dem Fragesteller empfehle ich allerdings verstärkt mit Klassen zu arbeiten, welche sich bei Vererbungen leichter überschreiben lassen und auch noch weitere Vorteile mit sich bringen.
    Google Chrome bietet in seinen Entwicklertools eine Simulation für Handheldgeräte welche du für Layouttests nutzen kannst. Eine reale Testumgebung für Funktionalität
    bieten aber nur die entsprechenden Geräte und deren Browser.

    Ich verstehe die Freude, dass HTML-Tags endlich vermehrt ihren Inhalten zugeordnet werden dürfen.
    Trotzdem müssen auch die neuen semantischen Stückchen mehrmals verwendet werden und sollten keinesfalls als ID- oder Klassenersatz "missbraucht" werden.
    Wenn es um gute Architektur geht bleibt die Selektierung in CSS also die Selbe.


    Ich verstehe den Ärger, dass Schnittstellen eventuell mit aktuellen Standards auffahren und den Quelltext zerzausen.
    Aber es wird immer Neuerungen und Verbesserungen geben, wie damals, als sich alle von Layouttabellen abgewandt haben. Daraus sollte kein Graul entstehen,
    sondern eine Möglichkeit, dem Kunden zu verdeutlichen dass es nach 2-3 Jahren wieder an der Zeit ist sich den Gegebenheiten anzupassen und zu optimieren -
    und schließlich auch wieder etwas zu verkaufen.


    Ein Auto will auch regelmäßig gewartet werden.

    In solchen Fällen immer in den Dev-Tools der Browser nachsehen, welches Regelset weiter oben dargestellt wird bzw. welche Regel durchgestrichen wird. Durch die beigefügten Zeilennummern und Dateinamen lassen sich dann Ursachen schnell ausmachen.


    Die Kaskade funktioniert nunmal auch Dateiübergreifend : )

    Das musst du grundästzlich von den Inhalten abhängig machen und normalerweise tut man dies in der Planungsphase.
    Wohlmöglich wäre es in deinem Fall eine gute Chance dich in das Thema responsive webdesign einzuarbeiten.
    Eine komprimierte mobile Version verfügt lediglich über eine andere Content-Strategie, im besten Fall ist diese auch responsive da es zahlreiche handheldviewports gibt.


    ugurus stellt ein umfassendes "Knowledge Hub" bereit,
    da solltest du dir alle Fragen selbstständig beantworten können.

    Die Intension ein paar Bytes zu sparen und statt einer Bilddatei ein wenig CSS zu nutzen ist zwar verständlich,
    allerdings verstehe ich das Problem ebenfalls nicht ganz.


    float / display und margin können dir helfen das umzusetzen.