You need to be careful of these little annoyances. That worked so well for HTML after all that no browser in existence can or does display the test pages from the official specs properly.
Lets not follow a defined standard, lets just let the client *guess* what you really intended to have happen and hope the result isn't too screwed up in which ever browser you use. The result is that *some* muds incorrectly impliment conversion, and in clients that treat bad or possible bad tags as errors, not plain text, those muds don't display right. Nick Gammon, the creator of Mushclient and Zugg, who makes zMud have had a long conversation about this issue, which left off with Zugg saying, "Yeah, its probably a good idea to make sure everyone knows exactly what the standard behaviour *should* be in such cases.", then not doing anything at all to make the specifications clear about it, or changing zMud. So you have two choices, a) delete the presumed tag and generate an error response through what ever system you have set up for that, or b) display it anyway, as though it was <blah>, which the specifications clearly indicate is actually wrong. How do you tell if the stuff between was *supposed* to be a tag, but something it wrong with it, or its just text, especially if the mud uses its own extensions to the protocol, which should logically be ignored, or its an element that is being sent in the tag? Simple, you can't. This causes a major pain if you decide to impliment error checking or capture of MXP tags. At least with dealing with the translation of to < and >. and b) if you follow specs, the muds might not, because sadly, zMud *doesn't* follow specs. The client I use didn't bother supporting *either*, since both where a pain to do. Not the least of which being a) its hard to make a window that supports HTML type elements, like pictures, but still supports text positioning.
0 kommentar(er)
