There's a great video from "Technology Connections" covering one-pedal driving here [1]. The gist of it is that one-pedal breaking doesn't have a great way to control the break lights, making it difficult for the cars behind you to recognize that you're slowing down, which can cause accidents.
This is only a problem in some EVs. Teslas, for example, illuminate the brake lights correctly when regenerative braking is used. The pinned comment on the video also suggests Hyundai may have fixed this on their cars by now, although I don't know whether they followed through.
IIRC the industry went from hard regen "may illuminate" -> "shall not illuminate" -> "must illuminate". Some cars designed and/or type approved when the middle one was regulatorily current follows it.
Manual transmissions (and sport shifting automatics) of most cars from 1904-2024 of sports coupes to trucks don't illuminate the brake lights when engine braking. Drivers following cars should be basing most decisions based on relative speed based on these existing.
If you were to follow behind me in my 2004 manual sports car or a 2021 automatic and only applied brakes when I did, you'd be speeding in my neighborhood and rear ending me, as I keep both in second gear and it keeps me at 20mph.
Having no brake lights for regenerative braking sounds incredibly dangerous. Regenerative braking can slow the vehicle down quite quickly, and as the name "one-pedal driving" suggests, it's common to barely touch the brake pedal at all.
Perhaps a better version of your complaint is that Tesla has made the threshold for the brake lights too sensitive; but I would be curious how much observation went into drawing that conclusion.
I drive my manual and auto cars like this, downshifting instead of using the brakes and preventing dangerous acceleration. I often only use the brakes from 20mph and below (though may touch them during a downshift)
Thinking it's more dangerous is odd as it's a great example of fail safe.
Wasn't his whole problem with one particular implementation of one-pedal driving, the Ioniq 5? As I recall, it was poorly implemented and had a relatively common use case that would allow you to stop without the brake lights ever coming on.
This isn't really a problem that other EVs have had. The brake lights come on when you slow down, just as if you had used the brake pedal. It's mostly as easy as triggering at a certain amount of kW generated.
> Wasn't his whole problem with one particular implementation of one-pedal driving, the Ioniq 5?
Yes. I watched that Tech Connections video a while back. In that implementation, his car would slow down too quickly without brake lights. I think it would get down to something like 15 mph from 55 before they'd come on, yet the deceleration was at least as rapid as casual braking.
I agree with the Tech Connections example; I have no comment on other EVs.
I can go from 75 to 5 mph in my ICE with the brake lights never coming on. Or, I can maintain 75 mph with my brake lights on 100% of the time.
But really, there should just be a standard - it seems obvious and easy for EVs to get it right: If deceleration is > X m/s^2, then brake lights are on.
The European Union has a regulation that requires EVs to illuminate their brake lights anytime the regenerative-braking system’s deceleration rate exceeds 1.3 meters per second squared, or about 0.13 g.
Simply because I've been driving TVs for a while and "in the beginning" when there was no rules for brake lights to be turned on when regenerative breaking, I got into trouble (German highways) with cars driving behind me and not being able to anticipate / react fast enough when I used it.
I quickly learned to force the break lights and started to follow this issue closely. That's how I became aware of the number.
How the EU saddled for 1.3 and not 1.2 or 1.4 is beyond my knowledge.
Unless I downshift using paddles, my ICE will coast forever from 75. My PHEV, on the other hand, will slow down much faster. I want my PHEV to illuminate the brake lights if I'm decelerating above a certain rate, just as you suggest.
It never occurred to me that I might want my ICE to do the same, but I suppose it would be helpful if I'm heading downhill and downshift without touching the brake.
How will we then be able to tell which drivers are ignorantly riding their brakes all the way down a long hill, versus the drivers using engine braking?
>Brake lights.....will remain on when the vehicle fully stops.
Mmmm, nothing better than a dark, rainy evening in November in a city after a long day at work and you're stuck for minutes on end right behind a car with red lights burning into your retinas.
Wankers.
Thank you for putting the list together! If I may make a suggestion, what you wrote above would be an excellent first paragraph in the readme, as it explains the intent well and the criteria for how you add books to the list.
If you'd like to use something like this in your own APIs to let your clients filter requests or on the CLI (as is the intention with gron), consider giving "json-mask" a try (you'll need Node.js installed):
If you've ever used Google APIs' `fields=` query param you already know how to use json-mask; it's super simple:
a,b,c - comma-separated list will select multiple fields
a/b/c - path will select a field from its parent
a(b,c) - sub-selection will select many fields from a parent
a/*/c - the star * wildcard will select all items in a field
> Start by running the migration helper on a current project. We’ve carefully minified and compressed a senior Vue dev into a simple command line interface. Whenever they recognize an obsolete feature, they’ll let you know, offer suggestions, and provide links to more info.
Vue's docs are a masterclass in docs-writing, imho. Clear. Concise. Empathetic. Written for humans.
I think the difference is that the browser already contains the shadow dom needed to render the video tag. But for a custom tag it would need to fetch, parse and execute your component code before it can begin to render.
That's an interesting read. I'm thinking on whether the real question is what is the declarative difference between the video tag, which by normal application lets everyone feel find about that content hidden by the shadow DOM vs the APIs we're developing for our custom elements. There seems to be an important piece of learning, not just for SSR, but for custom element development in general, that I think we can build off of.
I’m excited about this. There’s usually a ton unnecessary CPU usage with the current techniques, not to mention the human time waste of re-implementing them in JS. There’s feature detection for this too, so we can gracefully degrade “loading” to existing solutions and take advantage of it right away.
Great news for PWAs buried in the release notes: “Updated the behavior of websites saved to the home screen on iOS to pause in the background instead of relaunching each time.”
> Toshi is a three year old Shiba Inu. He is a very good boy and is the official mascot of this project. Toshi personally reviews all code before it is commited to this repository and is dedicated to only accepting the highest quality contributions from his human. He will though accept treats for easier code reviews.
There are two requirements that I personally don’t feel very comfortable with: the first one is uploading a picture of my ID (How is it stored / backed up. Who has access: third party validator or your team?) and the other is adding logmein to let a proctor control my machine prior to the exam. I saw that one may take the exam in person. I don’t know if it’s allowed by your rules, but I suppose I can set up a VM for this, but either way that just makes it more difficult for me to justify finding the time to do it.
Our third party proctoring service handles the KYC, as well as the LogMeIn. We did some vetting, and they are used by some well-known MOOCs and universities' online courses. It's a concern of ours as well, which is why we try to offer in-person proctored tests or appointments.
[1] https://youtu.be/U0YW7x9U5TQ?si=7XFO_ZHIwUjd-3Sm&t=195