Verborgen HTML-elementen laten spatie achter

[Thrilled]

Hallo,

Ik heb een probleempje met loze ruimtes in een html tabel. Het is een tabel met 3 td's erin, in de linkse (1e) zit een vragen-structuur, in de middelste (2e) zit nog even niks, en in de rechtse (3e) zitten 5 verborgen vervolg-vraagstructuren. In de linkse vraagstructuur worden vragen gesteld die uit kunnen komen op 1 van de 5 vervolg vraag structuren, die zich dan openen in de meest rechtse td. Nu wil alleen de 1e zich helemaal boven aan de tabel zetten. De 4 anderen laten steeds een klein beetje ruimte boven zich open, vermoedelijk omdat hier die verborgen structuren zitten. De 2e laat 1 regeltje open (waar de 1e zou moeten zitten), de 3e laat 2 regels open (waar de 1e en 2e zitten) en zo verder..

Alleen er zijn nergens concrete ruimtes gedefinieerd, elke tabel heeft een vertical align top in de css mee gekregen, dus ik ben erg benieuwd hoe ik ze toch allemaal naar boven kan schoppen.

elk verborgen vervolg structuur is als volgt opgemaakt:

code:

<tr>
 <td> vraag </td>
</tr>
<tr>
 <td> antwoord ja </td>
 <td> antwoord nee </td>
</tr>

meer zit er niet in. Bovenaan start ik de <table> tag die dus altijd gedefinieerd is, en vanaf dan begin ik ze te verstoppen. Iemand tips en/of suggesties?

[Mad Marty]

CSS? Online voorbeeld? Ik denk dat er toch íets meer informatie, vooral over je script, nodig is!

[FireMotion]

Probeer anders in ieder geval border=1 in je table tag te gebruiken in de table, dan kan je controleren wat er gebeurt met de ruimtes (margins, padding, whitespacing).

[Verwijderd]

Volgens mij klopt je html sowieso niet. Je hebt in 1 row 1 TD en de volgende 2 TD's. Ofwel je zal colspan's moeten gebruiken. Anders dan dat raad ik je aan de webdev extention van firefox te gebruiken. Hiermee kan je tabellen 'outlinen' zodat je ziet hoe ze opgebouwd worden.

Overigens lijkt me dat dit soort vraag/antwoord pagina's beter in een script taal gedaan kunnen worden (ASP/PHP/Javascript whatever makes you happy)

[Thrilled]

@Mad Marty: Het is allemaal lokaal en mn script is 50kb groot (vrij lang voor een kladblok bestandje)

@FireMotion: als ik de borders op 1 zet, zie ik gewoon de lege tables waarin (op aanvraag) de nieuwe vervolg vragen worden gesteld. En door simpele lettertjes her en der in mn script te zetten kom ik wel boven en onder die lege tabelletjes, maar niet er in, dus de lege ruimtes staan niet ergens getypt.. ik ga even met mijn padding / margins kloten..

[Thrilled]

Verwijderd schreef op vrijdag 08 februari 2008 @ 10:10:
Volgens mij klopt je html sowieso niet. Je hebt in 1 row 1 TD en de volgende 2 TD's. Ofwel je zal colspan's moeten gebruiken. Anders dan dat raad ik je aan de webdev extention van firefox te gebruiken. Hiermee kan je tabellen 'outlinen' zodat je ziet hoe ze opgebouwd worden.

Overigens lijkt me dat dit soort vraag/antwoord pagina's beter in een script taal gedaan kunnen worden (ASP/PHP/Javascript whatever makes you happy)

Is inderdaad logischer, maar omdat het in een netwerk lokaal gebruikt moet worden, kan er niks met server-side taal gedaan worden.

En die html tags in mn startpost was even een snel voorbeeld, in mn script staan ze wel met colspan..

code:

<tr>
   <td class="question" colspan="3">Vraag</td>
</tr>

<tr>
   <td class="answeryes"><input type="radio" name="vraag1" value="Vraag 1: Ja" rel="vraag2" id="vraag1ja" /> <label for="vraag1ja">Ja</label></td>
   <td class="empty"> &nbsp; </td>
   <td class="answerno"><input type="radio" name="vraag1" value="Vraag 1: Nee" rel="vraag3" id="vraag1nee" /> <label for="vraag1nee">Nee</label></td>
</tr>

Dit zit dus in de linker kolom bijvoorbeeld. Zodra men op antwoord 1 nee klikt, opent hij vraag 3 in het rechter venster. Zo zijn er meerdere vragen, met links naar andere vragen.

[RM-rf]

Ik vermoed dat je keuze een tabel te gebruiken hier duidelijk meespeelt bij de visuele problemen:

qua rendering kan de render-engine namelijk niet zomaar elementen binnen de tabel 'negeren' maar worden deze altijd meegenomen in het renderen van de tabel..
tabel-elementen hebben dan ook een eigen specifieke 'display'...

W3C raad zelf aan om gebruik te maken van de CSS2-waarde 'visibility: collapse' voor het verstoppen van Table-elementen:
http://www.w3.org/TR/REC-CSS2/tables.html#dynamic-effects

Ik weet niet zeker of dit ook door alle browser juist weergegeven wordt... (msie kan nog wel een probleem geven bij zulke, minder bekende CSS2 toepassingen)

andere oplossing kunnen eventueel het gebruik van 'border-collapse: collapse' zijn (een 'vieze' oplossing en eigenlijk niet aan te raden)
Of juist te kiezen voor onderling niet gerelateerde DIVs

[Thrilled]

RM-rf schreef op vrijdag 08 februari 2008 @ 10:49:
Ik vermoed dat je keuze een tabel te gebruiken hier duidelijk meespeelt bij de visuele problemen:

qua rendering kan de render-engine namelijk niet zomaar elementen binnen de tabel 'negeren' maar worden deze altijd meegenomen in het renderen van de tabel..
tabel-elementen hebben dan ook een eigen specifieke 'display'...

W3C raad zelf aan om gebruik te maken van de CSS2-waarde 'visibility: collapse' voor het verstoppen van Table-elementen:
http://www.w3.org/TR/REC-CSS2/tables.html#dynamic-effects

Ik weet niet zeker of dit ook door alle browser juist weergegeven wordt... (msie kan nog wel een probleem geven bij zulke, minder bekende CSS2 toepassingen)

andere oplossing kunnen eventueel het gebruik van 'border-collapse: collapse' zijn (een 'vieze' oplossing en eigenlijk niet aan te raden)
Of juist te kiezen voor onderling niet gerelateerde DIVs

Ik zit dus wel vast aan IE, is de enige geinstalleerde browser op elke pc hier in dit bedrijf dus CSS2 lijkt me geen optie. Hoe zit het bij div's met de 'rel'-tag? Want nu kijkt hij naar de 'rel' welk tabelletje hij omhoog moet schoppen voor de volgende vraag. Wordt een flinke klus als ik alles moet vervangen door div's btw

[RM-rf]

Thrilled schreef op vrijdag 08 februari 2008 @ 10:57:


Ik zit dus wel vast aan IE, is de enige geinstalleerde browser op elke pc hier in dit bedrijf dus CSS2 lijkt me geen optie. Hoe zit het bij div's met de 'rel'-tag? Want nu kijkt hij naar de 'rel' welk tabelletje hij omhoog moet schoppen voor de volgende vraag. Wordt een flinke klus als ik alles moet vervangen door div's btw

Wat bedoel je met 'rel-tag'?

er bestaat in HTML geen REL-tag, wel een rel-attribuut, dat echter enkel toegestaan is in LINK en A-elementen (als om een specifieke definitie aan bepaalde gelinkede documenten of sectoren te geven)..

[Thrilled]

RM-rf schreef op vrijdag 08 februari 2008 @ 11:36:
[...]


Wat bedoel je met 'rel-tag'?

er bestaat in HTML geen REL-tag, wel een rel-attribuut, dat echter enkel toegestaan is in LINK en A-elementen (als om een specifieke definitie aan bepaalde gelinkede documenten of sectoren te geven)..

zie mijn post met het stukje code Dit is een manier om in html-only, elementen uit een html formulier op voorhand te verbergen, en pas op te roepen zodra er een bepaald antwoord op een bepaalde vraag komt. Een soort cheaten omdat je anders met php if else structuren moet gaan werken.

vraag 1 antwoord A leid naar vraag 2, antwoord B leid naar vraag 3.. vraag 2 A leid naar vraag 4, B leid naar 5, terwijl antwoord A op vraag 3 leid naar vraag 6, en B naar 7.

Ingewikkeld om uit te leggen, ingewikkelder om op te zetten in html. Als de directie brood in dit systeem ziet, word er geld uitgegeven om aparte servers hiervoor aan te schaffen en dergelijke.. dus nu roeien met de (lokale) riemen die ik heb en alles zo 'simpel' en client-side mogelijk houden

[RM-rf]

je kiest dan zelf voor een niet valide toepassing van een bepaald attribuut ... dat hoeft niet verkeerd te zijn maar heeft verder geen enkele relatie tot je keuze een DIV te gebruiken of een TABLE.

de rel-attribuut is in beide gevallen niet valide maar toe te pasen, zolang je clientside script er maar rekening mee houd..

Overigens: ik vermoed zelf dat het best mogelijk is gewoon op een valide wijze door je HTML structuur onderlinge rletaies weer te geven, zolang er tenminste geen sprake is van tweezijdige of dubbele relaties (wat volgens mij ook niet mogelijk is met je oplossing om een attribuut daarvoor te gebruiken, aangenomen dat die ook altijd slechts één waarde kan bevatten):
gewoonweg door gebruik te maken van UL's en deze weer binnen de List-items te nesten..

Mij lijkt het 'nesten' van elementen die moeten verschijnen na het selecteren van een bepaalde optie een veel handigere manier: als het ware een soort van tree-menu-opzet.

[Thrilled]

RM-rf schreef op vrijdag 08 februari 2008 @ 13:35:
je kiest dan zelf voor een niet valide toepassing van een bepaald attribuut ... dat hoeft niet verkeerd te zijn maar heeft verder geen enkele relatie tot je keuze een DIV te gebruiken of een TABLE.

de rel-attribuut is in beide gevallen niet valide maar toe te pasen, zolang je clientside script er maar rekening mee houd..

Overigens: ik vermoed zelf dat het best mogelijk is gewoon op een valide wijze door je HTML structuur onderlinge rletaies weer te geven, zolang er tenminste geen sprake is van tweezijdige of dubbele relaties (wat volgens mij ook niet mogelijk is met je oplossing om een attribuut daarvoor te gebruiken, aangenomen dat die ook altijd slechts één waarde kan bevatten):
gewoonweg door gebruik te maken van UL's en deze weer binnen de List-items te nesten..

Mij lijkt het 'nesten' van elementen die moeten verschijnen na het selecteren van een bepaalde optie een veel handigere manier: als het ware een soort van tree-menu-opzet.

even voor de beeldvorming, het zijn 45 vragen, 90 antwoorden (45 x ja, 45 x nee), en een kleine 25 conclusies.

Elke vraag, elk antwoord, elke conclusie staat weer in een aparte TD, en klaar om opgeroepen te worden. Ik denk dat mn huidige systeem vele malen overzichtelijker is dan wanneer ik alles in unsorted lists ga plaatsen. Daarnaast krijg je een ul nooit mooi vormgegeven als in tabellen. In een ul moet dan de vraag + gelijk 2 antwoorden zichtbaar zijn he, terwijl een ul maar 1 regel is (tenzij je met regels gaat breken).. volgens mij een veel omslachtigere manier.

[equationunequal]

Thrilled schreef op vrijdag 08 februari 2008 @ 13:59:
Elke vraag, elk antwoord, elke conclusie staat weer in een aparte TD, en klaar om opgeroepen te worden. Ik denk dat mn huidige systeem vele malen overzichtelijker is dan wanneer ik alles in unsorted lists ga plaatsen. Daarnaast krijg je een ul nooit mooi vormgegeven als in tabellen. In een ul moet dan de vraag + gelijk 2 antwoorden zichtbaar zijn he, terwijl een ul maar 1 regel is (tenzij je met regels gaat breken).. volgens mij een veel omslachtigere manier.

code:

<dl>
<dt>Vraag...</dt>
<dd>Antwoord 1...</dd>
<dd>Antwoord 2...</dd>
</dl>

[ Voor 3% gewijzigd door equationunequal op 08-02-2008 14:26 ]

[RM-rf]

Thrilled schreef op vrijdag 08 februari 2008 @ 13:59:

Daarnaast krijg je een ul nooit mooi vormgegeven als in tabellen. In een ul moet dan de vraag + gelijk 2 antwoorden zichtbaar zijn he, terwijl een ul maar 1 regel is (tenzij je met regels gaat breken).. volgens mij een veel omslachtigere manier.

Ik begrijp niet wat je hier mee bedoelt ...
ben je ervan op de hoogte dat via CSS de hele visuele vormgeving te sturen is, en er vrijwel geen legitieme 'visuele presentatie'-argumenten geldig zijn om te kiezen voor een bepaalde Tag-structuur?
uitzondering daarop is dat je wel soms uit presentatie-overweging onderscheid wil maken tussen bepalde elementen-groepen; waarbij het indelen in 'divisies' dmv Div-tags meestal de handigste oplossing zal zijn

wel is het handig om een Tag-structuur zo te kiezen dat onderlinge relaties tussen elementen goed weergegeven worden.

Ik krijg de indruk dat je nogal de visuele presentatie verward met de gebruiks- en informatieve waarde
van de elementen op je pagina; probeer wat meer abstract te denken