Only the problem was a bit different, I wanted to be able to select a section of a blog post to generate a url fragment representing that selection, so, if you shared it, that section would be highlighted when entering the page, but the underlying problem is the same, example:
That's actually Really cool. Looks like you hacked it to do it positionally. What is the 9-1? I'm assuming that last bit is the range in a Dom content substring
The 9-1 is the node hierarchy needed to find out where to start the highlighting, it's something like look for the 10nth child and then find the second child of that element (zero based index).
If you have a more complex markup it becomes apparent, for example, if you selected something inside <p><span></span><strong><em>Text</em></strong></p> it would look like 0-1-0-0
The last part is exactly what you suggested, it's just the dom content substring.
Another thing that it's not evident is that the selected text can transverse trough html elements, for example, start inside a span and end outside that span.
Sadly that blog is not under my control, maybe i should try to blow the dust off that code and make a sample page.
I getcha.cthe code will work if the blog author changes the layout still? That is, the children aspect works and doesn't need to be tweaked for each layout and works for all correct HTML?
That said, if it's a Wordpress blog or something and the layout changes any existing links might not work.
Did you try encoding the text you want to highlight (and maybe the ordered instance) and then have the code search for it? I figure this might be less straight forward though as you'd need to strip HTML tags, find the text, and translate that back into modified Dom which could break many things.
The code looks for the post container element, so, if the layout is changed you would need to change at most just the parent css selector, and old links would still be working, but would stop working if the post is edited, i.e. a new paragraph was added.
It wouldn't be a problem to encode the selected text and look for it, actually that's how the selecting works, i get the selected text and look for it on the document,striping html tags and finding all the elements which contains part of the selected string, only then i enconde the relative position on the dom tree of the node to be able to look for it later (The 9-1 stuff).
The problem with encoding the text is that the url could get pretty long pretty easily, but that could be solved if the server stored it and you got only a hash to look it up, that would have the benefit of the highligting links to keep working if the post is edited partially.
This doesn't solve the cross-element-boundary problem though. If a match starts in one element but ends in another this plugin doesn't seem to replace it at all.
Oddly enough, I was working on a similar problem earlier today.
I've found that collecting the Text nodes and returning them in an Array is preferable. All it requires is some simple traversal. The developer (that should know what text goes where) can then map text to nodes.
One of the reasons not to use the innerHTML prop is because (almost) all interactivity gets broken; for example a CSS3 animation restarts if you set innerHTML of one of its parent elements.
Another reason is because IE (even the 9) likes to delete white-spaces when you set innerHTML; even in PRE tags!
Only the problem was a bit different, I wanted to be able to select a section of a blog post to generate a url fragment representing that selection, so, if you shared it, that section would be highlighted when entering the page, but the underlying problem is the same, example:
http://gnozin.com/sobremesa/2012/07/02/buena_venta/#highligh...