Tunneling with SSH
SSH Guide: Index
Platforms
Linux, Unix, Solaris. Linux supports SSH. To connect using SSH, see the "Tunneling Using Cygwin" section below.
Macintosh. In important regards, procedures for tunneling with a Mac client terminal resemble those for Windows clients. Mac users can download and install any number of free or for-fee terminals, the most popular being MacSSH, which is characteristically easy to use, is free, and offers superior performance for SSH1 connections.
NiftyTelnet 1.1 SSH
Mac OS X, based on FreeBSD and the Mach 3 kernel, has SSH built in and is constantly updated. You can also obtain and use Data Fellows' F-Secure SSH, a for-fee (see below) client create a desktop terminal allowing you to tunnel to the CVS server. F-Secure SSH can be obtained at: http://www.DataFellows.com. For SSH1, you will want F-Secure SSH v.1.02; v.2.1 is for SSH2 connections only--i.e., those requiring encrypted certificates, or keys.
Windows. If you are using Windows (NT or 9x or 2K), then you can use SecureCRT, F-Secure SSH, or Cygwin. Cygwin, from Cygnus Solutions, provides a nearly full Unix environment on your desktop.
In contrast, SecureCRT and F-Secure SSH only provide user-friendly terminals, i.e., they don't pretend to emulate a Unix environment. Both F-Secure SSH and SecureCRT cost money ($100 for SecureCRT, $150 for F-Secure SSH), although a free, 30-day trial version is available for each. Of all, Cygwin has the added value of not just being free and very powerful, but also open source and constantly improved upon.


The exposed API from jiff.js (The client side library of JIFF).
Wraps the jiff API. Internal members can be accessed with jiff.<member-name>.
- Version:
- 1.0
- Source:
Classes
Namespaces
Methods
make_jiff(hostname, computation_id, options) → {jiff-instance}
Create a new jiff instance.
Parameters:
| Name | Type | Description |
|---|---|---|
hostname |
string | server hostname/ip and port. |
computation_id |
string | the id of the computation of this instance. |
options |
object | javascript object with additonal options [optional],
all parameters are optional, However, for predefined public keys to work all
of "party_id", "secret_key", and "public_keys" should be provided.
{ "triplets_server": "http://hostname:port", "numbers_server": "http://hostname:port", "keys_server": "http://hostname:port", "party_id": number, "party_count": number, "secret_key": <RSAKey> (check Cryptico Library), "public_keys": { 1: "ascii-armored-key1", 2: "ascii-armored-key2", ... } } |
- Source:
Returns:
the jiff instance for the described computation.
The Jiff instance contains the socket, number of parties, functions
to share and perform operations, as well as synchronization flags.
- Type
- jiff-instance
mod(x, y) → {number}
Mod instead of javascript's remainder (%).
Parameters:
| Name | Type | Description |
|---|---|---|
x |
number | |
y |
number |
- Source:
Returns:
x mod y.
- Type
- number


Projects
Solidity Client
Client portal connecting to a locally deployed Ethereum smart contract used to manages a list of customers.
Client portal connecting to a locally deployed Ethereum smart contract used to manages a list of customers.


nips nips2007 nips2007-22 nips2007-22-reference knowledge-graph by maker-knowledge-mining
Source: pdf
Author: Percy Liang, Dan Klein, Michael I. Jordan
Abstract: The learning of probabilistic models with many hidden variables and nondecomposable dependencies is an important and challenging problem. In contrast to traditional approaches based on approximate inference in a single intractable model, our approach is to train a set of tractable submodels by encouraging them to agree on the hidden variables. This allows us to capture non-decomposable aspects of the data while still maintaining tractability. We propose an objective function for our approach, derive EM-style algorithms for parameter estimation, and demonstrate their effectiveness on three challenging real-world learning tasks. 1
[1] J. Besag. The analysis of non-lattice data. The Statistician, 24:179–195, 1975.
[2] P. F. Brown, S. A. D. Pietra, V. J. D. Pietra, and R. L. Mercer. The mathematics of statistical machine translation: Parameter estimation. Computational Linguistics, 19:263–311, 1993.
[3] G. Hinton. Products of experts. In International Conference on Artiﬁcial Neural Networks, 1999.
[4] V. Jojic, N. Jojic, C. Meek, D. Geiger, A. Siepel, D. Haussler, and D. Heckerman. Efﬁcient approximations for learning phylogenetic HMM models from data. Bioinformatics, 20:161–168, 2004.
[5] D. Klein and C. D. Manning. Corpus-based induction of syntactic structure: Models of dependency and constituency. In Association for Computational Linguistics (ACL), 2004.
[6] P. Liang, B. Taskar, and D. Klein. Alignment by agreement. In Human Language Technology and North American Association for Computational Linguistics (HLT/NAACL), 2006.
[7] B. Lindsay. Composite likelihood methods. Contemporary Mathematics, 80:221–239, 1988.
[8] H. Ney and S. Vogel. HMM-based word alignment in statistical translation. In International Conference on Computational Linguistics (COLING), 1996.
[9] A. Siepel and D. Haussler. Combining phylogenetic and hidden Markov models in biosequence analysis. Journal of Computational Biology, 11:413–428, 2004.
[10] C. Sutton and A. McCallum. Piecewise training of undirected models. In Uncertainty in Artiﬁcial Intelligence (UAI), 2005.
[11] C. Sutton and A. McCallum. Piecewise pseudolikelihood for efﬁcient CRF training. In International Conference on Machine Learning (ICML), 2007.
[12] M. Wainwright and M. I. Jordan. Graphical models, exponential families, and variational inference. Technical report, Department of Statistics, University of California at Berkeley, 2003. 8


Spring MVC view layer: Thymeleaf vs. JSP
In this article we will compare the same page (a subscription form) created twice for the same Spring MVC application: once using Thymeleaf and another time using JSP, JSTL and the Spring tag libraries.
All the code seen here comes from a working application. You can download the source code of such application from the documentation page.
Common requirements
Our customers need a form for subscribing new members to a message list, with two fields:
- Email address
- Type of subscription (receive all emails, daily digest)
We will also need this page to be HTML5 and completely internationalizable, extracting all texts and messages from resource files already configured in our MessageSource
objects in our Spring infrastructure.
Our application will have two @Controller
s, which will contain exactly the same code but will forward to different view names:
SubscribeJsp
for the JSP page (thesubscribejsp
view).SubscribeTh
for the Thymeleaf page (thesubscribeth
view).
We will have the following classes in our model:
Subscription
form-backing bean with two fields:String email
andSubscriptionType subscriptionType
.SubscriptionType
an enum modeling thesubscriptionType
field of the form, with valuesALL_EMAILS
andDAILY_DIGEST
.
(In this article we will just focus on the JSP/Thymeleaf template code. If you want to know implementation details for the controller code or Spring configuration, check the source code in the downloadable package)
Doing it with JSP
This is our page:
And this is our JSP code, making use of both JSTL (core
) and Spring (tags
and form
) JSP tag libraries:
<%@ taglib prefix="sf" uri="http://www.springframework.org/tags/form" %>
<%@ taglib prefix="s" uri="http://www.springframework.org/tags" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html>

<title>Spring MVC view layer: Thymeleaf vs. JSP</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link rel="stylesheet" type="text/css" media="all" href="<s:url value='/css/thvsjsp.css' />"/>

This is a JSP

<s:url var="formUrl" value="/subscribejsp" />
<sf:form modelAttribute="subscription" action="${formUrl}">
<fieldset>

<s:message code="subscription.email" />:
<sf:input path="email" />

<s:message code="subscription.type" />:

<c:forEach var="type" items="${allTypes}" varStatus="typeStatus">

<sf:radiobutton path="subscriptionType" value="${type}" />

<s:message code="subscriptionType.${type}" />

</c:forEach>

<button type="submit" name="save"><s:message code="subscription.submit" /></button>

</fieldset>
</sf:form>

Doing it with Thymeleaf
Now, let’s do the same with Thymeleaf. This is our page:
And this is our Thymeleaf code:
<!DOCTYPE html>

<title>Spring MVC view layer: Thymeleaf vs. JSP</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link rel="stylesheet" type="text/css" media="all"
href="../../css/thvsjsp.css"<EMAIL_ADDRESS>

This is a Thymeleaf template

<form action="#" th:object="${subscription}" th:action="@{/subscribeth}">
<fieldset>

Email:
<input type="text" th:field="*{email}" />

Type:

<input type="radio" th:field="*{subscriptionType}" th:value="${type}" />
First type

<input type="radio" /> Second Type

<button type="submit" name="save" th:text="#{subscription.submit}">Subscribe me!</button>

</fieldset>
</form>

Things to notice here:
- This looks much more HTML-ish than the JSP version – no strange tags, just some meaningful attributes.
- Variable expressions (
${...}
) are Spring EL and execute on model attributes, asterisk expressions (*{...}
) execute on the form backing bean, hash expressions (#{...}
) are for internationalization and link expressions (@{...}
) rewrite URLs. (If you want to know more about this, have a look at the “Getting started with the Standard Dialect in 5 minutes” guide). - We are allowed to have prototype code there: for example, we can set an
Email:
text in the label for the first field, knowing that Thymeleaf will substitute it with the internationalized text with keysubscription.email
when it executes the page. - We have even been able to add an

for a second radiobutton just for prototyping pleasure. It will be removed when Thymeleaf executes our page.
Let’s change the page style!
Imagine that now our pages are written we suddenly decide that we do not want green anymore for that region around the submit button, but rather a pale blue. Anyway we’re not sure about the exact tone of blue that will fit better, so we will have to try some combinations before deciding on a specific one.
Let’s see the steps we would have to take with each technology:
Changing the page style using JSP
Step 1: Deploy the application into our development server and start it up. Our JSP page will not render without starting the server, so this will be a requirement.
Step 2: Navigate through the pages until we find the one to change. Normally, the page to change will be one among several dozen pages in our application, and it is quite possible that in order to reach it we will need to click links, submit forms and/or query databases.
Step 3: Fire up firebug, dragonfly, or our favourite in-browser web development tool. This will allow us to modify our styles acting directly on the browser’s DOM, and thus see immediate results.
Step 4: Make the colour changes. Probably trying a couple of different tones of blue before deciding on the one we like.
Step 5: Copy-paste the changes into our CSS files.
Done!
Changing the page style using Thymeleaf
Step 1: Double-click on the .html
template file itself and let our browser open it. Being a Thymeleaf template, it will show just fine, only with template/prototype data (note the subscription type options):
Step 2: Open the .css
file with our favourite text editor. The template file statically links to the CSS in its <link rel="stylesheet" ...>
tag (with an href
that Thymeleaf substitutes when executing the template by the one generated by th:href
). So any changes we make to that CSS will be applied to the static page our browser is displaying.
Step 3: Make the colour changes. As was the case with JSP, we will probably have to try several colour combinations, which will be refreshed in our browser just by pressing F5.
Done!
That was a big difference!
The difference in the number of steps is not really important here (we could also have used firebug with the Thymeleaf template). What is really important is the complexity, the effort and the time required by each of the steps required for JSP. Having to deploy and start the whole application made JSP just lose.
What’s more: think of how this difference would evolve if:
- Our development server was not local but remote.
- Changes didn’t involve only CSS but also adding/removing some HTML code.
- We still hadn’t implemented the required logic in our application to actually reach that page once deployed.
This last point is an important one: what if our application was still being developed, the Java logic needed to show this or other previous pages wasn’t still working alright, and we had to show the new colour to our customer? (or even let him/her choose on the fly!)…
And what about trying to use the JSP as a static prototype?
OK, you can say now, but why did we start the application to modify the JSP instead of just opening it like you did with the Thymeleaf one? Can’t we just do that?.
The short answer is NO.
But let’s try anyway: of course, we will have to rename our file so that its name ends in .html
instead of .jsp
, but let’s see what happens when we open our browser:
WHAT? Where’s our page gone? Well, it’s still there, but in order to make our page work as JSP we had to add lots of JSP tags and features that made it work wondefully when executed by our web server… but at the same time made it be HTML no more. And therefore made it undisplayable for a browser.
Again, let’s remind ourselves what the Thymeleaf template looked like when we double-clicked on it:
Definitely not in the same league, right?
Got HTML5?
But hey – we said at the beginning that our page was going to be HTML5, so… why don’t we use some of the cool new HTML5 form-related features?
For example, there is now an <input type="email" ...>
, which will make our browser check that the text input by users has the shape of an email address. And also, there is a new property for all inputs called placeholder
which shows a text in the field that automatically dissapears when the input gains focus (usually by the user clicking on it).
Sounds good, doesn’t it? Unfortunately not all browsers support this yet (as of 2011, Opera 11 and Firefox 4 do), but we are safe using these features anyway because all browsers will treat an input of a type they do not understand (email
) as a text
input, and will silently ignore the placeholder
attribute in the same way they ignore Thymeleaf’s th:*
ones.
Doing HTML5 with JSP
Before Spring 3.1
Spring MVC’s JSP tag libraries didn’t offer complete support for HTML5 until Spring 3.1, so before this version there was no way to write an email type input tag other than do it in plain HTML, like:
<input type="email" id="email" name="email" placeholder="your@email" value="" />
But this was not correct! In Spring MVC we should never write a JSP input field like that, because we wouldn’t be correctly binding our input to the email
property of the form-backing bean. In order to do so, we would need to use an <s:eval/>
tag, which will apply all the required transformations (like property editors) and make our plain-HTML tag work as if an <sf:email/>
tag existed:
<input type="email" id="email" name="email" placeholder="your@email"
value="<s:eval expression='subscription.email' />" />
Since Spring 3.1
In Spring 3.1 there still is no <sf:email ...>
tag, but the existing <sf:input ...>
allows us to specify a type
attribute with value email
, which will work just fine:
<sf:input path="email" type="email" />
And this will correctly perform our form bindings :-).
Doing HTML5 with Thymeleaf
Thymeleaf has complete support for HTML5 (even with Spring 3.0), so we will only have to change the type
of our input and add a placeholder
, and it will work out of the box, correctly binding our property and integrating with Spring MVCs property editors and more importantly, being displayed as a usual input
box when displayed as a prototype —something the sf:input
tag won’t—:
<input type="email" th:field="*{email}" placeholder="your@email" />
Done!


This section describes features that apply most directly to Web browsers. Having said that, unless specified elsewhere, the requirements defined in this section do apply to all user agents, whether they are Web browsers or not.
A browsing context is a collection of one or
more Document
objects, and one or more views.
At any one time, one of the Document
s in a browsing context is the active
document. The collection of Document
s is the browsing context's session
history.
A view is a user agent interface tied to a particular
media used for the presentation of Document
objects in some
media. A view may be interactive. Each view is represented by an
AbstractView
object. Each view belongs to a browsing context. [DOM2VIEWS]
The document
attribute of an
AbstractView
object representing a view
gives the Document
object of the view's browsing context's active
document. [DOM2VIEWS]
Events that use the UIEvent
interface are
related to a specific view (the view in which the
event happened); the AbstractView
of that view is given in
the event object's view
attribute. [DOM3EVENTS]
A typical Web browser has one obvious view per browsing context: the
browser's window (screen media). If a page is printed, however, a second
view becomes evident, that of the print media. The two views always share
the same underlying Document
, but they have a different
presentation of that document. A speech browser also establishes a
browsing context, one with a view in the speech media.
A Document
does not necessarily have a browsing context associated with it. In particular,
data mining tools are likely to never instantiate browsing contexts.
The main view through which a user primarily interacts with a user agent is the default view.
The default view of a
Document
is given by the defaultView
attribute on the Document
object's DocumentView
interface. [DOM3VIEWS]
When a browsing context is first created, it
must be created with a single Document
in its session
history, whose address is
about:blank
, which is marked as being an HTML document, and whose character
encoding is UTF-8. The Document
must have a single child
html
node, which itself has a single
child body
node. If the browsing context is created specifically to be
immediately navigated, then that initial navigation will have replacement enabled.
The origin of the
about:blank
Document
is set when the
Document
is created, in a manner dependent on whether the browsing context created is a nested browsing context, as follows:
about:blank
Document
is the origin of the active document of the new browsing context's parent
browsing context at the time of its creation.
about:blank
Document
is the origin of the active document of the new browsing context's opener
browsing context at the time of the new browsing context's creation.
about:blank
Document
is a globally unique identifier assigned when the
new browsing context is created.
Certain elements (for example, iframe
elements) can instantiate further browsing contexts. These are called nested browsing contexts. If a
browsing context P has an element in one of its
Document
s D that nests another browsing
context C inside it, then P is
said to be the parent browsing context of C, C is said to be a child browsing context of P, and C is said to be nested through D.
A browsing context A is said to be an ancestor of a browsing context B if there exists a browsing context A' that is a child browsing context of A and that is itself an ancestor of B, or if there is a browsing context P that is a child browsing context of A and that is the parent browsing context of B.
The browsing context with no parent browsing context is the top-level browsing context of all the browsing contexts nested within it (either directly or indirectly through other nested browsing contexts).
The transitive closure of parent browsing contexts for a nested browsing context gives the list of ancestor browsing contexts.
A Document
is said to be fully active
when it is the active document of its browsing context, and either its browsing context is
a top-level browsing context, or the
Document
through which that browsing context is nested is itself fully active.
Because they are nested through an element, child browsing contexts are always tied
to a specific Document
in their parent
browsing context. User agents must not allow the user to interact with
child browsing
contexts of elements that are in Document
s that are not
themselves fully active.
A nested browsing context can have a seamless browsing context flag set, if it is
embedded through an iframe
element with
a seamless
attribute.
It is possible to create new browsing contexts that are related to a top level browsing context without being nested through an element. Such browsing contexts are called auxiliary browsing contexts. Auxiliary browsing contexts are always top-level browsing contexts.
An auxiliary browsing context has an opener browsing context, which is the browsing context from which the auxiliary browsing context was created, and it has a furthest ancestor browsing context, which is the top-level browsing context of the opener browsing context when the auxiliary browsing context was created.
The opener
DOM
attribute on the Window
object must
return the Window
object of the browsing context from which the current browsing
context was created (its opener browsing context),
if there is one and it is still available.
User agents may support secondary browsing contexts, which are browsing contexts that form part of the user agent's interface, apart from the main content area.
A browsing context A is allowed to navigate a second browsing context B if one of the following conditions is true:
Each browsing context is defined as having a list of zero or more directly reachable browsing contexts. These are:
The transitive closure of all the browsing contexts that are directly reachable browsing contexts forms a unit of related browsing contexts.
All the executable code in a unit of related browsing contexts must execute on a single conceptual thread. The dispatch of events fired by the user agent (e.g. in response to user actions or network activity) and the execution of any scripts associated with timers must be serialized so that for each unit of related browsing contexts there is only one script being executed at a time.
Browsing contexts can have a browsing context name. By default, a browsing context has no name (its name is not set).
A valid browsing context name is any string with at least one character that does not start with a U+005F LOW LINE character. (Names starting with an underscore are reserved for special keywords.)
A valid browsing context name or keyword is any
string that is either a valid browsing context name
or that case-insensitively matches one of: _blank
, _self
, _parent
, or _top
.
The rules for choosing a browsing context given a browsing context name are as follows. The rules assume that they are being applied in the context of a browsing context.
If the given browsing context name is the empty string or _self
, then the chosen browsing context must be the
current one.
If the given browsing context name is _parent
,
then the chosen browsing context must be the parent browsing context of the current one,
unless there isn't one, in which case the chosen browsing context must
be the current browsing context.
If the given browsing context name is _top
, then
the chosen browsing context must be the most top-level browsing context of the current one.
If the given browsing context name is not _blank
and there exists a browsing context whose name is the same as the given browsing
context name, and the current browsing context is allowed to navigate that browsing context, and the
user agent determines that the two browsing contexts are related enough
that it is ok if they reach each other, then that browsing context must
be the chosen one. If there are multiple matching browsing contexts, the
user agent should select one in some arbitrary consistent manner, such
as the most recently opened, most recently focused, or more closely
related.
Otherwise, a new browsing context is being requested, and what happens depends on the user agent's configuration and/or abilities:
_blank
, then the new auxiliary browsing context's name
must be the given browsing context name (otherwise, it has no name).
The chosen browsing context must be this new browsing context. If it is
immediately navigated, then the
navigation will be done with replacement
enabled.
User agent implementors are encouraged to provide a way for users to configure the user agent to always reuse the current browsing context.
The AbstractView
object of default views must also implement the Window
object.
[NoInterfaceObject] interface Window { // the current browsing context readonly attribute Window window; readonly attribute Window self; attribute DOMString name; [PutForwards=href] readonly attribute Location location; readonly attribute History history; readonly attribute UndoManager undoManager; Selection getSelection(); // the user agent readonly attribute ClientInformation navigator; readonly attribute Storage sessionStorage; readonly attribute Storage localStorage; Database openDatabase(in DOMString name, in DOMString version, in DOMString displayName, in unsigned long estimatedSize); // user prompts void alert(in DOMString message); boolean confirm(in DOMString message); DOMString prompt(in DOMString message); DOMString prompt(in DOMString message, in DOMString default); void print(); any showModalDialog(in DOMString url); any showModalDialog(in DOMString url, in any arguments); void showNotification(in DOMString title, in DOMString subtitle, in DOMString description); void showNotification(in DOMString title, in DOMString subtitle, in DOMString description, in VoidCallback onclick); // other browsing contexts readonly attribute Window frames; readonly attribute unsigned long length; [IndexGetter] Window XXX4(in unsigned long index); readonly attribute Window opener; Window open(); Window open(in DOMString url); Window open(in DOMString url, in DOMString target); Window open(in DOMString url, in DOMString target, in DOMString features); Window open(in DOMString url, in DOMString target, in DOMString features, in DOMString replace); // cross-document messaging void postMessage(in DOMString message, in DOMString targetOrigin); // event handler DOM attributes attribute EventListener onabort; attribute EventListener onbeforeunload; attribute EventListener onblur; attribute EventListener onchange; attribute EventListener onclick; attribute EventListener oncontextmenu; attribute EventListener ondblclick; attribute EventListener ondrag; attribute EventListener ondragend; attribute EventListener ondragenter; attribute EventListener ondragleave; attribute EventListener ondragover; attribute EventListener ondragstart; attribute EventListener ondrop; attribute EventListener onerror; attribute EventListener onfocus; attribute EventListener onkeydown; attribute EventListener onkeypress; attribute EventListener onkeyup; attribute EventListener onload; attribute EventListener onmessage; attribute EventListener onmousedown; attribute EventListener onmousemove; attribute EventListener onmouseout; attribute EventListener onmouseover; attribute EventListener onmouseup; attribute EventListener onmousewheel; attribute EventListener onresize; attribute EventListener onscroll; attribute EventListener onselect; attribute EventListener onstorage; attribute EventListener onsubmit; attribute EventListener onunload; };
The window
, frames
, and self
DOM attributes must all return the
Window
object itself.
The Window
object also provides the
scope for script execution. Each Document
in a browsing context has an associated list of added properties which, when a document is active, are available on the
Document
's default view Window
object. A Document
object's
list of added properties must be empty when the
Document
object is created.
Objects implementing the Window
interface must also implement the EventTarget
interface.
Window
objects also have an implicit [[Get]] method which returns
nested browsing contexts.
User agents must raise a security exception
whenever any of the members of a Window
object are accessed by scripts whose effective
script origin is not the same as the Window
object's browsing
context's active document's effective script origin, with the following
exceptions:
location
object
postMessage()
method
frames
attribute
XXX4
method
User agents must not allow scripts to override the location
object's
setter.
All Window
objects must provide the
following constructors:
Audio()
Audio(src)
When invoked as constructors, these must return a new HTMLAudioElement
object (a new
audio
element). If the src argument is present, the object created must have
its src
content
attribute set to the provided value, and the user agent must invoke the
load()
method on
the object before returning.
Image()
Image(in unsigned long w)
Image(in unsigned long w, in unsigned long h)
When invoked as constructors, these must return a new HTMLImageElement
object (a new
img
element). If the h argument is present, the new object's height
content attribute must be set to
h. If the w argument is present,
the new object's width
content
attribute must be set to w.
Option()
Option(in DOMString name)
Option(in DOMString name, in DOMString value)
When invoked as constructors, these must return a new
HTMLOptionElement
object (a new option
element). need to define argument
processing
And when constructors are invoked but without using the constructor syntax...?
The open()
method on
Window
objects provides a mechanism for
navigating an existing browsing context or opening and navigating an auxiliary browsing context.
The method has four arguments, though they are all optional.
The first argument, url, gives a URI (or IRI) for a
page to load in the browsing context. If no arguments are provided, then
the url argument defaults to
"about:blank
". The argument must be resolved
to an absolute URI by ...
The second argument, target, specifies the name of the browsing
context that is to be navigated. It must be a valid
browsing context name or keyword. If fewer than two arguments are
provided, then the name argument defaults to the value
"_blank
".
The third argument, features, has no effect and is supported for historical reasons only.
The fourth argument, replace, specifies whether or not the new page will replace the page currently loaded in the browsing context, when target identifies an existing browsing context (as opposed to leaving the current page in the browsing context's session history). When three or fewer arguments are provided, replace defaults to false.
When the method is invoked, the user agent must first select a browsing context to navigate by applying the rules for choosing a browsing context given a browsing context name using the target argument as the name and the browsing context of the script as the context in which the algorithm is executed, unless the user has indicated a preference, in which case the browsing context to navigate may instead be the one indicated by the user.
For example, suppose there is a user agent that supports
control-clicking a link to open it in a new tab. If a user clicks in that
user agent on an element whose onclick
handler uses the window.open()
API to open a
page in an iframe, but, while doing so, holds the control key down, the
user agent could override the selection of the target browsing context to
instead target a new tab.
Then, the user agent must navigate the selected
browsing context to the URI given in url. If the replace is true, then replacement must be
enabled; otherwise, it must not be enabled unless the browsing context was just created as part of the the rules for choosing a browsing context given a
browsing context name. The navigation must be done with the browsing context corresponding to the Window
object that is the script execution context of the script that invoked
the method as the source browsing context.
If the script execution context of a
script isn't a Window
object, then it
can't ever get to a Window
object to
call this method.
The method must return the Window
object of the default view of the browsing
context that was navigated, or null if no browsing context was
navigated.
The name
attribute of
the Window
object must, on getting,
return the current name of the browsing context,
and, on setting, set the name of the browsing
context to the new value.
The name gets reset when the browsing context is navigated to another domain.
The length
DOM
attribute on the Window
interface must
return the number of child
browsing contexts of the active Document
.
The XXX4(index)
method must return the indexth child browsing context of the
active
Document
, sorted in document order of the elements nesting
those browsing contexts.
The origin of a resource and the effective script origin of a resource are both either opaque identifiers or tuples consisting of a scheme component, a host component, and a port component.
These characteristics are defined as follows:
The origin and effective script origin of the URI is whatever is returned by the following algorithm:
Let uri be the URI for which the origin is being determined.
Parse uri according to the rules described in RFC 3986 and RFC 3987. [RFC3986] [RFC3987]
If uri does not use a server-based naming authority, then return a new globally unique identifier.
Let scheme be the <scheme> component of the URI, converted to lowercase. If the UA doesn't support the given protocol, then return a new globally unique identifier.
If the scheme is "file
", then the user agent
may return a UA-specific value.
Let host be the <host>/<ihost> component of the URI.
Apply the IDNA ToASCII algorithm to host, with both the AllowUnassigned and UseSTD3ASCIIRules flags set. Let host be the result of the ToASCII algorithm.
If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, then return a new globally unique identifier. [RFC3490]
Let host be the result of converting host to lowercase.
If no port is explicitly listed, then let port be the default port for the protocol given by scheme. Otherwise, let port be the <port> component of the URI.
Return the tuple (scheme, host, port).
The origin and effective script origin of a script are determined from another resource, called the owner:
script
element
Document
to which the script
element belongs.
javascript:
URI that was returned
as the location of an HTTP redirect (or equivalent in other protocols)
javascript:
URI.
javascript:
URI in an attribute
Document
of the element on which the
attribute is found.
javascript:
URI in a style sheet
javascript:
URI to which a browsing context is being navigated, the URI having been provided by the user
(e.g. by using a bookmarklet)
Document
of the browsing context's active
document.
javascript:
URI to which a browsing context is being navigated, the URI having been declared in markup
Document
of the element (e.g. an
a
or area
element) that declared the URI.
javascript:
URI to which a browsing context is being navigated, the URI having been provided by script
The origin of the script is then equal to the origin of the owner, and the effective script origin of the script is equal to the effective script origin of the owner.
Document
objects and images
Document
is in a browsing context whose sandboxed origin browsing context flag is set
Document
is created.
Document
or image was returned by the
XMLHttpRequest
API
Document
object that was the active document of the Window
object of the browsing context from
which the XMLHttpRequest
constructor was invoked. (That
is, they track the Document
to which the
XMLHttpRequest
object's Document
pointer pointed when it was created.) [XHR]
Document
or image was generated from a javascript:
URI
javascript:
URI.
Document
or image was served over the network and
has an address that uses a URI scheme with a server-based naming
authority
Document
or image.
Document
or image was generated from a data:
URI that was returned as the location of an HTTP
redirect (or equivalent in other protocols)
data:
URI.
Document
or image was generated from a data:
URI found in another Document
or in
a script
Document
or script in
which the data:
URI was found.
Document
has the URI "about:blank
"
Document
is the origin it was assigned when
its browsing context was created.
Document
or image was obtained in some other
manner (e.g. a data:
URI typed in by the user, a
Document
created using the createDocument()
API, a data:
URI
returned as the location of an HTTP redirect, etc)
Document
or image is created.
When a Document
is created, unless stated otherwise
above, its effective script origin is
initialized to the origin of the
Document
. However, the document.domain
attribute can be used to
change it.
The serialization of an origin is the string obtained by applying the following algorithm to the given origin:
://
" to result.
Two origins are said to be the same origin if the following algorithm returns true:
Let A be the first origin being compared, and B be the second origin being compared.
If A and B are both opaque identifiers, and their value is equal, then return true.
Otherwise, if either A or B or both are opaque identifiers, return false.
If A and B have scheme components that are not identical, return false.
If A and B have host components that are not identical, return false.
If A and B have port components that are not identical, return false.
Return true.
The domain
attribute on Document
objects must be initialized to the document's domain, if it has one, and the empty
string otherwise. On getting, the attribute must return its current value,
unless the document was created by XMLHttpRequest
, in which
case it must throw an INVALID_ACCESS_ERR
exception. On
setting, the user agent must run the following algorithm:
If the document was created by XMLHttpRequest
, throw an
INVALID_ACCESS_ERR
exception and abort these steps.
Apply the IDNA ToASCII algorithm to the new value, with both the AllowUnassigned and UseSTD3ASCIIRules flags set. Let new value be the result of the ToASCII algorithm.
If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, then throw a security exception and abort these steps. [RFC3490]
If new value is not exactly equal to the current
value of the document.domain
attribute, then run these
substeps:
If the current value is an IP address, throw a security exception and abort these steps.
If new value, prefixed by a U+002E FULL STOP ("."), does not exactly match the end of the current value, throw a security exception and abort these steps.
Set the attribute's value to new value.
Set the host part of the effective script
origin tuple of the Document
to new
value.
Set the port part of the effective script
origin tuple of the Document
to "manual override" (a
value that, for the purposes of comparing origins, is identical to "manual override" but not
identical to any other value).
The domain of a
Document
is the host part of the document's origin, if that is a scheme/host/port tuple. If it
isn't, then the document does not have a domain.
The domain
attribute is used to enable pages on
different hosts of a domain to access each others' DOMs.
The string representing the script's domain in IDNA format is obtained as follows: take the host part of the script's origin tuple and apply the IDNA ToASCII algorithm and then the IDNA ToUnicode algorithm to each component of the domain name (with both the AllowUnassigned and UseSTD3ASCIIRules flags set both times). [RFC3490]
If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, or if the origin of the script is not a scheme/host/port tuple, then the string representing the script's domain in IDNA format cannot be obtained. (ToUnicode is defined to never fail.)
Various mechanisms can cause author-provided executable code to run in the context of a document. These mechanisms include, but are probably not limited to:
script
elements.
javascript:
URIs (e.g. the src
attribute of img
elements, or an @import
rule in a CSS style
element block).
addEventListener()
, by explicit event
handler content attributes, by event handler DOM
attributes, or otherwise.
The script execution context of a script is
defined when that script is created. It is typically a Window
object.
A script execution context always has an
associated browsing context. If the script execution context is a Window
object, then that object's browsing context is it. Otherwise, the script execution context is associated explicitly with
a browsing context when it is created.
It is said that scripting is disabled in a script execution context when any of the following conditions are true:
designMode
enabled.
A node is said to be without script if either the
Document
object of the node (the node itself, it is itself a
Document
object) does not have an associated browsing context, or scripting
is disabled in that browsing context.
A node is said to be with script if it is not without script.
If you can find a better pair of terms than "with script" and "without script" let me know. The only things I can find that are less confusing are also way, way longer.
When a script is to be executed in a script execution context in which scripting is disabled, the script must do nothing and return nothing (a void return value).
Thus, for instance, enabling designMode
will disable any event handler attributes, event listeners, timeouts, etc,
that were set by scripts in the document.
Define security exception.
javascript:
protocolA URI using the javascript:
protocol must, if and
when dereferenced, be evaluated by executing the script obtained using the
content retrieval operation defined for javascript:
URIs. [JSURI]
When a browsing context is navigated to a javascript:
URI, and the active document of that browsing context has the same origin as the script given by that URI, the
script execution context must be the Window
object of the browsing context being navigated.
When a browsing context is navigated to a javascript:
URI, and the active document of that browsing context has an origin that is not the same as that of the script given by the URI, the
script execution context must be an empty object,
and the script execution context's associated browsing context must be the browsing context being navigated.
Otherwise, the script execution context must be
an empty object, and the script execution context's
associated browsing context must be the browsing context of the Document
object
of the element, attribute, or style sheet from which the
javascript:
URI was reached.
If the result of executing the script is void (there is no return value), then the URI must be treated in a manner equivalent to an HTTP resource with an HTTP 204 No Content response.
Otherwise, the URI must be treated in a manner equivalent to an HTTP
resource with a 200 OK response whose Content-Type metadata is text/html
and whose response body is the return value
converted to a string value.
Certain contexts, in particular img
elements, ignore the Content-Type metadata.
So for example a javascript:
URI for a src
attribute of an img
element would be evaluated in the context of
an empty object as soon as the attribute is set; it would then be sniffed
to determine the image type and decoded as an image.
A javascript:
URI in an href
attribute of an a
element would only be evaluated when the link was
followed.
The src
attribute of an iframe
element would
be evaluated in the context of the iframe
's own browsing
context; once evaluated, its return value (if it was not void) would
replace that browsing context's document, thus
changing the variables visible in that browsing
context.
The rules for handling script execution in a script execution context include making the script not execute (and just return void) in certain cases, e.g. in a sandbox or when the user has disabled scripting altogether.
We need to define how to handle events that are to be
fired on a Document that is no longer the active document of its browsing
context, and for Documents that have no browsing context. Do the events
fire? Do the handlers in that document not fire? Do we just define
scripting to be disabled when the document isn't active, with events still
running as is? See also the script
element section, which says scripts don't run when the document isn't
active.
HTML elements can have event handler attributes specified. These act as bubbling event listeners for the element on which they are specified.
Each event handler attribute has two parts, an event handler content
attribute and an event handler DOM attribute. Event handler attributes must
initially be set to null. When their value changes (through the changing
of their event handler content attribute or their event handler DOM
attribute), they will either be null, or have an
EventListener
object assigned to them.
Objects other than Element
objects, in particular Window
, only have event handler DOM attribute (since they have
no content attributes).
Event handler content attributes, when specified,
must contain valid ECMAScript code matching the ECMAScript FunctionBody
production. [ECMA262]
When an event handler content attribute is set, its new value must be
interpreted as the body of an anonymous function with a single argument
called event
, with the new function's scope chain being
linked from the activation object of the handler, to the element, to the
element's form
element if it is a form control, to the
Document
object, to the Window
object of the browsing context of that Document
. The
function's this
parameter must be the Element
object representing the element. The resulting function must then be set
as the value of the corresponding event handler attribute, and the new
value must be set as the value of the content attribute. If the given
function body fails to compile, then the corresponding event handler
attribute must be set to null instead (the content attribute must still be
updated to the new value, though).
See ECMA262 Edition 3, sections 10.1.6 and 10.2.3, for more details on activation objects. [ECMA262]
The script execution context of the event handler
must be the Window
object at the end of
the scope chain.
How do we allow non-JS event handlers?
Event handler DOM attributes, on setting, must set the corresponding event handler attribute to their new value, and on getting, must return whatever the current value of the corresponding event handler attribute is (possibly null).
The following are the event handler attributes that must be supported by
all HTML elements, as both content attributes
and DOM attributes, and on Window
objects, as DOM attributes:
onabort
Must be invoked whenever an abort
event is targeted at or bubbles through
the element.
onbeforeunload
Must be invoked whenever a beforeunload
event is targeted at or
bubbles through the element.
onblur
Must be invoked whenever a blur
event is
targeted at or bubbles through the element.
onchange
Must be invoked whenever a change
event is targeted at or bubbles through the element.
onclick
Must be invoked whenever a click
event
is targeted at or bubbles through the element.
oncontextmenu
Must be invoked whenever a contextmenu
event is targeted at or
bubbles through the element.
ondblclick
Must be invoked whenever a dblclick
event is targeted at or bubbles through the element.
ondrag
Must be invoked whenever a drag
event is targeted at or bubbles through the
element.
ondragend
Must be invoked whenever a dragend
event is targeted at or bubbles
through the element.
ondragenter
Must be invoked whenever a dragenter
event is targeted at or bubbles
through the element.
ondragleave
Must be invoked whenever a dragleave
event is targeted at or bubbles
through the element.
ondragover
Must be invoked whenever a dragover
event is targeted at or bubbles
through the element.
ondragstart
Must be invoked whenever a dragstart
event is targeted at or bubbles
through the element.
ondrop
Must be invoked whenever a drop
event is targeted at or bubbles through the
element.
onerror
Must be invoked whenever an error
event is targeted at or bubbles through
the element.
The onerror
handler is also used for reporting script errors.
onfocus
Must be invoked whenever a focus
event
is targeted at or bubbles through the element.
onkeydown
Must be invoked whenever a keydown
event is targeted at or bubbles through the element.
onkeypress
Must be invoked whenever a keypress
event is targeted at or bubbles through the element.
onkeyup
Must be invoked whenever a keyup
event
is targeted at or bubbles through the element.
onload
Must be invoked whenever a load
event is targeted at or bubbles through
the element.
onmessage
Must be invoked whenever a message
event is targeted at or bubbles
through the element.
onmousedown
Must be invoked whenever a mousedown
event is targeted at or bubbles
through the element.
onmousemove
Must be invoked whenever a mousemove
event is targeted at or bubbles
through the element.
onmouseout
Must be invoked whenever a mouseout
event is targeted at or bubbles through the element.
onmouseover
Must be invoked whenever a mouseover
event is targeted at or bubbles
through the element.
onmouseup
Must be invoked whenever a mouseup
event is targeted at or bubbles through the element.
onmousewheel
Must be invoked whenever a mousewheel
event is targeted at or bubbles
through the element.
onresize
Must be invoked whenever a resize
event is targeted at or bubbles through the element.
onscroll
Must be invoked whenever a scroll
event is targeted at or bubbles through the element.
onselect
Must be invoked whenever a select
event is targeted at or bubbles through
the element.
onstorage
Must be invoked whenever a storage
event is targeted at or bubbles
through the element.
onsubmit
Must be invoked whenever a submit
event is targeted at or bubbles through the element.
onunload
Must be invoked whenever an unload
event is targeted at or bubbles through the element.
When an event handler attribute is invoked, its argument must be set to
the Event
object of the event in question. If the function
returns the exact boolean value false, the event's
preventDefault()
method must then invoked. Exception: for
historical reasons, for the HTML mouseover
event, the
preventDefault()
method must be called when the function
returns true instead.
All event handler attributes on an element, whether set to null or to a
function, must be registered as event listeners on the element, as if the
addEventListenerNS()
method on the Element
object's EventTarget
interface had been invoked when the element was created, with the event
type (type argument) equal to the type
described for the event handler attribute in the list above, the namespace
(namespaceURI argument) set to
null, the listener set to be a target and bubbling phase listener (useCapture argument set to false), the
event group set to the default group (evtGroup argument set to null), and the
event listener itself (listener
argument) set to do nothing while the event handler attribute is null, and
set to invoke the function associated with the event handler attribute
otherwise. (The listener argument is
emphatically not the event handler attribute itself.)
maybe this should be moved higher up (terminology? conformance? DOM?) Also, the whole terminology thing should be changed so that we don't define any specific events here, we only define 'simple event', 'progress event', 'mouse event', 'key event', and the like, and have the actual dispatch use those generic terms when firing events.
Certain operations and methods are defined as firing events on elements.
For example, the click()
method on the HTMLElement
interface is defined as firing a click
event on the element. [DOM3EVENTS]
Firing a click
event means that a click
event with no namespace, which bubbles and is cancelable, and which uses
the MouseEvent
interface, must be dispatched at the given
element. The event object must have its screenX
,
screenY
, clientX
, clientY
, and button
attributes set
to 0, its ctrlKey
, shiftKey
,
altKey
, and metaKey
attributes
set according to the current state of the key input device, if any (false
for any keys that are not available), its detail
attribute set to 1, and its relatedTarget
attribute
set to null. The getModifierState()
method on the
object must return values appropriately describing the state of the key
input device at the time the event is created.
Firing a change
event means that a change
event with no namespace, which bubbles but is not cancelable, and which
uses the Event
interface, must be dispatched at the given
element. The event object must have its detail
attribute set to 0.
Firing a contextmenu
event means that a contextmenu
event with no namespace, which
bubbles and is cancelable, and which uses the Event
interface, must be dispatched at the given element. The event object must
have its detail
attribute set to 0.
Firing a simple event called
e means that an event with the name e, with no namespace, which does not bubble but is
cancelable (unless otherwise stated), and which uses the
Event
interface, must be dispatched at the given element.
Firing a show
event means firing a simple event called show
. Actually this
should fire an event that has modifier information (shift/ctrl etc), as
well as having a pointer to the node on which the menu was fired, and with
which the menu was associated (which could be an ancestor of the
former).
Firing a load
event means firing a simple event called load
.
Firing an error
event means firing a simple event called error
.
Firing a progress event called e means something that hasn't yet been defined, in the [PROGRESS] spec.
The default action of these event is to do nothing unless otherwise stated.
If you dispatch a custom "click" event at an element that would normally have default actions, should they get triggered? If so, we need to go through the entire spec and make sure that any default actions are defined in terms of any event of the right type on that element, not those that are dispatched in expected ways.
Window
objectWhen an event is dispatched at a DOM node in a Document
in
a browsing context, if the event is not a load
event, the user agent
must also dispatch the event to the Window
, as follows:
Window
object before being dispatched to any of
the nodes.
Window
object at the end of the phase, unless
bubbling has been prevented.
This section only applies to user agents that support scripting in general and ECMAScript in particular.
Whenever a runtime script error occurs in one of the scripts associated
with the document, the value of the onerror
event handler DOM
attribute of the Window
object
must be processed, as follows:
The function referenced by the onerror
attribute must be invoked with three
arguments, before notifying the user of the error.
The three arguments passed to the function are all
DOMString
s; the first must give the message that the UA is
considering reporting, the second must give the URI to the resource in
which the error occurred, and the third must give the line number in
that resource on which the error occurred.
If the function returns false, then the error should not be reported to the user. Otherwise, if the function returns another value (or does not return at all), the error should be reported to the user.
Any exceptions thrown or errors caused by this function must be reported to the user immediately after the error that the function was called for, without calling the function again.
null
The error should not reported to the user.
The error should be reported to the user.
The initial value of onerror
must be undefined
.
The alert(message)
method, when invoked, must show the
given message to the user. The user agent may make the
method wait for the user to acknowledge the message before returning; if
so, the user agent must pause while the method is
waiting.
The confirm(message)
method, when invoked, must show the
given message to the user, and ask the user to respond
with a positive or negative response. The user agent must then pause as the method waits for the user's response. If
the user responds positively, the method must return true, and if the user
responds negatively, the method must return false.
The prompt(message, default)
method,
when invoked, must show the given message to the user,
and ask the user to either respond with a string value or abort. The user
agent must then pause as the method waits for the
user's response. The second argument is optional. If the second argument
(default) is present, then the response must be
defaulted to the value given by default. If the user
aborts, then the method must return null; otherwise, the method must
return the string that the user responded with.
The print()
method,
when invoked, must run the printing steps.
User agents should also run the printing steps whenever the user attempts to obtain a physical form (e.g. printed copy), or the representation of a physical form (e.g. PDF copy), of a document.
The printing steps are as follows:
The user agent may display a message to the user and/or may abort these steps.
For instance, a kiosk browser could silently ignore any
invocations of the print()
method.
For instance, a browser on a mobile device could detect that there are no printers in the vicinity and display a message saying so before continuing to offer a "save to PDF" option.
The user agent must fire a simple event called
beforeprint
at the Window
object of the browsing context of the
Document
that is being printed, as well as any nested browsing
contexts in it.
The beforeprint
event can be used to annotate the printed copy, for instance adding the
time at which the document was printed.
The user agent should offer the user the opportunity to obtain a physical form (or the representation of a physical form) of the document. The user agent may wait for the user to either accept or decline before returning; if so, the user agent must pause while the method is waiting. Even if the user agent doesn't wait at this point, the user agent must use the state of the relevant documents as they are at this point in the algorithm if and when it eventually creates the alternate form.
The user agent must fire a simple event called
afterprint
at the Window
object of the browsing context of the
Document
that is being printed, as well as any nested browsing
contexts in it.
The afterprint
event
can be used to revert annotations added in the earlier event, as well as
showing post-printing UI. For instance, if a page is walking the user
through the steps of applying for a home loan, the script could
automatically advance to the next step after having printed a form or
other.
The showModalDialog(url,
arguments)
method, when invoked, must cause the user agent to run the following
steps:
If the user agent is configured such that this invocation of showModalDialog()
is somehow
disabled, then the method returns the empty string; abort these steps.
User agents are expected to disable this method in certain cases to avoid user annoyance. For instance, a user agent could require that a site be white-listed before enabling this method, or the user agent could be configured to only allow one modal dialog at a time.
Let the list of background browsing contexts be a list of all the browsing contexts that:
Window
object on which the showModalDialog()
method was called,
and that
showModalDialog()
method at the time
the method was called,...as well as any browsing contexts that are nested inside any of the browsing contexts matching those conditions.
Disable the user interface for all the browsing contexts in the list of background browsing contexts. This should prevent the user from navigating those browsing contexts, causing events to to be sent to those browsing context, or editing any content in those browsing contexts. However, it does not prevent those browsing contexts from receiving events from sources other than the user, from running scripts, from running animations, and so forth.
Create a new auxiliary browsing context,
with the opener browsing context being the
browsing context of the Window
object
on which the showModalDialog()
method was called.
The new auxiliary browsing context has no name.
This browsing context implements the ModalWindow
interface.
Let the dialog arguments of the new browsing context be set to the value of arguments.
Let the dialog arguments' origin be the origin of the script that called the showModalDialog()
method.
Navigate the new browsing context to url, with replacement enabled,
and with the browsing context of the Window
object that is the script execution context of the script that invoked
the method as the source browsing context.
If the script execution context of a
script isn't a Window
object, then it
can't ever get to a Window
object to
call this method.
Wait for the browsing context to be closed. (The user agent must allow the user to indicate that the browsing context is to be closed.)
Reenable the user interface for all the browsing contexts in the list of background browsing contexts.
Return the auxiliary browsing context's return value.
Browsing contexts created by the above algorithm must implement the
ModalWindow
interface:
[XXX] interface ModalWindow { readonly attribute any dialogArguments; attribute DOMString returnValue; };
Such browsing contexts have associated dialog
arguments, which are stored along with the dialog
arguments' origin. These values are set by the showModalDialog()
method in the
algorithm above, when the browsing context is created, based on the
arguments provided to the method.
The dialogArguments
DOM attribute, on getting, must check whether its browsing context's active document's origin is the
same as the dialog arguments' origin. If it is, then the browsing
context's dialog arguments must be returned
unchanged. Otherwise, if the dialog arguments are
an object, then the empty string must be returned, and if the dialog arguments are not an object, then the
stringification of the dialog arguments must be
returned.
These browsing contexts also have an associated return value. The return value of a browsing context must be initialized to the empty string when the browsing context is created.
The returnValue
DOM
attribute, on getting, must return the return value
of its browsing context, and on setting, must set the return value to the given new value.
Notifications are short, transient messages that bring the user's attention to new information, or remind the user of scheduled events.
Since notifications can be annoying if abused, this specification defines a mechanism that scopes notifications to a site's existing rendering area unless the user explicitly indicates that the site can be trusted.
To this end, each origin can be flagged as being a trusted notification source. By default origins should not be flagged as such, but user agents may allow users to whitelist origins or groups of origins as being trusted notification sources. Only origins flagged as trusted in this way are allowed to show notification UI outside of their tab.
For example, a user agent could allow a user to mark all subdomains and ports of example.org as trusted notification sources. Then, mail.example.org and calendar.example.org would both be able to show notifications, without the user having to flag them individually.
The showNotification(title, subtitle, description, onclick)
method, when invoked, must cause the user agent to show a notification.
If the method was invoked from a script whose script execution context's associated browsing context has the sandboxed annoyances browsing context flag set, then the notification must be shown within that browsing context. The notification is said to be a sandboxed notification.
Otherwise, if the origin of the browsing context associated with the script execution context of the script that invoked the method is not flagged as being a trusted notification source, then the notification should be rendered within the top-level browsing context of the browsing context associated with the script execution context of the script that invoked the method. The notification is said to be a normal notification. User agents should provide a way to set the origin's trusted notification source flag from the notification, so that the user can benefit from notifications even when the user agent is not the active application.
Otherwise, the origin is flagged as a trusted notification source, and the notification should be shown using the platform conventions for system-wide notifications. The notification is said to be a trusted notification. User agents may provide a way to unset the origin's trusted notification source flag from within the notification, so as to allow users to easily disable notifications from sites that abuse the privilege.
For example, if a site contains a gadget of a mail application in a
sandboxed iframe
and that frame
triggers a notification upon the receipt of a new e-mail message, that
notification would be displayed on top of the gadget only.
However, if the user then goes to the main site of that mail application, the notification would be displayed over the entire rendering area of the tab for the site.
The notification, in this case, would have a button on it to let the user indicate that he trusts the site. If the user clicked this button, the next notification would use the system-wide notification system, appearing even if the tab for the mail application was buried deep inside a minimised window.
The style of notifications varies from platform to platform. On some, it is typically displayed as a "toast" window that slides in from the bottom right corner. In others, notifications are shown as semi-transparent white-on-grey overlays centered over the screen. Other schemes could include simulated ticker tapes, and speech-synthesis playback.
When a normal notification (but not a sandboxed notification) is shown, the user agent may bring the user's attention to the top-level browsing context of the browsing context associated with the script execution context of the script that invoked the method, if that would be useful; but user agents should not use system-wide notification mechanisms to do so.
When a trusted notification is shown, the user agent should bring the user's attention to the notification and the browsing context associated with the script execution context of the script that invoked the method, as per the platform conventions for attracting the user's attention to applications.
In the case of normal notifications, typically the only attention-grabbing device that would be employed would be something like flashing the tab's caption, or making it bold, or some such.
In addition, in the case of a trusted notification, the entire window could flash, or the browser's application icon could bounce or flash briefly, or a short sound effect could be played.
Notifications should include the following content:
icon
, if any are available.
If a new notification from one browsing context has title, subtitle, and description strings that are identical to the title, subtitle, and description strings of an already-active notification from the same browsing context or another browsing context with the same origin, the user agent should not display the new notification, but should instead add an indicator to the already-active notification that another identical notification would otherwise have been shown.
For instance, if a user has his mail application open in three windows, and thus the same "New Mail" notification is fired three times each time a mail is received, instead of displaying three identical notifications each time, the user agent could just show one, with the title "New Mail x3".
Notifications should have a lifetime based on the platform conventions for notifications. However, the lifetime of a notification should not begin until the user has had the opportunity to see it, so if a notification is spawned for a browsing context that is hidden, it should be shown for its complete lifetime once the user brings that browsing context into view.
User agents should support multiple notifications at once.
User agents should support user interaction with notifications, if and as appropriate given the platform conventions. If a user activates a notification, and the onclick callback argument was present and is not null, then the browsing context associated with the script execution context of the function given by onclick should be brought to the user's attention, and the onclick callback should then be invoked.
The navigator
attribute of the Window
interface must
return an instance of the ClientInformation
interface, which
represents the identity and state of the user agent (the client), and
allows Web pages to register themselves as potential protocol and content
handlers:
interface ClientInformation { readonly attribute boolean onLine; void registerProtocolHandler(in DOMString protocol, in DOMString uri, in DOMString title); void registerContentHandler(in DOMString mimeType, in DOMString uri, in DOMString title); };
The registerProtocolHandler()
method allows Web sites to register themselves as possible handlers for
particular protocols. For example, an online fax service could register
itself as a handler of the fax:
protocol ([RFC2806]), so that if the user clicks on such a
link, he is given the opportunity to use that Web site. Analogously, the
registerContentHandler()
method allows Web sites to register themselves as possible handlers for
content in a particular MIME type. For example, the same online fax
service could register itself as a handler for image/g3fax
files ([RFC1494]), so that if the user has no
native application capable of handling G3 Facsimile byte streams, his Web
browser can instead suggest he use that site to view the image.
User agents may, within the constraints described in this section, do whatever they like when the methods are called. A UA could, for instance, prompt the user and offer the user the opportunity to add the site to a shortlist of handlers, or make the handlers his default, or cancel the request. UAs could provide such a UI through modal UI or through a non-modal transient notification interface. UAs could also simply silently collect the information, providing it only when relevant to the user.
There is an example of how these methods could be presented to the user below.
The arguments to the methods have the following meanings:
registerProtocolHandler()
only)
A scheme, such as ftp
or fax
. The scheme
must be treated case-insensitively by user agents for the purposes of
comparing with the scheme part of URIs that they consider against the
list of registered handlers.
The protocol value, if it contains a colon (as in
"ftp:
"), will never match anything, since schemes don't
contain colons.
registerContentHandler()
only)
A MIME type, such as model/vrml
or
text/richtext
. The MIME type must be treated
case-insensitively by user agents for the purposes of comparing with
MIME types of documents that they consider against the list of
registered handlers.
User agents must compare the given values only to the MIME type/subtype parts of content types, not to the complete type including parameters. Thus, if mimeType values passed to this method include characters such as commas or whitespace, or include MIME parameters, then the handler being registered will never be used.
The URI of the page that will handle the requests. When the user agent
uses this URI, it must replace the first occurrence of the exact literal
string "%s
" with an escaped version of the URI of the
content in question (as defined below), and then fetch the resulting URI
using the GET method (or equivalent for non-HTTP URIs).
To get the escaped version of the URI, first, the domain part of the URI (if any) must be converted to its punycode representation, and then, every character in the URI that is not in the ranges given in the next paragraph must be replaced by its UTF-8 byte representation, each byte being represented by a U+0025 (%) character and two digits in the range U+0030 (0) to U+0039 (9) and U+0041 (A) to U+0046 (F) giving the hexadecimal representation of the byte.
The ranges of characters that must not be escaped are: U+002D (-), U+002E (.), U+0030 (0) to U+0039 (9), U+0041 (A) to U+005A (Z), U+005F (_), U+0061 (a) to U+007A (z), and U+007E (~).
If the user had visited a site that made the following call:
navigator.registerContentHandler('application/x-soup', 'http://example.com/soup?url=%s', 'SoupWeb™')
...and then clicked on a link such as:
<a href="http://www.example.net/chickenkïwi.soup">Download our Chicken Kiwi soup!</a>
...then, assuming this chickenkïwi.soup
file was
served with the MIME type application/x-soup
, the UA might
navigate to the following URI:
http://example.com/soup?url=http%3A%2F%2Fwww.example.net%2Fchickenk%C3%AFwi.soup
This site could then fetch the chickenkïwi.soup
file and do whatever it is that it does with soup (synthesize it and
ship it to the user, or whatever).
A descriptive title of the handler, which the UA might use to remind the user what the site in question is.
User agents should raise security exceptions if the methods are called with protocol or mimeType values that the UA
deems to be "privileged". For example, a site attempting to register a
handler for http
URIs or text/html
content in a
Web browser would likely cause an exception to be raised.
User agents must raise a SYNTAX_ERR
exception if the uri argument passed to one of these methods does not
contain the exact literal string "%s
".
User agents must not raise any other exceptions (other than binding-specific exceptions, such as for an incorrect number of arguments in an ECMAScript implementation).
This section does not define how the pages registered by these methods are used, beyond the requirements on how to process the uri value (see above). To some extent, the processing model for navigating across documents defines some cases where these methods are relevant, but in general UAs may use this information wherever they would otherwise consider handing content to native plugins or helper applications.
UAs must not use registered content handlers to handle content that was returned as part of a non-GET transaction (or rather, as part of any non-idempotent transaction), as the remote site would not be able to fetch the same data.
These mechanisms can introduce a number of concerns, in particular privacy concerns.
Hijacking all Web usage. User agents should not allow
protocols that are key to its normal operation, such as http
or https
, to be rerouted through third-party sites. This
would allow a user's activities to be trivially tracked, and would allow
user information, even in secure connections, to be collected.
Hijacking defaults. It is strongly recommended that user agents do not automatically change any defaults, as this could lead the user to send data to remote hosts that the user is not expecting. New handlers registering themselves should never automatically cause those sites to be used.
Registration spamming. User agents should consider the
possibility that a site will attempt to register a large number of
handlers, possibly from multiple domains (e.g. by redirecting through a
series of pages each on a different domain, and each registering a handler
for video/mpeg
— analogous practices abusing other Web
browser features have been used by pornography Web sites for many years).
User agents should gracefully handle such hostile attempts, protecting the
user.
Misleading titles. User agents should not rely wholly
on the title argument to the methods when presenting
the registered handlers to the user, since sites could easily lie. For
example, a site hostile.example.net
could claim that it was
registering the "Cuddly Bear Happy Content Handler". User agents should
therefore use the handler's domain in any UI along with any title.
Hostile handler metadata. User agents should protect against typical attacks against strings embedded in their interface, for example ensuring that markup or escape characters in such strings are not executed, that null bytes are properly handled, that over-long strings do not cause crashes or buffer overruns, and so forth.
Leaking Intranet URIs. The mechanism described in this section can result in secret Intranet URIs being leaked, in the following manner:
No actual confidential file data is leaked in this manner, but the URIs
themselves could contain confidential information. For example, the URI
could be
https://www.corp.example.com/upcoming-aquisitions/samples.egf
,
which might tell the third party that Example Corporation is intending to
merge with Samples LLC. Implementors might wish to consider allowing
administrators to disable this feature for certain subdomains, content
types, or protocols.
Leaking secure URIs. User agents should not send HTTPS
URIs to third-party sites registered as content handlers, in the same way
that user agents do not send Referer
headers from secure
sites to third-party sites.
Leaking credentials. User agents must never send username or password information in the URIs that are escaped and included sent to the handler sites. User agents may even avoid attempting to pass to Web-based handlers the URIs of resources that are known to require authentication to access, as such sites would be unable to access the resources in question without prompting the user for credentials themselves (a practice that would require the user to know whether to trust the third-party handler, a decision many users are unable to make or even understand).
This section is non-normative.
A simple implementation of this feature for a desktop Web browser might work as follows.
The registerProtocolHandler()
method could display a modal dialog box:
||[ Protocol Handler Registration ]||||||||||||||||||||||||||| | | | This Web page: | | | | Kittens at work | | http://kittens.example.org/ | | | | ...would like permission to handle the protocol "x-meow:" | | using the following Web-based application: | | | | Kittens-at-work displayer | | http://kittens.example.org/?show=%s | | | | Do you trust the administrators of the "kittens.example. | | org" domain? | | | | ( Trust kittens.example.org ) (( Cancel )) | |____________________________________________________________|
...where "Kittens at work" is the title of the page that invoked the
method, "http://kittens.example.org/" is the URI of that page, "x-meow" is
the string that was passed to the registerProtocolHandler()
method as its first argument (protocol),
"http://kittens.example.org/?show=%s" was the second argument (uri), and "Kittens-at-work displayer" was the third
argument (title).
If the user clicks the Cancel button, then nothing further happens. If the user clicks the "Trust" button, then the handler is remembered.
When the user then attempts to fetch a URI that uses the "x-meow:" scheme, then it might display a dialog as follows:
||[ Unknown Protocol ]|||||||||||||||||||||||||||||||||||||||| | | | You have attempted to access: | | | | x-meow:S2l0dGVucyBhcmUgdGhlIGN1dGVzdCE%3D | | | | How would you like FerretBrowser to handle this resource? | | | | (o) Contact the FerretBrowser plugin registry to see if | | there is an official way to handle this resource. | | | | ( ) Pass this URI to a local application: | | [ /no application selected/ ] ( Choose ) | | | | ( ) Pass this URI to the "Kittens-at-work displayer" | | application at "kittens.example.org". | | | | [ ] Always do this for resources using the "x-meow" | | protocol in future. | | | | ( Ok ) (( Cancel )) | |____________________________________________________________|
...where the third option is the one that was primed by the site registering itself earlier.
If the user does select that option, then the browser, in accordance with the requirements described in the previous two sections, will redirect the user to "http://kittens.example.org/?show=x-meow%3AS2l0dGVucyBhcmUgdGhlIGN1dGVzdCE%253D".
The registerContentHandler()
method
would work equivalently, but for unknown MIME types instead of unknown
protocols.


| com.artear.injector.api.JsEventManager |
A JsEventManager is an entity that control the communication between the webview and your javascript events. It is part of divide each responsibility idea. |
| com.artear.injector.api.JsInterface |
Use them to establish a suitable communication between a single javascript event for your web loaded in a webview and an object in your application, making a clean code and a single responsibility. |


List environments are environments that have list-like properties. For instance, the elements of a list environment are ordered and can be accessed and iterated over using index subsetting, e.g. 'x <- listenv(a = 1, b = 2); for (i in seq_along(x)) x[[i]] <- x[[i]] ^ 2; y <- as.list(x)'.
| Version: | 0.7.0 |
| Depends: | R (≥ 3.1.2) |
| Suggests: | R.utils, R.rsp, markdown |
| Published: | 2018-01-21 |
| Author: | Henrik Bengtsson [aut, cre, cph] |
| Maintainer: | Henrik Bengtsson <henrikb at braju.com> |
| BugReports: | https://github.com/HenrikBengtsson/listenv/issues |
| License: | LGPL-2.1 | LGPL-3 [expanded from: LGPL (≥ 2.1)] |
| URL: | https://github.com/HenrikBengtsson/listenv |
| NeedsCompilation: | no |
| Materials: | NEWS |
| CRAN checks: | listenv results |
| Reference manual: | listenv.pdf |
| Vignettes: |
List Environments |
| Package source: | listenv_0.7.0.tar.gz |
| Windows binaries: | r-devel: listenv_0.7.0.zip, r-release: listenv_0.7.0.zip, r-oldrel: listenv_0.7.0.zip |
| OS X binaries: | r-release: listenv_0.7.0.tgz, r-oldrel: listenv_0.7.0.tgz |
| Old sources: | listenv archive |
| Reverse imports: | aroma.affymetrix, aroma.core, future, origami, PSCBS |
| Reverse suggests: | furrr, future.apply, future.BatchJobs, future.batchtools, future.callr |
Please use the canonical form https://CRAN.R-project.org/package=listenv to link to this page.


When using the options.editable
option, this option toggles whether or not cells should automatically go into edit mode when they are clicked selected. If disabled, cells will only become editable on double-click.
(boolean)
: Defaulttrue
.
{autoEdit: false}


Dgame.Graphics.Sprite
- class Sprite: Dgame.Graphics.Transformable.Transformable, Dgame.Graphics.Drawable.Drawable, Dgame.Graphics.Blend.Blendable;
- Sprite represents a drawable object and maintains a texture and his position.
Author:
rschuett
- this();
- CTor
- this(Texture tex);
- CTor
- pure nothrow ref const(Vector2s) calculateCenter();
- Calculate, store and return the center point.
Usefull for e.g. rotate.
- const bool collideWith(const Sprite rhs);
- Check whether the bounding box of this Sprite collide
with the bounding box of another Sprite
- const bool collideWith(ref const ShortRect rect);
- Check whether the bounding box of this Sprite collide
with the given Rect
- const bool collideWith(const ShortRect rect);
- Rvalue version
- const pure nothrow ShortRect getClipRect();
- Returns the current Clip Rect, the area,
where the Sprite lies with the same size as the Sprite.
- final pure nothrow void setBlend(Blend blend);
- Set (or reset) the current Blend instance.
- final inout pure nothrow inout(Blend) getBlend();
- Returns the current Blend instance, or null.
- final const pure nothrow @property ushort width();
- Returns the current width (the width of the current texture).
- final const pure nothrow @property ushort height();
- Returns the current height (the height of the current texture).
- final const pure nothrow bool hasTexture();
- Check if the current Sprite has already a Texture/Image.
If not, nothing can be drawn.
But it does not check if the current Texture is valid.
- final void setTexture(Texture tex);
- Set or replace the current Texture.
- final inout pure nothrow inout(Texture) getTexture();
- Returns the current Texture or null if there is none.
Page generated by Ddoc.


HTML 5 DEMO
I'm Editable Caption, Just Click On For Magic
Your Name
Email
Mobile Number
Address
Gender
Male
Female
Date of birth
Select City
Select your city
Rajkot
Ahmedabad
Surat
Select your subject
Maths
Physics
Chemistry
English
Password
Submit


The script operation is defined as the first argument passed. In all of the following examples it is alpha
.
./script.example.sh alpha bravo charlie
./script.example.sh -f alpha
./script.example.sh --test alpha -f
If no argument is passed then the YAML configuration file may define a default operation like this:
default_command: get
If the configuration file is as above, then these two are identical:
$ ./script.example.sh
$ ./script.example.sh get
Somewhat related to the default command is assume_command
. It is used in a case where you want to insert (assume) a command that is not typed. For example, if you want your users to type, ./script.example.sh <arg>
instead of ./script.example.sh <command> <arg>
, you should use assume_command
in your config, which will cause the command to be inserted. Any command that is registered will be respected as you would expect, but if the immediate first script argument is not registered as a command, then the assume_command
will be used as if it had been typed. This effectively inserts the assume_command
value between the script name and the first argument.
assume_command get
When configured as show above, the following are the same (so long as file
is not registered as a command).
$ ./script.example.sh file file2
$ ./script.example.sh get file file2
get_command
get_config "default_command"


--- permalink: 404.html layout: default title: "404" id: "not-found" ---
GET. ME. [[index|THE FUCK.]] OUT. OF. HERE.


{% with messages = get_flashed_messages() %} {% if messages %}
{% for message in messages %}
{{ message }}
{% endfor %}
{% endif %} {% endwith %}
Your wiki has been created. Yay!
Log in to your wiki using username
admin
and password
headstrong
. You should immediately log in and change the password. Do it NOW :-)


The former repository of ChatScript was at https://github.com/bwilcox-1234/ChatScript, however, I lost access to this repository (2 factor authentication lost that I didn’t want in the first place and I could not convince github to restore my access). So it is no longer maintained. But the global user ChatScript became available, and is a better name anyway.
Natural Language tool/dialog manager
ChatScript is the next generation chatbot engine that has won the Loebner’s 4 times and is the basis for natural language company for a variety of tech startups.
ChatScript is a rule-based engine, where rules are created by humans writers in program scripts through a process called dialog flow scripting. These use a scripting metalanguage (simply called a “script”) as their source code. Here what a ChatScript script file looks like:
#
# file: food.top
#
topic: ~food []
#! I like spinach
s: ( I like spinach ) Are you a fan of the Popeye cartoons?
a: ( ~yes ) I used to watch him as a child. Did you lust after Olive Oyl?
b: ( ~no ) Me neither. She was too skinny.
b: ( yes ) You probably like skinny models.
a: ( ~no ) What cartoons do you watch?
b: ( none ) You lead a deprived life.
b: ( Mickey Mouse ) The Disney icon.
#! I often eat chicken
u: ( ![ not never rarely ] I * ~ingest * ~meat ) You eat meat.
#! I really love chicken
u: ( !~negativeWords I * ~like * ~meat ) You like meat.
#! do you eat bacon?
?: ( do you eat _ [ ham eggs bacon] ) I eat '_0
#! do you like eggs or sushi?
?: ( do you like _* or _* ) I don't like '_0 so I guess that means I prefer '_1.
#!
#! I eat fish.
s: ( I eat _*1 > )
$food = '_0
I eat oysters.
Above example mentioned in article How to build your first chatbot using ChatScript.
Take this project and put it into some directory on your machine (typically we call the directory ChatScript, but you can name it whatever). That takes care of installation.
git clone https://github.com/ChatScript/ChatScript
From your ChatScript home directory, go to the BINARIES directory:
cd BINARIES
And run the ChatScript engine
ChatScript
./LinuxChatScript64 local
Note: to set the file executable:
chmod a+x ./LinuxChatScript64
./MacChatScript local
This will cause ChatScript to load and ask you for a username. Enter
whatever you want. You are then talking to the default demo bot
Harry
.
From your ChatScript home directory, go to the BINARIES directory and run the ChatScript engine as server ### Run the server on Windows
ChatScript port=1024
./LinuxChatScript64
./MacChatScript
This will cause ChatScript to load as a server.
But you also need a client (to test client-server communication). You
can run a separate command window and go to the BINARIES directory and
type
ChatScript client=localhost:1024
./LinuxChatScript64 client=localhost:1024
./MacChatScript client=localhost:1024
This will cause ChatScript to load as a client and you can talk to the server.
Run ChatScript locally. From the ChatScript command prompt, type
:build Harry
or whatever other preinstalled bot exists. If you have revised basic data, you can first:
:build 0
On windows if you have Visual Studio installed, launch
VS2010/chatscript.sln
or VS2015/chatscript.sln
and do a build. The result will go in the BINARIES
directory.
On Linux, go stand in the SRC directory and type
make server
(assuming you have make and g++ installed).
This creates BINARIES/ChatScript, which can run as a server or locally.
There are other make choices for installing PostGres or Mongo.
The Dockerfile
in this repository provides a ChatScript
server with no bots. To build and run it, run the following
commands:
docker build -t chatscript .
docker run -it -p 1024:1024 chatscript
Note: You will probably want to replace the image tag
chatscript
with a more meaningful one for your
purposes.
Adding bot data to the base image above is as simple as writing a
Dockerfile
like the following one, which builds the
Harry
bot:
FROM chatscript
# Copy raw data needed for Harry
COPY ./RAWDATA/filesHarry.txt
COPY ./RAWDATA/HARRY /opt/ChatScript/RAWDATA/HARRY
COPY ./RAWDATA/QUIBBLE /opt/ChatScript/RAWDATA/QUIBBLE
# Build Harry
RUN /opt/ChatScript/BINARIES/LinuxChatScript64 local build1=filesHarry.txt
This Dockerfile
can then be built and run in the same
manner as the base chatscript
image:
docker build -t chatscript-harry .
docker run -it chatscript-harry local
ChatScript Wiki (user guides, tutorials, papers)


mice influenza virus Rb. LPS administration infected {border-style (Fig. infection response animals blood px;} serum #ffffff;} level Fig. IL- production (HN) dose weight day antibodies IFN-β TCID cells []. cytokines mouse viral TLR induction IgGa animals. experiment experiment. immune levels A/Hamburg/ IL-, IgG antibody control groups increased mice, px; synthesis used virus, {font-family LPS, Mice compared condition cytokine font-size group pro-inflammatory significantly strain survival TNF-α caused determined double; effect end factors influenza-infected injected significant strains using various < (day ELISA additional anti-inflammatory antiviral border-color border-width capsulatus changes days doses healthy increase infection, innate lipopolysaccharide mice. promotes regardless shown solid; survived titer viruses {font-style {font-weight Additional Hamburg/ IFN-γ IFN-γ, Rhodobacter TLR, TNF-α, [], affect bold cell courier; did divided em; enhanced findings following half high higher inflammation molecular platinum pt;} receptors showed simultaneously


Brennan posted a blog entry about the Firefox 2.0 beta release a couple of days ago that talks about a lot of the new features in the next Firefox release. This version seems to be an evolutionary release and not a revolutionary one. A lot of work has gone on in the internals of the code, and there are quite a few new developer fatures in this release, but there are still some really cool user centric features as well. Brennan talks a lot about the user features, so check them out. For more info, also look at the new features for end users that Mozilla provides.
I really want to look at some of the new features of Javascript though.
Javascript 1.7 is picking up a lot of new features that more popular scripting langauges have such as Ruby and Python. I've drawn comparison to Javascript and Ruby before and a number of the new features in Javascript 1.7 only give them more feature parity.
yield
keyword. Yield allows
you leave a method of code and have the state of the method saved at that
point. When the method is called again, the last state of the code is resumed
(or continued) from the state of the last time the method was called. This is
often used for Iterators (another new feature). It can also be used to
implement things like Continuations which can
be used to create state machines and parsers.
Iterator
object. While previous versions of Javascript
have allowed you to iterate over Array's and the like using for...each
, the Iterator allows you to build
your own Iterator to iterate over any object that you create.
var myArray = [ "Cool " + i for (i in range(0, 10))];
let
allows you to define an explicit scope of a
variable. Just like var
makes a
variable so that it is not globally scoped, let
narrows the scope to a defined block. This allows you to
redefine the value of a var
(or
another let
) variable to a more
limited section of code, temporarily changing the value without
effecting the value outside of that defined block.
Lots of fun new features plucked from the best scripting and programming languages out there. The future looks bright for web client-side development. (Of course IE won't support this stuff for 10 years probably.)