Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

May 03 2017

finkregh
repeat after me: dont let javascript from some 3rdparty domain render you website...
Reposted byit-failLykoucoloredgrayscale

December 06 2011

November 21 2011

finkregh

Damit hätte ich nicht gerechnet! Auf mein lapidares Twitter-Gestöhne, man könne doch nicht <p></p>, <br><br><br> oder &nbsp;&nbsp;&nbsp; verwenden, um sich Abstände in HTML/CSS-Layouts zurechtzuzimmern, kamen einige ernstgemeinte Rückfragen in Richtung: »Wie sollen wir es denn dann handhaben?« Dafür dieser Artikel.

Zunächst einmal: Der Grund, warum oben genannte Abstandstechniken uncool sind, ist eine Vermischung von Struktur und Styling. Ich packe damit das Styling-Vorhaben »horizontaler Abstand« und »vertikaler Abstand« in den HTML-Code, wo es nicht hingehört. HTML ist für die logisch-hierarchisch-semantische Struktur zuständig, und im CSS kümmert man sich um alles, was visuell zum Styling beiträgt, also auch die Abstände.

Für entsprechende vertikale Abstände nutzt man selbstredend margin und padding, und beschreibt damit die gewünschten Abstände vor und nach bestimmten Headlines und Absätzen. Gerne auch mittels :first-child oder :nth-child() die Abstände zwischen schwerer zu greifenden Konstellationen. Auch der Plus-Selektor (.content ul + p) kann wertvolle Dienste leisten, um dort Abstände zu setzen, wo sie sinnvoll sind.

Doch manchmal ist die Konstellation des Inhalts etwas ungünstig, denn man möchte bisweilen an bestimmten Stellen Abstände haben, wo vielleicht gerade kein besonderes Strukturelement gesetzt ist, der diesen Abstand mit sich bringt. Wenn man also in Gottes Namen ins HTML eingreifen muss, um genau zu definieren, wo denn nun der Abstand hin soll, verwendet man in der Regel das class-Attribut, hängt es an bestehende Elemente (z. B. p oder ul) und denkt sich sinnvolle Klassennamen aus, an die man dann per CSS Abstand zuweist.

Nicht cool sind dabei Klassen wie .large-space-top oder .bottom35, denn dabei handelt es sich um de-facto-Styling-Angaben. Auch diese haben in HTML nichts zu suchen.

Besser wären Klassen wie .teaser, .new-section oder keep-seperated, denn dabei wird ein wenig Semantik deutlich: Man beschreibt mit den Klassen die Funktion, die dieses HTML-Element erfüllt, und kann das im CSS mit den gewünschten Styling-Regeln hübsch machen. Ist mehr Denkarbeit, letztlich aber sinnvoll, denn man bleibt im CSS flexibel und kann statt 35 Pixel auch später mal auf 45 Pixel hochgehen, wenn es besser aussieht. Und im HTML steht dann diese blöde 35er-Klasse nicht fälschlicherweise herum!

In der Horizontalen sieht’s ähnlich aus. Statt:

<div class="timing">17.11.2011&nbsp;&nbsp;–&nbsp;&nbsp;19.11.2011</div>

schreiben wir im HTML lieber:

<div class="timing"><span class="from">17.11.2011</span>–<span class="to">19.11.2011</span></div>

Klar, das ist länger. Aber ich habe zwei wunderbare Haken, an denen ich flexibel handhabbare CSS-Regeln festmachen kann, die über padding-right: 20px; oder padding-left: 16px ganz exakt den Abstand der beiden Datumsangaben definieren können.

Also: Scheut nicht die Arbeit! Haltet das HTML sauber und denkt euch ordentliche, bedeutungsschwangere HTML-Klassennamen aus, dann klappt’s auch bei der Code-Übergabe zu einem anderen Frontend-Entwickler.

Individuelle Abstände in HTML/CSS: So geht’s! | praegnanz.de

November 12 2011

September 21 2011

September 11 2011

August 16 2011

August 09 2011

Requests: HTTP for Humans — Requests v0.5.1 documentation

Most existing Python modules for sending HTTP requests are extremely verbose and cumbersome. Python’s builtin urllib2 module provides most of the HTTP capabilities you should need, but the api is thoroughly broken. It requires an enormous amount of work (even method overrides) to perform the simplest of tasks.

Things shouldn’t be this way. Not in Python.

>>> r = requests.get('https://api.github.com', auth=('user', 'pass'))
>>> r.status_code
200
>>> r.headers['content-type']
'application/json'

See the same code, without Requests.

Requests allow you to send HEAD, GET, POST, PUT, PATCH, and DELETE HTTP requests. You can add headers, form data, multipart files, and parameters with simple Python dictionaries, and access the response data in the same way. It’s powered by urllib2, but it does all the hard work and crazy hacks for you.

June 19 2011

LearnBoost/stylus - GitHub

Stylus is a revolutionary new language, providing an efficient, dynamic, and expressive way to generate CSS.
Reposted bysciphex sciphex

NodeCloud - Node.js resources

NodeCloud is a resource directory gathering sites related to Node.js and ordering them by their Alexa traffic, allowing to evaluate relative popularity of a project.

May 19 2011

December 29 2010

Less Framework 3

Less Framework is a cross-device CSS grid system based on using inline media queries.

The idea is to first create a default layout normally, and then additional layouts using inline media queries. Any browsers incompatible with media queries will simply ignore all the additional layouts, and will only use the default one. The additional layouts will inherit any styles given to the default layout, so coding them is a breeze.

December 13 2010

Webkrauts » Formulare auf der Höhe der Zeit

Neben neuen strukturellen Elementen und der nativen Wiedergabe von Audio und Video beschert HTML5 auch einige Neuerungen im Hinblick auf Formulare. Damit nimmt sich die Web Hypertext Application Technology Working Group (WHATWG) sowie das W3C der bisher sehr limitierten Funktionalitäten eines der wichtigsten Interaktions-Elemente des Internets an. Wer jedoch die Diskussionen rund um HTML5 verfolgt hat, fragt sich nun zu Recht, ob diese Neuerungen jetzt schon verwendet werden können. Hier kann ich mit einem klaren »Ja« antworten. Auch wenn noch nicht alle Browser (und manche bisher nur sehr rudimentär) die neuen Formular-Funktionalitäten von HTML5 unterstützen, können die Nachzügler mit ein wenig jQuery-Feenstaub dazu gebracht werden, diese zumindest zu imitieren.

Webkrauts » Zentrieren ohne zusätzliches Markup

Wer ein zentriertes Webseitenlayout entwickeln möchte, verwendet oft den typischen »Wrapper-Div« (<div id="wrapper"></div>). Dieser wird meist einmal um den gesamten Inhalt der Seite gelegt und per CSS mit automatischen Abständen zu den Rändern in der Mitte des Bildschirms platziert (margin: 0 auto;). Dieses zusätzliche und in der Regel überflüssige Markup lässt sich in den allermeisten Fällen vermeiden.

November 11 2010

November 09 2010

finkregh

Ich habe noch einen halbfertigen Rant auf Halde, in dem ich am Beispiel eines gewissen, aus unerfindlichen Gründen populären E-Commerce-Systems (dessen Name mit M anfängt und mit agento aufhört) auf Websites schimpfe, die ohne JavaScript nicht funktionieren. Da ich mir aber ziemlich sicher bin, dass ich mich dort gleich mehrfach im Ton vergriffen habe, lösche ich diesen Text jetzt und lasse Jenn Lukas sprechen. Die gute Frau bringt die wichtigsten Gründe nämlich in wesentlich zivilisierterer Form vor, als ich mir das gelingen würde und liefert uns einen schönen kurzen Vortag, den man wunderbar als Munition gegen die meine-Website-muss-ohne-JS-nicht-funktionieren-Fraktion verwenden kann:

Jenn Lukas - JSConf 2010 auf Blip.tv

Alle guten Gründe hin und her – was mich an JS-untauglichen Webseiten mehr als alles irritiert, ist dass es sie überhaupt gibt. Wenn man nur kurz überlegt, bevor man draufloshackt, passieren ohne JS benutzbare Websites wie von selbst. Unobtrusive JavaScript ist kein Hexenwerk, sondern, sofern man seine Auszeichnungs- Gestaltungs- und Script-Schichten sauber trennt, fast unvermeidlich. Um Seiten zu bauen, die nur mit JavaScript funktionieren, muss man sich richtiggehend anstrengen. Und mir ist nicht wirklich klar, was in den Köpfen jener vor sich geht, die sich diese Mühe machen und derartiges HTML an die Öffentlichkeit lassen:

<button type="button" class="button" onclick="productAddToCartForm.submit()"><span><?php echo $this->__('Add to Cart') ?></span></button>
<button type="button" class="button" onclick="productAddToCartForm.submit()"><span><?php echo $this->__('Add to Cart') ?></span></button>

Klar, wenn man ein hyper-dynamisches neues Webapp rund um neueste JavaScript-Features herum konstruiert und das Projekt ohne JS prinzipbedingt nicht funktionieren könnte, wäre das etwas anderes. Aber eine herkömmliche Website oder einen Onlineshop mutwillig oder fahrlässig fest an JS zu binden, ist, als würde man über das Schiebedach in ein Auto einsteigen. Das kann man sicher so machen, aber wenn vorher nur kurz nachdenkt und entsprechend plant, kommt man ohne zusätzliche Mühen auch anders in die Karre – und sieht dabei dann auch nicht aus wie ein Vollhonk.

Warum Websites ohne JavaScript zu funktionieren haben • Peter Kröner, Webdesigner & Frontendentwickler
Reposted bydatenwolfIntekrannix
Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl