On Tue, Sep 14, 2010 at 4:30 PM, Jim Williams wrote:
> I see localStorage and sessionStorage as a chance to fix things that weren't
> so good with cookies. So I'd be interested to know what factors actively
> promote the failure to come up with a common browser-independent interface
> for localSt
The application I'm mainly thinking of is
courseware, and it indeed does need to obtain server-side copies of
students' work. But, academia being what it is, these systems tend to
get overused and bog down and crash, inflicting furor and anguish on
students and professors alike. An ability fo
I see localStorage and sessionStorage as a chance
to fix things that weren't so good with cookies. So I'd be interested
to know what factors actively promote the failure to come up with a
common browser-independent interface for localStorage. Do browser
builders actually have something to gai
On Tue, 14 Sep 2010 21:13:46 +0200, Jian Li wrote:
Yes, we only need to add it to BlobBuilder so that it can be applied to
both FileReader, XHR.send and any other place that take the blob.
send() takes everything straight as well. BlobBuilder should not be a
prerequisite to transmit bytes,
Yes, we only need to add it to BlobBuilder so that it can be applied to both
FileReader, XHR.send and any other place that take the blob.
On Wed, Sep 8, 2010 at 10:57 AM, Eric Uhrhane wrote:
> On Tue, Sep 7, 2010 at 4:09 PM, Jian Li wrote:
> > Hi,
> > Several specs, like File API and WebGL, us
On 2010-09-14 08:37, Julian Reschke wrote:
On 13.09.2010 23:51, Aryeh Gregor wrote:
...
And for heavens sake, do not specify any sniffing as "official".
Instead, explicitly specify all sniffing as UA specific and possibly
suggest that UAs should inform the user that content is broken and the
c
On 2010-09-13 15:55, Nils Dagsson Moskopp wrote:
Mikko Rantalainen schrieb am Mon, 13 Sep
2010 16:03:27 +0300:
[…]
Basically, this sounds like all the issues of BOM for all binary
files.
And why do we need this? Because web servers are not behaving
correctly and are sending incorrect Conten
On Tue, Sep 14, 2010 at 4:52 AM, Jim Williams wrote:
> I tried out local storage, used it to save the contents of a
> content-editable passage. It worked great in Firefox, Chrome, Safari, and
> MSIE. Only one problem: Every time I switched browsers, I had to start
> over with the original unedi
On Tue, Sep 14, 2010 at 4:52 AM, Jim Williams wrote:
> I tried out local storage, used it to save the contents of a
> content-editable passage. It worked great in Firefox, Chrome, Safari, and
> MSIE. Only one problem: Every time I switched browsers, I had to start
> over with the original unedi
Interesting points. Possibly, my proposed cure is worse than the
original problem.
Jim Williams
Matthew Kaufman wrote:
On 9/14/2010 5:00 AM, Ashley Sheridan wrote:
I'm not entirely sure that this is possible. As far as I know (and I
could be very wrong) the events start
On 9/14/2010 5:00 AM, Ashley Sheridan wrote:
I'm not entirely sure that this is possible. As far as I know (and I
could be very wrong) the events start with the OS and work their way
down the system to eventually reach the Javascript through a user
agent, so if the mouse has moved off of the
"Michael(tm) Smith" , 2010-09-14 19:26 +0900:
> So if you can make time to review it, comments and questions on it
> are welcome anywhere; for example, as a reply to this message, or
> as entries on the related Talk page here:
>
> http://www.w3.org/WAI/PF/HTML/wiki/Talk:Media_Accessibility_Chec
On Tue, 2010-09-14 at 07:51 -0400, Jim Williams wrote:
> Currently, there appears to be no way of sensing the location of the
> mouse cursor without waiting for user-initiated events. The problem
> is that there is no way to fill in the real current values for many of
> the parameters when execut
I tried out local storage,
used it to save the contents of a content-editable passage. It worked
great in Firefox, Chrome, Safari, and MSIE. Only one problem: Every
time I switched browsers, I had to start over with the original
unedited passage. So I have two requests.
1. I would like th
The following document has recently been made available for review:
http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Checklist
It is the product of quite a lot of discussion and work, by a
number of people, toward the goal of identifying specific needs of
users with disabilities for alter
On Tue, 14 Sep 2010 10:30:03 +0200, Simon Pieters wrote:
On Tue, 14 Sep 2010 10:11:16 +0200, Philip Jägenstedt
wrote:
The point of a header is that browsers can identify WebSRT files and
not keep parsing through a 100GB movie file,
I don't think we should break SRT compat for this. I do
On Tue, 14 Sep 2010 10:33:42 +0200, Philip Jägenstedt
wrote:
I don't know, do we need comments anywhere? Putting them between cues
might work, but is that useful?
Apart from text/plain I cannot think of a "web" text format that does not
have comments. Validators should probably recommend a
On Tue, 14 Sep 2010 10:27:28 +0200, Silvia Pfeiffer
wrote:
On Tue, Sep 14, 2010 at 6:11 PM, Philip Jägenstedt
wrote:
On Mon, 13 Sep 2010 15:50:09 +0200, Silvia Pfeiffer <
silviapfeiff...@gmail.com> wrote:
Further, with your analysis, it seemed like the following could be
acceptable for
On Tue, 14 Sep 2010 10:11:16 +0200, Philip Jägenstedt
wrote:
The point of a header is that browsers can identify WebSRT files and not
keep parsing through a 100GB movie file,
I don't think we should break SRT compat for this. I don't think this is a
problem at all. We already have this s
On Tue, Sep 14, 2010 at 6:11 PM, Philip Jägenstedt wrote:
> On Mon, 13 Sep 2010 15:50:09 +0200, Silvia Pfeiffer <
> silviapfeiff...@gmail.com> wrote:
>
> On Mon, Sep 13, 2010 at 5:55 PM, Philip Jägenstedt > >wrote:
>>
>> On Sat, 11 Sep 2010 01:27:48 +0200, Silvia Pfeiffer <
>>> silviapfeiff...@g
On Mon, 13 Sep 2010 15:50:09 +0200, Silvia Pfeiffer
wrote:
On Mon, Sep 13, 2010 at 5:55 PM, Philip Jägenstedt
wrote:
On Sat, 11 Sep 2010 01:27:48 +0200, Silvia Pfeiffer <
silviapfeiff...@gmail.com> wrote:
On Fri, Sep 10, 2010 at 11:00 PM, Philip Jägenstedt
>wrote:
On Thu, 09 Sep 2010
21 matches
Mail list logo