Like it says, <1kB minified and gzipped. But 9.5kB only minified, i.e. The css is highly repetitive so gzip is able to do a lot.

I know it's still small, but I'd be tempted to extract just the rules I wanted. Very nice regardless.

Why are schemas strings?

It would seem much more natural to make them JSON structures since they're almost that anyway.

Strings make it easy to define as configs and can be implemented uniformly across different languages. In world of microservices, a Python and a Go service can easily share the schema definitions via some config files. Also strings provided the best minimalist syntax.

then you might as well use jsonschema.

Indeed, there seems to be no reason to use this instead of JSON Schema.

I use and can recommend the chrome extension from https://sessionbuddy.com/

Even if you don't use it actively, it periodically saves the state of your windows and tabs (all locally), so you can restore sessions from months and years ago.

SessionBuddy is amazing. It is the only thing I am missing from chrome.

Although it is not open-source, it has customizable exports in a variety of text formats . Too tired to write more, but if you use chrome check it out.

Session Buddy is great though I moved to Bookmark OS as it was easier to share sessions between browsers https://bookmarkos.com

Try mine! https://github.com/gunn/pure-store

Super simple, 100% test coverage, 100% typesafe if using typescript, absolutely no boilerplate.

Edit: Just checked out the code. This really looks like an event emitter with Immer. Is that fair to say? I totally dig the simplicity of it.

There's quite a lot of code in the packages dir - 76,000 lines of typescript.

It was all added in the first commit 45 mins ago. Why would they hide their commit history?

Also I found this funny - comments in package.json:

  "//": "Look! No deps!",
  "dependencies": {},
  "///": "Only used for static type checking",
  "devDependencies": {

> Why would they hide their commit history?

I'm the only author at the moment. The project started off years ago as a side project without any commit history, and what little history there was over the years wasn't very thorough. Prior to the open sourcing I've been working on it internally and still did pretty massive diffs that changed thousands of files, still without good history. It's something I'm working on though and will obviously need to be accountable for now that the project is public.

Thanks for the reply. It looks well organized now. I'll be keeping my eye on it.

Looks excellent. One thing I'd question is why it should deviate from html / css like it does - why choose corners: 4px over border-radius: 4px?

Thanks! I've actually been putting some thought into that exact question with a lot of things (i.e. using Markdown-style identifiers for things like Headings [#, ##, ...])

I think what I'll probably do is support both the raw CSS/HTML keywords as well as a subset of more human-readable keywords and presets (my gripe with border-radius is that more often than not when I use border-radius, I don't even have any borders, what I really mean is corner radius)

Another example is box-shadow: I think the syntax for this CSS feature is horrible for people who don't use CSS all the time. I think some presets like `shadow: soft` would be nice in addition, where

  shadow: soft  |-->  box-shadow: 0px 2px 4px rgba(0,0,0,0.1)

I'd definitely hope browsers could encode them for example to allow canvas.toDataURL("image/flif")

Like I said: they shouldn't need to encode images very often, and that doesn't seem like all that much of a common use case (nor would it preclude a browser from implementing decoding and just not supporting FLIF for encoding-dependent functionality like that).

To give them some credit: it's not sent when in incognito mode.

How thoughtful of them!

In ruby you are always calling a method, you can't access a property from outside a class with normal syntax.

Ruby doesn't have properties except as an alias for a certain pattern of methods, and in languages that do have properties they are almost invariably just a layer over calling getter and setter methods.

You seem to confusing “properties” with “data members” which, it is true, Ruby does not permit external access to except via method calls. But properties are a way of calling methods with a syntax that looks like direct member access, not actual direct member access.

Excellent clip thank you.