Wordgard: โปรแกรมแก้ไข Rich Text สำหรับเบราว์เซอร์จากผู้สร้าง ProseMirror

 (wordgard.net)
1 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Wordgard เป็นไลบรารี JavaScript โอเพนซอร์สสำหรับสร้างโปรแกรมแก้ไข rich text บนเบราว์เซอร์ โดยเป็นฐาน editor ใหม่ที่สร้างโดยผู้พัฒนา ProseMirror
  • มุ่งเน้นที่ การควบคุมโครงสร้างเอกสาร มากกว่าเครื่องมือแก้ไข HTML แบบอิสระ ทำให้นักพัฒนาสามารถกำหนดชนิดของเนื้อหาที่อนุญาตและโครงสร้างเชิงความหมายได้อย่างละเอียด
  • มุ่งเป้าไปที่ editor แบบปรับแต่งเฉพาะที่ซับซ้อน โดยมี โมเดลแบบ schema-based และโครงสร้างที่เน้นการขยายความสามารถ ทำให้สามารถเปลี่ยนหรือแก้ไขฟีเจอร์ให้ตรงตามความต้องการได้
  • จัดการข้อกำหนดต่าง ๆ ในฐาน editor เช่น accessibility, internationalization, เอกสาร RTL/สองทิศทาง, เนื้อหาแบบมีโครงสร้าง, สไตล์เชิงฟังก์ชัน และ การแก้ไขร่วมกัน
  • เป็นโอเพนซอร์สแบบ permissive ภายใต้ไลเซนส์ MIT แต่มีแนวทางการดำเนินโครงการที่ยินดีรับรายงานบั๊กและ ไม่รับ Pull request

ฐาน editor ที่ควบคุมโครงสร้างเอกสาร

  • Wordgard เป็นไลบรารี JavaScript โอเพนซอร์สสำหรับพัฒนาโปรแกรมแก้ไข rich text ภายในเบราว์เซอร์
  • ไม่ใช่ editor HTML แบบอิสระ แต่เป็น ระบบแก้ไข rich text เชิง semantic ที่ให้นักพัฒนาควบคุมชนิดของเนื้อหาที่จะรองรับและโครงสร้างเอกสารได้อย่างแม่นยำ
  • ใช้แนวทาง schema-based เพื่อให้กำหนดโครงสร้างเอกสารได้ละเอียดและสร้างองค์ประกอบเอกสารแบบกำหนดเองได้
  • อินเทอร์เฟซการเขียนโปรแกรมถูกออกแบบโดยมีเป้าหมายด้านความเป็นสากลและความยืดหยุ่น เพื่อใช้เป็นฐานสำหรับ editor แบบปรับแต่งเฉพาะที่มีข้อกำหนดสูง

ความสามารถในการขยาย, accessibility และฟีเจอร์การทำงานร่วมกัน

  • ฟีเจอร์ส่วนใหญ่ของ editor ถูกพัฒนาเป็น extension จึงสามารถเปลี่ยนหรือแก้ไขได้หากไม่ตรงกับความต้องการ
  • ฟีเจอร์ด้าน accessibility คำนึงถึงผู้ใช้ screen reader, ผู้ใช้ที่ใช้เฉพาะคีย์บอร์ด และสภาพแวดล้อมบนอุปกรณ์มือถือ พร้อมรองรับการ internationalization ของ UI
  • สำหรับสภาพแวดล้อมการเขียนจากขวาไปซ้าย รองรับ การรับรู้ทิศทาง ทั้งในเนื้อหาและอินเทอร์เฟซ และสามารถจัดการเนื้อหาแบบสองทิศทางและเอกสาร RTL ได้
  • ต้นไม้เอกสารสามารถรวม เนื้อหาแบบมีโครงสร้าง เช่น ตาราง, รายการซ้อน, figure ที่มีคำบรรยาย และโครงสร้างแบบกำหนดเอง
  • ส่วนใหญ่ของระบบเขียนในสไตล์เชิงฟังก์ชันเพื่อความชัดเจนและความสามารถในการทดสอบ
  • รองรับ การแก้ไขร่วมกัน ที่ให้ผู้ใช้หลายคนแก้ไขเอกสารเดียวกันพร้อมกันและรวมการแก้ไขที่เกิดขึ้นพร้อมกันได้

ไลเซนส์และการดำเนินโครงการ

  • ไลเซนส์คือ MIT และพัฒนาบน code.haverbeke.berlin
  • ยินดีรับรายงานบั๊ก แต่ ไม่รับ Pull request
  • แนะนำให้ใช้ forum สำหรับการพูดคุยและคำถามเกี่ยวกับโครงการ และควรรายงานบั๊กใน issue tracker

บทความที่เกี่ยวข้อง

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

 
GN⁺ 5 시간 전
ความเห็นจาก Hacker News

  • คิดว่าคนส่วนใหญ่น่าจะอยากรู้ว่า “ทำไม?” เอกสารนี้พูดถึงความแตกต่างจาก ProseMirror เลยถือว่าเป็นคำตอบที่ใกล้เคียงที่สุดสำหรับคำถามนั้น: https://wordgard.net/docs/prosemirror/
    จุดที่น่าสังเกตอย่างหนึ่งคือไม่มี เส้นทางการอัปเกรด ถึงจะมีแนวคิดหลายอย่างร่วมกับ ProseMirror แต่ถ้าจะย้ายก็น่าจะต้องลงแรงพอสมควร Obsidian คงไม่เปลี่ยนเพราะอิงกับ CodeMirror แต่ที่อย่าง tiptap.dev อาจได้รับผลกระทบ
    @merijn อยากรู้ว่าช่วยอธิบายได้ไหมว่าอะไรทำให้ Wordgard คุ้มค่าพอจะรับต้นทุนการย้าย
    แก้ไข: เห็นว่ามีประเด็นหลายอย่างถูกพูดถึงไว้ในบล็อกส่วนตัวของ Marijn แล้ว เลยส่ง https://marijnhaverbeke.nl/blog/wordgard-0.1.html ไปที่ HN เพื่อให้มีบริบทที่ดีกว่า

    • สำหรับคำถามว่า “Wordgard คุ้มค่าพอจะรับต้นทุนการย้ายไหม?” ก็อาจจะไม่ก็ได้ ถ้าคุณพอใจกับ ProseMirror ก็ใช้ ProseMirror ต่อไปได้เลย และผมก็จะยังซัพพอร์ตมันต่อ
      แต่ตามที่อธิบายในโพสต์บล็อก ผมสะสม ข้อค้นพบด้านการออกแบบใหม่ มาไม่น้อย ซึ่งช่วยหลีกเลี่ยงปัญหาบางอย่างที่เจอใน ProseMirror ได้ เลยอยากทำรอบใหม่ขึ้นมา
      ผมจะเพิ่มลิงก์ไปยังโพสต์บล็อกในส่วนเอกสารของเว็บไซต์
      แล้วก็ชื่อไม่ใช่ merijn แต่เป็น marijn
    • ในบล็อกมีบอกไว้ว่า “ตอนนี้ผมก็ไม่ได้ชอบมุกชื่อ ProseMirror เท่าไรแล้ว มันคือ CodeMirror แต่สำหรับร้อยแก้ว เข้าใจใช่ไหม?” เพราะงั้นต่อไปก็คงถึงตาใครสักคนทำ Codegard แล้วล่ะ
    • สิ่งที่อยากรู้จริง ๆ คือ “ทำไมมันถึงคุ้มกับต้นทุนการย้าย?” และที่สำคัญกว่านั้นคือทำไมถึงไม่ทำเป็น ProseMirror v2 ไปเลย
      หน้าแลนดิ้งเพจน่าจะต้องมีข้อมูลเรื่อง “ทำไม” มากกว่า “คืออะไร”

  • นอกเหนือจากตัวเอดิเตอร์แล้ว ศิลปินที่รับผิดชอบงานดีไซน์นี่น่าประทับใจมาก ดูเนี้ยบมากและสะดุดตาสุด ๆ: https://kamilastankiewicz.com/

    • คิดเหมือนกันเลย สวยมาก และก็สงสัยว่าถ้าจะใส่ ภาพประกอบ แบบนี้ในเว็บไซต์ทั่วไปจะมีค่าใช้จ่ายประมาณไหน
    • กราฟิกดีแบบน่าทึ่งและมีกลิ่นอาย Ghibli ด้วย แปลกดีที่ได้พูดแบบนี้ในบริบทของ rich text editor

  • ราว 25 ปีก่อน จำได้ว่าการทำให้ WYSIWYG editor ใช้งานได้บนไซต์ PHP-Nuke ของหนังสือพิมพ์โรงเรียนเป็นอุปสรรคใหญ่ และสุดท้ายก็ผ่านมันมาได้
    มันเหลือเชื่อมากที่จนถึงตอนนี้ยังไม่มีการทำตามมาตรฐานเว็บสำหรับฟีเจอร์แบบนี้ที่ผ่านมาราว 15 ปีแล้ว

    • มี contenteditable อยู่แล้ว และของอย่าง Wordgard หรือ ProseMirror ก็ถูกสร้างอยู่บนสิ่งนั้นในระดับพื้นฐาน ส่วนที่เหลือก็ใกล้เคียงกับเรื่อง ส่วนติดต่อผู้ใช้ และการทำงานร่วมกับระบบที่ไม่ต้องการรับ HTML ตามอำเภอใจ
    • อยู่นานมากที่ผู้พัฒนาเบราว์เซอร์ยังตกลงกันไม่ได้ แม้แต่รายละเอียดของพฤติกรรม การเลือกข้อความ แบบพื้นฐาน

  • อันนี้ดูยอดเยี่ยมแบบน่าประหลาดใจ
    ช่วงหลังผมหาอะไรคล้าย ๆ กันอยู่ สุดท้ายก็ลงมือทำเอง โดยใช้ operational transform (OT) แบบบล็อกเป็นฐานเพื่อซิงก์กับเซิร์ฟเวอร์โลคัล และใช้การซิงก์แบบอิง diff กับเซิร์ฟเวอร์ระยะไกล
    อ่าน system guide ไปก็พยักหน้าตามไปเรื่อย ๆ เห็นทั้งส่วนที่คล้ายและส่วนที่ต่าง เลยรู้สึกเหมือนได้รับการยืนยันพอสมควร

    • ProseMirror และก็น่าจะรวมถึง Wordgard ด้วย ทำหลายส่วนได้ถูกต้องมากจริง ๆ

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

    • ProseMirror และ Lexical ที่พูดถึงในคอมเมนต์ข้างเคียง ก็ควรจะจัดการเรื่องนี้ได้ดี
      Safari บนมือถือกับ Chrome บน Android มีพฤติกรรมประหลาดเยอะมากเมื่อเทียบกับเบราว์เซอร์พี่น้องบนเดสก์ท็อป และก็จัดการมาตรฐานแบบค่อนข้างหลวม ๆ ด้วย ดังนั้นถ้าจะให้ทำงานได้จริงมักต้องมี โค้ด workaround ยาวเป็นหางว่าว
      Wordgard ก็น่าจะไปถึงจุดนั้นในที่สุด แต่ก่อนปล่อยเวอร์ชันแรก จุดโฟกัสคือสถาปัตยกรรม
    • เมื่อหลายปีก่อนผมเคยประเมิน rich text editor บนเว็บ เดสก์ท็อปดูโอเคหมด แต่พอบนมือถือ ตัวไหนที่ลองก็เละหมด
      เลือกข้อความไม่ได้, autocorrect พัง, แตะข้อความแล้วเคอร์เซอร์ไม่ย้าย, อินพุตค้าง, แล้วคีย์บอร์ดก็ไม่ยอมหายแม้องค์ประกอบจะเสียโฟกัสไปแล้ว
      ตลอดหลายสิบปีที่ผ่านมา มีความพยายามหลายครั้งในการเพิ่ม องค์ประกอบ rich text ที่ใช้งานได้จริงให้เว็บ แต่ก็ไม่รู้ว่าทำไมถึงล้มเหลวหมด น่าจะเพราะงานใหญ่ ซับซ้อน และไม่ค่อยให้ผลตอบแทน
      การรองรับ rich text แบบเนทีฟที่ดีจริง ๆ เป็นหนึ่งในจุดบอดใหญ่ของเว็บ ขณะที่แพลตฟอร์มเนทีฟแก้ปัญหานี้กันไปตั้งนานแล้ว

  • ราว 6 ปีก่อน ผมลำบากมากกับการสำรวจและทำฟีเจอร์ autocomplete ของทรัพยากรระยะไกลแบบสไตล์ @ คือการอ้างถึงผู้ใช้คนอื่นหรือเอกสารอื่น วิธีขยายความสามารถของเอดิเตอร์ตัวนี้ดูเหมือนวิวัฒนาการของ ProseMirror
    คงดีมากถ้าสิ่งนี้เป็น ฟีเจอร์ในตัวพื้นฐาน แทนที่จะต้องมานั่งสร้างเองจากตัวอย่างไดโนเสาร์ ทุกครั้งที่ใช้ไลบรารี text editor แบบนี้ use case อันดับหนึ่งของผมคือสิ่งนี้ แล้วค่อยเป็น WYSIWYG

    • ถ้ามีรูปแบบ @ mention มาให้เป็นค่าเริ่มต้นและให้แค่ API มาก็จะยอดเยี่ยมมาก
      การรองรับมือถือแบบจริงจัง ก็จำเป็นเหมือนกัน

  • สิ่งที่ทำให้การใช้ ProseMirror ผ่าน TipTap ลำบากคือ บ่อยมากที่ต้องจัดการ JSON representation ของเอกสารแบบเป็นโปรแกรมเพื่อดึงข้อมูลออกมา ซึ่งพอทำแบบนั้นแล้วก็จำเป็นหรืออย่างน้อยก็อยากได้ representation ที่มี static type กำกับ
    ProseMirror ไม่มีอะไรช่วยเรื่องนี้โดยตรง สุดท้ายเลยต้องเลือกทำอย่างใดอย่างหนึ่ง

    1. นิยามสคีมาสองรอบ รอบหนึ่งด้วย ProseMirror และอีกรอบด้วยอะไรอย่าง Zod แล้วก็เขียนการทดสอบความเท่าเทียมไว้กองใหญ่เพื่อเช็กว่าสองสคีมาตรงกัน
    2. สร้าง ชั้นนิยาม meta schema ที่สามารถ generate ProseMirror schema ได้ โดยให้เป็นไปตามมาตรฐานสคีมา https://standardschema.dev/ ซึ่งแนวทางนี้ใช้งานได้จริงมากกว่าเมื่อไม่ได้ใช้ของอย่าง Tiptap
      ผมยังไม่ได้ลอง Wordgard เลยไม่รู้ว่าจัดการปัญหานี้หรือเปล่า แต่เป็นจุดเจ็บปวดที่อยากเห็นถูกแก้ เลยอยากชี้ไว้

  • งานอาร์ต บนเว็บไซต์สวยมาก รู้สึกเหมือนแนวทางดึงความสนใจแบบนี้ถูกลืมกันไปแล้ว

    • แถมยัง “มี AI 0%” อีกด้วย ศิลปินคนนี้เจ๋งจริง
    • ในยุคที่มีแต่ ขยะ AI เต็มไปหมด การได้เห็นภาพประกอบสวย ๆ ที่วาดด้วยมือมันสดชื่นจริง ๆ

  • ผมไม่ชอบ WYSIWYG บนเว็บเลย เขียนโพสต์ในฟอรัมยาว ๆ จัดฟอร์แมตเสียสวย แล้วเผลอปิดแท็บ ทุกอย่างหายหมด
    ผมชอบใช้ text editor ในเครื่องแล้วค่อย Ctrl+V ไปวางในฟอร์มเว็บมากกว่า ถ้าเป็น Markdown ก็ทำแบบนั้นได้

    • เคยเห็นบางแพลตฟอร์มแก้ปัญหานี้ด้วย localStorage คือ autosave “ฉบับร่าง” ระหว่างพิมพ์ แล้วพอเปิดหน้าเดิมอีกทีก็กู้กลับมาให้เนียน ๆ
      ตอนที่เจอแบบนี้ครั้งแรกหลังปิดแท็บพลาด มันเป็นความประหลาดใจที่ดีมากจริง ๆ
    • ลองดู Linear ผมไม่ได้เกี่ยวข้องอะไรนะ แต่เมื่อวานนี้เองผมเผลอปิดกล่องโต้ตอบ แล้วพอกดสร้าง issue ใหม่ ข้อความยาว ๆ ที่ผมเขียนไว้ยังอยู่ครบ
      ประเด็นคือ นี่ไม่ใช่ปัญหาทางเทคนิค แต่เป็น ปัญหาด้านผลิตภัณฑ์
    • มันก็แล้วแต่กรณี ในบล็อกของผมมีเอดิเตอร์บนเว็บ แต่จริง ๆ ก็เป็นแค่ Markdown พร้อมพรีวิว เลยมี workflow คล้ายกับที่คุณอธิบาย
      แต่กับแอปโน้ต ผมเลือกใช้ WYSIWYG เพราะไม่มีที่พอสำหรับมุมมองแบบแบ่งหน้าจอ และก็ไม่ได้อยากดูต้นฉบับ Markdown อย่างเดียว
      ข้อร้องเรียนใหญ่สุดของผมต่อ WYSIWYG คือมันอาจรบกวนได้ เช่นสร้างบล็อก verbatim แล้วดันออกจากบล็อกนั้นไม่ได้ กำลังพูดถึง Teams นี่แหละ เลยอาจเป็นเหตุผลว่าทำไมผมถึงชอบ LaTeX มาก
    • มี แบ็กเอนด์ ดี ๆ สำหรับ ProseMirror และเอดิเตอร์ตัวอื่นอยู่แล้ว ตั้งค่าไม่ได้ยากนัก
    • เห็นด้วย แต่หลายคนชอบ WYSIWYG มากกว่า วิธีง่าย ๆ ก็คือมี มุมมองแบบวางข้างกัน เหมือน HTML editor หรือ Markdown editor หลายตัว

  • ดีใจมากที่ได้เห็น ศิลปะ จริง ๆ อีกครั้งในรอบนาน ดูดีมาก