On Sat, Sep 19, 2015 at 5:19 PM, Cameron McCormack wrote:
> We could probably use the same mechanism that we do for restyling,
> effectively modelling any registered selector observers as an additional
> style sheet rule (that doesn’t have any properties set in it). All of
> the data we store in
On 10/09/2015 03:46 AM, zbranie...@mozilla.com wrote:
We're about to start working on another API for the next Firefox OS, this time
for DOM Intl, that will operate on `data-intl-format`,
`data-intl-value` and `data-intl-options`.
It would be much easier for us to keep l10n and intl separately
We're about to start working on another API for the next Firefox OS, this time
for DOM Intl, that will operate on `data-intl-format`, `data-intl-value` and
`data-intl-options`.
It would be much easier for us to keep l10n and intl separately and
independently, but in the current model we will ha
smaug:
> But in principle I think some kind of filtering would be nice.
> Implementing it for node removals would be a bit annoying in Gecko
> case (since our internal nsIMutationObserver::ContentRemoved happens
> after the removal) but it is doable. However it is unclear to me
> what kind of perfo
Reported: https://github.com/whatwg/dom/issues/77
zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 09/18/2015 06:30 AM, Zibi Braniecki wrote:
Hi,
One of the major use cases for MutationObserver is all kinds of libraries that
either shim APIs or provide intrinsic modifications to DOM experience.
Examples of such libraries may be:
* A library that provides Date/Time pickers only caring ab
6 matches
Mail list logo
