Is there a standard way to design web pages now or not XHTML STRICT / html4 stick?

Just like the gas engineers ,are there really industry standards for web design? Whats the set standard to ultimatly design to. xhtml strict ? html4 strict ? THIS ISNT ASKING WHAT YOU DO WITH YOUR PAGES ITS ASKING IF THERE IS ACTUALLY AN INDUSTRY STANDARD WAY.

My previous post seemed to reveal everyones idea on what is was, not what is actually is. Are people just going , "I fancy a bit of xhtml strict today ? What are you having? rather than “fit that pipe to that pipe or the place will blow up” eveytime.

Are people just being lazy and not adopting them because its harder to make pages sing and dance or what?

THIS IS NOT A STAGE FOR YOU TO SHOW OFF YOU INTELLECTUAL PROWESS , ITS A QUESTION. No “breakdance battles please”

my last post left me more confused than it helped. POST: whats the correct XML and html declarations for xhtml strict ? it told me what it was but now I’m not sure if I want it.

Wow, I’d not heard that. Felgall, your posts are getting fascinatinger and fascinatinger. Keep it up!

There’s people in both camps - there seems to be more people holding your view on the topic though.

I vote we either ask the author of the spec the question or simply agree that the answer to this age old question doesn’t need to be found as XHTML served as XML doesn’t and will never work.

In fact type=“text/javascript” is deprecated and the correct MIME type for JavaScript is type=“application/javascript”.

The correct MIME type will work for all browsers that support JavaScript and since they all support XHTML as well you can use <script type=“application/javascript”/> for those browsers.

The browser that doesn’t support either XHTML or JavaScript is of course Internet Explorer and that browser offers JScript or VBScript in place of JavaScript. JScript is similar enough to JavaScript to be able to use feature sensing along with the deprecated MIME type to create code that will work as JavaScript or JScript (as long as you avoid the functionality that JScript supports and JavaScript doesn’t).

By choosing between the correct MIME type and the deprecated one you can determine whether IE will try to run the JavaScript as JScript or not.

That HTML 5 is making the type on the script tag optional and having it use a deprecated type if you don’t specify one is just another of the ways in which those creating HTML 5 are disregarding standards.

That IE doesn’t run scripts that use the correct MIME type for JavaScript isn’t really an issue at all given that IE doesn’t even have JavaScript at all. So not trying to run JavaScript is in fact the correct action for IE to take when the script is correctly defined as JavaScript. Where it gets a bit misleading is that IE will recognise either text/javascript or text/jscript as being a valid request to run the script as JScript.

Fortunately since both JavaScript and JScript are based on ECMAScript JavaScript is mostly a subset of JScript (apart from JScript not having event listeners and a few other differences mostly detectable through feature sensing) so that if you incorporate the approrpiate tests into your JavaScript you can get it to run as JScript. The same is not true the other way around as there are lots of things in JScript without a JavaScript equivalent.

So the MIME types available for use with script tags in HTML are:

application/javascript - run as JavaScript
text/jscript - run as JScript
text/vbscript - run as VBScript
text/javascript - run as JavaScript or JScript

only the first of these four is relevant for XHTML since neither JScript nor VBScript is available in browsers that support XHTML.

Also since I was using markup languages such as GML, Script and EDI in the 80s and early 90s meant that I was well aware of all the benefits of XML before starting to write web pages in 1999 and could even then see no reason why anyone would want to stick with HTML when the alternative is so much more flexible (unfortunately it is lack of support by browsers that has kept web markup in the stone age).

I haven’t made any claims about what XHTML is in this thread - I have posted a HTML5 document with XHTML’s self-closing syntax.

I’ve read your description of the differences between HTML and XHTML and I might just agree with them - but I simply don’t care of the differences because real XHTML served as XML simply doesn’t work in the real world.
What you call broken HTML because of the self-closing syntax makes sense to me and works consistently in browsers.
The doctype that you say shouldn’t be used because it’s a draft renders my pages in standards mode and will continue to work with the newly developed standards.
These are the things I care about - You insist that I am making claims about what XHTML is and that because I use self-closing syntax I am saying I am better than those who don’t. That simply isn’t true.

Wouldn’t <br></br> be even easier to understand? And how come you accept <script></script> without blinking when <script/> would be much more efficient?[/b]

Right. Now explain to the same newbie why he or she can use <br/> but not <br></br> or <script/>. :slight_smile:

No <br></br> isn’t clearer because it looks like it can contain content.
The problem with the script tag is not a probem with my argument but a problem with the way that particular tag has been implemented.
I feel I have been very clear on this point - yes I would prefer to use <script /> or <link type=“text/javascript” /> if I could - but because it breaks certain browsers I cannot. :injured:

I am promoting forward-thinking standards whilst maintaining an acceptable backwards compatibility in my Perfect HTML Document.

Mark out.

Not entirely true. XHTML 1.0 Strict is valid if served as text/html. It is only XHTML 1.1 that is invalid if served as text/html.

I think it was Appendix C in the XHTML 1.0 W3C spec that stated you were allowed to serve it as text/html.

Edit: The text/html MIMETYPE RFC document even explicitly states:

In addition, [XHTML1] defines a profile of use of XHTML which is compatible with HTML 4.01 and which may also be labeled as text/html.

http://www.ietf.org/rfc/rfc2854.txt

how much does he pay you for the SEO work ? quite a bit for you to be trawling forums to promote him.

LOL, I said the same thing several years ago when I grew tired of butting my head against the wall. But somehow I get drawn into the same darn arguments five years later. :slight_smile:

An option to giving up would be to learn the real differences between HTML and X(HT)ML. Then you could participate in the dialogue with solid, factual arguments. (And you’d probably be on my side, too! :))

I know what the two of you are trying to say, but it doesn’t really work for pretend-XHTML. Real XHTML, yes, that has more consistent syntax rules, but you can’t use those for pretend-XHTML.

Now, you say that <br /> is easier to understand than <br>. Fine. It makes no difference for me, but I respect that it does for you.

Wouldn’t <br></br> be even easier to understand? And how come you accept <script></script> without blinking when <script/> would be much more efficient?

In real XHTML you could do both of these things. In pretend-XHTML you cannot, because you are using invalid HTML, not XHTML!

It’s no harder for a newbie to learn that a handful of tags should have no end tag than to learn that those same tags should end with ‘/>’. Especially since you cannot teach this newbie that ‘/>’ signals an empty element, because he or she might then try to use it for other empty elements … like <script/>.

I was using XML before XHTML was an itch in its authors’ trousers. I have nothing against XML when it’s used as a data storage and transfer format (for which it was created). I can also accept people using it for web content if they are willing to live with the QC issues involved. What I dislike is people writing things that look like XML but isn’t, thinking that they are somehow ‘superior’ to those old plods who still use old-fashioned HTML.

Right. Now explain to the same newbie why he or she can use <br/> but not <br></br> or <script/>. :slight_smile:

Agreed, although that can be alleviated with consistent source code indention. But if you don’t know what the tags mean, you can’t write useful web pages and you probably won’t understand someone else’s either. Besides, the XML syntax is not automatically intuitive; you have to learn that <foo/> means <foo></foo>.

Then you are grossly misinterpreting what I’m saying. Perhaps wilfully.

I have said again and again that even pretend-XHTML is perfectly acceptable as long as you understand what you are doing and that you are really using invalid HTML as far as user agents are concerned. The problem is that many who use pretend-XHTML do think they are using XML and do think that they are more progressive and clever than the rest of us.

I’m just trying to fight against ignorance. Not for my own sake, but to save others from being misled and wooed by hyperbole.

I’m sorry you’re having such a hard time with these elitist XHTML coders… I don’t know anyone who works with XHTML who thinks it’s XML or that somehow they’re more progressive. As a matter of fact all of the developers I know (who have heard about XML) also work on the server so they know what XML is used for even if they don’t know all of the intricacies of the spec.

I use XML all the time but it’s on the server or more to the point between servers… I first learned of XML in about 1999 in a Dr Dobbs journal. I was really excited about its possibilities and learned as much as I could about XML, XSL and later XSLT. I wrote stock tickers, weather forecast widgets, the backend of a banking website and custom shipping calculators that consumed and/or produced XML data. I even wrote a cool CMS and I had hoped that a few years later when XHTML appeared we would be able to really work with XML on the client. No such luck :frowning: Until this discussion, I had forgotten half of the neat stuff I did with XML five or six years ago. Now it’s all remote member log-ins and web service data-munching stuff with the odd RSS feed or XML sitemap.

The front end XHTML coders I know aren’t elitist either… I think they use XHTML because it is more recent than 4 and they probably haven’t even given XML a second thought if they’ve even heard of it.

Am I trawling ? :slight_smile:

I respect the guy and his publishing. His sensible approach to topics like this one is what we all need more of.

I vote that we simply wait for a moment and get Jeremy Keith to tell us all what HTML5 is and isn’t in his next book:

They did - they got HTML 4 to the point where it was nice clean basic HTML (as clean as HTML could get without a rewrite from scratch). To be able to make it extensible they converted it to follow the XML standard which gave them XHTML 1.0. They then realised that a further cleanup was possible and got XHTML 1.1 onto which they started designing the extensions. Some people wanted to get it even cleaner even though it did require a rewrite from scratch and started on XHTML 2.0.

Had all browsers supported XHTML 1.1 and XHTML 2.0 then you’d have got exactly what you wanted.

Unfortunately some browsers decided to not support XHTML at all and some people decided that HTML was too clean and needed lots of garbage added and so started working on a new HTML full of multiple ways of doing the same thing which they call HTML 5.

Thanks for convincing me that your viewpoint is incorrect and that you know it is incorrect.

When HTML5 started they had the question ‘Where are we at currently?’ - like it or lump it they have included some things in the spec because that’s simply how they work in the current browsers - having things work in IE was a rather important thing for them to keep in mind.
If this means disregarding some of contributions like the correct MIME type on that attribute so be it.

I don’t know - The philosophy of HTML5 has a good sense of real world application that appeals to me.

“Unhinged from Reality” is now my new HTML5 buzzword.

HTML5 ‘unhinged from reality,’ say Javascripters

HTML 5 will have everything from HTML 4, a few useful additiions, a lot of junk that HTML 4 got rid of brought back so that people don’t have to do things properly, and lots of new tags to duplicate existiing ones so that you can choose between several different tags to do the same thing.

The only thing HTML 5 isn’t retaining from earlier versions of HTML is that HTML 5 no longer follows the markup standards so anything goes.

As for HTML and XHTML - they both serve different purposes and the only people who are wrong are those who don’t understand the difference and use XHTML thinking it is an upgrade to HTML. There are valid reasons for serving XHTML as HTML but unless the person using it actually has a reason (and since XHTML is no more valid than HTML and certainly no faster that isn’t a reason) then they should be using HTML for creating a web page.

So, doing straight HTML isn’t going to be a problem anytime soon…???

No it isn’t - it has created an entirely new tag.

The <!DOCTYPE html> with or without anything else in the tag in HTML 2, HTML 3.2, HTML 4, XHTML 1.0, XHTML 1.1, and XHTML 2.0 is an SGML tag identifying that the document follows an SGML (X) HTML standard.

The <!DOCTYPE html> in HTML 5 is an HTML 5 tag and not an SGML tag at all. Since HTML 5 doesn’t follow the standards they can generate all the <!crap> and <#junk> and </openparagraph><//closeparagraph//- etc tags they want and there doesn’t have to be any consistency in how the tags work at all. That they start with a tag that looks like it is SGML when they aren’t following that standard may be confusing but when you don’t care about standards then you don’t care if it causes any conflicts or not.

Yes that’s what I was concerned about. If that is the case, we can kiss any backwards compatibility goodbye. It’s been a good, probably six years since I did a test on a basic html page and swapped out one doctype for another and the result was differences in various elements alignment. Being that it was such a long time ago it could have been a result of my stylesheet not zeroing all off the elements in the first place but I take comfort in the browser knowing what version of HTML it is dealing with because in my experience they (the browsers) don’t necessarily treat all versions the same way.

Yup… Me too and on so many fronts…

It’s funny because we seem to have two camps of purists; The HTML camp and the XHTML camp and some of the arguments are getting petty. Like inferring someone is a moron because they find it’s easier to develop or troubleshoot code when they adopt XML standards of well formed documents. That’s just arrogant. :nono:

On the topic of XHTML… I don’t care anymore that Microsoft decided not to support XHTML and as a result we aren’t parsing XHTML in the browser or that XHTML is being served at text/html and therefore isn’t consumed as XML. It would be cool but oh well, it doesn’t matter. For 100% of my production use, XHTML1 does 100% of what it needs to do. I write XHTML markup according to W3C specifications and it does exactly what I need it to do. It’s not rocket science, it’s just markup. Pick a standard that works and then write it according to the specification.

When HTML5 actually makes it out of the starting gate, I’ll more than likely use it if it provides a clear advantage for my clients and if it is backwards compatible because I know from experience, my clientele are very concerned about consistency.