#css4 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #css4, aggregated by home.social.
-
BBC sites share a common layout with identical styling and fonts... except for the lowercase "a".
Someone made a font variant just for Bitesize, changing its A to be more kid-friendly!
https://www.bbc.co.uk/news
https://www.bbc.co.uk/bitesizeToggle between. They're identical, except for the double-storey |a| on News, and Bitesize sporting a single-storey |ɑ|.
https://en.wikipedia.org/wiki/A
It's implemented with CSS font-feature-settings:
https://developer.mozilla.org/en-US/docs/Web/CSS/font-feature-settings
-
#Development #Proposals
Searching for a new CSS logo · It’s time for a change and some fresh proposals https://ilo.im/160cew_____
#Logo #CSS #CSS3 #CSS4 #CSS5 #CSS6 #Evolution #Community #WebDev #Frontend -
New Status: Totally Not Bikeshedding the new #css4 logo that will probably use csspink, and not hotpink.
-
-
I would love to see proper versioning on CSS. I still remember the release of CSS3 and it's sad, that this moment just happened once in the 18 years I do this job now.
At the same time other language had multiple ground breaking releases.
CSS isn’t developing in a slow way. Not a bit. But you can't put the finger on a feature set. You can't hire for a specific feature set.
"10 years of CSS experience" can mean, that border-radius is the most exciting thing that person ever did and starts to cry if they see the clamp syntax.
"1 year experience with CSS 5" on the other hand would be pretty clear.
https://www.smashingmagazine.com/2024/08/time-to-talk-about-css5/
-
A really interesting read.
“Naming is always hard, yet it’s just something we have to do in CSS to properly select things. I think it’s time we start naming [CSS releases] like this, too. It’s only a matter of time before “modern” isn’t “modern” anymore.” — Geoff Graham
https://www.smashingmagazine.com/2024/08/time-to-talk-about-css5/
-
#Development #Challenges
It’s time to talk about ‘CSS5’ · What’s the optimal way to describe CSS’s evolution? https://ilo.im/15zpet_____
#ModernCSS #Naming #CSS3 #CSS4 #CSS5 #CSS6 #W3C #WebDev #Frontend #CSS -
You know what else is happening in CSS? An effort to define #css4
We released an RFC a while back to see if our intuition for what CSS4 should be aligns with what web devs think.
https://github.com/CSS-Next/css-next/discussions/92
It would be useful to have more people to argue this idea, for or against, or argue about whether a feature belong in CSS4 or 5 or even later ...
-
#Development #Previews
CSS3? Pfff. · CSS4 and CSS5 are coming, and CSS6 is the future https://ilo.im/15ywmr -
#Development #Proposals
Initial CSS level categorization · How we could better organize the evolving landscape of CSS https://ilo.im/15ysr9_____
#CSS #ModernCSS #Versioning #CSS3 #CSS4 #CSS5 #WebDev #Frontend -
I started to create a new #HTML5 and #CSS4 boilerplate, mainly for my personal use. I'm aiming for the following:
1. #A11y / #Accessibility support / #ARIA
Often forgotten. This time, it's deeply personal, it's now a must for me.
2. Avoid #IconFonts, use #SVG instead.
Same as the first item, but deserves to be mentioned separately.
3. #Microformats support
For #IndieWeb, #Webmention, #Fediverse, and related support.
4. Use the ‘rel’ attribute where appropriate
Same as those in the previous items.
5. Styling using style classes only. Not microformats classes, as those can be reused for other purposes.
I used to, and I also noticed others doing the same, use microformats classes for styling. And then just override it if the same microformat class is reused elsewhere. Makes everything confusing; and hard to track, especially if you're using someone else's theme/template/skin.
6. Avoid using advance CSS selectors as much as possible; without resorting to multiple styling classes.
Multiple classes, as well as, advance CSS selectors, can and do slow down rendering. It's easy to fall into this trap because it makes things easier. I'm guilty of it.
7. Drop deprecated stuff; and only use future-proof ones.
Like backwards compatibility with anything IE.
Also, many CSS resets are actually no longer needed.
8. Less JavaScript as possible.
If something can be done without scripts, use that method. Everything else is optional. The site should work with or without scripts.
Remember, we're creating a boilerplate that we can reuse. We build on top of it.
9. As semantic as possible.
For example, use “article”, “main”, “nav”, “aside”, “section”, where applicable, instead of “div” with a “role” and/or “id/class”.
We requested for those when HTML5 was being developed, but only few actually use it (especially blog templates).
10. BEM methodology
---
I hope those are everything worth applying in this journey.
Some notes:
* For #SchemaOrg, I prefer #JSON than embedding it in the HTML code through classes or itemprop.
* I understand there are a few with some of the goals I listed already implemented, but I prefer to learn along the way, not “how to use” this and that. -
I started to create a new #HTML5 and #CSS4 boilerplate, mainly for my personal use. I'm aiming for the following:
1. #A11y / #Accessibility support / #ARIA
Often forgotten. This time, it's deeply personal, it's now a must for me.
2. Avoid #IconFonts, use #SVG instead.
Same as the first item, but deserves to be mentioned separately.
3. #Microformats support
For #IndieWeb, #Webmention, #Fediverse, and related support.
4. Use the ‘rel’ attribute where appropriate
Same as those in the previous items.
5. Styling using style classes only. Not microformats classes, as those can be reused for other purposes.
I used to, and I also noticed others doing the same, use microformats classes for styling. And then just override it if the same microformat class is reused elsewhere. Makes everything confusing; and hard to track, especially if you're using someone else's theme/template/skin.
6. Avoid using advance CSS selectors as much as possible; without resorting to multiple styling classes.
Multiple classes, as well as, advance CSS selectors, can and do slow down rendering. It's easy to fall into this trap because it makes things easier. I'm guilty of it.
7. Drop deprecated stuff; and only use future-proof ones.
Like backwards compatibility with anything IE.
Also, many CSS resets are actually no longer needed.
8. Less JavaScript as possible.
If something can be done without scripts, use that method. Everything else is optional. The site should work with or without scripts.
Remember, we're creating a boilerplate that we can reuse. We build on top of it.
9. As semantic as possible.
For example, use “article”, “main”, “nav”, “aside”, “section”, where applicable, instead of “div” with a “role” and/or “id/class”.
We requested for those when HTML5 was being developed, but only few actually use it (especially blog templates).
10. BEM methodology
---
I hope those are everything worth applying in this journey.
Some notes:
* For #SchemaOrg, I prefer #JSON than embedding it in the HTML code through classes or itemprop.
* I understand there are a few with some of the goals I listed already implemented, but I prefer to learn along the way, not “how to use” this and that. -
I started to create a new #HTML5 and #CSS4 boilerplate, mainly for my personal use. I'm aiming for the following:
1. #A11y / #Accessibility support / #ARIA
Often forgotten. This time, it's deeply personal, it's now a must for me.
2. Avoid #IconFonts, use #SVG instead.
Same as the first item, but deserves to be mentioned separately.
3. #Microformats support
For #IndieWeb, #Webmention, #Fediverse, and related support.
4. Use the ‘rel’ attribute where appropriate
Same as those in the previous items.
5. Styling using style classes only. Not microformats classes, as those can be reused for other purposes.
I used to, and I also noticed others doing the same, use microformats classes for styling. And then just override it if the same microformat class is reused elsewhere. Makes everything confusing; and hard to track, especially if you're using someone else's theme/template/skin.
6. Avoid using advance CSS selectors as much as possible; without resorting to multiple styling classes.
Multiple classes, as well as, advance CSS selectors, can and do slow down rendering. It's easy to fall into this trap because it makes things easier. I'm guilty of it.
7. Drop deprecated stuff; and only use future-proof ones.
Like backwards compatibility with anything IE.
Also, many CSS resets are actually no longer needed.
8. Less JavaScript as possible.
If something can be done without scripts, use that method. Everything else is optional. The site should work with or without scripts.
Remember, we're creating a boilerplate that we can reuse. We build on top of it.
9. As semantic as possible.
For example, use “article”, “main”, “nav”, “aside”, “section”, where applicable, instead of “div” with a “role” and/or “id/class”.
We requested for those when HTML5 was being developed, but only few actually use it (especially blog templates).
10. BEM methodology
---
I hope those are everything worth applying in this journey.
Some notes:
* For #SchemaOrg, I prefer #JSON than embedding it in the HTML code through classes or itemprop.
* I understand there are a few with some of the goals I listed already implemented, but I prefer to learn along the way, not “how to use” this and that. -
I started to create a new #HTML5 and #CSS4 boilerplate, mainly for my personal use. I'm aiming for the following:
1. #A11y / #Accessibility support / #ARIA
Often forgotten. This time, it's deeply personal, it's now a must for me.
2. Avoid #IconFonts, use #SVG instead.
Same as the first item, but deserves to be mentioned separately.
3. #Microformats support
For #IndieWeb, #Webmention, #Fediverse, and related support.
4. Use the ‘rel’ attribute where appropriate
Same as those in the previous items.
5. Styling using style classes only. Not microformats classes, as those can be reused for other purposes.
I used to, and I also noticed others doing the same, use microformats classes for styling. And then just override it if the same microformat class is reused elsewhere. Makes everything confusing; and hard to track, especially if you're using someone else's theme/template/skin.
6. Avoid using advance CSS selectors as much as possible; without resorting to multiple styling classes.
Multiple classes, as well as, advance CSS selectors, can and do slow down rendering. It's easy to fall into this trap because it makes things easier. I'm guilty of it.
7. Drop deprecated stuff; and only use future-proof ones.
Like backwards compatibility with anything IE.
Also, many CSS resets are actually no longer needed.
8. Less JavaScript as possible.
If something can be done without scripts, use that method. Everything else is optional. The site should work with or without scripts.
Remember, we're creating a boilerplate that we can reuse. We build on top of it.
9. As semantic as possible.
For example, use “article”, “main”, “nav”, “aside”, “section”, where applicable, instead of “div” with a “role” and/or “id/class”.
We requested for those when HTML5 was being developed, but only few actually use it (especially blog templates).
10. BEM methodology
---
I hope those are everything worth applying in this journey.
Some notes:
* For #SchemaOrg, I prefer #JSON than embedding it in the HTML code through classes or itemprop.
* I understand there are a few with some of the goals I listed already implemented, but I prefer to learn along the way, not “how to use” this and that. -
I started to create a new #HTML5 and #CSS4 boilerplate, mainly for my personal use. I'm aiming for the following:
1. #A11y / #Accessibility support / #ARIA
Often forgotten. This time, it's deeply personal, it's now a must for me.
2. Avoid #IconFonts, use #SVG instead.
Same as the first item, but deserves to be mentioned separately.
3. #Microformats support
For #IndieWeb, #Webmention, #Fediverse, and related support.
4. Use the ‘rel’ attribute where appropriate
Same as those in the previous items.
5. Styling using style classes only. Not microformats classes, as those can be reused for other purposes.
I used to, and I also noticed others doing the same, use microformats classes for styling. And then just override it if the same microformat class is reused elsewhere. Makes everything confusing; and hard to track, especially if you're using someone else's theme/template/skin.
6. Avoid using advance CSS selectors as much as possible; without resorting to multiple styling classes.
Multiple classes, as well as, advance CSS selectors, can and do slow down rendering. It's easy to fall into this trap because it makes things easier. I'm guilty of it.
7. Drop deprecated stuff; and only use future-proof ones.
Like backwards compatibility with anything IE.
Also, many CSS resets are actually no longer needed.
8. Less JavaScript as possible.
If something can be done without scripts, use that method. Everything else is optional. The site should work with or without scripts.
Remember, we're creating a boilerplate that we can reuse. We build on top of it.
9. As semantic as possible.
For example, use “article”, “main”, “nav”, “aside”, “section”, where applicable, instead of “div” with a “role” and/or “id/class”.
We requested for those when HTML5 was being developed, but only few actually use it (especially blog templates).
10. BEM methodology
---
I hope those are everything worth applying in this journey.
Some notes:
* For #SchemaOrg, I prefer #JSON than embedding it in the HTML code through classes or itemprop.
* I understand there are a few with some of the goals I listed already implemented, but I prefer to learn along the way, not “how to use” this and that. -
✩ A CSS 2024 snapshot, compiled by Sebastian Zartner of the W3C CSS Working Group.
https://github.com/w3c/csswg-drafts/issues/9770 #webstandards #CSS #css4 #csswg
-
Oh! #oklch is now supported in all major browsers. That was fast, within the year.
⇉ https://caniuse.com/?search=oklch
I guess it is now safe to trim down #CSS / #SCSS files to just #hwb and oklch colours.
-
Today's lunch video is "CSS4 Is Coming (Not a Clickbait)" — "A detailed explanation of why #CSS4 is coming even though we were told that it will never happen, what it might include, and what all of this means for you." #css https://www.youtube.com/watch?v=j4mOm1qic7k
-
#Development #Outlooks
CSS4 is coming (not a clickbait) · We were told that it will never happen, but it will https://ilo.im/15i0ls -
With #CSS4 coming out we’ll all have to upgrade our footer verified certification gifs.
—————————
| CSS 4 | HTML 6 |
————————— -
The #CSS4 image() function is really cool! It enables us to inject portions (fragments) of images, change image direction (flip), provide solid color fallbacks & more.
https://12daysofweb.dev/2022/css-image/ -
@craiggrannell My book is a project I've been working on for years now, but stuff kept happening and I also had bouts of laziness. It's not a second edition or anything, I just have to finish the manuscript.
On the positive side about 1/3 already exists in draft form. On the negative side, I have to re-outline the remainder because of the huge #css advances in the last year.
And there's the emerging definition of #css4 to keep track of ...
