Support for "slices"

[shawn]

Here's an example:

http://www.bullzip.com/products/pdf/info.php#slice_versionhistory

 

It might not be the best example, but it demonstrates how slices work pretty well.

 

Ideally, this would function by pre-parsing the resulting HTML from the page for the "slice", and excluding all external content.

[floele]

Slices? What do you intend to do actually? I've got no clue on that one

[CybTekSol]

I believe shawn wishes to decrease the amount of html that regex would have to process and possibly increase performance Flo. Forgive me if I'm wrong shawn, but it is a very interesting prospect if possible.

[shawn]

I guess I should have stated that you have to visit the URL above using Internet Explorer 8 or newer with the "Slices" functionality enabled.

 

Slices are an answer to the problem of sites that do not provide a legitimate or useful RSS feed, but they do provide other content in a consistent fashion. In the site above, the "sliced" section is the changelog (there didn't used to be an RSS feed, btw). Using a URL with an anchor reference, as so:

http://www.bullzip.com/products/pdf/info.php#slice_versionhistory

...would effectively strip off all text before the object with that id.

This would result in a much smaller code sample to have to parse for your RegEx pattern or before/after links. In the link above, it would effectively remove everything outside of this object:

<div class="hslice" id="slice_versionhistory"> ... </div> 

Thus, a page that's 70kb of text with numerous repeated phrases becomes 30kb, with much less duplication, which reduces the risk of "selecting" the wrong content.

[josh]

this is too much IE centric... i never ever use IE. maybe a Ketarin user script or extension would be better?

[shawn]

You're missing the point - Slices are not about "IE", they're about trimming the fat in large pages for only the important information. If you can easily identify a consistent block of meaningful code based on an elements ID, through an existing standard - it should be a very simple implementation in the core.

 

While "slices" are the name MS uses in IE for this functionality, URLs with named anchors have existed as long as HTML itself - the only significant difference between this and named anchors in general is that under "slices" the object with the associated ID is not only an inline reference but a container - which means that the agent/browser/whatever would consume the entire codeblock that relates to the ID and nothing more.

 

And, since Ketarin is already parsing the content, I'm pretty confident that it would be a relatively small change to add the ability to parse the results for a named ID or other selector...but the ability to convey that with an accepted definition ("slices" or "named anchors") would make describing the feature far more effective. I've come across the need for something like this a few times, but have coded around it the long way. It would be far more useful to only have to parse what's absolutely necessary in the returned HTML.

 

On a related note, it sure would be nifty to have the ability to use XSL selectors in general, too - but I'd be perfectly satisfied (for now) with slices.

[josh]

okay thx for clarification but you did say

 

I guess I should have stated that you have to visit the URL above using Internet Explorer 8 or newer with the "Slices" functionality enabled.

Edited July 30, 2010 by josh

[shawn]

That was just a demonstration page to show how Slices could be effective for downloading cool apps. They're in use in the wild, and having slices "enabled" would literally make that portion of the page "pop" for you.