SitePoint Sponsor

User Tag List

Page 12 of 17 FirstFirst ... 28910111213141516 ... LastLast
Results 276 to 300 of 402
  1. #276
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    And also equally valid for HTML2+ or any version of XHTML. It doesn't identify the version of (X)HTML being used at all.
    That's the point. Browsers don't care which version of (X)HTML pages claim to be anyway.

    Quote Originally Posted by felgall View Post
    Also there is the problem that HTML 5 itself defines an identical tag and so you have no way to tell then whether that tag is the SGML identifier or is meant to be the one defined as a part of HTML5.

    I guess the only time you'd be sure it is HTML5 is if you had both the SGML qualifier AND the HTML5 doctype tags both present at the top of your document.

    <!DOCTYPE html ><!DOCTYPE html >

    Then you know that the page is XHTML5 since the SGML doctype is followed by a tag that only exists in HTML5.
    ???

    text/html-HTML5 has nothing to do with SGML, there is no SGML identifier and you can't use an SGML parser to parse text/html-HTML5 or actually pages on the Web in the general case.

    XHTML5 is XML and XML does not allow two doctypes.
    Simon Pieters

  2. #277
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Stomme poes, exactly my feelings on the subject and what I was trying to put across earlier.

  3. #278
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by zcorpan View Post
    text/html-HTML5 has nothing to do with SGML, there is no SGML identifier and you can't use an SGML parser to parse text/html-HTML5 or actually pages on the Web in the general case.

    XHTML5 is XML and XML does not allow two doctypes.
    But XML is SGML and therefore XHTML5 either is SGML or it isnt XML - it can't be somethiong that is a subset of something else without being that something else as well. If it isn't SGML then it can't be XML because XML is SGML.

    The fact that (X)HTML5 is the first version to add a doctype statement to the (X)HTML language effectively makes it impossible for it to follow the standards since the standard say that there needs to be an SGML doctype or schema in order for it to be a valid markup language even in those instances where the language itself aloows it to be omitted. By replacing the SGML doctype (X)HTML5 has breached the markup standards and is not following the standards for markup languages that almost all markup languages of the last 30+ years have followed.
    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="^$">

  4. #279
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    XHTML 5 is XML, HTML 5 is not SGML. It doesn't do both at the same time, from what I understand anyway.

  5. #280
    SitePoint Author silver trophybronze trophy

    Join Date
    Nov 2004
    Location
    Ankh-Morpork
    Posts
    12,158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But didn't Simon say that HTML5 and XHTML5 are identical except for the parsing? How can one then be an application of a subset of SGML (viz. XML) and the other one not be an application of SGML?

    Oh well, this is after all from a working group that believes that a form consists of paragraphs. We shouldn't expect too much.
    Birnam wood is come to Dunsinane

  6. #281
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,287
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    ^Lawlz, but the currect examples on w3c HTML4 form pages use paragraphs as well. Paragraphs instead of fieldsets even!

  7. #282
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    But didn't Simon say that HTML5 and XHTML5 are identical except for the parsing? How can one then be an application of a subset of SGML (viz. XML) and the other one not be an application of SGML?

    Oh well, this is after all from a working group that believes that a form consists of paragraphs. We shouldn't expect too much.
    Yeh, one thing I disagree with. Still, you don't have to use their examples, you are permitted to do things your own way... like the whole argument of the font tag. If you don't like it, don't use it, but don't write off the whole language just because it is there!

  8. #283
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    But XML is SGML
    Yes
    Quote Originally Posted by felgall View Post
    and therefore XHTML5 either is SGML or it isnt XML -
    XHTML5 is an application of XML which is in turn a subset of SGML.

    Quote Originally Posted by felgall View Post
    it can't be somethiong that is a subset of something else without being that something else as well. If it isn't SGML then it can't be XML because XML is SGML.
    I never said XHTML5 is not SGML. I said text/html-HTML5 is not SGML. I can also say that CSS is not SGML. It does not affect XHTML5.

    Quote Originally Posted by felgall View Post
    The fact that (X)HTML5 is the first version to add a doctype statement to the (X)HTML language
    It does not. It defines one for the text/html-HTML5 syntax.
    Simon Pieters

  9. #284
    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 zcorpan View Post
    I never said XHTML5 is not SGML. I said text/html-HTML5 is not SGML.
    But you said the two are identical except for parsing, didn't you? That's what's confusing me. How can two things be identical and one be SGML and the other not be SGML?
    Birnam wood is come to Dunsinane

  10. #285
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    But didn't Simon say that HTML5 and XHTML5 are identical except for the parsing?
    Yes. Well, modulo minor differences such as lang="" and xml:lang="".

    Quote Originally Posted by AutisticCuckoo View Post
    How can one then be an application of a subset of SGML (viz. XML) and the other one not be an application of SGML?
    I don't see why not.
    Simon Pieters

  11. #286
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    But you said the two are identical except for parsing, didn't you? That's what's confusing me. How can two things be identical and one be SGML and the other not be SGML?
    It's just syntax. You could imagine a JSON serialization of HTML5 if you will. Clearly, JSON is not SGML, yet it can probably represent most of the HTML5 language.
    Simon Pieters

  12. #287
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Think of it like... syntax over theory.

    These two are exactly the same, they produce the same results:
    Code C#:
    if(Something != "SomethingElse"){
        //do something
    }
    Code vb:
    If Something <> "SomethingElse" Then
        ' do something
    End If

    In the same way, HTML5 and XHTML5 are the same - they just have different syntax (though the difference is much, much smaller).

    XHTML5 is a waste of space, from my point of view. XHTML2 splits away from HTML, after all HTML and XML just don't mix. However, XHTML has potential to truly split away from the idea of HTML and, in itself, become an XML-based structured markup language. Until we actually give that a chance (which XHTML5 is not doing), XHTML is not going to be useful.

    I think I've seen enough of both to safely say that both have equal amounts of benefits and issues.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  13. #288
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    270
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    No they don't - the only things needed to identify XHTML is a MIME type of application/xml+xhtml and an xmlns attribute on the HTML tag.
    Oops. Yes, you're right. XHTML1 required the DTD's but that was dropped for further versions, so it comes into the same territory.

    But let's analyze that and see if it's significant, shall we? Since there's no requirement for any DTD to be present, how does the lack of one for XHTML5 make it any different, or any more significant than XHTML1.1 or 2? If there's fatal confusion between XHTML5 and XHTML2, then isn't there also the same between XHTML1.1 and XHTML2 or XHTML3 when/if it arrives?


    Quote Originally Posted by felgall View Post
    In all the web languages so far only (X)HTML5 has defined a <!doctype> tag as a part of its language. HTML2-4 and XHTML are all validly defined using SGML
    OK, we need to stop that train right there. for some real-world distinctions.

    HTML was conceived as a markup language insipred by but not conforming to SGML. As such, no browser that has ever rendered an HTML page has *ever* treated it like an SGML application. Claiming HTML as an SGML application is like claiming a hedge trimmer as a hay mower, because they both have moving blades against a bar.

    One of the motivations for the XHTML spec was to create an HTML-like syntax that conformed to XML. XHTML1 is HTML4 rewritten as a conforming XML language.

    While yes, it can be said that theoretically HTML is an SGML application, the fact that XML, another subset of SGML, required a separate DTD for HTML to conform to it may shed some light on just what that means as a practical matter.

    Quote Originally Posted by felgall View Post
    If (X)HTML5 is SGML
    I've quoted this line before, but here's an apt place to requote it:

    "since neither of the two authoring formats defined in this specification are applications of SGML" (from the HTML5 draft spec.)

    You've made reference before to the heinous fact that HTML5 defines a doctype statement. There are very simple reasons for that:

    HTML5 documents can (note please I'm not saying "are always", just "can") be served either way, as XHTML and as HTML. If you're going to serve it both ways, depending upon user agent, you'd best have it in the spec for the HTML side, n'est ce pas? Also, since the DOCTYPE has been mistakenly pressed into service as a switch for most browsers between standards and "quirks" mode, it's necessary to recognize reality and allow the statement in an HTML5 document.

    Quote Originally Posted by felgall View Post
    them an optional SGML doctype should be valid at the start of the file (before the <!doctype html> that HTML5 defines).
    I think you're laboring here under the misapprehension that because it is defined it therefore must be used. It's *not* a required element in HTML5, it's a permitted one. I don't see how this concept causes so much trouble. It seems self-evident to me: An XML/XHTML document is required to have a DOCTYPE. An HTML5 document is not, but can have one if it wants. Therefore, if I serve my document with a mime type declaring it as XHTML/XML, there must be a DOCTYPE. Note there is only required to be one. Since the mime type requires it, the DOCTYPE the server sees in the file must be the one required by XHTML/XML. Why you think two would be necessary is beyond me. There's only one, the one that's required when served with some mime types, and that's all. Now, If I take the exact same document and serve it to another user agent as HTML, for it to be a valid document it would appear I have two choices: either I have to have the DOCTYPE in the spec as valid HTML5 or I have to somehow tell the server to strip it off before sending the document. The first is the simpler option.

    If I have my server configured to only serve as HTML, I don't need a doctype in the file, but then I trigger quirks mode, so as a concession to reality, I'll put it in, and the spec will allow that.

    How is that so confusing, or even potentially confusing?

    Quote Originally Posted by felgall View Post
    If it is not SGML then the people writing HTML5 have thrown away decades of knowledge about how markup languages should be defined
    When I saw that paragraph I had a hard time restraining my own sarcasm. How can not using a tool possibly mean you can't have learned from the ideas behind the purpose of the tool? It's not like SGML is perfect. I mean, have you ever read that spec? We could restore the world's rainforests if we could turn that paper back into trees! (OK, so I got a little hyperbolic, sue me.)

    If I write a program in Ruby, I'm not throwing away the decades of knowledge about how programming is done that have been stored in COBOL. It's quite possible for a different approach to be better, or more likely, just as good as.

    It looks from my standpoint they've learned not only about SGML, but have also taken a look at the real world. Is there even one browser that actually follows SGML rules? If not, then maybe it's not such a good thing for the markup language directed at them to require it.

    Quote Originally Posted by felgall View Post
    Of course the other way we could work things is if someone were to create a translator to convert from a given version of (X)HTML that people want to develop in to the HTML4 equivalent that current browsers can understand. This would allow the full use of (X)HTML5 or XHTML2 now for all of your page source. You would then either feed your static pages through the converter before uploading them or attach the converter into dynamic pages so that it converts them immediately prior to sending them to the browser. If appropriate converters were made available then it would not be necessary to wait for browsers to start supporting your preferred markup language before you start using it, you'd simply use the appropriate converter to have your preferred language converted into the HTML4 that the browsers do support.
    I tried that. Some years back I was convinced the only way forward was XSLT, turning the same source doc into HTML3.2, HTML4.01, and other variations of it all based on browser capabilities. I even started writing some of those translators. I recovered from my delusion some time later; no way am I going back there.

    I don't see browser support of the complete spec as a valid issue, because, as has been noted, if we waited for support of a complete spec before using it, we wouldn't even be using CSS.

    So there are going to be bugs and lag time between implementations of the spec? Just how is that worse than what we have today? Or, for that matter, what we can reasonably expect from a future without HTML5? If there's no real difference, then there's no reason to object to HTML5 on those grounds.

    @arkinstall, I appreciate the sentiment, but in fact pieces of HTML5 *are* even now being put on production sites by professionals. Try An Event Apart, The Watchmaker Project or UX London. It's filtering out, piece by piece. And I'm far from the only one taking note of it. See Jeremy Kieth for another voice.

    Is it a good fit for every project? Of course not, don't be daft. But it's just as daft to assume it's not usable for any production site.

    @Stomme, Good Points. I'm by no means recommending everyone jump on HTML5 right now for everything. I'm not even advocating every developer has to, or should, use it. But to dismiss it out of hand like some on this tread have been doing is also a Bad Idea. More specifically:

    one of the things I did not like the smell of was the client doing basically the work of either Javascript (canvas and loading were two examples) or of what normally should be the back end
    Not exactly sure what you're getting at, here. The client does the work of javascript as well, in that it runs on the client machine inside the environment given it by the user agent.

    In it's simplest form, canvas merely reserves a space for scripts to dynamically draw inside. It can do more, of course, but it works with scripting, so I think I'm missing your point.

    I understand the bias against javascript. I felt the same way for a long time. But lately I'm seeing a lot of good work being done there. I still think it's "not a *real* programming language" but I'm finding it quite useful for enhancements to interaction. It'd be nice to have access to another language that wouldn't require round-trips to the server with every click, but it's all we have.

    I don't see a non-text future for the web, but let's face it, people today want more than just text; if we don't give it to them, our competition will. It's not fair, and sometimes it's even counter-intuitive, but I think it derives from the fact that computers themselves are more graphical these days, so the user expects anything they do with the computer to be that way as well.

    @autisticcuckoo, What part of "identical except for the parsing" confused you? If the two markup specs can be parsed differently, then it's quite possible for a document conforming to one to be well-formed, from an SGML standpoint, and one conforming to the other not. One can be valid according to SGML, and one not. What's going on here is that it's perfectly possible to write an HTML5 document that is a valid document, and is able to be parsed correctly by an HTML5 parser, but does not conform to XML/XHTML/SGML, and cannot be properly parsed by one of those parsers. As a further point, it would not be properly parsed by an XHTML5 parser, for those same reasons. It's also possible to write one that can be properly parsed by both, and the HTML5 folks recommend you do, but don't insist on it and don't force you do so. Maybe it's just my perl background, but the fact there are multiple ways write the same markup seems natural to me.

    I'm with you and @stomme though on the paragraphs vs fieldsets in forms.

  14. #289
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Arlen View Post
    HTML was conceived as a markup language insipred by but not conforming to SGML.
    That was the case before HTML 2.0 (and is the case again with HTML5). However, HTML 2.0 to HTML 4.01 were all conforming applications of SGML, as specced.

    Quote Originally Posted by Arlen View Post
    no browser that has ever rendered an HTML page has *ever* treated it like an SGML application.
    Correct.

    Quote Originally Posted by Arlen View Post
    I think you're laboring here under the misapprehension that because it is defined it therefore must be used. It's *not* a required element in HTML5, it's a permitted one. I don't see how this concept causes so much trouble.
    Actually, it is required in text/html.

    http://www.whatwg.org/specs/web-apps...html-documents

    Quote Originally Posted by Arlen View Post
    It seems self-evident to me: An XML/XHTML document is required to have a DOCTYPE.
    There's no such requirement in neither XML nor XHTML5.
    Simon Pieters

  15. #290
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Arlen View Post
    What's going on here is that it's perfectly possible to write an HTML5 document that is a valid document, and is able to be parsed correctly by an HTML5 parser, but does not conform to XML/XHTML/SGML, and cannot be properly parsed by one of those parsers. As a further point, it would not be properly parsed by an XHTML5 parser, for those same reasons.
    The idea with XHTML (or applications of XML in general) is that you just use an XML parser. As such, there's no such thing as an XHTML parser or XHTML5 parser.
    Simon Pieters

  16. #291
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by zcorpan View Post
    That was the case before HTML 2.0 (and is the case again with HTML5). However, HTML 2.0 to HTML 4.01 were all conforming applications of SGML, as specced.
    That change in HTML2 was the biggest ADVANCE to the HTML language. The reverse of that change in HTML5 gives you a version that is therefore worse than HTML2. Those developing the language have thrown away decades of standards development knowledge relating to markup languages and are doing their own thing rather than following the standards. If they can't follow standards in developing HTML5 then why should they expect anyone else to follow standards.

    Also in the case of XHTML5 if it is valid XML then it is also valid SGML and would need to allow for the SGML doctype as well as the XHTML5 doctype so that <!DOCTYPE html ><!DOCTYPE html > would then be a valid way to start the page - the first tag would be the doctype defined by SGML (which is a valid part of all XML documents) and the second would be the one defined in the (X)HTML5 spec. As an XHTML statement that second one would of course require a matching closing tag since every tag in XML must be closed.
    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="^$">

  17. #292
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    Also in the case of XHTML5 if it is valid XML then it is also valid SGML and would need to allow for the SGML doctype
    It does.

    Quote Originally Posted by felgall View Post
    as well as the XHTML5 doctype
    There is no such thing.

    Quote Originally Posted by felgall View Post
    so that <!DOCTYPE html ><!DOCTYPE html > would then be a valid way to start the page -
    That cannot be a valid start of the page since it's not well-formed XML.

    Quote Originally Posted by felgall View Post
    the first tag would be the doctype defined by SGML (which is a valid part of all XML documents)
    Yes.

    Quote Originally Posted by felgall View Post
    and the second would be
    ...a well-formedness error.


    I'm not sure how to make it clearer. Maybe I should quote the spec?
    Quote Originally Posted by HTML 5
    The syntax for using HTML with XML, whether in XHTML documents or embedded in other XML documents, is defined in the XML and Namespaces in XML specifications. [XML] [XMLNS]

    This specification does not define any syntax-level requirements beyond those defined for XML proper.

    XML documents may contain a DOCTYPE if desired, but this is not required to conform to this specification. This specification does not define a public or system identifier, nor provide a format DTD.
    -- http://www.whatwg.org/specs/web-apps...html-documents
    Simon Pieters

  18. #293
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by zcorpan View Post
    ...a well-formedness error.
    So all that garbage in the HTML5 spec aboutr the doctype needs to be removed in order to remove that error.

    An XML doctype is part of SGML and not a part of XML and so either all mention of the doctype in the standard is wrong and should be deleted before it confuses people into thinking that the doctype is a part of (X)HTML5 instead of being SGML (as it is with HTML2 through 4 and XHTML) OR (X)HTML5 isn't following the SGML/XML standards and therefore XHTML5 is not XML (since to be XML it must also be SGML and therefore it is valid to add an SGML doctype in front of the XHTML5 which can also include a doctype) OR the two doctypes one after the other ARE valid since that is what you get when you put the standards together - the SGML doctype followed by the HTML5 doctype.

    You are claiming that all three are false but one of these must be true since they cover all the alternatives.

    I think in fact that it is the second of these that is the one that is true as several people have already stated in this thread and those writing the (X)HTML5 standard are doing their own thing rather than following the SGML standards for the specification of markup languages. If so then the only discrepancy is the omission of the decimal point in the version number for (X)HTML0.5 (or possibly 1.5 since it is obviously a lot worse than HTML2 i9f it isn't following the standards). Of course that is what you get when you don't follow standards - a mess. Also the second of these alternatives - that (X)HTML5 isn't following the markup standards and is just being thrown together without any thought for the SGML standards that define how to define markup languages - is the only one that doesn't lead to contradictions in the so called standards.
    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="^$">

  19. #294
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    So all that garbage in the HTML5 spec aboutr the doctype needs to be removed in order to remove that error.
    I don't know which part of HTML5 you want removed. Could you quote the specific part you're thinking of?

    Quote Originally Posted by felgall View Post
    An XML doctype is part of SGML and not a part of XML
    How is it not part of XML? XML is a self-contained spec. It defines the syntax for the doctype. Note that the syntax for an XML doctype is different than the allowed syntax for SGML doctype. For instance, "<!doctype foo system>" is a valid SGML doctype but not well-formed XML.

    Quote Originally Posted by felgall View Post
    and so either all mention of the doctype in the standard is wrong and should be deleted before it confuses people into thinking that the doctype is a part of (X)HTML5 instead of being SGML
    Well, so far, it's just you being confused.

    Quote Originally Posted by felgall View Post
    OR (X)HTML5 isn't following the SGML/XML standards and therefore XHTML5 is not XML (since to be XML it must also be SGML and therefore it is valid to add an SGML doctype in front of the XHTML5 which can also include a doctype)
    Which part of XHTML5 is not following XML? Could you please quote the part of the HTML 5 spec that violates XML.
    Quote Originally Posted by felgall View Post
    OR the two doctypes one after the other ARE valid since that is what you get when you put the standards together - the SGML doctype followed by the HTML5 doctype.
    I must say, you have a very creative way to interpret specifications (if you read them at all?).
    Simon Pieters

  20. #295
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,287
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Arlen
    Not exactly sure what you're getting at, here. The client does the work of javascript as well, in that it runs on the client machine inside the environment given it by the user agent.

    In it's simplest form, canvas merely reserves a space for scripts to dynamically draw inside. It can do more, of course, but it works with scripting, so I think I'm missing your point.
    I'm not explaining it well because it was like 2 months ago? And unless he's got the presentation on his site somewhere (he might, I never looked) I'll never remember what exactly it was... it was along the lines of basically doing MORE of what otherwise was Javascript, except it was in the markup itself. But I'll let it lay there because I can't be clearer. I'm a non-smoker I swear.

    Quote Originally Posted by Arlen
    I understand the bias against javascript. I felt the same way for a long time. But lately I'm seeing a lot of good work being done there. I still think it's "not a *real* programming language" but I'm finding it quite useful for enhancements to interaction. It'd be nice to have access to another language that wouldn't require round-trips to the server with every click, but it's all we have.
    Actually, after reading Crockford's book, I think it actually *is* a true programming language... one with maybe quite a few mistakes in how it was written, but I'd consider it mature enough. My bias seems based on the way people've used it (which we generally can't do anything about except not be so dumb ourselves). It seemed at Anne's presentation that the scripty things being added to the markup basically meant that if your user agent didn't support the scripting (or similar processing) then the whole HTML element couldn't be used. But again, I should shut up unless I find a copy of the presentation (mostly just a rundown of what was new, how it compared with HTML and XHTML...).

  21. #296
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    270
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    So all that garbage in the HTML5 spec aboutr the doctype needs to be removed in order to remove that error.

    An XML doctype is part of SGML and not a part of XML and so either all mention of the doctype in the standard is wrong and should be deleted before it confuses people into thinking that the doctype is a part of (X)HTML5
    Ah, I think that is the source of your confusion. You're reading/seeing/hearing that the doctype tag is in the HTML5 spec and you're assuming, without justification, that it's required by the XHTML5 spec as well. It's not.

    It's in the HTML5 spec because browser makers use it as a standards mode switch. To quote from the "HTML Syntax" portion of the spec:

    NOTE: DOCTYPEs are required for legacy reasons. When omitted, browsers tend to use a different rendering mode that is incompatible with some specifications. Including the DOCTYPE in a document ensures that the browser makes a best-effort attempt at following the relevant specifications.
    (The words are bold and green, to make them easier to find, I suspect.)

    But when we turn to the "XHTML Syntax" portion of the spec, it says:

    XML documents may contain a DOCTYPE if desired, but this is not required to conform to this specification.
    To be considered as XHTML5, the document has to be served as XML (serving it as text/html automatically makes it HTML5) and as XHTML5 the spec clearly states the DOCTYPE is *not* required. So, if you're going to parse this as SGML, and that requires a DOCTYPE, but the XHTML5 does not require a DOCTYPE (as the spec clearly states) why do you insist there has to be two DOCTYPEs? Clearly only one is required.

    You are claiming that all three are false but one of these must be true since they cover all the alternatives.
    Only if your reasoning process is:
    1) The spec makes it possible for me to write something that is unnecessarily confusing.
    2) It's good to make things as confusing as possible.
    3) Therefore I must use both DOCTYPES.

    Of course, using that rationale, people would be writing documents that consist solely of div tags.

    "It's allowed, therefore it's required" isn't a good way to go about writing any sort of markup, but I guess that's only a problem if you want to use HTML5?

    I think in fact that it is the second of these that is the one that is true as several people have already stated in this thread and those writing the (X)HTML5 standard are doing their own thing rather than following the SGML standards for the specification of markup languages.
    And the penny drops at last. How many times now have I posted the statement from the HTML5 pages that said even XHTML5 is not supposed to be an application of SGML?

    It's not an SGML application, but it can be parsed using the parsing rules from XML if it's served as an XML file.

    I understand your affection for SGML. I get it. I really do. Now, can you wrap your head around the idea that perhaps SGML isn't the absolute be-all and end-all of document processing? That it gets some things right, but creates unnecessary complications in other areas?

    HTML5 is different from SGML. I think it's better than XHTML, you apparently don't. That's fine. We can disagree about that amicably. You write in XHTML and I'll write in HTML5 and we can both be happy. I jumped on this thread not to condemn everyone as benighted who chooses to follow XHTML, but to defend the very existence of HTML5, which seems to offend some on this thread.

    HTML5 is a different approach. It flows out of practical matters. You claim HTML's "biggest advance" was to change the wording of the spec to conform to SGML. I don't see that. Instead I see how no browser under the sun parses HTML as SGML, and think the wording change in the spec therefore has had no impact at all, and I wonder if maybe we'd be better off if we just stopped pretending HTML was anything except HTML, and just get on with building.

    The position "HTML is horrid because it's not SGML" can only be valid if one accepts the proposition "only SGML is good," and I don't. I also don't accept the proposition "SGML is bad". I think SGML is good, *and* I think HTML5 is good.

    Sometimes difference only means difference. I want a spec the browser makers can implement. So far they haven't implemented SGML, so I'm wiling to use something they will implement.

    that (X)HTML5 isn't following the markup standards and is just being thrown together without any thought for the SGML standards that define how to define markup languages - is the only one that doesn't lead to contradictions in the so called standards.
    It's the unspoken premise in the above that I find most offensive. The one that says "If you don't follow every jot and tittle of SGML, you aren't thinking." It's that attitude that makes it hard to discuss this topic with any objectivity. If you can't admit that someone can read the SGML spec, and learn from it, and still want to do something a little bit different, then why not just drop any pretense of evaluating any standard that isn't SGML? After all, if SGML is perfect, then why look at anything else? And if it's not perfect, why criticize something on the sole grounds that it isn't SGML?

    I happen to think that one can rationally decide that SGML is overkill for some projects, but that one can look at SGML and take from it some good ideas without being saddled with the whole thing, and make those ideas work well in some projects.

    When you try to be all things to all projects, such as SGML tries to be, you end up with lots of baggage. It has to be there for some subsets of "all projects" that you've declared for your domain. When you don't intend to cover "all projects" you can leave some baggage behind, and you can smooth over some wrinkles.

    I've looked at the HTML5 spec and decided it makes sense to me, and seems on track for better support faster than XHTML will get, and that's good enough for me.

    I guess what it comes down to is some folks think SGML is the way to parse documents. I think it's a way. Those who take the former position should stick to XHTML. I won't.

  22. #297
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Well said ^

  23. #298
    SitePoint Enthusiast fvsch's Avatar
    Join Date
    Apr 2009
    Location
    Lyon, France
    Posts
    64
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Arlen View Post
    I've looked at the HTML5 spec and decided it makes sense to me, and seems on track for better support faster than XHTML will get, and that's good enough for me.
    I share that point of view.

    Actually, i fail to see why the compliance to the ancestor norm, 1986's SGML, would be important. Internet browsers never cared about implementing a full-featured SGML parser, but instead did their own HTML parsers and implemented rules to cope with faulty markup. And for authors and developers who want stricter rules, there is XML and applications of XML, including XHTML 1.0, XHTML 1.1, and XHTML 5.

  24. #299
    bronze trophy
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    2,670
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by zcorpan View Post
    Accesskeys have not yet received proper research and consideration, which is why they are not in the spec.
    I'm not sure if there has been further research in this area resently, but nevertheless accesskeys are now specified.

    http://html5.org/tools/web-apps-trac...m=3064&to=3065

    http://www.whatwg.org/specs/web-apps...skey-attribute

    http://www.w3.org/mid/Pine.LNX.4.62....reamhostps.com
    Simon Pieters

  25. #300
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    270
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The UK politicians are gung-ho for accesskeys, seems like opinions are pretty solidly divided everywhere else. I used them for a while, but I came around to agreeing with Joe Clark's statement, "Support is poor, they’re badly misunderstood, there are too many conflicts with browsers and operating systems, and it is virtually impossible even to make clear to the visitor what the accesskeys are."

    I think they're a good idea, and hope someday someone comes up with a way to make them happen, but I just don't see a way to do it properly. Even the UK pols stick to numeric keys, for the most part.


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
  •