I finally made it work. The missing piece in the puzzle: a reflow. The overlay (or overlayElement) function correctly dissassembles the svg, and reassembles it. But a reflow is triggered just once, when the svg has no image info. If you are sanitizing the following (with everything allowed):
<svg...><g...><rect...>This browser does not show svg</svg> a reflow is triggered when the svg element is copied, but before the children (g, rect, circle,...) are added: <svg...>This browser does not show svg</svg> And never again. So, you end up having a correct svg in DOM, but it will be rendered as "This browser does not show svg" unless you force a reflow. That was it. I'm not sure if I should file a bug against Gecko, maybe that is the desired/correct behaviour for an svg. On 2016-01-06 21:53, Eduardo Trápani wrote: > Thanks Staś! I didn't even know there was a l20n.js. You saved me a lot > of time! > > I added svg, and g and rect as elements, and then the list of allowed > attributes for each one. It works *sometimes*. After the > dissassembly/assembly of the svg element (while sanitizing) something > happens with Gecko. If it doesn't work, sometimes it's enough to go to > the inspector and touch a property, and then it redraws ok. > > So now I'm trying to figure out why it works without a glitch for > 'no-contacts' (apps/communications/contacts/contacts.properties) and it > doesn't ever work for 'contacts' (the application title, in the same > file). And it sometimes works inside settings only if I manually modify > attributes in Inspector. > > The user case: it's a script that has a complex text layout[1]. I made > it work[2] using innerHTML in the gaia code around 2.2. But the > conversion from the preferred textual form (FSW[3], an ASCII string) to > the graphic representation (SVG) was done by an external webservice and > I had to modify l10n.js more than I would've liked to. > > Now I'm trying to code the necessary pieces so that they play nicely and > non-intrusively with the current gaia at master. Something I could > actually do a pull request for, sometime in the future. Some sign > languages already have a lot of literature and being able to localize > the phone would be very good, for many reasons. The script is meant to > accomodate all sign languages. > > I moved the FSW->SVG conversion to the build process (no lag and no need > for internet connection) and now all I need is the device to correctly > show the SVG, hacking as little as possible (not resorting to innerHTML > again). Once that's done, translators could use FSW, which is very > convenient because there's already a javascript viewer that would show > the sign, even if using, let's say, Transvision. Or they could use SVG > directly, though I guess that would not be as comfortable (just think of > a string with parameters) and it could not play as well with existing tools. > > [1] https://en.wikipedia.org/wiki/SignWriting > [2] https://vimeo.com/137097242 > [3] http://tools.ietf.org/html/draft-slevinski-signwriting-text-05#section-2 > > On 2016-01-05 07:04, Staś Małolepszy wrote: >> Hi Eduardo -- >> >> The sanitization of translations happens in the overlayElement function here: >> >> https://github.com/bidaian/gaia/blob/78b2bc4cad3fcf83cbbbe4aeb77079cf956972cf/shared/js/l10n.js#L2018 >> >> and uses the list of allowed elements defined here: >> >> https://github.com/bidaian/gaia/blob/78b2bc4cad3fcf83cbbbe4aeb77079cf956972cf/shared/js/l10n.js#L1527-L1548 >> >> If your goal is just to play around and experiment, you can edit this >> list locally and <svg> should work, I think. Keep in mind, however, >> that some apps use shared/js/intl/l20n.js so make sure you're editing >> the right file. >> >> I'm curious, what's the use-case for putting SVG inside of a localized >> message? >> >> Best, >> -stas >> >> On Mon, Jan 4, 2016 at 11:24 PM, Eduardo Trápani <[email protected]> wrote: >>> Hi, >>> >>> I know it's a bad idea[1], but for a project in my development device I >>> need to put an SVG inside a localized message. >>> >>> The thing is, all HTML is being stripped and I cannot find where that >>> happens in the code. I thought it would be around here[2], but at that >>> time no HTML is left in the value. I've been building and using >>> console.log for a while now ... >>> >>> I do understand the code is meant NOT to let me insert arbitrary HTML >>> :). In spite of that, could somebody tell me where the actual stripping >>> takes place? >>> >>> In the index.ab.json for the application the entry is something like >>> {..."entry": "hello <svg...</svg> world!"...} and all the quote >>> characters are escaped). The result on the device is simply "hello world!". >>> >>> Thanks, Eduardo. >>> >>> [1] https://github.com/bidaian/gaia/blob/master/shared/js/l10n.js#L1987 >>> [2] https://github.com/bidaian/gaia/blob/master/shared/js/l10n.js#L1962 >>> >>> _______________________________________________ >>> dev-fxos mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-fxos _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
