[JS/DHTML] Tekst in kolommen, client-side

[Verwijderd]

Ik heb geen script probleem, maar ik ben benieuwd naar een mening. Het zit er aan te komen in CSS3 dat teksten automatisch in kolommen geplaatst kunnen worden (wat Word al eeuwen kan), maar een site als http://www.iht.com heeft het bijvoorbeeld al wel, middels heel gecompliceerde scripts. Ik heb een wat simpelere geschreven met wat beperktere mogelijkheden. Je hebt twee onzichtbare DIV kolommen en zet alle childnodes in de rechter kolom. Vervolgens kopieer je het spul een voor een terug in de linker kolom totdat de rechter net minder lang is dan de linker. En als laatste plop je het geheel in een twee nieuwe DIVs of tabellen zodat het zichtbaar wordt. Het is het zo simpel dat ik me afvraag waarom er niet meer gebruik gemaakt wordt van dergelijke methodes. Het heeft veel voordelen: Het is efficienter qua beeldschermgebruik; Je hoeft niet eindeloos te scrollen; Het is makkelijker om het begin van de volgende zin te vinden. Wat is jullie mening? Het scriptje staat hier.

[Rowanov]

Even ter info, volgens mij had Nexxennium ook iets in die geest gemaakt. Kan je het misschien even mee vergelijken als je benieuwd bent naar de methode

Edit: link uit zijn sig: http://randysimons.com/pagina_129_NL.xhtml

[ Voor 17% gewijzigd door Rowanov op 26-03-2006 18:22 ]

[RobIII]

offtopic:
Niet voor het één of ander maarre:

Is het de bedoeling dat het zo onleesbaar is?

Verwijderd schreef op zondag 26 maart 2006 @ 18:48:
@Robill: Oeps. Euh, is in aanbouw .

Mijn naam is RobIII met 3x een hoofdletter i (Ook wel een romeinse 3 )

[ Voor 54% gewijzigd door RobIII op 26-03-2006 18:57 ]

[Verwijderd]

@rowanov: Bedankt voor de link! Ik had 'm niet gevonden met de search. Dit script werkt ook met verplaatsen van childnodes, het is alleen veel geavanceerder. Kan ik mijn script bij het vuilnis kieperen.

Blijft de vraag waarom het zo weinig gebruikt wordt. Te moeilijk? Niet echt nodig?

@Robill: Oeps. Euh, is in aanbouw .

[Rowanov]

Ik vind het bij een hele hoop dingen niet echt nodig, alhoewel ik me kan voorstellen dat een krant het leuk vindt of zo. Daarnaast vind ik het uit het gebruikers oogpunt irritant dat als ik een tekst lees, ik omhoog moet scrollen voor de volgende kolom. Het lijkt me in zekere zin wel een toepasbaar iets, zolang het maar binnen het browser venster blijft.

[BasieP]

Rowanov schreef op zondag 26 maart 2006 @ 18:22:
Edit: link uit zijn sig: http://randysimons.com/pagina_129_NL.xhtml

en op de site staat:
'a low end javascript css1 example etc..'

maar ondertussen kan ik niet zonder schokken die site scrollen.. kortom: niet low end

[Verwijderd]

Omdat het nog niet ter sprake is gekomen: het originele design en script van iht.com is van John Weir. Op zijn website www.smokinggun.com kon je vroeger een meer algemene versie van dit script terugvinden maar nu niet meer. Misschien met Google of the WaybackMachine?

Het script op IHT werkte vroeger zonder al die ads eromheen trouwens een stuk beter, vind ik.

BasieP schreef op zondag 26 maart 2006 @ 20:48:
maar ondertussen kan ik niet zonder schokken die site scrollen.. kortom: niet low end

Dat komt omdat de background image fixed is.

[ Voor 25% gewijzigd door Verwijderd op 26-03-2006 21:50 ]

[Verwijderd]

@basieP: Ja, niet echt low-end, kwam ik later ook achter. Bij mij hapert hij bij een window resize. Maar er kan een hoop uit het script weggelaten worden, als je met wat simpelers genoegen neemt (max. 2 kolommen bijvoorbeeld), dus je kan het wel low-end maken.

edit: Hij hapert ook bij deze voorbeeldpagina, waar geen background image in zit, dus daar ligt het niet (alleen) aan.

Het argument dat je weer naar boven moet scrollen om verder te scrollen is makkelijk op te lossen door de kolommen niet te hoog te maken; zie iht.com.

Ik heb dus nog niet echt een verklaring. Misschien dat website designers gewoon meer op graphics gefocused zijn. Jammer en ongelooflijk inefficient. Deze forumtekst is best breed bijvoorbeeld, 15 cm op mijn schermresolutie. Een normale krantenkolom is 4 a 5 cm. Ik heb even gekeken in mijn boekenkast: de grootste tekstbreedte die ik kon vinden was 12 cm, maar meestal is het iets van 8 cm. Mijn scherm is 33 cm breed, dus je gooit ook nog eens meer dan 50% weg.

[ Voor 11% gewijzigd door Verwijderd op 27-03-2006 11:24 ]

[Fuzzillogic]

BasieP schreef op zondag 26 maart 2006 @ 20:48:
[...]

en op de site staat:
'a low end javascript css1 example etc..'

maar ondertussen kan ik niet zonder schokken die site scrollen.. kortom: niet low end

Dat schokken heeft met mijn voorliefde voor alpha blended PNG's te maken, en helemaal niets met het multi-column script _{En Opera is er een stuk sneller mee dan Firefox.}

Het 'haperen' bij resizen is by design: er zit een timeout op. Pas als er 500ms niet geresizet is wordt het script opnieuw uitgevoerd. Je kunt die tijd veel korter zetten, desgewenst.

En waarom multi-column niet meer gebruikt wordt? Sja.. Geen CSS3-support in de browsers, en de bestaande scripts zijn behoorlijk beperkt. Designers moeten opeens met "fluid" designs gaan rekening houden. Mijn ervaring is dat ze die mogelijkheid helemaal niet kennen . Het vereist ook extra inspanning, dus is het duurder, dus wordt het niet gebruikt.
De reden waarom dit script (nog) niet gebruikt wordt, is waarschijnlijk omdat het erg nieuw is

Er zijn ook andere nadelen: als je veel tekst hebt die niet in 1x op je scherm past, dan scroll je nog regelmatig op en neer. Of dat nou zo'n probleem is, is wellicht subjectief. De Herald Tribune heeft, zoals je al vemeldde, dat anders opgelost: automatische paginering van de content. Dat concept valt vast te combineren met mijn script.
En zoals op mijn site reeds vermeld is, is het printen nog een probleem. Dat is overigens wel op te lossen.

Het script kan op punten verbeterd worden. Helaas heb ik er nu geen tijd voor om verder aan te klussen. Maar als mensen bijdragen willen leveren, graag! Ik heb eventueel suggesties voor het aanpakken van het print-probleem en de mogelijkheid voor het opgeven van het aantal gewenste kolommen, ipv de (minimum) breedte per kolom.

[ Voor 14% gewijzigd door Fuzzillogic op 27-03-2006 18:07 ]

[Verwijderd]

Ah, het script is dus snel zat. Ik dacht dat het in kolommen zetten zo lang duurde. Aangezien ik een redelijk snelle pc heb zou dat een beetje raar zijn.

Wat je zegt zal wel kloppen: te moeilijk / men kent het niet / de scripts zijn nog niet optimaal. Erg nieuw is het niet aangezien iht.com al zeker 3 jaar met kolommen werkt. Ik vind het toch vreemd, want het is toch best een grote industrie.

Kolommen printen is bij mijn huidige homepage/script combi geen probleem meer (met IE en FF). Bij eerdere versies ging het niet goed; dan zette hij het gewoon in 1 brede kolom. www.iht.com kan het ook lijkt het. Wellicht komt dat door de opmaak van de websites en niet zozeer door het script.

[Fuzzillogic]

Verwijderd schreef op dinsdag 28 maart 2006 @ 09:02:
Wat je zegt zal wel kloppen: te moeilijk / men kent het niet / de scripts zijn nog niet optimaal. Erg nieuw is het niet aangezien iht.com al zeker 3 jaar met kolommen werkt. Ik vind het toch vreemd, want het is toch best een grote industrie.

Met 'nieuw' doelde ik op mijn script Het IHT script is statisch en kan alleen platte tekst aan. Mijn script is een stuk flexibeler. CSS3 zal het allemaal nog fancier doen. (Maar eerlijkheid gebiedt mij te zeggen dat ik nog niet eens naar FF met CSS3-columns heb gekeken )

Kolommen printen is bij mijn huidige homepage/script combi geen probleem meer (met IE en FF). Bij eerdere versies ging het niet goed; dan zette hij het gewoon in 1 brede kolom. www.iht.com kan het ook lijkt het. Wellicht komt dat door de opmaak van de websites en niet zozeer door het script.

Het IHT-script gaat ook ook jammerlijk de mist in bij het printen. Alleen de eerste 2 kolommen worden afgedrukt, de rest van het artikel is onzichtbaar. (Noot: imo moet je een site kunnen printen middels het print-functie van je browser. Niet met een "print-fuctie" van een site.)

De huidige browsers gaan ervan uit dat een a4'tje 800 pixels breed is. Jouw site past dus precies. Voor fluid designs is het lastiger: er zijn geen events op het moment dat iemand gaat printen, dus je kunt niet even de boel herstellen.

De oplossing die ik nu voor ogen heb is simpel: laat de originele tekst gewoon staan, zonder kolommen, met display: none voor screen/projectie-media en display: block voor print. En vice versa natuurlijk voor de columnized versie. In kolommen printen zou natuurlijk veel mooier zijn, maar dat is erg lastig.

[Verwijderd]

Deze FF CSS3 demo ziet er gelikt uit! Het gaat ook heel snel met resizen. Maar ja, naar IE support kun je fluiten.

Met FF lukt het wel om alle drie iht.com kolommen te printen. Met IE wordt de derde door midden gedeeld over twee a4'tjes (een leuke knip en plak oefening voor thuis ).

Een display:none div laten staan voor het printen zal zeker werken ja. Eventueel kun je die tekst in een aparte JS op 800 pixels in kolommen zetten.

[ Voor 3% gewijzigd door Verwijderd op 28-03-2006 10:07 ]

[Michali]

In die pagina maken ze gebruik van -moz-* properties, dus logisch dat IE daar niet mee omgaat (niet dat ik daarmee iets beweer over de algemene CSS support van IE).

[Fuzzillogic]

Verwijderd schreef op dinsdag 28 maart 2006 @ 10:07:
Deze FF CSS3 demo ziet er gelikt uit! Het gaat ook heel snel met resizen. Maar ja, naar IE support kun je fluiten.

Aha! Stiekem lijkt dat toch verdraait veel op wat mijn scriptje doet Sterker nog: het scriptje gaat <p>aragraphs nog splitsen om gelijke hoogtes te bereiken, en dat doet deze CSS3 demo niet.

Over de snelheid: verlaag de timeout in het scriptje van 500ms naar 0ms en het gaat opeens ook 'snel'. Of het nuttig is betwijfel ik: hoevaak resize je je browser? En is 1x 500ms wachten dan teveel?

Met FF lukt het wel om alle drie iht.com kolommen te printen. Met IE wordt de derde door midden gedeeld over twee a4'tjes (een leuke knip en plak oefening voor thuis ).

3 kolommen idd, maar nog steeds maar 1 'pagina' van het artikel. De rest valt buiten de boot. FF lijkt uit te gaan van 1024 pixels voor de breedte van een a4'tje.

Een display:none div laten staan voor het printen zal zeker werken ja. Eventueel kun je die tekst in een aparte JS op 800 pixels in kolommen zetten.

Dat kan. Maar dan moet de tekst wel de volledige breedte zijn, zonder (fluid) sidebars ernaast. Maar dan nog zit je met het probleem dat je niet wil dat één kolom zich over meerdere pagina's uitstrekt.

[Verwijderd]

500 ms is niet te lang. Het punt was dat ik dacht dat het rekentijd was. Bij een minder snelle processor (een PDA ofzo) zou het dan veel te lang duren voordat de tekst op het beeld verschijnt.

Sidebars (waar je je links hebt e.d.) printen lijkt me nutteloos. Als je het echt wil kun je je tekstblok smaller maken dan 800 pixels. Als het geheel niet op 1 A4 past zul je een tweede A4 moeten starten. Dan moet je de onzichtbare div opdelen in verticaal gestapelde blokken die de hoogte hebben van de A4 printhoogte.

edit: CSS2 heeft ook 'page-break-after' om de pagina's op te delen. Dat lijkt me een beter idee dan DIVs.

[ Voor 10% gewijzigd door Verwijderd op 28-03-2006 18:49 ]

[Fuzzillogic]

Ter aanvulling: ik heb net v1.3 van m'n MC-script online gezet. Korte changelog:

• Je kunt nu het gewenste aantal kolommen ook opgeven, ipv dat dat berekent wordt a.d.h.v. een minimale kolombreedte.
• De "printbaarheid" van columnized pagina's is verbeterd. Voorheen kreeg je lege regels tussen gesplitste elementen in, dat is nu voorkomen.
• IE6 compatibiliteit hersteld. Was stukgemaakt in v1.2.1. Oeps. Maar uiteraard lag het aan IE6 en niet aan het script

De rest staat op de infopagina.

[djluc]

Ben ik de enige die het irritant vindt dat een pagina weer opnieuw versprint als de pagina geheel geladen is en dus het onload event (je wilt normaal gesproken daarvoor geen button) uitgevoerd wordt? Dat stoort me echt. Ik had eerst ook zo iets gebruikt op http://Oisterwijksculptuur.nl om de eerste alinea in een niet-scroll div te zetten maar uiteindelijk het toch maar gewoon hard in de HTML gedaan om het irritante verspringen.

[Fuzzillogic]

Dat is eenvoudig op te lossen door de functie niet onload aan te roepen, maar aan het einde van de HTML.

[djluc]

Mmm, sounds ugly Nee, het werkt nu prima hoor, dus ik ga er nu sowieso niet meer zulke dingen in wijzigen. Maar wel een leuke tip om het zo te doen. Ik ben van de mooie JS code dus zal het niet snel gebruiken maar misschien lost het eens wat op!

[Fuzzillogic]

Waarom is dat ugly? Je mag toch gewoon (bijna) overal Javascript neergooien. Nu gebruik je dat om zo snel mogelijk nadat de browser kennis heeft van de to columnize content (dus de afmetingen, positie e.d.) al het script aan te roepen.

Als het werkt (niet getest) dan is het toch prima. Potentieel probleem is als je content hebt die na het inladen van de HTML nog kan veranderen, dus m.n. afbeeldingen die geen vaste width en height hebben meegekregen in de HTML.

[djluc]

Mijn JavaScripts worden alleen geinclude in de header met een scripttag. Verder hangen die zelf evenhandlers aan de juiste elementen e.d. Daarom is het niet zo mooi om het in de body handmatig te doen. Dan wordt het een HTML specifiek iets terwijl het juist met de layout te maken heeft. Maargoed, zolang het maar werkt he

[ Voor 41% gewijzigd door djluc op 29-05-2006 12:50 ]