Form action= ?

Discussion in 'HTML' started by shajnday, Aug 13, 2010.

  1. shajnday

    shajnday Guest

    What would form action do?

    I had an html tag <form><input .... without the requested atributes
    action (and .ev.method="").
    This tag is working fine but due to restrictions of XHTML transitional
    validation i had to change it to <form action="#"><input..... />
    </form>

    and it works as it worked before, but now it passes HTML validation.

    What is the best to put at action="" atribute and method and what's
    the puropeses of these two atributes ?
    i don't get the purpose part. ?


    :)
    shajnday, Aug 13, 2010
    #1
    1. Advertising

  2. On 13/08/10 12:38, shajnday wrote:
    > What would form action do?
    >
    > I had an html tag <form><input .... without the requested atributes
    > action (and .ev.method="").
    > This tag is working fine but due to restrictions of XHTML transitional
    > validation i had to change it to <form action="#"><input..... />
    > </form>
    >
    > and it works as it worked before, but now it passes HTML validation.
    >
    > What is the best to put at action="" atribute and method and what's
    > the puropeses of these two atributes ?
    > i don't get the purpose part. ?


    If your form doesn't have an action (ie it's just a wrapper for input /
    textarea / select elements) then why are you using form? You can
    dispense with it, as the following shows (validates as direct input with
    a charset warning).

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>Test</title>
    <script type="text/javascript">
    function clicked(obj)
    {
    alert(obj.name + " " + obj.id + " " + obj.value);
    }
    </script>
    </head>
    <body>
    <p>
    <input type="text" name="t1" id="t1" size="30"><br>
    <select name="s1" id="s1">
    <option value="1">one</option>
    <option value="2">two</option>
    <option value="3">three</option>
    </select><br>
    <textarea name="a1" id="a1" rows="5" cols="80"></textarea><br>
    <input type="button" id="b1" name="b1" value="Reset"
    onclick="clicked(this)">
    <input type="button" id="b2" name="b2" value="Submit"
    onclick="clicked(this)">
    </p>
    </body>
    </html>

    If you want input / reset buttons with onclicks to drive your
    javascript, just use normal buttons with the values set to "Reset" and /
    or "Submit" and use their onclick handlers instead. If you're using the
    form name to refer to elements, switch to document.getElementById().

    Rgds

    Denis McMahon
    Denis McMahon, Aug 13, 2010
    #2
    1. Advertising

  3. Denis McMahon wrote:
    > If your form doesn't have an action (ie it's just a wrapper for input /
    > textarea / select elements) then why are you using form? You can
    > dispense with it, as the following shows (validates as direct input with
    > a charset warning).


    Well not necessarily, it all depends on that the OP is doing with these
    controls.

    If all you are doing using controls to interact with some JavaScript,
    then yes you can dispense with the form element. But if the OP intends
    to submit data either via GET or POST then:

    A form element *is* required
    The the controls must be inside form element
    The controls must have name attributes
    The form must have a valid action attribute

    See <www.w3.org/TR/html401/interact/forms.html#successful-controls>

    Browsers will summit a form to the URI of the current document if the
    action attribute is not default, but they are not obligated to because
    the condition is "undefined" See that action is a required
    attribute with a valid URI else the condition is "undefined" under
    "Attribute Definitions"

    <http://www.w3.org/TR/html401/interact/forms.html#edef-FORM>


    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Aug 13, 2010
    #3
  4. On 13/08/10 18:51, Jonathan N. Little wrote:
    > Denis McMahon wrote:


    > If all you are doing using controls to interact with some JavaScript,
    > then yes you can dispense with the form element. But if the OP intends
    > to submit data either via GET or POST then:


    The whole point of the OPs post, as I understood it, was to find some
    pseudo-value to use for the action field so that the html would
    validate, that kind of suggests to me that he's not actually submitting
    the form.

    Because if he was actually submitting the form, I'd expect him to have a
    real action value and not need some pseudo-value to get the page to
    validate.

    Rgds

    Denis McMahon
    Denis McMahon, Aug 13, 2010
    #4
  5. shajnday

    dorayme Guest

    In article <4c658c88$0$10277$>,
    Denis McMahon <> wrote:

    > On 13/08/10 18:51, Jonathan N. Little wrote:
    > > Denis McMahon wrote:

    >
    > > If all you are doing using controls to interact with some JavaScript,
    > > then yes you can dispense with the form element. But if the OP intends
    > > to submit data either via GET or POST then:

    >
    > The whole point of the OPs post, as I understood it, was to find some
    > pseudo-value to use for the action field so that the html would
    > validate, that kind of suggests to me that he's not actually submitting
    > the form.
    >


    Possibly, but he might be just testing or making a template and
    feels uncomfortable with it lazily lying about invalid.


    > Because if he was actually submitting the form, I'd expect him to have a
    > real action value and not need some pseudo-value to get the page to
    > validate.
    >


    --
    dorayme
    dorayme, Aug 14, 2010
    #5
  6. shajnday

    William Gill Guest

    On 8/13/2010 2:18 PM, Denis McMahon wrote:
    > The whole point of the OPs post, as I understood it, was to find some
    > pseudo-value to use for the action field so that the html would
    > validate, that kind of suggests to me that he's not actually submitting
    > the form.


    I suspect the OP, and many others have a misconception of what exactly
    validation is.

    I'm sure Yucca will correct me if I misstate it, but validation checks
    that a document conforms precisely to the structure defined by a
    particular DTD. Much like a spell checker validates that words in a
    document conform to a particular dictionary. So if I use a term that
    means something to an audience, but not necessarily to the dictionary
    (i.e. fubar = f'ed up beyond all recognition), the spell checker will
    point out the "validation error." At that point I can add fubar to the
    dictionary, or recognize the "error" is deliberate and ignore it.
    Similarly, when validating against a particular DTD, and I get a
    validation error that was deliberate, I can ignore it or create a
    modified version of the DTD that matches the variation. The inherent
    risk is that if I leave the "error" in the document, then ask an
    application (i.e. a browser) that relies on the original DTD (or even my
    modified version) to parse the document I don't know how it will react
    to the non-conforming entry, and how it reacts today may not be how it
    will react after the next update.

    The value of validation is finding all the unintentional deviations.
    William Gill, Aug 14, 2010
    #6
  7. shajnday

    shajnday Guest

    On 14 kol, 01:23, William Gill <> wrote:
    > On 8/13/2010 2:18 PM, Denis McMahon wrote:
    >
    > > The whole point of the OPs post, as I understood it, was to find some
    > > pseudo-value to use for the action field so that the html would
    > > validate, that kind of suggests to me that he's not actually submitting
    > > the form.

    >
    > I suspect the OP, and many others have a misconception of what exactly
    > validation is.
    >
    > I'm sure Yucca will correct me if I misstate it, but validation checks
    > that a document conforms precisely to the structure defined by a
    > particular DTD.  Much like a spell checker validates that words in a
    > document conform to a particular dictionary.  So if I use a term that
    > means something to an audience, but not necessarily to the dictionary
    > (i.e. fubar = f'ed up beyond all recognition), the spell checker will
    > point out the "validation error."  At that point I can add fubar to the
    > dictionary, or recognize the "error" is deliberate and ignore it.
    > Similarly, when validating against a particular DTD, and I get a
    > validation error that was deliberate, I can ignore it or create a
    > modified version of the DTD that matches the variation.  The inherent
    > risk is that if I leave the "error" in the document, then ask an
    > application (i.e. a browser) that relies on the original DTD (or even my
    > modified version) to parse the document I don't know how it will react
    > to the non-conforming entry, and how it reacts today may not be how it
    > will react after the next update.
    >
    > The value of validation is finding all the unintentional deviations.




    I have put astray the form element as i have thought that it is the
    necessary block element in which goes input...
    As i had thought that the form element is a process element of some
    kind and that it does some important actions so as when submitting
    button to print or to close a page. I checked(what previously did not
    came to my mind) and left only the input element and it works the
    same. Validation shows pass!

    One another thing was strange which made me to leave the form element
    at first, when i submited the close button i sometimes got the "Are
    you sure you want to close this window?"question, for which i had
    thoughts that is the action of form element.

    I don't receive this question anymore, i think it's a browser inner
    action at some point to trigger it...
    shajnday, Aug 14, 2010
    #7
  8. shajnday

    shajnday Guest

    On 14 kol, 21:01, shajnday <> wrote:
    > On 14 kol, 01:23, William Gill <> wrote:
    >
    >
    >
    >
    >
    > > On 8/13/2010 2:18 PM, Denis McMahon wrote:

    >
    > > > The whole point of the OPs post, as I understood it, was to find some
    > > > pseudo-value to use for the action field so that the html would
    > > > validate, that kind of suggests to me that he's not actually submitting
    > > > the form.

    >
    > > I suspect the OP, and many others have a misconception of what exactly
    > > validation is.

    >
    > > I'm sure Yucca will correct me if I misstate it, but validation checks
    > > that a document conforms precisely to the structure defined by a
    > > particular DTD.  Much like a spell checker validates that words in a
    > > document conform to a particular dictionary.  So if I use a term that
    > > means something to an audience, but not necessarily to the dictionary
    > > (i.e. fubar = f'ed up beyond all recognition), the spell checker will
    > > point out the "validation error."  At that point I can add fubar to the
    > > dictionary, or recognize the "error" is deliberate and ignore it.
    > > Similarly, when validating against a particular DTD, and I get a
    > > validation error that was deliberate, I can ignore it or create a
    > > modified version of the DTD that matches the variation.  The inherent
    > > risk is that if I leave the "error" in the document, then ask an
    > > application (i.e. a browser) that relies on the original DTD (or even my
    > > modified version) to parse the document I don't know how it will react
    > > to the non-conforming entry, and how it reacts today may not be how it
    > > will react after the next update.

    >
    > > The value of validation is finding all the unintentional deviations.

    >
    > I have put astray the form element as i have thought that it is the
    > necessary block element in which goes input...
    > As i had thought that the form element is a process element of some
    > kind and that it does some important actions so as when submitting
    > button to print or to close a page. I checked(what previously did not
    > came to my mind) and left only the input element and it works the
    > same. Validation shows pass!
    >
    > One another thing was strange which made me to leave the form element
    > at first, when i submited the close button i sometimes got the "Are
    > you sure you want to close this window?"question, for which i had
    > thoughts that is the action of form element.
    >
    > I don't receive this question anymore, i think it's a browser inner
    > action at some point to trigger it...- Sakrij citirani tekst -
    >
    > - Prikaži citirani tekst -



    Yeah,
    Thanks for that mr.Gill,
    I did learned that.
    I do have a lot of warnings but the page is fully functional in three
    most exposed browsers and it is showed the very same, and i'am happy
    about that. Not that i don't like validation buttons as they do look
    great on the page, but it's only an aestehetic appendix.
    As the knowledge tree is growing so i make valuations what is worth to
    leave, and what is worth to rewrite or fix. Sometimes things jump from
    byitself in front of me but i enjoy in it, everything is cheerful and
    fun at my place.
    Thanks for precious advice though.
    shajnday, Aug 14, 2010
    #8
  9. William Gill wrote:

    > Similarly, when validating against a particular DTD, and I get a
    > validation error that was deliberate, I can ignore it or create a
    > modified version of the DTD that matches the variation.


    Indeed. But many people want to validate due to some external requirement.
    They don't understand the reasons for the requirement (maybe there isn't
    one), and they don't even understand the content of the requirement; they
    just want to "pass validation", or get a "clean report".

    If the requirement really means that you must "validate against HTML 4.01",
    then you just cannot have a <form> element without an action attribute. You
    can use a fake value there (since validation does not check the attribute
    value at all, except for some minor formalities), or you can dispense with a
    <form> element if your form fields are purely JavaScript-driven (and then
    you have an accessibility issue, but that's a completely different
    perspective).

    > The inherent
    > risk is that if I leave the "error" in the document, then ask an
    > application (i.e. a browser) that relies on the original DTD (or even
    > my modified version) to parse the document I don't know how it will
    > react to the non-conforming entry,


    Theoretically yes, but in practice, browsers don't use DTDs. Some browsers
    have validation add-ons, but they don't affect the rendering.

    The risk is that you are using an element, or an attribute, or a syntax of
    an element that won't be supported by all browsers. People say that HTML
    4.01 DTDs reflect the constructs that browsers actually support, but this is
    just partly true. There are HTML 4.01 features that aren't supported at all,
    or aren't supported by very commonly used browsers. And there are features
    that are virtually universally supported but not part of HTML 4.01.

    > The value of validation is finding all the unintentional deviations.


    Right - it is meant to protect against typos and similar mistakes.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Jukka K. Korpela, Aug 14, 2010
    #9
  10. shajnday

    William Gill Guest

    On 8/14/2010 3:38 PM, Jukka K. Korpela wrote:
    >
    > Indeed. But many people want to validate due to some external
    > requirement. They don't understand the reasons for the requirement
    > (maybe there isn't one), and they don't even understand the content of
    > the requirement; they just want to "pass validation", or get a "clean
    > report".


    As I have observed many times over the years "There is no reason. It's
    just policy."

    Most likely someone implemented the requirement as a metric, without
    understanding any of the implications. Similar to "lines of code per
    day" as a metric for programmers.

    > Theoretically yes, but in practice, browsers don't use DTDs. Some
    > browsers have validation add-ons, but they don't affect the rendering.


    I didn't really expect that browsers used DTDs in real time, but I would
    guess that programmers use them when they are designing the code, even
    if not when the code is run.
    William Gill, Aug 15, 2010
    #10
  11. shajnday

    Neredbojias Guest

    On 14 Aug 2010, William Gill <> wrote:

    > On 8/14/2010 3:38 PM, Jukka K. Korpela wrote:
    >>
    >> Indeed. But many people want to validate due to some external
    >> requirement. They don't understand the reasons for the requirement
    >> (maybe there isn't one), and they don't even understand the content
    >> of the requirement; they just want to "pass validation", or get a
    >> "clean report".

    >
    > As I have observed many times over the years "There is no reason.
    > It's just policy."
    >
    > Most likely someone implemented the requirement as a metric, without
    > understanding any of the implications. Similar to "lines of code per
    > day" as a metric for programmers.
    >
    >> Theoretically yes, but in practice, browsers don't use DTDs. Some
    >> browsers have validation add-ons, but they don't affect the
    >> rendering.

    >
    > I didn't really expect that browsers used DTDs in real time, but I
    > would guess that programmers use them when they are designing the
    > code, even if not when the code is run.


    If browsers didn't use dtds, there would be absolutely no point in
    putting one in an html page and that isn't the case. Browsers may not
    use dtds as intended or to the fullest extent, but they do use them. I
    hope you and Jukka do not propagate yet another html myth.

    --
    Neredbojias

    http://www.neredbojias.org/
    http://www.neredbojias.net/
    Neredbojias, Aug 15, 2010
    #11
  12. Neredbojias wrote:

    > If browsers didn't use dtds, there would be absolutely no point in
    > putting one in an html page and that isn't the case.


    There is no point in putting a DTD in an HTML page. Try it, and you will see
    that browsers can get very wild.

    > Browsers may not
    > use dtds as intended or to the fullest extent, but they do use them.


    Prove it. Provide any evidence of a browser actually even _reading_ a DTD.

    (My guess is that you have confused a DTD with a DOCTYPE declaration.
    Browsers do "use" DOCTYPE declarations, in their wild guesswork on whether
    the authors wants the page to be shown in a very broken mode, a somewhat
    broken mode, or in "standards" mode which is not intentionally broken, or at
    least they say so. This has absolutely nothing to do with using a DTD. It is
    just a play on DOCTYPE declarations as strings, as if they were magic
    incantations.)

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Jukka K. Korpela, Aug 15, 2010
    #12
  13. shajnday

    William Gill Guest

    On 8/15/2010 5:16 AM, Neredbojias wrote:
    >
    > If browsers didn't use dtds, there would be absolutely no point in
    > putting one in an html page and that isn't the case. Browsers may not
    > use dtds as intended or to the fullest extent, but they do use them. I
    > hope you and Jukka do not propagate yet another html myth.
    >


    I will try to express this so that even you parse it correctly. I will
    try not to use big words, or concepts so as to not confuse, and so that
    your somewhat limited parser will be able to validate.

    A DTD (document type definition) describes the precise structure a
    conforming document must follow. Think of it as the rules. In theory
    every document could have a unique set of rules (DTD), but so long as
    they are publicly available a parser (for this discussion we are talking
    about a browser) could obtain the rules and parse each document
    dynamically. Coding such a parser would be a monumental task. In
    reality a limited number of DTDs have been agreed to as "standard." So
    when a programmer writes the code to parse documents, he has copies of
    all the appropriate rules handy, and codes (in most cases) accordingly.
    It is not necessary for the browser to read the rules for each
    document as it is parsed, since it is assumed that neither the rules nor
    the browser's own code have changed. In a sense the browser doesn't
    "use" the DTD, it has it incorporated into its own code. However, since
    there are several "standards" in use, the browser must decide which
    branch of its own code to follow. I haven't coded any browsers, but
    they appear to use the DOCTYPE declaration for this, and though it
    could, it doesn't retrieve the DTD with each request, because the DTD is
    of no use to the browser anymore since it cannot rewrite its own code to
    accommodate the DTD if it had changed.

    So when you parse the term "use" in this context, is anything Yucca, or
    I have said invalid?

    Try it for yourself. Start with a simple valid HTML document and view
    it w/Firefox web developer toolbar. Does it indicate standards compliant
    mode? Now start editing the DOCTYPE declaration to see how you can get
    it to switch to quirks mode.
    William Gill, Aug 15, 2010
    #13
  14. William Gill wrote:

    > A DTD (document type definition) describes the precise structure a
    > conforming document must follow.


    To the extent it can, yes. The formalism used in DTDs is pretty limited, and
    it cannot express all syntactic requirements.

    > In theory
    > every document could have a unique set of rules (DTD), but so long as
    > they are publicly available a parser (for this discussion we are
    > talking about a browser) could obtain the rules and parse each
    > document dynamically. Coding such a parser would be a monumental
    > task.


    Not really monumental, though considerable effort. Such parsers (generic
    SGML parsers) existed long before HTML was invented. People who wrote
    browsers just decided not to use them.

    > In a sense the browser
    > doesn't "use" the DTD, it has it incorporated into its own code.


    It doesn't use a DTD at all. And it's the other way around: DTDs in HTML
    recommendations have more or less been retrofitted to describe, partly
    incorrectly or inexactly, what browsers generally deal with, or can be
    expected to deal with. Browsers tend to be much more permissive than they
    would if the used DTDs, but roughly speaking, when you deviate considerably
    from HTML recommendations in your document, browsers will often be
    permissive _in different ways_.

    > However, since there are several "standards" in use, the browser must
    > decide which branch of its own code to follow.


    No, they don't do such things. Each browser uses its built-in browser.

    > I haven't coded any
    > browsers, but they appear to use the DOCTYPE declaration for this,


    No, they use that declaration to make a choice between _rendering modes_.
    Parsing is not affected at all, even in cases where some markup is not
    honored in some mode. For example, when IE 8 refuses, in "standards" mode,
    to use the line breaking opportunities suggested by <wbr> markup
    (nonstandard but widely supported tag), this hardly happens due to any
    difference in parsing. Rather, the browser parses the tag as usual, then
    just ignores it.

    > and though it could, it doesn't retrieve the DTD with each request,


    They don't retrieve it at all.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Jukka K. Korpela, Aug 15, 2010
    #14
  15. shajnday

    Neredbojias Guest

    On 15 Aug 2010, "Jukka K. Korpela" <> wrote:

    > Neredbojias wrote:
    >
    >> If browsers didn't use dtds, there would be absolutely no point in
    >> putting one in an html page and that isn't the case.

    >
    > There is no point in putting a DTD in an HTML page. Try it, and you
    > will see that browsers can get very wild.
    >
    >> Browsers may not
    >> use dtds as intended or to the fullest extent, but they do use them.

    >
    > Prove it. Provide any evidence of a browser actually even _reading_ a
    > DTD.
    >
    > (My guess is that you have confused a DTD with a DOCTYPE declaration.
    > Browsers do "use" DOCTYPE declarations, in their wild guesswork on
    > whether the authors wants the page to be shown in a very broken mode,
    > a somewhat broken mode, or in "standards" mode which is not
    > intentionally broken, or at least they say so. This has absolutely
    > nothing to do with using a DTD. It is just a play on DOCTYPE
    > declarations as strings, as if they were magic incantations.)


    Um, yes, you're right. Well, -half right. Over on this side of the
    Atlantic, "dtd" is commonly used to refer to the Doctype _Declaration_
    as well as the Doctype _Definition_. Whether this is technically
    correct or not I don't know but it certainly is more commonplace than
    the latter. Anyway, I did mean Doctype _Declaration_, and since your
    posts were unspecific about the issue in general, I thought you did,
    too.

    --
    Neredbojias

    http://www.neredbojias.org/
    http://www.neredbojias.net/
    Neredbojias, Aug 16, 2010
    #15
  16. shajnday

    Neredbojias Guest

    On 15 Aug 2010, William Gill <> wrote:

    > On 8/15/2010 5:16 AM, Neredbojias wrote:
    >>
    >> If browsers didn't use dtds, there would be absolutely no point in
    >> putting one in an html page and that isn't the case. Browsers may
    >> not use dtds as intended or to the fullest extent, but they do use
    >> them. I hope you and Jukka do not propagate yet another html myth.
    >>

    >
    > I will try to express this so that even you parse it correctly. I
    > will try not to use big words, or concepts so as to not confuse, and
    > so that your somewhat limited parser will be able to validate.


    Ha ha, pretty funny, Willie. However, I don't parse, I think. But
    macht nicht for now because I'll admit I was a bit snide, too (-though
    it was with a smile and a wink.)

    > A DTD (document type definition) describes the precise structure a
    > conforming document must follow. Think of it as the rules. In theory
    > every document could have a unique set of rules (DTD), but so long as
    > they are publicly available a parser (for this discussion we are
    > talking about a browser) could obtain the rules and parse each
    > document dynamically. Coding such a parser would be a monumental
    > task. In reality a limited number of DTDs have been agreed to as
    > "standard." So when a programmer writes the code to parse documents,
    > he has copies of all the appropriate rules handy, and codes (in most
    > cases) accordingly.
    > It is not necessary for the browser to read the rules for each
    > document as it is parsed, since it is assumed that neither the rules
    > nor the browser's own code have changed. In a sense the browser
    > doesn't "use" the DTD, it has it incorporated into its own code.
    > However, since there are several "standards" in use, the browser must
    > decide which branch of its own code to follow. I haven't coded any
    > browsers, but they appear to use the DOCTYPE declaration for this,
    > and though it could, it doesn't retrieve the DTD with each request,
    > because the DTD is of no use to the browser anymore since it cannot
    > rewrite its own code to accommodate the DTD if it had changed.
    >
    > So when you parse the term "use" in this context, is anything Yucca,
    > or I have said invalid?


    As I informed Yukka, his imprecision as to what he actually meant by
    "dtd" was the cause of the mix-up.

    > Try it for yourself. Start with a simple valid HTML document and
    > view it w/Firefox web developer toolbar. Does it indicate standards
    > compliant mode? Now start editing the DOCTYPE declaration to see
    > how you can get it to switch to quirks mode.


    Well, it used to be by removing the link. Html5's doctype is simply
    <!DOCTYPE html> so I would guess that no longer applies and you could
    have anything after the "html" for validity.

    --
    Neredbojias

    http://www.neredbojias.org/
    http://www.neredbojias.net/
    Neredbojias, Aug 16, 2010
    #16
  17. On 14 Aug, 00:23, William Gill <> wrote:
    > and how it reacts today may not be how it
    > will react after the next update.

    Sadly that is true of all updates, even where your script may be
    valid. Microsoft have many products that specialise in this.
    Captain Paralytic, Aug 16, 2010
    #17
  18. Neredbojias wrote:

    > As I informed Yukka, his imprecision as to what he actually meant by
    > "dtd" was the cause of the mix-up.


    There was no imprecision, in what I wrote, or in what you wrote. "DTD" is a
    technical term, and I used it in its correct meaning. Your statement
    involving it was incorrect; it was pointless to try to explain that on your
    side of the pond, others get this wrong too.

    You were not imprecise in your statements about the significance of DTDs to
    browsers. Just completely wrong. This is actually simpler than being just
    half right would have been, since you just need to abandon your old idea and
    get the new one, instead of modifying the old one.

    The difference between a DTD and a DOCTYPE declaration is not just a matter
    of terms, but even if it were, you would still be wrong in playing with
    technical terms and not knowing their defined meanings, or not caring about
    them.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Jukka K. Korpela, Aug 16, 2010
    #18
  19. shajnday

    shajnday Guest

    On 16 kol, 16:12, "Jukka K. Korpela" <> wrote:
    > Neredbojias wrote:
    > > As I informed Yukka, his imprecision as to what he actually meant by
    > > "dtd" was the cause of the mix-up.

    >
    > There was no imprecision, in what I wrote, or in what you wrote. "DTD" is a
    > technical term, and I used it in its correct meaning. Your statement
    > involving it was incorrect; it was pointless to try to explain that on your
    > side of the pond, others get this wrong too.
    >
    > You were not imprecise in your statements about the significance of DTDs to
    > browsers. Just completely wrong. This is actually simpler than being just
    > half right would have been, since you just need to abandon your old idea and
    > get the new one, instead of modifying the old one.
    >
    > The difference between a DTD and a DOCTYPE declaration is not just a matter
    > of terms, but even if it were, you would still be wrong in playing with
    > technical terms and not knowing their defined meanings, or not caring about
    > them.
    >
    > --
    > Yucca,http://www.cs.tut.fi/~jkorpela/



    tutto completo.
    shajnday, Aug 16, 2010
    #19
  20. shajnday

    William Gill Guest

    On 8/16/2010 3:05 AM, Neredbojias wrote:
    > Ha ha, pretty funny, Willie. However, I don't parse, I think.

    Ah! That was your first mistake. Better you should leave that thinking
    stuff to people who are qualified. <G>

    BTW I should have indicated my previous jab was intended to be in good
    spirit.
    William Gill, Aug 16, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Joe Bloggs
    Replies:
    1
    Views:
    752
    Sudsy
    Aug 3, 2003
  2. rjweytens
    Replies:
    6
    Views:
    16,085
    rjweytens
    Jun 25, 2004
  3. runescience

    Struts mapping action to action???

    runescience, Feb 6, 2006, in forum: Java
    Replies:
    3
    Views:
    1,820
    runescience
    Feb 7, 2006
  4. vyshu
    Replies:
    1
    Views:
    2,548
    Richard Senior
    Apr 27, 2007
  5. John
    Replies:
    0
    Views:
    860
Loading...

Share This Page