Update Notice Module and Module CSS loading API #880
Conversation
kabel
commented
Aug 27, 2015
kabel
commented
- Reverts bad commit to debug html instance
- Changes the example markup for notice
- Updates the core band styles to use margin to offset the page-pad on mobile
- Updates notice styles to not do so many overrides
- Cleanup WDN api to remove dead code and add a method for getting a versioned template file URL
- Update all modules to use the versioned template file URL getter for loading CSS.
This will provide better support for legacy/unbanded content that has existing padding. This may cause a backward compatibility issue with legacy grids as direct children of maincontent. Also refactors media queries band styles directly into the selectors they apply to.
Webkit and Gecko have implemented working event implementations for the <link> element. This can be used in our loadCSS function.
Implemented HTML5 data attributes for setting the overlay and auto-close period. Updated the example HTML to match. The code remains fully backwards compatible with the css class based initialization.
Also removes unused variables
|
|
||
| @media @bp3 { | ||
| padding: 0; | ||
| padding-left: 0; | ||
| paading-right: 0; |
| </div> | ||
| </div> | ||
| <script type="text/javascript"> | ||
| WDN.initializePlugin('notice'); | ||
| </script> | ||
| </div> | ||
| </body> | ||
| </html> |
There was a problem hiding this comment.
I wonder if these examples could use some accessibility love. Perhaps aria roles of alert and/or alertdialog. I also wonder if it is possible to have the JavaScript side of things add the appropriate role automatically, so it doesn't have to be hand coded.
There was a problem hiding this comment.
They could, but this is beyond the scope of this PR.
There was a problem hiding this comment.
Is it beyond the scope? You are already refactoring it, accessibility should be in mind.
I am curious exactly how AT processes these roles if they exist on the page on initial page load. Do they announce them right away? I will have to check.
There was a problem hiding this comment.
That's like saying, "hey, I see you changing something in this file, mind changing something else mostly unrelated to your original intent?"
Make your own PR. :P
There was a problem hiding this comment.
Sorry, I don't see how accessibility is mostly unrelated. The example code was updated to include the latest best practices, which should include accessibility considerations.
There was a problem hiding this comment.
I'm not trying to be confrontational, but this is exactly what feature creep is. If you see something else that needs improvement, you should create your own pull request.
There was a problem hiding this comment.
I'm not trying to be confrontational either. I'd argue that feature creep is not this. Pull requests should be reviewed for code style, bugs, usability and risk. Risk and usability includes accessibility. If care was taken to refactor something to make it better (and this is much better than it was before), accessibility should be reviewed in the pull request.
Feature creep on the other hand is adding additional superficial (maybe the wrong word) features, such as different fading transitions, or different colors because they would look nice, or a different widget entirely.
When a widget is updated, all aspects of that widget in terms of code and usability should be visited and addressed.
Perhaps that is just my professional opinion.
|
@kabel it looks like the tests are failing for this one. |
|
Boo. It seems like a side-effect. I'm restarting the build to confirm. |
|
Looks like it is still failing. :( |
Fixes a build error.
|
Found it. |
Update Notice Module and Module CSS loading API
