On Thu, Dec 2, 2010 at 4:07 PM, Charles Pritchard wrote:
> On 12/2/2010 4:00 PM, Aryeh Gregor wrote:
>>
>> On Thu, Dec 2, 2010 at 3:30 PM, Charles Pritchard wrote:
>>>
>>> I can tell you, that blocking the issue does have real usability costs:
>>
>> I don't know if everyone here actually agrees w
On 12/2/2010 4:00 PM, Aryeh Gregor wrote:
On Thu, Dec 2, 2010 at 3:30 PM, Charles Pritchard wrote:
I can tell you, that blocking the issue does have real usability costs:
I don't know if everyone here actually agrees with that. Why can't
you rely on the browser's built-in spell-checking? Wha
On Thu, Dec 2, 2010 at 3:55 PM, Robert O'Callahan wrote:
> I think we could spec the following cases:
> 1) containing a fully loaded image; size is the intrinsic size of the
> image
> 2) when it's displaying a video or fully loaded poster image; size
> is the intrinsic size of the video or poste
On Thu, Dec 2, 2010 at 3:30 PM, Charles Pritchard wrote:
> I can tell you, that blocking the issue does have real usability costs:
I don't know if everyone here actually agrees with that. Why can't
you rely on the browser's built-in spell-checking? What are you
trying to do here? What, in othe
On Thu, Dec 2, 2010 at 6:34 PM, Simon Fraser wrote:
> On Dec 1, 2010, at 5:37 PM, Robert O'Callahan wrote:
>
> On Thu, Dec 2, 2010 at 2:25 PM, Tab Atkins Jr. wrote:
>
>> On Wed, Dec 1, 2010 at 5:20 PM, Robert O'Callahan
>> wrote:
>> > In the absence of compelling use cases, I'd just leave it at
Currently, Firefox and Safari output image/jpeg in a way that differs
from the spec:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11431
As Philip quotes:
"For image types that do not support an alpha channel, the image must be
composited onto a solid black background using the source-over opera
On 12/2/10 4:26 PM, Daniel Veditz wrote:
On 12/1/10 10:25 AM, timeless wrote:
Pnglets date to around 1999 according to a quick read of http://elf.org/pnglets/
Pnglets haven't worked in Mozilla for a long time, is
sandboxed.
It's not just sandboxed; it also doesn't execute. There's a bug o
On 12/2/10 2:31 PM, Daniel Veditz wrote:
On 12/1/10 7:29 AM, Boris Zbarsky wrote:
On 12/1/10 3:49 AM, Philip Jägenstedt wrote:
I dunno about solid, but the obvious things you can do with
javascript: that you can't do as easily with data: are things
that are dynamic. That said, in a sandbox the o
On Thu, Dec 2, 2010 at 8:30 PM, Charles Pritchard wrote:
> On 11/28/2010 11:30 PM, Benjamin Hawkes-Lewis wrote:
>>
>> Breaches would include:
>>
>> 1. Detecting the user's language (including fine distinctions like
>> British/US English).
>> 2. Fingerprinting the user's system. Different sys
On 12/1/10 10:25 AM, timeless wrote:
> Pnglets date to around 1999 according to a quick read of
> http://elf.org/pnglets/
Pnglets haven't worked in Mozilla for a long time, is
sandboxed. Theoretically you could embed the pnglet.js source into
the javascript: url, but that would be ridiculously c
On 11/28/2010 11:30 PM, Benjamin Hawkes-Lewis wrote:
Breaches would include:
1. Detecting the user's language (including fine distinctions like
British/US English).
2. Fingerprinting the user's system. Different systems likely use
different dictionaries with different coverage. You could
On 12/2/2010 12:08 PM, whatwg-requ...@lists.whatwg.org wrote:
Date: Thu, 02 Dec 2010 13:39:35 -0500
From: Boris Zbarsky
To:whatwg@lists.whatwg.org
Subject: Re: [whatwg] CSS canvas() function
Message-ID:<4cf7e7e7.3080...@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 12/2
On 12/1/10 7:29 AM, Boris Zbarsky wrote:
> On 12/1/10 3:49 AM, Philip Jägenstedt wrote:
> I dunno about solid, but the obvious things you can do with
> javascript: that you can't do as easily with data: are things
> that are dynamic. That said, in a sandbox the only things that
> are available a
On Thu, Dec 2, 2010 at 10:30 AM, Boris Zbarsky wrote:
> On 12/2/10 1:06 PM, Tab Atkins Jr. wrote:
>>
>> does, though, if the resource for whatever reason hasn't been
>> received and successfully decoded yet.
>
> I think showing @alt in this context for would be _really_ weird...
I agree; I'm j
On 12/2/10 1:27 PM, Charles Pritchard wrote:
Is this one in specs somewhere?
No, though there is ongoing work to create a way to have iframes outside
the DOM that load documents.
-Boris
On 12/2/10 1:06 PM, Tab Atkins Jr. wrote:
does, though, if the resource for whatever reason hasn't been
received and successfully decoded yet.
I think showing @alt in this context for would be _really_ weird...
-Boris
On 12/2/2010 2:48 AM, whatwg-requ...@lists.whatwg.org wrote:
Message: 2
Date: Wed, 01 Dec 2010 21:58:46 -0500
From: Boris Zbarsky
To:whatwg@lists.whatwg.org
Subject: Re: [whatwg] CSS canvas() function
Message-ID:<4cf70b66.7060...@mit.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
On
On Thu, Dec 2, 2010 at 2:28 AM, Simon Pieters wrote:
> On Thu, 02 Dec 2010 06:34:05 +0100, Simon Fraser wrote:
>> On Dec 1, 2010, at 5:37 PM, Robert O'Callahan wrote:
>>> On Thu, Dec 2, 2010 at 2:25 PM, Tab Atkins Jr.
>>> wrote:
>>> On Wed, Dec 1, 2010 at 5:20 PM, Robert O'Callahan
>>> wrote:
>
I forgot to mention that maybe only one bluetooth stack is relevant
here, the RFCOMM (serial). I think this makes the API more simple and
consistent (as USB and firewire are also serial).
--
Diogo
On Thu, 2010-12-02 at 15:56 +0100, Anne van Kesteren wrote:
> On Thu, 02 Dec 2010 15:50:07 +0100,
On Thu, 02 Dec 2010 15:50:07 +0100, Diogo Resende
wrote:
This is exactly my point (and probably Don). I was not thinking about
common i/o devices. I was thinking about a way to somehow connect to an
uncommon device. Maybe something like websockets, maybe devsockets :P
Heh.
I can see 3 impo
This is exactly my point (and probably Don). I was not thinking about
common i/o devices. I was thinking about a way to somehow connect to an
uncommon device. Maybe something like websockets, maybe devsockets :P
I can see 3 important steps to do this:
- have a way expose diferent devices (so the
On Thu, 02 Dec 2010 15:17:37 +0100, Silvia Pfeiffer
wrote:
IMO it's not so much about how the device is connected, but rather
what the device is: e.g. if it's a storage device then it should come
up as a storage device and not as a USB or FW device - the latter
doesn't really say what its use i
IMO it's not so much about how the device is connected, but rather
what the device is: e.g. if it's a storage device then it should come
up as a storage device and not as a USB or FW device - the latter
doesn't really say what its use is.
It would be more interesting to hear more about what uses w
On Thu, 02 Dec 2010 15:05:06 +0100, Diogo Resende
wrote:
What about having the possibility to "use" a device other than a video?
Maybe a specific hardware. I agree about not having a distinction on the
hardware stack being used, but there should be a way for an app to be
able to access an USBx/
What about having the possibility to "use" a device other than a video?
Maybe a specific hardware. I agree about not having a distinction on the
hardware stack being used, but there should be a way for an app to be
able to access an USBx/BT/FW device.
--
Diogo
On Wed, 2010-12-01 at 22:16 +1100,
I don't think Don was talking about mouse/kb/video/gps stuff. That
should be handled by the OS and reflected to the current APIs as wired
alternatives do. I think Don meant to be able to scan other types of
devices and be able to interact with them.
For example, a medical device may have no intere
On Thu, 02 Dec 2010 14:10:33 +0100, Anne van Kesteren
wrote:
For fetching EventSource resources treating mailto as if it was a 204
does not work as that reestablishes the connection. The result should be
more akin a network error of some kind I think. Similarly to how other
cross-origin re
Per the EventSource specification URLs are resolved against the "first
script". However, implementations -- Opera and Chrome -- appear to resolve
URLs in the same way they are resolved for XMLHttpRequest. I.e. against
the Document the interface object is associated with.
That is why this te
For fetching EventSource resources treating mailto as if it was a 204 does
not work as that reestablishes the connection. The result should be more
akin a network error of some kind I think. Similarly to how other
cross-origin requests fail if CORS is not used. I will add some tests for
thi
On Thu, 02 Dec 2010 11:38:33 +0100, Simon Pieters wrote:
On Thu, 02 Dec 2010 09:32:43 +0100, Philip Jägenstedt
wrote:
Right, these aren't inlines, in Opera terminology at least. As far as
I
can see the spec agrees on this, as frames/iframes have their own
browsing contexts.
So do s, so
What will be the current point after an arc with endAngle-startAngle > 2pi?
The specification seems to say that the end point is defined to be the point
at endAngle, but the path is required to be exactly a circle.
Andrea
On Thu, 02 Dec 2010 06:34:05 +0100, Simon Fraser wrote:
On Dec 1, 2010, at 5:37 PM, Robert O'Callahan wrote:
On Thu, Dec 2, 2010 at 2:25 PM, Tab Atkins Jr.
wrote:
On Wed, Dec 1, 2010 at 5:20 PM, Robert O'Callahan
wrote:
> In the absence of compelling use cases, I'd just leave it at ,
On Wed, 01 Dec 2010 16:24:31 +0100, Boris Zbarsky wrote:
On 12/1/10 3:16 AM, Philip Jägenstedt wrote:
Do you do that just for inlines, or also when navigating to javascript:
URLs? If it's both, then that's something we'd need to standardize,
unless all browsers already do the same.
It's both
33 matches
Mail list logo
