SitePoint Sponsor

User Tag List

Results 1 to 24 of 24
  1. #1
    SitePoint Evangelist
    Join Date
    Aug 2005
    Posts
    574
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Having trouble getting XHTML 1.0 Strict to validate

    Hi,

    I'm using XHTML 1.0 Strict for a site redesign. I'm having trouble getting it to validate and most of the errors are about this code that I copied from Google for a Google search box:


    Code:
      <div id="search"> 
      	<!-- Google CSE Search Box Begins  -->
    	<form id="searchbox_001039391038114845130:hjdg0ismp6u" action="http://www.susanlitton.com/search.html">
    		<input type="hidden" name="cx" value="001039391038114845130:hjdg0ismp6u" />
    		<input type="hidden" name="cof" value="FORID:9" />
    		<input name="q" type="text" size="30" />
    		<input type="submit" name="sa" value="Search" />
    	</form>
    <script type="text/javascript" src="http://www.google.com/coop/cse/brand?form=searchbox_001039391038114845130%3Ahjdg0ismp6u"></script>
    	<!-- Google CSE Search Box Ends -->  
     </div>
    The errors I'm getting are below:

    # Error Line 54 column 80: document type does not allow element "input" here; missing one of "p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre", "address", "fieldset", "ins", "del" start-tag.

    ..."001039391038114845130:hjdg0ismp6u" />

    The mentioned element is not allowed to appear in the context in which you've placed it; the other mentioned elements are the only ones that are both allowed there and can contain the element mentioned. This might mean that you need a containing element, or possibly that you've forgotten to close a previous element.

    One possible cause for this message is that you have attempted to put a block-level element (such as "<p>" or "<table>") inside an inline element (such as "<a>", "<span>", or "<font>").


    # Error Line 55 column 55: document type does not allow element "input" here; missing one of "p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre", "address", "fieldset", "ins", "del" start-tag.

    <input type="hidden" name="cof" value="FORID:9" />


    # Error Line 56 column 45: document type does not allow element "input" here; missing one of "p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre", "address", "fieldset", "ins", "del" start-tag.

    <input name="q" type="text" size="30" />


    # Error Line 57 column 53: document type does not allow element "input" here; missing one of "p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre", "address", "fieldset", "ins", "del" start-tag.

    <input type="submit" name="sa" value="Search" />
    Any ideas on what's causing this and how to fix it?

  2. #2
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,804
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    You need a wrapper around the form content inside of the form tag. Either add a <fieldset> or <div> tag immediately after the <form> tag along with a corresponding closing tag just before the form close tag.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  3. #3
    SitePoint Wizard drhowarddrfine's Avatar
    Join Date
    Aug 2005
    Posts
    3,438
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    iow, exactly what the error response says to do.

  4. #4
    SitePoint Evangelist
    Join Date
    Aug 2005
    Posts
    574
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    You need a wrapper around the form content inside of the form tag. Either add a <fieldset> or <div> tag immediately after the <form> tag along with a corresponding closing tag just before the form close tag.
    Amazing. I didn't realize that fieldset was required. Thanks so much.

  5. #5
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is not an XHTML vs HTML issue, but a Strict vs Transitional issue.

    In Strict DTDs – both XHTML 1.0 Strict and HTML 4.01 Strict – certain block-level element types (like BODY, FORM and BLOCKQUOTE) may only have block-level children. In old-school Transitional DTDs it is permissible to put plain text and inline-level elements as immediate children to those element types.
    Birnam wood is come to Dunsinane

  6. #6
    In memoriam gold trophysilver trophybronze trophy Dan Schulz's Avatar
    Join Date
    May 2006
    Location
    Aurora, Illinois
    Posts
    15,476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yep. Fieldsets are required, but just so you know, they are a pain in the neck to style cross-browser, as are legends. Check Tyssen's Web site for a tutorial on how to style them cross-browser (the article is titled "Legends of Style") at http://www.tyssendesign.com.au/artic...ends-of-style/

  7. #7
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    FIELDSET as such is not required. All that's required is that the immediate children of a FORM element are block-level elements. You could use DIV or P or TABLE as well, although FIELDSET is of course the most semantically appropriate choice.
    Birnam wood is come to Dunsinane

  8. #8
    In memoriam gold trophysilver trophybronze trophy Dan Schulz's Avatar
    Join Date
    May 2006
    Location
    Aurora, Illinois
    Posts
    15,476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Tommy, I forgot to add "if you wish your forms to be structured semantically" - it happens from time to time when going through multiple threads at once.

  9. #9
    SitePoint Wizard bronze trophy C. Ankerstjerne's Avatar
    Join Date
    Jan 2004
    Location
    The Kingdom of Denmark
    Posts
    2,702
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Plus, FIELDSET allows you to have the LEGEND-tag, which I personally think looks nice (for some purposes). I would still apply a table for aligning the individual fields, though, since this will align the forms better (and which I believe is still semantically correct, since the form fields are directly related to their labels).
    Christian Ankerstjerne
    <p<strong<abbr/HTML/ 4 teh win</>
    <>In Soviet Russia, website codes you!

  10. #10
    In memoriam gold trophysilver trophybronze trophy Dan Schulz's Avatar
    Join Date
    May 2006
    Location
    Aurora, Illinois
    Posts
    15,476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Actually you don't need tables to lay out the form elements. If you're using form labels and input fields, just put the form input after the label, and then follow that up with a line break tag (<br>). For checkboxes and radio buttons, wrap the inputs around labels.

    Then style to taste. If you need examples, let me know and I'll be more than happy to post some.

  11. #11
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by C. Ankerstjerne View Post
    I would still apply a table for aligning the individual fields, though, since this will align the forms better (and which I believe is still semantically correct, since the form fields are directly related to their labels).
    I wouldn't, and I disagree, but YMMV.
    Birnam wood is come to Dunsinane

  12. #12
    SitePoint Wizard bronze trophy C. Ankerstjerne's Avatar
    Join Date
    Jan 2004
    Location
    The Kingdom of Denmark
    Posts
    2,702
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dan Schulz View Post
    Actually you don't need tables to lay out the form elements. If you're using form labels and input fields, just put the form input after the label, and then follow that up with a line break tag (<br>). For checkboxes and radio buttons, wrap the inputs around labels.

    Then style to taste. If you need examples, let me know and I'll be more than happy to post some.
    Quote Originally Posted by AutisticCuckoo View Post
    I wouldn't, and I disagree, but YMMV.
    Quote Originally Posted by W3C
    The HTML table model allows authors to arrange data -- text, preformatted text, images, links, forms, form fields, other tables, etc. -- into rows and columns of cells.
    http://www.w3.org/TR/html4/struct/tables.html
    My emphasis.
    Christian Ankerstjerne
    <p<strong<abbr/HTML/ 4 teh win</>
    <>In Soviet Russia, website codes you!

  13. #13
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There are certainly cases where it is semantically correct to use a TABLE inside a FORM. One example is order forms where you have multiple rows containing identical columns with input fields for things like article ID, quantity, etc.

    But that isn't the same as saying that it's semantically proper to use a TABLE for layout purposes in a 'single-record' form, e.g. for inputting a delivery address.

    There is a relation between a LABEL and its control, but that is specified with the label's for attribute (or by wrapping the control inside the LABEL element).

    An address form may be well suited for a 'two-column' layout (labels and controls), but that doesn't make it tabular data. It's also easy to achieve with semantic markup and CSS, so there's no 'need' for a table.

    Also, you have to remember that the HTML spec was written in 1999, when CSS support in browsers was much poorer than it is today.
    Birnam wood is come to Dunsinane

  14. #14
    SitePoint Wizard bronze trophy C. Ankerstjerne's Avatar
    Join Date
    Jan 2004
    Location
    The Kingdom of Denmark
    Posts
    2,702
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    That's not how I interpret the specifications, but I guess that's more a matter of taste than anything else.
    Christian Ankerstjerne
    <p<strong<abbr/HTML/ 4 teh win</>
    <>In Soviet Russia, website codes you!

  15. #15
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by W3C
    The HTML table model allows authors to arrange data -- text, preformatted text, images, links, forms, form fields, other tables, etc. -- into rows and columns of cells.
    My emphasis.
    Birnam wood is come to Dunsinane

  16. #16
    SitePoint Wizard bronze trophy C. Ankerstjerne's Avatar
    Join Date
    Jan 2004
    Location
    The Kingdom of Denmark
    Posts
    2,702
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    So which part of the form would you then include in a table, and which part would you exclude? Also, which images would you interpret as data, and which part would you exclude from the table?
    Christian Ankerstjerne
    <p<strong<abbr/HTML/ 4 teh win</>
    <>In Soviet Russia, website codes you!

  17. #17
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by C. Ankerstjerne View Post
    So which part of the form would you then include in a table, and which part would you exclude?
    Quote Originally Posted by AutisticCuckoo View Post
    There are certainly cases where it is semantically correct to use a TABLE inside a FORM. One example is order forms where you have multiple rows containing identical columns with input fields for things like article ID, quantity, etc.
    The order rows are tabular data, because they have relationships in two dimensions. The input fields in each row are related, because they apply to the same order row. The fields in each column are related, because they correspond to the same entity (e.g., quantity) in all order rows.

    The delivery address, on the other hand, would appear in a fieldset of its own and would not be marked up as a table, because it's not tabular data.

    Quote Originally Posted by C. Ankerstjerne View Post
    Also, which images would you interpret as data, and which part would you exclude from the table?
    In a product listing, for instance, an image or thumbnail depicting the product could be considered to be part of the tabular data, along with product name, article ID, dimensions, weight, price, and so on.

    Decorative images used as layout elements, on the other hand, are not tabular data and do not belong in a table cell. In many instances they should be background images, but in some cases its appropriate to have a (mainly) decorative foreground image, e.g., as an illustration to a news article. This is not tabular data.
    Birnam wood is come to Dunsinane

  18. #18
    SitePoint Wizard bronze trophy C. Ankerstjerne's Avatar
    Join Date
    Jan 2004
    Location
    The Kingdom of Denmark
    Posts
    2,702
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    The order rows are tabular data, because they have relationships in two dimensions. [...] The delivery address, on the other hand, would appear in a fieldset of its own and would not be marked up as a table, because it's not tabular data.
    I have plenty of tables on my websites which are only one-dimensional, but which are still obviously semanticall tables, e.g. <http://www.panzerworld.net/jagdpanzeriv.html>.

    Forums are not tabular data, but tables are still the best semantical mark-up for them, as far as I know.
    Christian Ankerstjerne
    <p<strong<abbr/HTML/ 4 teh win</>
    <>In Soviet Russia, website codes you!

  19. #19
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by C. Ankerstjerne View Post
    I have plenty of tables on my websites which are only one-dimensional, but which are still obviously semanticall tables, e.g. <http://www.panzerworld.net/jagdpanzeriv.html>.
    I would argue that this is not really tabular information. As you say, there is only a one-dimensional relationship. Unfortunately there is no semantically proper element type for marking up generic key-value pairs in HTML, unless you relax the semantics of DL to the maximum.
    FWIW, I would have used a TABLE to mark up that page, too.

    Quote Originally Posted by C. Ankerstjerne View Post
    Forums are not tabular data, but tables are still the best semantical mark-up for them, as far as I know.
    I'd say a forum is tabular data. The data in a row has one relationship: a post. The data in a column has another relationship: e.g., post content.

    Normally forums only use two columns and put all post metadata (author info, timestamps, etc.) in one column, but that's more to do with width constraints.

    Tabular data, to me, is something that you could retrieve an arbitrary number of instances of from a relational database. The page you referred to as an example is a degenerated example (or edge case) where there is only one row.
    Birnam wood is come to Dunsinane

  20. #20
    SitePoint Wizard bronze trophy C. Ankerstjerne's Avatar
    Join Date
    Jan 2004
    Location
    The Kingdom of Denmark
    Posts
    2,702
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    I guess we should write W3C and get their oppinion
    Christian Ankerstjerne
    <p<strong<abbr/HTML/ 4 teh win</>
    <>In Soviet Russia, website codes you!

  21. #21
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by C. Ankerstjerne View Post
    I guess we should write W3C and get their oppinion
    Yeah, why not? Although that wouldn't be necessary, since the some of us are lurking on SPF anyway. I'm a member of the W3C HTML WG. (However I only speak for myself here, not on behalf of any WG.)

    I don't know what the intention was behind the HTML4 spec, although I agree with Tommy's interpretation.

    However, as of HTML5, <dl> has lost its "definition" semantics and is now a generic "description list", sort of like a one-dimensional table.
    Simon Pieters

  22. #22
    SitePoint Wizard bronze trophy C. Ankerstjerne's Avatar
    Join Date
    Jan 2004
    Location
    The Kingdom of Denmark
    Posts
    2,702
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    I would argue, if that is the case, that the usage isn't sufficiently well-defined in the specification.

    On a different note, HTML4 already allows quite versatile usage of DL, e.g. as a time line. HTML5 appears to have certain problems, e.g. it does not fully comply with ISO 31/SI and ISO 8601 (or ISO 690:1987/ISO 690:1997, for that matter, though this would probably be too complicated to justify implementation).
    One example is the fact that the current draft does not recognise the internationally valid decimal comma (","), but only the decimal point (".") which - at this time - has not been implemented into ISO 31 (ISO has written that they are planning to allow both decimal separators in the future). With the current draft of HTML5, it is therefore impossible to write decimal numbers.
    I also wonder why dates lower than 0000 or higher than 9999 are not allowed, since ISO 8601 clearly defines how to expand the standard year-element to take this into account.
    Christian Ankerstjerne
    <p<strong<abbr/HTML/ 4 teh win</>
    <>In Soviet Russia, website codes you!

  23. #23
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by C. Ankerstjerne View Post
    I would argue, if that is the case, that the usage isn't sufficiently well-defined in the specification.
    You mean <dl> in HTML5? Could you elaborate on why and what you'd want the spec to say?

    Quote Originally Posted by C. Ankerstjerne View Post
    On a different note, HTML4 already allows quite versatile usage of DL, e.g. as a time line.
    Indeed, HTML4 suggests DL can be used for things other than defining terms, but at the same time it defines DL to be a definition list. This is one of many contradictions in HTML4.

    Quote Originally Posted by C. Ankerstjerne View Post
    HTML5 appears to have certain problems, e.g. it does not fully comply with ISO 31/SI and ISO 8601 (or ISO 690:1987/ISO 690:1997, for that matter, though this would probably be too complicated to justify implementation).
    I haven't looked in to this in depth, but, if it doesn't, should it? Why?
    Quote Originally Posted by C. Ankerstjerne View Post
    One example is the fact that the current draft does not recognise the internationally valid decimal comma (","), but only the decimal point (".") which - at this time - has not been implemented into ISO 31 (ISO has written that they are planning to allow both decimal separators in the future). With the current draft of HTML5, it is therefore impossible to write decimal numbers.
    It is possible to write decimal numbers. You use the decimal point instead of the comma. If you don't want it to be presented with a decimal point to the user, then you specify the number in an attribute in the HTML5 format and then whatever format you want in the contents. All elements whose contents are processed for dates or numbers also have attributes in which you can specify the value, in order to support arbitrary formats.

    Quote Originally Posted by C. Ankerstjerne View Post
    I also wonder why dates lower than 0000 or higher than 9999 are not allowed, since ISO 8601 clearly defines how to expand the standard year-element to take this into account.
    I'm not sure, although I think this has been discussed on the list.

    I'd encourage you (and anyone else) to join the list to comment on the proposal, or if you don't like reading specs or subscribing to mailing lists there are still other things you can do if you want to contribute.
    Simon Pieters

  24. #24
    SitePoint Wizard bronze trophy C. Ankerstjerne's Avatar
    Join Date
    Jan 2004
    Location
    The Kingdom of Denmark
    Posts
    2,702
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    You mean <dl> in HTML5? Could you elaborate on why and what you'd want the spec to say?
    No, the scemantically correct usage of TABLE in HTML4. The HTML5 definition of DL is fine.

    I haven't looked in to this in depth, but, if it doesn't, should it? Why?
    Since it mentions areas covered by both ISO 31/SI (numbers) and ISO 8601 (dates), I think it should.

    It is possible to write decimal numbers. You use the decimal point instead of the comma. If you don't want it to be presented with a decimal point to the user, then you specify the number in an attribute in the HTML5 format and then whatever format you want in the contents. All elements whose contents are processed for dates or numbers also have attributes in which you can specify the value, in order to support arbitrary formats.
    That my whole point - the decimal comma is an internationally correct decimal seperator (and, at the moment, the only one), so it seems strange that HTML5 doesn't allow it.

    Now that you actually encourage me, I might write up some proposals for those areas in HTML5 which doesn't comply with standards I'm well-aquainted with, once I find the time
    Christian Ankerstjerne
    <p<strong<abbr/HTML/ 4 teh win</>
    <>In Soviet Russia, website codes you!


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •