Blast text apart to make it manipulable.

Blast treats spaces between words as non-characters. This causes the character delimiter to return improper indexes. Because of this, lining up character index data with blast's generated blast-indexes is very difficult.

There should be an option to treat whitespace as characters in order to maintain the actual index of characters from start to finish in a string of text.

By the way... this could be handled simply (I think) by adding a "preserveWhitespace" option that would only apply to characters. Then, you could do this inside the delimiter creation section:

case "character":
                /* Matches every non-space character. */
                /* Note: This is the slowest delimiter. However, its slowness is only noticeable when it's used on larger bodies of text (of over 500 characters) on <=IE8.
                   (Run Blast with opts.debug=true to monitor execution times.) */
                if (opts.preserveWhitespace)
                    delimiterRegex = /(.)/;
                else
                    delimiterRegex = /\S/;
                break;

I don't know if "." is the best way to do this. Perhaps it should only preserve the actual space character.

As a sidenote, to render properly you would need to give white-space: pre|pre-line|pre-wrap to the blasted element to make the spaces not collapse in their own HTML elements.

@julianshapiro , did you consider any of this during initial development?

Hey, I've noticed a problem when you try to use the same function twice on 2 divs with the same class. I've made a demo on codepen here, illustrating the problem. The function only works on the last div.

http://codepen.io/sdras/pen/8d7f8116818ec9ec00f8f82be65838d5

I forked your demo on delimiters, just so that we know for sure I'm using versions of jquery, velocity, velocity ui, and blast that do work in isolation.

With this, there's an option for not modifying the DOM if we only want to retrieve the text but not to manipulate the HTML. In this way the operation is much less expensive than wrapping each of the elements with another one.

Bumped to V2.1.0 according to semver (added functionality in a backwards-compatible manner)

Fix #12

When a first name is abbreviated, the library doesn't normally catch it. A good solution might be to add the following regex as an exception for this case:

[A-Z][a-z]*\.\ [A-Z]

In action: Regex101.com

It accounts for all the instances of F. Presencia or similar first names abbreviations.

Here a list of examples of first names, all follow this pattern.

I am using Blast and wondered if it is expected that the original sequence of an array is not honoured, instead blast returns according to position in the DOM.

Here is an illustration: http://jsfiddle.net/9gogkww5/

Where it says:

npm install --save julianshapiro/blast
bower install blast

It should say:

npm install --save blast-text
bower install blast-text

and the version in bower is not the lastest.

Adds package, component, and bower.json files plus instructions. I broke it up into separate commits so you can take as much or as little as you’d like.

Steps to Reproduce:

1. enter the word "sentence" into the textbox #txtBtnSearch in the Robustness Gallery section.
2. Press "search" button (#btnSearch)

Expected:

• Occurrences of the word "sentence" are highlighted

Actual:

• Occurrences of the word "sentence" are highlighted
• Additional text (looks like an encoding) is injected
  • 'e{{46}}g{{46}} Blast{{46}}js'
  • Pressing any other button in the section undoes the injected text.

I have run into compatibility issues when integrating Blast into a Jekyll project, due to a regular expression with unescaped double curly braces ({{ and }}). While it's generally accepted not to escape curly braces, doing it doesn't harm and it widens Blast to integrate with other projects and build tools such as the aforementioned.

After effect in iOS 5 blink the last word.

$("#lastnews .ticker_tick")
    .html(data.title)
    .attr("href", data.hash)
    .blast({ delimiter: "character", aria: false })
    .velocity("fadeIn", {
        display: null,
        duration: 600,
        stagger: 60,
        delay: 600,
        mobileHA: !conditionizr.ios,
        complete: $$.last_news_home.after_magic
    });

A small bug at http://julian.com/research/blast/ in "Options Overview" code example, there are missing commas that should be after each parameter in the sample code. Great libraries velocity & blast :+1:

Hi, I don't think it's an issue, more a request: Blast is awesome, I have so many ideas I could use it for my projects. The only thing I found annoying, and I'm not good enough with js to figure how to change it, is that if I want to style sentences, Blast leaves the space right after the end of every sentence outside of span tags, leaving an unstyled space between every sentence. Is that clear ? Is there an easy fix for this ? For now, i do this in js :

$("document").ready(function() {
    $("p").blast({
        delimiter: "sentence"
    });
    $('.blast').prepend(' ');
});

and hide the last space with font-size:0 in css. But then there is an extra space before the first sentence of every paragraph. Anyway, far from perfect.

Again, this is really great otherwise, so many thanks ! best, Robin

for working example, see http://codepen.io/anon/pen/pyYJzv

If you have

<div>
  Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do. Eiusmod tempor incididunt ut labore et dolore magna aliqu.
  Lorem IPSUM dolor sit amet, consectetur adipisicing elit, sed do. Eiusmod tempor incididunt ut labore et dolore magna aliqu.
</div>

and search for ipsum

$("div").blast({ delimiter: /ipsum/gi, debug:true });

notice the case of ipsum in both sentences. The result is

<div aria-label="..." class="blast-root">
  Lorem<span class="blast" aria-hidden="true" style="background-color: rgb(7, 93, 154);"> ipsu</span>m dolor sit amet, consectetur adipisicing elit, sed do. Eiusmod tempor incididunt ut labore et dolore magna aliqu.
  Lorem <span class="blast" aria-hidden="true" style="background-color: rgb(241, 33, 133);">IPSUM</span> dolor sit amet, consectetur adipisicing elit, sed do. Eiusmod tempor incididunt ut labore et dolore magna aliqu.
</div>

notice that the first instance is offset by 1

<span ...> ipsu</span>m

My workaround is to lower-case the comparison of matchText and subMatchText, although I don't think this is the correct solution as simple lowercase comparisons are not necessarily appropriate in all locales:

https://github.com/saviourofdp/blast/commit/1a171d62c3af3fa2e980cebe76e1cd9a39e7dbc8

On Line 419, thisParentNode.normalize(); is called in order to combine and clean up all child nodes. On certain versions/certain settings in IE, the normalize(); function does not work correctly. It does not combine the child nodes, which in turn leads to faulty results.

For example:

1. Searching for "pm" in [email protected]
2. The child nodes could be "cs.p", "[email protected]".
3. blast.js will search for "pm" in "cs.p"
4. blast.js will search for "pm" in ""[email protected]"

Both will return no matches. The correct functionality should be:

1. Searching for "pm" in "[email protected]"
2. The child nodes should just be "[email protected]".
3. blast.js will search for "pm" in "[email protected]" A match is found.

I know this is mostly a bug in IE, but maybe changing the code to not use this function, and instead doing it manually might be the better choice. Another solution might be to combine all child nodes into one, before searching through them. Although this is not necessary a bug with blast, it does affect it.

Here is more information: http://stackoverflow.com/questions/12972090/ie-9-standards-mode-normalize-method-does-not-work

Within a contenteditable div, I will execute a blast as the user is typing to highlight the last group of nouns entered into the div by the user (using an NLP package). After the blast, the cursor is positioned at the beginning of the blast style DOM object, as opposed to the end of it. When the user continues typing, the blast is removed and the cursor actually is positioned where expected -- however, while the blast is shown, the cursor blinks at the beginning of the blast span and would lead the user to think that any typing that is about to be done will occur before the blast span of text.