Apply styling through JavaScript (remove typeahead.css) #15
Conversation
|
Looks good to me |
…typeahead-css Conflicts: Gruntfile.js src/css/typeahead.css src/dropdown_view.js src/input_view.js src/typeahead_view.js test/typeahead_view_spec.js
|
Why are these changes coming in? Now if I want to override the default styles I have to use Personally I would not use this project if these changes went in, but I know I'm one person so I'd love to hear what other people have to say about this. |
|
Main reason why this change is coming in (well, being considered) is because I think it makes typeahead.js easier to use. Which styles are we setting in this pull request that you'd want to override? I have a hard time imagining you'd want to override any of them as they're mostly for positioning the hint and the dropdown menu, but maybe there's a use case I'm not seeing. BTW, we currently use Also, we'll be setting fewer styles after this pull request gets merged in, making typeaheads a tad bit easier to customize. One of the reasons why we'll be setting fewer styles is because of the switch from Hopefully this addresses your concerns. If you still have issues with this pull request, please voice them. |
|
Thanks for the speedy reply. You make valid points, sir. I hadn't thought about the styling issues related to Keep up the good work! |
|
Merged into |
…head.js into integration-0.9.0 Conflicts: Gruntfile.js dist/typeahead.css dist/typeahead.min.css package.json src/dropdown_view.js src/typeahead.js test/dropdown_view_spec.js test/typeahead_view_spec.js
|
It may make typeahead easier to drop into a project, but realistically, anyone that can understand how to apply the plugin knows how to apply layout styles. Even though you had essentially the same styling before with the Forcing the end user to overwrite your preferred styles with '!important' and restyling the same element multiple times is bad technique in my eyes, especially when the core functionality isn't reliant on layout styles (as it might be in a slideshow plugin for example). |
|
Sorry for the delay in getting back to you, life's been hectic lately 😫 What do you consider the core functionality of typeahead.js to be? I think if I know your answer to that question, I'll be able to address your concerns more appropriately. |
|
No worries, we all have crazy times. In my eyes, the core functionality is the returning search results for the query. What happens after that should be up to the developer using it. For example, I agree with a reply you made on another issue about typeahead not being a select menu plugin. I was bummed at first because that is exactly what I was trying to do with it, but then I thought about what would be required once you opened that box and how typeahead would just become the same thing as Select2. Yet if we want to, we can write some extra scripting with the selected callback to make it act like a select menu. |
|
Ah alright so that's what I was hoping you'd say. That functionality is provided by the dataset component which we're planning on creating an API for (see #95). So in theory, you'll eventually be able to do something like this: var datset = $.typeahead.Dataset({ /* ... */ });
dataset.getSuggestions(query, function(err, suggestions) {
// now you can render suggestions from typeahead.js however you'd like
});Considering the dataset component and its dependencies account for probably less than half of the source code, we'll probably want to generate something like typeahead_dataset.js so devs like yourself can take advantage of this functionality without having to load all of the code for the UI components. |
|
Nice, now that makes a lot of sense. I was going to suggest an option when initializing to skip over the styles, but this is even better. Carry on :) |
tt-is-openandtt-is-emptyclasses.divinstead ofolandli.