av ·0 kommentarer

En webbsida i sin simplaste form består av tre taggar/områden (ev. fyra – se slutet av inlägget).

DTD – Document Type Definition

Denna indikerar vilken typ av kod-dokument/kod-standard webbläsaren skall tolka.

Detta är nödvändigt då varje gång en besökare besöker en webbsida i webbläsaren så är det webbläsaren som läser igenom och ”översätter” källkoden till det slutresultat som sen presenteras för besökaren.

För HTML5 ser denne ut som följer:
<!DOCTYPE html>

Väldigt ren och simpel, jämfört med tidigare för XHTML t ex. som var ganska otymplig/klumpig att skriva varje gång man skapade ett webbdokument:
<!DOCTYPE html
     PUBLIC ”-//W3C//DTD XHTML 1.0 Strict//EN”
     ”http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
DTD:n skall stå med i ALLA webbdokument man skapar! (för HTML5, skall HTML5 DTD:n stå med överst i webbdokumentet)

<head> området

Andra delen är <HEAD> taggen och HEAD-området för webbsidan, detta är den del som en besökare inte direkt kan se innehållet av, utan att inspektera källkoden!
– Här placeras allt från inkludering av CSS-stilar, länk till favorit/bokmärkes- ikon, implementering av Google Web Fonts, Meta-data sökmotoroptimerings taggar, webbsidans <TITLE> (som har hög profil när vi pratar sökmotoroptimering), inkludering av JavaScript (ibland), m.m.

<body> området

Sist men inte minst kommer <BODY>-taggen och BODY-avdelningen, som är den del av webbsidan som håller allt som besökaren ska kunna se när webbsidan presenteras/tolkas av webbläsaren.
– Här placeras hela webbsidans struktur, alla HTML-taggarna som bygger upp webbsidan, länkar och allt som skall vara ”synligt” för besökare!

<title> taggen

Man skulle kanske även kunna kalla <title> taggen för en av de fundamentalaste delarna, då det (förr iaf.) var krav på att ha med denne tagg i HEAD-avdelningen för en webbsida.

av ·2 kommentarer

Att inspektera HTML-kod för webbsidor du besöker i webbläsaren, brukar inte vara svårare än att högerklicka på webbsidan, och välja ”inspektera-källkod”, eller granska källkod, eller liknande. Källkoden för en webbsida brukar oftast syfta till HTML-koden (kan även inkludera JavaScript och CSS-kod dock).

I Google Chrome verkar alternativet heta ”Visa sidkälla” såvitt jag kan se just nu i version 41.

För att sen leta sig fram till specifika element finns där tricks man kan använda sig av, t ex. [CTRL + F] för ”find”/hitta på svenska, för att hitta/identifiera antingen text som står skriven på webbsidan, eller kanske element man är ute efter.

På detta sätt att inspektera hur andras källkod ser ut kan man lära sig mycket om att skapa egna webbsidor, genom att lära från hur andra gjort det, man kan till-och-med låna av deras källkod om man hittar något man gillar(!). Var vaksamma här dock så ni inte ”lånar” något som ni inte har tillåtelse till! Vissa är okej att man lånar kod från deras sidor, andra är inte lika okej med det..

Se till att ni vet vad som gäller innan ni gör något :)

Mer avancerad och praktisk inspektion av källkod

Idag finns en mer avancerad form av inspektering av källkod som jag kommer ta upp i ett helt eget inlägg som sen kommer att länkas till härifrån när väl publicerat. Detta sätt är nämligen granskning av komponenter via antingen Google’s Code/Web Inspector (tror jag det heter), eller Mozilla Firebug och liknande. Dessa verktyg har blivit något av min egna preferens för inspektion av källkod det senaste året, då de erbjuder ett väldigt brett utbud av användbara och bra funktioner!

Mer om dessa senare som sagt :)

av ·0 kommentarer

När HTML-standarden XHTML (X:et står för eXtensible och XHTML var en kombinationsstandard mellan HTML & XML) kom så följde även strikta och bra kodningspraktiker med från XML.

På följande länk kan mer i detalj ses vilka skillnader det blev mellan HTML 4.01 och tillkommandet av XHTML 1.0, och XHTML’s nya kodningsprinciper är betydligt bättre (tycker jag själv) att följa vid kodandet av HTML: http://www.w3.org/TR/xhtml1/#diffs – De bidrar med renare, striktare och professionellare HTML-kod! Detta är även varför jag kommer följa dessa vid egna kodexempel.

Små bokstäver för alla taggar

XHTML kräver att ALL HTML-kod skall vara med små bokstäver (gemener)!

<table> <- Korrekt
<TABLE> <- Fel
<TaBle> <- Fel

Avsluta taggar i korrekt ordning

Taggar skall avslutas i rätt ordning – t ex. om du startar en paragraf-tagg och inuti den har en span-tagg, så måste span-taggen avslutas först, och sist paragraf-taggen.

<p><b>fisk</b></p> <- Korrekt ordning
<b><p>fisk</b></p> <- Fel ordning - se byte av plats på </b> och </p> t ex.

Stäng alla taggar som öppnas

XHTML kräver även att alla taggar som öppnas, måste stängas! Vilket betyder att ensamstående taggar måste avslutas på följande vis: <br /> med ett mellanrum och ett snedstreck innan ”större-än”- tecknet. XHTML krävde även att ALLA attribut-värden skulle omslutas med citationstecken.

<hr /> <- Korrekt
<hr>   <- Fel
---------------------------------------------------------------------------------
<header>
    <img src="" width="" height="" alt="" />
    <nav></nav>
-------- <- Notera hur här saknas </header> avslutningstaggen för <header> t ex.
<article></article>
<footer></footer>

<header>
    <img src="" width="" height="" alt="" />
    <nav></nav>
</header> <- Notera hur FINNS avslutningstaggen för <header> jmft. med ovan exempel där den saknades.
<article></article>
<footer></footer>

Indentering för ökad läsbarhet och bättre kodningsstruktur

En personlig preferens som man sen kan avgöra om man vill använda sig av eller inte- är användandet av s.k. ”indentering”, som jag snappat upp från programmeringen. Indentering innebär att man skapar en ”hierarkisk frånskjutningsstruktur” från vänster i koddokumentet utefter hur element (eller kod i allmänhet) är nästlad och hör ihop, så man ser vilken kod som hör till var. Se exempel nedan:

<första-tagg>
     <första-tagg-sub-tagg>
          lite text…
     </första-tagg-sub-tagg>
 </första-tagg>

Med ovan exempel kan vi se att följande kodblock tillhör <första-tagg> taggblocket:

<första-tagg-sub-tagg>
     lite text...
</första-tagg-sub-tagg>

camelCase för bättre och lättläsligare namngivning i kod

En annan personlig preferens- även denne hämtad från programmeringen, är något som kallas för ”camelCase”, och för er som ännu inte stött på detta är det konsten att skriva lättlästa beskrivande/deskriptiva namn för t ex. variabler och annat genom att börja första ordet med liten bokstav, därefter följer varje nytt ord efter första med en stor första bokstav! Se nedan exempel på variabelnamn med camelCase:
enVariabelSomHeterDuga
secondVariableToUse
thirdVariableToUse

Väldigt användbart och proffsigt ;)

Kommentarer för dokumentation och information av vad ens kod gör

Kommentarer i HTML är ytterligare en väldigt viktig del som hjälper utvecklare att dokumentera sin kod, såväl som informera övriga utvecklare om vad specifika delar i koden fyller för funktion.

Där finns bara en typ av HTML-kommentar som gäller för både enskilda, såväl som flera rader med text, medan t ex. i vissa programmeringsspråk så finns där olika typer av kommentarer för utifall kommentaren sträcker sig över en, eller flera rader.

HTML-kommentaren ser ut som följer:
<!– Kommentarstexten här –>

Som ni då ser ovan så inleds en HTML-kommentar med <!–, och avslutas med –>.

Emellan starten av kommentaren och slutet av kommentaren så skrivs då kommentarstexten, och denne kan sträcka sig över enstaka rader, såväl som flertalet rader, så länge den är emellan starten och slutet av HTML-kommentaren.

Vad dessa start- och sluttecken i princip gör- är att meddela webbläsaren att ignorera vad som än som står mellan dessa tecken. Då kommentarer egentligen är innehåll som skall ignoreras av webbläsaren när den tolkar din webbsida och dess kod för att sen presentera för sidans besökare.

av ·0 kommentarer

Med HTML5 kom smarta och bra uppdateringar när det gäller s.k. ”semantisk markup” (läs mer om ordet semantik på: synonymer.se/semantik).

Vad detta då är och innebär, är att istället för att definiera ganska så ”intetsägande” element för att bygga upp sin webbsida, så har man nu möjligheten att bättre – inte bara för sig själv och andra utvecklare, men även för indexeringsrobotar (kommer förklaras mer i detalj i inlägg om sökmotoroptimering som kommer att skrivas inom kort) – att informera om vad taggen har för syfte på hemsidan, och vilken typ av innehåll den har hand om. Detta då sökmotor-indexeringsrobotarna inte kan på samma sätt som oss människor läsa och förstå kontexten/sammanhanget av en text. Däremot kan de läsa taggarna och få sig en bättre uppfattning om vad taggen gör/har för typ av innehåll – om dess ”taggnamn” har betydelse!

Därav ”Semantisk markup” – taggnamnen har en betydelse för mer specifikt vilken typ av innehåll de ska ta hand om.

Praktiskt exempel varför Semantisk markup framför vanlig markup

Ett mer praktiskt exempel på detta är att man förut oftast använde <div> taggar för att skapa behållare på en webbsida, men den var ganska intetsägande om själva innehållet den skulle hantera då det enda taggnamnet informerade om, var i stort sett ”division-element”.. Men med HTML5 så hade tydligen de som utvecklade den nya standarden gjort undersökningar för att se vilka ID och Klass-attribut som var mest använda på webbsidor på nätet för att se vilka nya typer av element som hade underlättat HTML-kodandet, såväl som gett taggnamnen en smartare innebörd och betydelse för indexeringsrobotarna- såväl som utvecklare.

Semantiskt tagg-tillskott med HTML5

Några av dessa ”semantiska taggar” som blev nya tillskott med HTML5 för att ersätta DIV som behållare i olika lägen var som följer: <header> för sidhuvud, <footer> för sidfot, <section> för sektioner/avdelningar på sidan, <article> för artiklar på webbsidor, <nav> för navigeringsdelar på en webbsida, <aside> för sidospalter, samt <figure> & <figcaption> för bildbehållare med möjlighet till undertexter (figcaption-elementet).

av ·0 kommentarer

HTML-taggar som Element, med Attribut som Egenskaper

HTML-taggarna utgör vad som kallas för s.k. ”element” på webbsidor (t ex. en <div> tagg motsvarar ett ”division”-element, eller på svenska: ”avdelnings element” (personligen föredrar jag att tänka mig <div> element som behållare)), sådana element skulle kunna vara bilder, paragrafer, formulär, tabeller, listor, behållare, m.m. som ni kan se i ovan stycke.

Till varje HTML-tagg så finns det attribut, som nämndes ovan- som motsvarar egenskaper man kan tilldela sina taggar, olika taggar har olika egenskaper, men kan även ha vissa gemensamma attribut/egenskaper även trots att taggarna är olika!

Attributen erbjuder utvecklaren möjlighet att utöka HTML-taggarna på fördefinierade sätt som i sin tur möjliggör skapandet av unika webbupplevelser.

Där finns t ex. attribut som definierar ett elements bredd, respektive höjd, samt attribut som tilldelar identifierande värde (id), som sen kan hänvisas till från andra kodspråk för att hitta just det elementet!

Wrappers – vad är det, hur använder man det, och varför använda det?

Wrappers är ett koncept som ofta glöms att nämna vid utbildande inom området webbdesign och webbutveckling. Kanske då utbildare antar att alla förstår vad det är och hur man använder dessa, men jag tror att för många är detta inte så självklart.. För er som inte ännu är bekanta med wrappers kommer jag här gå igenom vad de är, hur ni kan använda de och varför.

Varför man ska använda wrappers är enkelt: för bättre design och uppbyggnad/struktur av webbsidor.

Vad: Wrappers är samma sak som om ni tänker er ramar som läggs omfamnande kring flera lösa byggklossar för att samla alla klossarna inom den ramen, då har ni i stort sett greppat vad de är och hur de fungerar.

De är tänkta att ”omfamna” lösa byggklossar som är relaterade till varandra – den vanligaste Wrappern är ”huvudwrappern” för en sida som är tänkt att omfamna alla elementen för en webbsida. Se exempel nedan:

<div id="mainContainer">
     <header>
          <img src="logo.png" width="" height="" alt="" />
          <nav>
               <ul>
                    <li></li>
                    <li></li>
               </ul>
          </nav>
     </header>
     
     <article>
          <p></p>
     </article>

     <footer></footer>
</div>

Vad är då poängen med detta? Jo, om ni har en behållare/wrapper som omfamnar alla elementen på er webbsida så är det bl. a. mycket enklare att ange stilar som är gemensamma för flera barn-element inuti den wrappern på ett och samma ställe – nämligen wrappern själv – då barn-elementen ärver egenskaper från wrappern!

Detta är speciellt användbart för att ange en gemensam bredd för samtliga element på webbsidan, såväl som att inte få innehåll att ”flyta över gränserna”, vilket tenderar att hända om man inte har någon form av wrapper som hindrar det från att hända.. Jag gillar att kalla det: ”spacial-confinement-restrictions”, vilket på svenska kan översättas till: rumsliga inneslutnings begränsningar.

Med detta menar jag att om vi antar att ni har en wrapper, och inuti denne har ni en artikeltext, då kommer artikeltexten endast fylla ut fram till kanten av wrappern, och inte längre, då den endast kan sträcka sig så långt som wrappern såvida inte ”speciell” positionering anges via CSS.