Hi,
On Wed, 30 Dec 2015, Christophe Siraut wrote:
> Not ack, showing a form in a modal window or fullscreen makes no real UI
> difference: both ways require the same number of clicks, the same number
> of server requests, the same content is displayed, except the greyed
> background in the case of
Hi,
Raphael Hertzog wrote:
> While I certainly love simplicity and better code, I don't think that
> it's good idea to drop the ajax + javascript on that page. Switching
> back and forth between different pages to change keywords on multiple
> packages is not very good UI.
Not ack, showing a form
On Sat, 19 Dec 2015, Daniel Shahaf wrote:
> > and we need to ensure that the fallback when javascript is disabled do
> > actually work. I discovered recently while working on the port to
> > bootstrap 4 that it was not the case for some of the forms... (can't
> > remember which one right now)
>
>
Package: tracker.debian.org
Followup-For: Bug #808285
Raphael Hertzog wrote:
> and we need to ensure that the fallback when javascript is disabled do
> actually work. I discovered recently while working on the port to
> bootstrap 4 that it was not the case for some of the forms... (can't
> remembe
Hi,
On Fri, 18 Dec 2015, Christophe Siraut wrote:
> Keywords management is currently done using extensive javascript and
> ajax requests. As the rest of the application is using Django, we could
> gain reliability and simplicity using Django forms. We should not
> require javascript IMHO, better u
Package: tracker.debian.org
Severity: wishlist
Dear contributors,
Keywords management is currently done using extensive javascript and
ajax requests. As the rest of the application is using Django, we could
gain reliability and simplicity using Django forms. We should not
require javascript IMHO,
6 matches
Mail list logo
