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 <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
> >>>
>
