documentcloud / documentcloud-notes Goto Github PK

Very much enjoying the new responsive notes feature. ... but it seems like the calculation of the bounding box could use a little work.

Using the Willingham story:

http://www.themarshallproject.org/2014/08/03/did-texas-execute-an-innocent-man-willingham/

Here's some screenshots of how the clipping changes as you resize the page. Ideally, the visible text would be identical in each one. Also, the centering.

In the integration branch, scaleNote is called every time the window resize handler fires, regardless of whether the note needs to be rescaled/restyled.

Can this be made smarter, so that notes are not scaled unless the boundary conditions for how each note is displayed has been passed?

Sprung from: documentcloud/documentcloud#19

Been chatting with @knowtheory about ways to allow this. Basically, we should be able to internally store a note model once and then reference it from multiple note views. Currently, there's a 1:1 relationship and so the last view instantiated is the only one who gets the note. (dc.embed.notes is keyed by note ID and points to a noteView, so you can't have multiple noteViews modeled on the same note.)

Goals:

1. Make this work
2. Make this work in a way that doesn't break existing integrations

Classifying this as a bug because there are many reasonably scenarios where a user would expect the same note to appear on the same page (e.g., index page for blog posts which each embed the same note).

Noticed an issue when trying to embed notes on our article pages – they work, but cause a cascade of errors to the rest of the page with anything else that requires jQuery.

We assign jQuery.noConflict to a different global var ($j) when we call it, but since jQuery is also delivered via note_embed.js it reassigns, breaking other functions called by the footer (or anything that runs after the embed script does).

Could the vendor scripts be checked and called as part of the asset loader rather than minified into note_embed.js to avoid reassigning to the default global vars? While less common, I imagine this would also be an issue for sites that already call Underscore, but reassign to a different global var.

A step toward unification of the note embed code with components of the page embed code. Backwards-compatible with existing embed codes. This issue is mostly a stub for documenting existing API coverage and requirements.

Load paths

Application

Available at assets.documentcloud.org, s3.documentcloud.org, and s3.amazonaws.com/s3.documentcloud.org:

• /notes/loader.js: Writes the following two to DOM
• /note_embed/note_embed.js
• /note_embed/note_embed.css

Data

• www.documentcloud.org/documents/282753-lefler-thesis/annotations/53674.js: JSONP that wraps JSON in dc.embed.noteCallback() function

dc global structure

• dc
  • embed
    • notes: Array of note views, keyed by note ID
    • loadNote(url, {id, container, afterLoad()})
    • noteCallback()
    • pingRemoteUrl()
    • noteModel()
    • noteView()
      • displayModes
      • displayNames
      • $()
      • setElement()
      • render()
      • cacheDomReferences()
      • checkAndSetWidth()
      • resize()

HTML structure:

• .DC-note
  • .DC-note-contents
    • .DC-note-title
      • a.DC-title-link
        • .DC-page-number
    • .DC-note-draft-label
    • .DC-icon
    • a
      • .DC-note-excerpt-wrap
        • .DC-note-excerpt
          • .DC-left-cover
          • .DC-right-cover
          • .DC-note-image
    • .DC-note-text

One of the consequences of writing things into someone else's DOM is sharing their CSS rules.

We need our note images to have a max-width and max-height set to none or else our width and positioning calculations end up coming out wrong.

Due to selector specificity (a page may use an ID on an element, and note embeds can't use IDs to override their specificity), i suspect we don't have any choice except to inline those directives.

When this page is sized down, the underline on the headline link gets pushed to the right.

Also, it might look better the wrapped headline's second line was flush left with the line above it.

Instead of relying solely on getting a URL for a note which must be fetched.

Should spawn a new window/tab with target="_blank".