[Opmerking: voor degenen die deze vraag misschien verwarren met “waarom geen tabellen gebruiken voor HTML-opmaak”, ik stel die vraag niet. De vraag die ik stel is waarom een rasterlay-out fundamenteel verschilt van een tabellay-out.]
Ik doe onderzoek naar CSS-bibliotheken (met name Bootstrap) voor een project. Ik ben een programmeur in plaats van een webdesigner en ik denk dat ik baat zou kunnen hebben bij een bibliotheek die een goed ontwerp omvat.
We weten allemaal dat het een slechte gewoonte is om HTML-tabellen te gebruiken om de basislay-out van de site te realiseren, omdat het presentatie en inhoud combineert. Een van de voordelen van CSS-bibliotheken zoals Bootstrap is dat ze de mogelijkheid bieden om “raster”-lay-outs te maken zonder tabellen te gebruiken. Ik heb echter een beetje moeite om te begrijpen hoe hun rasterlay-outs op een zinvolle manier verschillen van de equivalente tabellay-out.
Met andere woorden, wat is het fundamenteleverschil tussen deze twee voorbeelden van HTML? Heb ik het mis als ik denk dat de rasterlay-out gewoon een tabel is met een andere naam?
<div class="row">
<div class="span16"></div>
</div>
<div class="row">
<div class="span4"></div>
<div class="span4"></div>
<div class="span4"></div>
<div class="span4"></div>
</div>
en
<table>
<tr>
<td colspan=4></td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</table>
Antwoord 1, autoriteit 100%
Het verschil is dat het eerste voorbeeld semantisch gemarkeerdis, ervan uitgaande dat de gegevens die worden gemarkeerd niet echt in tabelvorm zijn. <table>mag alleen worden gebruikt voor tabelgegevens, niet voor gegevens die toevallig worden weergegeven in een lay-out die lijkt op een tabel.
Het is echter juist dat het gebruik van CSS-pakketten zoals Bootstrap, waarbij u klassen moet toewijzen aan HTML-elementen die nietsemantisch maar presentatief zijn, de scheiding van inhoud en presentatie vermindert, waardoor het verschil enigszins onduidelijk wordt . U zousemantisch betekenisvolle klassen aan uw elementen moeten toewijzen en lesscss-mixins (of vergelijkbare technologie) moeten gebruiken om het in het CSS-framework gedefinieerde presentatiegedrag aan deze klassen toe te wijzen, in plaats van de presentatieklassen rechtstreeks aan de elementen toe te wijzen.
Zeg:
<div class="products">
<div class="product"></div>
</div>
.products {
.row;
}
.products > .product {
.span16;
}
Merk op dat ik zeg zou. In de praktijk is dit niet altijd de meest werkbare optie, maar het zou het theoretische doel moeten zijn.
Antwoord 2, autoriteit 61%
Ik geloof dat CBroe-opmerking is de beste optie, dus ik heb ervoor gekozen om het te verduidelijken.
Vermijd div‘s. Een divzou uw laatste redmiddel moeten zijn, niet uw eerste optie. Probeer in plaats daarvan Bootstrap-klassen te gebruiken voor de daadwerkelijke elementen. Bijvoorbeeld:
<form class="container">
<fieldset class="row">
<label class="span4" for"search">Type your search</label>
<input class="span6" type="text" id="search" />
</fieldset>
</form>
Het is een schande om Fieldet te gebruiken om een enkel veld te bevatten, maar het is semantisch het beste dan het gebruik van een divvoor hetzelfde. De HTML5-standaard definieert veel nieuwe containerelementen, zoals article, section, header, footeren nog veel meer . In sommige gevallen moet u divs gebruiken, maar als u het gebruik van het gebruik minimaliseert, is uw code veel meer semantisch.
Antwoord 3, Autoriteit 36%
Het fundamentele verschil is dat u de lay-out met bootstrap kunt “reflow” voor verschillende weergavegrootte die eenvoudigweg media-query’s gebruiken zonder uw markup te hoeven wijzigen. Ik kan bijvoorbeeld beslissen op desktops, ik wil dat je 4 DIV’s op dezelfde rij staan omdat de gebruiker een hoge resolutie brede display heeft, maar op telefoons wil ik 2 duiken op één rij en volgende divs op de volgende rijen. Dus op deze manier kan ik mijn kolomcount in elke rij aanpassen met behulp van mediaquery’s. Als u harde gecodeerde HTML-tafels gebruikt, is het erg moeilijk om dit te doen.
Dat gezegd hebbende, ik hou niet echt van bootstrap implementatie om de volgende redenen:
- Het heeft breakpoints hard gecodeerd in pixels. Dit betekent dat uw website als telefoons en tabellen vooruitgeeft, uw website kan beginnen met het tonen van onverwachte lay-outs op die apparaten. Pixel Count is Slechte proxy voor het weergeven Maat .
- Het beperkt het maximale gebruikte weergavegebied naar 1170px, dat weer een Bummer is voor gebruikers met mooie brede displays die ze daadwerkelijk kunnen gebruiken om meer inhoud in uw app te bekijken.
- Bootstrap’s lay-out is niet onafhankelijk, d.w.z. u kunt geen kolomvolgorde wijzigen die is ingesteld in HTML. Dit is echter meer van een pedantisch punt.
- De standaardlay-out is voor zeer kleine resolutie en lay-outs met een hogere resolutie alleen trigger wanneer media-query’s brand, welke IMO, een slechte keuze is, rekening houdend met telefoons zullen een betere resolutie blijven bestaan en eerder dan later uw website voor verouderde lay-out is ingesteld mobiele toestellen.
- Bootstrap-lay-outs zijn niet echt “zorgen maken” in die zin dat je hun fijne afdruk moet lezen om alle bugs en browsers te zien die ze niet waardig zijn om te ondersteunen, maar welke u over. Als u gericht is op gebruikers in Zuid-Korea of China, zou u bijvoorbeeld in verrassing zijn.
Dus, niet alles is goud in bootstrap en hun aanpak is niet noodzakelijk altijd altijd het best mogelijke (als een terzijde, een ander ding dat ik verachten in bootstrap is hun obsessie met zogenaamde “jumbotrones” – die onroerend goed wijst ongemak Your-Face Headers – die ik hoop dat de gemeenschap niet begint te nemen als “nieuwe standaard”). Persoonlijk gebruik ik CSS TABLE-lay-out (display:table) TELECTEERD DAGEN die vergelijkbare voordelen hebben als bootstrap zonder hardcoding <table>in mijn markup. Ik kan nog steeds media-query’s gebruiken om rijen te herschikken, afhankelijk van het portret of de landschapsoriëntatie, bijvoorbeeld. Het belangrijkste voordeel is echter dat mijn lay-outs echt pixel of zelfs percentage onafhankelijk zijn. In de lay-out van 3 kolom laat ik bijvoorbeeld inhoud bepalen hoeveel ruimte eerst en laatste kolommen moeten nemen. Er is geen pixel of zelfs percentage breedte. De Center Column grijpt alle resterende ruimte (wat goed is voor mijn app, maar het is misschien niet voor anderen). Bovendien gebruik ik EMS in Media Query-pauze punten die Bootstrap verrassend niet.
Antwoord 4, Autoriteit 12%
Ik gebruik het bootstrap-raster voor pagina-indeling, tabellen voor tabelgegevens.
Ik denk aan het rooster in bootstrap, niet als een raster in de ontwikkelaarsgevoel, zoals een gridview-besturing, maar meer in het ontwerppagina-lay-out-gevoel – als een raster om de pagina-inhoud te bevatten. En hoewel het bootstrap-raster ook kon worden gebruikt om een conventioneel raster te creëren dat tabulaire gegevens bevat, zoals bedrieglijk opmerkt, is dit soort raster beter geschikt voor HTML-tabellen – die nog steeds acceptabel zijn om in dit scenario te gebruiken.
Antwoord 5, Autoriteit 9%
Als je alleen tabellen gebruikt, denk ik dat je veel flexibiliteit misloopt bij het aanpassen van de grootte van je document voor mobiel/tablets zonder dat je voor elk apparaat een aparte pagina hoeft te maken. als je tabelstructuur eenmaal is gedefinieerd, kun je alleen nog maar in- en uitzoomen.
Antwoord 6, autoriteit 9%
Hoewel er niet per se veel semantischverschil is tussen de twee sets van opmaak (aangezien de klassen die worden gebruikt door Bootstrap’s rastersysteem inderdaad puur presentatief zijn), is een zeer belangrijk onderscheid dat het rastersysteem veel meer is flexibel.
Het zou bijvoorbeeld erg moeilijk zijn om uw op tabellen gebaseerde lay-out te laten reageren op verschillende schermformaten. Er is geen manier om de browser te vertellen om een tdelement ondereen andere tdin dezelfde rij weer te geven. Terwijl met het voorbeeld divdat gemakkelijk te doen is, en dezelfde opmaak op verschillende manieren kan worden gepresenteerd zelfswanneer de klassen “presentatief” zijn in de zin dat ze de relatieve verhoudingen en positionering van de elementen op de pagina.
Antwoord 7, autoriteit 3%
Als het mag, wil ik graag samenvatten wat ik heb verzameld uit de andere opmerkingen en de linkexplosie die ik op deze pagina heb ervaren:
Het probleem met het gebruik van tabellen is niet de lay-out van het raster, het is de poging om het uit te drukken met HTML in plaats van CSS.
Bootstrap staat rasterlay-outs toe via (meestal) pure CSS, daarom is het OK. Het ‘meestal’ deel komt omdat je HTML nog steeds besmet zal zijn door je lay-outgegevens, maar subtieler:
<nav class="span4"> ... </nav>
<article class="span8"> ... </article>
Dit is zeker aanzienlijk semantischer en beter te onderhouden dan de oude tabelontwerpen, maar de ‘span4’ en ‘span8’ zijn nog steeds weergavegegevens die zijn ingebed in onze HTML. Omdat ontwerp echter nooit echt kan worden losgekoppeld van onze gegevens (bijv. geneste div’s), is dit een redelijke prijs om te betalen.
Dat gezegd hebbende, zelfs deze koppeling kan worden verbroken als je wat modernere CSS-functies gebruikt die worden geleverd door een voorverwerkte taal, zoals MINDER. Hetzelfde voorbeeld:
<nav id="secondary-nav"> ... </nav>
<article id="main-content"> ... </article>
In combinatie met de volgende MINDER:
#secondary-nav{
.span4;
// More styling (padding, etc) if needed
}
#main-content{
.span8;
}
Dit creëert volledig ontkoppelde HTML en Stylesheet, wat ideaal is, omdat de HTML schoner en leesbaarder is, en herontwerpen kunnen worden gemaakt met minder HTML-aanpassing. Dit werkt echter alleen als u LESS of een andere CSS-preprocessor gebruikt, omdat CSS momenteel geen mixins (AFAIK) ondersteunt.
We gebruiken LESS al op mijn werkplek, dus ik weet dat ik dit soort oplossingen zal gaan gebruiken. Ik ben een groot voorstander van semantische HTML en ontkoppeling van gegevensontwerp. 🙂
Antwoord 8
In principe zijn DIV’s DIV’s & Tafelelementen zijn gewoon tafelelementen. Het probleem met tabellen is vaak het bijhouden van alle kolommen & de rijen omdat het uiteindelijk een strikte gegevensconstructie is. DIV’s zijn veel flexibeler & vergevingsgezind.
Als u bijvoorbeeld de vier DIV’s wilt nemen met de klasse die gelijk is aan “span4” en deze wilt wijzigen in een breedte van 2 kolommen, hoeft u alleen maar een klein beetje CSS aan te passen voor de buitenste klasse “rij” en misschien de klasse “span4”. Als ik DIV’s als deze doe, zou ik zelfs vermijden om individuele DIV’s “span4” of een ander nummer te noemen.
Mijn benadering zou zijn om een bovenliggende wrapper DIV te maken die “rowspan” wordt genoemd en de binnenste DIV’s zouden een generieke ID hebben, zoals misschien “cell”.
<div class="rowspan">
<div class="cell"></div>
<div class="cell"></div>
<div class="cell"></div>
<div class="cell"></div>
</div>
Elke “cel”-klasse kan bijvoorbeeld een breedte van 100 pixels hebben, en dan kan de bovenliggende “rijspan” 400 pixels zijn. Dat komt neer op 4 kolommen op een rij. Wil je er 2 kolommen van maken? Geen probleem! Verander gewoon “rijspanwijdte” in 200 pixels breed. Op dit moment is het allemaal in CSS, dus het is gemakkelijk te doen zonder de paginastructuur in de DOM te verschuiven.
Maar met tabellen? Niet makkelijk. U zou de tabel in principe opnieuw moeten renderen met </tr><tr>-tags om nieuwe rijen te maken.
Antwoord 9
Versie met tabel, tr, td is afhankelijk van browseralgoritmen – inwikkeling, dynamische breedte, marges, centreren enz.
Versie met div kan gemakkelijker worden afgesteld door css en scripts.