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

Remove save className auto-application #2035

Closed
aduth opened this issue Jul 26, 2017 · 4 comments
Closed

Remove save className auto-application #2035

aduth opened this issue Jul 26, 2017 · 4 comments
Assignees
Labels
[Feature] Block API API that allows to express the block paradigm. [Type] Question Questions about the design or development of the editor. [Type] Task Issues or PRs that have been broken down into an individual action to take

Comments

@aduth
Copy link
Member

aduth commented Jul 26, 2017

Currently when a block is saved, we automatically inject a generated class name to the generated markup without the block author's intervention.

However, the block author must apply this generated class themselves in the edit implementation, using the provided className prop.

The block author must also have general awareness of this class name to be able to apply styling to their block in stylesheets, so it is not intended to be totally transparent.

We must decide one or the other of the two actions below:

  • Remove auto-application and force block implementer to consistently apply className themselves in both edit and save
  • Account for auto-application in invalid block preview
@aduth aduth added [Feature] Block API API that allows to express the block paradigm. [Type] Question Questions about the design or development of the editor. [Type] Task Issues or PRs that have been broken down into an individual action to take labels Jul 26, 2017
@youknowriad
Copy link
Contributor

Making the className explicit sounds like the good approach to me for consistency between edit/save methods.

@youknowriad
Copy link
Contributor

Like mentioned here #2394 (comment) The className property has two roles right now:

1- Overriding the default generated className and dropping this className if set to false.
2- Setting it to false hides the className inspector control.

Does it make sense to have two different attributes for this: declare support for the inspector control and another property to override the generated className (or disable it)?

This separation would allow us to have a more generic support property to declare support for advanced inspector controls. (className and anchor)

@aduth
Copy link
Member Author

aduth commented Aug 18, 2017

Does it make sense to have two different attributes for this: declare support for the inspector control and another property to override the generated className (or disable it)?

Please no 😩 If it really must be opt-out, we can still do supports as an object of boolean values.

@gziolo
Copy link
Member

gziolo commented Feb 1, 2018

It was implemented in #2507. Closing this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block API API that allows to express the block paradigm. [Type] Question Questions about the design or development of the editor. [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Development

No branches or pull requests

3 participants