Website for stdlib, a standard library for JavaScript and Node.js.
Home Page: https://stdlib.io
License: Apache License 2.0
Website for stdlib, a standard library for JavaScript and Node.js.
Stdlib is a standard library for JavaScript and Node.js, with an emphasis on numerical and scientific computing. The library provides a collection of robust, high performance libraries for mathematics, statistics, streams, utilities, and more. This is the GitHub repository for the stdlib website.
For information on how to develop stdlib, see the main project repository.
See LICENSE.
Copyright © 2016-2023. The Stdlib Authors.
The landing/welcome page links to documentation pages should use <Link> elements to allow navigation within the SPA.
Currently, when clicking on a documentation page, the application reloads.
This RFC proposes to add support for filtering the side menu according to published individual package name (e.g., @stdlib/math/base/special/sin => @stdlib/math-base-special-sin).
Currently, a user can filter according to the main project name, but not the equivalent individual package name.
No.
No.
No.
RFC:.Please ensure the following tasks are completed before submitting a feature request.
RFC:.Description of the feature request.
This RFC proposes to place TypeScript docs under a similar URL versioning scheme as the API docs. Currently, the TS docs are under docs/ts without being versioned.
Does this feature request have any related issues?
No.
Any questions for reviewers?
No.
Any other information relevant to this feature request? This may include screenshots, references, sample output, and/or implementation notes.
No.
This RFC proposes adding a help modal/popover for how to use the side menu filter.
Currently, the side menu filter supports regular expression queries, but this is not obvious to a user. We should add support for displaying a how-to guide with example search queries.
No.
No.
No.
RFC:.Please ensure the following tasks are completed before submitting a feature request.
RFC:.Description of the feature request.
This RFC proposes to allow API docs users to directly navigate from a package's API docs to its corresponding TypeScript declarations, as hosted on the website, should they exist.
Currently, we use typedoc to generate TypeScript HTML docs, and, because of project conventions (e.g., consistent use of ./docs/types for storing declaration files), the package slugs are consistent:
https://stdlib.io/docs/ts/modules/_assert_is_anagram_docs_types_index_d_.html
In which case, we should be able to predictably resolve a API docs package to its corresponding declaration URL.
As for the API docs package top navigation element, possibly the menu item should be "TypeScript" (alongside "Tests" and "Benchmarks" and "Source"), maybe after "Source"?
As for determining whether declaration files exist, we'll probably want to modify asset database script (https://github.com/stdlib-js/www/blob/master/tools/scripts/build_api_docs_asset_database.js) to check for TypeScript docs. The one caveat being that, as with the bundles, we'll need to make sure that the TypeScript docs have been generated just prior (or are the "latest") so that the asset database does not drift from the actual available docs.
Does this feature request have any related issues?
No.
Any questions for reviewers?
No.
Any other information relevant to this feature request? This may include screenshots, references, sample output, and/or implementation notes.
No.
This RFC proposes adding a "See Also" section to package READMEs.
In order to get a list of related packages, we will need to extract this info from the namespace database, similar to how we populate repl.txt files during the REPL documentation build process.
No.
No.
No.
RFC:.Encountered an error when attempting to close the settings menu by clicking on the close menu button. The hover state indicates that the button is active and clicking triggers a ripple effect, but the menu does not close. This is likely due to the listener being set on the wrong element.
None.
No.
No response
- open the settings menu.
- try closing the menu without explicitly clicking on the `x` icon.The menu should close.The close button ripples, but does not close.Firefox, Chrome, Safari, Microsoft Edge, Internet Explorer, Other Browser
No response
No response
No response
Encountered an error when hovering over top-navigation icons. They are oblong, rather than circular. This change likely happened during the migration from Material UI to Mui v5.
None.
No.
No response
- hover over top-navigation icons.The hover backgrounds should be circular.The hover backgrounds are oblong.Firefox, Chrome, Safari, Microsoft Edge, Internet Explorer, Other Browser
No response
No response
No response
Please ensure the following tasks are completed before filing a bug report.
Description of the issue.
Encountered an error when clearing the filter in the side menu. When filtering, the menu automatically expands to highlight those packages which match the filter. However, on clearing the menu, the filter remains expanded.
Preferably, we'd return the menu to its previous unfiltered state (presumably a mixture of collapsed/uncollapsed based on prior user behavior). Otherwise, can be fully collapsed (i.e., the menu resets).
Does this issue have any related issues?
No.
Any questions for reviewers?
No.
Any other information relevant to this issue? This may include screenshots, references, stack traces, sample output, and/or implementation notes.
If relevant, provide a link to a live demo.
For a live demo of the issue, see
What steps are required to reproduce the unexpected output?
In order to reproduce this bug, do the following:
What are the expected results?
The following results are expected:
What are the actual results?
The following are the actual results:
What environments are affected (e.g.,
Node v0.4.x,Chrome,IE 11)? If Node.js, include thenpmversion, operating system, and any other potentially relevant platform information.
The following environments are affected:
Encountered an error when navigating to a new API docs page.
When I click on a navigation element (e.g., clicking on a link to navigate to the "next" package), the focus stays on the navigation element. This means that, for those with screen readers, they are unable to begin tabbing through the new page's content. Instead, hitting TAB picks up where they left off on the previous page.
The preferred approach here is that we reset the focus to the top of the page to the skip-link so that users can either TAB through navigation or skip to the main content.
No.
No.
N/A
- navigate to a package on the API docs website.
- use a navigational element to navigate to a new package.
- notice that the focus does not reset.- the focus should reset.- the focus remains on the previously focused element (where applicable).Firefox, Chrome, Safari, Microsoft Edge, Internet Explorer
No response
No response
No response
Encountered an error when adjusting the font-size for the <body> in the inspector. Upon doing so, most text scaled as expected. However, various elements have fixed font-size leading to an odd patchwork of things which were visually off. A screenshot is shown below:
The following elements need to be updated in order to better accommodate users who wish to globally modify the base application font size:
Apart from the code blocks, some of this can be attributed to our use of Mui components which attempt to independently manage font-sizing.
None.
No.
N/A
- navigate to the website.
- open the inspector.
- adjust the body font-size to, say, `26px`.
- notice the various elements which are off.The application should accommodate larger font sizes.The application adjusts in some contexts, but not others.Firefox, Chrome, Safari, Microsoft Edge, Internet Explorer, Other Browser
No response
No response
No response
This RFC proposes supporting a dark theme for the API docs.
The general idea behind dark theme support to reduce the number of bright pixels (and thus blue light) for better long-term eye health.
This should be straightforward to do. Would mainly require adding a toggle element which would apply a theme class to the root element. From there, we'd just need to update the stylesheets to use different colors (syntax highlighting, links, etc) on the dark background.
No.
No.
No.
RFC:.This RFC proposes adding a link to each README to edit the file on GitHub.
Currently, if a user finds a typo or bug in an example in a package README, there is no immediate way to directly edit that file.
Next to the link, we can place a ? icon (or something similar) which links to https://docs.github.com/en/github/managing-files-in-a-repository/managing-files-on-github/editing-files-in-another-users-repository, in case this is a user's first time contributing or interacting with a repository on GitHub.
No.
No.
No.
RFC:.This RFC proposes to add support for viewing API docs for C APIs.
Currently, the side menu includes all packages. When writing native add-ons and C APIs, would be useful to limit the side menu to only those packages containing C APIs. Preferably, when limiting to C API packages, only the C API documentation would be present upon navigating to a package README.
No.
No.
No.
RFC:.This RFC proposes adding support for viewing API docs as JSON.
Currently, one can only view the API docs as HTML. Would be nice to be able to view the docs as JSON, as well, similar to Node.js (e.g., see console).
This would be useful as a consumable public format which can be consumed by IDEs and code editors.
Accomplishing this feature would require some tooling, as we'd like want to incorporate type information, which is not readily available in the README files, but is present in both the repl.txt (where present), in the TypeScript declaration files, and in the JSDoc source comments.
No.
No.
No.
RFC:.Please ensure the following tasks are completed before filing a bug report.
Description of the issue.
When we generate the HTML fragments, we transform the project links to absolute URLs; e.g.,
https://stdlib.io/docs/api/v0.0.90/@stdlib/array
Preferably, we'd have the ability to generate relative URLs; e.g.,
/docs/api/v0.0.90/@stdlib/array
To support this, instead of a version option which is set during the build process, we'd provide a base option, defining the "base" URL; e.g.,
var opts = {
'base': '/docs/api/v0.0.90/'
}Hence, a base URL would supplant the need for a version option. This would also allow providing an absolute URL; e.g.,
var opts = {
'base': 'https://stdlib.io/docs/api/v0.0.90/'
}Does this issue have any related issues?
No.
Any questions for reviewers?
No.
Any other information relevant to this issue? This may include screenshots, references, stack traces, sample output, and/or implementation notes.
If relevant, provide a link to a live demo.
For a live demo of the issue, see
What steps are required to reproduce the unexpected output?
In order to reproduce this bug, do the following:
What are the expected results?
The following results are expected:
N/A
What are the actual results?
The following are the actual results:
N/A
What environments are affected (e.g.,
Node v0.4.x,Chrome,IE 11)? If Node.js, include thenpmversion, operating system, and any other potentially relevant platform information.
The following environments are affected:
Please ensure the following tasks are completed before submitting a feature request.
RFC:.Description of the feature request.
This RFC proposes to create a different version of the docs for the REPL usage of stdlib. Instead of the namespace-oriented (and thus tree-based) organization of the docs, the sidebar menu of the REPL docs could be organized along the objects the respective functions are attached to (identified by their alias). For each function, we could create special README.md documentation files tailored around interactive usage.
Does this feature request have any related issues?
No.
Any questions for reviewers?
Any comments on the implementation details provided below? Any problems which need to be resolved in order to proceed?
Other open question:
repl.txt files contain documentation for the parameters and return values of each function. Which of these (if any) should be included in the documentation? It seems to me that the return value description could be included at the beginning of the ##### Notes section?repl.txt file into a README.md for the website documentation?Any other information relevant to this feature request? This may include screenshots, references, sample output, and/or implementation notes.
We need tooling for generating the documentation for the alias version of the functions. This could be based on the repl.txt files, which are already specifically tailored for describing how to use the respective functions int he REPL environment.
However, I would propose to merge parts from both the README.md and repl.txt files:
intro section from the README.md files, as it provides useful context for the function. In contrast to usage in a command line, where real estate is more limited, I do not see a disadvantage from keeping it for the docs on the websiteusage section from the repl.txt docs. Specifically, we would need a script which performs the following steps:
##### Notes section with each line in the extended description mapped to a Markdown list element.examples section from the main README.md files. Sometimes, the examples are rather long or include for-loops etc., which are not representative of REPL usage and might be rather cumbersome to execute.factory method), we would need to have multiple signature headings inside the usage section.Encountered an error when attempting to use skip links to navigate to the search input element when on the search page. Upon hitting ENTER on the skip link, the app attempts to navigate to the top nav search input element, but is redirected to the search results page. Hence, instead of focusing, the app appears to be actually executing the search.
None.
No.
No response
- execute a search
- hit `TAB` until "Skip to search"
- hit `ENTER`
- note that one is unable to update the search input element.To be able to update the search input element.Another search is executed without my being to able to modify the search query.Firefox, Chrome, Safari, Microsoft Edge, Internet Explorer, Other Browser
No response
No response
No response
This RFC proposes minifying package HTML fragments.
Currently, package HTML fragments are not minified (see example).
This leads to more transferred bytes, slower load times, and a larger Git repository. During the fragment build process, we should minify the fragments.
No.
No.
No.
RFC:.This RFC proposes investigating using web workers for running tests and benchmarks, rather than iframes.
Currently, in order to run benchmarks and tests, we load an HTML page into an iframe, which then loads a benchmark or test bundle, respectively.
This approach works; however, it often results in blocking the main thread and potentially causing the current browser tab to lock and/or crash.
This RFC proposes potentially moving execution logic to a web worker. This should be doable, as tests and benchmarks do not interact with the DOM, nor should we necessarily expect them to in the future. In which case, all we really care about is their printed output, which can be passed back to the main thread via message passing.
Moving execution logic to a web worker would entail a different benchmark/test loading mechanism. Notably, we'd no longer load via an *.html file, but would likely need to load the benchmark/test bundles directly.
Were we to successfully move execution logic to a web worker, we would presumably need to prevent the user from moving to another package/view during execution, or need to do something to address an orphaned web worker.
For those browsers lacking web workers, we'd either need a fallback OR we'd need to show an error and/or hide tests/benchmarks from the UI altogether. The latter is probably the most straightforward.
No.
No.
No.
RFC:.This RFC proposes refactoring the side menu to not add unnecessary SVG icons into the DOM.
Currently, we use Material UI buttons which wrap SVG icons. Given the large number of packages (which we can expect to only increase), we're potentially adding thousands of unnecessary DOM nodes which harms performance.
Better would be to instead rely on CSS background images and load a single SVG which can be cached for a performance boost.
No.
No.
No.
RFC:.Please ensure the following tasks are completed before filing a bug report.
Description of the issue.
Currently, when running benchmarks and tests, we use a fixed sized iframe. When viewing results, not always obvious that more contents exist unless one happens to intentionally or inadvertently scroll the iframe. Ideally, from a visual perspective, the user need not know whether we're embedding an iframe or not, and we'd automatically adjust the iframe height based on the content height.
For some inspiration, see https://stackoverflow.com/questions/9975810/make-iframe-automatically-adjust-height-according-to-the-contents-without-using
Does this issue have any related issues?
No.
Any questions for reviewers?
No.
Any other information relevant to this issue? This may include screenshots, references, stack traces, sample output, and/or implementation notes.
If relevant, provide a link to a live demo.
For a live demo of the issue, see
What steps are required to reproduce the unexpected output?
In order to reproduce this bug, do the following:
What are the expected results?
The following results are expected:
iframe scrollbar.What are the actual results?
The following are the actual results:
iframe height, we have to scroll to see the hidden results.What environments are affected (e.g.,
Node v0.4.x,Chrome,IE 11)? If Node.js, include thenpmversion, operating system, and any other potentially relevant platform information.
The following environments are affected:
Currently, when viewing the API docs on a mobile device (small screens), when the side panel is open, the only way to close the panel is by clicking the toggle button.
However, I often found that I wanted to tap outside the panel on, e.g., the package README, expecting the side panel to automatically close in order to return me to the README view. This is not the case, however, as I need to explicitly tap the close button.
I propose, similar to how we query the view port to determine whether the side panel should be open on page load, we use the view port width to determine whether to add a click/touch handler to close the side panel on smaller devices.
Encountered an error when adjusting the viewport width to emulate various devices. Upon adding the settings icon, we didn't update the top-navigation styling to accommodate the icon at various device widths. Screenshots are included below:
We need to determine our strategy for incorporating settings in the top navigation.
None.
No.
No response
- navigate to the documentation for a particular package.
- open the inspector.
- emulate various devices.
- notice that, at certain widths, our responsive design breaks.The expected behavior is that our design fluidly accommodates devices of most widths, barring possibly the smallest (such as Galaxy Fold).Our design breaks.Firefox, Chrome, Safari, Microsoft Edge, Internet Explorer, Other Browser
No response
No response
No response
This RFC proposes adding support for prefers-reduced-motion media query to disable animations. Animations can cause physical discomfort for some people, and we should respect user preferences in this regard.
In particular, this applies to the API docs side menu where we use animation for sliding out the drawer and for collapsing/expanding namespaces.
No.
No.
No.
RFC:.Please ensure the following tasks are completed before filing a bug report.
Description of the issue.
We need to fix the following styling issues with the API docs top navigation:
Does this issue have any related issues?
None.
Any questions for reviewers?
No.
Any other information relevant to this issue? This may include screenshots, references, stack traces, sample output, and/or implementation notes.
If relevant, provide a link to a live demo.
For a live demo of the issue, see
What steps are required to reproduce the unexpected output?
In order to reproduce this bug, do the following:
What are the expected results?
The following results are expected:
N/A
What are the actual results?
The following are the actual results:
N/A
What environments are affected (e.g.,
Node v0.4.x,Chrome,IE 11)? If Node.js, include thenpmversion, operating system, and any other potentially relevant platform information.
The following environments are affected:
This RFC proposes adding support for keyboard shortcuts to the API documentation. Would be nice, e.g., to be able to open and close the side menu, to focus on the search input element, etc.
A list of possible keyboard shortcuts:
/: focus on search (Algolia used cmd + k)fn + <-: navigate to "previous" packagefn + ->: navigate to "next" packagem: toggle side menushift + f: focus on side menu filter (similar to cmd + f/ctrl + f for browser find)shift + return: run code example (once supported)?: display help page (i.e., how to use the documentation, including keyboard shortcuts)b: open benchmarks page (if exists)t: open tests page (if exists)shift + t: navigate to TypeScript docs (if exists)s: navigate to source code (if exists)p: navigate to package doc page (if, e.g., currently on a package's benchmarks page)c: navigate to a package's changelog (if exists)d: toggle dark mode (once supported)esc: close search results/help/settings menuOthers?
No.
No.
RFC:.This RFC proposes adding chat functionality to the API documentation to facilitate user engagement.
When a user has a question, particularly when navigating the project given its size, would be great to provide a mechanism by which a user can ask a question without needing to, e.g., navigate to GitHub and open an issue, but instead, ask in a (public) chat forum.
One potential solution is using Gitter sidecar. We already use Gitter for community chat. This would simply embed the chat in the website, without a user needing to navigate to a separate website.
No.
No.
No.
RFC:.This RFC proposes investigating migration from Material-UI v4 to Mui v5. See migration guide.
Based on an initial skim, this should not be too difficult, as we mostly use fairly vanilla Material UI elements, such as buttons and icons.
No.
No.
No.
RFC:.Please ensure the following tasks are completed before submitting a feature request.
RFC:.Description of the feature request.
This RFC proposes to setup user integration (UI) testing via puppeteer and tape. Ideally, we'd setup UI testing to run in a continuous integration environment, such as that which is offered via GitHub actions.
Initially, the tests can be simple and straightforward; e.g.,
Eventually, testing can be expanded to crawling the site and ensuring that
Does this feature request have any related issues?
No.
Any questions for reviewers?
No.
Any other information relevant to this feature request? This may include screenshots, references, sample output, and/or implementation notes.
The following may provide some inspiration for how to use tape (or a stdlib equivalent):
This RFC proposes adding link elements to README section headings to allow linking to that section.
This would be similar to how GitHub displays a link icon on hover which supports creating a link to that specific section.
One issue, however, is that package README HTML fragments are generated outside of the React application, so we'd need to either
a. add <a> tags before all headings in the original Markdown files. We do this for some READMEs now, in order to cross-reference particular sections within the same Markdown file.
b. modify the fragment generation process to insert <a> tags before headings and assigning headings unique ids.
c. manipulate the DOM on fragment load from within the React app.
From a runtime performance perspective, my preference would be for (a) or (b).
Our practice for (a) is somewhat problematic as we rely on the deprecated name attribute.
For (b), we'd need to perform some processing of the generated HTML, which could be beneficial as we could generate readable heading ids for function signatures and methods.
Accordingly, I think I'd lean toward approach (b).
No.
No.
No.
RFC:.Encountered an error when running a Google Lighthouse audit in Chrome devtools.
We need to update and add fields in our web app manifest file. See here.
No.
No.
No response
That the audit passes.The audit fails.Chrome
No response
No response
No response
Upgrade to React v18.
Currently, this is blocked by
@mui/styles: we use this exclusively for SSR. We should investigate whether we can avoid using this and perform SSR using an alternative means.@mui/material: still has a peer dep on React v17.0.0. See tracking issue: mui/material-ui#29844.Encountered an error when loading the search page directly and then clicking the icon to clear the search results. The console logs various errors and the page is completely blank.
No.
No.
No response
- load <https://stdlib.io/docs/api/latest/search?q=sine> in the browser.
- click the icon to clear the search results page.The application should navigate to the welcome/landing page.The page is blank.Firefox, Chrome, Safari, Microsoft Edge, Internet Explorer, Other Browser
No response
No response
No response
Please ensure the following tasks are completed before filing a bug report.
Description of the issue.
The API docs should include the main website footer (or something similar). Currently, the footer lacks corresponding styling and is misaligned.
At some point, because we use GA, we need to link to our privacy policy, both in the API docs and on the main website.
Does this issue have any related issues?
No.
Any questions for reviewers?
No.
Any other information relevant to this issue? This may include screenshots, references, stack traces, sample output, and/or implementation notes.
If relevant, provide a link to a live demo.
For a live demo of the issue, see
What steps are required to reproduce the unexpected output?
In order to reproduce this bug, do the following:
What are the expected results?
The following results are expected:
N/A
What are the actual results?
The following are the actual results:
N/A
What environments are affected (e.g.,
Node v0.4.x,Chrome,IE 11)? If Node.js, include thenpmversion, operating system, and any other potentially relevant platform information.
The following environments are affected:
This RFC proposes to create a different version of the package documentation for installing and using individual packages.
Currently, the API docs are oriented around the main project and use nested import/require paths (e.g., @stdlib/math/base/special/sin. To facilitate individual package consumption, it would be nice if a user could toggle the docs and see specific instructions and examples for using individual packages (e.g., @stdlib/math-base-special-sin).
There are a couple of approaches which come to mind:
I think my preference would be the latter, if only because of SEO and less client-side load.
No.
No.
No.
RFC:.This RFC proposes adding internalization support to the API docs.
No.
How would we accomplish this?
No.
RFC:.This RFC proposes adding support for filtering the side menu according to a package's REPL alias.
Currently, a user can filter according to the nested package tree in the main project. However, it would be nice if a user could also filter according to REPL alias.
For example, the query
base.sin
would resolve the package
@stdlib/math/base/special/sin
in the side menu.
Similarly, the query
base.(sin|cos)
would resolve the packages
@stdlib/math/base/special/cos
@stdlib/math/base/special/sin
in the side menu.
No.
No.
No.
RFC:.The current theme selection UI does not accommodate future theme extensions, such as high contrast, in order to accommodate web accessibility needs.
Currently, the choice is binary, but we're likely to want at least three choices.
None.
No.
No response
- open settings menu.- UI element which accommodates more than 2 options.- UI element which only accommodates 2 options.Firefox, Chrome, Safari, Microsoft Edge, Internet Explorer, Other Browser
No response
No response
No response
Currently, if a user tries to print package documentation, the rendered docs use the current theme. Hence, if in dark mode, the print document will also be in dark mode. This is likely not desired (e.g., imagine printing 10 pages with black backgrounds).
Presumably, the fix here is to always switch the application to "light" mode, generate the print docs, and then revert to theme back to its original value before printing.
This RFC proposes to add support for viewing a package's changelog. This would be another navigation item in the top-navigation when viewing the docs for a package (either for the main project or as an individual package).
This is dependent, of course, on the project establishing a changelog process and publishing changelogs during individual package publishing.
No.
No.
No.
RFC:.Encountered a bug when viewing the API documentation on an iOS device where the styling of the version <select> element was incorrect.
Could consider a common approach to style a wrapper underneath the <select> element and thus allowing a custom (and consistent) arrow across devices.
Because we'd still be using the <select> element to display options, we'd retain web accessibility, while also ensuring that the <select> element has similar styling irrespective of view context.
No.
No.
N/A
- view API docs on an iOS device and attempt to use the side menu version filter.Consistent styling.Inconsistent styling.N/A
No response
No response
No response
When viewing the landing page in dark mode, the logo tag line has insufficient contrast with the background. We should probably target the text using, e.g., the default theme text color.
Please ensure the following tasks are completed before filing a bug report.
Description of the issue.
We currently use React. Preferably, we'd move away from using it in favor of Preact and tagged template strings. As we are not doing anything out of the ordinary for a React application, we should be able to use Preact as a drop-in replacement.
Does this issue have any related issues?
No.
Any questions for reviewers?
No.
Any other information relevant to this issue? This may include screenshots, references, stack traces, sample output, and/or implementation notes.
If relevant, provide a link to a live demo.
For a live demo of the issue, see
What steps are required to reproduce the unexpected output?
In order to reproduce this bug, do the following:
What are the expected results?
The following results are expected:
N/A
What are the actual results?
The following are the actual results:
N/A
What environments are affected (e.g.,
Node v0.4.x,Chrome,IE 11)? If Node.js, include thenpmversion, operating system, and any other potentially relevant platform information.
The following environments are affected:
This RFC proposes adding an API documentation index page (e.g., see NumPy).
This would provide a single page which links to all the package docs. This would be useful both to provide a high level overview of symbols in the namespace and for crawling.
No.
No.
No.
RFC:.This RFC proposes publishing the JSDoc source documentation.
Currently, we publish the TypeScript declarations and do not publish the JSDoc source documentation.
While the TypeScript documentation is useful, especially for those using TypeScript, the JSDoc source documentation provides a much richer set of types, examples, notes, and implementation details.
No.
No.
No.
RFC:.Please ensure the following tasks are completed before filing a bug report.
Description of the issue.
Encountered an error when closing the side menu (drawer). Upon closing, the README content width expands. This behavior differs from the previous behavior, where the README content simply shifted to the left.
Does this issue have any related issues?
No.
Any questions for reviewers?
No.
Any other information relevant to this issue? This may include screenshots, references, stack traces, sample output, and/or implementation notes.
If relevant, provide a link to a live demo.
For a live demo of the issue, see
What steps are required to reproduce the unexpected output?
In order to reproduce this bug, do the following:
What are the expected results?
The following results are expected:
What are the actual results?
The following are the actual results:
What environments are affected (e.g.,
Node v0.4.x,Chrome,IE 11)? If Node.js, include thenpmversion, operating system, and any other potentially relevant platform information.
The following environments are affected:
This RFC proposes adding support for exporting API docs to a PDF.
PDF documentation could be useful outside of the website and in the context of offline usage. PDF docs are common in, e.g., R and TeX documentation.
Generation of the PDF could be done either on-demand (client side; see htm2pdf.js) or pre-compiled on the server and simply sent on request.
HTML to PDF can be problematic, as a common technique is to capture HTML as an image, which prevents the generated PDF text from being searchable or selectable.
This RFC would benefit from gh-27, where JSON could be used to automatically generate TeX which could then be compiled to a PDF.
Related issues #27.
No.
No.
RFC:.Please ensure the following tasks are completed before filing a bug report.
Description of the issue.
Currently, the docs side menu renders navigation elements as <button> elements, rather than <links>. This breaks user expectations regarding behavior (i.e., navigating to new content) and ability to right-click and, e.g., open in a new tab or window.
Preferably, the markup would be refactored to use anchor <a> tags, rather than <button> tags.
Does this issue have any related issues?
No.
Any questions for reviewers?
No.
Any other information relevant to this issue? This may include screenshots, references, stack traces, sample output, and/or implementation notes.
If relevant, provide a link to a live demo.
For a live demo of the issue, see
/docs/api.button.What steps are required to reproduce the unexpected output?
In order to reproduce this bug, do the following:
What are the expected results?
The following results are expected:
<a> tags.What are the actual results?
The following are the actual results:
<button> tags.What environments are affected (e.g.,
Node v0.4.x,Chrome,IE 11)? If Node.js, include thenpmversion, operating system, and any other potentially relevant platform information.
The following environments are affected:
This RFC proposes adding support for navigating to the "next" and "previous" package.
While packages do not have an inherent order, allowing easier navigation between packages allows users to explore the project more readily.
The concept of navigating to the "next" and "previous" API is found elsewhere (e.g., see NumPy's sin).
This should be a straightforward addition. Will require loading a list of packages and tracking the index of the currently active package within that list.
No.
No.
No.
RFC:.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.