snowcode

I'm not a CSS guru, and as a result I've had to do things in a very very simple way. Currently the simplest solution for me, involving no additional server side frameworks is to just "compose" the static html on the server or at build time. So a "base" class of re-usable styling could easily be a static string. I wouldn't start by thinking about inheritance, I'd only consider it if and when I actually hit that problem. It's often just a single edge case.

So my code is generated server side, using something Jam-stacky like Hugo or Cloudflare pages, (with a cloudflare worker that dynamically replaces or modifies a button ...in that very one specific edge case.)

Your existing example needs to be made more complex though because I'd just use standard CSS for that, for example button.submit { color:blue) button.submit.critical { color:red }

i.e. all my buttons are blue, except that one special case where I have a "critical button" and we "override" the color to "red". I simply flag it with the extra semantic attribute and style it accordingly.The button will clearly be red because the css for red has a higher specificity, but it also "reads" easily as such if the css is properly crafted. Of course it's possible to write Semantic CSS that no-one can follow; and the same goes for Tailwind.

The problem with CSS though, is unfortunately the most common approach is to add a new DIV, and slap on a CSS definition that ignores all inherited styling. So, unless you're going to re-write everything a big corporate ball of mud is made up of, Tailwind works better here, since it's PURPOSE is overriding and ignoring everything. He says ..ducking!

Is this really an argument for Tailwind though? isn't this just an observation that both approaches seem to converge when the systems get very large and complex? At which time the work and effort is the same, except ..in the case of Tailwind you're using a made up syntax, and when writing similar amounts of code using CSS you can do it using the CSS standard. The key difference is that you would have to hope that Tailwind outlives CSS as a standard in terms of tooling and language support and continuing improvements (evolution) over time.

...the entire cast of Glee! bwaahahaha....

Is this a code highlighter I can use on my own jamstack blog?

another update: my suggestion of privately sending bots you want to "allow" to scrape your site, would make it trivial to ban bad bots. No guid, no enter.

Bots that flood your site, effectively DDOS the site, are no different to hackers trying to DDOS your site and would be dealt with as an illegal hacking attempt .. not a "legal" bot configuration issue.

It instantly puts all traffic into 2 buckets, legal and illegal. Versus 3 buckets of legal, badbot and illegal.

tools like "scrapeshield" et al already exist, so my suggestion would allow those vendors to make their scrapeshields even more focused, and allow me to build my poor man's version of those tools, since I dont want to pay for anything. even if it's $5 a month, or $5 a year per domain for some anti-scraping that's a deal breaker for me, since I'm managing hundreds of domains.

agreed; and it's the reason for this post. I have a cloudflare worker (code I've written) that tracks requests for robots.txt and then tracks if the requestor's session honours the robots allow and dissallow and forces the correct behaviour, i.e. robots that request files from a dissalow path my worker code returns 401. The problem is that I can't track bot behavior when good bots "continue" their session after requesting robots.txt (with a brief pause) because by then they probably (mostly do, according to my logs) make subsequent requests using IP addresses (or agents) from a pool, resulting in requests coming in from multiple IP addresses.

i.e. no way to manage or track bot sessions, and thus no way to monitor if they are adhering to the robots.txt allow/dissallow.

For now; the only way for me to be able to remove bad bots from my site, is to stick exclusively to bots that I can get a reliable set of IP addresses from; at this juncture that's just Google and Bing's bots, roughly, and then ignore the requests for robots.txt.

My suggestion, (this ycombinator post), is to have a reliable way of tracking robots, that's easy for low tech (amateur) bot builders to adhere to, and thus very efficiently block bad bot behaviour without punishing good bots, and allow site owners to be fully in control of pay for, and serving traffic to only the visitors they want on their sites.

update: forgot to say .. my code also blocks requests from bots that don't read robots.txt first. The tricky part of course is not accidentally tagging a real user, or a user using some genuine accesibility assistance tool as a bot. someone using curl for example; I dont mind a false negative and blocking his/her request, because if I want to make parts of my site available programmatically I would create an API for the bits that should be available programmatically, which currently is nothing.

more thoughts; Invert allow/disallow

Robots.txt should be inverted, with everything disallowed by default, and only allowed paths to be configured. Requiring site owners to explicitly list dissalowed secret folders is ludicrous. How this became de-facto is hard to fathom. If a site owner wants to allow everything then he/she should have to explicitly add a global allow.

A quick search on github shows more than 21K projects with IConsole interfaces, mmm?

Call for review : Proposed .NET `System.Console` abstraction called IConsole, that will enable interoperability between open source console library and app developers.

so many devs create some type of IConsole to remove the static dependancy to `System.Console` when refactoring I thought it would be great if there was a 'known' interface that we could use each time instead of whipping one up each time

But I can write my own System.Console wrapper, it will be done in less than 40 lines?

It's not about writing a wrapper, that is very easy. It's about setting a standard of interoperability between everyone that uses this as their interface. Since you would have started by writing your own interface, and then also writing something that implements that interface, why not save yourself the 2 or 3 hours you will be sidetracked doing that and dive right in to cleaning up your code.

You can use IConsole as simply as typing, `add package IConsole`. You can always come back later and remove it.

Anyway, I've created a proof of concept as well as a hierarchy of interfaces that allow devs to be explicit about what type of functionality their console app or method or class requires, and should solve save time when refactoring and cleaning up code, making it more testable and-or removing dependancies. (injecting etc).

If you can please take a few minutes and look at the interfaces and the project site on Github, that would be very helpful. Love you all, Alan