💡[IDEA/DRAFT] Introduce the .prose-bleed feature

[neupauer]

This PR introduces a feature that allows content to overflow the width (65ch) of the .prose container.

Useful for displaying content that may be wider than the text itself: images, videos, iframes, etc. I also think it would be useful in combination with the .unprose feature ( described in #32 )

Links:
https://css-tricks.com/full-bleed/

[RobinDev]

I like the idea (I actually use the same way with tailwind class directly inlined w-screen relative left-[49%] ml-[-49vw]).

Seeing your PR, it makes me feel weird to do and undo adding more and more css rules.

Maybe a solution would be to not set prose max width but children only and disabling the max width if the child element contain not-prose or w-full css class :

.prose > *:not(.not-prose) {
    max-width: 720px;
    margin-left: auto;
    margin-right: auto;
}

Good Point : it's permit to remove 1 encapsuler block (<div class="bleed"><div class="max-w..." to <div class="not-prose max-w... mx-auto)
Bad Point : this solutions is a breaking change (but I think the biggest part of users will not notice the move).

[adamwathan]

Hey thanks for this! I think I'm going to say no to this specific feature for now for a couple reasons:

1. Using grid means margins don't collapse between elements, and the current typography styles deliberately rely on that feature of CSS.
2. Adding new APIs is always hard because it's so difficult to really decide on the exact naming and the exact behavior. If we make a decision we later regret it's painful to fix because of breaking changes, so if we can solve the problem without new APIs that's usually preferred.
3. With the latest version of the plugin you can use not-prose to get a lot of control over how child elements are rendered, so it feels like this is easier to do now without new APIs.

Here's a demo as well of accomplishing the basic idea by adding utilities to a figure wrapping the img:

https://play.tailwindcss.com/NmqvR6QhUK

Anyways thanks as always, do appreciate the contribution! Just don't want to increase the API surface area right now. Can always revisit in the future of course — way easier to add new features than remove existing features so always have to be careful to only add things we're 100% on.