From: Lasse Reichstein Nielsen on
Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes:

> Gordon wrote:

>> Form controls can't be children of a form. They have to be contained
>> in something else, a fieldset preferably, but a div will do.
>
> Nonsense. Learn to read.

From the XHTML 1.0 Transitional DTD [1]:

<!ELEMENT form %form.content;>
....
<!ENTITY % form.content "(%block; | %misc;)*">
....
<!ENTITY % misc "noscript | %misc.inline;">
....
<!ENTITY % misc.inline "ins | del | script">
....
<!ENTITY % heading "h1|h2|h3|h4|h5|h6">
<!ENTITY % lists "ul | ol | dl">
<!ENTITY % blocktext "pre | hr | blockquote | address">

<!ENTITY % block
"p | %heading; | div | %lists; | %blocktext; | fieldset | table">

I.e., form controls (elements "input", "select", "textarea", "button"
and "object") cannot be children of a "form" element in valid XHTML
1.0 Transitional. They may be descendants (e.g., inside a "p" or
"fieldset" element"), but not children.

/L 'Being arrogant and wrong isn't worse than being arrogant and right,
just more embarrasing'

[1] http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_block
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

From: Jake Jarvis on
On 21.04.2010 18:32, wrote Lasse Reichstein Nielsen:
> Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes:
>
>> Gordon wrote:
>
>>> Form controls can't be children of a form. They have to be contained
>>> in something else, a fieldset preferably, but a div will do.
>>
>> Nonsense. Learn to read.
>
> From the XHTML 1.0 Transitional DTD [1]:

No, look again.

>
> <!ELEMENT form %form.content;>
> ....
> <!ENTITY % form.content "(%block; | %misc;)*">
> ....
> <!ENTITY % misc "noscript | %misc.inline;">
> ....
> <!ENTITY % misc.inline "ins | del | script">
> ....
> <!ENTITY % heading "h1|h2|h3|h4|h5|h6">
> <!ENTITY % lists "ul | ol | dl">
> <!ENTITY % blocktext "pre | hr | blockquote | address">
>
> <!ENTITY % block
> "p | %heading; | div | %lists; | %blocktext; | fieldset | table">
>
> I.e., form controls (elements "input", "select", "textarea", "button"
> and "object") cannot be children of a "form" element in valid XHTML
> 1.0 Transitional. They may be descendants (e.g., inside a "p" or
> "fieldset" element"), but not children.
>
> /L 'Being arrogant and wrong isn't worse than being arrogant and right,
> just more embarrasing'
>
> [1] http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_block


--
Jake Jarvis
From: Lasse Reichstein Nielsen on
Jake Jarvis <pig_in_shoes(a)yahoo.com> writes:

> On 21.04.2010 18:32, wrote Lasse Reichstein Nielsen:
>> Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes:
>>
>>> Gordon wrote:
>>
>>>> Form controls can't be children of a form. They have to be contained
>>>> in something else, a fieldset preferably, but a div will do.
>>>
>>> Nonsense. Learn to read.
>>
>> From the XHTML 1.0 Transitional DTD [1]:
>
> No, look again.

Damn, you are right. There is more than one DTD in that page, and I
was using the strict one.
For Transitional, %inline is a valid form element content.

>> /L 'Being arrogant and wrong isn't worse than being arrogant and right,
>> just more embarrasing'

Guess that'll apply to me then. :(
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

From: Garrett Smith on
Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Scott Sauyet wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Garrett Smith wrote:
>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>> Garrett Smith wrote:
>>>>>>>> Eric Bednarz wrote:
>>>>>>>>> Garrett Smith <dhtmlkitc...(a)gmail.com> writes:
>>>>>>>>>>> Are you sure you want to use XHTML?

[...]

>
> Given those premises that leaves the following valid alternative
> assumptions:
>

You spen so much time trying to justify your nutty assumptions and
theory for inducing probability for what the OP's doctype was. Silly!

Why didn't you just ask him if you wanted to know?

> A) The `onClick' indicates that this is supposed to be HTML. In that case,
> it can be Valid HTML 4.01 Transitional, although the output might not
> look as expected (if there was a user agent that parsed it strictly,
> there would be `>' displayed). It could be made HTML 4.01 Transitional.
>
> B) The `/>' indicates that this is supposed to be XHTML. Then it could be
> Valid XHTML 1.0 Transitional were it not for "onClick" instead of
> "onclick". It could be made XHTML 1.0 Strict with more changes.
>
> Facing these alternatives, I have applied that scientific principle known as
> Occam's Razor,


Oh brother. You really believe the OP was thinking along those lines?

You have no idea what was the doctype was.

Taking the OPs code, please create ONE valid document out of that
fragment as markup, using either:
XHTML transitional XHTML Strict, HTML Transitional, or HTML Strict.

You can't do it, so just please leave Occam's Razor or whatever
pointlessness goes on between your ears is out of it.

[snip nonsense]
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Scott Sauyet on
Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Scott Sauyet wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Garrett Smith wrote:
>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>> Garrett Smith wrote:
>>>>>>>> Eric Bednarz wrote:
>>>>>>>>> Garrett Smith <dhtmlkitc...(a)gmail.com> writes:
>>>>>>>>>>> Are you sure you want to use XHTML?
>>>>>>>>>> Probably not; that small sample contains XHTML errors.
>>>>>>>>> Please don’t feel shy about being specific.
>>>>>>>> Don't be scared to run the code through the w3c html validator and
>>>>>>>> find them for yourself.
>>>>>>> You don't know what you are talking about.  It's a fragment of Valid
>>>>>>> XHTML 1.0 Transitional.
>>>>>> That is an assumption. It could very well be XHTML strict for all you
>>>>>> know.
>>>>> I have written it to be XHTML 1.0 Transitional, stupid.
>
>>>> Thomas, you do realize that Garrett was almost certainly NOT referring
>>>> to your sample but to the OP's code when he responded to your
>
>>>> |> Are you sure you want to use XHTML?
>
>>>> with
>
>>>> | Probably not; that small sample contains XHTML errors.
>
>>>> don't you?  Why should your suggested replacement code have anything
>>>> to do with his response?
>
>>>> Perhaps at other times Garrett has earned the insult, but not this
>>>> time.  I think here it's your confusion at issue.
>
>>> I think I am not privileged to confusion:
>
>>> ,-<news:hqlsv7$keb$1(a)news.eternal-september.org>
>>> |
>>> | That is an assumption. It could very well be XHTML strict for all you
>>> | know.
>
>>> How can it be "XHTML strict" when it would not even qualify as XHTML 1.0
>>> Transitional?  ISTM Garrett needs to make up his mind about his
>>> assumptions, or stop making them.
>
>> I think it was your assumption that the OP was using an XHTML doctype
>> that started the confusion and then your misunderstanding of Garrett's
>> objection that extended it.
>
> On which parts the misunderstandings were, remains to be seen.

Only by you, I'm afraid.


>> You were the only one talking about your proposed alternative code;
>> everyone else, as I understand it, was talking about the OP's code.
>
> Check again.

I just did. Although your code fragment was carried through in many
quotations, I don't see anything that looks to be discussing that
code. If you have a few minutes, could you try something? Re-read
the thread assuming that everyone but you is discussing the OP's code,
and see if Garrett looks less stupid.


>> Can you justify your assumption that the OP was trying to use XHTML?
>
> Yes.

Okay. I should warn you that I don't scare easily. Boring me to
death is always possible, though.


>> The fragment supplied would not be valid in either HTML 4.01 or XHTML
>> 1.0 documents
>
> Wrong, see below.

You're right. It wouldn't be valid in either Strict mode, though.


>> but if the form controls were wrapped in a block element, then it would be
>> a valid fragment of an HTML 4.01 document but not of a an XHTML one.
>
> True.  The problem here is that the original code --
>
>   <form onsubmit="return false;" action="[action]" method="post">
>   <textarea name="myText" cols="30" rows="3"></textarea>
>   <input type="button" name="button" value="Value2"
>   onClick="this.form.submit();"/>
>   <input type="button" name="button" value="Value2"
>   onClick="this.form.submit();"/>
>   </form>
>
> -- does not make a lot of sense to begin with, so all of us are left with
> assumptions what it is supposed to be.  One assumption, from which, if
> accepted, could be deduced anything, which would not result in a fruitful
> discussion, should therefore be excluded from the start: That the OP just
> made an accidental typo, or used completely different code.  

I'm more than willing to believe that the OP retyped the code from
memory rather than cut-and-pasted it intact. I'm further willing to
believe that in doing so, he accidentally made some mistakes that
changed the validity of the fragment. I would also certainly
entertain the notion that it never validated properly in the first
place. So I don't quite buy your assumption that this is the original
code modulo only the following:


> We must therefore also exclude that "[action]" was anything else than a
> marked omission.

Agreed.


> Given those premises that leaves the following valid alternative
> assumptions:
>
> A) The `onClick' indicates that this is supposed to be HTML.  In that case,
>    it can be Valid HTML 4.01 Transitional, although the output might not
>    look as expected (if there was a user agent that parsed it strictly,
>    there would be `>' displayed).  It could be made HTML 4.01 Transitional.
>
> B) The `/>' indicates that this is supposed to be XHTML.  Then it could be
>    Valid XHTML 1.0 Transitional were it not for "onClick" instead of
>    "onclick".  It could be made XHTML 1.0 Strict with more changes.

I'm not quite willing to accept your premises, but these alternative
assumptions nonetheless seem proper.

> Facing these alternatives, I have applied that scientific principle known as
> Occam's Razor, which says in essence that the simplest explanation is
> usually the correct one.  The Levenshtein distance of the original fragment
> to a Valid HTML 4.01 Transitional fragment is 0, to a Valid HTML 4.01 Strict
> fragment --

Occam's Razor makes more sense based on conceptual differences than on
the Levenshtein distances. The latter are really only apply if one
accepts your assumption that this code is changed only minimally
between the code under test and the fragment posted here. I don't buy
that.

> [ ... deleted Levenshtein calculations ... ]

> Considering interoperability in
> addition to validity, HTML 4.01 Transitional would score at least 2, while
> HTML 4.01 Strict would score at least 9.  (The *lowest* score wins here..)

From what hat did you pull those numbers?

> That leaves HTML 4.01 Transitional (0 or 2) and XHTML 1.0 Transitional (2)
> as the most likely candidates.  Assuming that a newcomer writing such code
> would have at least heard about XHTML, given the number of occurrences in
> the past where newcomers posted (often invalid) markup with SHORTTAG
> syntax that turned out to be supposed to be XHTML, and that the OP used
> `onsubmit' where it could have been, for consistency, `onSubmit' in HTML,
> I decided that it would be best if I posted my suggestion as an XHTML 1.0
> Transitional fragment.

So your logic is based on the idea that since there would be more
characters to change in adding a block-level wrapper than there would
be to in changing the capitalization of two attributes, the latter is
significantly more likely to have occurred accidentally? That's a
pretty slim thread.

And somehow I don't believe that you actually explicitly made those
calculations before I challenged you.


> In any case, Garrett's assumption that this might be XHTML 1.0 Strict is,
> given these numbers, less likely than all the alternatives except  
> interoperable Valid HTML 4.01 Strict.  And his criticism of my XHTML 1.0  
> Transitional suggestion is inconsistent with his assumption (in the very
> same posting!) that the OP did not want to use XHTML at all.


Are you simply playing dumb here or is it not an act? Garrett did not
make the assumption about the document type. You made an assumption,
and Garrett challenged it. When you misunderstood and assumed he was
discussing your snippet, things got confused.


> BTW, Garrett's assumption that Eric changed the code was unjustified, too..  
> Eric merely quoted my suggestion as quoted by Garrett before, but he removed
> the relevant attribution lines.

Yes, Garrett's quoting habits leave a lot to be desired and have
contributed to this mess, starting with his first post in the thread
where he left intact your (irrelevant) code snippet when he responded
to the question about XHTML.


> So much for confusion.  EOD?

Of course not!

--
Scott