incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Dreimann <joachim.dreim...@wandisco.com>
Subject Re: [Apache Bloodhound] #146: Inline editing of objects
Date Tue, 27 Nov 2012 17:14:06 GMT
I like the fallback for the Quick Ticket button. For the Apps drop down, (we should really
rename that to *More*) we could alternatively link to the site map (do we have a functional
site map?).

- Joe

________________________
@jdreimann - Twitter
Sent from my phone

On 27 Nov 2012, at 16:54, Gary Martin <gary.martin@wandisco.com> wrote:

> On 27/11/12 15:56, Olemis Lang wrote:
>> On 11/26/12, Joachim Dreimann <joachim.dreimann@wandisco.com> wrote:
>>> On 26 November 2012 06:49, Peter Koželj <peter@digiverse.si> wrote:
>>> 
>>>> Not sure how much does support for javascript disabled browsers
>>>> complicate
>>>> things, but do we really care to support this when everybody is rushing
>>>> to
>>>> HTML5?
>>>> 
>>>> I haven't that kind of requirement for a web application in the last 7
>>>> years or so.
>>> HTML5 and JavaScript are two different issues, most obviously because one
>>> is a fix for the other: http://en.wikipedia.org/wiki/HTML5_Shiv
>>> HTML5 will also take some of the weight off JavaScript going forward, for
>>> example with contentEditable in this context:
>>> http://html5demos.com/contenteditable
>>> 
>>> Public sector organisations usually require all software to meet certain
>>> accessibility standards, and I would suggest that we build to their most
>>> basic standards at least. Screen readers often struggle with javascript, so
>>> Gary's suggestion was to at least have JS-less fallback (the current edit
>>> form). It's acceptable that this won't be pretty; most users will never see
>>> it.
>> 
>> Yes . Sometimes javascript solution is not available (e.g. disabled,
>> blocked by firewalls, unexpected errors ...) and pages should fallback
>> to non-JS behavior . There are even browsers like Netsurf built
>> without JS support ...
>> 
>> {{{
>> #!sh
>> 
>> $ apt-cache show netsurf
>> Package: netsurf
>> Priority: extra
>> Section: universe/web
>> Installed-Size: 1248
>> [...]
>> Description: Small portable web browser with CSS and Unicode support
>>  NetSurf is a multi-platform lightweight web browser. Its aim is to provide
>>  comprehensive rendering of HTML 4 with CSS 2 in a small resource footprint
>>  while remaining fast.
>> [...]
>> 
>> }}}
>> 
>> BTW , some parts of the site are not looking good on Netsurf . If that
>> deserves some attention , please let me know to create a new ticket
>> with screenshots .
>> 
>> Unfortunately at the moment that also means that e.g. mainnav and
>> create ticket shortcut menus won't work . We should take a look at
>> that too .
> 
> 
> Yeah, I suspected as much.
> 
> Is there a particular reason that these buttons cannot fall back to being links? I wouldn't
mind the Create Ticket button being a link to /newticket with the potential side effect of
being able to open /newticket in a new tab. Actually, I can't think of a good place for the
Apps to link to at short notice. Would there be any problems with having all the menu items
visible, perhaps wrapping when there are too many, when js is not available?
> 
> It does not need to be a particularly beautiful solution, we just need to let users access
the links that they would otherwise lose. All without compromising on the experience for those
with js enabled.
> 
> Cheers,
>    Gary
> 

Mime
View raw message