Archief - Enkele CSS vragen

Hallo iedereen, ik ben volop bezig met een nieuw concept uit te denken maar ik kom steeds bij dezelfde problemen terecht.
In welke mate kan je "grote" afbeeldingen gaan gebruiken, welke fonts zijn nu wel of niet browser compatibel ed.

1: Achtergrondafbeelding
-Extensie: Volgens mij een gif om sneller te laden maar tot welke grote moet je je proberen beperken. Het is niet de bedoeling dat je na 2 min zegt, ah een achtergrond ook..
Achtergrond afbeelding laten "rekken" en welke basisresolutie, aanpassen op een grote resolutie met gevolg dat sommigen enkel de helft zien, de grote resoluties in de steek laten.

2: Font
Ik vind op veel sites leuke fonts terug maar vraag me af of ze alle wel degelijk cross browser, cross platform zijn.
De standaard fonts als een arial, georgia, helvetica ed zijn vanzelfsprekend.
Maar dan die als Lucidia, Rockwell, Trebuchet MS.
Heeft iemand een link of weet iemand welke kunnen en welke niet.

Er zijn methoden om met JS alle fonts te gebruiken maar dat is voor later.
Eerst stappen voor het lopen.

3: Browser, host snelheid, internetverbinding
Wat zijn de voornaamste factoren die ervoor zorgen dat een site traag gaat laden?
Kan je dat sneller laten verlopen door bepaalde technieken?

4: Symantisch website opbouwen (code)
Het is een ongeloofelijke hype geworden waardoor er soms heel wat in de creativiteit wordt uitgespaard.
Dit met de grootste reden, SEO. Is het nodig om daar ook rekening mee te gaan houden als je traffic via een zoekmachine maar 10% bedraagd? Het is natuurlijk nodig om een overzichtelijke, gebruiksvriendelijke site te maken. Maar dat is ook mogelijk met 2keer de divs die je zou nodig hebben.

Graag wat feedback.
Ik weet dat alles op google te vinden is maar ik kom niet op de juiste antwoorden.
Ik hoop van jullie ervaring gebruik te kunnen maken.

1. Ge gebruikt een afbeeldingstype dat het beste bij uw afbeelding past. Hebt gij een pattern met 2 kleuren in dan pakt ge een gif. Hebt gij echter een gewone foto dan pakt ge een jpeg. En bij afbeeldingen met weinig detail met meer dan 256 kleuren, vaak ook met halftransparantie kiest ge voor PNG-24.

En iets redelijk van filesize.. Goh, blijf liefst onder de 100KB grens zou ik zeggen. Dat zijn dingen waar ik meestal niet zo op let omdat dat in mijn ontwerpen wel redelijk goed uitkomt. Maar ga gewoon geen echt grote afbeeldingen als achtergrond zetten, behalve als ge echt weet waar ge mee bezig zijt (in productsites, die dan nog voornamelijk in Flash worden gemaakt ziet ge het wel eens terugkomen).

2. Common fonts to all versions of Windows & Mac equivalents (Browser safe fonts) - Web design tips & tricks En die SiFR-achtige scripts zijn ook niet zo ideaal. Ze bieden u als webdesigner meer vrijheid, maar wel op de rug van uw gebruiker. Wees er dus 'voorzichtig' mee.

3. Uw site sneller laten laden lijkt me simpel? Zoweinig mogelijk overbodige afbeeldingen en de gebruikte afbeeldingen op de juiste manier comprimeren. Gebruikt gij een afbeelding die eigenlijk 1024*768 groot is en plaatst ge een thumb van 100*xx gaat dat zoveel goeds veroorzaken.

4. SEO is iets.. Goh ja, dunno. 't Begint met semantisch te werken. Maar dat doe ik voor de gebruiker, en gewoon omdat het zo 'hoort', niet voor google.
En als uw traffic via zoekmachines momenteel maar 10% bedraagt is eigenlijk onbelangrijk. Ge kunt uw aantal bezoekers er wel mee verhogen, en dan zullen die later ook via hun favorieten terugkomen en niet via de zoekmachines. Maar die bezoeker hebt ge er wel bijgekregen.

Nu, voor SEO zijn er wel meer dingen belangrijk dan semantische code. Linking, aantal updates, etc.. Gewoon wat artikeltjes over doornemen.

'k Heb't kort gehouden, anders wordt dat hier toch niet gelezen.

het wordt wel degelijk gelezen.
Alvast bedankt voor je antwoord

1 Over een grote afbeelding dan bedoel ik als dit Drumbeat!

2 Daarom ook juist dat ik liever niet met die JS oplossingen werk.
Op deze site was ik ook al gekomen, op een anders site kwam ik inline zonder sifr de rockwell font tegen. Is dat iets dat iedereen standaard heeft, dus ook kan gebruikt worden al dat het geen webfont is?

3 de tumbs is een logische oplossing. Het ding is dat ik op een pagina zo een 50tal thumbs moet laden 100x100, dat duurt lang en misschien was er een of andere verdoken techniek om dat toch wat sneller te laten verlopen.
Met comprimeren bedoel je dan de juiste extensie?

4 Ik ben me er zeker van bewust dat SEO meer inhoud dan een mooie code afleveren. Het gaan me vooral om of het echt een berg van verschil zou uitmaken <div><tag></div> ipv <tag> met extra opmaak, inline afbeeldingen voor layout. Zeker als je zoekmachine traffic laag is.

wat mij direct opvalt bij dieje webdrumbeat is dat deze ook geen list rond zijn listitems zet
loooool

daar gaat het hem nu ook niet derect over, eerder over de afbeelding op de achtergrond.

1) Degradation is the word: zorgen dat je hele site zonder images er vlekkeloos uitziet en dan via Illustrator/Fireworks/Photoshop je afbeeldingen exporteren met de "save for web" feature. Doel: eenvoudig. Gewoon zo klein mogelijk .

2) sIFR is momenteel de optie die ik persoonlijk de beste optie vind. In de toekomst hebben we hopelijk een algemene manier om webfonts te gebruiken, maar daar wordt voorlopig nog naarstig aan gewerkt. Ik geloof dat Firefox 3.1, Safari 3.1 en Opera 10 op dit moment al de CSS3 spec ondersteunen (CSS3 module: Web Fonts)

3) Zo weinig mogelijk http-requests maken. Dat betekent dus: zo weinig mogelijk verschillende files gebruiken. Liever één afbeelding--sprite--en dan de "sliding doors" techniek (CSS) gebruiken, dan voor elk menu-element een andere afbeelding gebruiken. Gzip-compressie aanzetten kan ook helpen (genoeg tutorials Googleable ). De host maakt een héél groot deel uit van hoe snel je site geserved wordt in België of daarbuiten. Een Content Delivery Network gebruiken voor standaard JavaScript files als jQuery kan de boel al héél wat versnellen (AJAX Libraries API - Google Code). Voor een uitgebreider gebruik van Google's CDN kan je deze link eens checken: 24 ways: Using Google App Engine as Your Own Content Delivery Network (eerder experimenteel dan operationeel). Veel meer informatie kan je vinden op Web Site Optimization: Speed Up Your Site website optimization web speed optimize web site performance company

4) Semantiek & inhoud en vormgeving zijn geen van elkaar losstaande elementen. Wat jij percipieert als een web waarbij er allemaal Jakob Nielsenwebsites gebouwd worden, is volgens mij een redelijk extreme visie. Het perfecte voorbeeld (en mijn persoonlijke Godfather op dat vlak) is Jason Santa Maria. Usable, semantically correct, and oh so be-a-utiful!

j design zei:

het wordt wel degelijk gelezen.
Alvast bedankt voor je antwoord

1 Over een grote afbeelding dan bedoel ik als dit Drumbeat!

2 Daarom ook juist dat ik liever niet met die JS oplossingen werk.
Op deze site was ik ook al gekomen, op een anders site kwam ik inline zonder sifr de rockwell font tegen. Is dat iets dat iedereen standaard heeft, dus ook kan gebruikt worden al dat het geen webfont is?

3 de tumbs is een logische oplossing. Het ding is dat ik op een pagina zo een 50tal thumbs moet laden 100x100, dat duurt lang en misschien was er een of andere verdoken techniek om dat toch wat sneller te laten verlopen.
Met comprimeren bedoel je dan de juiste extensie?

4 Ik ben me er zeker van bewust dat SEO meer inhoud dan een mooie code afleveren. Het gaan me vooral om of het echt een berg van verschil zou uitmaken <div><tag></div> ipv <tag> met extra opmaak, inline afbeeldingen voor layout. Zeker als je zoekmachine traffic laag is.

Klik om te vergroten...

1. http://www.webdrumbeat.com/webdrumb.../unstandard/images/planet-burst-wallpaper.jpg = 131KB. Valt dus nog goed mee voor de grootte en is nog acceptabel. Zeker bij een lokaal doelpubliek is breedband wel vrij goed ingeburgerd. Alhoewel ge ook nog steeds mensen hebt die op smallband zitten natuurlijk.

2. Ge kunt alle fonts gebruiken die ge wilt, zonder daar iets speciaals voor te moeten doen. Dat gaat werken zolang die gebruiker dat font geïnstalleerd heeft. Rockwell zou bij mij bijvoorbeeld ook werken, maar of het op Linux ook staat weet ik niet.

3. De juiste extensie en gewoon het compressieniveau ja. Ge kunt bij een jpeg ook instellen dat ge een kwaliteit van 50% hebt in plaats van 100% en uw afbeelding zal weer een pak kleiner zijn.
En voor contentimages is image replacement zonder te herladen ook altijd handig: mezzoblue Testing Grounds in samenwerking met mezzoblue Sprite Optimization (Ik gebruik dat over het algemeen enkel voor mijn menu-items though). Lees ook de comments bij die artikels voor meer info.

4. Zolang uw code valid is en niet clogged met belachelijk veel spare tags kunnen zoekmachines ze wel lezen.
Inline images zullen voor zoekmachines ook geen probleem zijn, behalve dat ze geïndexeerd zullen worden bij de afbeeldingenzoeker. Iets wat ook wel lichtjes overbodig is.
Tags zoals strong en h, waarbij ge extra gewicht geeft aan de content zullen wel altijd vrij belangrijk zijn.

'k Begrijp wel uw statement niet echt van <div><tag /></div> ?

Hmm, Xavez.. Ik zie dat ik wat punten van u heb herhaald, 'k heb uw post pas achteraf gelezen.

Ja ik ge ze zeker allemaal is doorlezen. Alvast bedankt voor de moeite.

Het is al zowat duidelijk geworden. Ik bedoelde dat die extra div tags er al dan niet veel invloed op zou hebben.

Zo heb ik al gedacht mij img op te delen. Dus dat ik een div met een bg heb en daarin een list met een bg. Op die manier zou mijn code <div><ul></ul></div> er gaan uitzien terwijl het ook perfect mogelijk zou zijn met enkel de <ul> maar dan met 1 afbeelding. Dan is de vraag reageert google daarop of zijn dat de kleine dingen die wel kunnen zonder invloed.
Maar daar heb je al een groot deel op geantwoord.

j design, dat zijn kleine dingen. Even wat dieper ingaan op semantiek.

Eerst en voral, er is semantiek, maar ook structuur, usability en user experience, ... allemaal losstaande facetten.

Eerst en vooral moet je uitgaan van inhoud. Wat moet er op de website komen? Het is geen boek, dus een beknopt overzicht van informatie aanbieden aan je bezoeker is al een must. Een bezoeker zoekt informatie en heeft geen zin om een tekst te gaan samenvatten tot de kern van de zaak, dat is de job van de eigenaar van de website.

Als je je content verzameld hebt moet je die in een nette structuur gaan gieten, als ware het een catalogus. Je begint met een h1 titel die de titel van je "document" bevat, desnoods een primaire navigatie die als TOC (table of contents) kan aanzien worden, en van daaruit ga je verder alle data netjes in een structuur gaan gieten (ik heb het dan nog niet over divs of whatever, enkel structuur tags).

Als dit gebeurd is kan je beginnen denken aan een layout, wss eerst schetsen of een wireframe maken (omnigraffle is hiervoor aan te raden, zeker met de stencils van konigi). Hier is vooral de opbouw van je interface belangrijk, usability, consistentie in layout over alle pagina's, etc...
Als je voor alle types pagina die je hebt een wireframe hebt kan je overstapen naar een layout. Je weet wat de inhoud is, dus kan je perfect een layout gaan maken, curly edges, rounded borders, glossy, patterns, backgroundimages, ... Het maakt niet uit hoe wild je gaat, het is JOUW layout.

In volgende fase moet je die layout dus op je xHTML structuur gaan leggen, daarvoor zal je wss wel container tags (divs) gaan gebruiken om je document op te splitsen in verschillende blokken, maar da's geen probleem want so far is je site nog voor iedereen toegankelijk. Het belangrijkste is dat je je tags niet in functie van je layout gebruikt. Soms zie ik mensen die een woord willen benadrukken en hiervoor een <h2> tag gebruiken ipv de voorziene strong...

Anyway, css is the way to go om je document er netjes te laten uitzien zonder in te moeten boeten op layoutzaken én toegankelijkheid. Als dit gebeurd is kan je je bezighouden met interactie (als dat nodig is). Je kiest zelf de taal die je het meest ligt maar ik denk dat vbscript de dag van vandaag niet meer echt aan de orde is, gezien het grote aanbod van opensource javascript libraries.

En dan nu waar alle ophef rond te doen is, namelijk semantiek. Semantiek gaat niet alleen over structuur, het gaat ook over interpreteren van inhoud. Tim Berners-Lee had een visie, nl:

have a dream for the Web [in which computers] become capable of analyzing all the data on the Web &#8211; the content, links, and transactions between people and computers. A &#8216;Semantic Web&#8217;, which should make this possible, has yet to emerge, but when it does, the day-to-day mechanisms of trade, bureaucracy and our daily lives will be handled by machines talking to machines. The &#8216;intelligent agents&#8217; people have touted for ages will finally materialize.

Klik om te vergroten...

Wat houdt dit in, dat een computer een webpagina kan lezen, het belang van alle inhoud kan begrijpen (structuur, xhtml tags dus) én kan interpreteren. Dit idee is echter niet echt uitvoerbaar (wat Berners-lee ook heeft verklaard in een artikel in 2001). De hele technische uitleg zal ik je besparen, however, er zijn wel enkele projecten opgezet die neigen naar die visie, waaronder FOAF (friend of a friend) die relaties gaat beschrijven tussen verschillende mensen via het Resource Description Framework. Xul is een goed voorbeeld van RDF, alsook DBpedia. Ik ga er niet te veel over uitbreiden, want er zijn veel meer projecten dan FOAF, DBPedia, etc...

Als laatste facet hebben we dan nog toegankelijkheid voor iedereen maar ook voor blinden, slechtzienden. Al te vaak worden cursor events opgevangen met javascript, zonder te denken aan mensen die met hun toetsenbord navigeren. Denken we maar aan de outline op een link die wordt verwijderd, dan is hij niet meer accessible via je tabkey. Tabindexes bij formulieren worden ook al te vaak vergeten, om nog maar te zwijgen over verplichte velden die pover voorzien worden van hoe mensen hun data in dat veld moeten invullen (een datum, tijd, hr nummer, btw nummer, telefoonnummer, etc...)

Ik heb er heel wat op na te lezen deze dagen
Alvast heel hard bedankt voor de moeite. Jullie mogen er zeker van zijn dat er aandacht aan zal geschonken worden.