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

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 วิธีการ นั่นคือการขอโดยนัยเมื่อใช้งานครั้งแรกและการขออย่างชัดเจนล่วงหน้า

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

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

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

การให้บริบทของสิทธิ์

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

เลิกทำได้ยาก

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

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

องค์ประกอบ <permission> ที่ประกาศ

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

<permission type="camera" />

ปัจจุบันยังมีการถกเถียงกันอย่างต่อเนื่องว่า <permission> ควรเป็นองค์ประกอบที่ว่างเปล่าหรือไม่ องค์ประกอบว่างคือองค์ประกอบที่ปิดตัวเองใน 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) โดยทำตามกฎเดียวกันกับพร็อพเพอร์ตี้ที่เทียบเท่า

Pseudo-classes

มี Pseudo-Class พิเศษ 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> ในเว็บไซต์กับผู้ใช้จริง ลงชื่อสมัครใช้การทดลองใช้ต้นทาง อ่านเริ่มต้นใช้งาน Origin Trials เพื่อดู วิธีการเตรียมเว็บไซต์ให้พร้อมใช้งาน Origin Trials ช่วงทดลองใช้จากต้นทาง จะเริ่มตั้งแต่ Chrome 126 ถึง 131 (19 กุมภาพันธ์ 2025)

สาธิต

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

ความคิดเห็น

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

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

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

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

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

คำขอบคุณ

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