OK, nå blir det litt teknisk her, de som ikke er opptatt av html kan lese neste sak 😉
Foto: breadcrumbs av Manuel Alarcón på Flickr (Creative Commons)
I det siste har jeg jobbet med å skrive HTML og CSS til det nye designet av yr.no, som vi skrev om for en uke siden i Slik pusser yr.no opp fasaden. I forbindelse med kodingen, dukket det opp et spørsmål som jeg gjerne vil diskutere med dere.
Vanligvis kodes en brødsmulesti som en flat <ul>– eller <ol>-liste. Det første punktet i listen refererer til forsiden, mens det siste punktet i listen ofte refererer til den aktive undersiden.
Eksempel på flat liste
- yr.no
- Norge
- Oslo
- Oslo
- Blindern
Alternativt, kan brødsmulestien kodes som en hierarkisk liste. Det ytterste nivået refererer til forsiden, mens det innerste nivået refererer til den aktive undersiden.
Eksempel på hierarkisk liste
- yr.no
- Norge
- Oslo
- Oslo
- Blindern
- Oslo
- Oslo
- Norge
Hvordan ville dere kodet en brødsmulesti?
Lars Marius Garshol
Jeg ville definitivt gjort det som en flat liste, av to grunner. For det første er det en flat liste rent konseptuelt (selv om elementene i listen kommer fra et hierarki). For det andre er en flat liste enklere.
Thomas Marthinsen
Flat liste gir deg muligheten til å hoppe n steg tilbake eller hoppe til et spesifik sted i lista.
I en hierkisk liste kjenner hver node kun sin egen parent (herregud for en sallig blanding av norsk og engelsk), noe som krever at man gå gjennom alle parents for å komme tilbake til start.
Hvor store lister snakker vi om her?
Magnus Revang
Dere forslår tre muligheter:
Den første, flat UL liste, blir feil. I og med at en breadcrumbs er ordnet (order matters), altså skal man velge flat liste så må man velge OL.
Nested list kan høres bra ut, men går man litt dypere i problemstilling vil vel den ikke gi noen merverdi i screen readers. Man skal jo helst unngå lister med kun ett punkt og i koden vil jo listen fremstå med nettopp dette når man nester.
Altså vil jeg anbefale å bruke OL
mvh,
Magnus Revang
Daniel
pastebin.no/324g
Martin Berglund (NRK)
Lenken fra Daniel viser et eksempel på HTML for en hierarkisk liste.
Mikkel Munch Mortensen
[På dansk]
Interessant. Jeg har aldrig tænkt på at lave det med hierarkisk lister.
Lavede man hver af listerne så de udover det aktuelle punkt også indeholdt andre menupunkter på samme niveau, så ville man med lidt snedig CSS kunne lave en ret fiks navigation til relateret indhold på alle niveauer tilbage mod forsiden.
Om det ville være brugbart kan jeg ikke lige blive enig med mig selv om. Generelt bruger jeg meget, meget sjældent brødkrummer til navigation.
George
For at det skal se riktig ut uten CSS, må det nesten bare skrives ut rett fram med skilletegn mellom.
F.eks.:
yr.no > Norge > Oslo > Oslo > Blindern
Det er slik jeg har løst det på bl.a. http://payex.se og er også slik det blir anbefalt for de som er Google-nerds.
Øyvind Solstad
Enig med George!
Martin Berglund (NRK)
Mener du at dette blir mer semantisk riktig, eller at det funker visuelt (uten CSS)?
Haakon Halvorsen
Jepp, George har løsningen her. Støtter den.
Eller hierarkisk, men da er det vel strengt tatt ikke en breadcrumb lengre – da minner det mer om en vanlig hierarkisk navigasjonsstruktur og det er vel ikke det som er poenget her.
Flat struktur blir feil på alle måter 🙂
Rune M. Andersen
«>» er et tegn som har en mening; «større enn».
Vil man ha en pen pil løses det best med CSS.
Vil man i tillegg ha semantikk, som er spesielt viktig for alle som leser weben på en ikke-visuell måte, må man tagge det opp også.
Flat eller hierarkisk..? Tja, hierarkisk gir ingen merverdi her, annet enn at f.eks. en talesyntesebruker får opplest ekstra metadata. Det er heller ikke gitt at innholdet _er_ hierarkisk, det kan også være en ordning, eller den reelle veien man fulgte for å finne aktuell side.
Jeg velger flat liste. Ordnet tenker jeg er hakket bedre enn uordnet, men begge gjør jobben.
George
I denne sammenhengen gir faktisk «større enn» semantisk betydning, da hver lenke består av et nivå som er større enn det neste.
Man trenger ikke noe mer tagging enn -elementene man skal bruke; man kan bruke dersom man ikke skal ha lenker på alle nivåene.
Ost
Hvordan høres det ut med en skjermleser når > er kodet inn sammen med lenketekstene?
Espen Antonsen
Google støtter også Microdata for å definere breadcrumbs
Pål Strøm
Vet ikke helt om jeg er enig i at det skal være en liste, heller, jeg. For hva er det egentlig en liste over? Er det ikke bedre å pakke de inn i bare anchors? så får du også færre elementer å forholde deg til. Et foreldreelement (div) som inneholder en serie med lenker (a).
Hein Haraldson Berg
En flat OL blir nok riktigst, når jeg tenker meg om. Har lagt meg til en vane å bruke UL, men selvfølgelig er rekkefølgen essensiell. Vanen skal nå brytes.
Nøsting er unødvendig, man skal kun liste ut stien og vet at man er dypere i hierarkiet jo lenger ut i listen man har kommet. Dessuten får man aldri flere greiner.
Magnus
Jeg synes den hierarkiske listen definitivt blir mer intuitiv i det eksempelet over.
Jesper Haug Karsrud
Definitivt ikke en nøstet liste, da en brødsmuleliste i seg selv ikke faktisk er hierarkisk. En flat ordnet liste eller en ren utskrift av linker med skilletegn er det jeg mener er best.
Man må ikke glemme at man har flere ulike typer brødsmulelister også. Hva med en brødsmuleliste som skal presentere steg i en registrerings-/bestillingsprosess? Kanskje ikke en tradisjonell brødsmuleliste, men likevel en lignende problemstilling man må ta høyde for.
Det som derimot blir interessant, er hvis man skal innføre såkalte «super breadcrumbs». Hva er det da som blir korrekt måte å oppmarkere ting på? Er det da korrekt å bruke en ol, med en ul under hvert punkt? Det synes jeg er mer interessant…
Victor Vikene
Magnus: intuitiv i visuell forstand er jeg enig i, men man trenger ikke nøste for å gjøre den visuelle delen ved CSS.
Pål Strøm: Hvordan vil du beskrive data i en breadcrumb-sti?
Man kan si noe sånt som: Først valgte du (brukeren) å gå inn på forsiden vår (nettstedet), som nummer to valgte du fylke, nummer tre valgte du tettsted, etc.
Jeg mener en rekke anchor-elementer forteller mindre en en liste.
Som nevnt flere ganger er en ordnet liste veien å gå, både for semantikk og brukervennlighet. Man trenger selvfølgelig ikke å style den som en nummerert liste.
Martin Berglund (NRK)
Her er det mange gode tanker. Det er hyggelig at en såpass liten detalj (og bloggpost) kan gi en slik diskusjon 🙂
Mitt fokus, ved valg av HTML for brødsmulestien, er å beskrive innholdet og strukturen på best mulig måte. Både for skjermlesere og søkemotorer. Det visuelle uttrykket er mer eller mindre uavhengig av hvilken HTML jeg ender opp med.
Hvilke erfaringer har dere med opplesing av brødsmulestien?
George
Testet opplesingsverktøyet til leseweb.net og da ble «yr.no > Norge > Oslo > Oslo» lest opp som «yr. no å gape Norge å gape…» eller noe sånn. Er ikke helt sikker på hva den sier når den kommer over ‘>’-tegnet.
Hadde i det minste vært litt forståelig hvis den faktisk sa «større enn», men ser ikke sånn ut. Uansett, må jeg si at det ikke er praktisk forsvarlig å ta hensyn til slikt, med mindre det foreligger strenge krav til tilgjengelighet.
Martin Berglund (NRK)
George, hva mener du her?
Er ikke tilgjengelighet en av hovedgrunnene til å bry seg om semantisk HTML?
George
Om du bruker en div eller en section eller noe annet så hjelper ikke det en svaksynt person. Hvis du skal møte WCAG-krav, koder du naturligvis litt annerledes enn for et «vanlig» nettsted, der man ikke har like høye krav til slikt.
Det er mange brukergrupper man burde/kunne/skulle tenkt på, kodet for, og forsikret om at hadde en bra opplevelse, men i de fleste prosjekter så er ikke dette et krav eller ønske fra kunden, og det blir dermed nedprioritert.
Sven K. Haaø
Georgs løsning er den eneste jeg har positiv erfaring med. Maskinell lesing fungerer greit. Opplesing vha. tale-til-tekst systemer kan testes her:
kristiansand.kommune.no/no/Administrasjon/Helse-og-sosialsektoren/Samfunnsmedisinsk-enhet/
(litt vanskelig å markere brødsmulestien men når det er gjort, trykker du avspillingsknappen.
Sven
Victor Vikene
Jeg rotet frem synspunkt fra W3C sine rettningslinjer angående tilgjengelighet. Punkt 10.5
Victor Vikene
Jeg mente selvfølgelig:
Espen Antonsen
Her er det flere akseptable alternativer. Jeg synes både OL/UL er ok. Er ikke helt komfortabel med delimited links slik George nevner. Jeg tror Google her er pragmatiske og ser at det er slik det gjøres av mange på nettet. Tror uansett så lenge man er bevisst på strukturen og gjenbruker den så klarer Google å tolke breadcrums godt.
Etter min mening er den beste løsning å benytte semantiske elementer (nav eller menu) i HTML5 sammen med microdata. Microdata har allerede en definisjon for microdata og den støttes av Google.
Eksempel med html-kode
Espen Antonsen
Skal selvsagt være definisjon for breadcrumbs.
George
Man burde selvfølgelig bruke runt selve brødsmulestien, hvis man skal kjøre HTML5 🙂
Syns eksemplene på breadcrumb med microdata og RDFa ble i overkant «verbose» og knotete. Man burde kanskje utviklet en microformat for det istedet?
George
manglet i denne kommentaren… 🙂
George
OK, går det ikke an å skrive inn kode her med code-elementet? NAV skulle det stått i kommentaren… Sheesh.
Lasse Søberg
Ville brukt noe lignende det under. Men med en spacer (eks: >). Dette gir en stor trykkflate med standard a tags som er keyboard vennlig.
div, div > a {
height: 50px;
background: #eee;
}
div > a {
display: block;
float: left;
padding: 0px 10px;
text-decoration: none;
line-height: 50px;
}
div > a:last-of-type {
font-weight: bold;
color: #222;
}
div > a:hover {
background: #ccc;
}
yr.no
Norge
Oslo
Oslo
Blindern
Lasse Søberg
Meg nub her.
div, div > a {
height: 50px;
background: #eee;
}
div > a {
display: block;
float: left;
padding: 0px 10px;
text-decoration: none;
line-height: 50px;
}
div > a:last-of-type {
font-weight: bold;
color: #222;
}
div > a:hover {
background: #ccc;
}
yr.no
Norge
Oslo
Oslo
Blindern
Lasse Søberg
Enda mer nub, HTML vises jo ikke. Skulle gjerne hatt preview at post 😛
Se her i stedet:
pastebin.com/1Dwdd5zr
Victor Vikene
Lasse: Hvorfor bruke et ikke-beskrivende div-element, når man har elementer som er mer beskrivende?
Tor Avseth
Brødsmuler et spor man legger ut etter seg for å komme tilbake til utgangspunktet. Heller enn å ha én gitt struktur som et tre, er brødsmuler ett utvalg av mulige spor tilbake i en lesesesjon. For eksempel kan Blindern, ved siden av å sortere under Oslo, også kunne sortere under Studiesteder, eller Meteorologistasjoner, eller steder som ligger langs Sognsvannsbanen, eller steder i Aker bydel, osv. Veien inn bør definere brødsmulene, og ikke den underliggende datastrukturen som meteorologi-profesjonelle trenger for å holde sine data organisert.
En ting til er den multiple «personligheten» til Oslo, som er bykommune og fylke. Selv om dette riktig nok er en måte å organisere administrative enheter, fins det ikke to Oslo’er – men bare ett Oslo. Der Oslo slutter, begynner annen geografi. Derfor bør Oslo som entitet servert ut til Yr’s brukere, ha én instans som er både (by)kommune og fylke i ett: Pseudostruktur: Oslo is fylke and kommune (and by). Over dette Oslo fins bare Norge, og under dette Oslo fins stedene, f.eks Blindern.