It really looks like a few lines of code — https://github.com/seanwalbran/rspec_around_all/blob/master/lib/rspec_around_all.rb — which complete the DSL and make up for those 0.1% of the cases like mine.

No one has requested it before so it's certainly not something we're planning to add.

To give a little more context, structures like this often come up in my work when dealing with NoSQL datastores, especially ones that rely heavily on JSON, like Firebase, where a records unique ID isn't part of the record itself, just a key that points to it. I think most Ruby/Rails projects tend towards use cases where these sort of datastores aren't appropriate/necessary, so it makes sense that this wouldn't come up as quickly as other structures.

This is probably rare enough that you would probably make a class (e.g. .link-looking-button) that incorporates the reset styles from above and otherwise matches what you do for anchor links.

But of course, there are UX implications. For example, it can be harder to select the text, and the entire element needs fairly complex styling to create clear focus and hover states. There are also accessibility implications, like the fact that the content of the entire card is read before it is announced as a link.

The second example also opens up the possibility of including multiple links. You can’t nest links, so things get a little tricky if you need to. It’s possible though, by making the individual links set above the card-covering link with z-index.

Well. I also recall that people complained about this when I did it in redux-form, which resulted in a persistentSubmitErrors config parameter.

In other words, I do not want an error to appear/disappear as a user types the text that swaps it from invalid to valid.

if we create a new branch or scope for some corner cases, we should have full features of a component without creating a new file

Always fascinated to discover a use case I'd never have considered.

Less than 1% of users in the world have Javascript turned off. So honestly, it's not worth anyones time accommodating for such a small audience when a large majority of websites rely on Javascript. Been developing websites for a very long time now, and 100% of my sites use Javascript and rely on it heavily. If users have Javascript turned off, that's their own problem and choice, not mine. They'll be unable to visit or use at least 90% of websites online with it turned off.

Well, as a home user, I also belong to an investment club with 10 members. I also have a medium size family who I like to send photo's to, and my son is on a soccer team. all those have greater than 5 people on the list. sooooooooo..... once again, the people with valid use of the internet have to 'deal' with those that abuse it.

How does HIBP handle "plus aliasing" in email addresses? Some people choose to create accounts using a pattern known as "plus aliasing" in their email addresses. This allows them to express their email address with an additional piece of data in the alias, usually reflecting the site they've signed up to such as test+netflix@example.com or test+amazon@example.com. There is presently a UserVoice suggestion requesting support of this pattern in HIBP. However, as explained in that suggestion, usage of plus aliasing is extremely rare, appearing in approximately only 0.03% of addresses loaded into HIBP. Vote for the suggestion and follow its progress if this feature is important to you.