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

Thomas Steiner

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

วิธีการที่จำเป็นในการขอสิทธิ์

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

ถามแบบบอกเป็นนัยเมื่อใช้ครั้งแรกกับขอแบบบอกล่วงหน้าอย่างชัดแจ้ง

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

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

ความท้าทายในการขออนุญาต

สแปมสิทธิ์

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

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

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

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

บริบทเกี่ยวกับสิทธิ์

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

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

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

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

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

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

<permission type="camera" />

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

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

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

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

ความคิดเห็น

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

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

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

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

• คำอธิบาย
• ตำแหน่งมาตรฐานของ WebKit
• ตำแหน่งมาตรฐานของ Mozilla

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

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