proto.re website dev thread

jadd

Well-known member
Joined
Jun 28, 2024
Messages
63
Reaction score
291
Location
somewhere plagued by concrete
Website
proto.re
Gold
6,423
Blurb Style Contest - Participant
Violent Glamour
Lounge Access
Circular Avatar Frame
Profile Music
About the proto.re project

Welcome to an out of character thread where I'll share my web development journey for the new version of my proto.re website. If you are out of the loop, proto.re is where I share my music releases.
It's been long overdue that I rework the website scaffolding and design, the current 5 year old version being too rigid content-wise and necessitating a full blown server & database for some reason.
The plan is to completely change the intent of the website from a generic record label to an in-world organization that gathers data archives and more. (you might have seen beginnings of this change in my art post)

1752571262768.webp
The current version is kinda barebones ngl.

I've made so many tech demos these last years to find what would be feasible and what would be cool, from gapless audio streaming, live audio effects, advanced 3d elements, advanced vfxs; now i think it's time to start the development for real or else I'll be still stuck in this demo stage forever.
I have many broad ideas for design and features, but no clear and precise plan yet. The first steps will be to create the base building blocks before I settle on design and features.
I think I should also make a progressive deployment of the website, feature by feature, instead of waiting until it is perfect to replace the first version, otherwise it might take up to year to properly polish my vision.

The design of the website would be largely inspired from turn of the century era websites, especially those waging into vectorheart aesthetics. It would feature 3d elements mixed with 2d vector blocks, constrained on a small viewport to emulate old 1024px wide websites. Later in the dev cycle, the focus will be on interactivity and animations, trying to emulate that Flash feel.
Here's a non exhaustive list of features I would like to implement, in order of importance:
  • Maintain all previous version URLs with redirects
  • SEO and social network meta-tags (something really important missing in the previous version)
  • Media archive not limited to music releases but also images/text/video, some would be hidden or private
  • Generic link pages for release / profile promotion
  • Generic short links
  • Music player with adaptive bitrate streaming, gapless playback, playlist management, speed control and visualizer
  • World lore wiki / codex
  • Interactive world map
Here's a moodboard with pictures that I gathered these last months, each holding a specific idea for the visual aspect of the website:
Moodboard.webp
You might or might not recognize your art on there.

As for the tech stack, I will be using the Astro website generator to take advantage of its powerful content management features and full control on the technical side of things. For interactive elements, I plan to use the SolidJS framework. The resulting static HTML files will be deployed on Cloudflare Pages for simplicity, and that would allow me to have dynamic content in the future with Workers if needed. For the design implementation I still haven't decided if I should use TailwindCSS or not, but many elements will be handmade in (S)CSS anyway to build my complex ideas.

Coming up, the first building block for my design ideas: dynamically shaded 3D elements.
 
Last edited:
Dynamically shaded 3D elements

You might have noticed that the current proto.re version already has a spinning CD case on the homepage featuring the latest release. It is made with a bunch of HTML divs with CSS 3D transforms. (it is basically the 3D cube tutorial you can see everywhere)
You might say what "What's wrong with it, it's really cool" and I will agree, but only partially: this design feels dated and lacks something to make it more interesting.

Screencast From 2025-07-15 13-02-12.gif
This is neat but this could become neater.

To set my design apart from what everyone makes I will need:
  • Complex shapes and animations
  • Shaded surfaces for a greater illusion of depth
During earlier experiments with those ideas, I quickly concluded that complex shapes could easily be obtained using CSS clip-path or mask properties.
On the other hand, shading is another story: I had to find the normal vector of a surface and then compare its direction to my light vector's, something CSS will not give out natively. My demos all used JavaScript to bridge the gap. The script animates the 3D transforms and compute the normal vector concurrently for each surface. This isn't ideal and adds more complexity when implementing designs on top of a performance penalty for the user.

Screenshot from 2024-03-02 23-29-03.webpScreencast from 2024-03-24 19-31-45.gif
Some early experiments with complex shapes and shading, including a wireframe mode that I'll probably not use.

Since then, browser engines took a big leap: CSS trigonometry functions (cos(), sin() & tan()) are now widely supported. Than means I can implement the shading calculations entirely in CSS and keep authoring my animations in CSS!
This is the following components that I will implement:
  • .scene setups the CSS perspective from an FOV value
  • .mesh groups both .mesh & .quad and 3D transforms them
  • .quad displays a shaded surface
Implementing the .scene perspective calculation is straightforward trigonometry. (I pretty much lifted this part from how quake games and derivatives compute the camera distance from the FOV setting)
Screenshot From 2025-07-18 17-46-21.webp
For the shading calculations however, it becomes really complex:
  • .scene initializes a new transformation matrix and saves it to a set of CSS custom properties.
    Screenshot From 2025-07-18 16-42-59.webp
  • .mesh applies rotation transformations to the matrix and overrides the set of custom properties for its children.
    Screenshot From 2025-07-18 16-43-09.webp
  • .quad applies the rotation matrix to an identity vector to obtain the normal vector and saves it to a set of custom properties that are then used for the surface color and reflections.
    Screenshot From 2025-07-18 16-43-19.webp
The matrix calculations create very long and unreadable calc() statements, for your sanity I will not show these here.

One big problem with this approach is that in CSS a custom property cannot depend on itself: (this is sadly not clearly stated on the MDN docs)
CSS:
.scene {
  --m01: 1;
}

.mesh {
  --m01: calc(42 * var(--m01)); /* THIS IS ILLEGAL! */
}
Thankfully I found a hack to obtain the same result, at the cost of repeating the same calculations and custom properties twice. The hack will alternate between custom property A and B depending on the nesting level, each depending on the other to avoid direct dependency cycles.
CSS:
.scene {
  --m01a: 1;
  --m01b: 1;
}

.mesh:not(.mesh .mesh),
... {
  --m01b: calc(42 * var(--m01a));
}

.mesh .mesh:not(.mesh .mesh .mesh),
... {
  --m01a: calc(42 * var(--m01b));
}

All there is left to do is to define the material of the surface, I will follow the Blinn-Phong model with ambient, diffuse and specular colors. The ambient and diffuse (modulated by the orientation of the normal vector) colors are applied to the background of the surface directly, while the specular reflection is simulated with a radial gradient overlayed on top of the surface contents.


Screencast From 2025-07-14 10-56-14.gif
The eureka moment.

After testing out my solution for a bit, I think maybe there is a reason that noone seems to have done this in pure CSS... I noticed that CSS custom properties do not hold values, but instead CSS tokens. Calculations assigned to a custom property are not evaluated until the custom property is used in an actual CSS property value. This creates a major performance problem: for EACH property where the normal vector custom properties are used, the complete chain of calculations (all rotations of the transformation matrix, etc.) will be reevaluated. Common calculation results between properties are not reused, wasting CPU cycles.
Screenshot From 2025-07-16 00-37-42.webp
The actual calculation that the browser evaluates only for the X component of the normal vector of a surface.
I was not aware of this CSS limitation. It creates a noticeable lag on mobile devices on my test page. (There is also graphical glitches on Chrome Android for some reason...) Sadly I will have to either scale back the 3D usage on my designs or switch to a more appropriate tech like Three.js.

You can test it for yourself here: https://63f3a8a7.proto-re.pages.dev Tell me how that works for you!

Screencast From 2025-07-16 00-42-54.gif
The test page.

Next up, I will be working further on the imagining and implementation of the new design.
 
Back
Top