I ran into a problem at working with Shopware today. I want to restrict the usage of certain CSS files (mobile css and desktop css).
Problem is: both files are being used and it seems to not letting me restrict the files to the viewports. What did I do wrong?
Would be great if you could help me out here, since Ive just started in LESS templating. Cheers!
{extends file='parent:frontend/index/header.tpl'}
#phoneLandscapeViewportWidth: 30em;
#tabletViewportWidth: 48em;
#tabletLandscapeViewportWidth: 64em;
#desktopViewportWidth: 78.75em;
when (#media screen and (min-width: #tabletLandscapeViewportWidth)=true) {
{block name="frontend_index_header_css_screen" append}
<link type="text/css" media="screen, projection" rel="stylesheet" href="{link file='frontend/_public/src/css/custom.css'}" />
{/block}
}
#media screen and (max-width: #tabletLandscapeViewportWidth) {
{block name="frontend_index_header_css_screen" append}
<link type="text/css" media="screen, projection" rel="stylesheet" href="{link file='frontend/_public/src/css/mobile.css'}" />
{/block}
}
First of all: As the comments already state out, you're mixing up different languages.
By now - from your example - you're dealing with three things, that cannot be combined in that way as you try it:
LESS: This is a preprocessor language that - at least in a Shopware 5 context is meant to be compiled and generates your CSS
files (there is a way of including LESS files directly, but this is not recommended for production, so I'd leave this part out).
CSS: Your stylesheets that are rendered. If you statically include them into your template (I mean if you're not using Javascript to dynamically change your DOM) you WILL have to decide whether you use one or another CSS-File before you render the DOM.
This brings us to the next CSS related-topic:
Media Queries: The concept of media queries is not meant to dynamically change the DOM (i.e. clearing out one CSS-Stylesheet and bringing in another).
Imagine the following case: You sit at your Desktop-PC and slowly drag the window of your browser smaller and smaller until your viewport-width is smaller than 64em (#tabletLandscapeViewportWidth). What is the media-query supposed to do? Request the server to load another resource?
Remember: Media Queries are CSS and CSS is all about style of your Website. In a normal case it is served once when the page loads and the rest of the magic happens in your client. There is no further communication with the server (and this is what you'd try to do, i guess).
Smarty (.tpl): The third part you mix up here is the .tpl files, and these come from the Smarty-Template-Engine. So we have to be clear here: Smarty renders your template. This happens server-side before the page is delivered to the requesting client.
That means you can decide to load one or the other css at this point (but not by media-queries, I'll come back to that later) but once the page is delivered to the client, Smarty's work is over and it will do nothing without another server-request (i.e. by an AJAX-call).
I must confess that I am not absolutely understanding what exactly you want to achieve. If you only some CSS definitions to a certian viewport width, you don't need to go into the template at all.
Let's assume you only want your styles that are in the custom.css apply when the viewport is larger than #tabletViewportWidth and everything below should serve mobile.css.
Since you can nest media-queries in CSS3 it shouldn't be a problem to wrap the whole less file into a media-query like that:
#media screen and (min-width: #tabletLandscapeViewportWidth) {
// all your custom.css content
}
#media screen and (max-width: #tabletLandscapeViewportWidth) {
// all your mobile.css content
}
But please keep in mind that this excludes all other media-types, so you maybe should go with #media all.
If you really want to change the stylesheets dynamically you should go with a library like Modernizr and make an AJAX-Request that dynamically changes the stylesheet, but imho this is kind of an ugly solution that only makes (no real, but with a bit of fantasy a little bit) sense if no stylesheet is loaded (or a base-stylesheet with styles, that both .css-files share) and the call is made to request a smaller CSS-File.
But if the production-css-file is minified this shouldn't be worth the effort.
As you can see, in the offered solution we are not even touching a smarty-tpl-file. But i want to mention a little thing if you work with smarty:
You're extending a file here, therefore every junk of code needs to be inside of the {block}-tags you're extending. Smarty doesn't know where to put the code otherwise and will throw an error (even though, as explained LESS-Code won't work anyways here ;) ).
regards
We are trying to use an #media print.css style sheet to enable a web page to print a set of Avery labels (6 up on a sheet - 4" x 3"). Generally a print media style sheet seemed like a perfect solution to having a page that looks like a list on screen, but when you print the list you get imprinting for Avery badges!
The challenge is in the details though. In addition to the fact that each browser seems to have unique interpretations of print styling and some of the rules just don't work. I've seen and studied most of the basic info readily available on using the print.css. It's fairly easy to override font colors with black and set details to print or not but what this assignment needs is precise element placement and styling within the #page details.
The site already features Bootstrap and other linked .css pages though I've unlinked them to test the pages and am trying to isolate out anything that could also be interfering with print styling.
It appears that float isn't working in IE. Our list page content to print lays out in floated divs in Chrome but font styling and other divs aren't rendering as intended. Firefox isn't displaying any of the required print content but indicating page numbering appears to agree with Chrome that there are 56 pages of labels, (sorry if you can't see them?) My hope is that this document can serve as a repository for the tips tricks and limitations of media #print.
I'm experiencing the same problem. I need to print onto specific Avery labels at exact dimensions and although I can get it to work with Chrome (despite it ignoring some Print CSS styles) - it doesn't work in Firefox. Safari seems to be in it's own world also.
I think the only way I'm going to solve this is to generate PDF's that the user has to download and print (or print the PDF's from their browser).
Sucks, but haven't found any solutions for a "CSS Print Browser Reset".
I'm rewriting a web app that allowed users to submit snippets of html via a WYSIWYG editor. The web app was designed from the ground up to be IE-only and quirksmode-only. As a result the html submitted by users was designed with this in mind.
One data item, for example, includes the following html:
<span style="font-size:small">Element name here</span>
Which incorrectly renders as font-size:medium in quirksmode (the way the user designed it), but renders properly as font-size:small in all other browsers including IE in standards mode.
I'm forcing IE into standards mode but I still want the app to look the same to existing users, so I'm looking for a way to override the font-size keywords in modern browsers to mean what they do in quirksmode. In other words I want the modern browsers to incorrectly render the text as font-size:medium. I'll contain all current user-submitted html in containers with class "old-user-content" or something similar.
For now I'm willing to resort to severe hackery to get this done. Any advice?
Use a media query to do this:
#media {
.old-user-content { font-size: medium }
}
If I specify a CSS link with an unsupported media type ("bork") it still gets downloaded by every browser I've tried (including both desktop and several mobile browsers).
<link href="bork.css" media="bork" rel="stylesheet" type="text/css" />
And it gets worse...
If the file bork.css #imports an other CSS file (also with an unsupported media type) that second CSS file also gets downloaded.
/* Inside "bork.css" */
#import url("bork2.css") bork, bork;
Why!?
My first assumption was that some browsers might be searching for nested #imports or #media blocks with media types that they supported - and then apply the styling rules contained within those files...
/* Inside "bork2.css" */
#import url("all.css");
#media all {
/* rules */
}
...but as far s I can tell, not a single browser does that. (Fortunately, as that would be a bug.)
So all this downloading seems wholly redundant - unless there's some explanation that I've missed all along.
EDIT: What I'm trying to understand is that motivates browser makers to go:
"Hey! We're trying to make our browser crazy fast! Let's download a bunch of CSS files that we have no intention of applying, and halt the loading of other resources meanwhile!"
I think the answer is this:
Browsers are allowed and encouraged to parse media descriptors - no matter what the descriptor - as a way to make them future friendly
Future versions of HTML may introduce
new values and may allow parameterized
values.
*From: http://www.w3.org/TR/html4/types.html#h-6.13
In this way, media may one day include 3d-glasses or other descriptors, including bork ;-)
EDIT:
The latest CSS3 spec on media queries says this, which supports the above, to a certain degree:
Unknown media
types evaluate to false. Effectively,
they are treated identically to known
media types that do not match the
media type of the device.
*From: http://dev.w3.org/csswg/css3-mediaqueries/#error-handling
So they are treated as known and downloaded to be used, just not at that time/for that device.
Thinking that the real reason that they load all media queries is because many devices CHANGE their responses to these queries after load.
Imaging an iPhone5 that is in portrait on page load (reporting 'width' as 640px, but not 'portrait, unfortunately the iSeries do not support those queries)... you then decide to turn the iPhone sideways, and the browser now activates the pseudo landscape mode (again, triggered from width # 1126 rather than 'landscape').
Most likely, a responsive web design has been designed to feed different stylesheets to a browser displaying at 640 (rather narrow, probably a phone/tablet) than it does to a browser displaying at 1126 (more likely a laptop).
If it hadn't bothered to load the additional media query sheets, then it would suddenly have to stop, shoot an http request out, wait for the sheet to load, and then parse it to display. This could result in a rather ugly delay.
As most browsers follow a pattern of code reuse, and the core chunks of Webkit or Gecko, for example, may not be aware whether they are on a laptop or a tablet (as if those lines aren't beginning to blur anyway), it simply loads each media query regardless of whether or not they choose to display it.
While this saves each browser from looking bad, overall it breaks a good chunk of the utility behind media queries.
A cell phone or a cheap android tablet shouldn't have to download the additional files (especially on limited data plans) that it will simply never need.
At the moment, my designs DO use media queries, but I use them sparingly. Much of the media queryishness on my sites is implemented through javascript loading of required files to eliminate this waste. The remaining queries are used in cases of javascript being shut off, or for sheets that need to be loaded 'just in case' (my 640px layout, for example, is usually always loaded, as most devices might display it in one situation or another).
If anyone out there has a better, cleaner, method of handling this, please let me know.
In the meantime, if you can think of a simply to implement functionality that might circumvent this (maybe android-style manifests built into browsers?), you might want to drop a line to the Mozilla or Chromium teams... seem like they could use a hand on this one.
After thinking about this more, I formed the theory that there might be a general "rule" at work - that any stylesheet, image or script would be downloaded, no questions asked, regardless of the specified mime-type or media attribute.
However, after a quick test, the results are a bit ambigious...
<script src="bork.js" type="bork/bork"></script>
<script src="bork2.js" type="text/bork"></script>
Chrome 12 downloads neither.
IE8 downloads #2.
Firefox 4 downloads both.
Opera 11 downloads both.
Safari 5 Win downlads both.
Still no parsing or running takes place in any of the browsers. A javascript alert(); inside either file does not run. And this is slightly different from the CSS loading case, because there the browsers parse the bork-media CSS code for #include directives and downloads those resources recursively.
The answer may come down to media queries. Consider these for example:
<link rel="stylesheet" media="(min-width: 300px)" href="example1.css" />
<link rel="stylesheet" media="(min-width: 1000px)" href="example2.css" />
If a browser with a window size of 600px is used, the example1.css stylesheet will be applied. If the window is resized to 1200px then the stylesheet example2.css can be immediately applied without waiting for it to download first.
Its worth noting that even though the non-matching media query stylesheet is still downloaded, it does not block rendering while it is downloading (normally all CSS files need to be downloaded before rendering will begin).
Sometimes, it's necessary to consider the prosaic answer. It's possible that all stylesheets are downloaded by browsers simply because the authors of each browser only really consider the case where there is a single (master) stylesheet when optimizing for speed, and the practice of a lot of sites of having a single stylesheet encourages this behavior. If nobody is testing for it, it's almost certainly not a case that's being optimized, as people prefer to work on results that are visible (or at least measurable). Maybe your question will encourage someone to change the testing regime…
Also, I'd venture that the overwhelming majority of sites' stylesheets are static documents, and so capable of being very highly cached (and delivered by CDN too, if the site owners choose to pay).
The only logical reason I can think of is that when you are changing dynamically (javascript) the faulty attribute's value of the <link> element to a recognized one, the file must be available immediately.
In fact in certain cases it could be considered a feature if you wanna load the file but defer its appliance for later.
So if you really do not want to download the CSS file until something happens, the you can try to validate when the page loads if certain conditions are meet and if so, then you can do a "lazy load" and store the commented code (type 8 element, that would be in this case your style tag) inside a newly created style tag child, and that will make the browser to validate the newly created content and will download the CSS file for the style to work.
Any question you may face trying to implement it, do not hesitate in asking some clarification, maybe i can help you with your problem. It works for almost anything (images, js, css, etc..) you do not want to be downloaded or processed until something occurs or some restrictions are meet.
I already tested it and IT WORKS :D, so you can use this code to start, hope it helps
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>TEST CODE</title>
<script type="text/javascript">
function test(){
var elems = document.body.childNodes;
alert(elems);
for (var i = 0, il = elems.length; i < il; i++) {
var el = elems[i];
alert(el.nodeType);
if (el.nodeType == 8) {
var style = document.createElement('style');
style.innerHTML = el.nodeValue;
document.getElementById("css").appendChild(style);
break;
}
}
}
</script >
<style id="css">
</style>
</head>
<body onload="test()">
<!--#import url(red.css) (min-width:400px) and (max-width:599px);-->
</body>
</html>
How do you get cross browser compatibility in Print? any tips for print css file to make print on paper identical from all browser.
Edit
I'm already using Eric meyer CSS but still facing inconsistencies in different browser when we take print from site.
Is there any CSS declarations which we can use always and put at a top in print css , Like other css resets which work good in media=screen?
I'm already using a different css for print (print.css) with media="print"
Would it be better to keep * {posotion:static} , *{float:none} , * {clear:both}
in print css always?
Identical results are impossible. The output depends not only on CSS but also on individual settings for page margins, the printer’s capabilities, available fonts, paper format (A4 vs US Letter) and probably a lot more.
For CSS
Avoid floats and positioning (relative, absolute and fixed). Especially Mozilla (Firefox) can not handle those properties very well.
Use page-break-* but don’t rely on it. Some browsers insert page breaks even in images.
You don’t know the page width and height (could A5). Keep anything as flexible as possible.
For performance, put your print style into the main stylesheet in a #media print {} rule.
Use pt not px for borders and margins. A printer doesn’t know what a pixel is and may come to strange results.
Develop your print layout in Opera, which has the best support for #media print currently, and insert compatibility hacks, when you’re done.
Internet Explorer may crash on print, if you use its reserved IDs.
Never rely on print preview. You get very different results on real printouts. Save the rain forest with a print-to-pdf-driver. :)
In html there use a link with the attribute "media" set to "print".
<LINK rel="stylesheet" type"text/css" href="print.css" media="print">
You can disable all other css and just use your "print" css. set the media first to "screen". Test it just like your testing a normal css in all browsers.
In my experience, what it looks in the screen, will pretty much look when it's printed.
Advice:
1) keep your layout as fluid as possible for it to be flexible to what ever the paper margin it was set to.
2) keep it simple.
3) In IE, backgrounds might be missing. To fix this, go to: Tools>Internet Options>Advanced. on the Settings box, scroll down to Printing and enable "Print background colors and images"