Make CKEditor (approximately) reflect the rows setting of a field

#507696: Allow individual width/height per field didn't fix this in the more than eight years that issue was open.

The patch you link to as being a solution (#2717599-7: Text editors do not respect <textarea rows>: make that clear in the formatted text field widgets) is a hack that doesn't work reliably in all situations, which is why we didn't commit that to Drupal core.

Really, #2717599: Text editors do not respect <textarea rows>: make that clear in the formatted text field widgets already explored all possibilities AFAICT. I told you at #2788905-7: "Number of rows" configuration on Page Body field not working:

Feel free to open a completely new issue and then summarize what's happened so far, and what you'd like to see happen on top of that.

You didn't say what you wanted to see happen on top of what has already been done, and how you propose we do that, differently from what #2717599: Text editors do not respect <textarea rows>: make that clear in the formatted text field widgets already tried to do a long time ago.

There's no point in asking to fix something that is not fixable, unless you provide some idea for how to fix it.

#6: Sorry, I didn't mean to be harsh. Reading my comment at #5, I of course agree that was unnecessarily harsh.

But I hope you also understand my point: we discussed this at length many times in the past. It's pointless to repeat the exact same discussion. So without new ideas, new perspectives, we'll just end up repeating the previous discussion, which is a waste of everybody's time. That is what I tried to convey, but I did that far too harshly 😥 Sorry! 😔

As we can see in the growing usage of axel.rutz contrib module, there's demand for this fix... I also agree this should be part of core, otherwise this form setting (rows) makes no sense at all for default ckeditor. And yes, there are many cases where you want a small or a hughe field dependent on expected content. Autogrow (in core already) helps if the field is too small then...

PS: The ckeditorheight plugin works like a charm :)

Shell we create a patch based on axel.rutz module to proceed here? The current situation where the setting simply has no effect is much worse than the solution from #12. So I don't unterstand what's the show-stopper here even after reading the linked issues / discussions.

@Wim Leers, would you mind to have a look at the contrib module and see what it does to compate that against the current core behaviour as documented in the issue description? Of course nobody wants to waste anyones time, but I think we can lead this to a fine solution.

I would very much like to see a patch based on the module. I am using the module on all sites now. It is simply providing expected behavior. I thought that when changing the rows failed to change the height, that it was a bug. I didn't even mentally register the "explanatory" text until finding issues about the problem, and still think the explanatory text is inadequate— but the very fact that it was added at all, indicates a need for this approximation fix instead.

I absolutely agree with #18!

Using the CKEditorHeight module too on several sites without problem.

https://ckeditor.com/blog/CKEditor-4.14.1-with-resizing-and-toolbar-impr... introduced new capabilities that may affect this — see https://ckeditor.com/docs/ckeditor4/latest/features/size.html for details.

#3155110: [backport] Update CKEditor to version 4.14.1 updated Drupal to CKEditor 4.14.1.

CKEditor has been removed from core, CKEditor 4 is removed from Drupal Core in 10.0.0

Has anyone tried out whether this just shifts the problem to CKEditor5 and we need a new ticket, then, or if it is solved in v5/solvable by different means?

Has anyone tried out whether this just shifts the problem to CKEditor5 and we need a new ticket

The contrib module CKeditor Height issue queue reports that their current implementation does not work with CKEditor 5: https://www.drupal.org/project/ckeditorheight/issues/3274041

or if it is solved in v5/solvable by different means?

The issue in the CKEditor 5 queue regarding this is https://github.com/ckeditor/ckeditor5/issues/636 , and it doesn't appear that they're providing a solution as of right now. A workaround is referenced in https://github.com/ckeditor/ckeditor5/issues/636#issuecomment-405952805 , specifically https://stackoverflow.com/a/46559355

If we wanted to apply this to Drupal markup syntax, a well-scoped CSS-only solution (tested, works), would be to add min-height declarations for a series of row attributes, a la:

...
textarea[data-ckeditor5-id][rows="3"]+.ck-editor .ck-editor__editable_inline {
  min-height: calc(1.5em * 3);
}
textarea[data-ckeditor5-id][rows="4"]+.ck-editor .ck-editor__editable_inline {
  min-height: calc(1.5em * 4);
}
textarea[data-ckeditor5-id][rows="5"]+.ck-editor .ck-editor__editable_inline {
  min-height: calc(1.5em * 5);
}
...

Being squeamish about such CSS verbosity, I also explored a JS approach that would add the min-height as an inline style (attached file). However, the auto_grow plugin uses JS to adjust the CKEditor window, which would remove the inline style. I can picture some JS that reapplies the style on change, but this would have its own disadvantages.

Unfortunately no browser will currently let us use the rows attribute value in css via a simple attr(rows). But the css verbosity can be reduced somewhat with something like:

[rows=3] {
  --rows: 3
}
[rows=4] {
  --rows: 4
}
[rows=5] {
  --rows: 5
}
[data-ckeditor5-id] + .ck-editor .ck-editor__editable_inline {
  min-height: calc(1.5em * var(--rows, 5));
}

Or a js solution (or Drupal preprocess) could insert the --rows variable in an inline style for css to use.

Preprocessing sounds the least intrusive and most compatible with other modules, to me at least.
I am just a sysadmin, but from what I gather from modules and preprocessing until now, I think this could be put into a simple loop and would somewhat abstract the ugliness of defining every single --rows variable (at least in code, the resulting CSS definitely has the list).

Generally speaking this should make it into core (or core's CKEditor5 module) as a fixed part eventually, not as an additional piece of code a theme or a module adds. This would keep those two parts (preprocessing and applying the CSS) pretty close together, which sounds favorable to me. Splitting the two parts too far apart would otherwise by a little hard to grasp (and understand/maintain later on).