[alg] Slechtste programmeervoorbeelden deel 4

[Otherside1982]

HawVer schreef op woensdag 27 januari 2010 @ 14:28:
[...]

Wat is er slecht aan de code? Het feit dat het anders werkt dan dat de klant verwacht?

Ja OK, met de code op zich is er niet echt iets verkeerd inderdaad. De functionaliteit echter klopt natuurlijk van geen kanten: als het verplichte velden zijn, dan kan je het toch niet maken om zomaar zelf wat waardes te gaan invullen?

[ameesters]

Modbreak:

Of je leest de knalgrote topicwarning effe

[ Voor 81% gewijzigd door RobIII op 27-01-2010 18:48 ]

[Onbekend]

.oisyn schreef op woensdag 27 januari 2010 @ 13:54:
Het zou ook wat zijn, als je in een query die heel lang duurt en records aan het ophalen bent adhv de huidige datum dat je dan inconsistente resultaten krijgt omdat de getdate() bij het eerste record niet meer hetzelfde is als de getdate() bij het laatste.

Ik heb helaas geen SQL2008 om te testen maar die kan het volgende statement uitvoeren:

code:

select datepart(ns, getdate()), datepart(ns, getdate()), datepart(ns, getdate()), datepart(ns, getdate()), datepart(ns, getdate()), datepart(ns, getdate()), datepart(ns, getdate()), datepart(ns, getdate())

Is er iemand dit dat kan doen? Als de resultaten het zelfde zijn is dat gelukkig veilig.

whoami schreef op zaterdag 26 december 2009 @ 23:00:

code:

select day(getdate())
select month(getdate())
select year(getdate())

Deze code bestaat uit 3 losse select statements, en hier zal altijd steeds opnieuw de datum opgehaald worden wat dus dat datumprobleem kan veroorzaken.

[RobIII]

Onbekend schreef op woensdag 27 januari 2010 @ 18:53:
[...]

Ik heb helaas geen SQL2008 om te testen maar die kan het volgende statement uitvoeren:

code:

select datepart(ns, getdate()), datepart(ns, getdate()), datepart(ns, getdate()), datepart(ns, getdate()), datepart(ns, getdate()), datepart(ns, getdate()), datepart(ns, getdate()), datepart(ns, getdate())

Is er iemand dit dat kan doen? Als de resultaten het zelfde zijn is dat gelukkig veilig.

code:

----------- ----------- ----------- ----------- ----------- ----------- ----------- -----------
817000000   817000000   817000000   817000000   817000000   817000000   817000000   817000000

(1 row(s) affected)

Ik had niet anders verwacht.

[Onbekend]

Gelukkig.
Anders hadden meer programma's er problemen mee gehad.

Edit @hieronder:
Inderdaad. Het zijn wel hele mooie ronde getallen.....

[ Voor 34% gewijzigd door Onbekend op 27-01-2010 19:28 ]

[.oisyn]

RobIII schreef op woensdag 27 januari 2010 @ 18:57:
[...]

code:

----------- ----------- ----------- ----------- ----------- ----------- ----------- -----------
817000000   817000000   817000000   817000000   817000000   817000000   817000000   817000000

(1 row(s) affected)

Ik had niet anders verwacht.

Blijkbaar is de resolutie wel slechts een milliseconde. Probeer eens een ingewikkelde query te doen op een bestaande tabel (die gegarandeerd >1ms duurt), waarbij je per geselecteerde row ook nog eens datepart(ns, getdate()) doet.

[Glimi]

getDate() is volgens de MSDN gelijk aan de CURRENT_TIMESTAMP psuedo kolom. Deze kolom mag volgens de SQL92 standaard slechts eenmaal per SQL statement gevalueerd. Of het ook gebeurd in SQL server is een tweede natuurlijk. Ik weet wel dat Postgres en Oracle het wel doen.

quote: http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

3) If an SQL-statement generally contains more than one reference
to one or more <datetime value function>s, then all such ref-
erences are effectively evaluated simultaneously. The time of
evaluation of the <datetime value function> during the execution
of the SQL-statement is implementation-dependent.

[sanzut]

Modbreak:

En toen je de topicwarning bekeek had je niet zo iets van: naaah, laat ik dit niet posten?

[ Voor 74% gewijzigd door Creepy op 27-01-2010 20:48 ]

[HeSitated]

.oisyn schreef op woensdag 27 januari 2010 @ 19:24:
[...]
Probeer eens een ingewikkelde query te doen op een bestaande tabel (die gegarandeerd >1ms duurt), waarbij je per geselecteerde row ook nog eens datepart(ns, getdate()) doet.

Maakt niet uit, ik heb het geprobeerd met een cross join over drie tabellen geunioned met een cross join van drie andere tabbellen en ze leveren allemaal het zelfde resultaat op....

De uitvoer van de query duurde bijna een minuut en leverde 5.000.000 records op.

Om even terug te komen op het onderwerp....

Van de week roept een collega me bij zich (hij is hoofd van de afdeling , met de vraag waarom zijn query niet werktte.....

Daarim stond o.a [pseudo-code] Als tabel X bestaat dan drop tabel X
SELECT veld A, VeldB
INTO X
FROM .....

Op de vraag waarom ie geen tijdelijke tabellen gebruikte, kreeg ik het antwoord: "als ik dan de query twee keer uitvoer bestaat de tabel al...."

[ Voor 27% gewijzigd door HeSitated op 27-01-2010 20:38 . Reden: tikfoutje ]

[.oisyn]

sanzut schreef op woensdag 27 januari 2010 @ 20:05:
*snip*

* .oisyn wijst nog maar een keer naar de topicwaarschuwing

[ Voor 31% gewijzigd door Creepy op 27-01-2010 20:48 ]

[sanzut]

Hmm volgende keer de topic warning ook echt even lezen ipv er alleen voorbij scrollen.

Oprecht niet gezien/niet opgevallen/niet gelezen, excuses!

[YakuzA]

* YakuzA houd er blijkbaar van om wat overbodige statements te typen:

C#:

DateTime date = DateTime.Parse(SourceData.Rows[i][0].ToString());
SourceData.Rows[i][0] = (double)new XDate(date.Year, date.Month, date.Day);

(moet later sorteren op datum, maar blijkbaar kan in C# de DataTable.Select niet goed sorteren op DateTime variabelen , vandaar naar een double)

[boe2]

Is het dan niet eenvoudiger om gewoonweg een ORDER BY in je sql statement te steken waarmee je die datatable gevuld hebt?

[MatHack]

YakuzA schreef op woensdag 27 januari 2010 @ 23:28:
* YakuzA houd er blijkbaar van om wat overbodige statements te typen:

C#:

DateTime date = DateTime.Parse(SourceData.Rows[i][0].ToString());
SourceData.Rows[i][0] = (double)new XDate(date.Year, date.Month, date.Day);

(moet later sorteren op datum, maar blijkbaar kan in C# de DataTable.Select niet goed sorteren op DateTime variabelen , vandaar naar een double)

Is het niet makkelijker om date.Ticks te gebruiken i.p.v. een nieuwe instantie van een object te maken en dat dan weer te casten naar een double?

[YopY]

Is het niet makkelijker om alles gewoon op één regel te pleuren en een nozel commentaar erbij te zetten (evt. met een ASCII koe of henk), zodat jij of iemand anders over vijf jaar in dit topic terugkomt, er nog even hartelijk over kunt lachen?

[L-VIS]

Ik heb ooit een keer (op een vrijdagmiddag) code geschreven om Data (meervoud van datum) te presenteren. Deze data waren in Amerikaanse notaties:

C#:

DateTime dt = DateTime.Now;
string date = dt.Day + "-" + dt.Month + "-" + dt.Year;

Toch jammer dat ik er maandag achterkwam dat de .ToString een mooie overload bevat

[.oisyn]

Hier is een slecht programmeervoorbeeld: de hardware-implementatie van de pow() functie op de RSX (de grafische chip van nVidia) op de PS3 geeft NaN terug bij machten kleiner dan 1

[bobo1on1]

Zo ken ik er nog wel een paar van nvidia:

GLX_SGI_video_sync werkt niet meer op linux als je met randr de display mode verandert, je krijgt met glXGetVideoSyncSGI nog wel een vblank counter terug maar glXWaitVideoSyncSGI wacht niet meer op een vertical blank, die returnt meteen, tenzij je de opengl context opnieuw attacht.

Het parsen van glsl ging vroeger alleen goed als de locale op C stond, zou best kunnen dat dat al opgelost is.

VDPAU kan op wat oudere gpu's video's van bepaalde afmetingen niet goed decoden (dat is een silicon bug).

Als je met xrender het root window scaled naar een pixmap krijgt je bij een fullscreen opengl window vaak de backbuffer terug, tenzij je flipping uitzet.

Als je een texture maakt met een border van 0 krijg je op windows en osx toch een border maar op linux niet (goh waarom krijg ik toch allemaal streepjes met deze shader).

[ Voor 10% gewijzigd door bobo1on1 op 28-01-2010 15:41 ]

[.oisyn]

bobo1on1 schreef op donderdag 28 januari 2010 @ 15:35:
Zo ken ik er nog wel een paar van nvidia:

Beetje flauw, iedereen produceert bugs in software. Bugs in hardware is echter een groter probleem, zeker bij een basis-math-functie als pow(). Dat kun je namelijk niet achteraf fixen.

[ Voor 6% gewijzigd door .oisyn op 28-01-2010 15:55 ]

[PrisonerOfPain]

.oisyn schreef op donderdag 28 januari 2010 @ 15:21:
Hier is een slecht programmeervoorbeeld: de hardware-implementatie van de pow() functie op de RSX (de grafische chip van nVidia) op de PS3 geeft NaN terug bij machten kleiner dan 1

Beetje hetzelfde gezever als noise() die altijd 0 terug geeft (de oorzaak is ongetwijfeld anders, maar SM1 stelt het al verplicht). Is het niet op te lossen met exp(x * log(y))?

[ Voor 4% gewijzigd door PrisonerOfPain op 28-01-2010 17:06 ]

[.oisyn]

Is het niet op te lossen met exp(x * log(y))?

Weet ik niet, ik liep zelf niet tegen de issue aan. Maar dat maakt de shader wel weer duurder. Het kwam trouwens boven water door artists die zich afvroegen waarom de pixels ineens zwart werden op de PS3 als ze de specular power van een material op 0 zetten

[PrisonerOfPain]

.oisyn schreef op donderdag 28 januari 2010 @ 17:13:
[...]

Weet ik niet, ik liep zelf niet tegen de issue aan. Maar dat maakt de shader wel weer duurder. Het kwam trouwens boven water door artists die zich afvroegen waarom de pixels ineens zwart werden op de PS3 als ze de specular power van een material op 0 zetten

Wacht even, de PS3 is GLSL based of niet? Dan is het gedrag gewoon conform aan de spec.

genType pow (genType x, genType y)

Returns x raised to the y power, i.e., x^y
Results are undefined if x < 0.
Results are undefined if x = 0 and y <= 0.

En de exp(x * log(y)) truuk gaat 't dan niet oplossen aangezien log(x) voor x <= 0 ook undefined is.

genType log (genType x)

Returns the natural logarithm of x, i.e., returns the value
y which satisfies the equation x = ey.
Results are undefined if x <= 0.

[ Voor 18% gewijzigd door PrisonerOfPain op 28-01-2010 17:28 ]

[MBV]

Hij heeft het waarschijnlijk over waarden tussen 0 en 1

[PrisonerOfPain]

MBV schreef op donderdag 28 januari 2010 @ 17:28:
Hij heeft het waarschijnlijk over waarden tussen 0 en 1

Als de specular 0 is krijg je pow(x, 0) = NaN dus is het conform aan de spec. Als het tussen [0..1] ook fout gaat is het nogal een grove bug.

[NC83]

PrisonerOfPain schreef op donderdag 28 januari 2010 @ 17:26:
[...]


Wacht even, de PS3 is GLSL based of niet? Dan is het gedrag gewoon conform aan de spec.


[...]


En de exp(x * log(y)) truuk gaat 't dan niet oplossen aangezien log(x) voor x <= 0 ook undefined is.


[...]

Enkel om snelheid op de PS3 te krijgen maak je geen gebruik van OpenGL maar van de PS3 specifieke API. En om cross platform te kunnen werken zijn de meeste shaders CG ipv GLSL of HLSL. En in CG moet x in dit geval ook groter dan 0 zijn.
log( x ) Natural logarithm ln( x ) ; x must be greater than 0.
En sinds maart 2009 ziet hetzelfde probleem in HLSL daarvoor werkt het gewoon.

[ Voor 15% gewijzigd door NC83 op 28-01-2010 19:15 ]

[kunnen]

PrisonerOfPain schreef op donderdag 28 januari 2010 @ 17:31:
[...]


Als de specular 0 is krijg je pow(x, 0) = NaN dus is het conform aan de spec. Als het tussen [0..1] ook fout gaat is het nogal een grove bug.

Ik zou het nog een keer lezen, die spec beschrijft exact hoe je zou verwachten dat pow werkt, en pow(x, 0) = 1

[Tanuki]

L-VIS schreef op donderdag 28 januari 2010 @ 15:16:
Ik heb ooit een keer (op een vrijdagmiddag) code geschreven om Data (meervoud van datum) te presenteren. Deze data waren in Amerikaanse notaties:

C#:

DateTime dt = DateTime.Now;
string date = dt.Day + "-" + dt.Month + "-" + dt.Year;

Toch jammer dat ik er maandag achterkwam dat de .ToString een mooie overload bevat

De mijne.

C#:

        internal static string DisplayDate(DateTime dateTime)
        {
            return DisplayDate(dateTime, '/');
        }

        internal static String DisplayDate(DateTime dateTime, char separator)
        {
            return dateTime.Year.ToString().PadLeft(4, '0') + separator
                 + dateTime.Month.ToString().PadLeft(2, '0') + separator
                 + dateTime.Day.ToString().PadLeft(2, '0');
        }

[.oisyn]

PrisonerOfPain schreef op donderdag 28 januari 2010 @ 17:26:
[...]


Wacht even, de PS3 is GLSL based of niet? Dan is het gedrag gewoon conform aan de spec.

Volgens die spec moet x⁰ gewoon werken als x > 0. Als x=0 boeit het niet, want dan heb je toch geen specular

[RobIII]

N.a.v. .oisyn in "[alg] Slechtste programmeervoorbeelden d..." de daarop volgende discussie... dat sméékt gewoon om een nieuwe smiley...


Bij deze

[ Voor 6% gewijzigd door RobIII op 28-01-2010 20:01 ]

[Snake]

Call me stupig, maar als je pow(x, .5) doet dan moet je toch niet 0 terug krijgen? Noch NaN? Omdat

genType pow (genType x, genType y)

Returns x raised to the y power, i.e., x^y
Results are undefined if x < 0.
Results are undefined if x = 0 and y <= 0.

x != 0, dus het resultaat moet gewoon defined zijn.

[Matis]

Snake schreef op donderdag 28 januari 2010 @ 20:26:
Call me stupig, maar als je pow(x, .5) doet dan moet je toch niet 0 terug krijgen? Noch NaN? Omdat


[...]

x != 0, dus het resultaat moet gewoon defined zijn.

Ligt er aan, als je het in een integer probeert te stoppen wel, ligt ook aan de waarde van x, maar normaal is tot de macht een half hetzelfde als worteltrekken.

Dus wat dat betreft is het wel vreemd

[NC83]

Matis schreef op donderdag 28 januari 2010 @ 20:29:
[...]

Ligt er aan, als je het in een integer probeert te stoppen wel, ligt ook aan de waarde van x, maar normaal is tot de macht een half hetzelfde als worteltrekken.

Dus wat dat betreft is het wel vreemd

Alleen gebruik je in shaders heel weinig integers, en zijn het meerendeel van je variabelen zelfs float4 dus een vector van 4 floats.

[Verwijderd]

code:

$_POST['captcha'] = ereg_replace("j", "J", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("k", "K", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("l", "L", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("m", "M", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("n", "N", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("o", "O", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("p", "P", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("q", "Q", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("r", "R", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("s", "S", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("t", "T", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("u", "U", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("v", "V", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("w", "W", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("x", "X", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("y", "Y", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("z", "Z", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("a", "A", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("b", "B", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("c", "C", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("d", "D", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("e", "E", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("f", "F", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("g", "G", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("h", "H", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("i", "I", $_POST['captcha']);

Dit kwam ik tegen op een live website. Strtoupper, anyone?

[Haan]

Gevalletje ken je API's

En gewoon stom, want volgens mij hebben de meeste gangbare programmeertalen wel een string to Upper/Lowercase functie.

[qanar]

Is ereg_replace beter/sneller dan gewoon str_replace in een geval als dit, waarbij je (niet echt) een reguliere expressie gebruikt?

[Otherside1982]

Verwijderd schreef op vrijdag 29 januari 2010 @ 10:18:

code:

$_POST['captcha'] = ereg_replace("j", "J", $_POST['captcha']);
$_POST['captcha'] = ereg_replace("k", "K", $_POST['captcha']);
...
$_POST['captcha'] = ereg_replace("i", "I", $_POST['captcha']);

Dit kwam ik tegen op een live website. Strtoupper, anyone?

Vreemde volgorde ook, welk alfabet is dat?
Gelukkig zijn er geen copy/paste fouten gemaakt en wordt bvb i niet naar K omgezet

[mithras]

qanar schreef op vrijdag 29 januari 2010 @ 10:47:
Is ereg_replace beter/sneller dan gewoon str_replace in een geval als dit, waarbij je (niet echt) een reguliere expressie gebruikt?

Check the manual:

quote: http://www.php.net/manual/en/function.ereg-replace.php

Warning

This function has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged.

[...]

Tip

preg_replace(), which uses a Perl-compatible regular expression syntax, is often a faster alternative to ereg_replace().

quote: http://www.php.net/manual/en/function.str-replace.php

If you don't need fancy replacing rules (like regular expressions), you should always use this function instead of ereg_replace() or preg_replace().

[ Voor 13% gewijzigd door mithras op 29-01-2010 11:05 ]

[Shagura]

qanar schreef op vrijdag 29 januari 2010 @ 10:47:
Is ereg_replace beter/sneller dan gewoon str_replace in een geval als dit, waarbij je (niet echt) een reguliere expressie gebruikt?

Nee, ordinaire stringfuncties zijn vrijwel altijd sneller. Tenzij je natuurlijk op patronen zoekt waar regexps juist voor gemaakt zijn.

[Spinal]

Misschien een echt programmeervoorbeeld, maar zie dit net in de HTML van Google Code en wil het toch met jullie delen:

HTML:

 <div class="pagination">
 <table cellpadding="0" cellspacing="0" class="flipper">
 <tbody>
 <tr>
 
 <td>
 <ul>
 
 <li><a href="detail?r=4990" title="Previous">&lsaquo;r4990</a></li>
 
 </ul>
 </td>
 
 <td><b>r4991</b></td>
 
 <td>
 <ul>
 
 <li><a href="detail?r=4992" title="Next">r4992&rsaquo;</a></li>
 
 </ul>
 </td>
 
 </tr>
 </tbody>
 </table>
 </div>

[MBV]

Ehm, wazzup? Behalve de zinloze ul/li constructie is dit gewoon valid HTML zo te zien, en Google werkt neem ik aan met standaard HTML-generators die misschien dit soort overtollige tokens ertussen zetten.

[Enfer]

Misschien wordt er bedoeld dat er voor de layout een tabel gebruikt wordt in een divje?

[MBV]

Oh sorry, dan mag je gaan quoten van 90% van de websites. Zelfs voor de websites

MBV schreef op dinsdag 02 februari 2010 @ 16:02:
Oh sorry, dan mag je gaan quoten van 90% van de websites. Zelfs voor de websites die de afgelopen 3 jaar een layout-update hebben gehad zie ik het somber in...

die de afgelopen 3 jaar een layout-update hebben gehad zie ik het somber in...
- GOT: code-tags levert een table op. Semantisch gezien bullshit.
- Fok!: bovenste navigatiebalk met frontpage, sport, games etc
- Nu.nl: copyright bij nieuwsberichten, totaal van de poll, plus nog wat dubieuze tables.

[ Voor 60% gewijzigd door MBV op 02-02-2010 16:08 ]

[mcDavid]

MBV schreef op dinsdag 02 februari 2010 @ 16:02:
Oh sorry, dan mag je gaan quoten van 90% van de websites. Zelfs voor de websites
[...]

die de afgelopen 3 jaar een layout-update hebben gehad zie ik het somber in...
- GOT: code-tags levert een table op. Semantisch gezien bullshit.
- Fok!: bovenste navigatiebalk met frontpage, sport, games etc
- Nu.nl: copyright bij nieuwsberichten, totaal van de poll, plus nog wat dubieuze tables.

doe op fok eens de paginabron van een forumtopic bekijken er worden voor iedere post iets van 3 geneste tabellen gebruikt!

Maar ik denk dat het in dit geval vooral om de lists met maar één item gaat. Dat is natuurlijk per definitie geen list. Dit is een gevalletje wel de klok horen luiden (menus horen in list) maar nog geen idee waar precies de klepel zit (die items horen dan wel in dezélfde list gegroepeerd).

[MBV]

Ach, ik vind hem wat overdreven. Als er nou iets van <ul><li></ul></li> had gestaan was het iets anders geweest

[BarôZZa]

Ach ja, het table verhaal. In sommige gevallen is het gewoon erg handig. Vooral dat cellen naast elkaar verticaal meeschalen met elkaar. Als je met div's werkt dan moet je vaak ook allerlei vervelende trucjes uithalen om iets te krijgen wat je met een simpele table zo voor elkaar hebt. Dan zit je met genestelde div's en background trucjes om een balk te laten doorlopen oid. Om nog maar te zwijgen over hoe sommige browsers ermee omgaan.
Voor de rest zal een layout van een forum qua structuur wel hetzelfde blijven, dus dan is het imo totaal geen probleem. Als het werkt, dan werkt het.

Zelf probeer ik het zoveel mogelijk te vermijden, maar ik zie vaak zo'n overdreven allergische reactie op een paar tables in de source

[Cartman!]

BarôZZa schreef op dinsdag 02 februari 2010 @ 17:11:
Ach ja, het table verhaal. In sommige gevallen is het gewoon erg handig. Vooral dat cellen naast elkaar verticaal meeschalen met elkaar. Als je met div's werkt dan moet je vaak ook allerlei vervelende trucjes uithalen om iets te krijgen wat je met een simpele table zo voor elkaar hebt. Dan zit je met genestelde div's en background trucjes om een balk te laten doorlopen oid. Om nog maar te zwijgen over hoe sommige browsers ermee omgaan.

Dat hangt gewoon af van hoe goed je kunt CSS-en natuurlijk, ik herken je probleem helemaal niet namelijk.

Voor de rest zal een layout van een forum qua structuur wel hetzelfde blijven, dus dan is het imo totaal geen probleem. Als het werkt, dan werkt het.

Das geen instelling imo. Het kan altijd beter, sneller en mooier

Zelf probeer ik het zoveel mogelijk te vermijden, maar ik zie vaak zo'n overdreven allergische reactie op een paar tables in de source

Je pikt de amateurs er vaak snel tussenuit als je ergens een site met tables voor layout ziet Opzich niet erg maar als alle sites volgens dezelfde semantiek gemaakt worden schieten we daar best wel iets mee op denk ik.

[Spinal]

Ging mij niet alleen om het gebruiken van een tabel voor layout, maar ín die tabel staat in elke cel een <ul> met één <li> erin. Dit had prima gekunt zonder die hele tabel en in één <ul> met 3 <li>'s.

[mcDavid]

ZanderZ schreef op dinsdag 02 februari 2010 @ 17:31:
Ging mij niet alleen om het gebruiken van een tabel voor layout, maar ín die tabel staat in elke cel een <ul> met één <li> erin. Dit had prima gekunt zonder die hele tabel en in één <ul> met 3 <li>'s.

Precies. En als je dan echt perse die tabel wilt voor je menutje (wat in dit geval geen van de voordelen heeft zoals BarôZZa omschrijft), dan in hemelsnaam die <ul><li> maar skippen.

[BarôZZa]

Cartman! schreef op dinsdag 02 februari 2010 @ 17:23:
[...]

Dat hangt gewoon af van hoe goed je kunt CSS-en natuurlijk, ik herken je probleem helemaal niet namelijk.

[...]

Das geen instelling imo. Het kan altijd beter, sneller en mooier

[...]

Je pikt de amateurs er vaak snel tussenuit als je ergens een site met tables voor layout ziet Opzich niet erg maar als alle sites volgens dezelfde semantiek gemaakt worden schieten we daar best wel iets mee op denk ik.

Vaak, maar lang niet altijd.

Het voordeel van tables is dat de cellen horizontaal en veticaal meeschalen met elkaar. Bij CSS + div mis je de onderlinge samenhang.
Maak je bijvoorbeeld een layout met aan de linkerkant een navigatie balk met een achtergrondkleurtje die moet meeschalen met de content van de rechterkant, dan moet je bij div's een containerdiv maken, die je een achtergrond waarbij je de navigatieachtergrond doorzichtig maakt en eroverheen plaatst. Eigenlijk een heel lelijke oplossing aangezien je de achtergrond moet veranderen wanneer je de breedte van de navigatie wilt aanpassen, en je dus niet de werkelijke elementen zelf stijlt. Bij een table geef je de kleur mee aan de linker cel.

[Cartman!]

En dat is erg omdat? Je wilt blijkbaar de volledige breedte voorzien van en background, waarom dat dan geen los overkoepelend element mag zijn mis ik een beetje. Maar als jij liever tables gebruikt, be my guest hoor, je moet het nog steeds zelf weten...

offtopic:
je site is stuk trouwens: Tabel './8464krabl/users' staat als gecrashed gemarkeerd en dient te worden gerepareerd

[BarôZZa]

Cartman! schreef op dinsdag 02 februari 2010 @ 18:07:
En dat is erg omdat? Je wilt blijkbaar de volledige breedte voorzien van en background, waarom dat dan geen los overkoepelend element mag zijn mis ik een beetje. Maar als jij liever tables gebruikt, be my guest hoor, je moet het nog steeds zelf weten...

Ik gebruik zelf divs. Met het voordeel van divs zou moeten zijn dat het flexibeler is en je de elementen zelf kan stijlen en aanpassen. Plus dat de breedte dus niet variabel kan zijn in dat geval. Wil je bijvoorbeeld de linkerbalk grijs hebben, dan zou je bij tables de background gewoon een kleurtje geven, terwijl je bij divs een plaatje moet maken waarbij je aan de linkerkant een gekleurd vlak hebt . Het werkt, maar het is verre van mooi.

Het heeft trouwens niks te maken met 'liever gebruiken', maar met een beperking waar je in sommige gevallen niet of nauwelijks omheen kan.

offtopic:
je site is stuk trouwens: Tabel './8464krabl/users' staat als gecrashed gemarkeerd en dient te worden gerepareerd

Dankje, meteen gefixt. Moet mezelf eens automagisch een mail laten sturen wanneer zoiets gebeurt . Altijd leuk, sites waar je amper op kijkt.

[RobIII]

BarôZZa schreef op dinsdag 02 februari 2010 @ 18:16:
[...]

Ik gebruik zelf divs. Met het voordeel van divs zou moeten zijn dat het flexibeler is en je de elementen zelf kan stijlen en aanpassen.

En dat kan met andere elementen niet? Een div is gewoon niet meer dan een betekenisloze container. Niet meer en niet minder.

BarôZZa schreef op dinsdag 02 februari 2010 @ 18:16:
Plus dat de breedte dus niet variabel kan zijn in dat geval. Wil je bijvoorbeeld de linkerbalk grijs hebben, dan zou je bij tables de background gewoon een kleurtje geven, terwijl je bij divs een plaatje moet maken waarbij je aan de linkerkant een gekleurd vlak hebt . Het werkt, maar het is verre van mooi.

Que Waarom zou je "bij divs" een plaatje moeten maken?

[ Voor 38% gewijzigd door RobIII op 02-02-2010 18:22 ]

[BarôZZa]

Geen open deuren intrappen, ik doelde uiteraard op de CSS manier van stijlen en het gebruik van div's ter vervanging van de klassieke table layouts.

RobIII schreef op dinsdag 02 februari 2010 @ 18:20:

Que Waarom zou je "bij divs" een plaatje moeten maken?

Hoe wil je anders dit krijgen?

hoi	fdsdfds fdsfdsfds fdsfdfds fdfsfds dfsfds dfdsfds fdfsfds dfsfds dfdsfds

[ Voor 57% gewijzigd door BarôZZa op 02-02-2010 18:26 ]

[MBV]

Main-achtergrond donkergrijs, en het rechtse vlak een grijze achtergrond Verder is er hier meer te vinden: plaats gewone links a.u.b. >> http://www.google.com/#hl=en&q=css+2-column+layout. En het voordeel van divs gebruiken voor dit soort dingen is heel simpel: dan kan je een aparte CSS maken voor mobieltjes die alles onder elkaar zet, en mobieltjes kunnen dat zelf ook al verzinnen als je vraagt om een compacte layout.

Over menu-items naast elkaar, over de hele breedte:

HTML:

<style type="text/css">
  ul.menu {
    width: 100%;
    text-align: justify;
  }
  ul.menu li {
    padding-right: 2px;
    border-right: 1px solid black;
  }
  ul.menu li.last {
    width: 1000px;
  }
</style>
...
<ul class="menu">
  <li>x</li>
  <li>x</li>
  <li>x</li>
  <li class="last"></li>
</ul>

Zo'n oplossing heb ik hier weleens gezien, de nettere variant weet ik niet meer.

Daarnaast vind ik CSS toch wel het ultieme voorbeeld van een taal die niet aan willekeurig welke eis voldoet die je aan een opmaaktaal kan stellen:
- duidelijk omschreven semantiek, zodat het makkelijk is om een correcte browser te maken
- duidelijk omschreven semantiek, zodat het eenvoudig is om een website te maken die doet wat jij wilt
- ondersteuning voor de meest basale layouts die je maar kan bedenken zonder kronkel-omwegen, zelfs in correcte browsers
- mogelijkheid om in een sleur-en-pleur-gui die layout te maken

Waarom kan QT wel een layout-taal verzinnen die werkt, GUI-support heeft, duidelijk is, en extreem simpel? Wanneer verzint iemand een CSS4 die niet compatible is maar wel aan die eisen voldoet?

[ Voor 3% gewijzigd door RobIII op 02-02-2010 21:23 ]

[BarôZZa]

Je hoeft van mij geen hele rant te houden over de voordelen van CSS of me naar die leuke 'Let me google that for you' linkjes te sturen, ik gebruik het dagelijks en dat was het hele punt niet. Het overdreven gedoe over een tabelletje hier en daar vind ik altijd sneu. Dat gejammer over amateurisch en dergelijke. De grootste websites maken er gebruik van(op Tweakers, Google en weet ik veel wat kom je ze tegen), dus wat er amateurisch aan is vraag ik me af. Als het in sommige gevallen kortere code oplevert en in alle browsers correct gerenderd wordt, dan lijkt me dat een stuk belangrijker. Net als van die mensen die uren lang blijven klooien om hun websites validated te krijgen. In veel gevallen aardige tijdsverspilling.

Het punt was dat het voordeel is bij tables dat de verticale en horizontale dingen automagisch meeschalen met elkaar. Probeer dat met div's met hoogtes/breedtes die kunnen variëren en je trekt je haren uit je kop.

Een voorbeeld is wanneer ik een formuliertje in elkaar wil zetten en de labels en inputs netjes onder elkaar wil hebben. Dan is een table toch echt het snelst en meest ideaal.

[Cartman!]

Maar semantisch niet correct dus. Misschien moet je gewoon meer ervaring (zeker als je van een layout en de huidige standaarden je de haren uit je kop wilt trekken...) krijgen want ik maak altijd m'n forms met fieldsets, legends, labels en inputs (duh) en dat vind ik zoveel makkelijker dan hoe ik dat deed met tables, daarnaast is het overzichtelijk in je code, makkelijk stijlbaar met CSS en je kunt makkelijk de usability verbeteren (for="" bijv).

[ Voor 11% gewijzigd door Cartman! op 02-02-2010 21:27 ]

[mcDavid]

MBV schreef op dinsdag 02 februari 2010 @ 19:55:
Main-achtergrond donkergrijs, en het rechtse vlak een grijze achtergrond

nope, als dan de linker kolom langer is dan de rechter gaat het mis.

overigens vind ik de automatische verbanden van tables in 99% van de gevallen alleen maar tegenwerken. Omdat het onvoorspelbaar is hoe ze reageren op wisselende content. Ik heb bijvoorbeeld internetfora gezien, waarbij je de gehele layout kon vernachelen door een lange subtitle in te stellen. Daardoor werd de linkerkolom ineens 90% breed waardoor er maar 10% breedte over was voor de posts.
En daar komt nog eens bij dat het juist deze verbanden zijn die het renderen van tables ongelooflijk traag maken (goed beschouwd moet bij iedere cel die toegevoegd wordt, de breedte van alle kolommen opnieuw berekend en ingesteld worden).

Er zijn eigenlijk maar 2 plaatsen waar ik voordeel zie in een table:
- in het content gedeelte, maar daar zijn ze wat mij betreft ook semantisch vaak prima op hun plaats
- als je een horizontaal uitvullend menu hebt, waar vanuit een CMS menu-items in toegevoegd moeten kunnen worden. Maar dan nog, kun je meestal wel met semantische elementen en "display: table/table-cel/enz" uit de voeten.

[BarôZZa]

Cartman! schreef op dinsdag 02 februari 2010 @ 21:27:
Maar semantisch niet correct dus. Misschien moet je gewoon meer ervaring (zeker als je van een layout en de huidige standaarden je de haren uit je kop wilt trekken...) krijgen want ik maak altijd m'n forms met fieldsets, legends, labels en inputs (duh) en dat vind ik zoveel makkelijker dan hoe ik dat deed met tables, daarnaast is het overzichtelijk in je code, makkelijk stijlbaar met CSS en je kunt makkelijk de usability verbeteren (for="" bijv).

Ervaring zat hier en die heeft me geleerd dat je de tijd die besteed aan alles 100% W3C maken van je site beter kan besteden aan het fixen van betere content, toevoegen van features en promotie. Behalve de paar Tweakers en standaarden fanaten is er werkelijk niemand die er iets om geeft. De gebruiker in de meeste gevallen niet en de zoekmachines al helemaal niet.

Als je bijvoorbeeld autocomplete="off" gebruikt bij een input, dan werkt dat prima in alle browsers, maar gaat de W3 validator over z'n nek. Ja, dan kan je ongetwijfeld een Javascript gaan schrijven die hetzelfde doet. Lekker nuttig.

Makkelijker dan tables hoeft van mij trouwens niet.

[MBV]

BarôZZa schreef op dinsdag 02 februari 2010 @ 21:21:
Je hoeft van mij geen hele rant te houden over de voordelen van CSS

Waar? Ik zeg dat CSS aan geen enkele eis voldoet die je aan een opmaaktaal kan stellen Zou je hem willen doorlezen? Er staat namelijk precies in waar jij over valt: de simpelste dingen vereisen een bijna onmogelijke hack om voor elkaar te krijgen. Zie ook faux columns etc.

Als het in sommige gevallen kortere code oplevert en in alle browsers correct gerenderd wordt

Probleem met tables voor layout is dat het dat niet doet: op browsers voor kleine schermen en blindreaders werkt dat voor geen meter. Tables voor kleine content-dingen en forms heeft niemand last van, maar je hele pagina in een table gooien is de pest voor compacte weergaves.

[Cartman!]

BarôZZa schreef op dinsdag 02 februari 2010 @ 21:52:
[...]

Ervaring zat hier en die heeft me geleerd dat je de tijd die besteed aan alles 100% W3C maken van je site beter kan besteden aan het fixen van betere content, toevoegen van features en promotie. Behalve de paar Tweakers en standaarden fanaten is er werkelijk niemand die er iets om geeft. De gebruiker in de meeste gevallen niet en de zoekmachines al helemaal niet.

Als je bijvoorbeeld autocomplete="off" gebruikt bij een input, dan werkt dat prima in alle browsers, maar gaat de W3 validator over z'n nek. Ja, dan kan je ongetwijfeld een Javascript gaan schrijven die hetzelfde doet. Lekker nuttig.

Makkelijker dan tables hoeft van mij trouwens niet.

Ik heb het over semantiek, niet over W3C validatie. In feite let ik daar ook niet heel erg op (tenzij een site moet voldoen aan de webrichtlijnen).

Overigens kwam ik nog iets moois tegen in een liveproject. We kregen van een externe partij documentatie voor hun API om bepaalde calls te doen (inloggen, registreren, activeren) en tot m'n grote verbazing was hun 'beveiliging' het gebruik van een hash als url. De registratieurl is gewoon 'http://site.be/blabla/7q9Fu8u_e5aq8886' waarbij de '7q9Fu8u_e5aq8886' dan staat voor de call die we willen doen... geen username, geen password of niks verder Direct gebeld naar ze en dit is hoe zij werken. Met wat problemen laatst nog een paar keer aan de lijn gehangen omdat wat gebruikers niet konden inloggen en toen zei ie "als ik t probeer werkt t wel". Waarop ik vroeg "heb je hun password dan?". Die staan toch in de database zei ie. Toen ik over veiligheid en salted hashes begon leek ie niet echt te begrijpen wat ik zei

[Matis]

Ik zie als tld een be-adres, heel vreemd vind ik het niet
/rant

Maar het is wel schokkend hoe sommige *programmeurs* denken dat een hash alles veilig maakt.

In plaats van een leesbaar wachtwoord een md5-encryptie gebruiken is voor sommige al voldoende

[MBV]

mwoah, zolang je geen rot13 gebruikt vind ik dat al snel goed. Ja, ik ken rainbow-tables etc, en ik weet hoe salted hashes werken (bij voorkeur gebruikersnaam + iets voor je applicatie in de hash opnemen). Maar gewoon MD5 gebruiken voor het wachtwoord is IMHO niet direct een WTF.

[Cartman!]

Matis schreef op maandag 08 februari 2010 @ 13:10:
Ik zie als tld een be-adres, heel vreemd vind ik het niet
/rant

zeggen wij hier ook altijd

Maar het is wel schokkend hoe sommige *programmeurs* denken dat een hash alles veilig maakt.

Ik denk dat ze niet weten dat ik denk aan een hash bij een linkje als dat. Volgens mij heeft iemand gewoon random wat toetsen aangeraakt om het te bedenken.

In plaats van een leesbaar wachtwoord een md5-encryptie gebruiken is voor sommige al voldoende

md5 is geen encryptie eh

[CodeCaster]

Als de "7q9Fu8u_e5aq8886" in bovengenoemd geval een éénmalig bruikbare hash is die een actie en een authenticatie koppelt is er niks aan de hand.

[Matis]

Cartman! schreef op maandag 08 februari 2010 @ 13:38:
md5 is geen encryptie eh

Nee, ik doelde op hashing idd

@hierboven, daar heb je gelijk in, maar ik denk uit Cartman!'s reactie op te kunnen maken dat dat ook het (gehashte) wachtwoord van de gebruiker is, zonder koppeltabel oid.

[ Voor 33% gewijzigd door Matis op 08-02-2010 13:47 ]

[Cartman!]

CodeCaster, die url is en blijft hetzelfde. Niet tijdgebonden, geen username/password, apikey of wat dan ook. Op die url kun je bijv. iemand registeren als je de juiste postdata hebt

Net ook even een scriptje gemaakt die files die met PHPLockit! 'ge-encrypt' zijn kan decoden... omdat t kan.

[321X]

Heb in code op m'n werk dit gevonden en moest aan deze topic denken:

PHP:

if(floor($lNumberOfPages) < $lNumberOfPages)
{
       $lNumberOfPages= floor($lNumberOfPages) + 1;
}

Of je doet:

PHP:

ceil($lNumberOfPages);

[Verwijderd]

321X schreef op dinsdag 09 februari 2010 @ 14:49:
Heb in code op m'n werk dit gevonden en moest aan deze topic denken:

PHP:

if(floor($lNumberOfPages) < $lNumberOfPages)
{
       $lNumberOfPages= floor($lNumberOfPages) + 1;
}

Of je doet:

PHP:

ceil($lNumberOfPages);

Laffing out laud!

[Nick_S]

321X schreef op dinsdag 09 februari 2010 @ 14:49:
Heb in code op m'n werk dit gevonden en moest aan deze topic denken:

PHP:

if(floor($lNumberOfPages) < $lNumberOfPages)
{
       $lNumberOfPages= floor($lNumberOfPages) + 1;
}

Of je doet:

PHP:

ceil($lNumberOfPages);

Volgens mij doet dat bovenste stukje heel wat meer als het onderste stukje.

@Onder, die doet inderdaad wel hetzelfde.

[ Voor 5% gewijzigd door Nick_S op 09-02-2010 15:18 ]

[kenneth]

Nick_S schreef op dinsdag 09 februari 2010 @ 15:15:
[...]

Volgens mij doet dat bovenste stukje heel wat meer als dan het onderste stukje.

PHP:

<?php
$lNumberOfPages = ceil($lNumberOfPages);
?>

[CodeCaster]

Oeps.

C#:

while (File.Exists(destFileName))
{
  destFileName = String.Format("{0}{1} (2)", fullDestPath, source, seq);
  seq++;
}

[Haan]

Dat is geen slecht programmeren, maar gewoon een bugje Ik moest nog behoorlijk diep denken voordat ik hem doorhad trouwens.

[Snake]

Resharper komt daar wel helpen hoor

[kenneth]

Ik neem aan dat destFileName vooraf nog geen waarde heeft?

[Snake]

kenneth schreef op dinsdag 23 februari 2010 @ 12:13:
Ik neem aan dat destFileName vooraf nog geen waarde heeft?

spoiler:

De (2) heeft () ipv {}

[AW_Bos]

Zojuist kwam ik een briljante PHP-code tegen op een forum.

Afgezien het feit dat de eregi-functie, al achterhaald is en preg_match aanbevolen wordt:

PHP:

<?php
 elseif(eregi("[jJ][aA][vV][aA][sS][cC][rR][iI][pP][tT]",$bericht) && $fout==false) {
      $fout=true;
      $foutmelding="Het bericht mag geen javascript bevatten.\n<br>"; 
?>

Nu kan je gewoon ook 'javascript' gebruiken in de reg-ex, met een /i -modifier.
Trouwens, eregi zelfs is al niet hoofdletter gevoelig en ereg wel. Dus die hele constructie is bij het gebruik van die functie niet nodig.

[ Voor 14% gewijzigd door AW_Bos op 23-02-2010 22:23 ]

[MBV]

wel de speciale functie gebruiken, maar niet snappen wat het doet? Enneh, wat is er met de gewone string-match-functies gebeurt? Ook flauw dat je het woord javascript niet mag gebruiken trouwens

[YopY]

Typisch geval klok / klepel. Ergens gehoord dat JS in posts fout is, maar niet verdiept in hoe je dat nu het beste tegen kunt houden.

[mcDavid]

Precies, simpelweg < en > vervangen door &lt; en &gt; zorgt er ook voor dat javascript of HTML-code niet uitgevoerd wordt. Veel effectiever, én gebruiksvriendelijker want dan kun je "<javascript>" wel gewoon als tekst invoeren.

En dik kans dat die replace er óók al in zat, dat doet vrijwel ieder forum namelijk wel

[ Voor 17% gewijzigd door mcDavid op 24-02-2010 09:15 ]

[.oisyn]

mcDavid schreef op woensdag 24 februari 2010 @ 09:14:
Precies, simpelweg < en > vervangen door &lt; en &gt; zorgt er ook voor dat javascript of HTML-code niet uitgevoerd wordt. Veel effectiever, én gebruiksvriendelijker want dan kun je "<javascript>" wel gewoon als tekst invoeren.

Da's wel leuk, maar als het forumsysteem ook nog dingen als url's omzit heb je wel een mooie security issue als je daar niet extra dingen voor doet. [url]javascript:alert(document.cookie)[/url] werkt hier op GoT gelukkig ook niet

[BarôZZa]

Sowieso alleen http:// whitelisten en er standaard voorzetten als dat er niet staat. De data: URI is ook behoorlijk gevaarlijk.

[Verwijderd]

MBV schreef op maandag 08 februari 2010 @ 13:26:
mwoah, zolang je geen rot13 gebruikt vind ik dat al snel goed. Ja, ik ken rainbow-tables etc, en ik weet hoe salted hashes werken (bij voorkeur gebruikersnaam + iets voor je applicatie in de hash opnemen). Maar gewoon MD5 gebruiken voor het wachtwoord is IMHO niet direct een WTF.

Pak voor de gein eens de md5 hash van een wachtwoord en vier die hash in in google.
Grote kans dat google een site vind waarop staat werk wachtwoord bij die hash hoort, haha

[MBV]

@tomtom: Zolang het geen woordenboek-woord is valt dat wel mee. Net met p4ssw0rt geprobeerd, en die staat er niet.Of heb je al je wachtwoorden in een online MD5-encryptor gegooid? Hint: hoe wordt die dienst betaald?

spoiler:

door de gegevens aan MD5-decryptor-sites te verkopen, d'oh

[.oisyn]

BarôZZa schreef op woensdag 24 februari 2010 @ 17:43:
Sowieso alleen http:// whitelisten en er standaard voorzetten als dat er niet staat. De data: URI is ook behoorlijk gevaarlijk.

En https, ftp en mailto mogen niet?

[Haan]

Ik zie die hele data: URI sowieso voor het eerst Maar die is relatief nieuw aan de browserondersteuning te zien.

[DanielG]

Haan schreef op donderdag 25 februari 2010 @ 15:25:
Ik zie die hele data: URI sowieso voor het eerst Maar die is relatief nieuw aan de browserondersteuning te zien.

Ja, is er pas 12 jaar
Although the IETF published the data URI specification in 1998, they never formally adopted it as a standard.

[BarôZZa]

.oisyn schreef op donderdag 25 februari 2010 @ 15:12:
[...]

En https, ftp en mailto mogen niet?

Die kan je eventueel ook whitelisten. Mailto vind ik sowieso niet zo fijn aangezien ik liever geen emailadressen gepost zie worden. Ftp links zie je nog zelden en https sites zijn meestal via een http link te bereiken. Je kan ze prima implementeren, maar ik ben er te lui voor en voor die enkele keer doen ze dan maar copy pasta.

[Haan]

Er zijn trouwens nogal wat verschillende URI schema's, best interessant eigenlijk: Wikipedia: URI scheme

[ Voor 9% gewijzigd door Haan op 25-02-2010 16:19 ]

[bobo1on1]

Dit vond ik toch wel een apart iets: http://www.libsdl.org/cgi...ew=revision&revision=5425

Bij SDL willen ze om de een of andere reden de input_absinfo struct van de linux kernel niet gebruiken, dus pakken ze een int[5] array en geven ze die door aan de variable arguments list van ioctl(), nouja moet kunnen.

Alleen laatst is er een extra int toegevoegd aan die struct, en zodoende is bij SDL de grootte van de array ook verhoogd naar 6 elementen (alleen zijn er nog redelijk wat mensen met oude sdl libs die nu segfaults krijgen).
Dan vraag ik mij af, waarom maken ze bij SDL die buffer niet gewoon een stuk groter (voor mijn part een kilobyte) om dit soort problemen in de toekomst te voorkomen.

[user109731]

Niet zozeer een slecht programmeervoorbeeld, maar wel een valkuil: http://www.robweir.com/bl...andom-browser-ballot.html

[Matis]

JanDM schreef op dinsdag 02 maart 2010 @ 21:25:
Niet zozeer een slecht programmeervoorbeeld, maar wel een valkuil: http://www.robweir.com/bl...andom-browser-ballot.html

Jeetje, naast het feit dat de browsers verspringen op het moment dat de site geladen is, ziet het er nog eens slecht uit ook

Mooi semantisch opgemaakt ook

[418O2]

die pagina is een big fuck you naar de EU natuurlijk.

Kulregel natuurlijk. Ik denk dat de meeste mensen die nu nog IE gebruiken dat OF bewust doen OF helemaal geen andere browser willen en alleen maar schrikken van dat scherm. Maar dat is een andere discussie.

[Herko_ter_Horst]

418O2 schreef op dinsdag 02 maart 2010 @ 21:36:
die pagina is een big fuck you naar de EU natuurlijk.

Kulregel natuurlijk. Ik denk dat de meeste mensen die nu nog IE gebruiken dat OF bewust doen OF helemaal geen andere browser willen en alleen maar schrikken van dat scherm. Maar dat is een andere discussie.

Je denkt als een tweaker. De "gemiddelde" gebruiker zit op IE omdat dat er al op stond en/of ze aan IE gewend zijn. Niet vanwege een bewust keuze.

Als ik mijn moeder niet had uitgelegd dat ze op een blauw icoontje met een rood/oranje randje moet klikken om een browser te starten (Firefox dus, die ik er voor haar heb opgezet), dan kwam ze uberhaupt niet aan browsen toe, laat staan dat ze weloverwogen een keus maakt om bij een browser te blijven of een andere te kiezen.

Oftewel: zonder mijn hulp zou ze gewoon IE gebruiken, omdat ze dat in een "Windows voor Dummies" boekje had gelezen, of omdat de buurvrouw het gebruikt. Niet omdat ze dat persé zou willen, maar omdat ze niet beter weet. Dát is waar de de EU nu verandering in heeft gebracht: het brengt het bestaan van andere browsers onder de aandacht van de "domme" gebruikers. (Of die daar een goede keuze in kunnen maken is een heel ander verhaal).

[roy-t]

Herko_ter_Horst schreef op dinsdag 02 maart 2010 @ 22:05:
[...]

Je denkt als een tweaker. De "gemiddelde" gebruiker zit op IE omdat dat er al op stond en/of ze aan IE gewend zijn. Niet vanwege een bewust keuze.

Als ik mijn moeder niet had uitgelegd dat ze op een blauw icoontje met een rood/oranje randje moet klikken om een browser te starten (Firefox dus, die ik er voor haar heb opgezet), dan kwam ze uberhaupt niet aan browsen toe, laat staan dat ze weloverwogen een keus maakt om bij een browser te blijven of een andere te kiezen.

Oftewel: zonder mijn hulp zou ze gewoon IE gebruiken, omdat ze dat in een "Windows voor Dummies" boekje had gelezen, of omdat de buurvrouw het gebruikt. Niet omdat ze dat persé zou willen, maar omdat ze niet beter weet. Dát is waar de de EU nu verandering in heeft gebracht: het brengt het bestaan van andere browsers onder de aandacht van de "domme" gebruikers. (Of die daar een goede keuze in kunnen maken is een heel ander verhaal).

Nouja ik leg het ook vaak uit aan mensen, maar ik ben daar nu erg terug houdend in. IE wordt gesupport door alle banken (waar Opera en Firefox heel af en toe het niet doen, soms wordne ze gewoon tegen gehouden door een stom scriptje). Ook andere belangrijke website slikken gewoon niet zomaar elke browser, en als IE dat wel doet, en users ergeren zich niet aan IE, waarom dan geen IE dacht ik bij mezelf. Dus ik zit lekker in Opera te browsen, maar ik heb alle niet nerds om me heen aangeraden om gewoon IE te gaan gebruiken als ze zich er niet aan ergerden (en raad eens, er was niemand die dat deed).

Toen kwam natuurlijk de "buurjongen/neef/oom" langs en heeft gewoon firefox geinstalleerd, waarna ik een week later kon gaan uitleggen hoe dat programma werkt...

Ohwell.

(erg offtopic trouwens).

[Soultaker]

JanDM schreef op dinsdag 02 maart 2010 @ 21:25:
Niet zozeer een slecht programmeervoorbeeld, maar wel een valkuil: http://www.robweir.com/bl...andom-browser-ballot.html

Pfff, maandenlang gesteggel over zo'n simpele site en dan zijn ze nog in staat de boel te verprutsen bij Microsoft. Ik ben niet echt van het MS-bashen, maar dit is toch wel heel sneu.

[SpaceK33z]

Ik heb mijn moeder gewoon verteld dat Internet Explorer "slecht" is en Firefox "goed", voor de rest heeft ze er nooit over geklaagd .
Wat mij opviel is dat de ABN bank Firefox niet ondersteund. Mijn oma belde me laatst (ik heb ook bij haar Firefox geïnstalleerd) met de vraag waarom online bankieren het niet deed. Toen merkte ik dat hetzelfde wel lukte met IE, maar niet met FF. Dat slaat toch gewoon nergens op . Pure discriminatie .

[MBV]

ABN checkt de user-agent ID. Met een iceweasel-browser krijg je dus niet het centrale, ajax-gebaseerde scherm, maar werken alleen de menu's

Verder nog nooit problemen gehad; als ABN het niet doet in mijn browser ga ik gewoon de klantenservice bellen dat internetbankieren stuk is.
* MBV knikkert direct dat rare blauwe icoontje uit de startbalk. Al een jaar lang niet aangeklikt: ik dacht dat hij al weg was, en start IE (als ik hem nodig heb) dus op via winkey+r

[ Voor 54% gewijzigd door MBV op 02-03-2010 22:51 ]

[MrBucket]

Soultaker schreef op dinsdag 02 maart 2010 @ 22:38:
[...]

Pfff, maandenlang gesteggel over zo'n simpele site en dan zijn ze nog in staat de boel te verprutsen bij Microsoft. Ik ben niet echt van het MS-bashen, maar dit is toch wel heel sneu.

Serieus, niemand bij MS maakt zich zorgen (of beter: zou zich zorgen moeten maken) over de uiteindelijke volgorde waarin de verschillende browsers getoond worden. Iedereen behalve de grootste digibeet heeft wel eens van Internet Explorer gehoord, en hoe groter de digibeet, hoe groter de kans dat iemand anders de installatie verzorgt die wel een expliciete voorkeur - al dan niet terecht - heeft voor een bepaalde browser.

Met andere woorden: het percentage mensen dat consequent "de meest linker browser" kiest omdat ze geen voorkeur hebben is te verwaarlozen.

Dus als het goed is zal 't Microsoft echt jeuken of de distributie uniform is of niet.

[MatHack]

Kees Kluskens schreef op dinsdag 02 maart 2010 @ 22:44:
Ik heb mijn moeder gewoon verteld dat Internet Explorer "slecht" is en Firefox "goed", voor de rest heeft ze er nooit over geklaagd .
Wat mij opviel is dat de ABN bank Firefox niet ondersteund. Mijn oma belde me laatst (ik heb ook bij haar Firefox geïnstalleerd) met de vraag waarom online bankieren het niet deed. Toen merkte ik dat hetzelfde wel lukte met IE, maar niet met FF. Dat slaat toch gewoon nergens op . Pure discriminatie .

Dat is wel erg raar, ik gebruik al jaren Firefox i.c.m. ABN-AMRO InternetBankieren, en ik heb nog nooit problemen hiermee gemerkt.

[MBV]

ik zit net te denken: kees, heb je haar ook opdracht gegeven om ctrl+F5 te doen? Als er een rot bestandje in je cache zit zal IE het wel doen en FF niet

En nog een puntje: als FF het niet doet, is er dan niet misschien iets mis met je computer? Trojans, man-in-the-middle en dat soort ongein?

[ Voor 31% gewijzigd door MBV op 02-03-2010 23:15 ]