2.1 Beta "input{border:0}" change to elastic.css causes loss of platform-native look and feel

[rgm]

It appears that elastic.css has added border:0 to the reset.css. I think it's a bad idea to set border:0 on input elements because many designers want their input elements to look like they belong on the native platform.  Buttons are especially noticeable.  If you touch the border property for a button or a text input field then it loses its operating-system derived theme, and there's no way to put it back.

I theorize that this was done for a couple of reasons -- to make width calculations take into account borders, and perhaps to work around some browser quirks where if a border width was NOT defined then computedStyle.borderLeftWidth could sometimes return the string "medium" which would cause a NaN in Elastic.getInnerWidth while trying to parseFloat( computedStyle.borderLeftWidth ).

I suggest that Elastic not touch the border for input elements in order to preserve OS-specific look and feel where desired.  There's just no way to explicitly set an input's look and feel back to a platform-native one, so best not to disturb that.

I'm not sure how best to handle the "thin, medium, thick" strings, nor am I entirely sure under what circumstances (browser, doctype, OS) those values appear -- but it seems to be an Internet Explorer thing.

[Fernando]

i will check this one, this was not supposed to be like that according
to what i remember, i will check the code and make appropriate
changes.

On Aug 26, 7:04 pm, rgm <roland.mcint...@gmail.com> wrote:
> It appears that elastic.css has added border:0 to the reset.css. I think

> it's a bad idea to set border:0 on input elements because many designers *
> want* their input elements to look like they belong on the native platform.  

[Fernando]

i think this was a mistake i pushed the change because i see a valid
point in your suggestion, now the search for the tags that should get
border 0 starts, I think td could be a good candidate.