Re: Intent to ship: unicode-range
On Thu, Nov 19, 2015 at 5:16 PM, John Daggett wrote: > We intend to ship unicode-range in Firefox 44. It has been implemented for > non-Linux platforms for over a year now behind the > "layout.css.unicode-range.enabled" pref. The pref has been enabled by > default for Nightly and Developer builds but not for Beta and Release > builds. Once changes to Linux font handling have been enabled (bug > 1180560), this feature will now be available on all platforms. > > Safari, Internet Explorer and Chrome have all implemented this. However, > font loading behavior is not consistent across implementations. Safari and > Internet Explorer ignores the unicode-range value when deciding which fonts > to download. Firefox and Chrome only download those fonts for which the > unicode-range matches the characters used within content. > > Bug to enable unicode-range: 1119062 > > Spec definition: > CSS3 Fonts specification (CR) > http://www.w3.org/TR/css3-fonts/#unicode-range-desc Congratulations! One question that, the current nightly is Firefox 45, and I suppose you are not going to uplift the enabling bug, so you probably meant shipping in Firefox 45? - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Implement: HTML and tags
Summary: The is used as a disclosure widget from which the user can obtain additional information or controls. is used as a summary or legend of the details. To expand the details, the user could click on the summary or by adding a bool attribute 'open' to the details. An example: Open the example in Chrome or Safari. http://simpl.info/details/ Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=591737 Link to standard: https://html.spec.whatwg.org/multipage/forms.html#the-details-element Platform coverage: All platforms. Estimated or target release: Firefox 45 or 46. Preference behind which this will be implemented: No preference yet. Will add if needed. DevTools bug: None. Do other browser engines implement this: Implemented by Chrome and Safari. http://caniuse.com/#feat=details ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: HTML and tags
I'll give the same feedback here as I did for . I don't think authors will use this very much unless they can style it. In this case enabling styling might not actually be that hard either, so especially worth looking into. / Jonas On Thu, Nov 19, 2015 at 1:21 AM, Ting-Yu Lin wrote: > Summary: The is used as a disclosure widget from which the user > can > obtain additional information or controls. is used as a summary or > legend of the details. To expand the details, the user could click on the > summary or by adding a bool attribute 'open' to the details. > > An example: Open the example in Chrome or Safari. http://simpl.info/details/ > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=591737 > > Link to standard: > https://html.spec.whatwg.org/multipage/forms.html#the-details-element > > Platform coverage: All platforms. > > Estimated or target release: Firefox 45 or 46. > > Preference behind which this will be implemented: No preference yet. Will > add if needed. > > DevTools bug: None. > > Do other browser engines implement this: Implemented by Chrome and Safari. > http://caniuse.com/#feat=details > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Faster Windows builds on Try
Over the past months we've been working on migrating our Windows builds from the legacy hardware machines into Amazon. I'm very happy to announce that we've wrapped up the initial work here, and all our Windows builds on Try are now happening in Amazon. The biggest win from this is that our Windows builds are now nearly 30 minutes faster than they used to be. As of today, windows builds on try generally take around 50 minutes to complete, down from 1h20 before. Our next step is to migrate the non-try builds onto Amazon as well. Big thanks to Rob, Mark, and the rest of our Release Engineering and Operations team for making this possible! Cheers, Chris https://bugzilla.mozilla.org/show_bug.cgi?id=1199267 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster Windows builds on Try
This is the greatest! Thank you so much! On 19/11/2015 3:23 PM, Chris AtLee wrote: > Over the past months we've been working on migrating our Windows builds > from the legacy hardware machines into Amazon. > > I'm very happy to announce that we've wrapped up the initial work here, and > all our Windows builds on Try are now happening in Amazon. > > The biggest win from this is that our Windows builds are now nearly 30 > minutes faster than they used to be. As of today, windows builds on try > generally take around 50 minutes to complete, down from 1h20 before. Our > next step is to migrate the non-try builds onto Amazon as well. > > Big thanks to Rob, Mark, and the rest of our Release Engineering and > Operations team for making this possible! > > Cheers, > Chris > > https://bugzilla.mozilla.org/show_bug.cgi?id=1199267 > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: Changes to Worker performance.now() zero time
Summary: Currently for a dedicated worker, we set its 0 time for performance.now() purposes to the zero time of its parent worker or window. The spec defines a different behavior, now that there is a spec for this. Consumers that rely on the timebases matching right now can use translateTime instead. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1226147 Spec: http://w3c.github.io/hr-time/ Target release: 45 State in other UAs: Chrome plans to implement, unclear on the others. One of IE and Safari (can't recall which one) doesn't even implement performance.now() in workers. -Boris P.S. I'm not doing the impl work, just the paperwork. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: Performance.translateTime
Summary: A new method on Performance that allows translating a timestamp from one timeline to another. The idea is that you can take a performance.now() value or performance mark from some other global and convert them to the timeline of your global. It works like this: var myTime = Performance.translateTime(otherTime, otherGlobal); where otherGlobal is a Window, Worker, SharedWorker, or ServiceWorker. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1169068 Spec: http://w3c.github.io/hr-time/ Target release: 45 State in other UAs: Chrome plans to implement, unclear on the others. -Boris P.S. I'm not doing the impl work, just the paperwork. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Performance.translateTime
This API doesn't seem to work for nested workers (which Blink doesn't implement), does it? Since there's no way in the window to get hold of a reference of a sub-sub-worker. It also doesn't seem possible for a worker to convert to the timeline of a parent window, since there's no object representing the parent of a worker. / Jonas On Thu, Nov 19, 2015 at 2:11 PM, Boris Zbarsky wrote: > Summary: A new method on Performance that allows translating a timestamp > from one timeline to another. The idea is that you can take a > performance.now() value or performance mark from some other global and > convert them to the timeline of your global. It works like this: > > var myTime = Performance.translateTime(otherTime, otherGlobal); > > where otherGlobal is a Window, Worker, SharedWorker, or ServiceWorker. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1169068 > > Spec: http://w3c.github.io/hr-time/ > > Target release: 45 > > State in other UAs: Chrome plans to implement, unclear on the others. > > -Boris > > P.S. I'm not doing the impl work, just the paperwork. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Performance.translateTime
On 11/19/15 5:39 PM, Jonas Sicking wrote: This API doesn't seem to work for nested workers (which Blink doesn't implement), does it? Since there's no way in the window to get hold of a reference of a sub-sub-worker. While true, there is also no way to directly get a message from a sub-sub-worker, right? The only way to get one is via the intermediate worker. So you have a window create worker W1, W1 creates W2. W2 does something, posts a message back to W1 with some timestamps. W1 translates those into its timeline and posts message back to the window, which translates into its timeline. It also doesn't seem possible for a worker to convert to the timeline of a parent window, since there's no object representing the parent of a worker. That's true. If you want to ship timestamps from a window to a worker, there's no convenient way to do that, though you can hack it together like so: w.postMessage(myTimeStamp - Performance.translateTime(0, w)) It seemed to me when this was being discussed that typically your timestamps would flow the other way, but maybe that's a bad assumption? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: HTML and tags
On Fri, Nov 20, 2015 at 6:22 AM, Jonas Sicking wrote: > I'll give the same feedback here as I did for . > > I don't think authors will use this very much unless they can style it. This pair of tags has been widely used on the web. The first example is experimental CSS specs like https://drafts.csswg.org/css-backgrounds-4/ . The "Not Ready For Implementation" notice there is actually a / which is collapsible in Chrome and Safari, but doesn't work in Firefox. In addition, Drupal, a CMS framework which backs at least 2.1% of all websites worldwide (according to Wikipedia), has adopted these tags in version 8.0 which was released yesterday. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Performance.translateTime
On Thu, Nov 19, 2015 at 2:48 PM, Boris Zbarsky wrote: > On 11/19/15 5:39 PM, Jonas Sicking wrote: >> >> This API doesn't seem to work for nested workers (which Blink doesn't >> implement), does it? Since there's no way in the window to get hold of >> a reference of a sub-sub-worker. > > While true, there is also no way to directly get a message from a > sub-sub-worker, right? The only way to get one is via the intermediate > worker. You can actually create a MessageChannel and then send one of the ports to a sub-sub-worker. Unfortunately the other port can't be used as something that represents the sub-sub-worker since even after a port has started getting used, it can be sent around again. > So you have a window create worker W1, W1 creates W2. W2 does something, > posts a message back to W1 with some timestamps. W1 translates those into > its timeline and posts message back to the window, which translates into its > timeline. Yes, this is possible. It's not great, but it's probably a fine enough solution. >> It also doesn't seem possible for a worker to convert to the timeline >> of a parent window, since there's no object representing the parent of >> a worker. > > That's true. If you want to ship timestamps from a window to a worker, > there's no convenient way to do that, though you can hack it together like > so: > > w.postMessage(myTimeStamp - Performance.translateTime(0, w)) > > It seemed to me when this was being discussed that typically your timestamps > would flow the other way, but maybe that's a bad assumption? I suspect having a worker which takes care of coordinating network traffic to a server is likely to be a good design. Especially having a sharedworker or serviceworker take care of coordinating the network traffic if the website expects the user to have multiple tabs open. Though Service Workers do actually have a 'client' object which represent window objects. So we could enable passing those as global to the translate function. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: HTML and tags
On Thu, Nov 19, 2015 at 3:05 PM, Xidorn Quan wrote: > On Fri, Nov 20, 2015 at 6:22 AM, Jonas Sicking wrote: >> I'll give the same feedback here as I did for . >> >> I don't think authors will use this very much unless they can style it. > > This pair of tags has been widely used on the web. > > The first example is experimental CSS specs like > https://drafts.csswg.org/css-backgrounds-4/ . The "Not Ready For > Implementation" notice there is actually a / which > is collapsible in Chrome and Safari, but doesn't work in Firefox. > > In addition, Drupal, a CMS framework which backs at least 2.1% of all > websites worldwide (according to Wikipedia), has adopted these tags in > version 8.0 which was released yesterday. Cool. Maybe I was overly pessimistic. Though the first example here does seem to significantly style how the elements are rendered. I don't know if the second one does or not. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster Windows builds on Try
That's a great news. Hopefully Windows builds would no longer be a significant backlog anymore. On Fri, Nov 20, 2015 at 7:23 AM, Chris AtLee wrote: > Over the past months we've been working on migrating our Windows builds > from the legacy hardware machines into Amazon. > > I'm very happy to announce that we've wrapped up the initial work here, and > all our Windows builds on Try are now happening in Amazon. > > The biggest win from this is that our Windows builds are now nearly 30 > minutes faster than they used to be. As of today, windows builds on try > generally take around 50 minutes to complete, down from 1h20 before. Our > next step is to migrate the non-try builds onto Amazon as well. > > Big thanks to Rob, Mark, and the rest of our Release Engineering and > Operations team for making this possible! > > Cheers, > Chris > > https://bugzilla.mozilla.org/show_bug.cgi?id=1199267 > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster Windows builds on Try
On Fri, Nov 20, 2015 at 11:05:58AM +1100, Xidorn Quan wrote: > That's a great news. Hopefully Windows builds would no longer be a > significant backlog anymore. The backlog usually was for tests, not builds. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: HTML and tags
On Thursday 2015-11-19 11:22 -0800, Jonas Sicking wrote: > I'll give the same feedback here as I did for . > > I don't think authors will use this very much unless they can style it. There are some styling mechanisms in other browsers, but I don't think they are standardized, and I don't know if all the existing implementations of / have a way to style the disclosure triangle. I previously told Ting-Yu that whether we want to gate shipping / in order to get some form of styling implemented may depend on whether all of the existing implementations have a styling mechanism (and perhaps even on how consistent they are). Support for styling the disclosure triangle is covered by: https://bugzilla.mozilla.org/show_bug.cgi?id=1221416 -David -- š¯„˛ L. David Baron http://dbaron.org/ š¯„‚ š¯„¢ Mozilla https://www.mozilla.org/ š¯„‚ Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: HTML and tags
Jonas, Le 20 nov. 2015 Ć 04:22, Jonas Sicking a Ć©crit : > I don't think authors will use this very much unless they can style it. DetailsElement - 0.0856% https://www.chromestatus.com/metrics/feature/timeline/popularity/480 (features are at risk of removal for Chrome when below 0.03%) hope it helps. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Performance.translateTime
On 11/19/15 6:57 PM, Jonas Sicking wrote: You can actually create a MessageChannel and then send one of the ports to a sub-sub-worker. Ah, good point. Unfortunately the other port can't be used as something that represents the sub-sub-worker since even after a port has started getting used, it can be sent around again. Right. There's really no good solution here short of introducing something that represents an arbitrary worker to an arbitrary window or worker, right? That's unfortunate... Though Service Workers do actually have a 'client' object which represent window objects. So we could enable passing those as global to the translate function. That's a good idea. Want to raise it with the webperf WG? Seems like it wouldn't be that hard to implement. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: HTML and tags
On Thu, Nov 19, 2015 at 5:33 PM, Karl Dubost wrote: > Jonas, > > Le 20 nov. 2015 Ć 04:22, Jonas Sicking a Ć©crit : > > I don't think authors will use this very much unless they can style it. > > DetailsElement - 0.0856% > https://www.chromestatus.com/metrics/feature/timeline/popularity/480 > > (features are at risk of removal for Chrome when below 0.03%) > > hope it helps. > input=date seems clearly in that at-risk category--perhaps for the lack of styling that Jonas noted: https://www.chromestatus.com/metrics/feature/timeline/popularity/28 I expect we'll see more usage once all the browsers have it: http://caniuse.com/#feat=details BTW, please ensure that we avoid the known issues noted on that caniuse link. Nice job, Ting-Yu! --Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: unicode-range
> One question that, the current nightly is Firefox 45, and I suppose > you are not going to uplift the enabling bug, so you probably meant > shipping in Firefox 45? Plan is to uplift to aurora, so Firefox 44 is the intent. ā€‹ ā€‹ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
