As I am starting to creating custom components, I noticed that upon creation of a component, the css file names are being changed to the name of the component. Example:
Create an accordion and place a table inside it.
I want to create a css file for the accordion (accordion-style-1.css) and another one for the table (table-style-1.css). I do this so I can have different css files for different stylings of both the accordion and the table. This way I can just swap out the css with whichever style I want.
Now we have an accordion, and a table inside it, and we have two css files for both the accordion and the table. Save the accordion as a custom component and give it a name, say "Fancy Accordion".
Place the custom component into a new document.
Now you end up with a css file: Fancy-Accordion.css.
What happened to the two separate css files accordion-style-1.css and table-style-1.css? Why did they got merged into a single file as opposed to just simply have the same two css file? Why not have an option/checkbox that specifies to keep the css files as is?
+1 I would have to say this is definitely a good point. Files in the Library components should not change content or be merged. Changing the name for them is one thing, but as long as we put a comment at the top of each file to say what it is for that's doable, but combining them is definitely not a good thing at all. Especially, as in the OP's case, when there are probably a ton of duplicate CSS Classes/ID's that now are merged together into one file and no way to know which is which.
Files added to components should remain intact as they were added.
I can confirm this behavior. Saving a component that references multiple stylesheets to the user library will consolidate those stylesheets into a single stylesheet. I think this is necessary behavior. If you have ten stylesheets, and your component uses a few classes from each one of them, and you save that component to the library, do you really want it importing ten separate stylesheets, each with just a few rules? And what if one of those stylesheets is named the same as an existing stylesheet in your design? Does the component refuse to import? Overwrite your stylesheets? Force you rename them?
It would get very cumbersome, so I can see why the devs chose to just have all the classes consolidated into a single stylesheet.
As for your wanting to "swap out" stylesheets to change the look/feel, that seems like a convoluted way to do things. Just create different IDs with different rules in the same stylesheet, and then change the ID on the component when you want to change how it looks.
It would get very cumbersome, so I can see why the devs chose to just have all the classes consolidated into a single stylesheet.
No, I do not see that. Currently you can specify for EACH style whether you want to include them or delete them. It is really not hard to put in a checkbox to specify whether all stylesheets should be combined or not. I am not asking for an AI algorithm that will intelligently detect if I have multiple class names in different css files. That's the problem of the individual who created the stylesheets, not the developers.
As for your wanting to “swap out” stylesheets to change the look/feel, that seems like a convoluted way to do things.
Actually, it is not. It is a clear and conscience way of doing things. You don't know the requirements or the specifications so it is not about a single button with 10 different background colors.
If you have ten stylesheets, and your component uses a few classes from each one of them, and you save that component to the library, do you really want it importing ten separate stylesheets, each with just a few rules?
Why would a component need 10 stylesheets? Did you just say something completely random without a thought behind it?
I wanted to create 5 different accordions. Each accordion have tables in them. Each accordion needs to look different, but the tables have only 2 different looks. Instead of creating a single project for all 5 accordions and 2 separate projects for the tables, I wanted to place them into a single project, create a css file for each, so I can import them based on which one I need in which combination. But apparently that is not working because all my stylesheets are getting combined into one.
So it seems I will have to create separate projects for each.
Assign unique IDs to each of your five different accordions and two different tables. Then put all your CSS in one stylesheet (eg. master-accordion.css), and use IDs and classes to change the appearance of the Accordions and tables as needed. I don't see what the advantage is in loading completely different stylesheets just to change the appearance of a component.
Thank you for the feedback folks! The reason why stylesheets are merged is because we want every component to produce a single stylesheet with a matching name when it's dropped in your design. This helps in keeping your code better organized, which is a big issue when downloading other people's components.
Multiple stylesheets have benefits, of course, but on a component level the same can be achieved by bundling all relevant CSS in a single stylesheet, like @Printninja suggested. You can then use class names for variations of your component (e.g. dark, large, striped etc), which would cause different styles to be applied.
Yeah, I realized that every component needs to be in their own files in order to make this work. Originally I was trying to cut down on the files and had all the components in a single document, hoping I can jut output the individual css for each component. But that didn't work, so I ended up just using one file per component.
I was just going to suggest that, create a separate component for each of the varieties. I do understand the reasoning though and it is probably for the best, but still would be nice to have the option.<br />
After all, if you add a prefix or suffix to the file names, it's almost impossible that it will overwrite any files even if there were separate CSS/JS/etc. files in the component.
I look at things like this: If I can do it in the real world outside of BSS without any issues, very simply, etc., then I should be able to do it IN BSS as well. Some of the things people have asked for over the years are basic editing features (edit the HTML directly, edit the text content in the HTML Directly, ability to link or reference files within a local folder (and it's sub folders) as if it were part of the project, use our own fonts, and so on.
These are all things that are basic to web design and used constantly when you are coding. We shouldn't have to hinder our creativity in order to use another tool I guess is what I'm saying. If I were coding in Brackets or Dreamweaver or Textmate etc. I could do all these things within seconds. In BSS I have to use work arounds to do basic things which adds to the project time, and after 3 1/2 years that should not be the case.
P.S. Not a rant or anything like that, just a very astute observation.
I agree with you Jo. There should be an assignable files/media folder in BSS that corresponds to a local folder on one's hard drive, so that when you export the project for uploading, it creates a subfolder in the BSS assets folder with the copied files.
Actually I wasn't even going quite that far, but I like where you went with it lol. My idea is just to be able to reference them and the app would be able to read them from a folder outside the app rather than only things inside. Wasn't thinking to save anything, just reference it so it was viewable or usable. You know, for some of those things that you can't import (PDF's, videos, text files, etc.) as well as images that we could just have an assigned project directory (not to be confused with the export directory) with whatever files we need, and the content would show up in our previews, or be downloadable from our previews.
Basically to be able to have a local directory for our site/project that the app would be able to read from same as it would from it's own files.
Your idea is great too, but probably wouldn't work for files that cannot be imported yet.