I tried to take a look around here and on the Liferay forums but I couldn't find a documented solution to my issue.
I am currently using Liferay 6.2 and am very new to the environment. My issue arises from CSS #import functions. Our architecture is one main stylesheet with all supporting stylesheets imported into this document. Those CSS documents in the same directory present no issue - for example #import url(document.css);. We do have a master stylesheet located in another portlet and all other portlets reference this stylesheet with an import call similar to #import url(../../../../folder/folder/document.css);. When using this command, the CSS in this file isn't imported into the portlet. If I place the master stylesheet in the same directory as the CSS for that portlet and adjust the import path accordingly, the stylesheet is imported without any issues. I can also place it one directory up such as #import url(../folder/document.css); and the CSS is imported correctly.
Several team members do not have this issue, while several members do experience this issue - all running the same version of Liferay and on identical machines.
I'm sure my question is fairly vague due to me being new with the environment so if I can clarify or provide any additional details, please let me know!
If all of the portlets reference the same CSS file they shouldn't: Just assume that the necessary CSS is deployed through the theme and add it to the theme once. This is way more elegant than delivering it multiple times, relying on relative paths to not have changed, and potentially not being available (at runtime, nobody guarantees that an appserver even unzipps your warfiles).
Through enforcing the assumption that you're running in an environment that has proper styling, life will be so much easier.
Related
Disclaimer: There are a few questions on SO regarding CSS and debates over a single or multiple CSS files but I think this is a bit different
I have a pretty big Angular 7 app using Angular Material 2 and I want to introduce themes. Each theme will be retrieved on user login (the theme is saved on the server and cannot be changed by the user).
The question is mainly regarding whether it would be best to export a single CSS file using top-level classes (body or app container) for each theme, replacing only classes that change for each theme or lazy load a new css file on top of the main css file with only the classes that are getting overwritten.
My biggest concern with the first option is getting a huge single CSS file. The current file is already around 300kb (unminified CSS is about 11k lines of code) and with themes ranging from 200-500 lines each and there could be 10+ themes, the file can easily get double or even triple that amount.
On the other hand, lazy loaded CSS might cause the user to download 2 smaller files but the implications might be worse. For example a lazy loaded CSS file needs to be exported with separate configs in Angular CLI and the name needs to be specific so it can be loaded from Angular on login which means caching might be an issue if something changes and also no versioning (eg. theme-blah-2.17.css) is also not possible in the name of the file. Possibly other implications that I cannot think of at the moment too.
Look at how material handles themes.
Also, take a look at how teradata Covalent handles themes.
I'm using CSS Modules (Sass) with rollup on a component library project, which is working well. Each component ends up with a dist folder containing a single JS bundle file, and a corresponding CSS file with the scoped CSS classes so consumers of the component don't have to worry about CSS class name conflicts. All they do is include the JS bundle and the CSS file and everything is great. Yay CSS Modules.
The problem I'm now facing is that some components really need separate "themes" - ideally, separate CSS files, one per theme. So consumers can continue as they've been doing: including the JS bundle, but now choosing which CSS file to include to pick a theme.
I'm not sure how to get this going with CSS modules & rollup, and whether this is even the sort of approach others are taking. From what I can see, rollup always handles bundling things together, whereas I want separate CSS files, all of which get their classes renamed identically during the build phase. That way, if within my JS I refer to styles.myclass, if myclass had gotten renamed to scoped-myclass by CSS modules for the original CSS file, for a second CSS file it would also get the same name.
This would keep consumption of the component extremely simple - just a matter of including a different CSS file.
Any suggestions?
Awfully late, but let me answer this 3 years on. So what I ended up doing was totally detaching the CSS generation step from rollup and relying on the Sass CLI to handle that portion of the build process. It felt a bit klutzy, but I remember it wasn't awfully hard to do and solved the problem I outlined above. I don't believe there was a plain rollup solution at the time, nor do I think there's one today.
However... in my case the whole approach was kinda mistaken. This certainly won't be everyone's scenario, but let me spell it all out because hey it may be useful and it definitely wasn't obvious to me at the time.
This was for an in-house shared component library, where each component and its corresponding CSS was a separate npm package stored in our Artifactory. When it grew, plenty of internal references popped up, e.g. multiple components would reference the Button component, and over time they'd reference different versions of the Buttons component - each of which needed its own properly scoped CSS, unique to that package-version.
So what I found was that by doing it this way - having the CSS generated as part of the npm package dist files - I had to write an additional layer for the consumer applications that would parse their node_modules/ folder for our own internal components and combine all the different CSS files, such as the multiple versions of buttons. e.g. the main application would directly import buttons v1.0.0 in its package.json file, but the Dialog component (also included in the package.json) could include buttons 2.0.0 as its own dependency. For every version of the package, there was a uniquely scoped version of the CSS - so the consuming application HAD to include every version otherwise the styling would be borked.
So all in all, it ended up being way more complex that I wanted. I thought I could make it easier & better with the separate generated themed CSS files as part of the package dist, but it didn't end up that way. If I could revisit that project today, I'd re-examine a solution used by Material UI and others which I kinda poo-poo'd at the time: automatic injection of the CSS into the page by the component JS, rather than generating standalone CSS files which required extra work by the consumer applications to gather up and add to the final webpage. Frankly, now I regard it as the "least crap". There are definite downsides to the injection approach (extra work done on every page render for everyone! Yikes!), but there's no doubt in my mind it hugely simplifies the job of the consumer applications. It's a balancing act, but in 20-20 hindsight I'd lean towards the injection approach. With that, scoping & theming is a different and much simpler problem.
If I got you right, consider looking at SCSS plugin: rollup-plugin-scss. It captures all spare .css files imported in the components, and then processes them through underlying node-sass. The catch is, it seems like you can write a custom callback function that'd handle your CSSs differently based on conditions you throw in.
Based on the example from the plugin's page:
import scss from 'rollup-plugin-scss'
...
export default {
input: 'src/index.tsx',
output: [...],
plugins: [
...
output: function (styles, styleNodes) {
// replace this with conditioned outputs as needed:
writeFileSync('bundle1.css', styles)
writeFileSync('bundle2.css', styles)
},
]
}
I'm new to web development and am developing a website using bootstrap. I've got quite a few .css files that involve bootstrap, an open source bootstrap theme, some style sheets for the plugins I'm using and etc. Thing is, I feel like I'm doing the same thing over and over again, putting a lot of overhead on things.
For example, this is how the styles on the web page I'm developing currently operate:
Bootstrap default theme is loaded
Bootstrap custom theme is loaded, overrides the majority of the default bootstrap css configurations
My own custom css file is loaded, overrides the majority of the custom theme css configurations
I guess it's worth mentioning that my custom css file only overrides colours and borders.
I'm thinking if the theme is open source, should I just edit the theme itself? Or should I still be editing everything within my own custom css file?
Again, I'm very new to web development so apologies if this is quite a silly question. Optimisation is key for me, though. After the development stage I will combine the CSS files using bundles provided by the Microsoft.NET optimization package.
Never modify a library directly (css, js, php etc.). What if a new version come out, fixing some bugs. You can not download it, because it will override all your fabulous work.
You get the right process right now. Import your libraries, then override them with you own file and lines of codes.
In your case, it does not matter at all the number of files you are importing, because you will combine and minify them.
If you really care about performances, I suggest you to look at the "CDN" systeme, for Bootstrap or jQuery it could be interesting and provide some good benefits.
Look at this question and the answers, they will give you some good hints : Single huge .css file vs. multiple smaller specific .css files?
I'm trying to upgrade a Plone 3.3.5 server to 4.3.6. However, when I update the site, I find that the CSS for the site is not carried over. If I go to my CSS Registry, I find that almost all of my CSS is producing the (resource not found or not accessible) error.
My confusion seems to be in how Plone locates and links/imports stylesheets in general as Plone seems to be loading virtually none of my CSS and pretty much giving me raw HTML in the browser. I'm assuming the CSS registry is loading CSS from the buildout-cache. With this assumption, an example stylesheet that I'm targeting is located under:
Plone/buildout-cache/eggs/Products.NuPlone-1.0b3-py2.7.egg/Products/NuPlone/skins/nuplone_styles/base.css
When the CSS Registry failed to load this, I noticed that some CSS was being loaded in via handles like this:
++resource++tinymce.stylesheets/tinymce.css
But this format doesn't work with base.css and others.
So my question is, given I've got a new product installed with some CSS included in it, how do I get Plone to target said CSS?
For resources inside "skins" FS folders, the way to register on portal_css tool is to simply provide the filename, so simply put there base.css.
If this is not working probably the nuplone_styles skin folder is not registered properly in the portal_skins tool.
So go to ZMI --> portal_skins --> click on "Properties" and check the following:
what theme is used? You must probably switch back to NuPlone (but I'm not sure if it works on Plone 4)
is the nuplone_styles folder in the list of CMF layers of the used theme?
Please note also that adding the nuplone_styles layer to another theme is not a good idea. Please think about copying CSS you need in the custom directory.
This is not an answer, but some additional explanation, not fitting in a comment:
The "old" way to include style-sheets via skin-folders, requires to specify only the file-name, not a full path, and will be found by traversal, meaning the first found file with the according name, will be taken. In case of several files with the same name, the order of skins matters.
The other way is to register style-sheets via a browser-package, to have an unambiguous path to a certain file, they must start with +++resource++.
I know that there are questions regarding this same topic, but for HTML. What are some good conventions in regards to using external stylesheets in a Flex app.? How would you break up the stylesheets (names of stylesheets and what they include)?
Flex compiles the external CSS file when you publish your project.
There is a way to load CSS at runtime using Flex; it can be done by compiling CSS files into SWF files and load them at runtime using StyleManager.loadStyleDeclarations.
See the LiveDocs on Stylesheets at Run Time for more info.
Some conventions we use in organizing stylesheets:
Have one main.css stylesheet that holds all of the data for skinning the base application.
Have one fonts.css stylesheet to store all of the fonts in the main app, because these can get quite messy.
The main.css stylesheet is included in the main swf via the <mx:Style source="main.css"/> tag. We load our app with as little as possible, and once everything is loaded, if we need to immediately show some text (sometimes we just have a video playing if it's an advertising site), we fade/tween in the main elements and load the fonts.css via StyleManager.loadStyleDeclarations at runtime.
If we have an admin panel, we have an admin.css stylesheet which we load at runtime because the main app doesn't need it.
We don't need to divide up the CSS anymore than that because we usually create a whole set of skins in a Theme, so the stylesheet is just applying those skins to components and is pretty lean (using Flex 4). I tend not do divide stylesheets into anything smaller (like "pages.css", "comments.css", "popups.css", or even "controls.css", etc.) because it would be overkill and too much to manage for little in return. That's common with HTML, but that's because HTML requires CSS for nice presentation; Flex could do without CSS entirely.
When developing, one of us usually develops most of the skin right away (having a default wireframe setup, like those found on ScaleNine as they do the photoshop/flash/after-effects. There's no way to not have to recompile the css swf if you make changes. But if it is loaded at runtime, you only have to recompile the css file and not the main swf, which is useful but not really useful during hardcore skin development.
I tried keeping the main stylesheet separate during development (in a custom Theme), and it made development a LOT harder, because I had to recompile the css separately every time I made a change and sometimes I had to recompile the main app too, and there were strange and hard-to-track-down bugs, etc. Then I was compiling two different apps. So I recommend keeping the main css file part of the main app.
If you wanted runtime css without having to recompile anything, try Ruben's CSS Loader and check out the source. But that would come at a runtime performance cost.
Flex is not something I've dealt with, but I did some research. It looks like the code to call a remote stylesheet is this:
<mx:Style source="com/example/assets/stylesheet.css" />
Flex Quick Start: Building a simple user interface: Styling your components says this:
Note: You should try to limit the
number of style sheets used in an
application, and set the style sheet
only at the top-level document in the
application (the document that
contains the tag). If
you set a style sheet in a child
document, unexpected results can
occur.
The implication of this seems to be that multiple stylesheets are not really possible. It sounds like what you want to do is organize your stylesheets, check out Organizing Your Stylesheets and Architecting CSS for some ideas for approaches. It looks like you have classes and basic tags, but the W3C stylesheet specifications are different from the Flex stylesheet specification.
As a non-Flex developer, Namespaces looks interesting as a way to organize namespaces: How to use the new CSS syntax in Flex 4.