-
-
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
Reusable block features #507
Comments
You're right – the image feature is implemented in the You're also right when thinking about other styling options. In general, we called this feature "image styles" because it's about giving the developer a tool to control consistent image styling (which is applied to images by classes). Basically, as a developer you can configure the editor to provide the user with a choice of image styles. The default is this: editor.config.define( 'image.styles', [
// This option is equal to situation when no style is applied.
{ name: 'imageStyleFull', title: t( 'Full size image' ), icon: fullSizeIcon, value: null },
// This represents side image.
{ name: 'imageStyleSide', title: t( 'Side image' ), icon: sideIcon, value: 'side', className: 'image-style-side' }
] ); There are full size and side images. Full size image has no special value (no additional class is assigned to the image) and the side image has the "side" class. And the rest is controlled through stylesheets. You can define your own styles and style the image from your stylesheets however you want. That's about images. Now, when it comes to reusing the styling feature in other types of blocks – this is definitely a good idea. We'll definitely look for a way to have as little code duplicated between images, tables, etc. However, we're cautious when it comes to that because it's easier to maintain duplicated code than to fix a broken abstraction. It's too early now to know how the abstraction should be proposed to be really usable because every case is different. And it's not that much code either. Anyway, thanks for the idea. Let's see what we'll be able to do with this feature. |
May be related to #1065 |
There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue. |
There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue. |
Looks as though this might still be relevant. |
There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue. |
We've closed your issue due to inactivity. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it). |
As I understand the design, features like images (with or without captions) are implemented in their own packages that can be composed into the editor for any given situation. I note that tables are on the horizon as a possible feature, and I can think of other components that would also behave like blocks, such as pull quotes or media embedding.
Would it be possible to make sure that any extensible features inherit the same controls as are currently used for images? Then, say, a table could be made text-width, or made into a half-width box with text flowing around it, just by reusing the existing controls from the image feature.
I could also envision other controls to push the block component outside the text margin, which is often needed for pull quotes, or to align it completely outside the text block as an aside at that point in the flow.
The text was updated successfully, but these errors were encountered: