-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Editable needs padding #5438
Comments
Some possible solutions, each has some drawbacks: A
Pros:
Cons:
<img/>
<p>foo</p> /* <- this one has margin-bottom: 0 */ [<img/>]
<p>foo</p> /* <- this one should have margin-bottom: 0 */
<div>fake sel container</div> /* <- but this container gets it instead */ B
Pros:
Cons: C
Pros:
Cons:
|
What about C but with first-child only? We know that fake-sel-con is the last child so it's better to not touch this. OTOH, does absolutely positioned element's margin count? |
That makes some sense. We could use A and leave last-child untouched too. In other words: any solution which does not touch last-child.
No, it doesn't. Anyway, by
I meant that there could (?) be some last-child element in the content without |
Or... we could force the engine to apply some CSS class to the last non–fake–selection element in the content 😅 |
This goes too far :P
So maybe let's just not overcomplicate this. Some minimal first-child's top margin solves this issue and is easy enough to understand. |
Created PR for this issue ckeditor/ckeditor5-theme-lark#117. |
Fix: First child of editable should always have a top margin to make sure the content is separated. Closes #116. Closes ckeditor/ckeditor5-ui#351.
I think I reported it already but I can't see that ticket now.
The problem is that editable has no padding, so when you style your blocks to have the only bottom margin (which is common, e.g. GitHub does it), then that content looks terribly in the editor.
OTOH, if we'd simply add padding at the top then we'd make the content look bad with user agent styles which set block's top and bottom margins. So, to workaround that we'd also need to add
:first-child
and:last-child
styles. I'm not sure this is worth it, but I had to fix editable's styling in at least 2 integrations already (Umberto and GH RTE), so this is a quite common problem.The text was updated successfully, but these errors were encountered: