My personal opinion, publicly stated before, is to kill everything that is design related from the forms. Forms are there to serve the data editing. Editors ARE NOT necessarily designers. It's about time to separate these two areas for the benefit of all. Stop being afraid that you will break Joomla, it's already broken!

@ciar4n i can tell you you'll anger a lot of folks by removing that "feature". The intent of that function has zero to do with the template per se`, nor does it interfere with it, it has EVERYTHING to do with article layout which should be template neutral.
It's the templates job to layout the site, the articles job to layout the content. I realize that flex, grid & other dynamic css manipulators make it seem useless but imo a template should not dictate to the article how it should be laid out.

the articles job to layout the content.

@N6REJ NO. HELL NO! Article shouldn't be doing any layout or design decisions! This is utterly wrong

imo a template should not dictate to the article how it should be laid out.

You got it wrong! Template is the ultimate dictator for the presentation, by design!

As long as we support a WYSIWYG style edit view, there will be design decisions made in these backend pages as it relates to content display. And rightfully so, this enables users who are not capable of maintaining their own templates to make simpler design changes to affect a certain item's layout.

So no, we can't arbitrarily strip every option and tell users "to change how an image is displayed for X article you're going to have to make a layout override and do all this complicated stuff with PHP and HTML". That is the compromise of a distributed CMS platform, as much as a lot of us hate it, there are going to be options for things that we would much rather just be done in the template and make it impossible for an end user to affect.

Ok. My mistake then is to assume that this is an image associated with the article rather than an image inside the article. If that is the case then why does the image field even exist?? If you want to be WYSIWYG then have users add the image using the WYSIWYG editor that is there!!

Those are the images that display outside the content area (so they're still part of the layout, but if the user wants to have some things left aligned in one category and right aligned in another category, how do you pull that off without the override stuff I mentioned?).

@mbabker all @ciar4n is asking here is to drop the inline style for a class, if we don't want to drop this option altogether (which I'm in favour, overrides is the right solution)

I just jumped onto where this discussion was going. Yes, a class is preferred to inline style definitely.

Just add the appropriate class to an Image Class field (BS4... float-left).

What if you want to display the image after the content? What if floating the image breaks article content next to it and you want to use flex? What if you want the image placed behind the text as a background? What if you want to proportion the image differently to the content they are alongside? What if you don't want text to surround your floated image? What if.... What if....

Changing this field to an Image Class means you can do any of the above and more to the categories/articles of your choice.

There's only so much we can do in the UI sanely before the user just has to get into maintaining overrides. So to me it's all about finding a balance. I'd like us to not have options to dictate the HTML tag something is displayed within anymore (module settings), but completely removing anything that can help the user make small display changes seems a bit excessive. That's really all I mean to communicate in the end.

but completely removing anything that can help the user make small display changes seems a bit excessive

I never suggested we completely remove it. Just change it to something that doesn't restrict us to floating these images. Something that doesn't shoehorn template developers in to a particular layout practice if they don't want to break this option.

You can not float elements inside a flex object so this field also dictates the display property of any article container. These 'small display changes' have far reaching effects that we should at least consider.

Agree totally. But when the thread starts having commentary about removing "everything that is design related from the forms" something's gotta be said to make sure expectations are managed.

This proposal is fine IMO.

closed as having PR #17402

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/17399

@dgt41 the day a cms decides the html / css I've put in my article is irrelevant is the day I find a new cms.
Template is like walls in a house, NOT the interior decorations. What the furniture looks like that I place in the room is my business not the templates. Thats the whole point of a cms is to have the articles UNTOUCHED regardless of the template. If I want my image floating left instead of right in my article that is my business!!!

@ciar4n i don't mind the float but your right in that there can be other possibilities then just simply float left/right. Thankfully we can do that with article class suffixes, but that makes the float param irrelevant, so I agree with you there.
As for not being able to float with flex thats incorrect. I can place a element anywhere within the row I wish too. Not only can you apply offsets, but you can change the order on a row / column basis. In & of itself flex does not' control the order, it only controls the flow, nothing more.

imo styling should be controlled on a hierarchical basis just like .css does.
in reverse order here...
Framework - ultimate fallback.
Template - overall architecture of the site.
Layouts - Overall architecture of the page style.
Article - ultimate item layout/design
custom.css - overriding master of all.

Anything less is dictating the user is wrong and doesn't know what they want.

As for not being able to float with flex thats incorrect.

You will find the flexbox spec at the following URL which clearly states the float property will not float a flex item.. https://www.w3.org/TR/css-flexbox-1/#flex-containers

@ciar4n correct, "float" doesn't work, HOWEVER , flex does have the ability to put anything in any place within the row even reordering, which takes the place of the float.

This should probably be re-opened since #17402 is closed.

Just as an information: While the parameter is called "Float", the code actually only applies a CSS class. It's pull-left, pull-none and pull-right. It's done in a JLayout so it's fully customisable by the template.
See https://github.com/joomla/joomla-cms/blob/4.0-dev/layouts/joomla/content/intro_image.php and
https://github.com/joomla/joomla-cms/blob/4.0-dev/layouts/joomla/content/full_image.php

That was already the case in J3.

True. My original issue thou is with the field itself, not so much the JLayout.

please test #31017