บทความนี้อธิบายเหตุผลและวิธีที่เราใช้การจําลองการมองเห็นสีบกพร่องในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์และโปรแกรมแสดงผล Blink
พื้นหลัง: คอนทราสต์ของสีไม่ดี
ข้อความคอนทราสต์ต่ำเป็นปัญหาการช่วยเหลือพิเศษที่พบบ่อยที่สุดซึ่งตรวจพบได้อัตโนมัติบนเว็บ
จากการวิเคราะห์การช่วยเหลือพิเศษของ WebAIM สําหรับเว็บไซต์ยอดนิยม 1 ล้านเว็บไซต์ หน้าแรกกว่า 86% มีคอนทราสต์ต่ำ โดยเฉลี่ยแล้ว หน้าแรกแต่ละหน้ามีข้อความคอนทราสต์ต่ำ36 อินสแตนซ์ที่แตกต่างกัน
การใช้เครื่องมือสำหรับนักพัฒนาเว็บเพื่อค้นหา ทำความเข้าใจ และแก้ไขปัญหาคอนทราสต์
เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome จะช่วยนักพัฒนาซอฟต์แวร์และนักออกแบบปรับปรุงคอนทราสต์และเลือกชุดสีที่เข้าถึงได้ง่ายขึ้นสำหรับเว็บแอปได้ ดังนี้
- เคล็ดลับเครื่องมือของโหมดตรวจสอบที่ปรากฏที่ด้านบนของหน้าเว็บจะแสดงอัตราส่วนคอนทราสต์ขององค์ประกอบข้อความ
- เครื่องมือเลือกสีของ DevTools จะระบุอัตราส่วนคอนทราสต์ที่ไม่เหมาะสมสำหรับองค์ประกอบข้อความ แสดงเส้นคอนทราสต์ที่แนะนำเพื่อช่วยเลือกสีที่ดีขึ้นด้วยตนเอง และยังสามารถแนะนำสีที่เข้าถึงได้
- ทั้งแผงภาพรวม CSS และรายงานการตรวจสอบการช่วยเหลือพิเศษของ Lighthouse จะแสดงรายการองค์ประกอบข้อความที่มีคอนทราสต์ต่ำซึ่งพบในหน้าเว็บ
เราเพิ่งเพิ่มเครื่องมือใหม่ลงในรายการนี้ซึ่งแตกต่างจากเครื่องมืออื่นๆ เล็กน้อย เครื่องมือข้างต้นมุ่งเน้นที่แสดงข้อมูลอัตราส่วนคอนทราสต์เป็นหลักและให้ตัวเลือกในการแก้ไข เราพบว่า DevTools ยังไม่มีวิธีที่จะช่วยให้นักพัฒนาแอปเข้าใจปัญหานี้ได้ดียิ่งขึ้น เพื่อแก้ไขปัญหานี้ เราได้ใช้การจำลองภาวะบกพร่องทางการมองเห็นในแท็บการแสดงผลของเครื่องมือสำหรับนักพัฒนาเว็บ
ใน Puppeteer page.emulateVisionDeficiency(type) API ใหม่ช่วยให้คุณเปิดใช้การจําลองเหล่านี้แบบเป็นโปรแกรมได้
ภาวะบกพร่องในการมองเห็นสี
ประมาณ 1 ใน 20 คนมีภาวะบกพร่องในการมองเห็นสี (หรือที่เรียกว่า "ตาบอดสี" ซึ่งมีชื่อที่ไม่ค่อยถูกต้องเท่าไหร่) ความบกพร่องเช่นนี้ทำให้แยกสีต่างๆ ได้ยากขึ้น ซึ่งจะเพิ่มปัญหาคอนทราสต์ได้
ในฐานะนักพัฒนาซอฟต์แวร์ที่มีสายตาปกติ คุณอาจเห็นว่าเครื่องมือสำหรับนักพัฒนาเว็บแสดงอัตราส่วนคอนทราสต์ไม่ดีสำหรับคู่สีที่มองดูแล้วโอเค ปัญหานี้เกิดขึ้นเนื่องจากสูตรอัตราส่วนคอนทราสต์คำนึงถึงข้อบกพร่องในการมองเห็นสีเหล่านี้ คุณอาจยังอ่านข้อความที่มีคอนทราสต์ต่ำได้ในบางกรณี แต่ผู้ที่มีปัญหาด้านการมองเห็นจะไม่มีสิทธิ์นั้น
เรามุ่งมั่นที่จะมอบสิ่งที่ขาดหายไปด้วยการอนุญาตให้นักออกแบบและนักพัฒนาแอปจำลองผลกระทบของข้อบกพร่องด้านการมองเห็นเหล่านี้ในเว็บแอปของตนเอง ซึ่งไม่เพียงช่วยให้ DevTools ช่วยคุณค้นหาและแก้ไขปัญหาคอนทราสต์เท่านั้น แต่ยังช่วยให้คุณเข้าใจปัญหาเหล่านี้ได้ด้วย
การจำลองภาวะบกพร่องในการมองเห็นสีด้วย HTML, CSS, SVG และ C++
ก่อนที่จะเจาะลึกการใช้งานโปรแกรมแสดงผล Blink ของฟีเจอร์นี้ เราขออธิบายให้คุณเข้าใจวิธีใช้ฟังก์ชันการทำงานที่เทียบเท่าโดยใช้เทคโนโลยีเว็บ
คุณอาจคิดว่าการจําลองการมองเห็นสีบกพร่องแต่ละรายการเป็นการวางซ้อนที่ครอบคลุมทั้งหน้า แพลตฟอร์มเว็บมีวิธีดำเนินการดังกล่าว ซึ่งก็คือฟิลเตอร์ CSS เมื่อใช้พร็อพเพอร์ตี้ filter ของ CSS คุณจะใช้ฟังก์ชันตัวกรองที่กําหนดไว้ล่วงหน้าได้ เช่น 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 อาจละเมิดสมมติฐานเหล่านี้
นอกเหนือจากกรณีขอบแล้ว ปัญหาหลักของแนวทางนี้คือเราจะทําการเปลี่ยนแปลงหน้าเว็บที่สังเกตได้แบบเป็นโปรแกรม หากผู้ใช้ DevTools ตรวจสอบ DOM ผู้ใช้อาจเห็นองค์ประกอบ <svg> ที่ไม่เคยเพิ่ม หรือ filter CSS ที่ไม่เคยเขียน การทำเช่นนั้นจะทำให้สับสน หากต้องการใช้ฟังก์ชันนี้ในเครื่องมือสำหรับนักพัฒนาเว็บ เราต้องใช้โซลูชันที่ไม่มีข้อเสียเหล่านี้
มาดูกันว่าเราจะทำให้ผู้ชมรบกวนคุณน้อยลงได้อย่างไร โซลูชันนี้มี 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>
การหลีกเลี่ยงทรัพยากร Dependency ของ SVG ในเอกสาร
มาเริ่มกันที่ส่วนที่ 2: เราจะหลีกเลี่ยงการเพิ่ม SVG ลงใน DOM ได้อย่างไร 1 วิธีคือย้ายไปยังไฟล์ SVG แยกต่างหาก เราคัดลอก <svg>…</svg> จาก HTML ด้านบนและบันทึกเป็น filter.svg ได้ แต่ต้องทําการเปลี่ยนแปลงบางอย่างก่อน SVG ในบรรทัดของ HTML เป็นไปตามกฎการแยกวิเคราะห์ HTML ซึ่งหมายความว่าคุณอาจไม่ต้องทำสิ่งต่างๆ เช่น การละเว้นเครื่องหมายคำพูดรอบๆ ค่าแอตทริบิวต์ในบางกรณี อย่างไรก็ตาม SVG ในไฟล์แยกต่างหากควรเป็น XML ที่ถูกต้อง และการแยกวิเคราะห์ XML มีความเข้มงวดมากกว่า HTML ข้อมูลโค้ด SVG ใน 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 ที่ด้านบน ส่วนการเพิ่มที่ 2 คือสิ่งที่เรียกว่า "เครื่องหมายทับ" ซึ่งเป็นเครื่องหมายทับที่บ่งบอกว่าแท็ก <feColorMatrix> ทั้งเปิดและปิดองค์ประกอบ การเปลี่ยนแปลงครั้งล่าสุดนี้ไม่จำเป็นจริงๆ (เราอาจใช้แท็กปิด </feColorMatrix> แบบชัดเจนแทน) แต่เนื่องจากทั้ง XML และ SVG ใน HTML รองรับเครื่องหมาย </feColorMatrix> คร่าวๆ นี้ เราจึงอาจใช้ประโยชน์จากเครื่องหมายดังกล่าว/>
อย่างไรก็ตาม เมื่อทำการเปลี่ยนแปลงดังกล่าวแล้ว เราจึงบันทึกไฟล์นี้เป็นไฟล์ SVG ที่ถูกต้องได้ในที่สุด และชี้ไปยังไฟล์จากค่าพร็อพเพอร์ตี้ filter ของ CSS ในเอกสาร 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 นั้นคล้ายกันมาก ต่อไปนี้คือยูทิลิตีโปรแกรมช่วย 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> ในบรรทัดที่แสดงอยู่ในเอกสารเดียวกันอีกต่อไป เราจึงลดโซลูชันลงเหลือเพียงคำจำกัดความของพร็อพเพอร์ตี้ CSS filter ในตัวเพียงค่าเดียว เยี่ยม! ตอนนี้มากำจัดสิ่งนั้นกัน
หลีกเลี่ยงการพึ่งพา CSS ในเอกสาร
เราขอสรุปข้อมูลว่าเราดำเนินการไปถึงไหนแล้ว
<style>
:root {
filter: url('data:…');
}
</style>
เรายังคงใช้พร็อพเพอร์ตี้ filter ของ CSS นี้อยู่ ซึ่งอาจลบล้าง filter ในเอกสารจริงและทำให้ระบบใช้งานไม่ได้ และก็จะแสดงขึ้นเมื่อตรวจสอบสไตล์ที่คอมไพล์แล้วในเครื่องมือสำหรับนักพัฒนาเว็บด้วย ซึ่งอาจทำให้เกิดความสับสน เราจะหลีกเลี่ยงปัญหาเหล่านี้ได้อย่างไร เราต้องหาวิธีเพิ่มตัวกรองลงในเอกสารโดยที่นักพัฒนาแอปไม่สามารถสังเกตเห็นได้แบบเป็นโปรแกรม
มีแนวคิดหนึ่งขึ้นมาคือการสร้างพร็อพเพอร์ตี้ CSS ภายในของ Chrome ใหม่ซึ่งทำงานเหมือน filter แต่มีชื่ออื่น เช่น --internal-devtools-filter จากนั้นเราอาจเพิ่มตรรกะพิเศษเพื่อให้แน่ใจว่าพร็อพเพอร์ตี้นี้จะไม่แสดงในเครื่องมือสำหรับนักพัฒนาเว็บหรือในสไตล์ที่คอมไพล์แล้วใน DOM เรายังตรวจสอบได้ว่าการทำงานจะส่งผลต่อองค์ประกอบเดียวที่เราต้องการเท่านั้น ซึ่งก็คือองค์ประกอบรูท อย่างไรก็ตาม โซลูชันนี้ไม่ใช่วิธีที่ดีที่สุด เนื่องจากเราจะทำซ้ำฟังก์ชันที่มีอยู่แล้วใน filter และแม้ว่าเราจะพยายามซ่อนพร็อพเพอร์ตี้ที่ไม่ใช่มาตรฐานนี้ แต่นักพัฒนาเว็บก็อาจค้นพบและเริ่มใช้พร็อพเพอร์ตี้ดังกล่าวได้ ซึ่งจะเป็นผลเสียต่อแพลตฟอร์มเว็บ เราต้องการวิธีอื่นในการใช้สไตล์ CSS โดยที่ DOM มองไม่เห็น คุณพอจะมีใครแนะนำบ้างไหม
ข้อกำหนด CSS มีส่วนแนะนำรูปแบบการจัดรูปแบบภาพที่ใช้ และหนึ่งในแนวคิดหลักคือวิวพอร์ต นี่คือมุมมองแบบภาพที่ผู้ใช้ต้องดูในหน้าเว็บ แนวคิดที่เกี่ยวข้องอย่างใกล้ชิดคือบล็อกที่บรรจุข้อมูลเริ่มต้น ซึ่งคล้ายกับวิวพอร์ตที่ปรับแต่งสไตล์ได้ <div> ที่มีเฉพาะในระดับข้อกำหนดเท่านั้น ข้อมูลจำเพาะหมายถึงแนวคิด "วิวพอร์ต" นี้ในทุกตำแหน่ง เช่น คุณทราบไหมว่าเบราว์เซอร์แสดงแถบเลื่อนอย่างไรเมื่อเนื้อหาไม่พอดี ซึ่งทั้งหมดนี้ระบุไว้ในข้อกําหนด CSS โดยอิงตาม "วิวพอร์ต" นี้
viewport นี้อยู่ในโปรแกรมแสดงผล Blink ด้วยเช่นกัน โดยเป็นรายละเอียดการใช้งาน นี่คือโค้ดที่ใช้รูปแบบวิวพอร์ตเริ่มต้นตามข้อกําหนด
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 เพื่อดูว่าโค้ดนี้จัดการ z-index, display, position และ overflow ของวิวพอร์ต (หรือที่ถูกต้องกว่านั้นคือของบล็อกที่บรรจุเริ่มต้น) แนวคิดทั้งหมดเหล่านี้เป็นแนวคิดที่คุณอาจคุ้นเคยจาก CSS นอกจากนี้ยังมีการทำงานอื่นๆ ที่เกี่ยวข้องกับบริบทการซ้อน ซึ่งไม่ได้แปลเป็นพร็อพเพอร์ตี้ CSS โดยตรง แต่โดยรวมแล้ว คุณอาจคิดว่าออบเจ็กต์ viewport นี้เป็นออบเจ็กต์ที่กำหนดสไตล์ได้โดยใช้ CSS จากภายใน Blink เช่นเดียวกับองค์ประกอบ DOM เพียงแต่ไม่ได้เป็นส่วนหนึ่งของ DOM
ซึ่งช่วยให้เราได้รับสิ่งที่ต้องการ เราสามารถใช้สไตล์ filter กับออบเจ็กต์ viewport ซึ่งส่งผลต่อการแสดงผลภาพได้ โดยไม่รบกวนสไตล์หน้าเว็บที่สังเกตได้หรือ DOM แต่อย่างใด
บทสรุป
กล่าวโดยสรุปเกี่ยวกับเส้นทางเล็กๆ ในที่นี้ เราเริ่มจากการสร้างต้นแบบโดยใช้เทคโนโลยีเว็บแทน C++ จากนั้นจึงเริ่มย้ายส่วนต่างๆ ของภาพไปยัง Blink Renderer
- ก่อนอื่น เราทำให้โปรโตไทป์มีความสมบูรณ์มากขึ้นด้วยการใช้ URL ของข้อมูลในบรรทัด
- จากนั้นเราจึงทำให้ URL ของข้อมูลภายในของ CSP เหมาะกับ CSP ด้วยการเขียนตัวพิมพ์เล็ก/ใหญ่พิเศษ
- เราได้ทําให้การใช้งานของเราไม่เกี่ยวข้องกับ DOM และไม่สามารถสังเกตได้แบบเป็นโปรแกรมโดยย้ายสไตล์ไปยัง
viewportภายใน Blink
สิ่งที่พิเศษเกี่ยวกับการติดตั้งใช้งานนี้คือต้นแบบ HTML/CSS/SVG ของเราส่งผลต่อการออกแบบทางเทคนิคขั้นสุดท้าย เราพบวิธีใช้แพลตฟอร์มเว็บแม้ในโปรแกรมแสดงผล Blink
ดูข้อมูลเบื้องต้นเพิ่มเติมได้ที่ข้อเสนอการออกแบบหรือข้อบกพร่องการติดตามของ Chromium ซึ่งอ้างอิงถึงแพตช์ที่เกี่ยวข้องทั้งหมด
ดาวน์โหลดแชแนลตัวอย่าง
ลองใช้ Chrome Canary, Dev หรือ เบต้า เป็นเบราว์เซอร์สำหรับนักพัฒนาซอฟต์แวร์เริ่มต้น ช่องทางเวอร์ชันตัวอย่างเหล่านี้จะช่วยให้คุณเข้าถึงฟีเจอร์ล่าสุดของ DevTools, ทดสอบ API ของแพลตฟอร์มเว็บที่ล้ำสมัย และช่วยคุณค้นหาปัญหาในเว็บไซต์ได้ก่อนที่ผู้ใช้จะพบ
ติดต่อทีมเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
ใช้ตัวเลือกต่อไปนี้เพื่อพูดคุยเกี่ยวกับฟีเจอร์ใหม่ การอัปเดต หรือสิ่งอื่นๆ ที่เกี่ยวข้องกับเครื่องมือสำหรับนักพัฒนาเว็บ
- ส่งความคิดเห็นและคำขอฟีเจอร์ถึงเราที่ crbug.com
- รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บโดยใช้ ตัวเลือกเพิ่มเติม > ความช่วยเหลือ > รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บในเครื่องมือสำหรับนักพัฒนาเว็บ
- ทวีตที่ @ChromeDevTools
- แสดงความคิดเห็นในวิดีโอ YouTube เกี่ยวกับข่าวสารใน DevTools หรือวิดีโอ YouTube เกี่ยวกับเคล็ดลับใน DevTools