Here we find the <link rel="sidebar" ... that embed.js injected into the page. We pass it into the constructor method of Annotator.Host below.

Calling the Annotator.Host construct, passing an options object including our sidebar link.

Having created our Annotator instance and added our custom plugins etc to it, we inject Annotator into the page.

Finally, we inject a <link rel="sidebar" type="application/annotator+html" href=".../app.html"> into the <head> of the document. This is the HTML page for the contents of the sidebar/iframe. This link will be picked up by hypothesis.js later.

This loop is where we actually call injectScript() or injectStylesheet() on each of the resource URLs defined above.

And we do the same thing for injecting scripts as we did for injecting stylesheets - we either use the function passed in by the browser plugin, or when called by the bookmarklet we fall back on the DOM API.

hypothesisInstall() will use the inject.stylesheet() function passed in to it to inject stylesheets into the page or, if no function was passed in, it'll fallback on the default function defined inline here.

The default method just uses the DOM's appendChild() method, but this method may fail if the site we're trying to annotate uses the Content Security Policy.

That's why when we're using one of the browser plugins rather than the bookmarklet, we pass in the browser API's method for injecting a stylesheet instead.

This is why the bookmarklet doesn't currently work on GitHub, for example, but the Chrome plugin does.

embed.js is responsible for "embedding" the different components of the Hypothesis frontend application into the page.

First, either bookmarklet.js or one of the browser plugins injects a <script> tag to embed.js into the page, then embed.js runs.

This way the code in embed.js is shared across all bookmarklets and browser plugins, and the bookmarklets and plugins themselves have very little code.

Here we construct the actual <script> element, set its src URL, and inject it into the page using the DOM's appendChild() method.

The whole job of the bookmarket is to inject a <script src=".../embed.js"> element into the current page. The src URL of this script element points to embed.js, another Pyramid template rendered by the server-side Hypothesis app.

bookmarklet.js is the Pyramid template (rendered by our server-side Pyramid app) for the Hypothesis bookmarklet. This little bit of JavaScript (after being rendered by Pyramid) is what the user actually drags to their bookmarks bar as a bookmarklet.

Wonderful!

This is made possible by Hypotheis.is

Hey look!!1! "group annotation services"!

Here's one: http://via.hypothes.is/

Sorry cannot read the questions in full as I cannot get my sidebar to collapse. I cannot speak for developers but from my perspective the page-based group seems a good starter because it seems more straight forward and is less likely to change in the future but still shows off a hint of the full capabilities of hypothesis.

The mock ups are great. The copyright notice on the bottom of the annotations that the "Annotations can be used freely by anyone for any purpose" sort of defeats the idea of private readership of groups.

Still not convinced that sharing a link will be secure enough for the initial audience of lawyers, educators, researchers that you had in your user stories. Would having the link illicitly allow you to view the annotations without being detected.

This seems a sensible first step as a sort of soft launch but the capability of future progression to groups with limitations on annotators yet public readership will need to be considered in development.

Will be an important part of groups if groups are to to become important in establishing credibility or reputation in publicly visible groups with a limitations on annotators.

Is this stream the annotations in the sidebar or a stream that is independent of the sidebar. This independent stream will be important for inter-page groups if used by say research or educational groups..

I have not explained this part well. It is important so I will try again. In my opinion the way groups are set up is crucial to the development of reputation for annotators on Hypothesis. Annotators’ reputations will be strongly related to the Groups they belong. Trusted groups will need to have private annotator membership that is extended by invitation only but these groups need to be able to choose between public or private readership. Other groups will have different requirements for annotators and readers in terms of the public, private, link mix. Bridge

Trying to embed something in here from the atlantic article

<iframe width="640" height="360" frameborder="0" webkitallowfullscreen="webkitallowfullscreen" allowfullscreen="allowfullscreen" mozallowfullscreen="mozallowfullscreen" src="&lt;a href=" http:="" <a="" href="http://www.theatlantic.com" target="_blank" rel="nofollow noopener">www.theatlantic.com="" video="" iframe="" 384088="" "="" target="_blank" rel="nofollow noopener">http://www.theatlantic.com/video/iframe/384088/"></iframe> OK, that didn't work. How about a YouTube vid? <iframe width="640" height="360" src="//&lt;a href=" http:="" <a="" href="http://www.youtube.com" target="_blank" rel="nofollow noopener">www.youtube.com="" embed="" VX07m-wahOg"="" target="_blank" rel="nofollow noopener">www.youtube.com/embed/VX07m-wahOg" frameborder="0" allowfullscreen=""></iframe> OK, not embeds work so far. Not even images. Inserting images using the image url just gives you a link. Was hoping for the actual image.

Federated Wiki loses page if hypothes.is is applied.

hypothesis testing

The frequencies are reminiscent of the decomposition of a musical sound into its constituent harmonics; the primes have music in them.

Publisher Best Practices is a great idea that I would like to see codified in the authoring and publishing tools to make the practices commonplace by default.

I would like to mix PBP with other techniques, though, for richer connection between source and rendering-- I have some source mapping ideas that make it possible to keep annotations linked even as the original source is edited over time.

The question "So what's the relationship to h?" is a good one here; in particular, where does h end and other services/apps begin? I have quite a few thoughts in this area, including possible h spin-off companies, but my first interest in thinking about integrating it with other services is more from a strategic engineering perspective: what are the best places to focus h development so that it fits that composable unix-y philosophy of "do one thing well"; and I translate that thinking from tool to person... how can h help me do one thing well? As an end-user, even though I am admittedly a power-user with a lot of tools, I actually want to use as few tools as possible. The browser-extension part of h is the single most important part of the project from my end-user perspective-- the back-end infrastructure is there to support the browser-extension doing one thing well.

The one thing I want h to do for me that I can't do with any other tool that I know of is to allow me to rapidly track my reading and thinking and note-taking habits together. I want to be able to quickly select multiple portions of text and apply commentary and tags to the text within particular activity-based or goal-based contexts. The last part of that thought is the essential element I need that is missing. Speeding up the text selection would be very helpful in making it a tool I want to use on a daily basis for everything I do, but the contexts feature is what will make h a killer app for me.

What a great text to demo epub.js and hypothes.is! Moby-Dick must be the most mind-blowingly allusive and hypertextual writing in the English language!

Ma première annotation partagée publiquement!