Additionally, in places where there's loads of green energy, crypto mining captures excess energy and discourages innovation in energy storage.
Rather than electricity prices being driven down by more green production and storage, there's this floor where it's better to just convert the energy into blockchain coin flips and heat.
This is literally addressed in the article. All the other blockchain ideas also reward those with existing, large-scale, wealth in the real world (the way that Proof of Work rewards those that spin the most GPUs)
The italics are amazing - very visible and distinct from the regular font, making it a great tool for validation. E.g. it's very noticeable when a CSS rule is not italic all of a sudden (misspelled). It adds a nice layer on top of colors to distinguish between different states.
Spending time designing in photoshop and then "cheaply" "outsourcing" HTML and CSS development, aka your _actual_ website, is a terrible idea. There are people who implement designs well, and they are worthwhile to hire if you don't know browsers; they're certainly not cheap.
It depends on what you're doing. Yes if you're doing a large scale project that's mission critical you want a front end pro and wouldn't dream of going cheap. But on the other hand say you have to do a single simple landing page for a one time marketing campaign it would be silly to bring in the best.
Also as a designer I find myself telling potential clients that they don't need a designer and should just go with a template or a logo from 99designs. For the longest time I hated doing this, but I realized that if someone wants to spend from $10 to $500 to do something that I wasn't the right person for the gig!
Media queries are still necessary to lay out the page you've described. The primary containers of your pages all need to move around based on the size of the top-level container.
If you could only rely on your parent, that would also be problematic - the size of a component would be dependent on its chain of parents. If you were reusing the same component within further containers, say 3 different pages, you might want two to look the same despite a size difference, and element queries don't help you anymore. You just need a .testimonial.compact class, have slitghtly different media targeting, and now you have two types of testimonials that you can use on further pages.
Element queries could also easily create strange loops that cause the threshold to be crossed recursively, if the parent bases its width on the child. This is the case with inline-block elements and the property-which-must-not-be-named.
you still have to base it off either the parent (.signup-page .testimonial) or a conditional that's only used on a particular page (.testimonial.compact). The media queries are sub-optimal but it's contained within .testimonial. Here's how it can look:
.testimonial {
media screen and (max-width: 900px) {
font-size: 0.8em;
}
&.compact {
media screen and (max-width: 1200px) {
font-size: 0.8em;
}
}
}
What if this thing shows up in 18 places, some of those change sizes on mobile, some of them in turn being reused in several places and then somebody changes something that affects the size (and therefore desired styles) of some but not other of those contexts, and adds 6 more contexts in which the size matters?
I want to say "When displaying a user profile, If there's more than X units of horizontal space, use the large profile image. If there's more than Y units of vertical space show their bio, trimmed to length but avoiding widow sentences and followed by ellipsis. If there's very little room at all, just show their user name."
I know what I want and I can describe it simply and in a way that a machine could implement, but using today's tools it will take significant developer (human) effort (which typically isn't within my client's priorities and ultimately gets neglected).
By all means, I would love to have element queries. They would definitely help in many cases. You would have to limit their use to just those areas of markup where container widths are explicit.
If it shows up in 18 places I bet you there will be two different contexts with the same container size, but different looks, and element queries won't help you at this point. You'll still need to tailor your CSS classes for different contexts.
Obviously if I want styles to vary by context of their container, I'll need to create those rules. The desire for and utility of being able to do that is not at all in question. I don't see how having such rules is in any way mutually exclusive with element queries.
GWT is definitely not going to help the problem the author is talking about. GWT's "packaged" components still end up as the same markup and CSS. In most backend frameworks I'm talking about the Helpers, in GWT this would be some "View", or whatever isn't the presenter.
You would still need to use different CSS in the two cases mentioned, so it would be two different packaged components in GWT, two different Views. Maybe interiting from one another, but certainly far FAR more lines of code than a conditional / "modifier" CSS class. .testimonial.compact vs just a normal .testimonial, for instance.
Rather than electricity prices being driven down by more green production and storage, there's this floor where it's better to just convert the energy into blockchain coin flips and heat.