btremI did all this work on it, and realized that, when all's said and done, the easiest thing is to just use the itemref attribute, which is already in html5. (sigh) I don't know why that didn't occur to me before I did all the work.
btremBut, in case you want some idea of how it might work, check out the link. And if you don't want to use itemref, maybe my idea could be used instead.
ethanyoo, [chrisaldrich], gRegorLove_, Loqi, sebbu, [tantek], [KevinMarks], [Ana_Rodrigues], [jgarber], [jgmac1106], KartikPrabhu, [snarfed] and btrem joined the channel; btrem left the channel
btremOk. I don't know what the protocol is about doing work outside the wiki. I created the pages because it seemed too large to include in their entirety there.
btremSimilar situations exist for the proposed h-menu, where some menus -- notably beer lists -- have a price in a header that applies to all beers in that menu section.
btremedited /menu-brainstorming (+437) "Proposes using p-nutrition for recipe items that have calories added to it, with caveat that it is not part of h-product." (view diff)
ben_thatmustbeme, [jgmac1106], Phae, craftyphotons__, [barryf] and [tantek] joined the channel
btremedited /microdata (+112) "Corrects status of microdata at W3C (editors for microdata were found, so the standard survived. Rumours of its death were greatly exagerated.)" (view diff)
btremFWIW, I actually think there was real potential for microdata, but for something bigger than microformats. I think it should have been developed with something bigger in mind. IMHO and all that.
[tantek]yeah, the WHATWG HTML inclusion of microdata is dubious because there are zero browser implementations, and the HTML spec is based on actual stuff implemented in browsers
[tantek]aaronpk, yup, which is why we kept microformats separate deliberately. also the processes for evolving them (HTML and microformats) were very different
Loqi[jgraham] #3135 Remove the HTML Microdata API, since no one else ended up implementing it and now it's been removed from the spec. r=bkelly,jgraham
[schmarty]yeah i am confused by that. i think it pre-dates the move from w3c to whatwg so maybe this issue was from back when this repo was under w3c control??
btremI'm curious: unless there was a bug or whatever, why did FF remove the implementation? IOW, why should they care whether other browsers implemented it or not? I've never worked on a project at even a small scale, so it's hard to understand one as large as a browser.
btremAnother question: what is the point of the microdata DOM api? Microdata and microformats are, to my eyes, something for communities to use. E.g., cooking sites/blogs etc. use h-recipe, and so search engines show recipes in search result rich snippets. But that's for Google or DDG to figure out, isn't it? And for microformats or schema.org to create
btremTo take another example, one of the motivations for my idea of h-menu is so that restaurants can publish menus on their web site, and any services they subscribe to -- Open Table, Grub Hub, etc. -- can read.
btremIf a menu were created in microdata instead of microformats, I'd think it would be up to restaurant publishers to agree on a format, and for services to agree to read them. This is sort of why I don't quite get what browser are supposed to do with microdata.
[schmarty]btrem: if i understand right, w3c and whatwg agree with your reading of it - the API specification was for browsers but folks eventually agreed that browsers were not intended to be consumers of microdata.
[tantek]btrem, re: "microdata ... it would be up to restaurant publishers to agree on a format", two big problems with that: 1. there is no microdata community to actually make that happen. and 2. restaurant publishers are not vocabulary experts, so they don't actually have the necessary infoscience skills to come up with a "format".
[schmarty]the big open question in my mind is: who is taking care of this standard? who are the groups or individuals that are consuming and publishing microdata?
btremSee, that why I think it's a shame that microdata died. I think of microdata as a possible way to make html extensible without the rat's nest of namespaces.
btremIf anyone is familiar with wine classifications, there's an analogue: in Italy, for example, they had DOC and DOCG for classified wines, iow, wines deemed high quality. And "table wines" for those not deemed high quality. There was too wide a gulf between them.
btremaaronpk: an obvious way for web authors to imagine how new elements are created. By sharing existing conventions. Microformats offers that, but authors have to know about them before they know about them. That is, the source code alone does not tell a novice that class=h-card means something more than class=blue or class=bottom.
btremI've thought about this a lot. Sorry you don't like analogies, [tantek], but I think it is appropriate. Something like microdata, where authors could have a semi element, if you will, would be useful imho.
[tantek]Adding anything element-like, whether semi or not would add a lot more confusion than not, e.g. to the DOM tree, CSS selectors etc. so that's perhaps why it doesn't make any sense to me
btremAnd if a microformat gains enough adoption, it could then be elevated to an actual element. Or not, maybe that step isn't even necessary. Still it'd be useful imho.
Loqi[[tantek]] btrem, re: "microdata ... it would be up to restaurant publishers to agree on a format", two big problems with that: 1. there is no microdata community to actually make that happen. and 2. restaurant publishers are not vocabulary experts, so they don...
btremAs to your remark about web publishers and restaurants, yeah, that's true, but I'm using restaurants loosely, more like, "people who publish websites for restaurants".
[tantek]to design good formats, you need both subject matter experts (on what the format is about), and formats experts. neither can do a good job by themselves
[tantek]so "people who publish websites for restaurants" will inevitably come up with a bad or unworkable format, because they don't typically have the expertise on how to do good format design
btremI'm not an expert in vocabulary. That means people who are familiar with the needs of restaurants don't know what's needed for restaurants. This is a sort of weird anti-tautology.
[tantek]subject matter experts can be expected to design bad technology because they're not technology experts. the technology experts can be expected to design a theoretical technology that doesn't actually match real world needs because they're not subject matter experts in those real world needs.
btremAs to the point that I missed when I got dumped: my point is that, it seems to me, a method for subject matter experts to participate is needed. The microformats community is good for that, but it's not something that subject matter experts would likely know about.
btremThe microdata idea -- or something like it -- might have been a way for subject experts to learn what's out there simply by looking at source code. Which is how a lot of learning on the web happens.
aaronpkone of my biggest frustrations when trying to learn new languages or frameworks is trying to distinguish arbitrary decisions the author made vs things that are conventions or even rules of the language
aaronpkbut if I looked at a bunch of website source code and saw that a lot of them were using the h-entry class, i might then search for "h-entry", and then find the microformats wiki
btremAgreed. I'd wager that would happen much more quickly if a bunch of websites were using microformats.org/h-entry, because the link is right there.
aaronpki guess what i mean is seeing one instance of anything (even a url) on a website isn't enough to establish a pattern or suggest that it's something more than the one author doing something on their own
btremI guess I'm saying that microdata had a potential usefulness that was not really explored. It was limited to an alternative to microformats when an alternative was not really needed.
btremI added a note about itemref, just in case we decide it's a good idea. It is easy, and the attribute already exists, and won't trigger errors in a validator. At the end of the day, while my custom element is nifty, it doesn't offer any advantage over itemref, and it does add lots of complexity.
aaronpktho this is leaving the microformats parsing realm and getting into microformats consumer realm which tends to be more discussion over at #indieweb-dev
btrem edited /menu-examples (+245) "/* T.S. McHugh's Irish Pub */ Adds details about draughts menu." (view diff)
[schmarty] hehehe, "[...[ if we believe the schema.org implementation announcements[...]"
KartikPrabhu I am confused. You can literally put any attribute in your HTML like foojangle = "beepboop"
aaronpk "Microdata does not generally interact with browsers, being a static document format that lacks any DOM interface." https://www.w3.org/TR/microdata/#security-considerations
[tantek] btrem, re: "microdata ... it would be up to restaurant publishers to agree on a format", two big problems with that: 1. there is no microdata community to actually make that happen. and 2. restaurant publishers are not vocabulary experts, so they don't actually have the necessary infoscience skills to come up with a "format".