Last modified: 2013-07-21 22:29:57 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 T29025, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 27025 - ResourceLoaderFileModule should have a debug mode for styles
ResourceLoaderFileModule should have a debug mode for styles
Status: NEW
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: 30804 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2011-01-29 03:14 UTC by Michael Dale
Modified: 2013-07-21 22:29 UTC (History)
12 users (show)

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


Description Michael Dale 2011-01-29 03:14:39 UTC
In debug mode it would be ideal if the css files could be directly referenced rather than inline included.

At least the css files should not be compressed in debug mode.
Comment 1 Michael Dale 2011-01-31 19:42:16 UTC
Note this would also help situations where your dealing with dynamic paths for the script include. ie in remote embedding or when you have a stand lone test file outside the root directory of the resource loader. 

When inserting transformed files into the current page, the resource loader does not take into consideration the current path of the page its acting on, ie a runtime configuration setting relative path. With the current setup you have to set $wgScriptPath to an absolute url.

Would be nice" to support non-transformed css output so that debugging css error is not as tricky.
Comment 2 Krinkle 2011-01-31 22:35:18 UTC
I'd say this is a bug rather than a feature request if you ask me. Debug mode means not combined, but linked directly, that goes for CSS as well.
Comment 3 Michael Dale 2011-02-01 00:27:55 UTC
I have to agree with Krinkle, its very difficult to debug css once you have a half dozen files with cascading rules all in same page without any reference to what files they came from.
Comment 4 Krinkle 2011-02-03 00:24:40 UTC
Since ResourceLoader should not make things harder but instead make things easier adding this as a blocker to the general 'Implement ResourceLoader' as the current situation is sort of a regression.
Comment 5 Trevor Parscal 2011-02-03 00:28:45 UTC
The only place this breaks down is RTL - because we support that on the fly. Otherwise CSS could be included directly just as JS is with no issues.
Comment 6 Michael Dale 2011-03-25 00:42:04 UTC
Even for RTL you should load the style sheet in another "&only=styles" request, otherwise you have every style sheet in the same dynamic include page append ... making it difficult to trace which rules come from where
Comment 7 Chad H. 2011-03-25 19:10:44 UTC
Removing odd dependency on bug 26939
Comment 8 Brion Vibber 2011-04-20 17:49:43 UTC
Sensible thing for RTL could be to load them as individual <link rel="stylesheet">s but still run them through load.php for transformation.
Comment 9 Bugmeister Bot 2011-08-19 19:12:57 UTC
Unassigning default assignments.
Comment 10 Brion Vibber 2011-09-07 20:34:23 UTC
What's the status on this in regards to bug 30804, which claims that RTL is now broken in debug mode?
Comment 11 Krinkle 2011-09-07 20:37:21 UTC
*** Bug 30804 has been marked as a duplicate of this bug. ***
Comment 12 Krinkle 2011-09-07 20:42:26 UTC
I don't know what Michael currently things about this, for me. I don't really care whether we do or do not load CSS in debug mode though load.php or from disk directly. What I do care about, is these two points:

1) Not minified,

so that advanced developer tools such as those that come with Google Chrome (not the default web inspector, but the more elaborate tools such as in-file editing of referenced resoruces)

2) Should eventually end up in a place other than the main document's DOM.

Reason being that many developer tool mark those styles as "in-document" style overrides (which, in a away, then are).

Note that these two points don't require loading them from disk. Using only=styles in a separate request in <link> works too. I don't have a preference for which one.
Comment 13 Brion Vibber 2011-09-07 20:44:02 UTC
Krinkle -- since you marked 30804 as a dupe of this, I assume you know: can you clarify what the present status of this is and describe how the RTL CSS got broken?
Comment 14 Michael Dale 2011-09-07 21:01:47 UTC
Krinkle, I would agree. All that maters is that you a way to find out what came from where.. if you have to read the url to get the style name that’s fine as you can relatively easily find where the rule came from.
Comment 15 Roan Kattouw 2011-09-08 08:52:26 UTC
(In reply to comment #12)
> 2) Should eventually end up in a place other than the main document's DOM.
> Reason being that many developer tool mark those styles as "in-document" style
> overrides (which, in a away, then are).
If I recall correctly, there are browsers in which adding <link> tags dynamically doesn't work but adding <style> tags does, and that's why we chose the latter back when we developed RL. However I think it was just one browser that was old and shitty (but still supported at the time), so it may be defensible to break that browser in debug mode. I just wish I remembered which one it was.
Comment 16 darklama 2011-09-08 11:34:15 UTC
If styles aren't minified in debug mode, wouldn't prepending a comment
as each stylesheet is combined together do the trick?

/** /skins/common/shared.css **/

abbr, acronym, .explain { }

/** /resources/mediawiki.special/mediawiki.special.preferences.css **/

#mw-emailaddress-validity { }

/** MediaWiki:Common.css **/

Comment 17 Michael Dale 2011-09-08 14:32:07 UTC
Prepending a comment to each style is not as ideal as separate requests because your looking at these styles via a debug tool like firebug, which has an interface organized around css coming from particular files. 

In firebug you can click through to the style location in-page then scroll up, but a separate request is much more ideal so that you can get a quick summary of what rules come from where and how they are cascading to build the given in-page representation.
Comment 18 Krinkle 2012-05-19 21:01:24 UTC
Adding the comment is not a useful fix. Implementing something like that would require lots of changes that simply aren't needed. We can just fix this bug the "right way".

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