Print

[Rashnu]

Ik zou heel graag een voorbeeld van de HTML + CSS van Mondriaans schilderij hebben. Ik krijg het maar niet voor elkaar.

Ik zou eigenlijk aan alle cellen in deze tabel meerdere klassen willen kunnen toewijzen, eentje voor de kolombreedte, eentje voor de rijhoogte, eentje voor de kleur, en en eentje voor de borders. Maar een klasse bij een element is altijd uniek, zo te zien.
Een brute force approach oplossing zou kunnen zijn om voor elke cel apart een eigen klasse te maken met daarin alle eigenschappen die ik nodig heb (dus 7x7 klassen voor een tabel van 7 rijen bij 7 kolommen), maar dat vind ik niet passen bij het idee van overerving en hierarchie, d.w.z. om dingen op een high level te definieren die voor alles daaronder gelden.
Wat zou ik nu bijvoorbeeld moeten doen als ik in diverse vakjes teksten met verschillende lettertypes zou willen zetten? Dan heb ik nog meer klassen nodig.
Of moet ik maar gaan werken met div elementen, zodat ik alles een unieke ID kan geven, en dan per ID alle benodigde eigenschappen opsommen? Maar dat lijkt me ook weer een brute force approach.
 
Mijn poging heb ik bijgevoegd. Graag je commentaar.
 
Uiteindelijk heb ik maar mijn toevlucht tot inline CSS genomen om de rand langs de omtrek van het schilderij te onderdrukken, maar ook dat werkt niet goed. Kun je me ook vertellen waarom het onderdrukken van de rand links en bovenaan het schilderij niet werkt, terwijl het onder en rechts wel werkt?
Hoe voorkom ik dat de zwarte rand om de vakjes heen niet helemaal tot aan de rand van het schilderij doorloopt, maar juist een klein stukje ervoor ophoudt? Dat snap ik al helemaal niet. Of ik zou daarvoor nog extra een aparte hele smalle kolom links en een hele dunne rij boven en onder erbij moeten maken.
Ook het werken met width en height op kolom en rijniveau gedraagt zich heel vreemd, want ik moet om het er natuurgetrouw uit te laten zien andere maten opgeven dan die ik meet met een lineaal. En bij het vertonen in de browser schaalt de zaak wel in de breedte (als ik de venstergrootte aanpas), maar niet in hoogte. Ra, ra, waarom niet? Alle maten staan in mm.
Als ik de maten in em doe (zodat het kan schalen) dan krijg ik de juiste verhoudingen maar niet voor elkaar.
 

[Frances]

Hallo Rashnu,

Ik heb een voorbeeld gemaakt op basis van jouw Mondriaan. Je opzet is namelijk heel goed. Je kunt het bekijken op http://www.waalweb.nl/boek/tips-aanvullingen/mondriaan.html

Inderdaad heb je best wel een aantal classes nodig, maar niet zoveel als waar jij bang voor bent.  Een class is zeker niet uniek maar kan aan meerdere elementen op dezelfde pagina worden gegeven (in tegenstelling tot een ID). Je kunt zelfs meerdere classes aan een element geven (pag. 81). Dus jouw inline stijlen zijn daarmee overbodig geworden. Wat ook helpt om extra classes te vermijden zijn samengestelde kiezers. Je kunt het allemaal zien in de code van de Mondriaan die ik online heb gezet.

Je was zelf al begonnen met col-tags, dat scheelt weer een aantal classes. Verder had je al gekozen voor 4 classes voor de hoogtes, daarmee kan je heel goed alle cellen de juiste hoogtes geven.

Met de rand ben ik wel een beetje vrij omgesprongen. Uiteraard kan het zeker wel om het exact van het schilderij na te maken, maar of dat nou zoveel toevoegt? Wel meer tijd, dat is zeker. Ik denk dat als je dit snapt, wat in het voorbeeld is gedaan, dat het doel wel is bereikt.

Maten in mm had ik eigenlijk nog nooit gebruikt, lijkt wel te werken trouwens, maar wat dat precies doet is me nog niet duidelijk. Het is geen beeldschermmaat, beter px, ems of % doen.

En inderdaad, ik denk dat als je alle vlakken een ander lettertype zou willen geven, dat je dan misschien wel classes erbij moet maken.

Ik hoop dat ik je zo verder heb geholpen. Succes!
Frances

[Rashnu]

Dank je wel.

Het enige dat ik inderdaad miste was dat je wel meerdere klassen aan een element kunt geven. Daarmee is het allemaal eenvoudig op te lossen, al vind ik jouw oplossing om nogal complexe kiezers te maken voor de randen niet mooi. Wat je eigenlijk doet is in je kiezers al een opsomming te geven van op welke elementen ze moeten slaan, terwijl dit a. niet de bedoeling van deze randklassen is, en b. ze eigenlijk nog teveel elementen selecteren - kijk maar wat er gebeurt als je de border style op collapse zet, dan gaat het bij jou mis. Ik maak gewoon kale klassen voor de randen, en dan wijs ik die per element apart toe. Alleen bij de bovenkant hoef ik niet zo specifiek te zijn, daar kan ik hem al aan de rijhoogte-klasse toewijzen. (Zie de attachments.) Eigenlijk zou ik ze ook aan de kolom 1 en 7 klassen willen toewijzen, maar dat werkt helaas niet.

Ik heb voor de table de width expres op procenten gezet, zodat je het plaatje kunt uitrekken of versmallen - dat vond ik wel geinig.

Wat me opvalt is dat de verhoudingen van de kolombreedtes enigszins verschillen per browser. Vooral Opera bakt niks van de maat van de derde kolom., met name bij voorvertoning vanuit Dreamweaver.

[Frances]

Hoi Rashnu,

Inderdaad zijn er altijd meerdere manieren om het doel te bereiken. Gewoon daar waar je dat wilt een class plaatsen is ook prima. Wel is het misschien interessant om je te realiseren dat, stel je kunt niet bij de HTML-code, je dan alsnog in CSS met samengestelde kiezers veel HTML-elementen kunt vormgeven.

Wat je schrijft over randklassen, die begrijp ik niet helemaal, ook niet de border style collapse, in mijn voorbeeld heb ik border: collapse gebruikt.

Tabellen zijn lastig, cellen springen alle kanten op en breedte en/of hoogte maten lijken onbetrouwbaar: je geeft ze een breedte en desondanks (of gelukkig) rekken ze toch mee als de inhoud meer ruimte nodig heeft. En als je de tabel een breedte geeft en de kolommen niet, dan gaat iedere browser daar verschillend mee om. Dat zal zeker ook het geval zijn als je werkt met 100% breedte.

De voorvertoning van Dreamweaver is je grote vriend maar de enige echte ware is toch de browser. En helaas zijn er daar meerdere van en die zijn het niet altijd met elkaar eens :-)

Frances

[Rashnu]

Sorry, ik heb me verschreven, ik bedoelde juist wat er gebeurt als je de border-collapse op separate zet in jouw uitwerking, dan verdwijnen de randen ook bij sommige cellen die NIET aan de rand zitten, omdat jouw kiezers ook op die cellen slaan.
In mijn uitwerking met 4 extra klassen voor de randen, gebeurt dat niet. Met die extra klassen is het in de HTML ook meteen duidelijk waar die worden toegepast, terwijl dat in jouw geval echt puzzelen is om te zien wat voor effect ze hebben. Daarom had ik die border-collapse ook even op separate gezet.

Maar het is wel leerzaam om te zien hoe je m.b.v. samengestelde complexe kiezers allerlei eiegenschappen voor specifieke elementen erin kunt krijgen, en hoe een kiezer voor een element met meerdere klassen eruit ziet, want dat was ik nog niet eerder tegengekomen.

Wat ik echter niet snap is hoe het nu met die overerving precies zit. In jouw uitwerking heb je voor het wegpoetsen van de bovenrand de kiezer ".hoogtedubbel td" gebruikt met als eigenschap "border-top-style: none;". Maar de klasse hoogtedubbel is al gekoppeld aan de bovenste rij (de <tr>), dus alle elementen die daaronder vallen in de hiërarchie zouden deze eigenschap toch moeten overerven. De <tr> is toch immers de parent van de <td>  ? Waarom moet er dan toch nog "td" in de kiezer worden opgenomen? Is dat soms omdat dit iets met de border te maken heeft, die op tr-niveau nog niet is gedefinieerd, maar pas op td niveau? (Hoewel de border-collapse wel al op een nog hoger niveau (nl. op table-niveau) wordt gedefinieerd.)
En omgekeerd, als je bv. kijkt naar de rode cel rechtsonder, die wordt geraakt door de kiezer ".hoogtemiddel .rood" met als eigenschap "border-right-style: none;", dan mag je daar juist geen td aan toevoegen, anders werkt het niet en komt de rand weer terug.
Ik heb ook zitten experimenteren met mixen van separate en collapsed borders voor verschillende rijen of cellen, maar ook dat krijg ik niet voor elkaar. Blijkbaar is dit een property die alleen voor een hele tabel geldt, en niet op micro-niveau.

[Frances]

Hallo Rashnu,

Je wordt op je wenken bediend :-) Het voorbeeld dat ik je stuurde was een aanpassing van jouw tabel. Ik vond het zo fascinerend hoe je eruit was gekomen met de 4 hoogtes die je aan de tr-elementen had gegeven. Het werkte maar hoe je dat hebt uitgerekend lijkt me best wel ingewikkeld. In ieder geval, daar was ik op verder gegaan.

Maar ik vind het toch geen goede oplossing, juist omdat het zo weinig inzichtelijk is, aanpassen is lastig want je ziet niet wat je doet. Dus ik heb zojuist een nieuwe Mondriaan gemaakt voor de Mondriaan-fans, met een korte beschrijving, staat op http://www.waalweb.nl/boek/tips-aanvullingen/mondriaan.html

Ik heb in mijn voorbeeld ook de waarde van de border op 0 staan ipv op none, is betrouwbaarder.
Ik hoop dat ik verder niets ben vergeten, maar als ik het zo lees dan denk ik daarmee jouw vragen ook opgelost zijn. En als ik er een mis, letmeknow!

Frances

[Frances]

O ja, en inderdaad moet je border-collapse aan de tabel geven voor de randen van de cellen in de tabel. Dus het is alles of niets.

[Rashnu]

Dank je voor je reactie, maar de link die je erin zet geeft precies hetzelfde als je eerste poging. Exact dezelfde code. Dus daar gaat iets mis.
Ben benieuwd naar wat je dan nu hebt veranderd...

Dan hoop ik ook dat mijn vraag over overerving  daarmee opgelost wordt.

[Frances]

Krijg jij niet op http://www.waalweb.nl/boek/tips-aanvullingen/mondriaan.html een nieuwe versie? Het wordt voorafgegaan met een korte uitleg. Lijkt erop dat je je cache moet legen (pag. 75).

Overerven:  kinderen overerven de eigenschappen die zich daarvoor lenen van hun voorouders. Op pag, 128 staat een kort overzicht van eigenschappen die niet overerven. Wat betreft de eigenschappen die wél overerven: met een declaratie die dichter bij het element staat (bijv. verderop in de stylesheet) kan je een eerdere declaratie overrulen. Maar een eerdere specifieke declaratie (met bijv. kiezer p.accent) wordt niet overrulet door een latere algemene declaratie (met bijv. kiezer p).

[Rashnu]

Inderdaad, een refresh gaf me de nieuwe versie - had ik niet aan gedacht.

Je laatste uitwerking vind ik ook beter leesbaar. Ook het onderscheid dat je maakt tussen id's en klassen is verhelderend: id's voor dingen die slechts eenmaal voorkomen, en klassen voor zaken die vaker worden gebruikt. Ik had voor alles alleen maar klassen gemaakt.

Ik vind het vreemd dat je de hoogte van de rijen nu koppelt aan individuele cellen (td) en niet aan de rij als geheel (tr).
Tevens wil ik graag weten waarom je voor het wegpoetsen van de randen nu ervoor hebt gekozen om de dikte van de rand op 0 in te stellen, terwijl je in je eerste uitwerking de border gewoon uit zette mbv border-top/right/bottom/left-style: none.

Wat betreft de overerving lijkt het er toch op dat i.t.t. wat in de tabel op p.128 staat de background color wel overerft, want anders zouden de cellen in de tabel niet bij default de kleur krijgen die je op table-niveau hebt ingesteld (de #F7F7F1).

[Frances]

Misschien is het gewoon gewoonte maar bij mijn weten is het betrouwbaarder om de tabel te stylen met de td's ipv met de tr's. Ik gebruik de tr's alleen voor dat doel als het echt voordeel biedt, maar anders bij voorkeur de td's.

border: 0 is betrouwbaarder dan border: none. Ik meen dat die laatste niet werkt in IE6.

De cellen zijn standaard transparant, je ziet de achtergrondkleur van de tabel, tenminste, zo heb ik het altijd geïnterpreteerd. Misschien komt dat op hetzelfde neer als dat de achtergrondkleur overerft, alleen zou dat dan hier een uitzondering zijn want standaard overerft die niet. Daarom waarschijnlijk mijn voorkeur voor de eerste verklaring.