@bramus@samdutton interesting. Is there a difference between scheme and protocol? I always called protocol to the https:// or ftp:// part (including the ://)
Ooooh. Another idea for a new project I'll never finish - inspired by a post from @chriscoyier about new.css - a no-class CSS "framework"!
I've seen a few of them around and I like them. It'd be fun to build my own. I could build color-scheme into it, and have it respond to prefers-contrast as well as prefers-color-scheme.
I recommend not publishing on Medium, for starters.
Full disclosure, I opened the article to see if its 2024 #accessibility recommendations were the same as the 2004 or 2014 recommendations (headings, alt text, contrast, etc.) but now I cannot be sure what new insights it contains. #a11y
@aardrian Medium tracks the free article reads using cookies. To read the article even after you've hit the limit, open the link in a new private window, and you'll be able to read the article.
@aardrian I repost my articles on Medium behind a paywall (setting my blog as canonical, where the article is free and more accessible). If people prefer medium as a platform (it's pretty) and they are willing to pay to read even when the article is freely available on my blog, who am I to stop them? It's a nice extra income.
@NatureMC If I recall correctly, the publishers don't get paid for unregistered user reads, so if I wasn't going to get paid anyway, at least someone read it. (Yes, I am a small publisher at Medium and still share this trick.)
@NatureMC I must be a weird person, but I actively recommend people reposting on Medium (not posting directly there, but resharing). They allow canonical URLs, and when you hit a minimum number of subscribers, they let you monetize the articles. Cross-posting on Medium pays for my personal blog hosting, domain, and all the other silly web pet projects I have. So I can't complain.
Inspired by a question by @lea, I created a progressively enhanced component that turned CodePen links into cards with CSS, and into embedded demos with JS. This article explains how I did it.
If you prefer other reading platforms, the article is also available on:
@simevidas@lea The demo I used does not have JS, so there's no difference between JS enabled and disabled. A more JS-oriented codepen demo will load the <iframe> and then show a blank when hitting the "run" button, providing a poor experience. But even with my non-JS demo, the CodePen embed depends on JavaScript to interact with the HTML/CSS/JS/Result tabs, so that functionality won't be available either. In that case, keeping the link (as text or a card) may still provide a better experience.
@simevidas@lea@5t3ph I get that. For HTML+CSS-only demos the iframe works best... but demos that are dependent on JavaScript will not run in an iframe either. So why have an iframe at all? Wouldn't actually the iframe provide a worse experience for the person?
My component is more theoretical than practical (and probably not that great either way), and it casts a net over all the CodePen links, even the ones that don't have JS. But developers may not know if those demos have JS or not.
I came to dislike the word "user" in software development and IT. It feels impersonal and dehumanizing even when it is the correct term (they are using our software). It turns them into a weird entity that you don't really have to care about. I prefer to use "person" or "people."
Which may not me the correct term anyway as many actors that will interact with our products won't be people or human anyway. It just makes it easier for me to keep the person in mind when designing/developing things.
What happens when you share a demo online? Today's comiCSS tries to answer that question with a pinch of humor. Check the cartoon at https://comicss.art/?id=108