Here's a situation I run into a lot with CSS architecture using BEM/SMACSS. I'd like to see how other developers handle it.
You have a library of CSS modules that you use across multiple sites. Modules like .btn-group, .nav-tabs, etc.
Then you encounter a module that's styled in a very site-specific way -- it's too unique to be able to use one of your library modules.
So you have the code for that "site module" in a Sass/Less file and you save it with the other style code for that site, like the layout styles. It's not saved with your "library modules."
My question is: do you do anything to distinguish the "site module" from your "library modules"?
I usually follow YAGNI principle in CSS which helps making decisions in these sort of circumstances. Following always implement things when you actually need them, never when you just foresee that you need them approach a new module starts its life as a site module. Whenever I need to use that module in more than one site then that is the moment I consider turning it into a library module.
This issue is solved with the help of Levels of Definition.
The main idea is that you can split blocks (even parts of the same blocks) into different layers which you combine on a project. E.g. you can have library level (or a few of libraries) and a project level or it could be different levels according to environment: common parts for all the platforms and different ones for desktop and tablets and so on.
See http://bem.info/method/filesystem/ for more details.
Related
I'm thinking about changing the processCSS gulp task that Aurelia CLI creates to create physical css files, instead of including it directly in the app-bundle.
Are there any major drawbacks within the Aurelia framework to doing this?
I'm more comfortable with separate css files after preprocessing, but I don't want to do it if I'd be missing out on some performance benefits, or create other troubles down the road.
I don't think there's any major drawback that can't be reasonably overcome. However, I would try to evaluate the benefit of doing it your way, instead of bundling it together.
I'll list a couple of points I can think of, in no particular order.
It can be challenging to get the modules and paths set up correctly if you are requiring CSS from standalone CSS modules. If you are using plain CSS files, then you will need to included and maintain the Link tags in your host HTML page. All this is easier if the CSS is bundled directly into the app bundle. Especially when adding more CSS due to 3rd party libraries etc.
if you are using the organizational pattern where you create css-per-component instead of having one monolithic CSS file, then there are potential performance impacts to making http requests for each individual css file, although the impact is probably more thoeretical than practical.
when deploying, it is really nice to just deploy a minimum number of files.
when all css is bundled, you can add comments at top of each CSS source file to help identify the source file when looking at the CSS in the browser inspector.
One last thing, it may be worth your time to experiment loading the CSS in different ways, including as individual files and see which way works best for your environment.
As an interaction designer looking for better ways to collaborate with developers, I have tried to introduce Pattern Lab to my current client. The lead developer for the front end framework pushes back, however. Main gist of his argument:
Our toolkit has complex components that require JavaScript or a JS library in addition to HTML/CSS. This would not mix well with the Mustache or Handlebars templating in the Pattern Lab. Thus we use Angular JS, which is the framework that our components are written in.
I have tried to look for articles that discuss this topic. There's nothing here on SO as far as I can tell. Outside SO I have found just a few posts (example), but nothing that's specifically on the topic of Pattern Lab's (lack of) compatibility with Angular, except for a parsing issue that was solved two years ago.
As a non programmer I don't have the necessary influence to sway my developer peers. Would be great if someone with hands on experience could elaborate.
Reusable patterns created with Pattern Lab are IN NO WAY dependant on Mustache, so your developers can rest assured that pattern Lab does not introduce any dependencies that will carry over to their code.
In fact, the whole point of a style guide, built using Pattern Lab or not, is to build a language independent library of style patterns -- HTML markup and CSS -- which developers can reuse in their apps, whether they choose to build them in AngularJS, ReactJS, Plain old server-side code behind or something else.
Pattern lab is just a convenient tool for the front end developer or designer who maintains the style guide. It generates a static style guide website showcasing the different patterns. That website will be the tool for project developers using the patterns. Just as AngularJS can be used in any static site, it can of course also be used in a static site generated using Pattern Lab.
Mustache is part of the tool stack Pattern Lab uses to generate the static website, but no traces of Mustache or dependencies upon it carry over to the resulting website. I serve several AngularJS teams with design patterns hosted on Pattern Lab, and none of them have ever had to touch or even know about Mustache.
If your developers are familiar with frontend frameworks like Bootstrap or Foundation, which offer documented patterns for different front end blocks, this is just the same. Developers on different projects can copy HTML markup and CSS code without any other dependencies.
A style guide should be a prerequisite in any modern web development setup, as it's a prerequisite for smart and efficient collaboration between developers and designers and makes quick prototyping much quicker. So I think the discussion you should be having is whether you should use a style guide to collaborate and aid more efficient collaboration. If you come to an agreement around that, Pattern Lab is just a smart choice for developing one.
Here's a good intro to using style guides, and also to different toolsets you can use to build one. Pattern Lab is listed under the section for Style guide platforms:
https://www.smashingmagazine.com/2015/04/an-in-depth-overview-of-living-style-guide-tools/
Hopefully this can spark a better discussion with your developers, they're missing out if they stop you building a style guide.
Maintainer of Pattern Lab Node here.
I just created this reductive sample repository illustrating Angular within Pattern Lab.
Repository https://github.com/bmuenzenmeyer/patternlab-node-angular-example
Live Demo http://www.brianmuenzenmeyer.com/patternlab-node-angular-example/public/index.html
As you can see, Pattern Lab can run arbitary frontend code, including Javascript, within the confines of a single pattern, so a motivated individual could showcase components using it.
That said, I don't think that PL's "with the grain" approach of building atomic components works perfectly with Angular (like, don't build your whole app in here) but showcasing the JS behind, say, a tooltip or modal component, is possible in isolation.
This strategy would be similar to reminds me of https://rizzo.lonelyplanet.com/styleguide/design-elements/ - in which they have UI components alongside JS components.
Hope this helps clear up any confusion.
We have successfully built Pattern Lab into our development workflow. We simply adjusted the patternlab build to copy the resulting CSS files into the assets folder of our application. Developers write all CSS and templates in Pattern Lab and the generated files are automatically used in the app.
I have something on my mind for quite a while but couldn't find an answer to it. Consider the following:
You like to build a fancy website with React and have to decide which front-end framework you should use. In my example I have chosen Material-UI.
Now you came to a point where you need more features like a responsive grid system, show/hide styles etc. Instead of implementing them on your own (or copying it from bootstrap/foundation, for example) you think: 'Hey, why wouldn't I include another framework beside Material-UI'.
Now comes the question. I know that most of the css frameworks available have their own normalisation css and basic styles for typography and other elements.
Can I safely include another (more featured) css framework beside Material-UI without breaking fundamental things or should I avoid that?
Furthermore, what is a good practice approach to extend the css features without copying parts from other frameworks and without reinventing the wheel all the time. Did you ever had a case or project where you had to combine multiple front-end frameworks and how did you solve this problem?
Thanks for your feedback.
Cheers
Gregor
FYI, there's a Material Design version of Foundation, you can check it out at http://eucalyptuss.github.io/material-foundation/
Now, talking about your doubts... one should be very careful when mixing and/or using more than one framework at the same time... one issue can be conflict, other can be unnecessary bloating which could make load time heavier.
However, if you are aware of that, most of modern frameworks (as Foundation) can be compiled partially, so you will be loading only the stuff you'll use, minimizing all possible issues.
Have been thinking this exactly thing lately.. I would choose one that has most of the features i need in my project. I usually go just with Bootstrap (sass version) and use only the styling part of that (css grids mostly).
Mixing frameworks will eventually be hard to maintain and you have to include lot of extra (unused) features into your application. When using some "cool", full featured components like Material-UI has, there will still be times when some component doesn't have just the property you would need.
So my opinion is:
Use some framework for styling only. This way you have uniform look in your site. Or even just some responsive grid library could be enough.
Usually basic html components are enough to fill basic needs, you can just build your own custom components for special needs (or use some from npm library). This way you have just the features you need.
This way my site is not depending just some single framework. I can change the styling part anytime, i can change one component to another etc. without having to re-write my whole application just because it's been developed entirely with some "full featured" framework.
I am running a server that hosts several disjunct instances of MediaWiki for several customers. There are a few set of CSS adjustments, which I would like to apply server-wide and "group-wide".
I already checked out WikiPedia's stacks of CSS classes, but they are all predefined and would most probably be overwritten on updates.
It would be perfect, if there were some kind of css.d folder, where I could store links to CSS files, but to the best of my knowledge there is not such a thing.
How should I realize sharing a CSS file among several instances?
Within a wiki family, install the GlobalCssJs extension and edit the MediaWiki:Global.js/MediaWiki:Global.css pages on the central wiki (manual), as you would do to customise a wiki's CSS.
Alternatively, write your own extension to make all your custom changes in a single place (the code repository) and then deploy them to all wikis with the usual methods you use to update code.
This is a serious question, specifically relating to the many frameworks out there for Wordpress and Joomla - Warp, T3, Gantry etc. What I dont understand is how they are different to a starter template and what exactly you are supposed to do with them - simply child theme them or is it a whole other codex to learn? I mean, all of the native codex is there with Joomla and WP anyway to construct a theme simple enough so what good does a whole proprietary app do between your design and the CMS? Are they faster to develop with?
What confuses me is that people seem to love them and claim that they make life easier but I dont get how adding another technology to learn can make things easier. Like I say, it is a serious question, not one for effect to make a point.
Can anybody define the difference between a framework and a starter template? I ask in part because I am one of those anxious developers who always feels like I am somehow missing a trick or doing things the "wrong" way - what am I missing?
This is definitely mostly an issue of definition, and I can guarantee that some cases will not follow what I outline below. Obviously, anyone is free to call the template/framework by whatever they want.
Generally though, a template is comprised of basic HTML and CSS that works with the platform (Wordpress, Joomla, etc) that is used to build the output to the page. In Wordpress, this contains the loop and other constructs to get all the content for the page. In Joomla, it outlines all the module positions available and such.
Typically when you purchase a higher end theme, you will have significant choices on the backend to customize the theme without having to actually code. These parameters let you typically change colors and such.
Some of the theme developers and others have taken this parameter settings system to the next level and made it into a framework. In all the cases that I've seen, "framework" is really the basis for the template parameter system. In this way, you can have consistency between different themes and expect the same settings and features between different themes. This is why they use a different word, because it really isn't a "theme" any more. It really is like a "theme engine" in that it is a backend system for changing things in the theme.
Yes, many platforms offer some basic options for editing the theme out of the box, so in most cases, the framework is really an improvement on the base platform's theme engine.
It's been my experience that a theme will be a visual style along with a set of theme options available in the admin (in addition to Customize if it's supported).
Theme Frameworks on the other hand, like Thesis, are installed just like a theme but have a very vanilla visual style that you build your theme on top of. Usually the framework provides many added features that aren't available in WP core.
tl;dr - Themes frameworks aren't installed and used right away, they are installed and built upon to deliver a site.