How can I get support for multiple screens such as tablets and phones to work in NativeScript with Angular (I am on NS 5.1 now)? I am currently trying to use the nativescript-platform-css plugin, which creates classes phone and tablet classes on the Page element and then supply different CSS along the lines of:
.phone :host .photo {
width:300;
}
.tablet :host .photo {
height:600;
}
The trouble is that it works fine in some cases but in other cases don’t (at least not in angular). For example, in modals it doesn’t work really and also I found other cases that are problematic.
I could of course apply the CSS programatically going by the nsPlatform.deviceType global variable that the plugin creates, but that seems not so 'clean' and will require quite some code on every component that I would prefer to avoid.
The multiple screen section in the docs mention that it doesn't work for Angular and Webpack builds (although AFAIK the project is moving to webpack by default now).
Thanks for any contributing thought!
Related
We write css when we use styled components, and I dont understand the benefit of using it why we just dont use the css we write as a classname for the components. In styled components we have wrappers of the components and when we use plain css we have class names. what is the advantage of wrapping components with styled components
The reason styled components is pushed in React web development is to encapsulate styles to only those components. There is no risk of bleeding css into other components. Rather than learn a new css organisation structure new developers can onboard more quickly.
That being said, it is restrictive, slower to develop with, and adds some page weight by applying same styles you could have shared.
I have found the fastest way to work is create static html webpages with pure css, and organise it in a way you are going to import it into your framework. Then you can have boilerplate html designs that can be tested independently of the compiler, which is so much faster to test in Internet Explorer, Firefox, chrome, mobile devices and all the varying screen sizes.
If you want to use styled components, you can either use this npm plugin to convert your static css into variables to use with style components -
https://www.npmjs.com/package/#inspiraller/create-css-vars
or just don't. Nextjs does not support css imports unless its global, so webpack compiling option is a more universal solution.
Main benefits of styled-components are listed in the Motivations page on their website.
styled-components is the result of wondering how we could enhance CSS for styling React component systems. By focusing on a single use case we managed to optimize the experience for developers as well as the output for end users.
Apart from the improved experience for developers, styled-components provides:
Automatic critical CSS: styled-components keeps track of which components are rendered on a page and injects their styles and nothing else, fully automatically. Combined with code splitting, this means your users load the least amount of code necessary.
No class name bugs: styled-components generates unique class names for your styles. You never have to worry about duplication, overlap or misspellings.
Easier deletion of CSS: it can be hard to know whether a class name is used somewhere in your codebase. styled-components makes it obvious, as every bit of styling is tied to a specific component. If the component is unused (which tooling can detect) and gets deleted, all its styles get deleted with it.
Simple dynamic styling: adapting the styling of a component based on its props or a global theme is simple and intuitive without having to manually manage dozens of classes.
Painless maintenance: you never have to hunt across different files to find the styling affecting your component, so maintenance is a piece of cake no matter how big your codebase is.
Automatic vendor prefixing: write your CSS to the current standard and let styled-components handle the rest.
With styled components it's possible to "enhance" CSS classes with JavaScript code because are written in JS.
const Input = styled.input`
color: ${props => props.hasError ? 'red' : 'black'};
`;
Opposed to writing 2 separate CSS classes and control which to show with JS.
.text {
color: black;
}
.text--danger {
color: red;
}
<input className={`text ${hasError ? 'text--danger' : ''}`} />
On the long run it can produce more maintainable code, but it's a matter of personal opinion if it's better to use it or not.
With styled components you can add logic programming
I use some CSS media queries on my Ektron site. They function correctly on the iPhone, but when I try simulating smaller screens on my production site, the breakpoints don't kick in.
Here's the strange part (to me, at least). When I view the site on my development server, the breakpoints work like a champ. The big difference is that on my dev server I've disabled CSS aggregation and minification. So it would appear that something about the css.register method in the framework API is (partially) breaking my responsive CSS. As I said, it seems to work correctly on mobile devices, but I would really like to know why it's not working on the desktop.
I've seen posts referring to minification routines used by certain platforms which break media queries (for example, they remove the word "and"). But that doesn't appear to be happening.
Has anyone else experienced this?
Here's a CSS snippet:
#media only screen and (min-width:320px) and (max-width:767px) {
/* phones, handhelds smaller than iPad */
#subnavbg {
visibility:hidden;
}
.login-left
{
border: none;
width: 100%;
}
.login-right
{
width:100%
}
}
CSS aggregation combines multiple CSS files together. If there is a syntax error in one file, it can affect all the other files that are aggregated with it. Browsers can ignore some syntax errors like a missing close } at the end of a file. However when that file is combined with other files it becomes a problem.
Try opening each css file in Visual Studio and check for errors.
I am just getting started with less. In an attempt to mmake less ugly Bootstrap's multitude of classes on tags, I have attempted to write some simple wrappers in less.
The entireity of my code is below.
// Import boostrap.
#import "./less/bootstrap.less";
// General classes for content.
focus {
.span12;
}
content {
.span8;
}
side {
.span4;
}
The purpose of this less file is to provide nice looking wrappers that do a single thing, such as Bootstrap's .span12 class. I will, in time, extend this to buttons of sorts.
Either way, I am running into a problem when compiling the less file using lessc style.less.
The error it gives is:
NameError: .span12 is undefined in /srv/http/www/style.less on line 6, column 5:
5 focus {
6 .span12;
7 }
I have found some documentation with the .makeColumn(i) class but the problem with that is Bootstrap already has perfectly good media queries and I wanted to avoid writing my own.
Is there anyway to wrap the classes that already have the media queries or do I need to just suck it up and write my own for my wrappers?
You are going to run into a few major problems in this approach.
First, there are issues in that Bootstrap is dynamically generating the .spanX series of classes, so they are not immediately accessible as mixins, as I note in this answer.
Second, some of Bootstrap's span code is not set by the .spanX series, but is done through an attribute selector of [class*="span"] (see, as of this writing, line 602 of the mixins.less file; they are also extensively used in the responsive files for the #media rules). This selector code would not be picked up by a .span12 inclusion of code, and if you are not putting .span12 in your code, then your code will not have those properties applied. So you need to work around that.
There may be other issues not immediately obvious, but the point is, if you want to use Bootstrap for grid purposes (especially responsive), it is probably best to use it as it is designed. If you do not, then it is best to go and copy the Bootstrap code and modify it as you desire to make your own reduced grid code (if your intent is to use less overall classes in your html).
Am gonna try a template which needs to support all devices most of them recommended me to grid framework because using media query by self may cause time but using framework makes fast.Now the thing is i don't about grid and my task is to finish it with foundation framework.! and which is the best way
*)writing media query by own (or)
*)using framework like foundation
and tell me the way and how to use it thanks a lot in advance..!
There are two opposite ways to accomplish your task.
Using a non-semantic CSS grid framework
There are a number of CSS grid frameworks. The most popular of them probably are:
Twitter Bootstrap;
Zurb Foundation;
Blueprint.
The advantage of using any of those is that you can prototype your grid very quickly by applying the non-semantic classes to your HTML elements. They also contain a lot of handy decorative styles.
But this approach is considered faulty by many CSS developers. There are a number of problems:
By using non-semantic classes you mix structure and presentation, which is fine to make the job done quickly but unacceptable for a serious project.
You force your users to download a huge CSS library while you barely use 10% of it on your website (i have to admit that Foundation allows to import different portions of its CSS library separately, and there exits pure grid frameworks like 960gs that don't contain decoration styles at all).
You are limited with the sizes and breakpoints provided by the grid system. There's no elegant way to override them. Most of grid systems provide only two responsive styles: small and large, while you may want more (e. g. phone portrait, phone landscape, tablet portrait, tablet landscape, laptop, desktop).
Using the power of SASS and Compass
SASS turns CSS into kinda programming language. You can use variables, functions, methods, you can include libraries of code and execute them with your parameters. The possibilities are almost endlest. You write your styles in SASS and then complile them into vanilla CSS accepted by all browsers.
Compass is a bunch of things under one name:
a handy tool to compile SASS efficiently;
a huge library of handy SASS styles for all occasions;
an ecosystem of extensions that you can install and use in your projects effortlessly.
There exist a number of SASS grid frameworks. They allow you to span your elements semantically. Instead of adding classess to HTML, e. g.:
<aside id="sidebar-left" class="grid-2-of-6 grid-4-of-12">
...you apply CSS to existing selectors, e. g.:
#sidebar-left { #include float-span(2); }
Another advantage is that you're not limited with the defaults. You can alter the number of columns, their width, the breakpoints. You can even have different grids for different portions of the web page! And the most tasty feature is that you can have different number of columns for different screen widths (instead of just making your columns ridiculously narrow).
In my opinion, the best SASS grid system out there is Singularity responsive grid framework. It is extremely powerful and flexible and at the same time it's very smooth and simple to use (once you study it).
For responsive media queries you can use Breakpoint or it's jet-propelled sidekick Breakpoint Slicer. Building a responsive grid with Singularity and Breakpoint Slicer is a pleasure.
SASS and Compass provide other fantastic advantages. For example, you can structure your code very efficiently. It's not a proper place do describe all the ways with which SASS and Compass make your life better. I'll just say that CSS compared to SASS is like a copybook and abacus compared to a spreadsheet processor. I suggest that you google for SASS to learn more.
The downsides of the SASS approach are:
You'll have to study it. It takes time.
You'll have to keep your styles in SASS. If you want to edit your CSS, you'll have to edit SASS and recompile. That's not much of a hassle and there are ways to automate this or even integrate into the deployment process, but it takes time and effort to adopt them.
Your teammates are obliged to use SASS too because any changes in CSS are overwritten during each compilation.
Once you start using SASS, you'll never want to code vanilla CSS anymore. That's not a true disadvantage actually. But you should be aware that your life as a frontend developer will never be the same!
After working on several large web applications, and seeing gigantic style sheets with no clear structure, I'd really love to know if people have found ways to keep their css clean for large and complicated web apps.
How do you move from a legacy, mess of css to cleaned up, nicely cascading, DRY stylesheets?
The app I'm currently working on has 12000 lines of css. It's grown to this size organically as early on there were no standards or review of the css, the only rule was to make the app match the design. Some of the problems we constantly have:
Conflicting styles: one developer adds a .header { font-weight: bold;} but .header was already used in other modules and shouldn't be bold in those.
Cascading problems: Foo widget has a .header but it also contains a list of Bar widgets with .header classes.
If we define .foo .header { ... } and .bar .header { ... } anything not explicitly overwritten in foo will show up in bar.
If we define .foo > .header and .bar > .header but later need to modify foo to wrap header in a div, our styles break.
Inheritance problems, we constantly redefine widget fonts to 11px/normal because some top container uses a 12px / 18 px line height.
Fighting against widget libraries, using libraries such as dojo/dijit or jquery ui that add tons of styles to be functional means that our code is littered with places where we have to override the library styles to get things looking just right. There are ~2000 lines of css just for tweaking the builtin dijit styles
We're at a point where we're thinking of implementing the following rules:
Namespace all new widget classes - if you have a widget foo all sub-classnames will be .foo_ so we get: .foo, .foo_header, .foo_content, .foo_footer. This makes our css essentially FLAT, but we see no other way to organize our code going forward without running into the legacy styles or the cascading problems I mentioned above.
Police generic styles - have a small handful of generic classes that are only to be applied in very specific situations. e.g. .editable - apply to portions of a sentence that should invoke an editor - should only contain text nodes.
Leverage css compiler mixins To avoid repeatedly defining the same styles in different widgets, define and use mixins. Although we worry the mixins will get out of control too.
How else can we move from css mess that constantly introduces regressions to something maintainable going forward.
We're using a style guide in the form of a simple HTML page with examples of every CSS rule in the stylesheet. It's very easy to tell if you add a new, incompatible rule since the examples are aligned on top of eachother.
An example I like: http://getbootstrap.com/components/ (added 2015)
The other pro you get from this method is reusability: you know what you got and you know that you want the style guide to be as small as possible - therefore: reuse.
When you make changes to styles already in use: check the style guide. If it doesn't change it's probably good (you might need to browse around a bit if you've just changed something including box model-issues, or width, height, padding, margin in general).
How do you move from a legacy, mess of
css to cleaned up, nicely cascading,
DRY stylesheets?
Use the style guide as a unit test. Once you got the essential parts in it: reduce, refactor and combine (you most probably will find some collissions between .campaign_1 span and your regular rules, inheritance can be your friend).
Conflicting styles: one developer adds
a .header { font-weight: bold;} but
.header was already used in other
modules and shouldn't be bold in
those.
In reply to Adriano Varoli Piazza's comment and the quote above: I don't recall this as a problem fully belonging to the CSS but more to the HTML markup. No matter what you do, it will be some heavy lifting. Decide which rule you'd want to keep and take actions towards cleaning out the lesser-used-ones; for example: via inheritance: #news a .header { ... } or renaming the HTML-class a .stand_out_header { ... }.
About the following idea
Namespace all new widget classes - if
you have a widget foo all
sub-classnames will be .foo_ so we
get: .foo, .foo_header, .foo_content,
.foo_footer. This makes our css
essentially FLAT, but we see no other
way to organize our code going forward
without running into the legacy styles
or the cascading problems I mentioned
above.
Use a containing element instead, which will be much more easy to maintain:
<div id="widget_email">
<h2>One type of h2</h2>
</div>
<div id="widget_twitter">
<h2>Another h2</h2>
</div>
I find that the method for "namespacing" and limiting conflict in CSS is separate into different includes what you want to apply, so each page calls only what it needs. Conflicting rules can then be made more specific simply by defining them in a more particular include:
general css for all pages
css for pages in section A
css for pages in section B
So if you find a .header modification you added in the general css works in A but doesn't in B, you simply move it to the lower CSS file.
Yes, this implies more files to load. There are ways around it with server-side languages, like reading all files with php and sending only one block of content.