Brad Knowles wrote:
>Ethan said:
>
>> I plan on using [2] to generate mbox thread indexes for rapid navigation
>> of lists. Any suggestions for more robust variants would be welcome;
>> feedback on how to handle threading for message-id-less messages would
>> also be welcome.
>
>All messages shoul
Ethan said:
> In the interest of not reinventing the wheel, I'm looking for existing
> python (or other!) code that does the things I need. I'm also putting
> out a call for anybody who likes this sort of thing to help me out (see
> below).
Don't ignore non-Python solutions. In particular, you s
Barry Warsaw wrote:
>> I will do this for browsers not employing JavaScript. Screen readers
>> employ JavaScript and provide no indication what they do/do not
>> provide
>> feedback to the user for.
>
> Will this also work for browsers with JS enabled per-page, a la the
> Firefox NoScript extensio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 4, 2006, at 2:06 PM, emf wrote:
> Brad Knowles wrote:
>
>> Speaking only for myself, this is not the kind of approach I'd
>> like to see
>> used. I'd prefer to see the web application auto-detect that
>> JavaScript
>> is not available, and
Dearest mail manipulating macaques and perambulating python
prestidigitators,
I have been blessed by the grace of Google and so am working full-time
on improving Mailman's web UI:
http://wiki.list.org/display/DEV/Summer+of+Code
In order to provide interfaces to archives, I believe I must perfo
emf wrote:
>> Likewise, it should auto-detect that there is a
>> screen reader being used, and present the appropriate screen reader
>> compatible interface.
>
> This is an admirable goal. One "screen reader" in semi-common use is IE
> 6 via Jaws; another one is Safari with OS X reading turned o
Brad Knowles wrote:
> Speaking only for myself, this is not the kind of approach I'd like to see
> used. I'd prefer to see the web application auto-detect that JavaScript
> is not available, and therefore to automatically present the appropriate
> non-JavaScript interface.
I will do this for br
Ethan replied to Barry:
>>> Pretty please, I need to set up a copy of someone's translation
>>> toolchain; can someone using OS X or Linux as their work operating
>>> system work with me to get an *exact* replica of their toolset?
>>
>> Have you gotten any love on this issue Ethan?
>
> No love as
Ethan wrote:
> Note that this would be in *addition* to the ability to get a JS-free
> version of the interface by using a different URL prefix for any user
> agent that doesn't want the JS action.
Speaking only for myself, this is not the kind of approach I'd like to see
used. I'd prefer to see
Gentlebeings,
I have read a depressing and recent article suggesting that DOM
manipulations are invisible to most screen readers [1]. There are some
workarounds suggested in [2], but for the most part it looks like
dangerous territory.
What's worse, there seems to be no way to detect screen re
Barry Warsaw wrote:
> I'm sure this was ages ago, but IIRC, UTF-8 was discussed at some point
> and the decision was made not to use it because it's support was pretty
> spotty in the browsers of the time. I'm sure this has improved vastly
> now and UTF-8 makes the most sense.
Yeah, that soun
A few weeks ago I opened a discussion "sender-based authorisation" about
something similar to "Approved: password", but where the password would be
associated with a person (sender) rather than a list.
There seemed to be agreement in principle. (For the history, see that
thread.)
Being completel
12 matches
Mail list logo
