CSS en positionering

[-FoX-]

Ik heb een definitionlist die ik wil stylen; en de html code ziet er ongeveer zo uit:

HTML:

<style type="text/css">
dl {
        width: 250px;
        border: 1px solid black;
        background-color: #FFFFCC;
}
dt {
        line-height: 20px;
}
dd {
        position: relative;
        float: left;
        left: 10px;
        margin-left: 1em;
        border: 1px solid red;
        overflow: hidden;
        background: white;
        top: -20px;
}
</style>
<dl>
  <a href="#"><dt>A</dt></a>
  <a href="#"><dd style="height: 20px;">A</dd></a>
  <a href="#"><dt>B</dt></a>
  <a href="#"><dd style="height: 20px;">B</dd></a>
  <a href="#"><dd style="height: 30px;">B</dd></a>
  <a href="#"><dt>C</dt></a>
  <a href="#"><dd style="height: 20px;">C</dd></a>
  <a href="#"><dd style="height: 20px;">C</dd></a>
  <a href="#"><dd style="height: 20px;">C</dd></a>
  <a href="#"><dd style="height: 20px;">C</dd></a>
</dl>

De DDs zullen uiteindelijk blokken vormen, die gepositioneerd zullen moeten worden bij bijhorende DTs.
Ik heb de dd een relatieve positie gegeven zodat ik deze left kan floaten, en ze dus mooi in een queue achter elkaar komen te staan. Dat werkt allemaal vrij goed. Het enige probleem is dat de DT values bij meerdere blocken ook met hetzeldfe interval mee verschuiven.

Ik heb dus een aantal probleempjes met deze opmaak:
1. De rij-titels schuiven mee op. Zoals je ziet staat titel B al niet meer onder A.
2. Ik moet nu expliciet "top: -20px;" erbij plaatsen, anders beginnen alle elementen 20px te laag.
3. Indien de DL niet groot genoeg is om de elementen te positioneren, komen deze er gewoon op de volgende rij bij. Is het niet mogelijk om deze op een of andere manier zoals overflow:hidden te behandelen?

Enig idee hoe dit op een elegante manier opgelost kan worden?

[BalusC]

Ik heb jouw code letterlijk gecopypasted in een leeg HTML pagina.

FF:


IE:


Ik snap eigenlijk niet wát je precies wilt bereiken. Het resultaat is een beetje in de strijd met jouw tekst Kun je het niet op een of andere manier grafisch weergeven? Kladje/tabelletje/betere test-CSS ofzo. Dan kunnen we je wellicht beter helpen

[ Voor 5% gewijzigd door BalusC op 28-08-2006 21:36 ]

[LionOne]

Het is mij ook niet helemaal duidelijk wat je bedoeld maar ik vermoed dat je dit als eindresultaat wilt?


In dat geval, hier de code:

Cascading Stylesheet:

dl {
    float:left;
    width: 250px;
    border: 1px solid black;
    background-color: #FFFFCC;
}
dt {
    float:left;
    line-height:20px;
    clear:both;
}
dd {
    float:left;
    margin-left:1em;
    border: 1px solid red;
    background: white;
    height:20px;
}

HTML:

<dl> 
    <dt><a href="#">A</a></dt>
        <dd><a href="#">A</a></dd>
    
    <dt><a href="#">B</a></dt>
        <dd><a href="#">B</a></dd>
        <dd><a href="#">B</a></dd>
    
    <dt><a href="#">C</a></dt>
        <dd><a href="#">C</a></dd>
        <dd><a href="#">C</a></dd>
        <dd><a href="#">C</a></dd>
        <dd><a href="#">C</a></dd>
</dl>

Ik heb het alleen in Opera getest, het kan dus best zijn dat ff of ie het anders weergeven.

[-FoX-]

Hier wil ik eigenlijk naartoe:


Dus, de rij-headers (A, B en C), dienen verticaal onder elkaar te staan, met een gelijke spacing. Dus een gelijke rij-hoogte voor ieder item. Zoals in het voorbeeld van BalusC schuiven deze rij aanduidingen mee op, en floaten ze dus mee naar rechts.

Het is de bedoeling dat de items automatisch uitgelijnd worden ten opzichte van elkaar. Een B-item is bijvoorbeeld dubbel zo hoog als andere items. De C-items moeten dus plaats maken voor dit B-item.

Een laatste probleem is dat als er nog meerdere C items zouden bijkomen, dat deze dan op de volgende lijn beginnen. Ik heb liever dat ze allemaal achteraan worden bijgeplakt bij een overflow.

Momenteel moet ik een expliciete top: -20px toevoegen als ik wil dat de items bovenaan starten, niet direct een probleem al weet ik niet precies waarom?

Ik hoop dat het nu een beetje duidelijk is, van wat de bedoeling is...

[BalusC]

LionOne schreef op maandag 28 augustus 2006 @ 23:23:
Ik heb het alleen in Opera getest, het kan dus best zijn dat ff of ie het anders weergeven.

FF = OK en IE = ramp

-FoX- schreef op dinsdag 29 augustus 2006 @ 09:39:
Hier wil ik eigenlijk naartoe:
[afbeelding]

Ik zou eerder div's of tabellen gebruiken, afhankelijk van het soort data. Dit is niet mogelijk met definition lists en volgens mij ook niet het doel daarvan.

[-FoX-]

BalusC schreef op dinsdag 29 augustus 2006 @ 12:43:
Ik zou eerder div's of tabellen gebruiken, afhankelijk van het soort data. Dit is niet mogelijk met definition lists en volgens mij ook niet het doel daarvan.

Een dd is toch gewoon evengoed een container als een div; dus in principe kan het allebei met css positionering opgelost worden, of waar zit het verschil dan?

Het is gemakkelijk om te zeggen gebruik dit of dat, maar in de praktijk zijn er altijd nadelen verbonden die op het eerste zicht niet duidelijk zijn. Dus als je het kan aantonen dat een manier beter is dan de andere, geloof ik je.. anders niet

[Blue-eagle]

Wat voor data ga je er in plaatsen? Tabulaire data moet kan gewoon in een tabel namelijk. En een DL is een definition list, als je er geen definities in gaat uitleggen of iets dergelijks is het misschien, semantisch gezien, handiger om een divje te pakken.

Het ziet er namelijk gewoon uit als een simpel tabelletje

[-FoX-]

Het zal voornamelijk gaan om kalendar data; datums waaraan iets gekoppeld wordt dus. View voor een planning systeem. Er zijn tig mogelijkheden om dergelijke view te realiseren. Maar ik had het graag in deze vorm gehad, Een DIV in tabulaire data plaatsen is een optie natuurlijk; en dan eventueel werken met de Z-index, om ze uit de cellen te laten breken?

[iworx]

1) Dat wat je wil kan helemaal niet.
2) De block gaat C altijd verder duwen dan B.
3) Bij 1 DT hoort 1 DD en niet meer -- Definition Term & Definition Descriptor
4) Probeer je CSS dynamisch op de bouwen aan de hand van reele sizes en absolute positionering als je het echt zo wil doen - class of ID toevoegen aan elke block.

[ Voor 11% gewijzigd door iworx op 29-08-2006 14:32 ]

[-FoX-]

dot.K schreef op dinsdag 29 augustus 2006 @ 14:31:
1) Dat wat je wil kan helemaal niet.
2) De block gaat C altijd verder duwen dan B.
3) Bij 1 DT hoort 1 DD en niet meer -- Definition Term & Definition Descriptor
4) Probeer je CSS dynamisch op de bouwen aan de hand van reele sizes en absolute positionering als je het echt zo wil doen - class of ID toevoegen aan elke block.

1) Ben ik niet zo zeker van... maar het zal zo wel zijn, till proved otherwise
2) Zie 1
3) Je hebt gelijk
4) Que?

Op welke manier is het dan wel "goed"?
Voor een tabel dien je ook altijd te weten hoeveel kolommen er gaan zijn, dit wil ik juist vermijden. Eén van die redenen is performance ttz de applicatie die deze layout zal genereren dient eerst een aantal berekeningen te maken alvorens de content te kunnen genereren. Dit wil ik niet, omdat dit een onnodige performance penalty op zal leveren. Waarom het niet door de layout laten afhandelen als dit kan?

[-FoX-]

Ik heb er nog eens goed over nagedacht, maar het is trouwens wel makkelijk gezegd dat een DL hier niet geschikt voor is. Op welke manier kan een andere container (vb table) hier dan beter mee omgaan, als het louter om de styling/positioning gaat?

[BalusC]

Met een table kun je rowspans gebruiken om de rijen van een kolom te mergen, precies zoals je wilde doen met de tweede B. Anders moet je de zooi absoluut positioneren en dimensies opgeven, wat imo viezer is.

edit:

Ik heb toch maar even gespeeld. Voldoet dit?

HTML:

<style>
dl {
    float: left;
    clear: left;
    margin: 5px;
    padding: 0px;
}
dt {
    float: left;
    margin: 0px;
    padding: 0px;
    width: 20px;
    height: 20px;
}
dd {
    float: left;
    margin: 0px 0px 0px 10px;
    padding: 0px;
    width: 20px;
    height: 20px;
}
dd a {
    display: block;
    margin: 0px;
    padding: 0px;
    border: 1px solid red;
    background: white;
    width: 20px;
    height: 20px;
}
</style>

<dl> 
    <dt><a href="#">A</a></dt>
    <dd><a href="#">A</a></dd>
</dl>
<dl> 
    <dt><a href="#">B</a></dt>
    <dd><a href="#">B</a></dd>
    <dd><a href="#" style="position: absolute; height: 50px;">B</a></dd>
</dl>
<dl> 
    <dt><a href="#">C</a></dt>
    <dd><a href="#">C</a></dd>
    <dd style="margin-left: 40px;"><a href="#">C</a></dd>
    <dd><a href="#">C</a></dd>
    <dd><a href="#">C</a></dd>
</dl>

[ Voor 85% gewijzigd door BalusC op 30-08-2006 11:40 ]

[-FoX-]

Niet helemaal, want je moet nu nog steeds (handmatig) bepalen, wanneer een element moet inspringen om plaats te maken voor een ander element. Een C element geef je nu een bepaalde margin om ervoor te zorgen dat hij juist inspringt.

Dit wil ik niet; een C element moet automatisch ruimte maken voor een ander element als deze elkaar dreigen te overlappen.

[BalusC]

een C element moet automatisch ruimte maken voor een ander element als deze elkaar dreigen te overlappen

Dat kan dus niet met lists.

want je moet nu nog steeds (handmatig) bepalen

Klop je de code zelf in of laat je het genereren? Indien het laatste, dan lijkt het me een klein klusje om het te inbouwen?

[ Voor 39% gewijzigd door BalusC op 30-08-2006 11:52 ]

[-FoX-]

BalusC schreef op woensdag 30 augustus 2006 @ 11:52:
Dat kan dus niet met lists.

Ok, hoe dan wel?

Klop je de code zelf in of laat je het genereren? Indien het laatste, dan lijkt het me een klein klusje om het te inbouwen?

De code wordt gegenereerd door een eigen custom-tag (java/j2ee).

[disjfa]

-FoX- schreef op woensdag 30 augustus 2006 @ 12:03:
[...]
Ok, hoe dan wel?

BalusC schreef op woensdag 30 augustus 2006 @ 11:11:
Met een table kun je rowspans gebruiken om de rijen van een kolom te mergen, precies zoals je wilde doen met de tweede B. Anders moet je de zooi absoluut positioneren en dimensies opgeven, wat imo viezer is.

^^ Je HOEFT niet alles in divjes en andere hokjes te plaatsen. Tabellen bestaan altijd nog.

[BalusC]

-FoX- schreef op woensdag 30 augustus 2006 @ 12:03:
De code wordt gegenereerd door een eigen custom-tag (java/j2ee).

Dan is het toch kleine moeite? Mits de customtag een slimme code heeft dat lijsten van DTO's accepteert en itereert (beetje datatable lookalike) en de DTO is voorzien van een corresponderend veld.

[ Voor 5% gewijzigd door BalusC op 30-08-2006 12:37 ]

[-FoX-]

disjfa schreef op woensdag 30 augustus 2006 @ 12:05:
^^ Je HOEFT niet alles in divjes en andere hokjes te plaatsen. Tabellen bestaan altijd nog.

Bananen bestaan ook nog altijd... so?

BalusC schreef op woensdag 30 augustus 2006 @ 12:34:
Dan is het toch kleine moeite? Mits de customtag een slimme code heeft dat lijsten van DTO's accepteert en itereert (beetje datatable lookalike) en de DTO is voorzien van een corresponderend veld.

Dat gebeurd nu ook, en dat gaat allemaal goed. Het gaat om afspraken die gepositioneerd moeten worden bij een bepaald startuur; maar iedere afspraak kan een variabele lengte hebben. Het geeft teveel performance overhead als ik alle afspraken eerst afzonderlijk moet gaan positioneren (+ ik moet ook weten hoeveel kolommen er zullen zijn).. en dit hoeft allemaal niet als je de DIVs/DDs/Whatevers gewoon tov elkaar laat floaten, zodat ze zich automatisch goed positioneren adhv een startuur en hoogte.

[BalusC]

Dat kan dus niet

Over de customtag: dat hoeft echt geen enorme overhead te zijn als je het slim aanpakt. Zolang de aangeleverde lijst maar volledig is.

[-FoX-]

Dat kan niet? Tot dusver heb ik het anders wel redelijk voor elkaar.. Enig nadeel is dat de rij-aanduidingen verspringen en bij een overflow aan kolommen de elementen op de volgende lijn beginnen. Beide zijn niet onoverkomelijk..
Enerzijds kan het opgelost worden door de rij-aanduidingen apart te 'renderen', het 2de probleem kan opgelost worden door niet meer dan X entries per rij toe te laten.

Het is meer overhead dan je denkt. Eerst moet je het startuur bepalen van het geïtereerde element, zodat je weet in welke kolom je deze moet plaatsen; dan moet je de hoogte bepalen. Het meest overhead geeft het bepalen van de kolom. Want je moet iedere kolom nog eens apart itereren om te zien of het element erin kan passen.

[BalusC]

-FoX- schreef op woensdag 30 augustus 2006 @ 13:19:
Dat kan niet? Tot dusver heb ik het anders wel redelijk voor elkaar.. Enig nadeel is dat de rij-aanduidingen verspringen en bij een overflow aan kolommen de elementen op de volgende lijn beginnen. Beide zijn niet onoverkomelijk..
Enerzijds kan het opgelost worden door de rij-aanduidingen apart te 'renderen', het 2de probleem kan opgelost worden door niet meer dan X entries per rij toe te laten.

Hiermee wordt het overlap/doordruk probleem niet opgelost en dat is toch waar het allemaal om draait.

Het is meer overhead dan je denkt. Eerst moet je het startuur bepalen van het geïtereerde element, zodat je weet in welke kolom je deze moet plaatsen; dan moet je de hoogte bepalen. Het meest overhead geeft het bepalen van de kolom. Want je moet iedere kolom nog eens apart itereren om te zien of het element erin kan passen.

Hou tijdens het itereren de dimensies van de list bij, dan kun je het direct toepassen op de nog te itereren of reeds geitereerde elementen.

[iworx]

Misschien ff terzijde -- neem een Google Calendar account, bekijk de source en de bijhorende CSS eens. Denk dat je dan veel sneller vooruit gaat.

[-FoX-]

BalusC schreef op woensdag 30 augustus 2006 @ 13:39:
Hou tijdens het itereren de dimensies van de list bij, dan kun je het direct toepassen op de nog te itereren of reeds geitereerde elementen.

Kan je hier wat dieper op ingaan? Ik begrijp niet helemaal wat je bedoelt..

Ik krijg 1 list terug met daarin een aantal DTOs. Deze bevatten een start- en einduur. Deze kunnen gesorteerd worden op startuur. Op welke wijze kan ik snel achterhalen of een positie nog vrij is in een bepaalde kolom?

[BalusC]

Dit valt onder PRG Maar goed, basic example:

Java:

for (int i = 0; i < myDtoList.size(); i++) {
    MyDto myCurrentDto = (MyDto) myDtoList.get(i);
    MyDto myNextDto = (MyDto) myDtoList.get(i + 1);
}

Hier kun je wel verder op uitbouwen.

[-FoX-]

BalusC schreef op donderdag 31 augustus 2006 @ 12:35:
Dit valt onder PRG Maar goed, basic example:

Java:

for (int i = 0; i < myDtoList.size(); i++) {
    MyDto myCurrentDto = (MyDto) myDtoList.get(i);
    MyDto myNextDto = (MyDto) myDtoList.get(i + 1);
}

Hier kun je wel verder op uitbouwen.

Tomato, tomatto.. :-) all the same..

maar ik weet nog altijd niet wat je hiermee wil aantonen.
Is ansich een erg basic for lusje

[BalusC]

Ik wilde hiermee aantonen hoe je direct de volgende entry/entries kunt opvragen, zodat je daarna de tijden daarvan kunt opvragen om te kijken of er nog ruimte vrij is. Ook kun je direct de waarden van de volgende entry/entries aanpassen waar nodig. Dat was toch de bedoeling?

[-FoX-]

Nee, het is de bedoeling dat ik de afspraken ga positioneren. Ik weet hun start/eind tijd en kan adh daarvan de startpositie en hoogte van het element bepalen. In welke kolom deze geplaatst moet worden, dient nog altijd berekend te worden. Hiervoor moet ik dus de reeds gespecifieerde afspraken nog altijd bijhouden in een Map oid.

Stel ik heb 4 afspraken die gepositioneerd moeten worden (ik druk het even uit in minuten):

code:

[0, 15]
[0, 30]
[30, 60]
[15, 60]

Zo ziet het er dan ongeveer uit:

code:

          1      2     3     4     5
0        ===    ===
15              ===   ===
30       ===          ===
45       ===          ===
60

Stel, ik wil element [15, 30] gaan inserteren; dan moet ik dus eerst nagaan of er in kolom1 plaats is voor dit element (dit is het geval hier, dus mooi..). Maar indien dit niet het geval zou zijn, dien ik eerst alle overige kolommen te checken op beschikbare ruimte. Dit kan een performance penalty opleveren bij grote resultaten.

Ik moet dus op een heel effectieve manier kunnen inschatten in welke kolom de plaats is voor een bepaald element.

[BalusC]

Ah, álle overige kolommen. Ik zou maar gewoon een andere map bijhouden met alle vrije ruimtes erin.