ทำไมผู้คนถึงทำโต๊ะกับ div


269

ในการพัฒนาเว็บยุคใหม่ฉันเจอรูปแบบนี้บ่อยขึ้นกว่าเดิม ดูเหมือนว่านี้:

<div class="table">
    <div class="row">
        <div class="cell"></div>
        <div class="cell"></div>
        <div class="cell"></div>
    </div>
</div>

และใน CSS มีบางสิ่งที่คล้ายกัน:

.table { display: table; }
.row { display: table-row; }
.cell { display: table-cell; }

* (ชื่อคลาสเป็นเพียงตัวอย่างเท่านั้นในชีวิตจริงชื่อเหล่านี้เป็นชื่อคลาสปกติที่สะท้อนถึงองค์ประกอบ)

ฉันเพิ่งพยายามทำสิ่งนี้ด้วยตัวเองเพราะ ... คุณรู้ไหมทุกคนทำมัน

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

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

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

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

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

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

เกี่ยวกับลิงค์ที่ซ้ำกัน:นี่ไม่ใช่ข้อเสนอแนะให้ใช้แท็กหรือสิ่งอื่น นี่คือคำถามเกี่ยวกับการใช้เป็นVS<table>display:table


6
@JuhaUntinen: นั่น ... ฟังดูไม่น่า แหล่งที่มา?
Paul D. Waite

5
@ PaulD.Waite - วันนี้ฉันยังคงเป็นจริง อ่านคำตอบอื่น ๆ หากไม่มีตารางtable-layout:fixedจะต้องโหลดทั้งหมดก่อนจึงจะสามารถแสดงได้ ด้วยบรอดแบนด์ที่ทันสมัยเอฟเฟกต์นี้เห็นได้ชัดเจนน้อยลง
Vilx-

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

4
ย้อนกลับไปในอดีตที่ผ่านมาเราเคยเลียนแบบ div ด้วยตารางดังนั้นที่นั่น
ไวแอตต์บาร์เน็ตต์

4
บางคนอ่านว่าพวกเขาไม่ควรใช้ตารางสำหรับการจัดวางและใช้เพื่อหมายความว่าพวกเขาไม่ควรใช้ตารางเลย ฉันเกลียดแนวโน้มนี้
Casey

คำตอบ:


120

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

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

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

มีความดีงามเป็นภาพรวมของตารางการตอบสนองใน CSS-เคล็ดลับ

แก้ไข: ฉันควรชี้ให้เห็นว่าฉันไม่ได้สนับสนุนรูปแบบนี้ - มันตกอยู่ในกับดัก divitis และไม่ใช่ semantic - แต่นี่คือเหตุผลที่คุณจะพบตารางที่ทำจากdivs


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

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

1
@Vilx: คำถามที่คุณโพสต์คือ "ทำไมคนทำตารางกับ divs" ซึ่งเป็นสิ่งที่คุณได้รับคำตอบ ตัวอย่างเช่นคุณอาจไม่สนใจเกี่ยวกับโปรแกรมอ่านหน้าจอ แต่นั่นไม่ได้เปลี่ยนแปลงว่าความสามารถในการเข้าถึงเป็นปัญหาที่แท้จริงสำหรับหลาย ๆ คนและ (รวมถึงเครื่องมือค้นหา) สาเหตุสำคัญที่หลายคนเลือกใช้ HTML ความหมาย
JacquesB

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

8
ฉันเชื่อว่าคำตอบนี้ทำให้เข้าใจผิดเล็กน้อย ตารางตอบสนองเป็นการออกแบบที่ดี แต่ไม่ขึ้นอยู่กับคำถามหากคุณควรใช้ <table> หรือ <div> - คุณสามารถใช้เอฟเฟกต์ภาพเดียวกันได้ อันที่จริงนี่คือหลักในความคิดของการแยกโครงสร้างและการนำเสนอ เป็นความจริงที่ IE เวอร์ชันเก่าไม่อนุญาตให้มีการแทนที่สไตล์ของตาราง แต่ IE เวอร์ชันเก่ากว่านั้นไม่รองรับ display: table เช่นกันดังนั้นคุณจึงไม่สามารถใช้ตารางที่ตอบสนองได้เช่นกัน
JacquesB

153

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

หากข้อมูลของคุณมีความหมายตารางคุณใช้<table>-tag ถ้าคุณเพียงต้องการกริดเพื่อจุดประสงค์ในการจัดวางคุณใช้องค์ประกอบ html อื่น ๆ ที่เหมาะสมและใช้display:tableในสไตล์ชีต

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


ตกลงทำไมไม่ใช้<table>สำหรับทุกสิ่งแทนที่จะเป็นแค่สิ่งที่มีความหมายในตาราง? เห็นได้ชัดว่ามันเป็นสิ่งเดียวกัน (เนื่องจากองค์ประกอบตารางมีdisplay:elementอยู่ในสไตล์ชีทเริ่มต้นเท่านั้น)

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

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

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

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


14
@ Vilx- ทำไมต้องใช้<em>และ<strong>มากกว่า<b>และ<i>? เพราะ<b>และ<i>ไม่เกี่ยวกับความหมายของแท็ก <table>มีความหมายความหมาย การใช้สำหรับสิ่งที่ไม่ใช่ตารางทำให้ยากต่อการเข้าใจความหมายของเอกสาร

22
@ Vilx- The book <i>Peoplesoft</i> is the <em>best</em> book on the subject. การนำ<i>สิ่งที่ดีที่สุดมาใช้จะผิดเพราะนั่นหมายถึงบางสิ่งที่แตกต่าง<i>ไปจากชื่อหนังสือ สำหรับข้อมูลเพิ่มเติมให้ดูที่เหตุใด<b>และ<i>แท็กจึงเลิกใช้แล้ว และอะไรคือความแตกต่างระหว่าง<b>และ<strong>, <i>และ<em>?

19
หากคุณไม่สนใจว่าเนื้อหาของคุณหมายถึงอะไรฉันขอแนะนำให้คุณหยุดใช้องค์ประกอบใด ๆ ยกเว้นแบบฟอร์มและตัวหาร เพียงเพิ่มคลาสเพื่อใช้สไตล์และพฤติกรรม
คนรวย Remer

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

31
@ Vilx- ใช่โปรแกรมอ่านหน้าจอถือว่า <table> แตกต่างจาก <div> มาก <div> s ส่วนใหญ่จะถูกละเว้นและอ่านตามลำดับ ภายใน <table> จะต้องมีการกดแป้นนาวิเกต / คำสั่งต่าง ๆ ("ข้ามไปที่เซลล์ทางด้านขวา", "อ่านคอลัมน์และชื่อแถว" และอื่น ๆ ) และเสียงข้อมูลตำแหน่งที่แตกต่างกัน (เมื่อกระแสการอ่านเข้าสู่ตาราง มันจะเป็นเช่น "ตารางที่ 3, แถวที่ 1 คอลัมน์ 1, Lorem Ipsum dolor ... ")
Euro Micelli

102

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

<div class="table">
  <div class="row">
    <div class="cell"></div>
    <div class="cell"></div>
    <div class="cell"></div>
  </div>
</div>

สิ่งที่ผู้พัฒนานี้ได้ทำคือทำซ้ำ<table>มาร์กอัปดั้งเดิมด้วยชื่อคลาส CSS ซึ่งหมายความว่าทันทีที่เค้าโครงนี้ไม่ได้เป็นตารางชื่อคลาสจะเป็นราคาต่อรอง

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

<div class="thumbnail-gallery">
  <div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
  </div>
</div>

ตอนนี้ฉันสามารถสร้าง CSS ที่ปรับได้แล้ว:

@media screen {
  .thumbnail-gallery {
    display: table;
    border-collapse: collapse;
    width: 100%;
  }

  .thumbnail-gallery > div {
    display: table-row;
  }

  .thumbnail-gallery .thumbnail {
    display: table-cell;
    border: 1px solid #333333;
  }
}

@media screen and (max-width: 640px) {
  /** reset all thumbnail gallery elements to display as block and fill screen **/
  .thumbnail-gallery,
  .thumbnail-gallery > div,
  .thumbnail-gallery .thumbnail {
    display: block;
    width: 100%;
  }
}

ทำไม divs และไม่ใช่ตาราง

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

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

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

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

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


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

1
อืม ... ในกรณีของคุณคุณใช้สอง HTML ที่ต่างกันในการสืบค้นสื่อ ตกลงนั่นเป็นกรณีการใช้งานที่ดี แต่ถ้ากรณีนี้ไม่ได้และคุณต้องการทราบก่อนที่แกลเลอรี่ภาพนี้จะปรากฏเฉพาะในสถานที่หนึ่งและที่เดียวในรูปแบบตาราง - คุณจะใช้<table>แล้วหรือยังdisplay:table? เพราะในทางที่มันเป็นข้อมูลตาราง ยกเว้นว่า "data" เป็นรูปภาพ แต่ก็ยังคง
Vilx-

15
ก็ไม่เป็นข้อมูลแบบตาราง คุณกำลังนำเสนอมันในตารางที่คล้ายกับตาราง ข้อมูลแบบตารางคือสถิติและข้อมูลเปรียบเทียบ - คิดเหมือนสเปรดชีต คุณจะบอกว่ามุมมองรูปขนาดย่อในตัวสำรวจไฟล์ Windows เป็นข้อมูลแบบตารางหรือไม่ และเป็นที่นี้เสมอไปที่จะนำเสนอเช่นโต๊ะ? ถ้าคุณต้องการสไตล์การดูที่แตกต่างใน 6 หรือ 12 เดือน ทำไมต้องมีข้อ จำกัด ที่มีผลกระทบระยะยาวเพื่อการดื้อรั้นในการเผชิญกับการฝึกฝนที่ยอมรับกันอย่างกว้างขวาง?
HorusKol

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

3
โอเคที่ยืดมันออกมาเล็กน้อย :) ดีคุณให้ฉันคิดเกี่ยวกับ! ขอบคุณสำหรับสิ่งนั้น! ฉันยังไม่มั่นใจ 100% แต่อย่างน้อยก็เป็นเรื่องที่ควรทำ :)
Vilx-

11

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

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

สิ่งนี้เลวร้ายยิ่งเมื่อตารางซ้อนกัน

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

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

ดังนั้น +1 ให้คุณถามคำถาม


เป็นเรื่องผิดปกติเกี่ยวกับ DOCTYPE: ฉันคิดว่าถึงแม้จะมีความแตกต่างทางทฤษฎี (และผู้ตรวจสอบความถูกต้องตรวจสอบอย่างจริงจัง) ในทางปฏิบัติเบราว์เซอร์ไม่ได้แยกความแตกต่างระหว่างพวกเขาจริงๆ ตกลงอาจมีการเปลี่ยนแปลงเล็กน้อยระหว่าง HTML / XHTML รส แต่ข้อมูลรุ่นและ DTD อย่างน้อยก็ไม่ได้ใช้ นี่คือเหตุผลว่าทำไม HTML5 จึงทิ้งสิ่งทั้งปวงไว้และไปด้วย<!DOCTYPE html>และนั่นคือสาเหตุที่มันเกิดขึ้นกับการทำงานแม้ในเบราว์เซอร์รุ่นเก่าเช่น IE6 ฉันพลาดอะไรไปหรือเปล่า
Vilx-

2
@Vilx: doctype ทำให้เบราว์เซอร์เข้าสู่โหมดที่แน่นอน เหนือสิ่งอื่นใดมันกำหนดรูปแบบกล่องที่ใช้งานอยู่ สำหรับหลักคำสอนจำนวนหนึ่งเบราว์เซอร์ไม่ได้จัดเรียงเพราะรูปแบบกล่องที่ใช้แตกต่างกัน นี่คือเหตุผลที่นักพัฒนาหลายคนบ่นว่าเบราว์เซอร์ที่แสดงหน้าแตกต่างกันและแทนที่จะแก้ไข doctype ใช้แผ่นงาน css รีเซ็ตขนาดใหญ่ อย่างไรก็ตามมีหลักคำสอนไม่กี่ข้อที่เบราว์เซอร์ทั้งหมดใช้รูปแบบกล่องเดียวกัน - แต่สิ่งเหล่านั้นไม่เคยเป็นค่าเริ่มต้นคุณต้องรู้จักพวกเขา
NotMe

@vilx: html 5 ไม่ได้ลดลง แต่มีการเพิ่มประเภทเอกสารใหม่ ประเด็นคือบรรทัดแรกที่ปรากฏที่ด้านบนของเอกสาร html นั้นสำคัญมากและถ้าคุณไม่เข้าใจว่ามันทำอะไรและเบราว์เซอร์ต่างๆตอบสนองต่อมันอย่างไรคุณจะใช้เวลามากเกินไปในการหาสาเหตุที่ทำให้เลย์เอาต์ของคุณ เป็น "เสีย" ในเบราว์เซอร์ที่เฉพาะเจาะจง
NotMe

รอสักครู่จึงมีเป็น doctypes ที่แตกต่างกันที่ทำให้เอกสารเดียวกันทำให้แตกต่างกัน? อันไหน? ใจคุณฉันกำลังพูดถึงหลักคำสอนที่แตกต่างกันไม่ใช่ doctype เทียบกับการขาด doctype (aka quirksmode)
Vilx-

@Vilx: มันซับซ้อนกว่านี้เล็กน้อยเนื่องจากโหมด doctypes ทริกเกอร์ quirks บางอัน (เหมือนไม่มี doctype) และ doctypes อื่น ๆ (รวมถึง html5 doctype) ทริกเกอร์โหมดมาตรฐาน โหมด "ในเบราว์เซอร์บางตัว
JacquesB

5

หากฉันได้รับ "เมตา" เล็กน้อยที่นี่นี่จะนำปัญหาสองข้อมาสู่ความคิดของฉัน:

ข้อหนึ่ง: มีคนเสนอกฎด้วยเหตุผลที่ดีและผู้คนพลาดจุดนี้อย่างสมบูรณ์โดยทำตามตัวอักษรทางเทคนิคของกฎขณะที่ไม่สนใจวิญญาณ พวกเขาพบวิธีที่จะบรรลุสิ่งเลวร้ายทั้งหมดที่กฎพยายามป้องกันในขณะที่ยังคงปฏิบัติตามกฎตามคำศัพท์

สอง: บางคนเห็นปัญหาและเสนอกฎเพื่อป้องกัน คนอื่น ๆ เห็นคุณค่าของกฎนี้ จากนั้นพวกเขายืนยันที่จะอุทิศตนให้กับกฎนี้โดยไม่คำนึงถึงปัญหาดั้งเดิมที่ควรแก้ไขและ / หรือคำนึงถึงปัญหาอื่น ๆ ที่เกิดขึ้น ฉันมีการสนทนาหลายครั้งที่มีคนพูดว่า "คุณต้องทำ X เพราะนั่นคือกฎ" แล้วฉันก็ถามว่า "แต่ทำไมเราถึงต้อง X?" และพวกเขาก็มองมาที่ฉันด้วย bafflement และ exasperation แล้วพูดว่า "แต่ ฉันแค่บอกคุณ! เพราะมันเป็นกฎ! " ฉันตอบว่า "แต่ดูเหมือนว่าจะทำให้เกิดปัญหามากกว่าที่จะแก้ฉันคิดว่าเราควรจะทำ Y ดีกว่า" และบุคคลนั้นก็พูดว่า "ไม่สิฉันจะแสดงให้คุณดูสิมันอยู่ตรงนี้ในหนังสือเล่มนี้ X คือกฎ"

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

ผู้คนมากมายเสนอวิธีแก้ปัญหา: อย่าใช้แท็กตารางเพื่อควบคุมเค้าโครงของสิ่งที่ไม่ใช่ "ตาราง" อย่างมีเหตุผล ใช้ CSS

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

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


7
wrt ถึงย่อหน้าสุดท้าย - คุณได้อ่านข้อกำหนด HTML5 สำหรับองค์ประกอบเหล่านั้นใช่ไหม? w3.org/html/wg/drafts/html/master/semantics.html#the-p-element w3.org/html/wg/drafts/html/master/semantics.html#the-ul-element w3.org/ html / wg / drafts / html / master / semantics.html # the-ol-elementโดยเฉพาะอย่างยิ่งถ้าคำสั่งซื้อมีความสำคัญให้ใช้องค์ประกอบ ol (เนื่องจากนี่คือส่วนโครงสร้าง) - คุณยังสามารถแสดงเป็นรายการสัญลักษณ์แสดงหัวข้อย่อย ใช้ CSS
HorusKol

5
และถ้าคุณดูอีกสองคำตอบที่นี่คุณจะเห็นว่าไม่พูดง่ายๆว่า "เพราะมันเป็นกฎ" - พวกเขาทั้งสองวางโครงสร้างเหตุผลที่ชัดเจนมากสำหรับกฎและการใช้กรณี
HorusKol

1
อืมดูเหมือนว่าฉันจะพูดว่า: "ใครบางคนเห็นปัญหาและเสนอกฎเพื่อป้องกันมันคนอื่น ๆ เห็นคุณค่าของกฎนี้จากนั้นพวกเขาก็ยืนยันที่จะอุทิศตนให้กับกฎนี้โดยไม่คำนึงถึงปัญหาเดิม เพื่อแก้ปัญหาและ / หรือคำนึงถึงปัญหาอื่น ๆ ที่เกิดขึ้น " ฉันไม่ปฏิเสธว่ามีความคิดที่สมเหตุสมผลอยู่เบื้องหลังกฎ ฉันไม่เห็นด้วยกับข้อสรุป แน่นอนฉันสามารถพูดได้ว่า "คุณมีจุดที่ดีที่นั่น แต่อย่างไรก็ตามฉันไม่เห็นด้วย" และแน่นอนคุณไม่ปฏิเสธว่ามีคนที่ไม่เข้าใจข้อดีและข้อเสียและพูดว่า ...
Jay

1
... "เพราะเป็นกฎ" ฉันมีการสนทนากับผู้คนจำนวนมากในช่วงหลายปีที่ผ่านมาในเรื่องนี้และที่อื่น ๆ อีกมากมาย คนที่ปฏิเสธที่จะพูดคุยถึงข้อดีและข้อเสียของกฎเพราะเป็นกฎสิ้นสุดการสนทนา
Jay

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

5

แล้วมีตันของคำตอบที่ดีที่นี่ แต่ฉันต้องการเพิ่มtableองค์ประกอบที่มีข้อ จำกัด ในการแสดงที่ไม่มีอยู่สำหรับdivองค์ประกอบ ลองสร้างตารางที่ใช้การเลื่อนเสมือน (เช่น: SlickGrid , DataTablesและอื่น ๆ ) และคุณจะผิดหวังอย่างมาก มันไม่ทำงาน Javids กริดสมัยใหม่ส่วนใหญ่ (ทั้งหมด?) ใช้divs เนื่องจาก css อนุญาตให้เรนเดอร์มีความยืดหยุ่นมากขึ้น

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


3

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

div { display: inline; }

ตามที่คุณทราบ<div>สามารถ repurposed เพื่อเลียนแบบ<table>และเพื่อนร่วมเดินทาง จริงๆแล้วแท็กส่วนใหญ่สามารถ ได้รับบทบาทพิเศษของพวกเขาผมสงสัยคุณประโยชน์สามารถ remap แท็กมหภาคเช่น<html>, <head>, <body>และ<script>แต่แท็ก "คนธรรมดา" เช่น<div>, <p>, <b>, <em>, <span>และ<pre>? ขึ้นสำหรับคว้า สร้างบล็อกแท็กแบบอินไลน์บล็อกแบบอินไลน์โฟลว์แท็กที่จัดรูปแบบไว้ล่วงหน้าบล็อกแบบลอยตัว ไปบ้าถ้าคุณชอบ!

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

ฉันไม่คิดว่ามันจะเกินกำลังที่จะบอกว่าการทดแทนก็จำเป็นเช่นกัน อย่างน้อยก็สะดวกมาก เป็นเวลานาน, HTML ไม่ได้มี<menu>, <section>หรือ<aside>องค์ประกอบ แต่หน้าเว็บและแอพทุกที่มีเมนูส่วนและแถบด้านข้าง อย่างไร? เนื่องจากองค์ประกอบรายการ HTML ( <ul>, <ol>และ<li>) ถูก repurposed อย่างง่ายดายและการใช้งานบางอย่างถูกจัดประเภทใหม่เป็นคอนเทนเนอร์เมนูและชิ้นส่วน <div>สามารถยืนอยู่ใน<article>, <section>, <aside>, และ<figure> <summary>HTML5 ได้ติดตามและเพิ่มองค์ประกอบตามความต้องการสำหรับกรณีการใช้งานที่ไม่ได้รับการแก้ไขก่อนหน้านี้ เป็นการอัปเดตและแก้ไขที่ยอดเยี่ยมเพื่อรองรับการใช้งานทั่วไปที่ใช้งานจริง

ดังนั้นแม้ยังคงมีจำนวนมากของสำนวนทั่วไปที่ไม่ได้มีแท็ก bespoke หรือรูปแบบความหมาย สิ่งต่าง ๆ เช่นหน้ากระดาษเชิงอรรถราคาอ้างอิงกระแสข้อมูลความคิดเห็นรูปภาพประจำตัวที่เกี่ยวข้อง "ไลค์" หัวเรื่องย่อยและคำบรรยายที่ฉันและคนอื่น ๆ ใช้กันทุกวัน เราต้องทำอะไร สิ่งที่เราทำได้ จัดองค์ประกอบใหม่ "ปิด แต่ไม่ถูกต้อง" ด้วยชั้นเรียนและรหัสเพื่อให้ยืนและสนับสนุนงานของเราในอีกห้าหรือสิบปีข้างหน้าหรืออีกหลายปีหรือจนกว่าจะถึง HTML6 หรือ HTML7 HTML / CSS ของ "ใช่มันเป็น X ในทางทฤษฎี แต่เราจะติดแท็กและทำงานกับมันในฐานะความสามารถ Y" สะดวกสบายอย่างเหลือเชื่อ ที่ขาดไม่ได้จริงๆ ทำให้เนื้อหาเว็บยืดหยุ่นและไม่แตกหักง่าย

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

รูปแบบมาตรฐานไม่สามารถครอบคลุมความต้องการความปรารถนาและความหลากหลายของมนุษย์ได้ทั้งหมด พวกเขาจะเป็น "เบื้องหลังโค้ง" ของสิ่งที่ผู้คนกำลังทำอยู่เสมอ วิธีที่พวกเขากำลังสร้างสรรค์ Heck, HTML5 ยังคงอยู่หลังส่วนโค้งของเชิงอรรถ subheads และนวัตกรรมการพิมพ์อื่น ๆ ของศตวรรษที่ 17 มันขาดคุณสมบัติที่จำเป็นสำหรับคนทำงานด้านข้อมูลและผู้สร้างเนื้อหา ดังนั้นเราจึงโพล่งออกมา

ไม่มีการเปลี่ยนแปลงมากขึ้นคือข้อมูลไม่ได้ปฏิบัติตามกฎชุดเดียว แน่นอนว่ามันเริ่มเป็นโต๊ะ แต่บางทีคุณอาจต้องการสรุป - พูดชื่อของแต่ละแถวเป็นรายการ อาจใช้พื้นที่มากเกินไปและคุณต้องการให้เป็นรายการอินไลน์แบบประหยัดพื้นที่ บางทีคุณอาจมีระเบียนที่คุณต้องการเพียงแค่ชื่อเรื่องจากนั้นถ้าคุณคลิกคุณจะเห็นรายละเอียดพื้นฐาน หรือคุณต้องการให้รายการในรายการหรือตารางที่ซับซ้อนถูกจัดกลุ่มและจัดหมวดหมู่ โอ้ตอนนี้คุณต้องการให้มันเปลี่ยนและจัดหมวดหมู่ด้วยวิธีที่แตกต่างกัน หรือค่าที่พล็อตเป็นแผนภูมิแท่ง สิ่งเหล่านี้เกิดขึ้นทุกวันในแอพสเปรดชีตและการสร้างภาพข้อมูล พวกเขาเป็นส่วนหนึ่งของภูมิทัศน์ข้อมูลของเราและสิ่งที่เราต้องการและจำเป็นต้องทำบนเว็บ มนุษย์จัดรูปแบบและการนำเสนอข้อมูลของเราใหม่อย่างต่อเนื่อง มันไม่ได้เป็นเพียงสิ่งเดียวหรือรูปแบบ / เค้าโครง หรือแนวคิดเดียว มันเป็นเรื่องที่เข้าใจง่ายมีความหมายขึ้นอยู่กับสถานการณ์และตัวเลือกที่ผู้ใช้โต้ตอบกัน ใช่ทำเครื่องหมายข้อความว่า "เน้น" (<em>) แต่นั่นเป็นเพียงการประชุม ฉันได้ทำงานกับเอกสารที่มี "การเน้น" ที่แตกต่างกันอย่างน้อยครึ่งโหล เราจำเป็นต้องสามารถปรับแต่งและทำการแมปใหม่สำหรับการใช้งานที่แตกต่างกันการตีความที่แตกต่างกัน การเน้น HTML ประเภทใด เลือดตาแทบกระเด็น การ จำกัด เปราะ. เช่นเดียวกับที่เป็นจริงสำหรับ<table>, <p>ฯลฯ

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


4
สิ่งนี้จะไปได้ทุกที่ใกล้กับการตอบคำถามได้อย่างไร
HorusKol

2
IMO จะกล่าวถึงคำถามพื้นฐานว่าทำไมนักออกแบบผู้พัฒนาและผู้ทำงานด้านเนื้อหาจึงเลือกใช้องค์ประกอบทั่วไป ( <div>และ<span>) แทนที่องค์ประกอบเฉพาะที่สร้างขึ้นตามวัตถุประสงค์ (เช่น<table>) มันเป็นเมตามากกว่าแท็กเหล่านั้นเพียงเล็กน้อย แต่มันพูดโดยตรงกับรูปแบบและหลักการใช้งาน
Jonathan Eunice

@HorusKol ที่จริงแล้วคำตอบทั้งหมดของที่นี่คำตอบนี้ตรงกับและสนับสนุนมากที่สุดคำตอบของคุณ ฉันจะบอกว่าพวกเขาเข้ากันได้ดี
Jonathan Eunice

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

@EricKing มันยุติธรรมที่จะพูดว่าdivมีวัตถุประสงค์ แต่divและspanไม่ได้มีมากเฉพาะวัตถุประสงค์ที่table, thead, tdฯลฯ ทำ ไม่มีใครจะประหลาดถ้าคุณใช้divองค์ประกอบอื่น ๆสำหรับ sidebars, ดึงคำพูด, การจัดกลุ่มส่วน ฯลฯ - สวยมากทุกที่ในเอกสารเช่นกัน ลองทำแบบนั้นกับประตูบานหนึ่งthead, หรือtd liแทนที่จะเป็น "จุดประสงค์ที่สร้างขึ้น" อาจจะ "เฉพาะจุดประสงค์" หรือ "ที่มีบทบาทเฉพาะเจาะจง"
Jonathan Eunice

0

ใช้กรณีที่สำคัญ มีความแตกต่างใหญ่ระหว่างเค้าโครง / งานนำเสนอในหน้าเนื้อหาและในแอปพลิเคชัน ในเนื้อหาความหมายสำคัญมากสำหรับการรับรู้ SEO และการใช้งาน ในกรณีเหล่านี้การใช้ตารางเพื่อนำเสนอข้อมูลแบบตารางเป็นสิ่งที่ควรทำ ดังที่คนอื่น ๆ ระบุไว้เครื่องมือค้นหาจะลงโทษคุณและคุณอาจเรียกใช้กฎหมายที่ใช้งานไม่ได้หากคุณจำเป็นต้องปฏิบัติตามกฎหมายเพื่อให้สอดคล้องกับแนวทางการใช้งานของรัฐบาล

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.