Keskustelu: Nettisivujen teko: PHP: Tiedon tulostaminen taulukoksi

Hei viisaat ihmiset,
Minulla on alla oleva koodin pätkä:

<?php
$tarkastajat = file("tarkastajat.txt");
echo "<ul>";
foreach ($tarkastajat as $rivi) {
    $osat = explode("|", $rivi);
    $nro = $osat[0];
    $sn = $osat[1];
    $en = $osat[2];
    $ai = $osat[3];
    $rajo = $osat[4];
echo "<li> {$nro} {$sn} {$en} {$ai} {$rajo}";
}
echo "</ul>";

?>

Tämä toimii jos halutaan tulostaa sivulle yksinkertainen luettelo.
Jos haluan nämä taulukkoon seuraavasti:

+-------------------------------+
| $nro | $sn | $en | $ai | $rajo|
+-------------------------------+
| $nro | $sn | $en | $ai | $rajo|
+-------------------------------+
jne...

Tämä täytynee tehdä tuolla ARRAY koodilla, mutten ole siinä onnistunut,
teillä on varmaankin hyviä ideoita?

Mitähän ihmettä tarkoitat ”tuolla ARRAY koodilla”?

Muuta vain echo-riveille taulukkoon tarvittavat HTML-tagit: taulukolle table, riville tr, solulle td.

Muista myös tekstien käsittely HTML-muotoon vahinkojen välttämiseksi.

kyllä tuo list itemeilläkin menee kunhan suljet tuon <li> tagin myös, joka tuosta on unohtunut ja teet taulukon css:llä. Imho, 2017 taulukotkin tulisi css:llä tehdä tablen sijaan. Alla pieni esimerkki.

<div id="container">
  <div id="row">

  	<div id="left">
  		<h4>Vasemmalla</h4>
  		<p>...</p>
  	</div>

  	<div id="middle">
  		<h4>Keskellä</h4>
  		<p>...</p>
  	</div>

  	<div id="right">
    	<h4>Oikealla</h4>
    	<p>...</p>
  	</div>

	</div>
</div>

#container {
    display: table;
    }

  #row  {
    display: table-row;
    }

  #left, #right, #middle {
    display: table-cell;
    }

Kyllä aidot taulukot kuuluu vielä vuonna 2017:kin tehdä HTML:llä.

No se ei kyllä suosituksiin ole kuulunut pitkään aikaan (ellei kyse ole tabikäytöstä, eli taulut pysyy verrattain pienenä), johtuen taulujen renderöinnin hitaudesta versus div elementtien rendaukseen. Nestattujen taulujen rendaus oli eräällä selaimella (Lue IE) jopa aivan suhteettoman hidasta kun käytössä oli prosenttileveydet. Tästä syystä alettiin käyttämään css tauluja yleisellä tasolla, jolla kyseistä ongelmaa kierrettiin. (tästä viimeisin fix varmaan tämä, mutta paska hajoaa aina aika-ajoin)

Yleisesti, HTML taulut renderöidään vasta kun sivu on kokonaan ladattu, jos käytössä on prosenttileveydet (leveydet lasketaan vasta kun koko sivu on rendattu). tästä johtuen aiheutuu tarpeetonta viivettä sivun latautumiseen. Tämä ilmiö on näkyvissä parhaiten isoilla nestatuilla tauluilla.

Tässä vähän yleistä löpinää aiheesta, jos käytetään perinteisiä tauluja

Siinä tapauksessa pitää käyttää asianmukaisia ARIA-määritteitä käytettävyyden varmistamiseksi.

Itse kannatan HTML-tauluja. Niitä on helppo parsia, jos haluaa renderöidä nettisivun jotenkin muuten kuin nettiselaimella. Lisäksi ne toimivat hyvin myös tekstipohjaisilla nettiselaimilla.

Taulut eivät useinkaan ole se suurin hitauden aiheuttaja. Hitaalla yhteydellä isot kuvatkin luovat ongelmia. Jos taulut kielletään hitauden vuoksi, pitäisi samalla kieltää myös kuvat, JavaScript ja erityisesti sisällön lataaminen vasta varsinaisen HTML-tiedoston lataamisen jälkeen.

Tosin tauluja ei pitäisi käyttää mihinkään muuhun kuin oikeiden taulukoiden (taulukkomuotoisen datan) näyttämiseen. Esimerkiksi asettelua ei pitäisi tehdä taulukoilla.

groovyb kirjoitti:

kyllä tuo list itemeilläkin menee kunhan suljet tuon <li> tagin myös, joka tuosta on unohtunut ja teet taulukon css:llä. Imho, 2017 taulukotkin tulisi css:llä tehdä tablen sijaan. Alla pieni esimerkki.

Esimerkkisi on ainakin todella huono, koska se hävittää kaiken semantiikan sekä jättää täysin huomiotta saavutettavuusasiat. Saavutettavuuden parantamisesta (julkisella sektorilla) on jo säädetty EU-tasolla direktiivikin, joten kyse ei ole millään muotoa pikkuasiasta.

Tableihin liittyvän implisiittisen semantiikan menettämisen lisäksi itse asiassa käytät h4-tageja väärin, joten ratkaisusi on semantiikaltaan heikompi kuin vaikka neutraaleja b-tageja roiskimalla. Tagit h1-h6 otsikoivat dataa lohkotasolla eli niitä ei voi käyttää taulukkomuotoisen datan sarakkeiden otsikointiin. (Mikäli yritit käyttää niitä th-tagien korvaajana.)

heh, Kuten Suomenkin sivustomääritykset (JHS suosituksista löytyy), ne ei ihan seuraa tätä päivää :) Tai että niitä edes noudatettaisiin. vai näetkö monilla sivustoilla tänäpäivänä noita a A fonttimuutospainikkeita, jotka kuuluu standardiin vieläkin? Julkishallinnon omilla sivustoilla niitä toki on, mutta ei muualla.

Ei sekään varsinaisesti paranna saavutettavuutta, että sivu ei yksinkertaisesti lataudu vaan timeouttaa vanhalla IE:llä (ja nyt ei puhuta edes mistään muinaisista versioista) koska prosenttimääritteiset taulut ei ehdi rendaamaan ajoissa. Tämä on ihan testattavissa isolla datamäärällä ja nestatuilla tauluilla.

Mitä saavutettavuuteen tulee, se ei tarkoita että kaikki pitäisi tehdä old schoolina. muuten meillä olisi tänä päivänäkin sivut iframe -osioina ja javascriptiä ei riviäkään, css:stä puhumattakaan. ei se IE 2 ja netscape navigator muuten toimisi kunnolla. vai annatko kenties itse rajan mihin saavutettavuus määritetään? jos annat, se vie vähän pohjan pois koko termiltä.

Ylhäällä oli mainittukin jo siitä että tauluja valitettavasti käytetään myös layout -tarpeisiin, joihin niitä ei saisi käyttää. Ja jos sama toiminnallisuus on saavutettavissa ilman niitä, miksi edes käyttää? ja kuten itsekin mainitsin, pieniin datataulukoihin ne käyvät, ei muuhun.

ja ei, en tehnyt mitään th -korvaajaa. kunhan laitoin pientä dataa esimerkin sisään. th sarakkeet voi tehdä ihan normaaleilla table-cell soluilla ekana rivinä, ja määrittää ulkoasun miksi tykkää.

Mitä tulee taas datan parsimiseen nettisivuilta, on muutenkin aika perverssiä alkaa lohkomaan dynaamisesta html:stä dataa ulos (jos se esim tuotetaan jonkun cms:n kautta ja näin myös data voi olla eri muotoista hajottaen parsimisen) CORS estoista puhumattakaan. Sille voi sitte tehdä vaikka kokonaan erillisen rss lähteen, jos haluaa että sivuston kamaa jaetaan muilla sivustoilla.

Sinun argumenttisi on siis se, että ihan turha yrittää tehdä edes välttävää jälkeä, koska kaikki muutkin tekevät huonosti. Hieman ristiriitaisesti annoit ymmärtää, että saavutettavuuteen liittyvät standardit olisivat vanhanaikaisia ja sitä myöten irrelevantteja, vaikka samalla lobbaat sellaista ratkaisua (ongelmaan, jota ei edes ole), joka perustuu siihen kaikista vanhanaikaisimpaan käsitykseen: "Vain sillä on väliä, miltä lopputulos näyttää ihmissilmälle."

Modernissa webissä – kärjistäen ilmaistuna – tuolla asialla on kaikista vähiten merkitystä.

Argumentointisi pyörii tuon yhden cherrypickatun esimerkin eli prosentuaalisia mittoja käyttävien taulukoiden ympärillä. Sanoisin, että jos ongelma on niinkin yksinkertaisesti ratkaistavissa kuin mittayksikköä vaihtamalla, niin mitään ongelmaahan ei edes ole.

Lisäksi argumentoisin itse, että mikäli taulukko on niin suuri, että sen näyttäminen muodostuu kohtuuttomaksi rasitteeksi laitteistolle, niin koko esitysmuoto on suunniteltu täysin väärin. Sivutus on juuri sitä varten, että ylipitkät listat voidaan jakaa pienempiin osiin.

tottakai on, mutta et sinä sivuta leiskaa mikä on tauluilla toteutettu. Tauluissa toki on jänniä rajoitteita muutenkin jotka tekee niistä paskoja leiskassa käytettäviksi. ja ymmärsinkö nyt oikein, että mielestäsi diveillä tehdyt taulut == välttävä jälki? vai mitä tarkoitit?

kyse oli puhtaasti siitä, että tauluja tulisi välttää mikäli kyse on muusta kuin pienestä taulukoinnista datalle. Eli lähtökohtaisesti taulukon käyttämiseen tulisi olla syy. Taulukot tuo mukanaan myös läjän responsiivisuusongelmia, joten ellei halua varautua läjään erillisiä media queryjä,kannattaa aina ensin miettiä tarvitsenko ylipäätään tablea vai voinko tehdä tämän asian ilman niitä. Usein syy tablen virheelliseen tarpeeseen on vertikaalinen keskitys, ja tähän ei tosiaan kannata niitä käyttää.

groovyb kirjoitti:

kyse oli puhtaasti siitä, että tauluja tulisi välttää mikäli kyse on muusta kuin pienestä taulukoinnista datalle. – – Usein syy tablen virheelliseen tarpeeseen on vertikaalinen keskitys, ja tähän ei tosiaan kannata niitä käyttää.

Nyt näköjään vaihdoit jo aihetta kokonaan. Hieno pelastus.

Aloittajalla näyttää olevan lista (ul), jossa yhdessä kohdassa (li) on aina viisi eri tietoa peräkkäin. Aloittaja kysyy, miten tästä saadaan taulukko. Mielestäni tämä on aivan tyypillinen järkevä taulukkojen käyttötilanne. Sanoit tähän, että ”2017 taulukotkin tulisi css:llä tehdä tablen sijaan”. Seisotko vielä näiden sanojesi takana tässäkin tilanteessa?

tottakai seison, jos kerran tarkoitus on unordered list tehdä luettelon näköisenä, miksi pakottaa tablet käyttöön? ko. toiminnallisuuden saa tehtyä mainiosti diveilläkin eikä tartte kikkailla responsiivisuuden kanssa. melkoisesti helpottaa vaikka bootstrapillä heittää li class col-xs-12 col-md-3 tyylisesti, versus hajoava leiska kun content ei mahdukkaan siihen width 25% table celliin.

Aloittajan esimerkissä ei mainittu minkäpituista dataa soluihin tulee, jos kyse on pienestä merkkimäärästä joka mobiiliin soluineen mahtuu inhimillisesti, miksei. ja jos sitä dataa on verrattain vähän. lähtökohtaisesti kuitenkin muulla kuin tablella, jos varmuutta ei ole. pitkät kuvaustekstit näyttää melkoisen herkulliselta td:ssä mobiililla, ellei sitten heitä x-overflow scrollia. ja se taasen on ihan yhtä ärsyttävää.

Mitä tuossa performansseja katselin, niin 2500 rivin table 10 solulla vei 18sek ilman paginaatioita, 10sek niiden kanssa IE 9:llä. sama chromella 3sek (kantahaut toki mukana, ja hain kaikki kerralla). mutta chromen ja ie:n ero on aika huomattava. IE vanha versio, mutta eikö se tuossa saatavuudessa ollut tarkoituksenakin?

groovyb kirjoitti:

tottakai seison, jos kerran tarkoitus on unordered list tehdä luettelon näköisenä, miksi pakottaa tablet käyttöön?

Jos katsot oikein tarkkaan, niin saatat huomata, että ap yritti tehdä taulukon unordered listiä käyttäen. Oikea vastaus ongelmaan on tehdä oikea taulukko.

groovyb kirjoitti:

Mitä tuossa performansseja katselin, niin 2500 rivin table 10 solulla vei 18sek ilman paginaatioita, 10sek niiden kanssa IE 9:llä. sama chromella 3sek (kantahaut toki mukana, ja hain kaikki kerralla). mutta chromen ja ie:n ero on aika huomattava. IE vanha versio, mutta eikö se tuossa saatavuudessa ollut tarkoituksenakin?

Ei. Puhut selainversiosta, jonka seuraajakin on ollut kuollut ja kuopattu jo puolentoista vuoden ajan. Microsoft on lopettanut kaiken tuen muille Internet Explorerin versioille kuin IE11 vuoden 2016 tammikuussa.

Ja vaikka asia olisikin toisin, niin saavutettavuus ei muutenkaan tarkoita sitä, että webin pitäisi olla selattavissa kaikilla mahdollisilla ohjelmistoilla, joille valmistaja tarjoaa vielä jonkinlaista tukea, vaan että webin tulee olla selattavissa niillä ohjelmistoilla, jotka noudattavat alan standardeja. Viime kädessä voidaan joutua tukemaan ohjelmistoja, joilla on laaja käyttäjäkunta, vaikka ne olisivatkin huonoja. IE9 ei kuitenkaan ole missää noista kategorioista.

Table on taulukoita varten. Sitä varten ne on suunniteltukin!