'Regels' wat betreft grootte webpage*

[Verwijderd]

Zo'n 3-4 jaar geleden werkte ik nog als webmaster en ontwierp zelf veel pagina's. Toendertijd waren er wat 'regeltjes' waar je rekening mee moest houden wat betreft de gemiddeld gebruikte resolutie van je bezoekers. Tsja maar toen was de standaard nog 800x600. Is inmiddels wel wat meer geworden denk ik zo.
Nu ben ik na jaren weer eens bezig met een page, en kan iemand mij vertellen wat de marges zijn bij de hedendaagse resoluties. En waar kan ik hier wat info over vinden.

[ixl85]

vele zegen nogsteeds 800/600... maar wat voor een mensen wil je dan in godsnaam aantrekken
ligt ook een beetje aan je doelgroep...
maar ik ga altijd uit van 1024 (wel wetende dat er geen mensen met 800/600 op mn pagina komen )

maar er is vrijveel te vinden in de search, go ahead, try it... you might like it

[Blaise]

Als ik voorgaande topics hierover globaal samenvat komt het erop neer dat 800 nog steeds veel wordt gebruikt, en dat veel mensen met een hogere resolutie dan 1024 ook 800 browsen. Daarnaast is een rekbaar design, paginabreed, niet aan te raden omdat bij hoge resoluties dan de regels te lang worden waardoor je tijdesns het lezen het begin van de volgende regel niet goed kan vinden.

[Voutloos]

Volgens mij was 4 jaar geleden een rustige periode op browser gebied. Daarvoor was het nog een gevecht tussen Netscape en IE. Inmiddels letten we ook weer meer op browsers, dus een belangrijke tip lijkt me om je site ook in alle alternatieve browsers te testen.

Voor de rest mag je best een beetje creatief zijn en denk ik dat je inmiddels met 1024*768 niet zoveel bezoekers meer misloopt, maar is het idd wel de gewoonte om een pagina smal te houden.

[ Voor 8% gewijzigd door Voutloos op 12-08-2004 02:16 ]

[Blaise]

Recente discussie over dit onderwerp: Resolutie, waar moet je nou rekening mee houden¿?

[Verwijderd]

Tof, echt wel snel reacties! Moet er weer een beetje 'inkomen' vandaar deze eigenlijk best wel noob-vraag. Toendertijd zatten we altijd te rekenen hoe hoog de taakbalk was en wat IE + Netscape zelf voor een ruimte innam. Dan 800x600 en die marges er aftrekken en dan ging het nog vaak de mist in.

[Verwijderd]

Blaise schreef op 12 augustus 2004 @ 02:21:
Recente discussie over dit onderwerp: Resolutie, waar moet je nou rekening mee houden¿?

Kijk dat zocht ik! Thanx!

[JeromeB]

Blaise schreef op 12 augustus 2004 @ 02:15:
Daarnaast is een rekbaar design, paginabreed, niet aan te raden omdat bij hoge resoluties dan de regels te lang worden waardoor je tijdesns het lezen het begin van de volgende regel niet goed kan vinden.

Dat ben ik niet helemaal met je eens:
- Je kunt natuurlijk altijd makkelijk je browser-venster aanpassen waardoor de tekst wel weer leesbaar wordt.
- Je kunt ook het lettertype groter maken waardoor de tekst op de totale regel niet meer zolang wordt.
- Daarnaast is dit te voorkomen door met marges en paddings te spelen die ook automatisch meerekken.

Solid-Designs vind ik persoonlijk niet zo fijn: Je zult serieus rekening moeten houden met resoluties en de groottes zijn niet aantepassen wat ik minder gebruiksvriendelijk vind.

[swampy]

Mmm, als ik een website maak, meestal alleen wat tekst en fotos ... dan zorg ik voor een zachte kleur op de achtergrond, een mooie bijbehorende kleur tekst, sinds kort ben ik ben CSS bezig stijlen aan te brengen... Ik moet zetten... het ziet er mooi en zacht allemaal uit...

Maar als ik een technische website zou opzetten over schaalmodellen en oorlog tuig zou ik het anders doen....

Ik ben een persoon van "keep it simple" ... teveel prut, rotzooi menutjes en nodeloze animaties en mensen kunnen je content niet meer vinden.

Flash gebruik ik ook eigenlijk niet!

Wel moet je duidelijk je website verdelen en in het oog houden wat je wilt, en wat voor gevoel je wilt uitstralen...

Laatste maanden heb ik module based thinking uitgetest en in sommige situaties werkt het, maar Evolutie gebaseerd bouwen vind ik toch beter. Als een boom de basis eerst, dan de grote takken..dan de kleinere takken.dan de bladeren!

[ Voor 47% gewijzigd door swampy op 12-08-2004 03:34 ]

[coubertin119]

Het hangt van je doelgroep af. Websites voor CG-artiesten hebben geen ondersteuning voor 800*600 nodig, websites met recepten voor huismoeders wel. Heb je geen gegevens over de resolutie van je bezoekers?

Je kan ook stretchende lay-outs bouwen. Dan staat hij op iedere resolutie mooi .

[BarôZZa]

Ik maak zelf m'n designs altijd voor 800x600. In 1024x768 en hoger heb je dan links en rechts wat ruimte over, wat ik er wel netjes en rustiger uit vind zien. Bovendien vind ik het overzichtelijker dan wanneer heel je scherm volstaat.

[VLQRT]

Je kunt ook eens kijken of je een boek van "Jacob Nielsen" kunt kopen. Is wel een dikke pil maar staat vol met richtlijnen over het ontwerpen van websites.

[ralpje]

En misschien ff een titelchange naar 'grootte webpage'. Het gaat hier om wat voor formaat het is, en niet of het toevallig een website is die veel bezoekers trekt.

[Verwijderd]

VLQRT schreef op 12 augustus 2004 @ 10:23:
Je kunt ook eens kijken of je een boek van "Jacob Nielsen" kunt kopen. Is wel een dikke pil maar staat vol met richtlijnen over het ontwerpen van websites.

Jakob Nielsen that is...

[edit] Ik dacht trouwens dat het over regels van grote websites ging, maar het gaat dus over de grootte, misschien handig om de titel van het topic even te wijgigen.

[ Voor 24% gewijzigd door Verwijderd op 12-08-2004 10:38 ]

[Willem]

sigh... intel vs amd, ie vs mozilla/netscape, pc vs mac etc... zijn echt genoeg boeken over geschreven en lots of topics over geopend; ja, ook over 800*600 of >.

[Stephan_jk]

JeromeB schreef op 12 augustus 2004 @ 02:38:
[...]

Solid-Designs vind ik persoonlijk niet zo fijn: Je zult serieus rekening moeten houden met resoluties en de groottes zijn niet aantepassen wat ik minder gebruiksvriendelijk vind.

Maar als je gebruik maakt van plaatjes tussen de tekst is het wel prettig om solid-designs te gebruiken. Ik doe dat ook altijd en het werkt goed. Maar ik hou dan ook altijd de resolutie van 800 * 600 aan. Dat vind ik het meest overzichtelijk. Bij hogere resoluties heb je aan beide kanten een lege ruimte wat ook weer rust brengt. (tenzij je achtergrond dat weer verpest )

[VLQRT]

Het is volgens mij juist niet slim om de grootten in pixels aan te geven, stel dat een belangrijke klant op 1600-1200 surft?

Die peert 'm direct weer omdat hij de text bijna niet kan lezen, scheelt toch weer een grote order.

[Verwijderd]

VLQRT schreef op 12 augustus 2004 @ 10:23:
Je kunt ook eens kijken of je een boek van "Jacob Nielsen" kunt kopen. Is wel een dikke pil maar staat vol met richtlijnen over het ontwerpen van websites.

Jammer dat Jacob Nielsen alleen geen verstand heeft van de designaspecten van het web, en zijn artikelen plaatst zonder deze te onderbouwen met wetenschappelijke of in ieder geval relevante gegevens.

De bedrijven trappen nog steeds in zijn gepreek, daar verdient hij zijn geld mee, sterker nog hij verkondigd gewoon wat in artikelen door andere auteurs is geschreven maar deze hadden hun gegevens wel onderbouwd.

Hier oa een link van een van de developers van Adobe Photoshop, die Jacob Nielsen keihard onderuit haalt.
http://www.designbyfire.com/000068.html

Oa Jeffrey Zeldman is ook niet een bijzonder grote fan van meneer Nielsen. Nielsen heeft geen kaas gegeten van het web imo, hij moet gewoon lekker de usability van een potlood met gum gaan evalueren.

http://www.useit.com/ is een goed voorbeeld van een toonaansprekende website op het web. ... van de Nielsen Norman Group uiteraard..

Er wordt afgesloten met de volgende quote

Mr. Nielsen, I respectfully request you stop posting articles like this. You do yourself and the usability field a disservice by speaking in terms that are vague, not backed up with research data, and filled with hyperbole. Further, until you learn more about what it takes to be a designer, and what it means to design a product with your own two hands, I respectfully request you stop trying to dictate any design agenda as some subset of what you view as the usability agenda.

Wil je echt dat boek nog aanbevelen?

[ Voor 21% gewijzigd door Verwijderd op 12-08-2004 10:49 ]

[Willem]

@VLQRT
hoe kortzichting

Sorry maar dit is echt niet te flitsen

[ Voor 7% gewijzigd door Willem op 12-08-2004 10:46 ]

[VLQRT]

Is idd een beetje overdreven, maar ik wilde aangezen dat wanneer je je website op absolute waarden bouwt je een deel van je mogelijke bezoekers afschrikt.

Met ongeveer dezelfde moeitje maak je je website relatief (je gebruikt % ipv absolute waarden) en dan kun je die bezoekers ineens wel bedienen

voorbeeltje was idd een beetje sumier en kortzichtig

[edit]
@gordijnstok
ik heb een boek van Nielsen gelezen en er stonden punten in waar ik nog niet aan had gedacht. Ik heb nooit gezegd dat Nielsen de waarheid in pacht heeft en zoals in elk boek staan er dingen in waar ik het niet mee eens ben. Maar het boek van Nielsen geeft wel een boel goede tips en truc's.

[ Voor 34% gewijzigd door VLQRT op 12-08-2004 11:02 ]

[BalusC]

Op mijn website is de basisfont 8px groot. Bij resoluties boven 1024px worden de zinnen in de main content nét te lang dat ze buiten het prettige "leesgebied" vallen en dat je je hoofd net teveel moet meebewegen om de zin goed te kunnen volgen. Ook wordt de volgende regel in een grote alinea moeilijker gevonden. Dit is de reden dat ik de maximum breedte van mijn website op 1024px heb zitten. Maar ik heb ook een minimumbreedte van 800px, de basislayout wordt anders misvormd wanneer je de browservenster verkleint tot onder de 800px.

Ergo, het kan best per website verschillen, maar de tekst moet wel prettig leesbaar blijven met behoud van de layout.

Overigens, volgens Nedstat stats van mijn website wordt 800x600 nog relatief veel gebruikt.

[JeromeB]

Stephan_jk schreef op 12 augustus 2004 @ 10:41:
[...]


Maar als je gebruik maakt van plaatjes tussen de tekst is het wel prettig om solid-designs te gebruiken.

Leg mij eens uit waarom dat prettiger zou zijn bij solid-designs. Het is ook heel goed mogelijk bij liquid-designs. Wat is dus je punt?

[crisp]

BalusC: 8px is wel èrg klein; ik heb behoorlijk goede ogen, maar ik moet toch echt naar voren gaan leunen om het goed te kunnen lezen...

[BalusC]

8px wordt ook gebruikt op de Frontpage en op de GoT Silver template en het leest uitstekend De fontsize in de tabellen is overigens idd kleiner: 7px.

[ Voor 6% gewijzigd door BalusC op 12-08-2004 11:36 ]

[OzBoz]

VLQRT schreef op 12 augustus 2004 @ 10:58:
Is idd een beetje overdreven, maar ik wilde aangezen dat wanneer je je website op absolute waarden bouwt je een deel van je mogelijke bezoekers afschrikt.

Als iemand op 1600x1200 surft en het niet meer kan lezen dan gebruikt ie gewoon een te hoge resolutie in verhouding tot de maat van de monitor. Das niet het probleem van de webdesigner.

[André]

Is er voor een font geen eenheid beschikbaar die rekening houd met de DPI van de monitor.

Terwijl ik ^^^ type denk ik aan de eenheid mm, werkt die ook?

Edit:
Even getest, die werkt dus. Is mm dan niet de perfecte eenheid om fonts mee weer te geven.

[ Voor 25% gewijzigd door André op 12-08-2004 11:43 ]

[Willem]

Een eenheid kan daar lijkt me geen rekening mee houden...
gezien je nog steeds op scherm zit

mm gaat natuurlijk niet op, want dan zou 10mm op alle resoluties er hetzelfde uitzien

[André]

willem169 schreef op 12 augustus 2004 @ 11:42:
Een eenheid kan daar lijkt me geen rekening mee houden...
gezien je nog steeds op scherm zit

mm gaat natuurlijk niet op, want dan zou 10mm op alle resoluties er hetzelfde uitzien

Ja, 1mm === 1mm op elke resolutie. Ik heb net een stuk tekst op 20mm gezet en met een lineaal tegen mijn monitor het even bekeken: het klopt

[Verwijderd]

André schreef op 12 augustus 2004 @ 11:44:
en met een lineaal tegen mijn monitor

serieus?

[ Voor 3% gewijzigd door Verwijderd op 12-08-2004 11:47 ]

[Nemrah]

Hoe zit het eigenlijk met de "normen" voor de andere grootte namelijk het gewicht van de pagina?
Het is natuurlijk leuk dat een "echte" tweaker met zijn 8 mbit verbinding alles in 3 milliseconde op zijn scherm heeft, maar dat is niet de norm. Dus wat is als omvang nog een beetje behapbaar voor een "gemiddelde"gebruiker? 10kb? 100kb? 1Mb?
Vind ik persoonlijk een lastige..

[ Voor 14% gewijzigd door Nemrah op 12-08-2004 11:50 ]

[Spruit_elf]

Verwijderd schreef op 12 augustus 2004 @ 02:27:
Tof, echt wel snel reacties! Moet er weer een beetje 'inkomen' vandaar deze eigenlijk best wel noob-vraag. Toendertijd zatten we altijd te rekenen hoe hoog de taakbalk was en wat IE + Netscape zelf voor een ruimte innam. Dan 800x600 en die marges er aftrekken en dan ging het nog vaak de mist in.

uit deze quote denk ik op te maken dat je je websites nog op de oude manier maakt, met tabellen enzo.

een van de grote veranderingen is dat men tegenwoordig wat meet op semantiek is gaan letten en dat daardoor tabellen tegenwoordig not done zijn (voor layout that is, voor tabulaire data mag het wel natuurlijk)

dat heeft 3 redenen,
ten eerste dus de semantiek,

ten tweede omdat een site met tabelen erg sterk resolutie gebonden is, je moet dan heel erg op de pixel werken, dan moet je idd veel rekenen. Als je met divjes gaat werken zorgt dat namelijk voor een site die een stuk flexiebeler word op verschillende resoluties.

ten derde omdat mensen die alternatieve browsers gebruiken (en dan bedoel ik vooral andere media zoals braille, text only, pda, of gesproken) nogal moeite hebben met tabelen omdat die browser de inhoud van layout tabelen gaan parsen als tabulaire data en daar wordt het meestal niet duidelijker op.


Wat op dit moment de belangrijkste dingen zijn is niet zozeer een perfect pixel design, maar voornameliijk ene flexiebel design waarbij je op semantiek let(dus tabellen voor tabulaire data, lists voor opsommingen, <h1> ipv van <span class="header1"> en waarbij je de inhoud puur in de html laat en de opmaak in een css file.

ook hoort daar bij dat je javascript niet onodig gebruikt, geen enorme uitklap menutjes scripts waneer je het zlefde met css kan doen bijv.


De enige uitzondering op dit alles is natuurlijk dat het wel toegestaan is om een beetje te sjoemelen als het gaat om het ondersteunen van browsers als IE. maar dat is een punt wat afhangt van je eigen wensen (zo zal een site voor een bedrijf wel goede IE ondersteuning hebben terwijl een site van een IE hatende css guru dat niet zal zijn.)

just my 2 cents


EDIT:

Lindetree schreef op 12 augustus 2004 @ 11:48:
Hoe zit het eigenlijk met de "normen" voor de andere grootte namelijk het gewicht van de pagina?
Het is natuurlijk leuk dat een "echte" tweaker met zijn 8 mbit verbinding alles in 3 milliseconde op zijn scherm heeft, maar dat is niet de norm. Dus wat is als omvang nog een beetje behapbaar voor een "gemiddelde"gebruiker? 10kb? 100kb? 1Mb?
Vind ik persoonlijk een lastige..

er zijn dacht ik wel een paar richtlijnen die bijvoorbeeld stellen dat het het beste is om je files zo groot te maken dat je in 1 packet passen, zo kan een pagina in 1 keer opgehaald worden ipv kleine stukjes. ik denk dat 50kb wle ene beetje de limiet is, maar als jij goed design toepast en de opmaak ik cssfiles doet en de inhoud in html en javascript ook in externe files.
bovendien kan je dan altijd in het geval van bijvoorbeeld een nieuws site met veel berichten op 1 pagina de pagina op delen, in meerdere of iets van een archief toepassen
als je dat doet denk ik dat je dan flink je best moet doen om boven de 100 kb uit te komen

[ Voor 22% gewijzigd door Spruit_elf op 12-08-2004 11:56 ]

[Willem]

André, tekst op 20mm slaat toch nergens op?
Als ik 640 draai of 1600 en tekst is 20mm is het echt buiten elke proportie

Eenheden voor webtekst in mm lijkt me echt ongeschikt, meer iets voor print.

[BetuweKees]

André schreef op 12 augustus 2004 @ 11:40:
Is er voor een font geen eenheid beschikbaar die rekening houd met de DPI van de monitor.

Terwijl ik ^^^ type denk ik aan de eenheid mm, werkt die ook?

en em dan?

[André]

willem169 schreef op 12 augustus 2004 @ 11:52:
André, tekst op 20mm slaat toch nergens op?
Als ik 640 draai of 1600 en tekst is 20mm is het echt buiten elke proportie

Eenheden voor webtekst in mm lijkt me echt ongeschikt, meer iets voor print.

Tja, stel je voor dat letters van 6 mm prima te lezen zijn, dan gebruik je die toch op elke resolutie zodat het altijd prima leesbaar is. Zo zul je op 640 geen koeiletters krijgen en op 1600 geen kleine frutsels.

BetuweKees schreef op 12 augustus 2004 @ 11:53:
[...]

en em dan?

en eh nut?

[ Voor 12% gewijzigd door André op 12-08-2004 11:55 ]

[Spruit_elf]

BalusC schreef op 12 augustus 2004 @ 11:36:
8px wordt ook gebruikt op de Frontpage en op de GoT Silver template en het leest uitstekend De fontsize in de tabellen is overigens idd kleiner: 7px.

bedenk wel dat dit ook van het lettertype af hangt, sommige lettertypen zijn niet meer dan pixels op 8px

[BetuweKees]

André schreef op 12 augustus 2004 @ 11:55:
en eh nut?

had zelf altijd begrepen dat 'em' de eenheid was die je moet gebruiken voor resolutie onafhankelijke weergaven van afstanden en eenheden, aangezien deze eenheid afgaat op de hoogte van de letter 'm' in het standaard lettertype.
als je deze eenheid consequent gebruikt zou je dus een resolutie onafhankelijke website in elkaar kunnen zetten, nl lettertype groter -> website groter en vice versa.

[OzBoz]

André schreef op 12 augustus 2004 @ 11:55:
[...]
en eh nut?

Nut, is schaalbaar.

Overigens is pt ook wel goed te gebruiken, de standaard in font-maten. Maar dan zit je weer met het probleem dat 12pt op PC anders is dan 12pt op Mac. Waarden in mm zijn echt onzin. Monitors hebben niet echt een bepaalde dpi, hooguit bij benadering (ligt immers ook aan je instellingen van je monitor config). MOnitors hebben wel een dotpitch maar er zijn geen maateenheden die daar rekening mee houden.

[ Voor 4% gewijzigd door OzBoz op 12-08-2004 12:05 ]

[Verwijderd]

'1em' heeft dezelfde waarde als de 'font-size' opgegeven door de browser of door een 'ancestor element', niks bijzonders aan.

[Verwijderd]

mrcactus schreef op 12 augustus 2004 @ 11:50:
[...]


uit deze quote denk ik op te maken dat je je websites nog op de oude manier maakt, met tabellen enzo.

een van de grote veranderingen is dat men tegenwoordig wat meet op semantiek is gaan letten en dat daardoor tabellen tegenwoordig not done zijn (voor layout that is, voor tabulaire data mag het wel natuurlijk)

dat heeft 3 redenen,
ten eerste dus de semantiek,

ten tweede omdat een site met tabelen erg sterk resolutie gebonden is, je moet dan heel erg op de pixel werken, dan moet je idd veel rekenen. Als je met divjes gaat werken zorgt dat namelijk voor een site die een stuk flexiebeler word op verschillende resoluties.

...


Wat op dit moment de belangrijkste dingen zijn is niet zozeer een perfect pixel design, maar voornameliijk ene flexiebel design waarbij je op semantiek let(dus tabellen voor tabulaire data, lists voor opsommingen, <h1> ipv van <span class="header1"> en waarbij je de inhoud puur in de html laat en de opmaak in een css file.

ook hoort daar bij dat je javascript niet onodig gebruikt, geen enorme uitklap menutjes scripts waneer je het zlefde met css kan doen bijv.

....

Dat hele semantiek verhaal klinkt mij nog een beetje wazig (maw, nog nooit van gehoord )

Tabellen zijn dus not done. Maar wat als als ik nu in PS een volledig grafische pagina maak en daar wat linkjes inbak, dan zit ik ook met een tabel. Of kan dat tegenwoordig ook anders?

Pfff shit echt lang geleden allemaal, wist niet dat je met css ook menu's kan maken. Is daar een tutorial voor?

[Verwijderd]

http://css.maxdesign.com.au/
http://www.google.com/search?q=semantic+markup
http://www.brainstormsand...cles/semantics/structure/

Etc.

[-Lars-]

Wat denken jullie van xx-small | x-small | small | medium | large | x-large | xx-large en larger | smaller.

Zover ik heb begrepen gaan deze uit van de standaardinstellingen van de gebruiker. Dat houdt in dat mensen die moeite hebben met lezen (en dus een groot lettergrootte hebben ingesteld) ook een leesbare tekst hebben. Procenten gaan uit van de grootte van het 'parent element' en zouden voor de gebruiker handig zijn i.c.m. bovenstaande waardes. Dat terwijl bij absolute lengtes in in, cm, mm, pt, pc de grootte vaststaat en dus moeilijk leesbaar worden voor dat soort mensen. "Relatieve" lengtes als em, ex en px gaan in zekere zin wel uit van de omstandigheden van de gebruiker (gebruikte resolutie, grootte van het lettertype), maar niet van de gebruikersinstellingen.

Correct me if I'm wrong, ik ben nog maar net begonnen me echt in CSS te verdiepen.

[Blaise]

BalusC schreef op 12 augustus 2004 @ 11:36:
8px wordt ook gebruikt op de Frontpage en op de GoT Silver template en het leest uitstekend De fontsize in de tabellen is overigens idd kleiner: 7px.

Volgens mij bedoel je .pt...

[JeromeB]

OzBoz schreef op 12 augustus 2004 @ 12:04:
[...]


Nut, is schaalbaar.

Wel grappig dat je dat zo zegt. Bijna elke eenheid is namelijk schaalbaar. Zo is px bijvoorbeeld ook schaalbaar -> je kunt de resolutie veranderen.

-Larz- schreef op 12 augustus 2004 @ 13:30:
Wat denken jullie van xx-small | x-small | small | medium | large | x-large | xx-large en larger | smaller.

Deze _eenheden_ gebruik ik meestal ook.

"Relatieve" lengtes als em, ex en px gaan in zekere zin wel uit van de omstandigheden van de gebruiker (gebruikte resolutie, grootte van het lettertype), maar niet van de gebruikersinstellingen.

Het punt daarbij is dan weer ... wat zijn precies die gebruikersinstellingen? een resolutie is namelijk ook een gebruikersinstelling.

[ Voor 52% gewijzigd door JeromeB op 12-08-2004 13:37 ]

[Verwijderd]

mrcactus schreef op 12 augustus 2004 @ 11:50:
uit deze quote denk ik op te maken dat je je websites nog op de oude manier maakt, met tabellen enzo.

Want? ... alsof je door CSS ineens van je statusbar af bent? Of dat ineens alle maten en eenheden zijn verdwenen?

een van de grote veranderingen is dat men tegenwoordig wat meet op semantiek is gaan letten en dat daardoor tabellen tegenwoordig not done zijn (voor layout that is, voor tabulaire data mag het wel natuurlijk)

Defineer "men". Is dat als in bedrijven, overheidsinstellingen? Of is dat wat de crowd meent te denken. De developersview.. ? Mensen schijnen nog steeds CSS te kiezen omdat het wel goed zal zijn, tenminste dat zeggen "ze".

ten tweede omdat een site met tabelen erg sterk resolutie gebonden is, je moet dan heel erg op de pixel werken, dan moet je idd veel rekenen. Als je met divjes gaat werken zorgt dat namelijk voor een site die een stuk flexiebeler word op verschillende resoluties.

Sorry hoor, wat verkondig je nu? Heb je zelf wel eens met tables gewerkt. Ik werk zelf dagelijks met css layouts, maar dit ....

Als jij voor een reclamebureau een site in elkaar slaat dan eisen ze dat je pixel precies werkt, kan je dat niet dan is wellicht de plantsoenendienst nog wat voor je. Dat heeft geen donder te maken met semantiek, css, of tables. Tables kun je pixelprecies mee werken, en css gepositioneerde elementen ook.

Ik ben gewoon wel verdomd benieuwd naar je onderbouwing voor die flexibiliteit. Het is gewoon een andere aanpak van de presentatielaag, maar zolang er nog steeds mensen zijn die elementen gaan nesten, zul je de flexibiliteit kunnen vergelijken met die van layouting in tables. Je verruilt td in tr in table voor div absolute, in div relative, in div absolute. Het 3de niveau is nu afhankelijk van zijn parent niveaus. Ik kan ook een table van links naar rechts verplaatsen of andersom, idem met css layouts.

ten derde omdat mensen die alternatieve browsers gebruiken (en dan bedoel ik vooral andere media zoals braille, text only, pda, of gesproken) nogal moeite hebben met tabelen omdat die browser de inhoud van layout tabelen gaan parsen als tabulaire data en daar wordt het meestal niet duidelijker op.

Dat heeft niets te maken met de presentatielaag, maar met de instelling van de developers. Als jij voor een pda template 80% van slapende presentatielaag gaat hiden met een display:none ben je lekker bezig, zeker als er overbodig business logic in de template zit. Als jij een grafische site gaat porten naar pda, dan ontkom je niet aan andere templates als je grafische elementen ook textueel zijn. Nee... dat is lekker snel laden voor een pda, of nog beter via GPRS naar je GSM.

Wat op dit moment de belangrijkste dingen zijn is niet zozeer een perfect pixel design, maar voornameliijk ene flexiebel design waarbij je op semantiek let(dus tabellen voor tabulaire data, lists voor opsommingen, <h1> ipv van <span class="header1"> en waarbij je de inhoud puur in de html laat en de opmaak in een css file.

Ik zal het doorgeven aan de design partners. "Jongens vanaf nu af aan wil ik geen pixel preciese designs meer hebben van jullie"...... ik denk inderdaad dat ik ze niet meer zal krijgen

er zijn dacht ik wel een paar richtlijnen die bijvoorbeeld stellen dat het het beste is om je files zo groot te maken dat je in 1 packet passen, zo kan een pagina in 1 keer opgehaald worden ipv kleine stukjes.

Hoe groot is een packet? Ip, tcp? ... lijkt me slim als je dat stuk gewoon edit want je praat poep.

[ Voor 28% gewijzigd door Verwijderd op 12-08-2004 13:54 ]

[Verwijderd]

Deze _eenheden_ gebruik ik meestal ook.

_waarden_

Het punt daarbij is dan weer ... wat zijn precies die gebruikersinstellingen? een resolutie is namelijk ook een gebruikersinstelling.

Die was dan ook genoemd.

[Verwijderd]

* Anne is het eens met het argument dat designers in px denken en niks anders

Het zou wel fijn zijn als ze die mentaliteit is veranderen en niet zo DTP achtig naar het web kijken, maar zover is het nog niet. (Daarnaast heb je natuurlijk ook nog Internet Explorer.)

[-Lars-]

JeromeB schreef op 12 augustus 2004 @ 13:33:
[...]

Het punt daarbij is dan weer ... wat zijn precies die gebruikersinstellingen? een resolutie is namelijk ook een gebruikersinstelling.

Ik bedoel dat als ik dan in Firefox bij de instellingen de standaardlettertypegrootte op 20 (pixels) zet, de lettertypes op sites die zulke waarden gebruiken ook enorm zullen vergroten. Ik neem aan dat dat in andere browsers ook op zo'n manier werkt (?).

[MAher]

Hm... Gordijnstok is wel erg geprikkeld door mrcactus zeg...

Verwijderd schreef op 12 augustus 2004 @ 13:44:

[...]

Hoe groot is een packet? Ip, tcp? ... lijkt me slim als je dat stuk gewoon edit want je praat poep.

Ik ben geen guru op dit gebied, maar als ik met de webdeveloper-toolbar voor Firefox een speedreport van een website opvraag, dan staat daar onderandere dit in:

CSS_SIZE - Caution. The total size of your external CSS is 3416 bytes, which is above 1160 bytes and less than 8K. For external files, try to keep them less than 1160 bytes to fit within one higher-speed TCP-IP packet (or an approximate multiple thereof). Consider optimizing your CSS and eliminating features to reduce this to a more reasonable size.

(http://www.websiteoptimiz...wso.php?url=http://nu.nl/

Dus zoveel poep is wat mrcactus zegt nou ook weer niet, lijkt mij.

[André]

MAher schreef op 12 augustus 2004 @ 14:05:
Ik ben geen guru op dit gebied, maar als ik met de webdeveloper-toolbar voor Firefox een speedreport van een website opvraag, dan staat daar onderandere dit in:

CSS_SIZE - Caution. The total size of your external CSS is 3416 bytes, which is above 1160 bytes and less than 8K. For external files, try to keep them less than 1160 bytes to fit within one higher-speed TCP-IP packet (or an approximate multiple thereof). Consider optimizing your CSS and eliminating features to reduce this to a more reasonable size.

(http://www.websiteoptimiz...wso.php?url=http://nu.nl/

Dus zoveel poep is wat mrcactus zegt nou ook weer niet, lijkt mij.

Toch wel, van het bovenstaande heb ik nog nooit gehoord. Eigenlijk staat er: hoe kleiner de file hoe sneller hij binnen is . En ik kan me voorstellen dat het protocol anders omgaat met kleine bestanden maar dan praat je volgens mij in millisecondes. Het is juist goed om alle css zoveel mogelijk in een extern bestand te frotten omdat die toch gechached word

Ik heb trouwens even mijn eigen site er doorheen gehaald:

TOTAL_OBJECTS - Warning! The total number of objects on this page is 11 - consider reducing this to a more reasonable number. Combine, refine, and optimize your external objects. Replace graphic rollovers with CSS rollovers to speed display and minimize HTTP requests.
TOTAL_IMAGES - Caution. You have a moderate amount of images on this page (7 ). Consider using fewer images on the site or try re-using the same image in multiple pages to take advantage of caching.
TOTAL_CSS - Congratulations, the total number of external CSS files on this page is 1 . Because external CSS files must be in the HEAD of your HTML document, they must load first before any BODY content displays. Although they are cached, CSS files slow down the initial display of your page.
TOTAL_SIZE - Congratulations, the total size of this page is 29621 bytes. This page should load in less than eight seconds on a 56Kbps connection - or 6.10 seconds. But there's always room for improvement.
TOTAL_SCRIPT - Congratulations, the total number of external script files on this page is 2 . External scripts are less reliably cached than CSS files so consider combining scripts into one, or even embedding them into high-traffic pages.
HTML_SIZE - Congratulations, the total size of this HTML file is 6306 bytes, which less than 20K. Assuming that you specify the HEIGHT and WIDTH of your images, this size allows your page to display content in well under 8 seconds, the average time users are willing to wait for a page to display without feedback.
IMAGES_SIZE - Caution. The total size of all your images is 17474 bytes, which exceeds 15K. Consider optimizing and creatively cropping your images, and combining them where appropriate. Even better, replace graphic text and form controls with styled text to eliminate unnecessary HTTP requests. Ideally each image should be less than 1160 bytes, to easily fit into one TCP-IP packet.
SCRIPT_SIZE - Caution. The total size of your scripts is 3148 bytes, which is above 1160 bytes and less than 4K. Consider optimizing your scripts and eliminating features to reduce this to a more reasonable size.
CSS_SIZE - Caution. The total size of your external CSS is 2693 bytes, which is above 1160 bytes and less than 8K. For external files, try to keep them less than 1160 bytes to fit within one higher-speed TCP-IP packet (or an approximate multiple thereof). Consider optimizing your CSS and eliminating features to reduce this to a more reasonable size.

Wat een poep hé

[ Voor 55% gewijzigd door André op 12-08-2004 14:14 ]

[Verwijderd]

MAher schreef op 12 augustus 2004 @ 14:05:
Hm... Gordijnstok is wel erg geprikkeld door mrcactus zeg...

Nee hoor Maar als je gaat lopen gooien met semantiek, css, etc. kom dan niet met van die nonsense argumenten

Ik heb echt helemaal niets tegen het gebruik van CSS, ik vind het een geweldige methodiek, maar als je gaat preken over CSS, preek dan goed, met argumenten die kloppen met de werkelijkheid, want mensen die daadwerkelijk ervan willen leren gaan die loze argumenten weer verder brengen, en verder, en verder, etc.

Dus zoveel poep is wat mrcactus zegt nou ook weer niet, lijkt mij.

Higher level TCP/IP packets bestaan niet eens, het is leuk dat ze er een marketing praat op na houden maar packet size is zelf in te stellen, deze is default 1500. Dan kun je je beter zorgen gaan maken over width en height parameters op je images om performance te meten, want die hebben een grotere impact. Meet anders is bij wijze van spreke voor de gein het aantal packets dat wordt verstuurd. Bij een request gaat het namelijk niet alleen om page packets. Daarom is het poep. Al had ik het wat vriendelijker kunnen verwoorden agree.

[ Voor 44% gewijzigd door Verwijderd op 12-08-2004 14:37 ]

[bogy]

André schreef op 12 augustus 2004 @ 11:44:
[...]

Ja, 1mm === 1mm op elke resolutie. Ik heb net een stuk tekst op 20mm gezet en met een lineaal tegen mijn monitor het even bekeken: het klopt

Woooow ... als je dat zo ergens gewoon post onder grapjes en grollen klinkt het wel héél leuk...


"Ik heb net een stuk tekst op 20mm gezet en met een liniaal tegen mijn monitor even bekeken: het klopt" ... moehahahah

[bogy]

André schreef op 12 augustus 2004 @ 14:10:

Wat een poep hé

dan heb je deze nog ni gezien.. 'k verschoot zelf van al de warnings:

Analysis and Recommendations
TOTAL_OBJECTS - Warning! The total number of objects on this page is 45 - consider reducing this to a more reasonable number. Combine, refine, and optimize your external objects. Replace graphic rollovers with CSS rollovers to speed display and minimize HTTP requests.
TOTAL_IMAGES - Warning! The total number of images on this page is 38 , consider reducing this to a more reasonable number. Combine, refine, and optimize your graphics. Replace graphic rollovers with CSS rollovers to speed display and minimize HTTP requests.
TOTAL_CSS - Congratulations, the total number of external CSS files on this page is 2 . Because external CSS files must be in the HEAD of your HTML document, they must load first before any BODY content displays. Although they are cached, CSS files slow down the initial display of your page.
TOTAL_SIZE - Warning! The total size of this page is 252139 bytes, which will load in 50.65 seconds on a 56Kbps modem. Consider reducing total page size to less than 30K to achieve sub eight second response times on 56K connections. Pages over 100K exceed most attention thresholds at 56Kbps, even with feedback. Consider contacting us about our optimization services.
TOTAL_SCRIPT - Caution. The total number of external script files on this page is 4 , consider reducing this to one or two. Combine, refine, and optimize your external script files. Ideally you should have one (or even embed scripts for high-traffic pages) on your pages.
HTML_SIZE - Congratulations, the total size of this HTML file is 13662 bytes, which less than 20K. Assuming that you specify the HEIGHT and WIDTH of your images, this size allows your page to display content in well under 8 seconds, the average time users are willing to wait for a page to display without feedback.
IMAGES_SIZE - Warning! The total size of your images is 176634 bytes, which is over 30K. Consider optimizing your images for size, combining them, and replacing graphic rollovers with CSS.
SCRIPT_SIZE - Warning! The total size of your scripts is 50930 bytes, which is over 4K. Consider optimizing your scripts for size, combining them, and using compression where appropsiate for any scripts placed in the HEAD of your documents.
CSS_SIZE - Warning! The total size of your external CSS is 10913 bytes, which is over 8K. Consider optimizing your CSS for size by eliminating whitespace, using shorthand notation, and combining multiple CSS files where appropriate.


http://www.websiteoptimiz...?url=http://www.dcnet.be/

[MAher]

Allright:

Die 1160 Bytes für CSS Files ist hoffnungslos übertrieben; auch bei Bildern wird das ziemlich eng. Ausserdem scheint dieser Analyzer nur auf Größenangaben einzugehen. Es gibt aber noch ein paar andere Aspekte, zum Beispiel width/height bei Bildern, die beim Seitenaufbau wichtig sind.

Denken aan de hoeveelheid packets is dus wel vrij zinloos. (of poep volgens Gordijnstok ) Het is beter ergens anders te optimaliseren.

[Verwijderd]

Waarschijnlijk hebben de maker van die website zich vergist in de architectuur van tcp/ip. Een onderdeel daarvan is inderdaad "the higher layer", nl. transmission control protocol. Wat deze laag doet is het samenstellen van de boodschap in kleinere pakketen, aan de andere kant pakt de tcp laag dit weer op om een resultaat samen te stellen. Het ip gedeelte is "the lower layer". Deze behandelt addresering van elk pakket zodat het op de goede plek aankomt.

"fit within one higher-speed TCP-IP packet" is niets anders als zeggen probeer je pagina te laten passen in één tcp-ip packet. Vervolgens gaat hij door "or a multiply of", kortom.. poep. Als het dus niet past gebruikt hij meerdere TCP-IP packets... joh.. hebben we zomaar de basis van het TCP-IP protocol.

Hij zegt dus in principe in zijn laatste alinea wat André al aangaf. Maak het pakket kleiner en je krijgt het sneller. Maar waar hij nu in vredesnaam die bytecount vandaan heeft gehaald.. ik denk dat de rode wijn erg lekker was.

[ Voor 20% gewijzigd door Verwijderd op 12-08-2004 14:42 ]

[Willem]

bogy:
Woooow ... als je dat zo ergens gewoon post onder grapjes en grollen klinkt het wel héél leuk...


"Ik heb net een stuk tekst op 20mm gezet en met een liniaal tegen mijn monitor even bekeken: het klopt" ... moehahahah

[Coach4All]

offtopic:
Maniacshouse, weet je dat er in [rml][ ontslagbrief] e-mailbericht rechtsgeldig?[/rml] nog op een reactie van je wordt gewacht?

[Creesch]

een handig boek hiervoor is het

Handboek Website Usability
geschreven door Peter Kassenaar en Oskar van Rijswijk
ISBN: 90 395 2101 8

Staan veel tips ed in

[ Voor 5% gewijzigd door Creesch op 12-08-2004 16:01 ]

[Verwijderd]

craze_ schreef op 12 augustus 2004 @ 16:01:
een handig boek hiervoor is het

Handboek Website Usability
geschreven door Peter Kassenaar en Oskar van Rijswijk
ISBN: 90 395 2101 8

Staan veel tips ed in

Wat vast ook wel een goeie is (heb het niet gelezen) is het boek van Zeldman, Designing with Web Standards.

[Verwijderd]

.

[ Voor 99% gewijzigd door Verwijderd op 31-10-2023 22:38 ]

[Neejoh]

Verwijderd schreef op 13 augustus 2004 @ 08:22:
Ik heb mijn browser nooit full-screen! altijd een klein windowtje van minder dan 800*600. Ik zou dus niet zo snel een pagina maken die een bepaalde afmeting vereist.

offtopic:
Hey maniachouse, er wachten nog wat mensen op een posting van jou in het topic [rml][ ontslagbrief] e-mailbericht rechtsgeldig?[/rml]. Kijk daar eens na, wil je?

Minder dan 800x600? Wordt je heir op GoT dan niet helemaal gek? Past toch precies op 800x600, dus mis je gewoon tekst als je het scherm kleiner maakt?

[Cavorka]

coubertin119 schreef op 12 augustus 2004 @ 10:08:
Het hangt van je doelgroep af. Websites voor CG-artiesten hebben geen ondersteuning voor 800*600 nodig, (...)

Sorry hoor, maar hier moet ik echt even op reageren. Dit is gewoon nonsense: >10% van mijn bezoekers gebruikt nog 800x600... En ik ben niet echt een onbekende in de 3D wereld en heb bezoekers van bijna alle grote 3D fora. Als ik mijn website dus groter zou maken (damn, wat zou het een verademing zijn), gaat het bij toch wel heel erg veel mensen niet werken zoals het hoort. Ik zou echt heel graag groter willen, maar feit is dat teveel mensen het nog gebruiken.

Ja zelfs in de grafische wereld.

[ Voor 25% gewijzigd door Cavorka op 14-08-2004 09:58 ]

[Spruit_elf]

Verwijderd schreef op 12 augustus 2004 @ 13:44:
Want? ... alsof je door CSS ineens van je statusbar af bent? Of dat ineens alle maten en eenheden zijn verdwenen?

nee zeg ik dat dan?

Defineer "men". Is dat als in bedrijven, overheidsinstellingen? Of is dat wat de crowd meent te denken. De developersview.. ? Mensen schijnen nog steeds CSS te kiezen omdat het wel goed zal zijn, tenminste dat zeggen "ze".

het begint bij mensen zoals Anne en het eindigt bij de rest als die eenmaal ingaan zien dat een dergelijke site beter werkt (in de meeste gevallen)
niet zeuren ik weet dat ik generaliseer

Sorry hoor, wat verkondig je nu? Heb je zelf wel eens met tables gewerkt. Ik werk zelf dagelijks met css layouts, maar dit ....

Als jij voor een reclamebureau een site in elkaar slaat dan eisen ze dat je pixel precies werkt, kan je dat niet dan is wellicht de plantsoenendienst nog wat voor je. Dat heeft geen donder te maken met semantiek, css, of tables. Tables kun je pixelprecies mee werken, en css gepositioneerde elementen ook.

Ik ben gewoon wel verdomd benieuwd naar je onderbouwing voor die flexibiliteit. Het is gewoon een andere aanpak van de presentatielaag, maar zolang er nog steeds mensen zijn die elementen gaan nesten, zul je de flexibiliteit kunnen vergelijken met die van layouting in tables. Je verruilt td in tr in table voor div absolute, in div relative, in div absolute. Het 3de niveau is nu afhankelijk van zijn parent niveaus. Ik kan ook een table van links naar rechts verplaatsen of andersom, idem met css layouts.

jah dat heb ik ook wel eens gedaan ja, en wat ik bedoel met flexibilieteit is dat je met divjes dat mits goed gebruikt en dus niet oneindig genest je sites kan maken die bij wijze van spreken op en ronde viewport nog te gebruiken zijn, bij tables moet je daar nu eenmaal veel meer je best mee doen

en wat ik bedoel met pixel precies is dat men websites bouwt waar men alles tot op de pixel moet afmeten en zodra ene veld om een of andere redewn een pixel groter wordt dat het design gelijk in duigen ligt, dat is met css en divjes nu een maal veel beter te regelen dan met tabelen

Dat heeft niets te maken met de presentatielaag, maar met de instelling van de developers. Als jij voor een pda template 80% van slapende presentatielaag gaat hiden met een display:none ben je lekker bezig, zeker als er overbodig business logic in de template zit. Als jij een grafische site gaat porten naar pda, dan ontkom je niet aan andere templates als je grafische elementen ook textueel zijn. Nee... dat is lekker snel laden voor een pda, of nog beter via GPRS naar je GSM.

als je de boel correct gebruikt heb je zoizo geen of weinig tekst in plaatjes en anders hebben ze wel een alt tekst die je kan gebruiken, dus daar zou je dan niets mee hoeven doen (desnoods gebruikt je image replacement oid om dat te regeln) en als jij je site goed maakt dan hoef je niet 80% van je site te hiden met css, dan is het enige wat je moet doen is de layout iets aanpassen en mischien de kleuren oid

Ik zal het doorgeven aan de design partners. "Jongens vanaf nu af aan wil ik geen pixel preciese designs meer hebben van jullie"...... ik denk inderdaad dat ik ze niet meer zal krijgen

das mooi dan voor je

Hoe groot is een packet? Ip, tcp? ... lijkt me slim als je dat stuk gewoon edit want je praat poep.

ten eeerste staat er "ik dacht" ik weet het ook niet zeker ten 2de is het niet zo poep zie reacties van anderen en ten derde weet ik ook wel dat packets in verschillende grootes komen, maar het is nu eenmaal wel logisch dat als jjij 2 packets nodig hebt om een site te versturen, waarvan de laatste 3bytes aan info bevat dat dat beter in 1 packet kon, stel dat door een hickup dat laatste packet een minuut later komt, dan heb je mooi wel ene trage site of zelfs een timeout


ten laatste, ik wijd je toon maar aan een verkeerde been uit bed ofzo maar sorry als ik het niet perfect hebt weten te verwoorden, ik had gehoopt dat je zelf ook kan nadenken
ik heb overigens geen zin om dat hier nog verder te gaan uitvechten, als je vind dat ik onzin blaat, lees het niet.

dit is niewt bedoelt om een flamewar te starten maar ik laat dit niet zomaar over mijn kant gaan

ben overigens niet boos op je hoor gordijnstok, ik vind het aleen wat flauw

* Spruit_elf geeft Gordijnstok een aai over zijn bol en hoopt dat ie weer blij is
* Spruit_elf vind het ook vervelend als mensen blaaten met loze argumenten
sorry als ik het in jouw ogen ook doet

ps:
http://www.csszengarden.c...m/extra/zen/zengarden.css
probeer dit maar eens met tabellen en zonder javascript (wel ff in ene css2 compatible browser kijken (nee dus niet inIE))

[ Voor 8% gewijzigd door Spruit_elf op 14-08-2004 13:16 . Reden: ff mijn toon iets aangepast wil geen flamewar of ruzies :) ]

[crisp]

BalusC schreef op 12 augustus 2004 @ 11:36:
8px wordt ook gebruikt op de Frontpage en op de GoT Silver template en het leest uitstekend De fontsize in de tabellen is overigens idd kleiner: 7px.

silver gebruikt 11px voor de content (en dat is al klein) en voor sommige elementen 10px of 9px. De normale GoT template en de nieuwe template gebruiken 13px voor de content...

[ Voor 3% gewijzigd door crisp op 14-08-2004 15:28 ]

[PrisonerOfPain]

OzBoz schreef op 12 augustus 2004 @ 12:04:
Maar dan zit je weer met het probleem dat 12pt op PC anders is dan 12pt op Mac.

Want? 1 punt is toch 1/72'ste inch of mis ik iets?

[Verwijderd]

Maar een Mac zit op 96 DPI. (Of 92, iig anders dan Windows en ja, sommige Macs hebben dat verschil niet.)

'px' is iig consequenter.