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 it's hard to know without knowing how to set attrs
@b0rk attrs are bare words with optional quotes: a[href=/api], img[src="https://bsky.app/abc&x=y"]
@jyn is the idea that everything inside the [] gets put into the html verbatim? like a[href=/api hidden class="test"] would translate to <a href=/api hidden class="test">?
@b0rk basically, yeah! it's meant to look like a CSS selector.
@jyn cool! asking bc the issue i always run into with tools to generate html (like JSX etc) is sometimes they have specific ideas about what html "should" look like that are different from my ideas. So knowing that i can write any attr I want (even if it seems "wrong" somehow) and that it'll be respected would be cool
@b0rk oh interesting, what kinds of restrictions do they have? i think currently the one thing i normalize is hidden -> hidden="", but that's easy to remove.

@jyn the main thing i remember is this issue I ran into with templ where it required you to quote attribute values https://github.com/a-h/templ/issues/963 (and also how templ requires that <li> and <p> tags be closed)

the "li tags must be closed" thing doesn't seem too relevant in this case though I am curious about how br and hr tags would be represented

templ errors if HTML attributes aren't quoted · Issue #963 · a-h/templ

Describe the bug If I try run templ on this file: package main templ Hello() { <div id=main></div> } I get this error: parsing error: <div>: malformed open element: line 3, col 7 Seems related to #...

GitHub
@b0rk i decided to make self-closing blocks hr; and empty blocks require a trailing div {}, so bare names are an error now unless they're followed by a > child selector.