Re: Intent to implement and ship: built-in CSS counter 'list-item'

On Wednesday 2019-03-27 01:42 +0100, Mats Palmgren wrote: > FYI, the CSS Lists spec isn't very well maintained, sadly, > so it's not up-to-date with recent resolutions. So, some > of the finer details in there might be wrong, but I think > most of it regarding counters is correct. If you've been

Re: Intent to implement and ship: built-in CSS counter 'list-item'

On 3/27/19 12:30 AM, Domenic Denicola wrote: (On-list this time) However, the actual semantics for how list items work are exclusively defined by CSS ([css-lists], [css-pseudo]). The above mentioned HTML elements/attributes simply maps to the relevant CSS properties, using a built-in 'list-item

Re: Intent to implement and ship: built-in CSS counter 'list-item'

(On-list this time) > However, the actual semantics for how list items work are exclusively defined > by CSS ([css-lists], [css-pseudo]). > The above mentioned HTML elements/attributes simply maps to the relevant CSS > properties, using a built-in 'list-item' counter. Where does [css-lists] an

Re: Intent to implement and ship: built-in CSS counter 'list-item'

On 3/25/19 6:21 AM, Domenic Denicola wrote: > The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item > seems to contradict that hard-fought consensus. It seems like a > regression to implement list item numbering according to that spec, > instead of according to HTML. As others hav

Re: Intent to implement and ship: built-in CSS counter 'list-item'

Note that the spec does not yet reflect the decisions made at the last F2F, or the subsequent decisions from Issues. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: built-in CSS counter 'list-item'

On Tuesday 2019-03-26 14:25 -0700, Domenic Denicola wrote: > It's great to hear that this isn't a regression in the way I expected. I > think I was thrown off by the phrasing of the OP, which implied to me a > switch from following the HTML spec to following the CSS lists spec. As I > noted, the

Re: Intent to implement and ship: built-in CSS counter 'list-item'

It's great to hear that this isn't a regression in the way I expected. I think I was thrown off by the phrasing of the OP, which implied to me a switch from following the HTML spec to following the CSS lists spec. As I noted, the CSS lists spec contradicts the HTML spec, e.g. disallowing reverse

Re: Intent to implement and ship: built-in CSS counter 'list-item'

On Sunday 2019-03-24 22:21 -0700, Domenic Denicola wrote: > Some time ago we spent some effort documenting a cross-browser > mostly-interoperable behavior for list-item-like behaviors, in > https://github.com/whatwg/html/pull/2002 and linked threads. The result is > the spec at > https://html.s

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

Hi Philip: 1) Yes 2) I think so -- it's clearly had substantial refactoring in the process of moving to Web Authentication 3) I think that's the one, but most sites redistribute a much older version that used to be served by gstatic.com (I can't find it now) archived here: https://github.com/fido-

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

On Tue, Mar 26, 2019 at 3:46 PM J.C. Jones wrote: > (Sorry for the delay in replying, had a long-weekend of PTO there) > > On Thu, Mar 21, 2019 at 7:08 AM Henri Sivonen > wrote: > > > On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones wrote: > > > It appears that if we want full security key support fo

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

(Sorry for the delay in replying, had a long-weekend of PTO there) On Thu, Mar 21, 2019 at 7:08 AM Henri Sivonen wrote: > On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones wrote: > > It appears that if we want full security key support for Google > > Accounts in Firefox in the near term, we need to gr

Re: Shippable Builds Incoming...

Yes it does, I'm currently looking at a good way to improve mozregression ASAP, which has been partially broken since the opt->pgo work mentioned above. This is tracked in 1532412 and whatever solution we get there should be translatable for s

Re: Shippable Builds Incoming...

Will the change to taskcluster indexes affect mozregression? On Tue, Mar 26, 2019 at 2:56 PM Justin Wood wrote: > > Hey Everyone, > > tl;dr I landed "shippable builds" [1] to autoland, and I'll assume it > sticks. This replaces Nightly and PGO for most job types for desktop jobs. > Expect to see

Shippable Builds Incoming...

Hey Everyone, tl;dr I landed "shippable builds" [1] to autoland, and I'll assume it sticks. This replaces Nightly and PGO for most job types for desktop jobs. Expect to see tests and builds in treeherder reflecting this, and no longer seeing most PGO platforms or Nightly platforms available for y

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

On Mon, Mar 25, 2019 at 10:05 PM wrote: > > As far as separating the value; it kind of depends on how you > > implement it; but let's say you were going to use a static uint64_t or > > something like that. Instead of heaving a static uint64_t, create a > > Dictionary and look up the uint64_t usin

Re: Intent to implement and ship: built-in CSS counter 'list-item'

On 25/03/2019 06:21, Domenic Denicola wrote: > Some time ago we spent some effort documenting a cross-browser > mostly-interoperable behavior for list-item-like behaviors, in > https://github.com/whatwg/html/pull/2002 and linked threads. The result is > the spec at > https://html.spec.whatwg.or

[ANN] In-tree helper crates for Rust XPCOM components

Hi all, Last year, Nika Layzell landed support for implementing XPCOM components in Rust [1]. Since then, folks on different teams have been adding components, and working out some common patterns. There are now several in-tree helper crates that provide more idiomatic wrappers for these patterns,