Terve taas ja tyhmät kysymykset jatkuu.
olen koittanut nettiä selailla ja saada divit järjestykseen, mutta ei onnistu vaikka lukuisia ohjeita lukenut, miten saisin erikokoiset divit järjestymään mukavasti järjestykseen.
eli:
minulla tule luupista erikokoisen divin vaativaa tavaraa, voisi kuvitella että divit on 1x1 2x1 ja 1x2 kokoisia. ja satunnaisessa järjestyksessä tulostuvat.
jos laittaa flaot left niin ne pomppii vähän miten sattuu
haluaisin ne esim näin
http://aijaa.com/fmlj6d
Onko tämä mahdollista mitenkään että ne tulostuisivat järkevästi luupilla?
Laita ne divit tulostumaan jonkun tietynlevyisen ison divin sisälle, jolloin aina kun div ei leveyden puolesta mahdu toisen viereen, se menee seuraavalle riville. Esimerkki löytyy täältä. Esimerkki yksinkertaisena:
<div id="container"> <div>Sisältöä</div> <div>Toinen erilevyinen divi</div> </div>
div#container {
width: 500px;
}
div {
witdh: 100px; // Tai muut leveydet
float: left;
}Kiitos, Tuolla ratkaisee leveys ongelman, mutta mites jos on eri korkuisia?
Ei niitä nyt voi aivan mielivaltaisessa järjestyksessä tulostella, koska muuten ruudukkoon jää tyhjiä ruutuja, jotka voivat sekoittaa leiskaa.
LessCSS:llä tekisin jotain tällaista:
@grid-unit: 100px;
@grid-space: 10px;
@grid-border: 1px;
.box-geom(@w, @h) {
width: (@grid-unit + @grid-border) * @w + @grid-space * (@w - 1);
height: (@grid-unit + @grid-border) * @h + @grid-space * (@h - 1);
}
#the-grid {
width: 500px;
padding: 0 0 @grid-space @grid-space;
}
.gbox {
border: @grid-border solid #000;
margin: @grid-space @grid-space 0 0;
float: left;
}
.g-1x1 {
.box-geom(1, 1);
}
.g-2x1 {
.box-geom(2, 1);
}
.g-2x2 {
.box-geom(2, 2);
}
.g-1x2 {
.box-geom(1, 2);
}<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Template Document</title>
<meta charset="UTF-8"/>
<style type="text/css">
#the-grid {
width: 500px;
padding: 0 0 10px 10px;
}
.gbox {
border: 1px solid #000;
margin: 10px 10px 0 0;
float: left;
}
.g-1x1 {
width: 101px;
height: 101px;
}
.g-2x1 {
width: 212px;
height: 101px;
}
.g-2x2 {
width: 212px;
height: 212px;
}
.g-1x2 {
width: 101px;
height: 212px;
}
</style>
</head>
<body>
<div id="the-grid">
<div class="gbox g-1x2"></div>
<div class="gbox g-2x1"></div>
<div class="gbox g-1x1"></div>
<div class="gbox g-1x1"></div>
<div class="gbox g-2x1"></div>
<div class="gbox g-2x1"></div>
<div class="gbox g-2x1"></div>
<div class="gbox g-1x1"></div>
<div class="gbox g-1x2"></div>
<div class="gbox g-1x1"></div>
<div class="gbox g-1x1"></div>
<div class="gbox g-1x1"></div>
</div>
</body>
</html>Tämä on itseasiassa niitä tapauksia, joissa taulukoista löytyy todella helppo toteutustapa esityspuolelle. Pelkän CSS:n kautta ajateltuna on pakko lähteä varsin monimutkaisiin kikkailuihin (kuten alkemistin mainitsema LESS), koska colspan ja rowspan ei ole CSS:n taulukkotyyleissä mukana ja silti joutuu myös ratkomaan tulostettujen elementtien järjestysongelman.
Ratkaisu siis yksinkertaisimmillaan on käyttää taulukkoa esityspuolella:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Simppeli järjestys</title>
<style type="text/css">
table {
border: 0;
border-collapse: collapse;
height: 750px;
margin: 0;
padding: 0;
width: 750px;
}
td {
background: #CCC;
border: 5px solid #FFF;
height: 33%;
vertical-align: top;
width: 33%;
}
</style>
</head>
<body>
<table>
<tr>
<td colspan="2">Vaaka</td>
<td rowspan="2">Pysty</td>
</tr>
<tr>
<td>Normi</td>
<td rowspan="2">Pysty</td>
</tr>
<tr>
<td>Normi</td>
<td>Normi</td>
</tr>
</ul>
</body>
</html>Listan tulostuksessa palvelimen puolella taas täytyy järjestää sisältöä. Se ei voi olla täysin satunnaisessa järjestyksessä!
Solujen määrä per rivi riippuu siitä, montako pystysolua edelliselle riville on tulostettu ja löytyykö vaakasoluja.
Rajoituksia tulostettaessa:
1) Vaakasolu ei voi koskaan alkaa rivin viimeisestä solusta!
2) Vaakasoluja ei voi laittaa riville, jota edeltävällä rivillä on useampi kuin yksi pystysolu tai jos pystysolu on sijoitettu siten, että tilaa jää vain pienille soluille.
Helpointa on toteuttaa kolmen tai neljän pystyrivin ratkaisu. Niin tai näin, järjestelyä joutuu tekemään ja voi olla, että tyhjiäkin soluja tarvitsee lätkäistä väliin jos saatavilla ei ole tarpeeksi pienisisältöisiä elementtejä.
Muoks!
Tulevaisuudessa Flexbox voi olla ratkaisu näihin ongelmiin. Toistaiseksi selaintuki ei ole riittävä. Tosin ainakaan tuon sivun esimerkeissä ei ole vielä yritetty saada vastaavaa lopputulosta aikaiseksi, mutta kokeilemalla sain "jotain vähän sinne päin".
Sulla on kovasti pokkaa sanoa tuota kymmenrivistä less-toteutusta monimutkaiseksi, muttet edes yrittänyt toteuttaa omaa table-viritelmääsi. Jos olisit kokeillut saada sitä toimimaan, niin olisit huomannut, miten monimutkainen siitä tuleekaan.
Taulukoiden käytössä on edelleen se sama ydinongelma: palikoita ei voi tulostaa täysin mielivaltaisessa järjestyksessä, koska muuten jää tyhjiä reikiä. Päin vastoin taulukoilla luo itselleen toisen yhtä mittavan ongelman: palikat eivät automaattisesti mene sinne, missä on tyhjää tilaa, vaan koodissa täytyy laskea rivien koko ja osata vaihtaa riviä oikeassa kohdassa. Tästä tuleekin hyvin äkkiä monimutkaista, jos edellisellä rivillä on palikoita, jotka korkeutensa puolesta valtaavat useamman rivin.
FAIL! Todella helppo? Haista ny v...
Öö. Totesin saman viestissäsi esille nostaman monimutkaisuuden, mitä palvelinpuolella tarvitsee järjestelemiseen. Toisin kuin sinä, kerroin kuitenkin viestissäni mitä kaikkea tähän monimutkaisuuteen kuuluu, jolloin pääsee jo ohjelmoinnissa alkuun. Tarkennetaan kuitenkin vielä.
Toteutuksessa itsessäänhän ei tarvitse ottaa huomioon muuta kuin se, että on tieto rivillä olevista vapaista soluista, jolloin voi jättää sijoittamatta vaakasolun jos tilaa ei ole. Pystysolu taas mahtuu aina mukaan, paitsi aivan viimeisimmälle riville. Sisältölistasta taas voi aina käydä napsimassa seuraavan sopivan solun tarpeisiin, eli skipata vaakasolut.
Toki koodi on monimutkaisempi kuin pelkkä suora tulostus, mutta ei välttämättä niin monimutkainen kuin mitä veettelet. Taulukkorakenne kun kuitenkin automaattisesti huolehtii sen puolen, että solut sijoittuvat oikein (eli jos edellisellä rivillä on ensimmäisenä pystysolu, niin seuraavan rivin ensimmäinen solu siirtyy automaattisesti oikealle).
Tietty jos ohjelmointi tuottaa hankaluuksia, niin homma ei ole todella helppo.
Taulukon ratkaisema ongelma on kaikista triviaalein osuus tässä, kuten jo tuolla omalla css-ratkaisullani osoitin. Taulukoiden käyttö kuitenkin hankaloittaa olennaisesti mahdollisia päälle liimattavia ajax-ratkaisuita, joten tablen tunkeminen tuonne on sulaa hulluutta. Ja jos lähdetään kirjoittamaan logiikkaa palikoiden älykkäämpään sijoitteluun, niin tekisin sen luultavasti javascriptillä, ja oletuksena tarjoaisin tuollaista yksinkertaista css-pohjaista asemointia.
Taulukko edelleenkin sopii vain taulukkomuotoisen datan esittämiseen, ei taulukolta etäisesti näyttävän esitysmuodon asetteluun.
Oho. Viesti ilman veettelyä.
Kaikki riippuu siitä, mitä ollaan tekemässä. Jos aletaan liimata mukaan muutenkin hienoja dynaamisia toteutuksia, niin sitten toki on hyvä kuorruttaa kaikki karkilla ja tehdä viimeisen päälle. Jos taas ollaan tekemässä vain listausta ilman suurempia ihmeellisyyksiä, niin on aika turhaa monimutkaistaa esityspuoltakin kaksinkertaisella työllä (LESS ja CSS-asemoinnit). Ainakin ensimmäisen vaiheen toteutuksessa on helppo työskennellä taulukon pohjalta, koska siinä ei tarvitse miettiä tulostuuko taulukko oikein vaiko ei - se on vahvasti testattu rakenne, joka tässä tapauksessa toimii aina oikein. Ja sitten kun sen saa toimimaan, niin voi toteuttaa myös sen täydellisen oikeaoppisen divejä käyttämättömän sisältölistauksen. Ja sen voi mahdollisesti päivittää flexboxiksi sitten joskus.
The Alchemist kirjoitti:
Taulukko edelleenkin sopii vain taulukkomuotoisen datan esittämiseen, ei taulukolta etäisesti näyttävän esitysmuodon asetteluun.
Taulukkotaitosta voidaan toki aina sanoa ”väärin ratkaistu!”, jolloin päästään ulvomaan isossa kuorossa. Todelliset argumentit ovat kuitenkin heppoisia ja sillä tasolla, että jos haluttaisiinkin tehdä jotain ihan muuta niin sitten pitäisi muuttaa jotain.
Olennaista on kuitenkin se, että kysyjän esittämä taitto ei sovi hyvin taulukolla toteutettavaksi, koska alueet sijaitsevat jokseenkin epäsäännöllisesti. Jos halutaan juuri sellainen asettelu pikselin tarkkuudella, niin sitten on tietysti helpointa käyttää absoluuttista asemointia. Eli position: absolute ja elementeille koordinaatit. Float yms. silloin vain sotkee asioita. Jos taas halutaan jotain muuta, no jaa, ratkaisu riippuu aika lailla siitä, mikä varsinaisesti on kysymys.
Merri kirjoitti:
-- on aika turhaa monimutkaistaa esityspuoltakin kaksinkertaisella työllä (LESS ja CSS-asemoinnit).
Lessissä ei ole mitään kaksinkertaista. Sen voi compiloida css:ksi automaattisesti niin palvelimen päässä php:llä kuin clientissakin js:llä. Lisäksi less on itse asiassa css:n superset eli validit css-määrittelyt ovat myös valideja less-määrittelyitä, joten vanhojen tyylitiedostojenkaan kanssa ei tule ongelmia. Se sopii siis täydellisesti css:n korvaamiseen kaikissa tilanteissa ilman poikkeuksia.
Esimerkkiini laitoin css:n näkyville ihan havainnollistamisen vuoksi.
lainaus:
Ainakin ensimmäisen vaiheen toteutuksessa on helppo työskennellä taulukon pohjalta, koska siinä ei tarvitse miettiä tulostuuko taulukko oikein vaiko ei - se on vahvasti testattu rakenne, joka tässä tapauksessa toimii aina oikein. Ja sitten kun sen saa toimimaan, niin voi toteuttaa myös sen täydellisen oikeaoppisen divejä käyttämättömän sisältölistauksen. Ja sen voi mahdollisesti päivittää flexboxiksi sitten joskus.
No eihän se nyt noin mene. Taulukkoa varten joudut kirjoittamaan oman algoritmisi asemointiin, eikä sitä ole silloin testattu kenenkään toimesta. Äkkiseltään pohdittuna mieleen tulee vähintään kymmenkunta testitapausta, joita tuollaisen algoritmin testaamiseen vaaditaan. Virheen mahdollisuuksia on siis lukuisia.
Sen sijaan matematiikka ei valehtele koskaan: oikein laadittu lauseke on aina oikeassa ja myös teoreettisesti validiksi todistettavissa. Css-pohjainen toteutukseni on ainoastaan yksi alkeistason geometriaa hyödyntävä lauseke, jolla lasketaan yksittäisen palikan fyysiset mitat.
Esittämäsi ratkaisu ei kuitenkaan pääse lähellekään aloitusviestissä esitettyä asettelua.
Lisäys:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Sama ajatus ilman taulukkoa</title>
<style type="text/css">
ul {
background: #000;
border: 0;
list-style: none;
margin: 0;
padding: 5px 0 0 0;
width: 605px;
}
ul:after {
clear: both;
content: '';
display: block;
}
li {
background: #CCC;
display: block;
float: left;
height: 195px;
margin: 0 0 5px 5px;
padding: 0;
width: 195px;
}
li.eka {
clear: left;
}
li.korkea {
height: 395px;
}
li.leveä {
width: 395px;
}
li.eka + li.korkea + li.eka {
margin-top: -200px;
}
li.eka + li.eka + li.korkea {
margin-top: -200px;
}
</style>
</head>
<body>
<ul>
<li class="eka leveä">Leveä</li>
<li class="korkea">Korkea</li>
<li class="eka">Normi</li>
<li class="eka">Normi</li>
<li class="korkea">Korkea</li>
<li>Normi</li>
</ul>
</body>
</html>Tässä nyt sitten sama lopputulos ilman taulukkoa. Koodia tarvitsee enemmän kuin tässä on esitetty, jotta katettaisiin kaikki rivityksien poikkeustapaukset. Eli siis lisää noita plussasääntöyhdistelmiä, joilla annetaan negatiivista marginaalia tarpeen mukaan.
class="eka" tarvitsee laskea palvelinpuolella. Se kertoo kunkin rivin ensimmäisen laatikon. Muuten rivien laskenta taitaa mennä aika samalla tavalla kuin aiemmin esittämässäni taulukkovaihtoehdossa. CSS:ää vaan tarvitsee kirjoittaa rutosti enemmän.
Useamman pystyrivin lisääminen tietenkin monimutkaistaa CSS:ää entisestään. Tässä kuitenkin sivuutetaan tarve ylimääräiselle kirjastolle tai JavaScriptille.
Muoks!
class="eka" voi toki laskea myös JavaScriptillä palvelinpuolen sijasta. jQueryllä lienee helpoin lisäillä niitä.
Itse kannatan aivan erilaista vaihtoehtoa: muuta suunnitelmaa. Olen nähnyt monia sivustoja, joissa on sovellettu mitä kummallisimpia laatikkoratkaisuja, jotka "näyttävät hauskalta", "luovat dynaamista tunnelmaa" ja "muistuttavat tuttua työpöytää tai paperilappusia". Käyttäjän asemassa en ole ikinä pitänyt näistä vapaamuotoisista asetelmista tai kuullut muidenkaan erityisesti pitävän. Minusta on selvintä, että laatikot muodostavat ensisijaisesti joko rivejä tai sarakkeita, jolloin myös asettelu on paljon yksinkertaisempaa. Tietenkin ison laatikon sisuksen voi sitten jakaa edelleen pienempiin osiin, jos on syytä.
Samalla ajatuksella jatkaen voi myös harkita vaikkapa YLE:n tai BBC:n käyttämää toteutusta, jossa laatikoiden fyysinen järjestys pysyy aina samana. Laatikon koko kuvastaa sisällön tärkeyttä. Kunkin laatikon sisältö määritellään toimituksissa erikseen, mutta määrittelyn perusteena voi pienemmällä sivustolla toimia sisällön tuoreus.
Laatikoita voi käyttää myös esikatselutyyppisesti, jolloin esim. viemällä hiiren päälle saa hieman enemmän tietoa (vaikka tekstiä kuvan lisäksi). Riippuu siitä, miten paljon haluaa "näyttävyyttä".
Merri kirjoitti:
Esittämäsi ratkaisu ei kuitenkaan pääse lähellekään aloitusviestissä esitettyä asettelua.
Ei pääse sinunkaan ratkaisusi, koska et kirjoittanut logiikkaa, jolla palikoiden sijoittelu voidaan laskea. Tämä algoritmi olisi joka tapauksessa täysin irrallaan siitä, miten laatikot lopulta päätetään renderöidä, joten sama algoritmi toimisi myös mille tahansa css-toteutukselle.
Maksusta voin toki toteuttaa koko touhun.
Itse en kyllä lähtisi ulkoasua edes ajattelemaan noin kaaosmaisena.
Tuo antamasi esimerkki ehkä vielä menisi ulkoasunsa puolesta antaen hieman hassun vaikutelman, mutta koska laatikoitasi ladataan dynaamisesti eri leveyksillä ja kokoisina, suurin osa muista ulkoasuvaihtoehdoista olisi yhtä hirveyttä teki sitten itse asettelun millä menetelmällä tahansa.
Täällähän on keskustelua, hienoa.
Täytyy ehkä alkaa etsimään toista lähestymistapaa tähän.
Mietin vaan miten saisin tiiviisti sisällön tulostettua, jos tekee määrämuotoiset laatikot, niihin jää väkisin tyhjää tilaa koska sisältöä ei kaikkii paljoa tule
Ei siinä tarvitse määrittää kuin leveys. Ja jos sisältöä ei tule joka laatikkoon paljoa edes etukäteissuunnitelmissa, niin silloinhan se on jo varma merkki siitä, että suunniteltu näyttömuoto on tarkoitukseen aivan väärä.
Aihe on jo aika vanha, joten et voi enää vastata siihen.