editorial: make Blob.slice a separate algorithm

[dlrobertson]

Split out Blob.slice into its own algorithm that other implementations may use and call this algorithm from Blob.slice.

Related to: whatwg/fetch#1070

---

Preview | Diff

[dlrobertson]

Just a first pass at the moment. Still likely have a good bit of cleanup to do. Originally I wanted a normalize range and a slice bytes algorithm, but after further reading I think its probably easier to just bundle all of it in one algorithm (especially since slice bytes is really only one line in the algorithm).

[dlrobertson]

I don't think this is substantive, but if this is considered to be substantive, I can create a w3c account.

[mkruisselbrink]

Generally looks good, just two minor points. I agree that just moving stuff around like this is probably not substantive. I really need to get around to rewriting splice more formally at some point, but that is unrelated to this.

[mkruisselbrink]

Suggested change

	<li><var>S</var> refers to <var>span</var> consecutive <a>byte</a>s from <var>blob</var>'s,
	<li><var>S</var> refers to <var>span</var> consecutive <a>byte</a>s from <var>blob</var>'s

[mkruisselbrink]

You probably want this to be exported so you can reference it from fetch? And this should probably be an abstract-op, and I don't think it needs an explicit ID.

Suggested change

	The <dfn id="slice-blob">slice blob</dfn> algorithm given a {{Blob}} <var>blob</var>,
	The <dfn abstract-op export>slice blob</dfn> algorithm given a {{Blob}} <var>blob</var>,

[annevk]

It should not be an abstract-op (that's mainly JS stuff, all our algorithms are the default dfn most of the time), but you're right that relying on the generated ID is fine.

[dlrobertson]

Thanks for the comments! Fixed the remaining build errors and made the suggested changes.

[w3cbot]

mkruisselbrink marked as non substantive for IPR from ash-nazg.