1865480 - Rename nsIContentViewer to nsIDocumentViewer

Status: RESOLVED FIXED

(Core :: DOM: Navigation, task)

Comment 1

[Jonathan Watt [:jwatt]]

Attachment: Bug 1865480. Rename nsIContentViewer to nsIDocumentViewer. r=dholbert

Comment 2

[Daniel Holbert [:dholbert]]

Not objecting, but I'm just curious: could you briefly explain the reasoning behind the rename here?

I don't interact with the nsIContentViewer interface super-often so I don't have a lot of intuition on why either name is better. But the rename does make some intuitive sense, since this does seem to live closer to the granularity of a "document" than a "content" (which is a bit of an overloaded term), and it's definitely closer to the granularity of a nsIDocument than a nsIContent. So the rename makes sense from that perspective. But I'm curious if this is just following that particular intuition, or if there's more behind this than that.

(I'm also curious to what extent there was careful reasoning behind the current nsIContentViewer name, but I haven't researched that yet, and perhaps the original reasoning is lost to time/CVS and/or not relevant these days.)

Also, this probably wants sign-off from a DOM peer or someone closer to this interface than myself (at least, agreeing in spirit with the rename; they don't necessarily need to review the details; I'm happy to do that part with a skim through the patch).

Comment 3

[Jonathan Watt [:jwatt]]

(In reply to Daniel Holbert [:dholbert] from comment #2)

Not objecting, but I'm just curious: could you briefly explain the reasoning behind the rename here?

I don't interact with the nsIContentViewer interface super-often so I don't have a lot of intuition on why either name is better. But the rename does make some intuitive sense, since this does seem to live closer to the granularity of a "document" than a "content" (which is a bit of an overloaded term), and it's definitely closer to the granularity of a nsIDocument than a nsIContent. So the rename makes sense from that perspective. But I'm curious if this is just following that particular intuition, or if there's more behind this than that.

Exactly this. "Content" is far too broad a term given that it is very specifically related to a document only. It has long bugged me that it makes the many places in the code where we use the term "content viewer" more difficult to intuit for new people than it needs to be. Just scratching that itch over the weekend.

(I'm also curious to what extent there was careful reasoning behind the current nsIContentViewer name, but I haven't researched that yet, and perhaps the original reasoning is lost to time/CVS and/or not relevant these days.)

I believe from memory the thinking was that at some point we may wish to extend viewing to fragments of documents. A couple of decades later and we've never done that, and since it's pretty document specific now it seems like we should acknowledge that.

Also, this probably wants sign-off from a DOM peer or someone closer to this interface than myself (at least, agreeing in spirit with the rename; they don't necessarily need to review the details; I'm happy to do that part with a skim through the patch).

Sure thing.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/14c89d004e06
Rename nsIContentViewer to nsIDocumentViewer. r=layout-reviewers,emilio

Comment 5

[Jonathan Watt [:jwatt]]

(In reply to Daniel Holbert [:dholbert] from comment #2)

(I'm also curious to what extent there was careful reasoning behind the current nsIContentViewer name, but I haven't researched that yet, and perhaps the original reasoning is lost to time/CVS and/or not relevant these days.)

Bug 540433 comment 1 has better background on the nsIContentViewer/nsIDocumentViewer split:

(In reply to Boris Zbarsky [:bzbarsky] from Bug 540433 comment #1)

I think the theory was that we could have non-document viewers (e.g.
for plug-ins or images PDFs or whatnot), but I think that's a silly theory.
We should just keep using synthetic documents.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Watt [:jwatt] from comment #5)

Bug 540433 comment 1 has better background on the nsIContentViewer/nsIDocumentViewer split:

Thanks for digging that up!

Comment 7

[Daniel Holbert [:dholbert]]

(this also probably doesn't really belong in Printing; searchfox suggests "File a bug in Core:: DOM: Navigation for the nsIContentViewer interface , so let's use that component.)

Comment 8

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/14c89d004e06