menu-brainstorming - Revision history

Btrem: Adds idea for menu sections with section element.

2020-12-18T19:38:32Z

Adds idea for menu sections with section element.

← Older revision		Revision as of 19:38, 18 December 2020
Line 37:		Line 37:

	There should be a way for publishers to indicate menu availability, so perhaps we should include a p-availability property. It would be nice if that could embed a machine readable format, but it doesn't look like there's been much work on [[opening-hours]]. Minus my contribution to earlier today, there hasn't been any contributions since 2017. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 22:42, 16 December 2020 (UTC)		There should be a way for publishers to indicate menu availability, so perhaps we should include a p-availability property. It would be nice if that could embed a machine readable format, but it doesn't look like there's been much work on [[opening-hours]]. Minus my contribution to earlier today, there hasn't been any contributions since 2017. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 22:42, 16 December 2020 (UTC)

			Another idea for menu sections is to use the <code>section</code> element without any class name. A nested <code>hx</code> element would name the menu section ("appetizers", "dinner", etc.). It has the advantage of being native html5 and understood by or at least intuitive to authors. There are, however drawbacks. One is that it would require <code>section</code> where it is not convenient. One example is a menu using table markup, where sections are delimited by the <code>tbody</code> element. That could work with <code>th</code> standing in for <code>hx</code>, but that might be confusing. Probably not workable, but worth mentioning. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 19:38, 18 December 2020 (UTC)

Btrem: Added signature.

2020-12-16T22:42:01Z

Added signature.

← Older revision		Revision as of 22:42, 16 December 2020
Line 36:		Line 36:
	I just came across the p-nutrition property from [[h-recipe]], which could be reused for menu items that include calories or other (often required) nutritional information. There is, however, a problem: as proposed so far, h-menu would be a collection of p-products that could embed [[h-product]]. But p-nutrition is not part of [[h-product]]. Other h-menu properties would pertain to the menu as a whole, not to individual menu items. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 00:57, 16 December 2020 (UTC)		I just came across the p-nutrition property from [[h-recipe]], which could be reused for menu items that include calories or other (often required) nutritional information. There is, however, a problem: as proposed so far, h-menu would be a collection of p-products that could embed [[h-product]]. But p-nutrition is not part of [[h-product]]. Other h-menu properties would pertain to the menu as a whole, not to individual menu items. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 00:57, 16 December 2020 (UTC)

	There should be a way for publishers to indicate menu availability, so perhaps we should include a p-availability property. It would be nice if that could embed a machine readable format, but it doesn't look like there's been much work on [[opening-hours]]. Minus my contribution to earlier today, there hasn't been any contributions since 2017.		There should be a way for publishers to indicate menu availability, so perhaps we should include a p-availability property. It would be nice if that could embed a machine readable format, but it doesn't look like there's been much work on [[opening-hours]]. Minus my contribution to earlier today, there hasn't been any contributions since 2017. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 22:42, 16 December 2020 (UTC)

Btrem: Adds suggestion for availability property.

2020-12-16T22:10:36Z

Adds suggestion for availability property.

← Older revision		Revision as of 22:10, 16 December 2020
Line 35:		Line 35:

	I just came across the p-nutrition property from [[h-recipe]], which could be reused for menu items that include calories or other (often required) nutritional information. There is, however, a problem: as proposed so far, h-menu would be a collection of p-products that could embed [[h-product]]. But p-nutrition is not part of [[h-product]]. Other h-menu properties would pertain to the menu as a whole, not to individual menu items. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 00:57, 16 December 2020 (UTC)		I just came across the p-nutrition property from [[h-recipe]], which could be reused for menu items that include calories or other (often required) nutritional information. There is, however, a problem: as proposed so far, h-menu would be a collection of p-products that could embed [[h-product]]. But p-nutrition is not part of [[h-product]]. Other h-menu properties would pertain to the menu as a whole, not to individual menu items. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 00:57, 16 December 2020 (UTC)

			There should be a way for publishers to indicate menu availability, so perhaps we should include a p-availability property. It would be nice if that could embed a machine readable format, but it doesn't look like there's been much work on [[opening-hours]]. Minus my contribution to earlier today, there hasn't been any contributions since 2017.

Btrem: Adds sig to most recent addition.

2020-12-16T00:57:30Z

Adds sig to most recent addition.

← Older revision		Revision as of 00:57, 16 December 2020
Line 34:		Line 34:
	For prix fixe menus, there's no way to mark up choices with microformats. It probably makes sense to just markup the entire menu as one h-product, with all choices for each course in one large e-description. That is an honest representation of the menu and probably is good enough. Something more specific would have to be done in h-product, and shouldn't be implemented unless it's really needed. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 00:38, 11 December 2020 (UTC)		For prix fixe menus, there's no way to mark up choices with microformats. It probably makes sense to just markup the entire menu as one h-product, with all choices for each course in one large e-description. That is an honest representation of the menu and probably is good enough. Something more specific would have to be done in h-product, and shouldn't be implemented unless it's really needed. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 00:38, 11 December 2020 (UTC)

	I just came across the p-nutrition property from [[h-recipe]], which could be reused for menu items that include calories or other (often required) nutritional information. There is, however, a problem: as proposed so far, h-menu would be a collection of p-products that could embed [[h-product]]. But p-nutrition is not part of [[h-product]]. Other h-menu properties would pertain to the menu as a whole, not to individual menu items.		I just came across the p-nutrition property from [[h-recipe]], which could be reused for menu items that include calories or other (often required) nutritional information. There is, however, a problem: as proposed so far, h-menu would be a collection of p-products that could embed [[h-product]]. But p-nutrition is not part of [[h-product]]. Other h-menu properties would pertain to the menu as a whole, not to individual menu items. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 00:57, 16 December 2020 (UTC)

Btrem: Proposes using p-nutrition for recipe items that have calories added to it, with caveat that it is not part of h-product.

2020-12-14T19:00:08Z

Proposes using p-nutrition for recipe items that have calories added to it, with caveat that it is not part of h-product.

← Older revision		Revision as of 19:00, 14 December 2020
Line 33:		Line 33:

	For prix fixe menus, there's no way to mark up choices with microformats. It probably makes sense to just markup the entire menu as one h-product, with all choices for each course in one large e-description. That is an honest representation of the menu and probably is good enough. Something more specific would have to be done in h-product, and shouldn't be implemented unless it's really needed. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 00:38, 11 December 2020 (UTC)		For prix fixe menus, there's no way to mark up choices with microformats. It probably makes sense to just markup the entire menu as one h-product, with all choices for each course in one large e-description. That is an honest representation of the menu and probably is good enough. Something more specific would have to be done in h-product, and shouldn't be implemented unless it's really needed. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 00:38, 11 December 2020 (UTC)

			I just came across the p-nutrition property from [[h-recipe]], which could be reused for menu items that include calories or other (often required) nutritional information. There is, however, a problem: as proposed so far, h-menu would be a collection of p-products that could embed [[h-product]]. But p-nutrition is not part of [[h-product]]. Other h-menu properties would pertain to the menu as a whole, not to individual menu items.

Btrem: Adds proposal for prix fixe menus.

2020-12-11T00:38:20Z

Adds proposal for prix fixe menus.

← Older revision		Revision as of 00:38, 11 December 2020
Line 32:		Line 32:
	One of the problems with coming up with a structure for h-menu is how to deal with menu sections. It seems like one simple solution is to allow [[h-menu]] to be nested. The outer container might have a p-name "Dinner". Then nested sections could be themselves h-menu instances, each with their own p-name set to Appetizers, Salads, etc. That would allow for simple, flat menus with a list of h-product instances, or complex menus with sections, sub-sections, etc., as needed. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 22:06, 10 December 2020 (UTC)		One of the problems with coming up with a structure for h-menu is how to deal with menu sections. It seems like one simple solution is to allow [[h-menu]] to be nested. The outer container might have a p-name "Dinner". Then nested sections could be themselves h-menu instances, each with their own p-name set to Appetizers, Salads, etc. That would allow for simple, flat menus with a list of h-product instances, or complex menus with sections, sub-sections, etc., as needed. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 22:06, 10 December 2020 (UTC)

			For prix fixe menus, there's no way to mark up choices with microformats. It probably makes sense to just markup the entire menu as one h-product, with all choices for each course in one large e-description. That is an honest representation of the menu and probably is good enough. Something more specific would have to be done in h-product, and shouldn't be implemented unless it's really needed. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 00:38, 11 December 2020 (UTC)

Btrem: Adds idea for dealing with menu sections.

2020-12-10T22:06:06Z

Adds idea for dealing with menu sections.

← Older revision		Revision as of 22:06, 10 December 2020
Line 29:		Line 29:

	I realize that h-menu is not ready for a draft, hence why I'm putting these ideas in menu-brainstorming. It's just me bouncing ideas off the wall. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 22:45, 8 December 2020 (UTC)		I realize that h-menu is not ready for a draft, hence why I'm putting these ideas in menu-brainstorming. It's just me bouncing ideas off the wall. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 22:45, 8 December 2020 (UTC)

			One of the problems with coming up with a structure for h-menu is how to deal with menu sections. It seems like one simple solution is to allow [[h-menu]] to be nested. The outer container might have a p-name "Dinner". Then nested sections could be themselves h-menu instances, each with their own p-name set to Appetizers, Salads, etc. That would allow for simple, flat menus with a list of h-product instances, or complex menus with sections, sub-sections, etc., as needed. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 22:06, 10 December 2020 (UTC)

Btrem: Adds proposal for menu structure and property names

2020-12-08T22:45:13Z

Adds proposal for menu structure and property names

← Older revision		Revision as of 22:45, 8 December 2020
Line 18:		Line 18:

	A simple solution might be to have a container for a menu section /instead of/ a container for a menu. That would allow a website to have a menu spread over several pages, each one with a single container element. If a website wants to put it on one page, they could place the container elements on one page, one after the other. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 16:31, 4 December 2020 (UTC)		A simple solution might be to have a container for a menu section /instead of/ a container for a menu. That would allow a website to have a menu spread over several pages, each one with a single container element. If a website wants to put it on one page, they could place the container elements on one page, one after the other. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 16:31, 4 December 2020 (UTC)

			Ideas for property names:
			* p-name for the name of menu, e.g. dinner, breakfast, etc.; or maybe desserts, wine list, appetizers, etc.
			* p-seller - the retailer, i.e., restaurant, cafe, pub, etc, that is selling the menu items. This can be an embedded h-card. The name of this property should be generic enough to include a wide rage of food retailers, perhaps with the ability to include other types of businesses. Alternative property names for p-seller:
			** p-brand - this has the advantage of reuse from h-product, but that might be a disadvantage, too: menu items will likely be nested h-products, so using p-brand on parent and nested type might cause confusion. There's an additional problem: p-brand as restaurant name might be confusing for authors who might reasonably assume that a property called p-brand refers to the item brand, not the restaurant brand. In other words, a restaurant called "Bavarian Pub" that sells Franziskaner beer might assign "Franziskaner" instead of "Bavarian Pub" to a p-brand property. Thus, p-brand is a strong "pass" for me.
			** p-restaurant - simple and straightforward, but might give wrong impression of its intended use. I imagine a street vendor might not think of her/himself as a restaurant.
			** p-organization - very adaptable, but not very intuitive.
			** p-retailer - again, adaptable, but not as obvious as seller, and perhaps again might give wrong impression to street vendors or food kiosks.
			* p-product -- the thing being sold, a beverage or dish, e.g., main dish, appetizer, dessert, beer, wine, etc. This can be an embedded h-product. The property name matches the embedded name, following the [[h-card]] convention which has a p-adr property that can be an embedded [[h-adr]]; and p-geo with optionally embedded h-geo. Also, p-product is both intuitive and adaptable. Obviously, a menu normally contains many items, so this would be a many-to-one relationship.

			I realize that h-menu is not ready for a draft, hence why I'm putting these ideas in menu-brainstorming. It's just me bouncing ideas off the wall. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 22:45, 8 December 2020 (UTC)

Btrem: Adds sig

2020-12-04T16:31:17Z

Adds sig

← Older revision		Revision as of 16:31, 4 December 2020
Line 17:		Line 17:
	A menu container needs a way to distinguish sections that is flexible to account for language differences and restaurant conventions. This could present challenges to third party consumers. However, I think a menu microformat should not get bogged down in such details. It's conceivable that a restaurant and third party could agree on a set of additional classnames for interoperability. So if menu aggregator Foo Delivery Service could look for a class name specific to its service in addition to any microformats, e.g., <code>section class="starter foo-deliver"</code>. The <code>starter</code> classname would be a microformat spec, used by menus everywhere, while <code>foo-deliver</code> would be specific to Foo Service, a way for a restaurant to specify that it offers items in this section for delivery by Foo. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 15:20, 4 December 2020 (UTC)		A menu container needs a way to distinguish sections that is flexible to account for language differences and restaurant conventions. This could present challenges to third party consumers. However, I think a menu microformat should not get bogged down in such details. It's conceivable that a restaurant and third party could agree on a set of additional classnames for interoperability. So if menu aggregator Foo Delivery Service could look for a class name specific to its service in addition to any microformats, e.g., <code>section class="starter foo-deliver"</code>. The <code>starter</code> classname would be a microformat spec, used by menus everywhere, while <code>foo-deliver</code> would be specific to Foo Service, a way for a restaurant to specify that it offers items in this section for delivery by Foo. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 15:20, 4 December 2020 (UTC)

	A simple solution might be to have a container for a menu section /instead of/ a container for a menu. That would allow a website to have a menu spread over several pages, each one with a single container element. If a website wants to put it on one page, they could place the container elements on one page, one after the other.		A simple solution might be to have a container for a menu section /instead of/ a container for a menu. That would allow a website to have a menu spread over several pages, each one with a single container element. If a website wants to put it on one page, they could place the container elements on one page, one after the other. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 16:31, 4 December 2020 (UTC)

Btrem: Adds suggestion for menu sections.

2020-12-04T16:30:52Z

Adds suggestion for menu sections.

← Older revision		Revision as of 16:30, 4 December 2020
Line 16:		Line 16:

	A menu container needs a way to distinguish sections that is flexible to account for language differences and restaurant conventions. This could present challenges to third party consumers. However, I think a menu microformat should not get bogged down in such details. It's conceivable that a restaurant and third party could agree on a set of additional classnames for interoperability. So if menu aggregator Foo Delivery Service could look for a class name specific to its service in addition to any microformats, e.g., <code>section class="starter foo-deliver"</code>. The <code>starter</code> classname would be a microformat spec, used by menus everywhere, while <code>foo-deliver</code> would be specific to Foo Service, a way for a restaurant to specify that it offers items in this section for delivery by Foo. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 15:20, 4 December 2020 (UTC)		A menu container needs a way to distinguish sections that is flexible to account for language differences and restaurant conventions. This could present challenges to third party consumers. However, I think a menu microformat should not get bogged down in such details. It's conceivable that a restaurant and third party could agree on a set of additional classnames for interoperability. So if menu aggregator Foo Delivery Service could look for a class name specific to its service in addition to any microformats, e.g., <code>section class="starter foo-deliver"</code>. The <code>starter</code> classname would be a microformat spec, used by menus everywhere, while <code>foo-deliver</code> would be specific to Foo Service, a way for a restaurant to specify that it offers items in this section for delivery by Foo. [[User:Btrem\|Btrem]] ([[User talk:Btrem\|talk]]) 15:20, 4 December 2020 (UTC)

			A simple solution might be to have a container for a menu section /instead of/ a container for a menu. That would allow a website to have a menu spread over several pages, each one with a single container element. If a website wants to put it on one page, they could place the container elements on one page, one after the other.