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 <solomax...@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 <mgrigo...@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 <s...@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 <s...@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 <s...@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 <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
