On Sun, 10 May 2020, Steven Pemberton wrote:
The current stylesheet sets everything to display: none, and then adds the
cases when it is not display: none.
I think the cure is to do it the other way round: set the default to visible
(inline/block) for those elements where this makes sense (like input, but not
the actions, model etc.) and then specify explicitly the cases where display
is none.
In that way, user added CSS (which is only interested in when the elements
are visible) can override the default case. The long, specific selectors for
display: none will never need to be overridden.
Steven
On Sun, 10 May 2020 16:06:25 +0200, Alain Couthures
<[email protected]> wrote:
Maybe it could be better if the XSLT stylesheet could read some option to
generate a reference to another CSS stylesheet >(instead of xsltforms.css).
What do you think?
--Alain
Le 10 mai 2020 à 12:41, Steven Pemberton <[email protected]> a écrit
:
I have this problem too, and I'm trying to trace how to fix it. The
xsltforms css has rules like:
xforms-input[xf-bound]:not([xf-notrelevant]) {display: inline}
which have very high 'specificity'. The CSS1 spec* says:
* Find all declarations that apply to the element/property in question.
Declarations apply if the selector >>matches the element in question. If
no declarations apply, the inherited value is used. If there is no
inherited >>value (this is the case for the 'HTML' element and for
properties that do not inherit), the initial value is >>used.* Sort the
declarations by explicit weight: declarations marked '!important' carry
more weight than unmarked >>(normal) declarations.* Sort by origin: the
author's style sheets override the reader's style sheet which override the
UA's default >>values. An imported style sheet has the same origin as the
style sheet from which it is imported.* Sort by specificity of selector:
more specific selectors will override more general ones. To find the
>>specificity, count the number of ID attributes in the selector (a), the
number of CLASS attributes in the >>selector (b), and the number of tag
names in the selector (c). Concatenating the three numbers (in a number
>>system with a large base) gives the specificity.
"An imported style sheet has the same origin as the style sheet from which
it is imported." means, I think, that >>the xsltforms.css has the same
importance as the style in the form itself.
Using !important is in general a poor solution, because it overrides other
rules in your own styling, though it >>would often work.
I think, strictly speaking, you have to use the same selector or a more
specific one than in the xsltforms.css
So to change the display value, you have to use
xforms-input[xf-bound]:not([xf-notrelevant]) {display: block}
I will be experimenting with the xsltforms.css in the coming weeks to see
if we can improve on this situation, >>because it was easier to do in the
previous xsltforms.
Best wishes,
Steven
* The latest CSS spec is harder to read. Check it for yourself at
https://www.w3.org/TR/selectors/#specificity
A rule of relevance is:
The specificity of an :is(), :not(), or :has() pseudo-class is replaced by
the specificity of the most specific >>complex selector in its selector
list argument.
On Sun, 10 May 2020 09:57:26 +0200, Alain Couthures
<[email protected]> wrote:
Hello Habs,
Sorry, I am not a CSS expert but I think that, in such as situation, you
have to add !important in >>>your own CSS rule to override the default
behaviour.
Thank you for your feedback!
--Alain
Le 22 avril 2020 à 15:03, Habs < [email protected]> a écrit :
Hello all :)
Using the new beta from here, www.agencexml.com/1.5beta/xsltforms.zip :
xf:input ( xforms-input when using a css inspecting tool ) defaults
to'display:inline'.
I can only seem to style a xf:input as 'display:block' by using aninline
style on the element
ie. <xf:input ... style="display: block">
and not in a external ref'd style sheet, or a style section within
'head',from where all other styling on the element appears to apply
withoutissue.
ie. xforms-input {display: block;}
Is it something I am getting wrong, or a bug, or ?
Thank you and regardsHabs
--- Sent using Alpine/Pine, probably the best MUA ---
_______________________________________________Xsltforms-support mailing
[email protected]https://lists.sourceforge.net/lists/listinfo/xsltforms-support
Thank you for the replies Steven and Alain.
I do too, not feel that using '!important' is the correct way forward.
Until this latest Xsltforms release, I was not experiencing this problem -
fortuitously or otherwise :-)
I will have another pick through following the comments. I have not got
into much detail yet and it is my first test and conversion of a few forms
working previously.
Thank you and regards. Best wishes.
Habs
--- Sent using Alpine/Pine, probably the best MUA ---
_______________________________________________
Xsltforms-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xsltforms-support
