I started learning less css. Is there any possibility to import different less files
based on view port meta tag. I want to write my own less files for different resolutions.
I also want to know "How does the viewport meta tag works? "
I want to know from the meta tag
how the device width is set to "width" property of the meta tag and the corresponding media
query getting executed.
AFAIK you can't do this with viewport metatag. You can use media queries for this: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries
When compiling Less client site (see: http://lesscss.org/#usage) you could do for example this:
<html>
<head>
<link rel="stylesheet" media="(max-width: 767px)" href="green.less" />
<link rel="stylesheet" media="(min-width: 768px)" href="red.less" />
<script src="less.js" type="text/javascript"></script>
</head>
<body>
<p>color this text</p>
</body>
</html>
with:
green.less: p{color:green;} and
red.less: p{color:red;} and
Also read http://andydavies.me/blog/2012/12/29/think-twice-before-using-matchmedia-to-conditionally-load-stylesheets/
In most cases you don't use client side compiling for production. Even preprocessors should be used only during the development process. In the production environment the real resulting CSS code should be used. When install LESS on the server, via npm, a compiler for server side compiling will be installed too.
Instead of using media queries to load different resources you could use them inside your less files. For the example above your less code should look like:
p{color:green;}
#media(min-width: 768px)
{
p{color:red;}
}
By adding media queries to <link> element it won't prevent the browser from downloading that css file.
The css file with the media query will be downloaded but it might not be a critical resource and it might not render blocking.
Finally, note that "render blocking" only refers to whether the browser has to hold the initial rendering of the page on that resource. In either case, the browser still downloads the CSS asset, albeit with a lower priority for non-blocking resources.
More details https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css
Related
I include 2 stylesheets in a page, one is the version for mobile that is alwys required. on larger screens i would like to load desktop.css in addition. So I link the desktop style so:
<link href="/css/desktop.css" rel="stylesheet" media="all and (min-width: 780px)" />
I thought that the browser would be clever enough to download desktop.css only on large screens. It loads it always however.
Is it possible to prevent the browser from downloading when the media query is not met?
No it is not possible. For media queries the resource is still downloaded (though often at lower priority) but not applied.
This has always been the case even with media=print for example. The exact reasons aren’t clear to me, but there was a brief discussion in this issue, suggesting it broke too many sites - sites presumably that checked the media queries in the CSSOM for even when they didn’t match. That issue clarifies that link rel=“preload” does honour the media query in terms of downloads but there is less risk of breakage there (preload is just an optimisation hint).
The fact that non-matching media queries are downloaded (but not render blocking) actually forms the basis of a bit of a hack to load CSS async with the following code:
<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">
As I have enabled the HTTP2 protocol of IIS, but the requests of the main javascript files were still queueing. According to the explanation of queueing by Chrome, I really don't know what cause this.
You can check at here: https://app.youjustgo.com/zh/
Queueing:
HTTP/2 means that more assets can be downloaded at once - not that they will be.
Browsers have various heuristics as to what to download and when.
For example, if an image is needed by a CSS file, then that image cannot be requested until the CSS file is downloaded and processed for example (ignoring preload). So in this case the CSS and the image will not download in parallel despite HTTP/2 allowing this.
Another issues is that <script> tags can change the content of the page, so unless it is explicitly marked as async (or defer) it is "render blocking". This means any JavaScript further down the page will not be run until the <script> tag is run. Now a browser could scan ahead and download the future scripts and just not run them until it needs to, if it wants, with the slight risk that it's a wasted download if the scripts subsequently are not actually needed. That's up to the browser and maybe Chrome decides it's not worth while to do this.
Looking at your specific site, your home page looks to be made up of basically only script tags. You could investigate the use of async or defer to allow more downloads to happen in parallel, but if you want the real performance improvement, you probably should go back to the basics of coding HTML, with CSS, and then enhancing it with JavaScript, rather than coding it all with JavaScript.
I'm also not sure of what the point of your preloading of your CSS is?
<link rel='preload' href='https://api.tiles.mapbox.com/mapbox-gl-js/v0.37.0/mapbox-gl.css' as="style" onload="this.onload=null;this.rel='stylesheet'" />
<link rel='preload' href='https://api.mapbox.com/mapbox-gl-js/plugins/mapbox-gl-directions/v3.0.2/mapbox-gl-directions.css' as="style" onload="this.onload=null;this.rel='stylesheet'" />
<link rel="preload" href="https://npmcdn.com/angular2-toaster#2.0.0/toaster.css" as="style" onload="this.onload=null;this.rel='stylesheet'" />
<link rel="preload" href="//cdn.jsdelivr.net/jquery.slick/1.6.0/slick.css" as="style" onload="this.onload=null;this.rel='stylesheet'"/>
<link rel="preload" href="//cdn.jsdelivr.net/jquery.slick/1.6.0/slick-theme.css" as="style" onload="this.onload=null;this.rel='stylesheet'"/>
Preload is intended for assets that are not immediately apparent to the browser (like the image example above) to allow it to start downloading earlier. Here you are using it to preload CSS. The only advantage is it will not be render blocking and then you use the onload function to display it. However CSS normally is render blocking for a reason - otherwise your content looks unstyled. And because it is preloaded it's requested as high priority (which the CSS would have been requested as anyway), so not sure what advantage this is giving you to be honest. Very confused...
I try to speed up initial loading by eliminating unnecessary downloading.
I split styles in to portrait and landscape css.
And want to load only one style based on media queries.
But is seems they are loading together.
<body>
<link rel="stylesheet" type="text/css" href="style-p.css" media="(orientation: portrait)" />
<link rel="stylesheet" type="text/css" href="style-l.css" media="(orientation: landscape)" />
</body>
The purpose of media attribute in a <link> tag is to decide when the resource applies, not if it loads. It always loads.
So, simply put, what you seem to want is not possible without JavaScript. There is nothing in the current CSS Editor's Draft to indicate it should or will ever be possible using clean HTML + CSS.
If you think about it, this makes a lot of sense. All it takes to flip your device from landscape to portrait is a pet on the back by an enthusiastic colleague. And it would be impossible to provide a decent user experience if you had to wait for a resource to load before the layout change was applied.
The closest the spec gets to the subject is in:
User agents must re-evaluate media queries in response to changes in the user environment that they’re aware of, for example if the device is tiled from landscape to portrait orientation, and change the behavior of any constructs dependent on those media queries accordingly.
But there's an important note on this: most modern browsers made the following (smart) choice: they load <link> resources with media attributes evaluating to false as non-blocking to reduce the time needed to initially render the page to the user.
One of the first articles to go viral on the subject was written by Keith Clark. You might also find Taylor Hunt's follow up interesting.
If you are still interested in loading stylesheets based on #media query conditions, you will need to load them using JavaScript. For performant detection of #media queries in JavaScript, I recommend enquire.js.
As of the moment, browsers still don't have the ability to dynamically load resources in <link> based on its media attribute.
See this article for a more in-depth discussion and implementation of this feature.
Option 1: Keep it as-is
If you're app isn't that big and the styles don't take up much bandwidth, it'd be best to keep them both intact. The cache is your friend. The initial load may be slow, but subsequent requests on the resources will be proxied through the cache.
Option 2: Load the styles with JavaScript
If your styles take about 500KB each, you're probably better off loading them asynchronously with JavaScript.
This will add much more complexity to your application (not to mention if you're using complex build tools like grunt, gulp, or webpack), but it can make initial load faster (or at least, seem faster).
If you want to pursue this path, you can simply include a small script at the bottom of your <body> that checks the user's environment, loads the appropriate css file, inject the contents into a style tag, and append that style tag to the document <head>.
Other notes
Personally, I think separating styles into landscape styles and portrait styles isn't the best way to organize your styles. A better code-separation technique might be to have different styles for different pages of your app, and have only the specific styles load based on the active page. (But it still depends if your layout relies heavily on the portait/landscape media query).
It goes without saying, but these all depend on the environment you're working with and the available server-side solutions you may have access to. It even depends as to how much effort you're willing to give just to reduce your initial load times by 10ms.
I'd say your best bet right now is to merge both files into a single one (so resources loaded pre-HTTP/2 loads faster) and keep it on all your pages. After the first load, it gets cached and that resource will load (almost) instantly. If you absolutely hate white screens, add a fun animated preloaded at the start of your app to entertain your users while they wait for your styles to load on the first render.
something like this could work
<link rel="stylesheet" media="screen and (min-device-width: 800px)" href="800.css" />
<link rel='stylesheet' media='screen and (min-width: 701px) and (max-width: 900px)' href='css/medium.css' />
try using this solution:
https://stackoverflow.com/a/8101452/1964336
https://stackoverflow.com/a/19675410/1964336
https://css-tricks.com/resolution-specific-stylesheets/
more explanation:
CSS syntax: link: https://www.w3.org/TR/css3-mediaqueries/
<link rel="stylesheet" media="mediatype and|not|only (media feature)" href="mystylesheet.css">
media type could be print, screen, all etc.
In media attribute, Use screen and (orientation: portrait) Instead of (orientation: ********)
<link rel="stylesheet" type="text/css" href="style-p.css" media="screen and (orientation: portrait)" />
<link rel="stylesheet" type="text/css" href="style-l.css" media="screen and (orientation: landscape)" />
I am working on my second foray into designing a responsive website for my business. I am wondering about best way to organize my css file with browser rendering performance in mind.
There will be only one css file, with all media query included (have three breaks: full size, tablet vertical, phone). Currently all my media queries come at the end of the file (easier to find what I am fine tuning at the moment). I had pondered creating a full css for each break, then calling them individually based on media queries, but was recently reading that tests have shown that browsers still download all the different css files but then only use the appropriate one, which just means more downloading without any benefit.
Once everything is ready would it be better to move the various M-Q's to sit right after their "default" css counterpart (ie the vertical tablet body font size, right after the "default" body font size). Or does the browser read through the entirety of the CSS file before starting to render the page.
Putting the M-Q's as snippets scattered around the css file, makes for a bigger initial css file download due to the replicated #media code for each snippet. But if it causes the browser to render quicker ....
The aspect that got me wondering was base font size, as I will be modifying it slightly for tablets vs phones vs desktop to accommodate the viewing distances. And since all font sizes, padding and margins are based on rem units, changing the base size effects a lot of items.
So from a purely performance point of view (download and browser rendering) is one method preferable over the other(s)?
additional details ...
I guess perhaps what I should be asking, how does a browser use the css file. Does it read through the entire css file and then start to render? Or does it start rendering with the first line of css and then the next line and the next line?
Well, i am not sure, for not having tested this exaustively, but, per example w3.org site is using the 'load by media query' technique.
<link rel="stylesheet" href="/2008/site/css/minimum" type="text/css"
media="handheld, all" />
<style type="text/css"
media="print, screen and (min-width: 481px)">
/*<![CDATA[*/
#import url("/2008/site/css/advanced");
/*]]>*/
</style>
<link href="/2008/site/css/minimum" rel="stylesheet" type="text/css"
media="handheld, only screen and (max-device-width: 480px)" />
<meta name="viewport" content="width=device-width" />
<link rel="stylesheet" href="/2008/site/css/print" type="text/css"
media="print" />
in order to make the browser load assets by media types.
This way, not all has to be loaded at first. Take example with the media="print". The printing style sheet is not loaded except for printing.
In your question you are mentionning 1 single .css file, so, maybe you are stucked, but if you can split your file in 3 different files, the example would help. The counter part is that if you use 'sizing' queries, the browser might have to download the next css file if the user minimize or reduce the viewport.
Also, if your design is NOT to change much, or if the resulting file is quite small, yes, 1 single .css file will be better than different files scoped by media-queries (for maintenance and caching).
Hope this helps
I am working on a project for school and wanted to use the less library. I tried something like
<link rel="stylesheet/less" type="text/css" href="style.less">
but this didn't work, I got the error
XMLHttpRequest cannot load file:/// [..] /style.less. Cross origin requests are only supported for HTTP.
Meaning I basically need to run a server for this implementation. However, since this is supposed to be a stand-alone project for a non-technical class, running a server is out of the question. So, my question is:
How do I use less at document level, the same way one would write the css equivalent
<style>div{color:#F00}</style>?
Searching the google for "document level less" returned no related results.
You can't use LESS at document level. Less is a pre compiler for CSS, so you should use the end product in your site (css). You don't need a webserver to show html + css local in a webbrowser. You can compile your LESS to CSS client side (by including less.js) or server side, the source code bundles a compiler.
Also read: Is there a way to bypass Javascript / jQuery's same origin policy for local access?
for example the file like below works also when i load it from my local files in a webbrowser:
<html>
<head>
<link rel="stylesheet" media="(max-width: 767px)" href="green.less" />
<link rel="stylesheet" media="(min-width: 768px)" href="red.less" />
<script type="text/javascript">less = { env: 'development' };</script>
<script src="less.js" type="text/javascript"></script>
</head>
<body>
<p>color this text</p>
</body>
</html>
update
When you are sure javascript works and less.js loads and you don't see your styles still, their probably will be an error or typo in your LESS files. If there is an error, your LESS file won't compile, so their will be any CSS and you won't see any styling.
By default less.js don't show errors in the browser. Add <script type="text/javascript">less = { env: 'development' };</script> to your source to allow LESS errors shown in your browser (from: https://stackoverflow.com/a/11289000/1596547).
Example: