ทำไมไม่ใช้ตารางสำหรับการจัดวางใน HTML? [ปิด]

ดูเหมือนว่าเป็นความคิดเห็นทั่วไปที่ไม่ควรใช้ตารางสำหรับเค้าโครงใน HTML

ทำไม?

ฉันไม่เคยเห็นความขัดแย้งที่ดีในเรื่องนี้ คำตอบปกติคือ:

• เป็นการดีที่จะแยกเนื้อหาออกจากเค้าโครง
  แต่นี่เป็นข้อโต้แย้งที่ผิดพลาด Cliche คิด ฉันเดาว่าเป็นความจริงที่การใช้องค์ประกอบตารางสำหรับเค้าโครงมีส่วนเกี่ยวข้องกับข้อมูลตารางเพียงเล็กน้อย แล้วอะไรล่ะ เจ้านายของฉันสนใจไหม ผู้ใช้ของฉันสนใจหรือไม่
  
  บางทีฉันหรือเพื่อนนักพัฒนาของฉันที่ต้องดูแลหน้าเว็บ ... ตารางรักษาได้น้อยลงหรือไม่ ฉันคิดว่าการใช้ตารางนั้นง่ายกว่าการใช้ div และ CSS
  
  โดยวิธีการ ... ทำไมการใช้ div หรือการแยกเนื้อหาที่ดีจากการจัดวางและตารางไม่ดี? การรับเลย์เอาต์ที่ดีกับ div เท่านั้นมักจะต้องใช้ div ที่ซ้อนกันมากมาย

• การอ่านรหัส
  ฉันคิดว่าเป็นวิธีอื่น ๆ คนส่วนใหญ่เข้าใจ HTML และเข้าใจ CSS ไม่มาก

• เป็นการดีกว่าสำหรับ SEO ที่จะไม่ใช้ตาราง
  เพราะเหตุใด ใครช่วยแสดงหลักฐานว่ามันคืออะไร? หรือคำสั่งจาก Google ว่าตารางถูกกีดกันจากมุมมองของ SEO หรือไม่?

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

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

ฉันสนใจอาร์กิวเมนต์ที่ดีในการใช้ divs + CSS แทนตาราง

ฉันจะผ่านการโต้แย้งของคุณและพยายามที่จะแสดงข้อผิดพลาดในพวกเขา

เป็นการดีที่จะแยกเนื้อหาออกจากเค้าโครง แต่นี่เป็นข้อโต้แย้งที่ผิดพลาด คิดโบราณ

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

แล้วอะไรล่ะ เจ้านายของฉันสนใจไหม ผู้ใช้ของฉันสนใจหรือไม่

ขึ้นอยู่กับ เจ้านายของคุณมีผมแหลมหรือเปล่า? จากนั้นเขาอาจไม่สนใจ ถ้าเธอมีอำนาจแล้วเธอจะดูแลเพราะผู้ใช้จะ

บางทีฉันหรือเพื่อนนักพัฒนาของฉันที่ต้องดูแลหน้าเว็บ ... ตารางรักษาได้น้อยลงหรือไม่ ฉันคิดว่าการใช้ตารางนั้นง่ายกว่าการใช้ div และ css

นักพัฒนาเว็บมืออาชีพส่วนใหญ่ดูเหมือนจะต่อต้านคุณ^{[ ต้องการอ้างอิง} ] ในความเป็นจริงตารางนั้นสามารถบำรุงรักษาได้น้อยกว่า การใช้ตารางสำหรับการจัดวางหมายความว่าการเปลี่ยนเค้าโครงขององค์กรนั้นจะหมายถึงการเปลี่ยนทุกหน้า อาจมีราคาแพงมาก ในทางกลับกันการใช้ HTML ที่มีความหมายเชิงความหมายอย่างรอบคอบรวมกับ CSS อาจจำกัด การเปลี่ยนแปลงดังกล่าวกับ CSS และรูปภาพที่ใช้

โดยวิธีการ ... ทำไมการใช้ div หรือการแยกเนื้อหาที่ดีจากเค้าโครงและตารางไม่ได้หรือไม่ การรับเลย์เอาต์ที่ดีกับ div เท่านั้นมักจะต้องใช้ div ที่ซ้อนกันมากมาย

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

การอ่านรหัสฉันคิดว่าเป็นวิธีอื่น ๆ คนส่วนใหญ่เข้าใจ HTML, เข้าใจ CSS เล็กน้อย มันง่ายกว่า

“ คนส่วนใหญ่” ไม่สำคัญ ผู้เชี่ยวชาญเรื่อง สำหรับมืออาชีพเค้าโครงตารางสร้างปัญหามากกว่า HTML + CSS เหมือนกับว่าฉันไม่ควรใช้ GVim หรือ Emacs เพราะ Notepad นั้นง่ายกว่าสำหรับคนส่วนใหญ่ หรือว่าฉันไม่ควรใช้ LaTeX เพราะ MS Word นั้นง่ายกว่าสำหรับคนส่วนใหญ่

เป็นการดีกว่าสำหรับ SEO ที่จะไม่ใช้ตาราง

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

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

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

แสดงเกณฑ์มาตรฐานบางอย่างที่การใช้ตารางช้าลงอย่างมากในหน้า

น่าเสียดายที่ฉันไม่มีข้อมูลมาตรฐาน ฉันจะสนใจมันด้วยตัวเองเพราะมันถูกต้องที่การโต้แย้งนี้ขาดความแม่นยำทางวิทยาศาสตร์

เว็บไซต์ส่วนใหญ่ที่ต้องการการอัพเกรดจำเป็นต้องมีเนื้อหาใหม่ (html) เช่นกัน สถานการณ์ที่เว็บไซต์รุ่นใหม่ต้องการเพียงไฟล์ css ใหม่นั้นไม่น่าเป็นไปได้มาก

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

อีกสิ่งหนึ่งที่. เลย์เอาต์ตารางทำให้การแยกวิเคราะห์เว็บไซต์อัตโนมัติ (การคัดลอกหน้าจอ) ทำได้ยากขึ้นมาก นี่อาจฟังดูไม่สำคัญเพราะในท้ายที่สุดแล้วใครทำเช่นนั้น? ฉันรู้สึกประหลาดใจตัวเอง การขูดหน้าจอสามารถช่วยได้มากหากบริการที่เป็นปัญหาไม่ได้เสนอทางเลือกให้กับ WebService ในการเข้าถึงข้อมูล ฉันกำลังทำงานในชีวสารสนเทศศาสตร์ซึ่งเป็นความจริงที่น่าเศร้า เทคนิคเว็บสมัยใหม่และ WebServices ยังไม่ถึงนักพัฒนาส่วนใหญ่และบ่อยครั้งที่การขูดหน้าจอเป็นวิธีเดียวที่จะทำให้กระบวนการรับข้อมูลโดยอัตโนมัติ ไม่น่าแปลกใจที่นักชีววิทยาหลายคนยังคงปฏิบัติงานดังกล่าวด้วยตนเอง สำหรับชุดข้อมูลหลายพันชุด

นี่คือคำตอบของโปรแกรมเมอร์จากเธรด simliar

ความหมาย 101

ก่อนอื่นให้ดูที่รหัสนี้และคิดว่ามีอะไรผิดปกติที่นี่ ...

class car {
    int wheels = 4;
    string engine;
}

car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;

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

ความหมาย 102

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

ข้อสรุป

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

คำตอบที่ชัดเจน: ดูCSS Zen GardenGarden ถ้าคุณบอกฉันว่าคุณสามารถทำเช่นเดียวกันกับเค้าโครงตาราง (จำได้ว่า HTML ไม่เปลี่ยน) จากนั้นใช้ตารางสำหรับเค้าโครง

อีกสองสิ่งสำคัญคือการเข้าถึงและ SEO

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

ดังนั้นคำตอบของคุณคือการบำรุงรักษาการเข้าถึงและ SEO

อย่าขี้เกียจ ทำสิ่งที่ถูกต้องและเหมาะสมแม้ว่าพวกเขาจะเรียนรู้ได้ยากขึ้นเล็กน้อย

ดูคำถามที่ซ้ำกันนี้

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

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

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

น่าเสียดายที่ CSS Zen Garden ไม่สามารถใช้เป็นตัวอย่างของการออกแบบ HTML / CSS ที่ดีได้อีกต่อไป การออกแบบล่าสุดทั้งหมดของพวกเขาใช้กราฟิกสำหรับส่วนหัว ไฟล์กราฟิกเหล่านี้ระบุไว้ใน CSS

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

สิ่งนี้แสดงให้เห็นว่าแม้แต่ผู้ที่สนับสนุนศาสนา DIV & CSS ที่เข้มงวดก็ไม่สามารถทำตามกฎของตัวเองได้ คุณอาจใช้สิ่งนั้นเป็นแนวทางในการติดตามอย่างใกล้ชิด

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

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

• มันยากมากที่จะอ่าน นั่นไม่ได้ขึ้นอยู่กับความเห็น มีแท็กซ้อนกันมากขึ้นโดยไม่มีเครื่องหมายระบุอยู่

• การแยกเนื้อหาจากงานนำเสนอเป็นสิ่งที่ดีเพราะช่วยให้คุณสามารถมุ่งเน้นไปที่สิ่งที่คุณทำ การผสมทั้งสองจะนำไปสู่หน้าป่องที่อ่านยาก

• CSS สำหรับสไตล์ช่วยให้เบราว์เซอร์ของคุณแคชไฟล์และคำขอที่ตามมานั้นเร็วกว่ามาก นี่คือขนาดใหญ่มาก

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

• ตารางมีสไตล์ที่ยาก คุณไม่มีความยืดหยุ่นมากนัก (เช่นคุณยังคงต้องเพิ่มแอตทริบิวต์ HTML เพื่อควบคุมสไตล์ของตารางอย่างเต็มที่)

ฉันไม่ได้ใช้ตารางสำหรับข้อมูลที่ไม่ใช่ตารางใน 4 ปี ฉันไม่ได้ดูกลับ

ฉันอยากจะแนะนำให้อ่านCSS Masteryโดย Andy Budd มันยอดเยี่ยมมาก

ภาพที่ ecx.images-amazon.com http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg

เป็นการดีที่จะแยกเนื้อหาออกจากเค้าโครง
แต่นี่เป็นข้อโต้แย้งที่ผิดพลาด คิดถ้อยคำที่เบื่อหู

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

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

ฉันคิดว่า tables vs divs นั้นลดลงตามความต้องการของใบสมัครของคุณ

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

อย่างไรก็ตามเรามีผู้ชมอย่างใกล้ชิดสำหรับผลิตภัณฑ์ของเรา (เราขายชิ้นส่วนของฮาร์ดแวร์ที่มีเว็บอินเตอร์เฟส) และปัญหาการเข้าถึงไม่ได้เป็นปัญหาสำหรับเรา ฉันไม่รู้ว่าทำไมตัวอ่านหน้าจอจึงไม่สามารถจัดการกับตารางได้ดี แต่ฉันเดาว่านั่นเป็นวิธีที่นักพัฒนาต้องจัดการหรือไม่

CSS / DIV - มันเป็นแค่งานสำหรับเด็กชายผู้ออกแบบใช่ไหม ใช้เวลาหลายร้อยชั่วโมงในการดีบักปัญหา DIV / CSS ค้นหาอินเทอร์เน็ตเพื่อให้ส่วนหนึ่งของมาร์กอัปทำงานกับเบราว์เซอร์ที่คลุมเครือซึ่งทำให้ฉันเป็นบ้า คุณทำการเปลี่ยนแปลงเพียงเล็กน้อยและเลย์เอาต์ทั้งหมดผิดไปอย่างน่ากลัว - ที่ใดคือเหตุผลในเรื่องนั้น การใช้เวลาหลายชั่วโมงในการเคลื่อนย้ายบางสิ่งบางอย่าง 3 พิกเซลด้วยวิธีนี้และอย่างอื่น 2 พิกเซลเพื่อให้พวกเขาทั้งหมดเข้าแถว ดูเหมือนว่าผิดปกติสำหรับฉันอย่างใด เพียงเพราะคุณเป็นคนเจ้าระเบียบและบางสิ่งบางอย่างก็คือ "ไม่ใช่สิ่งที่ถูกต้องที่จะทำ" ไม่ได้หมายความว่าคุณควรใช้มันในระดับที่ n และในทุกสถานการณ์โดยเฉพาะอย่างยิ่งถ้ามันทำให้ชีวิตของคุณง่ายขึ้น 1,000 เท่า

ดังนั้นในที่สุดฉันก็ตัดสินใจโดยแท้ในพื้นที่เชิงพาณิชย์ถึงแม้ว่าฉันจะใช้ให้น้อยที่สุดถ้าฉันคาดว่า 20 ชั่วโมงทำงานเพื่อให้วาง DIV อย่างถูกต้องฉันจะติดอยู่ในโต๊ะ มันผิดมันทำให้คนพิถีพิถันมากขึ้น แต่ในกรณีส่วนใหญ่จะใช้เวลาน้อยลงและถูกกว่าในการจัดการ ฉันสามารถมีสมาธิในการทำให้แอปพลิเคชันทำงานได้ตามที่ลูกค้าต้องการแทนที่จะทำให้เป็นที่ชื่นชอบ พวกเขาจ่ายบิลค่าใช้จ่ายทั้งหมดและการโต้เถียงของฉันกับผู้จัดการบังคับใช้ CSS / DIV - ฉันจะชี้ให้ลูกค้าจ่ายเงินเดือนด้วย!

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

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

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

ตรงประเด็น - จากการสนทนาครั้งนี้ฉันได้แปลง TDS และ TRS ที่มีอยู่สองสามรายการเป็น Divs 45 นาทีล้อเล่นกับมันพยายามทำให้ทุกอย่างเข้าแถวกันและฉันก็ยอมแพ้ ย้อนกลับไปในอีก 10 วินาทีต่อมา - ใช้งานได้ทันที - บนเบราว์เซอร์ทั้งหมดไม่มีอะไรให้ทำอีกแล้ว โปรดทำให้ฉันเข้าใจ - คุณมีเหตุผลอะไรบ้างที่ต้องการให้ฉันทำอย่างอื่น!

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

ถ้านั่นไม่ได้ทำให้คุณพูดว่า "WTF" คุณต้องใส่ kool-aid ตอนนี้

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

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

ถอนหายใจ การระบายอากาศเพียงพอ ไปข้างหน้าและเกาะหัวของคุณในทราย

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

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

นี่คือส่วนของ html จากโครงการล่าสุด:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <div id="header">
        <h1><!-- Page title --></h1>
        <ol id="navigation">
            <!-- Navigation items -->
        </ol>
        <div class="clearfix"></div>
    </div>
    <div id="sidebar">
        <!-- Sidebar content -->
    </div>
    <!-- Page content -->
    <p id="footer"><!-- Footer content --></p>
</body>
</html>

และนี่คือรหัสเดียวกันกับเลย์เอาต์ตามตาราง

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <table cellspacing="0">
        <tr>
            <td><!-- Page Title --></td>
            <td>
                <table>
                    <tr>
                        <td>Navitem</td>
                        <td>Navitem</td>
                    </tr>
                </table>
            </td>
        </tr>
    </table>

    <table>
        <tr>
            <td><!-- Page content --></td>
            <td><!-- Sidebar content --></td>
        </tr>
        <tr>
            <td colspan="2">Footer</td>
        </tr>
    </table>
</body>
</html>

ความสะอาดเพียงอย่างเดียวที่ฉันเห็นในเค้าโครงแบบตารางนั้นคือความจริงที่ว่าฉันขยันกับการเยื้องของฉัน ฉันแน่ใจว่าส่วนเนื้อหาจะมีตารางที่ฝังอยู่อีกสองตาราง

อีกสิ่งหนึ่งที่จะคิดเกี่ยวกับ: filesizes ฉันพบว่าโครงร่างแบบตารางมีขนาดใหญ่เป็นสองเท่าของ CSS ทั่วไป สำหรับบรอดแบนด์ความเร็วสูงของเรานั้นไม่ใช่ปัญหาใหญ่ แต่อยู่ที่ผู้ที่มีโมเด็มผ่านสายโทรศัพท์

ฉันต้องการเพิ่มว่าเลย์เอาต์ที่ใช้ div นั้นง่ายต่อการออกแบบพัฒนาและปรับโครงสร้างให้ง่ายขึ้น เพียงแค่การเปลี่ยนแปลงบางอย่างใน CSS เพื่อจัดลำดับองค์ประกอบใหม่และดำเนินการเสร็จแล้ว จากประสบการณ์ของฉันออกแบบเลย์เอาต์ที่ใช้ตารางเป็นฝันร้าย (เพิ่มเติมถ้ามีตารางซ้อนกัน)

รหัสของคุณยังมีความหมายจากมุมมองแบบsemantic

ไม่มีข้อโต้แย้งใน DIV จากการสนับสนุนของฉัน

ฉันจะบอกว่า: ถ้ารองเท้าพอดีสวมมัน

มันน่าสังเกตว่ามันเป็นเรื่องยากหากไม่สามารถหาวิธี DIV + CSS ที่ดีในการแสดงผลเนื้อหาในสองหรือสามคอลัมน์ที่สอดคล้องกับเบราว์เซอร์ทั้งหมดและยังคงมีลักษณะตามที่ฉันต้องการ

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

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

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

หากคุณสงสัยว่าการแยกเนื้อหาจากโครงร่างนั้นง่ายกว่าด้วย divs มากกว่ากับตารางลองดูที่ div-based HTML ที่CSS Zen Gardenดูว่าการเปลี่ยนสไตล์ชีตสามารถเปลี่ยนเค้าโครงได้อย่างมากและลองคิดดูว่าคุณสามารถ บรรลุความหลากหลายของรูปแบบเดียวกันหาก HTML เป็นตารางตาม ... หากคุณกำลังทำรูปแบบตารางคุณไม่น่าจะใช้ CSS เพื่อควบคุมระยะห่างและช่องว่างภายในเซลล์ (ถ้าคุณเป็นคุณ คุณจะพบว่ามันง่ายกว่าที่จะใช้ divs ลอยเป็นต้นในตอนแรก) โดยไม่ต้องใช้ CSS เพื่อควบคุมทั้งหมดนั้นและเนื่องจากความจริงที่ว่าตารางระบุลำดับจากซ้ายไปขวาและจากบนลงล่างใน HTML ตารางมักจะหมายความว่าเค้าโครงของคุณได้รับการแก้ไขใน HTML เป็นอย่างมาก

ฉันคิดว่ามันเป็นเรื่องยากมากที่จะเปลี่ยนเค้าโครงของการออกแบบที่ใช้ div และ CSS โดยไม่ต้องเปลี่ยน div สักเล็กน้อย อย่างไรก็ตามด้วยรูปแบบ div-and-CSS-based มันง่ายกว่าที่จะปรับแต่งสิ่งต่าง ๆ เช่นระยะห่างระหว่างบล็อคต่าง ๆ และขนาดที่สัมพันธ์กัน

ความจริงที่ว่านี่เป็นคำถามที่ถกเถียงกันอย่างถึงพริกถึงขิงเป็นเครื่องพิสูจน์ถึงความล้มเหลวของ W3C ที่จะคาดการณ์ความหลากหลายของการออกแบบรูปแบบที่จะพยายาม การใช้ divs + css สำหรับเค้าโครงที่เป็นมิตรกับความหมายนั้นเป็นแนวคิดที่ยอดเยี่ยม แต่รายละเอียดของการใช้งานนั้นมีข้อบกพร่องจนพวกเขา จำกัด เสรีภาพในการสร้างสรรค์อย่างแท้จริง

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

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

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

Google และระบบอัตโนมัติอื่น ๆทำดูแลและพวกเขากำลังเพียงที่สำคัญในหลาย ๆ สถานการณ์ Semantic code นั้นง่ายกว่าสำหรับระบบที่ไม่ฉลาดในการวิเคราะห์และประมวลผล

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

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

นอกจากนี้ลองด้วย JavaScript ย้ายเซลล์ตารางเดียวจากที่หนึ่งไปอีกที่หนึ่งในอีกตารางหนึ่ง ค่อนข้างซับซ้อนในการดำเนินการที่ div / span จะทำงาน copy-paste-wise

"เจ้านายของฉันดูแล"

ถ้าฉันเป็นเจ้านายของคุณ คุณจะสนใจ ;) ถ้าคุณเห็นคุณค่าชีวิตของคุณ

ความยืดหยุ่นในการวางผัง
ลองนึกภาพว่าคุณกำลังสร้างเพจด้วยภาพขนาดย่อจำนวนมาก
DIVs :
หากคุณวางภาพขนาดย่อแต่ละภาพใน DIV ให้ลอยไปทางซ้ายอาจจะเป็น 10 ภาพที่พอดีกับแถว ทำให้หน้าต่างแคบลงและ BAM - เป็น 6 แถวหรือ 2 หรือหลายขนาด
ตาราง:
คุณต้องระบุจำนวนเซลล์ที่อยู่ในแถวอย่างชัดเจน หากหน้าต่างแคบเกินไปผู้ใช้จะต้องเลื่อนในแนวนอน

การบำรุงรักษา
สถานการณ์เช่นเดียวกับข้างต้น ตอนนี้คุณต้องการเพิ่มภาพขนาดย่อสามภาพในแถวที่สาม
DIV:
เพิ่มเข้าไปเค้าโครงจะปรับโดยอัตโนมัติ
ตาราง: วางเซลล์ใหม่ลงในแถวที่สาม อ๊ะ! ตอนนี้มีรายการมากเกินไป ตัดบางส่วนจากแถวนั้นและวางในแถวที่สี่ ตอนนี้มีรายการมากเกินไป ตัดบางส่วนจากแถวนั้น ... (ฯลฯ )
( แน่นอนถ้าคุณกำลังสร้างแถวและเซลล์ด้วยการเขียนสคริปต์ฝั่งเซิร์ฟเวอร์นี่อาจไม่เป็นปัญหาเลย )

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

นอกจากนี้อย่าลืมว่าตารางไม่สามารถแสดงผลได้ดีบนเบราว์เซอร์มือถือ แน่นอนว่า iPhone มีเบราว์เซอร์ kick-ass แต่ทุกคนไม่มี iPhone การแสดงผลตารางสามารถเป็นถั่วลิสงสำหรับเบราว์เซอร์รุ่นใหม่ แต่เป็นแตงโมจำนวนมากสำหรับเบราว์เซอร์มือถือ

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

ดูเหมือนว่าคุณคุ้นเคยกับตารางและนั่นก็คือ การวางเลย์เอาต์ในตารางจะ จำกัด เฉพาะคุณสำหรับเลย์เอาต์นั้น ด้วย CSS คุณสามารถย้ายบิตไปดูhttp://csszengarden.com/ และไม่เค้าโครงไม่จำเป็นต้องใช้ div ที่ซ้อนกันมากมาย

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

ประโยชน์ SEO มาจากความสามารถในการมีเนื้อหาที่สำคัญที่สุดสูงขึ้นในหน้าและมีอัตราส่วนเนื้อหาต่อมาร์คอัปที่ดีขึ้น

http://www.hotdesign.com/seybold/

• 508 มาตรฐาน - ความสามารถของโปรแกรมอ่านหน้าจอเพื่อให้เข้าใจถึงมาร์กอัปของคุณ
• กำลังรอเรนเดอร์ - ตารางจะไม่แสดงผลในเบราว์เซอร์จนกว่าจะถึงจุดสิ้นสุดของ</table>องค์ประกอบ

แนวคิดทั้งหมดเกี่ยวกับมาร์กอัปความหมายคือการแยกมาร์กอัปและการนำเสนอซึ่งรวมถึงเค้าโครง

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

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

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

เครื่องมือที่ใช้เลย์เอาต์ตารางอาจมีน้ำหนักมากเป็นพิเศษเนื่องจากจำนวนรหัสที่ต้องใช้ในการสร้างเลย์เอาต์ Netweaver Portal ของ SAP โดยค่าเริ่มต้นจะใช้ TABLE เพื่อจัดวางหน้า

พอร์ทัลการผลิตของ SAP ที่กิ๊กปัจจุบันของฉันมีโฮมเพจซึ่ง HTML มีน้ำหนักมากกว่า 60K และลึกลงไปถึงเจ็ดตารางสามครั้งภายในเพจ เพิ่มใน Javascript การใช้ iframe ในทางที่ผิด 16 รายการที่มีปัญหาเกี่ยวกับตารางคล้ายกันภายใน CSS ฯลฯ ที่หนักเกินไปและหน้าเว็บมีน้ำหนักเกิน 5MB

สละเวลาเพื่อลดน้ำหนักของหน้ากระดาษเพื่อให้คุณสามารถใช้แบนด์วิดท์ของคุณในการทำกิจกรรมร่วมกับผู้ใช้นั้นคุ้มค่ากับความพยายาม

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

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

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

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

เพราะมันเป็นสิ่งที่ดีในการดูแลเว็บไซต์ที่ใช้ตารางและใช้เวลาในการโค้ดนานขึ้น หากคุณกลัว divs ที่ลอยตัวให้ไปเรียนหลักสูตรเหล่านั้น พวกเขาไม่ยากที่จะเข้าใจและพวกเขาจะมีประสิทธิภาพมากขึ้นประมาณ 100 เท่าและเจ็บปวดน้อยลงหนึ่งล้านเท่า (เว้นแต่คุณจะไม่เข้าใจพวกเขา - แต่เดี๋ยวก่อนยินดีต้อนรับสู่โลกของคอมพิวเตอร์)

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

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

ตารางไม่ได้ง่ายกว่าทั่วไปหรือบำรุงรักษาได้ง่ายกว่า CSS อย่างไรก็ตามมีปัญหาเลย์เอาต์บางอย่างที่ตารางเป็นทางออกที่ง่ายและยืดหยุ่นที่สุด

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

อย่างไรก็ตามปัญหาเกี่ยวกับตารางนั้นโดยทั่วไปแล้วว่ารูปแบบตารางเค้าโครงใน CSS ไม่ได้รับการสนับสนุนใน Microsoft Internet Explorer ตารางและ CSS จึงไม่เทียบเท่าพลังงาน ส่วนที่ขาดหายไปคือพฤติกรรมที่คล้ายกริดของตารางโดยที่ขอบของเซลล์จัดแนวทั้งแนวตั้งและแนวนอนในขณะที่เซลล์ยังคงขยายเพื่อบรรจุเนื้อหา พฤติกรรมนี้ไม่ใช่เรื่องง่ายที่จะประสบความสำเร็จใน CSS ที่บริสุทธิ์โดยไม่มีการเข้ารหัสในบางมิติซึ่งทำให้การออกแบบมีความแข็งแกร่งและเปราะ (ตราบใดที่เราต้องสนับสนุน Internet Explorer - ในเบราว์เซอร์อื่น ๆdisplay:table-cell )

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

เหตุผลที่สำคัญที่สุดสำหรับการไม่ใช้ตารางคือการช่วยในการเข้าถึง หลักเกณฑ์การเข้าถึงเนื้อหาเว็บhttp://www.w3.org/TR/WCAG10/คำแนะนำในการใช้ตารางสำหรับเค้าโครง หากคุณกังวลเกี่ยวกับความสามารถในการเข้าถึง (และในบางกรณีคุณอาจมีข้อผูกมัดทางกฎหมาย) คุณควรใช้ CSS แม้ว่าตารางจะง่ายกว่า โปรดทราบว่าคุณสามารถเสมอสร้างรูปแบบเดียวกันกับ CSS เช่นเดียวกับตารางมันก็อาจต้องทำงานมากขึ้น

ฉันประหลาดใจที่เห็นว่าปัญหาบางอย่างยังไม่ครอบคลุมดังนั้นนี่คือ 2 เซ็นต์ของฉันนอกเหนือจากคะแนนที่ถูกต้องทั้งหมดที่ทำไว้ก่อนหน้านี้:

0.1 CSS & SEO:

a) CSS เคยมีผลกระทบอย่างมากต่อ SEO โดยการอนุญาตให้วางเนื้อหาในหน้าเว็บทุกที่ที่คุณต้องการ ไม่กี่ปีที่ผ่านมาเสิร์ชเอ็นจิ้นให้ความสำคัญกับปัจจัย "บนหน้า" อย่างมาก บางสิ่งที่ด้านบนของหน้าถือว่ามีความเกี่ยวข้องกับหน้ามากกว่าสิ่งที่อยู่ด้านล่าง "ส่วนบนของหน้า" สำหรับสไปเดอร์หมายถึง "ที่จุดเริ่มต้นของโค้ด" เมื่อใช้ CSS คุณสามารถจัดระเบียบเนื้อหาที่มีคำหลักมากมายไว้ที่จุดเริ่มต้นของโค้ดและยังสามารถวางตำแหน่งได้ทุกที่ที่คุณต้องการในหน้า สิ่งนี้ยังค่อนข้างมีความเกี่ยวข้อง แต่ปัจจัยหน้ามีความสำคัญน้อยลงสำหรับการจัดอันดับหน้าเว็บ

b) เมื่อเลย์เอาต์ถูกย้ายไปยัง CSS หน้า HTML จะจางลงและโหลดได้เร็วกว่าสำหรับ spider ของ search engine (สไปเดอร์ไม่รบกวนการดาวน์โหลดไฟล์ CSS ภายนอก) หน้าโหลดเร็วเป็นสิ่งสำคัญอันดับแรกสำหรับเครื่องมือค้นหาต่างๆรวมถึง Google

c) การทำ SEO มักจะต้องมีการทดสอบและเปลี่ยนแปลงสิ่งต่าง ๆ ซึ่งสะดวกกว่ามาก ๆ ด้วยการออกแบบด้วย CSS

0.2 เนื้อหาที่สร้าง:

ตารางนั้นง่ายต่อการสร้างโดยทางโปรแกรมมากกว่ารูปแบบ CSS ที่เทียบเท่า

foreach ($comment as $key=>$value)
{
   echo "<tr><td>$key</td><td>$value</td></tr>";
}

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

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

นี่คือเหตุผลหนึ่งว่าทำไมบางเว็บไซต์ที่ออกแบบมาอย่างดี (ตัวอย่างเช่น) ยังคงใช้เค้าโครงตาราง

แน่นอนถ้าผลลัพธ์จะต้องมีการดำเนินการผ่าน JavaScript divs นั้นคุ้มค่ากับปัญหา

0.3 การทดสอบการแปลงอย่างรวดเร็ว

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

0.4 วิธีแก้ไขปัญหาต่าง ๆ สำหรับปัญหาที่แตกต่างกัน

ตารางเลย์เอาต์มักจะหายไปเพราะ "ทุกคนรู้ว่า divs & CSS" เป็นวิธีที่จะไป

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

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

บางครั้งที่ผ่านมาฉันต้องเขียนเค้าโครง CSS ที่เรียบง่ายโดยใช้ตารางเนื่องจากส่วนสำคัญของผู้ใช้จะใช้ IE เวอร์ชันเก่าด้วยการสนับสนุน CSS ที่แย่มาก

ฉันคนหนึ่งป่วยและเบื่อกับปฏิกิริยาเข่าสะบัด "โอ้โห! ตารางสำหรับการจัดวาง!"

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