Front-end vraagstukken: Best practice voor 'superscript'

• Sander van Lambalgen
• 15 juni 2009
• • Front-end vraagstukken
  • Webrichtlijnen

In het kader van front-end vragen uit de vereniging (vragen blijven welkom) zoekt Jules Ernst advies over best practices inzake subscript en superscript.

Webrichtlijn 3.9 schrijft voor dat superscript en subscript waar mogelijk vermeden moeten worden.

Er circuleren diverse oplossing om bijvoorbeeld het copyright-teken in kleine letters zodanig in de hoogte te krijgen dat de regelhoogte hier geen schade van ondervindt.

We zijn voor onze wiki op zoek naar een correcte oplossing om bijvoorbeeld de naam van ons programmabureau correct weer te geven. De naam luidt: Overheid heeft Antwoord(c), waarbij (c) het copyright teken moet zijn die als superscript in de lucht hangt.
De HTML zou er zo uit kunnen zien: <span class="copyright">&copy;</span>

Is dit de manier waarop iedereen dit zou aanpakken, of valt er een alternatieve oplossing te bedenken? Welke CSS zou je gebruiken? (En mocht je je geheugen willen verfrissen over deze specifieke webrichtlijn, zie de discussie bij de weblog post hierover.)

• 24 reacties
• Reageer op dit bericht

Reacties

1 Edwin Martin op 15-06-2009 om 13:03 uur:

De richtlijnen leggen niet uit wat er mis is met E=mc². Daardoor kan je geen goede beredeneerde keuze maken.

Ik snap wel dat <sup> gebruiken om een tekst in kleine lettertjes te tonen fout is, maar is dat waar de richtlijnen op doelen?

Anders kun je het altijd nog met CSS oplossen, bijvoorbeeld met:

span.copyright {
vertical-align: super;
font-size: smaller;
}

2 Stephen Hay op 15-06-2009 om 18:33 uur:

@Edwin: Die richtlijn is in het leven geroepen omdat  geen betekenis geeft per se. Het is dus vergelijkbaar met <i></i>: er zijn legitieme redenen om het te gebruiken, maar die komen minder voor dan men zou willen denken. Vandaar "waar mogelijk".

Bij het copyright voorbeeld,  wordt alleen gebruikt om de presentatie van &copy; te bepalen en wordt in die zin beschouwd als presentational markup. Dan is jouw CSS een prima oplossing.

Dit is natuurlijk geen "showstopper" richtlijn, maar in 2004 gaven dergelijke richtlijnen meer context aan het begrip semantic markup.

3 Sander Aarts op 15-06-2009 om 21:32 uur:

Maar is het gebruik van <sup> in het voorbeeld van Edwin dan wel volgens de richtlijnen? Daar valt de positie immers samen met een specifieke betekenis en bij gebrek aan <power>...

4 Stephen Hay op 15-06-2009 om 21:46 uur:

@Sander: Dat is inderdaad iets moeilijker. E=mc^2 is math (E=mc^2 is overigens ASCII math), en HTML biedt daar geen mogelijkheden voor (thus MathML). Ik zou (persoonlijk) in dit geval wellicht beroep doen op het aspect "waar mogelijk" en gewoon  gebruiken. Maar iemand die meer doet met math heeft wellicht veel meer ideeën daarover. Misschien <sup title="power">2</sup>, title attribuut gebruiken voor meer context (dan denk ik aan semantiek en niet per se aan screen readers etc.)?

Let op dit soort dingen: de Webrichtlijnen zeggen niet dat  niet mag, dus je hoeft niet bijvoorbaat te accepteren als je hierop afgekeurd wordt. Het is altijd een discussie waard.

5 Anne van Kesteren op 15-06-2009 om 22:15 uur:

In HTML5 zijn de sub en sup elementen gewoon "semantisch" en OK. Als je ze weglaat en de betekenis wijzigt niet dan mag je ze echter niet gebruiken, maar in het geval van e.g. E=mc^2 lijkt het me duidelijk dat dit niet het geval is en moet de 2 dus gewoon in een sup element. (Je mag ook MathML gebruiken, maar dat lijkt me overkill voor een simpele vergelijking.)

6 Stephen Hay op 15-06-2009 om 22:32 uur:

@Anne: En daarom zijn we blij dat HTML5 komt. En misschien nog eerder dan CSS3.

7 Nick op 16-06-2009 om 20:00 uur:

Waar de richtlijnen op doelen is de web meer semantisch te maken toch? Zodat computers de informatie op de webpagina's beter begrijpen enz.

Ikzelf zou voor de css oplossing gaan als men geen nadruk op de sub of superscript wil geven. Maar wat ik niet begrijp is als men geen nadruk hier op wil leggen waarom de  niet gewoon gebruikt kan worden? Ok het is niet semantisch maar het zou best nog wel af en toe gebruikt kunnen worden? Het zijn tenslotte richtlijnen.

8 Stephen Hay op 16-06-2009 om 22:33 uur:

@Nick: zoals Anne aangaf zijn  en  semantisch in HTML5. Dit is echter in HTML 4.01 niet het geval; het gaat in 4.01 om de weergave. Vergelijik http://www.w3.org/TR/html5/text-level-semantics.html#the-sub-and-sup-elements en http://www.w3.org/TR/html401/struct/text.html#h-9.2.3.

9 Yvette Hoitink op 18-06-2009 om 23:20 uur:

In dit geval is als superscript presenteren van het copyright-teken precies dat: presentatie. Je voorstel om het met een <span> op te lossen lijkt me dus semantisch gezien de enige juiste.

10 Anne van Kesteren op 23-06-2009 om 14:21 uur:

Als de sub/sup elementen niet semantisch zijn (wat ik een dubieuze claim vind) dan zou het niet uit hoeven maken of je sub/sup of een span element gebruikt want beiden hebben geen enkele waarde. Het voordeel van sub/sup is echter dat ze meestal wel op de juiste manier overkomen.

11 Krijn op 23-06-2009 om 15:31 uur:

Nog wat vraagstukken, die ik eind vorig jaar ook al door heb gemaild naar Overheid heeft Antwoord© (als test of de Overheid ook echt Antwoord zou hebben, wat het geval was). Als we over <sup> en <sub> gaan miepen, kan dit ook wel:

* Waarom is het alt attribuut van jullie logo "logo overheid heeft antwoord" en niet "Overheid heeft Antwoord©"?
* Waarom gebruiken jullie </link>, </meta> en </img> terwijl de pagina's als text/html verstuurd worden?
* Waarom gebruiken http://www.overheidheeftantwoord.nl/colofon en http://www.overheidheeftantwoord.nl/colofo verschillende templates/styling/karakter encoderingen?
* Waarom verwijst http://www.oha.asp4all.nl/colofon niet naar http://www.overheidheeftantwoord.nl/colofon?
* Waarom werkt http://overheidheeftantwoord.nl/standaarden,webrichtlijnen niet?
* Waarom bevat http://www.overheidheeftantwoord.nl/contact geen contactformulier?
* Waarom wordt <a id="inhoud" class="skipLinks"></a>, <a id="topPagina" class="skipLinks"></a> en <a name="menu" class="skipLinks"></a> gebruikt?
* Waarom gebruiken jullie entities als ë en © terwijl utf-8 gebruikt wordt?
* Waarom wordt er op http://www.overheidheeftantwoord.nl/standaarden,webrichtlijnen een komma in de URL gebruikt, en op http://www.overheidheeftantwoord.nl/standaarden,webrichtlijnen/publicaties opeens ook een slash?
* Waarom gebruiken jullie bij de ene URL wel .html als extensie, en bij de andere niet?
* Waarom is http://www.overheidheeftantwoord.nl/standaarden,webrichtlijnen/ "niets"?
* Waarom worden op http://www.overheidheeftantwoord.nl/standaarden,zoekdienst (en andere pagina's) <em> en <strong> als koppen gebruikt?
* Waarom bevat http://www.overheidheeftantwoord.nl/overons,Organisatie.html (en een hele hoop andere pagina's) geen <title>?
* Waarom staan op http://www.overheidheeftantwoord.nl/actueel/nieuws de datum en de titel van het bericht aan elkaar geplakt in de HTML?
* Waarom is de titel van de 404 pagina 'Home'?
* Waarom valt de breadcrumb op http://www.overheidheeftantwoord.nl/standaarden,webrichtlijnen/publicaties/Nieuwsbrief-Overheid-heeft-Antwoord---Special-Webr.html achter het submenu?
* Waarom bevatten vrijwel alle links title="" ?
* Waarom is de URL van http://www.overheidheeftantwoord.nl/standaarden,webrichtlijnen/publicaties/Nieuwsbrief-Advies-Overheid-nl---Jaargang-7--nr--8.html niet echt "leesbaar"?
* Waarom is de afbeelding op http://www.overheidheeftantwoord.nl/standaarden,webrichtlijnen/publicaties/Nieuwsbrief-Advies-Overheid-nl---Jaargang-7--nr--8.html zo klein/ontoegankelijk?
* Waarom geeft http://www.overheidheeftantwoord.nl/standaarden,webrichtlijnen/publicaties/Lalala geen 404?
* Waarom is dit geen <ul>? :)

12 Sander Aarts op 23-06-2009 om 21:49 uur:

Ben wel benieuwd hoe het antwoord luidde ;)

13 Mallory op 27-06-2009 om 11:43 uur:

@Krijn
"Waarom gebruiken jullie entities als &euml; en &copy; terwijl utf-8 gebruikt wordt?"
Maakt het uit of het utf-8 is? HTML begrijpt wat &copy betekent, XML niet (of, zo heb ik gelezen, dat alleen de 5 "names entities" in XML bestaan). Voor mij is het gebruik van numerical entities een gewoonte van toen ik dacht dat ik XHTML schreef : )

14 Krijn op 27-06-2009 om 13:16 uur:

@Mallory: Nee, het maakt voor een browser waarschijnlijk niets uit, hooguit misschien omdat ze in de meeste gevallen meer bytes/dataverkeer innemen en pagina's dus langzamer laden, maar dat is vast niet merkbaar. Vroeg me gewoon af of het vanwege beperkingen was, of iets anders.

@Sander: Dat sommige zaken mee worden genomen bij de doorontwikkeling, sommige na een uitgebreide check zullen worden aangepast, en sommige hopelijk in de toekomst worden hersteld. Vanwege tijdsdruk was het niet mogelijk om voor live-gang alles in detail te checken, ofzo.

Tijdsdruk blijkt dus voor de overheid een goede reden om sommige webrichtlijnen aan je laars te mogen lappen :)

15 Sander Aarts op 28-06-2009 om 16:00 uur:

Het zijn net mensen... ;)

16 Koen Willems op 03-07-2009 om 20:55 uur:

@Stephen Hay:
Ik vraag me af of SUB en SUP in HTML 4.01 alleen maar voor presentational markup dienen.
Als je kijkt naar de voorbeelden die W3C geeft zijn het immers juist voorbeelden waar de beide elementen een semantische betekenis hebben.

Waar W3C zegt 'Many scripts ... require' kan dat alleen maar impliceren dat de correcte semantische markup moet worden gebruik (en dan staat er vervolgens wat ongelukkig: 'for proper rendering').

Het is mij in ieder geval veel te kort door de bocht om gelet op de erg korte beschrijving van W3C deze markup in HTML 4.01 als louter presentational aan te merken.

17 Raph de Rooij op 05-07-2009 om 00:54 uur:

@Krijn: Je schrijft: "Tijdsdruk blijkt dus voor de overheid een goede reden om sommige webrichtlijnen aan je laars te mogen lappen".

Tijdsdruk is volgens mij geen reden, maar een excuus. De reden waarom sommige dingen niet lukken is meestal niet toe te schrijven aan technische, maar aan organisatorische factoren. Een onderwerp als webrichtlijnen is om die reden te beschouwen als een lakmoesproef voor opdrachtgevers en/of projectleiders...

't Is soms best jammer dat de technische aspecten van de webrichtlijnen zoveel aandacht krijgen en niet de organisatorische. Die technische aspecten spreken veel meer tot de verbeelding en zijn - zeker voor front-enders - doorgaans veel interessanter.

Maar dat zijn slechts details vergeleken bij waar het verschil wordt gemaakt tussen het wel en niet slagen in een doelstelling: gericht sturen in alle fasen van een webproject. Wat in te veel webprojecten begint als een randvoorwaardelijk eis wordt gaandeweg verwaterd tot een 'nice-to-have'. Vervolgens wordt het onder tijdsdruk over de deadline heen getild onder het mom van 'dat fixen we daarna wel' en vervolgens 'vergeten'.

Toepassen van webrichtlijnen is weliswaar verplicht, maar er wordt in de documenten waarin die verplichting is vastgelegd niet gerept over een formele sanctie bij het niet voldoen. Sommigen vinden dat misschien jammer, maar daar is heel goed een mouw aan te passen. Opdrachtgever en/of projectleiders die de webrichtlijnen op waarde weet te schatten doen er verstandig aan die sanctie zelf te bepalen en vast te leggen in de formele overeenkomst. Ik weet van tenminste één opdrachtgever die het toepast. Het blijkt simpel en uiterst effectief.

Als je op die manier te werk gaat, houd je (mogelijk pas na de eerste keer...) alleen opdrachtnemers over die hun belofte "wij gaan aan de webrichtlijnen voldoen" ook echt kunnen waarmaken.

Vanwege het ontbreken van sancties hebben de webrichtlijnen niet altijd de hoogste prioriteit als complicaties de kop opsteken in een webproject . En al helemaal niet in vergelijking met factoren als tijd en geld. Als één van die twee begint op te raken is het vaak: "de webrichtlijnen zijn inderdaad heel belangrijk, maar nu even niet."

En da's jammer, want voor projectleiders zijn de webrichtlijnen niet zozeer een technische specificatie, als wel een krachtig hulpmiddel om te sturen op een kwalitatief hoogwaardig eindresultaat. En een effectief middel om opdrachtnemers bij de les te houden. Maar dan moet je het middel wel goed inzetten. Bijvoorbeeld door een opdrachtnemer ondubbelzinnig te wijzen op zijn contractuele verplichting als het mis (b)lijkt te gaan. En doen wat in het contract is vastgelegd als het ook daadwerkelijk mis is gegaan.

Of een website aan de webrichtlijnen gaat voldoen wordt dus helemaal aan het begin van een webproject bepaald, niet pas aan het einde.

@Sander Aarts: Je schrijft in een reactie op het stuk van Krijn: "Het zijn net mensen…" Hoe weet jij dat? ;-)

18 Krijn op 05-07-2009 om 10:13 uur:

@Koen: HTML 4.01 is op wel meer plekken veel te "kort" beschreven. Onder andere vandaar dus HTML 5. Ik snap dat de Webrichtlijnen door de ervaring met bijvoorbeeld WCAG 2.0 niet graag naar toekomstige specs kijken, maar volgens mij moeten jullie een uitzondering gaan maken ;) Of wachten jullie op Last Call?

@Raph: Welke van mijn vragen hebben een antwoord waarin organisatorische redenen naar voren komen en welke technische? Misschien dat we daar iets van kunnen leren. Als front-end/template developer en back-end/CMS developer vind ik het allemaal technische vragen (behalve misschien het contactformulier), maar ik ben wel benieuwd naar wat er verder nog speelt.

19 Sander Aarts op 05-07-2009 om 10:30 uur:

@Raph: intuïtie ;)

20 Sander Aarts op 05-07-2009 om 10:33 uur:

@Raph: kun je aangeven wat de sanctie precies is die toegepast wordt door de opdrachtegever waar je het over had? Heb wel een vermoeden, maar wellicht zit ik ernaast.

21 Raph de Rooij op 06-07-2009 om 00:22 uur:

@Sander Aarts: De winstmarge op een webproject is doorgaans tussen 10 en 15 procent, zo is de schatting. Het niet tijdig opleveren van een website overeenkomstig het contract levert een boete op. Die boete wordt elke dag hoger en heeft een maximum tussen 10 en 15 procent van de totale som. Als een opdrachtnemer aan een webopdracht iets wil overhouden zal hij dus zijn zaakjes goed voor elkaar moeten hebben.
In de begroting zijn overigens de kosten voor een externe toetsing meegenomen.

22 Stephen Hay op 10-07-2009 om 21:28 uur:

@Koen: De 4.01 spec luidt:

"Many scripts (e.g., French) require superscripts or subscripts for proper rendering."

Vervolgens geven zij de door jou genoemde voorbeelden.

Rendering. Dat is presentatie. Dat wil niet zeggen dat ze het niet semantisch bedoeld hebben. Wellicht. Ik geef alleen maar aan dat een element alleen semantische betekenis heeft als:

a. de user agent het element als semantisch beschouwt (dus de betekenis ervan kent en/of er iets mee doet; in 2004 was dat vermoedelijk niet het geval) en;

b. degene die het element aan de pagina toekent, dit als betekenisvol element heeft toegepast. Let wel-- de stelling ging over het gebruik van een copyright-symbool.

Voor zover ik het inschat zijn alle andere gevallen betekenisloos. Nou begrijp ik Anne's stelling, dat je dan in zo'n geval net zo goed een <sup> kan gebruiken als een <span>, maar: <span> is met opzet betekenisloos, om juist middels id en class structureel betekenis te kunnen geven aan arbitraire (inline) content. <sup> impliceert daarmee een betekenis, maar de spec geeft "rendering" aan als die betekenis.

Maar ach, waar hebben we het over, inderdaad? Mierenneukerij? Als dat zo is, waarom herschrijft Hixie de betekenis hiervan in gruwelijk detail in de HTML5 WD?

23 Koen Willems op 12-07-2009 om 18:06 uur:

@Stephen:

Ik denk dat we het eens zijn.

:-)

24 Joop op 29-09-2009 om 16:40 uur:

Buitengewoon interessant. Het probleem is dat niet iedereen met Microsoft producten werkt. Ik ben in staat om mijn browser zo in te stellen dat mijn instellingen worden gebruikt en niet die van de pagina. Wat heeft dat voor zin hoor ik u al denken. Wellicht is het u ontgaan, maar de meest gebruikte lettertypen in websites zijn van Microsoft en die mogen dus niet gebruikt worden door andere partijen. Gevolg daarvan is dat het teken dan fout kan worden vertaald omdat er gebruik wordt gemaakt van een "gelijkende" tekenset. Met &euml; en dergelijke ben ik er zeker van dat het ook een &euml; wordt. Het probleem van het kwadraat-teken (en andere niet standaard tekens zoals het doorsnede teken) heb ik opgelost middels een klein plaatje dat net zo hoog is als de gemiddelde letter. Het uiteindelijke probleem ligt bij de browsers. Niet alles wordt op precies dezelfde manier geïnterpreteerd waardoor in sommige browsers de letter of veel groter is of juist veel kleiner. Zo zit ik nu te tikken in een veld met een enorm klein lettertje terwijl ik toch gebruik maak van de laatst stabiele versie van FireFox. En het lettertje blijft klein, ook al maak ik gebruik van de zoom mogelijkheden van FireFox. De gehele opmaak van deze pagina is daarmee natuurlijk volkomen zoek. Dus zolang fabrikanten dwars blijven liggen en hun eigen "ei" blijven doordrukken, zolang zal het geen enkel nut hebben om wat dan ook aan standaards te gaan verzinnen. Uiteindelijk is namelijk de locale hardware en software die bepaald wat er gebeurd. Dus HTML 5 heeft alleen zin als dat in alle browsers exact gelijk is. De historie met IE wijst helaas uit dat Microsoft daar niet aan toe wil geven om op die manier hun standaard (en alles wat daar mee samengaat) af te dwingen. Nog verder terug, het draait dus allemaal om gewoon stom geld en macht. Maar dan komen we terecht in wijsheden die enorm "off topic" zijn.

Plaats een reactie

Naam

E-mailadres wordt niet getoond

Website wordt gekoppeld aan je naam

Reactie HTML niet toegestaan, maar simpele markup wel

Spammer? Nee invullen