SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 60 of 60
  1. #51
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,272
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    @logic_earth:
    ah, did you mean XML5?

    The goal of this project is develop a proposal for XML5. A revised of XML that no longer follows the well-formedness principle but instead has a way of error handling that is closer to HTML, except that it is more predictable. This new version will be backwards compatible with XML 1.0 and XML 1.1 in a way that documents written in those languages (and don't rely on external DTD validation) will still work in XML5. The other way around is not necessarily true of course.

    The idea is that having a non "draconian" version of XML would allow it be adopted more easily on the web as people tend to generate content using string concatenation which makes it very hard to guarantee "well-formed XML". It also allows for better competition in the mobile space where XML content is not always parsed using an XML parser by all players.
    So far as I know though this isn't implemented anywhere yet.

  2. #52
    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)
    deathshadow
    XHTML allows other XML-based languages to be used in conjunction with the XHTML, as long as their namespace is defined. You can see an example in the specification.

    In the document, I enable the qualified name svg, so that I can use the svg: prefix, with the reference to the SVG namespace (xmlns:svg="http://www.w3.org/2000/svg"). Having done this, any tag with the svg: prefix will be treated as the respective SVG tags without the prefix, so that e.g. svg:desc becomes desc when used as SVG.

    For the sake of argument, and to demonstrate that the browser is actually interpreting the namespace correctly, I swapped the prefix svg: with charlietheunicorn:. This still gives the correct rendering of the SVG image in Chrome (and it serves to confuse my enemies ).

    I suspect that Opera may be tripping over the syntax error, so I've made a version without the error.
    Christian Ankerstjerne
    <p<strong<abbr/HTML/ 4 teh win</>
    <>In Soviet Russia, website codes you!

  3. #53
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    @logic_earth:
    ah, did you mean XML5?
    Where do you get XML5? I'm talking about HTML5 that thing everyone is talking about You know that HTML5 thing?
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  4. #54
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,272
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Where do you get XML5? I'm talking about HTML5 that thing everyone is talking about You know that HTML5 thing?
    Because it's the only thing I can find on teh entire freaking interwebs that matches what you've been saying. XHTML5 must be parsed as XML, not some other special new manner of parsing, sorry. What you're talking about sounds an awful lot like this little project of Anne's that's been going on since 2007, which is XML without draconian error handling (and therefore without fatal errors). However it does not exist in reality (yet).

    Quote Originally Posted by logic_earth
    There are no fatal errors in (X)HTML5.
    Yes, there are, since it must be parsed as XML and XML has fatal errors. Or, you could explain what you're talking about so I can get up to speed. What you mention about unified error handling is HTML parsing only. The WHATWG spent 5 years documenting how browsers parsed HTML (not XML or XHTML), and in 2009 they could release what they had documented along with a new parsing method with defined (and unified) error handling, which previously did not exist in HTML at all. But this has nothing to do with XHTML-anything, which is still parsed with an XML parser.

    Enlighten me please.
    Last edited by Stomme poes; Jul 27, 2011 at 00:10. Reason: Zalgo, he comes... the <center> cannot hold

  5. #55
    Robert Wellock silver trophybronze trophy xhtmlcoder's Avatar
    Join Date
    Apr 2002
    Location
    A Maze of Twisty Little Passages
    Posts
    6,316
    Mentioned
    60 Post(s)
    Tagged
    0 Thread(s)
    For both XML 1.0 and XML 1.1 the validating and non-validating XML processors alike (the latter being typically seen in mainstream browsers) they MUST report violations of the XML 1.x specifications well-formedness constraints.

    From what I understand Fred (XML syntax) version [XHTML5] mainly uses the rules of 1.0 and it MUST follow XML well-formedness constraints: http://www.w3.org/TR/xml/

  6. #56
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Stomme poes, Section 8, and Section 9.
    Pay close attention to "8.2.8 An introduction to error handling and strange cases in the parser" which applies to both HTML 5 and XHTML 5, all the rules that apply to HTML 5 parsing apply to XHTML 5 as well.

    When an XML parser reaches the end of its input, it must stop parsing, following the same rules as the HTML parser. An XML parser can also be aborted, which must again by done in the same way as for an HTML parser.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  7. #57
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,272
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    The URL you posted only takes me to the top of the page, but I did scroll down to Section 8.2.8.
    Quote Originally Posted by logic_earth
    which applies to both HTML 5 and XHTML 5,
    I still am not convinced that Section 8.2.8 applies to XHTML5, rather than simply the small part at the top about what a UA must do after stopping with parsing.

    Section 9 discusses XHTML which is parsed as XML. I see no contradiction there from any of the other sources I've referenced. I see nowhere that XHTML must use an HTML parser rather than an XML parser?

    The entirety of your earlier quote is
    Quote Originally Posted by w3c
    When an XML parser creates a script element, it must be marked as being "parser-inserted" and its "force-async" flag must be unset. If the parser was originally created for the XML fragment parsing algorithm, then the element must be marked as "already started" also. When the element's end tag is parsed, the user agent must provide a stable state, and then prepare the script element. If this causes there to be a pending parsing-blocking script, then the user agent must run the following steps:

    1. Block this instance of the XML parser, such that the event loop will not run tasks that invoke it.

    2. Spin the event loop until the parser's Document has no style sheet that is blocking scripts and the pending parsing-blocking script's "ready to be parser-executed" flag is set.

    3. Unblock this instance of the XML parser, such that tasks that invoke it can again be run.

    4. Execute the pending parsing-blocking script.

    5. There is no longer a pending parsing-blocking script.

    Since the document.write() API is not available for XML documents, much of the complexity in the HTML parser is not needed in the XML parser.

    Certain algorithms in this specification spoon-feed the parser characters one string at a time. In such cases, the XML parser must act as it would have if faced with a single string consisting of the concatenation of all those characters.

    When an XML parser reaches the end of its input, it must stop parsing, following the same rules as the HTML parser. An XML parser can also be aborted, which must again by done in the same way as for an HTML parser.

    For the purposes of conformance checkers, if a resource is determined to be in the XHTML syntax, then it is an XML document.
    I could be wrong, but it seems to me that "end of its input" is not referring to errors but the end of the document, or whenever there is nothing left to parse. By "following the same rules as the HTML parser" it is only talking about the steps a user agent must follow in order to signal that a document is "ready" and "loaded", which does not translate to "XHTML5 gets parsed with an HTML parser and therefore does not have fatal errors". That they "ready" and "load" a document following the same steps is not the same as "XHTML5 parses using an HTML parser" and none of the parsing rules in Section 8 pertain to XHTML5, since XHTML5 is using an XML parser. This is directly the opposite of the claim made by the WHATWG.

    XHTML syntax and parsing from the official WHATWG wiki states that for XHTML:
    XML parsing rules are used. There is only one mode.
    and
    Well-formedness errors are fatal
    Note that near the top it says
    Please note that the information in here is based upon the current spec for (X)HTML5. Some of the issues technically do not apply to previous versions of HTML.
    and it mentions in several places (just as W3C's HTML5 page) that these documents are moving targets and information may change or be outdated. However today I am looking at them and see nowhere anything about XHTML5 being parsed with an HTML parser or following the new HTML5 parsing rules, which apply to HTML(5) and not X-anything.

    That they both use the same steps after parsing to set the document to "ready" does not convince me that XHTML5 does not use an XML parser and therefore does not have fatal errors.

    Everything I read states XHTML is parsed with an XML parser, which means well-formedness errors are fatal errors, which means when the parser hits them it must stop further parsing of the document, instead of going on and switching to error-parsing or HTML parsing or new HTML5 parsing.

    I've been wrong often enough that I am more than willing to ask anyone working on HTML5 which is correct: if XHTML5 is parsed with an XML parser and follows all the rules of XML parsing including abortion of parsing upon well-formedness errors (fatal errors), or if it uses the new parser for HTML5 which does not have fatal errors.

    *edit I've sent a question to Anne, tho he may direct me to someone with more knowledge on this part of the spec

  8. #58
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    Stomme poes, Section 8, and Section 9.
    Pay close attention to "8.2.8 An introduction to error handling and strange cases in the parser" which applies to both HTML 5 and XHTML 5, all the rules that apply to HTML 5 parsing apply to XHTML 5 as well.
    I REALLY have to say you're mis-reading the intent and purpose of that entire section -- SP really hit the key points.

    I think such misunderstandings just further illustrates the problems with all of the HTML specifications; it's this vague hard to interpret legalese that takes something which should be moronically simple to understand and implement, and turns it into just another convoluted mess that two people can read and interpret to have two radically different meanings.

    Though BOTH the SGML and XML legacies certainly don't help in that department - as both specifications are also needlessly complex for no good reason filled with tons of things nobody should ever need or even care about.

    I often think it would be better if all the 'extra crap' from both specifications that aren't needed to actually build a website was just dropped altogether from HTML.

  9. #59
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,272
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    I linked both Bruce and Anne to the thread but both just answered the basic question: XHTML5 must be parsed as XML with an XML parser.

    Boy I feel like a retard linking to tweets. But anyway I did send a follow-up question to Anne regarding the end-of-input thing, because it does seem weird to place "what to do when done parsing" in the section called "HTML parsing". You would think that would come after the XHTML parsing section.

  10. #60
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,272
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    diannaa: yeah, but the question was, did that change with XHTML5 (since it's not XHTML1.1)? I got more confirmation from Anne that all those rules of the XML parser are necessary with XHTML5... but it does seem some small things were changed in the XML spec regarding stuff like DOM events. Stuff I can't follow since I've never done XML Dom scripting or anything similar.


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
  •