ეს არის რედაქტირებული ნაწყვეტი მე-3 თავდან სიმართლე HTML5-ის შესახებ ლუკ სტივენსის მიერ.

ვებ დიზაინერების ერთ-ერთი ყველაზე გავრცელებული დავალებაა გვერდის სტრუქტურის მონიშვნა, რომელიც ჩვეულებრივ შედგება სათაურის, ქვედა კოლონტიტულის, ნავიგაციის, გვერდითი ზოლისა და შინაარსის ზონისგან. ეს არის ისეთი რამ, რისი გაკეთებაც, ალბათ, შეგიძლიათ გააკეთოთ თვალდახუჭული და ხელბორკილებით მიბმული თქვენს სკამზე ხუთი წუთის განმავლობაში დატრიალების შემდეგ.

HTML5 წარმოგიდგენთ ახალ ელემენტებს, რომლებიც დაგვეხმარება განვსაზღვროთ მოცემული ვებ გვერდის სტრუქტურა, მაგ, ,, , და .

ჩვენ არ უნდა გამოვიყენოთ ისინი. ისინი ახირებულად შექმნეს (ალბათ) ერთმა ბიჭმა 2004 წელს - და როგორც ჩანს, მასაც კი დაავიწყდა მათი მიზანი.

თუ ეს ყველაფერია, რაც თქვენ უნდა იცოდეთ, შესანიშნავია. განაგრძეთ div-ების გამოყენება მნიშვნელოვანი კლასის და ID სახელებით და შესაბამისი - სათაურები. ისინი იმოქმედებენ სამუდამოდ (მეტ-ნაკლებად) და თქვენ არაფერს გამოტოვებთ.

თუმცა, მე გირჩევთ გამოიყენოთ ზოგიერთი არა-HTML5 ფუნქცია დოკუმენტების მარკირებისას, როგორიცაა ARIA ატრიბუტები უსინათლო და მხედველობის დაქვეითებული მომხმარებლებისთვის და მიკრომონაცემების სქემები (როდესაც საჭიროა) საძიებო სისტემისთვის შედეგები.

მიუხედავად ამისა, ჩვენ სიღრმისეულად განვიხილავთ ამ ახალ ელემენტებს, რადგან ყველა მათ არასწორად იღებს. და ჩვენ დავაფიქსირებთ ჩანაწერს იმის შესახებ, თუ როგორ იპოვეს მათ გზა სპეციფიკაში და მათ რეალურ დანიშნულებაში, რაც გულისხმობს თქვენი გვერდების სტრუქტურირების რადიკალურად განსხვავებულ გზას.

01. ცოტა ტკივილის გემო

აქ არის მხოლოდ რამდენიმე პრობლემა, რომელიც ამ ახალ სტრუქტურულ ელემენტებს აჩენს:

• ისინი აძლევენ ტერმინებს, რომლებსაც ვებ დიზაინერები უკვე იყენებენ (როგორიცაა სათაური და ქვედა კოლონტიტული) ახალ გამოყენებას, ხოლო აცხადებენ, რომ უბრალოდ აკეთებენ იმას, რასაც უკვე აკეთებენ ვებ დიზაინერები.
• ისინი წარმოადგენენ დოკუმენტების სტრუქტურირების ახალ მეთოდს, რომელიც ბუნდოვანი, რთული და არასაჭიროა.
• ისინი სერიოზულად აზიანებენ ხელმისაწვდომობას ზოგიერთი მომხმარებლისთვის (განსაკუთრებით მათთვის, ვინც იყენებს IE6, IE7 და თუნდაც IE8 გამორთული JavaScript-ით).
• ისინი წარმოადგენენ ფართო, გაურკვეველ, ცუდად განსაზღვრულ გამოყენების შემთხვევებს, რაც ართულებს ვებ სტანდარტების სწავლას (და ართულებს სწავლებას).

ეს არის სერიოზული პრობლემები, რომლებიც აზიანებს და არა ეხმარება ვებ სტანდარტებს. მარკირება უნდა იყოს მსუბუქი, ადვილად შესასწავლი და ადვილად გამოსაყენებელი. არ უნდა მოითხოვდეს გონებრივი ტანვარჯიშის ცდა და დამუშავება, სად გამოვიყენოთ.

მაგრამ ამ ახალმა სტრუქტურულმა ტეგებმა შექმნა უცნაური, კვაზირელიგიური გამოცდილება, სადაც თქვენ უნდა გაიაროთ კონსულტაცია მაღალ დონეზე მღვდლები (HTML5 გურუები) გაურკვეველი რელიგიური ტექსტების ინტერპრეტაციისთვის (HTML5 სპეციფიკაცია) მხოლოდ უბრალო ქსელის აღსანიშნავად გვერდი.

"მაგრამ, მაგრამ... ეს ელემენტები არის ოფიციალურ HTML5 სპეციფიკაციაში! ნამდვილად უნდა არსებობდეს მათთვის კარგი მიზეზი? ”

წაიკითხეთ...

02. საიდან გაჩნდა ეს ელემენტები?

ვიქტორინის შეკითხვა: როგორ დაემატა ეს ელემენტები HTML5 სპეციფიკაციას?

1. ექსპერტებმა განიხილეს გამოყენების სხვადასხვა შემთხვევები, შეაფასეს სხვადასხვა ვარიანტები და ალტერნატივები და ფართო კონსულტაციებისა და ფრთხილად განხილვის შემდეგ შეიტანეს ყველაზე მნიშვნელოვანი.
2. ვებ დიზაინერების და HTML ავტორების საზოგადოებამ (როგორიცაა მე და შენ) ტიროდა გარკვეული ელემენტების გასააქტიურებლად განსაკუთრებული ფუნქციონირება და დიდი დისკუსიის შემდეგ საზოგადოებამ გამოაქვეყნა საჭიროების მოკლე სია ელემენტები.
3. იქნა მიღებული მეცნიერული, კვლევაზე დაფუძნებული მიდგომა, სადაც მარკირების ნიმუშები შეისწავლეს „ველურ ბუნებაში“ და კოდირებულ იქნა ახალ ელემენტებად.
4. ზოგიერთმა მარკირებამ ჩათვალა, რომ კარგი იდეა იქნებოდა და 7+ წლის წინ ჩააგდო სპეციფიკაციაში.

და პასუხი არის… (4).

”მაგრამ მე წავიკითხე [ჩადეთ თქვენი არჩევანის HTML5 წიგნი აქ], რომ ეს უფრო პასუხს ჰგავდა (3). WHATWG-მ შეისწავლა პირადობის მოწმობისა და კლასის სახელების რეალურ სამყაროში გამოყენება და ასე გაჩნდა ისინი!”

ჩვენ ამას მივაღწევთ.

მაინტერესებდა ვინ დაამატა ეს ელემენტები, როდის დაამატა და რატომ. ასე რომ, მე დავუსვი ეს კითხვები HTML5 სპეციფიკაციის რედაქტორს იან ჰიკსონს და აქ არის მისი პასუხი (გამრავლებული ნებართვით):

”მე და WHATWG-ის სხვა კონტრიბუტორებმა [დავამატე ისინი] 2004 წელს, რადგან ისინი აშკარა ელემენტები იყო დასამატებლად მას შემდეგ, რაც დავინახეთ, თუ როგორ იყენებდნენ ავტორები HTML4. ჩვენ მოგვიანებით (2005 წლის ბოლოს, 2006 წლის დასაწყისში) ჩავატარეთ ობიექტური კვლევა, რათა გაგვერკვია, რომელია HTML 10 საუკეთესო კლასი. იყო და აღმოჩნდა, რომ ისინი ძირითადად ზუსტად ემთხვეოდნენ ჩვენს მიერ დამატებულ ელემენტებს, რაც იყო მოსახერხებელი."

თქვენ შესაძლოა წაიკითხეთ ამ „ობიექტური კვლევის“ შესახებ სხვა HTML5 წიგნებში, HTML5-ზე საუბრებში ან ამ ახალი ელემენტების შესახებ ბლოგ პოსტებში. მაგრამ თითქმის ყველა აფუჭებს ისტორიას. ზოგჯერ ამბობენ, რომ კვლევა პირველი იყო - ასე არ მოხდა. ზოგჯერ უბრალოდ იგულისხმება, რომ კვლევა პირველი იყო, რაც მაინც გამოტოვების ცოდვაა.

(ფაქტობრივად, მიხედვით სადავო კვლევა, მთავარი დასკვნა იყო ის, რომ სინჯირებული მილიარდი გვერდის დაახლოებით 90 პროცენტს საერთოდ არ ჰქონდა კლასები. თუ ჰიქსონი და WHATWG ნამდვილად მიჰყვებოდნენ აქ კვლევას, ისინი საერთოდ გააუქმებდნენ კლასებს!)

ასე რომ, თუ ეს ელემენტები არ წარმოიშვა კვლევის შედეგად, საიდან გაჩნდა ისინი?

WHATWG საფოსტო სიის (საბედნიეროდ საჯარო) ბნელი ჩაღრმავების შესწავლისას აღმოვაჩინე, რომ ჰიქსონმა პირველად ახსენა ეს ელემენტები 2004 წლის ნოემბერში, როდესაც მან განიხილა ბლოკის დონის ელემენტები, რომლებიც ჩამოთვლილია მის დაფაზე.

იმავე კვირაში მან თქვა: ”რაც მე ვფიქრობ, რომ გავაკეთო არის სექციის ელემენტების [დამატება], რაც] იქნება: ”. (შეგიძლიათ ნახოთ სრული ელ.წერილი აქ.)

რა თქმა უნდა, სადღაც გზაზე გახდა, და გახდა .

ასე რომ, ეს ახალი, ძირითადი სტრუქტურული ელემენტები, რომელთა ამოცნობას ყველა ცდილობს, სავარაუდოდ, შედიოდა, რადგან ჰიკსონმა ჩაწერა ისინი თავის დაფაზე 2004 წელს. ისინი რეალურად ემსახურებიან ბევრად უფრო ფართო მიზანს "სექციისთვის" (რასაც ჩვენ მალე შევეხებით). მაგრამ ღირს იმის გარკვევა, თუ როგორ მოხვდნენ ისინი სპეციფიკაში და რამდენად თვითნებური არიან ისინი.

XHTML 2.0 აბსურდულად ამბიციური იყო. HTML5-ში ჩვენ სანაცვლოდ ვიღებთ რამდენიმე სემანტიკურ ელემენტს, რომელიც რედაქტორმა დახატა თეთრ დაფაზე წლების წინ სურვილისამებრ, იმდროინდელი WHATWG-ის რამდენიმე თანამემამულე წევრის შეყვანით.

03. ვის აინტერესებს?

”კარგი, ვის აინტერესებს?” შეიძლება იფიქროთ. ”თუ კვლევამ საბოლოოდ მხარი დაუჭირა ამ ელემენტების გამოყენებას, მაშინ რა არის დიდი საქმე?”

პრობლემა ის არის, რომ ჰიქსონი, ჩემი აზრით, ცოტა თავხედი იყო, როცა თქვა, რომ ეს ახალი ელემენტები „ზუსტად ემთხვევა იმ ელემენტებს, რომლებიც ჩვენ... დავამატეთ“. მიუხედავად იმისა, რომ ისინი იზიარებენ იმავე სახელს, როგორც ჩვეულებრივ გამოყენებულ ელემენტებს, სპეციფიკაცია აღწერს მათ გამოყენებას ძალიან განსხვავებულად, ვიდრე ვებ დიზაინერები და ავტორები იცნობენ. და სტანდარტისთვის, რომლებიც ამ ვებ დიზაინერებმა და ავტორებმა უნდა გამოიყენონ, ეს დიდი პრობლემაა.

რა ხდება, როდესაც თქვენ იღებთ ტერმინებს, რომლებსაც ადამიანები იყენებენ, ხელახლა განსაზღვრეთ, თუ როგორ უნდა გამოიყენონ ისინი (და კიდევ მიეცით მათ მრავალჯერადი იყენებს), და შემდეგ უთხარით იმავე ადამიანებს, რომ არ ინერვიულონ, რადგან პირობები ზუსტად ისაა, რაც უკვე არის გამოყენებით? თქვენ მათ ცალმხრივ მოგზაურობთ დაბნეულ ქალაქში.

04. წინააღმდეგობა HTML5-ის ახალი ელემენტების გულში

HTML5, სავარაუდოდ, არის იმის კოდიფიკაცია, რასაც ჩვენ უკვე ვაკეთებთ, ან „ძროხების დაგება“. რაც შეეხება ამ ახალ ტეგებს და ძირითადი შაბლონის აღნიშვნას, ისინი გთავაზობენ, რომ უბრალოდ შეცვალოთ თქვენი მიმდინარე სტრუქტურული ტეგები ახალი ტეგებით (მაგალითად, ჩანაცვლება თან ), და თქვენ დაასრულეთ.

ეს, რა თქმა უნდა, იყო 2007 წლის დეკემბრის ALA სტატიაში 'HTML 5-ის გადახედვა'და ეს იდეა მას შემდეგ განმეორდა წიგნებსა და ბლოგ პოსტებში, როგორც წესი, ისეთი გრაფიკით, როგორიც აქ არის:

ახალი ელემენტების შეცვლა ჩვენს ძველ დივში, რა თქმა უნდა, ადვილია, არა? ლამაზი, სუფთა ელემენტები, რომლებიც ცვლის შემთხვევით დივ-ს, რა მშვენიერია!

სამწუხაროდ, ამ იდეაში რამდენიმე პრობლემაა:

• ძალიან ცოტა ელემენტები. არ არის საკმარისი ახალი ელემენტები გონივრული 1:1 ჩანაცვლებისთვის. დამიჯერეთ, დივზები არსად მიდიან. ასე რომ, თუ გესმით ვინმეს ნათქვამი: „საბოლოოდ, მე შემიძლია მოვიშორო ჩემი არასემანტიკური დივები!“, თქვენ გაქვთ ჩემი ნებართვა ნერფის თოფით ქუდი უკანალში ამოიღოთ.
• Არ უდრის. მიუხედავად იმისა, რომ ელემენტები ხშირად წარმოდგენილია, როგორც თანაბარი, ისინი ასე არ არიან. როდესაც "სექციური" ელემენტები (,, და ) შეიძლება იგივე მუშაობდეს, და ელემენტები განკუთვნილია განყოფილების ელემენტების შიგნით მუშაობისთვის. ამან შეიძლება დიდი განსხვავება მოახდინოს (როგორც მოკლედ დავინახავთ დოკუმენტის მონახაზებით), მაგრამ თუ ამ ელემენტების შესახებ დისკუსიების უმეტესობას მიჰყვებოდით, ვერასოდეს გაიგებთ.
• არა შემცვლელი. როდესაც HTML5 სპეციფიკაციას იკვლევთ, აღმოაჩენთ, რომ ეს ტეგები, როგორც აღწერილია სპეციფიკაციაში, ნამდვილად არ არის გამიზნული არსებული ტეგების 1:1 ჩანაცვლება. ისინი რეალურად განკუთვნილია გამოყენებული იქნას დოკუმენტის მონახაზის ახალი ფორმის შესაქმნელად. ახლა დოკუმენტი? ჩვენ ამას შემდეგში შევისწავლით.

ამ ელემენტებს სხვა პრობლემები აქვთ (ისინი არაფერს ამატებენ სემანტიკისთვის ან საძიებო სისტემებისთვის), მაგრამ მათზე მოგვიანებით ვისაუბრებთ, როდესაც მიზნად დავისახავთ იმ ორ ზომბების მითს, რომლებიც უბრალოდ არ მოკვდებიან. ჩვენ ასევე გავიგებთ, რას ნიშნავს სინამდვილეში „სემანტიკა“ მარკირებაში და რა სურთ საძიებო სისტემებს.

05. დახაზეთ რა ახლა?

თუ თქვენ ცდილობთ გაიგოთ HTML5-ის ახალი სტრუქტურული ელემენტები დოკუმენტის კონტურების გაგების გარეშე, თქვენ იფიქრებთ, რომ ისინი თვითნებური, უცნაურად დასახელებული ელემენტების ერთობლიობაა დამაბნეველი გამოყენების შემთხვევებით.

თუმცა, როგორც კი გაიგებთ დოკუმენტის კონტურებს, დაინახავთ, რომ ისინი სინამდვილეში თვითნებური, უცნაურად დასახელებული არიან. ელემენტების თაიგული დამაბნეველი გამოყენების შემთხვევებით, რომლებსაც ასევე აქვთ საეჭვო ყოვლისმომცველი მიზანი ღირებულება.

მართალია, ეს არის ეზოთერული რამ. მოითმინეთ და დაინახავთ, თუ როგორ ცდილობს HTML5 რადიკალურად ახალი გზით შეასრულოს ისეთი ფუნდამენტური რამ, როგორც ვებ გვერდის სტრუქტურირება. ეს არ არის იმდენად ძროხების დაგება, რამდენადაც ახალი მსხვილფეხა რქოსანი გზატკეცილის მშენებლობა.

06. რა არის მონახაზი და რატომ უნდა მაინტერესებდეს?

მონახაზი არის დოკუმენტის ერთგვარი იერარქიული წარმოდგენა.

ჩვენ რეალურად ვაკეთებთ მონახაზს, როდესაც ვნიშნავთ დოკუმენტს და ვიყენებთ სათაურის ელემენტებს. ასე რომ, მაშინაც კი, თუ არასოდეს გსმენიათ „დოკუმენტის მონახაზის“ შესახებ, დიდია შანსი, რომ უკვე შეადგინეთ. უცნაურია, ხო?

მიზეზი, რის გამოც მათ შესახებ არასდროს გვესმის, არის ის, რომ ვებ დიზაინერებს არასდროს უწევთ მათი გამოყენება. მათ ძირითადად იყენებენ უსინათლო მომხმარებლები, როგორც ნავიგაციის ძირითადი საშუალება. რაც შეეხება ხელმისაწვდომობას, კონტურები დიდი საქმეა. ასე რომ, საუკეთესო, რაც შეგვიძლია გავაკეთოთ, რათა დავეხმაროთ უსინათლო და მხედველობის დაქვეითებულ მომხმარებლებს დოკუმენტებში ნავიგაციაში, არის კარგი სათაურის სტრუქტურის უზრუნველყოფა ვებ სტანდარტების გამოყენებისას.

HTML5 ცდილობს რადიკალურად შეცვალოს, თუ როგორ ვაკეთებთ ამ მონახაზებს… და შეინარჩუნოს არსებული გზა (კარგი, ერთგვარი). კონტურებისადმი ეს ახალი მიდგომა არის ახალი HTML5 ტეგების არსებობის მიზეზი და რატომ ფიქრობდნენ ჰიქსონი და WHATWG თავიდან „სექციური ელემენტების“ დამატებაზე.

როგორ ვქმნით ამჟამად კონტურებს (თუნდაც ამის გაცნობიერების გარეშე)

მოდით, ცოტათი შევხედოთ ჩვენს ამჟამინდელ მონახაზებს. (X)HTML-ში დოკუმენტის იერარქიული სტრუქტურა ნაკარნახევი იყო სათაურის დონეზე, ნაცნობის გამოყენებით რომ ტეგები.

ასე რომ, შეგიძლიათ მონიშნოთ თქვენი გვერდი ასე (როგორც გამარტივებული მაგალითი), სათაურებით, რომლებიც წარმოადგენენ თითოეული ნაწილის "მნიშვნელოვნებას":

this.panelNarr = ფუნქცია (aPanel){
var elevator = $('#panelControl a[href="'+aPanel+'"]');
var narrative = $(aPanel+' .narrative');
var overflowNewHt = narrative.outerHeight() + 500;

ჩემი ტკბილი ბლოგი

უახლესი პოსტები

ჩემი ბლოგის პოსტი 1

ჩემი ბლოგის პოსტი 2

ჩემი ბლოგის პოსტი 3

ბლოგის გვერდითი პანელი

ბლოგის არქივები

Პოპულარული პოსტები

ბლოგის როლი

ბლოგის ქვედა კოლონტიტული

ჩემი გემრიელი ლინკები

ჩემი flickr ფოტოები

ჩემი სოციალური ქსელები

დოკუმენტის იერარქია ან „მოხაზულობა“ ასე გამოიყურება:

1. ჩემი მაგარი საიტი
1. უახლესი პოსტები
1. ჩემი ბლოგის პოსტი 1
2. ჩემი ბლოგის პოსტი 2
3. ჩემი ბლოგის პოსტი 3
4. ბლოგის გვერდითი პანელი
1. ბლოგის არქივები 2. Პოპულარული პოსტები
3. ბლოგის როლი
4. ბლოგის ქვედა კოლონტიტული
1. ჩემი გემრიელი ლინკები
2. ჩემი flickr ფოტოები
3. ჩემი სოციალური ქსელები

უჰ-ო. Ჩვენ პრობლემა გვაქვს. ყველა ჩვენი ქვედა დონის სათაური „მფლობელობაშია“ მათ ზემოთ არსებულ სათაურს. „ბლოგის გვერდითი ზოლი“ არ უნდა იყოს სათაური „უახლესი პოსტების“ ქვეშ – ის უნდა დაიწყოს ახალი განყოფილება.

თუ ჩვენ შევცვლით "ბლოგის გვერდითი ზოლის" სათაურის დონეს (იგივე „უახლესი პოსტები“), რომელიც მოგვცემს:

1. ჩემი მაგარი საიტი
1. უახლესი პოსტები
1. ჩემი ბლოგის პოსტი 1
2. ჩემი ბლოგის პოსტი 2
3. ჩემი ბლოგის პოსტი 3
2. ბლოგის გვერდითი პანელი
1. ბლოგის არქივები
2. Პოპულარული პოსტები

მაგრამ ახლა ჩვენ აღარ წარმოვადგენთ სათაურის მნიშვნელობას. ამის ნაცვლად, ჩვენ ვცდილობთ ავაშენოთ ლოგიკური სტრუქტურა ტეგების შეზღუდული ნაკრების გამოყენებით (-), რომლებსაც აქვთ ჩვევა „ისაკუთრონ“ ყველაფერი მათ ქვემოთ - მაშინაც კი, როცა არ უნდა.

აი კიდევ ერთი მაგალითი. ვთქვათ, გვაქვს გვერდი, რომელიც ამბობს:

ჩემი HTML5 წიგნის მიმოხილვა

მოსწონს

მან კარგად ახსნა HTML5-ის ზოგიერთი ელემენტი.

არ მოსწონს

ავტორს შემაწუხებელი ჩვევა ჰქონდა სულელური, თვითრეფერენტული მაგალითების წერის.

ვიყიდე ეს HTML5 წიგნი დაბალ, დაბალ ფასად...

ამ დოკუმენტის მონახაზში, მთელი მიმოხილვა ექვემდებარება

არ მოსწონს

, რადგან სათაური „იფლობს“ ყველაფერს მის ქვეშ, მიუხედავად იმისა, რომ ის ნამდვილად უნდა მოექცეს

ჩემი HTML5 წიგნის მიმოხილვა

. როგორც წესი, ეს სტრუქტურული პრობლემა შეუმჩნეველი რჩება. ვიზუალური პრობლემა იმის შესახებ, რომ მიმოხილვის ტექსტი გამოჩნდება ქვეშ არ მოსწონს თუმცა შეუმჩნეველი არ დარჩება, ამიტომ სტილის მიზნებისთვის ჩვენ ალბათ შემოვიყვანთ div-ს, რათა ვიზუალურად განვასხვავოთ ქვემოთ მოცემული აბზაცები არ მოსწონს და თავად განხილვის ორგანო. და მართლაც, ხშირად ასე ვაწყობთ ჩვენს დოკუმენტებს - ვიყენებთ div-ებს, რომ დავყოთ ისინი ლოგიკურ სექციებად. მაგრამ ამას არანაირი მნიშვნელობა არ აქვს დოკუმენტის მონახაზზე ხელმისაწვდომობის თვალსაზრისით - მონახაზი იქმნება მხოლოდ სათაურებით.

როგორც ხედავთ, სათაურები ხარვეზებია კონტურების შესაქმნელად. ადამიანები ხშირად იყენებენ სათაურის დონეებს შრიფტის სხვადასხვა ზომის საჩვენებლად (CSS-ით ან მის გარეშე), ან თვითნებური „მნიშვნელოვნების“ აღსანიშნავად და არა სტრუქტურისთვის. და ზოგჯერ ისინი უბრალოდ ჭრიან და ათავსებენ HTML პირდაპირ ახალ შაბლონში.

როდესაც გაითვალისწინებთ ამ ყველაფერს, ისევე როგორც გამოყენების შეზღუდვებს -, აშკარაა, რომ ვებ გვერდების უმეტესობას ლოგიკური მონახაზი არ აქვს.

მაგრამ მათ აქვთ მონახაზი და გამოყენება - საერთოდ აძლევს უსინათლო და მხედველობის დაქვეითებულ მომხმარებლებს ჩვენს დოკუმენტებში ნავიგაციის საშუალებას, რაც გამოკვლევების თანახმად ჩვეულებრივია იმ ადამიანებისთვის, რომლებიც იყენებენ ეკრანის წამკითხველებს. (ამ კვლევას ცოტა ხანში შევეხებით.) ასე რომ, ხარვეზების მიუხედავად, ხელმისაწვდომობის მიზეზების გამო ჩვენ უფრო სერიოზულად უნდა მივიღოთ სათაურები სტრუქტურისთვის, და არა ნაკლები.

(ნებისმიერი საიტის კონტურების სანახავად (სცადეთ საკუთარი!), შეამოწმეთ HTML5 Outliner Google Chrome-ისთვის.)

მაგრამ რა იქნებოდა, თუ არსებობდა გზა, რომ შეგვექმნა თვითნებური მონახაზები სათაურებზე დაყრდნობის გარეშე? როგორც ირკვევა, ხალხი ამაზე ფიქრობს წლების განმავლობაში - თუ არა ათწლეულების განმავლობაში.

07. "სექცია" ძველი პრობლემაა

სათაურების პრობლემა და დოკუმენტის სტრუქტურირება დიდი ხნის პრობლემაა. XHTML 2.0-მა შესთავაზა გამოსავალი პირველი პროექტი 2002 წელს, რომელიც მოიცავდა ბუდეს ტეგები და გენერიკის გამოყენება ელემენტი სათაურებისთვის.

XHTML 2.0-ში ეს „სექციური“ გადაწყვეტა თავდაპირველად ტიმ ბერნერს-ლის მიერ იქნა მოყვანილი ჯერ კიდევ 1991 წელს. ჯერემი კიტმა აღნიშნაროდესაც ბერნერს-ლიმ თქვა:

„სინამდვილეში მირჩევნია ამის ნაცვლად, და ა.შ. სათაურებისთვის [ისინი მოდის AAP DTD-დან], რომ ჰქონდეს ბუდე

..

ელემენტი და ზოგადი .. რომელიც სექციებში შემავალ ნებისმიერ დონეზე წარმოქმნის სათაურის საჭირო დონეს“.

დიახ, კარგი ორი ათეული წლის წინ.

HTML5 ცდილობს გადაიტანოს სექციის ეს კონცეფცია მთავარ HTML-ში XHTML 2.0-ის მსგავსი ბილიკის გავლის გზით, ამასთან, შეინარჩუნოს გარკვეული უკუღმა თავსებადობა. და შედეგები, ვთქვათ, შერეულია.

მაგრამ სანამ HTML5-ის იმპლემენტაციას მივაღწევთ, მოდით გადავხედოთ რამდენად მნიშვნელოვანია სათაურები ხელმისაწვდომობისთვის.

თუ ჩვენ ვზრუნავთ ბრმა მომხმარებლებზე, ჩვენ უნდა ვიზრუნოთ სათაურებზე

როგორც უკვე აღვნიშნეთ, HTML4-ით არის ისეთი სათაურები, როგორიცაა

ბლოგის გვერდითი პანელი

(და არა შემთხვევითი დივები, როგორიცაა

ბლოგის გვერდითი პანელი

) რომელიც ქმნის დოკუმენტის კონტურებს. და ბრმა მომხმარებლებისთვის ეს სათაურები მნიშვნელოვანია.

Რამდენად მნიშვნელოვანია? ეკრანის მკითხველის 1000-ზე მეტი მომხმარებლის გამოკითხვაში (სადაც ადამიანების 80 პროცენტი ბრმა იყო, ხოლო 16 პროცენტი დაქვეითებული მხედველობით):

„ამ კითხვაზე პასუხებმა ერთ-ერთი უდიდესი სიურპრიზი მოგვცა. ცხადია, რომ სათაურის სტრუქტურის უზრუნველყოფა მნიშვნელოვანია ეკრანის მკითხველის მომხმარებლებისთვის, 76 პროცენტი ყოველთვის ან ხშირად ატარებს სათაურების მიხედვით, როცა ისინი ხელმისაწვდომია. სათაურის ნავიგაციის გამოყენება გაიზარდა ეკრანის წამკითხველის ცოდნის ფონზე, მათი გამოყენება ყოველთვის ან ხშირად 90,7-ით ექსპერტი მომხმარებლების პროცენტი, მოწინავე მომხმარებლების 79,3 პროცენტი, შუალედური მომხმარებლების 69,9 პროცენტი და 55,4 პროცენტი დამწყებთათვის."

(შეგიძლიათ ნახოთ სრული შედეგები აქ)

იცოდით ამის შესახებ? მე არ ვიყავი და ვიყენებდი - ნებით თუ უნებლიეთ წლების განმავლობაში. ვფიქრობ, ვებ დიზაინერების უმეტესობას ამის ბუნდოვანი წარმოდგენა აქვს - ტეგები მნიშვნელოვანია, მაგრამ არა რამდენად მნიშვნელოვანია ისინი ბრმა მომხმარებლებისთვის.

ასე რომ, ჩვენ გვქონდა ჩამოყალიბებული, პირდაპირი, ადვილად განსახორციელებელი გზა უსინათლო და მხედველობის დაქვეითებული მომხმარებლებისთვის კონტურების მიწოდების მიზნით. ანუ სანამ HTML5-ს არ მივაღწევთ.

HTML5-ის „გაუმჯობესებული“ მონახაზი მკვდარი იყო მის გაგზავნამდე

ჩვენ დავადგინეთ, რა არის დოკუმენტის მონახაზი (გვერდის პუნქტი, სარჩევი სტილის სახით) და დავადგინეთ, როგორ იქმნება ისინი ამჟამად (ერთად - ელემენტები).

მოკლედ, აი, როგორ გვთავაზობს HTML5 დოკუმენტის კონტურების შექმნას:

• მონახაზში, ან „სექციაში“ თითოეული პუნქტი განისაზღვრება ოთხი „სექციური“ ელემენტიდან ერთ-ერთის გამოყენებით:, , და; და არა - ელემენტები. აქ მიზანია გადაჭრას შეზღუდვები -.
• არ არსებობს ზოგადი ელემენტი, XHTML 2.0-ის მიხედვით. მაგრამ სუფთა HTML5-ში ვარაუდობენ, რომ უბრალოდ შეგვიძლია გამოვიყენოთ ყველგან, როგორც ზოგადი სათაურის ელემენტი. სინამდვილეში, ნებისმიერი სათაურის ელემენტი HTML5-ში განიხილება, როგორც ზოგადი სათაური, მისი დონე განისაზღვრება იმის მიხედვით, თუ რამდენად ღრმად არის ის ჩასმული განყოფილების ელემენტებში.
• მაგრამ არ არსებობს „სუფთა“ HTML5, ამიტომ ჩვენ უნდა შევინარჩუნოთ უკან თავსებადობა. ამიტომ მაინც უნდა გამოვიყენოთ - ლოგიკური გზით, რაც გულისხმობს ერთ დოკუმენტში ორი გარკვეულწილად განსხვავებული დოკუმენტის მონახაზის შენარჩუნებას.

ეს არის ზოგადი აზრი. Აი როგორ სპეც აყენებს:

„სექციები შეიძლება შეიცავდეს ნებისმიერი რანგის სათაურებს, მაგრამ ავტორებს ურჩევენ გამოიყენონ მხოლოდ h1 ელემენტები, ან გამოიყენოს შესაბამისი რანგის ელემენტები განყოფილების ბუდე დონისთვის."

გთხოვთ არ გამოიყენოთ ელემენტები ყველგან!

ჩემი აზრით, ყველამ (ჰიქსონმა სპეციფიკაციაში და საჯარო კომენტარებში, სტანდარტების დამცველებმა საზოგადოებაში და ზოგადად დიზაინერებმა და ავტორებმა) ამის შესახებ კომუნიკაციის სრული ჰეშტი გააკეთეს.

ეს ცუდი კომუნიკაცია ნიშნავს იმას, რომ დიზაინერები და დეველოპერები იყენებდნენ ამ HTML5 ელემენტებს და არ ესმით მათ მიერ შექმნილ კონტურებზე. ამ ელემენტებს უნდა მოეტანათ უკეთესი ლოგიკური დოკუმენტის კონტურები. ამის ნაცვლად, მათი განხორციელების შემთხვევითი გზის გათვალისწინებით, მათ შექმნეს HTML5-ის სტილის დოკუმენტის კონტურები, რომლებიც კიდევ უფრო დარღვეულია, ვიდრე -- დაფუძნებული მონახაზები, რომელთა შეცვლაც იყო განზრახული.

HTML5-ის ხაზგასმის ვერსია ფაქტობრივად მკვდარი იყო, სანამ ვინმეს ესმოდა, მით უმეტეს, რომ სწორად განხორციელდა.

და აი, ირონია: ეს მიდგომა, რომელიც თეორიულად შეიძლება მოგაწოდოთ ხელმისაწვდომობის უპირატესობა მომავალში (არავინ იცის როდესაც, ან თუნდაც, ეკრანის მკითხველები გამოიყენებენ ამ მონახაზებს), ანგრევს გვერდის სტილებს IE მომხმარებელთა მცირე ჯგუფისთვის. ახლა. ასე რომ, ის უკვე ზიანს აყენებს, მაგრამ სამომავლო სარგებელი არ აქვს.

08. დიდ იდეებში შეპარვა იწვევს მკვდარ იდეებს

პირველი პრობლემა ამ ახალი მიდგომის ხაზგასასმელად არის იდეა, რომ HTML5 უბრალოდ „დააფარებს ძროხებს“ და ახდენს არსებული პრაქტიკის კოდიფიკაციას.

ცხადია, დოკუმენტების სტრუქტურირების სრულიად ახალი ხერხის დანერგვა, რაც არ უნდა სუსტი კომუნიკაცია იყოს, არ არის „ძროხების მოპირკეთება“.

თქვენ არ შეგიძლიათ შებრუნდეთ და უთხრათ ავტორებს და დიზაინერებს: "ეს არის ის, რასაც თქვენ ყოველთვის აკეთებდით!" მაგრამ ჰიკსონმა სწორედ ეს გააკეთა და თქვა, რომ ახალი ელემენტები მხოლოდ კლასების საერთო სახელების შესანახად არის გამიზნული. აქ არის მხოლოდ რამდენიმე მაგალითი.

2009 წელს, თქვა ჰიკსონმა:

„ისინი მეტ-ნაკლებად ავსებენ ვებ დეველოპერების ყველაზე გავრცელებულ მოთხოვნებს იმის მიხედვით, თუ რა არის ყველაზე გავრცელებული კლასი = "" ატრიბუტის მნიშვნელობებია. მათი მთავარი მიზანია გამარტივდეს ავტორიზაცია და სტილისტიკა“.

და 2012 - ში:

"ძირითადად ეს ახალი ელემენტები აადვილებს ავტორის შექმნას."

ასე რომ, თუ HTML5 აპირებს დიდი ახალი იდეის დანერგვას, მას სჭირდება ამ დიდი ახალი იდეის კომუნიკაცია. სამაგიეროდ, როგორც ჩანს, ჰიქსონს არ ახსოვს, ან ვერ აწუხებს კამათს, ის და WHATWG-ის დაყოფის დიდი იდეა, რომელიც დაამატა სპეციფიკაციას.

HTML5-ის მომხრეებს (და თავად სპეციფიკაციას) სჭირდებათ ახალი ელემენტების მიზნის სწორად კომუნიკაცია, ან მათი გაუქმება.

როგორც ახლაა, ისინი უბრალოდ სისულელეს აყენებენ ვებ დიზაინის საზოგადოებას.

მოდი მაგალითს მოგიყვან. სპეციფიკაცია ამბობს და ელემენტები განსაზღვრავენ ზონებს სექციის შიგნით, მაგრამ თავად არ განსაზღვრავენ სექციებს და, შესაბამისად, არ გამოჩნდება დოკუმენტის მონახაზში. ეს არის ის, რასაც ადამიანების უმეტესობა ცდება, მათ შორის ისეთებიც, რომლებიც ასწავლიან HTML5-ს წიგნებისა და ბლოგების მეშვეობით, რომელთა მაგალითები ხშირად ჩანს თანასწორზე ყოფნა. სპეციფიკაციაშიც ნათქვამია და შეიძლება გამოყენებულ იქნას თითო გვერდზე რამდენჯერმე (მაგალითად, განყოფილებაში ერთხელ), მაგრამ ამას ვერასდროს აირჩევთ HTML5 რესურსებიდან.

ეს შეიძლება მოგეჩვენოთ პედანტურ, გაურკვეველ წერტილებად. მაგრამ ისინი ასახავს რაღაც ძალიან სერიოზულს – საზოგადოება ცდილობს განახორციელოს HTML5 მარკირება ისე, რომ დიდად არ იყოს დაკავშირებული რეალურ HTML5 სპეციფიკასთან. ეს არის უცნაური შუალედური მდგომარეობა, რომელიც უნებლიედ გამოჩნდა, რადგან ეს არის ის, რისთვისაც ყველა თვლიდა, რომ ეს ელემენტები უნდა გამოეყენებინათ.

09. ჩვენ დავყარეთ სპეც

გარკვეული გაგებით, საზოგადოებამ გააფუჭა HTML5, რამდენადაც მარკირება მიდის. ეს დიდი პრობლემაა. არსებობს HTML5-ის „საერთო (მაგრამ არასწორი) გაგება“ და აქ არის HTML5-ის რეალური სპეციფიკაცია. მაგრამ „საერთო გაგების“ დაცვა და ჩვენს შაბლონებში ვიზუალური უბნების შეცვლა ისეთი ელემენტებით, რომლებიც „სწორად ჟღერს“ არავისთვის არ არის სარგებელი. ჩვენ უბრალოდ ვქმნით უცნაურ, გატეხილ მონახაზს ახალი ელემენტების ბოროტად გამოყენებისას. და ამდენი გატეხილი HTML5 მონახაზით, კონცეფციის სახით ჩამოყალიბება თითქმის მკვდარია ჩამოსვლისას.

ჩვენ შევისწავლით თითოეულ ელემენტს ინდივიდუალურად ერთ მომენტში, მაგრამ მოდით, ახლა მივუდგეთ დიდ სურათს.

10. როგორ უნდა დავასტრუქტუროთ HTML5 გვერდი?

ეს ყველაფერი ამ მომენტში შეიძლება ცოტა დამაბნეველი ჩანდეს, ასე რომ, მოდით გადავდგათ ნაბიჯი უკან და გადავხედოთ HTML5-ში გვერდის სტრუქტურირების ზოგად წესებს (როგორიც არის!), როგორც აღწერილია სპეციფიკაციაში:

• ჩვენ უნდა გამოვიყენოთ, , ან მონახაზში ახალი განყოფილების შესაქმნელად. (ანუ ახალი პუნქტი დოკუმენტის მონახაზში.) თქვენ შეგიძლიათ ნახოთ, როგორ გამოიყურება თქვენი მონახაზი HTML5 Outliner დანამატი Chrome-ისთვის. დიახ, ტერმინოლოგია აქ მოუხერხებელია - აქვს მრავალი ელემენტი, მათ შორის, დოკუმენტის მონახაზში განყოფილების შექმნა საკმაოდ დამაბნეველია!
• Ჩვენ ვიყენებთ ან თითოეულ სექციაში ამ სექციის სათაურის ან ქვედა კოლონტიტულის გამოყოფა. ეს განყოფილება შეიძლება იყოს ნებისმიერი ძირიდან განყოფილება ინდივიდუალური კომენტარისთვის. (ინდივიდუალური კომენტარი უნდა იყოს, როგორც დავინახავთ მეოთხე თავში, რომელიც შექმნის განყოფილებას დოკუმენტის მონახაზში.)
• ჩვენ ვიყენებთ სათაურის ელემენტებს (-) თითოეულ განყოფილებას მიენიჭოს სათაური მონახაზში და უზრუნველყოს უკან თავსებადობა. (როდესაც ამას ვწერ, არსად არ არის HTML5 მონახაზების მნიშვნელოვანი მხარდაჭერა და, როგორც ჩანს, არც ჰორიზონტზეა. ასე რომ, "უკუღმა" თავსებადობა შეიძლება რეალურად იყოს "თავსებადობა უახლოეს მომავალში".)

თქვენ შეიძლება იფიქროთ, რომ თქვენ შეგიძლიათ უბრალოდ შეცვალოთ ყველა თქვენი div-ით s და შექმენით მონახაზი. თუმცა, s არ გამოიყენება იმ შემთხვევებში, როდესაც თქვენ გჭირდებათ მხოლოდ სტილის კაუჭი, ასე რომ, ნამდვილ HTML5 დოკუმენტში თქვენ კვლავ გექნებათ უამრავი div. სინამდვილეში, "სწორ" HTML5 დოკუმენტს ექნება:

• რამოდენიმე, , და ტეგები კონტურის შესაქმნელად
• თაიგულები სტილისთვის
• ზედმეტი გამოყენება - ტეგები კონტურის მაქსიმალურად დუბლირებისთვის (ეს არის ის, რასაც რეალურად გამოიყენებენ ეკრანის წამკითხველები)
• ჯანსაღი sprinkling ზედმეტი და ტეგები თითოეულ სექციაში, რომლებიც არაფერს აკეთებენ.

ავტორიზაციის გამარტივება? გვერდის სტრუქტურირების ორი საშუალებით, შესანარჩუნებლად ორი კონტურით და დასამატებელი ზედმეტი ტეგების თაიგულით?

მე ასე არ ვფიქრობ. და ეს მანამდეა, სანამ ჩვენ განვიხილავთ ჩვენი სათაურის სტილს.

სათაურების სტილისტიკა HTML5 სტილი ერთგვარი გიჟურია

წარმოვიდგინოთ სუფთა HTML5 მომავალი, სადაც შეგვიძლია გამოვიყენოთ ყველგან, როგორც ზოგადი სათაურის ელემენტი, სპეციფიკის შემოთავაზების მიხედვით, და ჩვენ ვიყენებთ განყოფილების ახალ ელემენტებს მონახაზის შესაქმნელად. ანუ თუ გამოვიყენებთ ა სამი მონაკვეთის სიღრმე, ეს არსებითად არის ა .

დავუშვათ, რომ ჩვენ გვინდა ამ სამი განყოფილების სიღრმის სტილი თითქოს ეს იყო ა. როგორ ვაპირებთ მის არჩევას? და წარმოგიდგენიათ კრეფა h1 ყველგან კასკადის მეშვეობით მისცეს მას განსხვავებული სტილი სხვადასხვა დონეზე, მოცემული ოთხი ელემენტი შეიძლება შექმნას განყოფილება და შეიძლება გამოყენებულ იქნას ნებისმიერ კომბინაციაში? ვერ დაიძინებდი.

ნიკოლ სალივანი შეეხო სიგიჟეს, რომელიც წარმოიქმნება, როდესაც თქვენ ცდილობთ HTML5 სტილის შექმნას ელემენტები კასკადის მეშვეობით სათანადო სათაურით ბლოგ პოსტში "ნუ დააწყობთ სათაურებს HTML5 სექციების გამოყენებით" და მოიყვანა ეს გამარტივებული მაგალითი:

h1{შრიფტის ზომა: 36px}
სექცია h1{font-size: 28px}section section h1{font-size: 22px}
განყოფილების სექცია სექცია h1{font-size: 18px}
განყოფილების განყოფილება სექცია h1{font-size: 16px}
განყოფილების განყოფილება სექცია სექცია სექცია h1{font-size: 14px}
განყოფილების განყოფილება სექცია სექცია სექცია სექცია h1{font-size: 13px}
განყოფილების განყოფილება სექცია სექცია სექცია სექცია სექცია h1{font-size: 11px}

თუმცა, ეს არის უაღრესად გამარტივებული ვერსია, როგორც სალივანი აღნიშნავს. ნამდვილი სიგიჟე ჩნდება მაშინ, როდესაც თქვენ უნდა მოაწყოთ თქვენი ყველა (ვთქვათ) ექვსდონიანი სიღრმისეული სათაური, რომელიც შეიძლება ჩასმული იყოს ნებისმიერ კომბინაციაში., ,, ან. კომედიური ღირებულებისთვის იხ როგორი იქნება ასეთი სტილის ფურცელი. ეს სრულიად გიჟურია.

ამის შემდეგ ერთადერთი ვარიანტია, დაუბრუნდეთ სათაურების კლასების სახელებს, მაგრამ კლასების სახელების თავიდან აცილება ავტორის შექმნისას სწორედ ის „პრობლემაა“, რომლის გადაჭრასაც WHATWG ცდილობდა.

და როგორ ფიქრობთ, ჩვენი კლიენტები და კოლეგები, რომლებიც სიამოვნებით ქმნიან და არედაქტირებენ ვებ გვერდებს, ოდესმე გაიგებენ თავიანთი სტატიების სწორად დაყოფის ნიუანსებს? Ვეჭვობ.

გასაკვირი არ არის, რომ ხალხი დაბნეულია.

ოჰ, და ეს ყველაფერი თქვენი სტილის ზევით (და ნებისმიერი სხვა ახალი HTML5 ელემენტი) შეიძლება აფეთქდეს მომხმარებელთა ~1%-ისთვის.

ეს არის HTML5-ის გზა. და ეს არეულობაა.

გასაკვირი არ არის, რომ ყველაზე გამოცდილი ვებ ავტორებიც კი ხვდებიან HTML5 მონახაზის ჭაობში. Წაიკითხო რაღაცის შესახებ როჯერ იოჰანსონის გამოცდილება, მაგალითად.

ეს არ არის უაზრო - ადამიანებმა უნდა ასწავლონ ეს

„კარგი, შესაძლოა, მარკირებამ არასწორად შეასრულა ეს. შესაძლოა ეს ტეგები ძირითადად ზედმეტია. ასე რომ, არავინ იყენებს მათ, ან ისინი ამას არ აკეთებენ სწორად. ვის აინტერესებს, მისტერ მარკუპ პედანტ?

საქმე იმაშია, რომ ამ ახალი ელემენტების – და ისეთი ცნებების, როგორიცაა თვითნებური მონახაზი – შემოღება ოფიციალურ HTML5 სპეციფიკაციაში ნიშნავს იმას, რომ ადამიანებმა რეალურად უნდა ასწავლონ ეს მასალა. (ჯანდაბა, ზოგიერთი დიზაინერი ბავშვებსაც კი ასწავლის ამ ნივთს - იხილეთ Cameron Moll's მაგარი HTML5 თეთრი დაფის მაგნიტები, მაგალითად)

ეს ცუდია ვებ სტანდარტებისთვის. ეს ართულებს საბაზისო HTML-ს სწავლებას, ძნელად სწავლას, დანერგვას და რისთვის? ვებ გვერდის სტრუქტურირება ჩვენი ყველაზე ნაკლები საზრუნავი უნდა იყოს – არა დიდი ყურადღების გაფანტვა სტუდენტებისა და პროფესიონალების თაობისთვის.

(შენიშვნა სწავლების ვებ სტანდარტებზე: თუ ნამდვილად გძულთ თქვენი სტუდენტები, სთხოვეთ მათ ახსნან განსხვავება და .)

11. სად გვტოვებს ეს?

ჰიკსონის და WHATWG-ის ზრახვები კარგია. თეორიულად, ამ ტეგების გამოყენებამ შეიძლება გააუმჯობესოს ხელმისაწვდომობა კონტურის განხილვის გარეშეც კი. (მაგალითად, ეკრანის მკითხველს შეუძლია გამოტოვოს ის მონიშნეთ, რომ პირდაპირ კონტენტზე გადახვიდეთ.) მაგრამ მომწოდებლები, რომლებიც ქმნიან ეკრანის წამკითხველებს, დღემდე ძალიან მცირე ინტერესს ავლენენ HTML5-ის მიმართ. და უკვე არსებობს უკეთესი ალტერნატივების მხარდაჭერა, რომელსაც შემდეგში განვიხილავთ.

ასე რომ, ჩვენ არ გვჭირდება HTML5-ის ახალი ელემენტები ხელმისაწვდომობისთვის. სინამდვილეში, ჩვენ უნდა მოვერიდოთ მათ იმ ზიანის გამო, რომელიც მათ მომხმარებელთა სხვა ქვეჯგუფს აყენებენ.

ხალხი კვლავ გამოიყენებს ამ ტეგებს, ძირითადად იმიტომ, რომ მათ სურთ „აკეთონ სწორი საქმე“ იმ იმედით, რომ Standards Fairy დატოვებს მცირე ცვლილებებს და/ან Apple-ის პროდუქტს ბალიშის ქვეშ. მაგრამ ეს მხოლოდ პროდუქტიული დროის დაკარგვაა, რომელიც უკეთესად შეიძლება დაიხარჯოს უფრო მნიშვნელოვან საკითხებზე.

დაიმახსოვრეთ: ის, რაც მთავრდება სპეციფიკაში, ხშირად მხოლოდ რამდენიმე (ან თუნდაც ერთი) დაინტერესებული, ჭკვიანი, ჩვეულებრივი ადამიანის იდეაა 7+ წლის წინანდელი (როგორც წერია). და დიდი შანსია, არც კი ახსოვთ, რატომ სურდათ ეს. ასე რომ, ვფიქრობ, ჩვენ გვაქვს უფლება არ დავეთანხმოთ იმას, რაც საუკეთესოა და ავირჩიოთ და ავირჩიოთ ის, რასაც განვახორციელებთ.

მაგრამ რა ხდება ხელმისაწვდომობასთან? ვტოვებთ მხოლოდ მხედველობის დაქვეითებულ მომხმარებლებს სტატუს-კვოსთან? არა, რადგან საბედნიეროდ უკეთესი ალტერნატივა არსებობს.

12. გონივრული მიდგომა სტრუქტურული მარკირებისადმი ხელმისაწვდომობისთვის

არსებობს გზა, რომ დავამატოთ დამხმარეები უსინათლოთა და მხედველობის დაქვეითებულთათვის ჩვენს მარკირებაში HTML5-ის ახალი სტრუქტურული ელემენტების ჭაობში ჩავარდნის გარეშე - ARIA როლები.

სინამდვილეში, ეს არის WAI-ARIA, რომელიც ნიშნავს "ხელმისაწვდომობის ხალხი აშკარად არ აკეთებს მიმზიდველ აკრონიმებს". ან, როგორც სიზუსტის სტიკერებმა შეიძლება გითხრათ, ეს არის "ვებ ხელმისაწვდომობის ინიციატივა - ხელმისაწვდომი მდიდარი ინტერნეტ აპლიკაციები". (ჩვენ მას უბრალოდ ARIA-ს დავარქმევთ.)

ეს არ არის HTML5 სპეციფიკაციის ნაწილი. ამის ნაცვლად, ეს არის ცალკე (და გიგანტური) W3C სპეციფიკაცია, რომელიც თავსებადია HTML5, HTML 4 და XHTML 1.x-თან.

ARIA-ს საიდუმლო არის როლი ატრიბუტი, რომელიც შეიძლება დაემატოს ასეთ ელემენტს:

The სრული ARIA სპეციფიკაცია არის დიდი. Ნამდვილად დიდი. მაგრამ ჩვენ განვიხილავთ მცირე ქვეჯგუფს, რომელსაც ე.წ ღირსშესანიშნაობები.

მაგალითად, აქ არის მარტივი გვერდის ოთხი ძირითადი სფერო:

• სათაური
• შინაარსი
• გვერდითი ზოლი
• ქვედა კოლონტიტული

და აი, როგორ აღვნიშნავთ მას ARIA-ს გამოყენებით:

Ადვილი.

ARIA-ს სარგებელი

ARIA როლებს რამდენიმე უპირატესობა აქვს HTML5-თან (ან წინა HTML ვერსიებთან):

• როლები ზოგადად ასახავს, ​​თუ როგორ აწყობენ ვებ ავტორები გვერდებს. (მაგალითად, სათაური ან „ბანერი“ არის გვერდის ზედა ნაწილისთვის - არა გვერდის ყველა განყოფილებისთვის, როგორც HTML5-ში.)
• ისინი ინარჩუნებენ ჩვენს მარკირებას შედარებით სუფთად, რადგან ჩვენ შეგვიძლია გამოვიყენოთ როლი ატრიბუტი, როგორც სტილის სამაგრი IE7-ისთვის და ზემოთ, ატრიბუტების სელექტორებით, როგორიცაა div[role="banner"] {საზღვარი: 10px ვარდისფერი;}. (თუ გჭირდებათ IE6 მომხმარებლების მხარდაჭერა, შეგიძლიათ ასევე შეიყვანოთ ზედმეტი კლასები.)
• მათ მუშაობა ახლავე ეკრანის წამკითხველებში, რომლებიც მხარს უჭერენ ARIA ნიშნებს, როგორიცაა JAWS 10 ვერსიის ეკრანის წამკითხველი, NVDA 2010.1 და VoiceOver iPhone IOS4+-ზე.
• ისინი არ აფუჭებენ სტილს IE6-8 მომხმარებლებისთვის JavaScript-ით გამორთული, როგორც ამას აკეთებს ახალი HTML5 ელემენტები.

ეს ტექნიკა ახლა უსინათლო მომხმარებლებს ეხმარება, არ აზიანებს ვებ სტანდარტებს და არ საჭიროებს თქვენი დოკუმენტის დაყოფის მეორე გზას.

13. განლაგების რეკომენდაციები

სანამ დავასრულებთ, ნება მომეცით აღვნიშნო, როგორ ვფიქრობ, რომ უნდა მოვინიშნოთ გვერდები HTML5-ის ასაკში:

• ჩვენ არ უნდა გამოიყენეთ ახალი ტეგები. (მაგრამ ჩვენ გადავხედავთ მათ შემდეგ და ARIA ღირშესანიშნაობებს, რომლებიც უნდა გამოვიყენოთ.)
• ჩვენ უნდა უფრო სერიოზულად მოეკიდეთ სათაურებს, იმის გათვალისწინებით, თუ რამდენად ეყრდნობიან მათ ბრმა და მხედველობის დაქვეითებული მომხმარებლები.
• ჩვენ უნდა გამოიყენეთ ARIA ღირშესანიშნაობები ხელმისაწვდომობისთვის.
• ჩვენ უნდა წინააღმდეგ შემთხვევაში გამოიყენეთ divs სემანტიკური კლასის სახელებით ან ID-ებით, როგორც ამას ყოველთვის ვაკეთებდით.
• ლუკ სტივენსი ათ წელზე მეტი ხნის განმავლობაში აშენებს საიტებს, როგორც წესი, ExpressionEngine-ით და ის არის მისი შემქმნელი Ninja Google Analytics-ისთვის. მისი წიგნი, სიმართლე HTML5-ის შესახებ, შეგიძლიათ შეიძინოთ აქ.