I den første del af denne serie vi dækkede de fejl, der fører til HTML5's strukturelle elementer, i denne anden del vil vi se nærmere på konsekvenserne af disse fejl.

Jeg har sagt flere gange, at HTML5 introducerer en ny metode til strukturering af en webside, og du spekulerer nok nok på, hvad det egentlig er. Det er lige der i spec, som introducerer begrebet "sektionsindhold ': sektionsindhold er indhold, der definerer rækkevidden af ​​overskrifter og footers. Hvert sektionsindholdselement har muligvis en overskrift og en oversigt.

Specifikationen dokumenterer sin tilgang til overskrifter, sektioner og konturer for at gøre konceptet klart. Nå, klart for dem, der skal implementere funktionaliteten i browsere. For at forstå HTML's strukturelle elementer (sektion, artikel, nav, til side og deres relaterede elementer header og footer) og dette uklare koncept for 'sektionsindhold' eller 'skitsering', skal vi tage en lille tur gennem HTML-historie.

Uddybende et gammelt koncept

Konceptet af beskrivelsen introduceret i HTML5 kan spores tilbage indtil 1991 og blev inkluderet i den forfalskede XHTML 2.0-specielle ende og endelig ser dagens lys i HTML5 ... kun for at være så dårligt formidlet, at ideen er ret meget død ved ankomsten.

Før HTML5 blev den hierarkiske struktur af en side bestemt af overskriftselementerne - vores gamle venner h1 til h6. Vi kunne strukturere en side ved at sige sidetitel er h1, artiklen overskriften kan være h2, og måske underpositioner i artiklen kan være h3 og h4 osv.

Dette er fint for et simpelt dokument, men ved at bruge overskriftskoder til at skabe et logisk hierarki eller "dokumentoversigt", er det meget vanskeligt at lave en kompleks, moderne webside. En del af problemet er manglen på en måde at bestemme, hvor en sidesektion starter og stopper. For eksempel, at vi havde vores tidligere nævnte dokument med h1 for sidetitlen, h2 for artikeltitlen, h3 for underpositionerne, men så ønskede at markere titlen på vores sidebjælksektioner med h3 overskrifter også.

Dokumentoversigten, som en sådan struktur ville skabe, ville se noget sådan ud:

My Old Blog

My Latest Blog Post

My Blog Post Sub Heading

My Blog Post Sub Heading

About Me

Archives

Social Links

Her er h3-elementerne "ejet" af h2 over dem, selvom det ikke giver stor mening. Selvfølgelig vil vi bryde disse op med noget som div for artiklen og div til sidebjælken, men disse ignoreres af brugeragenter (f.eks. Skærmlæsere), der bestemmer sidebeskrivelsen ved at skrive strukturen alene.

Ved at binde sidehierarki direkte til, hvad der ofte er præsentationsoverskriftsniveauer, er vi begrænset til, hvordan vi kan strukturere en side.

Et nyt forsøg på et gammelt mål

I et forsøg på at løse dette problem introducerer HTML5 begrebet "sektionselementer", det vil sige specielle elementer, der opdeler siden op i - du gættede det - sektioner, og disse sektioner bestemmer hovedernes nestingsniveau og i virkeligheden hierarkiet , eller 'disposition' af siden.

Dvs., hierarkiet på siden er afkoblet fra overskriftselementerne, og i stedet bestemmer disse nye sektionselementer hvilket niveau et overskriftselement faktisk er.

I det første udkast XHTML 2.0 specifikation , snitning arbejdet med et snitelement og et generisk header h-element. Når vi skriver HTML, vil vi ikke angive, hvilket niveau af overskrift vi ønskede at bruge, vi ville bare lade browseren bestemme niveauet for reden for en given overskrift. Vi kunne rede sektionselementer 99 niveauer dybt, og et h-element på 99-niveauet ville svare til et h99-element. På den måde kan vi strukturere vores dokumenter logisk uden at bekymre os om, hvordan vi kan bruge de begrænsede h1-h6 elementer.

(Denne ide går virkelig tilbage til 1991, forresten: som Jeremy Keith påpegede, Tim Berners-Lee mødte ideen om en sektion og h element til at strukturere en side i slutningen af denne oktober 1991 email .)

Hickson forsøgte at introducere det samme koncept i HTML5, men med en ekstra vanskelighed: han ønskede at opretholde baglæns kompatibilitet og introducere nogle nye semantik til at "forenkle forfatteren" til at starte. Derfor har vi i stedet for bare at have et afsnitelement i HTML5 også en artikel, nav og sideelement, som alle gør det samme som afsnit, men med forskellige navne, der kan bruges på forskellige måder.

Hvad siger specikken om disse elementer? Jeg opfordrer dig til læs spec for dig selv , men her er en smag:

Sektionselementet er grundlaget for sektionering for at oprette en dokumentoversigt.

Sektionselementet repræsenterer en generisk sektion af et dokument eller en applikation. Et afsnit i denne sammenhæng er en tematisk gruppering af indhold, typisk med en overskrift.

Eksempler på sektioner ville være kapitler, de forskellige faneblade i en faneblad eller de nummererede sektioner af en afhandling. Et websteds hjemmeside kan opdeles i afsnit for en introduktion, nyhedsartikler og kontaktoplysninger.

Et notat i specifikationen siger, at elementet ikke bør bruges til rent styling formål - en div ville være bedre der, og forståeligt nok så, som sektioner kastet i willy-nilly for styling ville skabe en meget brudt dokument disposition.

Notatet fortsætter med at sige 'En generel regel er, at sektionselementet kun er passende, hvis elementets indhold vil blive angivet eksplicit i dokumentets disposition', og det er den klareste erklæring om sektionselementet i specifikationen.

Når vi forstår begrebet sektionering og skitsering, er inddragelsen af ​​sektionselementet fornuftigt. Det fremgik ikke i den fælles klasseværdierforskning, men den blev vist i XHTML 2.0 og går tilbage konceptuelt til 1991.

De øvrige strukturelle elementer HTML5 introducerer - dem, der skulle afspejles i forskningen - gør det samme som sektionselementet, hvad angår dokumentoversigten. De skaber også hierarkiet på siden og dermed dokumentets disposition.

Tag f.eks. Elementelementet. Mange mennesker antager, at det er simpelthen for artikler som denne. Men det er det slet ikke. Det er 'artikel' i den forstand, at der er tale om 'en beklædningsgenstand'. Det betragtes bedre som 'vare' som i 'et stykke tøj', da dets definition er så bred.

Når elementelementer er nestede, repræsenterer de indre artikelelementer artikler, som i princippet er relateret til indholdet af den ydre artikel. Et blogindlæg på et websted, der accepterer brugerindgivne kommentarer, kan for eksempel repræsentere kommentarerne som artikelelementer, der er nestet inden for artikelelementet til blogindgangen.

I HTML5 er brugerkommentarer, artiklen korrekt, forumindlæg og endda "interaktive widgets og gadgets" alle artikler. Definitionen er så bred, at den er ubrugelig - semantikken skal give mening, men ved at bruge et kollektivt udtryk for så mange forskellige elementer gør elementet meningsløst.

Dette er et eksempel, hvor vi har forkedet specen - nogle få mennesker følger specielt korrekt og gør næsten alt til en artikel (blogpostsammendrag, blogindlæg, kommentarer, widgets, forumindlæg osv.), Mens andre kun har holdt det for hovedartikelen på en side, som kun er en del af dens brede definition. Du tror måske, at det ligegyldigt betyder noget, og i høj grad vil du have ret. Men tænk på alle dem, der læser tjenester, der sigter mod at analysere hovedindholdet på siden. Hvilken implementering af specifikationen skal de følge? Skal de følge hvad spec specifikt siger, eller skal de følge det generelle samfunds implementering, hvor der normalt kun er en kanonisk 'artikel' på en side?

Dette er en ubesvaret mulighed, og hvad sker der, når specifikationen ikke præciserer , og redaktøren og for at være retfærdig, samfundet, undlader at kommunikere, hvad specifikationen faktisk siger.

Forestil dig, om artiklen ikke blev brugt til kommentarer. Forestil dig, om kommentarer fik deres eget element, for eksempel, og vedtagelsen blev udbredt. Browser beslutningstagere kunne tilføje en funktion til "mute comments", der nemt kunne skjule (eller på anden måde parse) kommentarer på websider. Men Hickson har specifikt nægtet en anmodning om et kommentarelement . I HTML5 er det artikler helt ned.

Bortset er et andet element, der ikke forekommer hvor som helst i Hicksons klassenavn forskning, og får en meget ejendommelig definition til at starte:

Bortset elementet repræsenterer et afsnit på en side, der består af indhold, der er tangentielt relateret til indholdet omkring bortset elementet, og som kan betragtes som adskilt fra det pågældende indhold. Sådanne sektioner er ofte repræsenteret som sidebjælker i trykt typografi.

Elementet kan bruges til typografiske effekter som træk citater eller sidebjælker til reklame for grupper af nav elementer og for andet indhold, der anses for at være adskilt fra hovedindholdet på siden.

Hvem ved hvorfor på side skal dække både pull citer, sidebars, reklame og grupper af navigationselementer, men det skaber også nye sektioner i dokumentoversigten. Det betyder, at træk citater får deres eget punkt i dokumentoversigten, hvilket synes, lad os sige "ulige". Igen har dets tilfældige brug af velmenende webdesignere og vil skabe mange brudte dokumentoversigter.

Nav-elementet virker mest selvforklarende for sektionselementerne, og heldigvis er definitionen ikke blevet strakt ud over brud.

Nav-elementet repræsenterer et afsnit på en side, der linker til andre sider eller dele på siden: et afsnit med navigationslinks.

Det er fint og kunne have teoretiske tilgængelighed fordele (en bruger agent kunne springe forbi eller springe til nav links - de gør det ikke, men de kunne).

Problemet er, at vi i en ånd af "forenkling af forfatterskab" og erstatter div med nav-elementet blæser navigations styling til en anden delmængde af brugere. Brugere af IE6-8 med JavaScript off (Yahoo's forskning tyder på 1-2% af alle brugere har javascript ud ) er ofre for dette problem. Med JavaScript, den JavaScript-baserede HTML5 shim, der hjælper IE6-8 forstå HTML5 elementer, virker ikke, så browseren stiler ikke HTML5 elementer. Dette kan kun påvirke et lille antal brugere, men hvorfor påvirker dem overhovedet?

&

Hoved- og footerelementerne er et klassisk tilfælde af at tage fælles vilkår og give dem meget forskellige anvendelser.

Specifikationen angiver, at ingen af ​​disse elementer opretter nye sektioner i dokumentoversigten, på trods af at de ofte er afbildet som værende på niveau med sektion, nav, artikel og til side. Faktisk gør de slet ikke noget. De er kun inkluderet for at afgrænse områder af en bestemt sektion i dokumentoversigten.

Her er hvad specen siger om header: headerelementet repræsenterer en gruppe introduktions- eller navigationshjælpemidler.

Bemærk: Et headerelement skal normalt indeholde sektionens overskrift (et h1-h6-element eller et hgroup-element), men dette er ikke nødvendigt. Overskriftselementet kan også bruges til at pakke ind en sektions indholdsfortegnelse, en søgeformular eller relevante logoer.

og footer: footer-elementet repræsenterer en footer for dets nærmeste forfædresnitindhold eller snitrødelement. En footer indeholder typisk oplysninger om sin sektion, som hvem skrev det, links til relaterede dokumenter, ophavsretsdata og lignende.

I HTML5 er kropselementet faktisk rodafsnittet, så en overordnet overskrift og sidefod skal beskrive hovedlegemet. Enhver sektion kan have en header og / eller en footer-de er ikke kun beregnet til overordnede overskrifter og footers, som vi måske har antaget. Individuelle kommentarer kan hver for eksempel have en header og et fodfelt. Faktisk, som vi rørte på tidligere, giver specen faktisk et eksempel på, at footer bruges i en kommentar over selve kommentarindholdet. Det er korrekt, i HTML5 kommentarer er artikler, og de kan have en footer for en header, og det er i den aktuelle specifikation. Ønskede du et footer-element til overskriften af ​​dine kommentarer? Ingen? Nå, du har en.

Igen er det her, hvor HTML5 tager almindelige vilkår og bruger dem på måder, der ikke kan genkendes til den fælles webforfatter.

Det er sektionering, hvad mangler det?

Men der er noget, vi ikke har set på i HTML's implementering af sektionering. Fandt du det? Vi har sektionselementerne, men vi har ikke et generisk h-element. Ikke bekymre dig, løsningen er i spec :

Afsnit kan indeholde overskrifter af en hvilken som helst rang, men forfatterne opfordres kraftigt til enten at bruge kun h1 elementer eller at bruge elementer af den passende rang for sektionens nestningsniveau.

HTML5 ønsker at være bagudkompatibel, så WHATWG besluttede ikke at introducere et h-element (på trods af at introducere en flok nye sektionselementer), og i stedet ønsker at omformulere h1-elementet som det generiske h-element. Brug h1 overalt, og lad HTML5-udformningsalgoritmen bestemme dets sande niveau ... eller så går teorien.

Dette er en forfærdelig ide af flere grunde, de to vigtigste er tilgængelighed og styling.

Tilgængelighed

Brug af h1 overalt er meget dårligt for tilgængelighed. Blinde brugere er afhængige af overskriften på et websted. Det er vigtigt for os alle at blive mindet om, hvor vigtig overskriftsstruktur er til tilgængelighedsformål. For eksempel, en december 2008 undersøgelse af over 1000 skærmlæser brugere udført af WebAIM fandt, at 76% af blinde og synskadede brugere altid eller ofte navigerede efter overskrifter, da de var tilgængelige. Og en undersøgelse fra maj 2012 viste, at 82,1% overskriftsniveauer var "meget nyttige" eller "noget nyttige", når du navigerede på en webside. (Dette er en god, praktisk forskning, så tag notat.)

At have h1s overalt vil gøre websteder sværere at navigere for blinde brugere. I teorien vil skærmlæsere i stedet bruge HTML-oversigtsalgoritmen og navigere ved hjælp af dokumentoversigten, men på den måde, som forfatterne har fået at vide om at implementere sektionselementer, er det et rod og forsøger at navigere i dokumentoversigter, som ikke har været tænkt overhovedet være endnu værre for blinde brugere.

HTML5-spec'en giver en vej ud: Fortsæt med at bruge de relevante h1-h6-niveauer for at opretholde baglæns kompatibilitet. Men nu opretholder vi to dokumentoversigter i det ene dokument, og i betragtning af de problemer, som forfatterne har haft i engang i betragtning af dokumentoversigten i første omgang, sandsynligheden for at nogen opretholder både en logisk h1-h6-oversigt og et logisk, korrekt -Sected HTML5 disposition synes i bedste fald remote.

Styling

Men det bliver værre. Lad os sige, at vi vil køre med en ren HTML5-oversigt, og vi bruger h1s overalt. Husk, at i HTML5-specen er h1 blot et generisk h-element; dets reelle niveau bestemmes af hvor dybt det er indlejret i snitelementer.

Så hvordan stilarter vi det? Nå, vi kunne tilføje klassenavne til alle vores h1-elementer, så vi kan udvælge dem, men det er i strid med det angivne HTML5-mål for at forenkle forfatteren; og vi kan lige så godt holde os til h1-h6 (som alle behandles som generiske h-elementer i en HTML5-oversigt).

Vi kunne forsøge at style dem gennem kaskaden, men det bliver hurtigt absurd, som Nicole Sullivan har påpeget . Faktisk begynder "absurd" kun at beskrive det. Når du overvejer de mulige kombinationer af sektion, artikel, nav og til side, og du vil oprette en generisk stil til en overskrift, det vil sige fem niveauer dybt (dvs. tilsvarende h5), skal du skrive stilarter til alle mulige kombinationer, som får absolut latterligt . Her er den generiske stil til et h3-element:

article aside nav h1, article aside section h1,article nav aside h1, article nav section h1,article section aside h1, article section nav h1, article section section h1,aside article nav h1, aside article section h1,aside nav article h1, aside nav section h1,aside section article h1, aside section nav h1, aside section section h1,nav article aside h1, nav article section h1,nav aside article h1, nav aside section h1,nav section article h1, nav section aside h1, nav section section h1,section article aside h1, section article nav h1, section article section h1,section aside article h1, section aside nav h1, section aside section h1,section nav article h1, section nav aside h1, section nav section h1,section section article h1, section section aside h1, section section nav h1, section section section h1 {font-size: 1.00em;}

Men det er, hvad HTML's strukturelle elementer giver os. Sikke et rod.

Sulten for mere? Del tre af denne artikel er nu tilgængelig, og Lukas bog "The Truth About HTML5" er tilgængelig i et begrænset tidsrum gennem vores søsters websted MightyDeals.com med en fantastisk 50% rabat.

Bruger du artikelelementer flere gange i et dokument? Er sektioner nyttige eller skal vi holde fast med divs? Lad os vide dine tanker i kommentarerne.

Fremhævet billede / miniaturebillede, anvendelser struktur billede via Shutterstock.