How to render primitives with the "%o" specifier

[fflorent]

The spec says:

Specifier	Description
%o	Formats the value as an expandable DOM Element (or JavaScript Object if it is not)

But is that relevant to display the properties of a primitive?

FWIW, Firebug and the Chrome DevTools print the representations of the primitives rather an object view:

Same question for the "%O" specifier, BTW. Currently, the only implementation (AFAIK) that follows the spec is the Chrome DevTools and seem to display the primitives with an expand icon (though they don't show any properties).

Thoughts?

Florent

[andysterland]

I think in general it would be great to not specify how the UI of a console.* API should function. As a tool vendor having flexibility in how developers interact with the tool is awesome as it allows more creativity. There could be other visualizations of data than a tree that might be more appropriate. For me the key thing for the console spec is to specify the contract with the page rather than the contract between the tool and the developer.

Over in IE land we haven't yet implemented %o but essentially have it working by the virtue that IE/VS console log all the parameters passed into console.log() as inspectable objects.

[bkardell]

Is the problem really the word "expandable"? I mean, documenting and agreeing on format specifiers and their basic meaning does seem key to me. As a developer I may care about seeing the object nature or the element nature of something - different tools could make that expandable or tree view or treetable or lots of things, but I do think I want to express 'this is the data I'm interested in', no?

[andysterland]

I guess I'm mainly viewing the spec as the contract between the console.* and the developer. Not between the tool, page and the developer.

So, I think it's the idea in general as the one sentence implies two things for the console UI:

1. It has an expandable tree viewer (which assumes some more general things about the UI - like that it exists)
2. It can distinguish between DOM elements and JavaScript objects

I think documenting what the expected object type for %o which is an object is the key point. That tells me as a tool developer that the (web) developer wants it to be treated as an object. Which in many implementations might mean a tree view.

After all in some scenarios it might be different. For example in IE if you were to log the object before the tools were open (and had console logging always on) we would serialize the entire message as a string. That way we don't have to keep the object alive for inspection or store enough data to enable a tree view. In IE10 of the tools we didn't have a tree view so instead had a "Add watch" button to the end of the console view which would add a watch in the debugger that was expandable. Or another example of a different UI is for logging. Internally we have some tools that record the console messages (as strings) to file which is compared later on and folk use that in various automated testing scenarios.

Basically there's lots of awesome to be had from console.log and it's fine to have example visualizations but developers expectations of what they see in the tool should be set by the tool.

[fflorent]

Is the problem really the word "expandable"?

I understand "expandable" as "in detailed view mode". We don't have any details to offer for primitives, and that's my point.

Also maybe Andy has made a good point with this argument:

For me the key thing for the console spec is to specify the contract with the page rather than the contract between the tool and the developer.

Is that something we should explain in the spec?

Florent