Alle CSS centrerings eksempler kan ses i aktion her

Horisontal centrering af tekst og billeder

Simpel text-align centrering:

<img src="image.jpg" alt="alternative text" />
<p>Centered text</p>

img, p { text-align:center; }

[ Se eksempel ]

Vertikal centrering af tekst og billeder

I de "gode" gamle tabel dage var det ingen problemer at centrere vertikalt. Men efter tabel-fri-design så dagens lys blev det til en større udfordring og nærmest umuligt for mit vedkommende. I dag er det heldigvis blevet "nemt" igen, der er selvfølgelig de normale Internet Explorer, IE, problemer! Tricket er, at få et element til at opføre sig som et tabel element, hvilket gøres vha. display attributten (display: table; og display:table-cell;). IE 6 og 7 understøtter desværre ikke table værdien, hvorfor en omvej må tages

 <ul>
    <li>
       <a href="#">
          <span>Vertical<br />centered<br />text</span>
          <!--[if lte ie 7]><b></b><![endif]-->
       </a>
    </li>
    <li>
       <a href="#">
          <span>Line one<br />Line two<br />Line three</span>
          <!--[if lte ie 7]><b></b><![endif]-->
       </a>
    </li>
    <li>
       <a href="#">
          <span>Only two<br />lines here</span>
          <!--[if lte ie 7]><b></b><![endif]-->
       </a>
    </li>
 </ul>

 ul { margin:0 auto; width:400px; }
 li { float:left; }
 a { display: table; height: 100px; }
 span { display: table-cell; vertical-align: middle; }

 IE 6 + 7 Styling:
 span { display: inline-block; }
 b { display: inline-block; height: 100%; vertical-align: middle; }

[ Se eksempel ]

Horisontal centrering af block elementer med fast bredde

Horisontal centrering med en fast bredde kan løses på mange måder, men den nemmeste og mest rene er immervæk "margin: 0 auto" tricket!

<ul>
   <li><a href="#">Item 1</a></li>
   <li><a href="#">Item 2</a></li>
   <li><a href="#">Item 3</a></li>
</ul>

ul { margin:0 auto; width:400px; }
li { float:left; width:33,3%;}

[ Se eksempel ]

Horisontal centrering af block elementer med dynamisk bredde

Horisontal centrering af menuer med dynamisk bredde har givet mig mange kvæler, hvorfor javascript har været min ven. Dette er dog ikke nødvendigt mere, hvorfor en pænere og mere ren løsning med CSS kan bruges

<ul>
   <li><a href="#">First item</a></li>
   <li><a href="#">Item in the middle</a></li>
   <li><a href="#">Last item, no more items</a></li>
</ul>

ul, li { float:left; position:relative; }
ul { left:50%; }
li { right:50%; }

[ Se eksempel ]

Vertikal og horisontal centrering af baggrundsbilleder

En meget effektiv men også overset måde at centrere på er vha background-position. Du undrer dig sikkert over, at jeg skriver overset, men det er min erfaring, at udviklere som kun kender løst til CSS ikke kender attributten!

<div class="bg"></div>

.bg { background: url('image.jpg') center center no-repeat; }

[ Se eksempel ]

Se alle kodeeksempler med vertikal og horisontal centrering her

Min påstand er, at alle udviklere på et tidspunkt kommer til at støde på front-end arbejde herunder CSS og markup. Mange af de tungere drenge bryder sig ofte ikke om det, hvilket til tider resulterer i spaghetti kode! Om det er manglende interesse/viden eller bare arrogance, skal jeg ikke kunne sige. Ved at følge nogle simple principper kan det hele blive lidt sjovere og nemmere for alle parter, for de tunge drenge, for dem som er begejstret for det og sidst men ikke mindst for dem som skal vedligeholde det efterfølgende.

1. Markup før CSS

Lav altid dit markup før du begynder at style. Sørg for at den så vidt muligt er valid, og at den er semantisk opbygget. En god tommelfingerregel er, at ens markup skal give mening uden CSS.

2. Lav valid kode

Ligesom med dit markup skal dit CSS være valid. Hvis du er i tvivl, kan du validere dine stylesheets via W3's CSS validator. Mange undervurderer vigtigheden af valid kode, så længe det bare virker. Men ved ikke at have valid kode, kan man ikke være sikker på, at ens kode vil virke i fremtiden. Ved at følge en vis standard undgår vi kaos og monopolisme.

3. Normalisering

Normaliser altid dit stylesheet inden du går i gang. Forskellige browsere har forskellige default værdier for de forskellige elementer, hvorfor det til tider kan være umuligt at lave en side, der opfører sig ens cross-browser uden brug af reset. Hvor meget eller hvor lidt der skal resettes er en temperamentssag. Herunder er listet nogle eksempler:

1. CSS Reset Reloaded by Eric Meyer
2. Yahoo! UI Library: Reset CSS
3. CSS Global Styles Reset by Kyle Neath

Være opmærksom på at det korte og brugte reset: * { margin: 0; padding: 0; } er et misforstået reset. Det er "tungere" at renderer (især med store websider), da det definerer regler for hvert enkelt element i ens dokument og nulstiller alt, hvorfor det ikke er anbefalingsværdigt.

4. Navngivning

Navngivningen er vigtig og desværre også utrolig undervurderet. Uanset hvad du vælger så vær konsekvent. Hold dig evt. til engelsk, brug camelCaseMedLilleBegyndelsebogstav eller adskil ord med bindestreg (-)  og giv som udgangspunkt strukturelle navne frem for præsentationsmæssige.
Et strukturelt navn beskriver, hvad det er for et element, du vil henvise til frem for et præsentationsmæssigt navn, som beskriver, hvor elementet befinder sig på siden, eller hvordan det ser ud.

Præsentationsmæssige navne:

topNav, leftTopLogo, leftContent, redBoldLink

Strukturelle navne:

primaryNav, branding, mainContent, externalLink

De præsentationsmæssige navne låser elementet fast, hvorfor de skal undgås. Hvad nu hvis din top menu (#topNav) pludselig skal ligge til venstre for dit indhold? Der findes dog som altid undtagelser, hvor de præsentationsmæssige navne giver mening, som næste punkt vil illustrere.

5. Lav genanvendelig kode

Du er sikkert stødt på ordet "object-oriented CSS" også kaldet OOCSS?! Hvis ikke gør du det nu. Selve navnet, OOCSS, er en smule misvisende og forvirrede mig, da jeg første gang stødte på det. OOCSS er ikke, hvad man traditionelt vil betegne som objekt-orienteret programmering, OOP, men i stedet benytter man nogle af OOPs principper såsom polymorfi, abstraktion, arv mm.
Ideen bag OOCSS er at lave mindre og mere genanvendeligt CSS vha klasser. For en dybere redegørelse henvises til "opfinderens" hjemmeside, Nicole Sullivan.

Hvordan opnår man så genanvendeligt CSS? Først et eksempel på, hvordan man ikke skal gøre:

CSS:
#element1 a.btn {background-color:#000;color:#fff;}
#element2 a.btn2 {background-color:#000;color:#fff;}
#element1 a.btnWithBorder {background-color: #000;border:1px solid #ccc;color:#fff;}
Markup:
<div id="element1">
   <a href="#" class="btn">Knap 1</a>
   <a href="#" class="btnWithBorder">Knap 1 med border</a>
</div>
<div id="element2">
   <a href="#" class="btn2">Knap 2</a>
</div>

Her indkapsler og fastlåser du din knap til et anchor tag samt id element og opnår derved redundans CSS samt kode, der ikke kan genbruges! Fjern afhængighederne og du har genanvendelig kode:

CSS:
.btn {background-color:#000;color:#fff;}
.border {border:1px solid #ccc;}
Markup:
<div id="element1">
   <a href="#" class="btn">Knap 1</a>
   <a href="#" class="btn border">Knap 1 med border</a>
</div>
<div id="element2">
   <a href="#" class="btn">Knap 2</a>
</div>

Nu kan dine klasser bruges på alle typer af objekter og ikke kun anchor tagget:

<button type="button" class="btn">Knap</button>
<div class="btn">Knap</div>

6. CSS struktur

CSS strukturen bliver ofte glemt eller nedprioriteret, hvilket er ærgerligt, da den kan spare dig og andre for en masse spildtid! Et godt råd er, at man i sit team/udviklingsmiljø aftaler nogle strukturelle regler, så man nemt kan arbejde på tværs af hinandens projekter.  Eksempler på strukturelle regler kunne være:

• Stylesheets inddeles i afsnit, fx via sektioner eller selectors.
• En regels egenskaber opstilles i alfabetisk rækkefølge for at få et hurtigere overblik (#element { float: left; height: 250px; width: 250px; }).
• Man har et element pr linje kontra en egenskab pr linje i sit stylesheet.
• Hierarkisk inddeling.
• etc.

Hvis det skal have nogen effekt, er det vigtigt, at man er konsekvent. Man laver en ens struktur for at gøre udviklingen nemmere her og nu samt i fremtiden. Når man skal have sit projekt live bliver strukturen ligegyldig, hvorfor man altid skal minify sine stylesheets for at spare kb.

7. Stylesheets

Stylesheets skal altid være placeret i toppen fordi:

1. W3 dikterer, at stylesheets skal være i toppen (head), medmindre det er inline-styling.
2. Ved at placere stylesheets i toppen opnår man, at ens side loader progressivt, hvilket er vigtigt, hvis din side har meget indhold, eller brugeren sidder bag en langsom forbindelse. Siden viser indholdet så snart, det er klart, og brugeren har en indikation af, at siden er ved at loade. Denne indikation er meget vigtig for brugervenligheden. Hvis man derimod indsatte stylesheets nær bunden, ville man i mange browsere (eksempelvis Internet Explorer) miste den progressiv hentning og stå tilbage med en hvid blank side, da browsere blokerer renderingen for at forhindre at skulle gentegne elementer, der måtte ændre sig.

Der findes mange meninger omkring, hvordan du opnår den bedste performance samt struktur mht stylesheet inddelingen. Jeg er dog ikke stødt på en løsning, der kan bruges bestandigt og som hos så meget andet, mener jeg, at det skal vurderes fra projekt til projekt. Oftest ender jeg med et setup, hvor jeg samler mit reset jf. punkt 3, klasse objekter jf. punkt 5 og fællesregler (element styling, h1, h2 etc) i et stylesheet og, hvis nødvendigt, et side-specifikt stylesheet (internt eller eksternt), hvor regler der kun gælder for den aktuelle side er.

8. Brug shortcase

Brug shortcase, da det formindsker din kode og giver et bedre overblik. Et eksempel illustrer pointen:

#element { margin-top: 15px; margin-right: 10px; margin-bottom: 15px; margin-left: 10px; }

bliver til

#element { margin: 15px 10px; }

Du kan også bruge shortcase hos følgende egenskaber; background, border, font, list, margin, outline og padding. Dustin Diaz har skrevet en fremragende guide til emnet.

9. Spring mellemledet over

Som i den virkelige verden er det oftest billigst for forbrugeren, at mellemledet bliver fjernet, og det er det også hos CSS. Mellemledet er ofte ubrugeligt og fylder kun ekstra i dit stylesheet, hvorfor det skal fjernes. Der findes dog situationer, hvor du kan blive tvungen til at inkludere det men som udgangspunkt; fjern det:

#element ul li a span.class

bliver til

.class eller #element .class hvis man har behov for indkapsling

10. Undgå hacks

Hold dig fra at bruge hacks! Hvad enten det er * hack, _ hack eller lignende. Brug i stedet Conditional Comments til fx at indsætte et Internet Explorer 6 specifikt stylesheet.

<!--[if IE 6]>
<link type="text/css" href="ie6styling.css" rel="stylesheet">
<![endif]-->

Eller til at sætte en klasse på html tagget for derved at kunne style specifikt til en ønsket version af IE.

<!--[if lt IE 7 ]> <html lang="en" class="no-js ie6"><![endif]-->
<!--[if IE 7 ]> <html lang="en" class="no-js ie7"><![endif]-->
<!--[if IE 8 ]> <html lang="en" class="no-js ie8"><![endif]-->
<!--[if IE 9 ]> <html lang="en" class="no-js ie9"><![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--> <html lang="en" class="no-js"> <!--<![endif]-->

11. Adskillelse

Markup og CSS er som Batman og Robin. De er fantastiske sammen, dog kan Batman fint klare sig alene, hvorimod Robin er ubrugelig uden Batman.
Man må aldrig begynde at sammensmelte markup og CSS og lave noget så uhyggeligt som inline styling. For at sikre fleksibilitet og overblik er det vigtigt at alt styling adskilles fra markup og kun lever i et stylesheet. Nu siger du sikkert, at der findes situationer, hvor inline-styling er eneste løsning, og ja det gør der, men brug det kun som sidste udvej, og ikke fordi du er doven.

12. Divitus, classitis og idikus

Undgå at få divitus, classitis eller idikus. Generelt for alle 3 sygdomme er, at man overforbruger. Man kan sammenligne det med et sønderjysk kaffebord, hvor der minimum er 14 forskellige kager, 7 bløde og 7 hårde, hvilket er helt unødvendigt. Derimod ville 1-2 kager fra hver kategori have været rigeligt.
Divitus er når man bruger for mange div'er. Mange nybegynder har en tendens til at smide en div rundt om alt:

<div id="mainHeader"><h1>Min overskift</h1></div>

Div'en er ikke nødvendig, og man kan i stedet skrive

<h1>Min overskrift</h1>

og så style på h1 i stedet for #mainHeader. Dog må man ikke være bange for at bruge div'er!  Jeg kan godt lide html5 tankegangen, som giver bedre overblik og en pænere struktur, hvorfor jeg til tider indkapsler hovedområder i en div med et sigende id!

Classitis og idikus minder meget om divitus:

<ul id="unsortedList">
  <li class="listItem firstItem">Item 1</li>
  <li class="listItem">Item 2</li>
  <li class="listItem">Item 3</li>
</ul>

Det er ikke nødvendigt at overklistre alle selectors med klasser og id'er:

<ul>
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ul>

Brug i stedet de elementer der allerede er til rådighed (ul, li) og, hvis IE6 også er død for dig, de smarte og hjælpefulde CSS selectors!

li:first-child   = Første li element.
ul > li          = Alle ul'ers børn der er li.
li + li          = Alle li'er der har samme forældre,
                   og hvor der kommer en li lige efter en li.

13. Vær god til matematik

Undersøgelser har vist, at personer med gode matematiske færdigheder har nemmere ved at programmere, hvilket også gavner, når man skal forstå, hvilken regel der er præcedens ved kollision. Fx kan et element have 2 regler der modsiger hinanden:

HTML:
<h1 class="h1">Header</h1>

CSS:
.h1{color:white;}
h1{color:black;}

Mange vil måske tro, at sidste regel altid er vigtigst, og at header teksten derfor vil være sort! Men hos CSS er der andre faktorer, der spiller ind. Først vægtes måden din styling bliver indlæst på:

1. prioritet: Inline styling
2. prioritet: Internt stylesheet
3. prioritet: Eksternt stylesheet
(4. prioritet: Browser default)

Dernæst vægtes attributterne:

li             {...}  /* a=0 b=0 c=1 -> specificity =   1 */
ul li          {...}  /* a=0 b=0 c=2 -> specificity =   2 */
ul ol li       {...}  /* a=0 b=0 c=3 -> specificity =   3 */
li.class       {...}  /* a=0 b=1 c=1 -> specificity =  11 */
ul ol li.class {...}  /* a=0 b=1 c=3 -> specificity =  13 */
#element       {...}  /* a=1 b=0 c=0 -> specificity = 100 */

hvor a repræsentere antal #id attributter, b antal klasse attributter og c antal tag elementer.  Jo højere tallet er, jo højere vægtning. I fornævnte eksempel vil header teksten være hvid, da klassen (.h1) vægtes med 10 point og tagget (h1) med 1 point.

14. Vær progressiv

I stedet for at udvikle til laveste fællesnævner, bør man være progressiv og anvende den nye teknologi, browsere løbende får, så længe siden stadig fungerer funktionelt hos laveste fællesnævner. Fx understøtter firefox bl.a. drag and drop af filer, hvor en bruger, der skal uploade en fil, kan dragge og droppe filen direkte ind i browseren og derved spare adskillige kliks. IE understøtter i skrivende stund ikke denne feature, hvorfor det selvfølgelig stadig skal være muligt at uploade en fil på den gammeldags måde. Her får brugeren med den bedre browsere bare en bedre oplevelse.

Et andet eksempel kunne være, hvor du har et element, der skal have runde hjørner og en gradient baggrund. I stedet for at skulle være afhængig af et stykke grafik eller flere, kan du lave runde hjørner samt gradient med CSS. Dette understøttes dog ikke i alle browser, nærmere bestemt IE, så når man udvikler efter laveste fællesnævner, bliver man nødt til at løse det med grafik, som gør siden tungere. Men nu er vi jo progressive, og derfor vælger vi den lettere og elegante CSS løsning, og lader brugerne af IE se et firkantet element med fast baggrund, og alle andre et lækkert rundt element med gradient. Siden kan stadig bruges af IE brugere, og IE brugerne ser stadig samme indhold, som andre brugere. Dog kan designere være tunge at danse med, og ofte kan det ende i et kompromis, hvor man bruger CSS3 de steder, der understøtter det og ellers grafik (IE).

15. Kend dine elementer

Som med alle programmeringssprog er det en god ide at kende til basis funktionaliteterne. Nogle gange er området dog så stort, at en del erfaring er påkrævet. CSS har derimod et overkommeligt antal basis elementer, der derfor gør det hurtigere og nemmere at få et overblik og derved at kunne vælge de rigtige elementer i den rigtige situation. Lær elementerne at kende før du går i gang, float vs. position, display vs. visibility, tabel vs. div etc.

16. Centrer med margin

Centrer med margin: 0 auto; i stedet for fx at fastkode en fast padding i venstre side. For at centrer med margin skal du definere en bredde:

#element { margin: 0 auto; width: 800px; }

17. Vær doven

Sidste punkt som i øvrigt gælder programmering generelt er, at man skal være doven. Der findes et utal af udviklere, som allerede har haft de problemstillinger, som du støder på, hvorfor det vil være fjollet ikke at benytte sig af deres viden og erfaringer. Genbrug dine og andres komponenter og brug de erfaringer, der allerede er tilgængelige. I CSS støder man på mange lignende problemstillinger, hvorfor man nemt kan ende som Sisyfos!

SLUT

Det var mit bud på, hvordan man ved hjælp af nogle simple principper, opnår bedre og mere overskueligt CSS og markup. Vigtigst af alt er, at man er konsekvent hele vejen igennem og tro mod kode standarderne. Sammen kan vi gøre verden til et bedre sted!

P.S. Har jeg glemt noget, eller er du bare dybt enig/uenig så smid gerne en kommentar.

21.04.12: New release, bPopup version 0.7.0

bPopup is a learning and exploring jQuery project. It's a lightweight cross browser jQuery popup plugin. It's not creating your popup but doing all the logic as opening, closing, centering on resize & scroll, creating a modal overlay etc. It can open any container you create with all kinds of content. bPopup has been tested in IE67-9, FF2-7, Opera 9-10, Safari 4-5 and Chrome 4-15.

Contents

1. How to use bPopup
2. Options (API)
3. Changelist
4. What can you do?
5. Downloads

How to use bpopup

Basic example that will bind a click event which will trigger bPopup when fired. Add a reference to the jquery core lib (newer than 1.3.x) and bPopup. Please don't hotlink to bPopup:

    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
    <script src="jquery.bpopup-x.x.x.min.js"></script>

Markup:

    <html>
        <head> ... </head>
        <body>
          ...
            <!-- Button that triggers the popup -->
            <button>POP IT UP</button>
            <!-- Element to pop up -->
            <div>Content of popup</div>
          ...
        </body>
    </html>

CSS:

    element_to_pop_up { display:none; }

The magic:

    // Semicolon (;) to ensure closing of earlier scripting
    // Encapsulation
    // $ is assigned to jQuery
    ;(function($) {

         // DOM Ready
        $(function() {

            // Binding a click event
            // From jQuery v.1.7.0 use .on() instead of .bind()
            $('button').bind('click', function(e) {

                // Prevents the default action to be triggered. 
                e.preventDefault();

                // Triggering bPopup when click event is fired
                $('element_to_pop_up').bPopup();

            });

        });

    })(jQuery);

Or with custom settings

    ;(function($) {
        $(function() {
            $('button').bind('click', function(e) {
                e.preventDefault();
                $('element_to_pop_up').bPopup({
                    appendTo: 'form'
                    , zIndex: 2
                    , modalClose: false
                });
            });
         });
     })(jQuery);

Enjoy

Options

Changelist

0.7.0 change-list (21.04.12):

• Bugfix: Multiple popup count fix (Thanks to Michael for reporting)
• Bugfix: Callback now returns 'this' instead of 'window' (Thanks to Jeppe for reporting)
• Bugfix: Scroll before popup is loaded opacity fix
• Bugfix: Moved initialization of popup to after onOpen event so it will center properly when adding stuff onOpen.
• Changed: Important note - Swapped arguments in Position so it now takes [x, y] instead of [y, x] like everything else in the world.
• Changed: Important note - Also swapped arguments in Follow so it also takes [x, y] instead of [y, x] and removed third argument. See positionStyle instead.
• New option: appending: true. Defines if the popup should append to an element or just open where it is.
• New option: positionStyle: 'absolute'. Defines the position style which has impact on how the popup follows on scroll and resize. Absolute or fixed.
• Removed private function, getDistanceToBodyFromLeft().

0.6.0 change-list (29.10.11):

• New feature: Supports multiple bPopups. Now you can open all the bPopups you want on top of each other.
• New feature: Won't follow if popup is bigger then the window.
• Changed: Added 3rd parameter to follow, default false. If true the popup will be fixed on the screen.
• Removed: Browser detecting is bad why I removed the check for IE6. IE6 doesn't support position: fixed but I don't support IE6 any more. I'm afraid I killed it. It's easy to add if you still need to support IE6.

0.5.1 change-list (13.04.11):

• Bugfix: Added a duration time to the hide() call so onOpen and loadUrl always will be trigged when needed.
• Bugfix: Added frameborder="0" and scrolling="no" to iframe to remove borders in IE. Removed width="100%" and height=100%" from iframe so you have full control over the iframe
• Code update: updated the logic regarding follow and position

0.5.0 change-list (12.03.11):

• bPopup, now with more control and features!
• New events: onOpen and onClose
• New option: Position['auto','auto']. Replacing vStart. Gives you full control where the popup should be.
• Changed option: follow changed to array of booleans, follow[true,true]. Defines if the popup should follow vertical and/or horizontal.
• Changed option: default value for amsl changed from 150px to 50px.
• Removed option: vStart, see Position.
• Removed feature: the popup doesn't auto reset input fields or auto focus any more. If you need this feature do the magic inside the onOpen event.
• Removed feature: xlink removed from content type. Instead do the xlink stuff inside the onOpen event.
• Bugfix: Modal overlay fits whole screen on an iphone in safari.
• Known issue: The popup doesn't center properly when zooming on an iphone in safari.

0.4.1 change-list (17.10.10):

• New option: content, now it's possible to load content into the popup through Ajax or in an iframe. It takes the url from loadUrl.
• New option: contentContainer, gives you the possibility to load content into a small area of the popup e.g. a div at the bottom.
• Removed option: xLink, use content type instead (content:'xlink')!

0.4.0 change-list (22.09.10):

• Attention: In this update there has been changes that affect how you interact with the popup!
• New option: modalClose (should the popup close on click on overlay?)
• New way to create the popup.You should now call $(selector).bPopup() instead of $(selector).openPopup().
• New way to force popup to close. Force close by calling the public function close(), $(selector).bPopup().close(), instead of triggering the close event with $('.bClose').closePopup(). This will stop cluttering up the $.fn namespace.
• Changed default value for opacity from 0.5 to 0.7
• Ensures that the same popup can't be opened twice at a time.
• Next update will include support for iframes, generic xlink support and more.

0.3.6 change-list (14.07.10):

• New options: fadeSpeed, follow, followSpeed, vStart
• Deleted: duration, minTop
• Included position:absolute styling on popup in plugin

0.3.5 change-list (05.07.11):

• New option: modalColor
• bPopup can now take callback functions

0.3.4 change-list:

• New option: loadUrl
• The popup can now open an url inside the popup
• Implemented x-link feature
• Refactored code, created private help functions
• Changed default value for scrollBar to true

0.3.3 change-list:

• New options: opacity, closeClass
• Changed modal overlay to position fixed in supported browsers. Non position fixed supported browsers still uses position absolute.
• Added default close event
• Fixed issue with overlay in IE6+7 and body positioned relative with a width

0.3.2 change-list:

• Modal overlay width miscalculation on resize.
• Auto textfield focus
• Resetting textfields before showing popup

0.3.1 change-list:

• New options: escClose, zIndex and minTop.
• Fixed bug with modal overlay when body has position: relative and a width. Now calculates the distance from the left to the body.

0.3.0 change-list:

• Unbind events on close.
• Centering popup on resize.
• Centering popup on horizontal scroll.
• Refactor code.

What can you do?

• Report bugs
• Help optimizing code
• Give suggestions

Downloads

v 0.7.0 minified

v 0.6.0 developer

v 0.6.0 minified

v 0.5.1 developer

v 0.5.1 minified

v 0.5.0 developer

v 0.5.0 minified

v 0.4.1 developer

v 0.4.1 minified

v 0.4.0 developer

v 0.4.0 minified

v 0.3.6 developer

v 0.3.6 minified

v 0.3.5 developer

v 0.3.5 minified

OPDATERET: Efter at Internet Explorer 9 har set dagens lys, er man tvungen til en syntaks ændring, hvis man vil have en bulletproof @font-face syntaks! Se mere under afsnittet "Hvordan bruger man font-face?".

Hvorfor bruge font-face?

I dag er vi sørgeligt nok stadig begrænset af få standard fonte, der er websikre. Man kan dog altid bruge ikke-websikre fonte og håbe på, at ens brugere har den valgte font på sin computer. Dette er selvfølgeligt meget usikkert, og man risikerer at ødelægge sit design samt struktur, hvorfor man i stedet embetter sine specielle fonte i form af grafik. Men takket være font-face er den tid nu ovre.

Ulemper ved grafik embetting:

• Ekstra arbejde - Hver gang du vil bruge din font, skal du lave det som grafik. En lille rettelse betyder, at designeren skal åbne sit billedbehandling program, lave rettelsen, gemme filen i det ønskede billedformat og uploade billedet.
• Tungere sider - I stedet for ren tekst har du grafik, som fylder mere og koster HTTP-requests. Stor skift størrelse = stor grafik.
• Manglende indeksering - Web crawlers kan ikke indeksere tekst i grafik. Dog kan (læs skal) man give sine billeder alt beskrivelser, hvilke bliver indekseret.

Ulemper ved font-face:

• Manglende standard - I skrivende stund findes der desværre ikke et font format, der understøttes af de meste brugte browsere, hvorfor det kræver, at man som minimum har fonten i formatet .eot, .ttf og .svg. Som det kan ses af nedenstående tabel tyder det dog på, at WOFF bliver fremtidens standard webfont format!

Font-face browser support

Hvordan bruger man font-face?

En mere dybdegående forklaring på font-face syntaks kan læses på Paul Irish blog indlæg; Bulletproof @font-face syntax. Nedenstående eksempel er mit forslående minimum setup for at understøtte alle overstående browsere samt iphone/ipad. Url'en til svg fonten har et id (#id) , som skal stemme overens med id'et i svg filen.

@font-face {
   font-family: 'Font Navn';
   src: url('font.eot');
   src: local('☺'),
      url('font.ttf') format('truetype'),
      url('font.svg#id') format('svg');
   font-weight: normal;
   font-style: normal;
}

Ny bulletproof syntaks efter at IE9 er udkommet:

@font-face {
   font-family: 'font Navn';
   src: url('font.eot'); /* IE9 Compat Modes */
   src: url('font.eot?#iefix') format('eot'), /* IE6-IE8 */
     url('font.woff') format('woff'), /* Modern Browsers */
     url('font.ttf')  format('truetype'), /* Safari, Android, iOS */
     url('font.svg#id') format('svg'); /* Legacy iOS */
}

Fonten kan nu bruges som enhver anden standard font:

h1 { font: 100% 'Font Navn', Arial, sans-serif; }

De forskellige font formater kan genereres med font squirrel's font generator. Husk at sikre at du har tilladelse til at bruge fonten som @font-face.

Undgå "blink" effekten!

Først lidt baggrundsviden. IE downloader .eot filen så snart den støder på @font-face erklæringen, hvorimod Gecko, Webkit og Opera alle venter indtil de støder på markup, der har en CSS regel, hvori den specielle font indgår. Webkit har en feature/bug, der gør, at fonten først bliver vist, når den er indlæst, hvor Gecko og Opera viser en standard font imens, og så genrender når fonten er hentet.
Problemet med Webkit er, at hvis en bruger sidder bag en langsom forbindelse, vil brugeren ikke se teksten før den har hentet font filen, hvorfor brugeren kan se en (delvis) blank side i op til flere minutter afhængig af forbindelsen.
Problemet i Gecko og Opera er, at brugeren vil kunne se genrederingen (blinket), og at designet muligvis vil brække indtil fonten er hentet. Nedenstående billede illustrerer blinket og er et simplificeret eksempel på, at strukturen også kan ændre sig.

Font-face "blink" eksempel

For at opnå Webkit featuren i Gecko og Opera findes der et javascript bibliotek, WebFont Loader, der vha klasser på html tagget fortæller når fonten er hentet, hvorfor du selv kan gemme teksten via CSS indtil fonten er hentet, og dermed undgå blinket:

<script src="http://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js"></script>
<script type="text/javascript">
   WebFont.load({
      custom: {
         families: ['Font Navn'],
         urls : ['http://dinbror.dk/font-face-stylesheet.css']
      }
   });
</script>

CSS:

.wf-loading h1 {
   visibility:hidden;
}
.wf-active h1, .wf-inactive h1 {
   visibility: visible;
   font-family: 'Font Navn', Arial, sans-serif;
}

Ulempen er ligesom hos Webkit, at teksten ikke kan ses imens fonten hentes, og at man nu også skal hente og være afhængig af et javascript bibliotek. Dog kan man i stedet for at gemme teksten helt tilpasse den, så den i stedet passer størrelsesmæssigt med font-face fonten. Et lille tip er, at man ikke gemmer teksten i IE, da det ikke er nødvendigt (IE downloader .eot filen så snart den støder på @font-face erklæringen), og da IE ikke er kendt for sin hurtige rendering af javascript.

En anden og mindre ressourcekrævende løsning, hvor man dog kun minimere blinket, og som pt kun er understøttet i Gecko, er CSS attributten font-size-adjust. Den giver dig mulighed for at normalisere x-højden på tværs af en font, hvorfor forskellen reduceres og designet holdes konstant!

Hjælp, font-face virker ikke i Firefox!?

Selvom font-face er understøttet i Firefox, kan Firefox godt drille. Firefox tillader ikke cross-domain fonte som standard, hvilket betyder, at fonten skal ligge på samme domæne, endda samme sub-domæne medmindre man kan tilføje en “Access-Control-Allow-Origin” header til fonten. Dette er ikke altid en mulighed, men fortvivl ikke. Der findes selvfølgelig også en løsning på det. Det er måske ikke den pæneste løsning og heller ikke helt uden bivirkninger.  Løsningen er at embette fonten i sit stylesheet som Base64. Hvis du bruger font squirrel's font generator kan du vælge "Expert", og herefter sætte flueben i Base64 Encode under CSS options som nedenstående billede illustrerer.

Vælg Base64 Encode

Resultatet er, at ttf fonten nu i stedet bliver embettet i stylesheetet:

@font-face {
   font-family: 'Font Navn';
   src: url('font.eot');
   src: local('☺'),
      url("data:font/opentype;base64,[base64-encoded font her]");
      url('font.svg#id') format('svg');
   font-weight: normal;
   font-style: normal;
}

Bivirkningerne er, at stylesheetet bliver tungere, og at base64 encoding fylder mere selve ttf fonten.

Åhh nej @font-face virker ikke i IE9

Internet Explorer 9 kommer med mange gode opdateringer og standardiseringer, hvilket har medført ændringer i måden, hvad IE tillader. Det har bl.a. betydet, at IE9 som FF ikke tillader cross-domain font-linkning. Løsningen er som med FF, at tilføje en “Access-Control-Allow-Origin” header til fonten.

Problemer med WOFF
IE9 understøtter modsat sine forgængere .woff fonte. Hvis du benytter en IIS skal huske at tilføje .woff's MIME type til IIS'en for ikke at få en 404 not found:

<MimeType extention=".woff" type="application/x-font-woff" />

Hvis dette ikke er en mulighed, kan du også tvinge IE9 til at bruge .eot fonten i stedet ved at ændre formatet fra eot til embedded-opentype. IE9 supporterer formatet embedded-opentype modsat formatet eot, hvorfor fonten indlæses:

src: url('webfont.eot?#iefix') format('embedded-opentype')

EOT er som default kendt af IIS'en.

@font-face virker stadig ikke i IE9
Jeg er ikke selv stødt på problemet, men har læst at I nogle sjældne tilfælde vil @font-face fejle i IE pga. for mange karakter. Dette kan løses ved at tilføje et hash tegn efter spørgsmålstegnet:

src: url('font.eot?#iefix') format('eot')

0: Minimer HTTP-requests

Jo færre requests jo bedre. Den største og nok nemmest måde at reducere dine indlæsningstider på dine websider ligger i antallet af HTTP-requests, hvorfor du skal eliminere unødvendige requests.

Hvorfor
Browsere bruger i dag cirka 80% af deres tid på at hente eksterne filer såsom stylesheets, scripts, billeder etc. Hver fil er lig med et request, dog henter browsere disse requests parallelt (på nær script-filerne), og alt afhængig af browser, kan de have x antal forbindelser kørende på samme host på samme tid.  Herunder er opstillet nogle eksempler på, hvor mange forbindelser per host samt max forbindelser de mest benyttede browsere kan håndtere:

    Browser           |   Connection per hostname   |   Max connections
Internet Explorer 8                   6                        57
Chrome 4                              6                        55
Chrome 5                              6                        40
Firefox 3.5+3.6                       6                        30
Safari 4                              5                        60
Opera 10                              4                        20
Internet Explorer 7                   2                        60
Internet Explorer 6                   2                        56

Andre browsere og flere detaljer omkring de enkelte browsere kan findes på browserscope, som er et open source projekt startet af Steve Souders og Lindsey Simon.

Hvordan
Ja nu ved vi, hvorfor det er en god ide at minimere HTTP-requests, men hvordan gør vi det egentlig i praksis?
Der findes flere måder at gøre det på. Jeg vil her præsentere 2 måder, som jeg selv finder nyttige, brugbare og bruger til dagligt.

a) Kombinerede filer: Så snart det er muligt, skal man kombinere sine scripts og stylesheets således, at alle ens stylesheets bliver samlet i en fil og ligeledes med sine scripts. På denne måde kan man spare requests.
Det kan dog være svært, hvis scripts og stylesheets varierer meget fra side til side. Her må man gå ind og vurdere den enkelte situation, og kigge på hvad der mest gavner indlæsninghastigheden. Man skal være opmærksom på, at fx billeder i stylesheets også generer requests, så hvis tendensen på din side ikke er, at brugeren besøger mange sider, og du har meget forskelligt styling fra side til side, kan man spare requests ved at benytte sig af en side-modulær CSS opbygning. Men som tommelfingerregel skal man samle sine stylesheets samt scripts i en fil.

b) CSS Sprites: CSS Sprites reducerer antallet af billede requests. Kort fortalt går det ud på, at man samler flere af sine billeder i et billede, og vha. background-position styre hvilken sekvens af billedet, man vil vise. Hvis du ikke kender til sprites, kan du læse mere omkring emnet her:

-  CSS Sprites: Image Slicing’s Kiss of Death af David Shea

-  The Mystery Of CSS Sprites af Sven Lennartz

-  CSS Sprite: What they are ... af Chris Coyier

Eller kigge nærmere på hvordan jeg har lavet min top menu.

1: Placerer stylesheets i toppen

Der er to grunde til at placerer stylesheets i toppen.

1. W3 dikterer, at stylesheets skal være i toppen (head), medmindre det er inline-styling.
2. Ved at placere stylesheets i toppen opnår man, at ens side loader progressivt, hvilket er vigtigt, hvis din side har meget indhold, eller brugeren sidder bag en langsom forbindelse. Siden viser indholdet så snart, det er klart, og brugeren har en indikation af, at siden er ved at loade. Denne indikation er meget vigtig for brugervenligheden. Hvis man derimod indsatte stylesheets nær bunden, ville man i mange browsere (eksempelvis Internet Explorer) miste den progressiv hentning og stå tilbage med en hvid blank side, da browsere blokerer renderingen for at forhindre at skulle gentegne elementer, der måtte ændre sig.

2: Placerer scripts i bunden

Grunden til at scripts skal være i bunden er, at scripts blokerer for den parallelle hentning, hvorfor resten af dit indhold må vente til scriptet er færdighentet. Derfor placerer altid dine scripts i bunden, når det er muligt. Der findes selvfølgelig situationer, hvor du ikke kan, fx hvis du indsætter markup via document.write, hvilket jeg dog ikke er den store fan af eller initialisere ting i dit script i den øvre del af dit HTML dokument.

3: Stylesheets og scripts skal være eksterne

Nu kommer jeg til at modsige mig selv, men der er en mening med galskaben. I første punkt fik du at vide, at du skulle spare på HTTP-requests, og undgå dem så snart det var muligt, men nu fortæller jeg dig, at du skal gemme dine stylesheets samt scripts eksternt frem for at gemme dem inline, og dermed generer et ekstra request per fil. Igen kommer det an på situationen, men oftest er der mest at hente ved at gemme dem eksternt. Ved at gemme dem eksternt bruger du som sagt et ekstra request per fil, men da browsere cacher filerne, kan det være en fordel, hvis du eksempelvis bruger de samme filer på flere sider. Ved at gemme dem inline spare du det ekstra request, men HTML dokumentet bliver tungere, og filerne bliver indlæst ved hver page load. Når dine filer derimod er cachet generer de ikke et ekstra request og HTML dokumentet er ligeledes lettere.

4: Minify

Ved at minify sine stylesheets og scripts fjerner man unødvendige tegn og luft, og gør dem derved lettere at hente. Der findes forskellige værktøjer til at minify med:

1. YUI Compressor: YUI er et af de mest kendte og mest effektive minify værktøjer. Det er skrevet i Java, og man skal afvikle det på sin computer. Det gode ved YUI er selvfølgelig den effektive algoritme som minifyer, men også at den kan minify scripts såvel som stylesheets.
2. CSS Compressor: Online værktøj, som kan minify dit CSS ud fra forskellige indstillinger.
3. Closure compiler: Googles svar på et script minify værktøj, som eftersigende skulle være bedre end YUI. Compileren kan både downloades eller benyttes online samt indstilles efter behov og temperament.

5: Fjern duplikater

Punktet burde egentligt ikke have været med på listen, da det giver sig selv. Men jeg har set steder, hvor de stadig forekommer, duplikater af scripts. Ved at have duplikater forøges indlæsningstiden. Internet Explorer laver et ekstra unødvendigt request, hvorimod Firefox godt kan se, at det er det samme script. Dog spilder begge browsere tid på at evaluere scriptet to gange, så undgå at have duplikerende scripts.

6: Reducer DOM-elementer

En tommelfingerregel er, at jo flere elementer du har på en side, jo tungere er den at renderer. Sørg derfor altid for at have så ren og meningsfuld markup som muligt. Mange elementer på en side gør det ligeledes sværere for JavaScript at tilgå dem. En måde du kan undersøge, hvor mange elementer en side har, er ved hjælp af Firebug. Skriv blot følgende i konsol vinduet:

document.getElementsByTagName('*').length

7: Brug dine subdomæner

HTTP 1.1 specifikationen anbefaler, at browsere ikke downloader mere end 2 komponenter parallelt per host. Ved at gemme dine billeder på flere forskellige hosts, kan du opnå mere end 2 parallelle downloads ad gangen, og dermed gøre din side hurtigere. Steve Souders har lavet et lille eksempel, hvor han illustrerer forskellen på at gemme sine billeder på et host kontra to.

8: Undgå @import

Brug <link /> frem for @import. Internet Explorer opfatter filer indsat ved hjælp af @import som link-tags, der er indsat i bunden af siden.

9: Undgå filters

Hvis du vil have transparente png billeder i Internet Explorer 6, kan du bruge Microsofts eget filter, AlphaImageLoader. Dette er dog ikke anbefalingsmækværdi! Problemet ligger i at filteret blokerer rendering af siden og fryser browservinduet, mens billedet bliver hentet. Filteret forøger ligeledes brugen af computerens hukommelse. Undgå derfor at bruge dem, og brug i stedet gif eller png8 billeder eller nogle af de andre alternativer der findes, hvis du vil understøtte semi-transparente billeder i IE6.

10: Undgå tomme billede referencer

Tomme billede referencer resulterer i ekstra og nytteløse serverkald:

<img src="" alt="Tomt billede reference" />

Nicholas C. Zakas har skrevet en udmærket artikel, der beskriver problemet rigtig godt.

11: Komprimerer dine billeder

Hvis du som jeg ikke altid selv klipper dit grafik og dermed gemmer det, kan der opnås store besparelser ved selv at genkomprimerer billederne. Uden at slå alle designer over en kam, så tænker de ikke på størrelsen.

12: Komprimerer dine komponenter

GNU zip eller også kaldet gzip er en komprimeringsmetode, som kan spare dig adskillige kilo bytes og dermed minimere svar tiderne. Vel og mærket hvis server samt klient understøtter det. Fra og med HTTP/1.1 er web-klienter begyndt at understøtte komprimering med Accept-Encoding i headeren af HTTP-request'et, fx:

Accept-Encoding: gzip, deflate

Starter med minimum et tegn efterfulgt af et snabel a, hvor der så igen er minimum et tegn efterfulgt af en prik. Sidste men ikke mindst defineres domænetypen, som er på minimum 2 bogstaver fx dk, de etc.

En nem måde at håndtere en række regler for en tekststreng er ved at bruge Regular Expression. Et regulært udtryk er en tekststreng, som beskriver en mængde af tekststrenge og som overholder syntaksen for opstilling af det regulære udtryk. Så for at kunne validere en e-mail adresse vil jeg lave et regulært udtryk:

(/^.*?@\w[\w.-]*\.[a-z]{2,4}$/i)

Overstående giver måske ikke så meget mening, hvis man ikke kender til regulære udtryk, så jeg vil anbefale, at man læser om det på nettet [1][2][3]. Men jeg vil selvfølgelig ikke snyde jer for en forklaring af overstående udtryk.

^ : Starten af strengen.
.* : 0 eller flere tegn.
? : Non greedy (dvs. match mindst mulige tegn i stedet for flest mulige, 0 eller 1 gange).
@ : Et ”@”
\w : Et tegn a-z, A-Z eller 0-9 og ”_”
[\w.-]* : 0 eller flere tegn, som er a-z, A-Z eller 0-9, foruden ”.” eller ”-”
\. : Et ”.”
[a-z]{2,4} : 2-4 tegn af typen a-z. For eventuelt at fremtidsikre sine e-mail adresser kan man sætte max antal tegn op.
$ : Slutningen på strengen.
i : ”ignore case”, ingen forskel på store og små bogstaver.

Heldigvis findes der en række gratis værktøjer, der gør det muligt at teste sit design i de forskellige browsere. Nogle er online, hvor andre skal installeres på computeren:

Browsershots.org
En hjemmeside der gør det muligt at teste sine sider i alverdens kombinationer mellem browsere, operativsystemer og ekstra indstillinger. De ekstra indstillinger består af skærm størrelse, farve dybde og om javascript, java eller flash skal være aktiveret eller deaktiveret.
Værktøjet kan ikke bruges lokalt, men kun online. Man indtaster en url og vælger de browsere samt operativsystemer, der skal testes i. Herefter loader programmet din url i de forskellige browsere og tager et screenprint af siden. Værktøjet kræver en smule tålmodighed, da der kan forkomme ventetid på resultatet.

IE NetRenderer
Ligesom browsershots.org er dette et online værktøj til at se sine sider i forskellige browsere. Dog kan der kun vælges mellem forskellige versioner af IE ned til version 5.5. Testen renderer med det samme, og er derfor et godt alternativ til browsershots, hvis man kun skal teste IE.

Multiple versions of IE
Et program udviklet af TredoSoft, som hjælper dig med at installere flere versioner af IE på en gang. Her kan du teste dine sider online såvel som lokalt.

IETester
Et program udviklet af My DebugBar, som kan vise dine sider i IE ned til version 5.5. Programmet gør det mulig nemt og hurtigt at skifte mellem de forskellige browsere både lokalt samt online. GUI mæssigt er programmet nok det flottest og det fungere ok, dog skal man stadig tænke på, at det er et alpha release, hvorfor fejl kan opstå. Ligeledes har det stadig nogle begrænsninger, fx kan der forekomme problemer med visning af flashelementernår man tester i IE 6.

MS Expression Web SuperPreview
Microsofts eget værktøj til at teste sine designs i forskellige IE versioner. Værktøjet viser dit design i IE 6 og IE 7 eller IE 8, afhængigt af hvilken version du har installeret på computeren. Du kan se siderne ved siden af hinanden eller ovenpå hinanden, og programmet giver dig nogle værktøjer, der kan identificere forskelle helt ned til pixelniveau.

1) Inception

2) Elaboration

3) Construction

4) Transition

Fase 1: Inception (Forberedelsesfasen)

Fase 2: Elaboration (Etableringsfasen)

Fase 3: Construction (Konstruktionsfasen)

Fase 4: Transition (Overdragelsesfasen)

Fordele ved Unified Process:

- UP egner sig til store og tidskrævende projekter med mange udviklere.

- Løbende reviews.

- Meget dokumentation. UP er arkitekturcentreret og systemet beskrives grundigt, som gerne skulle resultere i, at andre udviklere hurtigt kan få et overblik og overtage systemet.

Ulemper ved Unified Process:

- Meget dokumentation, i form af use case specifikationer, sekvensdiagrammer mm. Den grundige dokumentation er tidskrævende og resulterer i, at ændringer løbende koster meget tid.

- Ufleksibelt, UP er låst fast i sine faser, og det er derfor ikke nemt at lave store ændringer, når man er sidst i en fase eller har afsluttet en fase.