On 24/06/14 16:35, Anne van Kesteren wrote:
No, no more indexed getters. You should know!
Yes hence the "something similar". :-) Was just easiest for working
with while implementing. Making the object iterable seems like the
right thing to do, but our bindings generation scripts don't handl
On Tue, Jun 24, 2014 at 2:02 AM, Cameron McCormack wrote:
> No. There's a note in the spec that says [SetClass] will be removed in
> favour of members on the interface that feel like a Set, but there's nothing
> concrete in there yet. I'm proceeding with something simple for the moment
> (add, h
On Mon, Jun 23, 2014 at 5:02 PM, Cameron McCormack wrote:
> On 24/06/14 06:30, Jonas Sicking wrote:
>>
>> Has the [MapClass] issue been resolved yet?
>
> No. There's a note in the spec that says [SetClass] will be removed in
> favour of members on the interface that feel like a Set, but there's n
On 24/06/14 11:10, Robert O'Callahan wrote:
Instead I think we should focus on extending HTML and making it
easier to use from SVG, e.g. by eliminating the need to wrap it in
.
This is another argument for going forward with
http://dev.w3.org/SVG/proposals/improving-svg-dom/ (at least the
na
See the thread in www-svg starting here:
http://lists.w3.org/Archives/Public/www-svg/2014Jun/0063.html
For the reasons mentioned in that thread, I'm against adding SVG elements
like that duplicate existing HTML elements, and I'm not the only
one.
Instead I think we should focus on extending HTML
Many of you may have seen the earlier add-on "file registration" and
signing discussions. I have posted a revised proposal that requires all
add-ons to be signed (AMO-hosted add-ons will be signed automatically)
to the mozilla.addons.user-experience group/list.
If you're interested in this top
Summary:
We are implementing SVG iframe element. It introduces the function that is
almost equivalent to 'iframe' element of html5.0 into svg. Except for any
SVG-specific rules explicitly mentioned in this specification.
It allows dynamic loading and embedding of browsing contexts into svg.
Beca
On 24/06/14 06:30, Jonas Sicking wrote:
Has the [MapClass] issue been resolved yet?
No. There's a note in the spec that says [SetClass] will be removed in
favour of members on the interface that feel like a Set, but there's
nothing concrete in there yet. I'm proceeding with something simple
Has the [MapClass] issue been resolved yet?
/ Jonas
On Fri, Jun 20, 2014 at 11:47 PM, Cameron McCormack wrote:
> Summary: The CSS Font Loading API provides a mechanism for authors to load a
> font from the network that can then be used from the font-family property.
> This allows control over wh
The next MemShrink meeting will be brought to you by LeakSanitizer now running
on TBPL Mochitests:
https://bugzilla.mozilla.org/show_bug.cgi?id=988041
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Prioritize unprioritized MemShrink bugs.
* Disc
Yes, please!
Cross-posting to B2G-Internal as we've been discussing font loading hacks on a
separate thread re: icon fonts. This font loading API should help.
Thanks,
--Jet
- Original Message -
From: "Cameron McCormack"
To: dev-platform@lists.mozilla.org
Sent: Friday, June 20, 2014 11
Bug 1020919 has been pushed to production, meaning that for TBPL pages
displaying just a single Try-server push - eg:
https://tbpl.mozilla.org/?tree=Try&rev=4ffa00b643cb
The tab title is now:
"[0] Description derived from commit message - Try - TBPL"
...so that those of you with multiple try pu
Low level USB API, I think it is one of the scalable idea that connect browser
with USB devices.
But for the MIDI, I think there is one big problem, which is "latency".
In general it is said that our ears can detect 20 msec of latency.
So if using low level USB API including MIDI, that API must g
13 matches
Mail list logo
