On Wed, Jul 8, 2009 at 11:51, Adam Barth<[email protected]> 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 Chang<[email protected]> 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 Arvidsson<[email protected]> wrote: >>> On Wed, Jul 8, 2009 at 11:13, Tony Chang<[email protected]> 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 Arvidsson<[email protected]> wrote: >>>>> On Wed, Jul 8, 2009 at 11:05, Glen Murphy<[email protected]> 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 Arvidsson<[email protected]> 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
