Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #17882 > unrolled thread

Is it legitimate to have a continuous TABLE through multiple FORMs?

Back to article view | Back to comp.lang.php

Contents

  Is it legitimate to have a continuous TABLE through multiple FORMs? Dan Campbell <dcwhatthe@gmail.com> - 2019-04-24 07:30 -0700
    Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Arno Welzel <usenet@arnowelzel.de> - 2019-04-25 08:55 +0200
      Re: Is it legitimate to have a continuous TABLE through multiple FORMs? "R.Wieser" <address@not.available> - 2019-04-25 10:12 +0200
        Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Arno Welzel <usenet@arnowelzel.de> - 2019-04-25 11:01 +0200
          Re: Is it legitimate to have a continuous TABLE through multiple FORMs? "R.Wieser" <address@not.available> - 2019-04-25 12:08 +0200
            Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Arno Welzel <usenet@arnowelzel.de> - 2019-04-25 13:59 +0200
              Re: Is it legitimate to have a continuous TABLE through multiple FORMs? "R.Wieser" <address@not.available> - 2019-04-25 16:13 +0200
                Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Arno Welzel <usenet@arnowelzel.de> - 2019-04-25 16:56 +0200
            Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Richard Damon <Richard@Damon-Family.org> - 2019-04-25 08:05 -0400
              Re: Is it legitimate to have a continuous TABLE through multiple FORMs? "R.Wieser" <address@not.available> - 2019-04-26 10:53 +0200
                Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Arno Welzel <usenet@arnowelzel.de> - 2019-04-26 11:14 +0200
                  Re: Is it legitimate to have a continuous TABLE through multiple FORMs? "R.Wieser" <address@not.available> - 2019-04-26 11:59 +0200
                    Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Arno Welzel <usenet@arnowelzel.de> - 2019-04-26 12:08 +0200
              Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-05-29 19:20 +0200
    Re: Is it legitimate to have a continuous TABLE through multiple FORMs? "R.Wieser" <address@not.available> - 2019-04-25 09:49 +0200
      Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Arno Welzel <usenet@arnowelzel.de> - 2019-04-25 11:06 +0200
        Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Arno Welzel <usenet@arnowelzel.de> - 2019-04-25 14:09 +0200
          Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Dan Campbell <dcwhatthe@gmail.com> - 2019-04-25 05:32 -0700
            Re: Is it legitimate to have a continuous TABLE through multiple FORMs? "R.Wieser" <address@not.available> - 2019-04-26 11:20 +0200
              Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Arno Welzel <usenet@arnowelzel.de> - 2019-04-26 11:31 +0200
          Re: Is it legitimate to have a continuous TABLE through multiple FORMs? "R.Wieser" <address@not.available> - 2019-04-26 11:09 +0200
            Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Arno Welzel <usenet@arnowelzel.de> - 2019-04-26 11:20 +0200
              Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Arno Welzel <usenet@arnowelzel.de> - 2019-04-26 11:24 +0200
              Re: Is it legitimate to have a continuous TABLE through multiple FORMs? "R.Wieser" <address@not.available> - 2019-04-26 12:31 +0200
                Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Arno Welzel <usenet@arnowelzel.de> - 2019-04-26 13:34 +0200
                Re: Is it legitimate to have a continuous TABLE through multiple FORMs? Arno Welzel <usenet@arnowelzel.de> - 2019-04-26 13:36 +0200
    Re: Is it legitimate to have a continuous TABLE through multiple FORMs? "J.O. Aho" <user@example.net> - 2019-04-25 21:36 +0200

Page 1 of 2  [1] 2  Next page →

#17882 — Is it legitimate to have a continuous TABLE through multiple FORMs?

Hi,

I've been working with code designed by a developer who left, around a year ago.

She was a decent programmer, and most of her stuff is easy to read and modify.

I had a minor issue with her including substantive js snippets inside the php/html module.  But that was easy to deal with.


But one quirk of her FORM design keeps triggering errors in my IDE.

She starts a FORM, then a table inside that form, and does a few things.

Then, without closing the table, she closes the FORM, creates another form,
and immediately starts adding rows to the first table, without creating a table.

It's like continuing a single table through multiple forms.

The funny thing is, it runs fine.  The Browser doesn't complain about it, although my IDE complains (appropriately, imo) of nesting issues.

Obviously, this style isn't recommended, but is it legitimate?  Should I go ahead and refactor these forms, with properly nested tables?


Note that the multiple FORMs themselves are inside one containing table, which is properly closed at the end.


[CODE]
<div id="main">
   <div class="container">
      <table width="100%">
        <tr>
           <td>
              <form class="xxxx" action="xxxx.php" method="post">
                 <table id="xxxx" class="xxxx" width="100%">
                    <tr>
<!--...-->
<!--...-->
<!--...-->
<!--...-->
                    </tr>
              <!-- HERE IT IS, A NEW FORM WITHOUT CLOSING THE TABLE -->
              </form>
              <form class="xxxx" action="xxxxxx.php" method="post">
              <!-- AND CONTINUING THE EXISTING TABLE, FROM PREVOUS FORM -->
                 <tr>
                    <td colspan = "2">
                        <label><b><u>APPLICANT DETAILS</u></b></label>
                        <br>
                        <br>
                    </td>
                 </tr>

[/CODE]

[toc] | [next] | [standalone]

#17883

Dan Campbell:

> Hi,
> 
> I've been working with code designed by a developer who left, around
> a year ago.
> 
> She was a decent programmer, and most of her stuff is easy to read
> and modify.
> 
> I had a minor issue with her including substantive js snippets inside
> the php/html module.  But that was easy to deal with.
> 
> 
> But one quirk of her FORM design keeps triggering errors in my IDE.[...]

And what does that have to do with PHP?

This is a question about HTML. And it's easy to answer: either it is
valid HTML or not.

> She starts a FORM, then a table inside that form, and does a few
> things.
> 
> Then, without closing the table, she closes the FORM, creates another
> form, and immediately starts adding rows to the first table, without
> creating a table.
This is not valid.

> It's like continuing a single table through multiple forms.
> 
> The funny thing is, it runs fine.  The Browser doesn't complain about
> it, although my IDE complains (appropriately, imo) of nesting
> issues.
Browsers are designed to cope with invalid HTML to a certain degree
since people often create invalid code. But nevertheless it is still
invalid HTML.

To be sure use validator like <https://validator.w3.org/>.

> Obviously, this style isn't recommended, but is it legitimate?
> Should I go ahead and refactor these forms, with properly nested
> tables?
Yes, you should refactor it to be valid HTML.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#17885

Arno,

Dan is already busy refactoring the HTML.   He does /not/ have to be told 
again.

He also mentioned using a checker which complains about the nesting and the 
reason why he's posting here, so he does /not/ need to be told to use such a 
tool either.

What he /could/ use is some advice on /how/ to refactor - something thats 
sorely lacking in your reply.

And he likely also knows that HTML is not the same as PHP, but chose this 
newsgroup as the best fit.   Giving your best "You're doing it WRONG!" 
impression without suggesting a better alternative doesn't help him much 
either.

Stepped outof bed with the wrong foot first maybe ?

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#17886

On 25.04.19 10:12, R.Wieser wrote:

> Dan is already busy refactoring the HTML.   He does /not/ have to be told 
> again.

Well - Dan asked: "Should I go ahead and refactor these forms, with
properly nested
tables?"

And I just confirmed his question with: "Yes, you should refactor it to
be valid HTML.".

What's wrong with this answer? I believe Dan already knows *how* to do
the refactoring. He was just not sure, if this is really neccessary
since the browser seems not do have any problem with the invalid HTML code.

> He also mentioned using a checker which complains about the nesting and the 
> reason why he's posting here, so he does /not/ need to be told to use such a 
> tool either.

Well:

"although my IDE complains (appropriately, imo) of nesting issues."

Checking for nesting issues is *not* the same as *validating* the HTML.

Even properly nested structures may still be *invalid* HTML. And as Dan
is already working on that stuff, he should also validate the result
properly. I don't know what IDE Dan is using nor do I know what kind of
validation that IDE does.

> What he /could/ use is some advice on /how/ to refactor - something thats 
> sorely lacking in your reply.

Is it? I recommended using a validator beacuse this clearly shows which
errors still exist. And I don't see any reason to explain all the basics
of HTML from a to z and how to fix invalid code.

> And he likely also knows that HTML is not the same as PHP, but chose this 
> newsgroup as the best fit.   Giving your best "You're doing it WRONG!" 

Best fit? What about comp.infosystems.www.authoring.html?

> impression without suggesting a better alternative doesn't help him much 
> either.
> 
> Stepped outof bed with the wrong foot first maybe ?

No.



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#17888

Arno,

> And I just confirmed his question with: "Yes, you should refactor
> it to be valid HTML.".

And how should he do that please ?     Although I gave a suggestion to get 
rid of the nesting warning, you yourself mentioned its invalid HTML (is it?) 
to interleave a table and a forms that way ...

> I recommended using a validator beacuse this clearly shows
> which errors still exist.

His IDE already seems to do validation - hence the nesting warning he got. 
And as you said, /how much/ it already does is currently unknown to you.

> Best fit? What about comp.infosystems.www.authoring.html?

Thats more like it.  Next time try to do it /together with/ your "wrong 
newsgroup!" complaint.

> Which is not valid either. <form> must not be a child of <table>.
...
> It may be neccessary to do more refactoring than just moving tags
> around.

Yup.  And somehow I don't think that that is his cup of tea.

So, help him to fix his problems as he mentions them.   Perfection is a nice 
secondary goal, but should not get in the way of creating something that 
works (on most, if not all browsers).

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#17889

On 25.04.19 12:08, R.Wieser wrote:

> Arno,
> 
>> And I just confirmed his question with: "Yes, you should refactor
>> it to be valid HTML.".
> 
> And how should he do that please ?     Although I gave a suggestion to get 
> rid of the nesting warning, you yourself mentioned its invalid HTML (is it?) 
> to interleave a table and a forms that way ...

That's why I recommended using a HTML validator to see what errors there
are.

Or do you expect, that I do the refactoring myself and show Dan how a
valid version of his example looks like?

>> I recommended using a validator beacuse this clearly shows
>> which errors still exist.
> 
> His IDE already seems to do validation - hence the nesting warning he got. 
> And as you said, /how much/ it already does is currently unknown to you.

Correct - that's why I recommended something I *do* know. The
alternative would be to ask what IDE Dan uses (PHPStorm, Visual Studio
Code, Eclipse etc.) and what plugins are installed with which settings etc..

If Dan will respond that his IDE already does a full HTML validation -
fine. Then my recommendation would not do any harm anyway. But otherwise
he now knows at least one way how to validate the HTML code.

[...]
> So, help him to fix his problems as he mentions them.   Perfection is a nice 
> secondary goal, but should not get in the way of creating something that 
> works (on most, if not all browsers).

I just talk about valid HTML. This has nothing to do with "perfection".

And why do *you* complain all the time? Nothing better to do? Where is
your *working* solution for Dan's problem?


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#17893

Arno,

> That's why I recommended using a HTML validator to see what
> errors there are.

And errors always tell you what needs to be changed ?     Furthermore, he's 
trying to /adjust/ something someone else wrote, not writing it himself.

> Or do you expect, that I do the refactoring myself and
> show Dan how a valid version of his example looks like?

Well, thank you for the offer. Yes please !

... or you could give him a few /suggestions/ in regard to what he described 
ofcourse.

> Correct - that's why I recommended something I *do* know.

Sigh.  You're simply "suggesting" Dan drops what he already has in favour of 
what /you/ know.  You're giving him more work instead of less.

> I just talk about valid HTML. This has nothing to do with "perfection".

:-)   No browser I know works according to those "valid HTML" rules (they 
are much more vorgiving, as the OP already found out).   Yes, you /are/ 
trying to get to perfection there.

> And why do *you* complain all the time? Nothing better to do?
> Where is your *working* solution for Dan's problem?

Lolz.  Try reading my first reply.  It might not ascend to perfection, but 
it does fix the problem he mentioned.  Without having to redesign the PHP 
scripts logic I might add.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#17894

On 25.04.19 16:13, R.Wieser wrote:

> Arno,
[...]
>> And why do *you* complain all the time? Nothing better to do?
>> Where is your *working* solution for Dan's problem?
> 
> Lolz.  Try reading my first reply.  It might not ascend to perfection, but 
[...]

Try reading my replies in this thread - all of them!


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#17890

On 4/25/19 6:08 AM, R.Wieser wrote:
> Arno,
> 
>> And I just confirmed his question with: "Yes, you should refactor
>> it to be valid HTML.".
> 
> And how should he do that please ?     Although I gave a suggestion to get 
> rid of the nesting warning, you yourself mentioned its invalid HTML (is it?) 
> to interleave a table and a forms that way ...

I don't have the inclination to find the exact reference in the HTML
standard, but the areas defined by tags that have a start and end can
next but not overlap. In general the following is invalid:

<tag1 ><tag2> </tag1> </tag2>

There also are rules for what sort of tags are allowed to be nested
within other tags (for example things like block structure rules),
sometimes with broad rules, and sometimes very specific rules (like what
is allowed directly inside a <table> tag).
> 
>> I recommended using a validator beacuse this clearly shows
>> which errors still exist.
> 
> His IDE already seems to do validation - hence the nesting warning he got. 
> And as you said, /how much/ it already does is currently unknown to you.
> 
>> Best fit? What about comp.infosystems.www.authoring.html?
> 
> Thats more like it.  Next time try to do it /together with/ your "wrong 
> newsgroup!" complaint.
> 
>> Which is not valid either. <form> must not be a child of <table>.
> ...
>> It may be neccessary to do more refactoring than just moving tags
>> around.
> 
> Yup.  And somehow I don't think that that is his cup of tea.
> 
> So, help him to fix his problems as he mentions them.   Perfection is a nice 
> secondary goal, but should not get in the way of creating something that 
> works (on most, if not all browsers).
> 
> Regards,
> Rudy Wieser
> 
> 

Truly broken HTML, that just happens to work on a given browser is never
a good idea. It may be expedient to get something out quickly, but in my
experience will always get you later when something changes, and it
seems you never really have the time to fix it once you let it go.

Generally this sort of 'hack' is a result of poor problem definition and
using a quick and dirty tool to get something done, as opposed to taking
the time to design something right.

My first guess is that the table is being used to create page structure,
which was a common technique in years past, but be declared obsolete.
Tables are now supposed to be used only for data that is semantically a
table, not just having a visual structure of rows and columns (there is
a distinction between semantic markup and presentation markup).

[toc] | [prev] | [next] | [standalone]

#17896

Richard,

> but the areas defined by tags that have a start and
> end can next but not overlap.

Yes.  Thats pretty-much the first rule in HTML country.

> There also are rules for what sort of tags are allowed
> to be nested within other tags

True.   I've got a rule here that "body" tags are allowed as childs of "tr" 
tags.    Now if I only could get the major browsers to adopt it ... :-)

> Truly broken HTML, that just happens to work on a given
> browser is never a good idea.

"Truly broken" as opposed to "just a bit broken" ? :-p

And I agree with you there.     But between "only works on browser X, 
version Y" and "conforms to strict w3 specs" is a whole range of 
possibilities.     Going for either of the extremes will seldom be 
productive.

> Generally this sort of 'hack' is a result of poor problem definition
> and using a quick and dirty tool to get something done, as opposed
> to taking the time to design something right.

There are several possible reasons to why it has been done the way the OP 
described.   Some of them as you describe.  Some of them because some 
solutions "just work (tm)" on most of the current browsers (and their w3 
compliant counterparts would not allow it - as in the OPs case).

And do realize: the OP is trying to refactor /someone elses/ code.   He has 
to work with what he has - or stop trying to refactor stuff and go for a 
full rewrite.

> My first guess is that the table is being used to create page
> structure, which was a common technique in years past, but
> be declared obsolete.

I don't care much for stuff being called "obsolete".   It most always 
translates to "I don't like it anymore (and have found a new toy to play 
with)".    The fact that it can be /declared/ obsolete (as opposed to 
technically /becoming/ it) pretty much says it all.  :-(

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#17898

On 26.04.19 10:53, R.Wieser wrote:

> Richard,
[...]
>> My first guess is that the table is being used to create page
>> structure, which was a common technique in years past, but
>> be declared obsolete.
> 
> I don't care much for stuff being called "obsolete".   It most always 
> translates to "I don't like it anymore (and have found a new toy to play 
> with)".    The fact that it can be /declared/ obsolete (as opposed to 
> technically /becoming/ it) pretty much says it all.  :-(

The problem is, browsers *must* support most obselete code as well,
otherwise many older websites wouldn't work at all.

However this does not change the fact, that some techniques *are*
obsolete, because there *are* better ways which got introduced by HTML5,
as for example semantic elements and by CSS as for example (flex-)grids.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#17903

Arno,

> The problem is, browsers *must* support most obselete
> code as well, otherwise many older websites wouldn't work
> at all.

Bullcrap.

Yes, your conclusion is right, those websites would not work anymore.    But 
I fail to see how that would be a problem.    It could even be beneficial, 
as it would get rid of alot of non-maintained websites that way.

Besides, if non-ssl cat video (and scores of similar) sites can be pushed 
off the web than why not all those badly written websites ? (and no Google, 
thats not a suggestion :-) )

Odd though: The OP /must/ write perfect HTML, even though there is no need 
for that as all browsers still support non-perfection too.    To me that 
sounds like a waste of time and money ...

> However this does not change the fact, that some techniques
> *are* obsolete,

No, most of them are not.  Instead they have been /declared/ obsolete, which 
is quite a bit different.    The way you are wielding it makes it a 
bullshit-bingo word, used by people who just want to push their 
newest-and-shiniest toys (your three-year old expensive iPhone has become 
obsolete.  Buy our even more expensive, but effectivily just stamped with a 
new version number, iPhone in stores near you!)

Stuff can actually /become/ obsolete.  But definitily not because someone 
just declares it to be.    My old C64 for example.   I still have it and it 
still works too. I can still hook it up to my smart TV.   Getting new stuff 
for it (hardware, parts, floppies and even software) will be problematic 
though.   And /that/ is what makes it obsolete, nothing else.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#17904

On 26.04.19 11:59, R.Wieser wrote:

> Arno,
> 
>> The problem is, browsers *must* support most obselete
>> code as well, otherwise many older websites wouldn't work
>> at all.
> 
> Bullcrap.
> 
> Yes, your conclusion is right, those websites would not work anymore.    But 
> I fail to see how that would be a problem.    It could even be beneficial, 
> as it would get rid of alot of non-maintained websites that way.

The problem is that people like you come to the wrong conclusion that
obselete code is still fine to use and there is no reason at all to use
newer techniques for new websites.

> Odd though: The OP /must/ write perfect HTML, even though there is no need 
> for that as all browsers still support non-perfection too.    To me that 
> sounds like a waste of time and money ...

No, there is need for this. Because you can not make sure, that *all*
browsers including *future* version will support the invalid code the
same way. But I guess, doing constant compatibility testing with all new
browser versions to make sure that invalid HTML will be displayed as
intended is not a waste of time and money for you.

Did you ever do a website or a web based application professionally?



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#17928

Richard Damon wrote:

> On 4/25/19 6:08 AM, R.Wieser wrote:
>>> And I just confirmed his question with: "Yes, you should refactor
>>> it to be valid HTML.".
>> 
>> And how should he do that please ?     Although I gave a suggestion to
>> get rid of the nesting warning, you yourself mentioned its invalid HTML
>> (is it?) to interleave a table and a forms that way ...
> 
> I don't have the inclination to find the exact reference in the HTML
> standard, but the areas defined by tags that have a start and end can
> next but not overlap. In general the following is invalid:
> 
> <tag1 ><tag2> </tag1> </tag2>

While the conclusion is correct, the explanation leading up to it is close 
to gibberish.  (“next” 	is a preposition, not a verb.  Things cannot “next”; 
they can _be_ next/adjacent _to each other_.)

“<tag1>…</tag1>” is a “tag1” _element_ with (written) start-tag “<tag1>” and 
end-tag “</tag1>”.

Elements cannot overlap, i.e. one element cannot end after another element 
has been started and not been ended.  However, there are element types where 
the end-tag is optional; those elements end automatically when the start-tag 
of an allowed element that cannot be contained in the first element is 
encountered or the end tag of another element type is encountered.  Example:

  <ul>
    <li>foo
    <li>bar
  </ul>

is a valid HTML fragment because “li” elements cannot be child elements of 
“li” elements (only of “ol” or “ul” elements) and the end-tag of “li” 
elements is optional.
 
> There also are rules for what sort of tags are allowed to be nested
> within other tags (for example things like block structure rules),
> sometimes with broad rules, and sometimes very specific rules (like what
> is allowed directly inside a <table> tag).

There are no “block structure rules”.

The rules are instead about which element _types_ may contain which other 
element _types_.  The rules are defined by a HTML DTD or the prose of the 
HTML specification.

<https://validator.w3.org/>
<https://www.w3.org/TR/html>

> My first guess is that the table is being used to create page structure,
> which was a common technique in years past, but be declared obsolete.

By whom?

> Tables are now supposed to be used only for data that is semantically a
> table,

This does apply to most forms where you have a label, which is the heading, 
and you have a form control, which is the data associated with that heading.

> not just having a visual structure of rows and columns (there is
> a distinction between semantic markup and presentation markup).

Yes, but it is proper and semantic markup to use tables in forms as long as 
they are serializable.  Using a “table” element has the advantage that it 
works everywhere, even in a text browser, and CSS can be used so that tables 
are displayed differently depending on the available viewport size.

The problem posted in the Subject (which does not have anything to do with 
PHP) can be solved by not having several “form” elements where each form 
contains a table of controls, but one “form“ element which may contain 
several tables.  Note that having one large table is usually rendered more 
slowly than having several tables that are just styled the same way.
 
-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#17884

Dan,

> The funny thing is, it runs fine.  The Browser doesn't complain
> about it, although my IDE complains (appropriately, imo) of
> nesting issues.

Have you tried (looking at the example you posted) to move the FORM tag from 
just above the TABLE tag to just below it (just infront of the TR tag) ?

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#17887

On 25.04.19 09:49, R.Wieser wrote:

> Dan,
> 
>> The funny thing is, it runs fine.  The Browser doesn't complain
>> about it, although my IDE complains (appropriately, imo) of
>> nesting issues.
> 
> Have you tried (looking at the example you posted) to move the FORM tag from 
> just above the TABLE tag to just below it (just infront of the TR tag) ?

Which is not valid either. <form> must not be a child of <table>.

See:

<https://www.w3.org/TR/html52/tabular-data.html#the-table-element>
<https://developer.mozilla.org/en-US/docs/Web/HTML/Element/table>

That's why I recommended using a HTML validator to check the result.
Just because elements are properly nested it does not mean that it's
valid HTML.

It may be neccessary to do more refactoring than just moving tags around.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#17891

On 25.04.19 11:06, Arno Welzel wrote:

> On 25.04.19 09:49, R.Wieser wrote:
> 
>> Dan,
>>
>>> The funny thing is, it runs fine.  The Browser doesn't complain
>>> about it, although my IDE complains (appropriately, imo) of
>>> nesting issues.
>>
>> Have you tried (looking at the example you posted) to move the FORM tag from 
>> just above the TABLE tag to just below it (just infront of the TR tag) ?
> 
> Which is not valid either. <form> must not be a child of <table>.
> 
> See:
> 
> <https://www.w3.org/TR/html52/tabular-data.html#the-table-element>
> <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/table>
> 
> That's why I recommended using a HTML validator to check the result.
> Just because elements are properly nested it does not mean that it's
> valid HTML.
> 
> It may be neccessary to do more refactoring than just moving tags around.

And for the sake of peace with R. Wieser who believes, it don't know,
what I'm talking about - a more specific example, how it *could* be:

1) Never put a <form> as a child of <table> itself - this is not allowed
and procudes invalid HTML

2) Never interleave tags

So the a simplified example for the code fragment *could* be like this:

<div id="main">
  <div class="container">

    <!-- first form here with a table *inside* -->

    <form class="xxxx" action="xxxx.php" method="post">
      <table width="100%">

        <!-- all the content for this form here -->

      </table>
    </form>

    <!-- second form here with another table *inside* -->

    <form class="xxxx" action="xxxxxx.php" method="post">
      <table width="100%">

        <!-- all the content for this form here -->

      </table>
    </form>

   </div>
</div>

Personally I would redesign the whole thing and not use TABLE at all but
 DIV elements only CSS grids or bootstrap. These could be responsive as
well, if needed.



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#17892

On Thursday, April 25, 2019 at 8:09:06 AM UTC-4, Arno Welzel wrote:
> On 25.04.19 11:06, Arno Welzel wrote:
> 
> > On 25.04.19 09:49, R.Wieser wrote:
> > 
> >> Dan,
> >>
> >>> The funny thing is, it runs fine.  The Browser doesn't complain
> >>> about it, although my IDE complains (appropriately, imo) of
> >>> nesting issues.
> >>
> >> Have you tried (looking at the example you posted) to move the FORM tag from 
> >> just above the TABLE tag to just below it (just infront of the TR tag) ?
> > 
> > Which is not valid either. <form> must not be a child of <table>.
> > 
> > See:
> > 
> > <https://www.w3.org/TR/html52/tabular-data.html#the-table-element>
> > <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/table>
> > 
> > That's why I recommended using a HTML validator to check the result.
> > Just because elements are properly nested it does not mean that it's
> > valid HTML.
> > 
> > It may be neccessary to do more refactoring than just moving tags around.
> 
> And for the sake of peace with R. Wieser who believes, it don't know,
> what I'm talking about - a more specific example, how it *could* be:
> 
> 1) Never put a <form> as a child of <table> itself - this is not allowed
> and procudes invalid HTML
> 
> 2) Never interleave tags
> 
> So the a simplified example for the code fragment *could* be like this:
> 
> <div id="main">
>   <div class="container">
> 
>     <!-- first form here with a table *inside* -->
> 
>     <form class="xxxx" action="xxxx.php" method="post">
>       <table width="100%">
> 
>         <!-- all the content for this form here -->
> 
>       </table>
>     </form>
> 
>     <!-- second form here with another table *inside* -->
> 
>     <form class="xxxx" action="xxxxxx.php" method="post">
>       <table width="100%">
> 
>         <!-- all the content for this form here -->
> 
>       </table>
>     </form>
> 
>    </div>
> </div>
> 
> Personally I would redesign the whole thing and not use TABLE at all but
>  DIV elements only CSS grids or bootstrap. These could be responsive as
> well, if needed.
> 
> 
> 
> -- 
> Arno Welzel
> https://arnowelzel.de


Thanks, Arno and R. Weiser.  I've refactored the whole thing, that wasn't a problem.  I was just trying to find out if extending a table across multiple forms is some kind of allowed exception to normal practices.

Everything is working fine.

Roger on the Divs and Bootstrap, Arno.  Deadline for this is a couple of days from now.  But I'll revisit, if they give me a chance.

[toc] | [prev] | [next] | [standalone]

#17900

Dan,

>  I was just trying to find out if extending a table across multiple
> forms is some kind of allowed exception to normal practices.

As shown by Arno and me, that fully depends on the definition of "normal 
practices".    His approach is a theoretical one, while mine is a bit more 
pragmatic.

According to W3 it is not allowed.   But (as already proven by your 
pre-refactoring webpage) it works on most major browsers (a "guess" I can 
hazard, otherwise your question would have been rather different).

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#17902

On 26.04.19 11:20, R.Wieser wrote:

> Dan,
> 
>>  I was just trying to find out if extending a table across multiple
>> forms is some kind of allowed exception to normal practices.
> 
> As shown by Arno and me, that fully depends on the definition of "normal 
> practices".    His approach is a theoretical one, while mine is a bit more 
> pragmatic.
> 
> According to W3 it is not allowed.   But (as already proven by your 
> pre-refactoring webpage) it works on most major browsers (a "guess" I can 
> hazard, otherwise your question would have been rather different).

This is not a matter of personal taste or "theoretical approach". HTML
is a technical standard. The fact that browser try to cope with invalid
documents does not mean that this is a good practice which should not be
avoided.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web