Last modified: 2011-03-13 18:05:36 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T8335, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 6335 - Additional MIME type in allowedCTypes in RawPage.php
Additional MIME type in allowedCTypes in RawPage.php
Status: RESOLVED WONTFIX
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-16 22:32 UTC by Danny B.
Modified: 2011-03-13 18:05 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Danny B. 2006-06-16 22:32:17 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.
Comment 1 Brion Vibber 2006-06-17 00:26:06 UTC
What can this do that existing JavaScript can't?
Comment 2 Danny B. 2006-06-17 01:22:32 UTC
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.
Comment 3 Brion Vibber 2006-06-17 01:41:14 UTC
But behavior *is* JavaScript (or VBScript). So what's the 
difference?
Comment 4 Danny B. 2006-06-17 01:57:59 UTC
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)
Comment 5 Brion Vibber 2006-06-17 02:06:42 UTC
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.
Comment 6 Danny B. 2006-06-17 02:21:16 UTC
(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...
Comment 7 Brion Vibber 2006-06-17 10:33:11 UTC
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.)
Comment 8 Danny B. 2006-06-17 11:12:52 UTC
(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.
Comment 9 Brion Vibber 2006-06-17 11:18:23 UTC
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?
Comment 10 Brion Vibber 2006-06-17 11:19:17 UTC
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.
Comment 11 Danny B. 2006-06-17 12:02:36 UTC
(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.
Comment 12 Brion Vibber 2006-06-17 12:08:12 UTC
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.
Comment 13 Danny B. 2006-06-17 12:25:18 UTC
(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.
Comment 14 Brion Vibber 2006-06-17 12:34:50 UTC
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.
Comment 15 Danny B. 2006-06-17 13:16:10 UTC
(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...

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links