On Tue, Jul 1, 2014 at 1:13 AM, Glenn Maynard gl...@zewt.org wrote:
Why would the identifier not just be the blob URL itself? The spec
currently makes the identifier just the scheme data, which seems much more
complex than it needs to be. revokeObjectURL should simply be Remove the
entry
On Jun 30, 2014, at 7:13 PM, Glenn Maynard gl...@zewt.org wrote:
Why would the identifier not just be the blob URL itself? The spec currently
makes the identifier just the scheme data, which seems much more complex than
it needs to be. revokeObjectURL should simply be Remove the entry from
On Jul 1, 2014, at 2:32 AM, Anne van Kesteren ann...@annevk.nl wrote:
That works for me. That way we can make this a more generic store if
god forbid we get more of these schemes.
While I think mediastream URLs may have died on the vine, using the same store
for filesystem URLs would be
Hi WebApps/HTML,
There has a been a lot of progress on figuring out goals and use cases for
Editing since the last call. I think it would be beneficial to do another call
next Friday, July 11th. Does everyone agree? We have the time reserved at 8am
Pacific Standard Time [1].
I will add all of
From: Maciej Stachowiak m...@apple.com
Web Components as currently designed cannot explain the behavior of any
built-in elements (except maybe those which can be explained with CSS alone).
Unfortunately this is a hard problem that nobody has even sketched a solution
to.
From what I
Domenic Denicola wrote:
True encapsulation, wherein each element gets some kind of isolated world in
which to implement itself, is much harder. Blink-in-JS [1] accomplishes
something along these lines, but does not leverage custom elements, shadow DOM,
or the like, and essentially works by
Hi,
Maciej said:
I agree with the need for encapsulation in Web Components and have
been arguing for it for a long time. Currently, despite agreement
dating back several years, it doesn’t even offer a mode with better
encapsulation. Now that the non-encapsulation version has shipped in
I meant Shadow DOM below, where I wrote Web Components.
IIRC Mozilla second, Google first, are implementing. Anyone else?
/be
Brendan Eich wrote:
I'm not saying WebComponents aren't good enough, note well. Sounds
like they're pretty good and can be evolved and built upon to be even
better in
From: Edward O'Connor [mailto:eocon...@apple.com]
But soft encapsulation is just as useless for explaining the platform
as no encapsulation at all.
I think just as useless overstates your case. Type 2 allows you to hide
implementation details of your component from authors better than
Domenic Denicola wrote:
Well, but*for explaining the platform* it is just as useless.
That is a false idol if it means no intermediate steps that explain some
but not all of the platform.
It may be useful independently for authors who wish to protect against
interference by people who
From: Brendan Eich [mailto:bren...@secure.meer.net]
That is a false idol if it means no intermediate steps that explain some but
not all of the platform.
Sure. But I don't think the proposed type 2 encapsulation explains any of the
platform at all. (Just as per Maciej's email from Monday,
Domenic Denicola wrote:
From: Brendan Eich [mailto:bren...@secure.meer.net]
That is a false idol if it means no intermediate steps that explain some but
not all of the platform.
Sure. But I don't think the proposed type 2 encapsulation explains any of the
platform at all.
Are you sure?
On Jul 1, 2014, at 5:34 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: Edward O'Connor [mailto:eocon...@apple.com]
But soft encapsulation is just as useless for explaining the platform
as no encapsulation at all.
I think just as useless overstates your case. Type 2
From: Brendan Eich [mailto:bren...@secure.meer.net]
I don't even know what 3 means. Is it well defined, or just some utopia?
I think it is as well defined as 2 is. Both are really in terms of vague
requirements:
2. Widget libraries should be implementable without leaking implementation
On Tue, Jul 1, 2014 at 6:13 PM, Brendan Eich bren...@secure.meer.net wrote:
Domenic Denicola wrote:
From: Brendan Eich [mailto:bren...@secure.meer.net]
That is a false idol if it means no intermediate steps that explain
some but not all of the platform.
Sure. But I don't think the
Domenic Denicola wrote:
From: Brendan Eich [mailto:bren...@secure.meer.net]
I don't even know what 3 means. Is it well defined, or just some utopia?
I think it is as well defined as 2 is. Both are really in terms of vague
requirements:
2. Widget libraries should be implementable without
On Jul 1, 2014, at 3:26 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: Maciej Stachowiak m...@apple.com
Web Components as currently designed cannot explain the behavior of any
built-in elements (except maybe those which can be explained with CSS alone).
Unfortunately
[snip]
On Jul 1, 2014 10:07 PM, Maciej Stachowiak m...@apple.com wrote:
(3) A two-way membrane at the API layer between a component and a script;
approximately, this would be the Structured Clone algorithm, but extended
to also translate references to DOM objects between the worlds.
Has this
On 7/1/14, 9:16 PM, Ryosuke Niwa wrote:
I would love to hear from Mozillians if they have gotten enough developer
feedbacks
Our implementation is currently at a stage that can best be described as
not usable yet, which is most of the feedback we've gotten thus far. ;)
-Boris
On 7/1/14, 9:13 PM, Brendan Eich wrote:
Are you sure? Because Gecko has used XBL (1) to implement, e.g., input
type=file, or so my aging memory says.
We use XBL to implement marquee.
We do not use XBL to implement input type=file, though there was
once a project to do that sort of thing.
On 7/1/14, 11:20 PM, Brendan Eich wrote:
XBL can expose anonymous content via special API:
https://developer.mozilla.org/en-US/docs/XBL/XBL_1.0_Reference/DOM_Interfaces#getAnonymousNodes
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/XBL_Example
Boris Zbarsky wrote:
On 7/1/14, 9:13 PM, Brendan Eich wrote:
Are you sure? Because Gecko has used XBL (1) to implement, e.g., input
type=file, or so my aging memory says.
We use XBL to implement marquee.
Also video playback controls, per your next message.
We do not use XBL to implement
On 7/2/14, 12:15 AM, Brendan Eich wrote:
Boris Zbarsky wrote:
On 7/1/14, 9:13 PM, Brendan Eich wrote:
Are you sure? Because Gecko has used XBL (1) to implement, e.g., input
type=file, or so my aging memory says.
We use XBL to implement marquee.
Also video playback controls, per your next
23 matches
Mail list logo
