soliciting feedback: which of these two syntaxes do you prefer?
kulupu jynbody {
@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)
(:title section) everywhere, even in the bodythis 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 errorsB: 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
Zack Weinberg
Julia Evanshidden -> 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
hr; and empty blocks require a trailing div {}, so bare names are an error now unless they're followed by a > child selector.@jyn In theory B, but I've used twirl (https://www.playframework.com/documentation/3.0.x/ScalaTemplates) which is in school A and it was Fine™ in practice.
That said, B3 looks like it might have a typo in its expansion? At least I can't find a logic for `foo foo > bar` to expand to `<foo/><foo><bar/></foo>` Also just generally not a fan of unmatched braces.
@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 :)
Natalie
PolyWolf
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 :)<hr> or <img> that are "void elements" (https://stackoverflow.com/a/10599002)? Hardcoded list probably?
k, cis iirc
✧✦Catherine✦✧
knutaf
polly
Maeryn | Mar !!