av ·0 kommentarer

Hej igen alla läsare :) I detta inlägg hade jag tänkt gå igenom stegen för att skapa vår alldeles första, HTML5-mall (väldigt simplifierad med bara det väsentligaste ”for now” – mer avancerad kommer att gås igenom i ett annat inlägg framöver).

Mallen vi kommer att skapa/visa här kommer ni sen kunna använda som den fundamentalaste grunden som kan utgöra startpunkten för alla era HTML5-webbsidor framöver att utgå från innan man fortsätter vidare till att skapa layout och sådant.

Vi kommer försäkra oss om att mallsidan vi skapar är validerad enligt W3C’s validator för HTML5-standarden, vi kommer även försöka visa på vad de olika delarna på sidan fyller för funktion och varför man bör ha med dem :)

Först och främst, allmänna grunden för webbsida (ej standardenlig, bristfällig, men basic)

<html>
<head>
    <title></title>
</head>
<body>
    this is the bare-minimum of any website OUTSIDE of any standards...
    the <html>-tag to indicate to the browser that it's a web document to be interpreted.
    the <head>-tag that will hold meta-data for the webpage as well as site-title text and load javascripts, css-styles, etc.
    the <body>-tag that holds the entire websites body - that will be visible to the website visitors (with some exceptions in a few cases)...
</body>
</html>

Vänligen OBSERVERA dock att ovan INTE ÄR REKOMMENDERAT att faktiskt koda till ”riktiga webbplatser”. Där saknas några grejer som i kombination med ovan kod, gör webbdokumentet standardenligt utefter den standard man väljer.

Skulle ni besöka W3C HTML Validator verktyg och skriva in ovan kod, så kommer ni få 1 st. ERROR och 4 st. VARNINGAR. (för koden bortsett från texten inuti <body>-taggen)

ERROR-meddelandet som ges kommer se ut såhär:

no document type declaration; implying ”<!DOCTYPE HTML SYSTEM>”

: The checked page did not contain a document type (”DOCTYPE”) declaration. The Validator has tried to validate with a fallback DTD, but this is quite likely to be incorrect and will generate a large number of incorrect error messages. It is highly recommended that you insert the proper DOCTYPE declaration in your document — instructions for doing this are given above — and it is necessary to have this declaration before the page can be declared to be valid.

Ovan felmeddelande talar om att vår mallkod saknade Document Type Definition, vilket innebär att ingen standard för koden man skriver är angiven, vilket också innebär att det är ”fritt fram” för webbläsaren att anta vilken standard man kodar i – och ni kan säkert gissa hur väl/illa det hade kunnat gå om webbläsaren skulle välja fel standard.. :/

Några av VARNINGAR-meddelandena kommer att vara:

1. Unable to Determine Parse Mode!

: The validator can process documents either as XML (for document types such as XHTML, SVG, etc.) or SGML (for HTML 4.01 and prior versions). For this document, the information available was not sufficient to determine the parsing mode unambiguously, because:

  • in Direct Input mode, no MIME Media Type is served to the validator
  • No known Document Type could be detected
  • No XML declaration (e.g <?xml version="1.0"?>) could be found at the beginning of the document.
  • No XML namespace (e.g <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">) could be found at the root of the document.

As a default, the validator is falling back to SGML mode.

Vilket i stort sett betyder att mallkoden vi angav ovan saknade tillräcklig med information för att indikera att det var en webbsida vi kodade. Vilket kan ställa till en del problem när webbläsaren ska försöka tolka koden och presentera element till besökaren för kod som den egentligen inte är helt säker på att den förstår.

2. No DOCTYPE found! Checking with default HTML 4.01 Transitional Document Type.

: No DOCTYPE Declaration could be found or recognized in this document. This generally means that the document is not declaring its Document Type at the top. It can also mean that the DOCTYPE declaration contains a spelling error, or that it is not using the correct syntax.

The document was checked using a default ”fallback” Document Type Definition that closely resembles “HTML 4.01 Transitional”.

Learn how to add a doctype to your document from our FAQ.

Verkar praktiskt taget vara samma som vårt första och enda ERROR-meddelande.

3. No Character encoding declared at document level

: No character encoding information was found within the document, either in an HTML meta element or an XML declaration. It is often recommended to declare the character encoding in the document itself, especially if there is a chance that the document will be read from or saved to disk, CD, etc.

See this tutorial on character encoding for techniques and explanations.

Ovan varningsmeddelande säger i stort sett att inget har angetts för att indikera på vilket språk sidan kodas, eller vilken teckenkodning som skall användas – detta kan i sin tur leda till att t ex. Svenska tecken som Å, Ä och Ö- bokstäverna blir jätteknasiga när de skall presenteras, då webbläsaren inte har den blekaste aning om vilket ”språk” de tillhör/vilken teckenkodning som kan ordentligt presentera tecknen.

Det fjärde varnings-meddelandet var p.g.a. att jag validerade ovan mallkod genom att i stort sett klistra in koden direkt i validatorn, och kan därför ignoreras.

Enda anledningen att jag visar denna grundkod för en HTML-webbsida, är i pedagogiskt syfte att visa på att detta är de allra viktigaste delarna av en webbsida, ett ”bare-minimum” som man kan säga på engelska. Det allra minsta som är nödvändigt för att göra ett webbdokument helt enkelt.

Det är bra kunskaper att ha och det är bra att känna till vilka delar, och i vilken utsträckning man kommer att använda dem. Om ni sen vill kan ni gärna experimentera själva genom att t ex. ta bort <body> taggen, eller kanske <title> taggen från koden och sedan testa klistra in koden i validatorn och köra den igen, se om ni får nya felmeddelande och vad de i sådana fall säger :)

Min rekommendation är att ni bör sträva efter att ha validerad kod för er webbplats, detta försäkrar om att inga onödiga fel riskerar att drabba er i stunden eller längre in i utvecklingsprocessen!

Lite insikt i de olika delarna

Som somliga av er säkert känner till publicerade jag ett inlägg tidigare: Dissekering av webbsida & Genomgång av dess tre fundamentalaste beståndsdelar: DTD, HEAD, BODY , som ger en koncis introduktion till delarna vi har tagit med i vår grundmall ovan. I det inlägget nämner jag även lite snabbt DTD som inte finns med i vår mall ovan, om man vill koda efter en standard (vilket är säkrast och föredraget för bäst- och förutsägbara resultat) så bör man åtminstone känna till att en DTD skall finnas med överst på sidan.

Längre ned i detta inlägg kommer jag även gå igenom en ”korrekt” HTML5 Boilerplate för att ni även ska se och lära er hur det ”korrekta” sättet att bygga basen för en webbsida går till på med dagens senaste moderna webbstandard, HTML5.

Visdomsord innan kodande inleds

Tänk på visdomsorden och rekommendationerna som nämndes och togs upp i inlägget: Bra kodningsprinciper och praktiker för HTML-kodning från XML.

För att vara konsistenta och även demonstrera kunskaperna vi tagit del av bör vi koda vår HTML-mallsida utefter de bra principer och praktiker för HTML-kodning som vi tidigare gått igenom.

Användbar och bra tillgänglig kodmall från andra källor

Innan vi börjar med vår egen mall tänkte jag snabbt nämna att det redan finns en framtagen mall som jag själv brukade utgå från för många av mina tidigare webbsidor, skapad av HTML5Doctor.com och deras kodare, länk till mallen kan hittas på vår Länkar-sida, eller på följande länk: HTML5Doctor.com: html5-boilerplate.

Deras mallsida har det väsentligaste och det nödvändigaste, och den blir dessutom godkänd av W3C HTML5 Validator verktyg för att vara enligt HTML5-Kodstandard(!).

Deras kodmall ser ut som följer:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>HTML 5 complete</title>
<!--[if IE]>
<script src="https://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<style>
  article, aside, details, figcaption, figure, footer,header,
  hgroup, menu, nav, section { display: block; }
</style>
</head>
<body>
<p>Hello World</p>
</body>
</html>

Och som ett ”FYI” (For Your Information) inför framtiden angående indentering, så brukar detta vara upp till er som kodar, men för det mesta verkar det populäraste vara att endast börja indentering vid block-element i respektive område (head/body).

Och vad jag då menar med detta är som ni kan se ovan så är det första ”block-elementet” i <head> taggen vårt <style> block där man kan placera On-page CSS-stilmalls kod (mer om detta i inlägg om CSS-kodning senare framöver), där har HTML5Doctor.com valt att indentera, och när det gäller <body> taggen har de endast ett s.k. ”inline-element” (paragraf-taggen (<p>)) som då inte är ett ”block-element” och behöver därför inte indenteras. Men som sagt, detta väljer ni själva hur ni vill göra, men det kan annars vara kul att veta hur man brukar avgöra var det är lämpligt med indentering :)

Genomgång av HTML5Doctors HTML5-boilerplate

Document Type Definition – DTD

Först i HTML5Doctors kodmall kan vi se en DTD för HTML5, som indikerar att standarden koden är skriven utefter, är just det: HTML5.

  <!DOCTYPE html>

HTML & HEAD- taggarna

Därefter följer bastaggarna vi är bekanta med sen tidigare, <html> och <head>.

Meta tagg för teckenkodning

Sen följer en intressant tagg vi tidigare inte sett, nämligen en ”meta tagg” (<meta>), dessa används för att förmedla meta-data för en webbsida, i det här fallet är meta taggen dedikerad till förmedling av teckenkodning (charset för character set). I andra fall kan meta taggar användas för att förmedla sökmotorindexerings nyckelord, sökmotorindexerings sidbeskrivningar, sökmotorindexerings robotregler för sidan (hur sidan skall indexeras), m.m.

Vår charset meta tagg är satt till värdet UTF-8, vilket är en idag väldigt populär teckenkodning, faktum är att det är rekommenderad ”default standard teckenkodning” för HTML-kodning.

Direkt citat från HTML5Doctor’s artikelsida för deras HTML5-Boilerplate säger följande för teckenkodnings meta-taggen:

This final, more complete boilerplate also indicates the character set. Without it, some characters will not render properly.

Mer info om UTF-8 och Unicode teckenkodning

Vid intresse av att läsa mer om UTF-8 som teckenkodning, vänligen se Engelska Wikipedias artiklar om UTF-8 och Informationssida om UTF-8 på webben :) Och för mer information om Unicode som UTF-8 kodar tecknen till, finns följande Engelska Wikipedia sida för Unicode till ert förfogande.

TITLE-tagg

Därefter följer sidans <title> tagg som ni bör ha goda kunskaper om vad den fyller för funktion(er).

HTML5 Shiv och IE-hack för att få HTML5 att funka

Nästa del av boilerplaten är ett Internet Explorer ”hack” för att använda ett script kallat ”HTML5 Shiv” med syfte att få HTML5 att funka i äldre versioner av Internet Explorer (, såväl som Firefox 2 verkar det som), som saknar stöd för standarden.

<!--[if IE]>
<script src="https://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

Vad HTML5 Shiv är, och gör

HTML5 Shiv är ett JavaScript fix (kräver alltså JavaScript aktiverat i webbläsaren för att fungera) & script som får äldre ovetande webbläsare att tolka de nya HTML5-elementen korrekt så att man sen kan använda dem och ge dem CSS-stilar utan att det blir oväntade fel och missförstånd när webbläsaren försöker sen översätta och tolka sidan.

Vad detta innebär är att de äldre webbläsarna har inga standard CSS-stilar för hur de nya HTML5-elementen är tänkta att presenteras (alla taggar har ju sina egna egenskaper för hur de fungerar och skall presenteras som webbläsaren får från standarden, saknas standarden dock = brist på standard stilar, egenskaper etc.), vad JavaScript då gör är att gå igenom sidan, identifiera de nya HTML5-elementen, och tilldela dem de nödvändiga egenskaperna (typ CSS-stilar) för att ”verka fungera som de är tänkta”.

Ni kan läsa mer om HTML5 Shiv på: deras GitHub sida: https://github.com/afarkas/html5shiv

Enda nackdelen med HTML5 Shiv är ju som sagt att det finns folk som inte litar på JavaScript och därför har det inaktiverat, då många använde det förr för att göra ”dåliga” saker på webben, vilket oftast lämnade besökare till vissa sidor med en sur eftersmak i munnen, p.g.a. irriterande eller ovälkomna webbupplevelser med reklam, virus, och andra otrevligheter.

ATT TÄNKA PÅ (Visdomsord): Tänk på detta när ni själva designar egna webbupplevelser, vilka besökare det är ni utvecklar webbsidan för, har de JavaScript aktiverat? Använder de gamla webbläsare? Osv. Frågor värda att ställa och ta med i beräkningarna för hur en webbsida skall byggas. Idag finns ännu ett element att överväga, och det är Hur era besökare kommer att besöka er webbsida, kommer de göra det via dator, mobil, surfplatta, eller annat? Vad stödjer den enheten som just dina besökare använder för att visa din webbsida? Behöver du kanske vidta speciella designåtgärder för om de använder pekskärm, eller ej? osv :)

On-page CSS-stilmalls kodblock

Nästa del i HTML5Doctors boilerplate är ett <style> block-element som sträcker sig över flera rader, som håller On-page CSS-stilar, vilket sällan är rekommenderat – speciellt om man har många undersidor, men anledningen till deras användning i det här fallet, är då deras mall enbart är tänkt att utgöras av 1 enstaka fil! Och då är det okej :) Annars vid större webbprojekt bör man överväga att placera denne CSS-kod i ett extern CSS-kods dokument, men mer om detta senare när vi börjar gå igenom CSS-kodning.

CSS-koden som HTML5Doctor har angivet i detta On-page CSS-blockelement är kod för att informera (även här) ovetandes webbläsare om hur block-level element skall presenteras genom att lista alla elementen och tilldela alla elementen en och samma stil, nämligen display as block.

Slutligen body och stängning av öppnade taggar

Sedan följer det gamla vanliga som ni kan se, <head> taggen stängs, innan <body> taggen öppnas och stängs, för att representera webbsidans ”kropp” som sen kommer bli presenterad för besökarna.

Slutkläm & presentation av framtida inplanerat inlägg

Det är inget fel med att använda någon annans kodmall, speciellt inte när den är så välgjord som den vi gick igenom ovan. Personligen är det min favorit kodmall att utgå från (eller brukade vara åtminstone), dock så har jag numera vidareutvecklat den en aning för mina egna sidor jag brukar bygga, dels har jag piffat upp den med PHP som förebyggande för att ha multipla undersidor med samma mallkod – för att undvika att behöva ändra på varje enstaka undersida bara för att alla har samma sidhuvud/sidfot, t ex. Med hjälp av PHP dynamisk konstruktion av kodmallen så används en och samma sidhuvud, respektive sidfot till samtliga sidor.

Jag inkluderar även för mina egna sidor:

  • Externt stylesheet (CSS-stilmall för samtlig CSS koder),
  • ibland en CSS ”printstyles” alternativ extern stilmall (för utskrifts stilar för sidor – inte ofta dock),
  • meta-taggar för On-page sökmotoroptimering,
  • favicon inkludering,
  • ibland eget visitor-tracking PHP-script,
  • Google Analytics i botten av sidan,
  • jQuery kod såväl som JavaScript filer (om det används för sidan),
  • LESS CSS preprocessor kod om jag använder det för CSS-kodningen (inte ofta),
  • Eric Meyers CSS-Reset v.20 för HTML5-reset,
  • Ibland Modernizr för HTML5/CSS3 feature detection (JavaScript bibliotek som hjälper till att upptäcka stöd för HTML5 och CSS3 funktioner hos besökaren, så man då kan vidta åtgärder baserat på om stöd skulle saknas, eller ej)
  • Google Fonts för typografiskt teckensnitt stöd och-
  • ibland övriga JavaScript filer.

Såja! Då har vi gått igenom HTML5-kodmall ordentligt i det här inlägget.

Låna gärna av ovan presenterade mallkod, experimentera på egen hand, lägg till, ta bort, och jämför vad som händer och se vad som blir annorlunda vid validering av koden.

Tills nästa gång ;)

av ·0 kommentarer

Detta inlägget skriver jag i syfte om att informera er läsare som sysslar med- och är intresserade utav webbdesign/webbutveckling eller kanske bara datorer och internet i allmänhet och någon gång stött på länkadresser i något sammanhang.

För många som använder internet idag så känner de säkert igen länkar / URL:er som ser ut som t ex: http://www.domain.se , eller www.domain.se eller domain.se .

Alla ovan är giltiga länkar som tar med olika delar, för webbutvecklingssyfte brukar man använda sig av 2 typer av navigerings-länkadresser när man hänvisar till material som skall användas på sidan, eller hämtas in från utomstående källor: Globala/Absoluta resp. Lokala adresser.

Absoluta/Globala länkadresser

Den första är den absoluta/globala länkadressen, som inkluderar http://www , vilket är den del av en länkadress som indikerar bl. a. vilket protokoll som används för kommunikationen webbläsaren hanterar. Protokoll är utanför det jag tänkt gå igenom, men kan åtminstone nämna att http är HyperText Transfer Protocol. Och som jag nämnt vid ett tidigare tillfälle är i stort sett ”hypertext” = webbinnehåll. Vilket då gör att protokollet på svenska skulle kunna kallas webbinnehålls överförings protokoll.

Som ni säkert också noterat så är absoluta/globala länkadresser ofta inkluderande domännamnet för själva webbsidan som länken leder till.. Exempel: www.domain.se

Hur som helst, det var en typ av adresser som används, och den brukar användas speciellt om man hänvisar till innehåll från externa, eller utomstående källor annat än ens egna webbsida.

ATT OBSERVERA! När dessa länkadresser används så hänvisar ni till någon annans webbserver/webbhotell, vilket innebär att ni ”lånar/snor” deras resurser för att kunna ladda det externa innehållet till er webbplats – i vissa fall anses detta som okej, i andra, inte lika okej.. Det är upp till er även här att ha koll på när det är lämpligt att använda sådana adresser, speciellt om ni gör webbprojekt åt kunder, då kan det vara extra viktigt(!).

Lokala länkadresser

Lokala länkadresser är den andra typen av länkadress som är populär att använda sig utav när man pysslar med webbutveckling. Lokala länkadresser utgår från själva källkods/webbdokuments-filen som skall hänvisa till innehåll via länkadress. Som exempel för detta kan ni föreställa er att vi har vår index.html webbdokuments fil som har en <img> tagg källa (src) som skall peka på en bild i en undermapp som vi har på vår webbserver eller webbhotells domän inuti en undermapp.

För att lättare förstå Lokala länkadresser kan det vara behjälpligt att se hierarkin framför sig, därför har jag tagit en screenshot av en exempel-hierarki som ni kan jämföra med och se hur jag menar, se nedan:

mapphierarki exempel vid webbutveckling

Mapp-hierarki för webbutvecklings projekt

Som ni då kan se i ovan bild så har vi index.html i den s.k. ”rotmappen” – högsta hierarkiska lagret i projektmappen, och sedan har vi en bild: fruit.png inuti mappen bilder.

Med detta vill jag då visa och jämföra att en Lokal länkadress hade bara sett ut som följer: bilder/fruit.png då den utgår från källkodsfilen som skall hänvisa till bilden och navigerar inuti egna webbservern skulle man kunna säga. http://www. har man inte med som ni ser, och inte heller själva domännamnet i fråga för webbsidan. För lokala länkar är allt som behövs navigering utifrån filen man länkar från inuti ens egna server/domän.

Globala/absoluta länkar vs. lokala länkar

Global/absolut länk:
http://www.domain.se/bilder/fruit.png

Lokal länk:
bilder/fruit.png

Om din webbsida finns på www.domain.se räcker det att ni använder er av lokala länkar, medan om www.domain.se inte är er domän, så bör ni använda globala/absoluta länkar (antaget att ni tänkt igenom just ert scenario och övervägt tillåtelse för användning, etc.).

Länkmekanik – Navigeringskommandon och funktion

Både Lokala såväl som Globala länkar har gemensamma möjligheter att navigera sig fram till olika filer och undermappar, detta tack vare båda typerna av länkar hänvisar till webbservrar, vare sig det är ens egen, en hyrd, eller någon annans.

Ni kan föreställa er länkmekanik som det sättet ni själva använder när ni navigerar er bland era egna mappar på er egna dator – fast istället för att göra det med muspekaren, så kommer vi använda kommandon i textform – typ såsom man kan göra via konsollfönster/CMD i Windows.

Gå in i undermappar

För att gå in i undermappar från en nivå ovanför den undermappen, så kan man använda mappnamnet + snedstreck (/) som t ex. ger: bilder/ för att gå in i bilder-undermappen som ni ser på screenshotten av en exempel hierarki ovan.

För att gå in i först en undermapp, och därefter ytterligare en undermapp inuti den första undermappen man gick in i, upprepar man bara samma kommando som då kan se ut såhär exempelvis: 1:a undermappnamnet + snedstreck (/) + 2:a undermappnamn + snedstreck (/), vilket då kan resultera i: bilder/slideshow/ <- om vi antar att vi hade haft en undermapp vid namn slideshow inuti bilder.

För att komma åt filer i undermappar

Så skriver ni filnamn + filtyp direkt efter snedstrecket (/) som tog er in i en undermapp där filen ni är ute efter befinner sig.

Exempel: bilder/fruit.png

För att komma åt fruit.png inuti bilder-undermappen.

Backa ur en undermapp

För att ”backa ur” en undermapp så använder man ett kommando bestående utav 2 st. punkter (.) + ett snedstreck (/), ser ut som följer: ../

Så om ni föreställer er att vi har gått in i undermappen bilder i ovan exempel, och vill ta oss tillbaka till rotmappen, så skriver vi: bilder/../  <- vilket i det här fallet är samma sak som +/- 0, med andra ord, ganska meningslöst.

När är detta användbart då om det i stort sett är meningslöst för ovan demonstrerade scenario? Jo, om ni tänker er att vi vill länka till en bild från vår styles.css stilmalls fil som ligger inuti undermappen css så måste vi först ta oss ur css-undermappen för att sen kunna gå in i bilder-undermappen för att komma åt bilden vi vill hänvisa till.

Exempel på detta (tänk er att vi länkar från styles.css): ../bilder/fruit.png <- ger oss en utmärkt lokal länkadress för att kunna komma åt bilden fruit.png från vår styles.css stilmalls fil.

1) ../           först tar vi oss ur css-undermappen.
2) bilder/       sen går vi in i bilder-undermappen.
3) fruit.png     slutligen kommer vi åt fruit.png bilden i bilder-undermappen.

av ·0 kommentarer

Två attribut som gäller för i stort sett alla HTML-taggar är attributen: id och class.

ID attributet: används för unik identifiering av ett element på en enstaka webbsida, vilket betyder att samma ID-värde får enbart finnas för 1 specifikt element på en hel webbsida!

Medan class attributet kan finnas på flera element på samma webbsida.

Båda attributen används för att identifiera, och välja (eng. select) taggar från t ex. CSS-kodning eller JavaScript kod.

ID-referens ger även Lokala ankar-länkar

ID attributet kan även användas för att specificera specifika s.k. ”lokala ankar-länkar” till en sidas innehåll. T ex. om du har en artikel på din sida med 5 olika stycken, och du vill kunna länka till var och ett av de specifika styckena, då kan man ange ett ID attribut till HX taggarna om varje stycke har en headline dvs. eller bara till Paragraf taggarna själva. Mer om detta kommer att gås igenom i ett inlägg om HTML länkar som jag kommer skriva lite längre fram! Se nedan exempelbild.

lokala ankarlänkar via id

Lokala ankarlänkar via ID i URLen

Praktiskt exempel

Som ett praktiskt exempel kan ni ju föreställa er om ni har en webbsida med 15 st. paragrafer, och ni vill lägga på speciella stilar för paragraf #10 av de 15 som finns på sidan, hur hade ni då kunnat ”sikta in stilarna på just den taggen”? Jo, antingen hade ni gett paragraf #10 id attributvärde så att den kan hittas från CSS/JavaScript via ID:t, eller så hade man gett paragraf #10 ett class attributvärde.

Enda skillnaden är att om ni sen skulle komma på att samma stilar hade sett snyggt ut för även paragraf #2, #5 och #8, så hade ett ID attribut inte kunnat anges på flera olika element på samma sida! Däremot hade ett class attribut kunnat anges på flera element på samma sida(!), och därmed hade alla elementen med samma class attributvärde, delat samma stilar!

Användning av flertalet Klasser/ID:n för ett och samma HTML-element

Denna praktik kan vara användbar om man har många olika separata klasser som var och en håller delar av stilmalls kod som man vill använda tillsammans för ett och samma element, utan att ange en ny klass där stilarna från t ex. 2 olika klasser skrivits om på nytt för att kunna finnas sammansatta, istället kan man ange multipla klasser/id:n genom att separera vart och ett med ett simpelt mellanrum som attributvärde.

Se exempel nedan:

<div class="klass1 klass2 klass3 klass4"></div> <- denna div får stilarna från klass1, klass2, klass3 och klass4.

<div id="id_1 id_2 id_3 id_4"></div> <- denna div får stilarna från id_1, id_2, id_3 och id_4.

Ett lite mer praktiskt exempel hade kunnat vara:
<div class="fontArial colorGreen fontSize13px normalPadding"></div> 

Ovan div och allt den innehåller får stilar från klass: fontArial, colorGreen, fontSize13px och normalPadding.

Sammanfattning

Så sammanfattat- Vad är då poängen med ID jämfört med Klasser?
Jo, ID använder man om man är säker på att referensen endast behöver/kommer att göras endast en gång! Klasser är till för motsatsen -> När du vet säkert att samma stilar eller samma typ av referens kan komma att behöva återanvändas på fler ställen på samma webbsida!

Så nu har ni fått en ”Crash Course” i även Klasser och ID:n ;) Enjoy :) Ni kommer att ha stor användning av kunskapen om dessa framöver!

av ·0 kommentarer

Var man skriver HTML-koden för sin egen webbsida

Man kodar hemsidor i texteditorer, som t ex. Notepad, Notepad++, SublimeText, eller annat program, det finns även IDE’s (Integrated Development Environments), som stödjer HTML-kodning.

Vissa har mer funktioner och finesser än andra, själv föredrar jag att koda i Notepad++, användarvänligt, enkelt, rent och praktiskt(!) Men vanliga Notepad hade funkat lika bra till en början :)

Hur man sparar HTML-kod inför granskning

När man väl skrivit sin HTML-kod i ett textdokument så sparar man textfilen som filtyp med filändelsen .html för att göra textfilen till en webbdokuments fil, närmare bestämt en HTML-fil.

Förhandsgranskning av HTML-kod i webbläsaren

När ert textdokument med HTML-kod väl blivit sparat som en .html fil, så brukar det vara intressant att se hur koden man skrivit ser ut i en webbläsare.

Detta kan göras ganska enkelt genom att öppna den nyligen sparade .html filen med en webbläsaren – vilken ni än har tillgängligt på er dator, om det så är: Google Chrome, Mozilla Firefox, Oracle Opera, Apple’s Safari, eller annan.

Tänk dock på att olika webbläsare kan skilja sig i hur de ”översätter och tolkar” er HTML-kod.

Olika definitioner/inställningar i olika webbläsare

Detta då olika webbläsare har olika inställningar som t ex. ”hur stor är 1 enstaka pixel” (vilket kan leda till olika layouter i olika webbläsare), eller ”om inga CSS-stilar angetts, hur skall HTML-element av den typen stil-sättas?”, m.m.

Där finns vissa skillnader mellan t ex. Mozilla Firefox och Google Chrome, men sen många år tillbaka har den som orsakat mest problem p.g.a. skillnader till andra webbläsare varit (ja, ni gissade rätt): Internet Explorer..

Internet Explorer börjar dock faktiskt bli bättre när det gäller översättning och tolkning av webbkod, dock kvarstår fortfarande problem på vissa fronter när man utvecklar för att det ska se ”likadant ut i samtliga webbläsare”, då vissa fortfarande är envisa med att byta från äldre versioner av Internet Explorer..

Varierat media stöd mellan olika webbläsare

Olika webbläsare stödjer också olika mediatyper för uppspelning av film och ljud – detta kommer vi gå igenom senare när vi börjar bli lite mer avancerade om hur man kan ”komma runt” detta, men för tillfället kan det vara bra att bara känna till att det finns skillnader för detta.

Därför kan det vara smart att kontrollera hur er webbsida ser ut i flertalet webbläsare – man kan ju trots allt ha hur många olika typer av webbläsaren man än vill på en dator.

Webbverktyg för webbläsar kompabilitets kontroll

Ute på nätet finns ett antal verktyg man kan använda för att genomföra just sådana här kontroller om hur ens webbsida ser ut i andra webbläsare (tror dock att ens webbsida först måste vara uppladdad till nätet isf.), sådana verktyg kan hittas på vår: ”Länkar” sida. Kolla efter BrowserStack eller annat webbverktyg.

CSS-reset för nollställning av webbläsares standard CSS-stilar

Senare när vi kommer börja gå igenom CSS kommer vi gå igenom något som kallas för ”CSS-Reset” och detta syftar till en framtagen testad, väldigt grundläggande CSS-kod som har i uppgift att ”nollställa” alla ”standard-stilar” som webbläsare har för element som inte har fått några stilar definierade specifikt av er själva som utvecklare – detta hjälper er då att få en ”clean-slate”/”blank-canvas” så man kan börja helt från scratch :)

Validera sin HTML-kod: Vad, varför och hur?

Validering av HTML-kod är en kontroll man kan göra för att försäkra sig om att man inte kodat fel någonstans enligt vad kodningsstandarden man valt dikterar som godkänd kod.

Varför vill/behöver man då validera sin kod? Jo, det är ganska smart att göra detta för att försäkra sig om att man inte har någon felaktig bit av kod som orsakar problem som i sin tur förstör för hur besökare ser ens webbsida, eller förstör för annat man försöker koda in på sin sida.

Dessutom kan det spara en väldans massa tid ”down the road” om man regelbundet validerar sin kod för att försäkra sig om att inga misstag begåtts under utvecklingsprocessens gång.

Det är väldigt bra att försöka göra rätt från början helt enkelt, besparar en från en hel del ”huvudbry” som annars kunnat komma djupare in i utvecklingsprocessen.

Hur Validerar man då sin kod? Jo, W3C (World Wide Web Consortium) har egna validator-verktyg som ni kan hitta på: https://validator.w3.org/

Ni går bara in på den sidan och sen väljer ni om ni vill 1. validera en fil genom att ladda upp den specifika fil ni vill validera, eller väljer ni att 2. validera en redan publicerad sida som redan finns ute på nätet genom att klistra in länk-URL:en/URI:en (Uniform Resource Locator/Identifier).

För utvecklingssidor man håller på med kan man: lägga in en länk på sin sida med en ”egen-referens” till validator-verktyget, vilket i sin tur innebär att allt man behöver göra är att klicka på den länken för att direkt få just den sidan man kom ifrån – att bli validerad. Referensen i själva länken pekar på sidan man kom från med andra ord, väldigt praktiskt och användbart!

Detta är i synnerhet väldigt användbart för att ha för validering av ens egna sidor medan man håller på att utveckla! En sådan länk ser ut som följer:
<a href=”http://validator.w3.org/check/referer”>HTML5</a>

Så även detta är en God Praxis att ta efter! ;)

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.