Skip to content
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.

[RFC] New (or replacement / improved) general block type #159

Open
dantleech opened this issue Nov 9, 2013 · 3 comments
Open

[RFC] New (or replacement / improved) general block type #159

dantleech opened this issue Nov 9, 2013 · 3 comments

Comments

@dantleech
Copy link
Member

Just an idea.

Provide a (HTML5?) block type which enables you to select which tags to use for title ,body and maybe other fields, e.g.

<article {{ block_class }}>
  <header>
    <{{ title_tag }}>{{ title }}</{{ title_tag }}>
  </header>
  <section>
    <{{ subtitle_tag }}>{{ subtitle }}</{{ subtitle_tag>
    <div>
        {{ block_content|raw }}
    </div>
  </article>

Where the various tags are defined in the configuration:

blocks:
  # general block options..
  header_tags: [ h1, h2, h3, h4, h5, h6]
  subtitle_tags: [ h1, h2, h3, h4, h5, h6]

So that the tag types and maybe other options are configurable from the block form in admin.

@dbu
Copy link
Member

dbu commented Nov 11, 2013

sorry, i am -1 on this.
i think this should not be the responsibility of a content editor. storing such things for every block in the database would also be problematic.
to change the html used by a template, we might configure the block template, but i think that would be rather over engineering it, overwriting the template will happen sooner or later anyways if you do care about specific markup.
if i had different cases for the same block, i would try to determine the case from context if possible, and otherwise have the editor just choose a type like "Important Block" / "Note Block" or whatever the semantical distinction is.

@dantleech
Copy link
Member Author

But then the content editor doesn't control how to display the title of a block does it? Or what container class to use, or indeed what class to use for the container.

I think what I am proposing is actually pretty uncontroversial on one level -- simply having the possiblity to configure the type of tags and classes to use for the block.

A more advanced step would be to persist such enumerated options in the block document.

  • This is less work than configuring another template
  • It allows you to change the appearance of your blocks without changing the code (e.g. you can have a css class for making a block "louder" which you would be able to turn on and off with this proposal)

I am also coming from a CMS which has a dynamic theming system - in which case modifying a template for each theme is really a no-go.

@dbu
Copy link
Member

dbu commented Nov 11, 2013

i think the theme system with configurable templates would be a general effort that should come orthogonal to blocks. you would need that for all of your cms, not only blocks. for such a thing, i would rather see a specific theming bundle that probably hooks into the template loading mechanic and provides very flexible templates. the issue with this is that this flexibility makes everything extremly complicated and harder to read, so i am against doing that in basic templates.

as said, i would be strongly against storing what html tags to use in the database. i think the most thing we could expect the editor to have to actively select is a "type" or "role" of the block, which then can be used by the template to render differently. whether something is h1 or h3 is not a question of display, but a question of semantics. the question of display should be left to css. the "type" or "role" would very likely be represented by some css class on the container, to allow specific styling.

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

No branches or pull requests

2 participants