ยินดีต้อนรับสู่ Chrome Dev Insider ฉบับที่ 2 ซึ่งเราจะแชร์ข้อมูลอัปเดตเกี่ยวกับสิ่งใหม่ๆ และน่าตื่นเต้นในชุมชนและที่ Chrome นี่คือตอนใหม่ของเรื่องราวจากวงในเกี่ยวกับวิธีที่เราทำงาน และข้อมูลอัปเดตที่สำคัญที่สุดบางส่วนที่คุณควรทราบ
ฉันชื่อ Rachel Andrew เป็นหัวหน้าฝ่ายเนื้อหาของ web.dev และ developer.chrome.com ซึ่งเป็นส่วนหนึ่งของทีมความสัมพันธ์กับนักพัฒนาซอฟต์แวร์ Chrome ฉันทำงานบนเว็บมานานกว่า 20 ปี โดยมุ่งเน้นที่มาตรฐานเว็บแบบเปิดและ CSS และเป็นสมาชิกของ CSS Working Group
เมื่อ 2 เดือนที่ผ่านมา เราได้จัดงาน Google I/O ซึ่งเราได้แชร์ข้อมูลอัปเดตที่สำคัญที่สุดบางส่วนเกี่ยวกับวิธีที่เราสนับสนุนนักพัฒนาแอปในการทำให้เว็บเร็วขึ้นและมีประสิทธิภาพมากขึ้น พร้อมทั้งรักษาข้อมูลของผู้ใช้ให้ปลอดภัยและเป็นส่วนตัว
สิ่งหนึ่งที่โดดเด่น (และเรายินดีที่ชุมชนสังเกตเห็น!) คือปริมาณงานมหาศาลที่ทีมกำลังทำเพื่อรองรับฟีเจอร์ CSS และ UI เพิ่มเติมบนเว็บ ในฉบับนี้ของ Chrome Dev Insider เราจะพาคุณไปดูเบื้องหลังว่าใครเป็นผู้ทำงานนี้ วิธีที่เราทำงานเพื่อสนับสนุนนักพัฒนา CSS และ UI รวมถึงสิ่งที่จะเกิดขึ้นในอนาคต ด้วยเหตุนี้ ฉันจึงรู้สึกตื่นเต้นที่จะได้เป็นผู้ดำเนินรายการ Insider ฉบับนี้
ข่าวสาร
ใน Chrome Dev Insider ฉบับแรก เราได้แชร์ข้อมูลอัปเดตเกี่ยวกับโครงการริเริ่ม Compat 2021 และ Interop 2022 ซึ่งผู้ให้บริการเบราว์เซอร์และผู้เล่นในระบบนิเวศได้ร่วมมือกันเพื่อนำฟีเจอร์เพิ่มเติมมาสู่เว็บที่รองรับในเบราว์เซอร์ทั้งหมด โครงการนี้มุ่งเน้นที่ CSS เป็นอย่างมากเนื่องจากความไม่เข้ากันของเบราว์เซอร์เป็นหนึ่งในความท้าทายที่ใหญ่ที่สุดสำหรับนักพัฒนา CSS
แม้ว่าเรื่องนี้อาจไม่ใช่เรื่องใหม่สำหรับคนส่วนใหญ่ แต่เราก็รู้สึกตื่นเต้นที่ได้เห็นความคืบหน้าที่เราทำได้แล้วในเบราว์เซอร์ต่างๆ
เมื่อต้นเดือนที่ผ่านมา เราได้เห็น Safari ประกาศการเปิดตัวครั้งใหญ่ด้วย Safari 16.0 Beta ซึ่งมีฟีเจอร์ที่น่าตื่นเต้น เช่น Container Queries, subgrid และ flexbox inspector Firefox และ Chrome เวอร์ชันล่าสุดมีฟีเจอร์และการแก้ไขที่น่าสนใจมากมาย โดยฉันจะพูดถึงสิ่งสำคัญในเบราว์เซอร์เวอร์ชันเสถียรและเบต้าทุกเดือนในชุดโพสต์ใหม่สำหรับแพลตฟอร์มเว็บ
ข้อมูลวงใน: การสนับสนุนนักพัฒนา CSS และ UI
ปี 2022 เป็นปีที่น่าตื่นเต้นสำหรับฟีเจอร์ CSS เราจึงคิดว่านี่เป็นช่วงเวลาที่เหมาะที่จะพาคุณไปดูเบื้องหลัง ฉันได้พูดคุยกับ Una Kravets หัวหน้า DevRel สำหรับ Web UI และ DevTools รวมถึง Nicole Sullivan ผู้จัดการผลิตภัณฑ์สำหรับ Web UI ที่มุ่งเน้นไปที่ CSS และ HTML API เพื่อพูดคุยเกี่ยวกับเส้นทางของ Chrome ในการสนับสนุนนักพัฒนา UI
มาเริ่มที่พวกคุณทั้ง 2 คนกันก่อน บอกรายละเอียดเกี่ยวกับตัวคุณให้เราทราบสักเล็กน้อย
Nicole: ฉันเป็นผู้จัดการผลิตภัณฑ์สำหรับ UI เว็บใน Chrome โดยฉันจะมุ่งเน้นไปที่ API ของ CSS และ HTML ใหม่ รวมถึงนักพัฒนาแอปและนักออกแบบที่สร้าง UI ซึ่งเป็นพื้นที่ที่น่าตื่นเต้นและมี API ที่สำคัญมากบางอย่าง เช่น Container Queries, Scope และ (หวังว่า!) vertical rhythm
อูนา: ฉันเป็นหัวหน้าทีม DevRel ของ Web UI และเครื่องมือสำหรับนักพัฒนาเว็บ เรามุ่งเน้นการสนับสนุนวิศวกร UI บนแพลตฟอร์มเว็บและตรวจสอบว่าวิศวกรมีเครื่องมือที่จำเป็นต่อความสำเร็จ ซึ่งรวมถึง CSS API และคอมโพเนนต์ HTML พร้อมกับฟีเจอร์เครื่องมือสำหรับนักพัฒนาเว็บเพื่อดูการเปลี่ยนแปลงที่ใช้งานอยู่และรับความคิดเห็น
การสนับสนุนนักพัฒนา UI ของ Chrome ได้รับการเร่งความเร็วในช่วงไม่กี่ปีที่ผ่านมา คุณคิดว่าทำไมถึงใช้เวลานานขนาดนี้ ความท้าทายที่ยิ่งใหญ่ที่สุดคืออะไร
อูนา: เราต้องทำงานบางอย่างเพื่อแสดงให้เห็นว่างานนี้สำคัญเพียงใดและเหตุใดจึงควรให้ความสำคัญเป็นอันดับแรก เราเริ่มต้นด้วยแบบสำรวจ DNA ของ MDN ในปี 2019 ซึ่งระบุว่า UI เป็นหนึ่งในจุดที่สร้างความเจ็บปวดมากที่สุดบนแพลตฟอร์ม และนับจากนั้นเป็นต้นมา เราก็ใช้ข้อมูลเป็นแนวทางผ่าน MDN และแบบสำรวจความพึงพอใจของนักพัฒนาซอฟต์แวร์ภายในของเราอย่างต่อเนื่อง ผลลัพธ์ทั้งหมดนี้ทำให้เราได้รับการสนับสนุนจากผู้นำมากขึ้น และสามารถจัดลําดับความสําคัญของงานด้านวิศวกรรมเกี่ยวกับฟีเจอร์สำหรับนักพัฒนาซอฟต์แวร์ที่ได้รับการร้องขอมากที่สุดในพื้นที่ UI ซึ่งยังเป็นจุดสนใจส่วนใหญ่สําหรับโครงการริเริ่มต่างๆ เช่น Compat 2021 และ Interop 2022
นิโคล: นอกจากการได้รับการอนุมัติจากผู้บริหารแล้ว เรายังต้องหาวิธีที่เหมาะสมในการส่งต่อ API เหล่านี้ไปยังนักพัฒนาแอปด้วย ตอนที่เพิ่งเข้าร่วมทีม Chrome ผมเคยทำผิดพลาดในโปรเจ็กต์ที่ชื่อ Layered APIs (หรือ LAPIs) LAPIs มีเป้าหมายเพื่อมอบประสบการณ์คอมโพเนนต์แบบดร็อปอินให้แก่นักพัฒนาแอป เรายังคงคิดว่านี่เป็นผลลัพธ์ที่ยอดเยี่ยมที่ควรพยายามทำให้ได้ แต่เราก็ทำผิดพลาดไปมากเช่นกัน เรามุ่งเน้นไปที่การแจ้งเตือนแบบป๊อปอัปและรายการเสมือนเป็นอันดับแรก การทำให้ข้อความป๊อปอัปเข้าถึงได้นั้นแทบจะเป็นไปไม่ได้ และรายการเสมือนก็เป็นหนึ่งในคอมโพเนนต์ที่ทำให้ถูกต้องได้ยากที่สุด แม้ว่าเราจะมีเจตนาดี แต่โครงการนี้ไม่ได้ช่วยนักพัฒนาแอป เราจึงปิดตัวโครงการนี้ การเรียนรู้ด้วยวิธีที่ยากลำบากนั้นเป็นเรื่องยาก แต่ข้อผิดพลาดทุกอย่างกำลังกระตุ้นการฟื้นฟู CSS และ HTML ที่กำลังเกิดขึ้นในตอนนี้
มาพูดถึง LAPI กันอีกหน่อย เกิดอะไรขึ้น
นิโคล: สำหรับ LAPI เราทราบว่าเว็บต้องการประสบการณ์การใช้งานคอมโพเนนต์แบบดรอปอินสำหรับนักพัฒนาซอฟต์แวร์ที่ใกล้เคียงกับการสร้าง UI แบบเนทีฟมากขึ้น และเห็นได้ชัดว่าการประดิษฐ์ล้อใหม่เป็นการถ่วงความเจริญของนักพัฒนาแอป ฉันนับจำนวนแท็บที่สร้างขึ้นในอาชีพการงานไม่ได้เลย แต่เราก็พยายามแก้ปัญหานี้ด้วยการจัดส่ง JavaScript พร้อมกับเบราว์เซอร์ ซึ่งเป็นเรื่องที่ยากมาก ก่อนหน้านี้ไม่มีใครเคยส่ง JavaScript ในเบราว์เซอร์ และยังไม่ชัดเจนว่าควรโต้ตอบกับโค้ด C++ ที่ขับเคลื่อนเครื่องมือการแสดงผลของเบราว์เซอร์อย่างไร เราได้ฟังความคิดเห็นจากผู้ให้บริการเบราว์เซอร์รายอื่นๆ (ขอขอบคุณ Mozilla!) และถอยออกจากแนวทางดังกล่าว จึงได้พบสิ่งที่ดีกว่ามากด้วย Open UI การใช้ HTML และ CSS ทำให้เราได้โซลูชันที่ยืดหยุ่นและประกาศได้ เนื่องจากเป็นแบบประกาศ เราจึงสามารถฝังการช่วยเหลือพิเศษในลักษณะที่ทำได้ยากกว่าด้วย JavaScript ฉันตื่นเต้นมากกับทิศทางของเรื่องนี้ เรากำลังดำเนินการเพื่อรองรับ selectmenu, popup, tooltip, nav, accordion, tabs, carousel และ toggle ซึ่งเป็นรูปแบบการออกแบบ UI ที่จำเป็นอย่างยิ่ง
เราจึงได้เรียนรู้อะไรมากมาย และฉันรู้ว่ามีโครงการอื่นๆ ในพื้นที่นี้ เช่น CSS Houdini เรื่องราวคืออะไร
อูนา: ใช่ CSS Houdini เป็นอีกที่หนึ่งที่เราได้เรียนรู้จากชุมชน ฟีเจอร์ Houdini มีประโยชน์มากมาย แต่หลายฟีเจอร์ก็อยู่ในระดับต่ำเกินไปที่จะได้รับการยอมรับและการสนับสนุนในวงกว้าง เราตระหนักว่าการใช้ API ระดับต่ำไม่ได้ช่วยลดอุปสรรคสำหรับนักพัฒนาแอปเสมอไป แต่การมุ่งเน้นไปที่โซลูชันและความต้องการในระดับที่สูงขึ้นช่วยให้ได้รับการสนับสนุนข้ามเบราว์เซอร์และมีจุดเริ่มต้นที่จำเป็นต่อการขับเคลื่อนระบบนิเวศ ขณะนี้เรากำลังติดตามความคืบหน้าที่ https://ishoudinireadyyet.com/
เมื่อพูดถึงการรองรับข้ามเบราว์เซอร์ โครงการริเริ่มต่างๆ เช่น Interop 2022 และ Open UI ดูเหมือนจะให้ผลลัพธ์เชิงบวกที่สำคัญแก่ชุมชน คุณได้ยินอะไรจากนักพัฒนาแอปบ้าง
อูนา: ปัญหาที่นักพัฒนาซอฟต์แวร์มักพูดถึงกันมากที่สุดคือ "การออกแบบให้ทำงานเหมือนกันในทุกเบราว์เซอร์" เราได้แก้ไขปัญหานี้ด้วยการทำงานร่วมกับผู้ให้บริการเบราว์เซอร์รายอื่นๆ เพื่อจัดลําดับความสําคัญและเปิดตัวฟีเจอร์สําหรับนักพัฒนาซอฟต์แวร์ที่ได้รับการร้องขอมากที่สุด และผลตอบรับที่เราได้รับจากชุมชนก็เป็นไปในทางบวกอย่างท่วมท้น นอกจากนี้ ความพยายามในการปรับโครงสร้างครั้งใหญ่ที่เรียกว่า RenderingNG ยังช่วยให้เราสามารถเปิดตัวฟีเจอร์บางอย่างเหล่านี้ได้อย่างมีประสิทธิภาพมากขึ้น นักพัฒนาแอปตื่นเต้นที่ในที่สุดเราก็เริ่มทำงานกับฟีเจอร์ที่รอคอยมานานเหล่านี้ ซึ่งเป็นฟีเจอร์ที่นักพัฒนาแอปขอมาหลายปีแล้ว และฟีเจอร์นี้จะพร้อมใช้งานในทุกเบราว์เซอร์
นิโคล: ความตื่นเต้นในชุมชนนั้นสัมผัสได้ คุณดูได้ใน Twitter :)
การทำงานร่วมกับระบบนิเวศเป็นสิ่งสำคัญต่อความสำเร็จที่เราได้รับในการช่วยให้ชีวิตของนักพัฒนาแอปง่ายขึ้น เราทราบว่าทีมของคุณทำงานอย่างหนัก คุณช่วยแชร์รายละเอียดเพิ่มเติมได้ไหม
Nicole: ก่อนอื่น ฉันรู้สึกทึ่งกับโปรเจ็กต์ที่นักพัฒนาแอปสร้างบนเว็บอยู่เสมอ นักพัฒนาแอปกำลังสร้างสรรค์สิ่งต่างๆ ที่น่าทึ่ง ตั้งแต่ไลบรารีขนาดเล็กที่สุดไปจนถึงเฟรมเวิร์กเต็มรูปแบบ ซึ่งเป็นชุมชนผู้สร้างที่ยอดเยี่ยม และ Chrome กำลังดำเนินการหลายอย่างเพื่อเชื่อมต่อกับโปรเจ็กต์เหล่านี้ให้มากขึ้น
ตัวอย่างเช่น เมื่อ 2-3 ปีที่ผ่านมา เราได้เริ่มทำงานร่วมกับ JavaScript Framework เช่น React และ Angular และ Metaframework เช่น Next, Nuxt และ Gatsby เมื่อปีที่แล้ว เราเริ่มทำเช่นเดียวกันกับเครื่องมือและเฟรมเวิร์ก UI เช่น Sass, Bootstrap และ Material หวังว่าในปีหน้าเราจะได้ร่วมงานกับ GreenSock และเครื่องมืออื่นๆ ที่ช่วยให้ชีวิตของนักพัฒนาแอปง่ายขึ้น ฉันเพิ่งเห็น Cassie Evans จาก GreenSock พูดใน Smashing Conference และทำให้ฉันตื่นเต้นมากที่จะได้ร่วมงานกับผู้คนในวงการแอนิเมชัน
แล้วเราเห็นโอกาสที่ใหญ่ที่สุดสำหรับระบบนิเวศของ UI บนเว็บอยู่ที่ใด
อูนา: ในแง่ของโอกาสที่ยิ่งใหญ่ ฉันรู้สึกว่าเราเพิ่งเริ่มต้นในสิ่งที่สามารถทำได้สำหรับประสบการณ์บนเว็บที่ปรับแต่งได้ API ใหม่ๆ เช่น Container Queries และ User Preference Media Features ของ CSS กำลังกำหนดวิธีที่นักพัฒนาแอปมองการออกแบบที่ตอบสนองตามอุปกรณ์ใหม่ นอกจากนี้ ฉันยังตื่นเต้นกับประสบการณ์การออกแบบร่วมกันที่ช่วยให้นักพัฒนาซอฟต์แวร์และนักออกแบบทำงานร่วมกับผู้ใช้ที่เข้าชมเว็บไซต์ได้
แล้ว Nicole ทีมของคุณมีแผนกลยุทธ์อะไรต่อไป
นิโคล: การสำรวจบางอย่างอาจไม่ได้กลายเป็นผลิตภัณฑ์ที่พร้อมจัดส่ง แต่ก็มีหลายอย่างที่ฉันตื่นเต้นมากในตอนนี้
อูนาได้กล่าวถึงสิ่งแรกแล้ว นั่นคือการเปิดใช้การออกแบบที่ปรับเปลี่ยนตามอุปกรณ์และอิงตามคอมโพเนนต์ ซึ่งรวมถึงเครื่องมือสำหรับการออกแบบระบบสี เพื่อให้นักออกแบบสามารถตอบสนองต่อค่ากำหนดของผู้ใช้ เช่น โหมดมืด เช่น ระบบสี OKLCH จะรักษาความสว่างให้สอดคล้องกันในทุกเฉดสี นักออกแบบสามารถเปลี่ยนจากการเลือกสีไปเป็นการออกแบบความสัมพันธ์ระหว่างสีได้โดยไม่ต้องกังวลว่าชุดสีจะดูมัวหมอง
นอกจากนี้ เรายังกำลังดำเนินการกับ API ที่มีการขอมากที่สุดบางรายการ เช่น การค้นหาคอนเทนเนอร์ เลเยอร์แบบเรียงซ้อน ตัวเลือกหลัก (:has) รูปแบบที่กำหนดขอบเขต และการซ้อน นักพัฒนาแอปจำเป็นต้องใช้สิ่งเหล่านี้เพื่อสร้างระบบการออกแบบที่ยืดหยุ่นซึ่งเต็มไปด้วยคอมโพเนนต์ที่นำกลับมาใช้ใหม่ได้
การเลื่อนภาพเคลื่อนไหวที่ลิงก์เป็นอีกส่วนที่น่าสนใจ ฉันชอบการสาธิตของ Steve Gardner มาก โดยมีฟีเจอร์การเลื่อนที่ราบรื่นและภาพเคลื่อนไหวเครื่องบินสุดเจ๋งที่ทริกเกอร์เมื่อเลื่อน แม้ว่าการใช้ฟีเจอร์เหล่านี้จะสนุก แต่ก็อาจเป็นเรื่องยากที่จะทำให้ถูกต้อง โดยเฉพาะอย่างยิ่งเมื่อคำนึงถึงการช่วยเหลือพิเศษ เราจึงทำการทดสอบผู้ใช้เพื่อการช่วยเหลือพิเศษในฟีเจอร์นี้
สิ่งที่ผมตื่นเต้นมากที่สุดเป็นการส่วนตัวคือการควบคุม UI ของเว็บในตัว นักพัฒนาแอปสร้างชุดแท็บเดียวกันซ้ำแล้วซ้ำอีก ฉันคิดว่าเบราว์เซอร์ช่วยได้ ที่ Open UI เรากำลังทำงานกับคอมโพเนนต์ต่างๆ เช่น selectmenu, popup, tooltip, tabs, nav, accordion และ toggle เรากำลังพิจารณาว่าการผสานรวมการช่วยเหลือพิเศษเข้ากับองค์ประกอบพื้นฐานของเบราว์เซอร์เหล่านี้จะเป็นอย่างไร เพื่อให้เว็บสามารถเข้าถึงได้โดยค่าเริ่มต้นเมื่อเวลาผ่านไป จากนั้นนักพัฒนาแอปจะมุ่งเน้นไปที่ปัญหาที่ซับซ้อนและละเอียดอ่อนมากขึ้นได้ ในขณะที่เบราว์เซอร์จะรองรับพื้นฐานต่างๆ เช่น วิธีการใช้แท็บ เรื่องนี้อาจต้องมีโพสต์ของตัวเอง ฉันจึงจะหยุดตรงนี้ก่อน
สุดท้ายนี้ เราจะยังคงลงทุนในการทำงานร่วมกันระหว่างเบราว์เซอร์ต่อไป การทำงานร่วมกับทีมที่ WebKit และ Gecko เพื่อมอบประสบการณ์การใช้งานที่สอดคล้องกันแก่นักพัฒนาแอปเป็นเรื่องที่ยอดเยี่ยมมาก เราได้ยินอย่างชัดเจนว่านักพัฒนาแอปต้องการฟีเจอร์นี้
และหากคุณยังไม่ได้ลองใช้ Shared Element Transitions API ของทีม Seamless Web ก็ขอแนะนำให้ลองใช้ เพราะ API นี้จะเปลี่ยนวิธีที่ผู้คนออกแบบสำหรับเว็บ การเปลี่ยนผ่านเล็กๆ น้อยๆ ทั้งหมดนี้จะช่วยให้นักออกแบบปรับการออกแบบในพื้นที่จริงได้ง่าย Jake Archibald มีเดโมที่ยอดเยี่ยม
หากมาตรฐานเป็นไปได้ด้วยดี เราอาจพิจารณาเรื่องจังหวะแนวตั้งในปีนี้ด้วย เราสามารถสร้างบน LayoutNG ซึ่งปลดล็อกฟีเจอร์มากมาย
ขอบคุณทั้ง 2 ท่าน เราเชื่อว่าทั้งชุมชนคงตื่นเต้นเช่นเดียวกับเราที่จะได้เห็นการปรับปรุงและฟีเจอร์ใหม่ๆ ที่จะมาสู่โลกของ Web UI ยังมีอีกหลายอย่างที่ต้องทำความเข้าใจ คุณคิดว่าควรเริ่มเส้นทางนี้จากตรงไหน
อูนา: เซสชันมีอะไรใหม่สำหรับแพลตฟอร์มเว็บที่ I/O จะครอบคลุมไฮไลต์ของฟีเจอร์หลายอย่างที่จะเปิดตัวในปีนี้ Adam Argyle ยังได้เขียนบทความที่ยอดเยี่ยมเกี่ยวกับการเปิดตัว CSS ใหม่ๆ ทั้งหมดที่กำลังจะเกิดขึ้นด้วย ในตอนนี้ เราขอแนะนำให้คุณมุ่งเน้นที่รุ่นที่เสถียรและรับทราบถึงงานอื่นๆ ที่กำลังจะเกิดขึ้น ซีรีส์เพิ่งเคยใช้แพลตฟอร์มเว็บที่ยอดเยี่ยมของคุณเป็นซีรีส์ที่ควรติดตามเพื่อเรียนรู้เรื่องนี้ การสมัครรับจดหมายข่าวของ web.dev จะช่วยให้เนื้อหานี้ไปปรากฏในกล่องจดหมายของนักพัฒนาซอฟต์แวร์ด้วย และสำหรับนักพัฒนาซอฟต์แวร์ที่ต้องการมีส่วนร่วมและช่วยในเรื่องนี้ การเข้าร่วม Open UI เป็นวิธีที่ดีที่สุดวิธีหนึ่งในการสนับสนุนงานนี้
การอัปเดตที่สำคัญซึ่งกำลังจะมีขึ้น
เรายังคงยึดมั่นในธรรมเนียมของเราที่จะแจ้งให้คุณทราบล่วงหน้าเกี่ยวกับการเปลี่ยนแปลงที่กำลังจะเกิดขึ้น ซึ่งคุณควรคำนึงถึงขณะสร้างประสบการณ์การใช้งานเว็บ
จำกัด max-age สำหรับคุกกี้เป็น 400 วัน
- การอัปเดต: เมื่อตั้งค่าคุกกี้ด้วยแอตทริบิวต์
Expires/Max-Ageที่ชัดเจน ค่าจะจำกัดไว้ไม่เกิน 400 วันนับจากนี้ ก่อนหน้านี้ไม่มีการจำกัดและคุกกี้อาจหมดอายุในอนาคตอีกหลายพันปี เป้าหมายของขีดจํากัดนี้คือการสร้างสมดุลระหว่างรูปแบบการใช้งานทั่วไปกับการเคารพความเป็นส่วนตัวของผู้ใช้ เว็บไซต์ที่เข้าชมบ่อยกว่าทุกๆ 400 วันจะรีเฟรชคุกกี้เพื่อให้มั่นใจว่าบริการจะทำงานได้อย่างต่อเนื่อง และผู้ใช้มั่นใจได้ว่าคุกกี้จะไม่คงอยู่ในเบราว์เซอร์เป็นเวลานานโดยไม่มีการใช้งาน - ลำดับเวลาโดยประมาณ: เปิดตัวใน Chrome 104 (เสถียรในวันที่ 2 สิงหาคม 2022)
- CTA ของนักพัฒนาแอป: นักพัฒนาแอปอาจต้องรีเฟรชคุกกี้เชิงรุกบ่อยขึ้นกว่าเดิมเมื่อผู้ใช้เข้าชมเว็บไซต์ของตน ไม่เช่นนั้น ระบบอาจบันทึกการออกจากระบบของผู้ใช้ 400 วันหลังจากตั้งค่าคุกกี้ครั้งแรก
เราหวังว่าคุณจะสนุกกับการอ่านฉบับนี้ของ Chrome Dev Insider หากคุณพลาดไป นี่คือฉบับแรก เราหวังว่าจะได้นำเสนอข้อมูลเพิ่มเติมให้คุณในไตรมาสหน้า
ในระหว่างนี้ โปรดบอกเราว่าคุณคิดอย่างไรกับ Chrome Dev Insider ฉบับนี้และเราควรปรับปรุงอะไรบ้าง
คุณคิดว่าฉบับนี้ของ The Chrome Dev Insider เป็นอย่างไร แชร์ความคิดเห็น