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.
Related
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.
Where are the default Emmet settings in Visual Studio Code (v1.15.1)?
I'm looking for the file that makes Visual Studio Code expand the Emmet HTML abbreviation ! into:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>Document</title>
</head>
<body>
</body>
</html>
I'm trying to workaround some problems that happened since Visual Studio Code started being shipped with Emmet 2.0 by default.
You can override it with custom snippets.
File settings.json (Ctrl + ,):
"emmet.extensionsPath": PATH_TO_YOUR_NEW_FOLDER_WITH_SNIPPETS
In this folder, create file snippets.json:
Emmet 2.0: Custom Emmet snippets in HTML should be a valid abbreviation. For example: use ul>li instead of <ul><li></li></ul>.
If you want to have just text and not markup in your snippet then use the {}notation:
{<ul><li></li></ul>}
{
"variables": {
"lang": "en"
},
"html": {
"snippets": {
"!": "!!!+html[lang=${lang}]>(head>meta[charset=UTF-8]+title{Document})+body"
}
}
}
Visual Studio Code documentation: "Using custom Emmet snippets"
From this Reddit answer:
I'm not sure where they are located on your filesystem when Visual Studio Code is installed, but all the default HTML snippets are here:
https://github.com/emmetio/snippets/blob/master/html.json
You can find the default Emmet settings in the defaultSettings.json file.
However, it's easier to open Visual Studio Code, hit Ctrl + Shift + P and type: "defaultSettings" to access this configuration file.
This directly answers your question, but it won't necessarily help you solve your problem.
Well, unfortunately you can't get the default Emmet settings, since the plugin is bundled with VS Code itself. You can view default Emmet files in editor's source code: https://github.com/microsoft/vscode/tree/main/extensions/emmet
As Peter Mortensen mentioned above, you can only add or customize Emmet snippets with extra file. It's explained in details here: https://code.visualstudio.com/docs/editor/emmet
Hope it satisfies your interest in this matter.
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.
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!
I have been using nxml-mode to edit XHTML. However, it does not work very well for HTML4 documents whose tags don't have to close. Has anybody found a good Emacs mode for editing these files?
Example document:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en-gb">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8">
<title>Test</title>
</head>
<body>
</body>
</html>
I find html-mode works quite well. You might also want to consider html-helper-mode, which has a lot more features than plain html-mode.
I used html-helper-mode for awhile, but switched back to html-mode because the indenting in html-helper-mode was acting funny and I didn't have the time to troubleshoot it. So my vote is for html-mode as well.