Turning a boring preassigned template to a dream come true!
Why just make a generic “project”, when you can have a real project that explodes with feelings, the right atmosphere, and the kind of set up design where all dreams come true? Of course, since the beginning of The Odin Project, I had to follow my own vision, and instinct, not just follow the curriculum blindly!
Furthermore, when revisiting to an established codebase- even a foundational static project like a multi-page recipe – the objective shifts rapidly from basic markup generation to a functional web cookbook that simulates a whole new world! What kind of world you may ask? One that has the library cafe of my dreams!
And to make this happen, refinement is needed as I keep updating it as needed. Without further ado, I shall provide with the brief that examines recent refactoring my dream, to upgrade it in both the repository, and its design! It focuses on DOM path resolution, Jekyll pipiline overrides, and the complere migration from static raster assets (AI generated placeholders, until I could come up with a version of my own), to inline Scalable Vector Graphics (SVG). This design system deserves its own tribute, on how to make a dream feel reachable!
**
1/Resolving Structural Path Anamolies and DOM Integrity**
Switching between different projects during multitasking, and the early stage of a multi-stage cookbook, a flat directory structure paired with a centralized styles.css is critical for minimizing the confusion in the path. Moreover, inconsistent relative referencing frequently introduces routing failures.
/Fix.failure:
Initial attempts to link sibling resources or stylesheets using hierarchical prefixes (e.g, … /styles.css ) or nested folder paths) resulted in client-side exceptions. Frankly, an embarrassing mistake, display of the current foundational stage.
/root: The Document Object Model (DOM) attempted to resolve parent directories that did not exist within flat working environment. The browser’s parser was fundamentally confused by the hierarchy.
/resolution: Enforcing strict relative path parity. By normalizing all stylesheet links, and navigation anchors to point directly to root-level siblings (href=”styles.css” and hreft=”index.html”), the routing tree was stabilized. This eliminated parser stalling and the unsightly layout shifts that occur when CSS fails to load.
##2/Bypassing Jekyll Static compilation barriers on GitHub pages-build-deployment
GitHub pages defaults to a Jekyll build process, which frequently interferes with custom static deployments, and specific asset pipelines. To ensure absolute control over the repository’s output, we must implement a nojekyll file at the root level. This bypasses the unnecessary static compilation barriers, allowing our raw HTML, and SVG assets to deploy directly to the edge network without Jekyll’s meddling. It is a simple but elegant override- a true gentle touch, one that makes the new website completely viewable.
So, yes, it is really funny that each time I encounter some kind of problem, I end up learning how to do something else...At this point, I should gather all the Today I learned, and attempt to keep track of them!
##3/ Migrating to Native Inline SVG
The migration from raster images (PNG/JPG) to native inline Scalable Vector Graphics (SVG) is not just a performance optimization; it is a metter of aesthetic superiority. Plus, it was part of my practice with SVG! Inline SVGs reduce HTTP requests, allow for direct DOM manipulation via CSS, and scale infinitely without pixelation. Raster assets are a thing of the past? Maybe, or maybe not, but that is what felt right. The elegance that is achieved with vectors is unique! Specially, since manual digital illustrations (as originally intended is too time-consuming!)
Because good design requires proper code working! From the second project where I eliminated routing errors, validating document trees, and replacing static rasters with an optimized, inline SVG vector pipeline, the recipe repository transforms from a basic project to a fanart of something with a soul of its own- A summary of it that you can find in the following sequence with the second part of the second project recipe that I found.
The takeaway: Just like the final cup where you get to taste the final sips of tea- you get to experience the images of the drinks that make you feel like they hug you from the inside- and, the final strokes that make a dream come true that comes to its destination. Do not be deceived, however! You can always pour yourself another cup of tea, just like you can keep improving the code...Which leads to the question: will this project need to be revisited (just like the others)? Definitely when needed!
And, with this finalizes the layered process in my last revisiting the project in which I got to learn how to use .nojekyll, and make the website, and repository into art itself. Would it have been worth it mentioning how I experimented with Krita too?
Check out my project here: https://labrava0x.github.io/odin-recipes/index.html
Top comments (0)