Readit NewsCan they be? I'm not sure they make NUCs designed for mobile power draw without the battery.
There are a good amount of lower power ones (e.g. with an N100 CPU) that draw ~15W usually and not that much more at full bore, and some of them are starting to come with USB-PD power inputs (even if they come with a DC power adapter some will accept USB-PD on another port).
Look for "PD in" on this sheet for some examples (columns BW-BY): https://docs.google.com/spreadsheets/d/1SWqLJ6tGmYHzqGaa4RZs...
cletusw commented on The casino in your pocket blog.curtii.com/blog/post... · Posted by u/baggachipz
Not mobile as far as I know, but Prodigy (prodigygame.com) is allowed/encouraged at my kid's school and has a lot of these traits. There are treasure chests at the end of a battle, gems or coins collected, and a constant reminder that subscribers get more rewards. Many of his classmates subscribe.
Ugh, yes. My kids play this one at school and when I read about the game mechanics I was super disappointed. Luckily they stopped begging me to subscribe eventually since I wouldn't budge.
cletusw commented on BMW: Gasoline Car Ban Poses “Imminent Risk” to European Automakers oilprice.com/Latest-Energ... · Posted by u/freedude
I agree that the EU and the world needs to move aggressively on clean energy (including nuclear), climate change etc.
But I really hate this tendency to overly micro-manage the economy.
Yes, gasoline cars pollute, but then the solution is to price a mitigation of that pollution into gasoline, even if than means it'll cost 20€/liter.
It's not to ban one particular category of devices that happens to use gasoline by some arbitrary date.
It's especially stupid because out of all the users of gasoline, cars are some of the "cleanest" due to emissions regulations.
Then middle and upper class people will just keep on polluting at marginally lower rates. The only real solutions to this problem are ones that get the will & finances of the upper classes involved.
"Do responsive things. I didn't spend most of my early career convincing clients to let us do a responsive website just for you to serve me up a boring layout that kicks down to your mobile layout as soon as you are less than 1200px."
Can anyone elaborate on this? I feel like I'm missing some context because a desktop layout that kicks down to a mobile layout at a breakpoint sounds like the essence of doing responsive things.
Obviously there are a ton of other aspects of responsiveness, but specifically calling out the layout change makes me think I misunderstood something.
Having two completely unrelated UIs – one for mobile, one for desktop - isn't really responsive. When done that way there's some point (e.g. 1199px width in the OP's example) where you suddenly have a tiny mobile web site with a ton of blank space on either side (or worse, it stretches it all out to fit and all the blank space is within every single button and widget).
There should either be several progressively more "mobile" breakpoints, or even better, use component queries so individual chunks of the page can rearrange their contents as their available area shrinks.
What gets me is when fancy-pants JS devs disguise complexity and features nobody has asked for behind native html looking controls like select menus.
I see this most often with the city and state inputs, where city is a text input and state is a drop-down/select menu.
As a Texan, I will type my city, tab to the State select menu and type "t" followed by another "t" then tab to the next form element.
But what I'm seeing lately is a text input (search field) dressed up like a drop-down menu... So my t , t input results in a text search for a literal "tt" instead of selecting Tennessee then Texas. It's so aggravating.
Now if someone chooses to click the triangle in the drop-down menu, and scroll through the states, the element would work as expected... If you only wanted to interact with the element with you mouse.
If it ain't broke, don't fix it.
This is (was) largely a problem caused by holes in the web platform. Historically it was incredibly hard (if not impossible) to style or otherwise extend the behavior of a true <select>, so most apps had to reimplement it (poorly). <selectmenu> seems to be the new styleable built-in replacement.
And then because code sharing across apps/frameworks/companies/etc was historically very hard, only really big companies had enough headcount to build fully functional, accessible, customizable replacements for built-in components. Web Components solve this, allowing global collaboration on common leaf node components like <select>.
Related: https://blogs.windows.com/msedgedev/2022/05/05/styling-selec...
Since we're on the topic of how people should learn to build web things: what do you think are the most important things to learn first to make web stuff? The "right" way? Just raw HTML, CSS, and some JavaScript (Typescript?)? It seems common among programmers to criticize the overuse of web frameworks. Are there a lot of people who learn only web frameworks?
I don't think vanilla HTML/CSS/JS is the way to go for beginners because of the "time to visually interesting results" problem. Starting with a framework that has widgets you can reuse is much more interesting and motivating.
That said, I'd argue that the selected framework should be one that doesn't completely obscure all the underlying HTML/CSS/JS (I'd avoid TypeScript at first) from them so it's easy to learn that when needed, plus it makes debugging using browser dev tools easier and means they'll have transferable skills for learning a second framework.
GWT (RIP, thank goodness) would be the extreme negative example, but React is on that side of the spectrum as well.
Vue, Svelte, Lit, and Angular seem to be the most popular frameworks on the "closer to HTML/CSS/JS" side of the spectrum, though I only have experience with the last two. Lit's great; Angular's not my favorite.
Maybe not visually hidden, but practically invisible to human: imagine a text box with color #fffffe on a white background. Visually impossible to discern for most humans on most screens, but for a machine #fffffe is totally distinct from #ffffff, and fully visible if display != none.
As AI becomes more intelligent, you can prove humanity by exploiting our weaknesses.
(Another idea. Have a random image on a page actually be a text box with an image background. You cannot activate it if you focus on it, with your mouse or touch, but a bot doesn't need focus to change input.value.)
Please don't do this. This confuses and possibly prevents screen reader users from using your site.
cletusw commented on The Failed Promise of Web Components lea.verou.me/2020/09/the-... · Posted by u/lemonberry
> "I just wanted something that is small and works like a normal HTML element"
My first stop when looking for a web component is always https://component.kitchen/elix because of their commitment to the Gold Standard (https://github.com/webcomponents/gold-standard/wiki), which is basically to imitate native elements wherever possible.
As opposed to non-OSS, where removing features that paying customers care about is of course trivial?
> Obligatory: https://xkcd.com/1172/
I don't mindless comic and its original context, but it's gotten extremely old seeing it wheeled out to justify completely discarding user input on any change. Sometimes an update does break legitimate workflows, and that is bad.