Re: WICKET-6725 styling of hidden elements: no vote yet
Hi Maxim,
thanks for your feedback.
Sven
On 27.03.20 05:06, Maxim Solodovnik wrote:
Still no issues reported after 2 days of work at our demo server
Seems this solution can be released :)
On Wed, 25 Mar 2020 at 18:24, Maxim Solodovnik wrote:
first results: everything seems to work as expected
will continue testing
On Wed, 25 Mar 2020 at 01:12, Sven Meier wrote:
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
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
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 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
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 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,
/* rule from the application that should be
used
whentheelement is visible */ div { display: flex; margin-bottom: 200px; } /* Rule coming from wicket-core.css */
Re: WICKET-6725 styling of hidden elements: no vote yet
Still no issues reported after 2 days of work at our demo server Seems this solution can be released :) On Wed, 25 Mar 2020 at 18:24, Maxim Solodovnik wrote: > first results: everything seems to work as expected > will continue testing > > On Wed, 25 Mar 2020 at 01:12, Sven Meier wrote: > >> 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 >> 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 >> 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 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 >> 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 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, >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> /* rule from the application that should be >> used >> when >> >> the >> >>> element is visible */ >> >>> div { >> >>> display: flex; >> >>> margin-bottom: 200px; >> >>> } >> >>> >> >>> /* Rule coming
Re: WICKET-6725 styling of hidden elements: no vote yet
first results: everything seems to work as expected will continue testing On Wed, 25 Mar 2020 at 01:12, Sven Meier wrote: > 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 > 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 > 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 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 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 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, > >>> > >>> > >>> > >>> > >>> > >>> /* 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; > >>> } > >>> > >>> > >>> > >>> > >>> > >>> > >>> Element when visible: >
Re: WICKET-6725 styling of hidden elements: no vote yet
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 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 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 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 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 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 wrote: On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov < mgrigo...@apache.org wrote: Hi Sven, /* rule from the application that should be usedwhentheelement is visible */ div { display: flex; margin-bottom: 200px; } /* Rule coming from wicket-core.css */ .wicket--hidden { display: none; } Element when visible: A1 B1 C1 D1 Element when hidden (there is no B1 because Wicket renders just the tag, without any children): A2 C2 D2 C2 D2 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. Element with wicket--hidden class A3 B3 C3 D3 C3 D3 are not 200px down because of 'display: none'! The application developer has nothing to do!
Re: WICKET-6725 styling of hidden elements: no vote yet
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 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 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 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 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 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 > > > >> wrote: > > > >> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov < > > > mgrigo...@apache.org > > > >> wrote: > > > >> > > > >>> Hi Sven, > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>/* 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; > > > >>>} > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>Element when visible: > > > >>>A1 B1 C1 D1 > > > >>> > > > >>> > > > >>> > > > >>>Element when hidden (there is no B1 because Wicket > > > >> renders > > > >>> just the tag, without any children): > > > >>>A2 C2 > > > D2 > > > >>> > > > >>>C2 D2 are still 200px > > > >> down > > > >>> because 'hidden' is not like 'display: none'! > > > >>>
Re: WICKET-6725 styling of hidden elements: no vote yet
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 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 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 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 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 > > >> wrote: > > >> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov < > > mgrigo...@apache.org > > >> wrote: > > >> > > >>> Hi Sven, > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>/* 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; > > >>>} > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>Element when visible: > > >>>A1 B1 C1 D1 > > >>> > > >>> > > >>> > > >>>Element when hidden (there is no B1 because Wicket > > >> renders > > >>> just the tag, without any children): > > >>>A2 C2 > > D2 > > >>> > > >>>C2 D2 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. > > >>> > > >>> > > >>> > > >>>Element with wicket--hidden class > > >>>A3 B3 > > C3 > > >>> D3 > > >>> > > >>>C3 D3 are not 200px > > down > > >> because > > >>> of 'display: none'! > > >>>The application developer has nothing to do! > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> It shows two things: > > >>> > > >>> 1) since Wicket placeholder
Re: WICKET-6725 styling of hidden elements: no vote yet
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 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 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 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 > >> wrote: > >> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov < > mgrigo...@apache.org > >> wrote: > >> > >>> Hi Sven, > >>> > >>> > >>> > >>> > >>> > >>>/* 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; > >>>} > >>> > >>> > >>> > >>> > >>> > >>> > >>>Element when visible: > >>>A1 B1 C1 D1 > >>> > >>> > >>> > >>>Element when hidden (there is no B1 because Wicket > >> renders > >>> just the tag, without any children): > >>>A2 C2 > D2 > >>> > >>>C2 D2 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. > >>> > >>> > >>> > >>>Element with wicket--hidden class > >>>A3 B3 > C3 > >>> D3 > >>> > >>>C3 D3 are not 200px > down > >> because > >>> of 'display: none'! > >>>The application developer has nothing to do! > >>> > >>> > >>> > >>> > >>> > >>> 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. > >>> > >> >
Re: WICKET-6725 styling of hidden elements: no vote yet
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 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 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 > wrote: > On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov > > wrote: > > > Hi Sven, > > > > > > > > > > > > /* 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; > > } > > > > > > > > > > > > > > Element when visible: > > A1 B1 C1 D1 > > > > > > > > Element when hidden (there is no B1 because Wicket > renders > > just the tag, without any children): > > A2 C2 D2 > > > > C2 D2 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. > > > > > > > > Element with wicket--hidden class > > A3 B3 C3 > > D3 > > > > C3 D3 are not 200px down > because > > of 'display: none'! > > The application developer has nothing to do! > > > > > > > > > > > > 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 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. > >> > >
Re: WICKET-6725 styling of hidden elements: no vote yet
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 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 wrote: On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov wrote: Hi Sven, /* 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; } Element when visible: A1 B1 C1 D1 Element when hidden (there is no B1 because Wicket renders just the tag, without any children): A2 C2 D2 C2 D2 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. Element with wicket--hidden class A3 B3 C3 D3 C3 D3 are not 200px down because of 'display: none'! The application developer has nothing to do! 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 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
Re: WICKET-6725 styling of hidden elements: no vote yet
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 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 wrote: > >> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov > >> wrote: > >> > >>> Hi Sven, > >>> > >>> > >>> > >>> > >>> > >>> /* 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; > >>> } > >>> > >>> > >>> > >>> > >>> > >>> > >>> Element when visible: > >>> A1 B1 C1 D1 > >>> > >>> > >>> > >>> Element when hidden (there is no B1 because Wicket renders > >>> just the tag, without any children): > >>> A2 C2 D2 > >>> > >>> C2 D2 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. > >>> > >>> > >>> > >>> Element with wicket--hidden class > >>> A3 B3 C3 > >>> D3 > >>> > >>> C3 D3 are not 200px down > >>> because > >>> of 'display: none'! > >>> The application developer has nothing to do! > >>> > >>> > >>> > >>> > >>> > >>> 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 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
Re: WICKET-6725 styling of hidden elements: no vote yet
Hi Martin, sorry, I don't get it. You can equally well just style it via "hidden" attribute: *[hidden] { display: none; } And no, this does *not* need to be provided by Wicket: Whoever decides to flex *all* divs (you or your web designer), he will be able to take care of those divs that should not be flexed. I'm certain there will be many more exceptions, based on CSS class or attribute. "hidden" is no exception to that. Thanks Sven On 13.03.20 15:16, Martin Grigorov wrote: On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov wrote: Hi Sven, /* 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; } Element when visible: A1 B1 C1 D1 Element when hidden (there is no B1 because Wicket renders just the tag, without any children): A2 C2 D2 C2 D2 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. Element with wicket--hidden class A3 B3 C3 D3 C3 D3 are not 200px down because of 'display: none'! The application developer has nothing to do! 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 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
Re: WICKET-6725 styling of hidden elements: no vote yet
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 wrote: On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov wrote: Hi Sven, /* 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; } Element when visible: A1 B1 C1 D1 Element when hidden (there is no B1 because Wicket renders just the tag, without any children): A2 C2 D2 C2 D2 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. Element with wicket--hidden class A3 B3 C3 D3 C3 D3 are not 200px down because of 'display: none'! The application developer has nothing to do! 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 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
Re: WICKET-6725 styling of hidden elements: no vote yet
Oh dear - why devs don’t stop using !important - it is so hard to customize it by use more specific selectors... anyway - as long as the css are clear and simple to support functions of the backend they are ok. Users can even customize them. display: none to hide something is simple and clear and bug-free. kind regards Tobias > Am 13.03.2020 um 15:21 schrieb Maxim Solodovnik : > > 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 wrote: >> >> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov >> wrote: >> >>> Hi Sven, >>> >>> >>> >>> >>> >>>/* 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; >>>} >>> >>> >>> >>> >>> >>> >>>Element when visible: >>>A1 B1 C1 D1 >>> >>> >>> >>>Element when hidden (there is no B1 because Wicket renders >>> just the tag, without any children): >>>A2 C2 D2 >>> >>>C2 D2 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. >>> >>> >>> >>>Element with wicket--hidden class >>>A3 B3 C3 >>> D3 >>> >>>C3 D3 are not 200px down because >>> of 'display: none'! >>>The application developer has nothing to do! >>> >>> >>> >>> >>> >>> 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 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
Re: WICKET-6725 styling of hidden elements: no vote yet
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 wrote: > > On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov > wrote: > > > Hi Sven, > > > > > > > > > > > > /* 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; > > } > > > > > > > > > > > > > > Element when visible: > > A1 B1 C1 D1 > > > > > > > > Element when hidden (there is no B1 because Wicket renders > > just the tag, without any children): > > A2 C2 D2 > > > > C2 D2 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. > > > > > > > > Element with wicket--hidden class > > A3 B3 C3 > > D3 > > > > C3 D3 are not 200px down because > > of 'display: none'! > > The application developer has nothing to do! > > > > > > > > > > > > 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 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, > >> >
Re: WICKET-6725 styling of hidden elements: no vote yet
On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov wrote: > Hi Sven, > > > > > > /* 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; > } > > > > > > > Element when visible: > A1 B1 C1 D1 > > > > Element when hidden (there is no B1 because Wicket renders > just the tag, without any children): > A2 C2 D2 > > C2 D2 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. > > > > Element with wicket--hidden class > A3 B3 C3 > D3 > > C3 D3 are not 200px down because > of 'display: none'! > The application developer has nothing to do! > > > > > > 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 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 >>
Re: WICKET-6725 styling of hidden elements: no vote yet
Hi Sven, /* 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; } Element when visible: A1 B1 C1 D1 Element when hidden (there is no B1 because Wicket renders just the tag, without any children): A2 C2 D2 C2 D2 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. Element with wicket--hidden class A3 B3 C3 D3 C3 D3 are not 200px down because of 'display: none'! The application developer has nothing to do! 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 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 > wrote: > >> Just as a brainstorm. Not
Re: WICKET-6725 styling of hidden elements: no vote yet
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 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 #ida and #id9 must be hidden, so in the page header we add something like this #ida, #id9 {display: none;} 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 : Hi, On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene 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
Re: WICKET-6725 styling of hidden elements: no vote yet
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 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 > > class="wupb-border"> class="wupb-foreground"> > > > > #ida and #id9 must be hidden, so in the page header we add something like > this > > > #ida, #id9 {display: none;} > > > 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 >: > > > Hi, > > > > On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene > > 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 > >
Re: WICKET-6725 styling of hidden elements: no vote yet
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 #ida and #id9 must be hidden, so in the page header we add something like this #ida, #id9 {display: none;} 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 : > Hi, > > On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene > 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 >
Re: WICKET-6725 styling of hidden elements: no vote yet
On Thu, Feb 27, 2020 at 11:56 AM Ernesto Reinaldo Barreiro wrote: > On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene > > 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). As I've explained in the other thread, it is very likely that not much needs to be done in additional frameworks. Also, when a framework is not yet compliant with CSP, the user can temporarily disable CSP or switch to a less strict version. As explained in the user guide, this is just one line of code. The changes made to the core of Wicket (removing inline styling and js) were absolutely necessary to be able to support a strict CSP via Wicket or any other way. This clearly is a wish of our users (and a personal wish as well, because our application also needs it). Also I think this is truly is a very unique feature. I don't think any framework offers such a strict CSP out of the box with so less effort from the user. Best regards, Emond
Re: WICKET-6725 styling of hidden elements: no vote yet
Hi, On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene 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
Re: WICKET-6725 styling of hidden elements: no vote yet
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. > Thus in practice the release of 9.x. by itself, with new CSS feature, will > not > bring any immediate value to many users as this will break most existing > applications. > > On Wed, Feb 26, 2020 at 10:34 AM Maxim Solodovnik > wrote: > > > [+] leave as is with .wicket--hidden & wicket-core.css > > > > IMO we should sheep the version which will work as expected > out-of-the-box > > According to my tests `hidden` attribute doesn't work (even `display: > > flex` breaks it) > > > > On Wed, 26 Feb 2020 at 15:22, Andrea Del Bene > > wrote: > > > > > > +1 to vote. I find your concerns legitimate > > > > > > On Tue, Feb 25, 2020 at 9:54 PM Sven Meier wrote: > > > > > > > Hi all, > > > > > > > > we have a disagreement on how to style hidden elements in Wicket 9.x. > > > > > > > > Due to the new CSP support we can no longer use inline styling to > hide > > > > elements. > > > > WICKET-6725 introduces new CSS classes and a file wicket-core.css. > > > > > > > > I don't think this is a good approach: > > > > > > > > - it adds a CSS file that is referenced by each page (after Wicket > > doing > > > > fine without it for 15 years) > > > > - the CSS is a mingle-mangle of out-of-date stylings (see > > > > .wicket--hidden-fields) > > > > - it's a kitchen-sink for left-over styles (see .wicket--color-red) > > > > - it introduces a new class naming scheme not used anywhere else > > (wicket--) > > > > > > > > IMHO we should remove that file again (and the required > infrastructure > > > > in ResourceSettings/WebApplication) and just > > > > use the HTML5 "hidden" attribute instead, whenever we want to hide > > > > something (Component, Form, ...). > > > > This "just works" in all browsers and is semantically correct. It has > > > > one caveat when an application's CSS changes the default styling of > > > > hidden elements (see > > > > https://css-tricks.com/the-hidden-attribute-is-visibly-weak), but > > that's > > > > in the responsibility of the application developer. > > > > AjaxIndicatorAppender can just render a CSS class and leave the > styling > > > > to the application developer, nobody will be happy with the default > > > > "red" anyway. > > > > > > > > Thus I'll be starting a vote in the next days with the following two > > > > options: > > > > > > > > [] leave as is with .wicket--hidden & wicket-core.css > > > > > > > > [] use HTML5 "hidden" attribute instead > > > > > > > > This isn't the vote yet, it's just the announcement. > > > > Maybe others see a third (forth?) option or want to raise their > > concerns > > > > first. > > > > > > > > Sven > > > > > > > > > > > > > > > > > > -- > > > Andrea Del Bene. > > > Apache Wicket committer. > > > > > > > > -- > > WBR > > Maxim aka solomax > > > > > -- > Regards - Ernesto Reinaldo Barreiro > -- Andrea Del Bene. Apache Wicket committer.
Re: WICKET-6725 styling of hidden elements: no vote yet
Hi, as you know I am a big fan of HTML5 and was experimenting a lot with it, I would also vote to stay with a core css and clean it up, because of a better backward compatibility. flex is used a LOT in modern layouts and would break the other option. kind regards Tobias > Am 26.02.2020 um 11:31 schrieb Martijn Dashorst : > > On Wed, Feb 26, 2020 at 11:15 AM Emond Papegaaij > wrote: > On Tue, Feb 25, 2020 at 10:54 PM Sven Meier wrote: > - it's a kitchen-sink for left-over styles (see .wicket--color-red) >>> >>> I agree that for this one Wicket can just add the CSS class (e.g. >>> wicket-feedback-indicator) on the HTML element and let the application >>> provide the CSS rules for it >> >> I'm ok with that. I only added that styling to be compatible with the >> old behavior, which was broken in my opinion anyway. >> > > As long as the default behavior is specified in the Wicket core css file, > I'm for it. .wicket--color-red is godawful so +1 for making it meaningful. > > IMO this means that we should move the styling of e.g. the feedback panel > [1] into the wicket-- fold. However, that is not something that is related > to CSP, so CSP should not be the driver (nor wait) for that. > > >>> An idea: >>> if CSP is disabled then Wicket can deliver the content of wicket-core.css >>> as inline CSS, i.e. . >>> This will keep the number of http requests the same as before. >> >> This already is an option now and doesn't depend on CSP being enabled >> or not. As long as the style element is rendered with a nonce, it will >> work. We can make the header contribution a bit more flexible with the >> following options: >> * inline wicket-core.css (or another stylesheet) >> * resource reference to wicket-core.css (or another stylesheet) >> * no core stylesheet at all >> > > AFAIR the extra request is normally not a problem as browsers multiplex > that on the HTTP/2 connection to the server, and the CSS is easily cached. > It might actually be a worse experience to inline the style than having it > as a separate resource. > > Martijn > > [1] > https://github.com/apache/wicket/blob/master/wicket-core/src/test/java/org/apache/wicket/markup/html/panel/FeedbackPanelTest_cssClasses_expected.html
Re: WICKET-6725 styling of hidden elements: no vote yet
On Wed, Feb 26, 2020 at 11:15 AM Emond Papegaaij wrote: > > On Tue, Feb 25, 2020 at 10:54 PM Sven Meier wrote: > > > - it's a kitchen-sink for left-over styles (see .wicket--color-red) > > > > I agree that for this one Wicket can just add the CSS class (e.g. > > wicket-feedback-indicator) on the HTML element and let the application > > provide the CSS rules for it > > I'm ok with that. I only added that styling to be compatible with the > old behavior, which was broken in my opinion anyway. > As long as the default behavior is specified in the Wicket core css file, I'm for it. .wicket--color-red is godawful so +1 for making it meaningful. IMO this means that we should move the styling of e.g. the feedback panel [1] into the wicket-- fold. However, that is not something that is related to CSP, so CSP should not be the driver (nor wait) for that. > > An idea: > > if CSP is disabled then Wicket can deliver the content of wicket-core.css > > as inline CSS, i.e. . > > This will keep the number of http requests the same as before. > > This already is an option now and doesn't depend on CSP being enabled > or not. As long as the style element is rendered with a nonce, it will > work. We can make the header contribution a bit more flexible with the > following options: > * inline wicket-core.css (or another stylesheet) > * resource reference to wicket-core.css (or another stylesheet) > * no core stylesheet at all > AFAIR the extra request is normally not a problem as browsers multiplex that on the HTTP/2 connection to the server, and the CSS is easily cached. It might actually be a worse experience to inline the style than having it as a separate resource. Martijn [1] https://github.com/apache/wicket/blob/master/wicket-core/src/test/java/org/apache/wicket/markup/html/panel/FeedbackPanelTest_cssClasses_expected.html
Re: WICKET-6725 styling of hidden elements: no vote yet
On Tue, Feb 25, 2020 at 9:54 PM Sven Meier wrote: > [] leave as is with .wicket--hidden & wicket-core.css > > [] use HTML5 "hidden" attribute instead > While it is true that Wicket hasn't depended on a CSS file for its own use, it has been dependent on its own styles, spread out through our code in odd ways. The fact that we now have to own up to this by having to ship a stylesheet file of our own after 15 years, sounds more like 15 years of neglect and harassment of our users than an actual achievement. I consider not having a wicket stylesheet file a bug, not a feature. Having an actual Wicket css file means that our styles are *finally* documented and available for our users to accommodate, rather than strewn out through our code base and hidden in style attributes, only to be discovered through perusing the generated markup or ample browsing through java code. This is a great benefit: want to know what Wicket uses for styling? Here's the file! Furthermore, the wicket-core css file can be easily disabled if one desires so (then you have add your own implementations of those classes to your own css file), or overridden (e.g. wicket-bootstrap can provide its own core css file). And we provide the default template as well... This doesn't mean that I want us to ship a full bootstrap/material like CSS styling with Wicket, but rather only those parts that ensure that applications keep working. 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. Telling folks to 'just add some arbitrary css to your styling to fix this attribute so some parts of your page remain invisible', is not a suitable substitute for providing our own css. Martijn [1] https://meowni.ca/hidden.is.a.lie.html
Re: WICKET-6725 styling of hidden elements: no vote yet
On Wed, Feb 26, 2020 at 10:53 AM Martin Grigorov wrote: > I am also not big fan of CSP but users ask for it and I see no other way > but to move all inline styles in such .css resource IMHO CSP is one of the changes to the web application ecosystem that Wicket will need an answer on to stay relevant in the upcoming years. Web application development is changing at a very rapid pace and Wicket will need to incorporate those changes or face becoming obsolete. > On Tue, Feb 25, 2020 at 10:54 PM Sven Meier wrote: > > - it's a kitchen-sink for left-over styles (see .wicket--color-red) > > I agree that for this one Wicket can just add the CSS class (e.g. > wicket-feedback-indicator) on the HTML element and let the application > provide the CSS rules for it I'm ok with that. I only added that styling to be compatible with the old behavior, which was broken in my opinion anyway. > > < cut use hidden attribute > > > > I don't agree here. > If each and every developer should make sure that Wicket's placeholder tags > should stay invisible then the framework does not do its job. > Often when we see that something is too common we actually add it to the > framework. Here you ask to do the reverse - remove the support and ask the > developers to deal with it. > The article you linked to explains it well that "hidden" attribute does not > really work. CSS libraries which provide reset rules like div { display: > block; } will make the life of the developer miserable. I totally agree with Martin. Using the hidden attribute puts the responsibility with the developer where this should be on the framework. The hidden attribute just doesn't work. > An idea: > if CSP is disabled then Wicket can deliver the content of wicket-core.css > as inline CSS, i.e. . > This will keep the number of http requests the same as before. This already is an option now and doesn't depend on CSP being enabled or not. As long as the style element is rendered with a nonce, it will work. We can make the header contribution a bit more flexible with the following options: * inline wicket-core.css (or another stylesheet) * resource reference to wicket-core.css (or another stylesheet) * no core stylesheet at all Best regards, Emond
Re: WICKET-6725 styling of hidden elements: no vote yet
Hi Sven, On Tue, Feb 25, 2020 at 10:54 PM Sven Meier wrote: > Hi all, > > we have a disagreement on how to style hidden elements in Wicket 9.x. > > Due to the new CSP support we can no longer use inline styling to hide > elements. > WICKET-6725 introduces new CSS classes and a file wicket-core.css. > > I don't think this is a good approach: > > - it adds a CSS file that is referenced by each page (after Wicket doing > fine without it for 15 years) > I am also not big fan of CSP but users ask for it and I see no other way but to move all inline styles in such .css resource > - the CSS is a mingle-mangle of out-of-date stylings (see > .wicket--hidden-fields) > What do you suggest to use instead ? > - it's a kitchen-sink for left-over styles (see .wicket--color-red) > I agree that for this one Wicket can just add the CSS class (e.g. wicket-feedback-indicator) on the HTML element and let the application provide the CSS rules for it > - it introduces a new class naming scheme not used anywhere else (wicket--) > We need this "namespace" to avoid clashes with the applications' styles. I see nothing bad in this one. > > IMHO we should remove that file again (and the required infrastructure > in ResourceSettings/WebApplication) and just > use the HTML5 "hidden" attribute instead, whenever we want to hide > something (Component, Form, ...). This "just works" in all browsers and is semantically correct. It has > one caveat when an application's CSS changes the default styling of > hidden elements (see > https://css-tricks.com/the-hidden-attribute-is-visibly-weak), but that's > in the responsibility of the application developer. > I don't agree here. If each and every developer should make sure that Wicket's placeholder tags should stay invisible then the framework does not do its job. Often when we see that something is too common we actually add it to the framework. Here you ask to do the reverse - remove the support and ask the developers to deal with it. The article you linked to explains it well that "hidden" attribute does not really work. CSS libraries which provide reset rules like div { display: block; } will make the life of the developer miserable. > AjaxIndicatorAppender can just render a CSS class and leave the styling > to the application developer, nobody will be happy with the default > "red" anyway. > +1 on this ^^ > > Thus I'll be starting a vote in the next days with the following two > options: > > [] leave as is with .wicket--hidden & wicket-core.css > > [] use HTML5 "hidden" attribute instead > > This isn't the vote yet, it's just the announcement. > Maybe others see a third (forth?) option or want to raise their concerns > first. > An idea: if CSP is disabled then Wicket can deliver the content of wicket-core.css as inline CSS, i.e. . This will keep the number of http requests the same as before. Martin > > Sven > > >
Re: WICKET-6725 styling of hidden elements: no vote yet
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. Thus in practice the release of 9.x. by itself, with new CSS feature, will not bring any immediate value to many users as this will break most existing applications. On Wed, Feb 26, 2020 at 10:34 AM Maxim Solodovnik wrote: > [+] leave as is with .wicket--hidden & wicket-core.css > > IMO we should sheep the version which will work as expected out-of-the-box > According to my tests `hidden` attribute doesn't work (even `display: > flex` breaks it) > > On Wed, 26 Feb 2020 at 15:22, Andrea Del Bene > wrote: > > > > +1 to vote. I find your concerns legitimate > > > > On Tue, Feb 25, 2020 at 9:54 PM Sven Meier wrote: > > > > > Hi all, > > > > > > we have a disagreement on how to style hidden elements in Wicket 9.x. > > > > > > Due to the new CSP support we can no longer use inline styling to hide > > > elements. > > > WICKET-6725 introduces new CSS classes and a file wicket-core.css. > > > > > > I don't think this is a good approach: > > > > > > - it adds a CSS file that is referenced by each page (after Wicket > doing > > > fine without it for 15 years) > > > - the CSS is a mingle-mangle of out-of-date stylings (see > > > .wicket--hidden-fields) > > > - it's a kitchen-sink for left-over styles (see .wicket--color-red) > > > - it introduces a new class naming scheme not used anywhere else > (wicket--) > > > > > > IMHO we should remove that file again (and the required infrastructure > > > in ResourceSettings/WebApplication) and just > > > use the HTML5 "hidden" attribute instead, whenever we want to hide > > > something (Component, Form, ...). > > > This "just works" in all browsers and is semantically correct. It has > > > one caveat when an application's CSS changes the default styling of > > > hidden elements (see > > > https://css-tricks.com/the-hidden-attribute-is-visibly-weak), but > that's > > > in the responsibility of the application developer. > > > AjaxIndicatorAppender can just render a CSS class and leave the styling > > > to the application developer, nobody will be happy with the default > > > "red" anyway. > > > > > > Thus I'll be starting a vote in the next days with the following two > > > options: > > > > > > [] leave as is with .wicket--hidden & wicket-core.css > > > > > > [] use HTML5 "hidden" attribute instead > > > > > > This isn't the vote yet, it's just the announcement. > > > Maybe others see a third (forth?) option or want to raise their > concerns > > > first. > > > > > > Sven > > > > > > > > > > > > > -- > > Andrea Del Bene. > > Apache Wicket committer. > > > > -- > WBR > Maxim aka solomax > -- Regards - Ernesto Reinaldo Barreiro
Re: WICKET-6725 styling of hidden elements: no vote yet
[+] leave as is with .wicket--hidden & wicket-core.css IMO we should sheep the version which will work as expected out-of-the-box According to my tests `hidden` attribute doesn't work (even `display: flex` breaks it) On Wed, 26 Feb 2020 at 15:22, Andrea Del Bene wrote: > > +1 to vote. I find your concerns legitimate > > On Tue, Feb 25, 2020 at 9:54 PM Sven Meier wrote: > > > Hi all, > > > > we have a disagreement on how to style hidden elements in Wicket 9.x. > > > > Due to the new CSP support we can no longer use inline styling to hide > > elements. > > WICKET-6725 introduces new CSS classes and a file wicket-core.css. > > > > I don't think this is a good approach: > > > > - it adds a CSS file that is referenced by each page (after Wicket doing > > fine without it for 15 years) > > - the CSS is a mingle-mangle of out-of-date stylings (see > > .wicket--hidden-fields) > > - it's a kitchen-sink for left-over styles (see .wicket--color-red) > > - it introduces a new class naming scheme not used anywhere else (wicket--) > > > > IMHO we should remove that file again (and the required infrastructure > > in ResourceSettings/WebApplication) and just > > use the HTML5 "hidden" attribute instead, whenever we want to hide > > something (Component, Form, ...). > > This "just works" in all browsers and is semantically correct. It has > > one caveat when an application's CSS changes the default styling of > > hidden elements (see > > https://css-tricks.com/the-hidden-attribute-is-visibly-weak), but that's > > in the responsibility of the application developer. > > AjaxIndicatorAppender can just render a CSS class and leave the styling > > to the application developer, nobody will be happy with the default > > "red" anyway. > > > > Thus I'll be starting a vote in the next days with the following two > > options: > > > > [] leave as is with .wicket--hidden & wicket-core.css > > > > [] use HTML5 "hidden" attribute instead > > > > This isn't the vote yet, it's just the announcement. > > Maybe others see a third (forth?) option or want to raise their concerns > > first. > > > > Sven > > > > > > > > -- > Andrea Del Bene. > Apache Wicket committer. -- WBR Maxim aka solomax
Re: WICKET-6725 styling of hidden elements: no vote yet
+1 to vote. I find your concerns legitimate On Tue, Feb 25, 2020 at 9:54 PM Sven Meier wrote: > Hi all, > > we have a disagreement on how to style hidden elements in Wicket 9.x. > > Due to the new CSP support we can no longer use inline styling to hide > elements. > WICKET-6725 introduces new CSS classes and a file wicket-core.css. > > I don't think this is a good approach: > > - it adds a CSS file that is referenced by each page (after Wicket doing > fine without it for 15 years) > - the CSS is a mingle-mangle of out-of-date stylings (see > .wicket--hidden-fields) > - it's a kitchen-sink for left-over styles (see .wicket--color-red) > - it introduces a new class naming scheme not used anywhere else (wicket--) > > IMHO we should remove that file again (and the required infrastructure > in ResourceSettings/WebApplication) and just > use the HTML5 "hidden" attribute instead, whenever we want to hide > something (Component, Form, ...). > This "just works" in all browsers and is semantically correct. It has > one caveat when an application's CSS changes the default styling of > hidden elements (see > https://css-tricks.com/the-hidden-attribute-is-visibly-weak), but that's > in the responsibility of the application developer. > AjaxIndicatorAppender can just render a CSS class and leave the styling > to the application developer, nobody will be happy with the default > "red" anyway. > > Thus I'll be starting a vote in the next days with the following two > options: > > [] leave as is with .wicket--hidden & wicket-core.css > > [] use HTML5 "hidden" attribute instead > > This isn't the vote yet, it's just the announcement. > Maybe others see a third (forth?) option or want to raise their concerns > first. > > Sven > > > -- Andrea Del Bene. Apache Wicket committer.
