On Wed, 18 Dec 2013 03:28:36 +0100, Krinkle krinklem...@gmail.com wrote:
In fact, we
could drop debug mode entirely (short of its effect on debug-modules being
loaded, it wouldn’t affect the way modules are packages anymore).
While this would be lovely, some browsers don't support source
I love how this thread evolved, +1 on pretty much all previous replies.
A few more thoughts though.
On 10 Dec 2013, at 03:29, MZMcBride z...@mzmcbride.com wrote:
Ori Livneh wrote:
On Mon, Dec 9, 2013 at 2:58 PM, Ryan Kaldari rkald...@wikimedia.org
wrote:
I am somewhat concerned about the
Another point to look into if someones wants to refactor the RL debug=true:
When loading VE with debug=true hundreds of modules are loaded (with
different requests) and it takes long to load it.
It would be nice to have an option of debug=0.5 :)
in which all the resources (or at least the ve
Le 10/12/13 05:30, MZMcBride a écrit :
I think adding an explicit HTML comment in the page source is a reasonable
suggestion to consider.
We already had an argument a few months ago regarding adding comments in
the minified css/js and we said no. Who ever look at that source code
will be able
2013/12/10 MZMcBride z...@mzmcbride.com
* Minification reduces bandwidth usage.
** At the cost of making debugging more difficult.
There is one thing that debug mode makes harder: Seeing how the page looks
in an RTL language. That's because CSSJanus doesn't work in debug mode, and
there were
As everybody else already said, less bandwidth is a good thing for most
people, obfuscation is OK when the source is available elsewhere, and
debug=true is not hard for developers to find.
I'd actually disagree with the assertion that debug=true is easy to
find, particularly for people who
On 11.12.2013, 19:36 Brian wrote:
As everybody else already said, less bandwidth is a good thing for most
people, obfuscation is OK when the source is available elsewhere, and
debug=true is not hard for developers to find.
I'd actually disagree with the assertion that debug=true is easy to
On Wed, Dec 11, 2013 at 11:33 AM, Max Semenik maxsem.w...@gmail.com wrote:
If they look at the URL it will be pretty obvious because all of them
have debug=false as first parameter.
As a proof of concept, this is how I found out about the debug parameter
the first time I tried doing
+1000 to what Max says. It really is kinda obvious to anyone who needs to
know how to get into debug mode and if not there are wiki pages and if not
it's easy enough to find out if you care enough.
That said debug mode could definitely be improved and I'm glad you brought
this topic up Max. A few
On 12/09/2013 11:30 PM, MZMcBride wrote:
Matthew Flaschen wrote:
On 12/09/2013 09:29 PM, MZMcBride wrote:
* You can specify debug=true.
** Specifying the URL parameter can damage reproducibility.
** URL parameter is non-obvious to just about everyone.
I can't think of a more straight-forward
Ori Livneh wrote:
On Mon, Dec 9, 2013 at 2:58 PM, Ryan Kaldari rkald...@wikimedia.org
wrote:
I am somewhat concerned about the implications for JS debugging here.
Debugging JS problems with the live sites is already pretty complicated:
1. debug=true won't reproduce some bugs (usually race
On 12/09/2013 09:29 PM, MZMcBride wrote:
* Minification is a form of obfuscation and it harms the open Web.
That's true iff there isn't a readily available way of getting the
non-obfuscated source. For normal day-to-day browsing you /want/ to
shave those extra ms off (all the more so if you are
On 12/09/2013 09:29 PM, MZMcBride wrote:
* You can specify debug=true.
** Specifying the URL parameter can damage reproducibility.
** URL parameter is non-obvious to just about everyone.
I can't think of a more straight-forward name. It's also clearly
documented.
* Minification is a form
Matthew Flaschen wrote:
On 12/09/2013 09:29 PM, MZMcBride wrote:
* You can specify debug=true.
** Specifying the URL parameter can damage reproducibility.
** URL parameter is non-obvious to just about everyone.
I can't think of a more straight-forward name. It's also clearly
documented.
14 matches
Mail list logo