Probleem CSS font maat

[Verwijderd]

Hallo,

Ik heb een probleem met een menu welke ik gemaakt heb met DreamWeaver.

Allereerst de link waar het gebeuren op staat: http://www.relaxcharters.nl/relax/relax.php

Probleem: Het menu bovenaan werkt op zich prima. Alleen op het moment dat ik mijn CSS bestandje neer plakte in de pagina voor de standaard layout van de pagina, trad er ineens een fout op bij het menu: Tussen de eerste 3 buttons zit ineens geen wit rand meer. (In IE sluiten ze ineens naadloos op elkaar aan, in Firefox gaan ze over elkaar heen zelfs.)

Onderzoek: Nu heb ik steeds kleine beetjes script weggehaald in de layout.css . Op het moment dat ik het gedeelte font-size weghaalde voor een tabel, was het menu weer normaal. Gevolg is natuurlijk dat de tekst dan een stuk groter word.
Op het moment dat ik de font-size bijvoorbeeld vergroot en op 12pt zet, krijg ik ook weer meer witruimte tussen de buttons.

Tip: Zowel in de SpryMenuBarHorizontal.css en in de layout.css wordt geschreven over een font-size. Ik vermoed dan ook dat hier het probleem zit.

Vraag: Lijkt me duidelijk: Hoe los ik dit op!

Ps, Ik heb geen code's geplaatst aangezien ik niet precies weet waar het probleem zit. Uiteraard kunnen de bestandjes gewoon opgevraagd worden via je eigen explorer.

Ik hoop op een antwoord!

[ Voor 0% gewijzigd door Verwijderd op 24-10-2008 19:29 . Reden: Spelfouten ]

[Fietslamp398]

verander in het stukje ul.MenuBarHorizontal li {} in SpryMenuBarHorizontal.css de waarde "width: 8em" naar "width: 10em".

Maarja, aan alleen een fix hebben we niks, dus nu het leermoment :
Als je frontend (html/css/js) aan het debuggen bent is het essentieel dat je de Firebug extensie van Firefox gebruikt. Hiermee kan je "live" dingen in je site veranderen in je browser. Zodoende vond ik dit binnen 10 sec (ik heb verder niet naar je code gekeken)

dus, hoppa richting: www.getfirebug.com

[Kiphaas7]

offtopic:
Je beseft dat je site in quirksmode wordt gerenderd door het ontbreken van een doctype, dat je het html element wel sluit maar niet opent, en dat je tabellen gebruikt met deprecated attributes om je layout te verzorgen?

[Verwijderd]

@Fietslamp398: Mooi, het werkt! Thx!
Maar om nog even terug te komen op dat proggie? Wat doet het precies? Ik heb de add-on einstalleerd, mar ik krijg het idee dat ik er alleen maar een brondcode mee kan lezen. Als ik er opzettelijk een foutje in zet, ziet hij dat verder niet. Hoe moet ik dat zien?

@Kiphaas7: Het begrip quirksmode had ik nog nooit van gehoord. Maar na enig research heb ik dan toch maar de Doctype terug geplakt die ik juist altijd uit alle pagina's trok!
html open element is waarschijnlijk destijds per ongeluk samen met de doctype gesneuveld! (A)
En met het laatste punt begrijp ik niet helemaal wat je bedoeld. Depricated Attributes houdt toch in dat er vernieuwde versie codes van zijn?

[Kiphaas7]

Verwijderd schreef op zaterdag 25 oktober 2008 @ 02:59:
@Fietslamp398: Mooi, het werkt! Thx!
Maar om nog even terug te komen op dat proggie? Wat doet het precies? Ik heb de add-on einstalleerd, mar ik krijg het idee dat ik er alleen maar een brondcode mee kan lezen. Als ik er opzettelijk een foutje in zet, ziet hij dat verder niet. Hoe moet ik dat zien?

@Kiphaas7: Het begrip quirksmode had ik nog nooit van gehoord. Maar na enig research heb ik dan toch maar de Doctype terug geplakt die ik juist altijd uit alle pagina's trok!
html open element is waarschijnlijk destijds per ongeluk samen met de doctype gesneuveld! (A)
En met het laatste punt begrijp ik niet helemaal wat je bedoeld. Depricated Attributes houdt toch in dat er vernieuwde versie codes van zijn?

Een tabel is bedoeld voor tabulaire data, jij gebruikt het element op dit moment om de globale site layout vast te leggen. Dat zou je beter kunnen doen met het (betekenisloze) div element.

het vergt wel iets meer kennis en/of onderzoek om de site dan werkend te krijgen, en ik kan me enigzins voorstellen dat je daar weinig zin in hebt, aangezien de site nu ook werkt.

Over de deprecated attributes, die opmerking klopte eigenlijk niet helemaal, aangezien deze eigenlijk samenhangen met een doctype; echter ervan uitgaand dat je html4.01 strict zou gebruiken mag je niet meer attributen zoals background of align gebruiken in je tabellen (Dat los je op met css).

In een ideale wereld geef je betekenis aan je content met html elementen (p = paragraaf, em = nadruk, strong = sterke nadruk, table = tabulaire data, ul = unordered list, etc etc), stijl je die elementen met css, en wijzig en/of voeg je gedrag toe met javascript.

Zou je dat doen dan kan je het uiterlijk veranderen door alleen veranderingen aan te brengen in het css bestand. Dat is overzichtelijker en uiteindelijk makkelijker voor jezelf.

[ Voor 13% gewijzigd door Kiphaas7 op 25-10-2008 10:18 . Reden: ideologisch blaatverhaal ]

[Fietslamp398]

Als je meer wilt leren over de basis van Firebug, dan kan je misschien het beste even dit filmpje bekijken:
http://files.jnewland.com/firebug.mov

En zoals Kiphaas al aangeeft, dient html gebruikt te worden zoals het bedoel is. Dus tabel data in en tabel, en niet te gebruiken om een lay-out te maken.

Het is goed te begrijpen dat je via DreamWeaver html/css op deze manier gebruikt (ik kan me talloze sites bedenken die ik zo gemaakt heb). Echter als je ECHT html/css wil gebruiken dan is het beter als je je er wat verder in verdiept. Ikzelf heb een boek gelezen over webstandards, en dat heeft me goed geholpen om volgens de standards te coden.

http://simplebits.com/publications/solutions/

Het grote voordeel van Firebug is ook dat je met die tool altijd makkelijk op andere sites kan kijken hoe men bepaalde problemen heeft opgelost.

[Verwijderd]

Het filmpje zal ik eens een keer gaan bekijken..

Maar goed, in principe zeggen jullie dus dat ik script op een noob manier!
Maar zoals 1 van jullie al zei, het werkt, dus eigenlijk maakt het ook niet zoveel uit. Maar toch, ik sta open!
Kortom, mijn volgende vraag, kan het problemen opleveren op de manier zoals ik nu script? Afgezien van de makkelijkheid voor het wijzigen van een css?

En, om even een beeld te krijgen, de hoofdwebsite die nu nog op de pagina staat: http://www.relaxcharters.nl
Dit is dus wel op de 'juiste' manier gescript?

[Kiphaas7]

Divjes ipv tabellen gebruiken is maar het halve verhaal, en eigenlijk net zo "fout". -> Het hele juiste element op de juiste plek gebruiken.

Op je hoofdpagina gebruik je de <center> tag (los op met css), inline styles(stop ze in een extern css bestand), span classes ipv betekenisvolle tags (een paar p elementen zouden hier niet misstaan...).

Dus nee, de hoofdpagina is ook "fout", maar op een andere manier.

Als je weet wat je doet met semantiek, html elementen en css, dan krijg je in theorie een veel efficientere en makkelijk te onderhouden pagina. Maar nogmaals, daar gaat tijd en moeite inzitten voordat je zover bent. En dan nog willen sommige browsers raar doen.

Heb je daar geen zin in, doe het dan op de manier die jij het beste kan, maar dit soort rare fouten zijn lastig te traceren voor jou omdat je dreamweaver gebruikt. Zou je de site zelf hebben gemaakt, dan heb je ook een beter beeld waar de fout zit, en kan je zelf gaan zoeken/googlen hoe het op te lossen. Dreamweaver is leuk speelgoed, totdat het fout gaat.

[Fietslamp398]

Maar de hele vraag is natuurlijk, wil jij (of iemand anders) de tijd en energie erin steken om een semantisch goede website te maken.

Met Dreamweaver zijn zonder veel kennis redelijke sites te maken. En zo zou je de meeste sites die je wil maken wel kunnen creeren. Maar wil je ECHT goede sites maken, die ook goed opgepakt worden door zoekmachines, vaker cross-browser te fixen zijn, goed te onderhouden zijn en makkelijk in een team van ontwikkelaars gebruikt kan worden, dan lijkt het me belangrijk het begrip "semantic webdesign" eens uit te zoeken.

Dit hoeft overigens niet veel tijd te kosten. Ik denk dat je na 1 weekend research al 90% van alle kennis kan opnemen.

[Verwijderd]

Okee.. Maar dan lopen we nu een beetje langs elkaar heen. Of eigenlijk, de manier van werken van mij is toch iets anders dan jullie in gedachten hebben!

Ik wil niet zeggen dat ik alles uit mn hoofd kan, maar ik gebruik Dreamweaver meer voor de makkelijkheid van de kleurtjes en het bepalen van een positie enzo. Snel een tabelletje maken, etc. . In principe zou ik DW dus niet nodig hebben om een pagina te maken.
Daarbij, maak ik meestal 1 standaard pagina, waar ik vervolgens met php lege layout loze pagina's met de inhoud ga includen.

Kortom, door het maken van 1 pagina voor de layout, kan ik de inhoud makkelijk aanpassen. Ik denk niet dat het makkelijker is dat ik voor die ene pagina een heel css gebeuren ga opzetten, toch?

Desondanks zal ik toch even kijken naat het semantic webdesign.

In elk geval bedankt voor de tot nu toe getoonde grote hulp vaardigheden!

[DiSiLLUSiON]

Mocht je meer interesse hebben in het visuele aspect van een website dan de achterliggende code, dan kan ik me dat best voorstellen. Ieder zo z'n ding; en daar zijn dit soort programma's dan ook voor. Maar wees je dan wel bewust welke programma's behoorlijk acceptabele code uit 'poepen', en welke dat niet doen. En ook wat dit voor gevolgen heeft voor aanpassingen op je website als 'ie eenmaal online staat.

Bij een recent onderzoek van Opera naar de correctheid van online websites, waaronder ze ook hebben berekend hoeveel procent van de pagina's gemaakt in een bepaalde editor valideren, kwamen deze resultaten naar voren:

Editor	Total URLs In MAMA	Quantity Passing Validation	Percentage Passing Validation
Apple iWeb	2.504	2.051	81.9% (!)
Adobe Dreamweaver	5.954	205	3.4%
Netobjects Fusion	26.355	1.086	3.0%
Adobe GoLive	41.865	1.086	2.6%

de rest komt onder de 2%.

Nu zegt dit natuurlijk ook niet alles, maar misschien is het een idee om dan even naar apple iWeb te kijken, mits je toegang hebt tot een Mac. Ik heb het zelf nog nooit geprobeerd; dus ik weet niet hoe het werkt.

[ Voor 3% gewijzigd door DiSiLLUSiON op 27-10-2008 09:52 ]

[Kiphaas7]

DiSiLLUSiON schreef op maandag 27 oktober 2008 @ 09:51:
Nu zegt dit natuurlijk ook niet alles

Sterker nog, in datzelfde artikel:

The role of the validator has been likened to that of a "spell-checker" for Web page structure. A validator alone will not make your page better...a page that passes validation can still look or behave terribly, and a page with hundreds or even thousands of errors can still produce a reasonable user experience in most browsers.

A validator simply catches errors. We all make mistakes, even the experts. The worst mistakes are often the typos or unintentional gaffes; a validator can make easy work of catching these. Authors should validate—it's an easy process. This is not a conundrum; validate your code and do it often.

[ Voor 9% gewijzigd door Kiphaas7 op 27-10-2008 10:49 ]

[DiSiLLUSiON]

Valideren is geen doel opzich, nee. Maar, ik had het hier dan ook niet over user experience, of vormgeving, of logische indeling van de content. Het ging over programma's als Dreamweaver. Op het moment dat iemand weinig van de code weet of wilt weten, is het verstandiger om een website te maken in een programma dat over het algemeen wél fatsoenlijke code maakt, dan een programma dat dat in 99,9% van de gevallen niet doet. De rest komt of met ervaring, of niet.

[ Voor 5% gewijzigd door DiSiLLUSiON op 27-10-2008 10:58 ]

[Kiphaas7]

DiSiLLUSiON schreef op maandag 27 oktober 2008 @ 10:58:
Valideren is geen doel opzich, nee. Maar, ik had het hier dan ook niet over user experience, of vormgeving, of logische indeling van de content. Het ging over programma's als Dreamweaver. Op het moment dat iemand weinig van de code weet of wilt weten, is het verstandiger om een website te maken in een programma dat over het algemeen wél fatsoenlijke code maakt, dan een programma dat dat in 99,9% van de gevallen niet doet. De rest komt of met ervaring, of niet.

Ik wist wel dat je dat bedoelde, maar toch wilde ik het nog even benadrukken.