First of all: I hope I'm not too annoying with all my suggestions/questions. Otherwise let me know. My mind is always filled with random ideas ;)
I'd like to spark some discussion about noscript-support, particularly after I read that it was a feature suggestion for phpMyAdmin 3 over 3 years ago (http://wiki.phpmyadmin.net/pma/phpMyAdmin_3).
I don't know the numbers, but I would assume that nowadays, the percentage of pma users that do not have javascript on must be very low. If there's uncertainty about it, maybe we could start some survey/poll on the phpmyadmin site? (I would offer myself to build it)
From what I can see in the global trends, is that the amount of
non-javascript users has been steadily decreasing, with current statistics talking about only 1-3% of internet users having javascript disabled.
It feels like a clear disadvantage to me needing to always consider non-javascript users, ending up with programming every feature twice where I could program twice the amount of features instead ;)
Having said this, does pma really need noscript-support?
Le 2011-05-20 16:24, Tyron Madlener a écrit :
First of all: I hope I'm not too annoying with all my suggestions/questions. Otherwise let me know. My mind is always filled with random ideas ;)
I'd like to spark some discussion about noscript-support, particularly after I read that it was a feature suggestion for phpMyAdmin 3 over 3 years ago (http://wiki.phpmyadmin.net/pma/phpMyAdmin_3).
I don't know the numbers, but I would assume that nowadays, the percentage of pma users that do not have javascript on must be very low. If there's uncertainty about it, maybe we could start some survey/poll on the phpmyadmin site? (I would offer myself to build it)
From what I can see in the global trends, is that the amount of
non-javascript users has been steadily decreasing, with current statistics talking about only 1-3% of internet users having javascript disabled.
It feels like a clear disadvantage to me needing to always consider non-javascript users, ending up with programming every feature twice where I could program twice the amount of features instead ;)
Having said this, does pma really need noscript-support?
I would say no. Anyway, looking at the development done for 3.4, the trend is to avoid inline js. We are now supposed to use jQuery to make visible a link or button that brings the user to a feature that requires js.
Note that 3.3 and 3.4 have problems with this. For example, Synchronize should not be shown to non-js users. Clearly, testing on non-js browsers has not been our priority.
On Sat, May 21, 2011 at 12:38 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-05-20 16:24, Tyron Madlener a écrit :
First of all: I hope I'm not too annoying with all my suggestions/questions. Otherwise let me know. My mind is always filled with random ideas ;)
I'd like to spark some discussion about noscript-support, particularly after I read that it was a feature suggestion for phpMyAdmin 3 over 3 years ago (http://wiki.phpmyadmin.net/pma/phpMyAdmin_3).
I don't know the numbers, but I would assume that nowadays, the percentage of pma users that do not have javascript on must be very low. If there's uncertainty about it, maybe we could start some survey/poll on the phpmyadmin site? (I would offer myself to build it)
From what I can see in the global trends, is that the amount of
non-javascript users has been steadily decreasing, with current statistics talking about only 1-3% of internet users having javascript disabled.
It feels like a clear disadvantage to me needing to always consider non-javascript users, ending up with programming every feature twice where I could program twice the amount of features instead ;)
Having said this, does pma really need noscript-support?
I would say no. Anyway, looking at the development done for 3.4, the trend is to avoid inline js. We are now supposed to use jQuery to make visible a link or button that brings the user to a feature that requires js.
Note that 3.3 and 3.4 have problems with this. For example, Synchronize should not be shown to non-js users. Clearly, testing on non-js browsers has not been our priority.
Oh interesting, so Synchronize doesn't work without Javascript? Does that mean I can drop the noscript-support for the Status page? :) I can avoid inline script, thats no problem. But I'd like to build in some feature that only work with javascript & ajax.
-- Marc Delisle http://infomarc.info
What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Sat, 21 May 2011 06:38:47 -0400 Marc Delisle marc@infomarc.info napsal(a):
I would say no. Anyway, looking at the development done for 3.4, the trend is to avoid inline js. We are now supposed to use jQuery to make visible a link or button that brings the user to a feature that requires js.
Yes, dropping inline js should be a goal to avoid need for inline and eval options in CSP.
Note that 3.3 and 3.4 have problems with this. For example, Synchronize should not be shown to non-js users. Clearly, testing on non-js browsers has not been our priority.
Well I doubt it was tested without javascript at all.
Probably it's really time to drop support for browsers without javascript, it would make lot of things easier. However what I would like to avoid is making all things using javascript. I really prefer when I can open link in new tab when I want and this does not work with javascript only solutions.
On Mon, May 23, 2011 at 4:03 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Sat, 21 May 2011 06:38:47 -0400 Marc Delisle marc@infomarc.info napsal(a):
I would say no. Anyway, looking at the development done for 3.4, the trend is to avoid inline js. We are now supposed to use jQuery to make visible a link or button that brings the user to a feature that requires js.
Yes, dropping inline js should be a goal to avoid need for inline and eval options in CSP.
Note that 3.3 and 3.4 have problems with this. For example, Synchronize should not be shown to non-js users. Clearly, testing on non-js browsers has not been our priority.
Well I doubt it was tested without javascript at all.
Probably it's really time to drop support for browsers without javascript, it would make lot of things easier. However what I would like to avoid is making all things using javascript. I really prefer when I can open link in new tab when I want and this does not work with javascript only solutions.
It does, if its done right. It works when you represent links with anchors (and ideally use a js history lib like RSH: http://code.google.com/p/reallysimplehistory/) I've implemented such behavior for my CMS that I'm using on my website tyron.at where pages are being loaded with ajax whenever you click a link. You can try it out there - to open a link in a new tab.
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Mon, May 23, 2011 at 5:32 PM, Tyron Madlener tyronx@gmail.com wrote:
On Mon, May 23, 2011 at 4:03 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Sat, 21 May 2011 06:38:47 -0400 Marc Delisle marc@infomarc.info napsal(a):
I would say no. Anyway, looking at the development done for 3.4, the trend is to avoid inline js. We are now supposed to use jQuery to make visible a link or button that brings the user to a feature that requires js.
Yes, dropping inline js should be a goal to avoid need for inline and eval options in CSP.
Note that 3.3 and 3.4 have problems with this. For example, Synchronize should not be shown to non-js users. Clearly, testing on non-js browsers has not been our priority.
Well I doubt it was tested without javascript at all.
Probably it's really time to drop support for browsers without javascript, it would make lot of things easier. However what I would like to avoid is making all things using javascript. I really prefer when I can open link in new tab when I want and this does not work with javascript only solutions.
It does, if its done right. It works when you represent links with anchors (and ideally use a js history lib like RSH: http://code.google.com/p/reallysimplehistory/) I've implemented such behavior for my CMS that I'm using on my website tyron.at where pages are being loaded with ajax whenever you click a link. You can try it out there - to open a link in a new tab.
Might be actually a cleverer choice to make anchor links and using rsh for the callback instead of attaching custom events to the links on each page.
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Mon, May 23, 2011 at 4:03 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Sat, 21 May 2011 06:38:47 -0400 Marc Delisle marc@infomarc.info napsal(a):
I would say no. Anyway, looking at the development done for 3.4, the trend is to avoid inline js. We are now supposed to use jQuery to make visible a link or button that brings the user to a feature that requires js.
Yes, dropping inline js should be a goal to avoid need for inline and eval options in CSP.
Note that 3.3 and 3.4 have problems with this. For example, Synchronize should not be shown to non-js users. Clearly, testing on non-js browsers has not been our priority.
Well I doubt it was tested without javascript at all.
Probably it's really time to drop support for browsers without javascript, it would make lot of things easier. However what I would like to avoid is making all things using javascript. I really prefer when I can open link in new tab when I want and this does not work with javascript only solutions.
By the way, for dropping support for browsers without js it would be useful to have all the js variable definitions in the right frame. The ones that are currently defined in the parent page where the <frameset> is defined. You could read it with a parent selector, but that doesn't work if one opens a page in a new tab.
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Mon, 23 May 2011 18:33:30 +0200 Tyron Madlener tyronx@gmail.com napsal(a):
By the way, for dropping support for browsers without js it would be useful to have all the js variable definitions in the right frame. The ones that are currently defined in the parent page where the <frameset> is defined. You could read it with a parent selector, but that doesn't work if one opens a page in a new tab.
Actually when dropping support for browsers without js, we could drop frames as well, because we would reload content only and not the list of the tables. However these are bigger changes which are probably not on the schedule right now...
On Tue, May 24, 2011 at 12:53 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Mon, 23 May 2011 18:33:30 +0200 Tyron Madlener tyronx@gmail.com napsal(a):
By the way, for dropping support for browsers without js it would be useful to have all the js variable definitions in the right frame. The ones that are currently defined in the parent page where the <frameset> is defined. You could read it with a parent selector, but that doesn't work if one opens a page in a new tab.
Actually when dropping support for browsers without js, we could drop frames as well, because we would reload content only and not the list of the tables. However these are bigger changes which are probably not on the schedule right now...
Oh yes, thats a great idea. Let's do this someday :)
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Tue, May 24, 2011 at 2:16 PM, Tyron Madlener tyronx@gmail.com wrote:
On Tue, May 24, 2011 at 12:53 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Mon, 23 May 2011 18:33:30 +0200 Tyron Madlener tyronx@gmail.com napsal(a):
By the way, for dropping support for browsers without js it would be useful to have all the js variable definitions in the right frame. The ones that are currently defined in the parent page where the <frameset> is defined. You could read it with a parent selector, but that doesn't work if one opens a page in a new tab.
Actually when dropping support for browsers without js, we could drop frames as well, because we would reload content only and not the list of the tables. However these are bigger changes which are probably not on the schedule right now...
Oh yes, thats a great idea. Let's do this someday :)
Until we build this, can I make a temporary solution and add (some) of those variables to my server_status.php header? That would mean I need to make the variable definitions in the php file (=inline js) That would simplify my js code and wouldn't require any adjustments once the frames are gone, except for deleting some lines of code where the js variables are being defined.
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-
Marc Delisle -
Michal Čihař -
Tyron Madlener