somishere

Cloudflare Pages works well as a serverless option for this, and without the separate deployment for functions, so no CORS required. Couldn't recommend more.

Big thumbs up for Kopia and its very simple GUI / strategy. Have been using it for a couple of years now to remote backup hard drives and working folders on a bunch of family macs to B2. Restored twice now - logic board & corrupt hd. Chose it after trialing both Borg and Restic for ease of use and storage cost. My monthly backblaze bill hovers around $1.40.

It's peer reviewed by Australians?

Point taken, but where would you expect Australians to publish re a fossil found in southern Australia? In a North American Journal?

2.5c isn't great, but 5 years is. Shows its definitely worth it if you've got any kind of load during the day. Are you able to make any use of the peak rates after 3 over there?

From what I hear SA is one of the best places in the country to generate. Optimal temperature for the panels plus lots of sunlight. 8 years seems like nothing with the genny and battery. We tried but couldn't make the numbers work with any kind of decent backup, this was 3 years ago.

Cheers for the info!

I live in NE Australia (~17"S) and our feed in tariff recently went up from ~6.6c to 9.3c (so now around US$0.063). Massive boon for us, given rising prices. With a 5kw system we feed in 1500kwh per quarter and buy back 600kwh (at ~22c), averaged across the year. Lots of variation summer to winter (sun angle) and depending on wet season, WFH, etc. On our "best" days we'll generate >38kWh. Pool runs for free year round, aircons run for free during the day. For now it's very cost effective for us without a battery. Less so with one. Less so for friends without pool / large appliance running through day. Older systems, generally much smaller, have grandfathered feed in tariffs sitting around 40c. These people tend to go out of their way not to use power during the day. Pool on at night, etc.

Interested to read other's experience.

Yes, you need to support lookahead. But not unbounded. There are so many efficient ways to solve this problem. But computer says no?

Forget the idea that the tokeniser could place markers on semicolons / curly brackets to bound any future lookaheads. Why couldn't you just look one token ahead and analyse the potential pseudo-class/property. Pseudo-classes are clearly defined. There are about 50 of them. AFAIK none of them clash with property values. Keep it this way. If it's not a valid pseudo it's either an invalid selector or a property. Then you're just analysing the equivalent of a property value anyway.

---

Of course the above logic is flawed. I'm really just trying to tease out some useful information other than "can't be done".

I think the main challenge with this discussion is that the limitations of the parsers are not clear, at least outside circles directly working with them. Not only that, the explanations of why certain cases won't work are provided without the proper context needed to understand.

From what I understand tokenisation is dumb, it basically just spits out words. Without nesting it is straightforward for a parser to iterate over these tokens one by one, distinguishing between selectors and properties, based on prior context. Of course parsers could look ahead, but by design they don't, because efficiency.

The arguments for breaking the defacto nesting syntax (i.e. scss) seem to lie in the fact that the rules of the past must lie within the rules of the future, because graceful degradation.

Option C. - the most popular option, and also the most true to scss - while pragmatic in it's approach, is still shoehorning new into old.

I'm sure most agree that unbounded lookahead is probably not workable. But to make the argument that parsers can never look ahead, can never improve, seems ideological, if not ridiculous.

First up, anything starting with a .#* is a selector. Secondly, if you're selective about valid tokens then how many tokens are both a valid selector and property name? Probably custom only? And the number of times you'd find a pseudo selector on one of these? We're rapidly approaching extreme edge case territory here.

Also, looking at your second line: I would say the second part (starting at the semicolon before the h1), is invalidated by the semicolon. No need to lookahead or read up to the semicolon. The first part would always be evaluated first, up to the closing curly bracket. The second part would fail at the first character. I'm looking at this on a phone so maybe I've misread?

Edit: I should add, I'm not disagreeing with your point (I don't think!), just emphasising it

I'm sorry but I thought the challenge as described was one of "infinite lookahead"? Similarly, the csswg profer "graceful degradation" as the reason why a declaration isn't workable. But this solution clearly doesn't require infinite lookahead. It also degrades gracefully.

In fact lookahead isn't needed at all, except in (exceptionally) rare cases. Is the problem that the parsers are incapable of using any smarts beyond what is already provided?

Am I missing something?

Aside: Good point on the semicolon! I think in the previous discussion someone was making the point that parsers are exceptionally flexible/forgiving re. weird and wonderful line break and spacing combos. I wasn't sure about the status of semicolon usage. Idea of strict would just be to put an end to that.

Edit: and hey, apologies for labouring the point on this. But I am genuinely interested. I feel like these conversations just always end up in "you wouldn't understand" territory.

The difference isn't the separator, it is the suffix. Strict designation would afford that either properties be signed off with a semi-colon on the same line (or just a newline). Alternatively you could go the other way and enforce selector signoff with a comma or a bracket on the same line. No strict, no nesting /newfangled wizardy.

This allows for graceful degradation.

My point about corner cases is that there is very, very limited use of pseudo selectors, relatively speaking. Let alone pseudo selection where the selector is based on an element and not a class, or ID, or something else easily differentiable from a property. Which is to say, they are the corner case.

The documented reasoning and references do not make any sense. Older browsers are going to choke on newer syntax regardless. This is an ongoing issue in the JS domain that is managed reasonably well via e.g. polyfills, tooling and rapid release. Often with code bloat initially, sure, but the browsers catch up. The days of "oldIE" are long gone.

The point of the declaration is to tell the browsers that can handle the syntax to handle it. Another method could be to use a new linking method. Regardless, the language would still gracefully degrade as only the newer syntax would require strict rules in place.

Please explain it to me if I am completely missing the point.

Understood. But if the idea was for a 'strict' syntax? i.e. in order to make use of newer syntax rules, CSS would need to declare itself as such and be formatted per spec (and would fail to parse otherwise, same as now), negating the need for "infinite lookaheads" per the explainer. So it's more like a switch statement than multiple engines. CSSOM is straightforward this way, you're dealing with strict by default. Inline styles the same.

I guess the idea would be something along the lines of a 'strict' tag, to identify a shift to modern syntax with stricter rules around parsing, that ensures an infinite lookahead wouldn't be required for e.g. pseudos vs properties.

I put together a regex last time this was discussed [1] (which obviously completely alleviates all concerns): https://regex101.com/r/aOc2Pz/1

But seriously, syntax evolutions happen. If there's an issue with parsing garbage CSS why not just let that garbage run slowly, and re-optimise for the rest, prioritising for form and function.

[1] https://news.ycombinator.com/item?id=32248837

Possibly a stupid question. But is there a reason you couldn't include 2 engines? And require e.g. a doctype assertion?

Lol. Amazing. I lived in Glasgow before Cairns but my main form of transport was bicycle so never had the pleasure :)

I live in Cairns. Based on some of my previous interactions with the council I wouldn't be surprised if your AI was talking to their AI / crudely programmed spreadsheet. That said, if you actually stop and chat to some of the parking inspectors you'll find some of the nicest / most understanding people in the business. Which is saying a lot considering they walk around in 30°C+ (with a plus 25 dew point) for much of the year. I've had them rip up tickets, sign them to make sure they don't fine me later, and stand around making jokes about the abuse they get. Good bunch. Very human.

Bright eyed 24yo dev: Hey look at this amazing thing I made. Only 100 dependencies. Donate money to my patreon. World: That's slick, good on you for putting yourself out there.

Bright eyed 24yo non-dev: Hey look at this amazing thing I made. Buy a print and think about conservation and I will donate money to a charity. World: Wow. Hang on, not wow! NOT. WOW! Our original wow was based on our own distorted / ignorant reality, now corrected by internet / Truth™. OMG you f#$!ing tried to trick us. At least we're pretty sure you did. Destroy.

Edit: She's 24. She doesn't need to be taught a lesson by you or the internet.

I would suggest this is a false dichotomy and so am not sure there would be much to balance in this regard (even if it were up for consideration)

My wife was involved with this, and was on country for some of the testimony to the land court. It's massive news in conservation circles here. She said the cases presented by traditional owners were both compelling and heartbreaking, showing first-hand the visible and culturally significant effects of climate change to e.g. the land (including sea level rises in the Torres Strait causing, among other things, grave sites to be lost to the ocean), and endemic and totemic species such as the flying fox / fruit bat around Cairns. The Environmental Defenders Office, who litigated the case, deserve serious kudos for their work, as do Youth Verdict and the first nations representatives who stepped up to tell their stories.

Yes the court's decision comes in the form of a recommendation, but it is a significant one and will be difficult to ignore. At the very least it should remove any question of a social license for these kind of activities in Australia (i.e. thermal coal extraction!) - which are often presented as beneficial to first nations groups, yet are environmentally and culturally blasé through and through.

a sweet spot?

Yes! Let's talk about about over-60s' screen time like we talk about young people's. Though I'd suggest "screen reliance" as a better measure than "screen time" (meaningful / active vs passive use?). Looking at my own family over the generations (sample size of 1) both screen time and reliance seem all-but incomparable, what is comparable is the sentiment around it:

My grandparents, both in their mid 90s and long-retired, probably watch at least 4-6hrs of TV in a day. At least. Almost always in the evening from about 6 or 7pm until they go to bed (quite late usually). Combination of news, british crime drama, and classic films from their DVD collection. They mainly spend their days playing (a surprising amount of) golf, driving to and eating cheap lunches at various clubs where they are life members (mainly motoring and golf clubs), getting coffee and browsing at shopping centres, and visiting (and being visited by) their large and ever-expanding family. They own a smart phone but until recently only used it for receiving calls (they've just started making them too). They do use the internet sporadically via a PC, mainly to make reservations or plan trips (no email or direct communication). They were the first family on the street to get a TV and every kid on the block used to come around to watch it when my Dad was a kid. They never allowed eating dinner in front of the TV, but usually do so themselves now unless someone is visiting. Their screen time is primarily passive. They find it enjoyable, normal, and don't seem to worry about it at all.

My parents and their partners, all in their 60s and working, waste time on their phones to varying degrees, including a small amount spent on social media. They all enjoy complaining about why internet technology works (or doesn't) the way it does and how much time they spend on it - they came to it later in life (duh) and are very self-ware in their usage. They also watch TV (2-3hrs, broadcast and on-demand), listen to radio, and read books, newspapers and magazines with much less complaint / awareness. Their media use encompasses their lives, but it is not all-encompassing. They take a lot of joy from a family group chat we're all part of, but to talk it's always over the phone or in person. They never allowed watching TV at dinner time, but we did watch the news together (sometimes the Simpsons!) and were one of the first houses in our small suburb to get a game machine (and a PC) in the early 90s, though usage was strictly controlled! My parents & partners will sometimes watch TV at dinner now. Their screen time is probably 50-50 passive to active.

I am on a phone and laptop all day for work. I lead a fairly active/outdoorsy life outside of work (mainly on the weekend), but also watch quite a bit of on-demand, a small amount of broadcast TV, and spend a couple of hours on personal internet use per day. I was the first professional / white collar worker in my family. I would classify my screen time as significant, bordering on excessive and primarily active.

My kids aren't allowed to watch TV at dinner time. They're about to enter school so still don't have too much use (or want) for a phone or the internet yet, beyond 2-3hrs on-demand streaming per week. I plan on limiting it as much as possible while I can, assuming that it will dominate their lives (while hoping that it won't). This seems to be the generationally-shared sentiment.

Agree, esp. regards a clarification around 'tiny'.

Personally (controversially?) I've always questioned the idea of a tiny house in the countryside. In dense urban (and otherwise restrictive) environments focusing on size makes some sense. But in a rural setting? Emphasizing 'tiny' over e.g the UN-Habitat's mantra of "fast, affordable and absolutely green" feels like a misinterpretation and unnecessary burden ('fast' might be switched out in this context too). I'm not advocating for sprawling mansions by any means, but certainly a more holistic consideration of space and its effects on mental health.

I'll have to respectfully disagree. Not with your first sentence, that's true enough, but everything else.

Totally get that. And I think if those are the conventions you're designing form interactivity with then, absolutely, you probably need a javascript library to validate and step your user through form submission.

My point is that this should be the exception, not the rule. I certainly don't think this level of abstracted complexity is necessary, or even better, in most scenarios. I'm talking at a design or implementation level.

Personally I would be aiming for consistency / simplicity. There's so many good ways to solve this at a design level without introducing a multi-phased state system. But that's me.

Looking forward to broad support for :has() ... infinite number of good potential use cases. The grid layout example is probably the most interesting here, though the syntax will certainly also make forms more flexible with less structural complexity.

That said, personally I put a bit of effort into achieving (dynamic) ends without javascript (despite being a js dev) and find form styling, with it's intrinsic state, one of the less-problematic things to style. In fact, I tend to use input elements in a bunch of unconventional places as state machines in place of js. Hamburger menus, overlays (prior to the <dialog> tag), dark mode toggle, etc. have all been prime candidates for "previous-sibling" (or "parent-previous-sibling") input treatment.

In the form examples provided, the <labels> being styled could easily be included "after" the <input> in code (regardless of where they appear visually) allowing them to be targeted based on state/focus of the input. Similarly the :focus-within vs :has(:focus-visible) consideration is interesting, but in reality not really a massive concern and certainly not a blocker. The fact that people have relied on JS for this stuff traditionally I think is the bigger concern for me. Here's to progress!

P.S. I mainly like the idea of low/no js from an academic perspective. But I do think it comes in handy in surprising situations, both when a random no-js purist stumbles across your site and is able to do something, but also when something breaks (naughty browser plugin, broken script, dodgy refactor) and people are still able to open your nav / close your popover / fill in your complaints form.

"And everything goes back to the beginning"

Cool article. Reminds me of the flash days .. where working with splines / bezier curves on day-to-day web projects was pretty much the norm. Dynamic motion guides, natural distribution around a shape. Not to mention visual experimentation like this. None of this pre-destination layout engine mumbo jumbo. The whimsical web was where it was at :)

I have a "generator" site[1] where people are able create/share a "fairly" unique image (billions of potential combos) rendered in the dom. There's no point pre-rendering every possible version of a all-but unique social image, so instead I generate them on the fly as they are requested (i.e someone shares one).

In my case I actually render them on the client using dom-to-image[2] and then store/cache them using R2. This is basically to save on server costs (it's hosted on free CF pages with a worker). A more secure implementation (with a compute budget) might use a headless browser like this server side to render the image.

[1] perfectpollie.au

[2] npmjs.com/dom-to-image

But if you accidentally type something now you can't just hit redo N times to get back. It's gone.