Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a general fragment identifier handler #5599

Closed
AlbertHilb opened this issue Nov 7, 2018 · 4 comments
Closed

Add a general fragment identifier handler #5599

AlbertHilb opened this issue Nov 7, 2018 · 4 comments

Comments

@AlbertHilb
Copy link
Member

@AlbertHilb AlbertHilb commented Nov 7, 2018

The interpretation of a fragment identifier - the last part of an URL, introduced by a hash mark - depends on the mimetype of the documents the URL points to.

For a text/html document the fragment refers to the id of the page element should be set into view by the browser.

application/pdf MIME allows a number of different fragment identifiers types: #page=n to display the page n, #nameddest=id similar to HTML anchors, #search=word1 word2 to highlight search terms, #zoom=x to set zoom level, etc.

The fragment of text/csv documents works as a selector for columns, rows, cells using row, col and cell keywords.

At moment jupyterlab is able to handle only HTML fragment idenfiers.
However, it would be handy, for example, to have the possibility of opening a (PDF) book exactly on the page you want, clicking on a link.

So we should add a more general mechanism to deal with fragment identifiers.

A possible design is this.

  • Add a new method to IDocumentWidget interface:

    setFragment(fragment: string): void
    

    or something more general, let's say:

    setViewOption(key: string, value: any): void
    
  • In the default implementation of that interface, DocumentWidget, put setFragment (or setViewOption) as no-op.

  • In MimeDocument overwrite the base setFragment (or setViewOption) and call the homonymous method on its MimeContent.

  • When MimeContent.setFragment is called run _render method adding fragment info to the metadata object of the MimeModel passed to renderModel.

  • In the handleLink command, after the document widget is revealed call setFragment (or setViewOption).

If there is agreement on that design I can submit a PR.

Cheers

@AlbertHilb
Copy link
Member Author

@AlbertHilb AlbertHilb commented Nov 7, 2018

@meeseeksdev tag "type:Enhancement"

@AlbertHilb AlbertHilb changed the title Add a general fragment identifier handler. Add a general fragment identifier handler Nov 7, 2018
@AlbertHilb
Copy link
Member Author

@AlbertHilb AlbertHilb commented Nov 7, 2018

xref: #4190

@ian-r-rose
Copy link
Member

@ian-r-rose ian-r-rose commented Nov 12, 2018

I think this is a nice idea @AlbertHilb. My main concern is that I don't think we should rely too much on undocumented, un-spec'ed behavior in various mimetypes. For instance, the application/pdf mimetype is not official, as far as I know, and any behavior of fragments is an implementation choice. Do the PDF viewers in Chrome, Edge, PDF.js, etc implement the same (or similar) behavior?

I think your overall strategy sounds reasonable, but I'd like to hew as closely as possible to open standards as possible.

@ian-r-rose
Copy link
Member

@ian-r-rose ian-r-rose commented Nov 12, 2018

Looks like I was off base about PDF fragments: they are described in the IETF documentation: https://tools.ietf.org/html/rfc8118#page-3

See also CSV: https://tools.ietf.org/html/rfc7111

So, I think this is a great idea @AlbertHilb! Your first idea of setFragment sounds good to me, since we are pretty tied to the concept of URI here.

@jasongrout jasongrout added this to the Future milestone Nov 12, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Aug 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants