I have stumbled upon this pen.
In it's code there are fragments using var(--tx, 0)
Then variable --tx is referenced and set in JS via
document.documentElement.style.setProperty('--tx', 'valueForProperty');
I searched google, mdn etc. and found out css3 variables. But what I understood, about them, is that one declares variables in :root pseudo element then use them with var keyword (mdn).
I didn't find information about second variable to var. I guess var(name, value) initializes variable in place, yet I couldn't replicate this in my pen.
The original author uses SCSS preprocesor, it might be the catch, but it declares variables with $ sign.
So I ask if somebody can explain, what's going on in this pen in regards to var statements.
Related
According to MDN getComputedStyle(element) returns CSSStyleDeclaration object. But Flow tells that return type of method is any. Can I fix this without writing own type declaration?
It doesn't look like there is any particular reason, just that it hasn't yet been given a better type. You can see in the DOM libdef file that it is declared as returning any, and that line hasn't been touched in over four years.
This would be an easy first PR, if you are interested in improving it.
I'm new to meteor, and I've followed different tutorials that explain and use things differently.
There seems to be two ways of processing an event. For example, if I want to manage a click on a tag, both of the following methods work :
This one is present on the hello world meteor app
'click p'(event, instance) {
}
This one is the one used in the tutorial.
'click p': function(event){
}
Both work perfectly and if I use both the last one will be effective. The weird thing is the color is not the same (on sublime text), the second has usual js colors but the first one is only green, orange, and everything else is white (on monokai).
I'm tempted to use the second one for better visibility, but I know I should not make that choice base on that. Which one is correct, and when ?
Bottom line: it doesn't really matter if you only need the event.
There are 2 syntactic differences between the functions, but there is no substantial difference:
The notation that you are using:
funcName(arg1, arg2)
vs
funcName: function(arg1, arg2)
The highlighting coloration difference you see in your editor is probably related to the shorthand notation. This shorthand notation is a feature of ES2015, the relatively new version of JS, and both are functionally identical. It is just syntactic sugar.
The arity (number of arguments).
The function is used as an event handler as a callback. Due to the dynamic nature of JavaScript, any function can be called with any number of parameters. The parameters are being assigned to arguments based on the function's definition, and are also dynamically available to the called function via the arguments pseudo-array.
The callback will always be called with 2 parameters. In the version with 1 argument, the second parameter will not be bound to any identifier within the function. You can omit the second argument if you don't need the template instance.
In the example given here https://developers.google.com/youtube/iframe_api_reference you can see that instead of using standard css selector syntax there's a custom string syntax that seems to only refer to id.
<div id="player"></div>
// note no 'var' and yet this will work in strict mode
// since 'player' is being implicitly grabbed from the dom
player = new YT.Player('player', ...);
This of course creates the problem of leaking a global variable for whatever the id is named, which is something that I try to avoid (because it creates a loophole for strict mode and is just confusing and unexpected behavior).
A workaround is to hyphenate the name so that it can't be accessed from the global space
<div id="js-player"></div>
// now window['js-player'] is guarded from accidental access
var player = new YT.Player('js-player', ...);
but the bottom line is that using ids is just bad practice and I prefer to avoid them altogether since classes work nicely and don't have the weird side affects.
Might be a bit late for an answer but anyways ...
Just pass the selector like so
var player = new YT.Player(
document.querySelector('.your-class'),
... API Stuff ...
);
Of course, you could use jQuery or any other vanilla JS method for selecting elements.
var player = new YT.Player(
$('.your-class')[0],
... API Stuff ...
);
If you use a method that returns a node list be sure to loop trough the items like so: Todd Motto - Looping Through NodeLists / Arrays
I am familiar with bindings with curly braces, like {{variable}}, from Polymer 0.5.
However, in examples and code snippets for the release version of Polymer, I've begun to notice bindings with square brackets, such as [[variable]], as well.
Does {{variable}} mean something different now, or is it the same and [[variable]] is just an addition? What is the difference between binding to [[variable]] and {{variable}} in Polymer?
Just as you've noticed, there are now two different syntaxes for data-binding, which have different purposes:
{{variable}} indicates that you would like Polymer to automatically detect whether or not the binding should be one-way or two-way.
[[variable]] indicates that you want the binding to one-way only.
Why the change?
Polymer 1.x differs from older versions is that bindings are now one-way by default, much unlike 0.5, where they were always two-way.
In other words, if you write
<my-element some-property="{{myVariable}}"></my-element>
then by default, when
myVariable is changed, Polymer updates the binding, and thus updates my-element's someProperty.
someProperty is changed, Polymer does not update the binding to myVariable.
This is always the case unless you set notify:true on the property inside my-element:
Polymer({
is: 'my-element',
properties: {
someProperty: {
notify: true,
...
With notify: true, the binding is now two-way, so when
myVariable is changed, Polymer updates the binding to someProperty.
someProperty is changed, Polymer also updates the binding to myVariable.
This behaviour (when using notify: true) used to be default in 0.5; now you must ask for it explicitly.
When to use [[variable]]
There's no technical reason why you must use [[variable]], because Polymer will automatically detect whether bindings are one or two-way with {{variable}}. So why would you use it?
Let's say you're working in a large project, and you know that based on the way that data flows in a particular page/element, a certain property should never be changed by the element it is being bound to, for example in the case of an element which functionally serves a purpose as a label:
<display-data source-data="{{data}}"></display-data>
...
<data-editor source-data="{{data}}"></data-editor>
Everything looks good! The data property is bound to both the display-data element and data-editor elements, and will be automatically shared between them. (In this example, assume display-data's sole purpose is to preview the data that it is bound to.)
One day, you or someone else is editing display-data, and you forget about the situation in which it is being used in above. For an entirely different use-case, you or the other developer would like display-data to also format or otherwise modify the data it is given and push it back towards any other elements that may be bound to it. You/they edit display-data as such:
Add notify: true to sourceData, to allow two-way data-binding.
Add code into display-data which modifies the sourceData property.
This works great for all the pages that needed this functionality. But on the page mentioned before, this was not intended and ends up garbling the data that data-editor sees!
This problem would have been avoided had:
The dev team communicated better and had been more considerate of where elements are being used,
and/or [[data]] was used instead of {{data}} in the page/element in question.
With
<display-data source-data="[[data]]"></display-data>
...
<data-editor source-data="{{data}}"></data-editor>
data-editor can change data, but display-data will only ever be able to read data, and won't be able to change its value when it changes the value of its sourceData property, even when notify: true is set on sourceData.
Therefore, it could potentially be a good idea to:
Use [[variable]] whenever you need to bind to variable. This way, you enforce the direction through which data should flow in your element/page/application.
Use {{variable}} whenever you know that the binding must be two-way.
According to the documentation,
To make your code more easier to read, you may want to use the [[property]] form by default, and only use {{property}} for two-way bindings.
This being said, however, it ultimately comes down to a matter of choice. If you want to forego the use of [[variable]], no one is stopping you and you will not start any fires.
VBScript on ASP Classic contains an "int" function. (It rounds numbers towards -∞.) Suppose that some excessively "clever" coder has created a global variable named "int". Is there any way to get at the original function? I've tried all manner of workarounds with scoping and dodgy execs, but no dice. I suspect that it is impossible, but I'm hoping that someone will know more about it than I do.
EDIT: Thanks for the responses. Since y'all asked, the global variable, called "Int" (though unfortunately, vbscript is not case-sensitive), is a factory for a class similar to Java's Integer. The default property is essentially a one-arg constructor; i.e. "Int(42)" yields a new IntClass object holding 42. The default property of IntClass in turn simply returns the raw number.
The creator was trying to work around the lack of proper namespaces and static methods, and the solution's actually pretty seamless. Pass in an IntClass where an int is expected and it will automatically trigger the default property. I'm trying to patch the last remaining seam: that external code calling "int" will not round properly (because the constructor uses CLng).
Not that I know of, getref only works on custom functions not on build-ins. I would suggest renaming the custom'int' function and update all references to this custom ones. You can use the search function visual studio (express) or any other tool of your liking for this. Shouldn't be to much work.
I didn't think reserved words would be allowed for function names or variables.
Duncanson's right. Do the pain and rename int. Chances are there are worse things going on than just this.
(why would someone make a global variable named int... that's going to take some thinking)
Or you can use CInt instead on Int
response.write trim(cint(3.14)) + "<br>"
Wrong!!
See NobodyMan comments