Showing different html source based on browser

HTML & CSS
1

I am having some serious issues with firefox & opera not accepting styles on html5 elements.
I am looking everywhere for help and I can not find any myself, so I am turning to the different forums of sitepoint-- my favourite place for web help, discussion, and pretty much everything els.e

Anyway, In short, I have a site that I am working on in html5 that has some styling to some of the html5 elements. However, in firefox and opera the styling doesnt work and these elements will appear to be gone or disappear.

When those parts are written in html4 with ids and classes to refer to them specifically then the styling works in all modern-browsers, but I would like to use as much html5 as I can.
Is there anyway I can display one version of html if the browsers is chrome/safari and display another if it is not those browsers?

I have a more detailed explnation and a link to the code in content here:
http://www.sitepoint.com/forums/showthread.php?p=4735257#post4735257

I have asked for some help using scripting languages in said sub-forums, but I was wondering if there is any way one could do this in html, even though html is a tag language and not a logic-language, or if anyone here knows any solutions to this issue.

I would greatly appreciate it.

Thanks in Advance and Best Regards,
Irfan Mir.

2

As Paul mentioned in that other thread, you need to set the display to block. 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 :rolleyes:)

cheers,

gary

3

Thank you Gary.
Especially for this:

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.

It helped me in understanding what paul did.

so, when there are default styling for certain elements, that css reset sheets aim to remove, come from the browser not the element being used in the code itself?

4

… come from the browser not the element being used in the code itself?
Correct. The html says nothing at all about rendering the content; only about what the content is.

cheers,

gary

5

I can certainly think of a few html elements that are not related to string in any way shape or form.

That’s pure eccentricity :lol:

A css declaration of display: block; on a <div> element from the html.css file doesn’t really make the <div> element a block level element! It seems you are implying just that. If so…

html.css is just another external css file. If I make another css file and in it I put display: inline; for <div>, will that make <div> an inline element?

html.css it’s just a feature, an opportunity for the user to play with default style, it doesn’t prove anything.

The correct answer lies in OO. The string class may be superclass for a number of classes of html elements .

6

Another one :lol:

HTML says EVERYTHING about rendering the content (visual or non-visual)!

Plus:
Hmmm, I wonder. What the <pre> element says about what its content is? NOTHING!
Hmmm, I wonder. What the <div>, <span> are saying about what their content is. ALSO NOTHING!

7

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.

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

You should never use a div or span tag without applying an id or class to identify what that content is (unless the tag is there specifically to get around shortcomings in CSS).

8

I’m sorry, but that sounds quirky to me :slight_smile:

The content is an… element? The content is a… concept?

Any reliable sources? :slight_smile:

9

Have you tried setting display:block?

10

I doubt the w3c validator will require a div or span to have an id or class.

I would normally give a div or span an id and/or class because it is most likely needed for css and/or javascript.

But if the div or span didn’t need an id or class for any reason another option is to simply add comments in the html to describe the purpose of the div or span.

11

No, in just the same way that it won’t slap you down for using layout tables, <h1> tags for body text or any other unsemantic nonsense. Felgall’s point, if I’ve understood it, is that you shouldn’t just be slapping down <div>s and <span>s unless they need to be there. In most cases, they will have a class or ID applied, which is used as a hook for CSS or Javascript. Sometimes the <div> or <span> will be unnamed but implicitly referenced as a child selector or getElementByTagName.

On the other hand, there are a huge number of pages out there stuffed full of <div>s and <span>s that do have classes and IDs but are totally unnecessary, as the same properties could be applied to parent, child or alternative elements to achieve the same effect but in a more efficient and more semantically appropriate way.

So I would re-state the point as “You should never use a <div> or <span> unless you need to”.

12

My understanding of Gary’s comment was that if you remove your browser’s default stylesheet (which he showed how to do in his post, just rename the browser’s stylesheet so it can’t find it anymore), then all elements will jumble together as if they were styled like inlines.

Not saying that a div is an inline element, but that it won’t look like a block element if you remove the browser’s default stylesheet.

This explains why browsers like FF and Opera who don’t understand HTML5 elements are “not styling” them… by default any <foo> they don’t understand gets shown as if it’s inline (just as they do with all the others if you take away their default stylesheets). This is why Team has to set those new HTML5 elements to “display: block” as most of his styles likely require/expect them to be blocks.

Browsers who “understand” HTML5 basically have those elements already pre-styled in their default stylesheets as blocks.

13

No, no, no, no…

I’m saying that gary tries a bogus explanation, that does more harm than good.

  1. You can remove the browser’s default style because of the browser’s modularization, not because html, rendering, semantics, Ursa Major or global warming :slight_smile: And the removal only proves the modularization works, nothing more, nothing less.

  2. When html specs say that an element is block level, it has nothing to do with css style, right?

  3. The proper explanation would be:

firefox & opera treat unknown elements like inline elements!

It has little to do with html5 (only recently it does, since it introduced new tags) and all to do with xhtml (which presented the issue long before), where you can define your own tags and make your own elements.

Right? :slight_smile:

14

Yeah. But that’s what Gary said:

Remember, all html elements make up an inline string without style rules.

Inline string… what you see on the screen when the browser doesn’t have a default stylesheet*. Explaining to Team what FF and Opera are doing here with the HTML5 elements… yes, because they are unknown to those browsers, or more precisely, they are unstyled in their default stylesheets.

  1. You can remove the browser’s default style because of of the browser’s modularization.

Isn’t that what Gary said? He even showed how to do it (in one of those superior OSes : )

*more accurately, their contents. Obviously if they’re empty you won’t see them at all.

15

I believe you’re making the same mistake. You should know that: ALL != UNKNOWN !

  1. Not all html elements are reduced to inline strings when the html.css is messed with. Because then, all the HTML (not CSS) theory about what elements can go inside which is down the tubes!. There are elements having nothing to do with strings: forms.css.

  2. We talk about a technical implementation, not the actual standing case. The fact that some html elements may have the same superclass: string (like Object Java superclass). But that doesn’t reduce them to the superclass when I mess with the technical implementation (if I was to remove some jar files, that will imped proper display of some objects, this will not change the way Java defines them). Which you’re suggesting. And gary did too. Wrongly so. Because then, all the HTML (not CSS) theory about what elements can go inside which is down the tubes!

  3. Tempering with the technical implementation doesn’t redefine any at all. It just proves you can mess up with it. That’s all :wink: Because then, all the HTML (not CSS) theory about what elements can go inside which is down the tubes!

Right? :slight_smile:

16

Because then, all the HTML (not CSS) theory about what elements can go inside which is down the tubes!.

Nah. The specs say what can go in what. But that doesn’t actually stop anyone from
<a href=“foo”><div> lookee mee</div></a>

The rules are based on what the w3c calls a “block” and what it calls an “inline” but how they display is still purely from the default browser stylesheets (and luckily they mostly make W3C blocks look like blocks and W3C inlines look like inlines).

Comment #2, I don’t do Java, but it ends with the same arg as #1 so I’ll count my answer to #1 and #2 together : )

Tempering with the technical implementation doesn’t redefine any at all. It just proves you can mess up with it. That’s all

Yeah, and? Isn’t that what we’re all saying?

17

NO! :slight_smile:

Did I say that specs don’t say what goes in which? NO! In fact I said that by using and tempering with technical implementation you’re trying to contradict the specs to prove a bogus point.

Let me remind you:

You’re saying that by tempering with technical implementation (removing html.css) you can prove all html elements are inline strings. WRONG! There are elements that have no string content or have nothing to do with string at all. You might as well make an external css with all inline and link it to your page and say: “Look, all html elements are inline text!” IT’S THE SAME THING WITH REMOVING HTML.CSS!!! It’s only manipulating the implementation, it’s not proving anything useful.

You used that to prove how come you need display:block for an element that happens to appear in html5 specs and is unknown to firefox&opera. WRONG! HTML5 has little to do with it, XHTML does since before and display:block, in any external css file, including html.css, has nothing to do with redefining an element as being a block level or not, as you imply.

You’re saying because unknown elements are treated like inline all elements are treated like inline. WRONG! All elements is not the same with unknown elements.

WRONG! WRONG! WRONG!

This is the biggest of them all!
The default browser stylesheets are based on HTML specs. If you remove the default stylesheet you ignore the specs. And block or inline have exact specific meaning for all of them not because of luck :slight_smile:

You should make a distinction between theory and implementation. Implementation may seem to coordinate the theory or contradict it, but the theory stands as the base for the implementation.

You can do wrong things with the implementation but that will not change the theory.

HTML === HyperTEXT Markup Language. TEXT! It must have a default visual presentation! First! because it must be written in the first place. And HTML specs are there to offer you a default visual presentation. Which is not about font, pixel or em sizes, colours or anything specific like that. It has to do with block or inline, with h1 being bigger that h6, etcetera.

You cannot ignore that, not for aural reasons nor for any other current hypes :wink:

18

You’re saying that by tempering with technical implementation (removing html.css) you can prove all html elements are inline strings.

No, not that they ARE inline strings, but that that is what a browser is left with if it doesn’t have a default stylesheet.

in any external css file, including html.css, has nothing to do with redefining an element as being a block level or not, as you imply.

Redefining and element?

All elements is not the same with unknown elements.

WRONG! WRONG! WRONG!

Dr. Robotnik demands an explanation?

Show me and I shall convert!

The default browser stylesheets are based on HTML specs.

I would hope so, though of course it’s that vendor’s view of the HTML specs.

If you remove the default stylesheet you ignore the specs.

I disagree, because I don’t believe a browser stylesheet is necessary to acknowledge the HTML specs. All I need is HTML for that.

HyperTEXT Markup Language.

You meant HyperText MARKUP Language right? Markup.

It has to do with block or inline,

Yes, the specs state those things.

with h1 being bigger that h6, etcetera.

No.

<!ENTITY % heading “H1|H2|H3|H4|H5|H6”>
<!–
There are six levels of headings from H1 (the most important)
to H6 (the least important).
–>

<!ELEMENT (%heading;) - - (%inline;)* – heading –>
<!ATTLIST (%heading;)
%attrs; – %coreattrs, %i18n, %events –
>

It says which is important, but not which is larger.

Later it says is “Visual browsers usually render more important headings in larger fonts than less important ones.” A descriptive statement of fact, but not proscriptive (it does not say they must, or even that they should).

19

That sounds kinky! :blush: Can we do something like this in here?


1. <!ELEMENT [COLOR="Red"]DIV[/COLOR] - - ([COLOR="MediumTurquoise"]%flow[/COLOR];)*            -- generic language/style container -->

2. <!ENTITY [COLOR="MediumTurquoise"]% flow[/COLOR] "[COLOR="Orange"]%block[/COLOR]; | %inline;">

3. <!ENTITY [COLOR="orange"]% block[/COLOR]
     "P | %heading; | %list; | %preformatted; | DL | [COLOR="Red"]DIV[/COLOR] | NOSCRIPT |
      BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">

If for you the word block has absolutely no meaning but a notional conceit, I believe I have now two english languages to learn, one I’ve never heard of :slight_smile:

You seem to get thrown off by the fact that CSS exists. But CSS role is to improve.

You seem to get thrown off by specific font, pixel value, colours and consider them as default style for html elements. No, default style is this: block, inline, bigger importance etcetera. All these get materialized in a general visual style and are defined in html specs :slight_smile: Basic visual style for TEXT. By MARKUP. It’s nothing about “we all consent to this” specific visual style: 16px, blue colour for links etcetera.

You seem to get thrown off by technical implementation over theoretical implementation.

20

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

Originally Posted by felgall
You should never use a div or span tag without applying an id or class to identify what that content is (unless the tag is there specifically to get around shortcomings in CSS).

I don’t agree with that at all and suggested you can use html comments instead if you choose to which imho enable you to provide a more meaningful description of the elements’ contents than an id or class do.