https://bugzilla.wikimedia.org/show_bug.cgi?id=27488

Happy-melon <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #20 from Happy-melon <[email protected]> 2011-04-02 
16:19:31 UTC ---
(In reply to comment #18)
> From user script developer side of view I would want a way to inject scripts
> before or after other scripts. 

I'm not convinced that that is really what a script developer wants (or at
least *should* want).  What you *really* want is an environment where these
things are not a concern.  We actually *don't* want wiki users to have either
the ability or inclination to microtune the mechanics of resource loading;
instead we want to provide a nice interface which allows users to specify in
abstract terms what they want, and then a backend which works correctly to
deliver it.  It's certainly true that that system is not correct or complete
currently.

Let's not forget that the biggest problem here is caused by scripts which are
making big changes to the structure of a page, particularly collapsing stuff. 
I'm not honestly too concerned about there being a delay before a piece of
whitespace becomes a new tab; the problem is when a JS-induced change moves
existing stuff around.

It's quite right that we don't apply the collapsible styles by default lest the
content become inaccessible to users without javascript.  But that's not really
the proper order of support: we are implicitly treating the no-javascript case
as the default, and then trying to add functionality on top of it; hiding stuff
shouldn't really be done with JS, it should be done with CSS, but we daren't do
it with CSS lest the user never actually get the corresponding JS.  

Rather, we should think of the with-javascript case as the default and treat
the without-script case as the exception.  In r83292 I introduced support for
loading [[MediaWiki:Noscript.css]] in a <noscript></noscript> tag in the
header.  That infrastructure could easily be extended to load core noscript
modules.  Having that extra option: to safely do something in CSS knowing you
can *undo* it in CSS for script-less browsers, could open up some interesting
new possible avenues.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to