[cleverdevil], nitot, KartikPrabhu, [keithjgrant], [acegiak_net], davidmead, KevinMarks, KevinMarks_, [scottgruber], uf-wiki-visitor and AndySky21 joined the channel
AndySky21_, bigbluehat, TallTed, KartikPrabhu and uf-wiki-visitor joined the channel
#uf-wiki-visitorhello, I'm looking at the possibility of a new microformat for spoilers. Is there anything you currently have that might cover it? I've spent quite a while looking through the other proposals here: http://microformats.org/wiki/exploratory-discussions . But I haven't found anything that looks close.
#ZegnatHi! No, I do not think there is such a thing as a spoiler mf yet. In what context would you use it?
#AndySky21I suppose you mean a post talking about an extensive work whose reading would spoil the suspense effect? Well then there should be a property on h-entry
#uf-wiki-visitorI was thinking more of things that the internet often spoills such as sporting event outcomes. Or TV/Movie endings & twists. If authors could mark up potential information that could ruin a users experience, the browsers (or extensions) could hook in to this and hide info based on the users desires.
#uf-wiki-visitor<div class="spoiler"> <div class="sport"> <p class="F1"><span class="individual">Lewis Hamilton</span> <span class="outcome">wins</span> the <time class="event" datetime="2017-01-14">UK Silverstone Grand Prix.</time></p> </div> </div>
#Zegnatthat feels like a lot of hidden metadata there.
#AndySky21well we're talking about post however, so it should be added to entry.
#ZegnatAndySky21, I am not sure about that. Would an entire post classify as spoiler in its entirety? The spoiler might only be part of a book h-review.
#ZegnatThough if an entire h-entry can be marked as being a spoiler, applications could hide it based on the h-entry's tags. Which would be a nice way to get rid of things like the hidden sport/F1 classes from the example above.
#uf-wiki-visitorWhile wrestling with this problem I've also noticed that. It could be a partial part of a post. Or the entire thing could be a spoiler. It feels like it should be an extension to something existing, rather than a whole new thing though
#uf-wiki-visitorreading through the h-entry docs. This seems like a natural area for a spoiler context to exist.
#AndySky21like e-spoiler : part of content giving potentially unwanted information about the original subject, not to be shown unless allowed by the user
#ZegnatHow would that work as part of the post? e-spoiler nested within e-content?
#KartikPrabhuall of this would be useless unless we have examples of something that would consume such data
#KartikPrabhubrowsers themselves do not look for any microformats AFAIK
#uf-wiki-visitorIts a fair point. But also its, a Chicken and egg scenario. If you don't have something in a standardised way. Why would you build anything for it?
#AndySky21this could work for search engines. Spoiler sections are not to be shown by SE widget/preview
#KartikPrabhuno, I mean does anyone consume anything like that on a page?
#uf-wiki-visitorI was coming at it more from a user need point of view. The internet spoils many things and we may be able to provide a way to fix that.
#AndySky21for sure this won't be implemented at UA level, like most extended semantics. It could work for content reposting/embedding/lookup
#uf-wiki-visitorNews articles frequently publish results to big sporting events in their headlines as a way to get more users reading them. But also spoil the result for others who haven't had time to watch on catch-up TV.
#KartikPrabhuuf-wiki-visitor: individual sites can provide that themselves. The use of microformats would be to have it cross-site
#KartikPrabhuI haven't seen any such publisher use mf2 in the first place
#uf-wiki-visitorfair point, I hadn't considered syndication, my bad.
#KartikPrabhuuf-wiki-visitor: one good practice would be to implement such a proposal yourself
#AndySky21listing participants usually involves a participating status - that's why i hoped to use p-attendee in conjunction with h-entry instead of h-card
#aaronpkin general, mf2 parsing doesn't care about the types of things, the parsers will all produce a result still. it's only the consumers of the data that care about whether e.g. the p-attendee value is an h-card vs a plain string or some other things
#AndySky21I will try and search something. as a baseline I put a suggestion on h-event to list p-attendee as standard rather than experimental and maybe use it for rsvp.
#AndySky21for what i know event always list participants along with participation status (e.g. by groups)
#aaronpk!tell tantek h-event needs the change control section that h-entry has