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
