On Mon, Mar 14, 2011 at 8:05 PM, Robert O'Callahan wrote:
> On Sat, Mar 12, 2011 at 5:56 AM, Tab Atkins Jr. wrote:
>
>> I think we should be closing the / hole, not
>> expanding it as the primary way to smuggle in drawWindow
>> functionality. ^_^
>
> I actually think svg image + foreignobject is
On Thu, Mar 10, 2011 at 1:58 PM, Andy Mabbett wrote:
> On 10 March 2011 08:20, Jukka K. Korpela wrote:
> > what should we say to people to need to use paragraphs
> > that contain lists, for example?
>
> This has concerned me for some time.
>
> Consider a more complex scenario:
>
> I always like t
On Mon, Mar 14, 2011 at 11:19 PM, Daniel Cheng wrote:
> Isn't there an image resize API? IMO, that sounds like things that should
be
> handled by that API.
That's what Canvas itself is for.
In principle, it could optimize for Canvas use (uncompressed), and punt to
Canvas for a more complete comp
On Mon, Mar 14, 2011 at 20:14, Glenn Maynard wrote:
> On Mon, Mar 14, 2011 at 10:47 PM, Daniel Cheng
> wrote:
> > Is there an alternate bitmap format that's likely to be widely supported
> > across different browsers? I picked PNG since if the compression proves
> to
> > be expensive, we can sim
Glenn's point is a good one and the problem isn't whether the bitmap
will be supported across the browsers, its whether the bitmap will
make it to the system pasteboard in the first place (assuming its
being put there from a source other than the browser. While the
browser could push pngs or whate
On Mon, Mar 14, 2011 at 10:47 PM, Daniel Cheng wrote:
> Is there an alternate bitmap format that's likely to be widely supported
> across different browsers? I picked PNG since if the compression proves to
> be expensive, we can simply try less hard to compress the data (at the
> extreme end, we d
On Sat, Mar 12, 2011 at 5:56 AM, Tab Atkins Jr. wrote:
> I think we should be closing the / hole, not
> expanding it as the primary way to smuggle in drawWindow
> functionality. ^_^
>
I actually think svg image + foreignobject is an OK way to smuggle in the
functionality of rendering HTML fragme
I probably sent it with the wrong from: address.
On Mon, Mar 14, 2011 at 19:21, Glenn Maynard wrote:
> (Was Daniel's reply off-list?)
>
> On Mon, Mar 14, 2011 at 9:14 PM, Jeb Boniakowski wrote:
> > On Mon, Mar 14, 2011 at 9:22 PM, Daniel Cheng wrote:
> >> I'm currently 60-75% complete landing
(Was Daniel's reply off-list?)
On Mon, Mar 14, 2011 at 9:14 PM, Jeb Boniakowski wrote:
> On Mon, Mar 14, 2011 at 9:22 PM, Daniel Cheng wrote:
>> I'm currently 60-75% complete landing the patches for image paste support in
>> Chrome. I've chosen to expose image/png instead of a raw bitmap through
IMHO, drawWindow is a bad idea for the security of the platform. For
example, there's a complex interaction with trying to hide the color
of hyperlinks to prevent history sniffing.
Adam
On Mon, Mar 14, 2011 at 6:28 PM, Jonas Sicking wrote:
> And this is why it's a bad idea to separate "right t
And this is why it's a bad idea to separate "right to embed" from
"right to read" :(
http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html
/ Jonas
On Mon, Mar 14, 2011 at 5:52 PM, Gregg Tavares (wrk) wrote:
> Someone pointed out that once you have HTML5->Canvas->WebGL, even th
Awesome! Yeah I saw some of your patches in the public webkit trac
last week, but only the bits that were clearly related to implementing
the current spec.
The great thing about doing it as getAsBlob(), besides just being
cleaner is you keep the door open for expanding, through adding more
entrie
Someone pointed out that once you have HTML5->Canvas->WebGL, even though you
can't call readPixels or toDataURL or getImageData because of cross origin
issues you can write a shader that takes longer depending on the color and
then just time draw calls to figure out what's in the texture.
In other
I'm currently 60-75% complete landing the patches for image paste support in
Chrome. I've chosen to expose image/png instead of a raw bitmap through
event.clipboardData.items in Chrome as a Blob. DataTransferItem::getAsFile()
is currently specced to return a File; in my local changes, it secretly
r
On Mon, 14 Mar 2011 22:09:26 +0200, Jukka K. Korpela wrote:
Christoph Päper wrote:
A new type is probably not necessary, because a new attribute that
is
called something like ‘unit’ and is only valid in the ‘number’ and
‘range’ states could be enough.
I don't quite see the point (no pun
I would like to be able to paste images from the system clipboard into
web apps. E.g. an annotated screengrab right into the bug tracker, a
pic into emails, an image from twitpic into a blog CMS's post screen.
(Apologies if this has been discussed recently and conclusions made.
I searched the arc
On Mon, Mar 14, 2011 at 1:27 PM, Luis Marsnao wrote:
> Can data: URIs be used insecurely?
Yes, but everything can be used insecurely, even a butter knife.
> I'm attempting to write a client-side script that processes a user selected
> file through an input element. Since the input element inter
Can data: URIs be used insecurely?
I'm attempting to write a client-side script that processes a user selected
file through an input element. Since the input element interface conceals the
file: URI, the best solution I can think of is to access the file through the
input element's interface, g
Christoph Päper wrote:
A new type is probably not necessary, because a new attribute that is
called something like ‘unit’ and is only valid in the ‘number’ and
‘range’ states could be enough.
I don't quite see the point (no pun intended). It seems that the unit="pt"
attribute just says th
Christoph Päper (2011-03-05):
> Thus, would it make sense to add another new type for the ‘input’ element?
A new type is probably not necessary, because a new attribute that is called
something like ‘unit’ and is only valid in the ‘number’ and ‘range’ states
could be enough.
This solution
On Sun, Mar 13, 2011 at 5:20 PM, Markus Ernst wrote:
> IMO, from the moment you decide to use and not style="bold" (be it due
> to a user selectable mode or not), style="bold" should actually be totally
> avoided. . . .
>
> I think that the code generated should be homogeneous, independent from t
Hi,
There are a few issues with the recently added media streaming API.
The IDL for GeneratedStream should indicate that it inherits from the
Stream interface.
The API includes both readystatechange event, as well as independent
events for play, paused and ended. This redundancy is unneces
22 matches
Mail list logo
