FrontAid

Formatting (without "arbitrary format specifications") has been available for years:

- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

- https://caniuse.com/mdn-javascript_builtins_intl_datetimefor...

Parsing, however, is an entirely different topic. I assume the Temporal proposal authors learned from the Date.parse fiasco. To this day, there are browser inconsistiencies that make it largely unusable for anything else than the full-length ISO date format. Hence, it might be better to use a userland library that works consistently regardless of the browser (version). There are also some notes about parsing in https://tc39.es/proposal-temporal/docs/parse-draft.html:

> Temporal's approach to most operations—including parsing—is to encourage strong typing, e.g. Temporal.Instant.from vs. Temporal.PlainDateTime.from. A type-spanning "parse anything" API goes against that strongly-typed model.

> As a side note, what do people think about JSON schema? I find it quite verbose and cumbersome

Agreed. But if you want to have validation and autocompletion in most editors, it is still the way to go. We use it to validate JSON content files for a CMS [1]. It is a little repetitive in our case (e.g. the `:name`/`:description` keys are repeated), but not that bad. Newer versions of JSON Schema [2] have improved in that respect, but most editors (or plugins) and tooling in general is still based on older versions. So we have to stick with those for a while.

[1] https://github.com/frontaid/schema/blob/master/frontaid-sche...

[2] https://json-schema.org/specification.html

If you have to deal with JSON a lot, you might want to checkout https://www.schemastore.org/json/ which has schemas for a large number of file types.

That page broke tabbing through interactive elements by using nested focussable elements like this:

    <div tabindex="0"><input ...></div>

Because of that, it is sometimes necessary to tab twice to focus the next element. Not sure whether that is a problem of DaisyUI in general or just their website. But it is definitely annoying.

No, I meant "expected by anyone who learned the language". Knowing the addition operator including its limitations is quite basic. I'm not saying you need to be able to solve all this "JavaScript is weird" puzzles as they are mostly non-sense. But you definetely have to know what you can us `+` for.

If someone does not like the ECMAScript specification, that is fine. But at least use a proper unofficial documentation like MDN.

I understand where you are coming from. But the addition operator simply does not have any special handling of arrays. The specification [1] clearly defines what it should be used for: "The addition operator either performs string concatenation or numeric addition." As JavaScript is weakly typed, it is the programmer's responsibility to use proper value types with these operators. That limitation (or advantage?) is also well-known and applies to all weakly-typed languages.

[1] https://tc39.es/ecma262/multipage/ecmascript-language-expres...

Both of these examples are well-known (and not unexpected) behaviours. I assume you already know why it behaves like that. If not, I can explain it.

> [1, 2, 3] + [4, 5, 6] // -> "1,2,34,5,6"

What would you expect instead?

> [,,,].length // -> 3

Is there any use case where you would want to deal with sparse arrays?

> I wish for the day where I can really just write clean semantic html and then add the CSS afterwards on top of it.

What exactly is stopping you from doing just that today?

Nesting is not possible in vanilla CSS. However, there is an Editor's Draft about it which has gained some momentum recently.

https://linkedlist.ch/ref/25/

> Besides, none of these services (dropbox, onedrive) support ignore files, so they're constantly syncing node_modules folders, etc.

Tresorit has that feature and it works great. Aside from data encryption, it was the main reason why I switched from Dropbox.

https://support.tresorit.com/hc/en-us/articles/217103697-Exc...

Container queries have been suggested for a while now, it is not a new idea. But it has gained a lot of momentum recently, for example [1]. So maybe it will not be years until all modern browsers might support it. Until then, you might want to try [2] (not a polyfill, but a workaround with JavaScript).

[1] https://github.com/w3c/csswg-drafts/issues/5796

[2] https://philipwalton.com/articles/responsive-components-a-so...

Assume you have a number of cards organized in rows and columns. You could define how many columns to show between each breakpoint using several media queries. However, a better approach would be to use a flex container with `flex-wrap:wrap`. Specify `flex-basis` for its children and the browser will automatically wrap them accordingly. No break points needed.

I agree with the general sentiment.

> What can the web designer do?

Completely disagree with this section.

Each of the suggested device categories (Desktop/laptop, Tablet, Phone) has many different screen sizes/resolutions. And all of them might have screens in landscape or portrait mode. All of these devices might support multi-tasking with varying split screen sizes. All of those devices support custom accessibility configurations for font-sizes, zooming or both. By detecting the UA and trying to shoehorn it into a certain category, you only increase the number of issues for the users.

One part of a solution to this problem is to use relative CSS units. Avoid hard breakpoints whenever possible. Only break columns into rows when there is no more space left.

Small bullet point, but an important one. This release also combats tracking with `window.name`. Discussion here:

https://news.ycombinator.com/item?id=26863109

OK, I see. The tool we are working on is similar but also not quite what you are looking for. In case you want to have a look, it is availale on <my-name> .io

> 3. GUI/WebUI CMS for contributing to a shared versioned repository.

Did you have some specific tool in mind? Because I completely agree that this is a great way of working with content. We have been doing that for a couple of months with our own tool. It uses Git and stores content in a pretty-printed JSON file. Techies can update that directly and push it manually. Content editors can use our tool to edit and commit to Git with a simple Web UI. Would that go into a direction you were thinking of?

Maybe you can take some inspiration from FrontAid CMS https://frontaid.io/

Most browsers changed that to a site-based cache instead of a global one.

https://www.zdnet.com/article/firefox-to-ship-network-partit...

Maybe https://globalprivacycontrol.org/ could change that.

Maybe FrontAid CMS might be interesting to you, even though it is also proprietary. FrontAid CMS is similar to Forestry, but stores all your content in JSON instead of Markdown. It is therefore better applicable to (web) applications in addition to simple blogs. https://frontaid.io/

Like what? I can't think of any "special behaviour" that I would not want to have in a button and that cannot be changed by CSS.

Maybe you are referring to https://en.wikipedia.org/wiki/Mozilla_Prism

That is great news! Thank you Florian, Robert, and everybody involved.

Many good points in there. One that I run into on a regular base and that can't be fixed right now:

> Selectors have terrible future-proofing. We should have split on top-level commas, and only ignored unknown/invalid segments, not the entire thing.

That forces you to duplicate declarations for backward-compatibility. For example, you can't combine those two selectors:

    /* works */
    :user-invalid {}
    :-moz-ui-invalid {}

    /* breaks */
    :user-invalid, :-moz-ui-invalid {}

Somewhat related to the link: https://github.com/jensimmons/cssremedy tries to "fix" some of those issues.

I'd recommend not doing that as it makes the UX on mobile worse and has a bad influence on SEO. Instead, I usually do something like that:

    h1::first-line {font-size:2rem;}
    h1 {font-size:1.5rem;}

It will show the first line of a heading in a larger and all further lines in a smaller font size. Additionally, you could hyphenate headings.

edit: And fluid typography might be something to look into. Currently, you seem to have a single breakpoint where font size is adapted. That does not work well on larger phones.

I rarely use any of the popular CSS frameworks. Unless you are making a small(ish) website where the styling is not important, it is actually more work to customize an existing framework than to just use CSS yourself.

But what I do use sometimes is a CSS reset like https://github.com/necolas/normalize.css

And what I also use is this CSS boilerplate: https://github.com/frontaid/natural-selection (Disclaimer: I created it because I wanted to avoid the repetitive work of writing out all the selectors).

I'm working on a CSS framework without any styling (!). It is a collection of selectors and meant to be used as a clean CSS boilerplate. Thus it can jump start your next project or design system.

https://github.com/frontaid/natural-selection

> Isn't DNT deprecated [...]?

No https://www.w3.org/TR/tracking-dnt/ The problem with DNT is not its specification but that the largest chunk of the industry does not adhere to it. Instead they nag their users with annoying cookie overlays.

> Isn't DNT [...] just not supported in browsers any more?

It is supported by all common browsers except Safari: https://caniuse.com/do-not-track

There are some nice examples in that post. One other example would be to respect the DoNotTrack setting of your browser. You don't need to load any tracking scripts if DNT is enabled. That saves bandwidth and has a small effect on your page's loading times.

We recently blogged about that on the example of Matomo (Google Analytics alternative). The main part is the following code:

    if (navigator.doNotTrack !== '1') { /* load script */ }

Here is the link if you are interested in the details: https://frontaid.io/blog/matomo-dnt-do-not-track/

Not sure about that. Normal sails "bend" away from the wind and thus have a much stronger lift. This concept's sails are "beant" outwards and would lose much of the wind's force. This source [1] states that "The futuristic sails are like airplane wigs using the same level of aerodynamic technology" which would imply that they absolutely do not "work just like normal sails".

[1] https://www.maritime-executive.com/article/swedish-collabora...

The article does not really explain how it works. From my naïve understanding, those wings sails do not seem to be ordinary wings but are shaped like the ones in airplanes. When they are rotated to the right angle given the wind direction, the vessel is pulled forward. The topic reminds me of the Flettner rotor [1] and other wind-assisted propulsion systems [2].

[1] https://en.wikipedia.org/wiki/Flettner_rotor & https://de.wikipedia.org/wiki/Flettner-Rotor

[2] https://en.wikipedia.org/wiki/Wind-assisted_propulsion