Oh dear - why devs don’t stop using !important - it is so hard to customize it
by use more specific selectors... anyway - as long as the css are clear and
simple to support functions of the backend they are ok. Users can even
customize them. display: none to hide something is simple and clear and
bug-free.
kind regards
Tobias
> Am 13.03.2020 um 15:21 schrieb Maxim Solodovnik <solomax...@gmail.com>:
>
> Additional note:
>
> Bootstrap has following CSS
>
> [hidden] {
> display: none !important;
> }
>
> which makes life much more diffiicult ...
>
>> On Fri, 13 Mar 2020 at 21:17, Martin Grigorov <mgrigo...@apache.org> wrote:
>>
>> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <mgrigo...@apache.org>
>> wrote:
>>
>>> Hi Sven,
>>>
>>> <html>
>>>
>>> <head>
>>> <style>
>>> /* rule from the application that should be used when the
>>> element is visible */
>>> div {
>>> display: flex;
>>> margin-bottom: 200px;
>>> }
>>>
>>> /* Rule coming from wicket-core.css */
>>> .wicket--hidden {
>>> display: none;
>>> }
>>>
>>> </style>
>>> </head>
>>>
>>> <body>
>>> <p>
>>> Element when visible: <br/>
>>> A1 <div id="blah1.1" >B1</div> C1 <span>D1</span>
>>> <br/>
>>> </p>
>>> <p>
>>> Element when hidden (there is no B1 because Wicket renders
>>> just the tag, without any children): <br/>
>>> A2 <div id="blah1.2" hidden></div> C2 <span>D2</span>
>>> <br/>
>>> <small><strong>C2 & D2</strong> are still 200px down
>>> because 'hidden' is not like 'display: none'!
>>> The application developer will have to do something more for
>>> the placeholder case to hide it.</small>
>>> </p>
>>>
>>> <p>
>>> Element with wicket--hidden class<br/>
>>> A3 <div id="blah3" class="wicket--hidden">B3</div> C3
>>> <span>D3</span>
>>> <br/>
>>> <small><strong>C3 & D3</strong> are not 200px down because
>>> of 'display: none'!
>>> The application developer has nothing to do!</small>
>>> </p>
>>> </body>
>>>
>>> </html>
>>>
>>> It shows two things:
>>>
>>> 1) since Wicket placeholder tags do not have children elements [1] there
>>> is not really a need to use 'hidden' or 'display: none'
>>>
>>
>> As I explained below we do need to use display: none.
>> I've forgot to update this line.
>>
>>
>>>
>>> 2) if we really want to hide the element without leaving extra work for
>>> web designers then we have to use display: none
>>>
>>>
>>> 1.
>>> https://github.com/apache/wicket/blob/10d10a92dda2e5834508f52d7807fe361f20fbea/wicket-core/src/main/java/org/apache/wicket/Component.java#L2370
>>>
>>>
>>>
>>>> On Thu, Mar 12, 2020 at 4:35 PM Sven Meier <s...@meiers.net> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've looked at all responses and most arguments in favor of a "core.css"
>>>> boil down to:
>>>>
>>>>> `hidden` attribute doesn't work (even `display: flex` breaks it)
>>>>
>>>>> Using the hidden attribute puts the responsibility with the developer
>>>>> where this should be on the framework. The hidden attribute just
>>>> doesn't work.
>>>>
>>>>> When something as simple as using flex or display:block on a div breaks
>>>>> the hidden attribute [1] we should not depend on it working.
>>>>
>>>> Sorry, but I don't share that assessment: 'hidden' works just fine!
>>>> Every browser supports it and it has a strong semantic meaning we can
>>>> utilize.
>>>>
>>>> If you (or your web designer) decides to style hidden elements as
>>>> floating, static, flex, pink or with marquee ... feel free to do so.
>>>>
>>>
>>> No. The web designer styles the element when it is supposed to be visible.
>>> But then when some condition is met Wicket may render it as a placeholder
>>> for Ajax requests and then this element will be rendered.
>>> It does not have text content but the CSS rules will be still applied and
>>> the web designer will have to add more rules for the cases when 'hidden' is
>>> there.
>>> Most probably something like:
>>> div[hidden] {
>>> display:none;
>>> }
>>>
>>>
>>>> Wicket doesn't need to ship a CSS file to fix anything here.
>>>> Note that the way we are hiding components in Wicket never exposes any
>>>> sensible information anyways. This topic is just about layout and
>>>> styling and that is completely in the responsibility of your developer
>>>> ... and works out-of-the-box if you don't break it!
>>>>
>>>
>>> What about the cases when the children need to be invisible ?
>>> .wicket--hidden-fields
>>>
>>>
>>>>
>>>>> Wicket ... has been dependent on its own styles, spread out through
>>>> our code in odd ways
>>>>> I consider not having a wicket stylesheet file a bug, not a feature
>>>>
>>>> I couldn't disagree more. These "odd ways" is one of many cool features
>>>> of Wicket named "components". BTW we Wicket devs have never been very
>>>> successful in crafting CSS anyways, we shouldn't start with this now :P.
>>>>
>>>
>>> We don't really start.
>>> We do not mandate styling. We just hide whatever is supposed to be hidden.
>>> Nothing more.
>>>
>>> As agreed (?!) earlier .wicket--color-red should be just a marker CSS
>>> class. The content should be provided by the application. Just like
>>> FeedbackPanel's CSS classes. I will remove it now!
>>>
>>>
>>>>
>>>> I'll start a vote soon.
>>>>
>>>> Sidenote : This doesn't mean I'm against the CSP feature in general!
>>>> After some iterations we arrived at a very cool solution (with some
>>>> minor detail questions remaining).
>>>>
>>>> Have fun
>>>> Sven
>>>>
>>>> On 27.02.20 22:18, Emond Papegaaij wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> I thought of this solution as well and it will work. The major
>>>>> advantage is that the styling is only added when it is actually used.
>>>>> But it requires significantly more work to build and is a lot more
>>>>> complex than the current solution. For this, we need some place to
>>>>> accumulate element styling, like we do for JS event handlers. This
>>>>> then needs to be rendered in the response.
>>>>>
>>>>> The most complex part is ajax updates. These might change some of the
>>>>> styling. Simply replacing the style element will not work, because in
>>>>> an ajax request only the added components are rendered. Rendering a
>>>>> style element per component will work, but is far from ideal. This is
>>>>> why I went for the easy solution.
>>>>>
>>>>> Emond
>>>>>
>>>>> On Thu, Feb 27, 2020 at 10:08 PM Andrew Kondratev <and...@kondratev.pro>
>>>> wrote:
>>>>>> Just as a brainstorm. Not sure if it's a good idea.
>>>>>>
>>>>>> Wicket potentially can add nounced style to the document with hidden
>>>>>> elements hidden by id.
>>>>>>
>>>>>> Imagine generated HTML has components like these
>>>>>> <div class="wupb-container">
>>>>>> <div class="wupb-progressBar" id="ida"><div
>>>>>> class="wupb-border"><div class="wupb-background"><div
>>>>>> class="wupb-foreground"></div></div></div></div>
>>>>>> <div class="wupb-uploadStatus" id="id9"></div>
>>>>>> </div>
>>>>>>
>>>>>> #ida and #id9 must be hidden, so in the page header we add something
>>>> like
>>>>>> this
>>>>>>
>>>>>> <style nonce="abracadabra">
>>>>>> #ida, #id9 {display: none;}
>>>>>> </style>
>>>>>>
>>>>>> Even if the wupb-progressBar has display: flex, the #ida will win.
>>>> Will
>>>>>> win even over #id8 .wupb-progressBar {display: fles}
>>>>>>
>>>>>> !important can potentially be added.
>>>>>>
>>>>>>
>>>>>> чт, 27 февр. 2020 г. в 23:56, Ernesto Reinaldo Barreiro <
>>>> reier...@gmail.com
>>>>>>> :
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
>>>> an.delb...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
>>>>>>>> reier...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Right now I have no enough knowledge to vote in this feature. One
>>>>>>> thing I
>>>>>>>>> didn't like, and I already mentioned it before, is some of us were
>>>>>>>> waiting
>>>>>>>>> for 9.x to be released some time ago (at least a few months ago I
>>>> was
>>>>>>>>> preparing some branch of our application and ported it to 9.x, after
>>>>>>>> asking
>>>>>>>>> about release plans) and all of the sudden this feature is
>>>> introduced
>>>>>>> and
>>>>>>>>> all sub-frameworks depending on Wicket will have to be adapted.
>>>>>>>>
>>>>>>>> In which way sub-frameworks should be affected? I mean, as far as I
>>>>>>>> understand it, if we disable CSP blocking configuration everything
>>>> should
>>>>>>>> work "the old way", and that's why I would prefer to keep CSP
>>>> disabled by
>>>>>>>> default.
>>>>>>>>
>>>>>>> Well if something is supported at core level then if associated
>>>> projects
>>>>>>> want to comply with this new feature, which might be ideal, then
>>>> they will
>>>>>>> have to be adapted (or not?). I'm not talking about not releasing the
>>>> new
>>>>>>> feature. I'm talking about not releasing as part of 9.x, as it was
>>>> said to
>>>>>>> be almost ready for release a few months ago, and deffer it to 10.x
>>>> (and
>>>>>>> try to release it soon).
>>>>>>>
>>>>>>> --
>>>>>>> Regards - Ernesto Reinaldo Barreiro
>>>>>>>
>>>>
>>>
>
>
>
> --
> WBR
> Maxim aka solomax
