On 11/5/07, Matej Knopp [EMAIL PROTECTED] wrote:
Okay, I might have overlooked the *or* part with implicates that empty
element shorthand should not be used for non-empty elements.
Still this leaves us with 3 options.
a) ignore things silently and then support lot of weird bugreport of
user
Matej Knopp wrote:
Hi,
I noticed that if you add empty div / tags to firefox, it treats it
like if you forgot to close it.
There seem to be some misconceptions about what div / means in this
thread.
It is true that in XML div/div and div/ are equivalent. However
XHTML (at least 1.0) has
Matej Knopp wrote:
I haven't heard a single argument against replacing div/ with
div/div except people being anxious of wicket touching the markup.
The best real argument I know is that I want the HLTM to be viewable
without Wicket.
Of course it is fine to have Wicket provide optional
On 11/3/07, Erik van Oosten [EMAIL PROTECTED] wrote:
Matej Knopp wrote:
I haven't heard a single argument against replacing div/ with
div/div except people being anxious of wicket touching the markup.
The best real argument I know is that I want the HLTM to be viewable
without Wicket.
I
Matej Knopp wrote:
Fixing this has practical benefits. And I haven't heard one argument
against it except that wicket shouldn't do that because it's html. I
have personally problems with such arguments. It just feels not
pragmatic.
We have three options here:
1. Fix the issue transparently
Though I'm not pro on this change, I suggest putting it in before rc1.
Martijn
On 11/3/07, Al Maw [EMAIL PROTECTED] wrote:
Matej Knopp wrote:
Fixing this has practical benefits. And I haven't heard one argument
against it except that wicket shouldn't do that because it's html. I
have
On 11/3/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 11/3/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Though I'm not pro on this change, I suggest putting it in before rc1.
Why aren't you pro? Because you don't agree with the idea, or because
it is too late in the game?
Ugh, nevermind.
On 11/3/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Though I'm not pro on this change, I suggest putting it in before rc1.
Why aren't you pro? Because you don't agree with the idea, or because
it is too late in the game?
Eelco
Done.
-Matej
On 11/3/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 11/3/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 11/3/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Though I'm not pro on this change, I suggest putting it in before rc1.
Why aren't you pro? Because you don't
I agree with this stance.
On Fri, 2007-11-02 at 09:19 -0600, John Ray wrote:
I got bit by this problem yesterday. Although I was just previewing the
page in the browser by loading the HTML file directly. Since Wicket
wasn't running it wouldn't have mattered if it fixed my div tag for me
or
Okay. Again. This is not about developer making error!
Code like this:
div/
Something
Is perfectly legal. However, firefox interprets it as
div
Something
...
Which is completely wrong. This is not correcting developer error!
This is correcting browser error. And such thing is very
It does not matter who is making the error, John is still right imho.
Regards,
Erik.
Matej Knopp wrote:
Okay. Again. This is not about developer making error!
Code like this:
div/
Something
Is perfectly legal. However, firefox interprets it as
div
Something
...
Which is
A Html error finder (IMarkupFilter) already exists but is disabled by
default. We could extend it or create a new one. Actually anybody can
create it and provide it to us.
Juergen
Agreed. I understood from previous threads that it was not a developer
error, but a firefox error. If we start going down this path, it is
likely to get slippery indeed. I'd rather not see wicket modify markup
any more than absolutely required. Are we going to fix code that
breaks on all
But we already do that. Part of Wicket as framework is to shield you
from browser inconsistencies and this is one of them.
-Matej
On 11/2/07, Philip A. Chapman [EMAIL PROTECTED] wrote:
Agreed. I understood from previous threads that it was not a developer
error, but a firefox error. If we
:
This doesn't really lead anywhere.
I haven't heard a single argument against replacing div/ with
div/div except people being anxious of wicket touching the markup.
But you should realize that without this, you can't even put div/
inside markup because it breaks the DOM in firefox. So what's
of valid
markup is not user's fault.
-Matej
Martijn
On 11/2/07, Matej Knopp [EMAIL PROTECTED] wrote:
This doesn't really lead anywhere.
I haven't heard a single argument against replacing div/ with
div/div except people being anxious of wicket touching the markup.
But you should realize
to take this? Are we going to include spell
checkers that automatically 'correct' misspelled words?
Martijn
On 11/2/07, Matej Knopp [EMAIL PROTECTED] wrote:
This doesn't really lead anywhere.
I haven't heard a single argument against replacing div/ with
div/div except people being anxious
argument against replacing div/ with
div/div except people being anxious of wicket touching the markup.
But you should realize that without this, you can't even put div/
inside markup because it breaks the DOM in firefox. So what's the
point?
I really don't think that I don't want
to include spell
checkers that automatically 'correct' misspelled words?
Martijn
On 11/2/07, Matej Knopp [EMAIL PROTECTED] wrote:
This doesn't really lead anywhere.
I haven't heard a single argument against replacing div/ with
div/div except people being anxious
spell
checkers that automatically 'correct' misspelled words?
Martijn
On 11/2/07, Matej Knopp [EMAIL PROTECTED] wrote:
This doesn't really lead anywhere.
I haven't heard a single argument against replacing div/ with
div/div except people being anxious of wicket touching
See reply below:
On 11/3/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
I think this change is controversial: several people have voiced their
concerns regarding this change. It is something we have been opposed
to until very recently (label with span/). You propose to change
markup that is
until now we have the policy that we don't alter the markup.
But we could expand all of them if needed. I don't mind to much
On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote:
Actually, I think that we might want to do this for all tags except
for couple of selected ones, e.g. hr /
This would
That's not entirely true. E.g. we generate unique ids for script
elements, that is altering markup (this is necessary for header
contribution filtering).
I don't think it would harm to expend those tags.
-Matej
On 11/1/07, Johan Compagner [EMAIL PROTECTED] wrote:
until now we have the policy
It is semanticaly the same. And Firefox really treats div/ etc.
wrong way. Should we have a vote on this?
-Matej
On 11/1/07, Johan Compagner [EMAIL PROTECTED] wrote:
yeah we are generating extra attributes
but do we introduce tags itself ?
On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote:
yeah we are generating extra attributes
but do we introduce tags itself ?
On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote:
That's not entirely true. E.g. we generate unique ids for script
elements, that is altering markup (this is necessary for header
contribution filtering).
I don't think
It seems to me that while it's something that Wicket /could/ do, I'm
not sure if it's something that Wicket /should/ do...
Having said that, I think I'd be less against it if we restricted it
to only tags that had a wicket:id attribute?
/Gwyn
Thursday, November 1, 2007, 2:18:34 PM, you wrote:
On 11/1/07, Matej Knopp [EMAIL PROTECTED] wrote:
This would also reduce confusion of new user when they do span
wicket:id=label'/
have you tried that with the latest betas? :)
-igor
28 matches
Mail list logo
