Tweakers.net remake

[Justice]

Had ik nog niet gelezen, ik ben gewoon niet zo snel met denken PPK introduceert zelf afgelopen paar weken de JIR methode om met javascript image replacement te doen, terwijl content: url(bla.jpg); in CSS3 zit. Dus dat vind ik daar niet mee samengaan... content wordt al ondersteund door Opera en een paar andere browsers (mozilla geloof ik nog niet helaas).

Probeer zulke methodes dan te gebruiken wanneer het niet persee nodig is om die image te swappen (en dat is het dus bijna nooit, anders had je die accessible text niet nodig ). Wanneer het veel op websites voorkomt, komt het ook in alle moderne browsers.

Zal ik nu even dat artikel lezen.

edit:
Ja het feit om bugs met bugs op te lossen is inderdaad ook nog een punt, en daar had ik niet eens aan gedacht.

[ Voor 13% gewijzigd door Justice op 26-11-2003 10:45 ]

[creative8500]

Als laatste opmerking over die CSS-hacks:

1) Bedenk wat voor reacties ik had gekregen op de pagina als in Internet Explorer opvallende fouten zichtbaar waren in de layout.

2) Ik heb de hacks alleen gebruikt om verkeerde behandeling van margin ongedaan te maken, en om er voor te zorgen dat je in het top-menu en de meuktracker op de hele block kunt klikken in plaats van de alleen op de tekst: een usability-verbetering die ik de hack waard vond. Bovendien zijn de hacks volledig correct volgens de CSS 2.1-specificatie, ze valideren enkel niet!.

3) Het alternatief van transparantie via JavaScript in CSS instellen is onwenselijk.

[Clay]

jir/fir met een span (of script) is handig, maar als je dat doet moet je er imo wel rekening mee houden dat mensen images uit kunnen hebben staan. Als je de css wegmikt zie je de tekst in die spans wel staan, maar met css en zonder images (al kan ik me niet voorstellen dat iemand dat zou doen) zie je een groot deel van de menu items niet.

Iets anders; in de CSS zie ik dit staan:

code:

...
#top-menu ul.firstUL { display: inline; margin: 0; padding: 0; }
...
#top-menu ul.secondUL li { display: block; ... }
#top-menu ul.firstUL li:hover ul.secondUL { display: block; }
...

Nou haal je die submenu's met position:absolute; uit de flow, maar ik vind het niet zo netjes om block elementen in inline elementen te zetten (als je iets wat absolute is nog als block kan beschouwen).

kan je de firstUL niet block maken, en de li's daarin block met float:left; en position:relative; ? Dan kunnen de submenu's er met position:absolute in, zonder display property, en dan showen en hiden met de visibility property. Dat lijkt mij wat netter. Ik heb ook ff gepookt met de css van die submenu's, omdat je erg veel width instelt, maar daar heb ik eigenlijk ook niet echt een andere oplossing voor kunnen vinden

Je geeft aan waarom je het doet, maar persoonlijk vind ik het toch jammer dat er hacks inzitten. Je zou toch zeggen dat het zonder moet kunnen maar toch niets dan hulde dat je het wel voor elkaar hebt gekregen

Wat ik verder nog wat vreemde regels vind;

code:

#meer li + li + li + li + li + li + li { border: 0; }

't zal niet anders kunnen misschien.

je zou nog wat borders samen kunnen trekken ipv 4 properties, ala:

code:

border:1px solid;
border-color:#D8D8D8 #B5B5B5 #BCBCBC #F5F5F5;

En waar je ook nog over kan twisten is het globale skelet jij hebt ervoor gekozen de globale opzet helemaal met absolute te doen, waar je deels ook gewoon de flow kan gebruiken van block level elementen.

Qua mierengeneuk vind ik dat je b.v. wel goeie id's heb gekozen voor de verschillende submenu's (hoewel menu en submenu er imo voor weg kan), maar "top-menu" en "tab-menu" vind ik dan weer nix

[Woudloper]

Ook nog even een toevoeging. Als je de pagina vergelijkt tussen Internet Explorer en Mozilla Firebird zie je nog wel redelijke verschillen met betrekking tot

• margins ( de afstanden bij hoofdnieuwsberichten, W3C Button margins before/after);
• onderstrepen van de nieuwsitems (wel in Firebird, niet in Internet Explorer);
• Reclamebanner van Microsoft (wel in Internet Explorer, niet in Firebird).

en zo zijn er nog een paar kleine miereneuk opmerkingen, maar het is neem ik aan toch wel wenselijk om de layouts tussen de verschillende browsers (en platformen) zo gelijk mogelijk te krijgen. Dat de reclamebanner van Microsoft wel te zien is in Internet Explorer, maar niet in Firebird is neem ik aan een kleine easteregg).

edit:
Dat heb je als je niet Firebird als standaard browser gebruikt, dan merkt je dus helaas niet zo snel dat je de Flash plugin (zie comment hieronder) niet hebt

[ Voor 11% gewijzigd door Woudloper op 26-11-2003 16:06 ]

[Verwijderd]

Woudloper schreef op 26 november 2003 @ 14:26:
Dat de reclamebanner van Microsoft wel te zien is in Internet Explorer, maar niet in Firebird is neem ik aan een kleine easteregg).

mwah, eerder een flashplugin die niet standaard in Firebird zit, ik zie hem nl wel
en ik zie in FB wel een zoekbox nu (nog niet gestyled dat wel), maar in IE niet?

[ Voor 11% gewijzigd door Verwijderd op 26-11-2003 15:44 ]

[creative8500]

Uitleg - Hoe zit het met... de meuktracker?

[tomato]

creative8500 schreef op 27 november 2003 @ 08:58:
Uitleg - Hoe zit het met... de meuktracker?

Hier volgt wat kritiek op je aanpak, niet bang worden, over het algemeen vind ik dat je een behoorlijke prestatie geleverd hebt

Ik vind het jammer dat je de lettergrootte in pixels hebt gedefinieerd. De site zou een stuk flexibeler geworden zijn als je ipv 11px bijvoorbeeld 0.9em voor lettergroottes genomen had.

Vervolgens had je ook je line-height en/of height op de meuk-tracker items in relatieve eenheden op kunnen geven (of evt padding). Ik neem aan dat je voor de vaste hoogte van 21px hebt gekozen om het background image goed te laten passen?

Als ik het goed zie is het background image eigenlijk niets anders dan een heel lichte verticale gradient en 4 borders van een pixel. Je zou dus best de borders met CSS kunnen opgeven, als background-image een verticale gradient van bijvoorbeeld 25px hoog opgeven (horizontaal maar niet verticaal herhalend) en als background-color de kleur waar de gradient mee eindigt.

Op die manier zou je een prima schaalbare meuktracker krijgen. Vergelijkbare aanpak is natuurlijk ook mogelijk op andere delen van de site. Je zou misschien problemen krijgen met je absolute positionering, maar daar huiver ik toch al een klein beetje van. Ik had liever gezien dat je gebruik had gemaakt van de normale flow en eventueel wat floating elementen.

Maar goed, voor iedere aanpak zijn wat redenen te verzinnen en jij hebt over deze pagina langer nagedacht dan ik neem ik aan

[Willem]

En als ik hier even op in mag haken: ik kan niet begrijpen waarom je een andere eenheid dan pixels zou hanteren m.b.t. lettergrootte voor beeldscherm.

[Woudloper]

willem169:
En als ik hier even op in mag haken: ik kan niet begrijpen waarom je een andere eenheid dan pixels zou hanteren m.b.t. lettergrootte voor beeldscherm.

Ik kan dat wel begrijpen. Zelf doe ik het ook regematig omdat ik wil dat de lettertypes hetzelfde acteren op de verschillende schermresolutie en DPI's. Ik zit nu achter een 21" scherm met 1600 x 1200 en DPI staat in gesteld op 120. Dit geeft bij sommige pagina's zo'n raar effect. Met andere woorden de letters zijn zo groot dat je weer standaard in bijvoorbeeld Internet Explorer je font grote op klein zet. Dat laatste zorgt er dan weer voor dat bij sommige pagina's het lettertype weer veel te klein is.

Mocht je dan gebruik maken pixel grote ziet het er wel op verschillende resoluties en DPI, etc. hetzelfde uit.

[Willem]

Woudloper:
Ik kan dat wel begrijpen. Zelf doe ik het ook regematig omdat ik wil dat de lettertypes hetzelfde acteren op de verschillende schermresolutie en DPI's. Ik zit nu achter een 21" scherm met 1600 x 1200 en DPI staat in gesteld op 120.

Hoe zet je je scherm op 120 DPI ?

Woudloper:
Dit geeft bij sommige pagina's zo'n raar effect. Met andere woorden de letters zijn zo groot dat je weer standaard in bijvoorbeeld Internet Explorer je font grote op klein zet. Dat laatste zorgt er dan weer voor dat bij sommige pagina's het lettertype weer veel te klein is.

Je lettergrootte in IE instellen vind ik dus ook zo apart. Ik vind dat de website moet bepalen hoe groot de tekst moet worden weergegeven. Daarom is mijns inziens de enige juiste notering die van de lettergrootte in pixels.

[DumbAss]

Nou, hij is nog niet helemaal perfect maar wel errug responsive. Perfect, zelfs voor die oude brakken van computers op mijn werk.

[ViNyL]

Hoe zit het met de frontpage. Enige kans dat hij ook gebruikt gaat worden op Tweakers.net zelf. Al een reactie gehad op je remake ?

[mabarto]

willem169 schreef op 27 november 2003 @ 13:19:
[...]


Hoe zet je je scherm op 120 DPI ?

Eigenschappen beeldscherm > geanvanceerd > Bij tabblad Algemeen zie je de DPI instellingen

[MrScratch]

Bij Mozilla Firebird zijn de menu's op de echte tweakers site een ramp. Deze openen traag en verdwijnen vaker niet dan wel als je je muispointer er af haalt.

Bij de remake is dit echter helemaal niet het geval. Reageert perfect, snel open snel dicht.

Kan dit niet geport worden naar tweakers? Het is nu echt een vervelend onderdeel van de site.

[Scipionyx]

willem169 schreef op 27 november 2003 @ 13:19:
[...]


Hoe zet je je scherm op 120 DPI ?
[...]

RMC @ bureaublad -> eigenschappen -> geavanceerd -> algemeen. En dan ergens bovenaan zie je Dpi-instelling staan

edit:

Voor het geval je de post van barto018 hebt gemist

[ Voor 15% gewijzigd door Scipionyx op 27-11-2003 13:32 . Reden: net te laat ]

[ViNyL]

Ik hoop inderdaad ook dat ze zo vriendelijk willen zijn en de frontpage aan te passen. Is inderdaad stukken slomer dan de remake.

[OkkE]

willem169 schreef op 27 november 2003 @ 13:06:
En als ik hier even op in mag haken: ik kan niet begrijpen waarom je een andere eenheid dan pixels zou hanteren m.b.t. lettergrootte voor beeldscherm.

Ik gebruik altijd 10pt (of 12, of ...) in CSS, zodat de lettergrote die je insteld in je browser wel effect heeft. Bijvoorbeeld voor slechtziende...

[Not Pingu]

willem169 schreef op 27 november 2003 @ 13:06:
En als ik hier even op in mag haken: ik kan niet begrijpen waarom je een andere eenheid dan pixels zou hanteren m.b.t. lettergrootte voor beeldscherm.

een van de officieuze regels van gebruikersvriendelijkheid cq. toegankelijkheid is dat je je site-bezoekers de mogelijkheid geeft zelf te bepalen hoe groot de tekst is (tegenwoordig is er toch al zo'n rage van puntgrootte 7, wat pijn doet om te lezen).

Als je fontgrootte met procenten of em aangeeft, kun je bovendien dmv. ctrl+scrollwiel de grootte van de tekst snel veranderen. Leest in sommige gevallen een stuk makkelijker.

[Woudloper]

willem169:
Hoe zet je je scherm op 120 DPI ?

code:

Start --> Settings --> Control Panel --> Display
Display Properties --> Settings (tab) --> Advanced.. (button)

En dan 'Large Font' (120 DPI) selecteren.

Tenminste zo werkt dat hier bij mijn PC.

edit:
Argh, er waren dus al 4/5 mensen voor mij. Maar ja, ik denk dat je het nu wel begrijpt. Zo werkt dat dus onder Windows, hoe het voor de andere platvormen werkt (zoals Macintosh, Linux, etc.) weet ik niet

/edit2 (nu in groter lettertype)

Nog een kleine toevoeging. Bij onderstaande weblog (Mezzoblue) staat een interessant verhaal over het gebruik van font-sizes:

Mezzoblue - Font Size: No Happy Medium

[ Voor 54% gewijzigd door Woudloper op 27-11-2003 14:52 ]

[Willem]

Gunp01nt:
een van de officieuze regels van gebruikersvriendelijkheid cq. toegankelijkheid is dat je je site-bezoekers de mogelijkheid geeft zelf te bepalen hoe groot de tekst is.

Sja, officieus

Maar, de bezoeker de mogelijkheid geven zelf te bepalen hoe groot de tekst is strijkt -naast de toegankelijkheids "regels"- tegen al mijn typografische haren in. Vormgeving en daarbij dus typografie heeft mijns inziens vaak een hogere prioriteit.

Gunp01nt:
Als je fontgrootte met procenten of em aangeeft, kun je bovendien dmv. ctrl+scrollwiel de grootte van de tekst snel veranderen. Leest in sommige gevallen een stuk makkelijker.

Dan denk ik op mijn beurt weer dat de site-maker de plank mis heeft geslagen als zijn doelgroep de tekst niet kan lezen en zelf moet vergroten. Zijn gewoon dingen waar je rekening mee moet houden.

[Stalkert]

Code ziet er zover ik verstand van heb geweldig uit. Ik ben benieuwd wat Femme er van vindt. Ik had hem eigenlijk al verwacht ..

[Not Pingu]

willem169 schreef op 27 november 2003 @ 13:54:
Dan denk ik op mijn beurt weer dat de site-maker de plank mis heeft geslagen als zijn doelgroep de tekst niet kan lezen en zelf moet vergroten. Zijn gewoon dingen waar je rekening mee moet houden.

daar gaat het niet om. het punt is dat als bijv. een slechtziend iemand de tekst te klein vindt, hij makkelijk die tekst wat groter kunt maken. zelfs als de tekst al puntgrootte 10 heeft, is het voor sommige mensen nog steeds moeilijk te lezen.
[edit]het punt is dus dat je bezoekers niet vastpint op 1 formaat. vandaar ook dat je op steeds meer sites knopjes ziet 'om de letters groter te maken'.

bovendien kun je makkelijk variabele tekstgrootte iplementeren zonder dat daardoor gelijk je hele layout gefuxored wordt.

[ Voor 11% gewijzigd door Not Pingu op 27-11-2003 15:25 ]

[Willem]

Gunp01nt:
daar gaat het niet om. het punt is dat als bijv. een slechtziend iemand de tekst te klein vindt, hij makkelijk die tekst wat groter kunt maken. zelfs als de tekst al puntgrootte 10 heeft, is het voor sommige mensen nog steeds moeilijk te lezen.

_{Afgezien van het feit dat deze discussie weinig te doen heeft met de topicstart}

Ik geloof dat je mijn punt van typografie een beetje miste?
Als ik als maker, ontwerper van de website vind dat de lettegrootte een bepaald formaat moet hebben, ga ik dat niet variabel maken.

Gunp01nt:
[edit]het punt is dus dat je bezoekers niet vastpint op 1 formaat. vandaar ook dat je op steeds meer sites knopjes ziet 'om de letters groter te maken'.

Kijk, daar sla je de spijker dus mee op z'n kop.

Als de tekst moeilijk leesbaar is, laat je de gebruiker kiezen om deze groter te bekijken. Zonder dat je afdoet aan de bedoelingen van de ontwerper.

[Femme]

Ik had dit topic maandagavond al gelezen en sindsdien in de gaten gehouden.

Leuk om te zien wat er allemaal mogelijk is met CSS en bizar dat iemand zoveel tijd wil stoppen in het herschrijven van de Tweakers.net-frontpage.

Ik heb geen plannen om de huidige layout van Tweakers.net om te gaan bouwen. In de eerste plaatst kost het een hoop tijd, het levert vrijwel niets op (layout ziet er hetzelfde uit voor de bezoekers) maar er zullen wel weer nieuwe bugs geïntroduceerd worden. Herschrijven doe ik wel als er een nieuwe layout gaat komen.

[AkaXakA]

Dat heb je echt goed gedaan, het is idd een goed voorbeeld om een site zoals T.net in standaard (x)html te hebben.

Een ding nog:
Je maakt gebruik van FIR, wat erg goed is, zo is de pagina nog steeds te lezen als de stylesheet uit staat.

Waar ik je echter op attent wil maken is het volgende:
Er is een nieuwere manier ontwikkeld om FIR zonder extra < span > te krijgen. Dat maakt de code schoner en kleiner.

code:

#li.firstUL {
 /* Groote van het plaatje*/
 padding-top: 133px; /* hoogte */
 width: 243px; /* Breedte */

 /* Plaatje zelf*/
 background: url(ex1.gif) no-repeat; /* Zonder 'quotaties' dan werkt het in IE5 Mac */

 /* Tekst verbergen */
 overflow: hidden;

 /* WIN IE5 hack */
 height: 133px; /* Hoogte voor IE 5 */

 voice-family: "\"}\"";
 voice-family:inherit;
 height: 0; /* Hoogte voor de rest, aangezien de rest naar de padding kijkt */
}

Die hack is dus daar om IE5 Win goed te laten werken, aangezien die de padding niet goed doet. Het extravagante comentaar in de code is om het duidelijk te maken voor de minder CSS bekenden onder ons

Zie ook: http://www.moronicbajebus...ssplay/image-replacement/

[Verwijderd]

creative8500 schreef op 27 november 2003 @ 08:58:
Uitleg - Hoe zit het met... de meuktracker?

Waarom gebruik je h3 in plaats h1, je hebt ten slotte te maken met maar 1 soort header binnen de meuktracker div

[Clay]

Ligt eraan hoe je redeneert.

Voor de kop moeten we even kijken bij welk nummertje we zijn aangeland: Tweakers.net → meuktracker → Software updates. <h3> dus.

[Willem]

Klopt

Cascading Stylesheet:

#meuktracker h1 { /* ... */ }

[djluc]

Femme schreef op 27 november 2003 @ 15:51:Ik heb geen plannen om de huidige layout van Tweakers.net om te gaan bouwen. ... Herschrijven doe ik wel als er een nieuwe layout gaat komen.

De TS had het ook over snelheidswinst en minder bandbreedte door minder javascripts. Is dit niet van toepassing of zijn de verschillen zo klein dat het niet uit maakt.?

[paragon]

noob question: what is FIR

[ Voor 4% gewijzigd door paragon op 27-11-2003 18:21 ]

[PrisonerOfPain]

paragon schreef op 27 november 2003 @ 18:21:
noob question: what is FIR

Fahrner Image Replacement

Een manier om met CSS (background) images te vervangen

[crisp]

paragon schreef op 27 november 2003 @ 18:21:
noob question: what is FIR

Fahrner Image Replacement

_{spuit-11, maar wel een ander linkje}

djluc schreef op 27 november 2003 @ 17:36:
[...]
De TS had het ook over snelheidswinst en minder bandbreedte door minder javascripts. Is dit niet van toepassing of zijn de verschillen zo klein dat het niet uit maakt.?

Met de huidige gzip compressie is dat verschil te verwaarlozen, en het voordeel van losse JS files is dat ze gecached worden. Ook de load op de client bij gebruik van javascript om de markup te genereren is maar zo'n 5 tot 10% van de totale parsetijd (mits goed geoptimaliseerde scripts worden gebruikt).
Wel kan je met een eenvoudigere structuur en zoveel mogelijk gebruik van CSS die parsetijd behoorlijk reduceren; dat kan soms wel de helft schelen

zie trouwens ook dit topic waar ik toevallig vandaag wat testjes voor gedaan heb op een trage client: [rml][ js] zorgt voor hoge load clientside[/rml]

Het nadeel van je markup in JS vastleggen is natuurlijk wel het feit dat het minder makkelijk onderhoudbaar is, en dat je client wel JS aan moet hebben staan cq. moet ondersteunen. Browser issues wb JS ondersteuning kunnen ook nog meespelen, maar dat is gelukkig steeds minder een probleem aangezien de huidige JS ondersteuning van browsers bijzonder goed te noemen is

[ Voor 20% gewijzigd door crisp op 27-11-2003 18:37 ]

[enriqueeeee]

euhmz als ik mijn muis aanwijzer op zoeken zet doet ie het niet
bij de andere wel

[creative8500]

enriqueeeee: "lees de draad voordat je blaat".

[ Voor 85% gewijzigd door creative8500 op 27-11-2003 20:45 ]

[marty]

willem169 schreef op 27 november 2003 @ 15:43:
[...]

_{Afgezien van het feit dat deze discussie weinig te doen heeft met de topicstart}

Ik geloof dat je mijn punt van typografie een beetje miste?
Als ik als maker, ontwerper van de website vind dat de lettegrootte een bepaald formaat moet hebben, ga ik dat niet variabel maken.

Maar ik geloof ook dat jij een belangrijk punt mist. Je zet in je eerste post hierover dat je het raar vind dat je de lettergrootte in IE kunt instellen. Als dat niet kon dan zouden slechtzienden dus gewoon helemaal niet van internet gebruik kunnen maken. Ik vind het raar dat jij dus liever zou hebben dat IE dit er uit sloopt (want daar komt het dan op neer) en deze doelgroep uit wil sluiten.
Bovendien: je zet iets op internet zodat anderen het kunnen bekijken. Waarom is het dan zo raar dat jij je lettergrootte definieert met een maat waarbij het standaard precies zo wordt weergegeven als jij wilt, maar met de optie dat mensen het groter kunnen maken als ze het niet kunnen lezen. Het is bij sommige mensen echt een kwestie van alles of niet, dus waarom zou je die met alle geweld uit willen sluiten?

[Oid]

Ik ben eigenlijk wel benieuwd hoe jij dat zo precies op de juiste plaatsen hebt gekregen, gebruik jij een programma daarvoor of wat dan ook maar, ik vind het zeer netjes gedaan en zit er zelf ook aan te denken, had er al veel over gelezen maar weet nog niet zoveel over CSS, vind het een mooie manier, werk je met een speciaal programma?

[AkaXakA]

Voor CSS hoef je geen speciaal programma te gebruiken. Notepad (Kladblok) volstaat.

Lees vooral veel op internet erover.

http://www.westciv.com/style_master/academy/css_tutorial/ - is een goede nasla hulp
http://www.sitepoint.com/ - is een goede plaats om te beginnen

[Oid]

AkaXakA schreef op 27 november 2003 @ 22:22:
Voor CSS hoef je geen speciaal programma te gebruiken. Notepad (Kladblok) volstaat.

Lees vooral veel op internet erover.

http://www.westciv.com/style_master/academy/css_tutorial/ - is een goede nasla hulp
http://www.sitepoint.com/ - is een goede plaats om te beginnen

Dat het gewoon met kladblok kan weet ik, maar voor de juiste positi's die px in de verschillende "divs" hoe krijg je het precies goed, want ik heb er een beetje meegekloot en het lukt mij niet zo erg, bedoel plaatst hij alles met een special programma op de juiste plaatsen oid?

En heb je nog meer NL tuts?

[ Voor 4% gewijzigd door Oid op 27-11-2003 22:56 ]

[AkaXakA]

Thijmen schreef op 27 november 2003 @ 22:56:
[...]
Bedoel plaatst hij alles met een special programma op de juiste plaatsen oid?
[..]
En heb je nog meer NL tuts?

1: Nee, het is gewoon rekenen en testen.

2: Sorry, werk eigenlijk niet in het NL. Zoek eens op css + nederlands.
En bekijk de sites van de NL/BE mensen die een CSS Zen Garden style hebben ontwikkeld.
http://www.mezzoblue.com/zengarden/alldesigns/ - Check de BE/NL vlaggen voor taal en click dan op de naam van de auteur om naar zijn/haar site te gaan. Wie weet vind je daar een 'tutorial' (op z'n goed nl)

[AkaXakA]

Ah, en ik heb ook een verbeterde versie van de verbeterde versie van de FIR gevonden.
Meerdere zelfs

http://www.mezzoblue.com/tests/revised-image-replacement/

Op deze (uitstekende) site wordt in detail beschreven wat de verschillende mogelijkheden zijn voor CIR (CSS Image Replacement).

Ik zou vooral 'Phark Revisited' aanraden:

code:

<h6 id="header">
    Revised Image Replacement
</h6>
<style>
/* CIR: Phark Revisited */
#header {
        width: 329px;
        height: 25px;
    text-indent: -5000px;
    background: url(sample-opaque.gif);
    }
</style>

Hier verschuift de 'text-indent' de tekst zo ver naar links dat die van het scherm verdwijnt. De 'width' en 'height' geven, natuurlijk, de breedte en hoogte v/h plaatje aan.

Het grote voordeel van deze manier is dat hij:
a) Overal werkt
b) Zelfs voor braille en andere browsers voor slechtzienden (zoals JAWS) werkt.
c) Heel erg schoon qua code is. En dus nog kleiner qua bestandsgrote.

[ Voor 8% gewijzigd door AkaXakA op 27-11-2003 23:18 ]

[Woudloper]

Nog even doorgaan op FIR en JIR. Er is namelijk een levendige discussie over dit fenomeen begonnen. Na een aantal weblog publicaties, is er enige tijd geleden hierover een artikel (Javascript Image Replacement) op A List Apart geschreven. Als je daar de discussie leest zie je dat er redelijk wat over geschreven staat en ook redelijk over wordt gemodder gooit.

PPK beweert namelijk dat FIR een stuk beter is dan de JIR welke in het A List Apart artikel wordt beschreven/besproken. In dit artikel onderbouwd hij (iets genuanceerder als de eerste keer) waarom de JIR (eigenlijk de organisatie van A List Apart) niet goed is en waarom FIR een stuk beter is.

Wellicht is dit nog de moeite waard om te lezen.

/edit: wat anne hieronder zegt ben ik het helemaal mee eens, mocht dat niet duidelijk zijn. Kijk je moet natuurlijk wel alle kanten bekijken voordat je er een oordeel over kan vellen. /offtopic: als je het mij vraagt is ppk zich de laatste tijd (sinds z'n nieuwe website) niet echt positief aan het profileren, maar wie ben ik...

[ Voor 16% gewijzigd door Woudloper op 27-11-2003 23:41 ]

[Verwijderd]

IMHO zegt PPK wel meer dingen. In dit geval heeft hij _absoluut_ ongelijk. Dit soort dingen doe je gewoon niet met JS. Je hackt het voorlopig met CSS en doet het later goed:

code:

element#unique-id{
 content:url(/img/blaat.png); /* werkt al in Opera */
}

[GoddXX2]

Thijmen schreef op 27 november 2003 @ 22:56:
[...]


Dat het gewoon met kladblok kan weet ik, maar voor de juiste positi's die px in de verschillende "divs" hoe krijg je het precies goed, want ik heb er een beetje meegekloot en het lukt mij niet zo erg, bedoel plaatst hij alles met een special programma op de juiste plaatsen oid?

En heb je nog meer NL tuts?

uhm 2 minuten op google zoeken is ook een goede. Ik zal je op weg helpem, klik op de eerste link:google css cursus

[HunterPro]

marty schreef op 27 november 2003 @ 21:17:
[...]


Maar ik geloof ook dat jij een belangrijk punt mist. Je zet in je eerste post hierover dat je het raar vind dat je de lettergrootte in IE kunt instellen. Als dat niet kon dan zouden slechtzienden dus gewoon helemaal niet van internet gebruik kunnen maken. Ik vind het raar dat jij dus liever zou hebben dat IE dit er uit sloopt (want daar komt het dan op neer) en deze doelgroep uit wil sluiten.
Bovendien: je zet iets op internet zodat anderen het kunnen bekijken. Waarom is het dan zo raar dat jij je lettergrootte definieert met een maat waarbij het standaard precies zo wordt weergegeven als jij wilt, maar met de optie dat mensen het groter kunnen maken als ze het niet kunnen lezen. Het is bij sommige mensen echt een kwestie van alles of niet, dus waarom zou je die met alle geweld uit willen sluiten?

Even heel bot gesteld: de Break-Out brengt toch ook geen braille-uitvoering uit? Waarom zou jij, als jouw doelgroep niet zozeer die mensen moet bevatten, en de opdrachtgever wil er geen geld extra voor uitgeven, maar liever gewoon een strakke site die er *altijd*, ongeacht de settings, goed uitziet (brandmerch sites dus, groot raakvlak van de campagne), wel zo'n 'braille-uitvoering' uitbrengen? Kijk, voor overheidsinformatie die gegarandeerd voor iedereen beschikbaar moet zijn, is het nuttig om 'm browsebaar te maken met tools als vergroters, brailleregels, etc. Maar voor een, ik noem maar wat, cu2 site, hoef jij echt geen braille-uitvoering te maken hoor Same for diepzeeduikvereniging De Dikke Duikslet. Bevat je doelgroep duidelijk mensen met een 'disability', dan kun je de opdrachtgever adviseren hiervoor te investeren. Maar als de opdrachtgever nee zegt, ga je dan die mogelijkheid 'uit principe' in je eigen tijd inbouwen?

[crisp]

Woudloper schreef op 27 november 2003 @ 23:24:
Nog even doorgaan op FIR en JIR....

Eerlijk gezegd kijk ik nooit op ALA of op quircksmode, maar ben nu even wat dingen gaan lezen, en jeetje wat heeft die PPK lange tenen zeg! zo een fuss over zoiets simpels als het doorlopen van je documentstructuur en het vervangen van een header door een plaatje - als ik hem was zou ik er patent op aanvragen
Daarbij gebruikt hij ook nog eens dat ranzige propriety add-on innerHTML attribuut dus kan hij het woordje DOM wel weghalen uit zijn title

Als het even kan probeer ik onload zoveel mogelijk te vermijden, zeker als je geen invloed hebt op de content van een site. Denk bijvoorbeeld aan extern gelinkte plaatjes die niet meer bestaan en je onload dus enorm vertragen. Ook zullen mensen wel degelijk de transition naar de plaatjes te zien krijgen als je JIR gebruikt - iets wat je pagina dus erg 'onrustig' zal maken.

[ Voor 25% gewijzigd door crisp op 28-11-2003 01:05 ]

[Verwijderd]

Ik kwam net in jouw highlight.htc dit tegen:
 

Cascading Stylesheet:

element.style.cursor = 'hand';

Moet dat niet pointer zijn?? Volgens mij is hand alleen voor IE
http://www.w3schools.com/css/pr_class_cursor.asp


Verder: petje af voor je goede werk! Er zouden veel meer mensen moeten kiezen voor valid XHTML! De huidige Tweakers.net code is ook wel erg lelijk! (en brak)

[ Voor 10% gewijzigd door Verwijderd op 28-11-2003 01:49 ]

[marty]

@HunterPro Het ging me er in eerste instantie om dat ik me er over verbaas dat willem169 het raar vind dat je in IE lettertypes kunt vergroten. (voer alle mensen met disabilities maar af naar een eiland waar ze niet meer van af kunnen.....ofzo).
En wel grappig hoor, dat je het naar het extreme door trekt door over braille te beginnen, maar daar heeft een discussie natuurljik niets aan. Ik had het over slechtzienden, die met een klein beetje aanpassingen toch kunnen internetten (en dat anders niet kunnen). En wat ik in het verlengde daarvan niet snap is waarom je je website opzettelijk ontoegankelijk zou maken voor deze mensen. Het maakt voor het gros van de bezoekers niets uit of je het in px of em neerzet, want het ziet er exact hetzelfde uit. Alleen mensen die het anders toch niet kunnen lezen zullen de lettertype groter hebben staan. Dus dat komt goed uit. En die weten zelf ook wel dat ze daardoor de websites iets anders voor hun snufferd kunnen krijgen dan bedoeld.
En ik heb nog nooit een opdrachtgever gehad die begon te klagen dat als ie z'n lettertype groter zet, dat dan de letters ook groter worden

[Justice]

Px (pixels) is in CSS gewoon een relative unit en niet absoluut zoals in photoshop, dus het zou geen probleem moeten zijn om als slechtziende de lettergrootte te veranderen. Zo moeilijk is het ook niet om een browser te vinden die dit wel kan. Er is dus eigenlijk geen probleem?

[Woudloper]

Verwijderd schreef op 28 november 2003 @ 01:49:
Ik kwam net in jouw highlight.htc dit tegen:
 

Cascading Stylesheet:

element.style.cursor = 'hand';

Moet dat niet pointer zijn?? Volgens mij is hand alleen voor IE
http://www.w3schools.com/css/pr_class_cursor.asp

Dat hoeft niet, want .htc is een Internet Explorer only behaviour iets. Met andere woorden voor de andere browsers hoef je dat niet te doen. Je kan binnen .htc gewoon IE only programmeren.

[Willem]

_{disclaimer: even afgezien van de discussie over de t.net fp}

marty:
@HunterPro Het ging me er in eerste instantie om dat ik me er over verbaas dat willem169 het raar vind dat je in IE lettertypes kunt vergroten.

Dat vind ik niet raar, het ging mij om de lettergrootte in een andere maatgeving dan pixels, zodat de site schaalbaarder is. Daarnaast heb ik gezegd dat dat niet altijd goed is, want over usability ging het hier niet.

Daarnaast heb ik een alternatief ^{* Willem} gegeven wat mijns inziens een beter oplossing is dan de tekst in (bijv) em (lees: schaalbaar) font.

^{* Willem}
Knop / link op de website voor tekst in grotere letters

marty:
(voer alle mensen met disabilities maar af naar een eiland waar ze niet meer van af kunnen.....ofzo).

Zie ^{* Willem}

marty:
...snip...

Mijn punt is dus, als ik als ontwerper een bepaalde lettergrootte opgeef, ik vind dat de gebruiker dan niet de font-size op welke wijze dan ook zou mogen veranderen omdat dat afdoet aan de intenties van de maker, tenzij ze voor de optie "Klik hier voor een grote-letter-versie" kiezen.

En dit laatste hangt er ook maar vanaf, absoluut niet elke site die wij hier ontwikkelen heeft deze toegankelijkheidsoptie, puur vanwege het feit dat het veel klanten ons 1) niet uitmaakt en 2) z'n klandizie niet zoekt in de doelgroep "disabled"- mensen (dit is niet grof bedoeld) en 3) omdat het ze simpelweg niets kan schelen.

Overheids-sites daarentegen (waarvan wij er een stuk of 4 hebben gemaakt en onderhouden) moeten aan compleet andere voorwaarden en eisen voldoen, waaronder vooraf bepaalde lettergroottes en de mogelijkheid om de website in een grote letter versie te kunnen bekijken.

Dus, ik baggatelliseer niets, ik zeg alleen dat het nogal kan verschillen (nl. afhankelijk van toepassing, doelgroep) maar dat mijn persoonlijke voorkeur uitgaat tot de lettergrootte definitie in pixels en daar waar nodig een linkje naar een stylesheet met een grotere font-size definitie.

marty:
En ik heb nog nooit een opdrachtgever gehad die begon te klagen dat als ie z'n lettertype groter zet, dat dan de letters ook groter worden

???

[paragon]

Hmm echt een intressant draadje dit. FIR JIR etc heb veel gelezen gisteren en die discussie over FIR JIR was erg intressant. Dat van die text-indent met een negatieve waarde schijnt ook niet overal te werken. Nu nog even wat lees werk over .htc want das ook nieuw.

[edwinistrator]

Justice schreef op 28 november 2003 @ 02:29:
Px (pixels) is in CSS gewoon een relative unit en niet absoluut zoals in photoshop, dus het zou geen probleem moeten zijn om als slechtziende de lettergrootte te veranderen. Zo moeilijk is het ook niet om een browser te vinden die dit wel kan. Er is dus eigenlijk geen probleem?

<a href="javascript:void(document.body.style.zoom==''?document.body.style.zoom=1*2:document.body.style.zoom=(parseFloat(document.body.style.zoom)*2));>test</a>

Zou al moeten zoomen, gewoon met een tekst linkje (werkt dus ook in IE )
Maakt dus niet uit of je px em of pt etc. hebt, andere browsers hebben weer andere opties

bron: http://www.naarvoren.nl/artikel/bookmarklet.html

[Woudloper]

Net even een screenshot met een Fantastisch Tool gemaakt welke laat zien hoe een pagina eruit ziet onder Safari 1.1. op Mac OS 10.3.1. Zie hieronder (of deze link naar de entry):



Daar zie je meteen dat naast Internet Explorer, Safari ook de nieuwsitems niet onderstreep, zoals ik eerder melde in dit topic.

[AkaXakA]

Klopt, en Mozilla Firebird ook niet. Goed toch?

= Over CIR/FIR:
Ik vind het gevaarlijk om zulke dingen in JavaScript (JS) te doen, aangezien het een integraal onderdeel is van het design. Als JS uit staat (bij 10% v/d mensen staat die uit) dan werkt het meteen niet meer. CSS kan (eigenlijk) niet uitgezet worden.*

Door het op (een van de varianten van) CIR te houden, weet je zeker dat het altijd werkt. En dus dat je design er (vrijwel) overal goed uitziet en in iedergeval bruikbaar is.

* Ik weet wel een manier, maar dat terzijde.

[Justice]

je moet integrale onderdelen van een design ook niet in FIR/CIR doen.. daar is het niet voor bedoeld. En het voordeel ervan is juist dat je een tekstalternatief hebt. Dus kritieke in plaatjes opgeslagen informatie moet je niet riskeren door zo'n IR

[mr.inno]

Woudloper schreef op 28 november 2003 @ 09:55:
Daar zie je meteen dat naast Internet Explorer, Safari ook de nieuwsitems niet onderstreep, zoals ik eerder melde in dit topic.

Uhm nou wil ik niet moeilijk doen.. maar dat doet T.net ook niet .. (in mozila dan) dus eignelijk klopt het dan wel weer..

Verder vind ik het echt Zeer goed gemaakt.
mijn complimenten.

[AkaXakA]

Justice schreef op 28 november 2003 @ 17:00:
je moet integrale onderdelen van een design ook niet in FIR/CIR doen.. daar is het niet voor bedoeld. En het voordeel ervan is juist dat je een tekstalternatief hebt. Dus kritieke in plaatjes opgeslagen informatie moet je niet riskeren door zo'n IR

Dat is juist het sterke van CIR....als css niet ondersteund wordt of 'uitstaat' dan verschijnt de tekst wel bij een aantal varianten...

= Weer een nieuwe CIR !
Deze keer de "Gilder/Levin Method + Shea Enhancement + AkaXakA Tweak"

Deze werkt door de breedte en hoogte van het element te beperken en dan een lege span uit te spreiden over het hele gebied, om zo de tekst weg te werken.

code:

<!-- html -->
<h6 id="11" title="CSS Image Replacement">
    <span></span>CSS Image Replacement
</h6>

/* CSS */
#11 {
    width: 83px;
    height: 16px;
    font-size: 12px;
    overflow: hidden;
    position: relative;
    padding: 0;
}
#11 span {
    background: url(title-plaatje.jpg) no-repeat;
    position: absolute;
    width: 100%;
    height: 100%;
}

Per element beschreven:
- 'width' en 'height' geven de breedte en de hoogte aan van het plaatje dat er moet komen.
- 'font-size' staat erom de tekst die je aan het vervangen bent niet te groot te laten worden zodat hij wel zichtbaar is als het plaatje niet laadt.
- "overflow: hidden" staat er om te zorgen dat niets (de tekst dus) de hoogte en breedte oprekt. Dit gaat het verschijnen van de tekst tegen bij mensen die hun fonts heel groot hebben staan, of de tekst (in mozilla) handmatig vergroot.
- "padding: 0" staat er om IE 5/win en IE 5.5/win goed te laten werken.
- "position: relative" zordt voor goede positie.
==
- 'background' zorgt ervoor dat het plaatje laadt. Zorg dat je er 'no-repeat' achter hebt staan, anders zou het een aantal keer kunnen verschijnen.
- "position: absolute" zordt voor goede positie.
- 'width' & 'height' op 100% zodat ze de volledige ruimte in beslag nemen die aangegeven staat bij de 'width' & 'height' hierboven.

Het voordelen van deze methode zijn
a) Geen hacks. Hacks zouden in de toekomst kunnen breken, deze code niet. Is ook schoner.
b) Werkt echt overal. Zelfs in JAWS, een browser voor slechtzienden.
c) Je hebt nog steeds je leuke 'alt' pop-up (door middel van die 'title' element.
d) Het heeft een leuke, pakkende, indrukwekkende naam.

[Justice]

offtopic:
mja mijn voorkeur gaat nog steeds uit naar

Cascading Stylesheet:

content: url(plaatje.jpg);

Scheelt je css, onderdeel van css3, en plaatjes met transparantie werken ook

[ Voor 7% gewijzigd door Justice op 28-11-2003 18:56 ]

[Verwijderd]

Een extra <span/> zou niet moeten IMO. Maar daarnaast: welke commerciele site heeft er een style switcher? (ok, vast wel een paar). <img/> voldoet vaak prima (alhoewel ik liever <object/> gebruik).

[AkaXakA]

Justice: Dat is idd wel zo, maar is nu nog toekomst muziek....als IE het niet ondersteund (met meer dan 90% v/d markt in handen) dan is het nu nog onbruikbaar..

Wellicht brengt IE7 goede ondersteuning voor CSS 3 en zijn all onze problemen opgelost.....*zucht*

Anne: Een IR is niet zozeer bedoelt om bij een styleswitcher handig te zijn, maar vooral om de structuur te behouden. Naast de morele overwinning die je zo behaalt is vooral van belang dat google rankschikt op basis van wat in je meta & h1-6 tags staat.

code:

<span style="font-weight:bold;">Belangrijke sleutelwoorden</span>
<img scr="sleutelwoord.png" alt="sleutelwoord" />
<h2 id="CIR" title="sleutelwoord">Belangrijke sleutelwoorden</h2>

Zo zal de 1e bijna niet uitmaken in je ranking bij google, de 2e wordt helemaal niet meegenomen, terwijl de 3e zorgt dat je voor die Belangrijke sleutelwoorden een hogere notering krijgt. En dat is weer wel van beland voor commerciele sites.

Maar idd, de extra span haalt weer van iets van je morele overwinning af Die zijn echter nodig om het trucje overal te laten werken.

[ Voor 13% gewijzigd door AkaXakA op 28-11-2003 19:54 ]

[Verwijderd]

Geloof me, dat weet ik. Ik bedoelde:

code:

<h1><img/></h1>

maar dat was blijkbaar niet duidelijk...?

edit: FYI: Google doet niet aan meta elementen

[ Voor 28% gewijzigd door Verwijderd op 28-11-2003 20:04 . Reden: toevoeging ]

[Justice]

kan je net zo goed

Cascading Stylesheet:

<h1><img/>belangrijke steekwoorden</h1>

en dan de image over de tekst schuiven

[AkaXakA]

aha, zo dus.

Ja dat kan idd, ook maar dan breek je weer met het 'scheiden van inhoud en stijl' adagium.

Lees anders:
http://www.alistapart.com/articles/fir/
http://www.digital-web.com/features/feature_2003-08.shtml

[AkaXakA]

edit: FYI: Google doet niet aan meta elementen

Dan zijn is de tekst in je H# tags dus helemaal belangrijk....

[Verwijderd]

Verwijderd schreef op 28 november 2003 @ 20:03:
Geloof me, dat weet ik. Ik bedoelde:

code:

<h1><img/></h1>

Ik vraag me ook al tijden af wat al die FIR/JIR/etc-dudes met CSS lopen te frutten. Deze methode werkt prima (i.c.m. met een alt tekst op de IMG natuurlijk).

AkaXakA schreef op 29 november 2003 @ 22:28:
Ja dat kan idd, ook maar dan breek je weer met het 'scheiden van inhoud en stijl' adagium.

Dat vind ik eigenlijk geen argument. Je gebruikt HTML-elementen precies waar ze voor bedoeld zijn: H1 voor een header en IMG voor 'grafische franje' - waarbij een tekstueel alternatief is gedefinieerd mocht de browser geen IMG ondersteunen. Als dit gebruik in strijd is met 'het scheiden van inhoud en stijl' is het gebruik van IMG dat dus sowieso.

http://www.alistapart.com/articles/fir/
Because it does not nest an image inside a heading, FIR is at least superficially better for accessibility.

Waarom? Ik zie in dit artikel verder geen argumentatie dus ik hoop dat iemand hier me dat uit kan leggen.

[ Voor 57% gewijzigd door Verwijderd op 29-11-2003 22:50 ]

[RocketKoen]

En ik heb nog nooit een opdrachtgever gehad die begon te klagen dat als ie z'n lettertype groter zet, dat dan de letters ook groter worden

een screenshot van de pagina maken, en de pagina dan vervangen door een .jpg je

[Justice]

Verwijderd schreef op 29 november 2003 @ 22:35:
Waarom? Ik zie in dit artikel verder geen argumentatie dus ik hoop dat iemand hier me dat uit kan leggen.

platte tekst kan worden voorgelezen door JAWS en andere lezers voor blinden. Platte tekst is altijd beschikbaar voor pda en mobiel gebruik, tekstbrowsers. Platte tekst is beschibkaar voor google. Plaatjes niet. Door dus een plaatje als stijl en tekst als alternatief te bieden hebben we dat probleem niet.

Dat is in het kort de redenatie.

Voordeel is ook dat je kan laten zien dat een plaatje puur decoratief is.

[ Voor 7% gewijzigd door Justice op 30-11-2003 11:48 ]

[Verwijderd]

Ik wilde eigenlijk reageren met het woordje 'blaat'. Ik zal het even onderbouwen.

IMG is een zogenaamd 'replaced element' (http://www.w3.org/TR/CSS21/conform.html#replaced-element), mocht de UA dus geen images ondersteunen (ze ondersteunen _bijna_ _altijd_ de <img> tag) dan laten ze gewoon 'alt' zien. ALTIJD. In tegenstelling tot al die rare CSS methodes (die overigens wel nut hebben bij CSSZenGarden).

Google ondersteund uiteraard beide methodes. Wellicht de CSS methode iets beter vanwege het kleinere aantal karakters, maar het gaat helaas niet alleen om Google en een stel grafische browsers, of wel?

[Not Pingu]

Verwijderd schreef op 29 november 2003 @ 23:19:
Ik wilde eigenlijk reageren met het woordje 'blaat'. Ik zal het even onderbouwen.

IMG is een zogenaamd 'replaced element' (http://www.w3.org/TR/CSS21/conform.html#replaced-element), mocht de UA dus geen images ondersteunen (ze ondersteunen _bijna_ _altijd_ de <img> tag) dan laten ze gewoon 'alt' zien. ALTIJD. In tegenstelling tot al die rare CSS methodes (die overigens wel nut hebben bij CSSZenGarden).

Google ondersteund uiteraard beide methodes. Wellicht de CSS methode iets beter vanwege het kleinere aantal karakters, maar het gaat helaas niet alleen om Google en een stel grafische browsers, of wel?

Het probleem is juist dat tekstbrowsers en screenreaders (dat zijn programmaatjes die de tekst op het scherm hardop voorlezen) <img> tags vaak compleet negeren. en dus ook de alt attribute. Bovendien is het plaatsen van de alt-tekst iets wat alleen visueel gebeurt, onderhuids is er dus nog steeds een img tag.

het punt is dus ook dat screenreaders en zoekmachines de visuele weergave negeren (voor hen maakt het geen verschil of de alt-tekst of de afbeelding zou worden weergegeven) en meestal dus gewoon de img tag overslaan. Een h1 tag beschrijft nou juist een heel belangrijk aspect van de pagina die wordt bekeken en het is dus niet handig als die als leeg word beschouwd.

je kunt je natuurlijk afvragen of het ertusssen proppen van een <span> dan geen nadelige gevolgen zou hebben, maar bij gebruik van een span staat er dus gewoon tekst tussen ipv. dat die in een attribute van een tag is gepropt.

[Verwijderd]

Geef me een link naar een pagina waar staat dat 'alt' vaak wordt genegeerd. Volgens mij is het namelijk complete onzin

[Spider.007]

jammer dat dit een beetje doodvalt; in hoeverre is er vanuit Tweakers.net interesse om bijvoorbeeld een subdomein (w3c.tweakers.net ofzo) aan te maken en daar deze versie van Tweakers.net op te zetten? Het lijkt met dat het niet meer dan een paar dagen werk kost om de backend hierin te hangen; en de voordelen zijn toch wel legio. Als alles uiteindelijk erin hangt kan wellicht gekeken worden naar het vervangen van de www door de w3c versie

[creative8500]

Spider.007 schreef op 10 december 2003 @ 17:09:
jammer dat dit een beetje doodvalt; in hoeverre is er vanuit Tweakers.net interesse om bijvoorbeeld een subdomein (w3c.tweakers.net ofzo) aan te maken en daar deze versie van Tweakers.net op te zetten? Het lijkt met dat het niet meer dan een paar dagen werk kost om de backend hierin te hangen; en de voordelen zijn toch wel legio. Als alles uiteindelijk erin hangt kan wellicht gekeken worden naar het vervangen van de www door de w3c versie

Geweldig dat jij dit ook zegt, precies mijn idee! Dit moet toch mogelijk zijn?
Ik zal bovendien nog eens wat extra's posten hierover, ik heb niet helemaal stilgezeten

[Bezulba]

creative8500 schreef op 10 december 2003 @ 17:12:
[...]

Geweldig dat jij dit ook zegt, precies mijn idee! Dit moet toch mogelijk zijn?
Ik zal bovendien nog eens wat extra's posten hierover, ik heb niet helemaal stilgezeten

zoals femme al melde, je introduceert een hele hoop nieuwe bugs bij een complete redo van de frontpage, terwijl de gebruiker er weinig tot nixs van merkt.

en dit is nog een statisch geheel, mischien kost het wel maanden voordat de totale dynamic contect erin verwerkt kan worden.

[creative8500]

eendje schreef op 10 december 2003 @ 17:21:
zoals femme al melde, je introduceert een hele hoop nieuwe bugs bij een complete redo van de frontpage, terwijl de gebruiker er weinig tot nixs van merkt.

en dit is nog een statisch geheel, mischien kost het wel maanden voordat de totale dynamic contect erin verwerkt kan worden.

Weinig tot niks? Op mijn computer (500mhz P3) ken ik geen langzamere website dan Tweakers.net, hoor; het duurt zeven tot tien seconden voordat de site op mijn scherm verschijnt. Dat is volledig over bij de nieuwe versie. Die tijd zit overigens in het renderen, niet in het downloaden (waarom niet? Cistron Maxx )

Bovendien kun je veel makkelijker nieuwe modules aan de site toevoegen, doordat het onderhoud en de code flexibeler en inzichtelijker is.

En verder: wie wil nu ook in één keer de hele site omzetten? Dat doe je toch gewoon stapsgewijs? Eerst de Frontpage, dan de artikelen, dan de Pricewatch, etcetera...

[ Voor 20% gewijzigd door creative8500 op 10-12-2003 17:33 ]

[Verwijderd]

Spider.007 schreef op 10 december 2003 @ 17:09:
jammer dat dit een beetje doodvalt; in hoeverre is er vanuit Tweakers.net interesse om bijvoorbeeld een subdomein (w3c.tweakers.net ofzo) aan te maken en daar deze versie van Tweakers.net op te zetten? Het lijkt met dat het niet meer dan een paar dagen werk kost om de backend hierin te hangen; en de voordelen zijn toch wel legio. Als alles uiteindelijk erin hangt kan wellicht gekeken worden naar het vervangen van de www door de w3c versie

Ten eerste is 'een paar dagen' wel erg kort door de bocht. Uitgaande van de grootte en scope van tweakers.net en de verschillende subdomeinen (GoT niet meegerekend) zou een week of twee implementatietijd me niet verbazen.

Bovendien zou dit betekenen dat de crew achter Tweakers een aantal hobbyisten zou moeten laten stoeien met hun backend en dat lijkt me ook niet al te verstandig.

Tegen de tijd dat Tweakers toe is aan een nieuw design zal er ongetwijfeld worden overwogen om W3C-complient code te gaan schrijven. De baten van een overhaul van de bestaande site wegen waarschijnlijk niet op tegen de kosten.

[creative8500]

Blues: Tegen de tijd dat Tweakers toe is aan een nieuw design zal er ongetwijfeld worden overwogen om W3C-complient code te gaan schrijven. De baten van een overhaul van de bestaande site wegen waarschijnlijk niet op tegen de kosten.

Denk jij hiernaast ook, dat het onverstandig is om een aantal mensen gewoon de kans te geven om de Frontpage dynamisch te herbouwen? Zoals je zei: hobbyisten; een gedeelte van de crew zou zelf enkele jaren geleden waarschijnlijk ook graag een dergelijke kans gehad willen hebben. Nu ze in de positie zijn om deze te geven, waarom geef je die niet, dan? Er zijn toch geen nadelen aan verbonden? Ikzelf zou erg graag de mogelijkheid hebben om, zoals Spider.007 zei, op een aparte subdomeinnaam met PHP dit te proberen!

Je denkt toch niet dat ik bij een volgend ontwerp weer zin heb om daar vrijwillig tijd in te steken - na deze behandeling? Ik snap sowieso niet dat dit aanbod wordt nu afgeslagen.

Femme (ik las dat jij de HTML verzorgt), zou je dit project niet groen licht willen geven? _{Kleine moeite toch?}

[djluc]

Is het systeem wat er momenteel achter hangt niet geschikt om met meerdere layouts te werken? Als dit zo is kan ik het wel begrijpen. Anders zou het inderdaad een leuke testcase zijn. Zeker als de stats ineens heel erg naar deze remake-layout zouden gaan wijzen

[Verwijderd]

creative8500 schreef op 10 december 2003 @ 17:55:
Er zijn toch geen nadelen aan verbonden? Ikzelf zou erg graag de mogelijkheid hebben om, zoals Spider.007 zei, op een aparte subdomeinnaam met PHP dit te proberen!

Tweakers.net is een bedrijf. Een bedrijf dat constant moet werken om zijn reputatie als top nederlandse tech-nieuws aanbieder hoog te houden. Ik denk dat je onderschat wat voor een risico's ze lopen bij een eventuele nieuwe implementatie, zelfs al is het een subdomein. Het is allemaal extra werk, juist voor de crew omdat zij verantwoordelijk zijn voor de kwaliteit van alles wat er via tweakers.net de wereld in wordt gestuurd. Op dit moment is het vanuit een zakenman-perspectief gewoon niet zinvol om dat pad in te gaan. Jammer, maar helaas.

[CrashOne]

Kan ik best begrijpen, maar maak dan een private subdomein aan waar gekeken kan worden naar de mogelijkheden.

Het lijkt mij mooi als t.net w3c valid is, tweakers is toch nederlands grootste tech site, dus waarom niet een goed voorbeeld proberen te geven?

[Spider.007]

Verwijderd schreef op 10 december 2003 @ 18:27:
[...]


Tweakers.net is een bedrijf. Een bedrijf dat constant moet werken om zijn reputatie als top nederlandse tech-nieuws aanbieder hoog te houden. Ik denk dat je onderschat wat voor een risico's ze lopen bij een eventuele nieuwe implementatie, zelfs al is het een subdomein. Het is allemaal extra werk, juist voor de crew omdat zij verantwoordelijk zijn voor de kwaliteit van alles wat er via tweakers.net de wereld in wordt gestuurd. Op dit moment is het vanuit een zakenman-perspectief gewoon niet zinvol om dat pad in te gaan. Jammer, maar helaas.

Tweakers.net heeft genoeg mogelijkheden om dit proces veilig te laten verlopen:
• Er zijn een klein aantal leden (zeg 1 of 2) die een update aan de crew aan mogen bieden.
• De crew plaatst deze na een evt. review op het subdomein en geeft de ontwikkelaars een week de tijd om eventuele problemen op te lossen. (dan is de volgende update)
• Het subdomein kan met een wachtwoord beveiligd worden totdat de crew de layout goed genoeg acht.

Verder neem ik aan dat er gebruik wordt gemaakt van een template parser die de ontwikkelaars niet de kans geeft om iets gevaarlijks te doen.

Ik ben er van overtuigd dat door het opschonen van de code; het vervangen van JavaScriptjes door W3C compliant HTML code en CSS de snelheid en onderhoudbaarheid van de code alleen maar verbeterd wordt. Het design dat creative8500 geheel belangeloos in elkaar heeft gezet bewijst nu al sneller te zijn!

[crisp]

ik vind persoonlijk dat je je site nooit helemaal afhankelijk moet maken van javascript; toevallig was ik vanmiddag GoT even aan het browsen met javascript disabled (wat prima gaat), maar op Tnet zelf kom je daar niet ver mee. Ik ben zelf nogal een javascript-fanaat, maar een website (een web-app of een game is wat anders) zou ik er nooit volledig afhankelijk van maken, en met een goede structuur en http-compressie is de winst bij het puur gebruik van javascript om je document structuur op te bouwen maar minimaal (en lastig onderhoudbaar zoals al gezegd werd).

[ Voor 5% gewijzigd door crisp op 10-12-2003 19:05 ]

[Spider.007]

crisp schreef op 10 december 2003 @ 19:04:
ik vind persoonlijk dat je je site nooit helemaal afhankelijk moet maken van javascript; toevallig was ik vanmiddag GoT even aan het browsen met javascript disabled (wat prima gaat), maar op Tnet zelf kom je daar niet ver mee. Ik ben zelf nogal een javascript-fanaat, maar een website (een web-app of een game is wat anders) zou ik er nooit volledig afhankelijk van maken, en met een goede structuur en http-compressie is de winst bij het puur gebruik van javascript om je document structuur op te bouwen maar minimaal (en lastig onderhoudbaar zoals al gezegd werd).

Ik denk dat heeeeeel erg vroeger (toen de structuur van Tweakers is neergezet) er wel degelijk snelheidswinst viel te behalen door het gebruik van document.write functies; inmiddels is dat achterhaald. Tweakers.net moet gewoon mee met de volgende stap op het WWW; en dat is het W3C compliant maken van je website; en de snelheid af te laten handelen door de webserver / client onderling (dmv GZIP). Het gebruik van javascript bied inderdaad een marginaal verschil in bestandsgroote; terwijl de verwerkingstijd er enorm op achteruit gaat. Daarom vindt ik dat het initiatief wat hier is neergezet door Tweakers.net met beide handen moet worden aangepakt; aangezien de verandering onvermijdelijk is. Momenteel is er al veel tijd in een W3C site gestoken door een groot deel van de GoT professionals; door dit ontwerp niet over te nemen zal er in een later stadium veel tijd in gestopt moeten worden; al dat werk is nu al gedaan

[creative8500]

Het is daarnaast natuurlijk ook zo dat bij een W3C-compliant gebruik van XHTML en CSS er veel minder snel een rede is om een nieuw design door te voeren.

En als er al een nieuw design komt, kan het gebeuren door slechts één alternatieve stylesheet

Zou het niet mogelijk zijn om de remake te debuggen via alleen GoT-bezoekers? Juist met XHTML/CSS heb je minder last van bugs, glitches, etcetera, en de diversiteit van gebruikers op het forum lijkt me groot genoeg om de debugfase buiten de eigenlijke Tweakers.net-website te houden.

[Harm]

Spider.007 schreef op 10 december 2003 @ 19:36:
Momenteel is er al veel tijd in een W3C site gestoken door een groot deel van de GoT professionals; door dit ontwerp niet over te nemen zal er in een later stadium veel tijd in gestopt moeten worden; al dat werk is nu al gedaan

Het is een feit dat er behoorlijk wat code achter de Fp schuilgaat. Meer dan je zo 1-2-3 zou verwachten en dat is dan ook de reden dat Femme (in dit topic geloof ik ook, gevonden!) al heeft aangegeven daar niet aan te beginnen. Alles hangt samen met alles en het is een enorm werk om al die code te vervangen door de nieuwe code. Maar nu ga ik Femme herhalen, en daar zie ik het nut niet echt van in.

creative8500 schreef op 10 december 2003 @ 17:55:
Femme (ik las dat jij de HTML verzorgt), zou je dit project niet groen licht willen geven? _{Kleine moeite toch?}

Ik denk dat je daarvoor beter een mailtje kan sturen naar Daniel en Femme dan dat je dit in dit topic meldt.

[djluc]

Ik kan me de reactie van Creative opzich wel voorstellen Harm. De meeste mensen hier werken toch wel met een template engine of een andere techniek om layout van het script te scheiden. De tijd om dat een nieuwe layout te implementeren is dan vaak erg klein.

[Harm]

Als dat (gebruikmaken van een template engine) het geval zou zijn, dan zou het niet zoveel werk zijn om de code aan te passen. AFAIK gebeurt dat echter niet en dus is het een enorm werk om de code aan te passen en bij te werken.

[ Voor 1% gewijzigd door Harm op 10-12-2003 21:48 . Reden: BTW ]

[Joen]

Ik heb niet de hele draad doorgelezen en weet niet of anderen dit probleem ook al hadden:
na in het voorbeeldje van TS over wat menu's te hebben bewogen en daarna mijn Internet Explorer venster sluit, maakt Internet Exploerer een ongeldige bwerking volgens Windows
(en vervolgens worden alle IE venster afgesloten )

[Joen]

Owjah! Je begrijpt dus dat ik daarom tegen stem

[djluc]

Misschien is het handig om even je browserversie en eventueel windowsversie te vermelden.

@harm: Dan is het inderdaad heel begrijpelijk hier niet zoveel tijd in te steken. Althans ik vind het begrijpelijk, want dat is ook maar een mening.

[Joen]

@djluc:
Owja, stom! Had het wel willen vertellen, maar vergeten te typen

Windows 2000 Pro NL SP4
Internet Explorer 5.50

[Femme]

Tweakers.net heeft een template engine omdat ik geen plannen heb om de code op een andere layout te draaien dan die van Tweakers.net. T.net is bovendien nogal uitgebreid in verscheidenheid van pagina's. Het is geen forum waar je een forumlijst, topiclijst, topicpagina en nog wat andere pagina's hebt die je snel in een template kunt stoppen. Als ik Tweakers.net volledig op een template engine moet draaien kost ontwikkeling alleen maar meer tijd.

De meest essentiële layout elementen hangen trouwens in javascripts, stylesheets en plaatjes rond en die kunnen relatief eenvoudig gewijzigd worden. Omswitchen van de huidige HTML code die veel gebruik maakt van javascript naar een CSS-site is echter wel veel werk. Ik voel er weinig voor omdat met de huidige layout te doen omdat het voor de bezoekers weinig oplevert. Zij krijgen er dezelfde site voor terug. Er zijn momenteel features die een hogere prioriteit hebben (product survey, specsdatabase) en waar een groter aantal bezoekers van kunnen profiteren dan van een XHTML/CSS site.

Die XHTML/CSS site gaat er uiteindelijk wel komen, alleen niet op korte termijn. Een hybride (overgangs)versie is wellicht wel mogelijk.

[ Voor 5% gewijzigd door Femme op 10-12-2003 23:10 ]

[Spider.007]

Femme schreef op 10 december 2003 @ 23:07:
Tweakers.net heeft een template engine omdat ik geen plannen heb om de code op een andere layout te draaien dan die van Tweakers.net. T.net is bovendien nogal uitgebreid in verscheidenheid van pagina's. Het is geen forum waar je een forumlijst, topiclijst, topicpagina en nog wat andere pagina's hebt die je snel in een template kunt stoppen. Als ik Tweakers.net volledig op een template engine moet draaien kost ontwikkeling alleen maar meer tijd.

De meest essentiële layout elementen hangen trouwens in javascripts, stylesheets en plaatjes rond en die kunnen relatief eenvoudig gewijzigd worden. Omswitchen van de huidige HTML code die veel gebruik maakt van javascript naar een CSS-site is echter wel veel werk. Ik voel er weinig voor omdat met de huidige layout te doen omdat het voor de bezoekers weinig oplevert. Zij krijgen er dezelfde site voor terug. Er zijn momenteel features die een hogere prioriteit hebben (product survey, specsdatabase) en waar een groter aantal bezoekers van kunnen profiteren dan van een XHTML/CSS site.

Die XHTML/CSS site gaat er uiteindelijk wel komen, alleen niet op korte termijn. Een hybride (overgangs)versie is wellicht wel mogelijk.

Ik begrijp dat het veel tijd kan gaan kosten en dat het momenteel weinig prioriteit heeft. Hoe sta je tegenover het idee om 1 of twee mensen toegang te geven tot een gedeelte van de Tweakers.net server alwaar zij de backend kunnen implementeren in de hier gepresenteerde front-end? Is hier iets voor in te richten? Dat heeft als voordeel dat mensen die er momenteel tijd en moeite in willen steken dit kunnen doen; en dat de crew van T.net hier weinig aan hoeft te doen. (zie ook mijn post hier)

[Genoil]

het implementeren van de XHTML/CSS versie in de huidige backend heeft weinig tot niets met het oorspronkelijke doel van de remake te maken. het zou (denk ik)waarschijnlijk neerkomen op een hoop gevrot met (gedateerde) PHP scripts die toegespitst zijn op de huidige implementatie. als je de vernieuwing wilt doortrekken richting backend, zul je daar ook vernieuwend moeten zijn (xslt). anders heeft het weinig zin (hoewel ik het nut van deze oefening sowieso betwijfel, afgezien van de educatieve waarde ervan). ik sta vierkant achter femme's beargumentatie en klantgerichte (itt techniekgerichte) opstelling. een bedrijfskritisch onderdeel van de techniek (backend) openstellen voor gebruik door hobbyisten (hoe professioneel in hun werk deze ook zijn, knap staaltje werk natuurlijk, deze remake) is natuurlijk helemaal van de zotten

[Skinkie]

Toen keek ik ook is in het topic... volgens mij zou zou het mooiste zijn als je de frontpage net zo uit kan lurken als je met het XML knopje onder aan deze pagina kan. Zoals ook de persoon hier boven al zei... een XSItje er tegen aan en het boeit niet meer hoe xhtml het is... het moet gewoon valideren anders werkt het niet.

maar hier zijn natuurlijk legio dingen tegen, als inkomsten mislopen van banners, ik verbaasde me dan ook dat die forum feature er gewoon is

[Verwijderd]

zou het niet beter zijn als er een soap/xml webservice komt (in de toekomst). De opzet van alle (sub) pagina's is in principe heel eenvoudig (het past m.i. redelijk goed in een xml bestand). Dan kan iedereen daar zijn eigen stylesheet overheen gooien en is iedereen weer gelukkig

Je kunt natuurlijk in de soap header de username/password van een gebruiker meesturen om te voorkomen dat je hele site geripped wordt door een andere site.

Tweakers.net biedt informatie aan, en dat doen ze kwalitatief goed, alleen de output zou veel optimaler kunnen. Nadeel is wel, daar geef ik sommige mensen gelijk in, als je een eigen stylesheet maakt je ook een bannerfree site kan maken dus zou je de feature alleen toegankelijk moeten maken voor mensen met een tweakers.net full abo

[crisp]

*bump*

Ik moest ineens weer aan dit topic denken
Grappig hoe dingen kunnen lopen en dat juist ik me momenteel o.a. hiermee bezig hou

Misschien wel leuk om eens te kijken hoe de huidige frontpage er momenteel bijstaat als het gaat om markup en validatie.
Ik denk dat we op dit moment wel in de hybride overgangsfase zitten waar Femme het toendertijd over had; een aantal zaken zijn al aangepakt en bij nieuwe ontwikkelingen wordt steeds meer gelet op goede markup, scheiding van content en opmaak en goed gebruik van o.a. javascript.

1 van de eerste dingen die opvalt aan de 'nieuwe' frontpage is waarschijnlijk wel het feit dat de meeste markup niet meer met javascript gegenereerd wordt; het werken met 'pure' opmaak biedt grote voordelen (betere onderhoudbaarheid, geen afhankelijkheden van de client, beter doorzoekbaar door searchengines) en hedentendage maar weinig nadelen - filesizes zijn iets toegenomen (maar niet veel dankzij HTTP compressie), maar steeds meer mensen beschikken ook over snellere verbindingen.
Verder valt op dat een aantal elementaire elementen van de site; o.a. het menu, het tabmenu en de updatetracker, een duidelijke markup hebben en volledig CSS-gestyled zijn.
Wel kom je nog veel tag-soup tegen (bloated tables, veel inline styles); dat is allemaal nog legacy, maar er is wel getracht dat zoveel mogelijk HTML4.01 Transitional compliant te maken.

Vanuit een behoefte aan een betere basis zijn deze elementen mede aangepakt, ook omdat deze basis weer herbruikbaar is bij bijvoorbeeld een redesign. Ik kan daarbij wel vertellen dat daar al veel werk in is gaan zitten.

[André]

En toch ben je dan al weer bijna 2 jaar verder

Maar goed, beter laat dan nooit idd. Tweakers.net is zeer zeker de goede weg in geslagen. Al heb ik het vermoeden dat sommige zaken op zoekmachine-gebied wel beter zouden moeten kunnen

[BtM909]

André schreef op woensdag 17 augustus 2005 @ 23:40:
En toch ben je dan al weer bijna 2 jaar verder

Maar goed, beter laat dan nooit idd. Tweakers.net is zeer zeker de goede weg in geslagen. Al heb ik het vermoeden dat sommige zaken op zoekmachine-gebied wel beter zouden moeten kunnen

Geef eens een voorbeeld in relatie met tweakers.net

[marty]

ik kwam een paar weken terug op de frontpage en toen kon de stylesheet (tijdelijk) niet gevonden worden. Moet zeggen: het zag er erg netjes uit!! Alles bleef overzichtelijk en logisch bij elkaar staan.

[HawVer]

Netjes! Goed bezig geweest.