Menyelami HTML5
Mengesan Ciri-ciri HTML5: Amat Mudah, Wahai Watson	Apa maksudnya Semua Ini?	Mari Kita Gelarnya Permukaan Lukisan

Apa maksudnya Semua Ini?

Menyelam Masuk

Bab ini akan mengambil sebuah halaman HTML, yang tidak ada apa jua kecacatan, dan memperbaikinya. Ada bahagian yang akan menjadi pendek. Ada yang menjadi lebih panjang. Semua akan menjadi semantik. Ia akan mengagumkan.

Ini laman yang dimaksudkan. Pelajarinya. Hayatinya. Minatinya. Bukanya dengan tab baharu dan jangan pulang ke mari sehinggalah anda memetik "Lihat Sumber" sekurang-kurangnya sekali.

Ini disebut "doctype." Ada sejarah panjang — dan ilmu hitam — di belakang doctype. Semasa mereka membangunkan Internet Explorer 5 untuk Mac, para pembangun di Microsoft terserempak masalah yang mengejutkan. Versi pelayar yang bakal diedarkan mereka memiliki dokongan yang lebih sempurna buat piawai hinggakan halaman-halaman lama tidak dapat dipaparkan dengan betul. Atau, dalam kata lain, halaman-halaman tersebut dipaparkan dengan betul (mengikuti spesifikasi), akan tetapi orang ramai mengharapkan laman tersebut dipaparkan secara tidak betul. Halaman-halaman itu sendiri telah ditulis berdasarkan "keanehan" (quirks) pelayar-pelayar utama masa itu, khususnya Netscape 4 dan Internet Explorer 4. IE5/Mac terlalu maju sehinggakan ia sebenarnya merosakkan sesawang.

Microsoft muncul dengan penyelesaian baharu. Sebelum menampilkan sesuatu halaman, IE5/Mac melihat "doctype," yang secara tipikalnya dijumpai pada baris pertama sumber HTML (sebelum unsur <html>). Halaman-halaman lama (yang bergantung paparannya pada keanehan paparan pelayar lama) selalunya tidak mempunyai doctype langsung. IE5/Mac menampilkan halaman-halaman ini sama seperti yang dilakukan pelayar-pelayar lama. Bagi "menghidupkan" dokongan bagi piawai baharu, pengarang halaman sesawang perlu opt-in ("memilih masuk"), dengan membekalkan doctype yang betul sebelum unsur <html>.

Idea ini merebak dengan cepat, dan tidak lama kemudian, semua pelayar utama memiliki dua mod: quirks mode ("mod aneh" ) dan standards mode ("mod piawai"). Seperti biasa, memandangkan kita bercakap tentang sesawang, keadaan menjadi kelam kabut. Apabila Mozilla cuba mengedarkan versi 1.1 pelayar mereka, mereka mendapati bahawa terdapat laman yang dipaparkan dalam "mod piawai" yang sebenarnya bergantung kepada satu keanehan yang spesifik. Mozilla baru sahaja membetulkan enjin penampilnya untuk menyingkirkan keanehan ini, dan beribu halaman menjadi rosak sekali gus. Maka wujudlah – dan ini bukan rekaan saya – almost standards mode ("mod hampir piawai").

Dalam karyanya yang amat berpengaruh, bertajuk Activating Browser Modes with Doctype ("Menghidupkan Mod Pelayar dengan Doctype"), Henri Sivonen memberikan ringkasan mod-mod yang berbeza:

Quirks Mode

Dalam mod aneh, pelayar melanggar spesifikasi kontemporari format Sesawang dengan tujuan untuk mengelak daripada "merosakkan" laman yang dikarang mengikut amalan yang terdapat pada hujung tahun 1990-an.

Standards Mode

Dalam mod piawai, pelayar-pelayar cuba untuk memberi dokumen yang menuruti spesifikasi paparan yang betul terbatas kepada kebolehan sesuatu pelayar itu. HTML5 menggelar mod ini no quirks mode ("mod tanpa keanehan").

Almost Standards Mode

Firefox, Safari, Chrome, Opera (semenjak 7.5) dan IE8 juga mempunyai mod yang dikenali sebagai Almost Standards mode ("mod Hampir Piawai"), yang melaksanakan pensaizan menegak sel jadual secara tradisional, dan tidak dengan ketat mengikuti spesifikasi CSS2. HTML5 menggelar mod ini limited quirks mode ("mod aneh terbatas").

(Anda seharusnya membaca rencana Henri sepenuhnya, kerana saya hanya meringkaskan penulisan tersebut. Mahupun dengan IE5/Mac, terdapat beberapa doctype lama yang tidak diambil kira bagi tujuan memilih masuk dokongan piawai. Dengan peredaran masa, senarai keanehan bertambah, dan begitu juga senarai doctype yang mencetuskan "mod aneh". Kali terakhir saya cuba mengiranya, terdapat lima doctype yang mencetuskan almost standards mode, dan 73 yang mencetuskan quirks mode. Namun berkemungkinan ada yang saya terlepas pandang, dan saya tidak mahu bercakap tentang perkara gila yang dilakukan Internet Explorer 8 untuk menukar mod – empat — empat! — mod paparan yang berbeza. Ini carta alir. Bunuhnya. Bunuhnya dengan api).

Baiklah. di mana kita tadi? Oh ya, bersama doctype:

<!DOCTYPE html
          PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Ini adalah satu daripada 15 doctype yang mencetuskan standards mode dalam kesemua pelayar moden. Tidak ada apa celanya. Jika anda suka, anda boleh menyimpannya. Atau anda boleh menukarnya kepada doctype HTML5, yang lebih pendek dan manis dan yang juga akan mencetuskan standards mode dengan semua pelayar moden.

Ini doctype HTML5:

<!DOCTYPE html>

Itu saja. Hanya 15 aksara. Amat senang, anda boleh menaipnya secara insani tanpa membuat kesilapan.

Unsur Akar

Sebuah halaman HTML merupakan sebuah siri unsur-unsur yang bersarang. struktur keseluruhan halaman menyerupai sebatang pokok. Beberapa unsur merupakan "saudara", sama seperti ranting yang tumbuh dari batang pokok. Beberapa unsur pula merupakan "anak" unsur lain, sama seperti sebuah ranting kecil yang tumbuh daripada ranting yang lebih besar. (Cara terbalik pun betul; sesuatu unsur yang mengandungi unsur-unsur lain digelar nod "induk" unsur-unsur anaknya, dan "moyang" cucunya). Unsur yang tidak mempunyai anak digelar nod "daun". Unsur yang paling luar, yang merupakan moyang kepada kesemua unsur lain yang terkandung dalam halaman, digelar "unsur akar" ataupun root element Unsur akar laman HTML senantiasa <html>.

Dalam laman contoh, unsur akar kelihatan sedemikian:

<html xmlns="http://www.w3.org/1999/xhtml"
      lang="en"
      xml:lang="en">

Tidak ada cela dengan penanda ini. sekali lagi, jika anda suka, anda boleh menyimpannya. Ia adalah HTML5 sah. Akan tetapi beberapa bahagian tidak diperlukan dengan HTML5 dan anda dapat mengurangkan bait dengan membuang bahagian-bahagian itu.

Perkara pertama yang akan dibincangkan ialah atribut "xmlns". Ini peninggalan XHTML 1.0. Ia mengatakan bahawa unsur dalam laman ini terletak di dalam ruang nama XHTML, "http://www.w3.org/1999/xhtml". Tetapi unsur-unsur HTML5 senantiasa berada di dalam ruang nama tersebut, justeru anda tidak perlu mengisytiharnya secara tersurat. Laman HTML5 akan bekerja macam biasa dengan semua pelayar, sama ada atribut ini hadir atau tidak.

Membuang atribut xmlns meninggalkan kita dengan unsur akar ini:

<html lang="en" xml:lang="en">

Dua atribut ini, lang dan xml:lang, memberi definisi bahasa halaman HTML ini. ("en" ialah untuk bahasa Inggeris. Tidak menulis dalam bahasa Inggeris? Cari kod bahasa anda.) Mengapa terdapat dua atribut buat benda yang sama? Sekali lagi, ini ialah peninggalan XHTML. Hanya atribut lang yang berkesan dengan HTML5. Anda boleh simpan atribut xml:lang jika anda suka tetapi, jika anda berbuat demikian, anda perlu pastikan yang ia mengandungi nilai yang sama dengan atribut lang.

Bagi memudahkan perpindahan ke dan daripada XHTML, para pengarang boleh menetapkan sebuah atribut tanpa ruang nama dan awalan, dan dengan nama lokal harfiah "xml:lang" pada unsur HTML dalam dokumen HTML, akan tetapi hanya perlu ditetapkan sekiranya atribut "lang" tanpa ruang nama juga ditetapkan, dan kedua-dua atribut perlu memiliki nilai yang sama apabila dibandingkan cara yang tidak mengambil kira kes ASCII. Atribut yang tidak memiliki ruang nama dan dengan nama lokal harfiah "xml:lang" tidak memiliki kesan terhadap pemprosesan bahasa.

Anda sudah bersedia untuk mengabaikannya? OK, lepaskan saja. Pergi, pergi... hilang! Dan sekarang kita tinggal dengan unsur akar:

<html lang="en">

Itu sahaja yang perlu perkatakan tentang itu.

Unsur <head>

Anak pertama unsur akar lazimnya unsur <head>. Unsur <head> mengandungi metadata – maklumat berkaitan halaman, bukan badan halaman itu sendiri. (Badan halaman, dan ini tidak mengejutkan, terkandung dalam unsur <body>). Dengan sendirinya, unsur <head> itu sendiri agak membosankan, dan tidak berubah dalam cara yang menarik dalam HTML5. Perkara yang penting terkandung dalam unsur <head>. Dan untuk itu, kita kalih semula kepada laman contoh kita:

<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>Weblog saya</title>
  <link rel="stylesheet" type="text/css" href="style-original.css" />
  <link rel="alternate" type="application/atom+xml"
                        title="Suapan Weblog saya"
                        href="/feed/" />
  <link rel="search" type="application/opensearchdescription+xml"
                        title="Gelintar Weblog saya"
                        href="opensearch.xml"  />
  <link rel="shortcut icon" href="/favicon.ico" />
</head>

Mula-mula sekali: unsur <meta>.

Pengekodan Aksara

Apabila kita berfikir tentang "teks", berkemungkinan besar kita membayangkan "aksara dan simbol yang saya lihat pada skrin komputer saya." Akan tetapi komputer tidak mengendali aksara dan simbol; komputer mengendali bit dan bait. Setiap cebisan teks yang pernah kita lihat pada skrin komputer sebenarnya distor dalam pengekodan aksara tertentu. Terdapat beratus pengekodan aksara, sebahagiannya dioptimumkan untuk bahasa tertentu seperti bahasa Rusia, atau Cina atau Inggeris, dan yang lain yang boleh digunakan untuk pelbagai bahasa. Secara kasar, pengekodan aksara menyediakan pemetaan antara benda yang kita lihat pada skrin dan benda yang sebenarnya distor oleh komputer dalam ingatan dan dalam cakera.

Sebenarnya, ia lebih rumit daripada itu. Aksara yang sama mungkin kelihatan dalam banyak pengekodan, akan tetapi setiap pengekodan mungkin menggunakan jujukan bait berbeza untuk menstor aksara itu dalam ingatan atau cakera. Jadi, kita boleh pengekodan aksara sebagai sejenis kunci nyahsulit buat teks. Apabila seseorang itu memberi kita jujukan bait dan mendakwa ia "teks", kita perlu tahu apa jenis pengekodan aksara yang digunakan agar kita dapat menyahsulit bait ke dalam aksara dan memaparnya (atau memproses, atau melakukan tindakan lain).

Jadi, bagaimana pelayar menetapkan pengekodan aksara strim bait yang dikirim pelayan sesawang? Terima kasih kerana bertanya. Jika anda biasa dengan pengepala HTTP, akan mungkin telah terserempak dengan pengepala seperti berikut:

Content-Type: text/html; charset="utf-8"

Secara ringkas, ini menyatakan bahawa pelayan sesawang berkira bahawa ia mengirimkan kita sebuah dokumen HTML, dan bahawa ia fikir yang dokumen itu menggunakan pengekodan aksara UTF-8. Malangnya, dalam sup hebat Sesawang Sejagat, tidak ramai pengarang yang sebenarnya mengawal pelayan HTTP mereka. Bayangkan Blogger: kandungan disediakan oleh individu, tetapi pelayan dikendali Google. Jadi, HTML 4 menyediakan satu cara untuk menetapkan pengekodan aksara dalam dokumen HTML itu sendiri. Anda mungkin juga pernah melihat ini:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Secara ringkas, ini mengatakan bahawa pengarang sesawang itu berfikir yang beliau telah mengarang sebuah dokumen HTML mengguna pengekodan aksara UTF-8.

Kedua-dua teknik ini masih bekerja dalam HTML5. Pengepala HTTP ialah kaedah yang diutamakan, dan ia mengatasi tag <meta> sekiranya tag itu hadir. Tetapi tidak semua orang dapat melihat pengepala HTTP, jadi tag <meta> masih kekal. Dan sebenarnya ia bertambah lebih mudah dengan HTML5. Sekarang ia kelihatan seperti ini:

<meta charset="utf-8" />

Ini bekerja untuk semua pelayar. Bagaimana kependekan sintaks ini boleh wujud? Ini penjelasan terbaik yang dapat saya cari:

Rasional buat kombinasi atribut <meta charset> ialah UA (user agent, agen pengguna) sudahpun mengimplementasinya, kerana orang awam sering kali meninggalkan tanda petikan, seperti berikut:

<META HTTP-EQUIV="Content-Type" CONTENT="text/html;" charset="ISO-8859-1">

Malah, terdapat beberapa ujian <meta charset> sekiranya anda tidak percaya yang pelayar sedang melakukan ini.

Tanya Profesor Penanda

S: Saya tidak pernah mengguna aksara pelik. Masihkah saya perlu menyatakan pengekodan aksara?

J: Ya! Anda perlu senantiasa menyatakan pengekodan aksara dalam setiap laman HTML yang anda karang. Tidak menetapkan pengekodan dapat menimbulkan kelemahan keselamatan.

Sebagai kesimpulan: pengekodan aksara itu rumit, dan tidak dibantu oleh perisian yang tidak ditulis dengan baik oleh pengarang jenis salin-dan-tampal selama berdekad-dekad. Kita sepatutnya menetapkan satu jenis pengekodan aksara pada setiap dokumen HTML; jika tidak perkara yang tidak diingini akan berlaku. Kita dapat melakukannya dengan pengepala HTTP Content-Type, deklarasi <meta http-equiv>, atau dengan deklarasi <meta charset> yang lebih pendek. Sila lakukannya. Sesawang mengucapkan banyak terima kasih kepada.

Rakan-rakan & Perhubungan (Pautan)

Pautan biasa (<a href>) hanya merujuk kepada laman yang lain. Perhubungan pautan ialah satu cara bagi menerangkan mengapa kita merujuk kepada laman itu. Perhubungan itu melengkapkan ayat "Saya merujuk kepada laman itu kerana..."

...ia sebuah lembaran gaya yang mengandungi peraturan yang harus dikenakan pelayar anda pada dokumen ini.
...ia sebuah suapan yang mengandungi kandungan yang sama dengan halaman ini, akan tetapi dalam format yang piawai dan dapat dilanggani.
...ia terjemahan halaman ini dalam bahasa lain.
...ia memuatkan kandungan yang sama dengan halaman ini tetapi dalam format PDF.
...ia bab berikutan bab ini dalam buku dalam talian dan bab ini juga sebahagian daripada buku itu.

Dan seterusnya. HTML5 membahagikan perhubungan atau pertalian pautan ke dalam dua kategori^[1]:

Dua kategori pautan dapat diwujudkan dengan mengguna unsur link. Pautan kepada sumber luar ialah pautan yang digunakan untuk menyokong dokumen, dan pautan hiperpautan ialah pautan kepada dokumen-dokumen lain ...

Kelakuan pautan kepada sumber luar bergantung pada pertalian sebenar, seperti ditetapkan dalam jenis pautan berkaitan.

Daripada contoh-contoh yang saya kemukakan, hanya yang pertama (rel="stylesheet") merupakan pautan kepada sumber luar. Yang lain adalah hiperpautan kepada dokumen-dokumen lain. Anda dapat mengikuti pautan-pautan tersebut, atau mungkin tidak, akan tetapi pautan tersebut tidak perlu hadir bagi membolehkan anda melihat halaman semasa.

Lebih sering lagi, pertalian pautan dijumpai pada unsur <link> dalam <head> sesuatu laman. Sesetengah pertalian pautan dapat juga digunakan pada unsur <a>, tetapi ini jarang berlaku mahupun bila dibenarkan. HTML5 juga membenarkan pertalian pada unsur <area> , tapi lagi jarang (HTML 4 tidak membenarkan atribut rel pada unsur <area> ). Lihat carta penuh pertalian pautan bagi mendapatkan penjelasan di aman anda boleh menggunakan nilai rel spesifik^[2]

Tanya Profesor Penanda

S: Can I make up my own link relations?

J: There seems to be an infinite supply of ideas for new link relations. In an attempt to prevent people from just making stuff up, the microformats community maintains a registry of proposed rel values and the HTML specification defines the process for getting them accepted.

rel = stylesheet

Let’s look at the first link relation in our example page:

This is the most frequently used link relation in the world (literally). <link rel="stylesheet"> is for pointing to CSS rules that are stored in a separate file. One small optimization you can make in HTML5 is to drop the type attribute. There’s only one stylesheet language for the web, CSS, so that’s the default value for the type attribute. This works in all browsers. (I suppose someone could invent a new stylesheet language someday, but if that happens, just add the type attribute back.)

rel = alternate

Continuing with our example page:

      type="application/atom+xml"
      title="My Weblog feed"
      href="/feed/" />

This link relation is also quite common. <link rel="alternate">, combined with either the RSS or Atom media type in the type attribute, enables something called “feed autodiscovery.” It allows syndicated feed readers (like Google Reader) to discover that a site has a news feed of the latest articles. Some browsers also support feed autodiscovery by displaying a special icon next to the URL. (Unlike with rel="stylesheet", the type attribute matters here. Don’t drop it!)

The rel="alternate" link relation has always been a strange hybrid of use cases, even in HTML 4. In HTML5, its definition has been clarified and extended to more accurately describe existing web content. As you just saw, using rel="alternate" in conjunction with type=application/atom+xml indicates an Atom feed for the current page. But you can also use rel="alternate" in conjunction with other type attributes to indicate the same content in another format, like PDF.

HTML5 also puts to rest a long-standing confusion about how to link to translations of documents. HTML 4 says to use the lang attribute in conjunction with rel="alternate" to specify the language of the linked document, but this is incorrect. The HTML 4 Errata document lists four outright errors in the HTML 4 specification. One of these outright errors is how to specify the language of a document linked with rel="alternate" The correct way, described in the HTML 4 Errata and now in HTML5, is to use the hreflang attribute. Unfortunately, these errata were never re-integrated into the HTML 4 spec, because no one in the W3C HTML Working Group was working on HTML anymore. Other Link Relations in HTML5

rel="author" is used to link to information about the author of the page. This can be a mailto: address, though it doesn’t have to be. It could simply link to a contact form or “about the author” page.

girl feeding birds

HTML 4 defined rel="start", rel="prev", and rel="next" to define relations between pages that are part of a series (like chapters of a book, or even posts on a blog). The only one that was ever used correctly was rel="next". People used rel="previous" instead of rel="prev"; they used rel="begin" and rel="first" instead of rel="start"; they used rel="end" instead of rel="last".

Oh, and — all by themselves — they made up rel="up" to point to a “parent” page. The best way to think of rel="up" is to look at your breadcrumb navigation (or at least imagine it). Your home page is probably the first page in your breadcrumbs, and the current page is at the tail end. rel="up" points to the next-to-last page in the breadcrumbs.

HTML5 includes rel="next" and rel="prev", just like HTML 4, and supports rel="previous" for backward compatibility. The specification once had rel="first", rel="last", and rel="up", too. However, “based on the lack of interest from implementors and users” the HTML Working Group decided to drop these values from the specification.

rel="icon" is the second most popular link relation, after rel="stylesheet". It is usually found together with shortcut, like so:

All major browsers support this usage to associate a small icon with the page. Usually it’s displayed in the browser’s location bar next to the URL, or in the browser tab, or both.

Also new in HTML5: the sizes attribute can be used in conjunction with the icon relationship to indicate the size of the referenced icon.

rel="license" was invented by the microformats community. It “indicates that the referenced document provides the copyright license terms under which the current document is provided.”

rel="nofollow" “indicates that the link is not endorsed by the original author or publisher of the page, or that the link to the referenced document was included primarily because of a commercial relationship between people affiliated with the two pages.” It was invented by Google and standardized within the microformats community. WordPress adds rel="nofollow" to links added by commenters. The thinking was that if “nofollow” links did not pass on PageRank, spammers would give up trying to post spam comments on weblogs. That didn’t happen, but rel="nofollow" persists.

rel="noreferrer" “indicates that no referrer information is to be leaked when following the link.” WebKit supports rel="noreferrer" so it works on Google Chome and Safari (and hopefully on other WebKit-based browsers). [rel="noreferrer" test case]

dog on chair

rel="prefetch" “indicates that preemptively fetching and caching the specified resource is likely to be beneficial, as it is highly likely that the user will require this resource.” Search engines sometimes add <link rel="prefetch" href="URL of top search result"> to the search results page if they feel that the top result is wildly more popular than any other. For example: using Firefox, search Google for CNN, view the page source, and search for the keyword prefetch. Mozilla Firefox is the only current browser that supports rel="prefetch".

rel="search" “indicates that the referenced document provides an interface specifically for searching the document and its related resources.” Specifically, if you want rel="search" to do anything useful, it should point to an OpenSearch document that describes how a browser could construct a URL to search the current site for a given keyword. OpenSearch (and rel="search" links that point to OpenSearch description documents) has been supported in Internet Explorer since version 7, Mozilla Firefox since version 2, and Google Chrome.

rel="tag" “indicates that the tag that the referenced document represents applies to the current document.” Marking up “tags” (category keywords) with the rel attribute was invented by Technorati to help them categorize blog posts. Early blogs and tutorials thus referred to them as “Technorati tags.” (You read that right: a commercial company convinced the entire world to add metadata that made the company’s job easier. Nice work if you can get it!) The syntax was later standardized within the microformats community, where it was simply called rel="tag". Most blogging systems that allow associating categories, keywords, or tags with individual posts will mark them up with rel="tag" links. Browsers do not do anything special with them; they’re really designed for search engines to use as a signal of what the page is about.

New Semantic Elements in HTML5

HTML5 is not just about making existing markup shorter (although it does a fair amount of that). It also defines new semantic elements.

</footer>

Nota kaki

   In association with Google Press, O’Reilly is distributing this book in a variety of formats, including paper, ePub, Mobi, and DRM-free PDF. The paid edition is called “HTML5: Up & Running,” and it is available now. This chapter is included in the paid edition.

   If you liked this chapter and want to show your appreciation, you can buy “HTML5: Up & Running” with this affiliate link or buy an electronic edition directly from O’Reilly. You’ll get a book, and I’ll get a buck. I do not currently accept direct donations.

Copyright MMIX–MMXI Mark Pilgrim

[1] Lihat whatwg.org – pertalian pautan

[2] whatwg.org –Jenis pautan

[1]

[2]