เมื่อคุณย่างก้าวที่จะเข้าสู่โลกของการ design แบบ tableless layout นั้น สิ่งที่คุณต้องคิดถึงไม่ใช่แต่เพียงคิดว่าจะจัดวาง container elements ของคุณอย่างไรแต่สิ่งที่คุณไม่ควรมองข้ามคือการจัดการ selector ของคุณด้วย
การที่จะเขียน code markup ขึ้นมาให้สนับสนุนกับมาตรฐานเต็ม ๆ นั้นมันขัดแย้งกับการที่เราใช้ table ที่เป็น container elements บรรจุทุก ๆ สิ่ง ทุก ๆ อย่าง แบบเมื่อก่อนโดยสิ้นเชิง เราจะใช้ container elements ให้เหมาะสมกับข้อมูล และ ไม่เอามาบรรจุ content ของเรามากมายซับซ้อนเหมือนแต่ก่อน คิดง่าย ๆ เลยให้คิดว่าเราจะเขียนหนังสือสักเล่มเราจะจัดระบบ content ของเราอย่างไรเริ่มและจบด้วยอะไร
อย่าเพิ่งคิดว่าจะปรุงเสริมเติมแต่งมันอย่างไร ให้เริ่มที่ content ของเราก่อน ดูว่าเราจะใช้อะไรร่วมกัน อะไรที่ต้องใช้แยกกัน (หมายถึง CSS properties ของ elements ต่าง ๆ) ใช้เท่าที่จำเป็น และ ประหยัด (design อย่างพอเพียง) อย่ากลัวที่จะต้องใช้ divs หรือ spans หรือ p หรือ อื่น ๆ ที่มี class ร่วมกันให้คิดเสียว่ามันเป็นการจัดหมวดหมู่ข้อมูล ก็เหมือนกับที่คุณจัดเอกสาร หรือ จัดรูปเล่มหนังสือนั่นแหละ เรียงลำดับ priority ของข้อมูลเริ่ม coding จากสิ่งที่สำคัญที่สุดไปหาสิ่งที่สำคัญน้อยที่สุด (เลือก tag ให้เหมาะสม) ตัด tag ที่ไม่จำเป็นออกไป ใช้เท่าที่ควรจะใช้ (ผมเริ่มอย่างนี้น่ะนะ) แล้วก็มาคิดว่าเราจะ design หน้าตาออกมาอย่างไร ข้อนี้มันจะเกี่ยวเนื่องไปถึงข้อต่อไป …
website ขององค์กรใหญ่ ๆ หรือ website ที่มีความหนาแน่นของข้อมูลมาก ๆ หรือ บริษัทที่มีการแยกแยะหน้าที่เป็นระบบเป็นหมวดหมู่ บางที designer อาจจะยังไม่เข้าใจถึง content ที่เราต้องการจะใช้ หรือ โครงสร้างลำดับขั้นของข้อมูลอาจจะทำให้ design ที่ออกแบบออกมานั้นไม่เอื้อต่อการที่จะทำเป็น มาตรฐานเท่าไหร่ (ปัญหานี้เคยประสบกันบ้างไหมครับ) เพราะฉะนั้นทุก ๆ ครั้งก่อนจะเริ่มลงมือทำอะไรให้ทีมพัฒนานั้นมีการประชุมตกลงกันก่อน คุยกันให้แล้วเสร็จในทุก ๆ สิ่งทุก ๆ อย่าง เพราะการคิดไปเรื่อยโดยไม่มีการกำหนดขอบเขต หรือ การกำหนดแนวทางเดิน และ/หรือ การเจริญเติบโตของ site ทำไปเพียงวันวันนั้น จะเกิดการสะสมของข้อมูลที่ใช้ไม่ได้ หรือ Link ที่เสียก็ได้ รวมไปถึงการสิ้นเปลือง class หรือ tag ที่ไม่จำเป็นต้องใช้ก็ได้
รู้กันใช่มั้ยครับว่าพอเราเริ่มทำเป็นแล้วมันมีเรื่องที่น่าเบื่อตามมาอีกอย่างหนึ่ง ก็คือ ปัญหาการ render การแสดงผลของในแต่ละ browser อีกซึ่งแต่ละ browser นั้นมีผู้พัฒนา และ มาตรฐานไม่เหมือนกันอีก เจอทีแรกผมก็สบถเลย แสดด … ทำไมมันไม่ทำมาให้มันเหมือน ๆ กันฟะ และ นั่นแหละที่ผมได้รู้จัก W3C และความฮิ … ของ browser บาง browser จุดเด่นความเก่งกาจของบาง browser ด้วย แม้นว่า W3C จะพยายามบัญญัติอะไรขึ้นมา มันก็พยายามทำอะไรที่เป็นตัวมันให้ได้สิน่า นั่นแหละ เหตุผลที่คุณต้องมานั่งเชค นั่ง hack นั่งปวดขมับปวดกบาล เพื่อให้มันแสดงผลได้เหมือนกันที่สุด (แต่ก็นะ ใช้ CSS Layout จะทำให้งานของเราแสดงผลได้แทบจะเหมือนกันเกือบ ๆ ทุก Modern Browser ฝรั่งเค้าบอกว่า 98% เชียวนะ ไม่รู้โม้ป่ะ) ทีนี้มันก็อยู่ที่เรา และ ลูกค้าของเราแล้วล่ะครับว่า requirement กันมาอย่างไร เพราะฉะนั้นคุณเองก็ต้องรอบคอบด้วยไม่ใช่ฆ่าตัวตาย เพราะงานตัวเอง
ย้อนกลับไปเมื่อ 1 ปีเกือบ ๆ สองปี ที่แล้วที่ผมยังใหม่สำหรับ CSS-XHTML อยู่ มีอะไรหลายอย่าง ๆ ที่ต้องปรับตัวปรับระบบความคิดต่าง ๆ หลาย ๆ อย่าง ด้วยความคุ้นชินกับการ design ในแบบ old school อยู่ ปัญหาของผมมันมีหลายอย่างมากมายมโหระทึกเลย จะเอาเจ้านี่ไว้ตรงนั้น แล้วจะเอาเจ้านั่นลอยไว้ตรงนี้ มันอะไรของมันนักหนาฟะ …
สารพัดจะสบถตามประสาคนปากจัดน่ะนะ เวลาคร่าว ๆ ในการปรับตัวให้คุ้นชินกับมันก็ประมาณเกือบ ๆ 5 เดือนเลยทีเดียว และ อีกประมาณ 2 – 3 เดือนสำหรับการปรับตัวให้หลุดพ้นจากการคิด การออกแบบในแบบเดิม ๆ (เป็นอิสรภาพจากตาราง) ถึงกระนั้นเวลา 1 ปี ผมก็ยังไม่ได้เข้าถึงขั้น advance coding เท่าไรนัก เพิ่งเริ่ม hand coding รวบรัดตัดตอนก็เมื่อ 4 เดือนที่ผ่านนี้เท่านั้นเอง
มองไปยังสิ่งแวดล้อมที่เป็นอยู่ ณ ปัจจุบัน คุณจะเห็นว่า มีนักเขียนเก่ง ๆ หลาย ๆ ท่านที่มีประสบการณ์เขียนหนังสือดีดีเกี่ยวกับเรื่องนี้ (แต่ยังไม่ใช่ในบ้านเรา) เขียนเกี่ยวกับ CSS เขียนเกี่ยวกับการออกแบบ การลำดับความคิด เกี่ยวกับการทำงานอย่างไรให้ถูกต้องเป็นไปตาม Standards จะมีใครบ้างที่เห็นว่าเรื่องนี้มันเป็นเรื่องท้าทาย และ น่าทดลองทำในบ้านเราบ้าง (แต่เป็นเรื่องน่ายินดี ที่ตอนนี้ website ใหญ่ ๆ ในไทยเริ่มเคลื่อนไหวกันแล้ว เช่น sanook.com (เฝ้ารอวัน debut ในเร็ววันนี้อย่างใจจดใจจ่อ), kapook.com, mThai.com, pantip.com และ อื่น ๆ ที่ผมยังไม่ได้ตรวจทานทั้งหมด