aboutsummaryrefslogtreecommitdiffhomepage
path: root/posts
diff options
context:
space:
mode:
authorBradley Taunt <bt@btxx.org>2025-01-20 15:39:24 -0500
committerBradley Taunt <bt@btxx.org>2025-01-20 15:39:24 -0500
commitc0673c23500eadb6d268b9650a4c79f1f4de4f4d (patch)
tree20b3b48623879ea9c689a123949eb2a9d2e5b4aa /posts
parent2fb22bc24f246c082bed0aca7cbee284fe26d71a (diff)
Minimal stylin changes, about page, table cleanup
Diffstat (limited to 'posts')
-rw-r--r--posts/default-html-style-updates.md2
-rw-r--r--posts/rss-hacks.md14
-rw-r--r--posts/tables.md128
3 files changed, 77 insertions, 67 deletions
diff --git a/posts/default-html-style-updates.md b/posts/default-html-style-updates.md
index 85a807b..e0e5cbf 100644
--- a/posts/default-html-style-updates.md
+++ b/posts/default-html-style-updates.md
@@ -57,7 +57,7 @@ That is probably the most streamlined dark mode on the web...
## The "Reading Length" Debate
-Proper reading length tends to be quite the point of contention on the web. Hell, even I've [written about it quite a bit](/character-unit/) in the past (and many of my side projects follow that standard). The main problem I have with this is lack of *user control*. I don't think the browser (or designers for that matter) should determine the best reading length for my own personal reading preferences. UX testing and group feedback has (somewhat) agreed upon 66-75 characters per line to be the most optimal reading experience. That is good to know. I *still* believe it should come down to user preference.
+Proper reading length tends to be quite the point of contention on the web. Hell, even I've [written about it quite a bit](/posts/character-unit/) in the past (and many of my side projects follow that standard). The main problem I have with this is lack of *user control*. I don't think the browser (or designers for that matter) should determine the best reading length for my own personal reading preferences. UX testing and group feedback has (somewhat) agreed upon 66-75 characters per line to be the most optimal reading experience. That is good to know. I *still* believe it should come down to user preference.
Do you want to know an incredible feature built into browsers? *Window resizing*. Abandon the idea that you "know better" than your users and give them the power to adjust as they see fit. The web was meant to be personal and flexible.
diff --git a/posts/rss-hacks.md b/posts/rss-hacks.md
index 3d1890c..666d72c 100644
--- a/posts/rss-hacks.md
+++ b/posts/rss-hacks.md
@@ -15,8 +15,10 @@ Since the shinobi script generates valid RSS code by default, I didn't want to m
My first attempt was to use the available `sort` parameter (in XSL version 1.1+) targeting the `dc:date` type linked to the `pubDate` element:
- <xsl:sort select="pubDate" data-type="dc:date" order="descending"/>
- <!-- each individual post's content here -->
+~~~html
+<xsl:sort select="pubDate" data-type="dc:date" order="descending"/>
+<!-- each individual post's content here -->
+~~~
This did not work as intended. RSS 2.0 requires that the `pubDate` content is set to comply with the RFC-822 date-time[^4], which shinobi handles perfectly fine. The issue came from the XSL `sort` parameter not honoring this setting across all dates. My best guess is that it struggles to properly organize posts from their "month" parameter, so it sets the posts in order of date in what I refer to as "monthly sections".
@@ -32,13 +34,17 @@ Then I remembered the `category` tag which shinobi does not utilize by default.
First I needed to convert the RFC-822 formatted date (found on the first line of all blog post text files) and render it inside a `category` tag. This was simple enough:
- $(date -j -f "%a, %d %b %Y" "$(head -n 1 $file)" +"%Y/%m/%d/%u")
+~~~sh
+$(date -j -f "%a, %d %b %Y" "$(head -n 1 $file)" +"%Y/%m/%d/%u")
+~~~
In a nutshell, this converts the RFC-822 date into the format "2022/05/24/2". Simple numbers that can be sorted much easier by XSL. Now all that was needed was setting to `sort` parameter properly:
- <xsl:sort select="category" order="descending"/>
+~~~sh
+<xsl:sort select="category" order="descending"/>
+~~~
Everything worked perfectly and the RSS was still valid!
diff --git a/posts/tables.md b/posts/tables.md
index c969889..4df3742 100644
--- a/posts/tables.md
+++ b/posts/tables.md
@@ -17,9 +17,11 @@ Included below are two separate demos showing how to optimize `table` HTML for m
Okay I will admit, this implementation isn't the *greatest* but I find it does work well with huge datasets. Simply set a `min-width` on your parent `table` element and the browser will just require the user to scroll the contents horizontally.
- table {
- min-width: 800px; /* Set your desired min-width here */
- }
+~~~css
+table {
+ min-width: 800px; /* Set your desired min-width here */
+}
+~~~
Check out the CodePen below to see it in action:
@@ -32,28 +34,29 @@ I actually prefer this method because of its simplicity and function. Users on m
Using something like `flexbox` tends to work better when you are working with smaller table datasets. All you need to do is add some minor `flexbox` layout at your targeted mobile screen size.
-
- /* Using 800px as mobile screen in this example */
- @media(max-width: 800px) {
- /* Hide the table headings */
- table thead {
- left: -9999px;
- position: absolute;
- visibility: hidden;
- }
- table tr {
- border-bottom: 0;
- display: flex;
- flex-direction: row;
- flex-wrap: wrap;
- margin-bottom: 40px;
- }
- table td {
- border: 1px solid;
- margin: 0 -1px -1px 0; /* Removes double-borders */
- width: 50%;
- }
+~~~css
+/* Using 800px as mobile screen in this example */
+@media(max-width: 800px) {
+ /* Hide the table headings */
+ table thead {
+ left: -9999px;
+ position: absolute;
+ visibility: hidden;
+ }
+ table tr {
+ border-bottom: 0;
+ display: flex;
+ flex-direction: row;
+ flex-wrap: wrap;
+ margin-bottom: 40px;
+ }
+ table td {
+ border: 1px solid;
+ margin: 0 -1px -1px 0; /* Removes double-borders */
+ width: 50%;
}
+}
+~~~
[Check out the CodePen demo](https://codepen.io/bradleytaunt/pen/mZbvOb/)
@@ -65,47 +68,48 @@ There are some caveats with this approach:
You could keep the table headings and style them the same as the `tbody` contents, but I find hiding them a little cleaner. That choice is entirely up to your personal preference. You can also decide to add heading `span` elements inside the main `tbody` elements like so:
-
- /* Default span styling - hidden on desktop */
- table td span {
- background: #eee;
- color: dimgrey;
- display: none;
- font-size: 10px;
- font-weight: bold;
- padding: 5px;
+~~~css
+/* Default span styling - hidden on desktop */
+table td span {
+ background: #eee;
+ color: dimgrey;
+ display: none;
+ font-size: 10px;
+ font-weight: bold;
+ padding: 5px;
+ position: absolute;
+ text-transform: uppercase;
+ top: 0;
+ left: 0;
+}
+
+/* Simple CSS for flexbox table on mobile */
+@media(max-width: 800px) {
+ table thead {
+ left: -9999px;
position: absolute;
- text-transform: uppercase;
- top: 0;
- left: 0;
+ visibility: hidden;
+ }
+ table tr {
+ border-bottom: 0;
+ display: flex;
+ flex-direction: row;
+ flex-wrap: wrap;
+ margin-bottom: 40px;
}
-
- /* Simple CSS for flexbox table on mobile */
- @media(max-width: 800px) {
- table thead {
- left: -9999px;
- position: absolute;
- visibility: hidden;
- }
- table tr {
- border-bottom: 0;
- display: flex;
- flex-direction: row;
- flex-wrap: wrap;
- margin-bottom: 40px;
- }
- table td {
- border: 1px solid;
- margin: 0 -1px -1px 0;
- padding-top: 35px; /* additional padding to avoid heading overlap */
- position: relative;
- width: 50%;
- }
- /* Show the heading span */
- table td span {
- display: block;
- }
+ table td {
+ border: 1px solid;
+ margin: 0 -1px -1px 0;
+ padding-top: 35px; /* additional padding to avoid heading overlap */
+ position: relative;
+ width: 50%;
+ }
+ /* Show the heading span */
+ table td span {
+ display: block;
}
+}
+~~~
[Live CodePen Example](https://codepen.io/bradleytaunt/pen/mZdzmZ/)