Last modified: 2013-06-05 16:01:31 UTC
Text inputs on special pages miss the type="text" attribute. I didn't search for all special pages with text inputs, but here some examples: * http://www.mediawiki.org/wiki/Special:FilePath * http://www.mediawiki.org/wiki/Special:AllPages * http://www.mediawiki.org/wiki/Special:ExpandTemplates This is bad as soon as you want to style text inputs with CSS (e.g. border, padding font/size) since you'd have to exclude all other inputs in forms and fieldsets (submit, cancel, search etc.).
Same for text inputs in the user preferences!
At the moment our HTML class intentionally strips out type="text" if specified (So if you see type="text" anywhere, you're looking at something generated by legacy code) I suppose it could be changed to force use of type="text" when type is unspecified.
Too bad CSS selects based on the given attributes not the interpreted values. (since type defaults to "text" in browsers).
Sounds like a good idea to normalize the type attribute to always be specified in HTML. Why was the HTML class stripping it out, to save a pair of bytes in output ?
>Why was the HTML class stripping it out, to save a pair of bytes in >output ? Looks like. (For reference, its r55905). It removes the default attributes for many elements, not just input.
Feel free to rename this bug report
You can use "input[type=text], input:not([type])" to find text inputs even if the type attribute is omitted. This doesn't work in IE7 or IE8, though, which input[type=text] does, and that's 25% of Wikimedia's traffic <http://stats.wikimedia.org/archive/squid_reports/2011-10/SquidReportClients.htm>. Both forms do work in IE9 and higher, and any interesting version of any other browser. Given IE's plummeting market share (<35% on Wikimedia!), I don't think we need to re-add the attributes for this use-case. But if people do want to, it would be simple enough to change the class so that they're always present instead of never present.
(In reply to comment #7) > You can use "input[type=text], input:not([type])" to find text inputs even if > the type attribute is omitted. This doesn't work in IE7 or IE8, though, which > input[type=text] does, and that's 25% of Wikimedia's traffic > <http://stats.wikimedia.org/archive/squid_reports/2011-10/SquidReportClients.htm>. > Both forms do work in IE9 and higher, and any interesting version of any other > browser. > > Given IE's plummeting market share (<35% on Wikimedia!), I don't think we need > to re-add the attributes for this use-case. But if people do want to, it would > be simple enough to change the class so that they're always present instead of > never present. I disagree, this makes stylesheets more unreadable and ugly. Leaving parts out of the HTML just to save a little bit of bandwidth, only to make styling the parts counter intuitive.
Not to mention that there is no fallback for < IE9.
Agreed. Dirty workarounds should be avoided, esp. for such trivial things. MW should output proper HTML instead.
And it doesn't save much ressources with standard gzip html compression
On the other hand, we should really be using classes for styling. For example, Smartere and GitHub use classes somewhat like the following: * button (any button, can be used in JS env on a <div> as well as on <a>, <input>, <button>) * button-row * button-primaryAction (emphasized in a group of buttons) * button-positiveAction (add, save, publish, ..) * button-negativeAction (delete, remove, ..) Anyway, that's for later.
We recently hit this bug in some work creating a custom skin and working with Semantic Forms. The text attribute being stripped out caused a lot of confusion until we tracked it down in the code. This behavior should be changed to help out skin developers, especially when adapting existing CSS frameworks (like Foundation) to work well with MediaWiki.
