DECAF° blog für digitale kommunikation » CSS

»Reset Reloaded«: Browserstyles zurücksetzen

Dirk Schürjohann — Tue, 01 May 2007 13:13:45 +0000

Browser tragen bekanntlich ein internes Basisstylesheet mit sich rum, das auf jedes Dokument angewendet wird, um eine Grundstruktur zu erreichen. Das ist sinnvoll und sorgt dafür, dass auch Dokumente ohne ein eigenes Stylesheet strukturiert sind: Überschriften werden hervorgehoben, Textabsätze haben einen Abstand nach unten, Listen werden eingerückt, etc.

Bei der Umsetzung von Websites geraten Webautoren jedoch gerne mal in Konflikt mit den Basisstyles des Browsers, wenn sie es verpassen, die Browservorgaben durch eigene Angaben zu überschreiben. Das, was bei der Kontrolle auf dem eigenen System dann wie gewollt aussieht, kann beim Nutzer unter anderen Bedingungen verfälscht werden. Ein typisches – wenn auch seltenes – Beispiel dafür ist, dass verpasst wird, eine Hintergrundfarbe für den body zu definieren, weil der Webautor von einem weißen Hintergrund ausgeht. Im Regelfall wird der Benutzer dann auch einen weißen Hintergrund erhalten, weil es die Standardvorgabe nahezu jedes Browsers ist, jedoch lässt sich der Farbwert meistens in den Browsereinstellungen verändern, so dass es durchaus vorkommen kann, dass aus Weiß ein freundliches Pink oder ein himmelblaues Grün wird.

Aus Sicht des Webautors kann es deshalb sinnvoll sein, Browservorgaben zu Beginn seiner Stylesheets zurückzusetzen, um danach unter (hoffentlich) gleichen Bedingungen für alle Browser/Systeme individuelle Werte einzusetzen.

Aber wie so oft: die Betonung liegt auf »es kann sinnvoll« sein. Denn im Gegenzug zu der Situation, es ohne ein vorheriges Zurücksetzen der Browserstyles zu verpassen, bestimmte Vorgaben mit eigenen Styles zu überschreiben und damit u.U. ungewollte Ergebnisse hervorzurufen, kann es bei der eben erwähnten Methode des Zurücksetzens passieren, dass verpasst wird, allen Elementen einen neuen Style zuzuweisen. Der Browser würde dann mit »Nullwerten« für diejenigen Elemente arbeiten, die nicht explizit vom Webautor angefasst wurden, und das kann z.B. dann zum Problem werden, wenn während der Entwicklung der Website noch nicht bekannt ist, welche Inhalte samt ihrer Elemente zur Auszeichnung später verwendet werden.

Wer als Webautor also konsequent alle Browserstyles zurücksetzt, müsste danach im Gegenzug genauso konsequent alle (vorkommenden) Elemente neu definieren, um keine Überraschungen zu erleben, wenn auf der Website neue Inhalte eingebracht werden — etwa vom Redakteur innerhalb des Content Management Systems oder vom Leser eines Blogs, der einen Kommentar hinterlässt.

Ich selbst bin eher kritisch gegenüber dem Reset, also dem Zurücksetzen der Browserstyles, und arbeite lieber mit der Umgebung, die mir vom Browser zur Verfügung gestellt wird. Die Styleangaben, die ich als Webautor verwende, sind aus dieser Sicht heraus lediglich ergänzende Styles. Aber natürlich sollten sie detailiert genug sein, um ein Ausgabeergebnis zu erhalten, das den Anforderungen entspricht und im Wesentlichen systemübergreifend einheitlich ist.

Nach langem Gerede nun noch der nützliche Hinweis an alle diejenigen Webautoren, die nach der Erstmal-alles-Zurücksetzen-Methode arbeiten: Eric Meyer hat heute seine vermutlich finale Variante vorgestellt, diese Aufgabe zu erledigen:

I have what I’m willing to call the final version of my take on the topic of reset styles.

- Eric Meyer, Reset Reloaded

Der IE/Win benötigt dabei wie üblich eine Sonderbehandlung, auf dessen verschiedene Ansätze Eric ebenfalls hinweist, sie jedoch als nicht zwingend notwendig betrachtet.

Und abschließend noch zu Formularelementen, die vom Reset bisher nicht erfasst sind:

I’m going to get to that “weirdness of form elements” post in the near future.

After my troublesome approach of achieving consistent flexible forms: I’m looking forward to it, Eric! Maybe there will be some things to improve.

Approach to flexible multi-column forms

Dirk Schürjohann — Mon, 16 Apr 2007 00:00:02 +0000

(Dieser Artikel wurde auf Deutsch im SELFHTML aktuell Weblog veröffentlicht: »Ansatz für flexible, mehrspaltige Formulare«)

Fluid web forms?

When it comes to fit a web form into a fluid layout we usually point out several reasons why form elements should be pixel based. That is because we are totally aware of web forms being part of the browser/system and therefore do not give authority to the web designer. Sort of fundamental perception. Actually, styling web forms is hard work, even pixel sized, and could turn out into the hell of a job if specification says: make it fluid.

So, here we are and asking: why should a web form be fluid? Why go to the time and effort of develop a form that is based on input fields with flexible widths? Doesn’t make sense.
Sure it may come to make sense when the form has multiple columns and a scaling form would allow input fields to grab content that otherwise would have been cut off in a fixed pixel based form. Single-column input fields are hopefully long enough at any time, but a multi-column form may benefit from flexible widths.

One last thought: why do we go for multi-column forms instead of simple single-column ones? It’s all about conformity with user expectation (buzzword) and the use for suggestive input fields which comply with the content they may receive. For instance a submission of the user’s last name requires a longer input field than a field for the few chars of his street number. According to this idea a discrepancy between (the length of) input fields and its estimated amount of data may distract the user. As multi-column forms allow input fields with different sizes — at least our form does — they may correspond to the user’s expectation.

Approach to a flexible multi-column web form (HTML/CSS)

HTML structure

This is what we need:

a wrapper that uses negative margins for left and right and therefore gets wider than the form itself. The purpose is to compensate the margins of inner elements and align them with the form.
```
   
   ..
   
```
embracing labels in order to get around supplemental div containers.
```
   (text)
   (input)
```

a bunch of spans used for titles and stuff and being abused as block elements.



   
      First name *

CSS, code and example

See an example of the flexible form and find further information – mainly the CSS part – in the source.
Last update: August 6, 2008

Browser compatibility

The form seems to work smoothly in common browsers like Firefox, Opera (~~a wee bit unsteady~~) and Safari. IEs 6+7 need a little help from javascript in order to reduce the width of input fields by a few pixels. IE8 is fine now.

License

This approach to flexible multi-column forms is released under a Whatever-you-like-to-do license and can therefore be used for whatever you like to do.

Discussion

We are aware of the form not winning an award for its semantic markup. That is why we call it an »approach«. In fact it is not evil and we consider it to be a gentle way of getting a flexible and scalable form that is valid, well structured, tableless and works in common browsers.
As usual: feedback is welcome!

Updates

November 20, 2007
Picked up some positioning problems in Apples new Safari 3 browser. Will fix it later – or even better will come up with a new approach to flexible forms.
November 22, 2007
Up for Safari 3 now. However, a new approach definitely to come.
July 12, 2008
Adjusted box sizing in Opera 9.
August 6, 2008
Works fine in IE 8 now.
March 20, 2009
Works fine in IE 8 final ~~now~~ again: doesn’t need any specific styles, just clear out the IE 8 beta stuff now.