ช่วงทดลองใช้จากต้นทางสำหรับองค์ประกอบใหม่ <สิทธิ์>

การขอสิทธิ์เพื่อใช้ฟีเจอร์ที่มีประสิทธิภาพอย่างการเข้าถึงตำแหน่งในเว็บแอปมีอยู่หลายวิธีที่จำเป็น วิธีการเหล่านี้มาพร้อมกับความท้าทายหลายประการ ซึ่งเป็นเหตุผลที่ทีมสิทธิ์ของ Chrome กำลังทดสอบเมธอดแบบประกาศใหม่ซึ่งเป็นองค์ประกอบ HTML <permission> โดยเฉพาะ องค์ประกอบนี้อยู่ในช่วงทดลองใช้จากต้นทางตั้งแต่ Chrome 126 และเราหวังว่าจะกำหนดมาตรฐานให้ในที่สุด

วิธีการแบบบังคับสำหรับการขอสิทธิ์

เมื่อเว็บแอปต้องการเข้าถึงฟีเจอร์ที่มีประสิทธิภาพ จะต้องขอสิทธิ์ เช่น เมื่อ Google Maps ต้องการตำแหน่งของผู้ใช้โดยใช้ Geolocation API เบราว์เซอร์จะแสดงข้อความแจ้งแก่ผู้ใช้ โดยมักจะมีตัวเลือกให้จัดเก็บการตัดสินใจนั้น นี่เป็นแนวคิดที่ชัดเจนในข้อกําหนดของสิทธิ์

ขอโดยนัยเมื่อใช้งานครั้งแรก เทียบกับขออย่างชัดเจนตั้งแต่ต้น

Geolocation API เป็น API ที่มีประสิทธิภาพและอาศัยแนวทางแบบขอโดยนัยเมื่อใช้งานครั้งแรก ตัวอย่างเช่น เมื่อแอปเรียกใช้เมธอด navigator.geolocation.getCurrentPosition() ข้อความแจ้งสิทธิ์จะปรากฏขึ้นโดยอัตโนมัติเมื่อเรียกใช้ครั้งแรก อีกตัวอย่างหนึ่งคือ navigator.mediaDevices.getUserMedia()

API อื่นๆ เช่น Notification API หรือ Device Orientation and Motion API มักจะมีวิธีขอสิทธิ์อย่างชัดเจนผ่านเมธอดแบบคงที่ เช่น Notification.requestPermission() หรือ DeviceMotionEvent.requestPermission()

ปัญหาเกี่ยวกับเมธอดแบบบังคับสำหรับการขอสิทธิ์

สแปมสิทธิ์

ก่อนหน้านี้ เว็บไซต์สามารถเรียกใช้เมธอดต่างๆ เช่น navigator.mediaDevices.getUserMedia() หรือ Notification.requestPermission() และยังเรียกใช้ navigator.geolocation.getCurrentPosition() ได้ทันทีเมื่อโหลดเว็บไซต์ ข้อความแจ้งสิทธิ์จะปรากฏขึ้นก่อนที่ผู้ใช้จะโต้ตอบกับเว็บไซต์ บางครั้งเราเรียกวิธีนี้ว่าสแปมสิทธิ์ ซึ่งส่งผลต่อทั้ง 2 วิธี ทั้งการขอสิทธิ์โดยนัยเมื่อใช้งานครั้งแรกและการขอสิทธิ์อย่างชัดเจนตั้งแต่ต้น

ข้อความแจ้งสิทธิ์ใช้ไมโครโฟนแสดงขึ้นเมื่อโหลดเว็บไซต์

ข้อกำหนดด้านการลดการใช้เบราว์เซอร์และท่าทางสัมผัสของผู้ใช้

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

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

เบราว์เซอร์ Chrome ที่แสดง

บริบทของสิทธิ์

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

Google Maps ที่เปิดข้อความแจ้งสิทธิ์เข้าถึงตำแหน่ง ปุ่มการเข้าถึงตำแหน่งที่เรียกให้แสดงข้อความแจ้งอยู่ไกลเกินไป

เลิกทำไม่ได้ง่ายๆ

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

การควบคุมเว็บไซต์ Chrome บน Google Maps เพื่อเพิกถอนสิทธิ์

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

วิธีการของ Google Meet เกี่ยวกับวิธีเปิดตัวควบคุมเว็บไซต์ Chrome

องค์ประกอบ <permission> แบบประกาศ

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

<permission type="camera" />

ยังคงมีการถกเถียงกันอย่างต่อเนื่องว่า <permission> ควรเป็นองค์ประกอบที่ว่างเปล่าหรือไม่ องค์ประกอบ Void คือองค์ประกอบที่ปิดเองใน HTML ซึ่งไม่มีโหนดย่อยได้ ซึ่งใน HTML หมายความว่าองค์ประกอบดังกล่าวอาจไม่มีแท็กปิด

แอตทริบิวต์ type

แอตทริบิวต์ type มีรายการสิทธิ์ที่คุณร้องขอซึ่งคั่นด้วยการเว้นวรรค ณ เวลาที่เขียนบทความนี้ ค่าที่ใช้ได้มี 'camera', 'microphone' และ camera microphone (คั่นด้วยเว้นวรรค) องค์ประกอบนี้โดยค่าเริ่มต้นจะแสดงผลคล้ายกับปุ่มที่มีการจัดรูปแบบ User Agent ของ Barebones

ปุ่มองค์ประกอบสิทธิ์ต่างๆ ที่มีสิทธิ์กล้อง ไมโครโฟน และกล้องและไมโครโฟน

แอตทริบิวต์ type-ext

สำหรับสิทธิ์บางรายการที่อนุญาตให้ใช้พารามิเตอร์เพิ่มเติม แอตทริบิวต์ type-ext จะยอมรับคู่คีย์-ค่าที่คั่นด้วยเว้นวรรค เช่น precise:true สำหรับสิทธิ์เข้าถึงตำแหน่งทางภูมิศาสตร์

แอตทริบิวต์ lang

ข้อความปุ่มมาจากเบราว์เซอร์และมีไว้เพื่อให้สอดคล้องกัน จึงไม่สามารถปรับแต่งได้โดยตรง เบราว์เซอร์จะเปลี่ยนภาษาของข้อความตามภาษาที่รับค่ามาจากเอกสารหรือเชนองค์ประกอบหลัก หรือแอตทริบิวต์ lang ที่ไม่บังคับ ซึ่งหมายความว่านักพัฒนาซอฟต์แวร์ไม่จำเป็นต้องแปลองค์ประกอบ <permission> ด้วยตนเอง หากองค์ประกอบ <permission> ดำเนินการต่อจากระยะทดลองใช้ของต้นทาง ระบบอาจรองรับสตริงหรือไอคอนหลายรายการสำหรับสิทธิ์แต่ละประเภทเพื่อเพิ่มความยืดหยุ่น หากสนใจใช้<permission> องค์ประกอบและต้องการสตริงหรือไอคอนที่เฉพาะเจาะจง โปรดติดต่อเรา

พฤติกรรม

เมื่อโต้ตอบกับองค์ประกอบ <permission> ผู้ใช้จะหมุนเวียนผ่านขั้นตอนต่างๆ ได้ดังนี้

  • หากไม่เคยอนุญาตให้ใช้ฟีเจอร์มาก่อน ผู้ใช้จะอนุญาตฟีเจอร์นั้นทุกครั้งที่เข้าชม หรืออนุญาตสำหรับการเข้าชมปัจจุบันก็ได้

    ข้อความแจ้งสิทธิ์ให้อนุญาตฟีเจอร์ในครั้งนี้หรือทุกครั้งที่เข้าชม

  • หากเคยอนุญาตฟีเจอร์นี้ไว้ ผู้ใช้จะอนุญาตต่อไปหรือหยุดอนุญาตก็ได้

    ข้อความแจ้งสิทธิ์ให้อนุญาตต่อไปหรือหยุดอนุญาต

  • หากเคยไม่อนุญาตฟีเจอร์หนึ่งมาก่อน ผู้ใช้จะไม่สามารถอนุญาตหรืออนุญาตฟีเจอร์ดังกล่าวได้ในครั้งนี้

    ข้อความแจ้งสิทธิ์ให้ไม่อนุญาตต่อไปหรืออนุญาตในครั้งนี้

ข้อความขององค์ประกอบ <permission> จะอัปเดตโดยอัตโนมัติตามสถานะ เช่น หากได้รับสิทธิ์ให้ใช้ฟีเจอร์ ข้อความจะเปลี่ยนเป็น "อนุญาตฟีเจอร์นี้" หากต้องให้สิทธิ์ก่อน ข้อความจะเปลี่ยนเป็นการเชิญให้ผู้ใช้ใช้ฟีเจอร์ เปรียบเทียบภาพหน้าจอก่อนหน้ากับภาพหน้าจอต่อไปนี้เพื่อดูสถานะ 2 สถานะ

ปุ่มสิทธิ์ที่มีข้อความ

การออกแบบ CSS

ระบบจะจำกัดการจัดรูปแบบขององค์ประกอบ <permission> เพื่อให้ผู้ใช้จดจำปุ่มว่าเป็นแพลตฟอร์มสำหรับเข้าถึงความสามารถอันทรงพลังได้อย่างง่ายดาย หากข้อจำกัดด้านการจัดรูปแบบใช้ไม่ได้กับกรณีการใช้งานของคุณ เรายินดีรับฟังสาเหตุและวิธีแก้ปัญหา แม้ว่าจะไม่สามารถรองรับความต้องการด้านการจัดรูปแบบได้ทั้งหมด แต่เราหวังว่าจะค้นพบวิธีที่ปลอดภัยในการอนุญาตการจัดรูปแบบองค์ประกอบ <permission> เพิ่มเติมหลังจากช่วงทดลองใช้จากต้นทาง ตารางต่อไปนี้แสดงรายละเอียดพร็อพเพอร์ตี้บางรายการที่มีข้อจํากัดหรือกฎพิเศษ ในกรณีที่มีการละเมิดกฎ ระบบจะปิดใช้องค์ประกอบ <permission> และผู้ใช้จะโต้ตอบกับองค์ประกอบดังกล่าวไม่ได้ การพยายามโต้ตอบกับองค์ประกอบดังกล่าวจะทำให้เกิดข้อยกเว้นที่จับได้ด้วย JavaScript ข้อความแสดงข้อผิดพลาดจะมีรายละเอียดเพิ่มเติมเกี่ยวกับการละเมิดที่ตรวจพบ

พร็อพเพอร์ตี้ กฎ

color background-color

สามารถใช้เพื่อตั้งค่าข้อความและสีพื้นหลังตามลำดับ ความคมชัดระหว่าง 2 สีต้องเพียงพอสำหรับข้อความที่อ่านได้ชัดเจน (อัตราส่วนความคมชัดอย่างน้อย 3) ช่องอัลฟาต้องมีค่าเป็น 1

font-size zoom

ต้องตั้งค่าภายในค่าเทียบเท่าของ small และ xxxlarge มิเช่นนั้นระบบจะปิดใช้องค์ประกอบ ระบบจะพิจารณาการซูมเมื่อคํานวณ font-size

outline-offset

ระบบจะแก้ไขค่าติดลบเป็น 0
margin (ทั้งหมด) ค่าติดลบจะถูกแก้ไขเป็น 0

font-weight

ระบบจะแก้ไขค่าที่ต่ำกว่า 200 เป็น 200

font-style

ระบบจะแก้ไขค่าที่ไม่ใช่ normal และ italic เป็น normal

word-spacing

ระบบจะแก้ไขค่าที่มากกว่า 0.5em เป็น 0.5em ระบบจะแก้ไขค่าภายใต้ 0 เป็น 0

display

ระบบจะแก้ไขค่าที่ไม่ใช่ inline-block และ none เป็น inline-block

letter-spacing

ระบบจะแก้ไขค่าที่มากกว่า 0.2em เป็น 0.2em ระบบจะแก้ไขค่าที่ต่ำกว่า -0.05em เป็น -0.05em

min-height

จะมีค่าเริ่มต้นเป็น 1em หากระบุ ระบบจะพิจารณามูลค่าที่คำนวณสูงสุดระหว่างค่าเริ่มต้นและค่าที่ระบุ

max-height

จะมีค่าเริ่มต้นเป็น 3em หากระบุ ระบบจะพิจารณาค่าที่คำนวณขั้นต่ำระหว่างค่าเริ่มต้นกับค่าที่ระบุ

min-width

จะมีค่าเริ่มต้นเป็น fit-content หากระบุ ระบบจะพิจารณาค่าสูงสุดที่คำนวณระหว่างค่าเริ่มต้นกับค่าที่ระบุ

max-width

จะมีค่าเริ่มต้นเป็น fit-content คูณ 3 หากระบุ ระบบจะพิจารณาค่าต่ำสุดที่คำนวณระหว่างค่าเริ่มต้นกับค่าที่ระบุ

padding-top

จะมีผลก็ต่อเมื่อตั้งค่า height เป็น auto เท่านั้น ในกรณีนี้ ระบบจะแก้ไขค่าที่มากกว่า 1em เป็น 1em และตั้งค่า padding-bottom เป็น padding-top

padding-left

จะมีผลก็ต่อเมื่อตั้งค่า width เป็น auto เท่านั้น ในกรณีนี้ ค่าที่เกิน 5em จะได้รับการแก้ไขเป็น 5em และกำหนด padding-right เป็นค่า padding-left.

transform

ไม่อนุญาตให้เอฟเฟกต์ภาพที่บิดเบี้ยว ขณะนี้เรายอมรับเฉพาะการแปล 2 มิติและการขยายขนาดตามสัดส่วน

คุณใช้พร็อพเพอร์ตี้ CSS ต่อไปนี้ได้ตามปกติ

  • font-kerning
  • font-optical-sizing
  • font-stretch
  • font-synthesis-weight
  • font-synthesis-style
  • font-synthesis-small-caps
  • font-feature-settings
  • forced-color-adjust
  • text-rendering
  • align-self
  • anchor-name aspect-ratio
  • border (และที่พัก border-* แห่งทั้งหมด)
  • clear
  • color-scheme
  • contain
  • contain-intrinsic-width
  • contain-intrinsic-height
  • container-name
  • container-type
  • counter-*
  • flex-*
  • float
  • height
  • isolation
  • justify-self
  • left
  • order
  • orphans
  • outline-* (ยกเว้น outline-offset ตามที่ระบุไว้ก่อนหน้านี้)
  • overflow-anchor
  • overscroll-behavior-*
  • page
  • position
  • position-anchor
  • content-visibility
  • right
  • scroll-margin-*
  • scroll-padding-*
  • text-spacing-trim
  • top
  • visibility
  • x
  • y
  • ruby-position
  • user-select
  • width
  • will-change
  • z-index

นอกจากนี้ คุณยังใช้พร็อพเพอร์ตี้ทั้งหมดที่เทียบเท่ากันเชิงตรรกะได้ (เช่น inline-size เทียบเท่ากับ width) โดยทำตามกฎเดียวกันกับพร็อพเพอร์ตี้ที่เทียบเท่า

คลาสจำลอง

ไพเสสคลาสพิเศษ 2 รายการที่อนุญาตให้จัดสไตล์องค์ประกอบ <permission> ตามสถานะ ได้แก่

  • :granted: คลาสจำลอง :granted ช่วยให้จัดสไตล์พิเศษได้เมื่อมีการให้สิทธิ์
  • :invalid: คลาสเทียม :invalid อนุญาตให้มีการจัดรูปแบบพิเศษเมื่อองค์ประกอบอยู่ในสถานะที่ไม่ถูกต้อง เช่น เมื่อแสดงใน iframe แบบข้ามต้นทาง
permission {
  background-color: green;
}

permission:granted {
  background-color: light-green;
}

/* Not supported during the origin trial. */
permission:invalid {
  background-color: gray;
}

เหตุการณ์ JavaScript

องค์ประกอบ <permission> มีไว้เพื่อใช้ร่วมกับ Permissions API มีหลายเหตุการณ์ที่สามารถฟังได้ เช่น

  • onpromptdismiss: เหตุการณ์นี้จะทริกเกอร์เมื่อผู้ใช้ปิดข้อความแจ้งสิทธิ์ที่เกิดจากองค์ประกอบ (เช่น โดยการคลิกปุ่มปิดหรือคลิกนอกข้อความแจ้ง)

    เป็นต้น
  • onpromptaction: เหตุการณ์นี้จะทริกเกอร์เมื่อผู้ใช้ดำเนินการบางอย่างกับข้อความแจ้งสิทธิ์ที่เกิดจากองค์ประกอบนั้นๆ เพื่อแก้ไข การดำเนินการนี้ไม่ได้หมายความว่าสถานะสิทธิ์มีการเปลี่ยนแปลง ผู้ใช้อาจดำเนินการที่คงสถานะเดิมไว้ (เช่น ยังคงให้สิทธิ์ต่อไป)

    เป็นต้น
  • onvalidationstatuschange: เหตุการณ์นี้จะทํางานเมื่อองค์ประกอบเปลี่ยนจาก "valid" เป็น "invalid" ระบบจะถือว่าองค์ประกอบเป็น "valid" เมื่อเบราว์เซอร์เชื่อถือความสมบูรณ์ของสัญญาณในกรณีที่ผู้ใช้คลิก และ "invalid" ในกรณีอื่นๆ เช่น เมื่อองค์ประกอบถูกบดบังบางส่วนโดยเนื้อหา HTML อื่นๆ

คุณลงทะเบียน Listener เหตุการณ์สำหรับเหตุการณ์เหล่านี้ได้โดยตรงในบรรทัดในโค้ด HTML (<permission type="…" onpromptdismiss="alert('The prompt was dismissed');" />) หรือใช้ addEventListener() บนองค์ประกอบ <permission> ดังที่แสดงในตัวอย่างต่อไปนี้

<permission type="camera" />
<script>
  const permission = document.querySelector('permission');
  permission.addEventListener('promptdismiss', showCameraWarning);

  function showCameraWarning() {
    // Show warning that the app isn't fully usable
    // unless the camera permission is granted.
  }

  const permissionStatus = await navigator.permissions.query({name: "camera"});
  
  permissionStatus.addEventListener('change', () => {
    // Run the check when the status changes.
    if (permissionStatus.state === "granted") {
      useCamera();
    }
  });

  // Run the initial check.
  if (permissionStatus.state === "granted") {
    useCamera();
  }
</script>

การตรวจหาองค์ประกอบ

หากเบราว์เซอร์ไม่รองรับองค์ประกอบ HTML องค์ประกอบนั้นจะไม่แสดง ซึ่งหมายความว่าหากคุณมีเอลิเมนต์ <permission> ในโค้ด HTML จะไม่มีอะไรเกิดขึ้นหากเบราว์เซอร์ไม่ทราบ คุณอาจยังต้องการตรวจสอบการรองรับโดยใช้ JavaScript เช่น เพื่อสร้างข้อความแจ้งสิทธิ์ที่ทริกเกอร์ผ่านการคลิก <button> ปกติ

if ('HTMLPermissionElement' in window) {
  // The `<permission>` element is supported.
}

ช่วงทดลองใช้จากต้นทาง

หากต้องการลองใช้องค์ประกอบ <permission> ในเว็บไซต์กับผู้ใช้จริง ให้ลงชื่อสมัครใช้ช่วงทดลองใช้เวอร์ชันที่ใช้งานจริง อ่านเริ่มต้นใช้งานการทดสอบต้นทางเพื่อดูวิธีการเตรียมเว็บไซต์ให้ใช้การทดสอบต้นทาง ช่วงทดลองใช้จากต้นทางจะทำงานตั้งแต่ Chrome 126 ถึง 131 (19 กุมภาพันธ์ 2025)

สาธิต

สำรวจเดโมและดูซอร์สโค้ดใน GitHub ภาพหน้าจอของประสบการณ์การใช้งานในเบราว์เซอร์ที่รองรับ

การสาธิตองค์ประกอบสิทธิ์ที่แสดงปุ่มสิทธิ์ 3 ปุ่ม

ความคิดเห็น

เรายินดีรับฟังความคิดเห็นว่า <permission> ทำงานอย่างไรสำหรับกรณีการใช้งานของคุณ โปรดตอบกลับปัญหาในที่เก็บหรือส่งปัญหาใหม่ สัญญาณสาธารณะใน repo ขององค์ประกอบ <permission> จะช่วยให้เราและเบราว์เซอร์อื่นๆ ทราบว่าคุณสนใจองค์ประกอบนั้น

คำถามที่พบบ่อย

  • วิธีนี้ดีกว่า <button> ปกติที่จับคู่กับ Permissions API อย่างไร การคลิก <button> เป็นท่าทางสัมผัสของผู้ใช้ แต่เบราว์เซอร์ไม่สามารถตรวจสอบได้ว่าการคลิกดังกล่าวเชื่อมโยงกับคำขอสิทธิ์หรือไม่ หากผู้ใช้คลิก <permission> เบราว์เซอร์จะมั่นใจได้ว่าการคลิกนั้นเกี่ยวข้องกับคำขอสิทธิ์ ซึ่งช่วยให้เบราว์เซอร์ดำเนินการตามขั้นตอนต่างๆ ได้โดยไม่เสี่ยงมากนัก เช่น ช่วยให้ผู้ใช้ยกเลิกการบล็อกสิทธิ์ได้ง่ายๆ
  • จะเกิดอะไรขึ้นหากเบราว์เซอร์อื่นๆ ไม่รองรับองค์ประกอบ <permission> คุณใช้องค์ประกอบ <permission> เป็นการเพิ่มประสิทธิภาพแบบเป็นขั้นเป็นตอนได้ ในเบราว์เซอร์ที่ไม่รองรับ คุณจะใช้ขั้นตอนการขอสิทธิ์แบบคลาสสิกได้ เช่น อิงตามการคลิก <button> ปกติ ทีมสิทธิ์ก็กำลังพัฒนา polyfill ด้วย ติดดาวที่เก็บ GitHub เพื่อรับการแจ้งเตือนเมื่อพร้อมใช้งาน
  • มีการพูดคุยเรื่องนี้กับผู้ให้บริการเบราว์เซอร์รายอื่นหรือไม่ องค์ประกอบ <permission> ได้ถูกพูดถึงอย่างจริงจังใน W3C TPAC ปี 2023 ในเซสชันย่อย คุณสามารถอ่านหมายเหตุเซสชันสาธารณะ ทีม Chrome ยังได้ขอตำแหน่งมาตรฐานอย่างเป็นทางการจากผู้ให้บริการทั้ง 2 รายด้วย โปรดดูที่ส่วนลิงก์ที่เกี่ยวข้อง องค์ประกอบ <permission> เป็นหัวข้อที่มีการพูดคุยกับเบราว์เซอร์อื่นๆ อย่างต่อเนื่องและเราหวังว่าจะทำให้องค์ประกอบดังกล่าวเป็นไปตามมาตรฐาน
  • นี่ควรเป็นองค์ประกอบ Void ใช่ไหม ยังคงมีการถกเถียงกันอย่างต่อเนื่องว่า <permission> ควรเป็นองค์ประกอบที่ว่างเปล่าหรือไม่ หากมีความคิดเห็น โปรดแสดงความคิดเห็นในปัญหา

กิตติกรรมประกาศ

เอกสารนี้ได้รับการตรวจสอบโดย Balázs Engedy, Thomas Nguyen, Penelope McLachlan, Marian Harbach, David Warren และ Rachel Andrew