การสืบค้นข้อมูลองค์ประกอบ และวิธีใช้งานในปัจจุบัน

เผยแพร่แล้ว: 2022-03-10
สรุปอย่างย่อ ↬ เราได้ทำงานเกิน ขีดจำกัดของสิ่งที่ CSS สามารถทำได้ มาเป็นระยะเวลาหนึ่งแล้ว ผู้สร้างเลย์เอาต์ที่ปรับเปลี่ยนตามอุปกรณ์จะยอมรับความผิดหวังและข้อบกพร่องของ CSS ที่บังคับให้เราเข้าถึงตัวประมวลผลล่วงหน้า ปลั๊กอิน และเครื่องมืออื่นๆ ของ CSS เพื่อช่วยให้เราเขียนสไตล์ที่เราไม่สามารถเขียนด้วย CSS เพียงอย่างเดียวได้ ถึงกระนั้น เราก็พบกับข้อจำกัดด้วยเครื่องมือปัจจุบันที่ช่วยให้เราบรรลุผลสำเร็จ

คิดสักครู่เกี่ยวกับโครงสร้างทางกายภาพ หากคุณกำลังสร้างสิ่งปลูกสร้างขนาดใหญ่ด้วยวัสดุที่ไม่แข็งแรง จำเป็นต้องมีการสนับสนุนภายนอกจำนวนมากเพื่อยึดเข้าด้วยกัน และต้องสร้างสิ่งต่างๆ มากเกินไปเพื่อให้แข็งแรง เมื่อคุณสร้างเว็บไซต์จาก HTML, CSS และ JavaScript การสนับสนุนภายนอกนี้อาจดูเหมือนเฟรมเวิร์ก ปลั๊กอิน ตัวประมวลผลล่วงหน้า ทรานสปิลเลอร์ เครื่องมือแก้ไข ตัวจัดการแพ็คเกจ และกระบวนการสร้าง

เพิ่มเติมหลังกระโดด! อ่านต่อด้านล่าง↓

แทนที่จะเพิ่มปลั๊กอินอื่นที่ด้านบนสุดของสแต็ก ฉันสงสัยว่าด้วย การขยายหนึ่งในภาษาหลัก CSS เราสามารถเสริมความแข็งแกร่งให้กับวัสดุที่สร้างเว็บไซต์ พัฒนาเว็บไซต์ที่ดีขึ้นและแข็งแกร่งขึ้นซึ่งต้องการการสนับสนุนและเครื่องมือจากภายนอกน้อยกว่า สร้าง.

สถานะปัจจุบันของแบบสอบถามองค์ประกอบ

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

ปัญหา

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

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

มีความหวังสำหรับอนาคตของการพัฒนาเว็บหรือไม่?

ในปี 2013 Tyson Matanich เขียนบทความเรื่อง "Media Queries Are Not the Answer: Element Query Polyfill" ซึ่งแนะนำแนวคิดของการสืบค้นองค์ประกอบให้กับผู้ชมจำนวนมาก เริ่มต้นการอภิปรายเกี่ยวกับวิธีการสร้างปลั๊กอินและโพลีฟิลเพื่อนำทางข้อบกพร่องของ CSS

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

แบบสอบถามองค์ประกอบคืออะไร?

การสืบค้นองค์ประกอบเป็นเหมือนการสืบค้นสื่อ ยกเว้นว่ากฎของพวกมันจะมีผลกับคุณสมบัติขององค์ประกอบจริง มากกว่าที่จะนำไปใช้กับวิวพอร์ตของเบราว์เซอร์

EQCSS เกิดขึ้นได้อย่างไร

ปลายปี 2013 ฉันพบว่าตัวเองทำงานในส่วนหน้าของเว็บแอป Ruby on Rails แอปจำเป็นต้องแสดงข้อมูลโดยละเอียดแก่ผู้ใช้ และเป้าหมายคือการสร้างอินเทอร์เฟซที่ตอบสนองได้ดีซึ่งจะทำงานได้ดีบนโทรศัพท์ แท็บเล็ต และเบราว์เซอร์เดสก์ท็อป สิ่งนี้ทำให้เกิดความท้าทายบางประการ ซึ่งหนึ่งในนั้นคือเนื้อหาสำคัญส่วนใหญ่ที่จะแสดงได้ดีที่สุดในตาราง — ใช่ องค์ประกอบ table จริง (เพื่อแสดงธุรกรรมทางการเงิน บันทึกกีฬา ฯลฯ)

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

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

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

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

ฉันรู้ว่าจะต้องมีวิธีแก้ปัญหาที่ดีกว่านี้ และหลังจากนั้นไม่นานฉันก็เริ่มคิดว่า: ฉันไม่ต้องการการสืบค้นสื่อ — สิ่งที่ฉันต้องการคือการสืบค้นองค์ประกอบ!

วิจัยและพัฒนา

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

แนวทางที่ละทิ้งบางอย่างที่ฉันเลิกใช้นั้นรวมถึงการเพิ่มแอตทริบิวต์ให้กับแท็ก HTML เพื่อเพิ่มการรองรับที่ตอบสนอง และพยายามหาวิธีที่จะฝังบล็อกทั้งหมดของโค้ด CSS ภายในคำสั่ง if ที่อิง JavaScript เพื่อสร้างสัตว์ประหลาด Frankenstein ที่แพตช์จาก JavaScript และซีเอสเอส

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

ดังที่กล่าวไว้ สำหรับเว็บไซต์ที่สร้างจาก HTML, CSS และ JavaScript การสนับสนุนภายนอกมาในรูปแบบของเฟรมเวิร์ก, ปลั๊กอิน, ตัวประมวลผลล่วงหน้า, ทรานสปิลเลอร์, เครื่องมือแก้ไข, ตัวจัดการแพ็คเกจ และกระบวนการสร้าง แทนที่จะเพิ่มปลั๊กอินอื่นที่ด้านบนสุดของสแต็ก ฉันสงสัยว่าด้วยการขยายหนึ่งในภาษาหลักคือ CSS เราสามารถเสริมความแข็งแกร่งให้กับสื่อที่สร้างเว็บไซต์ สร้างเว็บไซต์ที่ดีขึ้นและแข็งแกร่งขึ้นซึ่งต้องการการสนับสนุนจากภายนอกน้อยกว่าและ เครื่องมือในการสร้าง

กำเนิดของไวยากรณ์

ภายในสิ้นปี 2014 ฉันได้ติดต่อ Maxime Euziere นักกอล์ฟที่ใช้โค้ด JavaScript ที่ยอดเยี่ยม และถามความคิดเห็นของเขาเกี่ยวกับความเป็นไปได้ในการขยาย CSS โดยใช้ JavaScript ในเบราว์เซอร์ขณะรันไทม์ เขาไม่เพียงแต่บอกฉันว่ามันเป็นไปได้ แต่เขาเสนอให้ช่วยฉันทำ! เราตั้งชื่อไวยากรณ์ EQCSS ย่อมาจาก "องค์ประกอบคิวรี CSS" ชื่อนี้ยังเป็นการพาดพิงถึงคำว่า "ส่วนเกิน" เพราะทุกอย่างที่ทำนั้นเกินกว่าที่ CSS สามารถทำได้

ต้องการ

ความต้องการของฉันสำหรับไวยากรณ์คือต้อง ใกล้เคียงกับ CSS มากที่สุดเท่าที่จะเป็นไปได้ - ใกล้ที่ตัวเน้นไวยากรณ์จะถูกหลอกให้คิดว่าเป็น CSS มาตรฐาน ดังนั้นฉันจึงแมปไวยากรณ์ CSS สำหรับการสืบค้นองค์ประกอบที่เหมาะสม — ประเภทของไวยากรณ์ที่ผู้คนประหลาดใจนั้นยังไม่มีอยู่จริง

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

ในขณะนี้ การสนทนาในชุมชน CSS จะเน้นไปที่กฎ @ ที่กำหนดเอง และการพูดคุยเกี่ยวกับการสืบค้นองค์ประกอบยังคงเป็นเบื้องต้น เราน่าจะยังห่างไกลจากข้อกำหนด CSS อย่างเป็นทางการสำหรับคุณลักษณะเช่นนี้อีกหลายปี และแม้หลังจากข้อกำหนดแล้ว เรายังคงต้องรอการสนับสนุนเบราว์เซอร์ที่เพียงพอก่อนจึงจะสามารถใช้คุณลักษณะเหล่านั้นในเว็บไซต์ได้

การรอให้คุณลักษณะเหล่านี้เพิ่มลงใน CSS นั้นไม่สมเหตุสมผลเมื่อเราต้องการฟังก์ชันนี้เพื่อสร้างและแก้ไขเว็บไซต์ในปัจจุบัน

ผลลัพธ์

ผลลัพธ์ของการวิจัยนี้คือการสร้างไวยากรณ์ที่ประกอบด้วยเงื่อนไขการตอบสนองขั้นสูงชุดใหม่ สไตล์ที่มีขอบเขต และตัวเลือกใหม่สำหรับองค์ประกอบการกำหนดเป้าหมาย ตลอดจนไลบรารี JavaScript แท้ที่ชื่อ EQCSS.js นอกจากนี้ยังมีการรองรับ Internet Explorer (IE) 8 ในโพลีฟิลภายนอกที่เป็นอุปกรณ์เสริม ทั้งปลั๊กอินและ polyfill ได้รับการเผยแพร่ภายใต้ใบอนุญาต MIT และทุกคนใช้งานได้ฟรี

กรณีการใช้งานสำหรับการสืบค้นองค์ประกอบ

นักพัฒนาปลั๊กอิน

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

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

เครื่องมือสร้างเทมเพลต

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

สิ่งที่ฉันพบว่ามีประโยชน์อย่างยิ่งในการออกแบบหรือจำลองโดยใช้แบบสอบถามองค์ประกอบ ได้แก่ :

  • แถบนำทาง,
  • กิริยาช่วย
  • แบบฟอร์มลงทะเบียนและเข้าสู่ระบบ
  • ส่วนท้าย,
  • แผนภูมิราคา,
  • หน้า Landing Page,
  • โต๊ะ,
  • กล่องแท็บ
  • หีบเพลง
  • วิดเจ็ตแถบด้านข้าง,
  • เครื่องเล่นสื่อ,
  • ส่วนรับรอง

องค์ประกอบการออกแบบใดๆ สามารถ "กำหนดขอบเขต" และย้ายจากที่ใดก็ได้ - หน้าต่อหน้าหรือเว็บไซต์ไปยังเว็บไซต์

การสนับสนุนอุปกรณ์

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

ด้วยการใช้การสืบค้นองค์ประกอบ คุณสามารถออกแบบเว็บไซต์ได้ดีขึ้นและขจัดความแตกต่างระหว่างเบราว์เซอร์เหล่านี้บางส่วน

บทความจำนวนมากที่เขียนเมื่อเร็วๆ นี้เกี่ยวกับความจำเป็นในการสืบค้นองค์ประกอบแสดงรายละเอียดกรณีการใช้งานจำนวนมาก มาเริ่มใช้งานกันเลยดีกว่า!

วิธีการเขียนแบบสอบถามองค์ประกอบ

การเริ่มต้นใช้งาน EQCSS เป็นเรื่องง่าย สิ่งที่คุณต้องมีเพื่อเริ่มใช้ไวยากรณ์ EQCSS ก็คือการรวม JavaScript ไว้ที่ใดที่หนึ่งใน HTML ของคุณ

กำลังดาวน์โหลด EQCSS.js

หากคุณต้องการโคลนโปรเจ็กต์ EQCSS จาก GitHub คุณสามารถพิมพ์:

 git clone https://github.com/eqcss/eqcss.git

หากคุณใช้ npm คุณสามารถเพิ่ม EQCSS ในโครงการของคุณด้วยคำสั่งต่อไปนี้:

 npm install eqcss

การเพิ่ม EQCSS.js ให้กับ HTML . ของคุณ

เมื่อคุณดาวน์โหลด EQCSS แล้ว คุณสามารถเพิ่มลงใน HTML ของคุณด้วยแท็ก script :

 <script src="EQCSS.js"></script>

ไฟล์นี้ ( EQCSS.js ) รองรับเบราว์เซอร์ปัจจุบันทั้งหมด รวมถึง IE 9 ขึ้นไป เพื่อรองรับ IE 8 เราต้องใช้โพลีฟิลอื่นๆ เป็นจำนวนมาก โปรดทราบว่า IE 8 ไม่รองรับการสืบค้นสื่อ CSS โดยไม่ต้องใช้โพลีฟิล ดังนั้นจึงค่อนข้างน่าทึ่งที่เราสามารถรับการสืบค้นองค์ประกอบที่ทำงานที่นั่นได้เช่นกัน หากต้องการรวมการสนับสนุน IE 8 สำหรับเว็บไซต์โดยใช้ EQCSS ให้เพิ่มลิงก์ต่อไปนี้ก่อนลิงก์ไปยังปลั๊กอินหลัก:

 <!‐‐[if lt IE 9]><script src="EQCSS‐polyfills.js"></script><![endif]‐‐>

กำลังเรียกใช้ EQCSS

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

การเขียนแบบสอบถามองค์ประกอบ CSS

ปลั๊กอิน EQCSS.js สามารถอ่านสไตล์ได้หลายวิธี คุณสามารถรวม EQCSS ในแท็ก style ใดก็ได้บนหน้า HTML คุณยังสามารถเขียน EQCSS ในสไตล์ชีต CSS ภายนอกได้

หากคุณต้องการแยกโค้ดที่ขับเคลื่อนด้วย EQCSS ออกจาก CSS คุณสามารถโหลดไวยากรณ์ EQCSS โดยใช้แท็ก script โดยตั้งค่าประเภทเป็น text/eqcss คุณสามารถเพิ่มสไตล์แบบอินไลน์ในแท็กเช่นนี้ หรือลิงก์ไปยัง .eqcss ภายนอกด้วย <script type=“text/eqcss” src=styles.eqcss></script> ซึ่งจะโหลดไฟล์ชื่อ styles.eqcss .

กายวิภาคของแบบสอบถามองค์ประกอบ

การกำหนดขอบเขตสไตล์

ไวยากรณ์ใน EQCSS สำหรับการเขียนการสืบค้นองค์ประกอบนั้นคล้ายกับการจัดรูปแบบของการสืบค้นสื่อ CSS แต่แทนที่จะเป็น @media เราเริ่มการสืบค้นด้วย @element ข้อมูลอื่นๆ เพียงอย่างเดียวที่เราจำเป็นต้องจัดหาคือตัวเลือกอย่างน้อยหนึ่งตัวเลือกที่ควรใช้กับสไตล์เหล่านี้ นี่คือวิธีสร้างขอบเขตใหม่สำหรับองค์ประกอบชื่อ <div class=“widget”> :

 @element '.widget' { }

องค์ประกอบระหว่างเครื่องหมายคำพูด (ในกรณีนี้ . .widget ) อาจเป็นตัวเลือก CSS ที่ถูกต้อง ด้วยข้อความค้นหานี้ เราได้สร้างขอบเขตใหม่บนองค์ประกอบ . .widget เรายังไม่ได้รวมเงื่อนไขการตอบสนองใดๆ สำหรับขอบเขต ดังนั้นสไตล์ใดๆ ในการสืบค้นเช่นนี้จะนำไปใช้กับองค์ประกอบที่อยู่ในขอบเขตตลอดเวลา

หากไม่มีความสามารถในการกำหนดขอบเขตสไตล์ให้กับองค์ประกอบหนึ่งองค์ประกอบขึ้นไป (แทนที่จะเป็นทั้งหน้าในคราวเดียว) เราจะไม่สามารถใช้การสืบค้นแบบตอบสนองกับองค์ประกอบเหล่านั้นได้ เมื่อเราสร้างขอบเขตระดับองค์ประกอบแล้ว การใช้คุณลักษณะขั้นสูงของไวยากรณ์ EQCSS จะกลายเป็นเรื่องง่าย เช่น $parent meta selector เนื่องจากตอนนี้ JavaScript มีจุดอ้างอิงสำหรับคำนวณสิ่งต่างๆ เช่น parentNode ของขอบเขต องค์ประกอบ. นี่เป็นเรื่องใหญ่!

จริงอยู่ CSS ได้รวมตัวเลือกผู้สืบทอดโดยตรงด้วย > ซึ่งช่วยให้เราเลือกองค์ประกอบที่เป็นลูกโดยตรงขององค์ประกอบที่ระบุได้ แต่ปัจจุบัน CSS ไม่มีทางที่จะเดินทางไปอีกทางหนึ่งบนแผนภูมิต้นไม้ครอบครัว เพื่อเลือกองค์ประกอบที่มีองค์ประกอบอื่น ซึ่งจะเรียกว่าองค์ประกอบหลัก ข้อมูลจำเพาะ “CSS Selectors ระดับ 4” ในตอนนี้รวมถึงตัวเลือก :has() ซึ่งทำงานในลักษณะเดียวกันกับตัวเลือก :has() ของ jQuery แต่การรองรับเบราว์เซอร์ในปัจจุบันนั้นไม่มีเลย CSS ที่มีขอบเขตทำให้ตัวเลือกพาเรนต์ประเภทต่างๆ เป็นไปได้

ตอนนี้เราได้เปิดขอบเขตในบริบทขององค์ประกอบ .widget แล้ว เราสามารถเขียนสไตล์จากมุมมองขององค์ประกอบเพื่อกำหนดเป้าหมายองค์ประกอบหลักของตัวเองได้:

 @element '.widget' { $parent { /* These styles apply to the parent of .widget */ } }

อีกตัวอย่างหนึ่งของตัวเลือกพิเศษที่สามารถใช้ในการสืบค้นองค์ประกอบใดๆ ก็ได้คือตัวเลือก $prev และ $next ซึ่งแสดงถึงองค์ประกอบพี่น้องก่อนหน้าและถัดไป แม้ว่า CSS จะสามารถเข้าถึงพี่น้องถัดไปของวิดเจ็ตของเราด้วยตัวเลือกเช่น .widget + * ไม่มีทางที่ CSS จะย้อนกลับไปและเลือกองค์ประกอบที่อยู่ก่อนองค์ประกอบอื่นโดยตรง

 <section> <div>This will be the previous item</div> <div class="widget">This is the scoped element</div> <div>This will be the next item</div> </section> <style> @element '.widget' { $prev { /* These styles apply to the element before .widget */ } $next { /* These styles apply to the element after .widget */ } } </style>

แบบสอบถามองค์ประกอบ

นักพัฒนามักใช้คิวรีสื่อ CSS สำหรับการออกแบบที่ตอบสนองโดยการใช้สไตล์ตามความสูงหรือความกว้างของวิวพอร์ตของเบราว์เซอร์ ไวยากรณ์ EQCSS รองรับเงื่อนไขการตอบสนองหลายประเภท แทนที่จะทำงานกับความกว้างและความสูงของเบราว์เซอร์เพียงอย่างเดียว คุณสามารถเขียนสไตล์ที่ใช้กับองค์ประกอบตามคุณสมบัติของตนเองได้ เช่น จำนวนองค์ประกอบย่อยที่มีอยู่ในองค์ประกอบ หรือจำนวนอักขระหรือบรรทัดข้อความที่อยู่ในองค์ประกอบในขณะนี้ .

การเพิ่มเงื่อนไขแบบตอบสนองเหล่านี้ให้กับสไตล์ที่กำหนดขอบเขตของคุณนั้นคล้ายกับวิธีจัดรูปแบบคิวรีสื่อ: คุณต้องเพิ่ม and (condition: value) สำหรับแต่ละเงื่อนไขที่คุณต้องการตรวจสอบ ในตัวอย่างนี้ เราจะตรวจสอบว่าองค์ประกอบ .widget แสดงความกว้างอย่างน้อย 500 พิกเซลบนหน้าเว็บหรือไม่

 @element '.widget' and (min‐width: 500px) { /* CSS rules here */ }

ไวยากรณ์ของแบบสอบถามองค์ประกอบแบ่งออกเป็นดังนี้:

  • แบบสอบถามองค์ประกอบ @element selector_list [ condition_list ] { css_code }
  • รายการตัวเลือก " css selector [ "," css selector ]* "
  • รายการเงื่อนไข and ( query_condition : value ) [ "and (" query condition ":" value ")" ]*
  • ค่า number [ css unit ]
  • เงื่อนไขแบบสอบถาม min-height | max-height | min-width | max-width | min-characters | max-characters | min-lines | max-lines | min-children | max-children | min-scroll-y | max-scroll-y | min-scroll-x | max-scroll-x min-height | max-height | min-width | max-width | min-characters | max-characters | min-lines | max-lines | min-children | max-children | min-scroll-y | max-scroll-y | min-scroll-x | max-scroll-x
  • css หน่วย % | px | pt | em | cm | mm | rem | ex | ch | pc | vw | vh | vmin | vmax % | px | pt | em | cm | mm | rem | ex | ch | pc | vw | vh | vmin | vmax

อีกตัวอย่างหนึ่ง ต่อไปนี้คือวิธีเขียนข้อความค้นหาที่เปลี่ยนองค์ประกอบ body เป็นสีแดงเมื่อองค์ประกอบ .widget มีความกว้างถึง 500 พิกเซล

 @element '.widget' and (min‐width: 500px) { body { background: red; } }

โปรดทราบว่าองค์ประกอบ body จะเปลี่ยนไปเมื่อ .widget มีความกว้างถึงระดับหนึ่ง ไม่ใช่องค์ประกอบ .widget เอง!

เงื่อนไขการสืบค้นองค์ประกอบ

ด้านล่างนี้คือรายการเงื่อนไขการตอบสนองทั้งหมดที่ EQCSS รองรับ

เงื่อนไขตามความกว้าง

  • การสาธิต min-width สำหรับพิกเซล การสาธิตสำหรับเปอร์เซ็นต์
  • การสาธิต max-width สำหรับพิกเซล การสาธิตสำหรับเปอร์เซ็นต์

เงื่อนไขตามความสูง

  • การสาธิต min-height สำหรับพิกเซล การสาธิตสำหรับเปอร์เซ็นต์
  • การสาธิต max-height สำหรับพิกเซล การสาธิตสำหรับเปอร์เซ็นต์

เงื่อนไขการนับ

  • min-characters สำหรับองค์ประกอบบล็อก การสาธิตสำหรับอินพุตแบบฟอร์ม
  • max-characters สำหรับองค์ประกอบบล็อก การสาธิตสำหรับอินพุตแบบฟอร์ม
  • min-lines สาธิต
  • max-lines demo
  • min-children
  • max-children

เงื่อนไขการเลื่อนตาม

  • min-scroll-y สาธิต
  • max-scroll-y สาธิต
  • min-scroll-x สาธิต
  • max-scroll-x สาธิต

คุณสามารถรวมเงื่อนไขเหล่านี้จำนวนเท่าใดก็ได้ในการสืบค้นองค์ประกอบของคุณสำหรับสไตล์ที่ตอบสนองแบบหลายมิติอย่างแท้จริง นี้จะช่วยให้คุณมีความยืดหยุ่นมากขึ้นและควบคุมวิธีการเรนเดอร์องค์ประกอบ ตัวอย่างเช่น หากต้องการย่อขนาดฟอนต์ของส่วนหัวที่มีอักขระมากกว่า 15 ตัวเมื่อมีพื้นที่แสดงน้อยกว่า 600 พิกเซล คุณสามารถรวมเงื่อนไขสำหรับ max‐characters: 15 และ max‐width: 600px :

 h1 { font‐size: 24pt; } @element 'h1' and (min‐characters: 16) and (max‐width: 600px) { h1 { font‐size: 20pt; } }

Meta Selectors

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

 @element '.widget' and (min‐width: 500px) { .widget h2 { font‐size: 14pt; } }

ซึ่งหมายความ ว่า เมื่อองค์ประกอบ .widget บนหน้ากว้างอย่างน้อย 500 พิกเซล สไตล์จะนำไปใช้กับองค์ประกอบ . .widget ทั้งสองรายการ นี่อาจไม่ใช่สิ่งที่เราต้องการให้เกิดขึ้นในกรณีส่วนใหญ่ นี่คือที่มาของตัวเลือกเมตา!

สองส่วนที่ประกอบขึ้นเป็นแบบสอบถามองค์ประกอบของเราคือตัวเลือกและเงื่อนไขการตอบสนอง ดังนั้น หากเราต้องการกำหนดเป้าหมายเฉพาะองค์ประกอบบนหน้าที่ตรงกับทั้งตัวเลือก และ เงื่อนไขการตอบสนองพร้อมกัน เราก็สามารถใช้ตัวเลือกเมตาได้ $this เราสามารถเขียนตัวอย่างสุดท้ายของเราใหม่เพื่อให้สไตล์ใช้กับองค์ประกอบ .widget ที่ตรงกับเงื่อนไข min‐width: 500px เท่านั้น:

 @element '.widget' and (min‐width: 500px) { $this h2 { font‐size: 14pt; } }

ตัวเลือกใหม่จำนวนหนึ่งได้รับการสนับสนุนโดยไวยากรณ์ EQCSS ที่ไม่ได้อยู่ใน CSS ปกติ นี่คือรายการทั้งหมด:

  • $this
  • $parent
  • $root
  • $prev สาธิต
  • $next

ตัวเลือกเหล่านี้จะทำงานในแบบสอบถามองค์ประกอบเท่านั้น

การเปิดพอร์ทัลระหว่าง JavaScript และ CSS

  • eval(') สาธิต

ฟีเจอร์สุดท้ายและสุดท้ายของ EQCSS นั้นยอดเยี่ยมที่สุด: eval(') พลังทั้งหมดของ JavaScript สามารถเข้าถึงได้จาก CSS ผ่านช่องทางนี้ แม้ว่า JavaScript สามารถใช้สไตล์กับองค์ประกอบได้ แต่ในปัจจุบันก็ยากที่จะเข้าถึงบางสิ่ง เช่น :before และ :after องค์ประกอบหลอก แต่ถ้า CSS สามารถเข้าถึง JavaScript จากทิศทางอื่นได้ล่ะ แทนที่จะตั้งค่าคุณสมบัติ CSS ของ JavaScript จะเป็นอย่างไรถ้า CSS รับรู้ JavaScript ได้

นี่คือที่มา eval(') คุณสามารถเข้าถึงและประเมิน JavaScript ใดๆ ไม่ว่าจะใช้ค่าของตัวแปร JavaScript ใน CSS ของคุณ เพื่อรัน JavaScript one-liner (เช่น eval('new Date().getFullYear()') ) เพื่อตรวจสอบค่าเกี่ยวกับเบราว์เซอร์และองค์ประกอบอื่นๆ ที่ JavaScript สามารถวัดได้ (เช่น eval('innerHeight') ) หรือเพื่อเรียกใช้ฟังก์ชัน JavaScript และใช้ค่าที่ส่งคืนในรูปแบบ CSS ของคุณ นี่คือตัวอย่างที่แสดงผล 2016 ในองค์ประกอบ <footer> :

 @element 'footer' { $this:after { content: " eval('new Date().getFullYear()')"; } }

การใช้ $it ภายใน eval(')

ขณะประเมิน JavaScript eval(') ยังทำงานจากบริบทขององค์ประกอบที่กำหนดขอบเขตอย่างแข็งขัน ซึ่งเป็นองค์ประกอบเดียวกันกับสไตล์สำหรับ $this คุณสามารถใช้ $it ใน JavaScript ที่เขียนด้วย eval(') เป็นตัวยึดตำแหน่งสำหรับองค์ประกอบที่มีขอบเขต หากช่วยให้คุณจัดโครงสร้างโค้ดได้ แต่ถ้าละเว้น ก็จะทำงานในลักษณะเดียวกัน ตัวอย่างเช่น สมมติว่าเรามี div ที่มีคำว่า "hello" อยู่ในนั้น รหัสต่อไปนี้จะส่งออก "สวัสดี สวัสดี":

 <div>hello</div> <style> @element 'div' { div:before { content: "eval('$it.textContent') "; } } </style>

ที่นี่ $it หมายถึง div เนื่องจากเป็นตัวเลือกที่กำหนดขอบเขตในปัจจุบัน คุณสามารถละเว้น $it และเขียนโค้ดต่อไปนี้เพื่อแสดงสิ่งเดียวกัน:

 @element 'div' { div:before { content: "eval('textContent') "; } }

eval(') อาจมีประโยชน์ในสถานการณ์ที่ CSS ไม่ทราบถึงการวัดหรือเหตุการณ์ที่เกิดขึ้นบนหน้าหลังจากที่โหลดแล้ว ตัวอย่างเช่น องค์ประกอบ iframe ที่ใช้สำหรับการฝังวิดีโอ YouTube มาพร้อมกับความกว้างและความสูงที่ระบุ แม้ว่าคุณจะตั้งค่าความกว้างเป็น auto ใน CSS ได้ แต่ไม่มีวิธีง่ายๆ ในการรักษาอัตราส่วนความกว้างต่อความสูงที่ถูกต้องเมื่อวิดีโอขยายจนเต็มพื้นที่ว่าง

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

แนวทางที่ดีกว่าสำหรับอัตราส่วนกว้างยาวที่ตอบสนองอาจเกี่ยวข้องกับการวางวิดีโอแต่ละรายการใน Wrapper โดยไม่ต้อง Padding จากนั้นจึงเขียนไลบรารี JavaScript ที่คำนวณอัตราส่วนกว้างยาวของวิดีโอแต่ละรายการที่พบ และใช้ปริมาณ Padding ที่ถูกต้องกับ Wrapper แต่ละรายการ

แต่ถ้า CSS สามารถ เข้าถึงการวัดเหล่านั้นได้โดยตรงล่ะ ไม่เพียงแต่เราสามารถรวม CSS สำหรับอัตราส่วนกว้างยาวที่แตกต่างกันทั้งหมดไว้ในกฎเดียวได้ แต่ถ้าเราสามารถประเมินได้เมื่อหน้าเว็บโหลดขึ้น เราสามารถเขียนกฎหนึ่งข้อที่จะปรับขนาดวิดีโอที่เราเคยให้ในอนาคตตามการตอบสนอง และเราทำได้ทั้งหมดโดยไม่ต้องใช้กระดาษห่อหุ้ม!

หากสิ่งนี้ดูเหมือนดีเกินจริงให้ตรวจสอบสิ่งนี้ วิธีง่ายๆ ในการเขียนการปรับขนาดองค์ประกอบ iframe ที่ปรับขนาดตามการตอบสนองใน EQCSS โดยไม่ใช้กระดาษห่อ:

 @element 'iframe' { $this { margin: 0 auto; width: 100%; height: eval('clientWidth/(width/height)'); } }

ในที่นี้ width และ height อ้างอิงถึงแอตทริบิวต์ width=“” และ height=“” ใน iframe ใน HTML JavaScript สามารถคำนวณ (width/height) ซึ่งทำให้เรามีอัตราส่วนกว้างยาว และหากต้องการนำไปใช้กับความกว้างใดๆ เราจะแบ่งความกว้างปัจจุบันขององค์ประกอบ iframe ด้วยอัตราส่วน

สิ่งนี้มีความกระชับและความชัดเจนของ CSS และพลังทั้งหมดของ JavaScript ไม่จำเป็นต้องใช้ wrappers เพิ่มเติม ไม่มีคลาสพิเศษ และไม่มี CSS พิเศษ

ระวังด้วย eval(') แม้ว่า มีเหตุผลว่าทำไมนิพจน์ CSS จึงถือว่าเป็นอันตรายในอดีต และยังมีเหตุผลว่าทำไมเราจึงลองใช้แนวคิดนี้ หากคุณไม่ระมัดระวังกับจำนวนองค์ประกอบที่คุณนำไปใช้กับหน้าเว็บหรือความถี่ในการคำนวณรูปแบบใหม่ JavaScript อาจทำงานเกินความจำเป็นหลายร้อยเท่า โชคดีที่ EQCSS ช่วยให้เราสามารถเรียกใช้ EQCSS.apply() หรือ EQCSS.throttle() เพื่อคำนวณรูปแบบใหม่ด้วยตนเอง เพื่อให้เราควบคุมได้มากขึ้นว่าเมื่อใดที่สไตล์จะได้รับการอัปเดต

โซนอันตราย!

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

ต่อไปนี้คือตัวอย่างของการวนซ้ำซึ่งกันและกันใน EQCSS บางสิ่งที่การสืบค้นสื่อ CSS ปกตินั้นไม่ได้รับผลกระทบจากการออกแบบ:

 @element '.widget' and (min‐width: 300px) { $this { width: 200px; } }

ฉันเรียกสิ่งนี้ว่า jekyll: hide; ซีเอสเอส. แต่นอกเหนือจากรูปแบบหนึ่งที่เรียกตัวเองอย่างต่อเนื่องแล้ว ยังมีความเป็นไปได้ในการเขียนข้อความค้นหาหลายคำที่กระตุ้นกันและกัน ซึ่งเราเรียกว่า "การวนซ้ำแบบกลับหัวกลับหางสองครั้ง" ซึ่งน่ารังเกียจที่สุด:

 @element '.widget' and (min‐width: 400px) { $this { width: 200px; } } @element '.widget' and (max‐width: 300px) { $this { width: 500px; } }

ในทางทฤษฎี วิดเจ็ตที่โชคร้ายนั้นจะติดค้างอยู่ในลูป โดยปรับขนาดระหว่าง 200 ถึง 500 พิกเซลจนกว่าจะสิ้นสุดเวลา ไม่สามารถกำหนดความกว้างได้ สำหรับกรณีเช่นนี้ EQCSS จะคำนวณกฎตามลำดับที่ได้รับการประเมิน ให้รางวัลแก่ผู้ชนะ และดำเนินการต่อไป หากคุณต้องจัดลำดับที่กฎเหล่านี้ปรากฏใหม่ รูปแบบหลังจะชนะเสมอหากมีความจำเพาะเท่ากัน

บางคนบอกว่าความสามารถในการสร้างลูป (หรือแม้แต่การวนซ้ำแบบกลับหัวสองครั้ง) เป็นข้อบกพร่องในการออกแบบ แต่เพื่อป้องกันไม่ให้ลูปเป็นไปได้ คุณจะต้องจำกัดพลังของ EQCSS ในลักษณะที่จะขจัดส่วนใหญ่ของ ค่าที่ไวยากรณ์ให้ ในทางกลับกัน การสร้าง infinite loops ใน JavaScript นั้นง่ายมาก แต่นั่นไม่ได้ถูกมองว่าเป็นข้อบกพร่องของภาษา — มันถูกมองว่าเป็นเครื่องพิสูจน์ถึงพลังของมัน! แบบสอบถามองค์ประกอบก็เหมือนกัน

การสืบค้นองค์ประกอบการดีบัก

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

วิธีการออกแบบด้วยแบบสอบถามองค์ประกอบ

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

 footer a { display: inline-block; } @media (max‐width: 500px) { footer a { display: block; } }
 footer a { display: inline-block; } @element 'footer' and (max‐width: 500px) { $this a { display: block; } }

ความแตกต่างคือ ในตัวอย่างดั้งเดิม ลิงก์ส่วนท้ายยังคงเป็น display: block จนกว่า เบราว์เซอร์ จะมีความกว้างอย่างน้อย 500 พิกเซล ตัวอย่างที่สอง โดยใช้การสืบค้นองค์ประกอบ จะมีลักษณะเหมือนกัน แต่ถ้าองค์ประกอบ footer มีความกว้างเต็ม

หลังจากปลดปล่อยสไตล์นี้จากคิวรีสื่อดั้งเดิมแล้ว ตอนนี้เราสามารถวางส่วนท้ายในคอนเทนเนอร์ที่มีความกว้างเท่าใดก็ได้ และต้องแน่ใจว่าเมื่อส่วนท้ายต้องการสไตล์ที่ตอบสนองเพื่อนำไปใช้ (เช่น เมื่อแคบกว่า 500 พิกเซล) ก็จะเป็น สมัครแล้ว.

  1. ตรวจสอบให้แน่ใจว่า EQCSS.js มีอยู่ใน HTML ของเอกสารปลายทาง
  2. แทนที่ @media ด้วย @element ใน CSS
  3. เพิ่มตัวเลือก CSS ให้กับขอบเขตของคิวรี @element แต่ละรายการ
  4. ทางเลือก: แทนที่การเกิดขึ้นขององค์ประกอบที่กำหนดขอบเขตด้วย $this ในแบบสอบถามองค์ประกอบ

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

หลีกเลี่ยงการล็อคอิน

ประสบการณ์ในการเขียนสไตล์ EQCSS นั้นคล้ายกับประสบการณ์ในการเขียน CSS ทั่วไป: คุณสมบัติและเทคนิค CSS ที่คุณชอบทั้งหมดยังคงอยู่ที่นั่น โดยมีคุณลักษณะเพิ่มเติมบางอย่างที่ช่วยให้ทำงานร่วมกันในรูปแบบใหม่ เนื่องจาก EQCSS ส่งออก CSS มาตรฐานไปยังเบราว์เซอร์ คุณลักษณะ CSS ใดๆ ที่เบราว์เซอร์ของคุณมีการสนับสนุนในตัวจะทำงานได้เมื่อใช้กับ EQCSS หากมีการระบุคุณลักษณะสักวันหนึ่ง เช่น การสืบค้นองค์ประกอบและรูปแบบที่กำหนดขอบเขตใน CSS และรองรับในเบราว์เซอร์ คุณจะสามารถเริ่มใช้งานคุณสมบัติเหล่านี้ในโค้ด EQCSS ได้ทันที ในขณะที่ยังคงใช้ EQCSS สำหรับคุณลักษณะอื่นๆ ที่เบราว์เซอร์ไม่รองรับ ยังสนับสนุนโดยกำเนิด

เนื่องจากคุณสามารถใช้ไวยากรณ์ EQCSS ได้ทั้งโดยตรงใน CSS และในสคริปต์ของตัวเอง ด้วยประเภท text/eqcss หาก CSS พัฒนาไวยากรณ์สำหรับการสืบค้นองค์ประกอบดั้งเดิม คุณจะยังสามารถโหลด EQCSS เป็นสคริปต์และหลีกเลี่ยงข้อขัดแย้งได้ .

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

ดังนั้น เรายังควรใช้ Media Queries หรือไม่?

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

การออกแบบด้วยวิสัยทัศน์ 2020

สิ่งที่ดีที่สุดที่เราสามารถทำได้สำหรับอนาคตของ CSS คือการทดลองกับแนวคิดเหล่านี้ให้ได้มากที่สุดในวันนี้ ไม่มีการระดมความคิดและการสร้างทฤษฎีเกี่ยวกับคุณลักษณะเหล่านี้จะมีประโยชน์เท่ากับการพยายามนำไปใช้จริงและนำไปใช้ โดยค้นพบเทคนิคที่ทำให้พวกเขามีประโยชน์และมีประสิทธิภาพ

นอกเหนือจากการจัดหาโซลูชันสำหรับการสืบค้นองค์ประกอบแล้ว EQCSS.js ยังหวังว่าจะทำหน้าที่เป็นแพลตฟอร์มสำหรับการทดลองอื่นๆ ในการขยาย CSS หากคุณมีแนวคิดสำหรับเงื่อนไขการตอบสนองใหม่ คุณสมบัติ CSS ใหม่ หรือตัวเลือกใหม่เพื่อใช้ในโค้ดของคุณ การฟอร์ก EQCSS.js และการปรับเปลี่ยนเพื่อให้รวมแนวคิดของคุณ จะช่วยให้คุณได้รับประโยชน์สูงสุดจากที่นั่นโดยแทบไม่ต้องออกแรง

การออกแบบโมดูลาร์

In designing layouts using element queries, the biggest shift is learning how to stop viewing the DOM from the top down and from the perspective of only the root HTML element, and to start thinking about individual elements on the page from their own perspectives within the document.

The old paradigms of “desktop-first” and “mobile-first” responsive design aren't relevant any longer — the new way of building layouts approaches design “element-first.” Using element queries enables you to work on the individual parts that make up a layout, in isolation from one another, styling them to a greater level of detail. If you are using a modular approach for your back-end code already but have so far been unable to package your CSS with your modules because of the difficulties of styling with media queries alone, then element queries will finally allow you to modularize your styles in the same way.

Thinking Element-First

Element-first design is in the same spirit as the atomic design principle but looks different in practice from how most people have implemented atomic design in the past.

For example, let's say you have some HTML like the following, and the desired responsive behavior can be explained as, “The search input and button are displayed side by side until the form gets too narrow. Then, both the input and the button should be stacked on top of each other and displayed full width.”

 <form> <input type=search> <input type=button value=Search> </form>

Desktop-First Approach

In a desktop-first mindset, you would write styles for the desktop layout first and then add responsive support for smaller screens.

 input { width: 50%; float: left; } @media (max‐width: 600px) { input { width: 100%; float: none; } }

Mobile-First Approach

In a mobile-first mindset, you would design the mobile view first and add support for the side-by-side view only when the screen is wide enough.

 input { width: 100%; } @media (min‐width: 600px) { input { width: 50%; float: left; } }

Element-First Approach

In the first two examples, the media breakpoint was set to 600 pixels, and not because that's how wide the inputs will be when they switch. Chances are, the search input is probably inside at least one parent element that would have margins or padding. So, when the browser is 600 pixels wide, those inputs might be somewhere around 550 or 525 pixels wide on the page. In a desktop-first or mobile-first approach, you're always setting breakpoints based on the layout and how elements show up within it. With an element-first layout, you're saying, “I don't care how wide the browser is. I know that the sweet spot for where I want the inputs to stack is somewhere around 530 pixels wide.” Instead of using a media query to swap that CSS based on the browser's dimensions, with element-first design, we would scope our responsive style to the form element itself, writing a style like this:

 input { width: 100% } @element 'form' and (min‐width: 530px) { $this input { width: 50%; float: left; } }

The code is similar to that of the two previous methods, but now we are free to display this search input anywhere — in a sidebar or full width. We can use it in any layout on any website, and no matter how wide the browser is, when the form itself doesn't have enough room to display the inputs side by side, it will adapt to look its best.

Resources For Getting Started

EQCSS-Enabled Template

 <!DOCTYPE html> <html> <head> <meta charset="utf‐8"> <title></title> <style></style> </head> <body> <!‐‐[if lt IE 9]><script src="https://elementqueries.com/EQCSS‐polyfills.min.js"></script><![endif]‐‐> <script src="https://elementqueries.com/EQCSS.min.js"></script> </body> </html>

สาธิต

  • Responsive Aspect Ratio
  • Sticky Scroll Header
  • Blockquote Style
  • ปฏิทิน
  • Content Demo
  • Counting Children Demo
  • Date Demo
  • Zastrow-style Element Query Demo Demo
  • Flyout Demo
  • Headline Demo
  • Media Player Demo
  • Message Style Demo
  • Modal Demo
  • Nav Demo
  • Parent Selector Demo
  • Pricing Chart Demo
  • Responsive Tables Demo
  • Scroll-triggered Blocker Demo
  • Signup Form Demo
  • Testimonials Block Demo
  • Tweet-Counter Demo
  • JS Variables Demo
  • Responsive Scaling Demo
  • Geometric Design Demo
  • Responsive Order Form
  • Element Query Grid
  • JS Functions in CSS
  • Responsive Content Waterfall

อ่านเพิ่มเติม

You can find the EQCSS project on GitHub, demos, documentation and articles on the EQCSS website. An ever-growing number of Codepens use EQCSS, and you can create your own pen by forking the batteries-included template that comes hooked up with EQCSS. You can also play with the EQCSS tool that I built to preview if your EQCSS code is working as expected.

Happy hacking!