-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Browser compatibilty #8
Comments
@eltonmesquita I had a similar concern. Please do share your test findings with us or let us know if you won't have time to do this so someone else can take over. |
Yeah, it would be nice to run a test page through something like @saucelabs or something, in the future. For now, I haven't come across a browser that can't style custom attributes. |
@johnzach I can't garantee I'll have the time to do everything, but for sure I'll test in most browsers I can and will certainly share the results. @geelen Yeah, all we need is the benchmark page, right? I haven't dealt with any problem too, but if seeking widespread adoption, I think that have a proof to show people will make them more comfortable in trying it. |
You should be able to use https://github.com/amcss/am-benchmarks to test browser compatibility. For example:
Load each of those in your browsers and if they all look the same, AM is supported! |
Alright then! I'll do my testings and will post them here. |
That's the spirit! 👍 On 9 September 2014 14:36, Elton Mesquita notifications@github.com wrote:
|
Got some testing done: Looking good, no problem by now. |
You bloody champion! On 9 September 2014 15:12, Elton Mesquita notifications@github.com wrote:
|
@geelen ;D |
It is well known that attribute selectors don't work on IE6 and below. Obviously this browser has little support nowadays, but it means that a website using AM will be completely unstyled. This is particularly an issue if you want your website to work in China, which still has 10-13% of IE6 users. I think this should be mentioned in the spec to make people aware of the potential issue. |
I'm just working on a small javascript lib to use AM (like class functions in jQuery).
|
@oliver-eifler was just about to use this on a redesign we're doing to one of our pages, but it needs to hook into an "edit mode" that is totally reliant on Javascript. I see AMCSS + JS being a big headache for IE development, based on your findings. sigh passing… |
@ericfields The case-sesitive issue on some browsers is not a big deal, as mentioned in the specs the Module Name (Attribute) should be camel-case (ie. am-Button) and the values always lower-case (ie. big round green). |
Little update:
Tested on latest Firefox, Chrome, Opera, Android2.1 Stock Browser, Android4.4 Chrome, VMWare IE7/8/9/10/11, OS-X Safari 6 |
I don’t think I’m meant to be CC’d on this. On Sep 18, 2014, at 5:35 PM, Oliver Jean Eifler notifications@github.com wrote:
|
@ericfields mate, you've received a github notification, turn them off if you don't want them.. |
I don't know whether a seperate namespace affects browser compatibility, but http://caniuse.com/#feat=dataset is a useful reference, and highlights an Android 2.3 possible issue. |
@tobystokes only on select elements on Android 2.3? doesn't sound like a big deal to me. |
First release of my am.js |
My main concern, besides the performance, is browser compatibility.
I believe that all modern desktop and even older browser support custom attributes without a problem. But I don't know much about mobile browsers, mainly the under dogs like opera mobile and the ones in legacy phones. It would be good to also document the odds that might occur.
Shouldn't we create a test page and make a list of all the browsers tested with the results?
I think this way people won't be afraid of use AMCSS.
I'll start my testing as soon as I can as I just found it incredible and shared a lot of your thoughts and concerns about classes and the traditional way of authoring CSS.
The text was updated successfully, but these errors were encountered: