We Keep Coding

Using Enquire for layout as opposed to using CSS for layout

I am aware of the fact that layout and function of a site should be strictly separated. Layout should be done with CSS and functions of the site, like expand mobile menu on click, should be done with JS.
Reference:1. & 2.
What I often see happening for responsive layouts is having column classes for the various media queries, where just the class name is different, however the width values are identical.
This then leads to HTML in the form of
<div class="container small-query-columns-4 medium-query-columns-6 large-query-columns-12><p>Responsive paragraph..</p></div>.
Would it be acceptable to instead of always defining the same width for columns for various media queries to just make a minimal CSS grid, where the column classes widths are defined once and then dynamically pass those per media query with Enquire?
I know this ruins the above given separation from layout (CSS) and function (JS), though it would mean much cleaner HTML, and this per each media query plus much less CSS as well. Enquire also only calls once per media query so the hit on the amount to download would also be much less with a minimal CSS file. Yes, of course, this means the site is JS depended.

That's not bad idea but I think that it is not good idea too. I had thought about something similar few weeks ago. I wanted to make CSS which will be compiled in browser via JS in few loops and then appended to head section. But after deep thinking I decided to not doing that.
I know that you can make fallbacks and some fancy stuff so it works in every browser with or without js, but I have looked at my grid. It takes less than 10KB. It's interesting idea, but it isn't worh so much work as it will take. Keep your HTML organised and you won't run into issue with too many css classes. You have to let someone who use your "framework" do define widths at certain breakpoints. Easiest thing to do is just write a class name.
Consider that when you use for example bootstrap and want to have 12 columns on mobile, you just don't define it and it automatically falls into that width. Many times it just enough to define max 2 breakpoints with css classes.
When I think about enquirejs I think that it can be used for hiding sliders on mobile for example. When you just display: none it still running and changing classes. If you have something similiar what should be removed because mobile is not good environment for running something, you can disable it by using enquire. Another example is mansory grid, which you can start and disable via enquirejs.
Basically you can use it if you have something already js-depended and want to customize it on diffrent screens, or give diffrent behavior, because if you just set something on window load or document load, you have an issue with someone who resizes window. Here you can use it.

Best way to preview a template inside a div (without IFRAME)?

I'm working on a CMS system where the user has the ability to select between a number of different templates for their site. When they select from the list of templates on the left I want the middle of the page to show the preview of the template and the right side to show a property inspector for manipulating things like colors, font sizes, sections, etc. Clicking on an element inside the preview changes what is focused and thus changes the property inspector.
The big challenge is that the templates are designed by 3rd party designers and the CSS is designed with the expectation that there is no other CSS (like the CSS for the CMS). I might force them to restrict everything their design to work on any page and to always have a top level DIV that I can just inject into the page.
I could IFRAME it but that is not ideal because DOM manipulation becomes more complicated.
Ultimately I have full control over the template structure and how they are made but I'd like to keep it as simple as possible for designers.
What's the best way to go about structuring this kind of setup?

Given the requirements of no iframe (which would be the right way), I see 2 solutions:
Put the template in a div with a certain class/id and preprocess the CSS to prefix every selector with that class.
Use the Shadow DOM, but then you would only target Chrome.

Generate html from graphical UI

I am working on a CMS project where users can drag and drop different components(such as button, div, etc) from components menu on canvas area. Once they are happy about their layout then they click on button finish. What I want is when finish button is clicked then in popup they should see html and its appropriate CSS code.
How can I parse through those components and generate html, css and Javascript if necessary?
Are there any solutions available? I could not find any after googling.

maybe this approach is different but.
can you use of svg element? because with svg you can get positions for every element and then use for whatever you want (like get positions for example).
here some useful tutorials:
http://www.tutorialspoint.com/html5/html5_svg.htm
http://www.w3schools.com/html/html5_svg.asp (for some reason some people don't like this site)

Javascript workaround for slow scrolling with smooth scrolling in firefox

I am a developer for a web application. In this application there is a certain scenario where there are multiple position:fixed elements, and canvases and a overflow:scroll element. In this scenario, scrolling is super slow on firefox when smooth scrolling is enabled.
From the user's perspective the solution is simply to disable smooth scrolling. However, as a developer I can't ensure that the user has done this.
Is there anywhere that I can tell firefox to not to use smooth scrolling for my website from javascript (or html)? Or is there any other known workaround for this?

I do understand that your question basically is how to disable smooth scrolling. however I will answer you a little differently to get this working.
Why different?
Even if you can detect smooth scrolling of users, you cannot force the user to disable it. In other words, you are trying to cover the problem instead of solving it. so lets solve it!
Intro: pixels-to-screen pipeline
On each frame the browser does the following steps to render the page on screen.
JavaScript. Typically JavaScript is used to handle work that will result in visual changes, whether it’s jQuery’s animate function, sorting a data set, or adding DOM elements to the page. It doesn’t have to be JavaScript that triggers a visual change, though: CSS Animations, Transitions, and the Web Animations API are also commonly used.
Style calculations. This is the process of figuring out which CSS rules apply to which elements based on matching selectors, e.g. .headline or .nav > .nav__item. From there, once rules are known, they are applied and the final styles for each element are calculated.
Layout. Once the browser knows which rules apply to an element it can begin to calculate how much space it takes up and where it is on screen. The web’s layout model means that one element can affect others, e.g. the width of the element typically affects its children’s widths and so on all the way up and down the tree, so the process can be quite involved for the browser.
Paint. Painting is the process of filling in pixels. It involves drawing out text, colors, images, borders, and shadows, essentially every visual part of the elements. The drawing is typically done onto multiple surfaces, often called layers.
Compositing. Since the parts of the page were drawn into potentially multiple layers they need to be drawn to the screen in the correct order so that the page renders correctly. This is especially important for elements that overlap another, since a mistake could result in one element appearing over the top of another incorrectly.
details and source: https://developers.google.com/web/fundamentals/performance/rendering/?hl=en
Step 1:
First step is to remove render costly css properties. You might not be able to remove alot, however you can replace rgba(255,255,255,1); with #fff which removes the alpha layer.
check this for more details: https://csstriggers.com/
some properties do not need to do a layout or a paint and there are less heavy than others.
Step 2:
Check for forced synchronous layout triggers. These happen when you force the browser to do a layout while its in the javascript step, then return to javascript, instead of walking smoothly along the pipeline on each frame. to do this, avoid getting layout attributes and setting them directly afterwards in a loop for example.
here is a list of what causes sync layout: https://gist.github.com/paulirish/5d52fb081b3570c81e3a
read more: https://developers.google.com/web/tools/chrome-devtools/profile/rendering-tools/forced-synchronous-layouts?hl=en
Step 3:
Move components on the page that need to be repainted regularly into new layers.
The browser needs to repaint every time you scroll or an animation is playing. to avoid a full page repaint and only repaint the part that is changing, move that part (ex parallax, navigation, animation) to a new layer on the browser (think about it like photoshop layers)
to do so use the will-change css property to tell the browser to move it to a new layer, and use transform: translateZ(0); if you want to force the broswer to move it.

Have you tried adding
backface-visibility: hidden;
to you fixed position elements?
I would rather fix the source of the problem. Often there is one small detail that creates a giant bottleneck and that is easy to fix with the change of one line of code or something. Note that you most probably won't need to reduce the "good looks" of the app at all; it's just a matter of avoiding the small but devastating-for-performance details of the browser's layout engine.
I'll make a guess and say that something on you web app is causing very large repaints and/or frequent reflows. Check for things like usage of offsetTop and position: fixed. Also using requestAnimationFrame instead of updating for every scroll event is something worth looking at. Here's a good guide on both finding and fixing scrolling performance problems.

Use inspect element to try and get a handle on the specific cause.
Also, if you've not installed FireBug, install it and use it instead of the default inspect element. This will give you more code details and allow you to step through the script to find the problem.
There also plugins for FireBug for various frameworks, which can aid the diagnostics if your using one of those frameworks.
We can make assumptions about the cause or come up with shotgun solutions; but, only you can diagnose your code to find the specifics.

How to make responsive web page render faster?

Right now, every time I try to render a page, I will calculate the $(window).width() first and then add a corresponding class for the root html element, which will final determine the block width of some main responsive elements in the page. But this approach goes with a problem. It will first render the page with a initial default width, and then after the class is added, it will adjust the element width, which will create a non-smooth visual effect.
To overcome this, I then make all the responsive elements display: none in the first place and make them visible after the width calculation is done. But for a user, it takes more time to see the page in this way.
So I was wondering if there is a way to achieve this responsive page in a more efficient and faster way?

If you are using javascript to create a responsive site, there are much easier ways.
For example, there are TONS of free CSS based frameworks you can utilize to make responsive pages that the CSS controls, which doesn't eat up nearly as many resources as a javascript solution. Lots of DOM manipulation with javascript can get pretty hairy pretty quickly.
My suggestion would be to look into some of the following:
Foundation: http://foundation.zurb.com/index.html
Skeleton: http://www.getskeleton.com/
I personally use foundation for my development, as its easy to read/understand and it produces rapid development.
Example: http://www.sinsysonline.com/secondhomehostel
If you are ABSOLUTELY dead set on having Javascript handle your DOM rendering, it's going to be much slower than a CSS responsive site.
If so, try out:
Response JS: http://responsejs.com/
If you would like further clarification for a specific problem, could you please provide your code and I'm more than happy to provide some feedback on that.

CSS media queries allow you to apply CSS based on screen size. The advantages of this over your approach are:
1) The CSS will read the window size immediately
2) The page will automatically adjust if the user resizes the window (or rotates their tablet)
https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries

You need to use css3 media queries which is very useful to create responsive website. You need to write css according to viewport width. Please refer the link from which you will get all the idea about responsive website.
I hope this will help yo to work on the responsive websites.