Skip to content
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

Online Workshop - Reviewing developer-focused features in Gutenberg 14.9 #1241

Closed
6 tasks done
ryanwelcher opened this issue Jan 9, 2023 · 9 comments
Closed
6 tasks done
Assignees

Comments

@ryanwelcher
Copy link
Collaborator

ryanwelcher commented Jan 9, 2023

Event Details

Online Workshop Checklist:

@ryanwelcher ryanwelcher added [Content Type] Online Workshop [Content] Needs Co-host Online Workshops in need of a co-host. labels Jan 9, 2023
@ryanwelcher ryanwelcher self-assigned this Jan 9, 2023
@ryanwelcher ryanwelcher removed the [Content] Needs Co-host Online Workshops in need of a co-host. label Jan 9, 2023
@justintadlock
Copy link

You've already got the things I would suggest listed. But, if you want to dive into some of the theming-related items:

@annezazu
Copy link

annezazu commented Jan 9, 2023

I'd touch on fluid typography still, even if it's just a quick reminder. +1 to iframing the post editor!

@ryanwelcher
Copy link
Collaborator Author

ryanwelcher commented Jan 9, 2023

@justintadlock I've added the box shadows change but am wondering about the iframe issue.

While it does address issues that users run into but is there an issue that extenders would run into that this fixes? Like CSS bleed? I'm definitely not against mentioning it but I'm trying to focus on things that affect or are enabled by 3rd party code. I may also just not know what I'm talking about :) I'd love to be able to show some code that is broken and then turn the plugin on and show it fixed - that's what I am thinking any way.

@ryanwelcher
Copy link
Collaborator Author

I'd touch on fluid typography still, even if it's just a quick reminder. +1 to iframing the post editor!

Added! Thanks for the suggestion!

@justintadlock
Copy link

I'd say the biggest win with iframing the post editor is that there's no admin CSS bleed. This makes it much easier to style themes (probably some plugins too) without conflicts or accidentally touching the admin UI with custom styles. Theme authors are nearly 100% guaranteed to only need to worry about a single set of styles working on both the front and back ends. I know I've personally had to create a few workarounds in the past, and am assuming (haven't tested yet) that this should fix those cases.

@ryanwelcher
Copy link
Collaborator Author

I'd say the biggest win with iframing the post editor is that there's no admin CSS bleed. This makes it much easier to style themes (probably some plugins too) without conflicts or accidentally touching the admin UI with custom styles. Theme authors are nearly 100% guaranteed to only need to worry about a single set of styles working on both the front and back ends. I know I've personally had to create a few workarounds in the past, and am assuming (haven't tested yet) that this should fix those cases.

Awesome! Do you have an example I can test? I'll be doing my homework on these tomorrow so I can put it through it's paces.

@justintadlock
Copy link

Awesome! Do you have an example I can test? I'll be doing my homework on these tomorrow so I can put it through it's paces.

Unfortunately, I don't have any examples off-hand. It's been over a year since I've had a project where this was an issue (I tried to dig up the specifics, but I didn't find it). Anyway, I see it as more or less of a footnote.

As an aside, which I didn't see mentioned specifically in the commit message, the post editor is only in an iframe if the custom fields panel is disabled (default).

@ryanwelcher
Copy link
Collaborator Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants