-
Notifications
You must be signed in to change notification settings - Fork 5
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
Smaller polyfill #28
Comments
+1 |
Your polyfill looks great; thanks for posting. It seems that all browsers since IE 9 will gracefully deal with an unknown element? I don't have the cycles for the next couple of weeks, but I look forward to exploring in detail how this behaves from the perspective of Assistive Technologies (ATs) such as screen-readers. With
Some things it would need to be able to do that could perhaps be worked in...
Polymer is certainly a barrier to entry -- though it would be interesting to compare the behaviour/any trade-offs associated with your polyfill for a site that's already using Polymer (I have not yet looked into things like how efficient and robust the DOM mutation observers it provides actually are, and implications of them on large pages). It'll be interesting to see how we could develop both approaches. One challenge that appears universal is that of CSS specificity - would be interested to hear if you think there may be work-arounds for that (on the other issue threads). |
Polymer is a large library intended to work in the latest version of evergreen browsers. The legacy polyfill works in IE6+ (and still updates on DOM mutation). It’s 1322 bytes uncompressed and documented, which means it should be easy for other developers to see exactly what’s going on.
Interesting idea. What is the use case?
Default styling can be achieved in all browsers with this stylesheet. Selector specificity will be an issue. Adoption of
This can be done in the last line of the polyfill by changing the |
i haven't looked at this closely. My current leaning is small polyfill, extend h1 and keep custom element nomenclature |
In answer to @jonathantneal's question on the now-closed #30... we definitely want to take this forward and thanks again for sharing your polyfill. I have still not created the time to test it in detail with the accessibility APIs (though, again, I don't anticipate major issues) -- after that's done, would you be happy in principle for us to adopt it? One of our goals is to hopefully get this thing specified and adopted formally. Haven't looked too far into this yet, but that may be helped by keeping the Polymer version around and in-synch, because it uses and exposes the up-and-coming official APIs for doing (Custom) Elements, but for general use I think the polyfill looks a lot better (again, need to satisfy my curiosity with respect to its interaction with accessibility APIs). |
I've (finally, sorry for the lag) been able to start testing the polyfill in some detail -- the results are quite interesting; some of the screen readers appeared to have issues with identifying/moving between the headings, which I was not expecting. Test details and results:
Some thoughts:
Still need to test on other browsers and try to see more about what the accessibility APIs are getting from the browsers... |
I have just restarted my VM and tested it again and also with the Polymer version of
As a result, it is looking like the accessibility of the polyfill approach is not going to be an issue (as hoped and expected). But we do need to get to the bottom of the possible screen reader or browser bugs uncovered by this exercise before we can consider either approach accessible. I would very-much like to be able to recommend @jonathantneal's polyfill as the code is so simple and elegant -- looks like we'll be able to do that in the not-too-distant future! |
This is a neat project, but the Polymer polyfill is overkill. A fairly robust polyfill could be written in < 500 bytes. For instance, this polyfill assigns the appropriate role and level to all headings in all modern browsers (read: IE9 and up) even when the DOM tree changes.
The text was updated successfully, but these errors were encountered: