Inliner feature: Add section with class name

[johs]

The Inliner adds html without braking into a new element unless the user adds e.g. an image to the flow. What could be useful is that

• the ability to force html into a new section was enabled by having the "text" option in the (+) menu present alo when adding to an html section (thus starting a new one)
• give also the html sections a setting (cog wheel) popup with a field for css class name

This would allow the rendering system for the content a lot of opportunities to differentiate presentation, add functionality, especially important to achieve device adaptability. To keep this at the "cog wheel level" and not easily available in the html editor bar keeps it a step away from the user that is writing only. Some preset class names and tag list for new ones would be nice.

[ermouth]

I have own fork with this feature partially implemented, but I assumed it‘s too specific to put it into public release. The main problem is how should I differentiate visually blocks with this properties. When I have apriori known set of rules – well, thats ok. I see what I‘ve done immidiately and can fix possible errors.

If I keep this field just dummy meta – well, this approach looks bit weird. Any field requiring magic knowledge must be re-designed before implementation, and this one requires.

Although I see a reasonable compromise.

I can keep the field free-style, tag-alike, adding for example 3 pre-defined classes. They will lead to simple and understandable formatting, ie:

• With background
• With rules
• With accent (bold, or italics, or increased font – whatever)

All three will have visual presentation inside Inliner. Also settings will be applicable to a text block.

What do you think?

[johs]

On 20. aug. 2015, at 19.38, ermouth notifications@github.com wrote: I have own fork with this feature partially implemented, but I assumed it‘s too specific to put it into public release. The main problem is how should I differentiate visuallyblocks with this properties.

That could be just a subtle border, I think My idea with this is that content producers relate to a generic, structural preview that they learn to relate to as the thing a css designer need to delvier adaptable design. The float behaviour need to be consistent across various design variations on the final web sites. When I have apriori known set of rules – well, thats ok. I see what I‘ve done immidiately and can fix possible errors.

This might be best detremined after we have a good template model for final site rendering.

Right now I see that inliner is a good place for the writer to make decisions like "this pisture should be small" the other is the main one, enought to compose an article.

If I keep this field just dummy meta – well, this approach looks bit weird. Any field requiring magic knowledge must be re-designed before implementation, and this one requires.

Although I see a reasonable compromise.

I can keep the field free-style, tag-alike, adding for example 3 pre-defined classes. They will lead to simple and understandable formatting, ie:

With background With rules With accent (bold, or italics, or increased font – whatever) All three will have visual presentation inside Inliner. Also settings will be applicable to a text block.

What do you think?

Agree with your thinking Everything need to be as simple as possible, 3 choices is perfect. With too many options, it is not possible to build good models for templates in the rendering of the site.

johs:)

[ermouth]

Implemented, closing.