Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting my website in plain HTML and CSS

vijayp.dev

Post reply on HN
Print view View original

191–200 of 218 posts

Re: Rewriting my website in plain HTML and CSS

#191

Post by insonable »

makizar wrote: post #53
insonable wrote: post #43

There's a lot you can do with just plain html these days if you just need a clean site. Here's an example from my recipe site ( https://xilic.com/recipia/sauces/pesto_traditional.html ), mostly for my personal use or sharing with friends, with only html/css. It has expandable boxes, a menu system, etc. A simple script converts a directory structure of .csv files to these recipe cards with a template, and this way you…

What a beautiful website ! Feels carefully crafted, full of nice moments like the > turning the a - when sections are open in the TOC. Would love to hear more detail on how you went about making it. Did you ever consider sharing parts of the source code ?

thanks! i first just made a sample html the way i thought it would be nice, then made that into a templeate, and wrote a python script generate the site. it first scans for all the files to build the menu and homepage, then goes file-by-file to make each one, filling in the blanks in the template as you can imagine. it was pretty natural since my spreadsheets were all following the same format already anyway. i'd be surprised if there was a lot of interest, but if so i'd consider sharing the script/template etc.

Re: Rewriting my website in plain HTML and CSS

#192

Post by insonable »

johnreagan wrote: post #162
insonable wrote: post #43

There's a lot you can do with just plain html these days if you just need a clean site. Here's an example from my recipe site ( https://xilic.com/recipia/sauces/pesto_traditional.html ), mostly for my personal use or sharing with friends, with only html/css. It has expandable boxes, a menu system, etc. A simple script converts a directory structure of .csv files to these recipe cards with a template, and this way you…

Love the site! Usually desert = dry place and dessert = delicious food.

thanks, good point!

Re: Rewriting my website in plain HTML and CSS

#193

Post by insonable »

HumblyTossed wrote: post #172
insonable wrote: post #43

There's a lot you can do with just plain html these days if you just need a clean site. Here's an example from my recipe site ( https://xilic.com/recipia/sauces/pesto_traditional.html ), mostly for my personal use or sharing with friends, with only html/css. It has expandable boxes, a menu system, etc. A simple script converts a directory structure of .csv files to these recipe cards with a template, and this way you…

what's the csv look like?

simple like:

title

subtitle

.. [two blank lines make a section break]

ingredients with 4 columns, last one is an optional comment for the row

..

method steps with 2 columns, last one is optional comment

..

then optional sections that just have to have:

section title (this is the collapsed title string too)

any rows included until the next .. etc. etc.

plus just a few tricks like if an ingredient comment has [] then it uses that as a URL for the ingredient, if a row in ingredients has just one column then it's a header etc.

Re: Rewriting my website in plain HTML and CSS

#194

Post by insonable »

nayuki wrote: post #112
insonable wrote: post #43

There's a lot you can do with just plain html these days if you just need a clean site. Here's an example from my recipe site ( https://xilic.com/recipia/sauces/pesto_traditional.html ), mostly for my personal use or sharing with friends, with only html/css. It has expandable boxes, a menu system, etc. A simple script converts a directory structure of .csv files to these recipe cards with a template, and this way you…

Really appreciate that you're doing mass-based recipes, and in metric too. I'm tired of all the American recipes with quantities like "2 1/3 cups"; the proliferation of units and fractions makes work needlessly hard compared to just grams and millilitres.

it's also just way faster to not mess with the spoons/cups! an exception might be little fussy quantities like a bunch of 1/4 tsps of different spices etc.

Re: Rewriting my website in plain HTML and CSS

#195

Post by mikae1 »

lapcat wrote: post #136
mikae1 wrote: post #96

Earlier quoted context omitted.

And does your blog have RSS or Atom feed? That's usually where it becomes a little tedious.

Of course. It's not a blog without RSS! Believe it or not, I also manually edit that in BBEdit.

I'm impressed, that's grit!

Re: Rewriting my website in plain HTML and CSS

#196

Post by dickersnoodle »

lmm wrote: post #120
spoonfeeder006 wrote: post #56

Earlier quoted context omitted.

Isn't using React with a static site generator framework basically the same thing but better?

Yes, it is. Unfortunately HN has a crazy bias against JavaScript (the least crazy part of the web stack) and in favour of HTML and CSS, even though the latter are worse in every meaningful way.

It isn't crazy, judging by the number of times I've seen posts here and on other blogs talking about a 100k web page ballooning to 8Mb because of all the Javascript needed to "collect page analytics" or do user tracking when ads are included. Granted that may not be needed for personal websites, but for almost anything that has to be monetized you're going to get stuck with JS cancer because some sphincter in a suit needs for "number to go up".

Re: Rewriting my website in plain HTML and CSS

#197

Post by dmsnell »

tannhaeuser wrote: post #94
uncheckederror wrote: post #19

I've been maintaining my personal website as plain HTML for five years now. I must say, I quite like this method. There's no substitute for practice when it comes to maintaining your skills at editing HTML and CSS. Yes, you must copy and paste content and not having layout page is annoying at times. But the overhead of just doing it yourself is surprisingly small in terms of the time commitment. Typically, I'll draft…

> copy and paste content and not having layout page is annoying at times HTML was envisioned as an SGML application/vocabulary, and SGML has those power features, such as type-checked shared fragments/text macros (entities, possibly with parameters), safe third-party content transclusion, markup stream processing and filtering for generating a table of content for page or site navigation, content screening for remova…

I’ve become quite a fan of writing in SGML personally, because much of what you note is spot-on. Some of the points seem a bit of a stretch though.

Any type-checking inside of SGML is more akin to unused-variable checking. When you say that macros/entities may contain parameters, I think you are referring to recursive entity expansion, which does let you parameterize macros (but only once, and not dynamically within the text). For instance, you can set a `&currentYear` entity and refer to that in `copywrite "&currentYear/&currentDay`, but that can only happen in the DTD at the start of the document. It’s not the case that you could, for instance, create an entity to generate a Github repo link and use it like `&repoName = "diff-match-patch"; &githubLink`. This feature was used in limited form to conditionally include sections of markup since SGML contains an `IGNORE` “marked section”.

   
   ...
   
   I’m on the fence about including this bit.
   It’s not up to the editorial standards.
   
   ]]>
SGML also fights hard against stream processing, even more so than XML (and XML pundits regret not deprecating certain SGML features like entities which obstruct stream processing). Because of things like this, it’s not possible to parse a document without having the entire thing from the start, and because of things like tag omission (which is part of its syntax “MINIMIZATION” features), it’s often not possible to parse a document without having _everything up to the end_.

Would love to hear what you are referring to with “safe” third-party transclusion and also what features are available for removal or rejection of undesired script in user content.

Apart from these I find it a pleasure to use because SGML makes it easy for _humans_ to write structured content (contrast with XML which makes it easy for software to parse). SGML is incredibly hard to parse because in order to accommodate human factors _and actually get people to write structured content_ it leans heavily on computers and software doing the hard work of parsing.

It’s missing some nice features such as namespacing. That is, it’s not possible to have two elements of the same name in the same document with different attributes, content, or meanings. If you want to have a flight record and also a list of beers in a flight, they have to be differentiated otherwise they will fail to parse.

   
   
   

   
   
   Ultra Pils 2023
   Dual IPA
   Chocolate milk stout
DSSSL was supposed to be the transforms into RSS, page views, and other styles or visualizations. With XML arose XSL/XSLT which seemed to gain much more traction than DSSSL ever did. My impression is that declarative transforms are best suited for simpler transforms, particularly those without complicated processing or rearranging of content. Since `osgmls` and the other few SGML parsers are happy to produce an equivalent XML document for the SGML input, it’s easy to transform an SGML document using XSL, and I do this in combination with a `Makefile` to create my own HTML pages (fair warning: HTML _is not XML_ and there are pitfalls in attempting to produce HTML from an XML tool like XSL).

For more complicated work I make quick transformers with WordPress’ HTML API to process the XML output (I know, XML also isn’t HTML, but it parses reliably for me since I don’t produce anything that an HTML parser couldn’t parse). Having an imperative-style processor feels more natural to me, and one written in a programming language that lets me use normal programming conveniences. I think getting the transformer right was never fully realized with the declarative languages, which are similar to Angular and other systems with complicated DSLs inside string attribute values.

I’d love to see the web pick up where SGML left off and get rid of some of the legacy concessions (SGML was written before UTF-8 and its flexibility with input encodings shows it — not in a good way either) as well as adopt some modern enhancements. I wrote about some of this on my personal blog, sorry for the plug.

https://fluffyandflakey.blog/2024/10/11/ugml-a-proposal-to-u...

Edit: formatting

Re: Rewriting my website in plain HTML and CSS

#198

Post by TeMPOraL »

lmm wrote: post #189
TeMPOraL wrote: post #165

Earlier quoted context omitted.

Least unpleasant to the developer. Most unpleasant to the user. It breaks all kinds of useful browser features (which frontend devs then recreate from scratch in JS, poorly; that's probably the most widespread variant of Greenspun's tenth rule in practice).

> It breaks all kinds of useful browser features (which frontend devs then recreate from scratch in JS, poorly; that's probably the most widespread variant of Greenspun's tenth rule in practice). Nah, it's the opposite. JS tends to perform better and be more usable for the same level of feature complexity (people who want more complex sites, for good reasons or bad, tend to use JS, but if you compare like with like),…

> E.g. if you actually test with a screenreader, aria labels work better than "semantic" HTML tags

Interesting how this is opposite to the recommendations from MDN, such as:

Warning: Many of these widgets are fully supported in modern browsers. Developers should prefer using the correct semantic HTML element over using ARIA, if such an element exists.

The first rule of ARIA use is "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so." -- which also refers to: https://www.w3.org/TR/using-aria/#rule1

Though I can believe that real life may play out different than recommendations.

Also, as I understand it, ARIA is orthogonal to JS, and it doesn't alter behavior for browser users.

Re: Rewriting my website in plain HTML and CSS

#199

Post by thro1 »

erremerre wrote: post #107

I have found someone who uses the anchor suffix to solve the problem: https://john-doe.neocities.org/ I am not html expert, so I have no idea how complicate or what implications would that have.

Nice one.

Pro-tips: switch styles to show all content (and buttons) then use contenteditable - for the whole page or allow it at element levels, allow copying/removing specific element ("template"), POST new version, HTTP Authenticated, to the server or just save :)

Re: Rewriting my website in plain HTML and CSS

#200

Post by tannhaeuser »

dmsnell wrote: post #197
tannhaeuser wrote: post #94

Earlier quoted context omitted.

> copy and paste content and not having layout page is annoying at times HTML was envisioned as an SGML application/vocabulary, and SGML has those power features, such as type-checked shared fragments/text macros (entities, possibly with parameters), safe third-party content transclusion, markup stream processing and filtering for generating a table of content for page or site navigation, content screening for remova…

I’ve become quite a fan of writing in SGML personally, because much of what you note is spot-on. Some of the points seem a bit of a stretch though. Any type-checking inside of SGML is more akin to unused-variable checking. When you say that macros/entities may contain parameters, I think you are referring to recursive entity expansion, which does let you parameterize macros (but only once, and not dynamically within…

Nice to meet a fellow SGML fan!

> When you say that macros/entities may contain parameters, I think you are referring to recursive entity expansion,

No, I'm referring to SGML data attributes (attributes declared on notations having concrete values defined on entities of the respective notation); cf. [1]. In sgmljs.net SGML, these can be used for SGML templating which is a way of using data entities declared as having the SGML notation (ie. stand-alone SGML files or streams) to replace elements in documents referencing those entities. Unlike general entities, this type of entity expansion is bound to an element name and is informed of the expected content model and other contextual type info at the replacement site, hence is type-safe. Data attributes supplied at the expansion site appear as "system-specific entities" in the processing context of the template entity. See [2] for details and examples.

Understanding and appreciating the construction of templating as a parametric macro expansion mechanism without additional syntax may require intimate knowledge of lesser known SGML features such as LPDs and data entities, and also some HyTime concepts.

> create an entity to generate a Github repo link

Templating can turn text data from a calling document into an entity in the called template sub-processing context so might help with your use case, and with the limitation to have to declare things in DTDs upfront in general.

> it’s not possible to parse a document without having the entire thing from the start, and because of things like tag omission (which is part of its syntax “MINIMIZATION” features), it’s often not possible to parse a document without having _everything up to the end_.

Why do you think so and why should this be required by tag inference specifically? In sgmljs.net SGML, for external general entities (unlike external parameter entities which are expanded at the point of declaration rather than usage), at no point does text data have to be materialised in its entirety. The parser front-end just switches input events from another external source during entity expansion and switches back afterwards, maintaining a stack of open entities.

Regarding namespaces, one of their creators (SGML demi-good James Clark himself) considers those a failure:

> the pain that is caused by XML Namespaces seems massively out of proportion to the benefits that they provide (cf. [3]).

In sgmljs.net SGML, you can handle XML namespace mappings using the special processing instructions defined by ISO/IEC 19757-9:2008. In effect, element and attributes having names "with colons" are remapped to names with canonical namespace parts (SGML names can allow colons as part of names), which seems like the sane way to deal with "namespaces".

I haven't checked your site, but most certainly will! Let's keep in touch; you might also be interested in sgmljs.net SGML and the SGML DTD for modern HTML at [4], to be updated for WHATWG HTML review draft January 2025 when/if it's published.

Edit:

> Would love to hear what you are referring to with “safe” third-party transclusion and also what features are available for removal or rejection of undesired script in user content.

In short, I was mainly referring to DTD techniques (content models, attribute defaults) here.

[1]: https://sgmljs.net/docs/sgmlrefman.html#data-entities

[2]: https://sgmljs.net/docs/templating.html

[3]: https://blog.jclark.com/2010/01/xml-namespaces.html

[4]: https://sgmljs.net/docs/html5.html

Post reply on HN