Next, I want to talk about the input of type search.
And right off the bat, I just want to say that input elements of type search are very, very similar
to those of type text, except that they are specifically intended for handling search terms.
They're basically equivalent in behavior to the type of text, but user-agents (aka browsers) may choose
to style them differently by default.
I guess what I'm trying to say is that they're not special.
It just creates a single line text box.
That's all that this type of search does.
But this is not to say they're useless.
Search controls are useful to gather short runs of text that servers or client side scripts will use
as parameters to conduct search operations.
But from a browser side, it does absolutely nothing.
It behaves just like a text input.
And this isn't a problem.
In fact, the spec doesn't even require this type of search to do anything special.
What I'm trying to say is that don't expect the browser to bind this input type with a search engine
or perform any fancy search operations on the back of it.
And as I mentioned, it's almost the same as a normal text box that is input of type text, but the
browser just tweaks the design slightly to make it look a bit pretty.
Have you got it?
There are a few other differences.
For example, on touch devices you may see a search word or a magnifying glass icon 🔎 like this.
And that's pretty cool, right?
It's improving the UI.
And this is not all my dear students.
There's another benefit of having an input with type search, and that is values can be automatically
saved and reused to allow auto-completion.
This auto-completion and saving feature is pretty much done by all modern browsers today.
In other words, they automatically store search terms previously entered across domains which then
come up as autocomplete options when subsequent searches are performed.
And this obviously helps users who tend to do searches on the same or similar search queries over time.
So bottom line is that it's pretty similar to the input of type text, with a few subtle differences,
and those subtle differences boil down to styling.
You know what,
before we move on, I just want to have another lecture where we use the :valid and :invalid pseudo classes.
So with a lot of these different input types, we do get these pseudo classes by default.
The browser gives it to us and we can target these :valid and :invalid pseudo classes to style our widgets
differently depending on whether it's valid or invalid.
So why don't we code up an input with type search?
We can make this field required.
So if it's blank, I want to show a little cross ❌ and when it's valid, I want that cross to change to
a tick ✔.
How can we do that?
Hint: I am going to be using the ::after pseudo elements.
We've done this a few times in the course.
Give it a think 🤔.
And in the next lecture, let's code together.
I can't wait.
See you now.