Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recipe descriptions #4

Open
norm opened this issue Jun 27, 2020 · 4 comments
Open

Recipe descriptions #4

norm opened this issue Jun 27, 2020 · 4 comments

Comments

@norm
Copy link
Member

norm commented Jun 27, 2020

Many recipes are presented with prose descriptions. I suggest a key or keys at the top of the recipe object to represent this. Either keys like description / introduction / postscript / history... or a single key that contains an object.

The most common across my recipe books is a paragraph or several before the ingredients and steps, but I have also seen both a personal introduction to a recipe, then a description of it, the ingredients, the steps, then more prose afterward such as cooking tips and alternatives.

I would suggest they contain free text for the renderer to interpret as it will (eg I will be adding markdown to mine).

@jaylett
Copy link
Member

jaylett commented Jun 27, 2020

I'd be happy with adding description. The problem with adding more of them is that it gets into physical presentation, and the entire point was to avoid that as much as possible. ("History" is an interesting one, but "postscript" is not really structural.)

I'm 50/50 on whether a text blob should be treated as plain text and to use an object with typing for anything else. Improves compatibility, makes things more complex. The main problem being that if you're stuffing Markdown in a text blob, nosebag almost certainly won't care and it'll look a little weird. Although at least rendering Markdown as text doesn't look terrible; it's not like you're going to stuff docbook in there or something. Maybe the rule should be "will not look terrible if rendered as plain text with newlines preserved". Or would you start splitting lines within Markdown on sentence structure to make the diffs easier? In which case we could advocate simple unwrapping (similar to the Django |linebreaks filter).

(I'm thinking for instance of extending nosebag for tablet use while cooking at forts, going back to the ideas of omnom.)

@norm
Copy link
Member Author

norm commented Jun 27, 2020

Yeah, I have been trying to find the more involved recipes to see what doesn’t fit. I’d be happy to pare it back to a singular description. In the absence of more structure, you can have that contain subheadings. I just have seen some that are broken down into separate areas and presented around the recipe itself, so I thought it wise to mention.

We have precedent in ingredient amounts for simple or complex keys as needed, so I’d be happy with plain text vs some encoded representation with a content-type.

I’d also be happy with the default being to treat it Markdown, given mostly it’s just about paragraphs.

@jaylett
Copy link
Member

jaylett commented Jun 27, 2020

I wouldn't be completely happy with the default being to treat as Markdown, because that's a burden on nosebag (and subsequent clients) that someone will have to implement. And I don't know which of the 48000 npm modules is the "right" one to use.

@norm
Copy link
Member Author

norm commented Jun 29, 2020

Draft in #10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants