search

documentcloud / documentcloud-pages

Responsively embed DocumentCloud pages.
https://documentcloud.github.io/documentcloud-pages/examples/
MIT License
22 stars 10 forks source link

Revert to original `DC-embed/DC-embed-stub` behavior #32

Closed reefdog closed 9 years ago

reefdog commented 9 years ago

At first, I had the wizard creating markup whose root element had a class of DC-embed-stub, which our enhance.js then recomposed into an element with the class DC-embed. So -stub indicated it needed enhancing, no--stub meant it was enhanced. Following some internal feedback, I made the wizard generate an element with the class DC-embed which the enhancer recomposed into DC-embed-enhanced. (See 1345ffd6515f5c7c509ad364e91bc693278da640.)

After more thought, I really don't like this and am going to revert to the original model. The whole stub/enhanced thing is an intermediate step on the way to the canonical embed resource markup. It's that final markup that deserves the DC-embed class, particularly as we want people to be able to use the embed markup and libraries without using the enhancer.

This will break existing embeds from enhancing, but that's why it's beta.

knowtheory commented 9 years ago

Okay, well lets talk about how the existing embeds behave.

Essentially, user drops divs into the dom, and then using javascript notifies the app code to find a particular div and use that as the site into which more markup gets dumped.

With the enhancer set up, we are establishing a convention that any suitably named divs are sites at which something can happen.

How the page-embed code currently behaves differently is that it's relying upon the site itself as a control structure, as opposed to merely the landing place in which something happens.

reefdog commented 9 years ago

Closed with e3e02ef01b35badaa9d260a9c960cd576927f8b1