It won't override global scope, it's just a hint the layout engine that your container's paint and/or size won't change, and thus it can optimise it's performance.
Wholly agree with your second point, it's something I see from a lot of junior devs. They just reach straight for flex/grid, and tbh I don't blame them. They are more predictable layout algorithms that are largely unshackled from legacy layout decisions.
Depends - do you want screen readers to hear something? If so, add a `aria-label="heart"` or similar. If not, add `role="presentation"` to remove it from the accessibility tree altogether.
You might also want to change the element from a `header` to something else, like a `div` or a `span` or even a `figure` instead. Then put "potato.cheap is home of the... The "Cheap" Web" inside the `header` instead.
That's absolutely not the case for the most part, depending on the bar and the time. Go out to a city centre on an evening, especially Friday or Saturday. Most bars and pubs will be busy, noisy, and definitely playing music.
There are absolutely quieter pubs available, but you need to know where to go.
"stole a kiss" wtf is this minimising bullshit? According to the article, he forced himself on someone, grabbing them by the throat. They feared for their life.
According to the article, he also literally had sex with his partner while she was under the influence, without her consent.
There are lots of people without your educational background. It's a few years old now, but I remember finding Alice Bartlett's talk on <select> box inaccessability [1] quite instructive.
This has been my go-to placeholder site for the best part of a decade. Not because it necessarily works the best, but just because I always remember it.
I think this is really nice and smart. I would suggest left-aligning the text in the edit/view mode for a few reasons:
1) It's a bit easier to read for longer text sources
2) It makes writing/reading JSON/YAML/other data sources much easier
3) lists are much easier to parse
As a primarily frontend developer, I've had a couple of good experiences helping some experienced backend developers work through You Don't Know JS[0].
Elm is lovely, and I'd definitely encourage people to take a look at it from an education point of view at the least. However, I think that's a disingenous comparison.
TypeScript is a superset of JavaScript, which means any JS dev already knows most of TypeScript. They're effectively just learning the type system and best practices on implementing it.
The syntax of Elm is extremely different, which would effectively require developers to learn an entirely new language. It's also a completely different proposition. It's a whole framework, which means complete buy-in on a project. I know there are some interop packages, but you would normally use it instead of React/Vue/Angular etc. This means it's only suitable for new projects.
It's a very nice framework (imo) but it's not a true comparison.
I can only assume that you're trying to run before you can walk. Remember that you're just defining a set of layout rules. You're not giving the browser specific instructions to follow. It seems that there's the temptation to assume that CSS is easy and simple, because it's for the web and isn't a proper programming language.
That is clearly not true. CSS describes a complex set of interactions which evolved over many years. You'll have to refer to MDN, experiment in your browser dev tools, etc.
Start in small and isolated chunks. Open a codepen with just a couple of divs and work out how their layout interacts.
I firmly believe that you can write beautiful CSS. Your list of languages shows that you are clearly interested in learning, and in expressing your needs in varied ways.
As an aside, I would recommend having a design on paper/on screen to implement before starting to write your CSS. Until you become relatively fluent with it, I think CSS relatively counter-productive as a design tool. Thinking about the target result as a separate step from implementing that result is going to be a much better approach.
They will absolutely merge in fixes, though they may well not be timely if they're not from internal engineers. I've had broken behaviour sit in a PR for over 6 months before.
FlatList was absolutely the way to go here. In fact, we initially built the list in question when ListView was the only option. During development, FlatList was made available as an experimental component. It made a huge difference switching over to it. The optimisation we needed to do was to use onViewableItemsChanged to toggle the visibility of images. We found that otherwise it wasn't properly emptying the memory of Android devices, and it was easy to crash older devices. After implementing that, we got silky smooth 60fps everywhere.
RN isn't a wrapped HTML renderer like Phonegap. It uses bridge code to render native UI powered by JS business logic. You still write in JSX, which makes layout pretty straightforward. With some careful optimisation, I had pretty solid 60fps scrolling performance on 1000 item/image lists on old Android devices.
I had a pretty similar experience. It's still a challenging environment - getting performance and memory management nailed across platforms and devices took some very careful engineering.
Based on my limited experience with native iOS app development, RN actually requires an almost completely different way of working.