บทความนี้อธิบายถึงเหตุผลและวิธีที่เราใช้การจำลองภาวะบกพร่องในการมองเห็นสีในเครื่องมือสำหรับนักพัฒนาเว็บและเครื่องมือแสดงผล Blink
พื้นหลัง: สีคอนทราสต์ไม่ดี
ข้อความคอนทราสต์ต่ำเป็นปัญหาด้านการช่วยเหลือพิเศษที่ตรวจหาโดยอัตโนมัติที่พบได้บ่อยที่สุดในเว็บ
จากการวิเคราะห์ความสามารถในการเข้าถึงของ WebAIM ในเว็บไซต์ยอดนิยม 1 ล้านเว็บ พบว่าหน้าแรกกว่า 86% มีคอนทราสต์ต่ำ โดยเฉลี่ยแล้ว หน้าแรกแต่ละหน้าจะมีข้อความคอนทราสต์ต่ำ 36 รายการที่แตกต่างกัน
การใช้เครื่องมือสำหรับนักพัฒนาเว็บเพื่อค้นหา ทำความเข้าใจ และแก้ไขปัญหาคอนทราสต์
เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สามารถช่วยนักพัฒนาซอฟต์แวร์และนักออกแบบปรับปรุงคอนทราสต์และเลือกรูปแบบสีที่เข้าถึงได้มากขึ้นสำหรับเว็บแอป
- เคล็ดลับเครื่องมือของโหมดตรวจสอบซึ่งปรากฏที่ด้านบนของหน้าจะแสดงอัตราส่วนคอนทราสต์สำหรับองค์ประกอบข้อความ
- ตัวเลือกสีของเครื่องมือสำหรับนักพัฒนาเว็บจะแสดงอัตราส่วนคอนทราสต์ที่ไม่ดีสำหรับองค์ประกอบข้อความ แสดงเส้นคอนทราสต์ที่แนะนำเพื่อช่วยในการเลือกสีที่ดีขึ้นด้วยตนเอง และยังแนะนำสีที่เข้าถึงได้อีกด้วย
- ทั้งแผงภาพรวม CSS และรายงานการตรวจสอบการช่วยเหลือพิเศษของ Lighthouse จะแสดงองค์ประกอบของข้อความคอนทราสต์ต่ำที่พบในหน้าเว็บของคุณ
เราเพิ่งเพิ่มเครื่องมือใหม่ลงในรายการนี้และมีความแตกต่างเล็กน้อยจากเครื่องมืออื่นๆ เครื่องมือข้างต้นเน้นที่การแสดงข้อมูลอัตราส่วนคอนทราสต์และมีตัวเลือกในการแก้ไขข้อมูล เราพบว่าเครื่องมือสำหรับนักพัฒนาเว็บยังขาดช่องทางให้นักพัฒนาซอฟต์แวร์มีunderstandingเกี่ยวกับปัญหานี้มากยิ่งขึ้น ในการแก้ปัญหานี้ เราจึงใช้การจำลองภาวะบกพร่องทางการมองเห็นในแท็บการแสดงผลของเครื่องมือสำหรับนักพัฒนาเว็บ
ใน Puppeteer API ใหม่ของ page.emulateVisionDeficiency(type) จะช่วยให้คุณเปิดใช้การจำลองเหล่านี้แบบเป็นโปรแกรมได้
ภาวะบกพร่องในการมองเห็นสี
ประมาณ 1 ใน 20 คนมีความบกพร่องทางการมองเห็นสี (หรือเรียกอีกอย่างหนึ่งว่า "ตาบอดสี") ความบกพร่องดังกล่าวทำให้แยกแยะสีต่างๆ ได้ยากขึ้น ซึ่งจะทำให้มีปัญหาเกี่ยวกับคอนทราสต์มากขึ้น
ในฐานะนักพัฒนาซอฟต์แวร์ที่มีสายตาปกติ คุณอาจเห็นเครื่องมือสำหรับนักพัฒนาเว็บแสดงอัตราส่วนคอนทราสต์ที่ไม่ดีสำหรับคู่สีที่ดูเหมาะสมสำหรับคุณ ที่เป็นเช่นนี้เพราะสูตรอัตราส่วนคอนทราสต์คำนึงถึงความบกพร่องทางการมองเห็นสีเหล่านี้ด้วย คุณอาจยังอ่านข้อความคอนทราสต์ต่ำได้ในบางกรณี แต่ผู้ที่มีความบกพร่องทางการมองเห็นจะไม่มีสิทธิ์ทำเช่นนั้น
เรามุ่งหวังที่จะให้สิ่งที่ขาดไปได้ในการให้นักออกแบบและนักพัฒนาซอฟต์แวร์สามารถจำลองผลกระทบจากความบกพร่องทางการมองเห็นเหล่านี้สำหรับเว็บแอป ซึ่งนอกจากจะช่วยคุณค้นหาและแก้ไขปัญหาเกี่ยวกับคอนทราสต์ได้แล้ว คุณยังทำความเข้าใจปัญหาเหล่านั้นได้ด้วย
การจำลองภาวะบกพร่องในการมองเห็นสีด้วย HTML, CSS, SVG และ C++
ก่อนจะลงลึกถึงการนำฟีเจอร์ Blink Renderer ไปใช้ เราอยากให้คุณเข้าใจวิธีที่คุณจะใช้ฟังก์ชันการทำงานที่เทียบเท่ากันโดยใช้เทคโนโลยีเว็บ
ให้ลองนึกภาพการจําลองความบกพร่องทางการมองเห็นสีเหล่านี้เป็นการวางซ้อนที่ครอบคลุมทั้งหน้าเว็บ แพลตฟอร์มเว็บมีวิธีทำแบบนั้นได้ นั่นคือตัวกรอง CSS ด้วยพร็อพเพอร์ตี้ CSS filter คุณสามารถใช้ฟังก์ชันตัวกรองที่กำหนดไว้ล่วงหน้าบางรายการ เช่น blur, contrast, grayscale, hue-rotate และอื่นๆ อีกมากมาย เพื่อให้ควบคุมได้มากยิ่งขึ้น พร็อพเพอร์ตี้ filter ยังยอมรับ URL ที่ชี้ไปยังคําจํากัดความของฟิลเตอร์ SVG ที่กําหนดเองได้ด้วย
<style>
:root {
filter: url(#deuteranopia);
}
</style>
<svg>
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000">
</feColorMatrix>
</filter>
</svg>
ตัวอย่างข้างต้นใช้คําจํากัดความของตัวกรองที่กําหนดเองตามเมตริกซ์สี โดยหลักการแล้ว ค่าสี [Red, Green, Blue, Alpha] ของทุกพิกเซลจะคูณเมทริกซ์เพื่อสร้างสีใหม่ [R′, G′, B′, A′]
แต่ละแถวในเมทริกซ์ประกอบด้วย 5 ค่า: ตัวคูณสำหรับ (จากซ้ายไปขวา) R, G, B และ A รวมถึงค่าที่ 5 สำหรับค่าที่เปลี่ยนแปลงคงที่ มี 4 แถว ได้แก่ แถวแรกของเมทริกซ์ใช้ในการคำนวณค่าสีแดงใหม่ แถวที่ 2 สีเขียว แถวที่ 3 สีน้ำเงิน และแถวสุดท้ายเป็นอัลฟ่า
คุณอาจสงสัยว่าตัวเลขที่แน่นอนในตัวอย่างของเรามาจากที่ใด อะไรทำให้เมตริกซ์สีนี้เป็นค่าประมาณของภาวะตาบอดสีเขียวได้ คำตอบคือวิทยาศาสตร์ ค่าเหล่านี้อิงตามโมเดลจำลองภาวะบกพร่องในการมองเห็นสีที่ถูกต้องแม่นยำโดย Machado, Oliveira และ Fernandes
ทั้งนี้เรามีฟิลเตอร์ SVG นี้ และตอนนี้เราสามารถใช้กับองค์ประกอบที่กำหนดเองบนหน้าได้โดยใช้ CSS เราสามารถทำตามรูปแบบเดียวกันนี้ได้อีกหากมีความบกพร่องอื่นๆ ทางการมองเห็น นี่คือตัวอย่างของส่วนนี้
หากต้องการ เราสามารถสร้างฟีเจอร์เครื่องมือสำหรับนักพัฒนาเว็บได้ดังนี้ เมื่อผู้ใช้จำลองภาวะบกพร่องทางการมองเห็นใน UI เครื่องมือสำหรับนักพัฒนาเว็บ เราจะแทรกตัวกรอง SVG ในเอกสารที่ตรวจสอบ จากนั้นจึงใช้รูปแบบตัวกรองกับองค์ประกอบราก อย่างไรก็ตาม การดำเนินการดังกล่าวมีปัญหาหลายประการ ดังนี้
- หน้าเว็บอาจมีตัวกรองในองค์ประกอบรากอยู่แล้ว ซึ่งโค้ดของเราอาจลบล้างหลังจากนั้น
- หน้านี้อาจมีองค์ประกอบที่มี
id="deuteranopia"อยู่แล้ว และขัดแย้งกับคําจํากัดความของตัวกรอง - หน้าเว็บอาจอาศัยโครงสร้าง DOM บางอย่าง และการแทรก
<svg>ลงใน DOM เราอาจละเมิดสมมติฐานเหล่านี้
นอกจากกรณีที่เป็นปัญหาแล้ว ปัญหาหลักในแนวทางนี้คือเราจะทําการเปลี่ยนแปลงที่สังเกตได้ในหน้าเว็บโดยใช้โปรแกรม หากผู้ใช้เครื่องมือสำหรับนักพัฒนาเว็บตรวจสอบ DOM ก็อาจเห็นองค์ประกอบ <svg> ที่ไม่เคยเพิ่มเลย หรือ CSS filter ที่ผู้ใช้ไม่เคยเขียน คงฟังดูสับสน ในการใช้งานฟังก์ชันนี้ในเครื่องมือสำหรับนักพัฒนาเว็บ เราต้องมีโซลูชันที่ไม่มีข้อด้อยเหล่านี้
มาดูกันว่า เราจะลดการรบกวนน้อยลงได้อย่างไร โซลูชันนี้มี 2 ส่วนที่ต้องซ่อน ได้แก่ 1) รูปแบบ CSS ที่มีพร็อพเพอร์ตี้ filter และ 2) คําจํากัดความของฟิลเตอร์ SVG ซึ่งปัจจุบันเป็นส่วนหนึ่งของ DOM
<!-- Part 1: the CSS style with the filter property -->
<style>
:root {
filter: url(#deuteranopia);
}
</style>
<!-- Part 2: the SVG filter definition -->
<svg>
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000">
</feColorMatrix>
</filter>
</svg>
หลีกเลี่ยงการพึ่งพา SVG ในเอกสาร
มาเริ่มต้นส่วนที่ 2 กันก่อน: เราจะหลีกเลี่ยงการเพิ่ม SVG ไปยัง DOM ได้อย่างไร แนวคิดหนึ่งคือย้ายไฟล์ไปยังไฟล์ SVG แยกต่างหาก เราสามารถคัดลอก <svg>…</svg> จาก HTML ข้างต้นและบันทึกเป็น filter.svg แต่เราจำเป็นต้องเปลี่ยนแปลงบางอย่างก่อน SVG ในบรรทัดใน HTML เป็นไปตามกฎการแยกวิเคราะห์ HTML ซึ่งหมายความว่าคุณสามารถหลีกเลี่ยงสิ่งต่างๆ เช่น การละเว้นเครื่องหมายคำพูดเกี่ยวกับค่าแอตทริบิวต์ในบางกรณี อย่างไรก็ตาม SVG ในไฟล์แยกต่างหากควรเป็น XML ที่ถูกต้อง และการแยกวิเคราะห์ XML มีความเข้มงวดกว่า HTML อย่างมาก นี่เป็นข้อมูลโค้ด SVG-in-HTML ของเราอีกครั้ง
<svg>
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000">
</feColorMatrix>
</filter>
</svg>
เราจำเป็นต้องทำการเปลี่ยนแปลงบางอย่างเพื่อทำให้ SVG แบบสแตนด์อโลนที่ถูกต้อง (และด้วย XML) เดาออกไหม
<svg xmlns="http://www.w3.org/2000/svg">
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000" />
</filter>
</svg>
การเปลี่ยนแปลงแรกคือการประกาศเนมสเปซ XML ที่ด้านบน ส่วนที่เพิ่มเข้ามาคือ "solidus" ซึ่งเป็นเครื่องหมายทับที่ระบุแท็ก <feColorMatrix> ทั้งเปิดและปิดองค์ประกอบ จริงๆ แล้วการเปลี่ยนแปลงล่าสุดนี้ไม่มีประโยชน์เสมอไป (เราอาจใช้แท็กปิด </feColorMatrix> ที่ชัดเจนแทนได้) แต่เนื่องจากทั้ง XML และ SVG-in-HTML รองรับชวเลข /> นี้ เราจึงอาจใช้ประโยชน์จากแท็กนี้ได้
อย่างไรก็ตาม ด้วยการเปลี่ยนแปลงเหล่านั้น ในที่สุดเราก็สามารถบันทึกไฟล์นี้เป็นไฟล์ SVG ที่ถูกต้อง และชี้ไปยังไฟล์ดังกล่าวจากค่าพร็อพเพอร์ตี้ CSS filter ในเอกสาร HTML ของเรา
<style>
:root {
filter: url(filters.svg#deuteranopia);
}
</style>
ฮูร์ราห์ เราไม่ต้องแทรก SVG ลงในเอกสารอีกต่อไปแล้ว ซึ่งดีขึ้นมากอยู่แล้ว แต่...ตอนนี้เราต้องใช้ไฟล์แยกต่างหาก ผู้ใช้ยังคงต้องใช้ผลิตภัณฑ์ใด เราจะกำจัดปัญหานี้ได้อย่างไร
เราพบว่าจริงๆ แล้วเราไม่จำเป็นต้องมีไฟล์ เราสามารถเข้ารหัสทั้งไฟล์ภายใน URL โดยใช้ URL ข้อมูล เพื่อให้บรรลุเป้าหมายนี้ เราจะนำเนื้อหาของไฟล์ SVG ที่เรามีอยู่ก่อนหน้านี้ เพิ่มคำนำหน้า data: กำหนดค่าประเภท MIME ที่เหมาะสม จากนั้นเรามี URL ข้อมูลที่ถูกต้องซึ่งแสดงถึงไฟล์ SVG เดียวกันมากๆ ดังนี้
data:image/svg+xml,
<svg xmlns="http://www.w3.org/2000/svg">
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000" />
</filter>
</svg>
ประโยชน์คือ ในตอนนี้เราไม่ต้องจัดเก็บไฟล์ไว้ที่ใด หรือโหลดจากดิสก์หรือผ่านเครือข่ายเพียงเพื่อนำไปใช้ในเอกสาร HTML ของเราอีกต่อไป ดังนั้น แทนที่จะอ้างอิงชื่อไฟล์แบบที่เคยใช้ ตอนนี้เราสามารถชี้ไปที่ URL ของข้อมูลได้แล้ว ดังนี้
<style>
:root {
filter: url('data:image/svg+xml,\
<svg xmlns="http://www.w3.org/2000/svg">\
<filter id="deuteranopia">\
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000\
0.280 0.673 0.047 0.000 0.000\
-0.012 0.043 0.969 0.000 0.000\
0.000 0.000 0.000 1.000 0.000" />\
</filter>\
</svg>#deuteranopia');
}
</style>
ที่ส่วนท้ายของ URL เรายังคงระบุรหัสของตัวกรองที่ต้องการใช้เหมือนก่อนหน้านี้ โปรดทราบว่าไม่จำเป็นต้องเข้ารหัส Base64 ให้กับเอกสาร SVG ใน URL การทำเช่นนี้จะส่งผลเสียต่อความสามารถในการอ่านและเพิ่มขนาดไฟล์เท่านั้น เราใส่แบ็กสแลชไว้ที่ท้ายบรรทัดแต่ละบรรทัดเพื่อให้อักขระการขึ้นบรรทัดใหม่ใน URL ข้อมูลไม่สิ้นสุดลิเทอรัลของสตริง CSS
ที่ผ่านมาเราได้พูดถึงวิธีจำลองภาวะบกพร่องทางการมองเห็นโดยใช้เทคโนโลยีเว็บเท่านั้น เป็นที่น่าสนใจว่าจริงๆ แล้วการติดตั้งใช้งานในฟีเจอร์ Blink Renderer ครั้งสุดท้ายจะค่อนข้างคล้ายกัน นี่คือยูทิลิตีโปรแกรม C++ ที่เราเพิ่มเพื่อสร้าง URL ข้อมูลที่มีคําจํากัดความของตัวกรองที่ระบุโดยใช้เทคนิคเดียวกัน
AtomicString CreateFilterDataUrl(const char* piece) {
AtomicString url =
"data:image/svg+xml,"
"<svg xmlns=\"http://www.w3.org/2000/svg\">"
"<filter id=\"f\">" +
StringView(piece) +
"</filter>"
"</svg>"
"#f";
return url;
}
ต่อไปนี้คือวิธีที่เราใช้เพื่อสร้างตัวกรองทั้งหมดที่เราต้องการ
AtomicString CreateVisionDeficiencyFilterUrl(VisionDeficiency vision_deficiency) {
switch (vision_deficiency) {
case VisionDeficiency::kAchromatopsia:
return CreateFilterDataUrl("…");
case VisionDeficiency::kBlurredVision:
return CreateFilterDataUrl("<feGaussianBlur stdDeviation=\"2\"/>");
case VisionDeficiency::kDeuteranopia:
return CreateFilterDataUrl(
"<feColorMatrix values=\""
" 0.367 0.861 -0.228 0.000 0.000 "
" 0.280 0.673 0.047 0.000 0.000 "
"-0.012 0.043 0.969 0.000 0.000 "
" 0.000 0.000 0.000 1.000 0.000 "
"\"/>");
case VisionDeficiency::kProtanopia:
return CreateFilterDataUrl("…");
case VisionDeficiency::kTritanopia:
return CreateFilterDataUrl("…");
case VisionDeficiency::kNoVisionDeficiency:
NOTREACHED();
return "";
}
}
โปรดทราบว่าเทคนิคนี้ทำให้เราเข้าถึงฟิลเตอร์ SVG ได้เต็มศักยภาพโดยไม่ต้องติดตั้งหรือประดิษฐ์วงล้อขึ้นมาใหม่ เรากำลังจะพัฒนาฟีเจอร์ Blink Renderer แต่ใช้การใช้ประโยชน์จากแพลตฟอร์มเว็บ
เอาล่ะ เราได้เรียนรู้วิธีสร้างตัวกรอง SVG และเปลี่ยนให้เป็น URL ข้อมูลที่เราสามารถใช้ภายในค่าพร็อพเพอร์ตี้ filter ของ CSS ได้ คุณคิดออกว่าเทคนิคนี้มีปัญหาหรือเปล่า ดูเหมือนว่าเราเชื่อถือ URL ข้อมูลที่โหลดไว้ในทุกกรณีไม่ได้ เนื่องจากหน้าเป้าหมายอาจมี Content-Security-Policy ที่บล็อก URL ของข้อมูล การใช้งานระดับ Blink ในขั้นสุดท้ายของเราใช้ความระมัดระวังเป็นพิเศษในการข้าม CSP สำหรับ URL ข้อมูล "ภายใน" เหล่านี้ในระหว่างการโหลด
บางกรณีข้างต้น
เรามีความคืบหน้าไปได้ด้วยดี เนื่องจากเราไม่ได้อาศัย <svg> ในหน้าที่แสดงอยู่ในเอกสารเดียวกันอีกต่อไป เราจึงได้ลดโซลูชันของเราให้เหลือเพียงคำจำกัดความของพร็อพเพอร์ตี้ filter ใน CSS แบบตัวเดียวที่มีอยู่ในเอกสารเดียวกันได้อย่างมีประสิทธิภาพ เยี่ยมเลย เรามาดูวิธีนั้นกัน
หลีกเลี่ยงการพึ่งพา CSS ในเอกสาร
เพื่อเป็นการสรุป นี่คือสถานการณ์ในปัจจุบันของเรา
<style>
:root {
filter: url('data:…');
}
</style>
เรายังคงอาศัยพร็อพเพอร์ตี้ CSS filter นี้ ซึ่งอาจลบล้าง filter ในเอกสารจริงและทำให้สิ่งต่างๆ เสียหาย และจะปรากฏขึ้นเมื่อตรวจสอบรูปแบบที่คำนวณในเครื่องมือสำหรับนักพัฒนาเว็บ ซึ่งอาจสับสนได้ เราจะหลีกเลี่ยงปัญหาเหล่านี้ได้อย่างไร เราต้องหาวิธีเพิ่มตัวกรองลงในเอกสารโดยที่นักพัฒนาแอปไม่สามารถสังเกตการณ์ทางโปรแกรมได้
แนวคิดหนึ่งที่แสดงขึ้นคือการสร้างพร็อพเพอร์ตี้ CSS ภายในของ Chrome ใหม่ที่มีลักษณะการทำงานเหมือน filter แต่มีชื่อต่างกัน เช่น --internal-devtools-filter จากนั้นเราสามารถเพิ่มตรรกะพิเศษเพื่อให้แน่ใจว่าพร็อพเพอร์ตี้นี้จะไม่แสดงในเครื่องมือสำหรับนักพัฒนาเว็บหรือในรูปแบบที่คำนวณใน DOM เรายังสามารถทำให้มันใช้งานได้กับองค์ประกอบเดียวที่เราจำเป็นต้องใช้เท่านั้น ซึ่งก็คือองค์ประกอบรูท อย่างไรก็ตาม วิธีแก้ปัญหานี้ไม่เหมาะนักเนื่องจากเราจะทำซ้ำฟังก์ชันที่มีอยู่แล้วใน filter และแม้ว่าเราจะพยายามซ่อนพร็อพเพอร์ตี้ที่ไม่เป็นมาตรฐานนี้อย่างหนัก นักพัฒนาเว็บก็ยังสามารถค้นหาได้และเริ่มใช้ได้ ซึ่งเป็นสิ่งที่ไม่ดีสำหรับแพลตฟอร์มเว็บ เราต้องการวิธีอื่นในการใช้สไตล์ CSS โดยจะไม่สามารถสังเกตได้ใน DOM คุณมีไอเดียอะไรไหม
ข้อกำหนดของ CSS มีส่วนแนะนำรูปแบบการจัดรูปแบบภาพที่ใช้ และหนึ่งในแนวคิดหลักก็คือวิวพอร์ต นี่คือมุมมองภาพที่ผู้ใช้จะสำรวจหน้าเว็บ แนวคิดที่เกี่ยวข้องกันอย่างมากคือช่วงแรกที่มีการบล็อก ซึ่งคล้ายกับวิวพอร์ตที่จัดรูปแบบได้ <div> ซึ่งมีอยู่ที่ระดับข้อมูลจำเพาะเท่านั้น ข้อกำหนดดังกล่าวหมายถึงแนวคิด “วิวพอร์ต” ทั่วทั้งตำแหน่ง ตัวอย่างเช่น คุณทราบวิธีที่เบราว์เซอร์แสดงแถบเลื่อนเมื่อเนื้อหาปรับไม่ได้ ซึ่งทั้งหมดกำหนดในข้อกำหนดของ CSS โดยอิงตาม "วิวพอร์ต" นี้
viewport นี้อยู่ใน Blink Renderer รวมถึงรายละเอียดการใช้งาน นี่คือโค้ดที่นำรูปแบบวิวพอร์ตเริ่มต้นมาใช้ตามข้อกำหนดเฉพาะ
scoped_refptr<ComputedStyle> StyleResolver::StyleForViewport() {
scoped_refptr<ComputedStyle> viewport_style =
InitialStyleForElement(GetDocument());
viewport_style->SetZIndex(0);
viewport_style->SetIsStackingContextWithoutContainment(true);
viewport_style->SetDisplay(EDisplay::kBlock);
viewport_style->SetPosition(EPosition::kAbsolute);
viewport_style->SetOverflowX(EOverflow::kAuto);
viewport_style->SetOverflowY(EOverflow::kAuto);
// …
return viewport_style;
}
คุณไม่จำเป็นต้องเข้าใจ C++ หรือความซับซ้อนของ Blink's Style Engine เพื่อที่จะเห็นว่าโค้ดนี้จัดการกับ z-index, display, position และ overflow ของวิวพอร์ต (หรือถูกต้องกว่านั้น เช่น ค่าเริ่มต้นที่มีบล็อก) ซึ่งทั้งหมดนี้คือแนวคิดที่คุณอาจคุ้นเคยจาก CSS มีความพิเศษอื่นๆ อีกอย่างหนึ่งที่เกี่ยวข้องกับบริบทแบบซ้อน ซึ่งจะไม่แปลเป็นพร็อพเพอร์ตี้ CSS โดยตรง แต่โดยรวมแล้วคุณคิดว่าออบเจ็กต์ viewport นี้เป็นสิ่งที่สามารถจัดรูปแบบโดยใช้ CSS จากภายใน Blink ได้เช่นเดียวกับองค์ประกอบ DOM ยกเว้นกรณีที่ไม่ได้เป็นส่วนหนึ่งของ DOM
ซึ่งให้คำตอบที่เราต้องการ เราสามารถใช้รูปแบบ filter กับออบเจ็กต์ viewport ซึ่งจะส่งผลต่อการแสดงผลโดยไม่รบกวนรูปแบบหน้าเว็บที่สังเกตได้หรือ DOM แต่อย่างใด
บทสรุป
กล่าวโดยสรุปก็คือ เราเริ่มต้นจากการสร้างต้นแบบโดยใช้เทคโนโลยีเว็บแทน C++ แล้วเริ่มย้ายบางส่วนของโมเดลนี้ไปไว้ใน Blink Renderer
- ตอนแรกเราสร้างต้นแบบขึ้นมาให้สมบูรณ์แบบมากขึ้นด้วยการใส่ URL ข้อมูลแบบอินไลน์
- จากนั้นเราได้ทำให้ URL ของข้อมูลภายในของ CSP ใช้งานได้ง่ายโดยใช้ตัวพิมพ์เล็ก/ใหญ่พิเศษในการโหลด
- เราทำให้การใช้งานแบบ DOM-Agnos และไม่สามารถสังเกตแบบเป็นโปรแกรมได้ด้วยการย้ายรูปแบบไปยัง
viewportของ Blink-internal
สิ่งที่ไม่เหมือนใครในการติดตั้งใช้งานนี้คือต้นแบบของ HTML/CSS/SVG ที่มีอิทธิพลต่อการออกแบบทางเทคนิคขั้นสุดท้าย เราพบวิธีใช้แพลตฟอร์มเว็บ แม้กระทั่งภายใน Blink Renderer
หากต้องการทราบข้อมูลพื้นฐานเพิ่มเติม โปรดดูข้อเสนอการออกแบบของเราหรือข้อบกพร่องในการติดตามของ Chromium ซึ่งอ้างอิงถึงแพตช์ที่เกี่ยวข้องทั้งหมด
ดาวน์โหลดช่องตัวอย่าง
ลองใช้ Chrome Canary, Dev หรือเบต้าเป็นเบราว์เซอร์สำหรับการพัฒนาเริ่มต้น ช่องทางแสดงตัวอย่างเหล่านี้ช่วยให้คุณได้เข้าถึงฟีเจอร์ล่าสุดของเครื่องมือสำหรับนักพัฒนาเว็บ ทดสอบ API แพลตฟอร์มเว็บที่ล้ำสมัย และค้นหาปัญหาในเว็บไซต์ก่อนที่ผู้ใช้จะได้ใช้งาน
ติดต่อทีมเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
ใช้ตัวเลือกต่อไปนี้เพื่อพูดคุยเกี่ยวกับฟีเจอร์ใหม่ๆ และการเปลี่ยนแปลงในโพสต์ หรือเรื่องอื่นๆ ที่เกี่ยวข้องกับเครื่องมือสำหรับนักพัฒนาเว็บ
- ส่งคำแนะนำหรือความคิดเห็นถึงเราผ่าน crbug.com
- รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บโดยใช้ตัวเลือกเพิ่มเติม
> ความช่วยเหลือ > รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บในเครื่องมือสำหรับนักพัฒนาเว็บ - ทวีตที่ @ChromeDevTools
- โปรดแสดงความคิดเห็นในวิดีโอ YouTube เกี่ยวกับมีอะไรใหม่ในเครื่องมือสำหรับนักพัฒนาเว็บในวิดีโอ YouTube หรือเคล็ดลับสำหรับเครื่องมือสำหรับนักพัฒนาเว็บ