![]() ![]() With regard to the non-valid attribute, would it help if we made it a data- attribute? I believe we actually did this at one point in the evolution, I’m not entirely sure why we didn’t at least dasherize it, which would at least serve the same purpose and virtually guarantee it was safe. 3) upcoming developments of custom mq’s would make high fidelity of whatever design is ultimately settled on similarly small. We did this with lower fidelity specifically for a few reasons: 1) we’re not far enough along to seriously assume that what we have here could make the jump from prollyfill (speculative) to polyfill without feedback and changes 2) We can illustrate the usefulness in a practical way with a very small amount of code and allow developers to actually use it in production apps - this is really important if we want participation and feedback. Perhaps because I am not particularly in love with the approach and the use of a custom non-valid attribute… I wasn’t applying that argument to the prollyfill. I need to sit on it for a bit, and think about half a dozen use cases to see if that concept can hold up. ![]() I feel I am on a good track with the idea, but it’s going to take very long description to explain why it’s needed, what it solves and how it would work. PS: I’ll definitely explain the assisted-focus and hover-intent suggestion in depth, when I get a chance in a few days or within a week’s time. I can always come up with an alternative prollyfill reversing that approach. Because once you’d do that for modality: keyboard, it becomes part of your fundamental CSS approach for everything. I guess, I am just arguing in favor of a principle that leave the default focus alone by default, and address the cases where I need to remove the focus ring on a case per case. ![]() What I mean by “expensive” would be a true polyfill (in the likes of an ajax call re-parsing CSS). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |