I've been wanting to get into learning build-automation within web development having only real experience with ANT in building Android applications.
I want to build websites that utilize LESS but I can't see how to achieve this as It sounds like a it's good practice to use the embedded JS approach in development and compile LESS into CSS when deploying but I don't understand a good approach that would match up the LESS links and JS include for jess.js within a build script. e.g.
Replacing:
... html ...
<link rel="stylesheet/less" type="text/css" href="styles.less" />
<script src="less.js" type="text/javascript"></script>
... html ...
With:
<link rel="stylesheet/css" type="text/css" href="styles.min.css" />
I hope what I've mentioned makes sense.
Useful
HTML5 Boilerplate Build Script
Phing
If anyone could give me any pointers/advise on this matter I would greatly appreciate it.
I'm on the core team for Less.js. Don't use the browser version of LESS if you can avoid it (for instance, you might be enabling users to edit "themes" in real-time in the browser... but unless you're doing something like that, avoid the browser version).
Try using this build tool for compiling Less to CSS: https://github.com/assemble/assemble-styles. The recommended practice is to pre-compile LESS to CSS, and assemble-styles makes it easy to create "bundles" or multiple versions of your LESS/CSS files, and you can add a watch task so that as you are working on the LESS files they automatically compile to CSS.
With LESS being compiled to CSS as part of the development process, you can then just focus your energy on how you want to handle your CSS in production (without having to even think about LESS). Make sense? If you have any questions I'm happy to help.
If you are familiar with npm, then this is simple to use. Just do npm install assemble-styles
Then follow the instructions on the README.
No build script will be able to merge a css file with a js file as in your example. They are two completely different languages serving two completely different needs, and they need to be kept apart from each other. As Less is, in the end, just CSS it makes no sense to merge a Less file into a js file.
Moreover best practices suggest to put css links in the head of your document (as Steve Souders suggests here) and javascript code at the end of the document, just before the closing body tag (again Steve Souders, here).
If you follow these rules (which is strongly recommended for performance) you'll end up placing css links far away from your js scripts in the html, like so:
<html>
<head>
<link rel="stylesheet/less" type="text/css" href="styles.css" />
</head>
<body>
....here goes the content of the page
<script type="text/css" src="scripts.js"></script>
</body>
</html>
Now, let's imagine a very basic workflow.
You have your bare-bones HTML structure and you need to adjust its layout.
You add a css reset (reset.css) and start styling your document in a Less file called style.less. If you add
<link rel="stylesheet/less" type="text/css" href="styles.less" />
in the head of your document you won't be able to see any change as browsers do NOT understand .less files. These files need to be pre-processed and "translated" in css, so browsers can parse them and apply the given styles to the HTML page. So you'll run your (.less) file into a preprocessor which in turn will spit out a css file. So your <head> will be:
<head>
<link type="text/css" href="css/reset.css" />
<link type="text/css" href="css/styles.css" />
</head>
Notice that the styles.less file will NOT be referenced in the HTML, but only its CSS counterpart styles.css. When you'll be satisfied with your layout it'll be time to move on.
Here's now a good place for a build script to really shine.
A build script will (among other things) concatenate external files of the same kind.
In this case it will be able to merge these two files in a single one. Your new <head> will be:
<head>
<link type="text/css" href="css/main.css" />
</head>
The same thing will happen with js files at the bottom. From:
<script src="one.js" type="text/javascript"></script>
<script src="two.js" type="text/javascript"></script>
<script src="three.js" type="text/javascript"></script>
to:
<script src="scripts.js" type="text/javascript"></script>
As I said this is a very basic, rough example of a workflow using Less (or Sass/Scss, or Stylus) and a build script. I would say that Paul Irish gave the simplest and clearest representation of a build script in action in this video, which I highly recommend, especially because it features the HTML5 Boilerplate, as referenced in your question.
Hope this helped you better understanding, let me know if you have any doubts.
Related
For example in html file I have
<script src="https://d3js.org/d3.v6.min.js"></script> and I want to get hints like d3->csv etc.
In WebStorm it is possible by adding https://d3js.org/d3.v6.min.js to External Libraries. Is there a way to do so in VSCode?
It is in a simple HTML+JS file without npm, node etc. like:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
<script src="https://d3js.org/d3.v5.min.js"></script>
</head>
<body>
<script>
d3.SHOW_HINTS
</script>
</body>
</html>
For your d3 use case, all you need to do is:
move your <script> tag content from HTML file into a standalone JS file.
npm install #types/d3, like Mike Lischke has already pointed out
The result:
You cannot get the same kind of IntelliSense hint within the <script> tag inside a HTML file, since the official extension doesn't support it. Please refer to my answer to another question here for more details.
What you are after is the intellisense information, which is provided by the JS/TS language implementation. Beside the actual TS code (if provided) it uses socalled typings (or declaration) files. There are typings for many different libraries. For D3.js use npm install #types/d3 or add "#types/d3": "^5.7.2" to your dev-dependencies section in package.json and run npm install after that.
So I've got flutter web up and running (pretty amazing work tbh) and I went about bench marking the Button Press Count app that it gives by default on PageSpeed Insights. The results were impressive but there's one suggestion that would seem to increase the score. Is there any way to include <link rel='preload'> for the assets they mentioned?
And would there be anyway to do code splitting as well the way webpack does it for main.dart.js
See the website here: https://flutterdemoapp.netlify.app
You can try to add this code to your index.html file which is under the web folder,
<html>
<head>
<link rel='preload'>
<script defer type="application/javascript" src="main.dart.js"></script>
</head>
</html>
If you already tried that or this doesn't work so you can use this library. It makes this automatically.
We have been having discussions in our product dev team regarding html maintainability and reuse. To set the context, we started with HTML5/CSS3 front end with plain JS under Play MVC, which in turn uses RESTful backend. Then we thought of adding AngularJS to the spin and to adopting a hybrid approach only to realize that two strong MVC frameworks don't necessarily work together and you have to pick one. So for the performance and type-safety among other issues, we decided to go with using Play framework and Scala based templates.
Here's the challenge: We would like to create reusable web components just like Apache Tiles, so that common elements such as header, menus, footer, etc. can be reused. These components are ready to go in Play to which dynamic content could be added to serve the entire page.
Can this be done? If yes, how?
Secondly, play templates seem to take you back in the time since they don't allow the separation of concern in html. Therefore for re-designing or improving html content, the html developer will have to deal with the template or merging new html with existing templates. How to make this process easier?
I'm don't know exactly how Apache Tiles works, but if I properly understand, it offers a way to create pages using smaller components (like header, menu, footer, etc) and some sort of include mechanism to glue these components together and then compose the page.
That said, you can achieve the same thing using Twirl. You just need to declare reusable blocks that can be used inside the same page, or you can have something like Rails partials that can be reused across different pages.
Let's see an example. Consider that you have the following files:
File app/views/partials/header.scala.html:
<header>
<h1>My Header</h1>
</header>
File app/views/partials/navigation.scala.html:
<nav>
<ul>
<li>Home</li>
<li>Profile</li>
<li>FAQ</li>
</ul>
</nav>
File app/views/partials/footer.scala.html:
<footer>
Some copyright info
</footer>
File app/views/main.scala.html:
#(title: String)(content: Html)
<!DOCTYPE html>
<html lang="en">
<head>
<title>#title</title>
<link rel="stylesheet" media="screen" href="#routes.Assets.versioned("stylesheets/main.css")">
<script src="#routes.Assets.versioned("javascripts/hello.js")" type="text/javascript"></script>
</head>
<body>
#partials.header()
#partials.navigation()
#content
#partials.footer()
</body>
</html>
The files above defines not only some reusable partial templates (header, navigation and footer), but also a common layout (main) that all the pages of your application can reuse. Now, lets see a page that uses the structure above:
File app/views/users/profile.scala.html:
#(user: models.User)
#main(title = "User Profile Page") {
<h2>This is the profile page of #user.username</h2>
}
And there is more: since views are compiled to Scala code, you can import code written in Scala/Java and call it directly from your views, something like Rails view helpers:
File app/views/helpers/DateHelpers.scala:
package views.helpers
object DateHelpers {
def formatToISO8601(date: Date) = {
??? // format the date
}
}
Let's use this helper in our app/views/users/profile.scala.html page:
#(user: models.User)
#import controllers.DateHelpers._
#main(title = "User Profile Page") {
<h2>This is the profile page of #user.username.</h2>
<p>User since #formatToISO8601(user.createdAt)</p>
}
And there are other approaches to consider:
Ping-Play: Big Pipe Streaming for the Play Framework
You can create a Play module that integrate with Apache Tiles. I'm pretty sure this is possible.
A quick answer would be the following. If you are comfortable with Yeoman, you can keep most of the UI part in existing HTML, while rendering some pages with Scala templates. I would recommend Play-yeoman, which may help such that you can--with minimum effort--reuse UI components.
For instance, you may easily convert a NodeJS+Angular app into Play+Angular. The Play-yeoman plugin helps a lot. But it is not so flexible as it does not support any arbitrary Yeoman configuration, just Angular.
I just started a new Typo3 4.6 site and I found this weird line right off the bat in the
<link type="text/css" rel="stylesheet" href="data:text/css,">
Where does it come from? And how can I get rid of it?
This is the link to the css stylesheet which creates the styles for the pages in your Typo3 CMS. You probably need this line and might want to keep it.
It must have been added from some extension. I used the introductory package. Ive done a new site with the blank package and its not there anymore. Thanks!
Good evening,
I have a website with a current css optimized for a desktop experience. I am working on an Iphone css, using IwebKit5 to provide a better user experience on the go.
I was using javascript, parsing the user agent to detect which css to use. I was looking for a way to avoid use of javascript, and discovered the media queries feature.
<!--[if !IE]>-->
<link type="text/css" rel="stylesheet" media="only screen and (max-device-width: 480px)" href="mobile.css"/>
<!--<![endif]-->
<link type="text/css" rel="stylesheet" href="desktop.css"/>
This is what I tried, it works well on desktop (the Iphone css is ignored), but on Iphone I realized that both mobile.css and desktop.css are loaded, so I am trying to find a way to avoid that. What is the option to add in order to avoid this behavior ?
Thanks !
I believe you're approaching this the wrong way.
Include desktop.css first, and let that be included unconditionally.
Then, inside mobile.css, add/override whatever properties you need to.
The vast majority of desktop.css should still be relevant on the iPhone - you should just be adjusting sizes/lengths and other such small tweaks on various elements inside mobile.css.