Vertaling van de ciwas stylesheet authoring FAQ, zoals die te vinden is op http://css.nu/faq/ciwas-aFAQ.html
Deze FAQ-lijst bevat het bewerkte resultaat van een collectieve inspanning van de reguliere deelnemers aan de Usenet-nieuwsgroep... comp.infosystems.www.authoring.stylesheets
Het doel van dit document is het leveren van antwoorden op enkele van de meest voorkomende vragen in de Usenet-nieuwsgroep 'ciwas'.
Op dit moment hebben bijna alle discussies in deze groep te maken met CSS, alhoewel dat zou kunnen veranderen. Dit document tracht niet een complete handleiding voor stylesheets of CSS te zijn.
Er is een aparte FAQ-lijst over de Usenet-nieuwsgroep zelf, haar charter, gebruiken en conventies m.b.t. het plaatsen van berichten. Zie voor verdere informatie over stylesheets en CSS de bronnen die zijn opgenomen in het bronnendeel van http://css.nu/faq/ciwas-mFAQ.html
Enkele aanhalingstekens worden gebruikt om sleutelwoorden (keywords) aan te geven,
bijv. 'font-family'
en deze aanhalingstekens maken geen deel uit van het sleutelwoorden.
Dubbele aanhalingstekens worden gebruikt om tekst die wordt aangehaald vanuit een andere bron en/of jargon te markeren.
Zo geeft "Generic font family names are keywords..."
aan dat deze regel aangehaald materiaal bevat.
Deze vragen zijn als het topje van de ijsberg van een omvangrijk vraagstuk, waarover complete artikelen zijn geschreven en waarover zeer uiteenlopende meningen worden geventileerd.
Het WWW was oorspronkelijk ontworpen om gelijke inhoud in verschillende weergave-situaties en voor een scala aan 'lezers' te presenteren: op basis daarvan is "er hetzelfde uitzien" geen ontwerp-criterium; sterker nog, van verschillende presentaties zou moeten worden verwacht dat ze er verschillend uitzien.
Volgens sommigen is deze oorspronkelijke doelstelling niet meer relevant, en is het doel van webontwerp nu om om de verschillen tussen weergave-situaties weg te werken en de auteur de controle te geven over de details van de presentatie. Anderen wijzen erop dat CSS is ontworpen om de lezer aanzienlijke invloed te geven over dit proces, en dat dit ook wenslijk is, bijvoorbeeld om rekening te houden met gebruikers met een afwijkend gezichtsvermogen.
Het lezen van teksten op een beeldscherm is, door de relatief grove pixelstructuur van een monitor, geen sinecure; zelfs met een goede kennis van de weergave-details is het niet mogelijk om de gedetailleerde controle te bereiken die mogelijk is met, bijvoorbeeld, een printer. Wat ook het doel is, de praktijk leert dat veel van de pogingen die worden ondernomen om het precieze resultaat op het scherm te garanderen, belangrijke contraproductive bij-effecten hebben in een www-situatie.
De CSS-specificatie zelf beveelt aan, dat auteurs geen absolute afmetingen opgeven indien de weergave-eigenschappen niet bekend zijn. Er valt veel te zeggen voor een flexibel ontwerp, dat er onder de juiste omstandigheden uitziet zoals je het voor ogen had, maar dat toch zonder problemen inhoud en boodschap overbrengt in een breed scalaaan afwijkende browse-omstandigheden.
Voordat de technische details worden behandeld van wat er allemaal ingesteld kan worden, wordt dan ook ten zeerste aangeraden om enkele van deze artikelen over webdesign te lezen, en zelf een mening te bepalen over de sterktes en zwaktes van het medium, en over hoe je het beste de sterke punten in een webomgeving kunt gebruiken, zonder ten prooi te vallen aan de zwakheden.
Voorgesteld leesmateriaal...
http://style.cleverchimp.com/
http://www.westciv.com/style_master/house/good_oil/not_paper/
Alleen in uitzonderlijke omstandigheden kom je gebruikers tegen die een "gecalibreerd" weergave-apparaat hebben, dat lettertypes met een vaste grootte correct weergeeft. Dus we weten, dat we nooit de werkelijke afmetingen van letters weten zoals deze worden weergegeven bij een gebruiker.
Andere mensen kunnen de door jou gekozen lettergrootte onhandig vinden. Een verrassend groot aantal mensen hebben zichtproblemen en hebben grotere tekst dan gemiddeld nodig. Andere mensen hebben uitstekende ogen, en hebben liever het voordeel van meer tekst op het scherm, wat door een kleiner lettergrootte mogelijk wordt gemaakt. Wat voor jou op jouw systeem prettig is, kan onhandig zijn voor iemand anders.
Browsers hebben een standaardgrootte voor letters. Als gebruikers deze niet geschikt vinden, kunnen ze deze wijzigen in iets dat ze meer op prijs stellen. Je kunt er nooit vanuit gaan, dat jouw keuze beter is voor hen. Dus blijf voor het merendeel van de tekst van de lettergrootte af. Als je het op bepaalde plaatsen wilt aanpassen (bijvoorbeeld kleinere tekst voor een copyright-vermelding onderaan een pagina), gebruik dan relatieve eenheden, zodat de grootte in verhouding blijft met de al door de gebruiker gekozen grootte.
Onthoud, dat als mensen jouw tekst niet prettig leesbaar vinden, ze geen moeite zullen doen om zich door jouw site heen te worstelen. Slechts weinige (of helemaal geen) websites zijn belangrrijk genoeg voor de gemiddelde gebruiker, om het voor hem zinvol te maken, om de strijd aan te gaan met het idee van de schrijver van wat het beste is.
Voorgesteld leesmateriaal...
http://css.nu/articles/font-analogy.html
Zie ook Vraag 1: hierboven.
Het simpele antwoord is "Geen", en daarom biedt CSS vijf algemene lettertypes zoals 'serif', 'sans-serif', 'cursive', 'fantasy' en 'monospace'. Zet deze algemene lettertypes nooit tussen aanhalingstekens.
Een CSS-begrijpende browser zou een toepasselijke keuze moeten maken uit de beschikbare lettertypes naar aanleiding van een vraag naar deze algemene namen.
Het opgeven van enige andere lettertype in een www-omgeving, is niet meer dan een suggestie, die door de browser al dan niet gevolgd kan worden.
Het probleem met het gebruik van namen van specifieke lettertypes, is dat het weinig zin heeft om lettertypes te noemen die slechts weinig gebruikers zullen hebben, dus je bent beperkt tot een lijstje met enkele algemeen gangbare lettertypes. Dit overschrijft dan de veel betere keuze, die een minderheid van geavanceerde lezers mogelijk voor zichzelf hebben gemaakt.
Merk ook op dat lettertypes kunnen beschillen in de inhoud van hun tekenset, maar dat dit vaak niet blijkt uit de naam van het lettertype: door een ongeshikt lettertype te kiezen, kun je veroorzaken dat geïnternationaliseerde inhoud niet goed wordt weergegeven bij een deel van de gebruikers.
Let ook op dat MSIE op het Windows besturingssysteem enkele bugs heeft op het gebied van de lettertype-selectie, zoals hier beschreven...
http://css.nu/pointers/bugs.html
Zie voor meer details over de 'font-family'-eigenschap...
Sectie 5.2.2 "font-family" in de CSS1-specificatie...
http://www.w3.org/TR/REC-CSS1#font-family
Het korte antwoord is: dat kan niet, en je zou geen tijd moeten verspillen met het proberen om het precies hetzelfde te laten zijn. Webbrowsers kunnen, per definitie, een pagina interpreteren naar eigen goeddunken, binnen de algemene regels zoals verwoord in de HTML- en CSS-specificaties.
Als een webschrijver weet je niet van te voren wat de situatie precies is en/of welk medium gebruikt wordt om je pagina weer te geven, en het is bijna altijd tamelijk contraproductief om te proberen controle over dat proces te hebben.
Het is niet noodzakelijk voor een goed geschreven pagina om er hetzelfde uit te zien in verschillende browsers. Je kunt er naar streven dat het er goed uitziet in meer dan één browser, ook al zal de uiteindelijke weergave (in het geval van grafische browsers) een klein beetje afwijken.
"Er goed uitzien" kan worden bereikt met behulp van zinnig ontwerp en stijlregels, zoals het niet vastleggen van de grootte en lettertype van je letters, het niet vastleggen van de breedte van tabellen, enz...
Vecht niet tegen het medium; de meeste webgebruikers gebruiken maar één browser, en zullen nooit weten, of proberen er achter te komen, dat je pagina er anders, en misschien zelfs "beter", uitziet in een andere browser.
Dus aanvaard dat de flexibiliteit die is ingebouwd in het www-medium je vriend is, zorg er gewoon voor dat gebruikers makkelijk bij de inhoud kunnen komen en ontwerp je pagina's om dat te bereiken.
Daar kunnen verschillende oorzaken voor zijn. Een veel voorkomende fout is dat een externe stylesheet de een of andere vorm van HTML-markup bevat.
Een externe stylesheet mag alleen CSS-regels bevatten, en indien nodig goed opgemaakte CSS-commentaren; gebruik nooit welke HTML-syntaxis dan ook, zoals <style type="text/css">...</style>, in je externe stylesheets.
CSS-commentaar is alles dat wordt wordt geplaatst tussen
/* (markering begin commentaar) en
*/ (markering einde commentaar). Bijv. zoals hier...
/* Deze tekst hier is een correct CSS-commentaar */
CSS-commentaren kunnen meerdere regels in het stylesheet omvatten. Het nesten van CSS-commentaren is niet toegestaan.
Een andere oorzaak voor het niet functioneren van externe stylesheets (en zelfs van embedded en inline styleregels) zoals verwacht, kan zijn dat je hebt geprobeerd bepaalde CSS-mogelijkheden te gebruiken, die niet worden ondersteund door de browser die je gebruikt.
Browserondersteuning voor CSS varieert; en goede plek om meer te weten te komen over wat er wel en niet wordt ondersteund is "The Mastergrid"...
http://www.webreview.com/style/css1/charts/mastergrid.shtml
Externe stylesheets moeten door de www-server worden afgeleverd met het MIME-type 'text/css' in de HTTP-header 'Content Type:'.
Mischien moet je met je systeembeheerder overleggen over het toevoegen van dit MIME-type aan je server, als je de server niet zelf kunt configureren.
Geregistreerde MIME-types zijn te vinden in de IANA-verzamelplaats...
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/
RFC2318 beschrijft het 'text/css' MIME-type.
http://www.ietf.org/rfc/rfc2318.txt
HTTP-headerinhoud van www-bronnen kan hier worden bekeken...
http://www.delorie.com/web/headers.html
Netscape 4.x biedt slechts beperkte ondersteuning van CSS. Dat gezegd hebbende, moeten verder de volgende zaken worden opgemerkt.
Ongeldige HTML zal er bijna onvermijdelijk toe leiden dat Netscape jouw CSS-suggesties op een gegeven moment negeert. Je zult merken dat valide HTML je beste vriend is, maar om Netscape goed te laten werken, moet je zeker stellen dat alle elementen in je markup die afsluittags kunnen hebben, ook daadwerkelijk worden afgesloten.
Om dezelfde reden moet je je CSS-suggesties controleren en verbeteren. Netscape 4.x doet in feite precies wat het moet doen (in tegenstelling tot MSIE) volgens de CSS-specs, wanneer het stijlregels met fouten negeert.
Netscape 4.x heeft zogenaamd "overervingsprobleem" in het TABLE-element. Er kan worden betoogd dat Netscape het volste recht heeft om zich te gedragen zoals het doet in dit geval, maar aangezien de workaround tamelijk eenvoudig is, kunnen we deze net zo goed gebruiken en er verder niet meer over nadenken.
Stel dat je de inhoud van TABLE er "hetzelfde uit wilt laten zien" als de inhoud van BODY? "Redundante" stijlen kunnen daarvoor zorgen, zoals bijv. in
BODY, TABLE, TH, TD { /* voeg hier je stijlen in */ }
Over het algemeen heeft Netscape 4.x een voorkeur voor stijlregels die direct worden toegepast op de elementen waar ze nodig zijn. Je kunt nooit echt vertrouwen dat het overervingsprincipe op enig niveau in Netscape 4.x juist zal werken.
Zie...
http://css.nu/pointers/bugs.html
voor meer details over bugs en workarounds met betrekking tot Netscape's CSS-ondersteuning.
P { font-family: serif; font-size: 1.2em; }
Hier zien we een regel met een 'selector' P, die twee stijldeclaraties heeft gekregen, namelijk de twee 'eigenschap:waarde'-paren.
'font-family' en 'font-size' zijn eigenschappen van de inhoud van het element P, en deze eigenschappen krijgen respectievelijk de waardes 'serif' en '1.2em' toegewezen.
Een dubbele punt ':' is het symbool voor waarde-toewijzing in CSS, dus het gebruik van een gelijk-aan teken '=' in plaats daarvan is een fout, en de CSS-specificatie vereist dat zo'n toewijzing wordt genegeerd. Elke browser die deze stijl honoreert gedraagt zich verkeerd.
Voor lengte-waarden is altijd een 'eenheid' nodig, en er mag nooit een spatie staan tussen een getal en de bijbehorende lengte-eenheid.
Een waarde opgegeven als bijv. '1.2 em' is een fout en de CSS-specificatie vereist dat zo'n toewijzing wordt genegeerd. Elke browser die deze stijl honoreert gedraagt zich verkeerd.
Een puntkomma ';' tussen declaraties is verplicht, maar het is ook een goede "vuistregel" om de ';' ook na de laatste declaratie te plaatsen.
Krulhaken '{...}' tenslotte groeperen een of meer declaraties in de uiteindelijke CSS-regel.
Zie voor meer details over de beginselen van CSS-stijlregels Sectie 1 "Basic concepts" van de CSS1-specificatie...
http://www.w3.org/TR/REC-CSS1#basic-concepts
De meest directe aanpak is het definieren van aparte 'classes' voor de linksoorten, en deze classes direct te gebruiken in de <a href=...-markup.
Hieronder volgt een eenvoudig voorbeeld, gebaseerd op informatie uit de CSS2-specificatie, secties 5.11.2 en 5.11.3.
http://www.w3.org/TR/REC-CSS2/selector.html#link-pseudo-classes
http://www.w3.org/TR/REC-CSS2/selector.html#dynamic-pseudo-classes
a.internal:link { background: #c0c0c0; color: #800080; }
a.internal:visited { background: #c0c0c0; color: #008080; }
a.internal:hover { background: #c0c0c0; color: #00ffff; }
a.internal:active { background: #c0c0c0; color: #008000; }
a.external:link { background: #ffffff; color: #ff0000; }
a.external:visited { background: #ffffff; color: #0000ff; }
a.external:hover { background: #ffffff; color: #ffff00; }
a.external:active { background: #ffffff; color: #00ff00; }
En in de markup kan dan dit gebruikt worden...
<a class="internal" href="#foo">Link naar Foo</a> <a class="external" href="http://bar.baz">Link naar Bar</a>
...om een verschil in weergave voor te stellen tussen bijvoorbeeld de interne en externe links. De meeste CSS-eigenschappen zijn beschikbaar om stijlregels in te stellen voor links; het voorbeeld hierboven is alleen tot het minimum beperkt om ruimte te sparen.
Merk op dat de grammaticale regels voor CSS1 alleen het gebruik van de hier volgende linkselector toestaan...
a.internal:link { background: #c0c0c0; color: #800080; }
...terwijl de grammatica van CSS2 deze beide toestaat...
a.internal:link { background: #c0c0c0; color: #800080; }
a:link.internal { background: #c0c0c0; color: #800080; }
Aangezien ondersteuning voor de CSS1-syntax meer wijd verspreid is, wordt het aangeraden om alleen de CSS1-syntax te gebruiken voor link-style regels.
Er van uit gaande dat je al hebt gecontroleerd dat de stylesheet-declaraties zijn gemaakt met de juiste CSS-syntax, kan het zo zijn dat je het belang van de juiste volgorde van style-declaraties voor links over het hoofd bet gezien.
De CSS2-specificatie maakt de volgende kanttekening bij het belang van het in de juiste volgorde in een lijst van style-declaraties plaatsen van de dynamische pseudo-classes ':hover' en ':active'.
Note that the 'a:hover' must be placed after the 'a:link' and 'a:visited' rules, since otherwise the cascading rules will hide the 'color' property of the 'a:hover' rule.
Similarly, because 'a:active' is placed after 'a:hover', the active color will apply when the user both activates and hovers over the 'a' element.
Zie ook Q & A - 08: hierboven voor een voorbeeld van de juiste volgorde van style-declaraties voor links, en zie verder, voor de complete theorie, deze delen van de CSS2-spec.
http://www.w3.org/TR/REC-CSS2/selector.html#link-pseudo-classes
http://www.w3.org/TR/REC-CSS2/selector.html#dynamic-pseudo-classes
Merk op dat de ':hover' pseudo-class pas met CSS2 in de CSS-specs werd geïntroduceerd. Van browsers die niet claimen dat ze CSS2 op enig niveau ondersteunen, kan niet worden verwacht dat ze de ':hover' pseudo-class ondersteunen. Zo hebben de Netscape 4.x en Opera 3.x browsers gen ondersteuning voor de ':hover' pseudo-class.
De meta-FAQ voor de nieuwsgroep <comp.infosystems.www.authoring.stylesheets> heeft een hoofdstuk bronnen waarin een groot aantal URL's van websites wordt opgesomd, waarvan het bekend is dat ze goede informatie bevatten over het gebruiken en schrijven van Cascading Style Sheets (oftewel in het kort CSS).
De meta-FAQ wordt net zo vaak in deze nieuwsgroep geplaatst als deze FAQ, maar kan ook worden gevonden op het web als een HTML-document...
http://css.nu/faq/ciwas-mFAQ.html
...of als een plat tekst-document...
http://css.nu/faq/ciwas-mFAQ.txt
Voor traditionele validatie van markup-syntax...
http://www.htmlhelp.org/tools/validator/
http://valet.webthing.com/page/
http://validator.w3.org/
Voor CSS-controles...
http://www.htmlhelp.org/tools/csscheck/
http://jigsaw.w3.org/css-validator/validator.html.nl
Raak vertrouwd met de bovenstaande URL's, ze zullen je veel tijd en ergernis besparen. Om het te benadrukken, overdreven correcte HTML-markup -- zoals het uitdrukkelijk afsluiten van elementen waarbij dat niet strict noodzakelijk is -- en het juiste gebruik van CSS is essentieel om de CSS goed weergegeven te krijgen op het www.
De validator op webthing.com (The Page Valet, URL hierboven) heeft een experimentele "genormaliseerde markup"-optie, die gebruik maakt van "spam" (SPAddMarkup) om, onder andere, de optionele sluittags toe te voegen. "The Page Valet" is op precies dezelfde code en foutmeldingen gebaseerd als die gebruikt worden voor de validator op htmlhelp.org
"Vergissen is menselijk", maar nu is het eens mogelik dat computers een handje kunnen helpen: foutcontrole. Net zoals de spellingscontrole de vervelende typefouten kan vinden, die je zelf zo makkelijk over het hoofd ziet, zijn HTML-validators en CSS-checkers online beschikbaar om je webpagina's te controleren (URL's hierboven).
Je hebt je kennis van HTML en CSS nodig om de resultaten van deze hulpmiddelen te interpreteren, maar je kunt vervolgvragen plaatsen in deze nieuwsgroep, comp.infosystems.www.authoring.stylesheets, voor verdere discussie.
Deze FAQ is voor het laatst bijgewerkt op 10 maart 2001. Copyright 2000-2001, Jan Roland Eriksson.
Het is toegestaan dit document elektronisch te vermenigvuldigen zonder vergoeding, zolang het document geheel en ongewijzigd blijft.
Deze FAQ is ook beschikbaar in HTML op het World Wide Web op...
http://home.concepts-ict.nl/~rijk/info/faq/ciwas-aFAQ.html
en als een tekstdocument op...
http://home.concepts-ict.nl/~rijk/info/faq/ciwas-aFAQ.txt
De oorspronkelijke Engelstalige tekst van deze FAQ is beschikbaar in HTML op het World Wide Web op...
http://css.nu/faq/ciwas-aFAQ.html
en als een tekstdocument op...
http://css.nu/faq/ciwas-aFAQ.txt
en met de wijzigingsgeschiedenis van deze FAQ op...
http://css.nu/faq/ciwas-aFAQ-rev.html
