This is more appropriate, as the tabs are more akin to a label than an output.
Also better for touch screens because some browsers select the tab label text (highlight for copying) when output element tapped. Not a functionality issue, but looks bad and initially confusing (why is that text selected?)
Using data attributes
https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes
HTML5 is designed with extensibility in mind for data that should be associated with a particular element but need not have any defined meaning. data-* attributes allow us to store extra information on standard, semantic HTML elements without other hacks such as non-standard attributes, extra properties on DOM, or Node.setUserData().
Also suggested by @fabianfrz. Not perfect yet as we seem
to mix wheel with access and either need to lock down shell
access along with it or somehow tag along the shell privilege.
Small race in the group setting on the user page.
PR: https://forum.opnsense.org/index.php?topic=6994.0
The legacy code will still use a plain file_exists() for the optional theme.js, which keeps both in a working state after this commit.
To be able to move more files into the template directories for https://github.com/opnsense/core/pull/2124 we need to keep existing plugins functional, so we could integrate these changes into a minor release.
This works with both Android and Desktop Chrome (v63) as well as IE 11.
exception: there is apparently an incompatibility between Chrome and JQuery sortable. So drag/drop sort doesn't work in Chrome.
This is a modification of the previous:
3f7ee41b53
Touch events not working with the widget controls (link, buttons, drag/drop sort).
Add distance, delay and touch-action css for the widget controls to work with touch screen input.
Widget controls not working correctly with touch screen input
https://github.com/opnsense/core/issues/2092
Warning: The navigation role is unnecessary for element nav.
HTML 5.1 2nd Edition
W3C Recommendation 3 October 2017
4.3.4. The nav element
http://www.w3.org/TR/html51/sections.html#the-nav-element
Allowed ARIA role attribute values: ‘navigation’ role (default - do not set) or ‘presentation’.
http://www.w3.org/TR/html51/dom.html#do-not-set
Note: In the majority of cases setting an ARIA role and/or aria-* attribute that matches the default implicit ARIA semantics is unnecessary and not recommended as these properties are already set by the browser.
In the December 2017 document "is unnecessary and not recommended" is bold emphasized.
HTML 5.2
W3C Recommendation, 14 December 2017
http://www.w3.org/TR/html5/dom.html#aria-authoring-requirements
According to HTML5 Accessibility dot com, Chrome, Edge, and Safari have full support for the <nav> element. Firefox lacks only "Name/Description". Given the state of IE in this regard it is difficult to understand why anyone using it with assistive/accessibility technology at this point.
http://html5accessibility.com/
Markup like <nav role="navigation"> and <button role="button"> is superfluous since the HTML elements themselves already explain their role.
Widget purpose is to provide an overview, i.e. abbreviated information, of the firewall log. Details are available in the firewall log view.
Source port is not all that interesting. Consumes considerable space for not much value in this view.
Remove seconds from time field. Verbosity is available in the firewall log view.
Apply "table-condensed" class for better space utilization.
Settings:
Provide some separation between check boxes and make their labels active. Better accessibility and touch screen friendliness.
Error: A meta element with an http-equiv attribute whose value is X-UA-Compatible must have a content attribute with the value IE=edge.
The "Chrome=1" value was used to spawn Chrome Frame in IE 6,7,8,9. However, "Google Chrome Frame was discontinued in January 2014", and think all IE<11 is beyond EOL.
So is this even needed/useful?
If needed/useful it would probably be better to support deployment by HTTP headers method instead.
Google Chrome Frame
https://en.wikipedia.org/wiki/Google_Chrome_Frame
Touch events not working with the widget controls (link, buttons, drag/drop sort).
Add distance, delay and touch-action css for the widget controls to work with touch screen input.
Widget controls not working correctly with touch screen input
https://github.com/opnsense/core/issues/2092
Widget names are derived from the widget file base name, which in turn is used to obtain the widget title link.
This restores the original interfaces widget file base name, which fixes the broken title link.
