Beiträge von threadi

    Der HTML-Code selbst ist schonmal sehr fehlerhaft.

    Du verwendest z.B. <center>, welches man eigentlich gar nicht mehr nutzen sollte (Zentrierung wird per CSS erreicht) und noch dazu steht es an einer Stelle an der es nicht hingehört (zwischen <ul> und <li> darf nichts anderes stehen).

    Außerdem gibt es das Element <list> nicht beim XHTML 1.0-Standard, welchen dein Doctype angibt.

    Mach erstmal den HTML-Code valide bevor Du sich weiter um die Darstellung kümmerst.

    Du beziehst dich auf E-Mails die sowohl HTML als auch Text enthalten. Das E-Mail-Programm des Empfängers entscheidet dann je nach Einstellung, ob das HTML-Format der E-Mail angezeigt wird oder nicht.

    Um E-Mails die sowohl HTML als auch Text verschicken zu erzeugen, musst Du dich mal das E-Mail-Format genauer anschauen. Mit HTML hat das nämlich rein gar nichts zu tun. Die E-Mail muss nämlich in verschiedene Bereiche getrennt werden, Teile des Multiparts:
    - den Bereich mit dem Content-type text/html der HTML-Code und somit die HTML-Ansicht der E-Mail enthält
    - den Bereich mit dem Content-type text/plain der keinen HTML-Code und somit die rein textliche Ansicht der E-Mail enthält

    Ein Beispiel dafür habe ich gerade für Dich unter
    http://www.dominik-boecker.de/email/beispiel.html
    gefunden. Weitere findest Du wenn Du mal nach multipart suchst.

    Selbst kannst Du natürlich solche E-Mails auch verschicken. Wenn Du die E-Mail auf dem Server zusammenbaust, musst Du vor der Übergabe dieser E-Mail an den MTA den Inhalt der E-Mail genau so trennen wie es für Multipart-E-Mails vorgesehen ist.

    Noch ein paar Infos:
    http://www.wilsonweb.com/wmt5/html-email-multi.htm

    Die richtige URL lautet:
    http://rabidwolverine.ra.funpic.de/index.html

    Und dort sehe ich einen grauenhaften HTML-Code dem auch ein Doctype fehlt.
    http://validator.w3.org/check?verbose=…de%2Findex.html

    Kein Wunder, dass die Browser machen was sie wollen.

    Das hier

    PHP
    <meta charset="utf-8" />

    ist auch keine korrekte Angabe eines Zeichensatzes. Zudem liefert dein Webserver im Header (hat nichts mit dem HTML-Code zu tun!) den

    Code
    Content-Type: text/html; charset=ISO-8859-1

    zurück, weshalb Du entweder alle Zeichen in ISO-8859-1 kodieren müsstest oder deinen Webserver entsprechend umstellen müsstest, dass er utf-8 oder gar nichts als Zeichensatz zurückliefert. Die Browser richten sich immer primär nach der Angabe im Header, nicht nach der Angabe im HTML-Code.

    Außerdem bitte die Tipps von MrMurphy beachten. Ich würde auch dringend empfehlen das Tabellengrundgerüst sowie die Verwendung von Bildern statt richtigen Texten zu überdenken. Diese besondere Schriftart kann man, wenn man die Rechte dafür hat, auch in die Webseite einbetten.

    Ein Produktkonfigurator ist immer eine Individuallösung, denn Produkte die sowas ermöglichen sind immer unterschiedlich. Selbst bei Schuhen kann man nicht alles so sehr vereinheitlichen, dass man diese in einem Konfigurator zusammenstellen kann, ganz zu schweigen von den Produktionskosten. Aber möglich ist es alle mal - nur weil es eben Individual ist, muss man zunächst alle Details definieren. Nur dann kann man auch einen Preis dafür schätzen. Wie gesagt: nicht alle Produkte sind gleich.

    Und auch die Bezahlung von einem so zusammengestellten Produkt kann sehr unterschiedlich sein. Es stehen Dutzende Zahlweisen zur Verfügung. Manche erleichtern den Kauf den Kunden, andere wiederum dem Verkäufer, einige auch beiden. PayPal, soforueberweisung.de, Kreditkartenzahlung .. alles ist möglich - alles kostet aber auch je nachdem, welches System die Grundlage für die Webseite ist, auch mehr oder weniger Geld.

    Da der Konfigurator quasi eine Individuallösung wäre, müsste man auch die Zahlungen und die Verwaltung des ganzen individuell programmieren. Nach meiner Erfahrung geht sowas selten unter einem 4stelligen Betrag. Monatliche Kosten für Hosting, Domain, Support .. kommen noch dazu.

    Mein Tipp: such dir einige Agenturen raus die dir sowas zusammenstellen könnten und fordere von denen auf Basis eines detaillierten (!) Lastenheftes ein Angebot an.

    JOINs haben den Nachteil, dass sie innerhalb der Datenbank-Engine mehr Abfragen erzeugen. Führe mal ein Explain und Miss die Zeit für ein Statement mit JOIN aus und mach das selbe nochmal mit WHERE. Ich habe die Erfahrung gemacht, dass man auf JOIN besser verzichten sollte. Die Geschwindigkeit, gerade bei großen Datenbanken, kann dadurch noch gesteigert werden. Die Übersichtlichkeit kann man dagegen mit einer ordentlichen Einrückung und Zeilenumbrüchen einfach erreichen.

    CSS-Regeln werden in der Reihenfolge abgearbeitet in der sie in der CSS-Datei stehen. Die Reihenfolge der Klassen im HTML-Code spielt keine Rolle. Und das interpretiert nicht Plone sondern dein Browser, daher ist der Firebug durchaus hilfreich.

    Relevant ist der HTML-Code der in deinem Browser ankommt. Nicht der Quellcode der als Grundlage für die Generierung genutzt wird. Also zeig den Link zur betreffenden Seite oder den HTML-Code den Du in deinem Browser siehst. Ansonsten kann man nur raten was "navTreeCurrentItem" nun für eine Bedeutung hat.

    Dein Missverständnis beruht in der Funktion der Pseudoklasse :active. :active wirkt nicht, wenn Du gerade auf der Seite bist die dort verlinkt wird sondern nur wenn man mit der Maus dieses Element gerade anklickt. Siehe: http://www.css4you.de/active.html

    Wenn Du willst, dass der Menüpunkt auf dem man sich befindet (ohne, dass die Maus den Link berührt oder anklickt) anders gefärbt wird, gib diesem Link eine Klasse.

    HTML

    Code
    <a href="beispiel.html" class="aktiv">Beispiel</a>

    CSS

    Code
    a:link, a:visited {text-decoration:none;
    color:#A86232; }
    a:hover, a.aktiv:link, a.aktiv:visited {text-decoration:underline;
    color:#8F2323; }

    Da Du nicht den HTML-Code gezeigt hast, kann ich natürlich nur vermuten, dass es daran liegt. Denn der Zusammenhang zu .navTreeCurrentItem erschließt sich mir nicht.