[social]I noticed my footer on my links page (https://vanderwal.net/links.php) has two paragraphs aligned next to each other. I changed the element for the 81x35 to a div and it still is aligning to the right and not below in my footer.
btrem[Murray] missed your reply to my CKEditor gripe yesterday. (Had to go to work.) I use CKEditor in Drupal. But getting the markup I need can be tedious. So I often switch to code mode and insert my markup (composed in VS Code). It autocorrects missing closing tags. Fine, helpful even.
btremBut it changes markup when it isn't necessary. For exmample, I wanted to insert an address in my text using `<div><div>street address</div><span>city/zip/postal code</span></div>`. It insists -- and "helpfully" corrects to -- `<div><div>street address</div><p><span>city/zip/postal code</span></p></div>`. #@?$#! maddening because there is /nothing/ wrong with the markup as entered.
btremEven more maddening, Drupal's CKEditor blocks the paste function. Yep, that's not a misprint. You cannot paste text in a CKEditor. At least, not in Drupal's CKEditor. The only way around it is to again switch to code mode, insert, then switch back. I mean what the ever living #@$@ were they thinking!? Disabling paste?! CKEditor--
btremAnd trying to get around it's limitations, I tried to use a `<dl>` element like so: `<dd>some text <div>address</div> some more text</dd>`. Didn't like that, either. This time, it "helpfully" autocorrected to `<dd>some text</dd> <div>address</div> <dd>some more text</dd>`. Which at minimum changes the semantics, and is I'm pretty sure incorrect markup.
btremI don't mind VS Code inserting a closing </p>. And I wouldn't mind CKEditor doing that. I pretty much never rely on implicit closing tags when I use any editor. I *do* mind when the editor inserts entire elements that are (a) not needed, and (b) mess up the formatting or semantics.
[social]I use Panic Nova (and have for years) but for PHP version update I started using JetBrains’ PHPStorm (and then for Python, PyCharm) so helpful as IDEs.
gRegorckeditor is finnicky to update, but yeah I think you do have to allowlist certain HTML elements for them to work. No experience with dl specifically though
[social]FrESH discussion about dates had me notice my dates on my post were a format I rarely ever use (Month Day, Year), but as I was building it (well its precursor for travel entries) I was rolling a CMS from scratch for a government project and they required the American format. Since this was initiall created 25 to 26 years ago I would take the time stamp and log it, but also have a column in MySQL with the date written out in the desired
[social]Today I converted all the stored dates as they are called in many of my templates and it was quicker (and also keeping the load on a hosted shared server quick and efficient) to just update the stored date into the format I prefer (or one of them). The only code I needed to change was the processing of the blog entry script that stores the formatted date.
btremgRegor: The elements that I'm trying to insert are allowed. (Otherwise, it would simply remove every `<dl>`, `<dt>`, etc. I'll try to find the sanitize options to see if I can get it to stop breaking my markup. But I have little hope.
[Murray]@btrem: no worries, life happens 🙂 That does sound frustrating though! I can say that CKEditor not allowing paste is definitely a decision someone else has made; the native editor definitely allows it, and I've never had that restriction myself. Would be infuriating though!
[Murray]I'm personally most annoyed that it doesn't auto-format Markdown on paste, though apparently that can be configured, I just haven't worked it out yet
btremApparently, Drupal's unofficial slogan is "making difficult things easy and easy things difficult." And I'd have to say, that sounds pretty accurate to me.
[Murray]In terms of the code changes it seems to be making "on your behalf", the one pattern I can see is that both examples mix block and inline elements in a way that, whilst perfectly legitimate, is (I would say) atypical. Having a block-level `<div>` within a typically text-based `<dd>` might be the problem; if you were to use a `<span>` there, does it still make the same change?
[Murray]I even wonder if you were to explicitly set `display: inline` on the `<div>` (assuming your editor allows inline CSS) whether it would still try breaking it out like that.
[Murray]But I can see the same logic resulting in those added `<p>` tags: there is an inline element (`<span>`) nested between block-level `<div>` elements. Even though they're all wrapped in a block-level `<div>` the layout for that `<span>` is unclear, so I can kinda see the logic in wrapping it in an appropriate block-level element. As the content is text, a `<p>` would be accurate
btremAnd I don't know how else I could properly markup text, then a postal address, then more text, except to use `<dd>text <div>address</div> more text</dd>`
[Murray]The content model of `<dd>` is flow, but the content within it is inline. As in, like a `<p>` element, you don't really expect there to be nested block-level elements internally.
[Murray]I would personally use inline elements: either swap the `<div>` for a `<span>` to preserve the order, or drop both and use `<br>` elements to format the address
[Murray]No, sorry, I wasn't saying it was a flow content model, it's phrasing content, but the _usage_ is the thing that I think is being automated here
[Murray]Most text left outside of a block-level context _should be_ within a block-level context. I can't really think of a reason why it wouldn't be. So wrapping it in a `<p>` makes sense to me.
[Murray]Yeah, and I can see how that would be annoying, particularly because you do know the models and you do know what you want 😅 But I'd imagine the vast majority of people using a rich-text editor have no idea how HTML works, and I do understand why that kind of safeguard would kick in. Perhaps there is a way to disable it
btrem*If* it wanted to put the <span> inside a block level element -- it shouldn't want that, but ok, whatever -- how about a <div> instead? That'd fix the address part at least.
[Murray]Personally, I'd flag a `<div>` as inappropriate in both contexts. It might be technically allowed as per the letter of the spec, but it makes no sense to me. The address is part of the `<dd>` and therefore should be related to the surrounding text, so it shouldn't be broken out into its own context.
btremThe content model of <dl> is one of two: (1) <div>, within which are groups of <dt> and <dd> elements; or (2), collections of <dt> and <dd> elements. There is no mixing of the two AFAICT.
[Murray]A `<dl>` accepts flow content. I certainly wouldn't encourage the format that CKeditor has come up with, but I don't _think_ it's disallowed. Not sure, and agreed its an odd fix. But as I say, I'd also say that a `<dd><div/></dd>` would be a pattern I wouldn't expect, allowed or not 🤷
btremHere's a module to undo the crap that Drupal/CKEditor saddled you with. It all smells like classic Microsoft to me. The "We know better than you what you want" attitude.
btremI don't really understand the part "CKEditor 5 intercepts all native events like copy, cut, or drop and handles them on its side. The goal is to not allow the browser to touch the content in the rich text editor. This could lead to the browser messing it up." Mess it up how?
gRegorPasting like that often carries over formatting too, unless you choose the paste plain text only option, so I can see why it might be locked down. I've definitely had work clients copy some web text and paste it in and then wondering why it has some other color, or bolded, etc. (from the source they copied)
btremThe thing is, you can't move stuff around a page or even a paragraph with that limitation. So if you want to just move a word within a sentence, no can do in Drupal. It's very unintuitive if you ask me.
gRegorRight, if you don't have the clipboard plugin or it's disabled, that's not a way around it. Was just saying I can see some reasoning why one might limit pasting.
[social] I noticed my footer on my links page (https://vanderwal.net/links.php) has two paragraphs aligned next to each other. I changed the element for the 81x35 to a div and it still is aligning to the right and not below in my footer.
[KevinMarks] I am always annoyed by vs code inserting </p> and so on with self closing elements. The <p> closes the previous one.
[Murray] In terms of the code changes it seems to be making "on your behalf", the one pattern I can see is that both examples mix block and inline elements in a way that, whilst perfectly legitimate, is (I would say) atypical. Having a block-level `<div>` within a typically text-based `<dd>` might be the problem; if you were to use a `<span>` there, does it still make the same change?
gRegor Pasting like that often carries over formatting too, unless you choose the paste plain text only option, so I can see why it might be locked down. I've definitely had work clients copy some web text and paste it in and then wondering why it has some other color, or bolded, etc. (from the source they copied)