Re: [Xsltforms-support] new beta release testing - possible styling bug - display:block

[Steven P. <ste...@cw...>]

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  
<ala...@ag...> 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 < ge...@us...> 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 an 
>> inline 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 lis...@li... 
>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support