As I become more familiar with Angular, and the vast number of modules out there for making an application really shine, I am also becoming overwhelmed at understanding the basic logic of CSS overloading, and how to manage the imports to get the desired behavior.
For instance, I have pulled the following libraries into my Angular application; Boostrap, Bootcards, boostrap-select, font-awesome, and some custom bootstrap-wizard libraries for a modal tab-based wizard.
All of these libraries require being defined in the index.html page of my Angular app (both the CSS files the JS files). How do you manage the desired behaviors so that one components styles don't override another components styles? What are the best practices around bringing in multiple components and using them in an Angular app, without negatively affecting the applications previous behaviors?
You have 3 choices:
Place more important CSS files AFTER less important ones so the more important override when both have same attribute names.
Manually go in stylesheet and change attribute names.
Instead of including the stylesheet in index, include it in your html file
Related
New user to 3rd party bootstrap templates for Ember and need help.
I purchased the INSPINIA admin template from www.wrapbootstrap.com. The download comes with multiple pre-created projects with INSPINIA built in (e.g., Angular, Rails, etc.) but not for Ember. I reached out to the creator to see if they could include a project for Ember and they said no.
So, I am curious, does anyone know how to add INSPINIA to an Ember web application? Is it as simple as ember install bootstrap and then copy the *.css file? Note: the INSPINIA template comes with way more files than just a *.css, and I am using ASP.NET CORE 2.2 for the web API.
Any help is appreciated.
When I did the same thing a few years ago, I bought the theme just for the themed css. I used their less and integrated that into my existing ember build. Nowadays I'd use the scss but it's unimportant.
What is important is understanding that bootstrap js components will not simply work in the context of your ember application. If you want callbacks, events, binding, etc to exist in the context of ember (ie within ember's runloop and lifecycle), you will need to wrap each individual component. Luckily, ember-boostrap does exactly that for you. This addon provides the easiest way for you to pull in your bootstrap scss. This addon also does not use bootstrap's js, but rather is a full implementation of the bootstrap component's in a way that is ember-aware.
ember-bootstrap deliberately excludes bootstrap.js
because the jQuery and Ember ways of control flow and animation
sometimes don't play well together, causing unpredictable results.
This is the main motivation behind ember-bootstrap. It is possible to
import bootstrap.js from bower_components or the vendor folder. This
is NOT recommended or supported, and you will be on your own. You have
been warned!
Once you've gotten the scss preprocessing properly set up in your ember-cli-build.js file, you should be able to use their markup more or less directly. You will need to have some understanding, though, of when you're encountering bootstrap markup (stuff with data classes that will be handled by bootstrap's js). In moments like that, you simply use ember-bootstrap components instead
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 am making a static website with Flask and using the flask-bootstrap extension to simplify the front-end development. I concurrently have been learning Rails and so I understand that there are a few of these languages that compile down to CSS (LESS/SASS/SCSS). As I understand it, Bootstrap by default uses LESS, and in my Rails app I had to convert LESS variables (with an # symbol at the beginning) into SCSS variables (with a $). This wasn't too difficult, no problem.
I noticed that in Miguel Grinberg's tutorial (Flask Web Development, O'Reilly) Bootstrap is used (Flask-Bootstrap extension), and there is the brief mention of {% block styles %} used to include stylesheets that way, I am confused about how I can go about modifying the existing LESS variables that come by default with Bootstrap so that I can modify the grid structure and not mess things up with my own custom stylesheets. I want to be able to do, for example, is modify the #body-bg LESS variable, or any of the ones here: http://getbootstrap.com/customize
It is very interesting question. I also was interesting in creating styles dynamically. You need follow another ways. It is not possible by the way you have described above.
You mentioned you used Flask-Bootstrap. This extension adopts the Flask project to use the Twitter Bootstrap styles. I have not fond any SASS/LESS functionality.
http://pythonhosted.org/Flask-Bootstrap/#
https://github.com/mbr/flask-bootstrap
If you look at the static folder of the extension you will not find any tracks of SASS/LESS.
As I know Twitter Bootstrap is generated by LESS. There is also a SASS fork. You regenerate styles and replace them in the static folder of the Flask-Bootstrap project.
If you want to do it dynamically you need create your own solution. I do not know a ready extension. It is the very challenging task.
I've started a Rails project and implemented bootstrap-sass into it. A short time later I found a theme/template using a different version of twitter bootstrap. I've added the template to the app but the view doesn't align perfectly as was intended. I then added the specific assets that came with the theme/template to my project (such as jquery version, ANOTHER older bootstrap version) and the result is almost perfect. However, there are still some alignment issues. When I inspect the CSS I can see it's happening because of conflicts between the two versions of bootstrap.
I'm thinking I should make it so that this template only uses the version of twitter bootstrap that came with it. If so, how do I do this? How do I make it so that a rails view will only use a certain css stylesheet and not read from others?
(If this is not the best solution, what are some alternatives I should consider?)
Thanks
Try this out:
1) use 2 layouts (application.html.erb and new_application.html.erb)
2) have two master javascript/css file (application.js and new_application.js, application.css and new_application.css)
3) inside your application.html.erb include the first application.js and application.css, on your second layout, import the new application js and css
4) for the specific parts of your page, on the controlle inherit from the right parent controller for whichever layout you want.
class NewBootstrapController < ActionController::Base
layout 'new_application'
end
class OldBootstrapController < ActionController::Base
layout 'application'
end
Best practice is to try to view your project as consisting of "components" rather than pages. So focus on keeping the styling for your components up-to-date and consistent.
So rather than coding for individual pages, which doesn't scale and is difficult to maintain even with small(ish) projects, look for ways to turn elements into reusable components. Bootstrap is this way by default, so if there are certain components you use more than others, make those the priority for refactoring, and then look for repeating patterns across your pages and try to think about how you can create semantic, component-based classes to describe them.
Instead of this:
.sidebar-home {}
Try this:
.sidebar-narrow {} // or whatever describes your element
The operative point here is that if you will ever work on more than this project, get into the good habit of thinking about your CSS/HTML as consisting of components, and you will be able to reuse code and become much faster at identifying patterns in your UI.
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.