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