Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Volgens mij werkt code:php namelijk ook, vandaar dat ie hem niet parsed?
Hmmm.. toch nie
[ Voor 19% gewijzigd door RedHat op 04-12-2009 12:02 ]
Done
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Intentionally left blank
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ook al is '[bla :P bla]' niet een geldige tag, het wordt wel gezien als een tag in de tokenizer met tagname 'bla' en 2 (boolean) attributen :P en bla. Bij het parsen wordt deze tag echter niet herkent als een geldige tag, en dus weggeschreven als een 'denied' tag - het zou immers in de toekomst of bij een wijziging van rechten wel een valide tag kunnen worden.
Vergelijk het met HTML: <foo tralala blaat> wordt door je browser ook niet als gewone content gezien.
Het enige dat ik zou kunnen doen is de tokenizer stricter maken mbt het parsen van attributen, en op basis van de :P het niet meer als een tag kwalificeren.
Intentionally left blank
Waarom gaat het op het forum dan wel goed zonder het te escapen? Daar zouden dan toch dezelfde argumenten voor opgaan?
Sowieso lijkt het mij niet handig om het als een tag te zien waar eventueel later nog functionaliteit voor komt, aangezien je dan posts anders gaat parsen dan dat ze ooit bedoeld waren.
[ Voor 60% gewijzigd door Hooglander1 op 04-12-2009 12:42 ]
Lid van de Tweakers Kenwood TTM-312 club.
Andere parser met een iets andere benadering...Hooglander1 schreef op vrijdag 04 december 2009 @ 12:41:
[blabla]
Waarom gaat het op het forum dan wel goed zonder het te escapen? Daar zouden dan toch dezelfde argumenten voor opgaan?
Daarom wordt hij ook aangemerkt als een 'denied' tag, zodat hij bij herparsing ook nooit als tag gezien zal worden.Sowieso lijkt het mij niet handig om het als een tag te zien waar eventueel later nog functionaliteit voor komt, aangezien je dan posts anders gaat parsen dan dat ze ooit bedoeld waren.
Intentionally left blank
Daarnaast lijkt me consistentie tussen FP en forum gewenst.
Overigens:
Dit is natuurlijk een kul-argument. Het idee van HTML is idd dat het niet als content wordt gezien, maar dat staat haaks op hoe het er op de FP en het forum mee om wordt gegaan. Want daar zijn blokhaken gewoon content, tenzij het een geldige tag is. Het gedrag in HTML is dan ook compleet niet van toepassingcrisp schreef op vrijdag 04 december 2009 @ 12:39:
Vergelijk het met HTML: <foo tralala blaat> wordt door je browser ook niet als gewone content gezien.
[ Voor 103% gewijzigd door .oisyn op 04-12-2009 13:03 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Maar hoe weet je dat vantevoren? Ik zou morgen best wel een 'bla'-tag aan kunnen maken....oisyn schreef op vrijdag 04 december 2009 @ 12:59:
Als ie toch nooit als tag gezien gaat worden kun je net zo goed ook de smileys erin parsen.
En dat deed ik dus ookOok kun je arguen dat een : geen geldig teken is voor een attribuut.
True, en dat is al jaren een streven, maar zolang de FP parser en de React parser nog niet volledig compatible zijn is het lastig er een te laten vallen en dezelfde parser op beide fronten te gebruiken...Daarnaast lijkt me consistentie tussen FP en forum gewenst.
Het is geen kul-argument; het tokenizen en parsen van RML/UBB vertoont juist grote gelijkenissen met HTML. De tokenizer van de FP parser is ook een aangepaste versie van een HTML tokenizer die ik ooit geschreven heb. Dat je dan hetzelfde gedrag krijgt is dan ook geen toevalOverigens:
[...]
Dit is natuurlijk een kul-argument. Het idee van HTML is idd dat het niet als content wordt gezien, maar dat staat haaks op hoe het er op de FP en het forum mee om wordt gegaan. Want daar zijn blokhaken gewoon content, tenzij het een geldige tag is. Het gedrag in HTML is dan ook compleet niet van toepassing
Intentionally left blank
Je zegt toch zelf dat hij op het moment van posten niet als tag gezien wordt en dat dan ook nooit zal wordencrisp schreef op vrijdag 04 december 2009 @ 14:35:
[...]
Maar hoe weet je dat vantevoren? Ik zou morgen best wel een 'bla'-tag aan kunnen maken...
Sorry, die regel had ik even gemistEn dat deed ik dus ook
Implementatie-geneuzel, feitelijk doet dat er niet toe. In HTML is gespecificeerd dat niet bestaande tags niet gerenderd moeten worden. In RML is het val oudsher altijd al zo geweest dat niet bestaande tags gewoon onderdeel uitmaken van de content. Dat is een essentieel verschil. Uit dat verschil blijkt dat je een andere implementatie moet gebruiken, en je niet moet kijken naar hoe het met HTML is geïmplementereerd.Het is geen kul-argument; het tokenizen en parsen van RML/UBB vertoont juist grote gelijkenissen
met HTML.
En dus is dat gedrag verkeerd. Je houdt er nu een beetje Zend-argumentatie op na eerlijk gezegd. Het is geen bug omdat de implementatie zo in elkaar zit. Ja duh, dat is altijd met bugsDe tokenizer van de FP parser is ook een aangepaste versie van een HTML tokenizer die ik ooit geschreven heb. Dat je dan hetzelfde gedrag krijgt is dan ook geen toeval
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Daar kwam ik een post later dus (deels) op terug.oisyn schreef op vrijdag 04 december 2009 @ 15:49:
[...]
Je zegt toch zelf dat hij op het moment van posten niet als tag gezien wordt en dat dan ook nooit zal worden
Feit is dat RML/UBB een niet gespecificeerde taal is. Gezien de verwantschap met HTML is het niet gek daarnaar te kijken. Dat er ook verschillen zijn ontken ik niet, maar dat iets 'van oudsher' zo zou moeten zijn vind ik ook geen sterk argument eerlijk gezegd; je beroept je dan op een specifieke implementatie van een niet gespecificeerde taal, een soort 'quirksmode' eigenlijk[...]
Implementatie-geneuzel, feitelijk doet dat er niet toe. In HTML is gespecificeerd dat niet bestaande tags niet gerenderd moeten worden. In RML is het val oudsher altijd al zo geweest dat niet bestaande tags gewoon onderdeel uitmaken van de content. Dat is een essentieel verschil. Uit dat verschil blijkt dat je een andere implementatie moet gebruiken, en je niet moet kijken naar hoe het met HTML is geïmplementereerd.
Ik ben het met je eens dat dit gedrag voor RML niet het juiste is, zie mijn opmerking over de implementatie dus maar als achtergrondinformatie waarom het nu zo is. Het is echter wel een edge-case en dus geen high-prio issue.[...]
En dus is dat gedrag verkeerd. Je houdt er nu een beetje Zend-argumentatie op na eerlijk gezegd. Het is geen bug omdat de implementatie zo in elkaar zit. Ja duh, dat is altijd met bugs
Geen enkele parser is perfect, ook de React parser heeft zo z'n bugs. Het liefst zou ik van onze twee parsers gewoon 1 maken waarbij ik het beste van beide parsers combineer, maar dat is niet iets wat je even in een uurtje doet...
Intentionally left blank