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

Thomas Steiner

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

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

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

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

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

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

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

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

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

<permission type="camera" />

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

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

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

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

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

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

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

พฤติกรรม

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

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

  

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

  

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

  

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

การออกแบบ CSS

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

คุณใช้พร็อพเพอร์ตี้ 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 อื่นๆ

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

ความคิดเห็น

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

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

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

ลิงก์ที่เกี่ยวข้อง

• คำอธิบาย
• จุดยืนด้านมาตรฐานของ WebKit
• จุดยืนด้านมาตรฐานของ Mozilla

ขอขอบคุณ

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