A quote from my Slack chat with @wojtekidd:
It may be a stupid question, but I'll risk asking it:
Looking at the gif below, will it be possible to align images only to one side?

I was already asked about this by @wwalc, @pjasiun and @wojtekidd.
I know that it sounds totally correct for us (and was supported by votes) that, by default, we should offer a single "side image" style. But it's pretty obvious that our "generic side" (as opposed to "left side" and "right side" :D) is really confusing for developers less used to think about content semantics. In CKEditor 4 the most popular option was config.allowedContent = true and in CKEditor 5 it will be enabling the align left option :D.
I'd like to start this topic (before the community starts it), but I'm personally ok with our current choice. Content filtering in CKEditor 4 was also confusing and perhaps most of the developers turned it off completely, but it was a huge step forward and very important innovation. We certainly raised developers' awareness and image styles (not "image alignment"!) would help too.
PS. Medium also has only one style for aligned images. However, no one seems to notice that. @pjasiun was really surprised when I asked him to check that :D (I wasn't sure too). But if you think about this, it isn't a big surprise. If the options that you're given match the overall experience you're fine. You don't expect such features as a user (most of the time). You start analysing such things when your "developer" mind kicks in and changes your PoV.
cc @fredck and @oleq.
I was just trying to foresee the answers to questions I will get from users/customers ;)
I am perfectly fine with current solution. It's smart and easy to explain. CSS should be used to set the image to the left or right. It's always difficult to fight opposition who "is used to things". People will see it as a "bad change", but I think our approach is correct.
Funny because "I'm sure you can set it in CSS" is always my first thought when "something is missing" in the editor 😄
Funny because "I'm sure you can set it in CSS" is always my first thought when "something is missing" in the editor 😄
And that's totally correct :) It applies to image borders, heading colors, text font size, table borders, lists numbering (in most cases), margins between paragraphs, line height, etc. All these are styling options and should not be available to the user of an RTE. They should be defined by the developers who provide styling for the content which users create.
What we're really doing here is dropping the image alignment feature, not simply removing one of the alignment options.
A bold move, we know, and just time will tell us if we are right. We'll not be able to re-think this before going to market with it.
What we're really doing here is dropping the image alignment feature, not simply removing one of the alignment options.
A bold move, we know, and just time will tell us if we are right. We'll not be able to re-think this before going to market with it.
We're dropping it conceptually, but configuring the editor to allow for aligning images will actually be simple. Plus, it'd be possible to add the "left side image" style to the default setup if we see that it's really bad ;). So I don't think that we can't do anything. We just don't want to do anything.
That's fine, but me and @wwalc dips on the Stack Overflow question and answer about how to align the image to the left. Hope to get more points that question about allowedContent: true :)
IMO we should be bold in what we do in CKEditor 5. If this content semantics is the right thing to do (it is!), we should go for it. In other words, I'm for what we see in the gif.
I will just paste it here: https://en.wikipedia.org/wiki/Groupthink
I got your point, @wwalc but it brings little value to the discussion. There's no way we could confront our ideas with real–world integrations before alpha or, most likely 1.x, like 1.2 or even later. So what we think is right is the only factor we can take into consideration when implementing features like this. CKEditor is a developer–oriented software and there's no way to ship a beta to hundreds of devs, ask them to put it... where exactly? production? and harvest some good usage statistics and impressions from end–users. We're alone, whether we like it or not.
I added it just to underline that what you all agree about, will match precisely just one specific use case and that you may not see it. The world out there is full of people that expect different things. Based on the stats we have for our websites, for example we can notice that the document editor is more popular that the article editor. Same with presets, where full is equally popular as standard.
I completely understand the attitude towards having a really nice, semantic editor. My point is that, having the possibility to easily provide another version of editor, that will fit another large group of users (and will work out of the box, without having to do custom stuff) I completely do not understand why we don't want to do this.
Groupthink requires individuals to avoid raising controversial issues or alternative solutions, and there is loss of individual creativity, uniqueness and independent thinking.
We raised the issue, so we're safe!
(just joking ofc)
I completely do not understand why we don't want to do this.
Because we don't want to do this just based on assumptions. We can do this at any time later, based on feedback.
Note that our approach to CKEditor 5 is exactly what it differentiates us from others. This is innovation and it is not an easy path.
It is already understood that one of the most important tasks when marketizing CKEditor 5 is "educating", instead if "selling hundreds of features".
Because we don't want to do this just based on assumptions. We can do this at any time later, based on feedback.
But the current feedback is that fully independently, 3 people, out of the group of maybe 10 people who checked it out but was not working on that feature, ask the same question. What kind of feedback do you waiting for?
I would not be scared by "groupthink".
We know what is "current standard" and we know what are people expectations. Heck, we even know what we had in CKE4. We know that our proposal will rise issues and we might need to fix it later. So we are not doing anything just to not stand-out, rather opposite.
As far as we are concerned, I don't think that anybody here would agree with anyone if they had another idea or thought something is wrong. I am sure that everyone will drop their doubts here, and we can discuss them.
Let's just do what we think is right and see what's the outcome. We won't learn anything if we will do things like we've been doing for years. And we won't teach anyone either. BTW. this new approach has it's advantages, too. It's completely CSS-dependant (as far as I understand it :P) which may cause less problems for developers than if it would have some "hardcoded" floats and margins.
Worse come, we will add one more button and re-name them to "left-side" image and "right-side" image and give them floats and margins. 🤷♂️
My point is that, having the possibility to easily provide another version of editor, that will fit another large group of users (and will work out of the box, without having to do custom stuff) I completely do not understand why we don't want to do this.
But we do provide a version of editor which will fit those groups. Just the default setting won't.
But the current feedback is that fully independently, 3 people, out of the group of maybe 10 people who checked it out but was not working on that feature, ask the same question. What kind of feedback do you waiting for?
Your feedback is that you are surprised, not that it doesn't fit your use case. So it's not the kind of feedback that we'd be waiting for.
OK, I consider this a closed topic. To sum up:
I e-mailed my work account this URL on Jan 18, and then lost track of it. Dammit.
+1 for "image styles" as a concept.
Drupal has used this for _years_, albeit on a different level. Image styles in Drupal are about resizing, cropping, applying effects (e.g. black and white, invert, flip, blur). Drupal ships with several image styles by default. For example "thumbnail", which scales images down to fit within 100x100 pixels.
langcode: en
status: true
dependencies: { }
name: thumbnail
label: 'Thumbnail (100×100)'
effects:
1cfec298-8620-4749-b100-ccb6c4500779:
uuid: 1cfec298-8620-4749-b100-ccb6c4500779
id: image_scale
weight: 0
data:
width: 100
height: 100
upscale: false
I think it makes sense that "CKEditor image styles" are about the styling (layout + borders + …) of an image. "Drupal image styles" are about image manipulation, which CKEditor obviously can't do.
We've started creating concepts for the demos for the new website. When it comes to Inline Editor demos we've chosen to go for a Newsletter creator use case. We will be trying to create a simple newsletter mock ups with a couple of blocks of content. Since one of the most popular layouts of newsletters is that with an image on the left and the title of the article + introduction and link on the right, we realised that we can't align images to left with the default Inline Build.
Couple of questions arise: should we enable aligning images to left? should we enable this only in this example (if so it won't be an example of the Inline Build)? should we forget about it and come up with a different design that won't spoil the show?
I don't know how many more other use cases might need this functionality, but it seems to me that the Inline Build one might need this one by default. WDYT?
WDYT?
You made a good point. In your scenario you seem to need a single style of images (images on the left). In such case perhaps you don't even need multiple image styles to pick from, but just the one which your layout allows? The image might be styled as you want by default using an external stylesheet.
Of course, your layout may also be less strict than that and may allow images to the left and to the right. In such case, you should configure the editor (config.image.styles) to allow these two styles.
Finally, you may need also the full-width image or some constrained-size ones for hero banners. We don't know. That's why the editor allows configuring the styles instead predefining the ones you can choose from.
The default image styles that we propose (full width and side image) are just an example how the editor can be configured.
But the main point of the demo on the site is to showcase the Inline Build (next to Classic and Balloon) so I guess this goes deeper. We can't just change the features of a Build for the sake of the demo - or can we?
But the main point of the demo on the site is to showcase the Inline Build (next to Classic and Balloon) so I guess this goes deeper. We can't just change the features of a Build for the sake of the demo - or can we?
This is a topic beyond this ticket, so we should move it to some other place. But from what you're saying you're not demoing a build as it is. You're demoing a build's adaptation to some scenario. And every built editor has config options to use – e.g. the layout of the toolbars, image styles, etc.
So just to understand it right - Inline Build in CKE5 is the same as it is in CKE4 Inline mode (we have different editors with different features per instance)? If so then it's fine with me - we'll just need to add aligning image to right in one of the editors instance and that's it.
Aren't so just missing an easy way to change the "Side image" icon so it shows as a left aligned box? I mean, just an icon change, not the style itself.
Most helpful comment
I will just paste it here: https://en.wikipedia.org/wiki/Groupthink