soliciting feedback: which of these two syntaxes do you prefer?

body {
@each section in $(sections) where $(:title section) {
$(:title section)
}
$content
}

body {
@each section in (sections) where (:title section) {
$(:title section)
}
$content
}

(note that $ has disappeared from the @each line in the second one)

actually wait i'm a dumbass, this can consistently be (:title section) everywhere, even in the body

this is hot

body {
header.site-header {
nav.site-nav {
@each section in (sections) where (predicate section) {
a.page-link[href=$section.url] { $section.title }
}
}
}

ok follow-up question: which of these do you like better?

A: all of these rules:

  • div { Hello world } expands to <div>Hello world</div>
  • div { span { Hi } } expands to <div><span>Hi</span></div>
  • div { "Hello" span { world } } expands to <div>Hello<span>world</span></div>
  • div div > span { Hi } and p { Hello span { world } } are parse errors

B: all of these rules:

  • div { "Hello world" } expands to <div>Hello world</div>
  • div { span { "Hi" } } expands to <div><span>Hi</span></div>
  • div div > span { "Hi" } expands to <div></div><div><span>Hi</span></div>
  • p { Hello span { world } } expands to <p><Hello></Hello><span><world></world></span></p>

C: something else

@jyn A, but actually C since HTML is neither text nor tree it is something else, yet i like manipulating it as the former better than the latter
@PolyWolf ooh, say more! any different syntax you like more? or languages you'd point me towards to learn from?

@jyn i fear my original comment did not have as noble a thesis as you may have hoped: I was expressing a preference for "HTML template languages should operate on HTML text". however recalling some experiences doing that myself, you really do need entity escaping, so this doesn't quite work (e.x. https://github.com/p0lyw0lf/website/blob/8db2c0f8546773d7cf7dfb6bfd5407f86abf7189/src/runtime/remoteImage.js#L60 and also https://wolfgirl.dev/tags/blag/ is still broken lol)

I cut my teeth on React JSX, which does solve a lot of these escaping issues, at the cost of way too many {} and also those silly <></> fragments.

I have come around to appreciating these syntaxes because they (assumedly) handle the entity escaping issues, aren't very verbose, and map cleanly onto normal HTML ("can run the algorithm in your head"). I like A more than B just because it disallows > as an operator; I think it means a different thing in CSS, and if it did mean the same thing, non-local operators in a template language seems kinda wrong.

The "strings as bodies must be quoted" implying "unquoted things are elements" from B is nice tho, lets u work with webcomponents/not have a hardcoded list of HTML ones, so in a sense yes still C :)

website/src/runtime/remoteImage.js at 8db2c0f8546773d7cf7dfb6bfd5407f86abf7189 · p0lyw0lf/website

My website/blog! https://wolfgirl.dev/. Contribute to p0lyw0lf/website development by creating an account on GitHub.

GitHub
@PolyWolf ">" means "child combinator" in CSS. i think it's the same meaning but you're the second or third person to tell me it's confusing so i'm just going to cut it and make you use braces for nesting lol
@jyn yes but the div beforehand means the rule reads to me like div div > span, (anscestor then child) not div {} div > span (two separate rules). if you meant the example text to be the latter then i am ok with it. just avoiding ambiguity w/ how the rule is interpreted CSS-style :)
@PolyWolf ahhh ok. yes, i'm gonna require div {}, in retrospect i think bare div was a mistake
@jyn lastly i am curious: how will you handle things like <hr> or <img> that are "void elements" (https://stackoverflow.com/a/10599002)? Hardcoded list probably?
What are the allowed ways to close self-closing tags for void elements such as <br> in HTML5?

In HTML5 is it still appropriate to close a <br> tag with <br />? This obviously also applies to all other single tags. I realize this doesn't actually affect how stuff works, but what...

Stack Overflow
@PolyWolf yeah, hard-coded list
@PolyWolf actually hm i could have img; mean this is a self-closing block