WIP <figure> semantics

[forresto]

No description provided.

[forresto]

Why is this block.caption rather than block.metadata.caption?

Should it be html?

[forresto]

@bergie RFC

[forresto]

@bergie after p2p meetup can we figure out html consistency?

the-grid/ed#54
the-grid/ed#71

[forresto]

Do we want to allow formatting and / or links within figcaption ? Would be nice.

[bergie]

@forresto yes, if we allow figcaption, we should allow inline mark-up there.

[forresto]

Can we clean this up semantically?

[bergie]

@forresto right now title and caption are assumed to be text-only in the block format

[forresto]

@bergie what about using metadata alt and caption instead of description?

Or saving caption to description and making a new alt key?

[bergie]

@forresto if we want properties where the inline mark-up is retained, we should use new keys for them in order to not break backwards compat. Same should apply for example to article blocks.

[d4tocchini]

@bergie, what would be the appropriate keys for properties w/ inline markup? This is a powerful & needed step forward.

Using metadata fields like metadata.description as a catch-all for different block-types is a stumbling-block to appropriately render content in both the webapp and DS. It's not a complexity problem, simple to work-around with a few if/else statements, but it's a conceptual dilemma that cannot be overstated. The feedback from everyone who's touched the data model has been consistent on this. Just had a conversation with @nickvelloff on this very topic.

Being consistent with @cbchouinard's stated contract between DS & the data-model: the content of the blocks are ensured to be represented, metadata will be a nice-to-have but not guaranteed: let's move forward on allowing rich sub-block content immediately and keeping it outside of metadata.

@bergie, do you have a general API in mind for blocks to expose inline markup content (ie sub-blocks)? A general (ie recursive) solution would be preferred over an ad-hoc one, yes?

I'm assuming these changes can be rolled out without breaking DS or any clients, and new DS & clients v2 can move to new method in .5 days work...

[d4tocchini]

talking with @forresto, confirmed it will be needed for things like: edit the image caption inline in the editable, edit article block content inline, etc. Basically editable inline cards in Ed & would help catalyze Ed to next level. Most block metadata editing will be moving to a lightbox view.

DS needs this to ensure the most important content is rendered.

Apps could use it to more easily represent content on cards.

Not to mention it gives the possibility of having semi-rich text (links and what-not) in areas that reasonably should be have this possibility.

[d4tocchini]

@bergie @jonnor @aretecode is there another issue somewhere in APIs or elsewhere on the topic of exposing a block's inline html content outside of metadata? This has been brought up countless times, now that ed, DS & apps are leveling up, let's put this old beaten 🐴 to rest ASAP

[forresto]

Until we have a recursive content format, the source of full truth is html. @bergie what if we do this, saving the plain-text version of the caption in metadata.caption?

<figure>
  <img title="Hover title" alt="Alt text for screenreaders">
  <figcaption>
    No block elements; just <em>formatting</em> and <a href="https://thegrid.io/#8">links</a>
  </figcaption>
</figure>

→

block:
  metadata:
    title: 'Hover title'
    alt: 'Alt text for screenreaders'
    caption: 'No block elements; just formatting and links'

[bergie]

@forresto yep, we can do that. The tagToText helper should do the right thing there.

[bergie]

Note that it appears figcaption allows even headlines so we may have to think a bit how we populate the metadata from it https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Content_categories#Flow_content