17 April 2008, geplaatst in XHTML door Davy
Johan (Wolfr) heeft het nieuwe design van zijn blog Wolf’s Little Store deze week gelanceerd. Vriend Dieter heeft hierop al zijn mening geventileerd. De conversaties over dat nieuwe design zijn jammer genoeg verspreid, maar ik wou toch nog even inpikken op een conversatie op Twitter gisterenavond.
Wolf zegt dat de inhoudtafel op de homepage tabulaire data is. Ik ben het daar niet helemaal mee eens.
Waaruit bestaat zijn homepage? Uit een overzicht van alle artikels die op zijn blog zijn gepost. Technisch gesproken kan je dat wel in tabelvorm gieten, maar volgens mij kan je het eleganter oplossen.
Zo ziet de huidige markup eruit:
<table cellspacing="0" cellpadding="0" id="grid">
<tr>
<td class="date"><p>April 16, 2008</p></td>
<td class="category">
<ul class="post-categories">
<li><a href="" title="" rel="category tag"></a></li>
</ul>
</td>
<td><h2><a href="" rel="bookmark" title=""></a></h2></td>
</tr>
</table>
Eerste bedenkingen:
- Waarom zou je de datum in
<p> tag plaatsen?
- Waarom categorieën in
<ul> als je maar 1 categorie telkens gaat gebruiken?
- Waarom een tabel?
Waarom geen tabel?
Wanneer ik de CSS uitschakel en ik de broncode lineair overloop, dan krijg ik nu:
- datum
- categorie
- titel
Dit voelt niet goed aan. De titel is belangrijker dan de datum en de categorie, en dus zou die eerst moeten komen.
Een andere bedenking die ik me maak is: hoe zal de homepage zal weergegeven worden op mobile devices. Tabelrendering lijkt me door de kleine schermen minder evident.
Daarom zou ik met deze oplossing op de proppen komen:
<ul id="articles">
<li>
<h2><a href="" rel="bookmark" title=""></a></h2>
<p class="meta">
On <span class="date">April 16, 2008</span> in
<a href="" rel="category tag">Category</a>
</p>
</li>
</ul>
Via negatieve text-indent, en absolute positionering van de date en link, kan je de woorden ‘on’ en ‘in’ verbergen op de frontend.
Je zou zelfs een <ol> (ordered list) kunnen gebruiken, omdat het kan beschouwd worden als een numerieke opsomming van de artikels.
Een andere mogelijkheid is via een definition list, waarbij er een relatie bestaat tussen de titel van het artikel en de meta data:
<dl id="articles">
<dt><h2><a href="" rel="bookmark" title=""></a></h2></dt>
<dd class="date">April 16, 2008</dd>
<dd class="category">
<a href="" title="" rel="category tag">inspiration</a>
</dd>
</dl>
Niet alleen wordt de markup compacter, ook wanneer je CSS uitschakelt, leest het iets natuurlijker.
Via CSS kan je dan uiteraard identiek dezelfde visuele tabel creëren.
In HTML kan je meestal een probleem op verschillende manieren benaderen. Het is alleen kwestie van alle opties te overwegen en uitmaken wat een goeie manier is en wat de betere manier.
Minimal design is 1 ding, minimale markup iets anders.
20 Februari 2007, geplaatst in Apollo door Davy
Apollo is de codenaam voor de cross-platform runtime omgeving die momenteel nog door Adobe wordt ontwikkeld. De runtime zal het mogelijk maken om bestaande technologieën zoals Flash, Flex, HTLM, Javascript en Ajax te bundelen en zo Rich Internet Applications te ontwikkelen voor de desktop.
Net zoals de Flash player en de Acrobat Reader zal ook de Apollo runtime gratis beschilbaar zijn, voor zowel Windows, Mac als Linux.
Apollo zal vooral gebruikt worden bij offline applicaties, die occassioneel met het internet verbinding zoeken. Al hoeft dit niet de regel te zijn. Je kan evengoed zelf je eigen browser in Apollo ontwikkelen die dus bijna uitsluitend gebruik maakt van je internetverbinding.
Aangezien het een desktopapplicatie is, kan het beschikken over zijn eigen icoon op het bureaublad, in het dock of in het startmenu. Hierdoor kan je de aanwezigheid op de machine vergroten. Apollo applicaties kunnen voorzien worden van installatiewizards, snelkoppelingen, drag-and-drop functionaliteiten, klembord integratie, communicatie tussen verschillende applicaties, …
Het handige aan Apollo is dat het een system runtime is. Hiermee beschik je dus over de system file I/O, waardoor je lokale bestanden kan lezen en wegschrijven. De documenten op je machine kunnen dus gebruikt worden in de Apollo toepassingen.
Je Apollo applicaties kunnen tevens beschikken over een custom window chrome, waardoor je alle venster kan voorzien van eigen look-and-feel. Transparante windows behoren ook tot de mogelijkheden. Je bent dus niet meer afhankelijk van de browser of applicatie waarin je content zich vertoefd.
HTML in Flash, of visa versa?
Adobe heeft met het Apollo project een belangrijke stap gezet naar integratie tussen HTML en Flash content. HTML zal in voledig ondersteund worden en dit door de in Apollo ingebouwde WebKit HTML engine. Flash content zal dus HTML kunnen renderen, maar het kan evengoed zijn dat je HTML content laadt met daarin Flash inhoud.
Omdat een bestaande HTML rendering engine wordt gebruikt, zal er dus geen extra werk vereist worden van de developer. Je zal de HTML dus niet moeten testen tegen nog een browser op de markt. De WebKit werd ook gekozen omdat Nokia de engine ook gebruikt om zijn s60 platform. Safari, de browser op Mac OS X, gebruikt ook WebKit, maar dan de Apple WebKit variant, dus niet identiek hetzelfde framework als de webcore van het WebKit opensource project.
De HTML kan geladen worden vanop een netwerk, door een urlRequest, of dynamisch opgebouwd worden aan de hand van Actionscript. De HTML engine in Apollo zal voorlopig geen ondersteuning bieden voor plugins (zoals Quicktime, Windows Media, …). PDF support zal wel aanwezig zijn.
De Javascript voorzien in de HTML zal eender welke Flash of Apollo API kunnen aanspreken. Meer zelfs, je zal via Javascript de Flash displaylist kunnen manipuleren.
De Apollo technologie heeft in elk geval veel in zijn mars. Verwacht je dus zeker aan een boom in desktop applicaties van zodra Apollo gelanceerd wordt. Ik heb me alvast in deze nieuwe technologie vastgebeten en ben nu reeds bezig met dingen uit te proberen en de technologie te verkennen.
Van zodra meer info mag vrijgegeven worden zal ik dit zeker doen.
23 Januari 2007, geplaatst in Email door Davy
Sinds de bekendmaking door Microsoft is er al heel wat over gezegd geweest. Outlook 2007 zal in plaats van de huidige IE6 of zelfs de vernieuwde IE7 rendering engine gebruik maken van de HTML renderer die in Word zit.
Zoals ieder weldenkend mens vind ik dit een slechte zet. En aangezien ik regelmatig al eens HTML e-mails moet opmaken zal dit uiteraard ook invloed hebben om mijn huidige workflow.
Zoals te lezen in de post van Molly en op Campaign monitor probeert Microsoft met deze beslissing consistentie te creëren tussen hetgeen de Word gebruiker opstelt als e-mail en hetgeen effectief in Outlook gerendered wordt.
Ik vind dat de wereld op zijn kop zetten. In plaats van de rendering engine van Word te verbeteren, verslechteren ze de engine van Outlook. Probeer die logica maar eens te volgen, dit tart gewoon alle verbeelding.
Wat ze bij Microsoft blijkbaar belangrijker vinden is, dat een amateur in Word op een luie zondag een pruts HTML email in elkaar kan flansen, dan de duizenden bedrijven die dagelijks HTML e-mails versturen, op een - hopelijk - toch wel professionelere manier.
Ik versta dat Microsoft zijn producten verder wil innoveren en het voor de doorsnee gebruiker mogelijk wilt maken om met zijn geliefde Word mailtjes te versturen. Alleen mag dit niet ten koste gaan van de huidige HTML e-mails. Het zou me niet verbazen als een zeer groot percentage van de e-mails die dagelijks worden verzonden plots niet meer goed worden weergegeven. En wie zal daar de dupe van zijn? De webontwikkelaar die alles weer mag oplossen.
Ieder voor zich kan natuurlijk zelf beslissen welke e-mail client hij gebruikt. Ik heb Outlook snel achter mij gelaten en ben op PC overgestapt naar Thunderbird. Op Mac heb ik altijd al Mail gebruikt. Alleen is het net zoals bij Internet Explorer dat we moeten rekening houden met die grote massa die collectief Outlook gebruikt als favoriete e-mail client.
Ook de discussie van HTML tegenover text e-mails gaat volgens mij niet op. Ook al wordt al te vaak HTML foutief gebruikt bij e-mails, toch mag het niet als duivels bestempeld worden. HTML e-mail kan een verrijking betekenen, maar zoals steeds is overdaad dodelijk. En teruggaan naar plain text e-mail is niet dé oplossing.
Microsoft heeft met de lancering van Internet Explorer 7 een duidelijke stap in de goede richting gezet. Zelf ik kon wel enigzins lof opbrengen voor de verbeteringen in Internet Explorer. Maar blijkbaar hoort bij elke innovatie een krampachtige beweging achterwaarts. Hopelijk heeft Molly gelijk en is Microsoft alsnog bereid te luisteren.
In de tussentijd zullen we moeten leren leven met de gebreken van Outlook 2007. Alweer bedankt Microsoft…
26 Oktober 2006, geplaatst in CSS door Davy
Wanneer ik een website bezoek heb ik nogal vaak te neiging om de broncode ervan te bekijken. Natuurlijk niet bij alle sites, maar toch die van collega’s, of sites die ik inspirerend vind. Broncode van goede sites bekijken heeft ertoe bijgedragen dat ik nu zo handig overweg kan met XHTML en CSS. Maar ook het bekijken van slechtere voorbeelden kan verhelderend zijn.
De afgelopen weken en maanden heb ik mijn eigen manier van werken onder de loep genomen en het verder verfijnd. Zo heb ik op het werkvloer een aantal HTML en CSS templates gemaakt die kunnen dienen als startpunt voor nieuwe websites. Daarnaast heb ik bij Marlon ook nog een stijlgids geschreven met daarin mijn methodiek uitgelegd alsook een referentie voor veelgebruikte XHTML elementen. Alvast hier enkele tips en conclusies.
Wees consistent bij naamgeving
Dit is niet alleen belangrijk bij XHTML en CSS productie, maar ook bij het programmeren en scripten. Wees consistent bij het benoemen van elementen, functies, variabelen, … Vaak zie ik in de broncode van websites dat de maker sommige elementen een Engelstalige id of classe geeft, en andere dan weer in het Nederlands benoemd. Het is wel zo dat je sommige elementen moeilijk naar het Nederlands kan vertalen, maar daarom ben ik ook van mening dat je alles in het Engels moet plaatsen. Dus zowel bij XHTML en CSS als bij programmeren.
Dat is iets dat vooral nog voorkomt bij studenten, stagiairs en programmeurs van de oude stempel. Maar je vergroot de leesbaarheid van je bronbestanden enorm door deze tip te hanteren. En zoals Vincent altijd zegt: Je weet nooit wie je broncode nog moet gebruiken
.
Probeer ook een zekere consistentie te hanteren bij de casing van een id of classe. Zelf schrijf ik alles met kleine letters en scheid ik meerdere woorden aan de hand van een koppelteken (-). Kleine letters omdat XHTML ook in lowercasing staat. Een visuele scheiding tussen verschillende woorden vergroot de leesbaarheid en dus opteer ik voor dat koppelteken (of hyphen).
Bijvoorbeeld:
class="sidebar-news"
De underscore is af te raden, omdat het niet ondersteund wordt door de W3C specificatie, alsook niet in sommige browsers.
Structuur leidt tot productiviteit
Door mijn CSS files goed te structureren, weet ik voortaan perfect waar elk deel van de site zich bevindt. Door de verschillende stijlen onder te verdelen in groepen naargelang functie of plaats in de site is het voortaan een simpel denkwerkje om te achterhalen waar ik moet zoeken om een bepaalde stijl te wijzigen. Hiervoor baseer ik me op het modulair CSS principe, maar verfijnd naar mijn eigen visie en manier van werken.
Wat ook zeker helpt bij het verhogen van je productiviteit is voor jezelf een bepaalde volgorde bepalen voor de verschillende CSS properties. Zo doe ik het:
- float of position
- display
- overflow
- margin
- padding
- width
- height
- specifieke eigenschappen
- font
- text
- color
- border
- background
Specifieke eigenschappen kunnen zijn: list-type, cursor, vertical-align, … Text eigenschappen zijn dan weer: line-height, letter-spacing, decoration, …
Door op deze manier te werken kan ik sneller bepaalde properties terugvinden die in een grote stijlclasse zijn opgesomd. Het vergroot voor mij alleszins ook de leesbaarheid. Maar het is belangrijk dat je voor jezelf eens op een rijtje zet welke volgorde jij prefereert. Misschien ben je wel het chaotische type en hou je wel van wat zoekwerk.
Shorthand properties
Sommige CSS elementen kunnen gespecifieerd worden op 1 enkele regel. Persoonlijk vind ik dit een handige shortcut en wordt alles wat leesbaarder. Toch zijn er ook ontwikkelaars die dit tegenspreken en de normale manier van werken beter vinden. Aan u de keuze… Alvast hier een voorbeeld:
.someclass {
margin-top: 10px;
margin-bottom: 10px;
margin-left: 0px;
margin-right: 20px;
}
Kan aan de hand van een shorthand property omgetoverd worden tot:
.someclass {
margin: 10px 20px 10px 0;
}
De volgore van de properties is: top, right, bottom, left (TRouBLe). Dit kan mij dan uiteindelijk brengen tot:
.someclass { margin: 10px 20px 10px 0; }
Dit laatste doe ik wel enkel wanneer er slechts 1 CSS eigenschap wordt gedefinieerd.
De meest gebruikte shorthand properties zijn: font, background, list-style, margin, padding en border.
En ten slotte: wanneer een hexadecimale kleur is samengesteld uit 3 paar hexadecimale getallen, dan kan je deze inkorten tot 3 getallen.
Vb: #000000 wordt #000 en #667733 wordt #673
Tot zover deze korte toelichting over mijn structureren van CSS files. Ik heb hier zeker niet willen bewijzen dat mijn manier van werken de beste is, maar ik heb wel willen aantonen dat het belangrijk is na te denken over hoe je iets aanpakt. U bent alleszins vriendelijk uitgenodigd om mijn CSS bestand(en) te bekijken. Reacties zijn zoals altijd meer dan welkom.