Langdurig onopgelost ongedierte

Door Bubbles op maandag 16 april 2012 10:17 - Reacties (10)
CategorieŽn: Programming, Rants, Views: 3.962

Je zou verwachten dat producten van Microsoft goed aansluiten met andere producten van Microsoft en dat die aansluiting naar producten van andere fabrikanten soms wat minder zal zijn. Zelfde toko: korte lijntjes, makkelijk overleg, code is beschikbaar. Dat hoeft niet dus. Nog eentje in de categorie: interessante programmeerproblemen die je tegenkomt op de werkvloer. Ditmaal gaat het om de ASP:Login control.

Er waren eens een <input type="text"> en een <input type="password"> in de HTML wereld. Aangezien de combinatie van die twee vaak gebruikt wordt om in te loggen op een website, leek het Microsoft een goed plan daar 1 Control voor te maken in Visual Studio: <asp:login>. Goeie gedachte. Lekker makkelijk. Zit er ook gelijk een submit-knop bij en een checkbox om credentials te onthouden. Ben je in 1 keer klaar. Ideaal.

Helaas gaat er iets mis met het renderen van die input controls in Internet Explorer. Ik hoor je al zeggen: "gebruik dan ook een echte browser". Dat doe ik al, maar helaas doet niet iedereen dat en ben je genoodzaakt als webdeveloper om je code in andere browsers te testen, om zo te zien of datgene wat je gemaakt hebt, er overal hetzelfde uitziet en werkt. Wat gaat er dan mis in IE?

Heel simpel gezegd: de password textbox heeft een andere breedte dan de plain-text textbox. Maar alleen in Internet Explorer. Een workaround daarvan is relatief eenvoudig en werd door iemand van Microsoft hier aangedragen. Als je echter beter kijkt, zie je dat die vraag in 2005 werd gesteld. Ten tijde van IE6 en VS2005. We zijn inmiddels 2 versies van Visual Studio en 3 versies van Internet Explorer verder, waarbij IE9 zich velen malen beter aan de algemene standaarden houdt dan IE6 dat deed (nouja, 1000 x 0 is nog steeds nul, dus beter gezegd: IE9 houdt zich wel (grotendeels) aan de standaarden). Maar het probleem doet zich nog steeds voor. Nu nog. En dat is, zacht gezegd, best jammer. En hoewel het dan niet direct een fout is van Visual Studio an sich, zou je toch wel verwachten dat het VS-ontwikkelteam op z'n minst het IE-ontwikkelteam heeft ingelicht en dat ze zo'n ogenschijnlijke simpele bug in 7 jaar tijd wel een keertje zouden hebben kunnen oplossen...

-bubbles out-

Volgende: FunnyJunk vs. TheOatmeal - het Streisand Effect op volle toeren 06-'12 FunnyJunk vs. TheOatmeal - het Streisand Effect op volle toeren
Volgende: Prestatiewinst much?! 04-'12 Prestatiewinst much?!

Reacties


Door Tweakers user Gtoniser, maandag 16 april 2012 10:43

Je kunt ook gewoon css gebruiken ipv afhankelijk te zijn wat andere browsers toevallig met jouw code doen, het gaat hier immers om layout en niet om functionaliteit.

Door Tweakers user Bubbles, maandag 16 april 2012 11:16

Gtoniser: je mist het punt. Ja, CSS kan je gebruiken om dit te verhelpen, maar het is jammer dat zoiets nodig is voor iets simpels wat door iemand van Microsoft zelf wordt bestempeld als IE bug. Het is symptoombestrijding, geen probleemoplossing.

Door Tweakers user RobIII, maandag 16 april 2012 13:04

Bubbles schreef op maandag 16 april 2012 @ 11:16:
Het is symptoombestrijding, geen probleemoplossing.
Misschien, maar als ik moet kiezen tussen er een flinke rant over schrijven of een

Cascading Stylesheet:
1
#passwdbox { width: 150px; }


dan weet ik 't wel. Schouders ophalen, zuchten, doormodderen. En 't desnoods (nog eens) bij MS melden.

Door Tweakers user Bubbles, maandag 16 april 2012 14:07

Jamaar, dan heb ik niks te bloggen. ;)

[Reactie gewijzigd op maandag 16 april 2012 14:08]


Door Tweakers user Joolee, maandag 16 april 2012 14:47

Ik span sowieso niet hoe je code kunt schrijven zonder dat je enige invloed hebt op het eindresultaat. Het is dan misschien wel makkelijk om <asp:login> te schrijven maar ik schrijf veel liever 5 regels extra zodat ik ook precies weer wŠt er uiteindelijk naar de browser gestuurd wordt en ik niet hoef te hopen dat de Frontpage meuk die mijn MS Framework uitspuugt gesnapt wordt door alle browsers en er geen vreemde dingen gebeuren.

Wat is nou uiteindelijk de html die verstuurd wordt waardoor IE het niet meer snapt?

[Reactie gewijzigd op maandag 16 april 2012 14:48]


Door Tweakers user Bubbles, maandag 16 april 2012 16:16

Joolee: In de praktijk is <asp:login> niets anders dan

HTML:
1
<input type="text "/><br /><input type="password" />

met nog wat tekst eromheen. Het probleem zit in het feit dat IE type=password anders rendered dan type=text

Dus ook als je het los schrijft, gaat het in IE fout. Je moet expliciet een grootte opgeven om ervoor te zorgen dat beide inputvelden even breed worden getekend.

Door Tweakers user Apache, maandag 16 april 2012 20:37

Joolee schreef op maandag 16 april 2012 @ 14:47:
Ik span sowieso niet hoe je code kunt schrijven zonder dat je enige invloed hebt op het eindresultaat. Het is dan misschien wel makkelijk om <asp:login> te schrijven maar ik schrijf veel liever 5 regels extra zodat ik ook precies weer wŠt er uiteindelijk naar de browser gestuurd wordt en ik niet hoef te hopen dat de Frontpage meuk die mijn MS Framework uitspuugt gesnapt wordt door alle browsers en er geen vreemde dingen gebeuren.

Wat is nou uiteindelijk de html die verstuurd wordt waardoor IE het niet meer snapt?
Zal je werkgever appreciŽren dat je het wiel steeds opnieuw wil uitvinden :)

Door Tweakers user Gomez12, maandag 16 april 2012 23:04

Apache schreef op maandag 16 april 2012 @ 20:37:
[...]
Zal je werkgever appreciŽren dat je het wiel steeds opnieuw wil uitvinden :)
Ach, mijn werkgever apprecieert het wel als ik het wiel in 1x goed uitvind ipv dat ik met een to-fix oplossing blijf werken.

Dit zijn echt van die kleine dingen die zijn : Doe het goed of doe het niet.
De 3 toetsaanslagen die je bespaart ben je dubbel en dwars kwijt de eerste keer dat je het vergeet en merkt hoe ruk IE is en dat je daar echt alles moet uitleggen :)

[Reactie gewijzigd op maandag 16 april 2012 23:05]


Door Tweakers user edeboeck, woensdag 18 april 2012 11:43

Gomez12 schreef op maandag 16 april 2012 @ 23:04:
[...]

Ach, mijn werkgever apprecieert het wel als ik het wiel in 1x goed uitvind ipv dat ik met een to-fix oplossing blijf werken.

Dit zijn echt van die kleine dingen die zijn : Doe het goed of doe het niet.
De 3 toetsaanslagen die je bespaart ben je dubbel en dwars kwijt de eerste keer dat je het vergeet en merkt hoe ruk IE is en dat je daar echt alles moet uitleggen :)
Bubbles schreef op maandag 16 april 2012 @ 16:16:
Joolee: In de praktijk is <asp:login> niets anders dan

HTML:
1
<input type="text "/><br /><input type="password" />

met nog wat tekst eromheen. Het probleem zit in het feit dat IE type=password anders rendered dan type=text

Dus ook als je het los schrijft, gaat het in IE fout. Je moet expliciet een grootte opgeven om ervoor te zorgen dat beide inputvelden even breed worden getekend.
Bubbles, als ik je punt goed begrijp, gaat het dus eerder om het feit dat IE een input text en password anders rendert... eerder dan dat het probleem bij de asp:Login-control ligt. Tenzij die control ook onmiddellijk CSS zou creŽren... maar of dat dan zo wenselijk is...
edit:
Bubbles ff verward met Jolee

[Reactie gewijzigd op woensdag 18 april 2012 11:44]


Door Tweakers user Ruudjah, donderdag 19 april 2012 06:27

Goed verhaal en goed geschreven, Bubbles.
Ik span sowieso niet hoe je code kunt schrijven zonder dat je enige invloed hebt op het eindresultaat. Het is dan misschien wel makkelijk om <asp:login> te schrijven maar ik schrijf veel liever 5 regels extra zodat ik ook precies weer wŠt er uiteindelijk naar de browser gestuurd wordt en ik niet hoef te hopen dat de Frontpage meuk die mijn MS Framework uitspuugt gesnapt wordt door alle browsers en er geen vreemde dingen gebeuren.
Mja. Het idee is dat je betere kwaliteit code kan schrijven. Je wilde toch een <login>? Gebruik dan een <login>, als je wel een <customComponent> met een <password> en een <input> gebruikt, dan is je code simpelweg een stuk minder van kwaliteit. Je intentie is verdoezeld aangezien je nu opeens de vertaling moet maken van <input> en <password> en <customComponent> naar een mentaal model van een <login>.

Althans, dat is de theorie. In de praktijk werkt dat ook prima, mits je een library/framework hebt die regelmatig en iteratief updates heeft. Maar omdat Microsoft nog in het PC-era zit waarbij grote evoluties in ťťn keer worden uitgerold, werkt dat niet bij Microsoft spul. Het "correcte" werkproces zou zijn dat je zelf een fix bedenkt, die submit, en een maintainer de boel oppikt, beoordeelt, en in master verwerkt. Zodat je bij de volgende releasebuild een <login> kan gebruiken.

Ik snap het wel, als ontwikkelaar is je eigen ego ook belangrijk, zelf dingen maken, er trots op zijn, en dan showoffen... Doe je dat niet, dan blijft er weinig eer meer over. En dus neem je zelf het heft in hand om een <login> te maken. Feit is wel dat als je een dergelijk gedachtepatroon hebt, je heel veel opeens zelf in elkaar moet gaan klussen. En dan, is mijn eigen ervaring, blijf je hangen in het lowlevel gebied waarbij je vooral bezig bent om dingen opnieuw uit te vinden. De keerzijde is dat je bezig bent om juist composities van <login>s te bouwen, zodat je vertoefd in het gebied van "hoger nivo" ontwikkeling.

Dat Microsoft hun code gesloten houdt, begrijp ik, en dat is in de praktijk ook best prima om mee te werken. Natuurlijk, hier en daar kan je je groen en geel ergeren aan hoe zaken zijn opgelost, maar dat geld voor de meeste, zo niet alle, frameworks/libraries. Wat ik veel irritanter vind is dat ze, ook in 2012, niet overgaan op het iteratieve ontwikkelmodel. Dus niet elke drie jaar een CTP1/2/3 dumpen, een release op de markt gooien, en dan de 5 jaar die volgen gebruiken om 3 service packs uit te brengen. Maar gewoon iedere week een releasebuild doen. Met een publieke bugtracker (bugs van MS' software inzien kost geld, wist je dat?). Dan heb je een werkprocess op de plaats die een <login> rendering bug de volgende week plet.

Reageren is niet meer mogelijk