The web is constantly evolving, and CSS is no exception. The last few years have given us widely supported features such as Grids, Variables (Custom properties) and New viewport units – among other improvements.

New features are fine, but become great only when a sufficient amount of users have access to browser versions that support them. Let's look at three exciting additions that are now ready for production.

Container Queries 🖼️

As of February, Container queries for size are finally supported in all major browsers. Rather than relying solely on the viewport size of the whole viewport (browser window), container queries allow elements to adapt based on the size of their parent container.

Responsive design is typically implemented using a media query that checks the viewport width. In the code below, elements with the .panel class will flow vertically on small screens, and horizontally on screens larger than 500 pixels.

The example above might work well if the panel always uses the same amount of space on the page. But imagine the same panel is rendered in many different settings, as is often the case with reusable components. With container queries, we can query the actual amount of available space.

Crocodile Signs 🐊

Did you notice the «crocodile signs» in the last example? The new Media Range Syntax is also a welcome addition to CSS! These mathematical operators a more intuitive way to express ranges in conditions, and can be used with media queries as well as the new container queries.

The new syntax also supports more complex queries. Take this example:

Now, you can do this instead:

Subgrids #️⃣

CSS Grids has enjoyed wide browser support for a while now. But if you've been using Grids, you might have missed one specific tool – subgrids. Subgrids solves the issue where you want a grid item to become a grid container itself, but use the grid tracks of its parent.

Confused? For details on why we need CSS Grids, I recommend this article by Ken Bellows. If you've already encountered this issue, I have good news for you. Subgrids are now supported by all major browsers!

This also goes for display: contents, which is useful for telling the Grid algorithm to ignore certain elements. Just don't use it for buttons yet!



Looking Ahead

If you think 2023 has been a good year for CSS, stay tuned! Next time, we'll dive into what you might expect in 2024 – including nested CSS, improved scoping and a new «parent selector»!

3 New Additions to CSS in 2023

«Jeg vil lese mer, men har ikke tid». Det er lett å kjenne seg igjen i, men vet du hvor lang tid du må sette av for å komme gjennom boka du vil lese? Og visste du at du kan øke lesehastigheten uten å gå på kompromiss med forståelsen?

Jeg synes det er motiverende at det finnes teknikker for å lese fortere og forså mer av innholdet, selv med små grep. Ved å vite lesehastigheten kan du finne ut hvor mye tid du må sette av for å komme gjennom en bok på en uke eller måned.

Slik finner du din lesehastighet

Ta en bok – finn noen sider med mye tekst, marker startpunkt

Les i 2 min – normal lesehastighet for full forståelse, marker stoppunkt

Del antall linjer du leste på 2 – Gir antall linjer per minutt

Finn antall ord per linje – Ta et gjennomsnitt av 2-3 linjer (de fleste bøker har 10 ord per linje)

Gang antall ord per linje med antall linjer du leste = ord per minutt

Da får du din normale lesehastighet – din baseline! Samme øvelse kan brukes for å se hvor mye lesehastigheten din øker når du tar i bruk leseteknikker 🌟

Estimer tiden du bruker på en bok

Nå som du vet din lesehastighet kan du regne på hvor lang tid du vil bruke på å fullføre fagboka du har hatt ambisjon om å lese det siste året. Bruk gjerne mediantallet på antall ord i en bok på 64 000 for et grovt estimat.

Minutter du bruker på en bok = antall ord (64 000) / din lesehastighet

Minutter per dag for å fullføre en bok på en uke = Minutter du bruker på en bok / 7 dager

Bare med 10 minutter daglig lesing får man lest overraskende mye over tid. Om du vil lese flere bøker kan du sette av mer tid hver dag eller bruke teknikker for å lese fortere 🤩

Tips for å lese fortere

Bruk en visuell peker 👆 For eksempel fingeren eller datamusen for å understreke det du leser uten å røre papiret. Øynene følger bevegelsene og siden syn og berøringssansene er så tett sammenknyttet styrker de hverandre. Dette enkle tipset gjør at de fleste leser 25-100% raskere.

Var gøy å se hvor mye fortere det gikk når man bare brukte fingeren til å guide seg langs hver linje

– Sitat fra vi testet leseteknikker i faggruppa Leseinitiativet UX

Les fortere enn du normalt gjør med mer fokus over kortere tid ⏲️ Ofte har de som leser fort bedre forståelse fordi de må fokusere mer.

Lytt til musikk uten tekst 🎵 gjerne klassisk eller barokk

Unngå å si ordene høyt inni deg 🤐 Når vi leser uttaler vi ofte ordene høyt inni oss, men vi klarer ikke å snakke like fort som vi oppfatter betydningen av ordene vi leser så det sinker lesehastigheten. Du kan distrahere munnen ved å nynne, tygge tyggis, telle eller bruke en fikseringsmetode der man fokuserer på tre punkter på hver linje fra starten, midten og slutten av setningen.

Vil du lære mer om speed reading kan jeg anbefale noen videoer ✨

Jim Kwik om hvordan teste lesehastighet og tips for å lese raskere og bedre. Se video på youtube

Jim Kwik om hvordan lese fortere og forstå mer. Se video på youtube

Tim Ferris om hurtiglesing. Se video på youtube





Dette er et drypp fra faggruppen Leseinitiativet UX 📚 Håper du blir inspirert til å lese en fagbok i julen og starte det nye året med spennende faglige diskusjoner om noe nytt du har lært! 🎄

Finn din lesehastighet!

One of the best things about Sanity is the balance between flexibility and default features. They deliver a great product out of the box, but to unleash the full potential of Sanity, you should spend some time customizing it to make it even better. In this article, I will show you how to create a simple custom input component that provides a visual representation of icons, enhancing your studio experience.

Data input in Sanity

Sanity provides different solutions for the user to input and change data. These out-of-the-box solutions gives the user good alternatives, but in some cases you may want something extra from your input component. Maybe you want to query and show data from a third party API? Or maybe your editors just want to see what they're choosing when they're looking for a visual component to show?

The basic input component

Let's say you have a component in your frontend that uses an Icon, and you want the editor to be able to pick this icon in Sanity studio. The icon can be added with a list of options in Sanity, doing something like this: 

Which gives you a list looking like this: 

Well, this does the job, but it's also a bit of a hassle for the user to know what the icon they're choosing actually looks like. To be sure they would have to visit the page showing the icons before choosing the icon. Let's fix this by making a custom input component!

Making a custom input component with Sanity UI

Sanity UI is a React library made by Sanity that you can use when making input components. It offers primitives and some components. Using the Autocomplete component it's possible to render a React element, and we can use this to show our icons in the list. The Autocomplete component also provides a much better search functionality.

Let's start by defining the AutoComplete component:

Add the input component to the field as a component:

And we end up with a visual representation of the icons!



To actually change the value we need to add logic to set and unset the value when changed: 



And there we go! We now have a fully functional input component for our icons in Sanity studio.

Make your own input components in Sanity!

Society and programming has something fundamental in common; the stack. 

In software we say that the front end is dependent on logic layers and a back end and data base. 

In society our justice system runds on the legal institutions, which run on people, which make stuff with language, and that language is implemented in the logic and database architectures of the brain - the wetware.

But the towers of logic and interconnection has to be programmed, implemented and built. It doesn't come from nothing. Todays article is about the very mechanism that makes it all possible; and how we can use it to do natural language programming. 

I give you:

The declaration

Declarative: A sentence that speaks something into being by saying it is so. 


-Congratulations, you now have a PhD.

-This is a receipt of your purchase

-A counts as B in this context

let willYou = (answer) => {
if (answer === ‘marry me’) {
return ‘Together, for eternity.’;
} return ‘The heart waits, ever hopeful.’;
}



Limits to life
There are some fundamental limits to life; a limit to how much stuff one can have, how much one can move and change, a limit to our energy, and lastly a limit to how much we can compute and think.

Each of these limits have been overcome to some extent in various revolutions, like the industrial revolution, where our ability to use energy and put stuff together was multiplied tenfold from learning how to harness steam to make machines. It was the intelligentsia of that time, the engineers who really benefited form this transformation — for normal people much of that wealth was inaccessible.

Now we are part of our own revolution. The information revolution, where it is the computation and thinking that has been put into the logic of the hardware. There have been some attempts at making the power of computation available to more people, but still for the most part the power of definition, of declaring new pieces of logic into reality, has been reserved the priesthood of the mathematically minded coder. The encoder of the logic, the programmer.


It is normal, I declare…
But speaking, and making things up, is not something that is generally reserved for a small group of people. Just like we kan still knit by hand, even though there are machines that do it much faster, programming is part of a human experience that everyone can have — but instead of making a computer program, we write letters, make deals, define relationships and the like. Programming, or making social and written reality is part of who we are.

A large part of the reason why it was difficult to program before, was that there was not much incentive for the programmers to make powerful interfaces for non- programmers. Interfaces that would in any case be more domain specific and more limited than the tools they themselves use. The most powerful example is “Hypercard”, a program that for a long time was part of every mac, where cards could be hyperlinked to make small programs.





Of course now, there is a proliferation of no code tools, and these have hitherto had some success — but has not been seen, perhaps, as “real coding.”

No coding tools float at the top of the “stack” but without robustly connecting to what is below — it is not real coding. It is my impression that to truly connect, we need a text layer to be at the top too.



The text interface
As an affordance generative artificial intelligence systems have the ability to accept declaratives as an input, while at the same time speaking in a natural language to the user. This means that the task of programming, of putting logic into a computer system as is, has been lifted out of the realm of being merely an expert system, and is now accessible to a lot more people.

There is still a barrier to programming expert systems. This is because programming intrinsically is a hard skill. We recognise this because learning to speak and think in itself is hard — formulating complete ideas, and saying what is needed is indeed hard. Therefore, no matter how easy programming will become, we will still never be free of the demand to express what we actually want to happen — and for that reason we will still need professional programmers.



Generativity itself
Generativity is the ability of a combinatorial system to produce novel outputs or meanings based on known elements. To understand this we can contrast marbles and lego. No matter how how many ways you recombine your marbles, they will not make a box for your pencils. They have combinatoriality, but their effects will not change much. However, with lego you can make new and useful structures, even though you are only recombining old elements again and again. This is the difference between generativity and mere combinatoriality.

Programming and natural language are both generative systems. The input of building these systems is the declarative for both, and then there is the grammar or logic of combining these. However, there are other uses that are somewhere in between making a program and making something happen.



Smaller ideas for things to happen with
This is something we can see with the “advanced data analysis” tool that comes with openAI. With this you can ask it do to calculations for you, or explore in depth something that can only be done with some computation. For instance, if you have an xlsx file, a spreadsheet, it can go through it to do statistical analysis, alphabetise and sort, or make graphical representations of the data.

But is this programming? Yes, in the sense that you are providing a language input, that is then turned into an artificial logical structure, capable of producing novel inputs.

Traditionally programs are larger structures, systems of interdependent logical operations — but with the advent of, so to speak, just in time programming, we could have a more nuanced idea of what programming can be for us.



Not new, but new.
Has not declaratives been part of our interfaces before? In domain specific instances, there can be examples, such as with calculator or calendar functionality, where you as the user do some defining of your own. But these systems have not been generative, they cannot combine elements in a meaningful way.

I think it is impossible to say where this will take us. We already start seeing that generative programs have started cropping up. Some of these are image makers, some make GUI, and others music — but we have yet to see the truly robust companion that elevates your mental tasks to the next levels, and lets you define programs that work on your behalf to make your life easier.

Educate, elevate.
As we make these systems, we will need to educate the user in how to use them. 

For now, let us only stop to ask “What kinds of things must a user learn to make use of generative text interfaces that accept declaratives as an input?”. An interesting answer to this was provided to us by the computer engineer, programming language author and physicist Stephen Wolfram on his fourth appearance on the Lex Fridman podcast. 

Wolfram made the point that a general user might not know how to do things, but rather more that it could be done, and also what the output was. For instance, a user might have some data on the profile of their customers, and also have their purchasing information. Given this, what kind of analysis would produce a better understanding of targeted marketing? Maybe… regression analysis?

“Can’t we just ask the llm analysis tool what to do?” Sure, it might provide some answers, but this is only a second order approximation of what you want to do. Without knowing what kinds of computational tasks might be performed, it will be hard to both come up with the idea to use the tool, and also to robustly understand the results.

While not everyone will have the same needs for using computation like this in their everyday life, those who have this competency in computation, and those who lack, will create a class distinction — a new computer literacy gap.

11-Dec

Today's posts

3 New Additions to CSS in 2023

Finn din lesehastighet!

Make your own input components in Sanity!

Let there be "Hello world!"