You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Sven Meier <sv...@meiers.net> on 2020/02/25 20:54:17 UTC
WICKET-6725 styling of hidden elements: no vote yet
Hi all,
we have a disagreement on how to style hidden elements in Wicket 9.x.
Due to the new CSP support we can no longer use inline styling to hide
elements.
WICKET-6725 introduces new CSS classes and a file wicket-core.css.
I don't think this is a good approach:
- it adds a CSS file that is referenced by each page (after Wicket doing
fine without it for 15 years)
- the CSS is a mingle-mangle of out-of-date stylings (see
.wicket--hidden-fields)
- it's a kitchen-sink for left-over styles (see .wicket--color-red)
- it introduces a new class naming scheme not used anywhere else (wicket--)
IMHO we should remove that file again (and the required infrastructure
in ResourceSettings/WebApplication) and just
use the HTML5 "hidden" attribute instead, whenever we want to hide
something (Component, Form, ...).
This "just works" in all browsers and is semantically correct. It has
one caveat when an application's CSS changes the default styling of
hidden elements (see
https://css-tricks.com/the-hidden-attribute-is-visibly-weak), but that's
in the responsibility of the application developer.
AjaxIndicatorAppender can just render a CSS class and leave the styling
to the application developer, nobody will be happy with the default
"red" anyway.
Thus I'll be starting a vote in the next days with the following two
options:
[] leave as is with .wicket--hidden & wicket-core.css
[] use HTML5 "hidden" attribute instead
This isn't the vote yet, it's just the announcement.
Maybe others see a third (forth?) option or want to raise their concerns
first.
Sven
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Martijn Dashorst <ma...@gmail.com>.
On Tue, Feb 25, 2020 at 9:54 PM Sven Meier <sv...@meiers.net> wrote:
> [] leave as is with .wicket--hidden & wicket-core.css
>
> [] use HTML5 "hidden" attribute instead
>
While it is true that Wicket hasn't depended on a CSS file for its own use,
it has been dependent on its own styles, spread out through our code in odd
ways. The fact that we now have to own up to this by having to ship a
stylesheet file of our own after 15 years, sounds more like 15 years of
neglect and harassment of our users than an actual achievement. I consider
not having a wicket stylesheet file a bug, not a feature.
Having an actual Wicket css file means that our styles are *finally*
documented and available for our users to accommodate, rather than strewn
out through our code base and hidden in style attributes, only to be
discovered through perusing the generated markup or ample browsing through
java code. This is a great benefit: want to know what Wicket uses for
styling? Here's the file!
Furthermore, the wicket-core css file can be easily disabled if one desires
so (then you have add your own implementations of those classes to your own
css file), or overridden (e.g. wicket-bootstrap can provide its own core
css file). And we provide the default template as well...
This doesn't mean that I want us to ship a full bootstrap/material like CSS
styling with Wicket, but rather only those parts that ensure that
applications keep working.
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. Telling folks to
'just add some arbitrary css to your styling to fix this attribute so some
parts of your page remain invisible', is not a suitable substitute for
providing our own css.
Martijn
[1] https://meowni.ca/hidden.is.a.lie.html
Re: CSP and UI libraries
Posted by Maxim Solodovnik <so...@gmail.com>.
Yes,
All my prs were made with strict csp enabled
Additional minor change is required to make tests pass
Will create pr right after release
On Thu, Feb 27, 2020, 20:32 Martin Grigorov <mg...@apache.org> wrote:
> Thanks, Emond!
>
> @Maxim: since you started using Wicket 9.x Bootstrap 4.x recently: do you
> use it with CSP enabled ?
>
> On Thu, Feb 27, 2020 at 3:17 PM Emond Papegaaij <emond.papegaaij@gmail.com
> >
> wrote:
>
> > Hi Martin and Sebastien,
> >
> > I see no need for checking if CSP is enabled or not. It is not hard to
> > write your code to comply to even the strictest CSP. If it works with
> > the strict CSP, it will also work when CSP is disabled or with a less
> > strict CSP. Simply follow the few rules explained in the user guide.
> > Note that if your library needs to check if a nonce is required, this
> > is already supported, see
> > ContentSecurityPolicyEnforcer.isNonceEnabled().
> >
> > Our application uses WiQuery and several other frameworks, and I only
> > had to make minor changes to make this application fully compliant
> > with the strict CSP. No changes were required to WiQuery. A small
> > change is required to the ChartJS library we use
> > (https://github.com/haster/java-chartjs) because ChartJS tries to
> > insert a stylesheet into the head. This stylesheet has to be rendered
> > via Wicket to get the nonce.
> >
> > Best regards,
> > Emond
> >
> > On Thu, Feb 27, 2020 at 2:00 PM Sebastien Briquet <sb...@apache.org>
> > wrote:
> > >
> > > Hi Martin,
> > >
> > > Actually that's a good point! I will try to upgrade Wicket jQuery UI to
> > > wicket 9/CSP to see how it behaves...
> > >
> > > Thanks and best regards,
> > > Sebastien
> >
>
Re: CSP and UI libraries
Posted by Martin Grigorov <mg...@apache.org>.
Thanks, Emond!
@Maxim: since you started using Wicket 9.x Bootstrap 4.x recently: do you
use it with CSP enabled ?
On Thu, Feb 27, 2020 at 3:17 PM Emond Papegaaij <em...@gmail.com>
wrote:
> Hi Martin and Sebastien,
>
> I see no need for checking if CSP is enabled or not. It is not hard to
> write your code to comply to even the strictest CSP. If it works with
> the strict CSP, it will also work when CSP is disabled or with a less
> strict CSP. Simply follow the few rules explained in the user guide.
> Note that if your library needs to check if a nonce is required, this
> is already supported, see
> ContentSecurityPolicyEnforcer.isNonceEnabled().
>
> Our application uses WiQuery and several other frameworks, and I only
> had to make minor changes to make this application fully compliant
> with the strict CSP. No changes were required to WiQuery. A small
> change is required to the ChartJS library we use
> (https://github.com/haster/java-chartjs) because ChartJS tries to
> insert a stylesheet into the head. This stylesheet has to be rendered
> via Wicket to get the nonce.
>
> Best regards,
> Emond
>
> On Thu, Feb 27, 2020 at 2:00 PM Sebastien Briquet <sb...@apache.org>
> wrote:
> >
> > Hi Martin,
> >
> > Actually that's a good point! I will try to upgrade Wicket jQuery UI to
> > wicket 9/CSP to see how it behaves...
> >
> > Thanks and best regards,
> > Sebastien
>
Re: CSP and UI libraries
Posted by Emond Papegaaij <em...@gmail.com>.
Hi Martin and Sebastien,
I see no need for checking if CSP is enabled or not. It is not hard to
write your code to comply to even the strictest CSP. If it works with
the strict CSP, it will also work when CSP is disabled or with a less
strict CSP. Simply follow the few rules explained in the user guide.
Note that if your library needs to check if a nonce is required, this
is already supported, see
ContentSecurityPolicyEnforcer.isNonceEnabled().
Our application uses WiQuery and several other frameworks, and I only
had to make minor changes to make this application fully compliant
with the strict CSP. No changes were required to WiQuery. A small
change is required to the ChartJS library we use
(https://github.com/haster/java-chartjs) because ChartJS tries to
insert a stylesheet into the head. This stylesheet has to be rendered
via Wicket to get the nonce.
Best regards,
Emond
On Thu, Feb 27, 2020 at 2:00 PM Sebastien Briquet <sb...@apache.org> wrote:
>
> Hi Martin,
>
> Actually that's a good point! I will try to upgrade Wicket jQuery UI to
> wicket 9/CSP to see how it behaves...
>
> Thanks and best regards,
> Sebastien
Re: CSP and UI libraries
Posted by Maxim Solodovnik <so...@gmail.com>.
It is possible
but this CSP will not be `strict` anymore :)))
On Fri, 28 Feb 2020 at 15:23, Sebastien Briquet <sb...@apache.org> wrote:
>
> Thank you so much Emond! I will try that!
--
WBR
Maxim aka solomax
Re: CSP and UI libraries
Posted by Sebastien Briquet <sb...@apache.org>.
Thank you so much Emond! I will try that!
Re: CSP and UI libraries
Posted by Emond Papegaaij <em...@gmail.com>.
Hi Sebastien,
Unfortunately, not all libraries work with a strict CSP (Wicket used
to be one of those :) ). For such a library, you might want to roll a
less strict CSP via an IInitializer. From what I see in the link sent
by Maxim, you'll need to add 'unsafe-eval' for Kendo:
getCsp().blocking().add(CSPDirective.SCRIPT_SRC,
CSPDirectiveSrcValue.UNSAFE_EVAL);
Best regards,
Emond
On Fri, Feb 28, 2020 at 4:05 AM Sebastien Briquet <sb...@apache.org> wrote:
>
> Thank you very much for letting me know!
> I didn't exactly know what to expect until I would put my hands in it, but
> now I'm a little bit worried, haha !
>
> Best regards,
> Sebastien
Re: CSP and UI libraries
Posted by Maxim Solodovnik <so...@gmail.com>.
Sorry for bringing such news :(
On Fri, 28 Feb 2020 at 10:05, Sebastien Briquet <sb...@apache.org> wrote:
>
> Thank you very much for letting me know!
> I didn't exactly know what to expect until I would put my hands in it, but
> now I'm a little bit worried, haha !
>
> Best regards,
> Sebastien
--
WBR
Maxim aka solomax
Re: CSP and UI libraries
Posted by Sebastien Briquet <sb...@apache.org>.
Thank you very much for letting me know!
I didn't exactly know what to expect until I would put my hands in it, but
now I'm a little bit worried, haha !
Best regards,
Sebastien
Re: CSP and UI libraries
Posted by Maxim Solodovnik <so...@gmail.com>.
Hello Sebastien,
Unfortunately this task might be challenging :(
Kendo will not work in strict CSP mode :(
https://docs.telerik.com/kendo-ui/troubleshoot/content-security-policy
Other places to look at (should be easy to correct):
DisplayNoneBehavior
MessageDialog
:)))
On Thu, 27 Feb 2020 at 20:00, Sebastien Briquet <sb...@apache.org> wrote:
>
> Hi Martin,
>
> Actually that's a good point! I will try to upgrade Wicket jQuery UI to
> wicket 9/CSP to see how it behaves...
>
> Thanks and best regards,
> Sebastien
--
WBR
Maxim aka solomax
Re: CSP and UI libraries
Posted by Sebastien Briquet <sb...@apache.org>.
Hi Martin,
Actually that's a good point! I will try to upgrade Wicket jQuery UI to
wicket 9/CSP to see how it behaves...
Thanks and best regards,
Sebastien
Re: CSP and UI libraries
Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Feb 28, 2020 at 11:55 AM Martin Grigorov <mg...@apache.org>
wrote:
>
>
> On Fri, Feb 28, 2020 at 11:37 AM Andrea Del Bene <an...@gmail.com>
> wrote:
>
>> On Thu, Feb 27, 2020 at 1:03 PM Martin Grigorov <mg...@apache.org>
>> wrote:
>>
>> >
>> >
>> > I wanted to ask here whether we need an API that says whether CSP is
>> > enabled or disabled.
>> > For example UI libraries like Wicket Bootstrap & Wicket JQuery UI (and
>> any
>> > other) may use it to decide how to behave depending on the result.
>> > Because at the moment there is no place for assumption - every library
>> > should be updated to
>> > assume that CSP is always enabled.
>> >
>> >
>> >
>> I think it would be nice to provide such API for those who will have
>> problems adopting CSP. More generally I'd like to rework the CSP APIs in
>> order to make them coherent with code conventions we have adopted with the
>> other types of configurations . For example creating an
>> Application.getCSPSettings() to access CSP configuration.
>>
>
> +1 for this!
>
Done!
>
>
>
Re: CSP and UI libraries
Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Feb 28, 2020 at 11:37 AM Andrea Del Bene <an...@gmail.com>
wrote:
> On Thu, Feb 27, 2020 at 1:03 PM Martin Grigorov <mg...@apache.org>
> wrote:
>
> >
> >
> > I wanted to ask here whether we need an API that says whether CSP is
> > enabled or disabled.
> > For example UI libraries like Wicket Bootstrap & Wicket JQuery UI (and
> any
> > other) may use it to decide how to behave depending on the result.
> > Because at the moment there is no place for assumption - every library
> > should be updated to
> > assume that CSP is always enabled.
> >
> >
> >
> I think it would be nice to provide such API for those who will have
> problems adopting CSP. More generally I'd like to rework the CSP APIs in
> order to make them coherent with code conventions we have adopted with the
> other types of configurations . For example creating an
> Application.getCSPSettings() to access CSP configuration.
>
+1 for this!
Re: CSP and UI libraries
Posted by Andrea Del Bene <an...@gmail.com>.
On Thu, Feb 27, 2020 at 1:03 PM Martin Grigorov <mg...@apache.org>
wrote:
>
>
> I wanted to ask here whether we need an API that says whether CSP is
> enabled or disabled.
> For example UI libraries like Wicket Bootstrap & Wicket JQuery UI (and any
> other) may use it to decide how to behave depending on the result.
> Because at the moment there is no place for assumption - every library
> should be updated to
> assume that CSP is always enabled.
>
>
>
I think it would be nice to provide such API for those who will have
problems adopting CSP. More generally I'd like to rework the CSP APIs in
order to make them coherent with code conventions we have adopted with the
other types of configurations . For example creating an
Application.getCSPSettings() to access CSP configuration.
CSP and UI libraries
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
I'm creating a new thread to not hijack the discussion about the CSS
utilities.
On Thu, Feb 27, 2020 at 12:56 PM Ernesto Reinaldo Barreiro <
reiern70@gmail.com> wrote:
> Hi,
>
> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <an...@gmail.com>
> wrote:
>
> > On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> > reiern70@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).
>
I wanted to ask here whether we need an API that says whether CSP is
enabled or disabled.
For example UI libraries like Wicket Bootstrap & Wicket JQuery UI (and any
other) may use it to decide how to behave depending on the result.
Because at the moment there is no place for assumption - every library
should be updated to
assume that CSP is always enabled.
>
> --
> Regards - Ernesto Reinaldo Barreiro
>
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Sven Meier <sv...@meiers.net>.
Hi Martin,
sorry, I don't get it.
You can equally well just style it via "hidden" attribute:
*[hidden] {
display: none;
}
And no, this does *not* need to be provided by Wicket:
Whoever decides to flex *all* divs (you or your web designer), he will
be able to take care of those divs that should not be flexed.
I'm certain there will be many more exceptions, based on CSS class or
attribute.
"hidden" is no exception to that.
Thanks
Sven
On 13.03.20 15:16, Martin Grigorov wrote:
> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <mg...@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 <sv...@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 <an...@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 <
>>> reiern70@gmail.com
>>>>>> :
>>>>>> Hi,
>>>>>>
>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
>>> an.delbene@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
>>>>>>> reiern70@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
>>>>>>
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Tobias Soloschenko <to...@googlemail.com.INVALID>.
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 <so...@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 <mg...@apache.org> wrote:
>>
>> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <mg...@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 <sv...@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 <an...@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 <
>>>> reiern70@gmail.com
>>>>>>> :
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
>>>> an.delbene@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
>>>>>>>> reiern70@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
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Sven Meier <sv...@meiers.net>.
Hi Maxim,
thanks for your feedback.
Sven
On 27.03.20 05:06, Maxim Solodovnik wrote:
> Still no issues reported after 2 days of work at our demo server
> Seems this solution can be released :)
>
> On Wed, 25 Mar 2020 at 18:24, Maxim Solodovnik <so...@gmail.com> wrote:
>
>> first results: everything seems to work as expected
>> will continue testing
>>
>> On Wed, 25 Mar 2020 at 01:12, Sven Meier <sv...@meiers.net> wrote:
>>
>>> Hi,
>>>
>>> ok, let's give it a try!
>>>
>>> All hidden elements (hidden form fields or placeholders) are hidden via
>>> "hidden" attribute now.
>>>
>>> Have fun
>>> Sven
>>>
>>>
>>> On 24.03.20 08:15, Emond Papegaaij wrote:
>>>> Hi all,
>>>>
>>>> If you want to go ahead and remove the core CSS, please make sure all
>>>> components keep working. For example, in wicket extensions I had to
>>>> use the 'wicket--hidden' class in progressbar.js. Just do a grep on
>>>> 'wicket--hidden' and double-check those components in the examples.
>>>>
>>>> Best regards,
>>>> Emond
>>>>
>>>> On Tue, Mar 24, 2020 at 6:29 AM Maxim Solodovnik <so...@gmail.com>
>>> wrote:
>>>>> Let's try to remove this CSS and check :)
>>>>> I'm currently using latest wicket SNAPSHOT at master so most probably
>>>>> will provide some feedback :)
>>>>>
>>>>> On Fri, 20 Mar 2020 at 19:51, Martin Grigorov <mg...@apache.org>
>>> wrote:
>>>>>> In this case I am fine to go with 'hidden'.
>>>>>> We can introduce wicket-core.css later if needed.
>>>>>>
>>>>>> On Fri, Mar 20, 2020 at 1:44 PM Sven Meier <sv...@meiers.net> wrote:
>>>>>>
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> these stylings?
>>>>>>>
>>>>>>> width: 0px;
>>>>>>> height: 0px;
>>>>>>> position: absolute;
>>>>>>> left: -100px;
>>>>>>> top: -100px;
>>>>>>> overflow: hidden;
>>>>>>>
>>>>>>> They are a 10-year old workaround
>>>>>>>
>>>>>>>
>>>>>>>
>>> https://github.com/apache/wicket/commit/b00f8ed1647f7a69a38aba562efa98bb8eb84d97
>>>>>>> ... for a problem that no longer exists:
>>>>>>>
>>>>>>>
>>>>>>>
>>> https://stackoverflow.com/questions/8318428/submit-form-fields-inside-displaynone-element
>>>>>>> A simple "display:none"/"hidden" is sufficient.
>>>>>>>
>>>>>>> Sven
>>>>>>>
>>>>>>>
>>>>>>> On 20.03.20 10:29, Martin Grigorov wrote:
>>>>>>>> Hi Sven,
>>>>>>>>
>>>>>>>> What about wicket--hidden-fields ?
>>>>>>>> We still need wicket-core.css for it.
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> On Wed, Mar 18, 2020 at 11:25 PM Sven Meier <sv...@meiers.net>
>>> wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I've built an example to better demonstrate my argument:
>>>>>>>>>
>>>>>>>>> a) "hidden" tags work fine out-of-the-box :)
>>>>>>>>>
>>>>>>>>> https://jsfiddle.net/p8s7Lrk2/1/
>>>>>>>>>
>>>>>>>>> b) changing display of tags changes "hidden" tags too :(
>>>>>>>>>
>>>>>>>>> https://jsfiddle.net/p8s7Lrk2/2/
>>>>>>>>>
>>>>>>>>> c) and a simple fix for "hidden" tags - no !important required ...
>>> 8)
>>>>>>>>> https://jsfiddle.net/p8s7Lrk2/3/
>>>>>>>>>
>>>>>>>>> In my opinion there's no need to invent "wicket--hidden" when
>>> "hidden"
>>>>>>>>> works already as expected/needed (a).
>>>>>>>>> And furthermore Wicket does not need to provide a fix (c) for
>>> something
>>>>>>>>> the web designer screwed up (b) in the first place.
>>>>>>>>>
>>>>>>>>> Have fun
>>>>>>>>> Sven
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 17.03.20 13:01, Maxim Solodovnik wrote:
>>>>>>>>>> Hello Sven,
>>>>>>>>>>
>>>>>>>>>> I always thought:having override like this will require
>>> re-testing all
>>>>>>>>>> 3rd-party components manually
>>>>>>>>>> (I don't have that much time)
>>>>>>>>>> So I'm using library as-is and override as minimum as possible :)
>>>>>>>>>>
>>>>>>>>>> On Tue, 17 Mar 2020 at 18:56, Sven Meier <sv...@meiers.net> wrote:
>>>>>>>>>>> Hi Maxim,
>>>>>>>>>>>
>>>>>>>>>>> what is difficult about that?
>>>>>>>>>>>
>>>>>>>>>>> Actually it is recommended to have it in your normalize.css
>>> (formerly
>>>>>>>>>>> reset.css).
>>>>>>>>>>>
>>>>>>>>>>> Here one without !important:
>>>>>>>>>>>
>>>>>>>>>>>
>>> https://github.com/necolas/normalize.css/blob/master/normalize.css
>>>>>>>>>>> Sven
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 13.03.20 15:21, Maxim Solodovnik wrote:
>>>>>>>>>>>> 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 <
>>> mgrigorov@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>>>> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <
>>>>>>> mgrigorov@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 <sv...@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 <
>>>>>>>>> andrew@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 <
>>>>>>>>>>>>>>> reiern70@gmail.com
>>>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
>>>>>>>>>>>>>>> an.delbene@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo
>>> Barreiro <
>>>>>>>>>>>>>>>>>>> reiern70@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
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Maxim Solodovnik <so...@gmail.com>.
Still no issues reported after 2 days of work at our demo server
Seems this solution can be released :)
On Wed, 25 Mar 2020 at 18:24, Maxim Solodovnik <so...@gmail.com> wrote:
> first results: everything seems to work as expected
> will continue testing
>
> On Wed, 25 Mar 2020 at 01:12, Sven Meier <sv...@meiers.net> wrote:
>
>> Hi,
>>
>> ok, let's give it a try!
>>
>> All hidden elements (hidden form fields or placeholders) are hidden via
>> "hidden" attribute now.
>>
>> Have fun
>> Sven
>>
>>
>> On 24.03.20 08:15, Emond Papegaaij wrote:
>> > Hi all,
>> >
>> > If you want to go ahead and remove the core CSS, please make sure all
>> > components keep working. For example, in wicket extensions I had to
>> > use the 'wicket--hidden' class in progressbar.js. Just do a grep on
>> > 'wicket--hidden' and double-check those components in the examples.
>> >
>> > Best regards,
>> > Emond
>> >
>> > On Tue, Mar 24, 2020 at 6:29 AM Maxim Solodovnik <so...@gmail.com>
>> wrote:
>> >> Let's try to remove this CSS and check :)
>> >> I'm currently using latest wicket SNAPSHOT at master so most probably
>> >> will provide some feedback :)
>> >>
>> >> On Fri, 20 Mar 2020 at 19:51, Martin Grigorov <mg...@apache.org>
>> wrote:
>> >>> In this case I am fine to go with 'hidden'.
>> >>> We can introduce wicket-core.css later if needed.
>> >>>
>> >>> On Fri, Mar 20, 2020 at 1:44 PM Sven Meier <sv...@meiers.net> wrote:
>> >>>
>> >>>> Hi Martin,
>> >>>>
>> >>>> these stylings?
>> >>>>
>> >>>> width: 0px;
>> >>>> height: 0px;
>> >>>> position: absolute;
>> >>>> left: -100px;
>> >>>> top: -100px;
>> >>>> overflow: hidden;
>> >>>>
>> >>>> They are a 10-year old workaround
>> >>>>
>> >>>>
>> >>>>
>> https://github.com/apache/wicket/commit/b00f8ed1647f7a69a38aba562efa98bb8eb84d97
>> >>>>
>> >>>> ... for a problem that no longer exists:
>> >>>>
>> >>>>
>> >>>>
>> https://stackoverflow.com/questions/8318428/submit-form-fields-inside-displaynone-element
>> >>>>
>> >>>> A simple "display:none"/"hidden" is sufficient.
>> >>>>
>> >>>> Sven
>> >>>>
>> >>>>
>> >>>> On 20.03.20 10:29, Martin Grigorov wrote:
>> >>>>> Hi Sven,
>> >>>>>
>> >>>>> What about wicket--hidden-fields ?
>> >>>>> We still need wicket-core.css for it.
>> >>>>>
>> >>>>> Martin
>> >>>>>
>> >>>>> On Wed, Mar 18, 2020 at 11:25 PM Sven Meier <sv...@meiers.net>
>> wrote:
>> >>>>>
>> >>>>>> Hi all,
>> >>>>>>
>> >>>>>> I've built an example to better demonstrate my argument:
>> >>>>>>
>> >>>>>> a) "hidden" tags work fine out-of-the-box :)
>> >>>>>>
>> >>>>>> https://jsfiddle.net/p8s7Lrk2/1/
>> >>>>>>
>> >>>>>> b) changing display of tags changes "hidden" tags too :(
>> >>>>>>
>> >>>>>> https://jsfiddle.net/p8s7Lrk2/2/
>> >>>>>>
>> >>>>>> c) and a simple fix for "hidden" tags - no !important required ...
>> 8)
>> >>>>>>
>> >>>>>> https://jsfiddle.net/p8s7Lrk2/3/
>> >>>>>>
>> >>>>>> In my opinion there's no need to invent "wicket--hidden" when
>> "hidden"
>> >>>>>> works already as expected/needed (a).
>> >>>>>> And furthermore Wicket does not need to provide a fix (c) for
>> something
>> >>>>>> the web designer screwed up (b) in the first place.
>> >>>>>>
>> >>>>>> Have fun
>> >>>>>> Sven
>> >>>>>>
>> >>>>>>
>> >>>>>> On 17.03.20 13:01, Maxim Solodovnik wrote:
>> >>>>>>> Hello Sven,
>> >>>>>>>
>> >>>>>>> I always thought:having override like this will require
>> re-testing all
>> >>>>>>> 3rd-party components manually
>> >>>>>>> (I don't have that much time)
>> >>>>>>> So I'm using library as-is and override as minimum as possible :)
>> >>>>>>>
>> >>>>>>> On Tue, 17 Mar 2020 at 18:56, Sven Meier <sv...@meiers.net> wrote:
>> >>>>>>>> Hi Maxim,
>> >>>>>>>>
>> >>>>>>>> what is difficult about that?
>> >>>>>>>>
>> >>>>>>>> Actually it is recommended to have it in your normalize.css
>> (formerly
>> >>>>>>>> reset.css).
>> >>>>>>>>
>> >>>>>>>> Here one without !important:
>> >>>>>>>>
>> >>>>>>>>
>> https://github.com/necolas/normalize.css/blob/master/normalize.css
>> >>>>>>>>
>> >>>>>>>> Sven
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On 13.03.20 15:21, Maxim Solodovnik wrote:
>> >>>>>>>>> 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 <
>> mgrigorov@apache.org>
>> >>>>>> wrote:
>> >>>>>>>>>> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <
>> >>>> mgrigorov@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 <sv...@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 <
>> >>>>>> andrew@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 <
>> >>>>>>>>>>>> reiern70@gmail.com
>> >>>>>>>>>>>>>>> :
>> >>>>>>>>>>>>>>> Hi,
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
>> >>>>>>>>>>>> an.delbene@gmail.com>
>> >>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo
>> Barreiro <
>> >>>>>>>>>>>>>>>> reiern70@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
>>
>
>
> --
> WBR
> Maxim aka solomax
>
--
WBR
Maxim aka solomax
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Maxim Solodovnik <so...@gmail.com>.
first results: everything seems to work as expected
will continue testing
On Wed, 25 Mar 2020 at 01:12, Sven Meier <sv...@meiers.net> wrote:
> Hi,
>
> ok, let's give it a try!
>
> All hidden elements (hidden form fields or placeholders) are hidden via
> "hidden" attribute now.
>
> Have fun
> Sven
>
>
> On 24.03.20 08:15, Emond Papegaaij wrote:
> > Hi all,
> >
> > If you want to go ahead and remove the core CSS, please make sure all
> > components keep working. For example, in wicket extensions I had to
> > use the 'wicket--hidden' class in progressbar.js. Just do a grep on
> > 'wicket--hidden' and double-check those components in the examples.
> >
> > Best regards,
> > Emond
> >
> > On Tue, Mar 24, 2020 at 6:29 AM Maxim Solodovnik <so...@gmail.com>
> wrote:
> >> Let's try to remove this CSS and check :)
> >> I'm currently using latest wicket SNAPSHOT at master so most probably
> >> will provide some feedback :)
> >>
> >> On Fri, 20 Mar 2020 at 19:51, Martin Grigorov <mg...@apache.org>
> wrote:
> >>> In this case I am fine to go with 'hidden'.
> >>> We can introduce wicket-core.css later if needed.
> >>>
> >>> On Fri, Mar 20, 2020 at 1:44 PM Sven Meier <sv...@meiers.net> wrote:
> >>>
> >>>> Hi Martin,
> >>>>
> >>>> these stylings?
> >>>>
> >>>> width: 0px;
> >>>> height: 0px;
> >>>> position: absolute;
> >>>> left: -100px;
> >>>> top: -100px;
> >>>> overflow: hidden;
> >>>>
> >>>> They are a 10-year old workaround
> >>>>
> >>>>
> >>>>
> https://github.com/apache/wicket/commit/b00f8ed1647f7a69a38aba562efa98bb8eb84d97
> >>>>
> >>>> ... for a problem that no longer exists:
> >>>>
> >>>>
> >>>>
> https://stackoverflow.com/questions/8318428/submit-form-fields-inside-displaynone-element
> >>>>
> >>>> A simple "display:none"/"hidden" is sufficient.
> >>>>
> >>>> Sven
> >>>>
> >>>>
> >>>> On 20.03.20 10:29, Martin Grigorov wrote:
> >>>>> Hi Sven,
> >>>>>
> >>>>> What about wicket--hidden-fields ?
> >>>>> We still need wicket-core.css for it.
> >>>>>
> >>>>> Martin
> >>>>>
> >>>>> On Wed, Mar 18, 2020 at 11:25 PM Sven Meier <sv...@meiers.net> wrote:
> >>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> I've built an example to better demonstrate my argument:
> >>>>>>
> >>>>>> a) "hidden" tags work fine out-of-the-box :)
> >>>>>>
> >>>>>> https://jsfiddle.net/p8s7Lrk2/1/
> >>>>>>
> >>>>>> b) changing display of tags changes "hidden" tags too :(
> >>>>>>
> >>>>>> https://jsfiddle.net/p8s7Lrk2/2/
> >>>>>>
> >>>>>> c) and a simple fix for "hidden" tags - no !important required ...
> 8)
> >>>>>>
> >>>>>> https://jsfiddle.net/p8s7Lrk2/3/
> >>>>>>
> >>>>>> In my opinion there's no need to invent "wicket--hidden" when
> "hidden"
> >>>>>> works already as expected/needed (a).
> >>>>>> And furthermore Wicket does not need to provide a fix (c) for
> something
> >>>>>> the web designer screwed up (b) in the first place.
> >>>>>>
> >>>>>> Have fun
> >>>>>> Sven
> >>>>>>
> >>>>>>
> >>>>>> On 17.03.20 13:01, Maxim Solodovnik wrote:
> >>>>>>> Hello Sven,
> >>>>>>>
> >>>>>>> I always thought:having override like this will require re-testing
> all
> >>>>>>> 3rd-party components manually
> >>>>>>> (I don't have that much time)
> >>>>>>> So I'm using library as-is and override as minimum as possible :)
> >>>>>>>
> >>>>>>> On Tue, 17 Mar 2020 at 18:56, Sven Meier <sv...@meiers.net> wrote:
> >>>>>>>> Hi Maxim,
> >>>>>>>>
> >>>>>>>> what is difficult about that?
> >>>>>>>>
> >>>>>>>> Actually it is recommended to have it in your normalize.css
> (formerly
> >>>>>>>> reset.css).
> >>>>>>>>
> >>>>>>>> Here one without !important:
> >>>>>>>>
> >>>>>>>>
> https://github.com/necolas/normalize.css/blob/master/normalize.css
> >>>>>>>>
> >>>>>>>> Sven
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 13.03.20 15:21, Maxim Solodovnik wrote:
> >>>>>>>>> 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 <
> mgrigorov@apache.org>
> >>>>>> wrote:
> >>>>>>>>>> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <
> >>>> mgrigorov@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 <sv...@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 <
> >>>>>> andrew@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 <
> >>>>>>>>>>>> reiern70@gmail.com
> >>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
> >>>>>>>>>>>> an.delbene@gmail.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo
> Barreiro <
> >>>>>>>>>>>>>>>> reiern70@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
>
--
WBR
Maxim aka solomax
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Sven Meier <sv...@meiers.net>.
Hi,
ok, let's give it a try!
All hidden elements (hidden form fields or placeholders) are hidden via
"hidden" attribute now.
Have fun
Sven
On 24.03.20 08:15, Emond Papegaaij wrote:
> Hi all,
>
> If you want to go ahead and remove the core CSS, please make sure all
> components keep working. For example, in wicket extensions I had to
> use the 'wicket--hidden' class in progressbar.js. Just do a grep on
> 'wicket--hidden' and double-check those components in the examples.
>
> Best regards,
> Emond
>
> On Tue, Mar 24, 2020 at 6:29 AM Maxim Solodovnik <so...@gmail.com> wrote:
>> Let's try to remove this CSS and check :)
>> I'm currently using latest wicket SNAPSHOT at master so most probably
>> will provide some feedback :)
>>
>> On Fri, 20 Mar 2020 at 19:51, Martin Grigorov <mg...@apache.org> wrote:
>>> In this case I am fine to go with 'hidden'.
>>> We can introduce wicket-core.css later if needed.
>>>
>>> On Fri, Mar 20, 2020 at 1:44 PM Sven Meier <sv...@meiers.net> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> these stylings?
>>>>
>>>> width: 0px;
>>>> height: 0px;
>>>> position: absolute;
>>>> left: -100px;
>>>> top: -100px;
>>>> overflow: hidden;
>>>>
>>>> They are a 10-year old workaround
>>>>
>>>>
>>>> https://github.com/apache/wicket/commit/b00f8ed1647f7a69a38aba562efa98bb8eb84d97
>>>>
>>>> ... for a problem that no longer exists:
>>>>
>>>>
>>>> https://stackoverflow.com/questions/8318428/submit-form-fields-inside-displaynone-element
>>>>
>>>> A simple "display:none"/"hidden" is sufficient.
>>>>
>>>> Sven
>>>>
>>>>
>>>> On 20.03.20 10:29, Martin Grigorov wrote:
>>>>> Hi Sven,
>>>>>
>>>>> What about wicket--hidden-fields ?
>>>>> We still need wicket-core.css for it.
>>>>>
>>>>> Martin
>>>>>
>>>>> On Wed, Mar 18, 2020 at 11:25 PM Sven Meier <sv...@meiers.net> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I've built an example to better demonstrate my argument:
>>>>>>
>>>>>> a) "hidden" tags work fine out-of-the-box :)
>>>>>>
>>>>>> https://jsfiddle.net/p8s7Lrk2/1/
>>>>>>
>>>>>> b) changing display of tags changes "hidden" tags too :(
>>>>>>
>>>>>> https://jsfiddle.net/p8s7Lrk2/2/
>>>>>>
>>>>>> c) and a simple fix for "hidden" tags - no !important required ... 8)
>>>>>>
>>>>>> https://jsfiddle.net/p8s7Lrk2/3/
>>>>>>
>>>>>> In my opinion there's no need to invent "wicket--hidden" when "hidden"
>>>>>> works already as expected/needed (a).
>>>>>> And furthermore Wicket does not need to provide a fix (c) for something
>>>>>> the web designer screwed up (b) in the first place.
>>>>>>
>>>>>> Have fun
>>>>>> Sven
>>>>>>
>>>>>>
>>>>>> On 17.03.20 13:01, Maxim Solodovnik wrote:
>>>>>>> Hello Sven,
>>>>>>>
>>>>>>> I always thought:having override like this will require re-testing all
>>>>>>> 3rd-party components manually
>>>>>>> (I don't have that much time)
>>>>>>> So I'm using library as-is and override as minimum as possible :)
>>>>>>>
>>>>>>> On Tue, 17 Mar 2020 at 18:56, Sven Meier <sv...@meiers.net> wrote:
>>>>>>>> Hi Maxim,
>>>>>>>>
>>>>>>>> what is difficult about that?
>>>>>>>>
>>>>>>>> Actually it is recommended to have it in your normalize.css (formerly
>>>>>>>> reset.css).
>>>>>>>>
>>>>>>>> Here one without !important:
>>>>>>>>
>>>>>>>> https://github.com/necolas/normalize.css/blob/master/normalize.css
>>>>>>>>
>>>>>>>> Sven
>>>>>>>>
>>>>>>>>
>>>>>>>> On 13.03.20 15:21, Maxim Solodovnik wrote:
>>>>>>>>> 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 <mg...@apache.org>
>>>>>> wrote:
>>>>>>>>>> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <
>>>> mgrigorov@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 <sv...@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 <
>>>>>> andrew@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 <
>>>>>>>>>>>> reiern70@gmail.com
>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
>>>>>>>>>>>> an.delbene@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
>>>>>>>>>>>>>>>> reiern70@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
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Emond Papegaaij <em...@gmail.com>.
Hi all,
If you want to go ahead and remove the core CSS, please make sure all
components keep working. For example, in wicket extensions I had to
use the 'wicket--hidden' class in progressbar.js. Just do a grep on
'wicket--hidden' and double-check those components in the examples.
Best regards,
Emond
On Tue, Mar 24, 2020 at 6:29 AM Maxim Solodovnik <so...@gmail.com> wrote:
>
> Let's try to remove this CSS and check :)
> I'm currently using latest wicket SNAPSHOT at master so most probably
> will provide some feedback :)
>
> On Fri, 20 Mar 2020 at 19:51, Martin Grigorov <mg...@apache.org> wrote:
> >
> > In this case I am fine to go with 'hidden'.
> > We can introduce wicket-core.css later if needed.
> >
> > On Fri, Mar 20, 2020 at 1:44 PM Sven Meier <sv...@meiers.net> wrote:
> >
> > > Hi Martin,
> > >
> > > these stylings?
> > >
> > > width: 0px;
> > > height: 0px;
> > > position: absolute;
> > > left: -100px;
> > > top: -100px;
> > > overflow: hidden;
> > >
> > > They are a 10-year old workaround
> > >
> > >
> > > https://github.com/apache/wicket/commit/b00f8ed1647f7a69a38aba562efa98bb8eb84d97
> > >
> > > ... for a problem that no longer exists:
> > >
> > >
> > > https://stackoverflow.com/questions/8318428/submit-form-fields-inside-displaynone-element
> > >
> > > A simple "display:none"/"hidden" is sufficient.
> > >
> > > Sven
> > >
> > >
> > > On 20.03.20 10:29, Martin Grigorov wrote:
> > > > Hi Sven,
> > > >
> > > > What about wicket--hidden-fields ?
> > > > We still need wicket-core.css for it.
> > > >
> > > > Martin
> > > >
> > > > On Wed, Mar 18, 2020 at 11:25 PM Sven Meier <sv...@meiers.net> wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> I've built an example to better demonstrate my argument:
> > > >>
> > > >> a) "hidden" tags work fine out-of-the-box :)
> > > >>
> > > >> https://jsfiddle.net/p8s7Lrk2/1/
> > > >>
> > > >> b) changing display of tags changes "hidden" tags too :(
> > > >>
> > > >> https://jsfiddle.net/p8s7Lrk2/2/
> > > >>
> > > >> c) and a simple fix for "hidden" tags - no !important required ... 8)
> > > >>
> > > >> https://jsfiddle.net/p8s7Lrk2/3/
> > > >>
> > > >> In my opinion there's no need to invent "wicket--hidden" when "hidden"
> > > >> works already as expected/needed (a).
> > > >> And furthermore Wicket does not need to provide a fix (c) for something
> > > >> the web designer screwed up (b) in the first place.
> > > >>
> > > >> Have fun
> > > >> Sven
> > > >>
> > > >>
> > > >> On 17.03.20 13:01, Maxim Solodovnik wrote:
> > > >>> Hello Sven,
> > > >>>
> > > >>> I always thought:having override like this will require re-testing all
> > > >>> 3rd-party components manually
> > > >>> (I don't have that much time)
> > > >>> So I'm using library as-is and override as minimum as possible :)
> > > >>>
> > > >>> On Tue, 17 Mar 2020 at 18:56, Sven Meier <sv...@meiers.net> wrote:
> > > >>>> Hi Maxim,
> > > >>>>
> > > >>>> what is difficult about that?
> > > >>>>
> > > >>>> Actually it is recommended to have it in your normalize.css (formerly
> > > >>>> reset.css).
> > > >>>>
> > > >>>> Here one without !important:
> > > >>>>
> > > >>>> https://github.com/necolas/normalize.css/blob/master/normalize.css
> > > >>>>
> > > >>>> Sven
> > > >>>>
> > > >>>>
> > > >>>> On 13.03.20 15:21, Maxim Solodovnik wrote:
> > > >>>>> 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 <mg...@apache.org>
> > > >> wrote:
> > > >>>>>> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <
> > > mgrigorov@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 <sv...@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 <
> > > >> andrew@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 <
> > > >>>>>>>> reiern70@gmail.com
> > > >>>>>>>>>>> :
> > > >>>>>>>>>>> Hi,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
> > > >>>>>>>> an.delbene@gmail.com>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> > > >>>>>>>>>>>> reiern70@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
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Maxim Solodovnik <so...@gmail.com>.
Let's try to remove this CSS and check :)
I'm currently using latest wicket SNAPSHOT at master so most probably
will provide some feedback :)
On Fri, 20 Mar 2020 at 19:51, Martin Grigorov <mg...@apache.org> wrote:
>
> In this case I am fine to go with 'hidden'.
> We can introduce wicket-core.css later if needed.
>
> On Fri, Mar 20, 2020 at 1:44 PM Sven Meier <sv...@meiers.net> wrote:
>
> > Hi Martin,
> >
> > these stylings?
> >
> > width: 0px;
> > height: 0px;
> > position: absolute;
> > left: -100px;
> > top: -100px;
> > overflow: hidden;
> >
> > They are a 10-year old workaround
> >
> >
> > https://github.com/apache/wicket/commit/b00f8ed1647f7a69a38aba562efa98bb8eb84d97
> >
> > ... for a problem that no longer exists:
> >
> >
> > https://stackoverflow.com/questions/8318428/submit-form-fields-inside-displaynone-element
> >
> > A simple "display:none"/"hidden" is sufficient.
> >
> > Sven
> >
> >
> > On 20.03.20 10:29, Martin Grigorov wrote:
> > > Hi Sven,
> > >
> > > What about wicket--hidden-fields ?
> > > We still need wicket-core.css for it.
> > >
> > > Martin
> > >
> > > On Wed, Mar 18, 2020 at 11:25 PM Sven Meier <sv...@meiers.net> wrote:
> > >
> > >> Hi all,
> > >>
> > >> I've built an example to better demonstrate my argument:
> > >>
> > >> a) "hidden" tags work fine out-of-the-box :)
> > >>
> > >> https://jsfiddle.net/p8s7Lrk2/1/
> > >>
> > >> b) changing display of tags changes "hidden" tags too :(
> > >>
> > >> https://jsfiddle.net/p8s7Lrk2/2/
> > >>
> > >> c) and a simple fix for "hidden" tags - no !important required ... 8)
> > >>
> > >> https://jsfiddle.net/p8s7Lrk2/3/
> > >>
> > >> In my opinion there's no need to invent "wicket--hidden" when "hidden"
> > >> works already as expected/needed (a).
> > >> And furthermore Wicket does not need to provide a fix (c) for something
> > >> the web designer screwed up (b) in the first place.
> > >>
> > >> Have fun
> > >> Sven
> > >>
> > >>
> > >> On 17.03.20 13:01, Maxim Solodovnik wrote:
> > >>> Hello Sven,
> > >>>
> > >>> I always thought:having override like this will require re-testing all
> > >>> 3rd-party components manually
> > >>> (I don't have that much time)
> > >>> So I'm using library as-is and override as minimum as possible :)
> > >>>
> > >>> On Tue, 17 Mar 2020 at 18:56, Sven Meier <sv...@meiers.net> wrote:
> > >>>> Hi Maxim,
> > >>>>
> > >>>> what is difficult about that?
> > >>>>
> > >>>> Actually it is recommended to have it in your normalize.css (formerly
> > >>>> reset.css).
> > >>>>
> > >>>> Here one without !important:
> > >>>>
> > >>>> https://github.com/necolas/normalize.css/blob/master/normalize.css
> > >>>>
> > >>>> Sven
> > >>>>
> > >>>>
> > >>>> On 13.03.20 15:21, Maxim Solodovnik wrote:
> > >>>>> 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 <mg...@apache.org>
> > >> wrote:
> > >>>>>> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <
> > mgrigorov@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 <sv...@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 <
> > >> andrew@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 <
> > >>>>>>>> reiern70@gmail.com
> > >>>>>>>>>>> :
> > >>>>>>>>>>> Hi,
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
> > >>>>>>>> an.delbene@gmail.com>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> > >>>>>>>>>>>> reiern70@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
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Martin Grigorov <mg...@apache.org>.
In this case I am fine to go with 'hidden'.
We can introduce wicket-core.css later if needed.
On Fri, Mar 20, 2020 at 1:44 PM Sven Meier <sv...@meiers.net> wrote:
> Hi Martin,
>
> these stylings?
>
> width: 0px;
> height: 0px;
> position: absolute;
> left: -100px;
> top: -100px;
> overflow: hidden;
>
> They are a 10-year old workaround
>
>
> https://github.com/apache/wicket/commit/b00f8ed1647f7a69a38aba562efa98bb8eb84d97
>
> ... for a problem that no longer exists:
>
>
> https://stackoverflow.com/questions/8318428/submit-form-fields-inside-displaynone-element
>
> A simple "display:none"/"hidden" is sufficient.
>
> Sven
>
>
> On 20.03.20 10:29, Martin Grigorov wrote:
> > Hi Sven,
> >
> > What about wicket--hidden-fields ?
> > We still need wicket-core.css for it.
> >
> > Martin
> >
> > On Wed, Mar 18, 2020 at 11:25 PM Sven Meier <sv...@meiers.net> wrote:
> >
> >> Hi all,
> >>
> >> I've built an example to better demonstrate my argument:
> >>
> >> a) "hidden" tags work fine out-of-the-box :)
> >>
> >> https://jsfiddle.net/p8s7Lrk2/1/
> >>
> >> b) changing display of tags changes "hidden" tags too :(
> >>
> >> https://jsfiddle.net/p8s7Lrk2/2/
> >>
> >> c) and a simple fix for "hidden" tags - no !important required ... 8)
> >>
> >> https://jsfiddle.net/p8s7Lrk2/3/
> >>
> >> In my opinion there's no need to invent "wicket--hidden" when "hidden"
> >> works already as expected/needed (a).
> >> And furthermore Wicket does not need to provide a fix (c) for something
> >> the web designer screwed up (b) in the first place.
> >>
> >> Have fun
> >> Sven
> >>
> >>
> >> On 17.03.20 13:01, Maxim Solodovnik wrote:
> >>> Hello Sven,
> >>>
> >>> I always thought:having override like this will require re-testing all
> >>> 3rd-party components manually
> >>> (I don't have that much time)
> >>> So I'm using library as-is and override as minimum as possible :)
> >>>
> >>> On Tue, 17 Mar 2020 at 18:56, Sven Meier <sv...@meiers.net> wrote:
> >>>> Hi Maxim,
> >>>>
> >>>> what is difficult about that?
> >>>>
> >>>> Actually it is recommended to have it in your normalize.css (formerly
> >>>> reset.css).
> >>>>
> >>>> Here one without !important:
> >>>>
> >>>> https://github.com/necolas/normalize.css/blob/master/normalize.css
> >>>>
> >>>> Sven
> >>>>
> >>>>
> >>>> On 13.03.20 15:21, Maxim Solodovnik wrote:
> >>>>> 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 <mg...@apache.org>
> >> wrote:
> >>>>>> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <
> mgrigorov@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 <sv...@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 <
> >> andrew@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 <
> >>>>>>>> reiern70@gmail.com
> >>>>>>>>>>> :
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
> >>>>>>>> an.delbene@gmail.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> >>>>>>>>>>>> reiern70@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
> >>>>>>>>>>>
> >>>
>
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Sven Meier <sv...@meiers.net>.
Hi Martin,
these stylings?
width: 0px;
height: 0px;
position: absolute;
left: -100px;
top: -100px;
overflow: hidden;
They are a 10-year old workaround
https://github.com/apache/wicket/commit/b00f8ed1647f7a69a38aba562efa98bb8eb84d97
... for a problem that no longer exists:
https://stackoverflow.com/questions/8318428/submit-form-fields-inside-displaynone-element
A simple "display:none"/"hidden" is sufficient.
Sven
On 20.03.20 10:29, Martin Grigorov wrote:
> Hi Sven,
>
> What about wicket--hidden-fields ?
> We still need wicket-core.css for it.
>
> Martin
>
> On Wed, Mar 18, 2020 at 11:25 PM Sven Meier <sv...@meiers.net> wrote:
>
>> Hi all,
>>
>> I've built an example to better demonstrate my argument:
>>
>> a) "hidden" tags work fine out-of-the-box :)
>>
>> https://jsfiddle.net/p8s7Lrk2/1/
>>
>> b) changing display of tags changes "hidden" tags too :(
>>
>> https://jsfiddle.net/p8s7Lrk2/2/
>>
>> c) and a simple fix for "hidden" tags - no !important required ... 8)
>>
>> https://jsfiddle.net/p8s7Lrk2/3/
>>
>> In my opinion there's no need to invent "wicket--hidden" when "hidden"
>> works already as expected/needed (a).
>> And furthermore Wicket does not need to provide a fix (c) for something
>> the web designer screwed up (b) in the first place.
>>
>> Have fun
>> Sven
>>
>>
>> On 17.03.20 13:01, Maxim Solodovnik wrote:
>>> Hello Sven,
>>>
>>> I always thought:having override like this will require re-testing all
>>> 3rd-party components manually
>>> (I don't have that much time)
>>> So I'm using library as-is and override as minimum as possible :)
>>>
>>> On Tue, 17 Mar 2020 at 18:56, Sven Meier <sv...@meiers.net> wrote:
>>>> Hi Maxim,
>>>>
>>>> what is difficult about that?
>>>>
>>>> Actually it is recommended to have it in your normalize.css (formerly
>>>> reset.css).
>>>>
>>>> Here one without !important:
>>>>
>>>> https://github.com/necolas/normalize.css/blob/master/normalize.css
>>>>
>>>> Sven
>>>>
>>>>
>>>> On 13.03.20 15:21, Maxim Solodovnik wrote:
>>>>> 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 <mg...@apache.org>
>> wrote:
>>>>>> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <mgrigorov@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 <sv...@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 <
>> andrew@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 <
>>>>>>>> reiern70@gmail.com
>>>>>>>>>>> :
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
>>>>>>>> an.delbene@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
>>>>>>>>>>>> reiern70@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
>>>>>>>>>>>
>>>
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Martin Grigorov <mg...@apache.org>.
Hi Sven,
What about wicket--hidden-fields ?
We still need wicket-core.css for it.
Martin
On Wed, Mar 18, 2020 at 11:25 PM Sven Meier <sv...@meiers.net> wrote:
> Hi all,
>
> I've built an example to better demonstrate my argument:
>
> a) "hidden" tags work fine out-of-the-box :)
>
> https://jsfiddle.net/p8s7Lrk2/1/
>
> b) changing display of tags changes "hidden" tags too :(
>
> https://jsfiddle.net/p8s7Lrk2/2/
>
> c) and a simple fix for "hidden" tags - no !important required ... 8)
>
> https://jsfiddle.net/p8s7Lrk2/3/
>
> In my opinion there's no need to invent "wicket--hidden" when "hidden"
> works already as expected/needed (a).
> And furthermore Wicket does not need to provide a fix (c) for something
> the web designer screwed up (b) in the first place.
>
> Have fun
> Sven
>
>
> On 17.03.20 13:01, Maxim Solodovnik wrote:
> > Hello Sven,
> >
> > I always thought:having override like this will require re-testing all
> > 3rd-party components manually
> > (I don't have that much time)
> > So I'm using library as-is and override as minimum as possible :)
> >
> > On Tue, 17 Mar 2020 at 18:56, Sven Meier <sv...@meiers.net> wrote:
> >> Hi Maxim,
> >>
> >> what is difficult about that?
> >>
> >> Actually it is recommended to have it in your normalize.css (formerly
> >> reset.css).
> >>
> >> Here one without !important:
> >>
> >> https://github.com/necolas/normalize.css/blob/master/normalize.css
> >>
> >> Sven
> >>
> >>
> >> On 13.03.20 15:21, Maxim Solodovnik wrote:
> >>> 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 <mg...@apache.org>
> wrote:
> >>>> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <mgrigorov@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 <sv...@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 <
> andrew@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 <
> >>>>>> reiern70@gmail.com
> >>>>>>>>> :
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
> >>>>>> an.delbene@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> >>>>>>>>>> reiern70@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
> >>>>>>>>>
> >>>
> >
> >
>
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Sven Meier <sv...@meiers.net>.
Hi all,
I've built an example to better demonstrate my argument:
a) "hidden" tags work fine out-of-the-box :)
https://jsfiddle.net/p8s7Lrk2/1/
b) changing display of tags changes "hidden" tags too :(
https://jsfiddle.net/p8s7Lrk2/2/
c) and a simple fix for "hidden" tags - no !important required ... 8)
https://jsfiddle.net/p8s7Lrk2/3/
In my opinion there's no need to invent "wicket--hidden" when "hidden"
works already as expected/needed (a).
And furthermore Wicket does not need to provide a fix (c) for something
the web designer screwed up (b) in the first place.
Have fun
Sven
On 17.03.20 13:01, Maxim Solodovnik wrote:
> Hello Sven,
>
> I always thought:having override like this will require re-testing all
> 3rd-party components manually
> (I don't have that much time)
> So I'm using library as-is and override as minimum as possible :)
>
> On Tue, 17 Mar 2020 at 18:56, Sven Meier <sv...@meiers.net> wrote:
>> Hi Maxim,
>>
>> what is difficult about that?
>>
>> Actually it is recommended to have it in your normalize.css (formerly
>> reset.css).
>>
>> Here one without !important:
>>
>> https://github.com/necolas/normalize.css/blob/master/normalize.css
>>
>> Sven
>>
>>
>> On 13.03.20 15:21, Maxim Solodovnik wrote:
>>> 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 <mg...@apache.org> wrote:
>>>> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <mg...@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 <sv...@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 <an...@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 <
>>>>>> reiern70@gmail.com
>>>>>>>>> :
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
>>>>>> an.delbene@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
>>>>>>>>>> reiern70@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
>>>>>>>>>
>>>
>
>
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Maxim Solodovnik <so...@gmail.com>.
Hello Sven,
I always thought:having override like this will require re-testing all
3rd-party components manually
(I don't have that much time)
So I'm using library as-is and override as minimum as possible :)
On Tue, 17 Mar 2020 at 18:56, Sven Meier <sv...@meiers.net> wrote:
>
> Hi Maxim,
>
> what is difficult about that?
>
> Actually it is recommended to have it in your normalize.css (formerly
> reset.css).
>
> Here one without !important:
>
> https://github.com/necolas/normalize.css/blob/master/normalize.css
>
> Sven
>
>
> On 13.03.20 15:21, Maxim Solodovnik wrote:
> > 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 <mg...@apache.org> wrote:
> >> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <mg...@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 <sv...@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 <an...@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 <
> >>>> reiern70@gmail.com
> >>>>>>> :
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
> >>>> an.delbene@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> >>>>>>>> reiern70@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
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Sven Meier <sv...@meiers.net>.
Hi Maxim,
what is difficult about that?
Actually it is recommended to have it in your normalize.css (formerly
reset.css).
Here one without !important:
https://github.com/necolas/normalize.css/blob/master/normalize.css
Sven
On 13.03.20 15:21, Maxim Solodovnik wrote:
> 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 <mg...@apache.org> wrote:
>> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <mg...@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 <sv...@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 <an...@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 <
>>>> reiern70@gmail.com
>>>>>>> :
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
>>>> an.delbene@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
>>>>>>>> reiern70@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
>>>>>>>
>
>
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Maxim Solodovnik <so...@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 <mg...@apache.org> wrote:
>
> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <mg...@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 <sv...@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 <an...@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 <
> >> reiern70@gmail.com
> >> >>> :
> >> >>> Hi,
> >> >>>
> >> >>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
> >> an.delbene@gmail.com>
> >> >>> wrote:
> >> >>>
> >> >>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> >> >>>> reiern70@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
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov <mg...@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 <sv...@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 <an...@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 <
>> reiern70@gmail.com
>> >>> :
>> >>> Hi,
>> >>>
>> >>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <
>> an.delbene@gmail.com>
>> >>> wrote:
>> >>>
>> >>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
>> >>>> reiern70@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
>> >>>
>>
>
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Martin Grigorov <mg...@apache.org>.
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'
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 <sv...@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 <an...@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 <
> reiern70@gmail.com
> >>> :
> >>> Hi,
> >>>
> >>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <an.delbene@gmail.com
> >
> >>> wrote:
> >>>
> >>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> >>>> reiern70@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
> >>>
>
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Sven Meier <sv...@meiers.net>.
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.
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!
>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.
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 <an...@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 <reiern70@gmail.com
>>> :
>>> Hi,
>>>
>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <an...@gmail.com>
>>> wrote:
>>>
>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
>>>> reiern70@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
>>>
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Emond Papegaaij <em...@gmail.com>.
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 <an...@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 <reiern70@gmail.com
> >:
>
> > Hi,
> >
> > On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <an...@gmail.com>
> > wrote:
> >
> > > On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> > > reiern70@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
> >
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Andrew Kondratev <an...@kondratev.pro>.
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 <reiern70@gmail.com
>:
> Hi,
>
> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <an...@gmail.com>
> wrote:
>
> > On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> > reiern70@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
>
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Emond Papegaaij <em...@gmail.com>.
On Thu, Feb 27, 2020 at 11:56 AM Ernesto Reinaldo Barreiro
<re...@gmail.com> wrote:
> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <an...@gmail.com>
> > 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).
As I've explained in the other thread, it is very likely that not much
needs to be done in additional frameworks. Also, when a framework is
not yet compliant with CSP, the user can temporarily disable CSP or
switch to a less strict version. As explained in the user guide, this
is just one line of code.
The changes made to the core of Wicket (removing inline styling and
js) were absolutely necessary to be able to support a strict CSP via
Wicket or any other way. This clearly is a wish of our users (and a
personal wish as well, because our application also needs it). Also I
think this is truly is a very unique feature. I don't think any
framework offers such a strict CSP out of the box with so less effort
from the user.
Best regards,
Emond
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Hi,
On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene <an...@gmail.com>
wrote:
> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
> reiern70@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
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Andrea Del Bene <an...@gmail.com>.
On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo Barreiro <
reiern70@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.
> Thus in practice the release of 9.x. by itself, with new CSS feature, will
> not
> bring any immediate value to many users as this will break most existing
> applications.
>
> On Wed, Feb 26, 2020 at 10:34 AM Maxim Solodovnik <so...@gmail.com>
> wrote:
>
> > [+] leave as is with .wicket--hidden & wicket-core.css
> >
> > IMO we should sheep the version which will work as expected
> out-of-the-box
> > According to my tests `hidden` attribute doesn't work (even `display:
> > flex` breaks it)
> >
> > On Wed, 26 Feb 2020 at 15:22, Andrea Del Bene <an...@gmail.com>
> > wrote:
> > >
> > > +1 to vote. I find your concerns legitimate
> > >
> > > On Tue, Feb 25, 2020 at 9:54 PM Sven Meier <sv...@meiers.net> wrote:
> > >
> > > > Hi all,
> > > >
> > > > we have a disagreement on how to style hidden elements in Wicket 9.x.
> > > >
> > > > Due to the new CSP support we can no longer use inline styling to
> hide
> > > > elements.
> > > > WICKET-6725 introduces new CSS classes and a file wicket-core.css.
> > > >
> > > > I don't think this is a good approach:
> > > >
> > > > - it adds a CSS file that is referenced by each page (after Wicket
> > doing
> > > > fine without it for 15 years)
> > > > - the CSS is a mingle-mangle of out-of-date stylings (see
> > > > .wicket--hidden-fields)
> > > > - it's a kitchen-sink for left-over styles (see .wicket--color-red)
> > > > - it introduces a new class naming scheme not used anywhere else
> > (wicket--)
> > > >
> > > > IMHO we should remove that file again (and the required
> infrastructure
> > > > in ResourceSettings/WebApplication) and just
> > > > use the HTML5 "hidden" attribute instead, whenever we want to hide
> > > > something (Component, Form, ...).
> > > > This "just works" in all browsers and is semantically correct. It has
> > > > one caveat when an application's CSS changes the default styling of
> > > > hidden elements (see
> > > > https://css-tricks.com/the-hidden-attribute-is-visibly-weak), but
> > that's
> > > > in the responsibility of the application developer.
> > > > AjaxIndicatorAppender can just render a CSS class and leave the
> styling
> > > > to the application developer, nobody will be happy with the default
> > > > "red" anyway.
> > > >
> > > > Thus I'll be starting a vote in the next days with the following two
> > > > options:
> > > >
> > > > [] leave as is with .wicket--hidden & wicket-core.css
> > > >
> > > > [] use HTML5 "hidden" attribute instead
> > > >
> > > > This isn't the vote yet, it's just the announcement.
> > > > Maybe others see a third (forth?) option or want to raise their
> > concerns
> > > > first.
> > > >
> > > > Sven
> > > >
> > > >
> > > >
> > >
> > > --
> > > Andrea Del Bene.
> > > Apache Wicket committer.
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>
--
Andrea Del Bene.
Apache Wicket committer.
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
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. Thus in
practice the release of 9.x. by itself, with new CSS feature, will not
bring any immediate value to many users as this will break most existing
applications.
On Wed, Feb 26, 2020 at 10:34 AM Maxim Solodovnik <so...@gmail.com>
wrote:
> [+] leave as is with .wicket--hidden & wicket-core.css
>
> IMO we should sheep the version which will work as expected out-of-the-box
> According to my tests `hidden` attribute doesn't work (even `display:
> flex` breaks it)
>
> On Wed, 26 Feb 2020 at 15:22, Andrea Del Bene <an...@gmail.com>
> wrote:
> >
> > +1 to vote. I find your concerns legitimate
> >
> > On Tue, Feb 25, 2020 at 9:54 PM Sven Meier <sv...@meiers.net> wrote:
> >
> > > Hi all,
> > >
> > > we have a disagreement on how to style hidden elements in Wicket 9.x.
> > >
> > > Due to the new CSP support we can no longer use inline styling to hide
> > > elements.
> > > WICKET-6725 introduces new CSS classes and a file wicket-core.css.
> > >
> > > I don't think this is a good approach:
> > >
> > > - it adds a CSS file that is referenced by each page (after Wicket
> doing
> > > fine without it for 15 years)
> > > - the CSS is a mingle-mangle of out-of-date stylings (see
> > > .wicket--hidden-fields)
> > > - it's a kitchen-sink for left-over styles (see .wicket--color-red)
> > > - it introduces a new class naming scheme not used anywhere else
> (wicket--)
> > >
> > > IMHO we should remove that file again (and the required infrastructure
> > > in ResourceSettings/WebApplication) and just
> > > use the HTML5 "hidden" attribute instead, whenever we want to hide
> > > something (Component, Form, ...).
> > > This "just works" in all browsers and is semantically correct. It has
> > > one caveat when an application's CSS changes the default styling of
> > > hidden elements (see
> > > https://css-tricks.com/the-hidden-attribute-is-visibly-weak), but
> that's
> > > in the responsibility of the application developer.
> > > AjaxIndicatorAppender can just render a CSS class and leave the styling
> > > to the application developer, nobody will be happy with the default
> > > "red" anyway.
> > >
> > > Thus I'll be starting a vote in the next days with the following two
> > > options:
> > >
> > > [] leave as is with .wicket--hidden & wicket-core.css
> > >
> > > [] use HTML5 "hidden" attribute instead
> > >
> > > This isn't the vote yet, it's just the announcement.
> > > Maybe others see a third (forth?) option or want to raise their
> concerns
> > > first.
> > >
> > > Sven
> > >
> > >
> > >
> >
> > --
> > Andrea Del Bene.
> > Apache Wicket committer.
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
Regards - Ernesto Reinaldo Barreiro
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Maxim Solodovnik <so...@gmail.com>.
[+] leave as is with .wicket--hidden & wicket-core.css
IMO we should sheep the version which will work as expected out-of-the-box
According to my tests `hidden` attribute doesn't work (even `display:
flex` breaks it)
On Wed, 26 Feb 2020 at 15:22, Andrea Del Bene <an...@gmail.com> wrote:
>
> +1 to vote. I find your concerns legitimate
>
> On Tue, Feb 25, 2020 at 9:54 PM Sven Meier <sv...@meiers.net> wrote:
>
> > Hi all,
> >
> > we have a disagreement on how to style hidden elements in Wicket 9.x.
> >
> > Due to the new CSP support we can no longer use inline styling to hide
> > elements.
> > WICKET-6725 introduces new CSS classes and a file wicket-core.css.
> >
> > I don't think this is a good approach:
> >
> > - it adds a CSS file that is referenced by each page (after Wicket doing
> > fine without it for 15 years)
> > - the CSS is a mingle-mangle of out-of-date stylings (see
> > .wicket--hidden-fields)
> > - it's a kitchen-sink for left-over styles (see .wicket--color-red)
> > - it introduces a new class naming scheme not used anywhere else (wicket--)
> >
> > IMHO we should remove that file again (and the required infrastructure
> > in ResourceSettings/WebApplication) and just
> > use the HTML5 "hidden" attribute instead, whenever we want to hide
> > something (Component, Form, ...).
> > This "just works" in all browsers and is semantically correct. It has
> > one caveat when an application's CSS changes the default styling of
> > hidden elements (see
> > https://css-tricks.com/the-hidden-attribute-is-visibly-weak), but that's
> > in the responsibility of the application developer.
> > AjaxIndicatorAppender can just render a CSS class and leave the styling
> > to the application developer, nobody will be happy with the default
> > "red" anyway.
> >
> > Thus I'll be starting a vote in the next days with the following two
> > options:
> >
> > [] leave as is with .wicket--hidden & wicket-core.css
> >
> > [] use HTML5 "hidden" attribute instead
> >
> > This isn't the vote yet, it's just the announcement.
> > Maybe others see a third (forth?) option or want to raise their concerns
> > first.
> >
> > Sven
> >
> >
> >
>
> --
> Andrea Del Bene.
> Apache Wicket committer.
--
WBR
Maxim aka solomax
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Andrea Del Bene <an...@gmail.com>.
+1 to vote. I find your concerns legitimate
On Tue, Feb 25, 2020 at 9:54 PM Sven Meier <sv...@meiers.net> wrote:
> Hi all,
>
> we have a disagreement on how to style hidden elements in Wicket 9.x.
>
> Due to the new CSP support we can no longer use inline styling to hide
> elements.
> WICKET-6725 introduces new CSS classes and a file wicket-core.css.
>
> I don't think this is a good approach:
>
> - it adds a CSS file that is referenced by each page (after Wicket doing
> fine without it for 15 years)
> - the CSS is a mingle-mangle of out-of-date stylings (see
> .wicket--hidden-fields)
> - it's a kitchen-sink for left-over styles (see .wicket--color-red)
> - it introduces a new class naming scheme not used anywhere else (wicket--)
>
> IMHO we should remove that file again (and the required infrastructure
> in ResourceSettings/WebApplication) and just
> use the HTML5 "hidden" attribute instead, whenever we want to hide
> something (Component, Form, ...).
> This "just works" in all browsers and is semantically correct. It has
> one caveat when an application's CSS changes the default styling of
> hidden elements (see
> https://css-tricks.com/the-hidden-attribute-is-visibly-weak), but that's
> in the responsibility of the application developer.
> AjaxIndicatorAppender can just render a CSS class and leave the styling
> to the application developer, nobody will be happy with the default
> "red" anyway.
>
> Thus I'll be starting a vote in the next days with the following two
> options:
>
> [] leave as is with .wicket--hidden & wicket-core.css
>
> [] use HTML5 "hidden" attribute instead
>
> This isn't the vote yet, it's just the announcement.
> Maybe others see a third (forth?) option or want to raise their concerns
> first.
>
> Sven
>
>
>
--
Andrea Del Bene.
Apache Wicket committer.
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Tobias Soloschenko <to...@googlemail.com.INVALID>.
Hi,
as you know I am a big fan of HTML5 and was experimenting a lot with it, I would also vote to stay with a core css and clean it up, because of a better backward compatibility. flex is used a LOT in modern layouts and would break the other option.
kind regards
Tobias
> Am 26.02.2020 um 11:31 schrieb Martijn Dashorst <ma...@gmail.com>:
>
> On Wed, Feb 26, 2020 at 11:15 AM Emond Papegaaij <em...@gmail.com>
> wrote:
>
>>>> On Tue, Feb 25, 2020 at 10:54 PM Sven Meier <sv...@meiers.net> wrote:
>>>>> - it's a kitchen-sink for left-over styles (see .wicket--color-red)
>>>
>>> I agree that for this one Wicket can just add the CSS class (e.g.
>>> wicket-feedback-indicator) on the HTML element and let the application
>>> provide the CSS rules for it
>>
>> I'm ok with that. I only added that styling to be compatible with the
>> old behavior, which was broken in my opinion anyway.
>>
>
> As long as the default behavior is specified in the Wicket core css file,
> I'm for it. .wicket--color-red is godawful so +1 for making it meaningful.
>
> IMO this means that we should move the styling of e.g. the feedback panel
> [1] into the wicket-- fold. However, that is not something that is related
> to CSP, so CSP should not be the driver (nor wait) for that.
>
>
>>> An idea:
>>> if CSP is disabled then Wicket can deliver the content of wicket-core.css
>>> as inline CSS, i.e. <style>....</style>.
>>> This will keep the number of http requests the same as before.
>>
>> This already is an option now and doesn't depend on CSP being enabled
>> or not. As long as the style element is rendered with a nonce, it will
>> work. We can make the header contribution a bit more flexible with the
>> following options:
>> * inline wicket-core.css (or another stylesheet)
>> * resource reference to wicket-core.css (or another stylesheet)
>> * no core stylesheet at all
>>
>
> AFAIR the extra request is normally not a problem as browsers multiplex
> that on the HTTP/2 connection to the server, and the CSS is easily cached.
> It might actually be a worse experience to inline the style than having it
> as a separate resource.
>
> Martijn
>
> [1]
> https://github.com/apache/wicket/blob/master/wicket-core/src/test/java/org/apache/wicket/markup/html/panel/FeedbackPanelTest_cssClasses_expected.html
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Martijn Dashorst <ma...@gmail.com>.
On Wed, Feb 26, 2020 at 11:15 AM Emond Papegaaij <em...@gmail.com>
wrote:
> > On Tue, Feb 25, 2020 at 10:54 PM Sven Meier <sv...@meiers.net> wrote:
> > > - it's a kitchen-sink for left-over styles (see .wicket--color-red)
> >
> > I agree that for this one Wicket can just add the CSS class (e.g.
> > wicket-feedback-indicator) on the HTML element and let the application
> > provide the CSS rules for it
>
> I'm ok with that. I only added that styling to be compatible with the
> old behavior, which was broken in my opinion anyway.
>
As long as the default behavior is specified in the Wicket core css file,
I'm for it. .wicket--color-red is godawful so +1 for making it meaningful.
IMO this means that we should move the styling of e.g. the feedback panel
[1] into the wicket-- fold. However, that is not something that is related
to CSP, so CSP should not be the driver (nor wait) for that.
> > An idea:
> > if CSP is disabled then Wicket can deliver the content of wicket-core.css
> > as inline CSS, i.e. <style>....</style>.
> > This will keep the number of http requests the same as before.
>
> This already is an option now and doesn't depend on CSP being enabled
> or not. As long as the style element is rendered with a nonce, it will
> work. We can make the header contribution a bit more flexible with the
> following options:
> * inline wicket-core.css (or another stylesheet)
> * resource reference to wicket-core.css (or another stylesheet)
> * no core stylesheet at all
>
AFAIR the extra request is normally not a problem as browsers multiplex
that on the HTTP/2 connection to the server, and the CSS is easily cached.
It might actually be a worse experience to inline the style than having it
as a separate resource.
Martijn
[1]
https://github.com/apache/wicket/blob/master/wicket-core/src/test/java/org/apache/wicket/markup/html/panel/FeedbackPanelTest_cssClasses_expected.html
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Emond Papegaaij <em...@gmail.com>.
On Wed, Feb 26, 2020 at 10:53 AM Martin Grigorov <mg...@apache.org> wrote:
> I am also not big fan of CSP but users ask for it and I see no other way
> but to move all inline styles in such .css resource
IMHO CSP is one of the changes to the web application ecosystem that
Wicket will need an answer on to stay relevant in the upcoming years.
Web application development is changing at a very rapid pace and
Wicket will need to incorporate those changes or face becoming
obsolete.
> On Tue, Feb 25, 2020 at 10:54 PM Sven Meier <sv...@meiers.net> wrote:
> > - it's a kitchen-sink for left-over styles (see .wicket--color-red)
>
> I agree that for this one Wicket can just add the CSS class (e.g.
> wicket-feedback-indicator) on the HTML element and let the application
> provide the CSS rules for it
I'm ok with that. I only added that styling to be compatible with the
old behavior, which was broken in my opinion anyway.
> >
< cut use hidden attribute >
> >
> I don't agree here.
> If each and every developer should make sure that Wicket's placeholder tags
> should stay invisible then the framework does not do its job.
> Often when we see that something is too common we actually add it to the
> framework. Here you ask to do the reverse - remove the support and ask the
> developers to deal with it.
> The article you linked to explains it well that "hidden" attribute does not
> really work. CSS libraries which provide reset rules like div { display:
> block; } will make the life of the developer miserable.
I totally agree with Martin. Using the hidden attribute puts the
responsibility with the developer where this should be on the
framework. The hidden attribute just doesn't work.
> An idea:
> if CSP is disabled then Wicket can deliver the content of wicket-core.css
> as inline CSS, i.e. <style>....</style>.
> This will keep the number of http requests the same as before.
This already is an option now and doesn't depend on CSP being enabled
or not. As long as the style element is rendered with a nonce, it will
work. We can make the header contribution a bit more flexible with the
following options:
* inline wicket-core.css (or another stylesheet)
* resource reference to wicket-core.css (or another stylesheet)
* no core stylesheet at all
Best regards,
Emond
Re: WICKET-6725 styling of hidden elements: no vote yet
Posted by Martin Grigorov <mg...@apache.org>.
Hi Sven,
On Tue, Feb 25, 2020 at 10:54 PM Sven Meier <sv...@meiers.net> wrote:
> Hi all,
>
> we have a disagreement on how to style hidden elements in Wicket 9.x.
>
> Due to the new CSP support we can no longer use inline styling to hide
> elements.
> WICKET-6725 introduces new CSS classes and a file wicket-core.css.
>
> I don't think this is a good approach:
>
> - it adds a CSS file that is referenced by each page (after Wicket doing
> fine without it for 15 years)
>
I am also not big fan of CSP but users ask for it and I see no other way
but to move all inline styles in such .css resource
> - the CSS is a mingle-mangle of out-of-date stylings (see
> .wicket--hidden-fields)
>
What do you suggest to use instead ?
> - it's a kitchen-sink for left-over styles (see .wicket--color-red)
>
I agree that for this one Wicket can just add the CSS class (e.g.
wicket-feedback-indicator) on the HTML element and let the application
provide the CSS rules for it
> - it introduces a new class naming scheme not used anywhere else (wicket--)
>
We need this "namespace" to avoid clashes with the applications' styles. I
see nothing bad in this one.
>
> IMHO we should remove that file again (and the required infrastructure
> in ResourceSettings/WebApplication) and just
> use the HTML5 "hidden" attribute instead, whenever we want to hide
> something (Component, Form, ...).
This "just works" in all browsers and is semantically correct. It has
> one caveat when an application's CSS changes the default styling of
> hidden elements (see
> https://css-tricks.com/the-hidden-attribute-is-visibly-weak), but that's
> in the responsibility of the application developer.
>
I don't agree here.
If each and every developer should make sure that Wicket's placeholder tags
should stay invisible then the framework does not do its job.
Often when we see that something is too common we actually add it to the
framework. Here you ask to do the reverse - remove the support and ask the
developers to deal with it.
The article you linked to explains it well that "hidden" attribute does not
really work. CSS libraries which provide reset rules like div { display:
block; } will make the life of the developer miserable.
> AjaxIndicatorAppender can just render a CSS class and leave the styling
> to the application developer, nobody will be happy with the default
> "red" anyway.
>
+1 on this ^^
>
> Thus I'll be starting a vote in the next days with the following two
> options:
>
> [] leave as is with .wicket--hidden & wicket-core.css
>
> [] use HTML5 "hidden" attribute instead
>
> This isn't the vote yet, it's just the announcement.
> Maybe others see a third (forth?) option or want to raise their concerns
> first.
>
An idea:
if CSP is disabled then Wicket can deliver the content of wicket-core.css
as inline CSS, i.e. <style>....</style>.
This will keep the number of http requests the same as before.
Martin
>
> Sven
>
>
>