[tantek]They have an actual datetine of when they were published (whether or not it’s displayed), and an actual date time of when they were last updated (even if not displayed)
[tantek]Even some “blog posts” lack published dates because annoying SEO folks say to not display it because you don’t want your articles to look “old”
aaronpkthe problem is specifically that an editing app wants to show lists of things to edit, and people want those lists to be either their time-ordered posts or their pages
[tantek]As an editor you start with their root, their domain, their home page and then you have a discovery challenge, not a “type” challenging, and certainly not a “type” challenge between only two types. That’s super narrow thinking IMO
aaronpki feel like i'm getting a lot of pushback on the idea of collecting examples and researching this and you're jumping to the conclusion of "just use h-entry" when that doesn't actually solve the problem at hand
[tantek]I’m pushing back because I think you’re assume page vs post is the important distinction and I’m saying no, page/post vs collection/feed is actually a much more important distinction and there are likely even more such distinctions
[tantek](Feel free to ignore the h-card as root case for now 🙈, except as an example in the back of your mind that there are even more distinctions that an editor will likely have to care about)
Tekk_Is there any particular historical reason the spec needed to define implied properties with a whole bunch of implication rules instead of doing the (at least feels right to me) other possibility of just saying "you need to have these things to be valid"?
Tekk_Specifically thinking about the 10 different fallback rules that had to be defined to save the poor author the trouble of having to write class="p-name"
[tantek]we also learned from some of the early requirements on original microformats, and watching authors get them wrong anyway, despite various validators warning them etc.
[tantek]short version: making requirements like that doesn't actually result in more valid content. so if the goal is valid content, define how to process it rather than making extra work for the author.
Tekk_Fair enough, any reason for not going the other way? (e.g. the fields are optional and supported parsers don't have to jump through 30 different hoops to try and find it because you didn't specify.)
[tantek]ordinality is another requirement that most formats got horribly wrong it turns out (were based on theory rather than actual real world examples and author publishing behaviors)
[tantek]it's such a common pattern of publishing things on the web, that it adds a tremendous amount of efficiency to do the "obvious" thing for those cases.
Tekk_So it's more or less: MUST parse even if 'essential' data is missing, SHOULD try and infer the missing essential data, with a suggested algorithm for doing so?
[tantek]took some iterations on the implied rules (based on publishing and parsing experiences), but I think we're in pretty good shape now, especially for p-name and u-url
Tekk_In my particular case I'm only interested in writing on the publishing side, so it's not the end of the world for me. Just something I got curious about.
Tekk_If stuff like name or photo can be plural, is there any reason there's not like, an "m-canonical" class (to pick some arbitrary prefix for 'meta')? That'd solve the small h-card vs big h-card problem too.
Tekk_If I'm say an author who uses pen names it makes a perfect amount of sense to say <div class="h-card"><p class="p-name">Michael Jordan</p><p class="p-name">Jules Vernee</p><p class="p-name">Jonathan Frakes</p></div>
[tantek]that's a better question for #indieweb-dev since you're asking an IndieWeb specific question "commenting on someone's site and" … "what name to put on the comment"?
Tekk_Specifically that it's out of the question to expect implementors to go through that whole fallback process and then gracefully handle the case of "well it turns out they don't even specify 'A Picture Of The Grand Canyon' on their picture so we can't make that their name" but it's a ridiculous burden to have them check which child has a "canonical" attribute attached.
Tekk_Which like, the fallback system isn't the end of the world it just seems entirely reasonable to me to go "If they don't specify a picture in their card then they just don't have a picture and that's okay"
[tantek]not quite. it's more about providing a simpler and predictable model for the author, that deliberately optimizes common cases to not require extraneous markup
[tantek]which is the opposite of most formats, which attempt to optimize for the most complex edge-cases and then burden all uses with that complexity (see also namespaces, RDF, etc.)
[tantek]I feel like "editor" UI needs to be rethought as much as we rethought "feed reader" to come up with "social reader", but that's probably better discussed in #indieweb-dev
jackyI definitely take a lot of my ideas/inspiration on the editor experience from Ghost (which, in turn, is inspired by a mashup of Tumblr and Wordpress's approach)
[tantek]I'm curious why you think they don't fit — we've been using h-entry markup for various pages for quite some time and they seem to fit just fine
jackyWikipedia pages are more like articles if you were to run them by PTD, no? And they _have_ to have that kind of messaging due to its need to show a log of changes
[tantek]and perhaps the majority now have revisions in databases or git so they have logs, just not surfaced in the presentation by default (but could be)
[chrisaldrich]Another difference between a post (article) and a page is that of the difference between the garden and the stream... posts come and go, but use cases for pages in the wild give them a more curated permanence. This difference generally isn't indicated in the metadata, but more often by the fact that they're included in a menu.
[chrisaldrich]I'd actually think that there's a case to be made that "pages" would be beneficial to be put into a stream/feed -- especially when they're updated-- but almost no CMSes or systems do this in practice.
[chrisaldrich]The real question here is the problem we're trying to solve: how can one specify a page one would like to put into a more prominent space, menu, other in a way that an editor can target it for creation/update?
[tantek]It seems like the only real distinctions are 1. is it part of a (time ordered) feed, and 2. does it have a URL based on its name more than a date
[chrisaldrich]WordPress is an abysmal set up in that it has the same general UI for posting both posts and pages, but differentiates between them internally within the database. Even then, I could make a post look like a page by placing it into my menu.
[chrisaldrich]The difference between them is semantic, we just need something to specify that semantic handle so we can do something with them. N'est-ce Pas?
[chrisaldrich]pages/articles seem to be a superset of all of the various post types... even reads, watches, listens are really just a "bookmark" of a thing that got read, watched, or listened to.
[tantek]I feel like the UI argument of “people want to pick one or the other” is the same mistaken argument as “people want to explicitly pick a photo post vs a note vs an article etc before thy even start creating” which we already debunked many years ago as legacy UI
[tantek]If it really is just about does it show a published date or not, then make *that* the option. Or do it automatically (or as a default) if they check
aaronpk your site too http://tantek.com/contact
Tekk_ Is there any particular historical reason the spec needed to define implied properties with a whole bunch of implication rules instead of doing the (at least feels right to me) other possibility of just saying "you need to have these things to be valid"?
jacky whereas as a page like https://jacky.wtf/live.html wouldn't need something like that
[chrisaldrich] wow... what a scrollback...
KartikPrabhu I'm still not sure what the "actual" difference is for someone consuming/reading your website
@tomer ↩️ יש לך שגיאה לוגית. מצד אחד, אתה כותב שב־MDN אפשר למצוא רשימה של כל התגיות שאפשר להכניס בשדה, ואז כעבור שתי פסקאות פתאום מספר על דברים שלא מצאת ב־MDN. תחליט כבר.
אולי כדאי להוסיף את הדף הבא מ־http://microformats.org שמכיל גם הרחבות: http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions (twitter.com/_/status/1287305862596431873)
[grantcodes] There are plenty of examples of posts with top level paths and no date in the URL
[KevinMarks] Like mine