Is the search element the most stupid HTML addition yet?

You know, the new 'input type = search' thing you can supposedly use in forms nowadays.

Why is it so ridiculous? Well, read this article about it and how it works in Webkit browsers:

http://css-tricks.com/webkit-html5-search-inputs/

No, he's not kidding. They actually added an element which is pretty much impossible to style with CSS. Or more precisely, in which Google implemented in a way which completely ignores about half the site's stylesheet.

Brilliant.

And guess what? All those stupid internet geeks with an obsession with modern crap decided that it just NEEDED to be used by default in such scripts as XenForo, WordPress and numerous others. So in future, we'll pretty much be stuck with a mostly unstylable XenForo search box in about half of all web browsers due to a mix of Google forgetting their 'do no evil' thing and a bunch of designers thinking 'ooh shiny!' was more important than the ability to have a nicely working website.

Oh, and while I'm at it... isn't it funny how Webkit browsers are becoming the new Internet Explorer? You know, in introducing proprietary tags and weird implementations that don't really follow standards and only work in one browser? Yeah, they even came up with their own custom scrollbar CSS implementation too, if just to hammer in the comparisons even further:

http://css-tricks.com/custom-scrollbars-in-webkit/

But back to the point, does anyone else see the search input type and its implementation in certain browsers as completely ridiculous?

 

Chill out, you sound like you're about to bust a blood vessel, over a search box.

 

Does this not work http://priyanksharma.com/code-snippets/resetting-html5-search-input-in-webkit/

Code:

/* Reset HTML5 Search Input in Webkit */
input[type=search]::-webkit-search-cancel-button,
input[type=search]::-webkit-search-decoration,
input[type=search]::-webkit-search-results-button,
input[type=search]::-webkit-search-results-decoration {
-webkit-appearance:none;
}
input[type=search] {
-webkit-appearance:textfield;
-webkit-box-sizing:content-box;
}

 

Well yeah, but come on. The fact you have to do this in order to do absolutely any styling whatsoever seems like overkill. You shouldn't need to change the appearance property to make any edit at all to the style of an interface element.

Also, it's not the new standard. Indeed, there are quite a few articles online indicating that other browser makers and the W3C are not particularly happy about developers treating it like the 'one browser' to design for:

http://www.theverge.com/2012/2/10/2788967/w3c-webkit-damaging-web

http://arstechnica.com/information-...begs-web-devs-not-to-make-webkit-the-new-ie6/

 

Well its good practice to make sure all CSS code will work almost the same in any browser that means first reset lots of stuff before starting to code.

Code:

/**
Eric Meyer's Reset CSS v2.0 (http://meyerweb.com/eric/tools/css/reset/)
http://cssreset.com
**/
html, body, div, span, applet,object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small, strike, strong,sub, sup, tt,var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
margin:0;
padding:0;
border:0;
font-size:100%;
font: inherit;
vertical-align: baseline;
}

/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure,
footer, header, hgroup, menu, nav, section {
display: block;
}
body {
line-height:1;
}
ol, ul {
list-style: none;
}
blockquote, q {
quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
content:'';
content: none;
}
table {
border-collapse: collapse;
border-spacing:0;
}

This is needed to make sure you have some consistency between browsers like how IE and other browsers handle padding.

Also http://caniuse.com/ is a nice site it shows what you can and can't do with some elements. Also the !important is dangerous in some cases the course i toke said if you can't argue why it should be used on that sport your doing it wrong.

You should make a reset.css so that its included in every page that way it stays consistent

 

Good job google.... the problems with webkit could get worse now they have forked their own tree, they already want to chop out a lot of canvas already in their *own* webkit.
So much for standards... I am sure thats what google cried about with IE in the past and now google just make up their own or change them as they want.

 

If you are looking for target to hate, you've got wrong address. Instead of sending your complaints to Mountain View, you should send them to Cupertino, as it was Apple's Safari team who decided "os controlled" search input was good addition to the html spec. Their idea was that browser will remember results for your searches and will make them somehow accessible when you return to page next time.

Similiar story to type="file" input that too is night impossible to style anyhow.

 

This is what Xenforo has to say about that (and is also funny enough, the first comment in the article you posted.)

Code:

/* Undo some nasties */

input[type=search]
{
    -webkit-appearance: textfield;
    -webkit-box-sizing: content-box;
}

Undo some nasties. Classic Kier!

And I had no problem with changing the search bar design in XF in my current project (despite not even knowing the issue you are bringing up could have been one.)






And in general, the "input type = search" is an HTML5 standard. Either you move with the new standards or get left behind. That is a fact of Internet life. Thankfully, there are standards being set at all.

BTW, calling the people who follow or use new standards as "stupid internet geeks" is quite unfitting. They are far from stupid. The problem here aren't the geeks, but rather the browser vendors, who have based their browser on Webkit.

Scott

 

There's no standard saying it has to be styled like it is in webkit browsers. Just that it 'can' be made to look different from a normal text field. So I guess you're right, the browser vendors are to blame here. Treating Webkit like the 'standard' is just as stupid as treating Internet Explorer as such.

As for why you're finding it easy to style... yeah, Kier's code has much to do with that. But the fact you have to set webkit specific overrides isn't exactly the best thing in the world. It's certainly not what standards are made for.

 

Nope, they certainly aren't.

Scott

 

This is exactly what I was thinking! ROFL