Moet ik <i> tag voor pictogrammen in plaats van <span>?

Facebook’s HTML en Twitter Bootstrap HTML (vóór v3) gebruiken beide de <i>-tag om pictogrammen weer te geven.

Echter, uit de HTML5-specificatie:

Het I-element vertegenwoordigt een stuk tekst in een alternatieve stem of stemming,
of anderszins gecompenseerd van het normale proza, zoals een taxonomische
benaming, een technische term, een idiomatische uitdrukking van een andere
taal, een gedachte, een scheepsnaam of een ander proza waarvan de typische
typografische presentatie is cursief weergegeven.

Waarom gebruiken ze de tag <i>om pictogrammen weer te geven? Is het geen slechte gewoonte? Of mis ik hier iets?

Ik gebruik spanom pictogrammen weer te geven en het lijkt tot nu toe voor mij te werken.

Bijwerken:

Bootstrap 3 gebruikt nu spanvoor pictogrammen. Officieel document

Antwoord 1, autoriteit 100%

Waarom gebruiken ze de tag <i>om pictogrammen weer te geven?

Omdat het zo is:

• Kort
• i staat voor icoon (hoewel niet in HTML)

Is het geen slechte gewoonte?

Vreselijke praktijk. Het is een triomf van prestatie over semantiek.

Antwoord 2, autoriteit 45%

Ik spring hier een beetje laat in, maar kwam deze pagina tegen toen ik er zelf over nadacht. Ik weet natuurlijk niet hoe Facebook of Twitter het rechtvaardigde, maar hier is mijn eigen denkproces voor wat het waard is.

Uiteindelijk concludeerde ik dat deze praktijk niet zo onsemantisch is (is dat een woord?). Afgezien van de kortheid en de mooie associatie van “i staat voor pictogram”, denk ik dat het eigenlijk de meest semantische keuze is voor een pictogram wanneer een eenvoudige <img>-tag niet praktisch is.

1. Het gebruik komt overeen met de specificaties.

Hoewel het misschien niet is wat de W3 voornamelijk in gedachten had, lijkt het me dat de officiële specificatie voor <i>vrij gemakkelijk een pictogram zou kunnen bevatten. Het antwoordpijlsymbool zegt immers op een andere manier “beantwoorden”. Het drukt een technische term uit die de lezer misschien niet kent en die doorgaans cursief wordt weergegeven. (“Hier bij Twitter noemen we dit een antwoordpijl.”) En het is een term uit een andere taal: een symbolische taal.

Als Twitter in plaats van het pijlsymbool <i>shout out</i>of <i>[Japanese character for reply]</i>(op een Engelse pagina), dat zou in overeenstemming zijn met de specificatie. Waarom dan niet <i>[reply arrow]</i>? (Ik heb het hier uitsluitend over HTML-semantiek, niet over toegankelijkheid, waar ik op in zal gaan.)

Voor zover ik kan zien, is het enige deel van de specificatie dat expliciet wordt geschonden door het gebruik van pictogrammen, de zin “span of text” (wanneer de tag ook geen tekst bevat). Het is duidelijk dat de <i>tag voornamelijk bedoeld is voor tekst, maar dat is een vrij klein detail vergeleken met de algemene bedoeling van de tag. De belangrijke vraag voor deze tag is niet welk formaat inhoud het bevat, maar wat de betekenis van die inhoud is.

Dit is vooral het geval als je bedenkt dat de lijn tussen “tekst” en “pictogram” bijna niet bestaat op websites. Tekst kan meer op een pictogram lijken (zoals in het Japanse voorbeeld) of een pictogram kan op tekst lijken (zoals in een jpg-knop met de tekst “Verzenden” of een kattenfoto met een overlay-bijschrift) of tekst kan worden vervangen of verbeterd met een afbeelding via CSS. Tekst, afbeelding – wat maakt het uit? Het is allemaal inhoud. Zolang iedereen – mensen met een handicap, browsers met een handicap, spiders van zoekmachines en andere machines van verschillende soorten die betekenis kunnen begrijpen, hebben we ons werk gedaan.

Dus het feit dat de schrijvers van de specificatie niet hebben gedacht (of ervoor hebben gekozen) om dit te verduidelijken, zou ons niet moeten binden aan het doen van wat logisch is en in overeenstemming is met de geest van de tag. De tag <a>was oorspronkelijk bedoeld om de gebruiker ergens anders heen te brengen, maar nu kan er een lightbox verschijnen. Grote kreet, toch? Als iemand erachter was gekomen hoe hij een lightbox op een klik moest laten verschijnen voordat de specificatie inhaalde, hadden ze toch de tag <a>moeten gebruiken, niet een <span>, zelfs als het niet helemaal in overeenstemming was met de huidige definitie – omdat het het dichtst in de buurt kwam en nog steeds in overeenstemming was met de geest van de tag (“er zal iets gebeuren als je hier klikt”). Dezelfde deal met <i>– wat voor soort ding je er ook in stopt, of hoe creatief je het ook gebruikt, het drukt het algemene idee uit van een alternatieve of aparte term.

2. De tag <i>voegtsemantische betekenis toe aan een pictogramelement.

De alternatieve optie om alleen een pictogramklasse te dragen is <span>, wat natuurlijk geen enkele semantische betekenis heeft. Wanneer een machine de <span>vraagt wat het bevat, zegt het: “Ik weet het niet. Kan van alles zijn.” Maar de <i>-tag zegt: “Ik gebruik een andere manier om iets te zeggen dan de gebruikelijke manier, of misschien een onbekende term.” Dat is niet hetzelfde als ‘Ik heb een pictogram’, maar het komt er veel dichter bij dan <span>kreeg!

3. Uiteindelijk maakt algemeen gebruik het goed.

In aanvulling op het bovenstaande is het de moeite waard om te overwegen dat machinelezers (of het nu een zoekmachine, schermlezer of wat dan ook is) er op elk moment rekening mee kunnen houden dat Facebook, Twitter en andere websites de <i>tag voor pictogrammen. Ze geven niet zoveel om de specificatie als om het extraheren van betekenis uit code met welke middelen dan ook. Dus ze zouden deze kennis van algemeen gebruik kunnen gebruiken om eenvoudig vast te leggen dat “hier mogelijk een pictogram is” of iets geavanceerder te doen, zoals een kijkje in de CSS starten voor een hint naar betekenis, of wie weet wat. Dus als u ervoor kiest om de <i>voor pictogrammen op uw website te gebruiken, geeft u mogelijk meer betekenis dan de specificatie.

Bovendien, als dit gebruik wijdverbreid wordt, zal het in de toekomst waarschijnlijk in de specificatie worden opgenomen. Vervolgens ga je door je code, waarbij je <span>en vervangt door <i>‘s! Het kan dus zinvol zijn om aan boord te gaan met wat de richting van de specificatie lijkt te zijn, vooral wanneer deze niet duidelijk in strijd is met de huidige specificatie. Gemeenschappelijk gebruik heeft de neiging om taalregels meer te dicteren dan andersom. Als je oud genoeg bent, weet je nog dat ‘Website’ de officiële spelling was toen het woord nieuw was? Woordenboeken stonden erop dat er een spatie moest zijn en dat web een hoofdletter moest hebben. Daar waren semantische redenen voor. Maar algemeen gebruik zei: “Wat dan ook, dat is dom. Ik gebruik ‘website’ omdat het beknopter is en er beter uitziet.” En het duurde niet lang of woordenboeken erkenden die spelling officieel als correct.

4. Dus ik ga door en gebruik het.

Dus <i>geeft meer betekenis aan machines vanwege de specificatie, het geeft meer betekenis aan mensen omdat we “i” gemakkelijk associëren met “icon”, enhet is maar één letter lang. Winnen! En als u ervoor zorgt dat u equivalente tekst opneemt in de tag <i>of ernaast (zoals Twitter doet), begrijpen schermlezers waar ze moeten klikken om te antwoorden, de link is bruikbaar als CSS laadt niet, en menselijke lezers met een goed gezichtsvermogen en een fatsoenlijke browser zien een mooi pictogram. Met dit alles in gedachten zie ik het nadeel niet.

Antwoord 3, autoriteit 10%

Quentin’s antwoord stelt duidelijk dat de i-tag niet mag worden gebruikt om pictogrammen te definiëren.

Maar Holly suggereerde dat spanop zich geen betekenis heeft en stemde voor iin plaats van span-tag.

Weinigen stelden voor om imgte gebruiken omdat het semantisch is en een alt-tag bevat. Maar we moeten niet ook imggebruiken omdat zelfs een lege srceen verzoek naar de server stuurt. Lees hier

Ik denk dat de juiste manier zou zijn,

<span class="icon-fb" role="img" aria-label="facebook"></span>

Dit lost het probleem op van geen alt-tag in spanen maakt het toegankelijk voor slechtziende gebruikers. Het is semantisch en misbruikt (hackt) geen enkele tag.

Antwoord 4, autoriteit 2%

Ik benader de antwoorden van alle anderen hier totaal anders. Laat me mijn oplossing voorafgaan en argumenteren door te stellen dat standaarden en conventies soms bedoeld zijn om te worden verbroken, vooral in de context van de standaard HTML-lexicale tagdefinities.

Er is niets dat u ervan weerhoudt om aangepaste elementen te maken die hun doel zelf beschrijven.

Zowel moderne browsers als zelfs IE 6+ (met shim) kunnen zaken ondersteunen als:

<icon class="plus">

of

<icon-add>

Zorg er wel voor dat u de tag normaliseert:

icon { display:block; margin:0; padding:0; border:0; ... }

en gebruik een shim als je IE9 of eerder moet ondersteunen (zie bericht hieronder).

Bekijk dit StackOverflow-bericht:

Is er is een manier om uw eigen html-tag in HTML5 te maken

Om mijn argument kracht bij te zetten, gebruiken zowel de hoekrichtlijnen van Google als de nieuwe Polymer-projecten het concept van aangepaste HTML-tags.

Antwoord 5, autoriteit 2%

Mijn gok: omdat Twitter de noodzaak ziet om oudere browsers te ondersteunen, zouden ze anders de pseudo-elementen :before/ :aftergebruiken.

Verouderde browsers ondersteunen de pseudo-elementen die ik noemde niet, dus ze moeten een echt HTML-element gebruiken voor de pictogrammen, en aangezien pictogrammen geen ‘exclusieve’ tag hebben, gingen ze gewoon met de <i>-tag, en alle browsers ondersteunen die tag.

Ze hadden zeker een <span>kunnen gebruiken, net zoals jij (wat HELEMAAL prima is), maar waarschijnlijk om de reden die ik hierboven noemde plus de redenen die worden genoemd door Quentin , is ook de reden waarom Bootstrap de tag <i>gebruikt.

Het is een slechte gewoonte om extra opmaak te gebruiken om stijlredenen, daarom pseudo-elementszijn uitgevonden om inhoud en stijl te scheiden… maar als je de noodzaak ziet om oudere browsers te ondersteunen, ben je soms gedwongen om dit soort dingen te doen.

PS. Het feit dat pictogrammen beginnen met een ‘i’en dat er een <i>-tag is, is volkomen toeval.

Antwoord 6

Ik dacht dat dit er nogal slecht uitzag – omdat ik onlangs aan een Joomla-sjabloon werkte en ik kreeg steeds de sjabloon die niet W3C was omdat deze de <i>-tag gebruikte en die verouderd was, omdat het oorspronkelijke gebruik was om iets cursief te maken, wat nu wordt gedaan via CSS en niet meer via HTML.

Het is echt een slechte oefening, want toen ik het zag, ging ik door de sjabloon en veranderde ik alle <i>-tags in <span style="font-style:italic">en vroeg zich toen af waarom de hele sjabloon er vreemd uitzag.

Dit is de belangrijkste reden waarom het een slecht idee is om de tag <i>op deze manier te gebruiken – je weet nooit wie je werk achteraf gaat bekijken en “aanneemt” dat wat je echt probeerde te doen, is de tekst cursief maken in plaats van een pictogram weer te geven. Ik heb zojuist wat pictogrammen in een website geplaatst en ik deed het met de volgende code

<img class="icon" src="electricity.jpg" alt="Electricity" title="Electricity">

op die manier heb ik al mijn pictogrammen in één klasse, zodat alle wijzigingen die ik aanbreng van invloed zijn op alle pictogrammen (zeg dat ik ze groter of kleiner wilde hebben, of afgeronde randen, enz.), De alt-tekst geeft schermlezers de kans om te vertellen de persoon wat het pictogram is in plaats van mogelijk alleen “tekst cursief, einde cursief” te krijgen (ik weet niet precies hoe schermlezers schermen lezen, maar ik denk dat het zoiets is), en de titel geeft de gebruiker ook een kans om met de muis over de afbeelding te gaan en een tooltip te krijgen die hen vertelt wat het pictogram is voor het geval ze er niet achter kunnen komen. Veel beter dan het gebruik van <i>– en het voldoet ook aan de W3C-standaard.

Antwoord 7

Ik vond dit ook handig wanneer ik een pictogram met absolute positionering in een link <a>-tag wilde plaatsen.

Ik dacht eerst aan de <img>-tag, maar de standaardstijl van die tags in links heeft meestal een randstijl en/of schaduweffecten. Bovendien voelt het verkeerd om een <img>-tag te gebruiken zonder een “src”-attribuut te definiëren, terwijl ik een stijlbladdeclaratie voor achtergrondafbeeldingen gebruik, zodat de afbeelding niet spookt en sleept.

Op dit moment denk je aan tags als <span>of <i>– in welk geval <i>zo logisch is als dit soort icoon.

Al met al denk ik dat het voordeel, behalve dat het intuïtief is, is dat er minimale stijlbladaanpassingen nodig zijn om deze tag als een pictogram te laten werken.