SitePoint Sponsor

User Tag List

Page 4 of 6 FirstFirst 123456 LastLast
Results 76 to 100 of 148
  1. #76
    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 rguy84 View Post
    This article shows you how to write your own DTD
    I wish I'd seen that back in early 2004 when I was starting to work with xhtml. In June of that year, I had a small demo on my then site. I moved the archived page to my present site a few minutes ago.

    It's a damned shame MSFT has seen fit to not support xhtml. Were it supported, we'd not need that microformatting hackish work-around or half of html5.

    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

  2. #77
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @gary.turner:

  3. #78
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by rguy84 View Post
    noonnope, I ask if you have read through a DTD. This article shows you how to write your own DTD, which may help you some: http://csharpcomputing.com/XMLTutorial/Lesson8.htm

    replace xml with html for that page.
    actually i have: the one in question, here.

    and my whole point revolves around these excerpts:

    The HTML 4.01 specification includes additional
    syntactic constraints that cannot be expressed within
    the DTDs.
    which a developer should account for before putting a DTD on it's code.



    This is HTML 4.01 Strict DTD, which excludes the presentation
    attributes and elements that W3C expects to phase out as
    support for style sheets matures. Authors should use the Strict
    DTD when possible, but may use the Transitional DTD when support
    for presentation attribute and elements is required.
    today, while still using html 4.01 DTD, presentational structures that employ the use of empty divs or spans, like certain rounded corners or image replacement techniques
    expects to phase out as
    support for style sheets matures.
    and, as such,
    Authors should use the Strict
    DTD when possible, but may use the Transitional DTD when support
    for presentation attribute and elements is required.
    which i believe should be "updated" (as in a way of thinking, modern days coding extrapolation, not actual modifications in DTDs or specs) like this:
    [...] when support
    for presentation attribute and elements and presentation element structures is required

  4. #79
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,862
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by gary.turner View Post
    It's a damned shame MSFT has seen fit to not support xhtml. Were it supported, we'd not need that microformatting hackish work-around or half of html5.
    Microsoft have a demo XHTML page to showcase their XHTML support in IE9 at http://ie.microsoft.com/testdrive/HT.../Default.xhtml

    Once IE8 use falls low enough XHTML will become a practical alternative. That should happen long before HTML5 is finished.
    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="^$">

  5. #80
    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 gary.turner View Post
    It's a damned shame MSFT has seen fit to not support xhtml. Were it supported, we'd not need that microformatting hackish work-around or half of html5.
    Gary, now you're talking cross-eyed badger's spit!

    One word: semantics.
    Birnam wood is come to Dunsinane

  6. #81
    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
    Gary, now you're talking cross-eyed badger's spit!

    One word: semantics.
    How is a schema of semantic elements not semantic, not to mention less klugish than microformats. I understand the reason for microformats, and use them, but they could have been in the form of public xhtml schemata had IE supported xhtml. The same reasoning is valid vis &#224; vis many of html5's new elements.

    Please elucidate your position, Tommy, as I live too far south to have experience with cross-eyed badgers, spitting or otherwise.

    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

  7. #82
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    Maybe it's special to Sweden. I'm sure the badgers get pretty weird with 10 months of winter and all.

  8. #83
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    given this comment of AutisticCuckoo, which i believe has the most relevance so far, i think it's time for some various conclusions i got from posts.

    what impact has the use of html 4.01 transitional DTD for an otherwise html 4.01 strict markup, that has been "compromised", a so called "modern transitional", due to the use of some techniques, that involve markup with no links whatsoever to the actual content?

    for that, i think i best start defining what a DTD declaration does and what it doesn't.



    1. is the DTD declaration that important that i cannot change it easily?

    no. it has very little importance as content.

    it has some importance as a presence or as an absence. it has some importance for validation, but the validation it self has little importance.



    2. a change in the DTD declaration, from
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
    to
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
    affects how browsers understand my markup.

    no. the lack of it does, the change of it doesn't do much difference.

    browsers use DTD declaration as a switch between standard and quirks mode. as a general rule, the lack of DTD declaration triggers quirks mode. the presence of it triggers standard mode.

    there are a few (situation, browser) couples, when an almost standard mode is triggered, which i believe don't apply to this specific (scenario, time).



    3. a change of the DTD declaration, from
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
    to
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
    affects how your code validates when using a validator.

    no. a validator has limitations, and could possibly describe a markup as strict when, in fact, that markup has broken simple rules: like block-level elements in a paragraph element.

    using a DTD declaration to validate with a validator and obtaining an icon from it, it's not by it self proof enough that the markup is complying with a DTD or another. this is a developer's job.



    4. html 4.01 transitional DTD is to be used only to describe documents that have yet to make the transition from html 3.2 to html 4.01.

    arguable. we have to wait a long period of time until new specs are being developed, and even longer until they become standards in use.

    in the mean time, definitions and specs need to be reinterpreted and aligned with the new techniques and developments emearging. these cannot all be predicted at the time when specs are created. if it was possible, i'm sure such practices would be amended at the time, as many others are (like the use of empty <p> elements).



    5. a html 4.01 DTD transitional should not be used for newly created html documents.

    arguable. transitional means obtaining a separation between presentation and content, given some time.

    a period of transition is needed for some presentation elements and attributes to phase out as the support for style sheets mature. if new developments emerging are pointing to similar transitional coding behaviours in a document, but different in the nature of the elements involved, that have prospects of phasing out due to the style sheets maturing, i believe those qualify the document as transitional also.

    while it's pretty obvious that <div> and <span> don't fall in the deprecated elements category, using them as empty shells, outside the actual content borders, then this kind of use can be described as "modern transitional".



    6. are certain rounded corners techniques or image replacements techniques, presentation only constructs?

    yes. they employ the use of valid strict markup code, but for the wrong purpose when it comes to separation between presentation and content.

    the question is: is it that wrong? no, but it isn't right also. no matter how "correct" technically speaking, their simple use to achieve such presentational features it's not the job to be used for: to work with the actual content alone.



    7. using the DTD declaration to flag a markup (using the above mentioned techniques) as being "compromised", is this a wrong thing?

    no. this is the first thing a DTD declaration does: flags a markup.



    unrelated conclusions.

    1. is it wrong to question the use of something that is noting more than a recommendation?
    yes. but only if you live in a dictatorship.

    2. is my english broken and makes it harder for readers to understand my points?
    yes. but i promise to make it better.

    3. do i feel threatened by other's knowledge and have a viral response for any standing in my way?
    no, not at all. i respect it and i try to assimilate the good stuff.

    4. is this thread useless?
    yes. if you have rules you don't want to go over again.

  9. #84
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    or, to make it short:
    - yes, continue coding using html 4.01 strict specs. it's a very good idea. transitional specs don't count in this story.
    - no, don't think that using a DTD declaration and having a validator's icon will make your markup a html 4.01 strict compliant one. it's like going to the moon jules verne's way. or should i mention baron m&#252;nchhausen here. don't expect a magical wand to turn your code honest. do it your self, or die trying. if not possible yet, flag it.
    - yes, future can bring you ways and coding techniques (rounded corners, image replacement,...) that will screw up your otherwise strict markup. don't blame it on the past. while you are free to embrace any of them, and some will even help you end up with a technically speaking strict markup, their use means you'll never have a strict markup on your hands. or should i say: the operation was a complete success. too bad the patient is dead.
    - yes, you are free to be the first to recognize and acknowledge this. also you are free to stay away from such a stupid thing to do. if your choice is not properly explained and sustained (and understood, i might add), it will make you feel a lesser developer in the eyes of your fellow programmers and clients. some will see your point, but most will call it plain stupid. in the end, it really doesn't matter if you change this DTD. not to your code, not to the browsers, nor validators. only to yourself.

  10. #85
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,862
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    That's only true if you pay as little attention to what the doctype actually means as the major browsers do.

    If browsers ever actually start using the doctype for what it is intended instead of definiing their own internal version of HTML then any web page that has used the wrong doctype will be instantly broken.

    Of course this is far more likely to happen after IE8 dies off and everyone starts using XHTML instead of HTMLbut there are possibly already browsers out there that actually use the doctype but just are not yet popular enough for them to be noticed. Using the wrong doctype will break your page in any browser that uses the doctype properly and so will at least potentially reduce the number of visitors who see your page correctly.
    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="^$">

  11. #86
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    you are probably right. although what i'm suggesting it's in no way something that will cause major problems.

    i've seen so many improper uses of the doctype from authors part (even from high rollers), and so little cases in which the use of a specific doctype actually makes sense (something along the lines of html vs xhtml choice arguments and uses), i'm not worried user agents are going to take a leap of faith regarding authors discernment on this matter, real soon.

    until then i refuse to make DTD declaration slave to a trivial validation personal benefit. i choose to make a statement by it, acknowledging the fact that i have compromised a concept in favour of common usability.

  12. #87
    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 gary.turner View Post
    How is a schema of semantic elements not semantic, not to mention less klugish than microformats.
    Because a user-defined schema cannot convey semantics. Oh, you can make up element type names that look meaningful to a human, and you can use CSS to style those elements in browsers. But user agents including search engines still don't 'understand' what <city> means. They do 'understand' what <span class="city"> means, though (albeit they ignore the class name).

    The extensibility of XHTML is largely a myth. You need browser plugins or new browser versions to make sense of new element types, and when you include other types of user agents the picture gets even more complicated.

    Quote Originally Posted by gary.turner View Post
    I live too far south to have experience with cross-eyed badgers, spitting or otherwise.
    And you're obviously not a fan of Douglas Adams.
    Birnam wood is come to Dunsinane

  13. #88
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    You need browser plugins or new browser versions to make sense of new element types, and when you include other types of user agents the picture gets even more complicated.
    Do we care if the browser knows what <city> is? 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.

    Do the two applications need to understand <city>? Yes (maybe). However, if you're the programmer for those applications, esp when using real XHTML internally, I would expect s/he built that in.

  14. #89
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    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?
    html speaking, we do.

    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.
    are you describing <object> here? if we take data from some application (flash stream) and also display info on a web page (stream it), which then some other application can download from (play it), then the browser is stupid. do we need to make pages in flash alone? or plug-in it to death?

    Quote Originally Posted by Stomme poes View Post
    Do the two applications need to understand <city>? Yes (maybe). However, if you're the programmer for those applications, esp when using real XHTML internally, I would expect s/he built that in.
    you could employ any other data exchange format, x(ht)ml is not necessarily the best option out there, for all the use cases you can think of.

  15. #90
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    html speaking, we do.
    I disagree. They don't know what an <address> is either, but they know how to treat it. 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>.

    are you describing <object> here?
    No. I'm describing <city>.

    ...do we need to make pages in flash alone?
    That would never be a position of mine, seeing's how I do not have the Flash player and frequently come across pages with zero content for me because they are solely made of Flash. As Jason likes to say, there's a reason it's called Flash and not Substance.

    you could employ any other data exchange format, x(ht)ml is not necessarily the best option out there, for all the use cases you can think of.
    Could, yes. The whole idea of the benefit of XHTML was to have more freedom taking data in XML and being able to also display it on a web page. Since that didn't happen due to IE, you are correct: if our data format is JSON, we need some application to turn that data into HTML for the web, just as we still need some application to turn XML into HTML for the web.

  16. #91
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    what about if x(ht)ml would've been made possible in html through a plugin? it would've served your purpose better? after all, it's taking data in a format and displaying it along side another format.

  17. #92
    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
    Because a user-defined schema cannot convey semantics. Oh, you can make up element type names that look meaningful to a human, and you can use CSS to style those elements in browsers. But user agents including search engines still don't 'understand' what <city> means. They do 'understand' what <span class="city"> means, though (albeit they ignore the class name).
    For some reason applications can parse attributes but not elements?

    The extensibility of XHTML is largely a myth. You need browser plugins or new browser versions to make sense of new element types, and when you include other types of user agents the picture gets even more complicated.
    Oh? Why would you need for the browser to make sense of anything except maybe replaced elements, e.g. <img />, <object>, <hr />, &c., and those aren't data elements, so I strongly doubt an author would be creating <canvas> on his own. I imagine that the extensible part would continue to be data oriented, aimed at UAs that can use the document's data. Consider the networked automatic coffee maker. Wouldn't it know how to use the content of <starttime>, <cups> and <strength>?

    And you're obviously not a fan of Douglas Adams.
    Well, it has been 25 years or so since I read first three, become bored with the fourth and put it aside. I have been trying, but cannot recall a reference to a cross-eyed badger in the books, the TV series, or the movie. Sorry.

    Quote Originally Posted by Stomme poes View Post
    Do we care if the browser knows what <city> is? 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.
    Do the two applications need to understand <city>? Yes (maybe). However, if you're the programmer for those applications, esp when using real XHTML internally, I would expect s/he built that in.
    She's not at all a stomme 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. 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>.
    That' s what the aural properties are for. Just as css can control visual rendering, it can control aural rendering if W3, and, I suppose the reader vendors, ever gets around to specifying it.

    The whole idea of the benefit of XHTML was to have more freedom taking data in XML and being able to also display it on a web page. Since that didn't happen due to IE, you are correct: if our data format is JSON, we need some application to turn that data into HTML for the web, just as we still need some application to turn XML into HTML for the web.
    XHTML offers the best of both html and xml; an xml data structure combined with the ease of writing html.

    Curse you MSFT!

    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

  18. #93
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    That' s what the aural properties are for.
    I dunno who actually uses those. Right now I can tell UPPERCASE from lowercase by voice tone... dunno if I'd want authors screwing with that, or adding new voices (for Dutch in JAWS there's a Dutch chick voice and a Belgian chick voice and I think a Dutch man voice... but I prefer the English Reid because it sounds like MC Hawking (cosmologist by day, gangsta rapper by night)).

  19. #94
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    let's take, for example, other languages... like human languages.

    now, semantic is delivered by using certain language elements: verbs, nouns, adjectives, using certain rules. and this doesn't restrict one's vocabulary not a single bit, you can always add new words to it.

    xhtml, on the other hand, it's not doing that at all, with it's extensibility: you can use new constructs, like <city>, but where is the generally accepted definition that classify it's use and it's place in the language? having none of those, it lacks semantics.

    but in html, you can always build any number of new "words" by using any combination of the existing elements, words that will have semantic written all over them.

    going further with the analogy between human languages and xhtml, if we were to open the dam, and permit everyone to use constructs that only he/she&family co. can understand and decipher, semantic would become obsolete. but, then, it will only make thing worse, because, as it is,
    Le langage est source de malentendus. (Language is the source of misunderstandings.)
    Antoine de Saint Exup&#233;ry - Le Petit Prince (1943) (The Little Prince)

    the world would be full of dialects, like in the times when tribes were the most advanced human social structures, and no google translate could ever help us understand one another.

  20. #95
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    the world would be full of dialects, like in the times when tribes were the most advanced human social structures, and no google translate could ever help us understand one another.
    If you're under the impression that the world isn't full of dialects of the likes teh Googles cannot translate, come visit my country, where each town can have it's own little language : )

  21. #96
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    imagine every little street in every little town or city having it's own dialect. this is what i'm talking about.

    Off Topic:

    coincidently, i've been in your country, but only passing by, in a car. you know, cross the belgium-netherlands border, then netherlands-belgium border. but i must say i loved what i've seen: houses, nature. and good people of course


    and you're talking more likely about regionalisms, constructs with common roots, that differ in a way one from another. like in which rounded corner technique to use, not something entirely new. every region that uses a root of a language, may have different way of saying things, but they all say it the same way, using the same language elements, and that is making it easy for foreigners to learn.

  22. #97
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    the more i think of it, the more i believe that the whole x(ht)ml handled by a plug-in (something like SVG, but more generally speaking), would have been bigger than flash. it's not late.

    mixing it up with html, only blurred things up. only for the sake of self closing tags and other coding rules, the way it is used now doesn't justify it's existence. examples are numerous. if you take a short look at recent documentation provided even by big players (or even main pages), you'll see xhmtl using tables for layout. in this day and age. and they release wysiwyg solutions involving web technologies. it's the same paradox found in developers embracing a spec or another only by name, not by the meaning of it.

    i believe that xhtml is the main culprit when it comes to the html5 draft and it's weird proposals. if it was only concentrating around html issues the future would be spelled consensus.

  23. #98
    SitePoint Member zbatia's Avatar
    Join Date
    Jun 2007
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Unhappy

    I enjoyed this conversation even not participating in it. After all, to summarize, I guess we should move out of HTML 4.x standard the same way as we moved out of Netscape browser. Enough to talk about old stuff.

    The difficulties with the new standard (beyond all others mentioned here) are also in the fact that we still have to use multiple browsers (and many of them are micro browsers for mobile devices). And how about 508 standard? Each of them has its own character and capabilities, and to design the web page 100% based on the standards and to satisfy all of them is close to impossible. You will need much more time spent on design to follow the standard and ensure the compatibility. This is a reason why many web designers (including myself) use the tables with XHTML standard. The tables are nice shortcuts to the compatible content with no headache since every browser surely supports the tables.

    This kind of opinion exchange is very useful (due to shared knowledge) but the question is "will your opinion be heard by those who develops the standards"?

  24. #99
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,862
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by zbatia View Post
    I enjoyed this conversation even not participating in it. After all, to summarize, I guess we should move out of HTML 4.x standard the same way as we moved out of Netscape browser. Enough to talk about old stuff.
    But one aspect of this whole discussion has been due to the fact that about 98% of the web has yet to finish updating to HTML 4.

    Also HTML 4 is the latest standard and probably will be for quite a few years yet. HTML 5 is still and early draft and will probably take many years and go through many changes before it becomes a standard (by which time IE8 will have died and everyone will be converting to use XHTML since as IE9 does support XHTML there will then be no reason to not use it).

    Anyway a growing number of people are moving toward the latest "Netscape" browser only it was basically renamed Firefox when it became open source.
    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="^$">

  25. #100
    Non-Member
    Join Date
    Jun 2010
    Location
    4727′35″N 2618′0″E
    Posts
    1,789
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    well, my points and summarizations were in a completely different direction, zbatia.

    there is a perfectly good standard, html 4.01. xhtml it's not really an option: not supported properly, used as a programming shiny new hat, understood only as a way to code, not a way to a more complex content.

    this html 4.01 it's just maturing. why? because style sheets mature just about now. and we need to look at it in a different light. transitional vs. strict have new meanings. things changed since years ago when specs did the best they could to cover and define both bad uses and good uses.

    many jumped the strict boat without first buying a ticket. and that is one reason why html 4.01 appears to many as obsolete. in fact, years of false labels on bad markup make it look so. if there were stricter rules, not only recommendations, 80&#37; of those strict validated documents would fail to raise to the standards described in the specs. so many years it was in fact transitional the concept used the most, but promoted to strict for mercantility effects.

    is xhtml a way? probably, but has failed to show it so far. most markup is in fact html based, only written using xhtml coding rules.

    is html5 a way? not really. it's too specific, like xhtml was/is, and this approach proved it self wrong.

    i believe in html 4.01 strict+css 2.1 to be a modern html 4.01 transitional, making it's way up to html 4.01 strict+css3 as a modern html 4.01 strict. and i'm talking here about the actual way of programming rather than an DTD declaration, which, so far, it's only a flag.


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
  •