Kmom02: HTML-element och CSS-konstruktioner

OBS! Uppladdad till min mapp i servern finns det ett fåtal php- och CSS-filer vars namn slutar med "_fern". Dessa utgör en ”alternativ” version av min sajt som jag kastade ihop till en bekant för skojs skull och vilken jag använde som ursäkt för att leka mer med Gradient. De är inte tänkta att ses som en del av min inlämning (såvida man inte får bonus-poäng för regnbågar). Startsidan för den alternativa sajten, vars nav-meny är "avstängd", nås genom "me_fern.php". Jag har noterat att denna ”alternativa” version av min sajt inte valideras helt korrekt i skrivande stund, men detta var som sagt bara ett sido-projekt för skojs skull. I skrivande stund måste "me_fern.php" öppnas i Firefox, Safari, eller Opera för att allt ska visas korrekt.

Jag genomförde alla uppgifter, inklusive de valbara (dvs. stöd för HTML5 i Internet Explorer och inställningen så att en scrollbar alltid syns oavsett sidans längd).

Några av de HTML-element jag lade till är audio (ett nytt media-element för HTML5, för vilket jag angav en source-fil som är ett stycke ”klassisk minimalism”), article (nytt för HTML5), figure (nytt för HTML5), nav (nytt för HTML5), ordered list, unordered list, strong och emphasis. Somliga av de brukas endast i ”me.php” och andra endast i en ny sida jag lagt till, kallad ”favorites.php”, som även den går att nå via min nav-meny.

De ”extra” CSS3-konstruktioner jag lade till är Gradient och Opaque; Bakgrunden för sajtens body är nu en Gradient från mörkblå till ljusblå och bakgruden för sajtens ”div#content” är en Gradient från ogenomskinlig vStiit till 25% genomskinlig vit, dvs. en kombination av Gradient och Opaque. Denna Opaque är inte omedelbart uppenbar, men byter man mellan ex. den korta me-sidan och den långa favorites-sidan så märker man att det nog allt är så att det är en något genomskinligt Opaque-yta som blandar sig med den blåa Gradient-bakgrunden. Jag gav även Opaque till nav-menyns ”highlight”-box som man ser när musen är över ett menyval, vilket är ett mer uppenbart bruk. Jag använde de proprietära kit för Gradient och Opaque som behövs för att dessa style-inställningar skall visas korrekt i Chrome, Safari, Opera, Firefox, och Internet Explorer (åtminstone version 11), dvs. Mozillas moz-linear-gradient, Microsofts ms-gradient-linear, osv.

Det var inte svårt att följa resonemangen i kursmomentet och instruktionerna fann jag tydliga. Firebug, som jag fann särskilt användbart och brukade under min utveckling, tyckte jag var lätt att sätta sig in i, och uppgiften att flytta bilden till vänster var lätt då jag ju insåg att det fanns (eller antog att det förmodligen fanns) en class för vänster-justering kallad "left", antingen som fristående klass eller just för figure-tags. Med hjälp av experimentation med Firebug löste jag snabbt ett problem som uppstod för mig vilket var att jag inte lyckades få en av mina figures att placera sig till höger på sidan. Anledningen till att denna figure inte lades på rätt plats var att jag hade gjort vad jag trodde var en bra skalning av den img-tag som min figure-tag omsluter, men denna skalning visade sig ”förvrida” figure-element så att det blev såpass brett att en right-align inte gjorde någon visuell skillnad. Vad som löste problemet för mig var att ändra så att jag endast satte en måttenhet (i pixlar) på höjden för img-sourcen (dess största dimension), men idealet vore väl att jag helt enkelt skalar om bilden i ett ritprogram och laddar upp den i rätt storlek.

Resultatet är nu en sajt med lite av ett Batman-tema, en sajt som jag tycker är betydligt finare än den som blev resultatet av min prestation under första kursmomentet. Jag valde att låta min div#content vara betydligt smalare än motsvarande i MOS variant, endast p.g.a. att jag tyckte det såg snyggt ut, oavsett om det nu är praktiskt eller ej eller om det går emot vettiga konventioner eller ej.

Under arbetets gång fick jag ett antal varningar/råd som lite oväntade;

(1) Då jag hade en kommentar före doctype i ett dokument fick jag varningen, "Comments seen before doctype. Internet Explorer will go into the quirks mode.” Då jag ju inte vill att IE ska gå in i Quirks-mode (och riskera att visa sidan på fel vis) utan vill att den skall utvärdera min sida som om den skall hålla sig till HTML-standarden så flyttade jag ju förstås på kommentaren.

(2) Internationaliseringstestets resultat var ett råd att jag borde ändra head-taggens meta-tagg som satte ”http-equiv="Content-Type" content="text/html; charset=utf-8"” till bara ”meta charset="utf-8", vilket jag då gjorde.

(3) Först angav jag "type=mp3" inuti min audio-tag, men tydligen tillåts ännu inte något type-attribute för audio-taggen (till skillnad från för video-taggen) så jag tog bort detta.

(4) Jag fick varningar för mitt bruk av proprietära ”kits” för mitt sättande av Gradient och Opaque (moz, webkit, osv.) sägandes att dessa properties är "unknown vendor extension". Det föreslogs dock inte att något borde ändras och från vad jag förstått så verkar det som om man helt enkelt får godta dessa varningar för somliga nya CSS3-features, tills dess att implementationer som följer CSS3 korrekt finns klara att användas istället för dessa ”kits”.

(5) Då jag hade embeddat ett par YouTube-klippet blev jag informerad av validatorn att deras embed-kod har med ett obsolete element, ”frameborder”, vilket jag tog bort.

Jag är nybörjare inom HTML och CSS och nedan står några av mina tankar kring de två:

Jag gillar att utöver den mångfald av fördefinierad mark-up som finns inom HTML finns det även div- och span-tags att bruka när det inom HTMLs mark-up ej finns en tag vars betydelse passar ändamålet, så man inte behöver missbruka tags avsedda för annat.

Det "kaskaderande" bestämmandet av vilka CSS-regler som gäller för ett visst HTML-element känns intuitiv - ju närmre elementet bestämmandet sker och ju mer specifikt bestämmandet är desto oftare är det just den regeln som gäller (lite likt många programmeringsspråks konvention att lokala variabler med samma namn som globala variabler ersätter de globala) med undantagsfall vid bruk av exempelvis !important - och den mångdfald av selektorer för att specificera var man vill applicera den relaterade CSS-koden känns så gott som heltäckande.

Uppdelningen med att HTML sköter data/struktur och att CSS sköter presentation känns än så länge bra p.g.a. dess "modularitet" (via länkande/import), den enkelhet med vilken man skulle kunna låta användare ändra sidans presentation, med alternativa stylesheets man själv kodat och/eller som användaren har kodat/funnit (ex. skulle en person med synproblem och/eller känsliga ögon kunna införa en stylesheet som gör text större och ger mildare färgare), möjligheten att lätt erbjuda alternativa styles beroende på var sidan presenteras (desktop PC, telefon, i en viss webbläsare, i utskrift, osv), samt det faktum att koden blir, enligt mig, mer lättläst om inte de två olika språken blandas så mycket.

Angående filstruktur så kan jag tänka mig att man skulle vilja ha olika kategorier med stylesheets för en sida (utöver den man eventuellt har för debug och de man har för olika media), och olika alternativ inom dessa avsedda för olika delar av en sida. Exempelvis stylesheets som sköter just text-inställningar, stylesheets som sköter länk-inställningar, stylesheets som sköter bild-inställningar. Det blir ju förvisso extra ”round-trip time” för att hämta extra stylesheets (åtminstone tills de har hamnat i webbläsarens cache), men jag skulle behöva utföra mer gedigna tester, kanske brukandes något såsom Googles PageSpeed-plugin, för att se med mina egna ögon om det verkligen är betydligt illa med en viss stor mängd stylesheets. För övrigt har jag nog så gott som vant mig vid hur php- och css-filer kopplas samman på olika vis, vilket lite liknar "includes" i diverse programmeringsspråk jag har god erfarenhet inom.

Angående katalogstruktur så tycker jag att den fungerar bra än så länge och har inte funnit någon anledning till att göra den mer invecklad för en sådan här liten sida, men jag kan tänka mig att för en mycket större sida, eller en sida med mer varierat innehåll, så kan det ju vara bra att kategorisera ens material i underkataloger. Till exempel så tycker jag det vore en bra idé att man, om man bygger en sajt för att presentera fotografier man tagit, har en bild-katalog med minst en underkatalog just för fotona och minst en underkatalog för de bilder som är del själva sidans design (ev. logos, osv.)

4. Vad anser du om guiderna html20 och css20? Saknar du något i dem eller har du en annan syn på hur html/css skall organiseras?

Jag tycker HTML20- och CSS20-guiderna är lagom kortfattade som komplement till kurslitteraturen (som jag tagit mig igenom trots att den varit lite segläst för mig) och instruktionerna i kursmoment, med bra länkar till wc3.org för vidare läsning. Jag undrade ett tag varför span-taggen inte nämndes i samband med div-taggen, då dessa fyller liknande funktion och menas (av kurslitteraturen) vara ofta förekommande, men noterade sedan att den taggen togs upp som en fotnot. Guiden för CSS var mindre beskrivande av beståndsdelarna av CSS-koden än guiden för HTML var av HTML-koden och det kanske vore värt att, i CSS-guiden, ha med något mer om selectors och properties (även om det ju länkas till w3cs cheatsheet för dessa i guiden) och att ha med något kort om classes, id, och måttenheterna (risken blir ju dock att guiden inte längre blir kortfattat och tappar fokuset på hur CSS är i ”symbios” med HTML mark-up).

En av de mindre avvikelser från MOS kod som jag har i min kod i skrivande stund är att ”div id=”content””-taggen finns i slutet på min ”header.php” och att dess slut-”div”-tag finns i början av min ”footer.php”, eftersom det för närvarande verkade okej att automatiskt få content-omslutning för alla dokument med ”content” som jag kan tänkas lägga till, men än så länge har jag egentligen inte nämnvärt annorlunda synpunkt på hur man "ska" hantera en sidas layout med HTML/CSS-kod än vad som föreslås i guiderna, och layouten där, som vi instrueras följa i kursmomenten, verkar som sagt vara den som de flesta sidor följer, åtminstone i stora drag. Vill man avvika från sådan layout så vore det väl mest p.g.a. estetisk preferens, samt bruk av Javascript och/eller andra objekt som man har för att presentera och navigera bland information eller, om man vill ha det riktigt häftigt men kanske mer rörigt än praktiskt, kanske t.o.m. presentation av web-dokument/program i en 3D-miljö.