The documentation for the Foundation for Apps (and Angular Base Apps, which is the now-maintained fork of F4A) Interchange gives this example as a way to load only the small size of an image on mobile devices in order to save bandwidth:
<ba-interchange>
<img media="small" src="assets/img/small.jpg">
<img media="medium" src="assets/img/medium.jpg">
<img media="large" src="assets/img/large.jpg">
</ba-interchange>
However, while only the small image is displayed, the browser still sees three img tags and requests all three images, before angular is even loaded. This defeats the purpose of using the interchange at all, at least, if your purpose is to save bandwidth.
The Foundation 6 for Sites Interchange avoids this by putting all of the images into a data-interchange attribute string on the element instead. Does F4A have something similar that I'm missing? Or is there something about the above example code that I'm missing?
I would suggest using the ba-if directive provided by Angular Base Apps. This directive internally uses the ng-if directive, causing the img element to not be added to the DOM except when the specified media query is matched.
Your code can be re-written as follows using the ba-if directive:
<img ba-if="small only" src="assets/img/small.jpg">
<img ba-if="medium only" src="assets/img/medium.jpg">
<img ba-if="large only" src="assets/img/large.jpg">
Related
I'm new to clojurescript/reagent and am testing out ideas for a media display app.
At the moment I'm having problems with a few more specific elements of including html5 media components on my page and using their full features.
Example - including #t=10,10 at the end of a video source string(referenced here https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Using_HTML5_audio_and_video) will sometimes work but only take the end range value.
Same video element - using any attributes that aren't true/false will break compilation. e.g :preload auto doesn't work whereas :fullscreen false does.
Is there a clojurescript way to handle these elements or is this more js interop territory?
Since clojurescript will be compiled to JS eventually. Everything JS can do..clojurescript could do it equally well.
your "sometime work" issues are related to the nature of ReactJS ( Reagent is a wrapper of ReactJS ). Generally, you need to obtain the dom node of video tag to use most of the video tag's features.
Related issues
Video displayed in ReactJS component not updating
Example
Source Code Example of how to interact with video tag under ReactJS.
https://github.com/eisneim/react-html5-video/blob/master/src/Video.js
You should provide the minimum case to produce the problem, so others could help you.
Zurb Foundation's data-interchange works beautifully for me. In development.
But then I build and I end up with this sort of html:
<img alt='Why Believe' data-interchange='[/assets/images/logo.svg, (default)], [/assets/images/logo-square.svg, (medium)]'>
<noscript>
<img alt='Why Believe' src='/assets/images/logo-e8f041ee.svg'>
</noscript>
Can you spot the problem?
Middleman's build process smartly fingerprints all of the assets, and links to the fingerprinted ones. No "un-fingerprinted" assets get built. I want all of that.
But the asset paths in the data-interchange attribute get no fingerprints. Therefore they work in development, but not once built and deployed.
How can I make it so the data-interchange asset paths also get the fingerprint? (And if middleman calls the -e8f041ee something other than "fingerprint", please let me know!)
If you are going to use asset hashs then you should consider moving your images used by interchange to a new directory so they aren't automatically hashed. If you are not hosting on a CDN based setup, you should consider turning the cash busting hashes off.
For example I place images in source/blog/featured-images rather than /images/blog/... to avoid them being hashed for a similar reason (because I am defining the name via yml frontmatter.
I have a Qt program that downloads webpages (HTML), parses them and then generates its own HTML which is then displayed with QWebPage. Some times the HTML that I download contains IMG tags, which work fine when the src attribute contains a full URL. However, some times the IMG tag might use a relative path like:
<IMG SRC="images/foo.png" />
Since I know the URL that should be prepended to the SRC my first thought was to just tack it onto my resulting HTML when I'm parsing. However, this is proving more difficult than I anticipated and now I'm wondering if there's a better way.
If there any mechanism/property with QWebPage that I can say "use this URL for relative paths"? Or maybe someone can suggest a better way to accomplish what I want?
Thanks!
In the comments, you mentioned that you're using QWebView::setHtml(). The second, optional parameter of this method sets the URL to use for resolving relative paths. According to the documentation:
External objects such as stylesheets or images referenced in the HTML
document are located relative to baseUrl.
Setting that parameter should be all that's needed here.
I've got a Django project spinning up where it would be great to have the UI in lots of color schemes based on the users' school colors. I have this fantasy of having a base variables.less file along with a bunch of other .less files that compile into style.css.
But once a user sets their school colors it generates a blue.variables.less file (if they've selected the blue preset) or school123.variables.less file (if they got all fancy and used the color picker to make their own color scheme) and then compiles everything to blue.style.css or school123.style.css and then that's the .css file we load when we serve the page.
I can imagine lots of ways for this to fall down. Like how do I reprocess all those files when I push an update to forms.less or layout.less.
Is there a better way to do this? I Googled my fingers raw but haven't found anyone attempting this madness.
There are quite a few ways to accomplish your goal of being able to have user specific color schemes, but they each have their advantages / disadvantages.
I'm assuming you are using some framework like Bootstrap with the files that you name.
Option 1: Inline CSS for color-specific styles (Preferred)
This is my preferred option due to performance and simplicity. You can store each of the customized colors for each user, or even creating a model so you can reuse colors that represent a specific school. It's stored in the database and can scale to an very large number of color schemes without generating a lot of very similar files.
Create a snippet in your template code that has any style that uses the color variable.
base.html
{% include "color-snippet.css" with main-color="{{ user's main color }}" alt-color="{{ user's alt color }}" %}
color-snippet.css (note this file will be in your templates directory as it's being handled by your template engine
<style>
.some-style {
color: {{ main-color }} !important;
}
</style>
So the big downside to this is you'll need to customize Bootstrap beyond the variables.less. You'll need to grep through the less files to find all the classes that would be generated, and copy the style to your snippet in css and not less. It'll take some investment up front and work when you want to upgrade to a newer Bootstrap, but it'll allow you to separate the color part of the styles to be derived dynamically at runtime.
I prefer this approach since you don't have to deal with compilation of less outside your collectstatic step.
Option 2: Client side compilation of LESS
You can have Django serve a file that is dynamically created and returns the variables you want. Then you can have less.js compile it on the client.
This would involve adding to your base template a url path that is handled by Django that isn't part of your static path (e.g. /style/variables), creating a handler in views and then returning text content that would be your less file variables.
Option 3: Server side compilation of LESS
I use Django Pipeline to do my server side compilation of less to css. It takes some setup to get working with your Django application. In development mode, Django Pipeline will compile on every request the associated less files into CSS files. In production mode, it'll point to the appropriate file path to the compiled file. It hooks into collectstatic so your less gets compiled when you collectstatic.
The biggest problem with this approach is that the mapping for your static files (what less + css files compile to css) is defined in your settings file. This requires a server restart when you update this. You could base your own server side less compilation off how Django Pipeline works but have logic for the mapping instead of defining it in something that requires a server restart.
It's a lot of work and the less compilation of Bootstrap is non-trivial to have to do on every request.
If you created your own mapping that doesn't require you to restart your Django server process, you could always just run collectstatic to create the new css files. This would avoid compilation at every request.
While this last approach is closest to what you mentioned, it seems a lot more work and error prone than just separating the color-specific styles and using django templating to customize it.
The last approach as well works well if your number of schemes is rather low since you can just create all the mappings ahead of time and not let people generate their own at runtime. They can suggest them and you can just update them at some regular cadence.
Often, I encounter scenarios where I see it makes sense to use template tags in CSS and JavaScript files, such as the use of {{ STATIC_URL }} in CSS to access image. I understand the only way to achieve this is to have CSS and JavaScript files served by Django. I am interested in this approach. But before I commit, I want to hear you experts' experience on it. What are the pros and cons of this approach? Thx.
Pros:
You can make a lot of per-request decisions about how things look and behave.
You can keep the number of different CSS/JS files to a minimum.
Cons:
Browsers tend to cache CSS and JS aggressively, so you'll need to use some aggressive anti-cache techniques. Of course, this means disabling caching for some/all static files.
Every CSS and JS request will consume another thread of your WSGI server. In a normal request/response cycle, each request generally takes up one thread; you're effectively tripling this, at least, so now your app that could handle 200 simultaneous requests now can only handle 66.
When your site makes it big, a CDN probably can't help you.
Alternatives:
Tweak the CSS via javascript, and set a javascript variable inside your page template to control the tweaks.
Use multiple CSS files and control their inclusion dynamically.
Generate static files as needed, but then cache them to disk and serve them via mod_xsendfile. This only works if you are serving static files from somewhere the django process can write to, such as on the same machine or a network mount.
Personally, I've been sticking with the Django team's advice to make CSS and JavaScript static files, served directly by the server instead of via Django. It hasn't been a problem and has simplified a lot of things. Generally, any time I think I need a dynamioc CSS or JS file, there's a way to refactor so I don't.
For example:
the use of {{ STATIC_URL }} in CSS to access image
I'm not sure how variable your {{ STATIC_URL }} is, but I've found that using the <base> tag in my pages fixes a lot of things. I assume this is for background images? Could you update your question to give an example?
Another thing I've done is, if my JavaScript needs dynamic data, I'll put most of the code in a JavaScript library I serve as a static file and then put the minimum dynamic stuff in a <script> tag at the end of the page. Usually I'll put it all in an object (looking a lot like JSON) and then just pass that object to a function. Come to think of it, you could just take all the dynamic stuff, make a dictionary out of it in your view function, encode it into JSON, and pass it via context. Then your page template just looks something like:
<html><head>
...
<script src="{{ STATIC_URL }}/js/foo.js"></script>
...
</head><body>
...
<script>
foo_main({{ foo_params_json|safe }});
</script>
</body></html>
This makes it a lot easier to reuse this code.