Various improvements to doc. Thanks to @akauppi for the feedback.

doc/calling-javascript.md

@@ -11,8 +11,7 @@ direction of interoperability.
 
 Because JavaScript is dynamically typed, it is possible to call JS libraries in
 a dynamically typed way. However, it is also possible to interop with static
-types, for better leveraging of Scala. The former actually builds on top of the
-latter.
+types, for better leveraging of Scala.
 
 ## Primitive JavaScript types
 
@@ -197,7 +196,7 @@ var x = f.call(o, 4);
 
 ## Defining JavaScript interfaces with traits
 
-Most JavaScript APIs work with interfaces, that are defined structurally. In
+Most JavaScript APIs work with interfaces that are defined structurally. In
 Scala.js, the corresponding concept are traits. To mark a trait as being a
 representative of a JavaScript API, it must inherit directly or indirectly
 from `js.Object`.
@@ -233,11 +232,7 @@ if the result will always be the same (e.g., `document`), and `def` when
 subsequent accesses to the field might return a different value (e.g.,
 `innerWidth`).
 
-Use Scala primitive types instead of types in `js.prim._`. Instead of
-`js.prim.Number`, use `Int` where applicable (integral value, not
-`NaN`, in signed 32-bit integer range). Otherwise `Double` should be
-used (note that `Long` is opaque to JavaScript and therefore cannot be
-used).
+Use Scala primitive types instead of types in `js.prim._`. Use `Byte`, `Short` or `Int` where applicable (attention: `NaN` is not a value of any of these types). Otherwise `Double` should be used. `Long` is opaque to JavaScript and therefore cannot be used. `Float` is the same as `Double` and should generally not be used in JavaScript typings.
 
 Calls to the `apply` method of an object `x` map to calling `x`, i.e., `x(...)`
 instead of `x.apply(...)`.
@@ -248,7 +243,7 @@ is omitted entirely (or set to `undefined`). The value is only indicative, as
 implicit documentation.
 
 Methods can be overloaded. This is useful to type accurately some APIs that
-behave differently depending of the number or types of arguments.
+behave differently depending on the number or types of arguments.
 
 JS traits and their methods can have type parameters, abstract type members
 and type aliases, without restriction compared to Scala's type system.
@@ -284,7 +279,7 @@ def value(): js.String
 def value(v: js.String): this.type
 {% endhighlight %}
 
-If necessary, several overloads a method with the same name can have different
+If necessary, several overloads of a method with the same name can have different
 `@JSName`'s. Conversely, several methods with different names in Scala can have
 the same `@JSName`.
 
@@ -398,10 +393,10 @@ package object js extends js.GlobalScope {
 ## Monkey patching
 
 In JavaScript, a common pattern is monkey patching, where some top-level
-object, or class' prototype, is meant to be extended by third-party code. This
+object or class' prototype, is meant to be extended by third-party code. This
 pattern is easily encoded in Scala.js' type system with `implicit` conversions.
 
-E.g., in jQuery, `$.fn` can be extended with new methods, that will be
+E.g., in jQuery, `$.fn` can be extended with new methods that will be
 available to so-called jQuery objects, of type `JQuery`. Such a plugin can be
 declared in Scala.js with a separate trait, say `JQueryGreenify`, and an
 implicit conversions from `JQuery` to `JQueryGreenify`.
@@ -430,7 +425,7 @@ to avoid reflective calls altogether.
 ### What is a reflective call?
 Calling a method on a structural type in Scala creates a so-called
 reflective call. A reflective call is a type-safe method call that
-uses Java reflection at runtime. The following is an example for a
+uses Java reflection at runtime. The following is an example of a
 reflective call:
 
 {% highlight scala %}
@@ -473,7 +468,7 @@ reflective call can therefore not be generated.
 Because JavaScript is dynamically typed, it is not often practical, sometimes
 impossible, to give sensible type definitions for JavaScript APIs.
 
-Scala.js lets you call JavaScript call in a dynamically typed fashion if you
+Scala.js lets you call JavaScript in a dynamically typed fashion if you
 want to. The basic entry point is to grab a dynamically typed reference to the
 global scope, with `js.Dynamic.global`, which is of type `js.Dynamic`.
 
@@ -497,7 +492,7 @@ playground.appendChild(newP)
 {% endhighlight %}
 
 In this example, `document`, `playground` and `newP` are all inferred to be of
-type `js.Dynamic`. When calling `getElementById` of assigning to the field
+type `js.Dynamic`. When calling `getElementById` or assigning to the field
 `innerHTML`, the String is implicitly converted to a `js.String` to conform to
 `js.Any`.
 

doc/js-interoperability.md

@@ -6,7 +6,7 @@ title: JavaScript interoperability
 
 A key feature of Scala.js is its interoperability with JavaScript code, which
 far exceeds that of many other languages targeting JavaScript. Except of course
-for languages that translate almost litterally to JavaScript (e.g.,
+for languages that translate almost literally to JavaScript (e.g.,
 [TypeScript](http://www.typescriptlang.org/) and
 [CoffeeScript](http://coffeescript.org/)).
 

doc/sbt/cross-building.md

@@ -45,3 +45,19 @@ You now have separate projects to compile towards Scala.js and Scala JVM. Note t
 - `foo_sjs0.5.0-RC2_2.10-0.1-SNAPSHOT.jar`
 
 If you do not publish the artifacts, you may choose different names for the projects.
+
+## Dependencies
+
+If your cross compiled source depends on libraries, you will have to add the dependencies on the libraries separately for each project (using the `%%%` for the Scala.js project). For example, if your code uses [Scalatags](http://github.com/lihaoyi/scalatags), your project definitions look like this:
+
+ lazy val fooJS = project.in(file("foo-js")).settings(scalaJSSettings: _*).settings(
+ name := "foo",
+ unmanagedSourceDirectories in Compile += root.base / "foo-shared" / "src" / "main" / "scala",
+ libraryDependencies += "com.scalatags" %%% "scalatags" % "0.3.5"
+ )
+
+ lazy val fooJVM = project.in(file("foo-jvm")).settings(
+ name := "foo",
+ unmanagedSourceDirectories in Compile += root.base / "foo-shared" / "src" / "main" / "scala",
+ libraryDependencies += "com.scalatags" %% "scalatags" % "0.3.5"
+ )

doc/sbt/run.md

@@ -15,15 +15,17 @@ You now can run your application already by using the `run` task:
 
  sbt> run
 
-This will detect and run classes that extend `scala.scalajs.js.JSApp`, while optionally prompting the user to choose a class if multiple such classes exist. To run the `.sjsir` files, we invoke the Rhino JavaScript interpreter with a special scope that lazily reads and loads required `.sjsir` files on the fly (much like Java class loading). Note that by default, this environment doesn't have a DOM. If you need it set `requiresDOM := true` in your settings.
+This will detect and run classes that extend `scala.scalajs.js.JSApp`, while optionally prompting the user to choose a class if multiple such classes exist (fails with multiple classes if `persistLauncher := true`, see section below for details).
+
+To run the `.sjsir` files, we invoke the Rhino JavaScript interpreter with a special scope that lazily reads and loads required `.sjsir` files on the fly (much like Java class loading). Note that by default, this environment doesn't have a DOM. If you need it set `requiresDOM := true` in your settings.
 
 ## Fast-Optimize
 
 To produce a proper JavaScript file from your code, you need to call the linker:
 
  sbt> fastOptJS
 
-This will perform a coarse dead-code elimination and write all remaining code to a single JavaScript file. You can now use this JavaScript file in your HTML-page or in whatever way you like. The resulting file in the target folder will have the suffix `-fastopt.js`.
+This will perform a coarse dead-code elimination and write all remaining code to a single JavaScript file. You can now use this JavaScript file in your HTML page or in whatever way you like. The resulting file in the target folder will have the suffix `-fastopt.js`.
 
 If you want to run this code, you can tell sbt to run after the linking stage:
 

doc/sbt/setup.md

@@ -3,7 +3,7 @@ layout: page
 title: Scala.js sbt Setup
 ---
 
-Load the sbt plugin (`project/build.sbt`)
+Load the sbt plugin (`project/plugins.sbt`)
 
  addSbtPlugin("org.scala-lang.modules.scalajs" % "scalajs-sbt-plugin" % "0.5.0")
 

doc/tutorial.md

@@ -285,6 +285,8 @@ In your `build.sbt`, set:
 
  skip in ScalaJSKeys.packageJSDependencies := false
 
+As an alternative to prefixing with `ScalaJSKeys`, you may import all its members (`import ScalaJSKeys._`). Most of the documentation omits the `ScalaJSKeys` prefix for brevity.
+
 After reloading and rerunning `fastOptJS`, this will create `scala-js-tutorial-jsdeps.js` containing all JavaScript libraries next to the main JavaScript file. We can then simply include this file and don't need to worry about JavaScript libraries anymore:
 
 {% highlight html %}