A yw HTML 5 Tagiau Achos Sensitif?

Yr arferion gorau ar gyfer ysgrifennu elfennau HTML 5

Un cwestiwn sydd gan lawer o ddylunwyr gwe newydd yw a yw tagiau HTML 5 yn sensitif achos ai peidio? Yr ateb byr yw - "Na". Nid yw tagiau HTML5 yn achos sensitif, ond nid yw hynny'n golygu na ddylech fod yn llym yn eich ffordd o ysgrifennu eich marc HTML!

Yn ôl i XHTML

Cyn i HTML5 ddod i'r diwydiant , byddai gweithwyr proffesiynol y we yn defnyddio blas o iaith marcio o'r enw XHTML i adeiladu eu tudalennau gwe.

Pan fyddwch yn ysgrifennu XHTML, rhaid i chi ysgrifennu pob tag safonol yn isaf oherwydd bod XHTML yn achos sensitif. Mae hyn yn golygu bod y tag yn tag gwahanol na yn XHTML. Roedd yn rhaid i chi fod yn benodol iawn yn y modd y codoch chi dudalen we XHTML a dim ond defnyddio cymeriadau isaf. Roedd y cydlyniad caeth hwn mewn gwirionedd yn fantais i lawer o ddatblygwyr gwe newydd. Yn hytrach na gallu ysgrifennu marciad gyda chymysgedd o isafswm ac uchafswm, gwyddent fod fformat caeth y mae'n rhaid ei ddilyn. I unrhyw un sy'n torri eu dannedd yn y dyluniad gwe pan oedd XHTML yn boblogaidd, ymddengys y syniad da y gallai marcio fod yn gymysgedd o lythyrau uwch ac isaf yn ymddangos yn anghyffredin a dim ond yn anghywir.

Mae HTML5 yn Cael Loose

Nid oedd y fersiynau o HTML cyn XHTML yn achos-sensitif. Dilynodd HTML5 yn y traddodiad hwnnw ac aeth i ffwrdd o ofynion fformat llym XHTML.

Felly nid yw HTML 5, yn wahanol i XHTML, yn achos-sensitif. Mae hyn yn golygu bod a a yr un tag yn HTML 5. Os yw hyn yn edrych fel anhrefn i chi, rwy'n teimlo eich poen.

Y syniad y tu ôl i HTML5 nad oedd yn sensitif i achos oedd ei gwneud yn haws i weithwyr proffesiynol y we newydd ddysgu'r iaith, ond fel rhywun sy'n dysgu dylunio gwe i fyfyrwyr newydd, gallaf wirioneddol ardystio'r ffaith nad yw hyn yn wir o gwbl.

Gallu rhoi set ddiffiniol o reolau i fyfyrwyr newydd i ddylunio gwe ar y we, fel "bob amser yn ysgrifennu eich HTML fel isafswm", yn eu helpu wrth iddynt geisio dysgu popeth sydd ei angen arnynt i ddysgu bod yn ddylunydd gwe. Mae rhoi rheolau iddynt sy'n rhy hyblyg mewn gwirionedd yn drysu llawer o ddysgwyr yn hytrach na'i gwneud hi'n haws iddyn nhw.

Rwyf wrth fy modd â'r ffaith bod awduron y fanyleb HTML5 yn ceisio ei gwneud hi'n haws i'w ddysgu trwy ei gwneud hi'n fwy hyblyg, ond yn yr achos hwn, rwy'n credu eu bod yn gwneud camgamp.

Confensiwn yn HTML 5 yw Defnyddio Lowercase

Er ei bod yn ddilys i ysgrifennu tagiau gan ddefnyddio unrhyw achos y mae'n well gennych wrth ysgrifennu HTML 5, y confensiwn yw defnyddio pob math isaf ar gyfer tagiau a phriodoleddau. Mae hyn yn rhannol oherwydd bod llawer o ddatblygwyr gwe dyfeisio mwy a fu'n byw trwy ddyddiau XHTML llym wedi cario'r meddygfeydd gorau hynny i HTML5 (a thu hwnt). Nid yw'r gweithwyr proffesiynol ar y we yn gofalu bod cymysgedd o lythrennau uchaf a llythrennau isaf yn ddilys yn HTML5 heddiw, byddant yn cadw at yr hyn maen nhw'n ei wybod, sef llythyrau isaf.

Mae cymaint o wybodaeth dylunio gwe yn dysgu oddi wrth eraill, yn enwedig gan y rhai sy'n fwy profiadol yn y diwydiant. Mae hyn yn golygu y bydd datblygwyr gwe newydd yn adolygu cod gweithwyr proffesiynol tymhorol a gweld pob marc isaf. Os ydynt yn efelychu'r cod hwn, mae hynny'n golygu y byddant hefyd yn ysgrifennu HTML5 ym mhob isaf. Dyma'r hyn sy'n ymddangos yn digwydd heddiw.

Arferion Gorau ar gyfer Llythyrau

Yn fy mhrofiad fy hun, mae'n well gennyf bob amser ddefnyddio llythrennau isaf ar gyfer cod HTML yn ogystal ag ar gyfer enwau ffeiliau. Oherwydd bod rhai gweinyddwyr yn sensitif i achosion o ran enwau ffeiliau (er enghraifft, fe welir "logo.jpg" yn wahanol na "logo.JPG"), os oes gennych lif gwaith lle rydych bob amser yn defnyddio llythrennau llai, does dim angen i chi ofyn cwestiwn lle gallai casio fod yn broblem os ydych chi'n cael problemau fel delweddau ar goll . Os ydych bob amser yn defnyddio llythrennau llai, gallwch chi ostwng hynny fel problem wrth i chi ddadlau materion y safle. Dyma'r llif gwaith yr wyf yn ei ddysgu i'm myfyrwyr ac yr wyf yn ei ddefnyddio yn fy ngwaith dylunio gwe fy hun.

Erthygl wreiddiol gan Jennifer Krynin. Golygwyd gan Jeremy Girard.