Browser rendering question

[Fatstep]

To me it seems like a browser should be coded to completely understand a language and display it the same whether it's firefox or internet explorer. Apparently this is not the case; why can they not just make it work like a live html editor and display coding accordingly?

 

I'm not sure if I really asked the question right, I can't really find out how to word it.

[Buffy]

No matter how complete a spec is, there is still room for interpretation: when a column in a table has a specified width and there's no break after an image and before a piece of text, should the line break automatically or should the lack of an explicit break mean that the column should expand?

 

Earlier specs left more open, and once vendors built it one way or another, they were adverse to changing it because it would make existing sites break.

 

Most importantly though, if you're a browser vendor and you want people to use yours, you're going to build in some "extra-standard" behavior (doesn't *violate* the standard, but interprets or extends it) that is unique to your browser, so that people who use it as the basis for building a web site will at least start to be locked in.

 

Standards help, but believing that they are a panacea is almost as big a problem: I've fired developers who had such an attitude about Microsoft that they refused to make their code work with IE--in spite of the 90% of paying customers who use it.

 

No matter what, its totally sucky. I spend way too much time dealing with this topic....

 

,

Buffy

[CraigD]

To me it seems like a browser should be coded to completely understand a language and display it the same whether it's firefox or internet explorer.

The opinion Fatstep expresses illustrates, I think, a very common and profound misconception about what an HTML browser is fundamentally intended to be.

 

The “M” in HTML stands for “markup”, meaning that it is a language intended to place “marks” in ordinary, readable text, to provide the reader (usually a browser) with information about the nature of the text, which the reader may do with as it likes – what is sometimes termed “semantic markup”. Ideally, all HTML elements (“tags”) should say something about what the data it marks is, not specifically how the data should be rendered. By this reasoning, tags such as <strong> are “good” html, while ones like the typically equivalent <b> (bold) are “bad”.

 

A language that specifies precisely how text should be rendered is a typesetting language – it specifies, in points, inches, centimeters, etc. where text, graphics, and pagination should be placed.

 

Languages such as TeX, it’s more well-known macro package, LaTeX, and the even more popular and proprietary Portable Document Format (PDF) occupy a sort of middle ground between semantic and typesetting markup, giving the author more precise control, but leaving routines tasks such as line breaks up to the renderer.

 

Unfortunately, IMHO, HTML, being much more widely and better implemented, has largely intruded on and taken over the roles of typesetting and in-between markup languages, and even become the de facto standard medium for imbedding executable code, such as Java and ActiveX. As a result, many HTML documents are written as exactly as a typeset document, losing nearly all of the language’s originally intended flexibility, expandability, and ease of authoring.

[Buffy]

As a result, many HTML documents are written as exactly as a typeset document, losing nearly all of the language’s originally intended flexibility, expandability, and ease of authoring.

I'd agree with this, but the basic original intent--letting users "decide" how to render it--was a hacker's pipe dream: the fact of the matter is that 99% of all users will never have the expertise necessary to do much more than maybe bump the font size up a bit.

 

No matter how much you adhere to this spirit of "markup" its just plain impossible to have the same page render on both a big screen and on a cell phone unless its all text, IMHO. In my own company's software, we detect what you're using and give you completely different rendering: its not worth dumbing down everything just to please the idiot sales people with their Crackberries: they complain if its not perfectly designed for them anyway...

 

Really, if you want to do interesting stuff like mash-ups, you really want to have XML and render yourself!

 

Academic research projects mostly tell you how *not* to implement stuff,

Buffy

[LaurieAG]

A language that specifies precisely how text should be rendered is a typesetting language – it specifies, in points, inches, centimeters, etc. where text, graphics, and pagination should be placed.

....As a result, many HTML documents are written as exactly as a typeset document, losing nearly all of the language’s originally intended flexibility, expandability, and ease of authoring.

 

Hello CraigD and Buffy,

 

The original basic type of markup is tagged text or RTF (Rich Text Format) that have just one bracketed tag on the left hand side. Pagemaker 6 imports/exports files in tagged text format. The tags link with the style tags in the open PM document being imported into or being exported from.

 

SGML (Standard Graphics Markup Language), as used by Framemaker+SGML adds an extra context file with many pages that specify the properties (not just style) taken up by the contents (text/image etc) contained between the matching tags (both ends) in the SGML import file. Substitution variables are used to indicate that the text is an image path etc. This can be a real pain when your import data unintentionally contains the same substitution variable format (not to mention if the programming language used to generate the export file also uses the same substitution variable, double pain).

 

The original HTML (Hyper Text Markup Language) specs were very much like SGML without the context pages and XML (Xtended Markup Language) contains its own basic context section so that it operates in much the same way as SGML does.

 

The real problem with the HTML spec is that it has been expanded to become a quasi XML which is just a SGML with internal context sections. This cross fertilisation process is OK as long as all of the variations are treated equally by all of the different browsers. Unfortunately they don't and certain browsers are optimised to enhance the speed of their own particular flavour of extended HTML (should be called XHTML).

 

Once you start dabbling in foreign language HTML (like Japanese) you find other problems (at least 5 years ago anyway, I'm not sure now), while Japanese MS Windows and MS Word are good tools for developing your foreign language website pages, the pages actually appear better (WYSIWYG!) in non MS browsers.

 

It's about time somebody nailed down good basic HTML and XML specs (without all of the excess baggage) and opened up XHTML as the preserve for enhanced browser (and browse specific) functions that could be ignored by other browsers (or all browsers by option) without destroying the functionality or appearance of the webpage. Any new HTML spec would then only contain important basic functions (not every different variation under the sun) which can be treated in the same way by all browsers.

[alexander]

lol, that is due to the fact that FF supports CSS 1 and 2 and a little of 3, of which Internet Explorer suspports 1, and some of 2. Also FF handles PNG alpha transparency 100 million times better the IE, IE being the one that refuses to support open formats all the way. That is the case with HTML, M$ created IE speciffic tags back in their day, and they made sure that all the books that came out that taught HTML used the IE-speciffic tags, there was a thread a while ago on just such an occurence, where someone was having problems with an html tag they got used to using for IE, and in FF it just didnt show up right, in the end, the syntax for IE turned out to not be ISO or ANSI compiant at all :)

 

Its a lot of work trying to get a page to work nicely in IE, their positioning system is backwards(figuratively) from the rest of browsers (like what they define as the zeroweth pixel)

 

also you have to remember, that while FF and other open browsers (like Safari and Konquerer and Oprah and others) try to comply with standards, M$ says "screw not succeeding in implementing already established standards, we write our own" and hence why your web page looks different in different browsers :lol: