HTML: Semanttinen asettelu. Keskustelua HTML-koodin semantiikasta esimerkein
Semantiikka(ranskalainen sémantique antiikin kreikasta σημαντικός - tarkoittaa) - tiede ymmärtää tiettyjä merkkejä, symbolisarjoja ja muita symboleja. Tätä tiedettä käytetään monilla aloilla: lingvistiikassa, proksemiikassa, pragmatiikassa, etymologiassa jne. En voi kuvitella, mitä nämä sanat tarkoittavat ja mitä kaikki nämä tieteet tekevät. Ja sillä ei ole väliä, olen kiinnostunut semantiikan käytöstä verkkosivuston ulkoasussa.
Muistilappu
En käsittele termiä Semantic Web tässä. Ensi silmäyksellä saattaa vaikuttaa siltä, että aiheet Semantic Web ja semanttinen HTML-koodi ovat lähes sama asia. Mutta itse asiassa semanttinen verkko on melko filosofinen käsite, eikä sillä ole paljon yhteistä nykyisen todellisuuden kanssa.
Semanttinen asettelu - mikä se on?
Kielessä jokaisella sanalla on erityinen merkitys ja tarkoitus. Kun sanot "makkara", tarkoitat elintarviketuotetta, joka on jauhelihaa (yleensä lihaa) pitkänomaisessa kuoressa. Lyhyesti sanottuna tarkoitat makkaraa, et maitoa tai vihreitä herneitä.
HTML on myös kieli, jonka "sanoilla", joita kutsutaan tageiksi, on myös tietty looginen merkitys ja tarkoitus. Tästä syystä ensinnäkin semanttinen HTML-koodi on asettelu, jossa HTML-tunnisteita käytetään oikein, käyttämällä niitä aiottuun tarkoitukseen, kuten HTML-kielen ja verkkostandardien kehittäjät tarkoittivat.
microformats.org on yhteisö, joka pyrkii herättämään semanttisen verkon idealistiset ideat henkiin tuomalla sivun asettelun lähemmäksi samoja semanttisia ihanteita.
Miksi ja kuka ylipäätään tarvitsee semanttista asettelua?
Jos verkkosivuni tiedot näkyvät samalla tavalla kuin suunnittelussa, miksi vaivautua ryöstelemään aivojasi ja miettimään jonkinlaista semantiikkaa?! Tämä on lisätyötä! Kuka tätä tarvitsee?! Kuka arvostaa tätä paitsi toinen taittosuunnittelija?
Olen kuullut tällaisia kysymyksiä usein. Selvitetään se.
Semanttinen HTML web-kehittäjille
Semanttinen koodi käyttäjille
Lisää tiedon saatavuutta sivustolla. Ensinnäkin tämä on tärkeää vaihtoehtoisille aineille, kuten:
- semanttinen koodi vaikuttaa suoraan HTML-koodin määrään. Vähemmän koodia -> kevyempiä sivuja -> latautuu nopeammin, vähemmän RAM-muistia tarvitaan käyttäjän puolella, vähemmän liikennettä, pienempi tietokannan koko. Sivustosta tulee nopeampi ja halvempi.
- ääniselaimet joille tunnisteet ja niiden attribuutit ovat tärkeitä, jotta sisältö lausutaan oikein ja oikealla intonaatiolla, tai päinvastoin, ei liikaa.
- mobiililaitteet jotka eivät täysin tue CSS:ää ja siksi luottavat pääasiassa HTML-koodiin ja näyttävät sen näytöllä käytettyjen tunnisteiden mukaan.
- tulostuslaitteet Tieto tulostuu jopa ilman ylimääräistä CSS:ää paremmalla laadulla (lähempänä suunnittelua), ja ihanteellisen version luominen tulostamista varten muuttuu muutamaksi helpoksi CSS-käsittelyksi.
- Lisäksi on laitteita ja laajennuksia, joiden avulla voit nopeasti selata asiakirjaa - esimerkiksi Operassa otsikoiden perusteella.
Semanttinen HTML koneille
Hakukoneet parantavat jatkuvasti hakumenetelmiään varmistaakseen, että tulokset sisältävät haluamasi tiedot. todella etsimässä käyttäjä. Semanttinen HTML helpottaa tätä, koska... soveltuu paljon parempaan analysointiin - koodi on selkeämpi, koodi on looginen (näet selvästi missä otsikot ovat, missä navigointi, missä sisältö).
Hyvä sisältö ja laadukas semanttinen asettelu on jo vakava sovellus hyvät sijoitukset hakukonetuloksissa.
HTML-koodin semantiikka on aina kuuma aihe. Jotkut kehittäjät yrittävät aina kirjoittaa semanttista koodia. Toiset arvostelevat dogmaattisia kannattajia. Ja jotkut eivät edes tiedä, mikä se on ja miksi sitä tarvitaan. Semantiikka määritellään HTML:ssä tageissa, luokissa, tunnuksissa ja attribuuteissa, jotka kuvaavat tarkoitusta, mutta eivät määrittele niiden sisältämää tarkkaa sisältöä. Eli puhumme sisällön ja sen muodon erottamisesta.
Aloitetaan ilmeisellä esimerkillä.
Huono koodin semantiikka
Hyvä koodin semantiikka
Jonkun kirjoittaman artikkelin teksti. Inko Gnito- sen kirjoittaja.Artikkelin otsikko
Käytä tagia riippumatta siitä, onko HTML5 käyttövalmis vai ei Mutta kaikkea ei esitetä niin selvästi HTML5-tunnisteilla. Katsotaanpa joukko luokan nimiä ja katsotaan, täyttävätkö ne semanttiset vaatimukset. Ei semanttinen koodi. Tämä on klassinen esimerkki. Jokainen CSS-ruudukon työpenkki käyttää tämäntyyppisiä luokkanimiä ruudukkoelementtien määrittämiseen. Olipa kyseessä "yui-b", "grid-4" tai "spanHalf" - tällaiset nimet ovat lähempänä merkintöjen määrittämistä kuin sisällön kuvaamista. Niiden käyttö on kuitenkin väistämätöntä useimmissa tapauksissa, kun työskennellään modulaaristen ruudukkomallien kanssa. Semanttinen koodi. Alatunniste on saanut vahvan merkityksen web-suunnittelussa. Tämä on sivun alaosa, joka sisältää elementtejä, kuten toistuvan navigoinnin, käyttöoikeudet, tekijätiedot ja niin edelleen. Tämä luokka määrittelee ryhmän kaikille näille elementeille kuvaamatta niitä. Jos olet siirtynyt käyttämään HTML5:tä, on parempi käyttää elementtiä Ei semanttinen koodi. Se määrittelee sisällön tarkasti. Mutta miksi tekstin pitää olla suurta? Erottuako pienemmistä teksteistä? "standOut" (korostus) on sopivampi tässä tapauksessa. Voit päättää muuttaa korostustekstin tyyliä, mutta et tee mitään sen koon suhteen, jolloin luokan nimi saattaa hämmentää sinua. Semanttinen koodi. Tässä tapauksessa puhumme elementin tärkeystason määrittämisestä sovellusliittymässä (esimerkiksi kappale tai painike). Korkeamman tason elementissä voi olla kirkkaat värit ja suurempi koko, kun taas alemman tason elementit voivat sisältää enemmän sisältöä. Mutta tässä tapauksessa tyyleille ei ole tarkkaa määritelmää, joten koodi on semanttinen. Tämä tilanne on hyvin samanlainen kuin tagien käyttäminen Semanttinen koodi. Kunpa jokaisen luokan nimi olisi niin selkeästi määritelty! Tässä tapauksessa meillä on kuvaus osiosta, jossa on sisältöä, jonka tarkoitus on helppo kuvata, kuten "tweetit", "sivut" tai "admin-nav". Ei semanttinen koodi. Tässä tapauksessa puhumme tyylin asettamisesta sivun ensimmäiselle kappaleelle. Tätä tekniikkaa käytetään kiinnittämään lukijoiden huomio materiaaliin. On parempi käyttää nimeä "intro", joka ei mainitse elementtiä. Mutta on vielä parempi käyttää valitsinta tällaisille kappaleille, kuten artikkeli p:first-of-type tai h1 + p . Ei semanttinen koodi. Tämä on hyvin yleinen luokan nimi, jota käytetään elementtien muotoilun järjestämiseen. Mutta siinä ei ole mitään, mikä liittyisi sisällön kuvaukseen. Useat semanttiset teoreetikot suosittelevat käyttämään luokan nimeä, kuten "ryhmä". On todennäköistä, että he ovat oikeassa. Koska tämä elementti epäilemättä palvelee useiden muiden elementtien ryhmittelyä, suositeltu nimi kuvaa paremmin sen tarkoitusta yksityiskohtiin sukeltamatta. Ei semanttinen koodi. Liian yksityiskohtainen kuvaus sisältömuodosta. On parempi valita jokin muu nimi, joka kuvaa sisältöä sen muodon sijaan. Semanttinen koodi. Luokka kuvaa sisällön tilan erittäin hyvin. Esimerkiksi onnistumisviestillä voi olla täysin erilainen tyyli kuin virheviestillä. Ei semanttinen koodi. Tässä esimerkissä yritetään määritellä sisällön muoto eikä tarkoitus. "plain-jane" on hyvin samanlainen kuin "normaali" tai "tavallinen". Ihanteellinen CSS-koodi tulee kirjoittaa siten, että sisällön muotoa kuvaavia luokkien nimiä, kuten "tavallinen", ei tarvita. Ei semanttinen koodi. Tämän tyyppisiä luokkia käytetään yleensä määrittämään sivustoelementtejä, joita ei pitäisi sisällyttää linkkiketjuun. Tässä tapauksessa on parempi käyttää jotain kuten rel=nofollow linkeissä, mutta ei luokkaa kaikelle sisällölle. Ei semanttinen koodi. Tämä on yritys kuvata sisällön muotoa, ei sen tarkoitusta. Oletetaan, että verkkosivustollasi on kaksi artikkelia. Ja haluat antaa heille erilaisia tyylejä. "Elokuva-arvostelut" on sinisellä taustalla ja "Breaking News" on punainen tausta ja suurempi kirjasinkoko. Yksi tapa ratkaista ongelma on tämä: Toinen tapa on tämä: Varmasti, jos haastat useita kehittäjiä siitä, mikä koodi vastaa paremmin semanttisia vaatimuksia, suurin osa varmasti viittaa ensimmäiseen vaihtoehtoon. Se vastaa täydellisesti tämän oppitunnin materiaalia: tarkoituksen kuvaus ilman linkkejä muotoiluun. Ja toinen vaihtoehto ilmaisee muodon ("blueBg" on luokan nimi, joka muodostuu kahdesta englanninkielisestä sanasta, jotka tarkoittavat "sinistä taustaa"). Jos päätät yhtäkkiä muuttaa elokuva-arvostelujen suunnittelua - esimerkiksi tehdä vihreän taustan, luokan nimi "blueBg" muuttuu kehittäjän painajaiseksi. Ja nimen "elokuva-arvostelu" avulla voit ehdottoman helposti muuttaa suunnittelutyylejä säilyttäen samalla erinomaisen koodituen. Mutta kukaan ei väitä, että ensimmäinen esimerkki on parempi kaikissa tapauksissa poikkeuksetta. Oletetaan, että tiettyä sinisen sävyä käytetään monissa paikoissa sivustolla. Se on esimerkiksi tausta joillekin sivupalkin alatunnisteille ja alueille. Voit käyttää seuraavaa valitsinta: Elokuva-arvostelu, alatunniste > div:nth-of-type(2), sivuun > div:nth-of-type(4) ( tausta: #c2fbff; ) Tehokas ratkaisu, koska väri määräytyy vain yhdestä paikasta. Mutta tällaista koodia on vaikea ylläpitää, koska siinä on pitkä valitsin, jota on vaikea visuaalisesti ymmärtää. Tarvitset myös muita valitsimia yksilöllisten tyylien määrittämiseen, mikä johtaa koodin toistoon. Tai voit valita toisenlaisen lähestymistavan ja pitää ne erillään: Elokuva-arvostelu ( tausta: #c2fbff; /* Värin määritelmä */ ) alatunniste > div:nth-of-type(2) ( tausta: #c2fbff; /* Ja vielä yksi asia */ ) sivuun > div:nth-of - type(4) ( tausta: #c2fbff; /* Ja vielä yksi asia */ ) Tämä tyyli auttaa pitämään CSS-tiedoston järjestyksessä (eri alueet on määritelty eri osioissa). Mutta maksettava hinta on määritelmien toisto. Suurilla sivustoilla saman värin tunnistaminen voi olla useita tuhansia kertoja. Kauhea! Ratkaisu olisi käyttää luokkaa, kuten "blueBg", määrittämään väri kerran ja lisäämään se HTML-koodiin, kun haluat käyttää tätä mallia. Tietenkin on parempi kutsua sitä "mainBrandColor" tai "secondaryFont" päästäksesi eroon muotoilun kuvauksesta. Voit uhrata koodisemantiikan säästääksesi resursseja. HTML-tunnisteiden tarkoitus on välittää järkeä asiakirja. Älä ole huolissasi siitä, miltä verkkosivusi näyttää. Keskity jokaisen käyttämäsi tunnisteen merkitykseen. Kirjoittamasi sisällöstä riippuen voit valita sopivan elementin, joka vastaa tekstin merkitystä. Alue elementit ovat riittävän leveitä materiaaleihin sopivaksi yleistä kohteet (kuten kappaleet tai luettelot) ja paljon muuta erityisiä sisältö kuten Rakenneelementit auttavat sinua järjestämään sivusi pääosat. Ne sisältävät yleensä muita HTML-elementtejä. Tässä on mitä tyypillinen verkkosivu voi sisältää: Sisältä yleensä löytyvät rakenneosat teksti elementtejä, jotka on suunniteltu määrittämään kohde sisältöäsi. Käytät pääasiassa: Kappaleita varten; Koska tekstielementit voivat olla pitkiä, mutta sisällöltään erilaisia, pienet kirjaimet elementit sallivat erottaa tekstin osia. Sisäisiä elementtejä on monia, mutta tavallisesti kohtaat seuraavat: Vain lukemalla tämän HTML-koodin voit helposti ymmärtää, mitä kukin tarkoittaa HTML-elementti.
Jotkut kaikenlaisia asioita ja jotkut omistettu ja jopa tärkeä sanat. Toinen kappale. Kun mikään semanttinen elementti ei sovi sisällöllesi, mutta haluat silti lisätä HTML-elementin (ryhmittelyä tai tyyliä varten), voit tyytyä johonkin kahdesta yleistä elementit: Vaikka nämä HTML-elementit eivät itse asiassa sisällä mitään järkeä, niistä on hyötyä, kun alamme käyttää CSS:ää. Valittavana on noin 100 semanttista HTML-elementtiä. Se on paljon. Voi olla ylivoimaista käydä läpi tämä luettelo ja valita sisällöllesi sopiva kohde. Mutta älä käytä liikaa aikaa sen murehtimiseen. Jos pysyt toistaiseksi seuraavassa luettelossa, se riittää. Tänään puhumme HTML5:n semantiikasta. Olen jo kirjoittanut lyhyen arvostelupostauksen aiheesta. Suosittelen, että tutustut siihen ennen tämän artikkelin lukemista. Nyt tarkastellaan tätä asiaa yksityiskohtaisemmin, kuinka HTML5-dokumentin semanttinen rakenne luodaan oikein ja asiantuntevasti. Tässä artikkelissa luomme vähitellen HTML-sivun ja koristelemme sen semanttisilla HTML5-tageilla. Kuva - HTML5-sivun semanttinen rakenne. Aloitetaan tavallisella HTML5-dokumenttimallilla ja lisätään päähän sisällönkuvauskentät:
Lisäsin tagin joka vastaa avainsanoista. Ja tagi joka vastaa sivun kuvauksesta. SEO-optimointia varten nämä tunnisteet ovat pakollisia. Tunniste on myös täytettävä oikein Mennään pidemmälle. HTML5 esitteli uusia tunnisteita, joita käytetään semanttisten merkintöjen luomiseen dokumenttiin. Nämä ovat header-, nav-, main-, article-, aside-, alatunnisteet jne. tagit. Näytön suhteen ne toimivat samalla tavalla kuin tavalliset. Sivun otsikko muotoillaan otsikkotunnisteessa. Huomaa, että sivun otsikko on kirjoitettu h1-tunnisteella.
Jos otsikon vieressä on myös iskulause, sijoitamme sen p-, div- tai span-kirjaimeen.
sivuston iskulause Huomautus H1-tunnisteesta On huomattava, että HTML5:ssä H1-tunnistetta käytetään osoittamaan sen säilön otsikkoa, jossa se sijaitsee (tämä voi olla otsikko, osio, artikkeli jne.) Ennen HTML5-tunnisteiden tuloa semantiikka oli hieman erilainen ja erilainen. Joten HTML4:ssä voi olla vain yksi H1-otsikko sivulla! Tämä oli pääsääntöisesti artikkelin otsikko tai sivun otsikko (esimerkiksi jos kyseessä on luokkasivu, jolla on useita artikkeleita.) H2:ta käytettiin alaotsikoina tai pääartikkelin osioissa. H3 alaosioille ja niin edelleen. Sivuston päänavigoinnin suunnittelun tulee sisältyä nav-tunnisteeseen. Muista myös, että navigoinnin suunnittelu listaelementeillä on hyvä käytäntö.
Sivun pääsisältö on muotoiltu päätunnisteeseen. Tämä voi olla yksi artikkeli tai useita artikkelien esikatseluja, jos puhumme blogisivusta, jossa on useita merkintöjä. Et voi sijoittaa sivupalkkia, sivun otsikkoa, alatunnistetta tai päänavigointia päätunnisteeseen!
Artikkelitunnistetta käytetään artikkeleiden käärimiseen. Yleensä tämä tunniste sisältää sisältölohkon, joka voidaan poistaa sivun kontekstista ja käyttää erikseen muualla. Tämä voi olla artikkeli (artikkelin koko teksti tai esikatselu), viesti foorumilla jne. Alla olevassa esimerkissä näytin artikkelin ulkoasun kontekstissa, päätunnisteen sisällä. Artikkelissa on otsikkolohko, jossa on artikkelin otsikko. Artikkelin julkaisupäivämäärä määritellään erityisellä aikatunnisteella, joka näytetään tavallisena rivielementtinä. Aikatunnisteella on erityinen attribuutti, jossa julkaisuaika on määritettävä konemuodossa. Tämä voi olla vain datetime="2015-09-30" tai tuntien minuuttien ja sekuntien datetime="2015-09-30T15:25:55" . Pubdate-parametri osoittaa, että artikkeli on julkaistu samaan aikaan kuin se kirjoitettiin. Jos tämä on uutinen, voi olla, että uutisten aika on yksi ja julkaisuaika eri, tätä varten sinun on määritettävä aikatunniste kahdesti ja laitettava pubdate vain tagiin, jossa julkaisuaika on ilmoitettu. Lorem ipsum dolor sit amet, consectetur adipisicing elit. Nemo quisquam, soluta sunt, aliquam voluptatem voluptates! Deserunt repudiandae aperiam pariatur sit harum at a, quo, est neque. Adipisci beatae eaque unde? Yllä olevasta esimerkistä näet, että otsikko- ja alatunnisteita käytettiin artikkelin sisällä korostamaan artikkelin otsikkoa ja alatunnistetta. Jokaiselle yksittäiselle sivupalkin elementille käytämme sivupalkin. Sen sisällä otsikko on muotoiltu h1-tunnisteella. Joten sivupalkin sarake voi näyttää tältä:
Osatunnistetta käytetään edustamaan temaattisesti liittyvän sisällön ryhmää tai osiota. Sen käyttö on samanlaista kuin artikkelin pääasiallinen ero on, että elementin sisällöllä ei saa olla merkitystä Jos haluat antaa esimerkin nyt lukemastasi artikkelista, voit kääriä jokaisen kappaleen tunnisteeseen Esimerkki osiotunnisteen käytöstä kaupunkiluettelossa: Liity seuraamme näissä kaupungeissa vuonna 2010. Seuraa keltaista tiili tietä. Se on Beantown ystävilleen. Se on niin kiva. Sivuston alatunniste on suunniteltu tagilla
Voit tarkistaa sivun rakenteen HTML5 outliner -työkalulla. Se näyttää sivun rakenteen lohkojen ja otsikoiden mukaan. HTML5:n semantiikka ei rajoitu edellä artikkelissa annettuihin tunnisteisiin. Mutta käyttämällä yllä olevia esimerkkejä, voit päivittää merkintäsi ja tehdä sivustostasi hakukoneystävällisemmän, mikä parantaa sivustosi sijoitusta hakutuloksissa. Voit jatkaa tätä aihetta tutkimalla muita uusia HTML5-tageja. Sekä mikroformaatit tietojen suunnitteluun ja jäsentelyyn, kuten schema.org Tärkeä huomautus HTML5-tunnisteiden käytöstä. Spesifikaatio ei määrittele tiukkoja sääntöjä semanttisten tunnisteiden käytölle, se antaa vain suosituksia niiden käytöstä. Jos et ymmärrä tai et tiedä missä ja mitä HTML5-tunnistetta käyttää, on parempi käyttää diviä, jotta asiakirjan rakennetta ei vahingoiteta tai riko. Artikkelit ja materiaalit Kuvitukset: Kevin Cornell Käännös: Vlad Merževitš Haluan tehdä rohkean ennusteen. Kun sinä ja minä katoamme, HTML on edelleen olemassa. Ei vain aikakautemme miljardeilla arkistoiduilla sivuilla, vaan elävänä, hengittävänä organismina. Liian paljon vaivaa, energiaa ja investointeja käytettiin Internet-työkalujen, protokollien ja alustojen kehittämiseen, jotta se olisi niin helppo hylätä. Keskitytään omaan vastuuseen. Valitettavasti historiassa meidät yhdistetään sivilisaatiollemme tärkeän työkalun kehittämiseen, jota käytetään viestintään tulevina vuosikymmeninä. Siten, kun omistamme mielemme, tyhjäkäynnillä tai vakavasti, HTML:n parantamiseen, meidän on tänään ymmärrettävä kauaskantoisten päätösten seuraukset. HTML5, jota W3C äskettäin kaksinkertaisti ponnistelunsa seuraavan HTML-sukupolven muotoilemiseksi, on kehittynyt merkittävästi. Tämä on valtava projekti, joka kattaa paitsi HTML-rakenteen, myös jäsennysmallin, virheiden käsittelyn, DOM:n, resurssien poiminta-algoritmit, mediasisällön, 2D-grafiikan, tietomallit, suojauksen, lataussivut, asiakaspuolen tiedontallennustilan ja paljon muuta . Myös HTML:n rakenteeseen, syntaksiin ja semantiikkaan on tehty muutoksia, jotka Lachlan Hunt käsitteli artikkelissa osittain. Mutta tässä artikkelissa keskitytään vain HTML-semantiikkaan. Se on kiinnostanut minua useiden vuosien ajan ja uskon, että semantiikka on olennaisen tärkeä HTML:n tulevaisuuden kannalta. BBC ilmoitti äskettäin hylkäävänsä ohjelmaluetteloissaan käytetyn hCalendar-mikromuodon ja valittavansa kätevän ja helposti saatavilla olevan lyhennemallin. Tämä osoittaa, että olemme epäilemättä ylittäneet HTML:n semanttiset ominaisuudet, jotka oli tarkoitettu kielelle. Meillä on yksinkertaisesti loppuneet HTML-elementit ja attribuutit, jotka rikastavat asiakirjojen semanttista merkintää. Jos jatkamme huijaamista olemassa olevilla HTML-rakenteilla, syntyy monia ongelmia, koska HTML semanttisena merkintäkielenä kärsii perustavanlaatuisesta puutteesta - sen semantiikka on kiinteä eikä laajennettavissa. Tämä ei ole vain teoreettinen ongelma. Sadat tuhannet kehittäjät käyttävät class- ja id-attribuutteja luodakseen monipuolisia semanttisia merkintöjä. Samaan aikaan kehittäjät käyttävät lähes poikkeuksetta erityisiä sanakirjoja, joita he itse laativat, sen sijaan, että ne käyttävät olemassa olevista skeemoista otettuja arvoja. Tämä on parhaimmillaan pseudosemantiikkaa. Monilla Internetin sivuilla käytetään mikromuotoja jäsennellymmän semantiikan lisäämiseen kuin saatavilla olevien HTML-elementtien ja attribuuttien heikko joukko. Tässä tapauksessa luokka-attribuutille käytetyt arvot asetetaan konsensussanastoista, toisinaan muista standardeista, kuten vCardista, ja joskus uusista sanastoista, joissa ei ole kiinteää standardia (kuten hReviewissa). On olemassa todellinen ongelma, joka on ratkaistava. Tarvitsemme HTML:ään mekanismeja, jotka antavat kehittäjille mahdollisuuden lisätä selkeästi ja yksiselitteisesti merkityksellisempää semantiikkaa merkintään pseudosemantiikan sijaan. Tämä on ehkä yksi HTML5-projektin tärkeimmistä tavoitteista. Mutta tällaisen mekanismin keksiminen ei ole niin helppoa, koska kaikilla ratkaisuilla on rajoituksia. On merkittäviä rajoituksia, joista ehkä suurin on taaksepäin yhteensopivuus. Ratkaisun ei pitäisi rikkoa satoja miljoonia laitteita, joita käytetään nykyään ja joita käytetään vielä monta vuotta. Kehittäjät eivät hyväksy laajasti ratkaisuja, joissa ei ole taaksepäin yhteensopivuutta, koska he pelkäävät lukijoiden menettämisen. Tällaiset päätökset kuihtuvat nopeasti viiniköynnökseen. Ratkaisun tulee olla yhteensopiva myös tulevien versioiden kanssa. Ei siinä mielessä, että sen pitäisi toimia tulevissa selaimissa - se on selainkehittäjien vastuulla, mutta sen pitäisi olla laajennettavissa. Emme voi odottaa yhdenkään juuri nyt kehitettävän ratkaisun ratkaisevan kaikkia ajateltavissa olevia ja käsittämättömiä tulevaisuuden semanttisia tarpeita. Voimme suunnitella ratkaisun kasvaviin tarpeisiin niiden ilmaantuessa. Tämä kahden rajoituksen tandem on todella suuri ongelma. Mutta kielen kontekstissa, jonka suuret iteraatiot ovat toistuneet vuosikymmeniä ja jonka merkitys globaalina viestintäalustana on ensiarvoisen tärkeä, tähän haasteeseen on vastattava. Joten miten HTML5 ratkaisee tämän ongelman? HTML5 tuo joukon uusia elementtejä, joista joitain kutsun "rakenteellisiksi" - Vaikka nämä elementit voivat olla hyödyllisiä ja näyttävät herättäneen kiinnostusta, ratkaisevatko ne todella ongelman, erityisesti taaksepäin ja tulevan yhteensopivuuden? Katsotaanpa jokaista rajoitusta. Kuinka modernit selaimet käsittelevät uusia elementtejä, kuten
tämä on teksti osion sisällä Näyttää hienolta aloitukselta. Mutta kun yritämme asettaa esimerkiksi tämän tyylin elementille Osa (väri: punainen) Useimmat mainitut selaimet muuttivat elementin tyyliä, mutta IE8 (ja IE6–7) eivät. Meillä on siis vakava taaksepäin yhteensopivuusongelma 75 %:lla tällä hetkellä käytössä olevista selaimista. Ottaen huomioon Internet Explorerin puoliintumisajan voimme ennustaa, että suurin osa käyttäjistä käyttää edelleen IE6:ta ja IE7:ää muutaman vuoden kuluttuakin. Jos HTML5 tuo uusia elementtejä, mikä on todennäköisyys, että useimmat kehittäjät ottavat ne käyttöön, koska ne eivät ole olennaisesti yhteensopivia useimpien selainten kanssa? Valitettavasti, jos näet vaihtoehtoisen ratkaisun CSS-ongelmaan, on sisällyttää elementtiin class-attribuutti Siirrytään toiseen rajoitukseen - yhteensopivuus tulevien versioiden kanssa. Aloitetaan esittämällä kysymys: "Miksi keksiä uusia elementtejä?" Järkevä vastaus tähän olisi: "Koska HTML:stä puuttuu semanttinen rikkaus, ja lisäämällä näitä elementtejä lisäämme HTML:n semanttista rikkautta - mikä ei ole huono asia, vai mitä?" Lisäämällä näitä elementtejä pyrimme lisäämään semanttisia ominaisuuksia HTML:ssä, mutta vain kapealla alueella. Riippumatta siitä, kuinka monta elementtiä otetaan käyttöön, harkitsemme aina semantiikan lisäämistä HTML-koodiin. Lisäämällä niin monta uutta elementtiä kuin haluamme, ei silti ratkaista ongelmaa. Meidän ei tarvitse lisätä tiettyjä ehdot HTML-sanakirjaan meidän on lisättävä mekanismi, jonka avulla voimme rikastaa asiakirjaa semantiikan avulla tarpeen mukaan. Teknisestä näkökulmasta meidän on tehtävä HTML:stä laajennettavissa oleva. HTML5:ssä ei ole laajennusmekanismia. Tästä syystä HTML5 tappaa merkittävän osan nykyaikaisista selaimista eikä todellisuudessa lisää semantiikkaa ollenkaan. Mikset hyväksy olemassa olevaa sanakirjaa, samaa Docbookia? Sen asiakirjarakenteen sanasto on paljon rikkaampi, ja useat asiantuntijat ovat sitä kehittäneet useiden vuosien ajan. Tämä ei kuitenkaan ole argumentti Docbookin puolesta, pointti on, että tehtävä HTML:n semanttisen rikkauden mekanismin tarjoamisesta kulkee omalla tavallaan kiinnittäen vain vähän huomiota parhaisiin käytäntöihin liittyen työhön kolmekymmentä vuotta sitten (alkuperäinen työ alkoi 70-luvun alussa). Vaikka kritisoin nykyisiä pyrkimyksiä, onko minulla käytännön neuvoja tämän ongelman ratkaisemiseksi? No, aloitan yhdestä. Vaikka elementtien lisääminen HTML:ään ei ole aihetta, ainakin tässä keskustelussa attribuutit ovat toinen HTML:n looginen alue, johon keskitymme. Olemmehan melkein vuosikymmenen ajan käyttäneet class- ja id-attribuutteja mekanismeina HTML-semantiikan laajentamiseen. Monet kehittäjät tuntevat tämän lähestymistavan ja ovat tyytyväisiä siihen. Mikroformaatit-projekti on osoittanut, että olemassa olevat HTML-attribuutit eivät riitä tarjoamaan universaalia mekanismia HTML-semantiikan laajentamiseen. Joten jos haluamme käyttää määritteitä tämän ongelman ratkaisemiseksi, meidän on sisällytettävä yksi tai useampi uusi attribuutti. Ennen kuin perehdymme tämän toiminnan mekaniikkaan, testataan tätä ratkaisua samojen vaatimusten mukaisesti kuin uudet HTML5-elementit. Mikä tärkeintä, ovatko uudet HTML-attribuutit taaksepäin yhteensopivia? Ja jos on, tarjoaako tämä todellisen mekanismin semanttiselle HTML-laajennukselle? Otetaan uusi attribuutti käyttöön. Kutsun sitä "rakenteeksi", mutta nimenomaisella nimellä ei ole väliä. Voimme käyttää sitä näin:
Katsotaan kuinka selaimemme käsittelevät sitä. Ja tietysti kaikkien selaimien on vaihdettava tyyliään CSS:n kautta. Div (väri: punainen) Mutta miten se tehdään? Div (fontin paino: lihavoitu) Itse asiassa melkein kaikki selaimet, mukaan lukien IE7, ovat tyylikkäitä Uusien elementtien sijaan HTML5:n tulisi hyväksyä useita uusia attribuutteja. Jokainen näistä attribuuteista sisällytetään semantiikan luokkaan tai tyyppiin. Esimerkiksi, kuten minä, HTML sisältää rakenteellisen semantiikan, retorisen semantiikan, roolisemantiikan (otettu XHTML:stä) ja muita semantiikan luokkia tai luokkia. Näitä uusia attribuutteja voidaan käyttää samalla tavalla kuin luokkaattribuuttia: elementin luonnetta kuvaavan semantiikan liittämiseen elementtiin sekä metatietojen lisäämiseen elementistä. Tämä ei eroa XHTML:n rooliattribuutista, mutta sen sijaan, että yksi attribuutti ottaisi kunnian kaikille semanttisille elementeille, meidän on määriteltävä erityyppiset elementin semantiikka ja erotettava ne. Esimerkiksi rooli-attribuutti XHTML:ssä toimii näin:
Roolimääritteen arvot ovat välilyönnillä eroteltu luettelo oletussanakirjasta tai tietystä sanakirjasta. Mikset vain ota roolimääritettä sellaisenaan? No, on olemassa muunlaisia semantiikkaa, joihin roolisanakirja ei sovellu. Esimerkiksi:
Hän on fantastinen ihminen. Tässä on esitetty teoreettinen semantiikan tyyppi - "retoriikka", jota voidaan käyttää dokumentin retorisen luonteen merkitsemiseen. Tämä elementti ei tietenkään näytä ironista asiakirjassa. Pikemminkin se sisältää ironiaa. Tässä on toinen esimerkki. HTML:stä puuttuu selvästi tapa liittää koneellisesti luettavat versiot esimerkiksi päivämäärän ihmisen luettavaan versioon. Tämä on BBC:n hCalendar-mikromuotoon liittyvän ongelman ydin, josta keskustelimme aiemmin. Siitä huolimatta Ensi vuoden toukokuun ensimmäinen ei todellakaan ole mitään järkeä, jotain linjaa Ensi vuoden toukokuun ensimmäinen ilmestyy. Jälleen, käytämmekö tälle semanttiselle attribuutille erityistä termiä "ekvivalentti" vai jotain muuta termiä, ei ole tärkeää. Tärkeintä on huomata, että tämä ei ole niin yksinkertaista kuin yhden luokan tai roolimääritteen käyttäminen kaikissa tapauksissa. Oikean laajennettavan ratkaisun saamiseksi, joka tarjoaa taaksepäin yhteensopivuuden ja riittävän joustavuuden, tämänsuuntaisia ratkaisuja kannattaa tutkia. Nimesin tämän osion "Joitakin ajatuksia ratkaisusta", koska hyväksyttävän ratkaisun saavuttamiseksi on tehtävä paljon työtä. Avoimia kysymyksiä ovat muun muassa seuraavat. Sen sijaan, että kiirehtisin vastaamaan näihin kysymyksiin, nostan esiin ongelmat, joihin on puututtava, ja aloitan vuoropuhelun. HTML5:ssä tehtyjen päätösten seuraukset ja vaikutukset ovat liian suuret päätöksille, jotka tehdään ilman hyvää kielitieteen, semantiikan, semiotiikan ja niihin liittyvien alojen ymmärtämistä. Toivon, että on selvää, että pelkkä "uusien elementtien luominen" ei ole ratkaisu HTML:n semanttisen tehon lisäämiseen. Älkäämme kiirehtikö näihin päätöksiin, olemmehan antaneet lapsenlapsillemme tarpeeksi ongelmia ilmastonmuutoksen kanssa. Annetaan heille ainakin paras mahdollinen HTML-koodi. ,
,
, ja niin edelleen, mutta muihin käyttöliittymäelementteihin.
Mutta...
Rakenneelementit: sivun järjestely
sivun otsikkona;
Tekstielementit: sisällön määrittäminen
(järjestämättömille) luetteloille;
(järjestetyille) listoille;
lainauksia varten.
Sisäiset elementit: erilaista tekstiä
Pääsivun otsikko
Tekstitys
Kerran sanottu
Yhteiset elementit
Älä välitä semantiikan kanssa
Rakenteellinen Teksti Pienet kirjaimet
DOCTYPE ja sisällönkuvauskentät sivun otsikossa
Sivun otsikko
Sivuston otsikko
Sivuston otsikko
Sivulla navigointi
Sisältö sivulla
Artikkelin suunnittelu
Artikkelin otsikko
Artikkelin alaotsikko
Sivupalkki tai sarake widgeteillä
Osion tunniste
–
) osoittaaksesi osion aiheen.
Tapahtuma erillään
kaupungit
Seattle
Boston
Minneapolis
Sivuston alatunniste - Alatunniste
Johtopäätös
Laajentuva semantiikka
taaksepäin yhteensopivuus
Huipputason otsikko
Toisen tason otsikko
Kolmannen tason otsikko
Tulevaisuuden yhteensopiva
Muutama ajatus ratkaisusta
Laajennettavuus attribuuttien avulla
Muut artikkelit: