Welcome to WebmasterWorld Guest from 220.127.116.11
Forum Moderators: incrediBILL
Don't split highlighting/formatting elements with structural markup. The only problem here is that it's simply invalid HTML and some browsers will terminate it for you, giving the end user the undesired result of loosing some of the markup that you, the author, intended.
Yes, it works on Netscape and MS Internet Explorer but that's because they are playing games with their parsing of the HTML.
Instead, terminate and restart the formatting element
OK, what gives here? Is this really true? If so, I've never written a correct HTML page in my life! And no validator I've ever used has pointed out this kind of error.
The body tag applies to all of it, so close that after all of it. etc. do you see it? probably the w3.org has more info on this somewhere too. remember they are the standards that no one listens to. hehe.
I think what they are getting at is that structural HTML (<p>, <blockquote> etc) is handled differently from formatting HTML (<font>, <i> etc). What they are saying is each set of structural tags defines a section of code and that section should be treated almost as seperate page with it's own set of tags. Stretching a formatting tag across multiple sections of HTML could cause it to break at the structural seperation depending on the browser.
I agree tedster, I've never written a correct page in my life either according to this but all the major browers can handle our 'bad' code so I don't worry about it.
SGML allows you more alternate ways of doing something (optional closing tags, implicit elements, etc) than XML, but most of the leniency is actually coming from the browser rather than the SGML spec.
I imagine there'll be lots of panic and relearning once automatic validation results become more common as a browser feature. iCab already displays a frowning face and offers a list of errors when dealing with invalid markup. A similar Mozilla feature is in the works as well. It'd be rather embarassing to have your users view your page and see a big "This page contains errors and may not be rendered as intended." warning.
HTML specifies what each tag attribute means. XML uses 'tags' only to delimit pieces of data, and leaves the interpretation of the data completly to the application. source: w3.org
Grnidone compares the ability to work with html which is less strict then when working with xml. i.e if working with html, strict adherence to the spec is not required but it is required when working in xml otherwise the application reading the 'tags' will be lost.
here is a good article on XML by Scientific American for anyone whom is interested: [sciam.com...]
Thus, for its users, the XML-powered Web will be faster, friendlier and a better place to do business. Web site designers, on the other hand, will find it more demanding. Battalions of programmers will be needed to exploit new XML languages to their fullest. And although the day of the self-trained Web hacker is not yet over, the species is endangered. Tomorrow's Web designers will need to be versed not just in the production of words and graphics but also in the construction of multilayered, interdependent systems of DTDs, data trees, hyperlink structures, metadata and stylesheets--a more robust infrastructure for the Web's second generation.
it's all such a mess and results in a ridiculous waste of time. but i guess that's progress.
Has anyone converted their old <P> only pages to <P>..</P>
Having thought around search and replace strings, we have come to the conclusion there is no automated way to do this but has to be done manually (an enormous job)
Question is.. has anybody found a way to automatically change these tags?
it is on the following page:
i'm looking at the xhtml1.0 spec right now to see what it says about this.
read this, it may help fix your automation problem.
it is about converting your doc into xhtml using a program called html tidy.
i just checked it out more. nope, it doesn't help the end paragraph tag problem, but at least it does some stuff and may be helpful to someone.
My point was not to compare HTML to XML at all. My point was that if you are going to ever program XML, you may as well get into the good habit of nesting your tags correctly.
Anyway, HTML itself is no more or less lenient than the markup system it's based on. If it's XML-based, you have to play by XML rules. If it's SGML-based, you have to play by SGML rules. If it's being run through an ad-hoc Mosaic-style parser, you have to guess the rules by trial and error. I look forward to the day when 98% or more of users have a browser with XHTML 1.0 or higher support so that I can just write XML and trust it to be parsed correctly. Too bad that'll be a while.
There seems to be some controversy on the program however with comments on the downlaod.com site that there may be viruses in the code and that the installation program over-writes some windows files.
Scared me so much i didnt download it!
Theoretically accurate, but also full of excellent practical advice for our theoretically inaccurate present moment.