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

Peer review core templates and settings #35

Closed
danilobuerger opened this Issue May 28, 2014 · 16 comments

Comments

Projects
None yet
8 participants
@danilobuerger
Copy link

danilobuerger commented May 28, 2014

Dear fluidcontent_core users,

We are doing an open review of the options and templates which we will ship with the first official release of fluidcontent_core. In order to have the best possible starting point we ask for your suggestions. Below you will see a list of topics which are being decided by us - if you have input on any of the so far uncompleted topics please give us your thoughts in this issue's comments.

Before you do:

In order to avoid shipping a bloated and/or too generic set of templates and options we ask that you observe the following guidelines before chipping in:

  1. The Textpic element is left out intentionally and will not be added. You can read a more detailed explanation of why this is so, at https://github.com/FluidTYPO3/fluidcontent_core#special-note-about-the-textpic-text-with-images-content-type.
  2. We are not trying to reinvent the core elements' options - we are trying to define a set of shipped options which are relevant to everyone. One of the major points of fluidcontent_core is the ease with which you can change every aspect of the attributes added by fluidcontent_core - so we actively try to avoid adding any attributes or renderings which are not universally useful (or at the very least serve as the perfect starting point for customisation).
  3. We will not add any new content types - no column-type elements for example. Such elements are the sole responsibility of the integrator or developer, and should be created using fluidcontent rather than added as new core element types. We may choose to add such elements in the future but for this first version, we choose not to.

Topics of review

  • Finish Menu.html
  • Add ability to Table.html to make first row th elements
  • Gather wishes for shipped TypoScript settings
    • Header settings
    • Container settings
    • Tag names
    • Shipped CSS class selection options
    • Image settings (globals and defaults)
  • Gather wishes for Flux form settings
    • Removals (redundant, exotic settings)
    • Additions (must be universally useful)
    • Changes (existing fields' types, labels, names etc)

@NamelessCoder NamelessCoder changed the title Peer review core templates Peer review core templates and settings Jun 2, 2014

@dalder

This comment has been minimized.

Copy link

dalder commented Jun 27, 2014

Great, waiting for this for ages!

You already pointed it out with the explanation to the 'textpic' element. From my point of view the content should be separated from the flow/positioning/etc. I would go even further. Only one content element is required. All other types should inherit and share the same basic.

We do now have several approaches with different logic:

  • Textpic (as you already mentioned) => different kind of behavior of "flow" (positioning, two-in-one, etc)
  • Text, menu, etc are called "sys elements" with some specified behavior and their own CTYPE
  • Plugins, one CTYPE with a separate "Plugin configuration" and splitting up the logic again

From my point of view, there shouldn't be any difference over all this elements.
They all should work and share the same base.

The so called "sys elements" should work as a plugin. On the other hand the user should not realize whether he is using a plugin from a vendor or a "sys element".

  • So get rid of the CTYPEs: every plugin is automatically a new "CTYPE" and the "sys elements" are plugins too (so every content element has their specified fields in own tables)
  • Every content element (from plugin to "sys elements" uses the basic fields (title, show, etc) => section default (which can globally be extended)
  • Every element (for example text, image or a even a custom plugin) adds their specified functions/fields/etc in the same section custom, so the customer is not getting confused with several UX styles since the title is always in default section. And the elements specified functions/configurations always in the same place custom.

I know, this is more base, BE and organizing stuff, but for me much more important then the rendering itself or which kind of elements you deliver in the end.
With this you don't have to care about sys elements or not. You could only provide the "management approach", and deliver/update the content elements one by one (as you would with a plugin). As an integrator or user the only thing I care is using the elements I have chosen and that their look all alike.

I hope you get the point ;) and hopefully I got the question/thoughts you are asking for ;)

@xf-

This comment has been minimized.

Copy link
Member

xf- commented Jun 27, 2014

Nice approach, but i think it is nearly impossible. You need to rewrite some parts in T3 or more like in most common plugins.
Not everything has a title or bodytext. Only standard fields would be show, start-end .... If you put those typical fields in a custom area, extension who relay on them will fail. We don't try to create a complete new T3, we try to simplify it, get rid of overhead and be more flexible.
If you don't use textpic and replace csc with fluidcontent_core. The result is, all content is available and works.

Getting rid of CSC isn't so easy. It is a uninstall able extension, but it is deep in T3 core.

-> This ticket is more a task list until to publish the ext.

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Jul 18, 2014

@dalder We are not reinventing the TYPO3 content logic. Rendering instructions in TYPO3 simply configure what TYPO3 does when encountering a specific element and the fact that plugins (which includes fluidcontent elements) have their own CType which is shared, is impossible to work around without completely destroying all backwards compatibility, require a completely new way of configuring said plugins - and thus in all likelihood also destroying compatibility with 9/10 popular TER extensions. While your suggestion might have made sense if we were creating a new CMS, it's just too impractical for TYPO3 CMS.

Please note that this thread is intended to receive feedback about our selection of elements, the fields they contain and the default configuration we ship with those elements.

@erredeco

This comment has been minimized.

Copy link

erredeco commented Jul 28, 2014

A thing I really never liked about the current CSC elements in TYPO3 CMS is the div that wraps the element, i.e.

...

IMHO it could be better like this:

(forgive me for the notation, I hope I made clear what I mean ;) )
@erredeco

This comment has been minimized.

Copy link

erredeco commented Jul 28, 2014

Sorry: the editor cut the divs :)
Instead of:
<div id="c29" class="csc-default">... </div>

My suggestion is something like:
<div id="c29" class="csc-default ###CTYPE### ###LAYOUT### ###SECTION_FRAME###">...</div>

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Jul 29, 2014

You can already change the exact composition of container tags by changing the Layout each content element uses or the tag this Layout generates. No need for additional configuration to support this.

@danilobuerger

This comment has been minimized.

Copy link

danilobuerger commented Aug 5, 2014

One of the core missions of fcc is not to make the same mistakes as csc. It might be worthwhile overthinking the default use of containers. In every instance that i used fcc i never used containers and wouldnt want editors using them. The best approach if you want a container is to override the specific template or even layout.

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Aug 5, 2014

I agree about the containers but we should at least make the wrapper tag name configurable, e.g. Text can be wrapped in a <article> and Image in a <div>. Option for the editor to choose the type shall be removed.

@Outdoorsman

This comment has been minimized.

Copy link
Contributor

Outdoorsman commented Aug 8, 2014

This may be old news to all of you, but I recently read an article that I was pretty excited about. It details simple one-liner CSS options to handle images in text in ways that I haven't used in the past but wished were available.

Ten CSS One-Liners to Replace Native Apps

http://alistapart.com/blog/post/ten-css-one-liners-to-replace-native-apps

While I don't approve of the non-responsive behavior of the former Text w/ Image content element, I would love to see some of the techniques mentioned in the above article used in a functional way in FCC (I like your abbreviation @danilobuerger). I don't know if that would mean adding this functionality to an image CE separate from the text element or if it would make more sense to make it combined... I'm just throwing it on the table to talk about. This is in my opinion something pretty cool but I haven't thought out if it's appropriate to integrate or not. Hey, "In Text, Right" was an image alignment option in CSC's Text w/ Image CE :) What's the futurized version of that because admit it, it can look great to have text flowing around an image, especially if it's responsive. Discussion to follow...

@webian

This comment has been minimized.

Copy link

webian commented Sep 1, 2014

I'm not yet a fluidcontent_core user but I find this idea smart and amazing! This is also necessary since TYPO3 templating is going more and more towards Fluid and then CSC is anachronistic.
For images in particular, responsive and lazy loading (optional) are "must have" and a Bootstrap compatible markup could be much appreciated by many.
(sorry for this actual poor contribution)

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Sep 1, 2014

For images in particular, responsive and lazy loading (optional) are "must have" and a Bootstrap compatible markup could be much appreciated by many.

Both of these are certainly things we'd like to see, but:

  • lazy loading images currently requires JavaScript and we want to avoid shipping any JavaScript whatsoever since this is traditionally one of the first things you'd be removing or changing. However, something like a Bootstrap-specific Provider Extension could ship something like this (and provide overrides for the Image.html template of FCC).
  • a complete Bootstrap markup should be made for this, but not by shipping it as part of the feature itself. It can, however, easily be included in a Provider Extension which also adds the additional Bootstrap components (see for example https://github.com/bootstraptheme-for-typo3/fluidbootstraptheme).

Thanks for the "smart and amazing" btw :)

@s-leger

This comment has been minimized.

Copy link

s-leger commented Dec 13, 2014

Hi,
Out of the box, fluidcontent_core lead to raw un-scaled pictures. It's quite annoying for someone used to use csc and make it a way too far from a drop-in replacement.
Supporting srcset / picture in today's web is a common task nearly everyone has to do at some time.
The lack of native support for sutch basic and vital features delay / prevent massive adoption / don't speak in favor / of fluid-things in general.
Sutch "edges cases" no one seem to want to fix in the "fluid way" should absolutely be avoided and could be the price to pay for a bright future.

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Dec 14, 2014

Hi @s-leger,

Out of the box, fluidcontent_core lead to raw un-scaled pictures. It's quite annoying for someone used to use csc and make it a way too far from a drop-in replacement.

FCC (fluidcontent_core) was never intended to be a drop-in replacement for CSC. We clearly announce that it's a break from previous methodology specifically in that we ship a bare minimum working state and rely on others to create (CSS-framework-gnostic or generic) sets of templates and options which perfectly fit the target product.

Supporting srcset / picture in today's web is a common task nearly everyone has to do at some time.

True. We would like this to be implemented in Fluid because that's where it belongs - but we will gladly accept a pull request adding this capability to VHS' image-related ViewHelpers as a temporary measure until Fluid supports it natively!

The lack of native support for sutch basic and vital features delay / prevent massive adoption / don't speak in favor / of fluid-things in general.

Valid point, albeit misdirected. See the previous response. You must also remember that where CSC is manipulated by changing a hugely complex TS structure, FCC is manipulated by replacing or extending the fluid templates. Both approaches require additional setup. Both approaches require knowledge of each context (TS/Fluid). The only difference here is which one you'll be using in order to apply your manipulations.

So if you expect, in a CSC context, to have to modify the TS that renders HTML you should in all fairness expect the exact same requirement if you want to modify the HTML that is rendered by Fluid. You'll just be using Fluid instead of TS, that's all.

Sutch "edges cases" no one seem to want to fix in the "fluid way" should absolutely be avoided and could be the price to pay for a bright future.

I agree, trying to achieve support for rare edge cases should be avoided, because supporting one means we should/must support all - or be prepared to clearly argument in every new edge case whether or not to support it. We'll gladly tell you how to achieve the desired result but it's very unlikely that it will become a shipped feature unless demand is explicit.

@xf-

This comment has been minimized.

Copy link
Member

xf- commented Jul 25, 2015

Remove Media.
Media is fluidcontent, because scaled videos, different formats are hard to provide, best you use your optimal solution. From simple up to a service like vimeo or youtube.

-> Removed media from list

@xf-

This comment has been minimized.

Copy link
Member

xf- commented Jul 25, 2015

This should be the last open part from menu:
#132

@xf- xf- referenced this issue Jul 25, 2015

Closed

Menu is not working #132

@xf-

This comment has been minimized.

Copy link
Member

xf- commented Jul 27, 2015

Was the last issue.
Works in daily usage.

@xf- xf- closed this Jul 27, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment