1 คะแนน โดย GN⁺ 2023-11-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Servo ได้รับ ทุนสนับสนุนจาก NLnet ในเดือนกรกฎาคม 2023 เพื่อนำมาเสริมความสามารถหลักด้านเลย์เอาต์ ในฐานะทางเลือกที่มีน้ำหนักเบาและประสิทธิภาพสูงสำหรับการฝังเทคโนโลยีเว็บลงในแอปพลิเคชัน
  • ขอบเขตการปรับปรุงมุ่งเน้นที่ การทำ CSS float ให้สมบูรณ์, การขยายการรองรับหลายภาษาใน inline layout และการเพิ่มการรองรับ <table> ขั้นต้น
  • งานด้าน CSS float ดำเนินต่อเนื่องมาตั้งแต่กลางปี 2023 และมีเป้าหมายที่จะยกระดับอัตราการผ่านการทดสอบ WPT ที่เกี่ยวข้องให้มีค่าเฉลี่ย เกิน 80%
  • inline layout ยังขาดการรองรับการเลือกฟอนต์สำหรับการเรนเดอร์อักขระที่ไม่ใช่ละติน, อักษรที่เขียนจากขวาไปซ้าย และ logical properties
  • การที่เอนจินเลย์เอาต์ใหม่ยังไม่รองรับ table ทำให้การแสดงผลเว็บเพจจำนวนมากเสียหาย ดังนั้นเป้าหมายเชิงปฏิบัติในลำดับแรกคือ การเรนเดอร์ตารางของ Wikipedia

ส่วนที่ Servo เสริมความสามารถด้วยทุนจาก NLnet

  • Servo ได้รับ ทุนสนับสนุนจาก NLnet ในเดือนกรกฎาคม 2023 เพื่อปรับปรุงความสามารถที่เกี่ยวข้องกับเลย์เอาต์หลายด้าน
  • เป้าหมายหลักสรุปได้เป็น 3 ข้อ
    • ทำให้ การรองรับ float ของ Servo สมบูรณ์
    • รองรับภาษาให้มากขึ้นใน inline layout
    • เพิ่มการรองรับ <table> ขั้นต้น

เป้าหมายและความคืบหน้าของความสามารถด้านเลย์เอาต์แต่ละส่วน

  • Floats

    • การรองรับ float ของ Servo อยู่ระหว่างการพัฒนามาตั้งแต่กลางปี 2023
    • ยังมีปัญหาที่ต้องแก้อีกก่อนจะถือได้ว่าเป็นการใช้งานที่สอดคล้องกับ CSS float อย่างสมบูรณ์
    • เป้าหมายคือให้อัตราการผ่าน WPT เฉลี่ยเกิน 80% สำหรับ /css/CSS2/floats/ และ /css/CSS2/floats-clear/
    • ติดตามผลได้ที่ WPT dashboard
    • เมื่อสัปดาห์ที่แล้ว การทดสอบ /css/CSS2/floats/ มีอัตราผ่าน 82.2% ซึ่งเกินเป้าหมายแล้ว
    • ส่วน /css/CSS2/floats-clear/ ปัจจุบันมีอัตราผ่าน 73.3% และกำลังเข้าใกล้เป้าหมาย
  • More languages in inline layout

    • เอนจินเลย์เอาต์ของ Servo ยังขาดความสามารถหลักที่จำเป็นต่อการเรนเดอร์ภาษาที่ไม่ได้ใช้อักษรละติน
    • สิ่งที่จะเสริมมีทั้ง การเลือกฟอนต์ ที่ถูกต้อง, การรองรับอักษรที่เขียนจากขวาไปซ้าย และ logical properties
    • เป้าหมายคือขยายขอบเขตการรองรับของ inline layout เพื่อให้ Servo แสดงคอนเทนต์ที่หลากหลายได้มากขึ้น
  • Initial <table> support

    • HTML table เป็นความสามารถบนเว็บที่สำคัญและถูกใช้อย่างแพร่หลาย
    • เอนจินเลย์เอาต์ใหม่ของ Servo ยังไม่รองรับ table จึงทำให้เลย์เอาต์ของเว็บเพจจำนวนมากแสดงผลไม่ถูกต้อง
    • เป้าหมายลำดับแรกของการรองรับ table ขั้นต้นคือทำให้สามารถเรนเดอร์ตารางที่ใช้บน Wikipedia ได้
    • เมื่อแต่ละไมล์สโตนมีความคืบหน้าและบรรลุผลแล้ว จะมีการกล่าวถึงรายละเอียดเพิ่มเติมในบล็อกโพสต์ถัดไป

1 ความคิดเห็น

 
GN⁺ 2023-11-11
ความคิดเห็นบน Hacker News
  • ผมคาดหวังกับ Servo มาก และไม่น่าเชื่อว่า Mozilla จะไม่ได้สนใจมัน
    แนวคิดเรื่องเอนจินที่มีความปลอดภัยและประสิทธิภาพสูงก็ดีอยู่แล้ว แต่สิ่งที่ผมชอบเป็นพิเศษคือการใช้ เว็บเอนจินเป็นคอมโพเนนต์ ได้
    ในยุค Windows 9x นั้น IE มี ActiveX control ทำให้สามารถฝังเว็บเอนจินไว้ได้ทุกที่ และ KHTML ก็คล้ายกัน แต่ทุกวันนี้ทั้ง Firefox และ Chrome ดูเหมือนไม่สนใจการใช้งานลักษณะนั้น
    ยังดีที่มี Qt WebEngine แต่เท่าที่เข้าใจ ความสัมพันธ์กับฝั่ง Chrome ค่อนข้างอึดอัด เพราะ Chrome ไม่ได้ใส่ใจ use case แบบนี้
    แถม Chrome ก็เป็นของ Google และจากประสบการณ์ของผม ของจาก Google มักมีโลกของตัวเอง ทำให้ build และ integrate ได้ยุ่งยาก
    ดังนั้นผมจึงตั้งตารอทางเลือกที่ใช้งานได้จริง ซึ่งใส่ลงในโค้ดได้ ช่วยแก้ข้อกังวลด้านความปลอดภัยและลดความเจ็บปวดในการผสานรวมด้วย

    • คำว่า “Mozilla ไม่ได้สนใจ Servo” ดูจะไม่แม่นนัก
      Mozilla ให้ทุนในฐานะโครงการวิจัย และน่าจะใกล้เคียงกับการตระหนักว่าหากจะนำออกสู่ตลาดอย่างเต็มตัวต้องใช้เงินและเวลามากกว่านั้นมาก จึงตัดสินใจประหยัดค่าใช้จ่าย
      เพียงแต่มีปัญหาว่าพวกเขานำเงินนั้นไปจัดสรรให้ผู้บริหารและคนอื่น ๆ ในแบบที่ไม่สอดคล้องกับหลักศีลธรรมที่ตนชูไว้
      จากบล็อกต่าง ๆ จะเห็นว่า Mozilla ได้รวมสิ่งที่นำจาก Servo ไปใช้ได้เข้าใน Firefox แล้ว ดังนั้นจึงถือว่าได้คุณค่าจากโครงการไปพอสมควร
      ผมคิดว่าถ้ามีใครให้เงินจำนวนมากและกำหนดเวลาแบบไม่จำกัดแก่ Mozilla พวกเขาก็คงทำ Servo ให้เสร็จ
    • ผมเคยใช้ CEF, WebKit และ WebView2 มาแล้ว ในบรรดานี้ตัวเลือกข้ามแพลตฟอร์มที่ฝังได้ง่ายมีแค่ CEF
      แต่ทันทีที่ CEF เริ่มได้รับความนิยม Google ก็ทุ่มทรัพยากรจำนวนมากเพื่อบล็อกการเข้าสู่ระบบ Google บน CEF หรือเบราว์เซอร์แบบฝังตัวอื่น ๆ[0]
      ด้วยเหตุนี้ผมจึงต้องเลิกทำเบราว์เซอร์ที่ใช้ CEF และแม้แนวปฏิบัติทางธุรกิจแบบนั้นจะน่ารังเกียจ แต่ก็ทำอะไรไม่ได้
      ถ้าเบราว์เซอร์ของผมล็อกอินเข้าใช้ผลิตภัณฑ์ของ Google ไม่ได้ ก็ยากที่จะถูกใช้อย่างแพร่หลาย และผมก็ไม่มีเวลามาเล่นเกมแมวจับหนูกับวิธีตรวจจับของ Google
      ถ้าจะให้ คอมโพเนนต์เบราว์เซอร์แบบฝังตัว กลายเป็นกระแสหลักจนใคร ๆ ก็สร้างเบราว์เซอร์ได้ ก่อนอื่นต้องจัดการปัญหาที่บริษัทใหญ่ ๆ บล็อกเบราว์เซอร์แบบฝังตัวที่เริ่มได้รับความนิยม
      ตามอุดมคติแล้ว คงดีถ้ามี Gecko ที่ฝังได้และไม่ใช่ Android เพราะ Firefox ใหญ่เกินกว่าจะบล็อกได้
      ก่อนหน้านี้ก็มีการพูดถึงเรื่องนี้มาก และผมเคยทำ proof of concept ที่ขโมย window handle มาใช้ด้วย[1] แต่ทำเงินไม่ได้
      0 - https://developers.googleblog.com/2016/08/modernizing-oauth-...
      1 - https://github.com/cretz/ffembedpoc
    • Mozilla สนใจ Servo อยู่แล้ว
      ไม่แน่ใจว่าหมายถึงอะไร แต่พวกเขานำคอมโพเนนต์หลายอย่าง รวมถึง WebRender และ Stylo ไปใส่ใน Gecko
    • พูดถึง ActiveX แล้วทำให้นึกอะไรขึ้นมาเยอะ
      ผมจำได้ว่าถ้าพื้นหลังเดสก์ท็อปล้มเหลว จะมีหน้า error ของ ActiveX ที่มีลิงก์คลิกได้แสดงบนเดสก์ท็อป ซึ่งชวนสับสนจริง ๆ
    • WebKit ยังฝังได้ดีอยู่ แต่การ build บน Windows ค่อนข้างเละเทะ
      บน macOS และ Linux ทำงานได้ดีมาก
      ถึงอย่างนั้น เราก็ยังต้องการเว็บเอนจินที่ฝังได้มากกว่านี้
      Gecko นั้นดี แต่การที่มันถูกผูกติดกับ XULRunner อย่างถาวรเหมือนเป็นร่างเดียวกันนี่แหละที่เป็นอุปสรรค
  • ดีใจที่เห็นงานบน Servo เดินหน้าต่อหลังจาก Igalia เข้ามารับช่วง
    มีหนี้ทางเทคนิคมากมายจากช่วงหลายปีที่มีแค่การบำรุงรักษาขั้นต่ำ แต่ดูเหมือนว่าจะมีความคืบหน้าจริง
    ส่วนตัวแล้วอยากให้ผลักดันเรื่อง ความเป็นโมดูล อย่างจริงจัง
    ผมคิดว่ามีช่องว่างให้โอเพนซอร์สเบราว์เซอร์เอนจินที่เน้นการฝังตัวเข้าไปเติมเต็ม และถ้ามีไลบรารี “สร้างเบราว์เซอร์เอง” ที่ให้ผู้คนนำมาผสมกันเหมือนตัวต่อ Lego เพื่อสร้างเอนจินใหม่ได้ ก็น่าจะช่วยสุขภาพระยะยาวของเว็บแพลตฟอร์มได้มาก

    • เห็นด้วย
      ถ้ามี Electron ที่ฝัง Servo หรืออะไรสักอย่างคล้าย Electron ออกมา ก็น่าจะเป็นผลลัพธ์ที่ดี
      Tauri เติมช่องว่างนั้นได้ระดับหนึ่งแล้ว แต่ใช้สิ่งที่ระบบปฏิบัติการมีให้มากกว่าจะฝังอะไรบางอย่างเข้ามา
      ถ้ามีตัวเลือกที่อยู่กึ่งกลางระหว่างสองแบบนั้นก็คงดี
    • เอนจินแบบฝังตัว ยังเป็นเส้นทางที่เร็วกว่ามากไปสู่ use case ที่ใช้งานได้จริง
      ตัวอย่างเช่น Sciter [1] แม้จะ implement เพียง subset ที่สมเหตุสมผลของ DOM API ก็ยังประสบความสำเร็จในระดับหนึ่ง
      มันไม่ค่อยเหมาะกับการท่องอินเทอร์เน็ตทั่วไป แต่ถ้าใช้เป็น UI library ก็แค่หลีกเลี่ยงส่วนที่ทำงานไม่ได้
      1: https://sciter.com/
    • เดาล้วน ๆ แต่เมื่อ iPhone ถูกบังคับให้เปิดเสรีเว็บเอนจิน อาจมีแอปที่ต้องการ ฝังเอนจินของตัวเอง บนอุปกรณ์มือถือโดยรวมมากขึ้นก็ได้
    • มันถูกออกแบบมาอย่างเข้มข้นในทิศทางนั้นอยู่แล้ว
      โมเดลคอมโพเนนต์ และชั้นสำหรับการฝังตัวเป็นโครงสร้างแบบนั้น
  • เงินสนับสนุนนี้บางส่วนมาจาก European Commission และได้รับการสนับสนุนผ่านโปรแกรม NGI

  • เป็นข่าวดีมากสำหรับ Servo
    ช่วงหลัง NLNet Foundation สนับสนุนโครงการดี ๆ จำนวนมาก และเห็นชื่อนี้บ่อยขึ้น

    • โปรเจกต์ของผม https://www.oilshell.org/ ก็ได้รับการสนับสนุนจาก NLnet ตั้งแต่ปี 2022 และช่วยได้มากจริง ๆ
      เราต้องการความช่วยเหลือเพื่อผลักดันปัญหาบางอย่างให้เดินหน้า และมันก็เกิดขึ้นจริง
      พวกเราอยู่ในอเมริกาเหนือเป็นหลัก แต่เงินมาจาก EU นับว่าเป็นการสนับสนุนที่มองการณ์ไกลมาก
  • อีกเบราว์เซอร์หนึ่งที่สร้างใหม่ตั้งแต่ต้นอย่าง Ladybird ก็น่าจับตา
    สร้างโดยกลุ่มอินดี้ที่ดูเหมือนรวมตัวกันแบบหลากหลายกว่า: https://ladybird.dev/
    พูดตรง ๆ เป็นโปรเจกต์ที่โคตรห้าวมาก

    • พูดตรง ๆ ผมคาดหวังกับ Ladybird มากกว่า Servo
      ถ้าคิดว่ายังเป็นโปรเจกต์ที่ใหม่มาก ก็ถือว่าน่าประทับใจมากแล้ว
      แค่ลองจับภาพหน้าจอก็เห็นว่า renderer ของ Servo ยังพื้นฐานมาก ช้า และมีบั๊กเยอะ
    • Ladybird น่าทึ่งมาก
      มันเร็ว และทำทุกอย่างแบบเปิดเผย งานที่ทีม Ladybird ทำจึงน่าประทับใจมาก
    • จริง ๆ แล้ว Ladybird ใช้งานได้ดี นอก Serenity OS ด้วยหรือเปล่า?
    • ทำไมเราต้องมี browser engine อีกตัวที่เขียนด้วย C++?
  • ไม่รู้ทำไมผมนึกว่า Servo ถูกรวมเข้า Firefox ไปแล้ว
    มีวิธี render HTML เป็นรูปภาพใน Rust โดยไม่ต้องรันเบราว์เซอร์ทั้งตัวไหม?
    ไม่จำเป็นต้องรองรับ HTML หรือ CSS มากมาย

    • CSS style system อย่าง Stylo เริ่มจาก Servo และตอนนี้อยู่ใน Firefox แล้ว แต่เท่าที่ผมเข้าใจ ทั้งสองแยกทางกันไปค่อนข้างมาก
      https://blog.nightly.mozilla.org/2017/07/25/stylo-is-ready-f...
    • WebRender และ Stylo มาจาก Servo แล้วถูกรวมเข้าไปเป็น Quantum Render และ Quantum CSS
      อาจมีอย่างอื่นด้วยก็ได้
    • ตอนนี้สิ่งที่ใกล้เคียงที่สุดน่าจะเป็น https://github.com/trimental/inlyne
      แต่มีสองอย่างที่ต่างกัน: รองรับเฉพาะ Markdown ไม่ใช่ HTML ใด ๆ ก็ได้ และ render ลงหน้าจอ ไม่ใช่เป็นรูปภาพ
      ถึงอย่างนั้นก็เป็นจุดเริ่มต้นที่ดี
      ตอนนี้ผมมองว่าอุปสรรคหลักของการ render เว็บใน Rust คือ text layout ที่ดีกว่านี้ โดยเฉพาะการรองรับการใส่คอนเทนต์ที่ไม่ใช่ข้อความไว้ในข้อความ เช่น display: inline-block
      ถ้าสิ่งนั้นถูก implement ได้ ก็น่าจะ render หน้าเว็บพื้นฐานได้ค่อนข้างดี
    • แม้จะไม่ใช่ engine ทั้งตัว แต่ WebRender และ Stylo อยู่ใน Firefox มาหลายปีแล้ว
      โดยแต่ละตัวคือ compositor ที่ใช้ GPU และ CSS engine ตามลำดับ
  • Servo คือ web rendering engine ที่เขียนด้วย Rust รองรับ WebGL และ WebGPU และสามารถปรับให้เหมาะกับแอปพลิเคชันเดสก์ท็อป มือถือ และ embedded ได้
    เป็น web rendering engine ที่ฝังใช้งานได้ เป็นอิสระ มีความปลอดภัยด้านหน่วยความจำ มีความเป็นโมดูลาร์ และรองรับการประมวลผลแบบขนาน

  • Legacy Layout ที่ใช้เป็นตัวเปรียบเทียบนี่คืออะไร?
    เป็นเวอร์ชันก่อนหน้าของ Servo หรือเปล่า?
    โค้ดบางส่วนดูเหมือนยังถูกใช้ทั้งสองฝั่ง และบางครั้งกราฟก็ขึ้นลงพร้อมกัน แต่ก็ไม่เสมอไป

    • Legacy Layout หมายถึงระบบดั้งเดิมคือ Layout 2013
      ต่อมาจึงเริ่มระบบที่สองคือ Layout 2020 เพื่อแก้ปัญหาที่บางส่วนของสเปก CSS เมื่อ implement แล้วไม่เข้ากับสถาปัตยกรรม Layout 2013 อย่างเรียบร้อย
      ปีนี้ในวิกิของ Servo มีรายงานดี ๆ ที่คนจาก Igalia เขียนไว้ สรุปความแตกต่างของสองระบบและเหตุผลที่ตัดสินใจเดินหน้าต่อด้วย Layout 2020
      https://github.com/servo/servo/wiki/Servo-Layout-Engines-Rep...