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