p-content-warning proposal

[jk-na]

This is an initial proposal to introduce p-content-warning into the mf vocabulary.

An example use case would be in syndicating to the mastodon api, the existence of the p-content-warning property would indicate that the p-summary or e-content contains content which maybe construed as sensitive.

The text contained within the p-content-warning tag could be mapped to the ActivityStreams2 subject field or entry.spoiler_text and the result would be that on the receiving platform the p-summary or e-content would be collapsed in a similar vein to <details><summary> in html.

I initially raised a ticket for brid.gy and the topic has subsequently been discussed on https://chat.indeweb.org/microformats

There is an indieweb.org page about this topic too: https://indieweb.org/content_warning

[jalcine]

I’ve flagged this as something that Koype Publish will be implementing and for Koype to publish. The only bit would be a reader to consume this but technically, letting Bridgy use this (via snarfed/bridgy#952) would be a broader consumption case.

(Originally published at: https://v2.jacky.wtf/post/d3803dd7-8a6e-45b2-99be-8c85b7444471)

[vikanezrimaya]

I've had this exact idea over 1.5 years ago! https://fireburn.ru/posts/1544785813 (quoting below, my site is currently down for maintenance and renovation):

I think IndieWeb needs more content warning like in mastodon. I propose p-content-warning for this and I'll try to implement this at least on my own website.

This was also syndicated on Twitter (https://twitter.com/kisik21/status/1073535641919647744).

This is currently not included, but was included in a previous iteration, here's the link to the template snippet on my Gitlab.

[fluffy-critter]

I like this, I’ve used <details><summary> as the implementation of a content warning on my site for quite some time. Would the microformat for this case simply involve putting a class of p-content-warning onto the summary element?

Also I assume this would just apply the content warning to the entire entry, but what about entries where only some of it is covered by a content warning? (For example, a review of media where one section contains spoilers)

[jalcine]

Good question re: partial content coverage. This was meant to make the whole entry as sensitive (it’s mimicking the approach / reach that Mastodon uses with summary). I do like this specific case of perhaps hiding a photo of a photo post but not hiding the text. That might be up to either a reader or a site to decide on the granularity. I know I was planning to hide photos if this property was present but not the text on my site.

(Originally published at: https://v2.jacky.wtf/post/c58a799c-67ac-40a6-b4e2-46d4c19b5622)

[jalcine]

That said, I think you can get that kind of coverage if the entry is marked up to have children and one of the child entries are the ones marked with the p-content-warning. I know that’s not as smooth as a <spoiler> tag.

(Originally published at: https://v2.jacky.wtf/post/78f1f800-4bc3-4caf-9baa-b09c7a178732)

[jk-na]

Very happy to see and learn about the different ways that this property could be introduced! I hadn't much thought past the syndication out to the mastodon api, but I do like the idea of being able to blur\shield\hide parts of a syndicated message.. and it's certainly something I've been considering for my own fledgling, indieweb-ish site.

As a complete novice in microformats, should the cases above be represented by just one property? or perhaps a parent <-> child pair.. perhaps for the likes of brid.dy to mastodon, due to the limitations of the recipient they'd acknowledge the parent property but for other readers or clients they'd be able to parse the child properties and appropriately render the content?

[fluffy-critter]

One thing to keep in mind is that the microformats should be in addition to whatever HTML markup is suitable for your presentation; <details> is already a standard part of HTML and in principle should still be rendered through as the e-content on an item. The p-content-warning is there to introduce additional UX for other readers that might support other things (for example, a Mastodon reposter, as in your original use case).

I believe that you can nest multiple h-entry items inside a single h-entry although I have no idea what the implications are for existing readers or what it means for how the content gets displayed and in what order.

[toby3d]

I understand the idea, but I don't understand why this parameter provides for free-form values to describe the content? As previously stated, summary/description is fine for that.

More often than not, when I want to publish "unsafe" content, I want to describe it as briefly and clearly as possible by toggling the property between "yes" and "no", without detailing the descriptions. I propose to make the description of unsafe content optional, in favor of a simpler but unambiguous binary parameter. If the content is safe, it doesn't require a warning. If the content is unsafe, it should be marked accordingly first and, maybe, described in a warning second.

This becomes more important in the case of feeds that have to be unambiguously defined as "safe" or "unsafe" with respect to all the content in them. The presence of a warning in a feed cannot describe the content accurately enough, being limited to general descriptions such as "violence", "nudity" or combinations thereof, making this parameter practically useless.

[fluffy-critter]

Things that are safe for one person aren't necessarily safe for someone else though. For example, a very common content warning on Mastodon is "food," because a lot of people have issues with being shown images of food without warning, especially if they are dealing with an eating disorder or have certain sensory triggers.

Another similar thing is talking about potentially-triggering subject matters such as mental health, politics, etc. Those topics aren't inherently "unsafe" but they're things that folks might want to avoid.

The concept of whether something is "safe" or "unsafe" is not a binary. Having a simple flag doesn't tell anyone anything of value; the presence of a reason why something might be unsafe is a much more useful mechanism.

I also don't see how this is possibly a feed-level thing; personal blogs cover a lot of different ground and some of that ground involves topics that need content warnings.

[vikanezrimaya]

The whole point of this as a free-form property is for the person reading the entry to evaluate if they want to see it - a simple binary will not empower the user to make a decision but rather strip them of the power - look at how silos sometimes hide posts deemed "sensitive" making them hard to view and not giving users even a summary or understanding of what awaits them behind the "Show anyway" button.

[pdcawley]

This seems to have sat for a while with sense of whether there's consensus on it. As someone who really wants his blog to play nicely with the fediverse, and in particular with Mastodon, some kind of mechanism that can map cleanly to mastodon content warnings would be really handy and this seems to be the candidate that best fits the prehistoric elephant in the room.

[fluffy-critter]

Unfortunately Mastodon's mechanism can never be supported properly without compromise, as they implemented it by overriding the "subject" field on the ActivityPub descriptor rather than defining a new one specific for CW.

[pdcawley]

There's plenty of folk on Mastodon that are essentially using CWs as a subject line anyway. Definitely a terrible piece of naming/appropriation that causes far more problems than it solves. I get that calling it a content warning encourages people to actually add warnings to what's actually the subject of the post, but if it's a "content warning/subject" then better to call it that.

But we are where we are and having some way to markup my posts so that tooling can post appropriately formatted toots based on them would still be very useful.

[fluffy-critter]

Oh absolutely, having a p-content-warning or the like would be great, and if that causes it to get translated into subject when converted to Mastodon, that'd handle the use cases well, and would also have the benefit of long posts getting CWed which is also a common Mastodon behavior/request as well.

[gRegorLove]

I like the idea of this property as something applying to the entire post. Nesting is possible with microformats, but applying to the entire post is the simpler problem we can solve first.

Is there any other prior art (in addition to https://indieweb.org/content_warning) to consider for how this might work, from both publishing and consuming sides? Are there single-site implementations of either/both for the proposed property?

From https://microformats.org/wiki/h-entry#change_control, I think we're still in "proposed" status, but getting some examples of publishing, consuming, and multiple sites interoperating will help advance to draft status.