จะเขียน Media Queries ใช้ Px หรือ Em ถึงจะดี?

คนส่วนใหญ่ เวลาจะเขียน Media Queries ขึ้นมา ก็มักจะใช้หน่วยเป็น px ใช่มั้ยล่ะครับ แต่บางคนกลับเลือกที่จะใช้หน่วยเป็น em แทน ทำไมเค้าจึงทำเช่นนั้น การใช้ em ในการเขียน media queries มีข้อดีอย่างไร เรามาหาคำตอบด้วยกันครับ

รู้จักกับ Baseline Font Size

web browsers หรืออะไรก็ตามที่สามารถแสดงผลเว็บเพจได้จะมีการกำหนดค่าเริ่มต้นของ font size เอาไว้ครับ ค่านี้เราจะเรียกมันว่า baseline เพราะหากเราไม่ได้ระบุขนาดของตัวอักษรเอาไว้เลย มันก็จะใช้ค่านี้มาแสดงผลให้เราครับ

โดยปกติแล้ว ค่า baseline ของ web browsers บน desktop จะอยู่ที่ 16px ครับ ซึ่งเราสามารถเข้าไปปรับได้ที่ preferences หรือ options ของ web browsers แต่ในบาง devices กลับพบว่าค่านี้ไม่ได้อยู่ที่ 16px ที่เป็นเช่นนี้เพราะว่า นักออกแบบ devices นั้นๆ จะดูว่าที่ระยะห่างระหว่างตาของผู้ใช้งานกับหน้าจอเท่านี้ ควรใช้ตัวอักษรขนาดเท่าไรจึงจะเหมาะกับการใช้งานมากที่สุดครับ

อย่างไรก็ตาม เรามักพบว่า web browsers ส่วนใหญ่ มีฟังก์ชั่นที่จะช่วยให้เราปรับค่า baseline นี้ได้สะดวกยิ่งขึ้น ผ่านฟังก์ชั่นปรับขนาดตัวอักษร(+/- text size) เพื่ออำนวยความสะดวกแก่ผู้ใช้งานที่มีปัญหาทางสายตา หรือผู้ใช้งานที่มองว่าขนาดตัวอักษรของเว็บไซต์นั้นๆ ออกแบบมา ยังมีขนาดไม่เหมาะสม

ทีนี้มาดูว่า Px กับ Em ต่างกันอย่างไร?

Px(Pixels) เป็นหน่วยแบบ absolute ซึ่งก็คือหน่วยที่กำหนดขนาดแบบตายตัว ไม่ขึ้นอยู่กับใครทั้งสิ้น โดย 1 pixel จะมีค่าเท่ากับ 1 จุดบนหน้าจอแสดงผล ส่วน Em(M) อ่านว่า “เอ็ม” เป็นหน่วยแบบ relative หน่วยแบบนี้จะตรงข้ามกับหน่วยแบบ absolute ตรงที่ขนาดของมันจะไม่ตายตัว แต่จะมีขนาดปรับเปลี่ยนไปตาม element ที่เป็น Parent ของมัน

ความพิเศษของ em นั้นอยู่ตรงที่ em เป็นหน่วยที่เกิดมาเพื่อ typography โดยเฉพาะ ไม่ว่าเราจะใช้ em กับ property อะไรก็ตาม(font-size, line-height, width, height, margin, padding) ขนาดของมันจะขึ้นอยู่กับค่า “font-size” ของ parent(container) เสมอ หาก parent ของมันไม่ได้มีการกำหนดขนาดตัวอักษรเอาไว้ มันก็จะไล่ไปหา parent ระดับสูงขึ้นเรื่อยๆ ทีละระดับ ซึ่ง parent ระดับสูงที่สุดก็คือตัว web browser นั่นเอง หรือพูดง่ายๆ ก็คือ ถ้า baseline font size เปลี่ยน อะไรก็ตามที่กำหนดขนาดโดยใช้หน่วย em ก็จะเปลี่ยนตาม

เพื่อให้เห็นภาพชัดเจนยิ่งขึ้น สมมติว่าเราต้องการจะกำหนด padding ให้กับกล่อง content สักกล่องหนึ่ง ถ้าเรากำหนด padding โดยใช้หน่วย px เช่น 10px เวลาเราใช้ฟังก์ชั่นปรับ text size ของ web browser ให้ใหญ่ขึ้น เราจะพบว่าขนาดของตัวอักษรเพิ่มขึ้น ในขณะที่ขนาดของ padding ยังคงมีค่าเท่าเดิมคือ 10px

ในทางกลับกัน ถ้าเรากำหนด padding โดยใช้หน่วย em แทน เช่น 1em เวลาเราใช้ฟังก์ชั่นปรับ text size ของ web browser ให้ใหญ่ขึ้น เราจะพบว่าขนาดของตัวอักษรเพิ่มขึ้น พร้อมๆ กับขนาดของ padding ที่เพิ่มขึ้นตามไปด้วย ที่เป็นเช่นนี้ก็เพราะว่า การใช้ฟังก์ชั่นปรับ text size ของ web browser ให้ใหญ่ขึ้น เป็นการเพิ่มค่า baseline font size ทำให้ padding เดิมที่มีขนาด 1em หรือ 16px นั้น ไม่ได้มีขนาดเท่ากับ 16px อีกต่อไป สมมติเราเลือกปรับ text size เป็น 150% จะได้ว่า padding ของเราที่กำหนดไว้ที่ 1em จะมีขนาดเท่ากับ 1x16x1.5 = 24px นั่นเอง

สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับ Px และ Em สามารถอ่านต่อได้ที่ “Em vs. Px vs. Percent : Font-Size เลือกใช้แบบไหนถึงจะดี?”

คนส่วนใหญ่เขียน Media Queries โดยใช้หน่วย Px

โดยทั่วไปแล้ว นักพัฒนาเว็บส่วนใหญ่ต้องการให้เว็บตัวเองดูดีในทุกๆ devices เค้าก็เลยเลือกที่จะกำหนด breakpoints ในการเขียน media queries โดยยึดหลักตามขนาดหน้าจอของ devices ต่างๆ ไม่ว่าจะเป็น 320px, 480px, 768px, 800px, หรือ 1024px ไม่แปลกเลยที่พวกเค้าเหล่านั้นจะเขียน media queries โดยใช้หน่วย px (หากยังไม่คุ้นเคยกับ Breakpoints สามารถอ่านรายละเอียดเพิ่มเติมได้ที่ “รู้จักกับ Breakpoints ใน Responsive Web Design”)

จะเกิดอะไรขึ้น ถ้า Baseline Font Size ไม่เท่ากับ 16px ?

หากใครที่เคยทำ responsive web design คงจะคุ้นเคยกับการนำเว็บไป test กับ devices ต่างๆ ใช่มั้ยล่ะครับ แต่จะมีสักกี่คนที่ test ในกรณีที่ baseline font size ไม่ได้เท่ากับ 16px ตัวอย่างเช่น ถ้านำเว็บเราไปเปิดกับเครื่อง desktop ของหญิงชราคนหนึ่ง ที่ได้กำหนดขนาดของตัวอักษรใน preferences ไว้ที่ 32px เว็บเราจะยังคงแสดงผลออกมาได้อย่างสมเหตุสมผลมั้ย?

ลองมาดู case study กันดีกว่าครับ สมมติว่าเราเพิ่งหัดทำ responsive web เป็นครั้งแรก เราอยากให้เว็บเราดูดี ใช้งานง่ายใน iPhone หน้าตาของเว็บเราที่ขนาดหน้าจอ 320px เป็นแบบนี้

320px

ที่ขนาด 320px เราออกแบบให้ navigation เป็นแบบ stacked เรียงจากบนลงล่าง เพื่อจะได้กดได้สะดวก ส่วนการเรียง content ก็เป็นแบบ stacked เช่นเดียวกัน

480px

พอมาเป็นขนาด 480px หรือ iPhone4 ในแนวนอน เราตัดสินใจเปลี่ยน navigation ให้มาเรียงจากซ้ายไปขวาแทน เพื่อเป็นการประหยัดพื้นที่ เช่นเดียวกับในส่วนของ content ที่เปลี่ยนมาเรียงแบบ 2 คอลัมน์ แทน

480px + Large Text Size

ทีนี้เราลองมา test กับเครื่องที่ baseline font size ไม่ได้เท่ากับ 16px บ้างครับ ให้เราลองกำหนด font size ใน preferences ของ web browser ให้เป็นสัก 32px หรือจะใช้ฟังก์ชั่นปรับ text size ของ web browser ก็ได้ครับ

เมื่อ text size มีขนาดใหญ่ขึ้นเอามากๆ เราจะพบว่า content ของเรากลับดูไม่น่าอ่านเท่าไรนัก navigation ที่เคยเรียงกันอย่างสวยงาม กลับตกบรรทัด ส่วน description ที่อยู่ใต้รูป ก็ดูมีขนาดไม่สัมพันธ์กับรูปเอาซะเลย (การปรับ text size เป็นการปรับแต่ขนาดของตัวอักษร จะเห็นว่ารูปยังคงมีขนาดเท่าเดิม ซึ่งต่างจากการ zoom ที่ทุกๆ อย่างในหน้าเว็บจะมีขนาดใหญ่ขึ้นในอัตราส่วนที่เท่ากัน)

480px + Large Text Size + Media Queries with Em

ปัญหานี้แก้ได้โดยการเปลี่ยนมาเขียน media queries โดยใช้หน่วยเป็น em แทนครับ จากเดิมที่เราเขียนแบบนี้

@media (min-width:480px){
    .
    .
    .
}

หากจะเขียน media queries โดยใช้ em ให้เราเอา breakpoint เดิม หารด้วย 16 เสมอ(ไม่ว่า baseline font size จะเป็นค่าอะไรก็ตาม) เราก็จะได้ breakpoint ในหน่วย em ครับ

@media (min-width:30em){    /* 480/16 = 30 */
    .
    .
    .
}

หลังจากที่เราเปลี่ยนมาเขียน media queries โดยใช้ em แทน px แล้ว เราจะพบว่า content ของเรา แม้ตัวอักษรจะมีขนาดใหญ่ขึ้นมาก แต่ก็ยังคงแสดงผลได้อย่างสมเหตุสมผลอยู่ ที่เป็นเช่นนี้ก็เพราะว่ามันยังไม่ได้ไปเข้าเคส breakpoint แรกของเราครับ อย่าลืมนะครับว่า เราดูที่ viewport ขนาด 480px แต่เราได้เปลี่ยน breakpoint มาเป็น 30em แล้ว ซึ่ง 30x32 = 960px นั่นเอง หมายความว่า ที่ baseline font size เป็น 32px นี้ เราจะเข้าเคส breakpoint แรกก็ต่อเมื่อ viewport ของเรามีขนาด 960px ครับ

แล้วข้อเสียของการเขียน Media Queries โดยใช้หน่วย Em มีมั้ย?

มีครับ ข้อเสียเพียงข้อเดียวของการเขียน media queries โดยใช้ em ก็คือ ในบางครั้งเราแค่ต้องการให้ตัวอักษรนั้นใหญ่ขึ้น ไม่ได้ต้องการให้ layouts เปลี่ยนไปแต่อย่างใด กรณีนี้อาจจะพบได้น้อยครับ ซึ่งเรามักจะพบกับผู้ใช้สูงอายุที่เคยชินกับ layouts แบบเดิม ไม่อยากเรียนรู้อะไรใหม่ แต่ถ้าเราได้ออกแบบ layouts ในแต่ละ breakpoints ให้ “เหมาะกับผู้งานมากที่สุด” แล้วล่ะก็ ปัญหานี้ก็คงไม่เกิดจริงมั้ยล่ะครับ