we are looking at a lot of HTML usually.
Now, <, > and </ around the tags are splattered everywhere. But unless there is a syntax error, those really have no value. And syntax errors are highlighted.
So instead of looking at:
I would prefer to look at, note you can change this in
Settings -> Editor -> Color scheme -> HTML -> HTML Code
the problem is if I change it this way, the vue templates get affected as well and all condition operators become gray too like the <>
mycomponent.vue
notice all and in
is there a different way to do it?
This is a perfect case of using language injections
If you don't have explicit vue.js support already set up (or if it doesn't handle it), you can define language injections to highlight that area as javascript expressions.
https://studgeek.com/2010/08/16/intellijidea-webstorm-knockout-data-bind-attributes/
Shows how a dummy javascript context can be set up for arbitrary xml attributes.
In this (quite dated) image, you can see the Prefix is set to a random window variable object, and the suffix ends the object, this simply wraps the code in the xml attribute with something roughly resembling the correct context for the javascript.
The data-bind xml attribute in this case, would be swapped out for v-if v-else or any other vue attributes that take a binding that looks similar to javascript.
If this fails to work, it sounds like an IntelliJ bug which should be reported.
You can try if rainbow brackets plugin works for you.
It changes the color of brackets and gives each pair of opening and closing bracket a unique colour to make it easier to identify which belongs together.
Related
I'm developing a Vue app using UI Kit which implies using various custom attributes like uk-grid, uk-icon, uk-navbar etc (in Vue single file components' templates). For each one, IntelliJ gives me a warning like
Warning:(7, 52) Attribute uk-icon is not allowed here
How can I tell IntelliJ not to do this? Googling the warning haven't brought any sane results which makes me think there's no ready-to-use package for this (for this particular UI Kit), so the question is: how to make Idea not to warn about a custom list of attributes? But I'll be glad to be wrong and if there is a better solution, please let me know.
Update: like lena has suggested, pressing alt+enter suggests helpful options, including adding attribute to the list of custom attributes. However, wildcard suggestion didn't work for me: the below screenshot illustrates settings that make v-localize attrbute be recognized, but uk--prefixed attribute are still highlighted with warning:
You can add uk-* attributes to Custom HTML tag attributes list in HTML | Unknown HTML tag attribute inspection; the easiest way to do this is using Add to custom HTML attributes quickfix available on Alt+Enter:
Note that IDEA recognizes Vuikit components and directives out of the box - did you consider using it instead of pure UIKit?
I would like JS <script type="xx"> content to be colored nicely inside my HTML document.
Right now, when adding the type to a script tag, the element text becomes uniform white, as seen below.
Of course, the JS code is colored nicely within the HTML if removing the type attribute.
Is there some setting I can modify to make this work?
No setting to modify. This is a known issue. From the thread it looks like syntax highlighting was working at one point for script tags with the type attribute but was lost.
Hopefully it's fixed soon. I'm seeing the same thing on VSCode 1.13.1.
I am using custom seperators/tags for template variables in HTML code. My tags are "{[{" "}]}". Can I make IntelliJ IDEA (or WebStorm) ignore completely what is inbetween them? If it matters, it is Go template language with custom tags.
Example :
<div title="{[{.T.T "error"}]}!"></div>
Gets marked as error because of the quotes inside the quotes. It also disables the ability for proper auto indentation or code formatting.
Another example, in this case JavaScript in an HTML document :
<script>
{[{if .Data.User}]}
var userData = {[{.Data.User}]};
{[{end}]}
</script>
This marks the quotes themselves as error.
I don't want IntelliJ to check the template code, just ignoring everything between the brackets would be enough.
No, you can't. IntelliJ IDEA builds a complete parse tree for the entire file, and it is not able to ignore arbitrary chunks of the file.
What you can do is either write a plugin that will be able to parse your template syntax, or change the syntax you use so that it matches more closely an existing template library already supported by IntelliJ IDEA.
I explicitly set the line-height property of an <input> element in CSS. But when I check the element in firebug, the line-height value of this element is not what I set in CSS. And it seems that the line-height value has nothing to do with what I set in CSS. What is the possible reason for this?
According to the definition of line-height in the CSS 2.1 specification, it has a specific meaning for block container elements and a different meaning for non-replaced inline elements. I can’t find any statement on replaced inline elements there, and an input element can be regarded as a replaced element, somewhat debatably.
Anyway, odd as it may seem, browsers seem to ignore line-height on input elements. As a workaround, you might consider setting the height property, or setting vertical padding. But the results won’t be consistent across browsers. As a rule of thumb, we should expect the rendering of a text input box to the under the control of the browser, though in some cases some features can be tuned using CSS.
not sure if that was the point but i specified margin, padding and got rid of border, here you got exactly 14px: http://jsfiddle.net/mymlyn/Uq5Tt/2/
if you check the dev tools it is (and was before specyfying the above) exactly 14px:
http://dl.dropbox.com/u/26827941/ScreenShot060.png (chrome dev tools)
http://dl.dropbox.com/u/26827941/ScreenShot061.png (firebug in ff)
the reason in your case might be that your input field has a specified id or class,
<input id="someID"/>
and there is something like
input#someID {line-height: 20px;}
in your css somewhere else, andyou might be trying to change its value by setting
input {line-height: 14px;}
if that was not the case im out of ideas :)
The lineheight wont be rendered in firefox but i think it will be in IE. There's a small trick to do, which is to let lineheight style to be rendered as block elements instead of an inline elements.
For example:
This will not work
span {font-size:12px; line-height:14px}
But this will:
span {font-size:12px; line-height:14px; display:block;}
I was experimenting with Dojo and Dijit in the past days and I find it quite interesting. I was however trying to find a reference or an API doc that helps me understand all the properties I can assign to widgets and containers.
For example a Tab with a Save Icon will be like this:
<div data-dojo-type="dijit.layout.ContentPane" title="Group Two" data-dojo-props="iconClass: 'dijitEditorIcon dijitEditorIconSave'">
Now, where can I find what to put in the "data-dojo-props" property? Where can I find for example all the list of icons?
My main question would be for example on how to create a vertical menubar, but beyond odd examples scattered here and there, the api reference is not much helpful...
Any help? Am I missing something here?
For this kind of situation, the trick is learning how to convert between the programmatic Javascript style and the declarative HTML style (and sometimes also between the old declarative style, without data).
For the new declarative style, basically the only "real" argument now is data-dojo-props and it consists of an object that will be passed to the widget constructor.
//programatic style
new dijit.myWidget({foo:'a', bar:'b'});
//declarative style
<div data-dojo-type="dijit.myWidget" data-dojo-props="foo:'a', bar:'b'"></div>
You can find what properties an widget accepts by checking the corresponding widget documentation and looking for either declarative or programmatic examples (now that we know how to convert between them). If that is not enough, you can also check the source code - it is usually very well commented and is where api.dojotoolkit.org gets its data from anyway.