SitePoint Sponsor

User Tag List

Page 5 of 6 FirstFirst 123456 LastLast
Results 101 to 125 of 148
  1. #101
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,810
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by noonnope View Post
    i believe in html 4.01 strict+css 2.1 to be a modern html
    I agree since that is the latest version.


    Quote Originally Posted by noonnope View Post
    4.01 transitional, making it's way up to html 4.01
    which is what most people are using since they are still basically using HTML 3.2 tags and only gradually upgrading/transitioning to HTML 4.

    The only part of CSS3 that is currently a standard is SVG. The rest is still in various stages of development - close to but not quite yet having reached the stage of becoming a standard.

    With the introduction of IE9 with its support for proper XHTML that will gradually become a practical alternative as earlier versions of IE die out. That should happen long before HTML5 becomes a standard as it is still in a very early draft stage.

    The doctype is supposed to identify which tags and attributes are and are not valid in a particular version of HTML (or XML or whatever other SGML based language you are using). Because browsers have their tag support built in without relying on the doctype to tell them what is and isn't valid the doctype should be optional in HTML. That it is not is due to Internet Explorer misusing it for a different purpose.

    That issue arose when CSS 2 was in an early draft stage the way HTML 5 is now. IE5 implemented support for a lot of the features that CSS2 proposed and lots of people started using them. When the standard was actually finished a number of the definitions has changed from what IE5 had implemented and so Microsoft decided to start using the doctype in IE6 to determine whether the page should follow the correct CSS2 standard or the early draft version they had implemented in IE5. With the way people are jumping on using HTML 5 tags at a similar early draft stage we will eventually need a way to tell the difference between pages that are following the final HTML 5 standard and those that follow the current early draft and everyone will be cursing the browsers that currently support HTML 5 because of all the garbage non standard web pages that they allowed to be created that don't properly follow the HTML 5 standard. Possibly it will be a short version doctype means HTML 5 quirks mode with a longer as yet to be introduced version indicating that the page follows the correct HTML 5 standard.

    Of course with HTML 4 having now been out for over 11 years and with still only about 2% of web pages following the standard it will be a very long time before any significant fraction of the web uses HTML 5 (assuming that not everyone switches to XHTML in the meantime as it should not be more than ten years at the most before it becomes practical to do that).
    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="^$">

  2. #102
    Non-Member
    Join Date
    Jun 2010
    Location
    47°27′35″N 26°18′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    you really are naughty felgal, quoting (not!) me like that!

    you are absolutely right, except some programmers wrongly use DTD to put a better label on a weaker markup, and i wrongly want to use it to put a more normal label on a transitional markup. transitional until various dirty markup tricks (very clever ones, otherwise) phase out due to the style sheet maturing. which i believe it will happen sooner than html5 agreements or cross browser support for xhtml and all the good stuff it may bring. and this is why i say html 4.01 strict+css3 will probably be the first to hit the bullseye as strict (for those willing), and html 4.01 strict+css2.1 could probably mean, given certain circumstances (very excusable circumstances), modern html 4.01 transitional.

    why not xhtml? well, imagine, if html brought such a chaos with such limited inventory, then imagine the true chaos the xhtml extensibility would bring upon us. you complain now about <object> and <video> as redundant. dare to imagine what level of redundancy could bring xhtml, and you'll see that x(ht)ml by plug-in starts to sound good.

  3. #103
    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 Stomme poes View Post
    Do we care if the browser knows what <city> is?
    Well, not if you think a web page is a pretty picture to look at. But I thought more of you than that, Poes!

    Quote Originally Posted by Stomme poes View Post
    I disagree. They don't know what an <address> is either, but they know how to treat it.
    Yes, they 'know' what an <address> is. That's how they know how to treat it, i.e., render it.

    Quote Originally Posted by Stomme poes View Post
    If you're taking data from some application (who does know what <city> means) and also displaying info on a web page, which then some other application (who also knows what <city> is) can download from, then I don't see why the browser can't continue to be stupid.
    Should we then, in your opinion, use only <div> and <span>, since the browser doesn't have to know what elements are?

    Quote Originally Posted by Stomme poes View Post
    However, Tommy brings up a good point regarding other user agents. For example, a screen reader (who's actually just sitting atop a user agent, usually a browser) needs to also know what to do with <city>.
    Precisely. And I don't know why people seem to forget about other user agents and believe that the Web is only about graphic browsers.


    Quote Originally Posted by gary.turner View Post
    For some reason applications can parse attributes but not elements?
    Of course not. But class attributes aren't meaningful to the user agent, while element type names are. Microformats are a way to present basic semantic information to general-purpose UAs, e.g., 'this is a span of characters', while at the same time passing more details to specialised UAs, e.g., 'this is the city name as part of a postal address'.

    Using new element types, like <city>, you would lose all semantics in the former case.

    Quote Originally Posted by gary.turner View Post
    Oh? Why would you need for the browser to make sense of anything except maybe replaced elements
    Oh, so you too think that a web documents is just a pretty picture? Et tu, Gary?
    Birnam wood is come to Dunsinane

  4. #104
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Well, not if you think a web page is a pretty picture to look at. But I thought more of you than that, Poes!
    The only thing a browser knows about most elements is how to render it. It does not actually extract meaning from them. An application could though. I don't really see what pictures have to do with anything??

    Yes, they 'know' what an <address> is. That's how they know how to treat it, i.e., render it.
    But they don't know it's an address. Was kinda the whole point of the microformats... the browser still doesn't know it's an address, but someone's goofy PDA reading the page does, and is able to take the stuff inside and shove it appropriately into its addressbook.
    If we told the application what <city> was, and <street>, then after grabbing from the dumb browser, it could not only place the city in the proper "city" section, but now you can look up people in your addressbook by city.

    Or whatever, I'm not really hip enough to get enthousiastic with the whole "real XHTML/microformats" stuff, but I understand what they want to accomplish.

    Should we then, in your opinion, use only <div> and <span>, since the browser doesn't have to know what elements are?
    That only gives you two options of information. Gary mentioned extensibility of XHTML. I never thought that had anything to do with browsers actually learning the meaning of anything (it's still going to see things as blocks, inlines, whatever you or the vendor tells it).

    Using new element types, like <city>, you would lose all semantics in the former case.
    Whether we're talking about Gary's <city> within a real XHTML page (with its own DTD) or a microformat bloat like <span class="city">, the semantics are the same (aren't they? If not, why not?). One looks cleaner. The other makes overuse of spans and divs and class attributes.

    <address>
    <span class="name">Joe</span>
    <span class="streetaddress">Hondenpoeplaan 5</span>
    <span class="postalcode">1234 GG </span>
    <span class="city">Borculo</span>
    <span class="country">People's Republic of Foo</span>
    </address>

    Or
    <address>
    <name>Joe</name>
    <streetaddress>Hondenpoeplaan 5</streetaddress>
    <postalcode>1234 GG</postalcode>
    <city>Borculo</city>
    <country>People's Republic of Foo</country>
    </address>

    It's no dream of mine, but again, I can see why people want it.

  5. #105
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AutisticCuckoo View Post
    Well, not if you think a web page is a pretty picture to look at. But I thought more of you than that, Poes!
    I'll add comment to that lower down, where you call me out by name.

    Yes, they 'know' what an <address> is. That's how they know how to treat it, i.e., render it.
    No they don't. Without a style sheet, or cfg file, whether built in or separate, the UA has not a clue. The entire document would render as an inline string.

    Should we then, in your opinion, use only <div> and <span>, since the browser doesn't have to know what elements are?
    Of course not. Those element and attribute tokens are used to build a DOM structure which the stylesheet, client script, or other application uses to render visually, aurally, or as in an earlier example, turn on the coffee maker.


    Precisely. And I don't know why people seem to forget about other user agents and believe that the Web is only about graphic browsers.
    Yeah, what I said.

    Of course not. But class attributes aren't meaningful to the user agent, while element type names are. Microformats are a way to present basic semantic information to general-purpose UAs, e.g., 'this is a span of characters', while at the same time passing more details to specialised UAs, e.g., 'this is the city name as part of a postal address'.

    Using new element types, like <city>, you would lose all semantics in the former case.
    Microformats are a way to present basic semantic information to general-purpose UAs, […] while at the same time passing more details to specialised UAs, […]. Exactly, as a kluge to counter the lack of xhtml support by the majority browser. Their time and efforts would certainly have been better spent developing standardized xhtml+xml schemata, but that was impossible.

    Oh, so you too think that a web documents is just a pretty picture? Et tu, Gary?
    No, Tommy, I think the web document is one with markup that tells the user just what the content is. The user might be me and my Iceweasel sitting at my desk reading these comments, or might be my hypothetical coffee maker, or a screen reader application. In every case, there are instructions for what to do with the content: make this font 24px, make that element float right, make that word louder, use 113ml of water, 40g of coffee, and start brewing at 0630.

    XHTML allows the author to expand the vocabulary and define its relationships within the structure, making for a finer granularity of meanings. There is no way that is less semantic or useful than the Microformat scheme. I can easily imagine incorporating many of the class tokens into an xhtml extension, and the work of the wg is not wasted. There was much thought put into Microformat that is readily transferable to xhtml if MSFT gets off their collective ass and makes it work for IE (and it's not so late that developers have completely given up, or are overly vested in Microformat parsers). Each time I go to Allsopp's book, I am knocked over anew by some little something that manages to make the whole concept that much more robust, something I would likely have missed.

    cheers,

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  6. #106
    Non-Member
    Join Date
    Jun 2010
    Location
    47°27′35″N 26°18′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by gary.turner View Post
    XHTML allows the author to expand the vocabulary...
    maybe i'm not seeing it right. xhtml expands the language not the vocabulary.

    an example: <span class="city">Paris</city> is the expansion of vocabulary, like <noun class="city">Paris</noun> would be for the human language. doing <city>Paris</city> it's like creating new language elements for each word you like. and doing so, the language elements would surpase in number the actual words used in a language. how would you be able then to make sense of the grammar of a language? html is for displaying the info. xhtml wrongly understood uses html as grounds for data exchange, when it's supposed to enrich the way data is presented, instead.

    xhtml used for <city> adds new language elements that have no general semantic meaning, only locally declared meaning. how many specs would invade the web, trying to keep track of everybody's imagination. and how much redundancy would cause that?

    this use:
    Quote Originally Posted by Stomme poes View Post
    <address>
    <name>Joe</name>
    <streetaddress>Hondenpoeplaan 5</streetaddress>
    <postalcode>1234 GG</postalcode>
    <city>Borculo</city>
    <country>People's Republic of Foo</country>
    </address>
    needs to be correlated with some way of rendering, other that a DTD and CSS, in order to make sense to everybody. you're using <streetaddress>Hondenpoeplaan 5</streetaddress> and hope that 60-80&#37; off all the people reading it would understand basic english. when changed to <عنوان الشارع>Hondenpoeplaan 5</عنوان الشارع> then this would drastically change your view on the extensibility of xhtml.

    these (DTD and CSS) are the easy way to go. we need standardized ways for xhtml. like svg, or flash. that's why a plug-in for this make more sense, keeping it out from clouding the html markup.

  7. #107
    Non-Member
    Join Date
    Jun 2010
    Location
    47°27′35″N 26°18′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    sorry, errata:

    <span class="city">Paris</city>

    is in fact

    <span class="city">Paris</span>

    and no, flash it's not a x(ht)ml i was just in a hurry to make a point while having somebody standing behind me

  8. #108
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    needs to be correlated with some way of rendering, other that a DTD and CSS, in order to make sense to everybody. you're using <streetaddress>Hondenpoeplaan 5</streetaddress> and hope that 60-80% off all the people reading it would understand basic english
    Yes did you not realise that's the point of XHTML? You would indeed have to make your own DTD if you are using your own tags. And basic English has nothing to do with it. What kinds of tags do you think Japanese pages use?

  9. #109
    Non-Member
    Join Date
    Jun 2010
    Location
    47°27′35″N 26°18′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Yes did you not realise that's the point of XHTML? You would indeed have to make your own DTD if you are using your own tags. And basic English has nothing to do with it. What kinds of tags do you think Japanese pages use?
    precisely my point: Japanese pages use html tags. who's stopping them to use japanese for their xhtml tags? would then basic english have something to do with you, a japanese illiterate?

  10. #110
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    who's stopping them to use japanese for their xhtml tags?
    Internet Exploder.

  11. #111
    Non-Member
    Join Date
    Jun 2010
    Location
    47°27′35″N 26°18′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i don't see ie stopping you though ok, don't like japanese? maybe dutch is your thing then? but i thought that there every town can have it's own little language.

    don't you see that's not the point of x(ht)ml? it's only one of it's possible uses, and not even the smartest one.

  12. #112
    Non-Member
    Join Date
    Jun 2010
    Location
    47°27′35″N 26°18′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i hope not to upset you, but i think that ie is possible to have been right when chose not to support xhtml.

    they did a smarter thing though: they allowed xml islands. and kept html clean. parsing their (xml islands) content could have been done also by a plug-in, to handle easily complex uses.

    take a look at this scenario: if all browsers would have supported <xml> tag, many wrong uses for xhtml could have been avoided, and semantics spared. the same thing if ie would have supported xhtml, but still having all these problems concerning semantics.

    given the existing situation, one possible scenario would be the following:
    - use xml islands for ie
    - use xhtml for the the rest, but only to allow an <xml> element

    all your data, described by microformats or by a personal DTD, should go inside these type of elements. it would make much more sense.

  13. #113
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,810
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by noonnope View Post
    i don't see ie stopping you though ;
    Well XHTML doesn't work in any version of IE prior to IE9 and so if you use XHTML you immediately discard all of your possible visitors who insist on using IE8 or earlier.

    XHTML will demonstrate its full power once IE8 is dead as those browsers are yet to support the 1999 standard that introduced XHTML
    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="^$">

  14. #114
    Non-Member
    Join Date
    Jun 2010
    Location
    47°27′35″N 26°18′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i beg to differ. the real power of xhtml is xml. and xml could be easily put to work if <xml> element would've been implemented across browsers. much easier than three (useless) whole new specs, each with its problems.

    an example of a possible xml island, related to one presented earlier:

    HTML Code:
    <xml class="address">
    <name>Joe</name>
    <streetaddress>Hondenpoeplaan 5</streetaddress>
    <postalcode>1234 GG</postalcode>
    <city>Borculo</city>
    <country>People's Republic of Foo</country>
    </xml>
    sounds a whole lot better than the redundancy employed by the false extensibility of xhtml. you can wrap pretty much every xml sequence in there, and still get away with semantics. the content of an element has little to do with that. once wrapped between <xml> tags, the content stops being about tags defining elements, and the rest being the content. all that is now content.

    given the right implementation, to work around those tags inside xml islands, and doing something on the line of <dl> element to provide two types of subelements describing the xml element (xml-dt, xml-dd): info for the name and use of the custom tags used, and the actual xml sequence, this is something i was looking since four years ago and hoped until this day that it will become real. still do. and it's better for me than xhtml.

    on the other hand, a new borne breed of elements that can be tagged with any mambo-jumbo string, will puzzle you useless, giving you a sense of overwhelming. and 90&#37; of the time only looking to carry data for lazy programmers looking for shortcuts. or confusing vocabulary with lexical elements.

  15. #115
    Programming Team silver trophybronze trophy
    Mittineague's Avatar
    Join Date
    Jul 2005
    Location
    West Springfield, Massachusetts
    Posts
    17,156
    Mentioned
    190 Post(s)
    Tagged
    2 Thread(s)
    I was under the impression that XHTML is XML.

    The first line my pages serve to browsers that HTTP_ACCEPT application/xhtml+xml after the HTTP headers are sent is:
    Code XML:
    <?xml version='1.0' encoding='utf-8'?>

  16. #116
    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 Stomme poes View Post
    The only thing a browser knows about most elements is how to render it.
    Because that's all it's asked to do. But it could also use its built-in knowledge about headings to generate an automatic table of contents (some screen readers can do this, I believe). The point is that it 'knows' a closed set of element types and there is no way, except plug-ins and similar, to extend that set.

    Quote Originally Posted by Stomme poes View Post
    It does not actually extract meaning from them. An application could though.
    Sir Tim's dream about a semantic web relies on user agents 'understanding' the markup. Homegrown tag names will not make that possible.

    Quote Originally Posted by Stomme poes View Post
    I don't really see what pictures have to do with anything??
    Without semantics a web page is nothing more than a picture to look at. It has no meaning for applications which cannot interpret the visual information.

    Quote Originally Posted by Stomme poes View Post
    But they don't know it's an address.
    It isn't necessarily an address, but it is – at least it's supposed to be – contact information. Browsers 'know' this and could – in the ideal world where web authors knew what they were doing – use this to provide a means for getting in touch with the author. They couldn't do that if you chose to call it <postadress> and I chose to call it <contact> and Gary chose to call it <getintouch>, though.

    Element types must be pre-defined and known to be useful. Web semantics is about making information meaningful to software, not about using markup that is human-readable.

    Quote Originally Posted by Stomme poes View Post
    If we told the application what <city> was, and <street>, then after grabbing from the dumb browser, it could not only place the city in the proper "city" section, but now you can look up people in your addressbook by city.
    Yes, that's exactly the problem: we'd have to tell the application what <city> and <street> means. To a general-purpose UA, such as a browser, it's nonsense. If we use <span> with class attributes, however, we give even browsers at least a hint about what it is.

    Quote Originally Posted by Stomme poes View Post
    Or whatever, I'm not really hip enough to get enthousiastic with the whole "real XHTML/microformats" stuff, but I understand what they want to accomplish.
    Microformats is a way to add something approaching semantic meaning in a way that doesn't break backwards compatibility, which adding new element types would do.

    Quote Originally Posted by Stomme poes View Post
    Whether we're talking about Gary's <city> within a real XHTML page (with its own DTD) or a microformat bloat like <span class="city">, the semantics are the same (aren't they? If not, why not?).
    No!
    <city> has no semantics to a browser because it's completely unknown. It could equally well be <town> or <stad> or <cité> or <fztwqln>.

    Whereas <span class="city"> at least tells the browser that it's a span of characters that has some sort of special meaning.

    Quote Originally Posted by Stomme poes View Post
    One looks cleaner. The other makes overuse of spans and divs and class attributes.
    Yes, but semantics is not about making markup easy to read for people!.

    Quote Originally Posted by gary.turner View Post
    No they don't. Without a style sheet, or cfg file, whether built in or separate, the UA has not a clue. The entire document would render as an inline string.
    Now you're being silly, Gary. The UA style sheet is an integral part of the browser. Even Lynx has one, after a fashion.

    Quote Originally Posted by gary.turner View Post
    Exactly, as a kluge to counter the lack of xhtml support by the majority browser.
    So tell me how an XHTML-supporting browser (plus a search engine 'bot and a screen reader) would be able to understand arbitrary homegrown markup. You can't specify semantics in a DTD, only grammar.

    Quote Originally Posted by gary.turner View Post
    No, Tommy, I think the web document is one with markup that tells the user just what the content is.
    That is where you are wrong, Gary. The markup tells user agents what the content is; not human users. <city> isn't semantic because an English-speaking person understands the word.

    I'll say it again, since it seems that this is a point that a lot of people are missing:

    Web semantics is about conveying meaning to software, not about writing markup that is self-documenting for human beings.

    I know it's hard to believe for us professionals, but most users out there actually don't even look at the source code of most sites they visit!
    Birnam wood is come to Dunsinane

  17. #117
    Non-Member
    Join Date
    Jun 2010
    Location
    47°27′35″N 26°18′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Mittineague View Post
    I was under the impression that XHTML is XML.
    it probably is. depends on the programmer. while you can get away with lousy xhtml, if you use xml for other than a web page, you cannot make mistakes, or you'll be punished swiftly. that's why xhtml does not equal xml. an invalid xhtml document will always be used, while an xml malformed document will never be usable. these two are not synonymous.

    and i don't know if every xml document out there has an <html> tag in it xhtml declares to be xml, but nobody cares much if it is so.

  18. #118
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,810
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by noonnope View Post
    it probably is. depends on the programmer. while you can get away with lousy xhtml, if you use xml for other than a web page, you cannot make mistakes, or you'll be punished swiftly. that's why xhtml does not equal xml. an invalid xhtml document will always be used, while an xml malformed document will never be usable. these two are not synonymous.
    Yes they are since one error in an XHTML page will cause the page to not render - because XHTML is XML and applies all the same rules with the addition of those that apply to the specific variant of XML that goes by the name XHTML.

    You are getting it confused with HTML which does allow you to get away with errors in the markup such as omitting tags or using the wrong doctype (such as attaching an XHTML doctype to your HTML web page).

    To determine whether a web page is HTML or XHTML you look at the MIME type - if it is text/html then it is HTML and if it is application/xml+xhtml then it is XHTML.

    All modern browsers with the exception of IE8 (and earlier) can process web pages written using XHTML (including IE9). If you try to serve a page written in XHTML to IE8 it will offer it for download because it doesn't know how to display it. Make a single mistake in your XHTML markup and because it follows XML rules you end up with nothing displaying at all.

    See http://www.felgall.com/realxhtml.php for a very simple page written using XHTML and you will see exactly how different browsers treat it.
    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. #119
    Non-Member
    Join Date
    Jun 2010
    Location
    47°27′35″N 26°18′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    thanks for info and link, felgall. could you please provide also a link to a "broken" xhtml? i would like to see how it renders (or not) in browsers that support application/xhtml+xml. thanks.

  20. #120
    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)
    Well, that is easy just get a well-formed XHTML document and delete a closing tag for example the closing </p> in Stephen's 'example page' then serve it as: application/xhtml+xml.

    Else you may be able to "cheat" if you have a XHTML Compatible browser like Firefox by changing the extension to *.xht and viewing it offline. It will probably assume it is a x(ht)ml document and "try" and render it as such... but of course it won't be able to render the page without it displaying a "warning".

    For example you may see something like:

    Code:
    XML Parsing Error: mismatched tag. Expected: </p>.
    Location: file:///C:/realxhtml.xht
    Line Number 7, Column 3</body></html>
    --^
    Because it uses a real XML Processor.

  21. #121
    Non-Member
    Join Date
    Jun 2010
    Location
    47°27′35″N 26°18′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by xhtmlcoder View Post
    Because it uses a real XML Processor.
    thanks xhtmlcoder. that's the point i was getting at

    xhtml is treated like xml by a xml parser. but you can choose to parse it as html; when invalid, when desired. and the <?xml...> can be ommited. you can't fool around like that with xml in a real world application. so xhtml it's not xml.

  22. #122
    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)
    It is an application of XML a reformulation of HTML thus all XHTML documents are XML conforming.

    Yes, they should begin with an XML declaration and it uses XML type grammar and a namespace and is at bare minimum well-formed markup. Ideally it should be sent through an XML Processor but if it gets sent as 'text/html' then obviously it won't halt on errors and isn't treated as x(ht)ml.

    Code:
    <?xml version="1.0" encoding="UTF-8"?>
    <something>
      <p>
        <img src="example.png" alt="*"/>
      </p>
    </something>
    But theoretically you could do the exact same with XML (code example) send it as 'text/html' obviously completely pointless but possible.
    Last edited by xhtmlcoder; Jul 22, 2010 at 06:34. Reason: Typographical issues.

  23. #123
    Non-Member
    Join Date
    Jun 2010
    Location
    47°27′35″N 26°18′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by xhtmlcoder View Post
    It is an application of XML a reformulation of HTML thus all XHTML documents are XML conforming.
    and also theoretically xhtml would still be good while xml will not (see below). so maybe it's conforming but it's not xml.

    Quote Originally Posted by xhtmlcoder View Post
    But theoretically you could do the exact same with XML (code example) send it as 'text/html' obviously completely pointless but possible.
    no, that would be a string that resembles xml. and xhtml sent as 'text/html' still translates to something rather than a string: it can be parsed, doesn't need escaping. that's why i've said this before felgall's example:
    Quote Originally Posted by noonnope View Post
    it probably is. depends on the programmer. while you can get away with lousy xhtml, if you use xml [...] you cannot make mistakes, or you'll be punished swiftly. that's why xhtml does not equal xml. an invalid xhtml document will always be used, while an xml malformed document will never be usable. these two are not synonymous.
    many (and i was, at first, one of them) understand xhtml like a UA has to, as a two lane highway: text/html or maybe, if i want, application/xhtml+xml. well, it's not quite right. it's a one way highway. that and the common wrong use, makes the term xhtml not to be associated with xml. it's just a mongrel. and i believe by the time ie8 dies, xhtml would have lived its days as a favourite pet. that doesn't affect its presently insignificant usability compared with its initial higher purpose.

  24. #124
    Programming Team silver trophybronze trophy
    Mittineague's Avatar
    Join Date
    Jul 2005
    Location
    West Springfield, Massachusetts
    Posts
    17,156
    Mentioned
    190 Post(s)
    Tagged
    2 Thread(s)
    I purposely bugged my index page (for a few seconds) by taking out a closing unordered list tag to get this in Firefox

    Note that it doesn't say XHTML error.

    I don't understand how you can say it isn't XML when clearly it is.

    Sure, I could remove the opening declaration and then it wouldn't be XML.
    But I could remove the opening declaration from an XML file too and then that wouldn't be XML either.

  25. #125
    Non-Member
    Join Date
    Jun 2010
    Location
    47°27′35″N 26°18′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    xhtml it will be xml when it will be treated and parsed always as xml. it's not xhtml because it can be parsed as xml and as html also, is it? it's xhtml because
    Quote Originally Posted by xhtmlcoder View Post
    It is an application of XML
    isn't it?


    Quote Originally Posted by Mittineague View Post
    Sure, I could remove the opening declaration and then it wouldn't be XML.
    would it be treated like one if served as application/xhtml+xml?

    Quote Originally Posted by Mittineague View Post
    But I could remove the opening declaration from an XML file too and then that wouldn't be XML either.
    true. i don't see where this is going, though, related to xhtml.


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
  •