Schlagwort-Archive: HTML

Responsitive Webdesign, ein paar Stolpersteine

Ahh, Responsitive Webdesign, ein Begriff, der momentan in aller Webdesigner Munde ist. Es ist aber auch Reizvoll! Man schreibt einmal eine Webseite und bestimmt anschließend durch Media-Queries, wie diese auf mobilen Endgeräten oder eben dem klassischen Desktop aussieht. Keine Weichen auf Basis des User-Agents, keine Subdomains für die mobile Webseite, alles aus einer Hand. Ja, ich bin auch diesem Trend verfallen und habe – dank Inizializr mit dem Responsitive Design – auch schon Erfahrungen in der Praxis gesammelt.

Für mein aktuelles Projekt soll natürlich auch alles ganz hip werden. Von Anfang an auf Responsivität ausgelegt, selbst bei Bildern und eingebetteten Medien, soll die Seite auf Smartphones, Tablets, Laptops und großen Desktop-Monitoren gut aussehen und bedienbar sein. Gäbe es da nicht die kleinen Probleme…

iFrames! Ich dachte, es wäre recht simple damit umzugehen. Am Beispiel orientiert, habe ich mich selber in der Praxis versucht. Aber ganz puristisch:

iframe {
    width: 100% !important;
    max-width: 600px;
    margin: auto;
    height: auto;
}

Doch leider war es dann nicht ganz so einfach. Derweil eingebettete Bandcamp-Player soweit sehr gut aussahen, wurden Youtube-Videos, die per oEmbed eingebunden wurden, plötzlich gerade mal auf ~150px Höhe geschrumpft. Also: Attribut „height“ wieder aus der CSS-Definition gekickt, alles gut!

Doch derweil mein „margin: auto;“ den Bandcamp-Player schön zentriert darstellt, ist der Youtube-Player immer noch linksbündig. Lange musste ich den unterschied suchen. Es liegt im Attribut „seamless“ des iFrames, mit dem die Player eingebunden werden, Bandcamp setzt das Attribut standardmäßig, derweil es Youtube fehlt. Eine Zeile jQuery-Code hilft mir hier:

$("iframe").each(function(){$(this).attr("seamless", "seamless");});

Facebook-Comments! Obwohl Facebook selber eine sehr gute mobile Webseite hat, scheinen die Social Plugins nicht sonderlich responsitiv zu sein, sondern sind mehr oder minder statisch. Nach einfachem Google um das Problem, fand ich schnell Hilfe:

<style>
.fb-comments, 
.fb-comments iframe[style], 
.fb-like-box, 
.fb-like-box iframe[style] {
    width: 100% !important;
}
.fb-comments span, 
.fb-comments iframe span[style], 
.fb-like-box span, 
.fb-like-box iframe span[style] {
  width: 100% !important;
}
</style>
Advertisements
Getaggt mit , , , , , , ,

Bootstrap, Brackets, Grunt

Irgendwie war es ja klar. Gerade, als ich mit dem Theme für mein neues Projekt fertig war, wurde das GUI-Framework Bootstrap in der neusten Version veröffentlicht. Zwar wusste ich bereits, dass es als RC ansteht, aber hätte nicht gedacht, dass just nach Fertigstellung meines Themes auf Basis von Bootstrap 2.3.2 direkt die Version 3 als Final veröffentlicht wird. Natürlich ist die Abwärtskompatibilität eher bescheiden und bedurfte einiges an manuellen Änderungen…

Mehr oder minder gleichzeitig mit der Release von Bootstrap 3, wurde mir der Open Source Web-Editor Brackets von Adobe wieder in Erinnerung gerufen. Als ich das erste Mal davon hörte, wurde der Editor nur für Windows und OSX angeboten. Nun ist die Linux-Version halbwegs brauchbar, wenngleich einige Macken noch vorhanden sind…

Durch beide Projekte bin ich dann auf Grunt.js aufmerksam geworden. Built-Tools kannte ich bisher nur aus dem Java-Umfeld und weiß um ihre Vorzüge. Beispielsweise entstehen zur Entwicklungszeit viele Daten, die gar nicht erst mit dem Theme veröffentlicht werden müssen. Beispielsweise Gimp-Dateien mit hochauflösenden Bildern und Layern, Javascript-Bibliotheken und Schriften, die man zu Testzwecken mal in die entsprechenden Ordner gepackt hat und so weiter. Natürlich kann man auch alles als Shell-Script mit mv, cp, etc. lösen. Grunt bietet aber mehr. Es erlaubt direkt das übersetzen von SASS in CSS, kann CSS und Javascript komprimieren und noch tausend Dinge mehr. Und da es per Javascript oder Coffee-Script gesteuert wird, ist es für den Frontend-Entwickler schnell zu erlernen.

Der Einstieg war für mich hakelig, das offizielle Getting Started ist leider etwas oberflächlich. Auch die erste deutschsprachige Anleitung hat den ein oder anderen Fehler, erlaubte aber schon einen tieferen Einblick in das Thema. Nach ein oder zwei weiteren englisch-sprachigen Tutorials, habe ich aber schnell zumindest die Grunt-züge (*SCNR*) verstanden und nun eine klare Trennung zwischen Quellcode und fertig packetiertem Theme, das ich einfach nur noch auf den Webspace hochladen muss.

Ob der Overhead von ~20MB für das Grunt-Projekt zu anschließend 900kb Theme gerechtfertigt ist, ist sicherlich fraglich. Erst bei richtig großen Webprojekten, wo man Abhängigkeiten und Tests je nach Built-Ziel dynamisch gestalten muss, wird Grunt.js wohl seine richtigen Vorzüge haben.

Und damit mein kleines Webprojekt, ein Theme mit zwei Bildern, drei PHP-Seiten, drei Javascript-Bibliotheken und einer CSS-Datei, den richtigen Overhead bekommt, versioniere ich das komplette Verzeichnis mit Mercurial.

Nochmal als Zusammenfassung der Frameworks und Helfer für diese eigentlich kleine und einfache Aufgabe:

… manchmal glaube ich, dass diese Techniksache doch eigentlich mehr Selbstzweck ist…

Getaggt mit , , , , , , , , , , , , ,

WordPress, Rollen und iFrames

Wie geschrieben, erstelle ich gerade die technische Grundlage für ein neues Projekt. Dies ist mein erstes privates Weblog, an dem ich mit mehreren Benutzern zusammen arbeite; bisher war ich immer die zentrale Anlaufstelle, die gegebenenfalls die Texte in deren Namen veröffentlicht hat.
Nun ist die Struktur etwas professioneller und autonomer aufgestellt. Ich bin (Super-)Admin, es gibt einen Editor und der Rest ist Autor. Soweit finde ich das Rechtesystem von WordPress klasse.

Nun gab es aber ein Phänomen: Ein Autor wollte einen Bandcamp-Player in einen Beitrag einbinden, hat nach meiner Anleitung den Embed-Code von der Seite kopiert und in seinen Beitrag eingebunden. Nach der Veröffentlichung, verschwand aber der Player und hinterlies nur den Link zur Bandcamp-Seite zwischen zwei <code>-Tags.

Zunächst vermutete ich Probleme in der Filterung durch den eingebauten TinyMCE. Ich schreibe meine Artikel immer im Text-Editor, aber als HTML-unkundiger Autor, hat der Kollege lediglich den Embed-Code im Text-Editor eingefügt und den Rest des Beitrages per WYSIWYG geschrieben. Einige (teilweise zwar ältere) Beiträge aus Foren beschrieben Probleme beim Wechsel zwischen textuellem und visuellen TinyMCE, weswegen ich eine eigene Filterregel in meiner functions.php implementierte.

Doch das Problem bestand weiterhin. Kurzerhand habe ich mir selber einen Test-Account mit Autorenrechten angelegt und selber probiert. Das Ergebnis: Auch bei mir verschwand nun der Player und wurde durch einen Link ersetzt. Weitere Recherchen brachten heraus: Es liegt am Rollen- und Rechte-System von WordPress; dem Autor fehlt die Fähigkeit „unfiltered_html„.Um diese Fähigkeiten den Autoren – zumindest zur Verwendungszeit meines Themes – zuzuweisen, habe ich die functions.php erweitert:

  
  function add_author_capabilities() {
    // Rolle holen
    $role = get_role("author");     
    // Der Rolle die Fähigkeit zuweisen
    $role->add_cap("unfiltered_html"); 
  }
  // Funktion registrieren
  add_action("admin_init", "add_author_capabilities");
Getaggt mit , , , , , ,

Ein neues Web-Projekt: Die technischen Hintergründe

Aktuell arbeite ich an einem neuen Projekt, einem neuen Blog um Musik. Die Seite wird selber gehostet und entsprechend muss etwas vorarbeit geleistet werden.

Das Backend übernimmt wieder WordPress. Es ist einfach ein etabliertes CMS/Blogging-System, mit guter Community und vielen Plugins.

Für das Frontend stand ich wieder vor der Wahl: Ein fertiges Theme nehmen? From Scratch alles selber schreiben? Oder eine Starthilfe nehmen? Mein letztes Theme habe ich mit der Responsive-Konfiguration von Initializr gemacht und war damit eigentlich zufrieden. Doch kürzlich las ich einen Artikel über die Gestaltung von WordPress-Themes mit Bootstrap. Initializr bietet auch Responsive Bootstrap als HTML/CSS Template an. Zwar noch in Version 2.3.2, derweil Bootstrap selber bereits bei 3.0 ist, wenngleich nur als RC2. Aber für den Anfang reicht es. Vielleicht folgt auf die Final Release auch ein Upgrade in meinem Webprojekt.

Anfangs war das Arbeiten etwas ungewohnt. Doch als ich das Grid-System verstanden hatte, machte das Scaffolding richtig Spaß und führte schnell zu ansehnlichen Ergebnissen. Da ich ein sehr minimalistisches Theme haben wollte, und auf eine Sidebar verzichte, benötigte ich vergleichsweise wenig HTML und CSS-Code.

Beim CSS habe ich mich für einen Pre-Processor entschieden, weil DRY – Don’t Repeat Yourself. Ich nutze für Farben und andere Werte gerne Variablen, die ich zuweisen kann. Außerdem liegt mir die Schachtelung/Wiederverwendung der Pre-Processor mehr, als von CSS selber. Nach dem Vergleich von Less zu Sass, habe ich mich für Sass entschieden.

Für geringes Eye-Candy, ein paar aufklappende Elemente, Sticky-Divs, etc., bleibe ich beim gewohnten jQuery. Nichts besonderes und eigentlich der De Facto Standard in der Webentwicklung.

 

Interessanter war eher die strategische Frage um die Handhabung der Kommentare. Wenn man die eigenen Hausmittel von WordPress verwendet, muss man sich zuerst mit dem Layout des Formulars rumschlagen – keine einfache gestalterische Frage, da muss man nur mal Tante Google fragen. Anschließend muss man sich mit Spam rumschlagen. Egal, ob man mit Akismet (problematisch mit Datenschutz und ab wann eine Webseite als „kommerziell“ gilt) oder Antispam Bee schützt.

Bisher habe ich auf Disqus vertraut, was sich bei mir und vielen ähnlichen Blogs gut bewährt hat. Doch leider musste ich feststellen, dass die meisten Kommentare mittlerweile nicht mehr auf der entsprechenden Seite selber, sondern bei Facebook passieren. Inspiriert durch einen Artikel aus der CT, der zu ähnlichem Schluss kommt, probiere ich nun dessen Kommentarfunktion aus.

Getaggt mit , , , , , , , , ,