[cleverdevil], nitot, KartikPrabhu, [keithjgrant], [acegiak_net], davidmead, KevinMarks, KevinMarks_, [scottgruber], uf-wiki-visitor and AndySky21 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.
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.
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
AndySky21like e-spoiler : part of content giving potentially unwanted information about the original subject, not to be shown unless allowed by the user
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?
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.
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.
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
aaronpkfollowing http://microformats.org/wiki/process the thing to do would be to analyze how existing event websites list attendees and people who said they can't come, etc
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.