.Resize will soon be a major template feature but is currently limited to .Resources.
Just wondering if broadening the availability of the feature to more than the .Resources package (page bundle) is on a the road map ?
Couple use cases (including default page header image using the <picture> element) comes to mind…
The answer to your main question is “no”, but my question is what a “e<picture> element” is?
No idea why discourse is adding this e but something like this:
Too bad. This makes only images added by the editor “resizable” not the ones used by the theme dev.
You think about this the wrong way.
There are plenty of reasons why the images are Page Resources. Many unrealistic designs have been proposed over the years (parsing the output looking for special image names, processing every image in static with a special name etc. etc.).
The images as Page resources is an extremely simple mental model, but is also very fast and easy to track (when you change the original of an image, every processed version of it gets automatically regenerated etc.). Kinder surprise.
Your problem is really that a theme cannot add content
Which is on the road map (there is a GitHub issue about it).
I understand that, as both dev and editor I don’t want authors to mingle with the static dir. I want every images to be included in the bundle of a post and no where else. Really Page Resources is an amazing feature which will change the way people build theme and edit content.
The use case I used was for a default image to display (and process the same way as the others) when the bundle doesn’t have one. Where else could I store it but the theme’s static dir ? Even if the user can define its own default image, it would still live in the static dir (unless we make a config bundle of some sort)
Yes if a theme could add content I guess this would solve most of the use case I could come up with but not the one I mentioned. We could not add the same asset to every post bundle created.
I was not able to find the issue on GitHub, can’t wait to read more about it though.
Why would you need to do that?
I’m writing this fast and this isn’t something I have thought through, but:
In /mytheme:
/content/_index.md
/content/myheader.jpg
In theme’s header partial (or whatever):
{{ $header := (.Site.Home.Resources.ByType "image").GetMatch "myheader*" }}
{{ $resized := $header.Resize "200x200" }}
<picture>
...
</picture>
When I say that the other thing isn’t on the roadmap means that I don’t currently see the need for it, and we should have really good reasons to burn another 100 hours of dev time (+ added maintainance cost) adding some other complex beast.
Ok so first I need to get my head around this home bundle possibility which I was not aware before reading your answer. (I used to store the bundle in a headless page and use GetPage to pull it from the Home template)
Even then this would not be a suitable behaviour. As I want the author to stay out of the theme directory, I want the dev to stay out of the content directory. Those world should not collide.
Obviously I didn’t think it was such a lengthy operation. In this case, I agree it is not worth the trouble and will do without.
I suspect we don’t understand each other.
my-site
├── content
│ ├── _index.md
│ └── my-image.png
└── themes
└── the-theme
└── content
└── background.jpg
GIven the above, there may be naming conflicts that need some rules, but there is nothing in the theme above that the “author” needs to care about.
Now I get it, sorry for the confusion.
I would love the theme to get its own content folder and resources.
It is still difficult for me to understand the difference between images being stored in content (become resources) and images stored elsewhere. But educating me may take too much of your time and this is for another topic I suppose.
We have to know where to look, is the main point of it…
And it will end up as resources attached to a page, so putting those in the same logical place makes total sense to me. Not sure why people are so upset about putting image content in … /content.
More than 99% of images are attached to a page. So I am not sure either why they are upset about those, beside having to rework their editing workflow.
But for the less than 1% images that are used throughout the site. (I know we use less and less images as logo/icons etc… but some may still find their way in outside of content)
Well I think they just wished they could use .Resize on them 
But I can also see why there is not need to put too much efforts for <1% of images
You should never say never. There is a person on the GitHub repo thinkering about assets fingerprinting, which may be a use case for ad-hoc resources.
But the person implementing that will have to think careful about his design. It is easy to “get working”, it is not hard to get fast – but it can be tricky to behave nice with current and future partial reloading.
Also, if you have some images that don’t really belong in a page context, attach them to the home page (which represents the site).
When the theme has a content dir I will do just that, but in the mean time, I cannot expect the user of my theme to add those images to content/ himself 