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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

How about setting <body> to display: none until xforms-ready happens?

Steven

On Sun, 10 May 2020 21:28:59 +0200, Alain Couthures  
<ala...@ag...> wrote:

> In previous XSLTForms release, all controls were disabled, with a CSS  
> class, before evaluation to limit flickering when >building, especially  
> sensible for switch/case with just one selected case.
> This release does not use any CSS class but extra attributes which is  
> lighter for Javascript processing.
> The XSLT transformation is not even required if an author directly uses  
> the generated HTML5 notation. In this case, ><xforms-input  
> xf-ref="a"><xforms-label>A: </xforms-label></xforms-input> should not be  
> displayed until the extra xf-bound >attribute is added accordingly.
> It sounds then impossible to set the default to visible, doesn't it?
> --Alain
>> Le 10 mai 2020 à 19:33, Steven Pemberton <ste...@cw...> a  
>> écrit :
>> 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  
>> <ala...@ag...> 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 <ste...@cw...> 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  
>>>> <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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>