Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix .visuallyhidden not being actually hidden #107

Merged
merged 2 commits into from
Jan 12, 2017

Conversation

futpib
Copy link
Contributor

@futpib futpib commented Dec 22, 2016

Refs #106 and #104

@jlbooker
Copy link
Contributor

Looks good to me.

@colinrotherham, does this still work for your accessibility requirements?

@colinrotherham
Copy link
Contributor

Hi @jlbooker,

I'm against embedding CSS like this in JavaScript, for the following reasons:

  1. In future, an alternative "visually hidden" snippet may be recommended, making this superfluous.
  2. Embedding CSS stops us providing tailored Firefox, legacy IE or mobile styling behind media queries (we're stuck with these rules and only these)
  3. Some users may prefer to see the status.

This is a job for CSS, not script.

@futpib
Copy link
Contributor Author

futpib commented Dec 30, 2016

@colinrotherham I completely agree that this is better off done with css. But, for better or for worse, this is not how typeahead.js currently works. Just search for '.css' calls over the code base.

What happened with 0.11.1 release was a kind of semver abuse ("patch" and "minor" version number updates must be backwards compatible). Users already depend on typeahead.js doing it's stuff with inline css and do no expect elements popping out of nowhere with minor version update. Moreover, 0.11.1 does not provide any css files one could include to make typehead work as before out of the box.

Changing approach to styling (disabling all inline styles and requiring users to include a css file) is feasible for a minor update behind an option (disabled by default for smooth updates) or for a major update (then we could explicitly state that user must include provided or custom css).

@colinrotherham
Copy link
Contributor

@futpib Agreed.

The status message should really have been a new feature, under a major release number.

You'll need a Windows machine running a JAWS 40 minute trial or VoiceOver for Mac to verify this works before merging. Does everything work still?

Like the other .css() (especially font styling) we can consider consolidating those into a future release.

@jlbooker
Copy link
Contributor

jlbooker commented Jan 3, 2017

@futpib The semver abuse is my fault. I didn't realize the message was a breaking change, thus the minor version bump from 1.0.1 to 1.1.0.

I'm in favor of merging this fix now to correct what we broke, and creating a separate issue to look at pulling the styles out into an actual stylesheet in a separate (major version numbered) release.

Does that sound good to everyone?

@jlbooker jlbooker added the bug label Jan 3, 2017
@jlbooker jlbooker self-assigned this Jan 3, 2017
@futpib
Copy link
Contributor Author

futpib commented Jan 4, 2017

@jlbooker Sounds great.

@jlbooker jlbooker merged commit e9696a4 into corejavascript:master Jan 12, 2017
@jlbooker
Copy link
Contributor

@futpib Just published version 1.1.1 on NPM. Have a look!

@ricardobrandao ricardobrandao mentioned this pull request Jan 16, 2017
@ricardobrandao
Copy link

@jlbooker can you please create a github release?

@jlbooker
Copy link
Contributor

@ricardobrandao Done! Sorry about that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants