Showing different html source based on browser

[system]

It appears some philosophy came along and blurred things up a bit.

So, my point is, that for a thing like this:

@gary_turner

Remember, all html elements make up an inline string without style rules. Only browser configuration or its internal style sheet makes certain elements otherwise (cf. lynx.cfg to [path to Firefox]/res/html.css). To demonstrate, mv html.css html.css.orig, and view a page in Firefox. (mv is rename in the common inferior os )

cheers,

gary

to be looked upon as stupid and wrong, you only need to take a look at what the specs are saying:

[URL=“http://www.w3.org/TR/html401/sgml/dtd.html”]

<!--================== HTML content models ===============================-->

<!--
    [COLOR="red"]HTML has two basic content models[/COLOR]:

        [COLOR="Red"]%inline;[/COLOR]     character level elements and text strings
        [COLOR="Red"]%block;[/COLOR]      block-like elements e.g. paragraphs and lists
-->

This defines a general visual style, w/o being specific as to how font, colour, whitespace should look and measure up. But it does imply a certain visual style that, I think, it’s pretty clear to everyone.

This is where most people seem to mix-up: between default style apparent from specs and some commonly agreed upon specific default stylesheet: 16px, blue text for links, etcetera.

Inline and block have nothing to do with Firefox’s html.css. Furthermore, the way firefox&opera treat unknown elements is not to be regarded as a hint towards demonstrating a general rule, a wrong one nonetheless.

Yes, you can temper with UAs modularization by hidding html.css. That only proves that you know how to cause a malfunction

Yes, you can alter html.css. That only proves a feature, a technical one

Yes, you can make an external css stylesheet and rule all html elements be displayed inline. That doesn’t mean all html elements are basically inline, it only demonstrates you have freedom in coding

[felgall]

@Kalon

That I totally agree with :agree:

but what felgall said was totally different in that every <div> and every <span> should have an id or class (unless the tag is there specifically to get around shortcomings in CSS).

It is not totally different at all - just that I was stating what the end position looks like and Stevie D explained it in terms of how to get to that end point.

When you only use divs and spans when you absolutely have to then they will either have an id or class applied to them or they will be there to provide an extra hook for the CSS to use. Any div or span that doesn’t have an id or class and which isn’t there to resolve CSS shortcomings is unnecessary and should be removed.

The id or class basically defines what tag you would be using if you could define all the tags you need. Far more appropriate than using a comment since a comment doesn’t allow someone to come along and style your ‘custom tag’ differently.

[system]

@felgall

It is not totally different at all -

A wise person once told me

Say what you mean and mean what you say

I can only reply to what you actually said and not what you meant to say.

[system]

@felgall

Wrong - they say a lot about the content - the div and span tags in particular will identify exactly what sort of content they contain based on the information contained in the id and/or class attributes on those tags.

Wrong - the div and span tags have a clear and universally accepted definition and meaning, enforced by definitions in specs. The id and class attributes have a personal and subjective meaning, are usually undocumented, and therefore are only useful in a personal reference system.

It’s like with XHTML new tags, you may or may not be able to decipher their meaning. You can understand their meaning for sure only when an additional DTD info is present.

So, when you say that div and span id the content based on id and/or class attributes values, you’re saying you should provide more id and class DTD info to make your self universally understood. I believe you’re not doing so, and instead you’re basing your whole theory on an assumption: english id/class attributes values have the same weight as documented english tag names. Wrong.

@felgall

For example <div id=“footer”> identifies the content as being the footer.

For you. For an english language aware person. Let’s see I am not, in any way or extent, an english language person. How will I make my self clear to the rest of the web? For example <div id=“subsol”> The id value alone will suffice to make you understand what sort of content it has? No.

[xhtmlcoder]

Obviously there are few times where you don’t need to add the class or id attributes as they can be both generic language and style containers. The DIV and SPAN does not impose any presentation semantics besides block-level and Inline. I think that has been completely demystified now.

It probably got lost in translation that Gray probably meant association with a style sheet language and DTD to perform rendering. As obviously markup itself cannot render content; it is just “plain text” nothing more - there is no argument it is a plain fact.

It is only when you apply both the DTD and the Style sheet Language (including user-agent style sheet) you will see any display/rendering differences (in a visual browser or other UA) AND applied semantics respectively.

Some people were talking about; rendering, some about pure markup and others about rendered HTML via the browser and DTD. All completely different topics! That probably explains why there was a semi-pointless debate going on due to language misunderstandings.

Hopefully that should clear things up?

[system]

@xhtmlcoder

That probably explains why there was a semi-pointless debate going on due to language misunderstandings.

No misunderstanding here gary was mixing it up, leading to a possible wrong conclusion.

The subject: an unknown tag. If it’s just an unknown tag, it won’t get any useful default styling, right? No specific ties to HTML5. But rather with XHTML, previously.

He said: “all html elements make up an inline string without style rules”! NO! But if you choose to ruin the modularization UAs put at your disposal, if you hide the html.css, all that tempering will make it true!

He could, as well, prove false points all day long. He could make an entry in html.css for the unknown element and rule display:block; for it! Now, making it so, he could say “all unknown html elements are treated as blocks”?

So his explanation rocks… at the bottom of the sea.

A simple explanation:

[B]firefox & opera treat unknown elements like unknown elements.

Why? Since they’re unknown, they lack the html definition conveying a default style, style that will be further used as the base for default stylesheet rules!

Why they look like inline? That’s where his explanation should have excel, rather than going about stupid experiments![/B]

No mumbo-jumbo lynx.cfg, html.css