Hi Garret,
>going forward to tweak Wicket so that it doesn't change our HTML too much
we're working on it, see https://issues.apache.org/jira/browse/WICKET-4904
>it doesn't require us to "undo" the HTML that it forces on us
I fully agree.
I'd be in favour to change CheckBoxMultipleChoice to have an empty
suffix by default - we can change this for Wicket 7. Please create a
Jira issue.
Regards
Sven
On 07/11/2014 12:31 AM, Garret Wilson wrote:
Everyone,
Wicket was created in a world in which little was done at display time
to manipulate the HTML DOM tree, so Wicket felt like it had free reign
to muck around with the HTML given by the developer. But in today's
world in which we use JavaScript libraries like jQuery to modify the
DOM on a whim, and CSS libraries such as Yahoo! Pure to provide
styling, Wicket's modification of the HTML I give it can wreak havoc
with my application.
1. Let me give you two examples. The first is BookmarkablePageLink. I
have a simple and semantically useful navigation:
<nav>
<ul>
<li><a wicket:id="homePageLink" ...
I throw in a couple of CSS classes from Yahoo! Pure CSS Library, and
it turns into a beautiful menu with mouseover highlighting, selected
items, etc. I use a BookmarkablePageLink to wrap each link. But some
menu items are only available to users with certain permissions, so I
want to disable some of them. Oops! When I call
BookmarkablePageLink.setEnabled(false), the HTML changes! Suddenly my
<a> tags are turned into ugly <span><em> tags, completely destroying
the look of the menu because Yahoo! Pure CSS doesn't recognize
<span><em> tags as menu items.
Sure, I can call getMarkupSettings().setDefaultBeforeDisabledLink(...)
and friends, but I shouldn't have to. This is a holdover from the days
when stylistic changes were made by changing the HTML, not by applying
CSS. I recommend that by default links should not change the HTML, but
instead add or remove a particular HTML class value.
2. The second example is CheckBoxMultipleChoice. I have a nice set up
checkboxes in the HTML:
<div wicket:id="widgets">
<label for="foo"><input id="foo" type="checkbox"/> Foo</label>
<label for="bar"><input id="bar" type="checkbox"/> Bar</label>
</div>
Without Wicket, those look nice; they are displayed horizontally, and
the labels are beside the checkboxes:
X Foo X Bar
But if I use CheckBoxMultipleChoice, it completely screws up the HTML!
Suddenly my HTML looks like this:
...<input .../><label ...>foo</label><br/><input .../><label
...>bar</label><br/>
Wicket has not only taken my <input> out of the <label>...</label>, it
has added an ugly, non-semantic <br/> for styling. Why?? If I wanted
to style my HTML with <br/> (like I did around the year 1997), then I
would have put it in the original HTML myself! And by taking the
<input> out of the <label>, they are no longer a unit, and because of
my CSS styling the labels now appear under the checkboxes---not to
mention that Wicket has forced my checkboxes to be vertical instead of
horizontal via the <br/>. Yes, I realize I can call
CheckBoxMultipleChoice.setSuffix(), but again, I shouldn't have to. It
turns out that for the moment I will have to abandon
CheckBoxMultipleChoice altogether and do everything manually.
Yes, I know I can "remedy" much of this manually by adding lots of
boilerplate/setup code to what comes out of the box by default,
turning off auto-generation of "<em>" and "<br/>", etc. But that's one
of the shortcomings of Wicket right now---to get it work like one
would expect it to in the modern world of HTML5 and CSS3, one has to
add lots of boilerplate code to change its defaults. Wicket was made
to prevent boilerplate code.
In summary, I'd like to encourage the developers going forward to
tweak Wicket so that it doesn't change our HTML too much, it doesn't
require us to "undo" the HTML that it forces on us, and plays much
better in the modern world of HTML5, CSS3, and Ajax. And I'll be glad
to help make that a reality!
Best,
Garret
