รายการ HTML

 (blog.frankmtaylor.com)
3 คะแนน โดย GN⁺ 2026-05-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • รายการใน HTML ควรเลือกใช้ตาม ความหมายและลักษณะการโต้ตอบ มากกว่ารูปลักษณ์ทางสายตา และแบ่งได้เป็นรายการควบคุม, รายการมีลำดับ, รายการคำอธิบาย, เมนู และรายการไม่มีลำดับ
  • ตัวเลือกแบบตายตัวควรใช้ /, ส่วนการป้อนแบบมีคำแนะนำควรใช้ `` และต้องแยกความเข้าใจการทำงานของ multiple, optgroup, size, value
  • `` ใช้กับขั้นตอน, เหตุการณ์ หรือชุดต่อเนื่องที่ถ้าเปลี่ยนลำดับแล้วความหมายจะเปลี่ยน และ reversed จะสลับแค่หมายเลข ไม่ได้เปลี่ยนลำดับรายการจริง
  • `` ใน HTML5 ขยายจาก definition list ไปเป็น description list และเหมาะกับคู่ข้อมูลแบบคีย์-ค่า เช่น คำกับค่า, เมทาดาทา, หรือการดีบัก JSON
  • **** ใช้กับรายการคำสั่ง เช่น ปุ่มเครื่องมือ โดยมีความหมายและเนื้อหาที่อนุญาตต่างจาก `nav` ส่วนรายการทั่วไปอื่น ๆ ให้ใช้

รายการควบคุม: / และ ``

  • ในฟอร์มก็สามารถสร้าง รายการ ที่ผู้ใช้โต้ตอบได้

  • ตัวเลือกแบบตายตัวคือ และ

    • ถ้าผู้ใช้ต้องเลือกได้เฉพาะรายการที่อยู่ในลิสต์ ให้ใช้ และ
    • ตัวอย่างรายการภาษา คือวาง เช่น `Select a Language`, `English`, `French`, `Spanish`, `Portuguese` ไว้ภายใน
    • โดยปกติ `` จะเลือกได้เพียงหนึ่งตัวเลือกเท่านั้น
    • ถ้าต้องการให้เลือกได้หลายรายการ ให้เพิ่ม แอตทริบิวต์ multiple
      • เมื่อใช้ multiple รูปแบบการแสดงผลของรายการจะเปลี่ยน ทุกตัวเลือกจะมองเห็นได้ และผู้ใช้สามารถเลือกหลายรายการด้วย Shift หรือ Cmd + คลิก
      • เมื่อใช้ select และ option จริง เบราว์เซอร์จะจัดการ semantic พื้นฐานให้เอง จึงไม่จำเป็นต้องใส่ aria-multiselectable เองบนองค์ประกอบรายการที่มี role="listbox"

  • จัดกลุ่มตัวเลือกที่เกี่ยวข้องด้วย ``

    • ถ้าต้องการจัดกลุ่มภาษาเป็นตระกูลภาษา ให้ใช้ `` เพื่อจัดกลุ่มรายการตัวเลือก
    • ตัวอย่างคือสร้าง `` ที่มี label เป็น Germanic, Romance, Celtic แล้วใส่ English, French, Spanish, Portuguese, Irish, Welsh ในแต่ละกลุ่ม
    • หากต้องการปิดไม่ให้เลือกบางกลุ่มย่อย ให้เพิ่ม แอตทริบิวต์ disabled กับ `` นั้น
    • ในตัวอย่างจะใส่ disabled ให้กลุ่ม Celtic เพื่อปิดใช้งานกลุ่มที่มี Irish, Welsh

  • ปรับปรุงด้วยความสามารถพื้นฐานของ HTML

    • ถ้าต้องการเส้นแบ่งให้เห็นชัดระหว่างกลุ่ม สามารถใช้ **** ที่อนุญาตภายใน ได้
    • แอตทริบิวต์ size ใช้ควบคุมจำนวนรายการที่แสดงพร้อมกัน จึงเหมาะกับลิสต์ยาว ๆ
    • เมื่อใช้ size ร่วมกับ optgroup ป้ายชื่อกลุ่มก็จะกินพื้นที่แสดงผลด้วย
    • ตัวอย่างใช้ พร้อมกลุ่ม `Germanic`, `Romance`, `Celtic`, `Afroasiatic` และใส่ คั่นระหว่างกลุ่ม รวมถึง Hebrew, Arabic

รายการคำแนะนำ: ``

  • ถ้าผู้ใช้ไม่ได้จำเป็นต้องเลือกจากรายการเท่านั้น แต่ต้องการให้รายการเป็น คำแนะนำ ให้ใช้ ``
  • การเชื่อม `` มีสองขั้นตอน
    • สร้าง `` และกำหนด id
    • ใส่ค่า id นั้นในแอตทริบิวต์ list ของ `` ที่สอดคล้องกัน
  • ตัวอย่างคำแนะนำภาษา คือใส่ตัวเลือก English, French, Spanish, Portuguese, Irish, Welsh, Hebrew, Arabic ไว้ใน แล้วเชื่อมกับช่องกรอกผ่าน

  • การทำงานของ ``

    • ค่าเริ่มต้นของ `` คือข้อความที่ครอบอยู่ แต่ถ้ามี แอตทริบิวต์ value ค่านั้นจะเขียนทับค่าเริ่มต้น และข้อความจะทำหน้าที่คล้ายป้ายชื่อ
    • ใน ผู้ใช้เห็นแค่ข้อความ จึงมักไม่เป็นปัญหา แต่ใน ผู้ใช้อาจเห็นป้ายชื่อแล้วเลือก ทว่าค่าที่ถูกใส่ลงช่องกรอกกลับเป็น value ซึ่งอาจทำให้สับสน
    • ในตัวอย่าง เมื่อเลือก Welsh ผู้ใช้จะเห็น Welsh แต่ในช่องกรอกจะถูกใส่เป็น cy
    • เวลาจะใช้ `` ต้องตั้งต้นไว้ก่อนว่าค่าที่ถูกแทรกคือ value ไม่ใช่ป้ายชื่อ

  • ใช้ร่วมกับหลายชนิดของ input

    • `` ไม่ได้ใช้เฉพาะกับตัวเลือกข้อความ แต่ยังใช้ร่วมกับ input ชนิดอื่นได้ด้วย
    • ตัวอย่างการเลือกเป็นรายสัปดาห์คือเชื่อม กับ
    • สัปดาห์ที่แนะนำคือ 2026-W22, 2026-W23, 2026-W24, 2026-W25

  • ใช้ร่วมกับ ``

    • `` ไม่ได้จำกัดแค่ค่าสตริง แต่ใช้กับตัวเลขได้เช่นกัน จึงสามารถใช้ร่วมกับ range input เพื่อสร้างจุดบนช่วงค่าที่มีป้ายกำกับได้
    • ตัวอย่างอินพุตเปอร์เซ็นต์ทิปคือเชื่อม กับ และใส่ป้าย 10%, 18%, 30%, 45%
    • ในเบราว์เซอร์ตระกูล Chrome ใช้ @supports (x: attr(x type(percentage))) เพื่ออ่านค่า label ผ่าน attr() จากนั้นประกาศค่าเป็นเปอร์เซ็นต์ด้วย type() แล้วจัดวางตัวเลือกด้วย position: absolute
    • วิธีสำหรับ Firefox ใช้ @supports not (x: attr(x type(percentage))) และจะแสดงค่าผ่าน ::before
    • วิธีนี้ไม่ได้รับประกันว่าทุกเบราว์เซอร์จะทำงานหรือแสดงผลเหมือนกันทุกประการ

รายการมีลำดับ: ``

  • ชุดรายการที่ต้องอ่านตามลำดับเฉพาะควรใช้ ``
  • เกณฑ์ไม่ได้อยู่ที่ว่าต้องมีตัวเลขแสดงข้างรายการหรือไม่ แต่คือถ้าสลับลำดับของรายการแล้ว ความหมายของรายการ จะเปลี่ยนหรือไม่
  • คอลเลกชันที่เหมาะกับ `` ได้แก่ อัลกอริทึม, ลำดับเหตุการณ์, รายการบนสเกลที่เพิ่มหรือลด, สูตรอาหาร, และรายการเรียงตามตัวอักษร
  • ตัวอย่างสูตร banana bread ใช้ `` เพื่อแสดงลำดับตั้งแต่อุ่นเตาและทาน้ำมันในพิมพ์, ผสมส่วนผสม, เทแป้งลงพิมพ์, อบ 60 นาทีหรือจนไม้จิ้มฟันออกมาสะอาด, แล้วพักให้เย็นบนตะแกรง
  • แม้แต่รายการวัตถุดิบที่เรียงตามตัวอักษรก็ถือว่าอยู่บนลำดับต่อเนื่องของตัวอักษร จึงเข้ากับ `` เช่น baking soda, bananas, brown sugar, butter, eggs, flour, salt

  • การซ้อนรายการมีลำดับและไม่มีลำดับ

    • รายการมีลำดับที่จัดโครงสร้างดีควรอ่านแล้วเข้าใจได้ว่าอะไรต้องเกิดก่อนหลัง แม้ไม่เห็นการเรนเดอร์ของเบราว์เซอร์
    • ตัวอย่างสูตรอาหารใช้ กับขั้นหลัก และภายในขั้นที่ลำดับไม่สำคัญใช้ ส่วนขั้นย่อยที่ยังมีลำดับก็ซ้อน `` ต่อ
    • โครงสร้างนี้คงลำดับหลักของ Prepare, Mix, Pour, Bake, Cool เอาไว้ ขณะที่รายการคู่ขนานใน Prepare และ Bake ใช้ และขั้นตอนย่อยใน `Mix` กับ `Cool` ใช้

  • reversed

    • แอตทริบิวต์ reversed จะเปลี่ยนการนับเลขจากน้อยไปมากให้เป็นมากไปน้อย
    • แต่จะไม่เปลี่ยนลำดับจริงของรายการ
    • จึงใช้ได้กับรายการวัตถุดิบและปริมาณที่อยากแสดงแบบ most to least
    • ตัวอย่างคือใส่ eggs (2), flour (2 cups), bananas (2) (mashed), brown sugar (¾ cup), butter (½ cup), baking soda (1 teaspoon), salt (¼ teaspoon) ไว้ใน ``

  • กลับลำดับรายการจริงด้วย JavaScript

    • ถ้าต้องการกลับลำดับรายการจริง ต้องใช้ JavaScript จัดเรียงลูก li ใหม่เป็นลำดับย้อนกลับ และสลับแอตทริบิวต์ reversed
    • ฟังก์ชันตัวอย่างจะนำผลจาก list.querySelectorAll('li') มาทำเป็นอาร์เรย์, ใช้ .reverse(), จากนั้นล้างด้วย list.innerHTML = '' แล้วค่อยใส่กลับด้วย list.append(...children)
    • จากนั้นเรียก list.toggleAttribute('reversed')
    • อีเวนต์ตัวอย่างคือ orderedList.addEventListener('dblclick', (evt) => { reverseList(orderedList) }) เพื่อสลับลำดับเมื่อดับเบิลคลิก

  • start

    • แอตทริบิวต์ start ใช้รักษาความต่อเนื่องของหมายเลขเมื่อแบ่งรายการขนาดใหญ่ออกเป็นหลายรายการมีลำดับ แทนที่จะใช้รายการเดียวทั้งหมด
    • ในตัวอย่างสูตร banana bread, Prepare ใช้ ul, Mix ใช้ , `Pour` ใช้ , และ Cool ใช้ `` เพื่อให้หมายเลขขั้นตอนต่อเนื่องกัน
    • แม้ตรงกลางจะมีส่วนอย่าง 6: Bake ที่แสดงเป็นรายการไม่มีลำดับ ก็ยังเริ่ม ol ของ Cool ที่ start=7 เพื่อรักษาลำดับหมายเลขของกระบวนการทั้งหมดไว้

รายการคำอธิบาย: , , ``

  • รายการคำอธิบาย (description list) เป็นรูปแบบรายการที่ช่วยให้ไม่ต้องฝืนเอาทุกอย่างไปใส่ใน ol หรือ ul

  • definition list ใน HTML 4

    • ใน HTML 4 ไม่ได้เรียกว่า description list แต่เรียกว่า definition list และถูกออกแบบมาสำหรับการให้คำจำกัดความเป็นหลัก
    • โครงสร้างประกอบด้วย สำหรับคำที่จะนิยาม และ สำหรับเนื้อหาคำอธิบาย โดยถ้าต้องการให้ถูกต้องเชิงความหมายมากขึ้น คำที่ถูกนิยามควรครอบด้วย ``
    • ตัวอย่างคือเชื่อม throw, yeet เข้ากับคำจำกัดความเดียวกัน และให้คำจำกัดความแยกกับ no cap, bet
    
    throw
    yeet
    Verb. To discard at a high velocity
    no cap
    Interjection. Expresses authenticity and truthfulness, sometimes surprise.
    bet
    Interjection. Expresses agreement and affirmation.

  • ความหมายที่กว้างขึ้นใน HTML5

    • ใน HTML5 มันขยายจากรายการคำจำกัดความไปเป็น รายการคำอธิบาย ที่ไม่ได้จำกัดแค่การนิยาม และใช้ได้เมื่อมี “ชุดของคำกับค่า”
    • HTML5 อนุญาตให้ใช้ ซึ่งเป็น wrapper ที่ไม่มีความหมายเชิง semantic เพื่อจัดกลุ่ม และ `` ที่เกี่ยวข้องกัน
    • ตัวอย่างเอนจินเบราว์เซอร์คือจัด Chrome, Opera, Brave, Edge ไว้ในกลุ่ม Blink-based browsers และ Firefox, Tor, Librewolf ไว้ในกลุ่ม Gecko-based browsers
    
      Chrome
      Opera
      Brave
      Edge
      Blink-based browsers

      Firefox
      Tor
      Librewolf
      Gecko-based browsers

  • เมทาดาทาและการดีบัก JSON

    • ถ้าเป็นชุดต่อเนื่องของข้อเท็จจริงและป้ายชื่อ การใช้รายการคำอธิบายเพื่อแสดง เมทาดาทา ถือว่าเหมาะสม
    • โปรไฟล์ผู้ใช้ก็สามารถใส่ใน ได้ โดยตัวอย่างแสดง `First Frank`, `Last Taylor`, `Age 44`, `Job Writer`, `Handle Paceaux` เป็นคู่ และ ``
    • รายการคำอธิบายยังใช้สำหรับ การดีบัก JSON ใน single-page application ได้ด้วย
    • ตัวอย่าง DebugJson จะวน key, value ของอ็อบเจ็กต์ด้วย Object.entries(obj) แล้วเรนเดอร์คีย์เป็น ... และค่าเป็น ...
    • ถ้าค่าเป็นอ็อบเจ็กต์และไม่ใช่อาร์เรย์ จะเรียก DebugJson.createDl(value) ซ้ำเพื่อสร้าง แบบซ้อน และถ้าไม่ใช่ก็ใส่ `value.toString()` ลงใน
      const debugJson = new DebugJson({foo: 'bar', arr: ['a', 'b'], car: 1}, '.container')
  debugJson.render();
    • รายการคำอธิบายรองรับความต้องการแบบ คู่คีย์-ค่า ได้อย่างกว้างขวาง

เมนู: ``

  • องค์ประกอบ menu ใช้แทนรายการของคำสั่ง และใกล้เคียงกับเว็บแบบโต้ตอบมากกว่าการเรนเดอร์เนื้อหา
  • menu เหมาะกับรายการปุ่มที่เป็น “เครื่องมือ” เช่น คอนโทรลแก้ไขข้อความใน rich text editor
  • ตัวอย่าง rich text editor วางปุ่ม Strong, Emphasize, Strike เป็น li ภายใน menu

- Strong

- Emphasize

- Strike
  • ตามสเปก HTML นี่เป็นการใช้งานแบบ toolbar และในหน้าเว็บที่มีการโต้ตอบ พื้นที่ที่มีปุ่มเครื่องมือก็มักเป็นตัวเลือกที่เหมาะกับ menu
  • ตัวอย่างคอนโทรลวิดีโอก็อยู่ใน menu เช่นกัน โดยใส่ commandfor="vid-123" และ command="--play", --mute, --fullscreen บน button

- Play

- Mute

- Fullscreen
  • เมื่อใช้ menu ก็ไม่จำเป็นต้องเพิ่ม aria-role="menu" ให้กับรายการไม่มีลำดับ

  • อย่าคิดว่า li อยู่ได้แค่ในสองคอนเทนเนอร์

    • หากไม่ต้องการให้รายการในส่วนนำทางดูเหมือนรายการทั่วไป ก็ต้องจัดการกับ menu li ด้วยเช่นกัน
    • ที่ส่วนต้นของสไตล์ชีต ควรใส่ทั้ง nav li และ menu li เพื่อรีเซ็ต list-style-type, text-indent, margin
      nav li,
  menu li {
      list-style-type: none;
      text-indent: 0;
      margin: 0;
  }

  • กับ ไม่เหมือนกัน

    • nav ไม่ใช่แค่ menu ที่มีลิงก์เท่านั้น แต่มี ความหมายและเนื้อหาที่อนุญาต ต่างกัน
    • nav เป็น sectioning element ที่มีความหมายว่าให้ผู้ใช้เห็น “รายการหลายอย่างที่เกี่ยวกับการไปยังที่ใดที่หนึ่ง”
    • nav สามารถมี , อย่างย่อหน้าและหัวเรื่อง รวมถึงรายการอย่าง , , `` ได้
    • menu เป็น list element ที่มีความหมายว่าให้ผู้ใช้เห็น “รายการของสิ่งที่ทำได้” และอนุญาตเฉพาะรายการย่อย `
  • ` เท่านั้น
    • menu และ nav ไม่ใช่ตัวเลือกที่ต้องเลือกอย่างใดอย่างหนึ่ง โดย menu สามารถอยู่ใน nav ได้ แต่ nav อยู่ใน menu ไม่ได้

รายการไม่มีลำดับ: ``

  • ul เป็น รายการสารพัดงาน สำหรับความต้องการเรื่องรายการที่ไม่เข้ากับรายการประเภทอื่นหรือ nav
  • ใน HTML สมัยก่อน ความแตกต่างระหว่างรายการมีลำดับกับไม่มีลำดับมักใกล้เคียงกับความต่างทางภาพ เช่น เป็นตัวเลขหรือเป็น bullet
  • ปัจจุบันต้องคำนึงถึงการเข้าถึง, screen reader และ SEO จึงควรสนใจว่า ลำดับมีความหมายหรือไม่ มากกว่าหน้าตาทางภาพ
  • รายชื่อสมาชิกวงดนตรีไม่มีลำดับที่สำคัญ จึงเหมาะกับ ul
  Beatles

- John Lennon

- Paul McCartney

- Ringo Star

- George Harrison
  • รายชื่อวงดนตรีเองก็สามารถแสดงเป็นรายการไม่มีลำดับได้เช่นกัน

- Beatles

- Rolling Stones

- Van Halen

- Foo Fighters

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

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

 
GN⁺ 2026-05-17
ความคิดเห็นจาก Hacker News

  • แค่ลองทดสอบตัวอย่างก็เหมือนว่า datalist จะทำงานได้ไม่ดีบน Mobile Safari
    ถ้ามีปัญหาความเข้ากันได้ในตลาดใหญ่ขนาดนี้ ก็อาจพูดได้ว่าแทบไม่มีสถานการณ์ที่คุ้มจะนำไปใช้จริง

    • เป็นข้อมูลแบบ น้ำเย็นสาดใส่ความจริง ที่ไม่อยากได้แต่จำเป็นต้องรู้

      เมื่อกว่าสิบปีก่อนฉันเคยทำโปรเจกต์ที่ใช้วิดเจ็ตแนะนำการป้อนข้อมูลใน UI แบบค่อนข้างจัดเต็ม และตอนนั้นใช้ปลั๊กอิน jQuery
      มันเป็นส่วนที่ซับซ้อนที่สุดของฟรอนต์เอนด์ และแทบจะเป็นเหตุผลหลักที่โปรเจกต์นั้นต้องใช้ jQuery

      ตอนอ่านบทความนี้ก็คิดว่าการทำฟรอนต์เอนด์นั้นขึ้นมาใหม่ด้วย JS แบบเบาๆ และย่อให้เล็กน่าจะเป็นเรื่องง่ายมาก แต่ความจริงไม่ได้เป็นแบบนั้น เว้นแต่เราจะส่งสภาพแวดล้อมของเราทั้งชุดไปยังอุปกรณ์ของผู้ใช้ด้วย
      ถึงอย่างนั้นฟีเจอร์ที่อยู่ใน HTML spec ทุกวันนี้ก็น่าประทับใจมาก
      ตั้งแต่อ่าน XHTML ตอนมัธยม ฉันแทบไม่ได้ตามการเปลี่ยนแปลงของสเปกเลย คงต้องหาเวลาดูบ้างว่ามีอะไรเปลี่ยนไป
      แต่เรื่องความเข้ากันได้ของเบราว์เซอร์ก็ยังปวดหัวเหมือนเดิมไม่ต่างจากตอนนั้น

    • ตัวอย่าง datalist ใช้งานได้แน่นอนบน iPhone ของฉัน
      มันถูกรวมเข้าไปในพื้นที่คำแนะนำการเติมอัตโนมัติเหนือคีย์บอร์ด iOS แบบเนทีฟ
      แต่ไม่มีวิธีไล่ดูคำแนะนำทั้งหมด และดูเหมือนว่านั่นก็ไม่ใช่วิธีใช้งาน datalist ที่ตั้งใจไว้แต่แรก

      แต่ disabled ของ group นั้นไม่ทำงานแน่นอน

    • บน Firefox ของ Android ก็ใช้ไม่ได้เหมือนกัน

    • เมื่อนานมากแล้วตอนทำงานที่แรก datalist บน Firefox ใช้งานไม่ได้ และเพราะแบบนั้น Firefox เลยถูกตัดออกจากรายชื่อเบราว์เซอร์ที่รองรับ

      มันเป็นฟีเจอร์ที่มีปัญหามานานมาก ถ้าจะรองรับเบราว์เซอร์อื่นนอกจาก Chrome

    • ใช้กับ GBoard บน iOS แล้วทำงานได้ไม่ดี

  • ตัวอย่างที่เพิ่ม disabled ให้ optgroup เพื่อทำให้บางตัวเลือกเลือกไม่ได้ ดูเหมือนจะพังบน Mobile Safari
    ในความเป็นจริงมันไม่ได้ถูกปิดใช้งาน และยังเลือกค่าที่ควรถูกปิดได้อยู่

    • บน Safari รุ่นล่าสุดมันควรจะทำงานได้ ดังนั้นอาจไม่ถึงกับพัง แต่เป็นอาการแปลกมากกว่า

      https://caniuse.com/mdn-html_elements_optgroup_disabled

      ดูมีโอกาสว่าจะเป็น บั๊กของ Safari

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

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

  • เป็นบทความที่สนุกและครอบคลุมดีมาก

    น่าเสียดายที่ทุกวันนี้มี นักพัฒนาที่ข้ามการเรียน HTML แล้วไปเริ่มที่ React เลย เยอะมาก และตอนนี้พอมี LLM ก็ยิ่งมีโอกาสที่คนจะไม่เรียน HTML เลยด้วยซ้ำ

    เลยกลายเป็นว่าต่อให้เป็นงานที่ HTML ธรรมดาก็พอ คนก็ยังเริ่มจากการมองหา React component ก่อน

    • ฉันว่าก็ไม่เป็นไร

      ตอนที่ต้องใช้ XML ครั้งแรก ฉันต้องเรียน XML spec และสร้าง output เอง
      มันเป็นยุคที่แทบไม่มี serialization library เลย
      หลังจากนั้นก็เห็นรุ่นน้องใช้ XML และต่อมาก็ JSON เป็นรูปแบบแลกเปลี่ยนข้อมูลโดยไม่ได้เรียนมันแบบลึกๆ แต่ก็ไม่ได้มีปัญหาอะไร

      AJAX ก็เปลี่ยนจากของใหม่ร้อนแรงไปเป็นคำที่คนไม่รู้ด้วยซ้ำว่าย่อมาจากอะไร และตอนนี้คนส่วนใหญ่ก็แทบจำคำนี้ไม่ได้แล้ว
      AJAX ไม่ได้ตายไป แต่มันแพร่หลายจนไม่จำเป็นต้องมีคำเรียกเฉพาะอีกต่อไป

    • ปัญหาของฉันคือฉันเรียน HTML อย่างจริงจังเมื่อ 20 ปีก่อน แต่หลังจากนั้นกลับรู้การเปลี่ยนแปลงและพัฒนาการของมันแค่ประปรายโดยบังเอิญ
      CSS ก็ยิ่งเป็นแบบนั้นเข้าไปใหญ่

    • พูดตามตรง HTML มันจุกจิก

      ตัวอย่างเช่น วิธีแบบ HTML ในการสไตล์บางส่วนของคอนโทรลคือใช้ pseudo-class แต่บางครั้ง selector ก็แตกต่างกันไปในแต่ละเบราว์เซอร์
      แบบนี้ก็ไม่มีทางรู้ได้จริงๆ ว่ามันทำงานถูกต้องหรือเปล่า จึงต้องทดสอบแยกตามเบราว์เซอร์

      React ไม่ได้แค่ง่ายกว่า แต่ยังน่าเชื่อถือกว่า
      ถ้าทำด้วย React กับ div หลายๆ ตัว ก็พอคาดหวังได้ว่ามันจะทำงานเหมือนกันในทุกเบราว์เซอร์

  • เนื้อหาดีมาก แต่ไม่ควรคาดหวังจาก datalist มากเกินไป
    มันมี จุดเชื่อมต่อ ไม่มากพอที่จะใช้งานได้อย่างมีประโยชน์จริง จึงไม่ค่อยเหมาะกับอะไรที่เกินต้นแบบเล็กๆ

    • ฉันเคยใช้ datalist กับคำแนะนำการเติมอัตโนมัติ และมันทำงานได้ดีมาก
    • เหมือนฉันเคยพยายามทำ combobox ด้วย datalist มาก่อน แต่ไม่สำเร็จ

  • สงสัยว่า HTML linter จะช่วยแยกความต่างแบบนี้ได้จริงหรือเปล่า
    แล้วก็อยากรู้ว่ามี linter ที่บังคับการเลือกใช้ semantic tag แบบนี้ได้ไหม

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

    • สิ่งที่ใกล้เคียงที่สุดที่ฉันรู้คือ https://github.com/kristoff-it/superhtml#diagnostics

      SuperHTML ตรวจสอบไม่ใช่แค่ไวยากรณ์ แต่รวมถึงการซ้อนองค์ประกอบและค่าของแอตทริบิวต์ด้วย
      ไม่มี language server อื่นที่นำ HTML spec ทั้งหมดมาใส่ไว้ในโค้ดตรวจสอบแบบนี้

  • วันนี้เพิ่งรู้เรื่องนี้
    สงสัยว่าทำไมเฟรมเวิร์กถึงไม่เอาไปใช้กันมากกว่านี้

    • ในมุมประสบการณ์ผู้ใช้ มันก็เหมือนรายการทั่วไปนั่นแหละ
      ถ้ามันช่วยให้เข้าใจโค้ดได้ก็ใช้ได้ แต่ใน accessibility tree ของเบราว์เซอร์และในมิติอื่นๆ มันก็เป็นแค่ unordered list ธรรมดา

      ถ้าอยากสื่อว่านี่คือรายการของการกระทำ ก็ต้องเพิ่มแอตทริบิวต์ ARIA
      ในบทความพูดถึง role=menu แต่แค่นั้นยังไม่พอ แต่ละรายการก็ต้องมี role เป็น menuitem ด้วย
      WAI Authoring Practices Guide อธิบายเรื่อง role และความคาดหวังของการโต้ตอบไว้ แต่ไม่ควรคัดลอกตัวอย่างโค้ดไปใช้ตรงๆ และโดยเฉพาะอย่างยิ่งไม่ควรใช้ role นี้กับเมนูนำทาง

      https://www.w3.org/WAI/ARIA/apg/patterns/menubar/

    • คนฉลาดไม่ไปเรียน HTML ยากๆ หรอก ใช้ div หลายอันก็จบ

    • ทุกวันนี้ HTML มีฟีเจอร์น่าสนใจเยอะมาก

      ฉันชอบถามคนอื่นว่าเขาคิดว่า element ไหนทำอะไร
      ตอนแรกฉันเองก็เดาไม่ถูกเลยสักอย่าง

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

  • ถ้าแค่นักออกแบบ ชอบหน้าตา datalist แบบค่าเริ่มต้น ก็คงดี

    • จากประสบการณ์ของฉัน การปรับแต่งสไตล์ที่ทำได้น้อย คืออุปสรรคใหญ่ที่สุดของการใช้ฟีเจอร์ HTML แบบเนทีฟ

  • บทความในบล็อกดีมาก แต่ฉันหาวิธีดูรายชื่อบทความทั้งหมดของบล็อกนี้ทีเดียวไม่ได้เลย

    https://blog.frankmtaylor.com/archive ใช้ไม่ได้

    https://blog.frankmtaylor.com/archives ก็ไม่ใช่

    https://blog.frankmtaylor.com/posts ก็ใช้ไม่ได้

    https://blog.frankmtaylor.com/all ก็ไม่มี

    https://blog.frankmtaylor.com/blog ก็ไม่ใช่อีก

    มีคนจำนวนมากที่มีบุ๊กมาร์กเกิน 10,000 รายการ ดังนั้นถ้ามี หน้ารายการเดียว ที่แสดงบทความทั้งหมดที่เคยเขียนไว้โดยไม่มีคำอธิบายหรือข้อความเต็ม ก็คงสะดวกมากจริงๆ

    • หรือว่าหมายถึง sitemap?
      บล็อกส่วนใหญ่มี sitemap.xml ที่แสดงรายการบทความทั้งหมดอยู่แล้ว

      แล้วฉันก็สงสัยเหมือนกันว่าทำไมถึงอยากไล่ดูโพสต์ทั้ง 235 ชิ้นทั้งหมด