HTML 4.01 Transitional DTD is the answer?

HTML & CSS
41

Well, not if you think a web page is a pretty picture to look at. But I thought more of you than that, Poes!

Yes, they ‘know’ what an <address> is. That’s how they know how to treat it, i.e., render it.

Should we then, in your opinion, use only <div> and <span>, since the browser doesn’t have to know what elements are?

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. :frowning:

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.

Oh, so you too think that a web documents is just a pretty picture? Et tu, Gary? :wink:

42

I agree since that is the latest version.

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).

43

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.

44

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% 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.

45

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. :x

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”?

46

you really are naughty felgal, quoting (not!) me like that! :rofl:

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.

47

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 ([URL=“http://www.microsoft.com/en/us/default.aspx”]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.

48

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 :slight_smile:

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.

49

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 : )

50

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. :slight_smile:
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.

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.

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

51

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.

52

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.

53

html speaking, we do.

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?

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.

54

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.

55

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.

And you’re obviously not a fan of Douglas Adams. :slight_smile:

56

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.

57

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ü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.
58

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.

  1. 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).

  1. 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.

  1. 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).

  1. 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”.

  1. 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.

  1. 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.

59

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.

60

Maybe it’s special to Sweden. I’m sure the badgers get pretty weird with 10 months of winter and all.