And that’s not a kind of changing the layout?
So having a card in “small” and “big” is a different layout, but “text with media, floated left” is the same layout as “text with media-block at the bottom”?
Don’t get me wrong: I just wanna clarify, which field has which intention. And - maybe - which fields have the same meaning.
We do not use the mentioned CTypes in any of our projects. We do use the Table CE. But it has a major problem: it is very difficult to add links (or even not possible). Therefore, this could be another CType which should be moved.
The only field we use is “layout”.
While reading through all points made here I will try a more disruptive approach.
Please bear with me on this one, but I will start with a few harsh, but ugly truths.
If you want TYPO3 to be around for the next 10 years, you need to take the concerns of people outside of the TYPO3 ecosystem seriously.
9 times out of 10 you aren’t even in the same country when the decision against TYPO3 is taken.
So it boils down to what you consider more important to you:
a) Spending 15 minutes to add 4 fields to TYPO3
or
b) TYPO3 slowly but surely going down as “that complicated thing from Europe”.
Because that’s technically what we’re talking about here.
The first step to solving a problem is admitting there is one.
So I genuinely beg you all:
When you weigh in here, consider what’s best for TYPO3, not what’s best for you.
@dermattes Sorry, I have to disagree for me personally. If I want a framework where I have to do everything myself, then I use one. But that’s exactly what I don’t want, that’s why I use TYPO3.
According to your arguments, I would then also not need Languages… Or workspaces, or or or, access rights for users, editlock, fe_login_mode, who needs that? you can also omit everything.
For those who are interested, thanks for this to @just2b , I think a few more people see this there 
!
https://www.facebook.com/groups/250938618364487/permalink/4027815397343438/
For an experienced integrator it is only 15 minutes, but for a newbie it can take much longer and that can be the reason why TYPO3 is seen as complicated.
For a new project I always think about which fields of pages and tt_content are actually needed and hide all the others. But it’s mostly other fields than the ones mentioned above that I don’t need. What I want to point out is that the needs are very different and it should still be easy to realize individual wishes.
I don’t know if this is technically possible, but I could imagine that it would be very nice if the standard TCA was very slimmed down, but had a lot of options that a newbie integrator can unlock with a few clicks (feature toggles). This way the system would be very clear by default.
Or maybe the layout field could be hidden if the integrator has not set up layout options for the content element (or pages).
First off:
Nobody talked about taking “everything” away.
So from that POV I’d kindly ask you to stick to the topic at hand.
This is about removing fields that don’t to anything, unless someone specifically makes use of them.
pages.layout would be a good example.
If you do not specifically use it in your projects, it just sits there doing nothing.
I would like to go through your other arguments one by one, since I think it’s a good thing you bring those up.
Your argument about languages is also halfway false.
I say “halfway” for a reason:
To be able to compare the two (non-functional fields and languages) TYPO3 would need to come with n languages readily configured out of the box.
The Page module would have to show “Translate page to…” even though there are no languages to translate to.
It does not - which works towards the goal set out by Georg in the first place.
Workspaces can be enabled if necessary, they don’t come as part of the standard TYPO3 install. So no clutter for new editors here.
Access permissions are never exposed to editors within their regular editing workflow and are available either through a dedicated backend module or via the list module and PID 0. No clutter for editors here.
editlock is a great example for me of something backend related that should be enabled via config. It solves an edgecase, thus: I’d like to get it out of default views (maybe even put is somewhere completely different).
fe_login_mode is something that I think should be bundled into fe_login. The only reason it’s not in there is that technically logins are processed within TYPO3 regardless of whether fe_login is installed or not. It’s a technicality only few people know so I’d argue that bundling that into fe_login is a feasible way to get rid of it if unused.
So again: nobody is talking about removing everything.
I get that the discussion is heated because of things you are used to being challenged.
I know you’re an emotional person, just as I am - but I also know you’re a clever person.
I am also sure you don’t really think Georg is trying to remove every field from TYPO3.
Taking your argument to the other end of the extreme: Would you argue that we should add a couple dozen fields to core because somebody might be using them?
Followup to make clear, what I’m trying to achieve:
I want fewer fields in the Form View of a content element.
So let’s take spaceBefore as an example.
I don’t think you need to see that field while you are editing a headline.
That doesn’t mean the field needs to get dropped from the database.
Imagine a page module which allows you to drop a divider handle between two CEs that sets the value of spaceBefore.
Or imagine not having frame_class as a selectbox in the page view and the editor could immediately see the frame class applied.
Or (the fastest way): Imagine TYPO3 shipping with 10-20% of fields in tt_content being hidden via PageTSConfig and you just enable what you need.
FollowUpFollowUp:
Imagine a graphical interface to enable fields that are hidden by default.
That’s the level of strategy I’m on here 
In order to get a useful installation, I always have to “turn off” the fields which are not needed in that particular instance…
That is why people say T3 is too complicated, they have too much visual noise in the UI.
It would be great if we could develop the “Minimum Viable Settings” for a minimal installation,
with sensible settings for editors, admins and maintainers.
So fields which you might need have to be activated. Or Integrated by oneself.
Concerning the CTypes,
I’m with liayn here (https://decisions.typo3.org/t/remove-outdated-ctypes-and-fields/745/17)
I would go even further and suppose a new reduced markup and styling for the default Textmedia elements,
display:flex for the win here!
On your followup - yes - a good TSConfig will be good start here.
Best Regards, MT
imageorient is more specific, since it will be used for the positioning of images only, while the surrounding layout still could be changed. The card example would be “refined” by imageorient i.e. to position the image within the default/small/large cards.
With just a single layout field, this would mean 12 different layouts. Numbers would grow exponentially with the number of options per field.
Basically this is similar to the difference between having just umpteen different backend layouts for pages and adding refined backend layouts to structured content elements i.e. by Gridelements, Flux or Container.
Although I’ve seen some of the mentioned cTypes and also fields in usage in projects recently, I’m totally fine with the removal of all mentioned cTypes and also the layout, frame_class and linkToTop fields. Adding new useful cTypes as @benni suggested also makes sense to me.
I also agree with @dermattes, that we should really focus on what is best for TYPO3 and in my opinion, less is often more. Having a lot of (sometimes not self explaining) fields in TYPO3 core by default is overwhelming to new users. I’ve seen a lot of projects so far, where integrators simply “forgot” to disable unused fields and this may cause editors to be “afraid” of doing something wrong in the system and resulting in the “TYPO3 is too complicated” statement.
A little bit off-topic: I think a slim, well documented and easy to understand (default?) sitepackage/theme in/for TYPO3 could reveal TYPO3s flexibility and extendability (e.g. new tt_content fields) to new integrators.
Agree with the removal of the CTypes, especially if I think about the obvious duplication of textpic vs textmedia. Maybe “divider” is the most useful of the group
About the fields, I don’t know… I think they’re somehow useful but they always require some degree of customization to adapt to your needs (even re-labelling them)
I would keep the “to top”, maybe
I guess that also the layout field in pages should be removed, too?
Alternative options that come in my mind?
a) Hide these fields using tsconfig by default
b) add a sysext (disabled by default) that adds the fields (kinda filemetadata)
@sklein it should be possible to build a gallery without breakpoints using display:grid IIRC; have a look for example at: https://css-tricks.com/look-ma-no-media-queries-responsive-layouts-using-css-grid/
For an experienced integrator it is only 15 minutes, but for a newbie it can take much longer and that can be the reason why TYPO3 is seen as complicated.
Doesn’t matter if the fields are there or not, for a newbie who’s on his/her own, it will be complicated anyway.
The docs keep getting better every days, and there the newbies will find how to do the things. With or without that fields.
I fully support the move of content elements.
In my case i did not really understand the existence of textpic and textmedia as textpic seems like the worse version of textmedia.
Also upload and table could be moved i guess
We dont use the section, frame etc fields, but i would guess other people do, so not sure about that.
With extracting them into a 3rd party EXT i don’t really see a problem with the move as they’re not gone and you can install them, if needed
I’m fully on board with that exact perspective.
@just2b may I ask what you’re trying to do here? My answer to your question might depend on your intention.
If you’re trying to reduce the complexity of maintaining the TYPO3 core: Drop those fields and move them to a 3rd party extension. I’m perfectly fine with that.
If you’re trying to make the backend simpler for beginners: Hide them by default. I’m perfectly fine with that as well.
If you’re trying to shrink the default data structure (by removing the fields from the database) but not necessarily push them out of sight while maintaining the core: Move them to a core extenson that is not installed by default.
I 100% agree with everything Mathias said. Slimming down the UI especially by removing stuff that doesn’t work by default will be an improvement. I’m happy with the general direction here but I can’t speak for other situations than the projects I am involed with. And every option will do the job.
To me the idea of having individual content elements as well as barely used fields in individual tiny core extensions makes the most sense. Not having them present in the UI as well as not finding them when browsing the database is a plus for both, editors and integrator. But providing those fields and content elements just by any 3rd party extension might lack a certain impression of completeness while having them available in extensions within the TYPO3 namespace will communicate that everything is taken care of.
Regards,
Stephan.
A bit of everything:
All of that should lead to a better experience for all of us. Just hiding it with tsconfig still adds e.g. complexity for tsconfig and e.g. setup of permissions
you raise a good point here.
One thing worth a look is how JIRA handles that. The tl;dr is that a user can decide which fields to show of the ones available to them.
Translating this onto TYPO3 I’d argue that fields hidden via TSconfig should be declared as not visible to a user.
Now this opens topic B, which is “How hard/annoying/complex/difficult is it to make fields hidden by TSConfig visible again?”
I could imagine a GUI for that.
Most of the time I like to tailor the content elements to the project and therefore use custom ones instead of the default assortment (and keep a collection as some kind of kickstarter for new projects). Coming from this angle I don’t care too much which content elements get dropped and which stay.
But what I appreciate greatly is the predefined database fields, which can provide a reasonable expectation of what the custom content element contains to another integrator who might pick up the project at a later date. As we all know, naming things is hard And familiar conventions have a strong pull. Everyone having to create their own fields for more or less common functionality may be too messy for my part.
Providing the basic content elements as individual packages and allowing for a mix-and-match approach is an idea I find very compelling. And as it was mentioned already, some introductory collection of those packages would be very beneficial to newcomers (who can then replace what does not suit them easier at a later date) and provide a nice baseline.
So yeah, I’m all for streamlining the experience but on the basis of configurability and extendability. Because in my experience these are very big selling points of TYPO3.
Here we are
yes if at all, i would also be for switching fields “hidden”, but NOT kicking them out.
Yes I’m so emotional, because here is argued with arguments, with things that would not have THE big impact.
But there would be quite other construction sites (in my opinion), which are not touched, but which would address exactly these arguments, which I think are wrong here. Like for example “TYPO3 is too complicated”, so no idea but a field that default has no impact, in how far that is “complicated”, does not really want me in the head
Whereas TypoScript + Yaml, already, or also the still missing for editors translation module -dings for forms.
Or content elements that you can add to Extensions in the ListModule, but then also see in the SiteModule view. ← That is surely also confusing…
To the other punk, Workspaces:
Yes but it is included, so if that is outsourced to an extension but included by default ← fine by me, but then I don’t see the advantage (looking at the first sentence in this comment).
And still the fields ctype and languages:
Yes I understand that these are needed from a technical point of view, I just don’t understand why I can’t make them “hidden” even at the current time?
I didn’t look into it, but it seems that if I make these fields hidden by TS, they are not only hidden, but also the function behind them is gone…! But I would like to switch them off, because about half of our customers are monolingual and almost no one can do anything with “ctype”… xD
The bookmark feature I find totally good, have also often tried to establish that, but somehow that does not seem to prevail, so neither with our customers, nor with our own in-house editors… could also be gone from me.
What I’m getting at:
a) standard fields offer the possibility to use this standard - that means, theoretically, that there is this standard across ALL TYPO3 installations. This can not be intentional?!
b) I’m pretty sure (even if I don’t know of course) that at least as many installations use the mentioned fields as those that don’t, maybe even more (since there will be more small “cheaper” installations than highly customized ones).
That’s why I think this discussion is a waste of time, as long as nobody can give me a good reason, which offers a REAL added value for the developing TYPO3 team or for those who finally build something with the system, for themselves or their customers. Just because, these fields already now and in the past could be switched off. Say if an editor has actually argued that he finds TYPO3 complicated because of the many fields without function, then from my point of view, not TYPO3 is to blame, but the one who has screwed the system together for the customer…^^
Addendum:
a disadvantage of the “Opt-In” method comes to my mind, which I think would affect just “newbies”: If all “unnecessary” fields are hidden from the outset, then one believes possibly that the one or other feature is not built in, there is this not, and or you have to retrofit it yourself.
Should not forget that what you have in mind - no matter how - is a double-edged sword, quite independent of the possible effort for “pro’s” of the system…
What do you think about a small “is there more I can do” link at the bottom?