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 <solomax...@gmail.com> wrote: > first results: everything seems to work as expected > will continue testing > > On Wed, 25 Mar 2020 at 01:12, Sven Meier <s...@meiers.net> 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 <solomax...@gmail.com> >> wrote: >> >> Let's try to remove this CSS and check :) >> >> I'm currently using latest wicket SNAPSHOT at master so most probably >> >> will provide some feedback :) >> >> >> >> On Fri, 20 Mar 2020 at 19:51, Martin Grigorov <mgrigo...@apache.org> >> wrote: >> >>> In this case I am fine to go with 'hidden'. >> >>> We can introduce wicket-core.css later if needed. >> >>> >> >>> On Fri, Mar 20, 2020 at 1:44 PM Sven Meier <s...@meiers.net> wrote: >> >>> >> >>>> Hi Martin, >> >>>> >> >>>> these stylings? >> >>>> >> >>>> width: 0px; >> >>>> height: 0px; >> >>>> position: absolute; >> >>>> left: -100px; >> >>>> top: -100px; >> >>>> overflow: hidden; >> >>>> >> >>>> They are a 10-year old workaround >> >>>> >> >>>> >> >>>> >> https://github.com/apache/wicket/commit/b00f8ed1647f7a69a38aba562efa98bb8eb84d97 >> >>>> >> >>>> ... for a problem that no longer exists: >> >>>> >> >>>> >> >>>> >> https://stackoverflow.com/questions/8318428/submit-form-fields-inside-displaynone-element >> >>>> >> >>>> A simple "display:none"/"hidden" is sufficient. >> >>>> >> >>>> Sven >> >>>> >> >>>> >> >>>> On 20.03.20 10:29, Martin Grigorov wrote: >> >>>>> Hi Sven, >> >>>>> >> >>>>> What about wicket--hidden-fields ? >> >>>>> We still need wicket-core.css for it. >> >>>>> >> >>>>> Martin >> >>>>> >> >>>>> On Wed, Mar 18, 2020 at 11:25 PM Sven Meier <s...@meiers.net> >> wrote: >> >>>>> >> >>>>>> Hi all, >> >>>>>> >> >>>>>> I've built an example to better demonstrate my argument: >> >>>>>> >> >>>>>> a) "hidden" tags work fine out-of-the-box :) >> >>>>>> >> >>>>>> https://jsfiddle.net/p8s7Lrk2/1/ >> >>>>>> >> >>>>>> b) changing display of tags changes "hidden" tags too :( >> >>>>>> >> >>>>>> https://jsfiddle.net/p8s7Lrk2/2/ >> >>>>>> >> >>>>>> c) and a simple fix for "hidden" tags - no !important required ... >> 8) >> >>>>>> >> >>>>>> https://jsfiddle.net/p8s7Lrk2/3/ >> >>>>>> >> >>>>>> In my opinion there's no need to invent "wicket--hidden" when >> "hidden" >> >>>>>> works already as expected/needed (a). >> >>>>>> And furthermore Wicket does not need to provide a fix (c) for >> something >> >>>>>> the web designer screwed up (b) in the first place. >> >>>>>> >> >>>>>> Have fun >> >>>>>> Sven >> >>>>>> >> >>>>>> >> >>>>>> On 17.03.20 13:01, Maxim Solodovnik wrote: >> >>>>>>> Hello Sven, >> >>>>>>> >> >>>>>>> I always thought:having override like this will require >> re-testing all >> >>>>>>> 3rd-party components manually >> >>>>>>> (I don't have that much time) >> >>>>>>> So I'm using library as-is and override as minimum as possible :) >> >>>>>>> >> >>>>>>> On Tue, 17 Mar 2020 at 18:56, Sven Meier <s...@meiers.net> wrote: >> >>>>>>>> Hi Maxim, >> >>>>>>>> >> >>>>>>>> what is difficult about that? >> >>>>>>>> >> >>>>>>>> Actually it is recommended to have it in your normalize.css >> (formerly >> >>>>>>>> reset.css). >> >>>>>>>> >> >>>>>>>> Here one without !important: >> >>>>>>>> >> >>>>>>>> >> https://github.com/necolas/normalize.css/blob/master/normalize.css >> >>>>>>>> >> >>>>>>>> Sven >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On 13.03.20 15:21, Maxim Solodovnik wrote: >> >>>>>>>>> Additional note: >> >>>>>>>>> >> >>>>>>>>> Bootstrap has following CSS >> >>>>>>>>> >> >>>>>>>>> [hidden] { >> >>>>>>>>> display: none !important; >> >>>>>>>>> } >> >>>>>>>>> >> >>>>>>>>> which makes life much more diffiicult ... >> >>>>>>>>> >> >>>>>>>>> On Fri, 13 Mar 2020 at 21:17, Martin Grigorov < >> mgrigo...@apache.org> >> >>>>>> wrote: >> >>>>>>>>>> On Fri, Mar 13, 2020 at 4:13 PM Martin Grigorov < >> >>>> mgrigo...@apache.org >> >>>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>>> Hi Sven, >> >>>>>>>>>>> >> >>>>>>>>>>> <html> >> >>>>>>>>>>> >> >>>>>>>>>>> <head> >> >>>>>>>>>>> <style> >> >>>>>>>>>>> /* rule from the application that should be >> used >> >>>> when >> >>>>>> the >> >>>>>>>>>>> element is visible */ >> >>>>>>>>>>> div { >> >>>>>>>>>>> display: flex; >> >>>>>>>>>>> margin-bottom: 200px; >> >>>>>>>>>>> } >> >>>>>>>>>>> >> >>>>>>>>>>> /* Rule coming from wicket-core.css */ >> >>>>>>>>>>> .wicket--hidden { >> >>>>>>>>>>> display: none; >> >>>>>>>>>>> } >> >>>>>>>>>>> >> >>>>>>>>>>> </style> >> >>>>>>>>>>> </head> >> >>>>>>>>>>> >> >>>>>>>>>>> <body> >> >>>>>>>>>>> <p> >> >>>>>>>>>>> Element when visible: <br/> >> >>>>>>>>>>> A1 <div id="blah1.1" >B1</div> C1 >> <span>D1</span> >> >>>>>>>>>>> <br/> >> >>>>>>>>>>> </p> >> >>>>>>>>>>> <p> >> >>>>>>>>>>> Element when hidden (there is no B1 because >> Wicket >> >>>>>> renders >> >>>>>>>>>>> just the tag, without any children): <br/> >> >>>>>>>>>>> A2 <div id="blah1.2" hidden></div> C2 >> >>>> <span>D2</span> >> >>>>>>>>>>> <br/> >> >>>>>>>>>>> <small><strong>C2 & D2</strong> are still >> 200px >> >>>>>> down >> >>>>>>>>>>> because 'hidden' is not like 'display: none'! >> >>>>>>>>>>> The application developer will have to do >> something >> >>>>>> more for >> >>>>>>>>>>> the placeholder case to hide it.</small> >> >>>>>>>>>>> </p> >> >>>>>>>>>>> >> >>>>>>>>>>> <p> >> >>>>>>>>>>> Element with wicket--hidden class<br/> >> >>>>>>>>>>> A3 <div id="blah3" >> class="wicket--hidden">B3</div> >> >>>> C3 >> >>>>>>>>>>> <span>D3</span> >> >>>>>>>>>>> <br/> >> >>>>>>>>>>> <small><strong>C3 & D3</strong> are not >> 200px >> >>>> down >> >>>>>> because >> >>>>>>>>>>> of 'display: none'! >> >>>>>>>>>>> The application developer has nothing to >> do!</small> >> >>>>>>>>>>> </p> >> >>>>>>>>>>> </body> >> >>>>>>>>>>> >> >>>>>>>>>>> </html> >> >>>>>>>>>>> >> >>>>>>>>>>> It shows two things: >> >>>>>>>>>>> >> >>>>>>>>>>> 1) since Wicket placeholder tags do not have children >> elements [1] >> >>>>>> there >> >>>>>>>>>>> is not really a need to use 'hidden' or 'display: none' >> >>>>>>>>>>> >> >>>>>>>>>> As I explained below we do need to use display: none. >> >>>>>>>>>> I've forgot to update this line. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>>> 2) if we really want to hide the element without leaving >> extra work >> >>>>>> for >> >>>>>>>>>>> web designers then we have to use display: none >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> 1. >> >>>>>>>>>>> >> >>>> >> https://github.com/apache/wicket/blob/10d10a92dda2e5834508f52d7807fe361f20fbea/wicket-core/src/main/java/org/apache/wicket/Component.java#L2370 >> >>>>>>>>>>> >> >>>>>>>>>>> On Thu, Mar 12, 2020 at 4:35 PM Sven Meier <s...@meiers.net> >> >>>> wrote: >> >>>>>>>>>>>> Hi all, >> >>>>>>>>>>>> >> >>>>>>>>>>>> I've looked at all responses and most arguments in favor of a >> >>>>>> "core.css" >> >>>>>>>>>>>> boil down to: >> >>>>>>>>>>>> >> >>>>>>>>>>>> > `hidden` attribute doesn't work (even `display: flex` >> breaks >> >>>>>> it) >> >>>>>>>>>>>> > Using the hidden attribute puts the responsibility >> with the >> >>>>>> developer >> >>>>>>>>>>>> > where this should be on the framework. The hidden >> attribute >> >>>>>> just >> >>>>>>>>>>>> doesn't work. >> >>>>>>>>>>>> >> >>>>>>>>>>>> > When something as simple as using flex or >> display:block on a >> >>>>>> div breaks >> >>>>>>>>>>>> > the hidden attribute [1] we should not depend on it >> working. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Sorry, but I don't share that assessment: 'hidden' works just >> >>>> fine! >> >>>>>>>>>>>> Every browser supports it and it has a strong semantic >> meaning we >> >>>>>> can >> >>>>>>>>>>>> utilize. >> >>>>>>>>>>>> >> >>>>>>>>>>>> If you (or your web designer) decides to style hidden >> elements as >> >>>>>>>>>>>> floating, static, flex, pink or with marquee ... feel free >> to do >> >>>> so. >> >>>>>>>>>>> No. The web designer styles the element when it is supposed >> to be >> >>>>>> visible. >> >>>>>>>>>>> But then when some condition is met Wicket may render it as a >> >>>>>> placeholder >> >>>>>>>>>>> for Ajax requests and then this element will be rendered. >> >>>>>>>>>>> It does not have text content but the CSS rules will be still >> >>>>>> applied and >> >>>>>>>>>>> the web designer will have to add more rules for the cases >> when >> >>>>>> 'hidden' is >> >>>>>>>>>>> there. >> >>>>>>>>>>> Most probably something like: >> >>>>>>>>>>> div[hidden] { >> >>>>>>>>>>> display:none; >> >>>>>>>>>>> } >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>>> Wicket doesn't need to ship a CSS file to fix anything here. >> >>>>>>>>>>>> Note that the way we are hiding components in Wicket never >> exposes >> >>>>>> any >> >>>>>>>>>>>> sensible information anyways. This topic is just about >> layout and >> >>>>>>>>>>>> styling and that is completely in the responsibility of your >> >>>>>> developer >> >>>>>>>>>>>> ... and works out-of-the-box if you don't break it! >> >>>>>>>>>>>> >> >>>>>>>>>>> What about the cases when the children need to be invisible ? >> >>>>>>>>>>> .wicket--hidden-fields >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>>> >Wicket ... has been dependent on its own styles, >> spread out >> >>>>>> through >> >>>>>>>>>>>> our code in odd ways >> >>>>>>>>>>>> > I consider not having a wicket stylesheet file a bug, >> not a >> >>>>>> feature >> >>>>>>>>>>>> I couldn't disagree more. These "odd ways" is one of many >> cool >> >>>>>> features >> >>>>>>>>>>>> of Wicket named "components". BTW we Wicket devs have never >> been >> >>>>>> very >> >>>>>>>>>>>> successful in crafting CSS anyways, we shouldn't start with >> this >> >>>>>> now :P. >> >>>>>>>>>>> We don't really start. >> >>>>>>>>>>> We do not mandate styling. We just hide whatever is supposed >> to be >> >>>>>> hidden. >> >>>>>>>>>>> Nothing more. >> >>>>>>>>>>> >> >>>>>>>>>>> As agreed (?!) earlier .wicket--color-red should be just a >> marker >> >>>> CSS >> >>>>>>>>>>> class. The content should be provided by the application. >> Just like >> >>>>>>>>>>> FeedbackPanel's CSS classes. I will remove it now! >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>>> I'll start a vote soon. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Sidenote : This doesn't mean I'm against the CSP feature in >> >>>> general! >> >>>>>>>>>>>> After some iterations we arrived at a very cool solution >> (with >> >>>> some >> >>>>>>>>>>>> minor detail questions remaining). >> >>>>>>>>>>>> >> >>>>>>>>>>>> Have fun >> >>>>>>>>>>>> Sven >> >>>>>>>>>>>> >> >>>>>>>>>>>> On 27.02.20 22:18, Emond Papegaaij wrote: >> >>>>>>>>>>>>> Hi Andrew, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I thought of this solution as well and it will work. The >> major >> >>>>>>>>>>>>> advantage is that the styling is only added when it is >> actually >> >>>>>> used. >> >>>>>>>>>>>>> But it requires significantly more work to build and is a >> lot >> >>>> more >> >>>>>>>>>>>>> complex than the current solution. For this, we need some >> place >> >>>> to >> >>>>>>>>>>>>> accumulate element styling, like we do for JS event >> handlers. >> >>>> This >> >>>>>>>>>>>>> then needs to be rendered in the response. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> The most complex part is ajax updates. These might change >> some of >> >>>>>> the >> >>>>>>>>>>>>> styling. Simply replacing the style element will not work, >> >>>> because >> >>>>>> in >> >>>>>>>>>>>>> an ajax request only the added components are rendered. >> >>>> Rendering a >> >>>>>>>>>>>>> style element per component will work, but is far from >> ideal. >> >>>> This >> >>>>>> is >> >>>>>>>>>>>>> why I went for the easy solution. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Emond >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> On Thu, Feb 27, 2020 at 10:08 PM Andrew Kondratev < >> >>>>>> and...@kondratev.pro> >> >>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>> Just as a brainstorm. Not sure if it's a good idea. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Wicket potentially can add nounced style to the document >> with >> >>>>>> hidden >> >>>>>>>>>>>>>> elements hidden by id. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Imagine generated HTML has components like these >> >>>>>>>>>>>>>> <div class="wupb-container"> >> >>>>>>>>>>>>>> <div class="wupb-progressBar" id="ida"><div >> >>>>>>>>>>>>>> class="wupb-border"><div class="wupb-background"><div >> >>>>>>>>>>>>>> class="wupb-foreground"></div></div></div></div> >> >>>>>>>>>>>>>> <div class="wupb-uploadStatus" id="id9"></div> >> >>>>>>>>>>>>>> </div> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> #ida and #id9 must be hidden, so in the page header we add >> >>>>>> something >> >>>>>>>>>>>> like >> >>>>>>>>>>>>>> this >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> <style nonce="abracadabra"> >> >>>>>>>>>>>>>> #ida, #id9 {display: none;} >> >>>>>>>>>>>>>> </style> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Even if the wupb-progressBar has display: flex, the #ida >> will >> >>>>>> win. >> >>>>>>>>>>>> Will >> >>>>>>>>>>>>>> win even over #id8 .wupb-progressBar {display: fles} >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> !important can potentially be added. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> чт, 27 февр. 2020 г. в 23:56, Ernesto Reinaldo Barreiro < >> >>>>>>>>>>>> reier...@gmail.com >> >>>>>>>>>>>>>>> : >> >>>>>>>>>>>>>>> Hi, >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> On Thu, Feb 27, 2020 at 12:33 PM Andrea Del Bene < >> >>>>>>>>>>>> an.delb...@gmail.com> >> >>>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> On Wed, Feb 26, 2020 at 10:26 AM Ernesto Reinaldo >> Barreiro < >> >>>>>>>>>>>>>>>> reier...@gmail.com> wrote: >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> Hi, >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> Right now I have no enough knowledge to vote in this >> feature. >> >>>>>> One >> >>>>>>>>>>>>>>> thing I >> >>>>>>>>>>>>>>>>> didn't like, and I already mentioned it before, is some >> of us >> >>>>>> were >> >>>>>>>>>>>>>>>> waiting >> >>>>>>>>>>>>>>>>> for 9.x to be released some time ago (at least a few >> months >> >>>>>> ago I >> >>>>>>>>>>>> was >> >>>>>>>>>>>>>>>>> preparing some branch of our application and ported it >> to >> >>>> 9.x, >> >>>>>> after >> >>>>>>>>>>>>>>>> asking >> >>>>>>>>>>>>>>>>> about release plans) and all of the sudden this feature >> is >> >>>>>>>>>>>> introduced >> >>>>>>>>>>>>>>> and >> >>>>>>>>>>>>>>>>> all sub-frameworks depending on Wicket will have to be >> >>>> adapted. >> >>>>>>>>>>>>>>>> In which way sub-frameworks should be affected? I mean, >> as far >> >>>>>> as I >> >>>>>>>>>>>>>>>> understand it, if we disable CSP blocking configuration >> >>>>>> everything >> >>>>>>>>>>>> should >> >>>>>>>>>>>>>>>> work "the old way", and that's why I would prefer to >> keep CSP >> >>>>>>>>>>>> disabled by >> >>>>>>>>>>>>>>>> default. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Well if something is supported at core level then if >> associated >> >>>>>>>>>>>> projects >> >>>>>>>>>>>>>>> want to comply with this new feature, which might be >> ideal, >> >>>> then >> >>>>>>>>>>>> they will >> >>>>>>>>>>>>>>> have to be adapted (or not?). I'm not talking about not >> >>>>>> releasing the >> >>>>>>>>>>>> new >> >>>>>>>>>>>>>>> feature. I'm talking about not releasing as part of 9.x, >> as it >> >>>>>> was >> >>>>>>>>>>>> said to >> >>>>>>>>>>>>>>> be almost ready for release a few months ago, and deffer >> it to >> >>>>>> 10.x >> >>>>>>>>>>>> (and >> >>>>>>>>>>>>>>> try to release it soon). >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>>> Regards - Ernesto Reinaldo Barreiro >> >>>>>>>>>>>>>>> >> >> >> >> >> >> -- >> >> WBR >> >> Maxim aka solomax >> > > > -- > WBR > Maxim aka solomax > -- WBR Maxim aka solomax
