Last modified: 2011-03-13 18:05:36 UTC
Please add "text/x-component" as another allowed MIME-type in allowedCTypes in RawPage.php. Althoug IE does not natively support a bunch of W3C standards, such as :hover pseudoclass, PNG transparency or position: fixed, there is still way, how to allow it to behave correctly according to standards. Using behavior attribute (resp. _behavior to keep it valid) in stylesheets. This attribute has URL as a value which points to file (usually with .htc extension) of text/x-component MIME-type. Serving this file with another MIME-type causes no functionality of that file. Therefore if the behavioral file would be MediaWiki:Hover.htc, then in eg. Monobook.css it would have to be linged this way: someSelector { behavior: ("/path/index.php?title=MediaWiki:Hover.htc&action=raw&ctype=text/x-component"); } another example - allowing transparency for images: img { behavior: ("/path/index.php?title=MediaWiki:Pngbehavior.htc&action=raw&ctype=text/x-component"); } and so on... examples of solutions to be found on: http://users.hszk.bme.hu/~hj130/css/list_menu/hover/ (hover) http://webfx.eae.net/dhtml/pngbehavior/pngbehavior.html (PNG transparency) http://arcok.ujevangelizacio.hu/bubu/examples/ie-fixed.html (position: fixed) and there are other solutions on IE known bugs. Thanks for support.
What can this do that existing JavaScript can't?
In general, document formatting _should not_ be solved via javascript: All these features are regular CSS attributes used for formatting of documents (png transparency discounted). Behavior attribute is just workaround for IE, because it does not support some basic CSS constructions. IE workaround div { behavior: url("hover.htc"); } div.hover { color: red; } is equal to CSS standard div:hover { color: red; } Using of JS for formatting while CSS can be used is evil and against all recommendations. Javascript is eg. for manipulating of DOM and for events, but not for formatting. Possible objection that behavior is in fact script, can't be counted, because it's script only for IE, other browsers ignore it and use regular CSS, which is the right way. Also: - using of JS would cause having document formatting data in two different places - half in CSS file, half in JS, which might be hard to keep clear - one line in CSS against a bunch of lines of JS - from the client side, behavior is less resource demanding All these techniques have been proved many times and are widely used on the Internet as the easiest workaround.
But behavior *is* JavaScript (or VBScript). So what's the difference?
As been said above: Possible objection that behavior is in fact script, can't be counted, because **it's script only for IE**, other browsers ignore it and use regular CSS, which is the right way. In other words - nonIE browsers don't use it and use proper CSS = they don't need the potential JS file. Why ask CSS-compliant browsers to use JS when they don't have to? Or actually they should not to. Again - all formatting should be done via CSS only. The difference is that entire appearance of page is set only in CSS file(s), not in CSS and JS files. Also mind the slight detail: the *value* of behavior attribute is not a script, but URI. It's totally same like you would have someSelector { background-image: url("/GetBackround.php"); } where GetBackground.php is *script* too. (eg. returning different bgr each 10 minutes)
But this wouldn't do formatting via CSS, it would do it with hacked-up fake CSS that calls some JS. If you're calling JS anyway, why bother hacking up the CSS? Toss some fixup scripts into the conditional comments like the rest of the IE workarounds.
(In reply to comment #5) > But this wouldn't do formatting via CSS, it would do it with > hacked-up fake CSS that calls some JS. Fake CSS, as you call it, is only for IE - why do you want to push other browsers to use JS instead of CSS? That's wrong. Please look at it in this order: Use CSS. You can't? Then use JS. Not vice versa as you do. > If you're calling JS anyway, why bother hacking up the CSS? > Toss some fixup scripts into the conditional comments like the > rest of the IE workarounds. And where would you imagine to have that conditional code? Where would you put it to have it accessible for all users? Simply accessible, of course...
In the CSS and JavaScript code that's conditionally loaded for IE. Please look at the existing code for this. (You'll see some conditional comments in the <head> section which pull these in.)
(sigh) I thought you meant this place. Please note, that putting it in <head> section (regardless if conditional CSS or JS) means that nobody except for developers could edit it or add new features. If somebody wanted to add new behavior they would have to run the entire slow bugzilla round again and again and I guess you also would not be pleased for being asked every other day to add new stuff. Please mind that there is a bunch of IE bugs which can be workarounded this way. On the other side, if MIME-type allowed, anybody could simply edit behavior file and link it to his/her personal stylesheet and admins could link it to global stylesheets in MediaWiki ns. Everybody could do it anytime needed simply by adding one line to CSS and nobody would have to delay developers with request of adding.
It would be rather better for the fixes to be available to everyone running MediaWiki, instead of just the few who have hacked up their local copies. Yes?
WONTFIXing this; does nothing that can't be accomplished already, may open new security holes. No reason to add a new vector for IE bugs to try to take advantage of.
(In reply to comment #9) > It would be rather better for the fixes to be available to > everyone running MediaWiki, instead of just the few who have > hacked up their local copies. Yes? Looks like you did not understand the purpose and function of behaviors - you can't install it somehow globally since it's *based on selectors* - you add the behavior to certain element(s). You also asked, what can be done using this and not via JS: This is it - assigning to proper elements. It either can not be done at all or it's very difficult to assign it. Simple example: Assigning to anonymous class .hover would be one line in CSS. In JS you would have to write code which will loop through all elements, check their classname and then either assign or not. That's wasting of resources. And try to imagine more complex selectors. Instead of one line of CSS - dozens of lines in JS for _each_ selector. Another thing is that if handled by JS it would have to be done after entire document loaded while CSS way works even when partially loaded. (In reply to comment #10) > WONTFIXing this; does nothing that can't be accomplished > already, may open new security holes. No reason to add a new > vector for IE bugs to try to take advantage of. You're not right when saying it can be accomplished - there is no way how to workaround IE bugs either with or without help of developers now. If you think you know the way, please show it. Regarding a virtual possibility of security holes: Behavior has been proven and used for many years without any known issue. If you'd look on everything this way you could not ever use any technology, because there is always *possibility* of security hole.
Hover is assigned with the :hover pseudoselector, not a class. If you have general workarounds that can be installed, we'd love to include them in the standard MediaWiki distribution. If only special-case hacks are possible (eg by changing your CSS every time to use a hacky "behavior"), then this is rather disappointing, and we wouldn't probably want to support that.
(In reply to comment #12) > Hover is assigned with the :hover pseudoselector, not a class. Again, you did not understand - I meant something like this (assigning hover to anonymous class): CSS compliant browser: .redtext:hover { color: green; } IE workaround: .redtext { behavior: url("hover.htc"); } .redtextHover { color: green; } > If you have general workarounds that can be installed, we'd > love to include them in the standard MediaWiki distribution. > If only special-case hacks are possible (eg by changing your > CSS every time to use a hacky "behavior"), then this is rather > disappointing, and we wouldn't probably want to support that. Special-case? Everytime you would like to change your CSS with regular :hover, you just simply add the behavior. There is no special case. And please dont't think about hover only. Position:fixed, :before, :after etc. are other issues. So if you decide to add position fixed eg. to sidebar you would write: #sidebar { position: fixed; behavior: url("positionfixed.htc"); } If it had to be handled via JS as you are trying to suggest - there would special cases happen - a bunch of coding in JS with a bunch of conditions and loops. You would push people to write unnecessary long code instead of one simple line.
Thanks, that confirms that 'behavior' is definitely inappropriate for IE workaround use. The JS case could be written once ever, and would pop in and fix all instances at load time, with no need to litter every bit of CSS you write with instance-specific hacks.
(In reply to comment #14) > Thanks, that confirms that 'behavior' is definitely > inappropriate for IE workaround use. What confirms this? Ain't wide usage enough evidence that this is the easiest way? Why nobody make weird long javascripts? > The JS case could be written once ever, and would pop in and > fix all instances at load time, with no need to litter every > bit of CSS you write with instance-specific hacks. The htc is also written once ever. How would you write JS once ever, when it **depends on selector**? How would you assign it? There's no way for it - for each selector you would have to write own routine. Let's imagine your way: In eg. monobook.js you would have function HandleHover (action) { blah blah the hover code } then for each selector you would have to write it's own function - let's consider the example in previous post: (schematically, not necessary the proper syntax) tags = document.getElementsByTagName("*"); for (i=0, i<tags.length, i++) if (Regexp.Match (tags[i].className, "(^|\s)redtext(\s|$)")) { tags[i].onmouseover = function(){HandleHover ("mouseover"); tags[i].onmouseout = function(){HandleHover ("mouseout"); } Hmm... 5 lines of schematical code instead of one line for CSS behavior. OK, how about handling the ".redtext .boldtext" selector? Hmm... Another loop inside - another at least 2 lines. How about "div p.boldtext span.redtext" - wow! three loops! Etc... And how about "div:hover p.boldtext:hover span.redtext:hover"? I don't even want to think about how wastefully difficult that code be. On the other side there is always one line in CSS with behavior. Anyway - I would be pleased to see any other solution. Remember you want to assign hover behavior only in certain cases and not globally. Same with position:fixed, :before, :after etc...
