HINT: this patch has no functional change / it is the preparation for following
changes and bugfixes
Over the years, the preferences template became an unmanageable beast. To make
the source code more readable the monolith is splitted into elements. The
splitting into elements also has the advantage that a new template can make use
of them.
The reversed checkbox is a quirk that is only used in the prefereces and must be
eliminated in the long term. For this the macro 'checkbox_onoff_reversed' was
added to the preferences.html template. The 'checkbox' macro is also a quirk of
the preferences.html we don't want to use in other templates (it is an
input-checkbox in a HTML form that was misused for status display).
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
* mirror all inline SVGs so that direction SVGs display correctly on RTL
* set the bold list element in info box to RTL so the colon gets displayed on the right side
* set correct .ltr function for the left border on the search button in #q
* move text to the right in autocomplete
* move search form in lign with result article on RTL
* add the correct padding for img thumbnails in categories like music on RTL
* apply RTL to result table for map results
* align text in tables part of /preferences on RTL
* move burger menu on index page to the left on RTL
* fix positioning of drop down arrow on select boxes on RTL
* align result URL on the right (written LTR)
* align vim hotkeys help on the left since it is not translated
* image detail:
* labels (author, format, URL, etc...) are written on the right,
values are on the left.
* URL are written LTR and overflow on the right
* rework selection UI in pref (fix based on: 78643e9f43)
* moved search filters underneath categories
* cut params from url and replace / with ›
* make h3 and url in article bigger
* add safe search select to search filter (this will not override settings and only be valid while on result page in a session)
* make search form button not overlap each other when js is disabled
* 1rem padding around preview image and thumbnail in default article template
* update from ionicons-npm to ionicons ver.5
* drop the webfont built by grunt for icons
* built icons.html template for inlining icons with jinja2 into html
* update icon to use mostly the outline version
* add icons to categories and do not display them on mobile to save space
* remove all legacy ion icon font files from simple theme
* icons.html is added in this commit since make statc.build.restore requires git to know the file already
* cleanup error-dialog
* remove hover effect from vim help modal
* remove bold font weight from active item in prefenreces tab bar
* remove margin from answer box to unify with rest of result page
buttons:
* previous & next in the result page
* save, restore, & back in the preferences
* back to top
<select> input in Chrom* browsers:
* fix the white text with a white background issue
It is not possible to use CSS variable in a SVG when this is in a background.
This commit adds two .svg files, less converts them into data URL.
The two files are indentical except the fill color.
* 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
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>
This fix was autogenerated by::
npx stylelint -f unix --fix 'searx/static/themes/simple/src/less/**/*.less'
Signed-off-by: Markus Heiser <markus.heiser@darmarit.de>
