Extra Section In Extension Repository

[mechaflash]

As we all know, modules are usually made bare-bone without much touching up done to it.

Why not create another section/category to upload/download stylesheets for FE/BE modules?

Since many of the modules are plain, this will give the community a chance to share their stylistic ways of making these modules look good. I figure if we do it this way, devs can focus solely on creating the module to function the way its supposed to, and others who like to make things look good, can focus on the styling. Combine the two and you got a winner. And we keep the styles and modules separated so there aren't 100+ instances of the same module with a different color.

So if a dev wanted to, they could make the core functionality of the module, and throw it out there with no styling (or minimal), and if they had some styling done, slap it into a separate stylesheet and upload that with it.

The new section can be searched via module name, and it will have thumbnails/gallery of screenshots of how it looks with its corresponding style attached. And in the extension repository when you go to look up the module, if the developer of the module created a basic style for it, the stylesheet will be linked on the same page.

Then the CSS freaks will have a field day with naked modules, and the people that want ready-to-go modules have some options to sort through.

Maybe also update Contao to better organize stylesheets for this purpose.

EDIT:
Include an upload directory in the backend for easy stylesheet integration for end-users.

[ramjet]

I REALLY like this idea. :D

[Ben_360fusion]

Sounds like a plan

[mechaflash]

and also make the Extension Repository Menu based with filtering options instead of strictly filtering.

[Ruud]

Is there a guideline to what html elements, classnames to use and id conventions to follow? Without that, the proposed structure would probably have unpredictable results. There would be now way of surely targeting specific elements using CSS.

[ramjet]

There isn't - but I don't think there needs to be.

I think Mechaflash is just proposing a mechanism whereby if you have created your own stylesheet for any given module, and wish to make it available to others, you can upload your stylesheet and a screenshot and it will be associated with the module in the Repository.

Conventions would probably make styling easier, but this goes against the concept in a way - as then the developer has to know css well (and the idea is really to support and enhance modules where the developer doesn't, or hasn't, produced any style with it)

[Medianomaly]

you can upload your stylesheet and a screenshot and it will be associated with the module in the Repository.

OR to stay consistent with current trends in submitting extensions, simply upload the file, provide a description like...

"This CSS make for news."

Provide no screenshot, manual, documention, or further information of any kind, and leave it at that. :D

[ramjet]

Yip :D
I think this is where Mechaflashes idea will really help out... as with a screenshot of the styled module people will probably get a bit of an idea of it (perhaps).

I do think a minimum description of a modules purpose should be enforced somehow (its not much effort on the part of the developer to write it, and a translator would then be able to translate at least that).
A lot of modules I only know what they actually do because someone has commented on them or explained or questioned them in the forums.
Imagine when theres thousands! millions! squizillions! of them.

Maybe this idea could apply to documentation files too, so others could share their client manuals etc if they wanted.

[ramjet]

I also see mechaflash has suggested this in a feature request. I think its really important.
I hope Leo or Acenes (who designed the Repository i think) has something to say or suggest on the matter (hint ), as to how hard it would be to take this further.

[mechaflash]

OR to stay consistent with current trends in submitting extensions, simply upload the file, provide a description like...
"This CSS make for news."
Provide no screenshot, manual, documention, or further information of any kind, and leave it at that. :D

:lol: . I have to say, I would like to see Contao's way of doing it unique. Yes, this CMS is super for developers to create extremely well made, stable modules. Doing it in the manner I posted will help developers to spit out new modules or updates to modules quickly without having to focus any/much attention to making it look pretty. Then those of us that build them and style them can supply the stylesheet for the module when we're done.

SO! It stays a developer's favorite CMS, and then we gain more ground by bringing in the simple-type website builders that want everything pre-made, pretty and ready to go.

As for the repository for the CSS, it could be linked from the module page in the beginning of the module description. It will navigate to a new page with a thumbnail preview gallery of stylesheets available for download. Clicking on the image throws a lightbox with an enlarged image and a [Download] link for manual downloads (and another one if navigating from the backend to auto-import the CSS file to its correct location)

Is there a guideline to what html elements, classnames to use and id conventions to follow? Without that, the proposed structure would probably have unpredictable results. There would be now way of surely targeting specific elements using CSS.

If you think about it, the people doing the styling will give class names/IDs to all of the elements anyways. More than likely, we're going to be finding maybe the first few stylesheets actually being "Unique" and the rest are spinoffs of these, recycling the given classes/IDs assigned to the elements. So I don't see much of an issue with this. Plus, those that know how to style modules, know how to assign class names to elements in the modules... I would hope :?

but... if the dev. would want to be nice, he/she may assign semi-related class names to the elements to make it easier. Think of how many pure programmers we'll make happy by separating the visual, artistic aspect out of designing modules. They'll have a field day :D (gawd I make long posts)

EDIT: this is my first post placed from home. I hardly jump on outside the times of 8 and 5 LOL

[Ruud]

Is there a guideline to what html elements, classnames to use and id conventions to follow? Without that, the proposed structure would probably have unpredictable results. There would be now way of surely targeting specific elements using CSS.

If you think about it, the people doing the styling will give class names/IDs to all of the elements anyways. More than likely, we're going to be finding maybe the first few stylesheets actually being "Unique" and the rest are spinoffs of these, recycling the given classes/IDs assigned to the elements. So I don't see much of an issue with this. Plus, those that know how to style modules, know how to assign class names to elements in the modules... I would hope :?

I think you are missing the point here. But also misunderstand how styling works. It is the developer who writes the default HTML template and thereby determines what classnames are in the HTML. A user has limited options when using standard templates and almost complete freedom when changing each template themselves. But neither is the case if your idea is to work. (The user should not have to use options because that is in many cases too complicated for the targeted user)

Example:
We have DEV S (standard) who made a module that outputs:

<div class="content-el">
<h2>Some header</h2>


Some content</p>
</div>

DEV N (non standard) who made the same module that outputs:

<div class="contentElement">
<h2>A header</h2>
<p class="contents">Text here</p>
</div>

They both generated perfectly fine code. Lets call DEV S' code the agreed standard. If the CSS guru's start making templates they do not know or have ever met either DEV. In order to be able to offer a theme that right from the bat will style a module correctly both the module and the theme will have to follow the same rules and naming schemes.

GURU S creates the following theme:

.content-el h2 {
  color: red;
  font-size: 16px;
  margin-bottom: 4px;
}

GURU N creates a theme:

.block .contents h3 {
  color: green;
  text-decoration: underline;
}

Now you can see that DEV S + GURU S is the only combination that makes sense. Neither of the other two result in styled elements.

So I'd say a convention that defines which html elements must be used in specific places is needed. And a naming scheme for classes and ids. Default Contao templates seem to follow a scheme, though it is not enforced. So there is a lot of work to do to get the idea up and running....

[mechaflash]

DEV N (non standard) who made the same module that outputs:

<div class="contentElement">
<h2>A header</h2>
<p class="contents">Text here</p>
</div>

GURU N creates a theme:

.block .contents h3 {
  color: green;
  text-decoration: underline;
}

Now you can see that DEV S + GURU S is the only combination that makes sense. Neither of the other two result in styled elements.

I understand now what you're saying. You're right, there would have to be some guideline as to what class names/IDs would be used if that is the case. Either that, or the dev would have to specify the class/IDs prior to releasing the module, and every styler will have to conform to it. I think for the sake of publishing modules quickly, the latter solution would be good.

Or if the dev doesn't care for CSS, have another set of devs that are CSS specific, and pass the module to one of them just to classify elements, and then push it out. As long as we have just one person touching any one module for element classifying, the necessary need for a strict guideline would not be needed. Of course, this means we would have to have people willing to take their time to accept modules and do the legwork. Then again, this could work to the advantage of the community as we can request persons to get involved with the development of the modules in a unique way... and I think there's some people out there willing to do it.

[Ruud]

I don't think that last approach will work. Personally I wouldn't like people touching what I made. And the other way around; changing templates of another dev can be a huge job. Let alone what will happen if the dev uploads a new version in the old style...

I just realized that if such a system is to succeed you would need to separate the layout from the style. That way the dev can include a stylesheet that only handles position and other layout related stuff that a general style will not cover. The builder of any style would only be concerned with fonts, colors, borders, margins and such. (a guideline like discussed before is still required)

There are several projects that take this approach. I think Magento is one of them; you could in theory change the complete layout without changing the style. While I haven't tried a lot of them I was unable to combine any style and layout stylesheets not made by the same author. So such an approach is obviously not a sure success. I'd say it would take some enforcing of basic principles and I'm not sure if they are worth the benefit.

[mechaflash]

Then it comes down to either the dev giving class/IDs to all elements, or creating a specific guideline for stylers to follow.

hmmm... like "The first containing element will be class/ID of the module name. All elements will be named 'element_#' element being the name of the element (div, span, etc.) and # being the instance of that element in its hierarchy" or something.

So if the structure was:
div
div
span /span
span /span
ul
li /li
li /li
/ul
/div
div
span /span
/div
/div

the naming scheme would be like:
div class="modulename"
div class= "div_1
span class="span_1" /span
span class="span_2" /span
ul class="ul_1"
li class="li_1" /li
li class="li_2" /li
/ul
/div
div class="div_2"
span class="span_1" /span
/div
/div

eh not a planned out thought... but a thought

[Ruud]

Hmm, something like that. The naming scheme you use as an example would not add new information into the structure though...

I'm thinking it should be more along along the ways of the existing Contao scheme.

So a module is contained inside a div with the classnames mod_module_name and block. Main header can be h1. List elements contain at least the classnames first or last (for first and last items), odd/even and current/active if applicable. And so on... This is alike what the Contao templates already follow.

That makes up for predictable html that could be styled. But then there's still going to be problems for layouts that include elements that do not fall into anything predefined. So the dev should include layout stylesheets...

[mechaflash]

Okay devs!!! you're responsible for naming all elements in your module for styling purposes!!! THANK YOU!!! :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D :D

[mechaflash]

I'm surprised no one has updated the ticket yet on dev.contao.org they think if they just ignore me I'll go away... you can ask my wife... I don't :lol:

[Ruud]

Doesn't come across as a good trade though...

Of course the devs are responsible, but for as far as the extensions I've ever used are concerned; most already add in precise classnames that help selecting specifics. Unfortunately there are few that do not...

[ramjet]

Unfortunately there are few that do not...

Then a Suggested CSS Naming Instructions for Module DevelopersTutorial would help then :D
I'd write one, but I don't know my a*se from my elbow.

[Ruud]

I think this should and will be covered in the documentation as soon as it is written. There are strict patterns to follow when building any extension, but the templates are not restricted in any way. To ensure better quality it seems likely the topic will be covered in the documentation. As I understood this is one of the things most people find important and that should mean it will be written.

Then that leaves the question if it is desirable to have a (strict) separation between style and layout. I think the system will not work without some separation because some module output will be highly specific. But to strict separation will make it complex as to which goes where. I just like the system the way it is.

An extra theme section with complete themes on the main website might be an easier and equally good solution.

How does Joomla solve the problem? You can get lots of themes and modules. How do they work together? I recently wrote a joomla component, but included CSS that only works for that customer to go with it...

[Ruud]

I found this standard I didn't know about. It might provide a standardized basis for everyone to work on. Regardless of any theme implementation: http://en.wikipedia.org/wiki/RDFa