Hi Gijs,
On Friday, June 10, 2016 at 2:49:16 AM UTC-7, Gijs Kruitbosch wrote:
> Mutation observers or mutation events? How do you decide which elements
> you observe? Observing the entire DOM tree seems like it'd likely be
> terrible for performance once we start mutating the DOM. Have you done
> any measurements on the performance of this approach when large amounts
> of DOM are inserted (ie not about:support :-) )? How do you decide on
> which documents you add these observers to?
We're using Mutation Observers, and we haven't observed (no punt intended) any
performance impact yet. We've been using them on the slowest devices that FxOS
has been designed for, and they performed surprisingly well.
While working on with Mutation Observers I tried to evaluate the potential to
optimize them to increase the signal/noise ratio of callbacks, and talked to
people like Olly and Anne about potential improvements that would work better
for our use case [0].
The general response to my questions was -
a) Seems like Microsoft's NodeWatch proposal [1]
b) They asked us to show them an example of where the current API is slow for
our use case and they'll help us develop a better one.
So far we failed to find a case where MutationObserver would have a noticable
negative impact on performance.
Would you by any chance know any piece of Firefox which does large amounts of
DOM insertions that we could test against?
> MutationObservers are async, and dtd localization in XHTML is currently
> synchronous on parsing. That seems like a large change that will cause a
> lot of problems relating to reflow / flashes of unlocalized content
> (keep in mind we use l10n data for style as well)
Correct. It's a major change.
Similarly to performance concerns, FOUCs are on our mind, and we've been
working on this technology initially targeting very slow devices. We've been
able to get no-FOUC experience so far, but we know it's not deterministic.
We're in a position similar to many other developers who want to use JS to
alter DOM before frame creation and layout happen. [2]
> , tests that expect synchronous changes as a result of actions
We'll have to fix the tests. Yes.
> , as well as issues where we would want the localized changes in elements
> that aren't in the page DOM (so constructed in JS, but not included in the
> DOM (yet)).
That's actually fairly well solved in our approach. By default localization
happens only when you inject your DOMFragment into DOM, but you can also
manually fire "translateFragment" which will do this on a disconnected fragment.
> You don't mention a JS/C++ API, which we need for e.g. strings we pass to
> message boxes or into the argument strings for
> about:neterror/about:certerror.
> What are your plans in that department?
Two fold.
First of all, we are planning a pure JS API. In fact, we have Node as our
target, which obviously doesn't use any DOM.
The API is not finalized, but it'll allow you to do the same thing you do in
DOM from JS:
var bundle = new LocalizationBundle([
'path/to/source1',
'path/to/source2'
]);
bundle.formatValue('entityId').then(val => console.log(val));
On top of that we'll probably provide some synchronous way to get the value, if
only for the compatibility mode, but we'll actively discourage using it, and
using it will make the code not benefit from the features of the framework.
Secondly, we'll be advocating people to move the localization to the front-end
of their code. Except of a few cases, there's no reason to localize a message
deep in your code, and carry a translated string around, while instead the
entityId should be carried around and resolved only in the UI.
> Less markup is better, so please don't wrap in more custom elements.
So, you're saying that:
<link href="./source1"> // implcit bundle 'main'
<link href="./source2"> // implicit bundle 'main'
<link l10n-bundle="menu" href="./source3">
<link l10n-bundle="menu" href="./source4">
is preferred over:
<l10n-bundle>
<source href="./source1">
<source href="./source2">
</l10n-bundle>
<l10n-bundle name="menu">
<source href="./source3">
<source href="./source4">
</l10n-bundle>
?
> It's not clear to me why we need a key/value object rather than a
> sequence as we use now. Perhaps just a semicolon-separated string with
> \; as an escape for literal ; ? That'd certainly be easier to read/write.
semicolon-separated string would be flat. Stringified JSON allows us to build
deeper structures.
We provide a wrapper API to facilitate that:
document.l10n.setAttributes(element, 'l10nId', {
user: {
'name': "John",
'gender': "male"
}
});
will assign data-l10n-id and data-l10n-args to the element, while
const {
l10nId,
l10nArgs
} = document.l10n.getAttributes(element);
handles the reverse.
> Otherwise, it also seems wrong to require the bundle name
> (data-l10n-bundle) on every localized element. The observer should be
> able to simply iterate through the stringbundles in declaration order
> until it finds a matching symbol.
It will iterate over sources in a single l10n-bundle.
In most cases, you will only have one l10n-bundle per document, so no need to
explicitly name it or refer to it.
If you want a separate another bundle, you have to name it and refer to it from
elements that are supposed to use it (instead of the main one).
> > * Is there a more canonical way to do this?
>
> Besides "use a DTD file"? Not that I'm aware of. Note that XUL also
> supports <stringbundle>, and I don't know if there isn't a reason to
> reuse those tag names.
Because our API is so fundamentally different and based on fundamentally
different paradigms that we would prefer not to attempt to reuse the same HTML
API.
We'll also live for a while in a world where old method and new co-exist, so
choosing different names allow us to live without conflicts.
> tpaint, ts_paint, sessionrestore, sessionrestore_no_auto_restore,
> tsvg-opacity, tart, cart
>
> (and their e10s equivalents, of course) would be my prime suspects. IIRC
> these come under "other,svgr" in try syntax, but trychooser can confirm
> this for you (hover over suites tells you what tests they run).
>
> See https://wiki.mozilla.org/Buildbot/Talos/Tests for descriptions,
> which also explains why I'm listing tsvg-opacity. :-)
Thanks! That's super helpful :)
zb.
[0]
https://groups.google.com/d/topic/mozilla.dev.platform/z4_iYqIAG-A/discussion
[1]
https://www.w3.org/2008/webapps/wiki/MutationReplacement#NodeWatch_.28A_Microsoft_Proposal.29
[2]
https://groups.google.com/d/topic/mozilla.dev.platform/F3Mp6dZonMA/discussion
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
