การจำลองภาวะบกพร่องในการมองเห็นสีในเครื่องมือแสดงภาพกะพริบ

บทความนี้อธิบายเหตุผลและวิธีที่เราใช้การจำลองภาวะบกพร่องในการมองเห็นสีในเครื่องมือสำหรับนักพัฒนาเว็บและ Blink Renderer

พื้นหลัง: สีตัดกันไม่ดี

ข้อความคอนทราสต์ต่ำเป็นปัญหาการช่วยเหลือพิเศษที่ตรวจพบโดยอัตโนมัติที่พบได้บ่อยที่สุดในเว็บ

รายการปัญหาการช่วยเหลือพิเศษที่พบได้ทั่วไปบนเว็บ ข้อความคอนทราสต์ต่ำเป็นสาเหตุที่พบบ่อยที่สุด

จากการวิเคราะห์ความสามารถเข้าถึงได้ง่ายของ WebAIM ถึงเว็บไซต์ยอดนิยม 1 ล้านเว็บ พบว่าหน้าแรกกว่า 86% มีความคมชัดต่ำ โดยเฉลี่ยแล้ว หน้าแรกแต่ละหน้าจะมีข้อความคอนทราสต์ต่ำ36 อินสแตนซ์ที่แตกต่างกัน

การใช้เครื่องมือสำหรับนักพัฒนาเว็บเพื่อค้นหา ทำความเข้าใจ และแก้ไขปัญหาคอนทราสต์

เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สามารถช่วยนักพัฒนาซอฟต์แวร์และนักออกแบบปรับปรุงคอนทราสต์และเลือกรูปแบบสีที่เข้าถึงได้มากขึ้นสำหรับเว็บแอป ดังนี้

เราเพิ่งเพิ่มเครื่องมือใหม่ลงในรายการนี้ซึ่งแตกต่างจากรายการอื่นๆ เล็กน้อย เครื่องมือข้างต้นจะเน้นการแสดงข้อมูลอัตราส่วนคอนทราสต์เป็นหลักและให้ตัวเลือกในการแก้ไข เราพบว่าเครื่องมือสำหรับนักพัฒนาเว็บยังขาดวิธีที่จะช่วยให้นักพัฒนาแอปเข้าใจปัญหาดังกล่าวอย่างลึกซึ้งยิ่งขึ้น เพื่อแก้ไขปัญหานี้ เราได้ใช้การจำลองภาวะบกพร่องทางการมองเห็นในแท็บการแสดงผลของเครื่องมือสำหรับนักพัฒนาเว็บ

ใน Puppeteer page.emulateVisionDeficiency(type) API ใหม่ให้คุณเปิดใช้การจำลองเหล่านี้แบบเป็นโปรแกรมได้

ภาวะบกพร่องในการมองเห็นสี

ประมาณ 1 ใน 20 คนมีภาวะบกพร่องในการมองเห็นสี (หรือที่เรียกว่า "ตาบอดสี" ซึ่งมีชื่อที่ไม่ค่อยถูกต้องเท่าไหร่) ความบกพร่องเช่นนี้ทำให้แยกสีต่างๆ ได้ยากขึ้น ซึ่งอาจเพิ่มปัญหาคอนทราสต์ได้

วันที่ ภาพสีสันสดใสของสีเทียนละลายที่ไม่มีความบกพร่องทางการมองเห็นสี
ภาพสีเทียนละลายสีสันสดใส โดยไม่มีการจำลองภาวะบกพร่องทางการมองเห็นสี
ALT_TEXT_HERE
ผลกระทบของการจำลองภาวะตาบอดสีทุกสีบนภาพสีสันสดใสของสีเทียนที่ละลาย
ผลกระทบของการจำลองภาวะตาบอดสีเขียวบนภาพสีสันสดใสของสีเทียนที่ละลาย
ผลกระทบของการจำลองภาวะตาบอดสีเขียวบนภาพสีสันสดใสของสีเทียนที่ละลาย
ผลกระทบของการจำลองภาวะตาบอดสีแดงในรูปภาพสีสันสดใสของสีเทียนที่ละลาย
ผลกระทบของการจำลองภาวะตาบอดสีแดงในรูปภาพสีสันสดใสของสีเทียนที่ละลาย
ผลกระทบของการจำลองภาวะตาบอดสีน้ำเงินในภาพสีสันสดใสของสีเทียนที่ละลาย
ผลกระทบของการจำลองภาวะตาบอดสีน้ำเงินในภาพสีสันสดใสของสีเทียนที่ละลาย

ในฐานะนักพัฒนาซอฟต์แวร์ที่มีสายตาปกติ คุณอาจเห็นว่าเครื่องมือสำหรับนักพัฒนาเว็บแสดงอัตราส่วนคอนทราสต์ที่ไม่ดีสำหรับคู่สีที่ดูโอเคสำหรับคุณ ที่เป็นเช่นนี้เพราะสูตรอัตราส่วนคอนทราสต์จะพิจารณาความบกพร่องทางการมองเห็นสีเหล่านี้ด้วย! ในบางกรณี คุณอาจยังอ่านข้อความที่มีคอนทราสต์ต่ำได้ แต่ผู้ที่มีความบกพร่องทางสายตาจะไม่มีสิทธิ์นั้น

ในการให้นักออกแบบและนักพัฒนาซอฟต์แวร์จำลองผลกระทบของข้อบกพร่องทางการมองเห็นเหล่านี้ที่มีต่อเว็บแอปของตนเอง เรามุ่งหวังที่จะให้ส่วนที่ขาดหายไปซึ่งเครื่องมือนี้ไม่เพียงแค่ช่วยคุณค้นหาและแก้ไขปัญหาคอนทราสต์เท่านั้น แต่ตอนนี้คุณยังทำความเข้าใจปัญหาดังกล่าวได้ด้วย

การจำลองภาวะบกพร่องในการมองเห็นสีด้วย HTML, CSS, SVG และ C++

ก่อนที่เราจะเจาะลึกรายละเอียดเกี่ยวกับการใช้งาน Blink Renderer ของฟีเจอร์ดังกล่าว เราจะช่วยให้คุณเข้าใจวิธีที่คุณจะนำฟังก์ชันที่เทียบเท่าไปใช้โดยใช้เทคโนโลยีเว็บ

ให้ลองนึกภาพการจำลองภาวะบกพร่องในการมองเห็นสีแต่ละครั้งเป็นเหมือนการซ้อนทับที่บดบังทั้งหน้า แพลตฟอร์มแบบเว็บเองก็มีวิธีทำแบบนั้น นั่นคือตัวกรอง 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 คือสีน้ำเงิน และแถวสุดท้ายคือ Alpha

คุณอาจสงสัยว่าตัวเลขในตัวอย่างของเรามาจากไหน อะไรที่ทำให้เมตริกซ์สีนี้เป็นค่าประมาณที่ดีของภาวะตาบอดสีเขียว คำตอบก็คือวิทยาศาสตร์! ค่าเหล่านี้อิงตามโมเดลจำลองภาวะบกพร่องในการมองเห็นสีที่ถูกต้องแม่นยำโดย 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>

การหลีกเลี่ยงทรัพยากร Dependency ของ 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 ที่ด้านบน การเพิ่มที่ 2 คือสิ่งที่เรียกว่า "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 เราจะยังคงระบุรหัสของตัวกรองที่ต้องการใช้เช่นเดียวกับก่อนหน้านี้ โปรดทราบว่าไม่จำเป็นต้องเข้ารหัสเอกสาร SVG ใน URL ด้วย Base64 เพราะจะส่งผลเสียต่อความสามารถในการอ่านและเพิ่มขนาดไฟล์ เราเพิ่มแบ็กสแลชที่ท้ายแต่ละบรรทัดเพื่อให้มั่นใจว่าอักขระขึ้นบรรทัดใหม่ใน 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 ของข้อมูลที่เราใช้ภายในค่าพร็อพเพอร์ตี้ CSS filter ได้ คุณลองนึกถึงเทคนิคนี้ได้ไหม ผลปรากฏออกมาว่า เราไม่สามารถอาศัย URL ข้อมูลที่โหลดในทุกกรณีได้เนื่องจากหน้าเป้าหมายอาจมี Content-Security-Policy ที่บล็อก URL ข้อมูล การใช้งานระดับ Blink สุดท้ายของเราใช้ความระมัดระวังเป็นพิเศษในการข้าม CSP สำหรับ URL ข้อมูล "ภายใน" เหล่านี้ระหว่างการโหลด

นอกจากจะมีปัญหาบางอย่าง เราก็คืบหน้าไปได้เรื่อยๆ ด้วย เนื่องจากเราไม่อาศัย <svg> ในบรรทัดที่แสดงอยู่ในเอกสารเดียวกันอีกต่อไป เราจึงลดโซลูชันลงเหลือเพียงคำจำกัดความของพร็อพเพอร์ตี้ CSS filter ในตัวเพียงรายการเดียว เยี่ยม! ตอนนี้เราก็มาลองแก้ปัญหาเหล่านั้นด้วยกันดีกว่า

การหลีกเลี่ยงทรัพยากร Dependency ของ CSS ในเอกสาร

ขอสรุปสั้นๆ ว่าตอนนี้เราอยู่ ณ จุดใด

<style>
  :root {
    filter: url('data:…');
  }
</style>

เรายังคงใช้พร็อพเพอร์ตี้ filter ของ CSS นี้ ซึ่งอาจลบล้าง filter ในเอกสารจริงและทำให้สิ่งต่างๆ เสียหาย และไอคอนดังกล่าวจะปรากฏขึ้นเมื่อตรวจสอบรูปแบบที่คำนวณในเครื่องมือสำหรับนักพัฒนาเว็บด้วย ซึ่งทำให้สับสนได้ เราจะหลีกเลี่ยงปัญหาเหล่านี้ได้อย่างไร เราต้องหาวิธีเพิ่มตัวกรองลงในเอกสารโดยที่นักพัฒนาซอฟต์แวร์จะสังเกตการณ์โดยใช้ตัวกรองไม่ได้

มีแนวคิดหนึ่งขึ้นมาคือการสร้างพร็อพเพอร์ตี้ CSS ภายในของ Chrome ใหม่ซึ่งมีลักษณะการทํางานเหมือน filter แต่มีชื่ออื่น เช่น --internal-devtools-filter จากนั้นเราจะเพิ่มตรรกะพิเศษเพื่อให้มั่นใจว่าพร็อพเพอร์ตี้นี้จะไม่ปรากฏในเครื่องมือสำหรับนักพัฒนาเว็บหรือในรูปแบบที่คำนวณใน DOM เรายังสามารถตรวจสอบว่า URL ใช้งานได้กับองค์ประกอบเดียวที่เราต้องการ นั่นก็คือองค์ประกอบราก อย่างไรก็ตาม โซลูชันนี้คงไม่เหมาะสม เพราะเราจะสร้างฟังก์ชันการทำงานที่ซ้ำกันใน 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 เพื่อดูว่าโค้ดนี้จะจัดการ z-index, display, position และ overflow ของวิวพอร์ต (หรือถูกต้องมากกว่า ซึ่งก็คือโค้ดแรกที่มีการบล็อก) นี่เป็นแนวคิดทั้งหมดที่คุณอาจคุ้นเคยจาก CSS แล้ว นอกจากนี้ยังมีความสามารถอื่นๆ ที่เกี่ยวข้องกับการเรียงบริบทแบบซ้อนกัน ซึ่งไม่ได้แปลงเป็นพร็อพเพอร์ตี้ CSS โดยตรง แต่โดยรวมแล้วคุณอาจมองออบเจ็กต์ viewport นี้ว่าเป็นสิ่งที่จัดรูปแบบได้โดยใช้ CSS จากภายใน Blink เช่นเดียวกับองค์ประกอบ DOM เว้นแต่จะไม่ได้เป็นส่วนหนึ่งของ DOM

ซึ่งเป็นสิ่งที่เราต้องการจริงๆ เราอาจใช้สไตล์ filter กับออบเจ็กต์ viewport ซึ่งส่งผลต่อการแสดงผล โดยไม่รบกวนสไตล์หน้าเว็บที่สังเกตได้หรือ DOM แต่อย่างใด

บทสรุป

กล่าวโดยสรุปเกี่ยวกับเส้นทางเล็กๆ ในที่นี้ เราเริ่มจากการสร้างต้นแบบโดยใช้เทคโนโลยีเว็บแทน C++ จากนั้นจึงเริ่มย้ายส่วนต่างๆ ของภาพไปยัง Blink Renderer

  • เริ่มแรกเราทำให้ตัวต้นแบบของเราทำงานได้ในตัวเองมากขึ้นด้วยการใส่ URL ข้อมูลในบรรทัด
  • จากนั้นเราจึงทำให้ URL ของข้อมูลภายในของ CSP เหมาะกับ CSP ด้วยการเขียนตัวพิมพ์เล็ก/ใหญ่พิเศษ
  • เราทําให้การใช้งาน DOM-Agnostic และไม่สามารถสังเกตได้แบบเป็นโปรแกรมด้วยการย้ายสไตล์ไปยัง viewport ภายใน Blink

สิ่งที่โดดเด่นเกี่ยวกับการติดตั้งใช้งานนี้คือ ต้นแบบ HTML/CSS/SVG ของเรามีอิทธิพลต่อการออกแบบทางเทคนิคในขั้นสุดท้าย เราพบวิธีใช้แพลตฟอร์มเว็บ แม้ใน Blink Renderer ก็ตาม

หากต้องการทราบข้อมูลพื้นฐานเพิ่มเติม โปรดดูข้อเสนอการออกแบบของเราหรือข้อบกพร่องในการติดตามของ Chromium ซึ่งอ้างอิงแพตช์ที่เกี่ยวข้องทั้งหมด

ดาวน์โหลดเวอร์ชันตัวอย่าง

ลองใช้ Chrome Canary, Dev หรือ เบต้า เป็นเบราว์เซอร์เริ่มต้นสำหรับการพัฒนา ช่องทางพรีวิวเหล่านี้จะทำให้คุณเข้าถึงฟีเจอร์ล่าสุดของเครื่องมือสำหรับนักพัฒนาเว็บ ทดสอบ API แพลตฟอร์มเว็บที่ล้ำสมัย และพบปัญหาในเว็บไซต์ก่อนผู้ใช้

ติดต่อทีม Chrome DevTools

ใช้ตัวเลือกต่อไปนี้เพื่อพูดคุยเกี่ยวกับฟีเจอร์ใหม่และการเปลี่ยนแปลงในโพสต์ หรืออื่นๆ ที่เกี่ยวข้องกับเครื่องมือสำหรับนักพัฒนาเว็บ

  • ส่งข้อเสนอแนะหรือความคิดเห็นถึงเราทาง crbug.com
  • รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บโดยใช้ตัวเลือกเพิ่มเติม   เพิ่มเติม > ความช่วยเหลือ > รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บในเครื่องมือสำหรับนักพัฒนาเว็บ
  • ทวีตที่ @ChromeDevTools
  • แสดงความคิดเห็นว่ามีอะไรใหม่ในวิดีโอ YouTube เครื่องมือสำหรับนักพัฒนาเว็บ หรือวิดีโอ YouTube สำหรับเครื่องมือสำหรับนักพัฒนาเว็บ