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