I'm styling a page right now (developing using libsass), and I'm making changes to font-families, headers etc. For a lot of these changes, I notice that they can be altered in _settings.scss.
My question is, should I be making a bunch of changes to _settings.scss and also adding custom styles to app.scss? Its apparent that app.scss is really intended for app specific changes, but is _settings.scss also intended to be uses this way?
I recommend using _settings.scss as much as you can and create extra scss files for modules and include these in app.scss.
You should customize Foundation through _settings.scssIt's well documented with comments and since the settings can influence multiply css classes, it's the best way to achieve consistency.
Related
I recently started using SASS and right now I need Font Awesome for one of my project but I want to use it offline. I know that I could simply use CDN (as I did) but I just don't know how to use it offline so it's pretty annoying :D
Well, basically you just download the resources, add the .js/css-links to your .html and use the icons ;-)
It's all described on their website - but the choice of options (CSS or SVG) might make it look more difficult than it is...
I want to use onsen for a mobile web app. Most people seem to use it with phone gap/cordova so that the result can be installed as an app.
Am I going to have performance issues if I use it for a website?
The minified JS alone is 350kb and the css is almost 200kb. I suppose I can gzip it but I just want to make sure I'm not misusing the tool and doing something crazy.
Hmm actually
https://cdn.rawgit.com/OnsenUI/OnsenUI-dist/2.0.0-rc.15/js/onsenui.min.js - 85KB
https://cdn.rawgit.com/OnsenUI/OnsenUI-dist/2.0.0-rc.15/css/onsenui.css - 3.2KB
https://cdn.rawgit.com/OnsenUI/OnsenUI-dist/2.0.0-rc.15/css/onsen-css-components.css - 25KB
These are the only 3 files which you actually need to use Onsen UI.
If you want to use something like angular, react etc there are additional js files which you may need, but only if you want to use the frameworks.
And of course for the css - if you want to use some sort of icons either font awesome icons or something similar you would need to add those too, but if you're not using them you don't need to serve them.
As for performance issues
for loading you can concatenate the files to make less requests (you said you will be gzipping them so I guess you will probably also be doing this)
after everything is loaded I don't think you will be able to notice a difference between the app and the webpage.
I may be missing something, but I think this is pretty much it. Basically just include the things which you need - no need to include angular bindings if you're not using angular for example :D
Project utilizes AngularJS, Bootstrap and KendoUI. Issue is, Kendo advertises that it "integrates" with Bootstrap, when in fact it only really mimics bootstrap styles.
I've got a LESS workflow established with grunt, proper Bootstrap variable overrides and all, but I'm having the damnedest time finding source files for KendoUI.
All the documentation I've come across wants you to use some Theme Builder tool, but this isn't ideal. When you use the themebuilder, it includes a LESS file with variables, but I can't find the source LESS files for KendoUI Pro (which I've purchased a license for, so you'd think they'd serve it up on a platter.)
For anyone in the sorry position of having to use Kendo, you have to get the source files from the Telerik Control Panel.
Also, have fun tracking down the variables because their scattered across the four winds within the LESS files for both the core and theme packages.
Is there any way to convert html template to Liferay 6.2 theme ? Is Alloy UI help me about this ?
There is no "one-click" tool to convert an html template to a liferay theme. You have to implement the theme yourself and use the "diff" folder to configure your own custom templates (.vm), scripts (.js) and styles (.css). Check out the official docs:
https://www.liferay.com/documentation/liferay-portal/6.2/development/-/ai/creating-themes-and-layout-templates-liferay-portal-6-2-dev-guide-09-en
https://www.liferay.com/documentation/liferay-portal/6.1/development/-/ai/creating-liferay-them-7
+1 for Artem's answer which gives you the correct answer to your question. As a "no" might not be what you were looking for, let me add some reasoning extra - why would such a tool be introducing even more work later in the game?
If you look at the basic structure of Liferay's HTML code - all the nested divs, classes and ids - you'll find that they're quite clean and structured. A lot of Liferay's functionality is implemented with this kind of DOM in mind. If you'd introduce your own, completely unrelated, DOM from your own template, you'd need to find all components in Liferay that assume a certain structure. For example Layout Templates: They define "drop zones" where you can add portlets to the page. You probably don't have them in your existing templates. Another example: Maximized portlets. They'll need a DOM element to go into.
IMHO you're a lot better of to stick very close to the original DOM and just tweak your CSS to address the classes/elements you need. This is, of course, just a very general recommendation - for certain usecases this approach might also be a disadvantage. But most of the standard usecases are covered IMHO
We're using the SASS version of Foundation 4.
A co-worker is saying you shouldn't modify the sass files in case you want to update it in the future; which is a good point.
I think it's necessary to modify the files in order to make proper use of the existing mixins and nesting.
I'm hoping someone with more experience could shed some light on the proper way to use the framework.
For development I would definitely suggest not touching the core files as your co-worker pointed out.
Since you are using SCSS, you can easily include the core files into your own version of them (which add/overwrite rules).
Example: /scss/custom/components/_my_alert-boxes.scss
#import("/scss/foundation/components/_alertboxes.scss") // Foundation core
$alert-border-style: dashed;
#mixin alert-close {
//Override default mixin.
}
Then once you are ready for production you'd want to go back and remove all the unused rules, minify code, and all that good stuff.