Hacker News Reader

Comment by cjfd | Hacker News Reader

The 'eat your own dog food' principle would dictate that the W3C writes their site in plain html + css. The fact that this is not even considered proves the these languages are so incredibly non ergonomic. I know.... it is an often reiterated point, but when it is the site of the W3C it really is very hard not to notice this....

View on HN

IMO they are doing only HTML+CSS.

Using a generator to build the HTML+CSS from a headless CMS is exactly how a content-rich site should be build today.

That is because writing content is a different task to structuring and styling a page.

And the end result is still only HTML+CSS.

How so? W3C is also involved in standardizing the DOM interface to html. JS is equally their own dogfood (in the age of whatwg its debatable whether any of this other than maybe css is really their dogfood anymore)

I don't see how the w3c establishing a rule set would mean they would code it by hand, can you provide more details as to why the should, and not use a CMS that produces compliant code?

Because they edited and published the HTML spec with lots of examples portraying HTML as an authoring language. If W3C actually does intend to publish further HTML specs based on WHATWG (which they haven't done since 2017), they should consider injecting their own navi/styles into the bikeshed-generated WHATWG material as part of their CMS setup (and they have tons of static HTML anyway).

W3C and WHATWG signed and MOU last year to work together on documents and specs.

Regardless, to define a language it only makes sense to author the specification from the language perspective. From what I've read, and honestly it's been many years since I have read their stuff, most of the authoring docs have a section in them talking about applications and editors creating the documents.

I don't know, seems consistent to me?

They're still using HTML and CSS, all websites do. It's the dynamic and generated nature of web applications that makes static HTML and CSS not useful on it's own. You could argue the right choice then is a static site generator, but the difference between static site generation and dynamic site generation is really just when you do the generating work.

W3C, at least on their current site, have hardly any dynamic content beyond aggregated news/event snippets on the front page and maybe charter status pages and roadmaps published once every two years or so. Their collaboration workflow for spec text runs on github. They have gateways/integrations to external services (HTML validator) and a lot of static HTML.

There are two camps withing the HTML/CSS community, one that thinks HTML and CSS should be hand written (with the help of a static site generator), the other one thinks that HTML and CSS should always be generated by a design tool like Frontpage, CMS, Wordpress/Gutenberg et.al.

There's really no one who thinks both use cases are important?

Reply on news.ycombinator.com