Re: Proposal: Not shipping prefixed APIs on the release channel
On Tue, Dec 11, 2012 at 9:44 AM, Randell Jesup wrote: > I'm ok with it, Great! > but I think it may be insufficient to avoid problems. It turned out to be harder to get agreement on the part whose purpose was to avoid problems: the part about not shipping experimental stuff on the release channel. > One could argue if we're going to try to push everyone to move off the > current prefixing, let's do it once. If WebGL and WebRTC don’t want to be pushed now, I’d rather stop vendor prefixing for everything else and let WebGL and WebRTC to come round at their own pace than see this proposal sink because of WebGL or WebRTC concerns. (WebGL and WebRTC living in their own worlds isn’t quite safe, though, because they can leak. For example, we have WebGL to blame for making the Web platform dependent on little-endian hardware. Or maybe the real blame should go to TC39 for not giving WebGL something better in a timely fashion.) > Are Google, MS and Apple (and Opera) on-board > with this? If we require everyone to move in unison, we’ll never make progress. Someone needs to make the first move and others will follow if the CSS situation is any indicator. Previous discussions make me expect Opera and Google to be the most likely vendors to follow us soon if we stop shipping vendor prefixes. > Versioning might be best reserved for > more-complex-than-average APIs and ones where people want to do > cross-browser experimentation (pre-release). Considering that versioning has been an anti-pattern on the Web in general[1], I think we should wait and see how versioning works for WebRTC before doing it more broadly. (My general expectation is that it’s bad to introduce APIs in such more-complex-than-average chunks that the need for versioning arises.) [1] HTML tried to version itself but browsers ingest all versions using the same code. Likewise for SVG. On the other hand, XML tried to version itself but coupled versioning with such a disastrous error handling policy that their 1.1 launch flopped. JS versioning is virtually unused on the Web (as opposed to Firefox-internal code). CSS has been wisely designed as versionless from the processing point of view. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Synchronous loading of data: URLs
Neil wrote: Jonathan Kew wrote: You shouldn't normally see a flash of fallback text unless the font is particularly slow to load; the text should be invisible until the font is available. We aim to hide the text until the font is ready, unless it takes more than a few seconds to load. (The timeout is configurable - see gfx.downloadable_fonts.fallback_delay - so if you've set it lower than the default of 3000ms, you'll see visible fallback more frequently.) This is a debug build on a machine with an IDE disk, so it's possible it might be taking more than three seconds to load the font. I'll try tweaking the delay to see whether it helps. Increasing the preference to 1 made no difference. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Synchronous loading of data: URLs
On 11/12/12 10:51, Neil wrote: Neil wrote: Jonathan Kew wrote: You shouldn't normally see a flash of fallback text unless the font is particularly slow to load; the text should be invisible until the font is available. We aim to hide the text until the font is ready, unless it takes more than a few seconds to load. (The timeout is configurable - see gfx.downloadable_fonts.fallback_delay - so if you've set it lower than the default of 3000ms, you'll see visible fallback more frequently.) This is a debug build on a machine with an IDE disk, so it's possible it might be taking more than three seconds to load the font. I'll try tweaking the delay to see whether it helps. Increasing the preference to 1 made no difference. Could you give an example of a page where you see this happening? I wonder if it's doing something like inserting the stylesheet dynamically after the page has initially loaded. JK ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Synchronous loading of data: URLs
On Wed, Dec 5, 2012 at 5:37 AM, John Daggett wrote: > Fonts are loaded when used so font loading won't start until the > contents using a particular font are laid out. That seems like a problem for JS-driven display. A big problem in the canvas case and at least an annoyance when a JS program drives the input to CSS layout. > This optimization simply eliminates the extra reflow required by spinning the > event > loop. That makes sense. However, it’s still not nice for data: to be magic for the JS-driven case. For JS-driven cases, I think the platform really needs an async API that lets a JS program say “start loading this font now” and then some callback for getting notified asynchronously (regardless of URL scheme) when the font has been loaded so that it is ready for use with canvas or ready for use with CSS without a flash of unfontified content. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Synchronous loading of data: URLs
On 11/12/12 12:18, Henri Sivonen wrote: On Wed, Dec 5, 2012 at 5:37 AM, John Daggett wrote: Fonts are loaded when used so font loading won't start until the contents using a particular font are laid out. That seems like a problem for JS-driven display. A big problem in the canvas case and at least an annoyance when a JS program drives the input to CSS layout. This optimization simply eliminates the extra reflow required by spinning the event loop. That makes sense. However, it’s still not nice for data: to be magic for the JS-driven case. For JS-driven cases, I think the platform really needs an async API that lets a JS program say “start loading this font now” and then some callback for getting notified asynchronously (regardless of URL scheme) when the font has been loaded so that it is ready for use with canvas or ready for use with CSS without a flash of unfontified content. This sounds like what Font Load events and the FontLoader interface[1] are trying to address. I think that spec is still some way from being stable and ready to implement, though. JK [1] http://dev.w3.org/csswg/css3-fonts/#font-load-events ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Snappy Meeting, Thurs Dec 13, 11am PT (new Vidyo room)
The Snappy meeting is held bi-weekly to discuss issues with Firefox responsiveness and the various responsiveness initiatives that are underway. This week is a Snappy meeting ON week. Please add your items and status to the agenda before the meeting. https://etherpad.mozilla.org/snappy Dial-in: conference# 99355 US/International: +1 650 903 0800 x92 Conf# 99355 US toll free: +1 800 707 2533 (pin 369) Conf# 99355 Canada: +1 416 848 3114 x92 Conf# 99355 Vidyo: Performance Vidyo Guest URL: https://v.mozilla.com/flex.html?roomdirect.html&key=SxuriCZcSSNL IRC: #perf Lawrence ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Synchronous loading of data: URLs
On 12/11/12 7:18 AM, Henri Sivonen wrote: On Wed, Dec 5, 2012 at 5:37 AM, John Daggett wrote: Fonts are loaded when used so font loading won't start until the contents using a particular font are laid out. That seems like a problem for JS-driven display. It's also the only way to avoid loading tons of unnecessary font data that sites link to. Note also that the spec has ways of specifying different fonts for different Unicode character ranges, so you literally don't know which fonts you need until you know what characters you're trying to deal with... A big problem in the canvas case There are APIs being added to handle the canvas case, yeah. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink meeting today: 12/11/2012 @ 2:00pm PST
This week's MemShrink meeting will be brought to you by Dark Matter: https://wiki.mozilla.org/Performance/MemShrink/DMD The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * 64-bit Windows Builds Update * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progress. * Discuss approaches to getting more data. Meeting details: * Tue, Dec 11, 2012, 2:00 PM PST * SFO-7N Noise Pop, San Francisco office, 7th floor. * Dial-in Info: - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 95346 -- Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
