recipe-issues

From Microformats Wiki
Jump to navigation Jump to search

This page reflects externally raised issues about recipe as well as the discussion that occurs on the microformats-new list (especially here, here, here and here). Some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Please read this page carfully before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek

issues

Please add new issues to the bottom of this section by copy and pasting the Template. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

  • open issue! 2008-12-04 raised by TobyInk
    1. ingredients should not be required. When I proposed this property I intended that it be an optional wrapper for one or more ingredient properties. Whatsmore, I proposed that an optimisation exist such that any direct child elements of ingredients are assumed to be ingredient properties. That is, it was intended to streamline hRecipe markup. The way it is currently specced it does the opposite: it forces authors into using a superfluous wrapper around their ingredient list. I propose the following changes to the spec:
      • 3.2 Schema: Define ingredients as: "optional. wrapper for 1 or more ingredient elements."
      • 3.3.7 ingredients: change definition to:
        • The element is identified by the class name ingredients.
        • A Recipe MAY include one or more ingredients elements.
        • The element by definition includes 1 or more ingredient elements. Any direct child elements which are not marked with the ingredient class are assumed to be ingredient elements anyway.
      • 3.3.8 ingredient: remove the requirement that it must be the child of an ingredients property.
  • Agreed complete about not requiring ingredients as a property. I don't think it would fit gracefully with marking up: Take some onions, crushed garlic, fry them together, then sprinking liberally with cinnamon for a sweeter onion base.. --BenWard 00:47, 5 December 2008 (UTC)
    • I don't know. Couldn't I further your example to conclude that 'title' and 'method' should be optional as well? But what's the purpose of a recipe format if it doesn't enforce the simplest structure? title, method and ingredients all seem essential to me. TomLurge 11:42, 9. December 2008 (GMT)
  • I'm also unsure that saying 'any child is assumed to be an ingredient' is going to work. Seems unclear. Having an optimisation for saying that <ul class="ingredients"> treat all child li elements as an ingredient makes sense, but generically I disagree. --BenWard 00:47, 5 December 2008 (UTC)
    • So, a question here is rather than have two property names for pluralisation, could instead have a rule that has ingredient treated as a list when on a list element, but singular otherwise? --BenWard 00:47, 5 December 2008 (UTC)
      • This could work. The only circumstance where it would fail would be if some very strange people wish to markup a single ingredient as a list (i.e. <ul class="ingredient"><li class="item">Onions</li><li class="note">Chopped</li></ul>). TobyInk 15:18, 5 December 2008 (UTC)
    • The recipe you gave as an example could be written: <p class="hrecipe"><span class="ingredients method">Take some <b>onions</b>, <b>crushed garlic</b>, fry them together, then sprinkling liberally with <b>cinnamon</b> for a sweeter onion base.</span></p>. But certainly <ul> was the element I had in mind for class="ingredients". TobyInk 15:18, 5 December 2008 (UTC)
    • Can we make them either/or? Either ingredients or (a list of) ingredients? TomLurge 11:53, 9. December 2008 (GMT)
  • Sorry I messed up your proposal, Toby. I didn't understand it properly. Anyway I'm not sure I agree. Adding an element doesn't necessarily make a format less readable. Redundancy can help understandability. A very concise format may be simple from one point of view, but it might not be easy to understand and use. See for example very terse code... TomLurge 11:51, 9. December 2008 (GMT)
  • By the way: I would prefer if these discussions could take place on the mailinglist. That way they would be easier to follow. I would have missed this one if I hadn't planned to document some discussions from the brainstorming-page. At least posting a hint that an issue was opened would be helpful. TomLurge 11:54, 9. December 2008 (GMT)



template

Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter. 

<div class="hentry">
{{OpenIssue}} 
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2
</div>
</div>

closed issues

closed issue entry-title and entry-summary are not always semantically right and may not be good class names.

  • title and summary already used for a different purpose (in hCard and hCalendar/hReview/hListing). Read more.
  • recipe-title and recipe-summary suggested.
  • Changed to recipe-title and recipe-summary for now.

closed issue Scope of Recipes

  • Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? Andy Mabbett 14:53, 16 Nov 2006 (PST)
    • +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.Frances Berriman
    • Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. Cameron Perry
    • However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. John LeMasney
      • Recipe for Nitroglycerine (not recommended by Weight Watchers) ? Andy Mabbett 10:43, 1 Feb 2007 (PST)
    • The scope is determined by the recipe-examples research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the process. Tantek 07:39, 15 Mar 2007 (PDT)
      • Work is continuing on the recipe format now with the scope limited to food-based items only. Phae 08:44, 3 Oct 2007 (PDT)
  • Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [1]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) SudarshanP 06:46, 26 Jun 2007 (PDT)
    • I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behavior is common enough to warrant specific properties to hold it. Phae 08:44, 3 Oct 2007 (PDT)

closed issue Ingredient Item/Quantity

TobyInk 03:42, 23 Mar 2008 (PDT):

This idea's a bit more "out there" and probably needs a bit more work. 

<li class="ingredient">3  eggs</li>

(note the double-space between '3' and 'eggs') is treated as a shorthand for: 

<li class="ingredient"><span class="quantity">3</span> <span class="item">eggs</span></li>

This is similar to N-optimisation in hCard, but uses a double space instead of a single space because the components (quantity, item) may themselves each contain spaces. With both of these optimisations in place, the sponge cake ingredient list can be written as concisely as: 

<ul class="ingredients">
<li>3  eggs</li>
<li>6 oz  self-raising flour</li>
<li>6 oz  caster sugar</li>
<li>6 oz  butter</li>
<li>1 tsp  vanilla essence</li>
</ul>

Which (apart from the double spaces) is pretty close to how many people publish ingredients lists already. (Certainly close to how I do!)

closed issue Alternative Ingredient Item/Quantity Optimisation

TobyInk 02:02, 24 Mar 2008 (PDT): Perhaps a better solution than the double spacing...

As above, but: 

<ul class="ingredients">
<li><var>3</var> eggs</li>
<li><var>6 oz</var> self-raising flour</li>
<li><var>6 oz</var> caster sugar</li>
<li><var>6 oz</var> butter</li>
<li><var>1 tsp</var> vanilla essence</li>
</ul>

Or is this stretching the meaning of <var> too much?

closed issue rel-license 2008-11-11 raised by ThomasLoertsch

  • Toby Inkster expressed concerns with rel-license in the following mail to microformats-new: http://microformats.org/discuss/mail/microformats-new/2008-August/001737.html. Currently it's not possible to scope a license to a single recipe on a page instead of the whole page. Until that problem is ssolved rel-license shouldn't be supported within hRecipe.
  • So either we throw it out of the first version of hRecipe or we add a hint that it MUST only be used ONCE per page.
  • After a chat with TobyInk made it clear to me that adding rel-license to the whole PAGE is already perfectly possible I removed the element of the hRecipe format. ThomasLoertsch 15:26, 3 Dec 2008 (GMT)

closed issue Measure

  • The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See BBC weather example Lee Jordan 20:00, 4 Feb 2008 (GMT)
    • The linked example doesn't include a SUP tag, the degree symbol can just be used as normal in most cases Ciaran McNulty


resolved issues

resolved issue Alternative Ingredients We need a way to markup alternative ingredients.

  • This is not entirely straight-forward. We should put this off for a future revision.

resolved issue Photo The 'photo' property should be usable for elements containing the element <img>.

  • This format reuses the 'photo' property of hCard so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard (Human_vs._Machine_readable). This is an hCard problem and should not be discussed here.

resolved issue Reliance on Measure Microformat Mark-up of quantity would be enhanced by use of a measure microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable enough without explicit mark-up of values and units.

  • Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? Phae 08:44, 3 Oct 2007 (PDT)
    • The former. Andy Mabbett 13:10, 4 Feb 2008 (PST)
    • The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". Yde 08:59, 30 May 2008 (PDT)
  • The ‘quantity’ of an ingredient should be considered as a string which parsers may attempt to understand as required. A future ‘measurement’ format will be an obvious compound part in recipes, but it is not required for recipe to be specified usefully. [2], [3]

resolved issue Measure

  • Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? Lee Jordan 20:15, 4 Feb 2008 (GMT)
    • Volume->weight conversions won't be possible without a substantially more complex markup (e.g. 1 cup of sugar weighs substantially more than 1 cup of flour) Ciaran McNulty
    • The problem is not really substantial whereas a solution would require significant effort. Therefor the issue is considered outside the 80/20. ThomasLoertsch 15:44, 3 Dec 2008 (GMT)

related pages

Retrieved from "http://microformats.org/wiki/index.php?title=recipe-issues&oldid=35004"