[chromium-dev] Re: Rewrite of DOMUI l10n strings
[now, from property email address]
+1 on creating a i18n mechanism that is distinct from JSTemplate.-1 on using
the same syntax (or at least the same directives) as JSTemplate.
First, I personally like JSTemplate and think it is well suited for doing
dynamic HTML composition (rather than building HTML fragments programaticaly
with the DOM api). It is used for composing the chrome://extensions/ page
and I support wider usage.
JSTemplate has a particularly nice property that a template is itself a
valid HTML fragment which means your template can remain valid HTML which
makes editing, maintaining and previewing it easy for both engineers and
designers. Most templates in other systems quickly end of a mess of %% %%,
{} or ! @@ @@ !. Additionally, because a template is valid html, it is
easy to prototype a template without having to evaluate it against live
data and have the template exist with reasonable sample data. [I realize
this is probably somewhat vague -- anyone who wants a more
detailed explanation, feel free to ping me].
However, because some of our existing pages use JSTemplate both for
injecting strings and for doing dynamic composition, the jst directives can
colide. Consider the following:
div jsselect=items
span jscontent=i18n_downloadDownload: /span span jscontent=url
http://www.some.com/.. http://www.some.com/./span
/div
In the above the i18n_download span is intended to be a localized string,
and the url is a part of dynamic composition of the based on run-time
state.
The problem with this is that it contains a i18n string replacement *and* a
page composition value within a select directive. The jst replacements that
take place during i18n injection and dynamic composition are going to
collide. The above code will most likely result in the Download text being
replaced by either or null.
It sounds like a C++ solution is being considered, but here are a few humble
suggestions for whatever gets implemented:
-Avoid having the HTML produced after the i18n string injection have any
artifacts of the i18n template directives.
-Attempt to retain JSTemplate's property of a template being a valid HTML
fragment
I'm unfamiliar with the hardships of localization mechanisms, but an obvious
suggestion is just to add another virtual JST directive called (i18n for
example), that behaves exactly like jscontent, but additionally removes the
element attribute after it's evaluation. So the above example would be
div jsselect=items
span i18n=downloadDownload: /span span jscontent=url
http://www.some.com/.. http://www.some.com/./span
/div
after injecting Spanish strings, it would be
div jsselect=items
spanDescarga: /span span jscontent=url
http://www.some.com/..http://www.some.com/
./span
/div
2009/7/8 Erik Arvidsson a...@chromium.org
I uploaded a CL of what I initially had in mind.
http://codereview.chromium.org/155245
I realized now that JST is used for non l10n templating so the name
needs to change. Still, I think this is such a small change with such
a big win that I want to continue down this path until we have some
solution for doing the templating on the front end.
2009/7/8 Jungshik Shin (신정식, 申政湜) js...@chromium.org:
2009/7/8 Erik Arvidsson a...@chromium.org
It seems like we want to do the string replacing in the front-end.
Does anyone have any experience with C++ l10n/template libraries that
we might want to use?
I don't have, but I just came across a few:
http://www.clearsilver.net/ (Apache license, C library, i18n support
is
explicitly mentioned)
http://teng.sourceforge.net/ (C++ library, LGPL)
http://www.lazarusid.com/libtemplate.shtml (claimed to be much simpler
than the two above. license unclear)
I'll also ask around.
Jungshik
On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote:
On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org
wrote:
Agree with Erik that it seems like we should share this code between
DOMUI and the extensions system.
(Erik Kay)
--
erik
--
erik
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
2009/7/9 Rafael Weinstein rafa...@chromium.org However, because some of our existing pages use JSTemplate both for injecting strings and for doing dynamic composition, the jst directives can colide. Consider the following: div jsselect=items span jscontent=i18n_downloadDownload: /span span jscontent=url http://www.some.com/.. http://www.some.com/./span /div In the above the i18n_download span is intended to be a localized string, and the url is a part of dynamic composition of the based on run-time state. The problem with this is that it contains a i18n string replacement *and* a page composition value within a select directive. The jst replacements that take place during i18n injection and dynamic composition are going to collide. The above code will most likely result in the Download text being replaced by either or null. Arv's patch doesn't have these problems. It uses a different set of directives for localization templating. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
I'm pursuing the js solution since it buys a performance boost in the
short term. It uses l10n-values and l10n-content which are almost
identical to jsvalues and jscontent except that it does not allow
arbitrary expressions.
I expect to send out a finished CL today.
2009/7/9 Rafael Weinstein rafa...@chromium.org:
[now, from property email address]
+1 on creating a i18n mechanism that is distinct from JSTemplate.
-1 on using the same syntax (or at least the same directives) as JSTemplate.
First, I personally like JSTemplate and think it is well suited for doing
dynamic HTML composition (rather than building HTML fragments programaticaly
with the DOM api). It is used for composing the chrome://extensions/ page
and I support wider usage.
JSTemplate has a particularly nice property that a template is itself a
valid HTML fragment which means your template can remain valid HTML which
makes editing, maintaining and previewing it easy for both engineers and
designers. Most templates in other systems quickly end of a mess of %% %%,
{} or ! @@ @@ !. Additionally, because a template is valid html, it is
easy to prototype a template without having to evaluate it against live
data and have the template exist with reasonable sample data. [I realize
this is probably somewhat vague -- anyone who wants a more
detailed explanation, feel free to ping me].
However, because some of our existing pages use JSTemplate both for
injecting strings and for doing dynamic composition, the jst directives can
colide. Consider the following:
div jsselect=items
span jscontent=i18n_downloadDownload: /span span
jscontent=url http://www.some.com/.../span
/div
In the above the i18n_download span is intended to be a localized string,
and the url is a part of dynamic composition of the based on run-time
state.
The problem with this is that it contains a i18n string replacement *and* a
page composition value within a select directive. The jst replacements that
take place during i18n injection and dynamic composition are going to
collide. The above code will most likely result in the Download text being
replaced by either or null.
It sounds like a C++ solution is being considered, but here are a few humble
suggestions for whatever gets implemented:
-Avoid having the HTML produced after the i18n string injection have any
artifacts of the i18n template directives.
-Attempt to retain JSTemplate's property of a template being a valid HTML
fragment
I'm unfamiliar with the hardships of localization mechanisms, but an obvious
suggestion is just to add another virtual JST directive called (i18n for
example), that behaves exactly like jscontent, but additionally removes the
element attribute after it's evaluation. So the above example would be
div jsselect=items
span i18n=downloadDownload: /span span
jscontent=url http://www.some.com/.../span
/div
after injecting Spanish strings, it would be
div jsselect=items
spanDescarga: /span span
jscontent=url http://www.some.com/.../span
/div
2009/7/8 Erik Arvidsson a...@chromium.org
I uploaded a CL of what I initially had in mind.
http://codereview.chromium.org/155245
I realized now that JST is used for non l10n templating so the name
needs to change. Still, I think this is such a small change with such
a big win that I want to continue down this path until we have some
solution for doing the templating on the front end.
2009/7/8 Jungshik Shin (신정식, 申政湜) js...@chromium.org:
2009/7/8 Erik Arvidsson a...@chromium.org
It seems like we want to do the string replacing in the front-end.
Does anyone have any experience with C++ l10n/template libraries that
we might want to use?
I don't have, but I just came across a few:
http://www.clearsilver.net/ (Apache license, C library, i18n support
is
explicitly mentioned)
http://teng.sourceforge.net/ (C++ library, LGPL)
http://www.lazarusid.com/libtemplate.shtml (claimed to be much simpler
than the two above. license unclear)
I'll also ask around.
Jungshik
On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote:
On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org
wrote:
Agree with Erik that it seems like we should share this code between
DOMUI and the extensions system.
(Erik Kay)
--
erik
--
erik
--
erik
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
Fantastic. I'll look forward to using it.
On Thu, Jul 9, 2009 at 1:52 PM, Erik Arvidsson a...@chromium.org wrote:
I'm pursuing the js solution since it buys a performance boost in the
short term. It uses l10n-values and l10n-content which are almost
identical to jsvalues and jscontent except that it does not allow
arbitrary expressions.
I expect to send out a finished CL today.
2009/7/9 Rafael Weinstein rafa...@chromium.org:
[now, from property email address]
+1 on creating a i18n mechanism that is distinct from JSTemplate.
-1 on using the same syntax (or at least the same directives) as
JSTemplate.
First, I personally like JSTemplate and think it is well suited for doing
dynamic HTML composition (rather than building HTML fragments
programaticaly
with the DOM api). It is used for composing the chrome://extensions/ page
and I support wider usage.
JSTemplate has a particularly nice property that a template is itself a
valid HTML fragment which means your template can remain valid HTML which
makes editing, maintaining and previewing it easy for both engineers and
designers. Most templates in other systems quickly end of a mess of %%
%%,
{} or ! @@ @@ !. Additionally, because a template is valid html, it is
easy to prototype a template without having to evaluate it against live
data and have the template exist with reasonable sample data. [I
realize
this is probably somewhat vague -- anyone who wants a more
detailed explanation, feel free to ping me].
However, because some of our existing pages use JSTemplate both for
injecting strings and for doing dynamic composition, the jst directives
can
colide. Consider the following:
div jsselect=items
span jscontent=i18n_downloadDownload: /span span
jscontent=url http://www.some.com/.../span
/div
In the above the i18n_download span is intended to be a localized
string,
and the url is a part of dynamic composition of the based on run-time
state.
The problem with this is that it contains a i18n string replacement *and*
a
page composition value within a select directive. The jst replacements
that
take place during i18n injection and dynamic composition are going to
collide. The above code will most likely result in the Download text
being
replaced by either or null.
It sounds like a C++ solution is being considered, but here are a few
humble
suggestions for whatever gets implemented:
-Avoid having the HTML produced after the i18n string injection have any
artifacts of the i18n template directives.
-Attempt to retain JSTemplate's property of a template being a valid HTML
fragment
I'm unfamiliar with the hardships of localization mechanisms, but an
obvious
suggestion is just to add another virtual JST directive called (i18n
for
example), that behaves exactly like jscontent, but additionally removes
the
element attribute after it's evaluation. So the above example would be
div jsselect=items
span i18n=downloadDownload: /span span
jscontent=url http://www.some.com/.../span
/div
after injecting Spanish strings, it would be
div jsselect=items
spanDescarga: /span span
jscontent=url http://www.some.com/.../span
/div
2009/7/8 Erik Arvidsson a...@chromium.org
I uploaded a CL of what I initially had in mind.
http://codereview.chromium.org/155245
I realized now that JST is used for non l10n templating so the name
needs to change. Still, I think this is such a small change with such
a big win that I want to continue down this path until we have some
solution for doing the templating on the front end.
2009/7/8 Jungshik Shin (신정식, 申政湜) js...@chromium.org:
2009/7/8 Erik Arvidsson a...@chromium.org
It seems like we want to do the string replacing in the front-end.
Does anyone have any experience with C++ l10n/template libraries that
we might want to use?
I don't have, but I just came across a few:
http://www.clearsilver.net/ (Apache license, C library, i18n
support
is
explicitly mentioned)
http://teng.sourceforge.net/ (C++ library, LGPL)
http://www.lazarusid.com/libtemplate.shtml (claimed to be much
simpler
than the two above. license unclear)
I'll also ask around.
Jungshik
On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote:
On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org
wrote:
Agree with Erik that it seems like we should share this code
between
DOMUI and the extensions system.
(Erik Kay)
--
erik
--
erik
--
erik
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). This may be separate to what you're looking for. On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote: This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). I'm not sure what you mean be embed the strings live so that they could be cached? This may be separate to what you're looking for. It was different from what I had in mind but maybe we should do the string injection on the front end instead of JS? What was the reason for doing it in JS in the first place? On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
What are the more advanced things that we use JST for? Off the top of my head, all I can think of is bulleted lists. I think we went with a JS solution because it seemed easier and safer at the time. I'm ok with doing string injection in the front end (i.e., a C++ HTML templating library), I'm just concerned about XSS. Is there a good existing library that would integrate well into chromium? On Wed, Jul 8, 2009 at 11:09 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote: This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). I'm not sure what you mean be embed the strings live so that they could be cached? This may be separate to what you're looking for. It was different from what I had in mind but maybe we should do the string injection on the front end instead of JS? What was the reason for doing it in JS in the first place? On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
I'm not sure what you mean be embed the strings live so that they could be cached? Sorry. For things like CSS, it's convenient that we do all the string injection in the backend so that the frontend can cache the result and not have to do any work the next time the resource is requested. This may allow us to further speed up the DOM pages. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
On Wed, Jul 8, 2009 at 11:13, Tony Changt...@chromium.org wrote: What are the more advanced things that we use JST for? Off the top of my head, all I can think of is bulleted lists. jsselect - which allows iteration. This is used for bulleted lists and the like eval/switch - this is used to allowed arbitrary JS expressions but it is only used inside jsselect at the moments. I think we went with a JS solution because it seemed easier and safer at the time. I'm ok with doing string injection in the front end (i.e., a C++ HTML templating library), I'm just concerned about XSS. Is there a good existing library that would integrate well into chromium? I'm not sure. I think a small js solution is something I can do in a day or two and it will buy us about 30ms on every DOMUI page. Any objections to me going ahead with my initial plan? On Wed, Jul 8, 2009 at 11:09 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote: This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). I'm not sure what you mean be embed the strings live so that they could be cached? This may be separate to what you're looking for. It was different from what I had in mind but maybe we should do the string injection on the front end instead of JS? What was the reason for doing it in JS in the first place? On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
This seems like a reasonable plan. It would be cool if whatever mechanism you chose could be leveraged by extensions as well (see the earlier extensions i18n proposal that was sent around last week). For this reason I'd prefer that if we moved to a C++ solution (as others in this thread have suggested) that it run in the renderer and not in the browser process (for security reasons). Erik On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidsson a...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
On Wed, Jul 8, 2009 at 11:29, Erik Kayerik...@chromium.org wrote: This seems like a reasonable plan. It would be cool if whatever mechanism you chose could be leveraged by extensions as well (see the earlier extensions i18n proposal that was sent around last week). For this reason I'd prefer that if we moved to a C++ solution (as others in this thread have suggested) that it run in the renderer and not in the browser process (for security reasons). I'll go back and reread that design doc to see how that might change things. On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidsson a...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
No objections from me-- a faster new tab page sounds great! A couple side goals to consider: - Maybe move this new js code into a pseudo protocol rather than appending the js blob into every html file. I think e.g., the devtools does this already. - It would be nice if this would some day completely replace jstemplate, but maybe that's not really worth the effort. On Wed, Jul 8, 2009 at 11:28 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:13, Tony Changt...@chromium.org wrote: What are the more advanced things that we use JST for? Off the top of my head, all I can think of is bulleted lists. jsselect - which allows iteration. This is used for bulleted lists and the like eval/switch - this is used to allowed arbitrary JS expressions but it is only used inside jsselect at the moments. I think we went with a JS solution because it seemed easier and safer at the time. I'm ok with doing string injection in the front end (i.e., a C++ HTML templating library), I'm just concerned about XSS. Is there a good existing library that would integrate well into chromium? I'm not sure. I think a small js solution is something I can do in a day or two and it will buy us about 30ms on every DOMUI page. Any objections to me going ahead with my initial plan? On Wed, Jul 8, 2009 at 11:09 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote: This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). I'm not sure what you mean be embed the strings live so that they could be cached? This may be separate to what you're looking for. It was different from what I had in mind but maybe we should do the string injection on the front end instead of JS? What was the reason for doing it in JS in the first place? On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
Ideally we would use an existing library instead of rolling our own. One major benefit of using existing code is that all the XSS holes will have been worked out already. Adam On Wed, Jul 8, 2009 at 11:36 AM, Tony Changt...@chromium.org wrote: No objections from me-- a faster new tab page sounds great! A couple side goals to consider: - Maybe move this new js code into a pseudo protocol rather than appending the js blob into every html file. I think e.g., the devtools does this already. - It would be nice if this would some day completely replace jstemplate, but maybe that's not really worth the effort. On Wed, Jul 8, 2009 at 11:28 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:13, Tony Changt...@chromium.org wrote: What are the more advanced things that we use JST for? Off the top of my head, all I can think of is bulleted lists. jsselect - which allows iteration. This is used for bulleted lists and the like eval/switch - this is used to allowed arbitrary JS expressions but it is only used inside jsselect at the moments. I think we went with a JS solution because it seemed easier and safer at the time. I'm ok with doing string injection in the front end (i.e., a C++ HTML templating library), I'm just concerned about XSS. Is there a good existing library that would integrate well into chromium? I'm not sure. I think a small js solution is something I can do in a day or two and it will buy us about 30ms on every DOMUI page. Any objections to me going ahead with my initial plan? On Wed, Jul 8, 2009 at 11:09 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote: This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). I'm not sure what you mean be embed the strings live so that they could be cached? This may be separate to what you're looking for. It was different from what I had in mind but maybe we should do the string injection on the front end instead of JS? What was the reason for doing it in JS in the first place? On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
I reread the thread and the design doc and it does not really cover when string replacements should happen. Doing a JST lite for l10n is something that can be used in extensions but I think the long term solution is to do this on the front end. On Wed, Jul 8, 2009 at 11:33, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:29, Erik Kayerik...@chromium.org wrote: This seems like a reasonable plan. It would be cool if whatever mechanism you chose could be leveraged by extensions as well (see the earlier extensions i18n proposal that was sent around last week). For this reason I'd prefer that if we moved to a C++ solution (as others in this thread have suggested) that it run in the renderer and not in the browser process (for security reasons). I'll go back and reread that design doc to see how that might change things. On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidsson a...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org wrote: Agree with Erik that it seems like we should share this code between DOMUI and the extensions system. (Erik Kay) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
On Wed, Jul 8, 2009 at 11:51, Adam Barthaba...@chromium.org wrote: Ideally we would use an existing library instead of rolling our own. One major benefit of using existing code is that all the XSS holes will have been worked out already. Replacing JST with something custom is something I am totally comfortable with. If we end up doing the string replacing on the front end I do agree that we should use some existing library since this is a much harder problem. Adam On Wed, Jul 8, 2009 at 11:36 AM, Tony Changt...@chromium.org wrote: No objections from me-- a faster new tab page sounds great! A couple side goals to consider: - Maybe move this new js code into a pseudo protocol rather than appending the js blob into every html file. I think e.g., the devtools does this already. - It would be nice if this would some day completely replace jstemplate, but maybe that's not really worth the effort. On Wed, Jul 8, 2009 at 11:28 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:13, Tony Changt...@chromium.org wrote: What are the more advanced things that we use JST for? Off the top of my head, all I can think of is bulleted lists. jsselect - which allows iteration. This is used for bulleted lists and the like eval/switch - this is used to allowed arbitrary JS expressions but it is only used inside jsselect at the moments. I think we went with a JS solution because it seemed easier and safer at the time. I'm ok with doing string injection in the front end (i.e., a C++ HTML templating library), I'm just concerned about XSS. Is there a good existing library that would integrate well into chromium? I'm not sure. I think a small js solution is something I can do in a day or two and it will buy us about 30ms on every DOMUI page. Any objections to me going ahead with my initial plan? On Wed, Jul 8, 2009 at 11:09 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote: This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). I'm not sure what you mean be embed the strings live so that they could be cached? This may be separate to what you're looking for. It was different from what I had in mind but maybe we should do the string injection on the front end instead of JS? What was the reason for doing it in JS in the first place? On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik -- erik -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
It seems like we want to do the string replacing in the front-end. Does anyone have any experience with C++ l10n/template libraries that we might want to use? On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote: On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org wrote: Agree with Erik that it seems like we should share this code between DOMUI and the extensions system. (Erik Kay) -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
2009/7/8 Erik Arvidsson a...@chromium.org It seems like we want to do the string replacing in the front-end. Does anyone have any experience with C++ l10n/template libraries that we might want to use? I don't have, but I just came across a few: http://www.clearsilver.net/ (Apache license, C library, i18n support is explicitly mentioned) http://teng.sourceforge.net/ (C++ library, LGPL) http://www.lazarusid.com/libtemplate.shtml (claimed to be much simpler than the two above. license unclear) I'll also ask around. Jungshik On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote: On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org wrote: Agree with Erik that it seems like we should share this code between DOMUI and the extensions system. (Erik Kay) -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
I uploaded a CL of what I initially had in mind. http://codereview.chromium.org/155245 I realized now that JST is used for non l10n templating so the name needs to change. Still, I think this is such a small change with such a big win that I want to continue down this path until we have some solution for doing the templating on the front end. 2009/7/8 Jungshik Shin (신정식, 申政湜) js...@chromium.org: 2009/7/8 Erik Arvidsson a...@chromium.org It seems like we want to do the string replacing in the front-end. Does anyone have any experience with C++ l10n/template libraries that we might want to use? I don't have, but I just came across a few: http://www.clearsilver.net/ (Apache license, C library, i18n support is explicitly mentioned) http://teng.sourceforge.net/ (C++ library, LGPL) http://www.lazarusid.com/libtemplate.shtml (claimed to be much simpler than the two above. license unclear) I'll also ask around. Jungshik On Wed, Jul 8, 2009 at 12:00, Aaron Boodmana...@chromium.org wrote: On Wed, Jul 8, 2009 at 12:00 PM, Aaron Boodmana...@chromium.org wrote: Agree with Erik that it seems like we should share this code between DOMUI and the extensions system. (Erik Kay) -- erik -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
