incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: [Apache Bloodhound] #146: Inline editing of objects
Date Tue, 27 Nov 2012 16:54:56 GMT
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