Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 21 additions & 13 deletions index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -157,22 +157,30 @@ The following is an informative summary of the format specifiers processed by th
</tr>
</table>

<h3 id="printer" aoid="Printer" nothrow>Printer(<var>logLevel</var>, <var>args</var>)</h3>
<h3 id="printer" aoid="Printer" nothrow>Printer(<var>logLevel</var>, <var>args</var> [<var>, options</var>])</h3>

The printer operation is implementation-defined. It accepts a log level indicating severity, and a
List of arguments to print (which are either JavaScript objects, of any type, or are
implementation-specific representations of printable things such as a stack trace, a <a>group</a>,
or objects with either <a>generic JavaScript object formatting</a> or
<a>optimally useful formatting</a> applied). How the implementation prints <var>args</var> is up to
the implementation, but implementations should separate the objects by a space or something
similar, as that has become a developer expectation.
The printer operation is implementation-defined. It accepts a log level indicating severity, a List
of arguments to print, and an optional object of implementation-specific formatting options.
Elements appearing in <var>args</var> will be one of the following:

- JavaScript objects of any type.
- Implementation-specific representations of printable things such as a stack trace or
<a>group</a>.
- Objects with either <a>generic JavaScript object formatting</a> or
<a>optimally useful formatting</a> applied.

If the <var>options</var> object is passed, and is not undefined or null, implementations may use
<var>options</var> to apply implementation-specific formatting to the elements in <var>args</var>.

How the implementation prints <var>args</var> is up to the implementation, but implementations
should separate the objects by a space or something similar, as that has become a developer
expectation.

By the time the printer operation is called, all format specifiers will have been taken into
account, and any arguments that are meant to be consumed by format specifiers will not be present
in <var>args</var>. The implementation's job is simply to print the List. The output produced by
calls to Printer should appear only within the last <a>group</a> on the appropriate
<a>group stack</a> if the <a>group stack</a> is not empty, or in the elsewhere in the console
otherwise.
<a>group stack</a> if the <a>group stack</a> is not empty, or elsewhere in the console otherwise.

If the console is not open when the printer operation is called,
implementations should buffer messages to show them in the future up to an
Expand Down Expand Up @@ -241,7 +249,7 @@ namespace console { // but see namespace object requirements below
void table(any tabularData, optional sequence&lt;DOMString> properties);
void trace(any... data);
void warn(any... data);
void dir(any item);
void dir(any item, optional object? options);
void dirxml(any... data);

// Grouping
Expand Down Expand Up @@ -344,11 +352,11 @@ back to just logging the argument if it can't be parsed as tabular.

Perform Logger("warn", <var>data</var>).

<h4 id="dir" method for="console">dir(<var>item</var>)</h4>
<h4 id="dir" method for="console">dir(<var>item</var>, <var>options</var>)</h4>

<emu-alg>
1. Let _object_ be _item_ with <a>generic JavaScript object formatting</a> applied.
1. Perform Printer("log", «_object_»).
1. Perform Printer("log", «_object_», _options_).
</emu-alg>

<h4 id="dirxml" method for="console">dirxml(...<var>data</var>)</h4>
Expand Down