Re: [Xsltforms-support] new beta release testing - possible styling bug - display:block
Brought to you by:
alain-couthures
Menu
▾
▴
Re: [Xsltforms-support] new beta release testing - possible styling bug - display:block
|
From: Steven P. <ste...@cw...> - 2020-05-10 20:02:04
|
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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
> |
