https://bugzilla.wikimedia.org/show_bug.cgi?id=40329
--- Comment #16 from Daniel Friesen <mediawiki-b...@nadir-seen-fire.com> 2012-09-21 16:18:14 UTC --- (In reply to comment #15) > I hardly doubt align and valign are part of wikitext. Then you would have to > say that id, class, style, title and other common HTML attributes are part of > wikitext as well. No, they are not. In fact you can pass various attributes to > many elements (either in wikitext or html), even inexisting, and they are > simply passed out and Tidy deals with them. > > The only attribute handled is style, which does sanitization of external > resources. They are all part of WikiText. Every attribute you are permitted to use is part of WikiText. Each one is explicitly allowed. We just define most of them to work the same way as HTML defines them. Tidy doesn't do anything here. It's not responsible for ANY of the filtering. Attributes permitted inside WikiText are handled by the Parser.php related code inside Sanitizer.php. And Parser.php/Preprocessor*.php parses all the HTML we support. If our parser doesn't parse the markup, then it's not outputted as HTML. So ALL of it is handled by our WikiText parser. We output br in the same way whether you write <br> or <br />. Whether you write class=foo, class="foo", or class='foo' we output it as class="foo". And besides the explicit whitelisting of only the attributes we permit style isn't the only attribute that we handle specially. The id attribute is modified, depending on wiki settings we may replace some characters with dots or in other cases other characters with underscores, and we always decode entities you input into an id. If html5 output is enabled as a feature. We handle data- attributes specially, and strip them when disabled. If microdata or rdfa are enabled as features we special case permit them. We also reject inputs that we don't like (ie: they look like an evil uri). For microdata we have some extra handling. If you don't use itemscope we unset itemtype, itemid, and itemref. And while we don't have anything that explicitly permits href or src yet, we already have the related code saying that only urls matching our protocol whitelist are allowed. > I totally agree with comment #13 - handling of code is business of the > browser, > not of the MediaWiki. (In fact it's primarily business of writers of that code > anyway...) > > Attempting to "translate" attributes to different output will also cause > messing of the design, because you never can say how browsers were handling it > (and different browsers handle stuff differently). If what you're saying is true. Then we have even more reason to do the translation. Our job is to provide output that always works the same. Our job isn't to replicate browser quirks. If browsers behave differently with the same output then we should be outputting something that behaves the same in all browsers even if it's different than how html, etc... says the user input should behave. > I've seen a lot of various > ridiculous constructions which caused "proper" displaying and this > "translation" attempt would break it immediately. Those constructions had to > be > replaced manualy by human, who knows (and can see from context) the > dependencies. Either way, in the end whether we translate or drop support humans manually have to replace this stuff. And manually replacing only the things that are actually broken is simpler than replacing everything. Because the fact is that while there are some cases where the translation doesn't behave the same. For the majority of cases the translation actually works for what the user wanted it to do. > Summary: Do not have MediaWiki to deal with it, have browsers to deal with it > for the time being. And after some period (a year after announcement seems > reasonable) just drop the support of obsolete invalid constructions. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
