Scrollbar werkt niet correct

[Bitbored]

Als een soort van eindwerk moeten we een website maken, in ons geval een website die veel gelijkt op tweakers, maar dan wat eenvoudiger en moderner...

Het grootste nadeel: er is niemand in onze groep die echt goed overweg kan met css en opmaakcode...

Het hoofddeel van onze website is een container die in het midden van het scherm blijft staan, maar nu is het zo dat als je het scherm te klein maakt, een gedeelte gewoon onbereikbaar wordt, je kan er niet naartoe scrollen...

Het is waarschijnlijk een heel belachelijke en basic fout, want vrijwel elke website doet dit wel correct...

ik vermoed dat de fout hier ergens moet zitten:

Cascading Stylesheet:

#container
{
    position: relative;
    background: #f5f3ef;
    width: 1000px;
    height: auto;
    left: 50%;
    margin-left: -500px;
    top: 225px;
}

De website is http://www.convergeonline.be voor als je het resultaat hiervan wil zien...

Ik ben al 2 dagen w3schools aan het afzoeken naar een oplossing, maar tot nu toe geen succes, miss kan iemand me hier vlugger helpen?

[NMe]

Vervang die margin-left: -500px eens door margin: 0 auto

[crisp]

Inderdaad; het nadeel van centreren met de negatieve-margin truuk is dat inhoud niet meer bereikbaar is bij een te smalle resolutie - niet gebruiken dus.

Verder zitten er nog wat grove foutjes in je broncode; zo zie ik bijvoorbeeld dit:

HTML:

<img src="http://bit.ly/9GYapd"" alt="" style="width:757px;height:auto"/>

en even verderop dit:

HTML:

<img src='http://bit.ly/9GYapd"' alt="" />

Dat levert hetzelfde plaatje op, maar feitelijk zijn het andere requests door de fouten; je index pagina is daardoor al ruim 800KB zwaarder dan noodzakelijk (en hij is al zwaar).

Verder vraag ik me af wat je hiermee bedoelt:

in ons geval een website die veel gelijkt op tweakers, maar dan wat eenvoudiger en moderner...

en dan met name met 'moderner'; als dat het gebruik van faux XHTML is en misbruik van tables voor layout dan moet ik hier denk ik maar eens gaan voorstellen om onze HTML5 doctype te gaan vervangen

[Bitbored]

NMe schreef op zondag 31 januari 2010 @ 01:16:
Vervang die margin-left: -500px eens door margin: 0 auto

mmh, did not do the trick, ik heb wat verschillende combinaties gebruikt van auto en x aantal px, maar nog geen goed resultaat tot hiertoe...

crisp schreef op zondag 31 januari 2010 @ 11:18:
Inderdaad; het nadeel van centreren met de negatieve-margin truuk is dat inhoud niet meer bereikbaar is bij een te smalle resolutie - niet gebruiken dus.

Verder zitten er nog wat grove foutjes in je broncode; zo zie ik bijvoorbeeld dit:

HTML:

<img src="http://bit.ly/9GYapd"" alt="" style="width:757px;height:auto"/>

en even verderop dit:

HTML:

<img src='http://bit.ly/9GYapd"' alt="" />

Dat levert hetzelfde plaatje op, maar feitelijk zijn het andere requests door de fouten; je index pagina is daardoor al ruim 800KB zwaarder dan noodzakelijk (en hij is al zwaar).

Ik geloof dat dit code is van de slider, tesamen met een afbeelding die opgehaald wordt in een van onze artikels (die momenteel allemaal copy-paste zijn van engadget en tweakers om te testen...

crisp schreef op zondag 31 januari 2010 @ 11:18:
Verder vraag ik me af wat je hiermee bedoelt:

[...]

en dan met name met 'moderner'; als dat het gebruik van faux XHTML is en misbruik van tables voor layout dan moet ik hier denk ik maar eens gaan voorstellen om onze HTML5 doctype te gaan vervangen

Moderner is misschien verkeerd uitgedrukt, maar vooral eenvoudiger en simplistischer, en met een beetje een moderne look...
...maar met de weinige kennis van css wordt dit vrij moeilijk.

Wat heeft iedereen toch tegen tables btw, het is een van de enige dingen die ik echt logisch vindt werken in html, en css is wel goed gevonden, maar waarom zijn de standaarden op verschillende browser nu in godsnaam anders -.-

Toch bedankt voor de reacties

[RobIII]

Bitbored schreef op zondag 31 januari 2010 @ 14:22:
Wat heeft iedereen toch tegen tables btw

Ze zijn semantisch niet correct en daarbij een pain in the ass om te onderhouden (zeker als je tables in tables in tables hebt etc.).

Bitbored schreef op zondag 31 januari 2010 @ 14:22:
het is een van de enige dingen die ik echt logisch vindt werken in html

Ze werken ook logisch; echter zijn ze bedoeld voor tabulaire data en niet voor layout

Bitbored schreef op zondag 31 januari 2010 @ 14:22:
en css is wel goed gevonden

En juist bedoeld voor layout/stijl
Het idee is dat je content (inhoud) semantisch omschrijft (dus een list (ul/ol) gebruiken waar je een lijst nodig hebt, een tabel waar je tabulaire data hebt, een paragraph (p) voor een alinea etc. etc.) en opmaak hoort daar niet in thuis. Waar je vroeger heel de zut in 1 HTML document gooide heb je nu mooi content en opmaak gescheiden dankzij css.

Bitbored schreef op zondag 31 januari 2010 @ 14:22:
maar waarom zijn de standaarden op verschillende browser nu in godsnaam anders -.-

Historische redenen, vendors die doen waar ze zelf zin in hebben (MS), implementatieverschillen, bugs en verschillende interpretaties van soms vage standaarden. To name a few. Echt niet om Bitbored te plagen hoor

Mierenneukmode: De standaarden zijn overal dus hetzelfde (er is maar 1 standaard); ze worden alleen niet altijd cross-browser even goed nageleefd.

[ Voor 17% gewijzigd door RobIII op 31-01-2010 14:42 ]

[Spinal]

Bitbored schreef op zondag 31 januari 2010 @ 14:22:
[...]
mmh, did not do the trick, ik heb wat verschillende combinaties gebruikt van auto en x aantal px, maar nog geen goed resultaat tot hiertoe...

Afstappen van Transitional en in plaats daarvan Strict gebruiken wil nog wel eens helpen in dit geval, zeker in IE. In welke browser(s) test je?

[crisp]

ZanderZ schreef op zondag 31 januari 2010 @ 15:10:
[...]

Afstappen van Transitional en in plaats daarvan Strict gebruiken wil nog wel eens helpen in dit geval, zeker in IE. In welke browser(s) test je?

Strict of transitional maakt niet uit voor browsers, da's enkel nuttig voor de validator.

Wel is het zo dat je bij margin:0 auto natuurlijk ook je position:relative en je left:50% weg moet halen

[Saven]

Waarom position relative gebruiken?
Gewoon een width meegeven, en de left en right margin op auto zetten moet werken toch? Of roep ik nu te snel maar iets?

[crisp]

Saven schreef op zondag 31 januari 2010 @ 18:16:
Waarom position relative gebruiken?
Gewoon een width meegeven, en de left en right margin op auto zetten moet werken toch? Of roep ik nu te snel maar iets?

Nee, je roept het te laat

[kaesve]

ik denk dat ik je probleem vrij simpel is.. je hebt waarschijnelijk je margin-left: -500px vervangen met margin: 0 auto; of simpele varianten erop, maar bent dan 'vergeten' om je left: 50% weg te halen.. het werkt hier in firefox namelijk prima als ik die aanpassing doorvoer met firebug :]

[NMe]

Niet om lullig te doen, maar dat zeggen de twee mensen vlak boven je ook al.

[Bitbored]

yup, it works!!!!

Je hebt mij net overdreven gelukkig gemaakt door het oplossen van zo'n dom foutje, maar je wil niet weten hoe veel tijd ik daar al heb in gestoken

Bedankt!

[mcDavid]

crisp schreef op zondag 31 januari 2010 @ 18:09:
[...]

Strict of transitional maakt niet uit voor browsers, da's enkel nuttig voor de validator.

Wat wél kan helpen is het doctype zoals voorgeschreven te beginnen op de eerste positie van het document.

Anders heeft IE er volgens mij gewoon schijt aan.

[Bitbored]

mmh, de oplossing was blijkbaar nog steeds niet perfect, want de container blijft nu een pixel of 5 van de linkerkant verwijdert, waardoor hij bij een resolutie van 1024px al een scrollbar geeft, wat niet de bedoeling is...

Daarom dus maar left:-5px toegevoegd, en het werkte nog ook

Er is nu nog wel iets vreemd aan de hand met de menubar en de header, dus ik kan me de komende dagen nog wat bezighouden op w3schools...

[crisp]

mcDavid schreef op zondag 31 januari 2010 @ 22:06:
[...]


Wat wél kan helpen is het doctype zoals voorgeschreven te beginnen op de eerste positie van het document.

quote: http://www.w3.org/TR/html401/struct/global.html#h-7.1

An HTML 4 document is composed of three parts:

1. a line containing HTML version information,
2. a declarative header section (delimited by the HEAD element),
3. a body, which contains the document's actual content. The body may be implemented by the BODY element or the FRAMESET element.

White space (spaces, newlines, tabs, and comments) may appear before or after each section. Sections 2 and 3 should be delimited by the HTML element.

White space voor een DTD is geen probleem en gooit ook IE niet in quirksmode

[ Voor 3% gewijzigd door crisp op 31-01-2010 22:53 ]

[crisp]

Bitbored schreef op zondag 31 januari 2010 @ 22:34:
mmh, de oplossing was blijkbaar nog steeds niet perfect, want de container blijft nu een pixel of 5 van de linkerkant verwijdert, waardoor hij bij een resolutie van 1024px al een scrollbar geeft, wat niet de bedoeling is...

Daarom dus maar left:-5px toegevoegd, en het werkte nog ook

Da's weer typisch een geval symptoombestrijding zonder na te gaan wat nu eigenlijk de oorzaak is (giveaway: standaard margin/padding van het body element).

Bij deze een tip: probeer niet meteen terug te vallen op vieze hacks, dat levert je gaandeweg enkel meer problemen op...

[Bitbored]

crisp schreef op zondag 31 januari 2010 @ 23:00:
[...]

Da's weer typisch een geval symptoombestrijding zonder na te gaan wat nu eigenlijk de oorzaak is (giveaway: standaard margin/padding van het body element).

Bij deze een tip: probeer niet meteen terug te vallen op vieze hacks, dat levert je gaandeweg enkel meer problemen op...

Tja, ik weet het, ik moet terugvallen op waarschijnlijk nubisch manieren, gewoon omdat ik er geen andere ken...

Ik heb het geprobeerd door de padding van de body op nul te zetten, maar geen succes...
Er zit waarschijnlijk nog ergens iets tussen.


Mmmh, of het lukt blijkbaar toch wel, bedankt
En bedankt voor die link ook trouwens, er staan dingen in die ik niet vond op w3shools.

Wat is dat trouwens met die "standaard waardes", en niet gewoon nul, ook weer een stukje geschiedenis?

[ Voor 9% gewijzigd door Bitbored op 01-02-2010 20:40 ]

[mcDavid]

Bitbored schreef op maandag 01 februari 2010 @ 20:29:
[...]


Tja, ik weet het, ik moet terugvallen op waarschijnlijk nubisch manieren, gewoon omdat ik er geen andere ken...

www.w3schools.com, ga je maar inlezen dan!

Ik heb het geprobeerd door de padding van de body op nul te zetten, maar geen succes...
Er zit waarschijnlijk nog ergens iets tussen.

de paddin EN de margin? En ook van het html-element?

Wat is dat trouwens met die "standaard waardes", en niet gewoon nul, ook weer een stukje geschiedenis?

nee, dat is een stukje standaard.

[crisp]

Bitbored schreef op maandag 01 februari 2010 @ 20:29:
[...]
Wat is dat trouwens met die "standaard waardes", en niet gewoon nul, ook weer een stukje geschiedenis?

Ja en nee; het is gewoon een stukje default opmaak die browsers aan bepaalde elementen geven. De manier waarop ze dat doen verschilt wel per browser omdat er geen standaard is die dat voorschrijft. Derhalve zijn er ook mensen die prediken om dat met behulp van een zogenaamde 'reset-stylesheet' geheel ongedaan te maken alvorens daar zelf styling aan toe te kennen. Ik behoor overigens niet tot die groep omdat het 'resetten' van alle margins en paddings vaak tot meer werk leidt dan het specifiek aanpassen daar waar het nodig is.

Voor de body is het daarom ook noodzakelijk om zowel de margin als de padding aan te passen om crossbrowser hetzelfde effect te krijgen (het HTML element heeft itt wat mcDavid hierboven suggereert overigens naar mijn weten in geen enkele browser standaard padding of margin).

[curry684]

Bitbored schreef op zondag 31 januari 2010 @ 01:09:
Als een soort van eindwerk moeten we een website maken [...]

er is niemand in onze groep die echt goed overweg kan met css en opmaakcode [...]

ik heb wat verschillende combinaties gebruikt van auto en x aantal px, maar nog geen goed resultaat tot hiertoe [...]

Wat heeft iedereen toch tegen tables btw, het is een van de enige dingen die ik echt logisch vindt werken in html, en css is wel goed gevonden, maar waarom zijn de standaarden op verschillende browser nu in godsnaam anders -.-[...]

mmh, de oplossing was blijkbaar nog steeds niet perfect, want de container blijft nu een pixel of 5 van de linkerkant verwijdert, waardoor hij bij een resolutie van 1024px al een scrollbar geeft, wat niet de bedoeling is... Daarom dus maar left:-5px toegevoegd, en het werkte nog ook

Durf ik te vragen voor welke opleiding je een eindopdracht aan het doen bent?

[R4gnax]

crisp schreef op zondag 31 januari 2010 @ 18:09:
[...]

Strict of transitional maakt niet uit voor browsers, da's enkel nuttig voor de validator.

Nee, dat klopt niet. Transitional doctypes triggeren in bijv. Gecko browsers de 'almost standards' mode.

Er is hier een subtiele verschil wat voor pixel-perfecte designs desastreus kan zijn, en dat gaat wat verder dan de standaard use case die het MDC beschrijft.

Je hebt zgn. replaced elements: elementen waarvan de dimensies en verschijning door een externe bron geregeld worden. Denk hierbij aan de img tag, de object tag, maar ook de verschillende input tags (die verschillend renderen op basis van het OS, een geselecteerd theme, etc.). Deze hebben zgn. intrinsic dimensions: ingebouwde dimensies, waaronder dus een hoogte.

In 'Almost Standards' mode zal de hoogte van de tekst lijn, de zgn. line box, zich voegen naar de hoogste intrinsic height (ingebouwde hoogte) die er op de tekst lijn aangetroffen wordt en niet meer, mits er niet een daarmee conflicterende waarde ingesteld is m.b.v. de CSS line-height property

Het standaard voorbeeld, hoewel het tegenwoordig echt bad practice is, is dat table-cells op deze manier naadloos aan blijven sluiten wanneer ze img tags bevatten die een plaatje 'slicen'. Maar er zijn zeker andere use-cases te bedenken. Neem bijvoorbeeld een Flash object wat naadloos moet passen.

In 'Standards' mode zit dit anders in elkaar: daar voegt de hoogte van de line box zich naar de hoogste inline-box. Om tot de hoogte van de inline-box van een inline element te komen neemt men de (intrinsic) height en, afhankelijk van de vertikale plaatsing met de CSS vertical-align property, telt men daar een aantal keren de zgn. half-leading (spreek uit "ledding", als in lood) bij op. De half-leading is de helft van het verschil tussen de lijn hoogte en de em-hoogte v/h op dat moment gebruikte font.

Als een inline replaced element op de basis lijn (vertical-align: "baseline") van de tekst staat - De standaard instelling. - komt er bijvoorbeeld onderaan nog een extra half-leading bij, waar de inline box van de tekst nog onder de inline box van het replaced element uit steekt en de line box oprekt.

Dat soort zaken is in pixel-perfecte stukken van je design heel belangrijk wanneer je verder overal werkt met een font grootte die in em-hoogte gegeven is. Het herschalen van de tekst heeft dan nl. ook invloed op de grootte van deze half-leading en dus kan er bij het zoomen ineens 'magisch' ongewenste witruimte ontstaan (mits je daar al niet last van had op de standaard zoom factor).

[TheBorg]

De mooiste doctype is deze:

code:

<!doctype html>

Is eigenlijk voor HTML5, maar het renderd(t)? hetzelfde als HTML 4.01 Strict en het werkt in alle browsers. Google.com gebruikt het ook al een tijdje.

[curry684]

TheBorg schreef op dinsdag 02 februari 2010 @ 00:30:
De mooiste doctype is deze:

code:

<!doctype html>

Is eigenlijk voor HTML5, maar het renderd(t)? hetzelfde als HTML 4.01 Strict en het werkt in alle browsers. Google.com gebruikt het ook al een tijdje.

En helaas nog niet onderdeel van een W3C recommendation waardoor je er nog niet mee door Kwaliteitsmodel Webrichtlijnen komt als je klant dat toevallig boeit. Afgezien daarvan: vooral doen. Tis ook niet zozeer een HTML5 doctype als wel een 'generiek doctype' dat in-document versionering van HTML overbodig en impliciet moet maken.

[TheBorg]

curry684 schreef op dinsdag 02 februari 2010 @ 00:35:
En helaas nog niet onderdeel van een W3C recommendation waardoor je er nog niet mee door Kwaliteitsmodel Webrichtlijnen komt als je klant dat toevallig boeit. Afgezien daarvan: vooral doen. Tis ook niet zozeer een HTML5 doctype als wel een 'generiek doctype' dat in-document versionering van HTML overbodig en impliciet moet maken.

De validator poept al HTML5.

[curry684]

TheBorg schreef op dinsdag 02 februari 2010 @ 00:48:
[...]

De validator poept al HTML5.

En? Dat de validator een working draft slikt staat compleet los van dat ik zei dat een Nederlands overheids-initiated kwaliteitsmodel 'm niet slikt.

[NMe]

Bovendien is de validator een hulpmiddel en geen doel op zich.

[crisp]

R4gnax schreef op dinsdag 02 februari 2010 @ 00:19:
[...]


Nee, dat klopt niet. Transitional doctypes triggeren in bijv. Gecko browsers de 'almost standards' mode.

Dat klopt, en ik weet inderdaad wat de verschillen zijn - ik ging hier wat kort door de bocht wat dat betreft

curry684 schreef op dinsdag 02 februari 2010 @ 01:01:
[...]

En? Dat de validator een working draft slikt staat compleet los van dat ik zei dat een Nederlands overheids-initiated kwaliteitsmodel 'm niet slikt.

De overheids richtlijnen zijn zo slecht nog niet; ik kan me een aantal discussies herinneren ruim een jaar terug, onder andere over de eis dat header-niveaus niet overgeslagen mochten worden en dat een document maar één H1 mocht bevatten waar ik tegenin bracht dat dat erg lastig is bij bijvoorbeeld mash-ups of een overzicht van artikelen die standaard al voorzien zijn van een H1, en dat de hyarchie meer volgt uit de nesting dan uit het nummertje (iets wat HTML5 ook onderschrijft). Ik zie nu dat het ook geen verplichte eis meer is

Het gaat inderdaad wat ver om richtlijnen al aan te passen aan toekomstige specificaties. Tel daarbij op dat ook de HTML5 validator nog lang niet 'compleet' is aangezien de specificatie dat ook niet is. Tweakers.net gebruikt ook sinds enige tijd een 'HTML5' doctype, maar valideert ook niet volledig. Ik kan echter onderbouwen waarom het niet valideert, en misschien zijn dat zelfs redenen om de specificatie aan te passen (het opgeven van cellspacing=0 is bijvoorbeeld nog steeds noodzakelijk voor IE7 die CSS border-spacing nog niet ondersteunt).