If there are elements deep into the viewport near the top or bottom they
will end up obscured by the edge of the viewport when scrolling. This
may be undesirable in some cases. Implement a clamping of the allowed
range of the perspective origin to give better control over the
perspective and what it obscures.
Workaround issue in Safari where setting the perspective origin using a
var() expression for one of the axes does not apply correctly causing
the 3d parallax effect to be lost.
When scrolling the page on mobile and the toolbar gets hidden or made
visible again as a result of scrolling the browser reports the size of
the page having changed when the scrolling ends, which in turn causes
perspective shifts when the finger is lifted from the screen.
Try to work around this by anticipating this resize and calculating the
perspective as if the screen hadn't changed size.
While window.visibleViewport and window.screen in theory could have been
used to determine exactly where and when the browser toolbar is present,
it was found through testing that neither Chrome nor Firefox on Android
reports useful values through these APIs, and instead pretended that the
inner viewport was the whole screen.
If the origin is set to the center of the screen for a small 3d element
that's near the top or bottom, then it looks out of place and can't be
scrolled to fit nicely in view. Adjust the origin to stay inside the
bounds of the viewport when scrolled to the edge of the screen in this
case.
Prefer breaking words instead of overflowing the containers they are
inside of. This prevents the site from scrolling to the right on
extraordinarily narrow screens.
Establish a playground for trying out complex components and styles
without having to use them in a content page. This starts out as a
testing ground for the 3d Viewport.
Implement a Viewport component and associated update script that allows
rendering 3d content inside it. This is based on the implementation
used at Furnavia for their 2025 website.
Use a more traditional source code layout with the code located in the
src/ dir and static web content in the web/ dir, while the other places
are for data not related to code or content.
Add an HTTP server for development purposes that replies to requests
with both the static resources and on the fly generated pages. This
serves the following needs.
- Modern module scripts requires an origin supporting CORS policies,
which is not supported when pages are read from disk by the browser.
- Provide a way for implemting automatic reloading of pages when changes
are made to the source files.
- Act as the starting point for making interactive features such as
comments and analytics.
Add the necessary boilerplate for cli.ts to provide more than one
command, with the resource gathering step split out from the build
step in order for it to be re-usable.
The paths changed in d003ea01 to start with a forward slash, this broke
the create folder detection logic as now it matched the first slash of
the path instead of sub-folder in the path. Fix by ignoring the first
character in the path.
Write all links as absolute refs from the virtual root of the website's
path namespace and then transform these into relative links with the
resolveRefs utility function.
Provide a transformation function that maps absolute references to
resources into relative references based on the location of a page.
This makes it possible to use the same links across multiple pages
in the hierarchy that works when loaded as files from the filesystem.
Set up the basic layout of the site and greybox its content based on
statically generated pages. Content pages uses general base layouts
defined centrally to avoid duplicating code.
