* rework search form as grid layout
* remove various paddings and margins
* add logo and link to index to search form
* make categories bigger on phone
* clean up vars in defenition
* results look now the same on mobile and desktop
* reworked results on mobile
* new color theme with more vibrant colors
* remove vars and add elements to base and btn vars
* change default border radius to 10px and padding to 0.7em
* put border radius and padding on search input form, infoxbox and buttons
* remove unused .help class in #categories_container
* remove active background from tabs to straemline design
* redo search form: 10px padding
* 2rem margin on search results on desktop
* fix modal pacement of engine reliability in prefs
* use darker accent colors
* streamline autocomplete with more padding and a hover effect
The default *sans-serif* font from the browsers most often renders much better
compared to Arial font.
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
- using more rem in style and definitions
- mobile width in preferences.less fix max-width: 75em to 80em (normalized with
style.less and other)
- do not display #backToTop position on tablet (when max-width: 80em)
- fix answer box on mobile (when max-width: 50em)
- move jshint option from gruntfile to .jshintrc
- remove trailing-whitespace from gruntfile and
- add jshint esversion: 6
- .dir-locals.el add locals for js-mode to use JSHint from the simple theme
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
This patch disables role 'no-descending-specificity'. IMO it is better to have
this rule active (see below [1]), but it is hard to rewrite the less files to
pass this rule, so for the first I chose to disable this rule.
---
Source order is important in CSS, and when two selectors have the same
specificity, the one that occurs last will take priority. However, the situation
is different when one of the selectors has a higher specificity. In that case,
source order does not matter: the selector with higher specificity will win out
even if it comes first.
The clashes of these two mechanisms for prioritization, source order and
specificity, can cause some confusion when reading stylesheets. If a selector
with higher specificity comes before the selector it overrides, we have to think
harder to understand it, because it violates the source order
expectation. Stylesheets are most legible when overriding selectors always come
after the selectors they override. That way both mechanisms, source order and
specificity, work together nicely.
This rule enforces that practice as best it can, reporting fewer errors than it
should. It cannot catch every actual overriding selector, but it can catch
certain common mistakes.
[1] https://stylelint.io/user-guide/rules/list/no-descending-specificity/
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>