I understand the proposal, and am suggesting that having content
scripts might be a saner thing to do if they need to do less custom
stuff to get the job done. The API that locates the stuff could be
separate, but the transformation code feels like a natural content-
script task and one that I'd be pained to see another (parallel) API
for.
Regards
On Jun 1, 2009, at 6:14 PM, Erik Kay wrote:
> This proposal is specifically not to fix the DOM, but to exist
> outside of it without having to inject scripts into the page.
>
> Erik
>
>
> On Mon, Jun 1, 2009 at 4:33 PM, Alex Russell <a...@dojotoolkit.org>
> wrote:
> On Jun 1, 2009, at 12:00 PM, Erik Kay wrote:
>
> Similar to the translate, this feature could be used to support
> sites that use non-standard character set / font combinations (some
> indic websites depend on downloadable fonts and custom character
> sets).
>
> Also, if the API allowed styling of the text as opposed to just
> replacing it, then I could imagine that it could be used for
> interesting markup / highlighting (highlighting searched words,
> marking up grammar errors, auto-likifying, etc.). Perhaps this
> would defeat part of the point of this approach to an API.
>
> I guess I keep getting hung up on why this isn't execCommand() on a
> range. The hard bit is finding the text to "range-ify", and I think
> that bit might make sense as a new API, but in terms of actually
> transforming things, ISTM that we should go fix the DOM where isn't
> not good enough (yet).
>
> Regards
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
