I ran my site through the W3C validator for HTML 5, which is still experimental, I know. I got this warning with it though that I don't really understand:
The menu element is not supported by browsers yet. It would probably be better to wait for implementations.
I'm confused why this warning exists. What exactly needs to be "implemented" in the browser? As far as I was aware, the <menu> element was just another element for better semantic meaning, that was basically equivalent to a <div> element. Did I miss something? Is there something special that browsers are supposed to do with this element?
The menu tag is designed to contain 'commands' (see What exactly is the HTML5 <command> tag and what is the browser support). It is the command functionality that has not been widely implemented yet.
It may be implemented through a right-click menu, through an additional menu in the browser, or something else entirely.
Lots more good info here: http://www.html5laboratory.com/by-your-command.php
Related
I am attempting to ask a more specific question than "how does browsers work??", please bear with me :)
If I understand correctly, html elements may have some default properties that determine their behavior. For example, <div> has display: block property set by default, while span has display: inline
These defaults exist because they are defined in the browser's default stylesheet.
Ok cool, I get that (hopefully). But what about <br /> or <img>? The behavior of those is determined by more than their properties right? Is it just up to the browser's implementation to make them behave how the W3 html5 specification says they should?
Also, is there an official word for this kind element behavior or does it just fall under 'browser implementation'?
So, you're really asking two questions here:
What is the default presentation and behavior of HTML elements?
Who/what determines how this works in a browser?
Let's start with question 2
The HTML specification is written and reviewed by a group within the W3C called the HTML Working Group. When they've agreed on a specification they publish it as a Recommendation. You can read the HTML 5 spec here, but I don't recommend reading the whole thing - it's very long and boring full of technical jargon.
However, the W3C's recommendation defines only the syntax and intended purposes of the features of HTML - it does not define how browsers should render HTML. Browser vendors, like Microsoft (IE), Mozilla (FireFox), Apple (Safari), and Google (Chrome), get to determine how their browsers render and implement the features of HTML.
Fortunately, most of the common HTML elements behave almost exactly the same from browser to browser. It's in the vendor's best interests to stay consistent among each other, because if one of them decided to do something drastically differently from all the others, the people who build websites would have to spend more time supporting that specific browser and it would fall out of favor (as was the case with IE 6 up until IE 11).
What determines the behavior of HTML elements?
The browser's rendering engine. Some browsers share the same rendering engines (like Safari and Chrome) (not true anymore - see comments), but not all. This article offers some insights (and leads to more insights) about how browsers are built, and here's an article listing several browser engines.
For the most part, you can affect how your HTML document looks by changing its CSS properties, but the behavior of most HTML elements is unchangeable without scripting using JavaScript.
The default CSS styles applied by your browser is defined by a stylesheet called its User Agent Stylesheet. These are usually pretty basic styles that browser vendors design in order to make HTML documents a little more readable without drastically affecting the presentation of the document.
However, there are so many basic styles applied by different browsers, that it's very common for web developers/designers to what's called a CSS reset. Normalize.css is a great example of this, and it's one of the most popular ones.
I believe it is up to the browser implementation. The way it will appear on the screen is up to the browser implementation.
Although, all browsers agree on how it should appear on screen.
These standards are defined by the World Wide Web Consortium - (wikipedia).
I guess this information you are seeking can be found in these sites!
HTML5 allows for links to be wrapped around block elements (one or several), but how exactly will it render in older browsers? Let's say to go as far back as IE6.
I haven't found full details yet (but there are some examples).
The markup would be as follows:
<a href="http://example.com">
<section>
<h3>Heading</h3>
<p>Text</p>
</section>
</a>
Also, would the most semantic way to make it compatible in older browsers be to wrap the links inside each block element separately? I've seen suggestions to replace the block elements with span, but that'd make it inline and alter the meaning of headings.
I've noticed that even modern browsers (e.g. Safari on iOS 6) do weird things. For example, try clicking on the image in this JSFiddle from your mobile brwoser — even though it shares the link with the caption below, the caption doesn't get highlighted for me. Furthermore, when clicking the caption, the image nor caption get highlighted.
As far as I know, the behavior is generally the same as modern browsers. Everything in the sample markup given will turn into a single hyperlink. This is regardless of whether or not you include the HTML5 shiv for older IEs to recognize the new semantic elements.
This is probably because there's nothing in HTML that says a specific starting tag should automatically close an unclosed <a> tag — the end tag is required to denote the end of a hyperlink.
And yes, that's how I'd do it to preserve semantics if I want to conform to an older HTML doctype. It's not required for HTML5 conformance though, since it works based on the assumption that even older browsers already behave this way (backward compatibility and everything).
Relaxing the content model for a in HTML5 is based on observations on actual browser behavior: the original syntactic requirements were not really enforced. This can be expected to go as far as you can get. (I tested this on IE 6 and Firefox 3.)
So there is no need for compatibility. But it would surely not be “semantic” to split a link element. Two links are semantically different from one link, for any reasonable semantics for “semantic”. It would also be a usability problem, especially when using the keyboard to move between links.
The visual rendering is a different issue. It is not clear at all, from the HTML5 drafts or from practical considerations, how a link should be rendered, in its different states, when it may contain just about anything. This may have been a key reason behind the old syntactic requirement. Browsers do not render such links consistently. This applies at least to underlining. There can be functional differences, too; e.g., on some browsers, the area on the right of the heading text is not clickable, i.e. only the text is “active”, whereas other browsers make the entire area of the element (which is by default the entire available width for a heading) “active”.
So the basic issue, if you wish to use such a link, is to consider how you intend to have it rendered and how to do that in CSS in a manner that works reasonably cross-browser.
I know the "align" attribute of the <div> tag has been deprecated for some time now, as well as many other attributes. But you can still use it in all browsers. Has any browser ever made a step to actually not support deprecated elements of any kind?
The reason I ask is because I stopped using div align not just because it's frowned upon, but because I thought some day it would be abandoned and unsupported, as oppose to just throwing warnings in my IDE.
<basefont>
Dropped in Firefox.
https://bugzilla.mozilla.org/show_bug.cgi?id=3875
Most depreciated elements take several revisions to be worked out "completely". This is because in the interest of backwards compatibility new browsers retain code for handling these elements. Most browsers try to avoid this in an effort to retain their own share of the market. As long as the elements are still used generally then there will most likely be some level of support for them so not to lose those that want to access the content that uses them.
No, there is no evidence of any deprecated element having been dropped from browsers. Besides, what you ask in the text of your question is about a deprecated attribute, not an element. The answer is the same, though.
I recall battling with the <layer> element back in the days of Netscape 4. There were definitely web pages that depended on it, but it's long gone.
But <layer> was never standardized, and I am not aware of anything that was in the HTML 2.0, HTML 3.2 or HTML 4.01 standards that has been completely abandoned by HTML5. Sometimes though, implementation requirements are written in such a way that doesn't actually require the browser to do what you'd expect of it or be consistent with what other browsers do. <blink> is one such element. <keygen> is another.
Note that HTML5 doesn't have "deprecated" elements and attributes, only "obsolete" ones. What this means is that the expectation is that browsers will support them forever, but that web authors should not use them because there are better ways of doing the same thing, or that they are harmful to either authors or users to have them on the page.
I have built a custom context menu but have found annoyingly that when I right click on my site in firefox text and images just seem to randomly get selected.
The link below is a basic html dump of the page that is having issues. You can see that when you right click it in Firefox, certain elements are highlighted. Very annoying! This must be a purely html markup problem in Firefox as there is absolutely no CSS or JS on this page.
Example Here:
http://pastehtml.com/view/1e16jup.html
Love to hear your thoughts/suggestions...
There are a lot of errors in this page have a look at the validator result here.
Maybe it gives firefox a lot of problem rendering the page properly.
Close all the <meta> and <img> tags, <script> must have proper type attributes, tags like <h1> shouldn't be placed inside of <a>, <p> neither.
I'm assuming you mean the HTML5 contextMenu? Because this is not implented in any browser.
A bit of quick investigation seems to demonstrate that the header+footer elements have this behaviour. Also, lists appear to have it as well. This is because those elements have a certain semantic use and this behaviour seems consistent with those semantic uses. Check out the specification to see how these elements are intended to be used.
I'm firing blind but I'd suspect you can override this with -moz-user-select - but this is going contrary to the Firefox user experience. I wouldn't recommend it at all.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
(I'd like this to be the definitive community wiki. I seeded it from my own answer to this question.)
Specify Everything
A lot of cross-browser issues amount to this: you didn't specify something, and different browsers make different assumptions. Therefore:
Declare a valid doctype
Your doctype tells the browser what rules you'll be using in your code. If you don't specify, the browser has to guess, and different browsers will guess differently.
In my experience, a "strict" doctype makes IE behave better (enables things like CSS :hover selectors on divs in IE7).
This article gives good background on doctypes.
Use Web standards
Avoid browser-specific markup, or only use it when its failure in other browsers won't be significant to the site experience.
Validate your HTML and CSS
You don't have to get everything perfect, but validation is good feedback. As Jeff said:
Knowing the rules and boundaries helps you define what you're doing, and gives you legitimate ammunition for agreeing or disagreeing. You can make an informed choice, instead of a random "I just do this and it works" one.
Imagine you opened a paragraph tag and never closed it. If you then open a list tag, did you mean it to be inside the paragraph or not? Validating will help you catch that, close the tag, and eliminate ambiguity.
Consider a CSS Reset
Different browsers assume different baseline CSS rules. You can help them all to act the same by explicitly ironing out the differences up front. Eric Meyer, who wrote CSS: The Definitive Guide, uses this reset. Another popular choice is YUI Reset CSS.
Use a Javascript library for DOM interactions
Whenever your Javascript needs to work with elements on your page, it's best to use a library like jQuery, Prototype, or MooTools. These libraries are used by many thousands of developers, and they take most of the inconsistencies between browsers' interpretation of Javascript, deal with those internally, and give you a consistent set of commands that just work. Trying to find and work around all these inconsistencies yourself is a waste of time and likely to create bugs.
Test in multiple browsers, deal with IE last
Test in multiple browsers as you go. Generally, you'll find that non-IE browsers behave similarly and IE is a special case - especially if you follow the advice above. When necessary, you can add IE hacks in a separate stylesheet and only load it for IE users.
Quirksmode.com is a good place for hunting down random browser differences.
Browsershots.org can help show how your page will be displayed in an assortment of browsers and operating systems.
Fail Gracefully
No site will look perfect in every browser that exists. If a user doesn't have Flash, or Javascript, or advanced CSS, etc, you want your site to be usable anyway. Design with that in mind:
Check the bare HTML
Try loading your site with bare HTML - no styles, no scripts. Are menu options available? Does primary content precede secondary content? Is the site usable, even if ugly?
Consider test-driven progressive enhancement
Described in this article, this technique uses javascript to check if a browser has a given capability, such as support for a given CSS property, before using it on the page. It is unlike browser sniffing because it tests for features rather than a specific browser.
Use a library like jQuery abstract away the differences in the DOM, AJAX and JavaScript.
Make sure you're keeping HTML, CSS and Javascript in separate files as much a possible. Mixing structure, presentation and behavior in your HTML file just makes finding and fixing problems harder.
Use Firebug in Firefox for:
Debugging/stepping through your JS.
Seeing how your stylesheets are being interpreted and hacking them up on the fly to see how to fix your problem.
See how many calls you are making for remote resources and how long they take.
Profile your code.
Chrome and IE8 have similar tools built-in that can be used for the same thing.
Opera and Safari (and IE) have Firebug Lite.
Use CSS Reset on start of your stylesheet...
You can get one here...
Validate your code by w3c ...
You can validate your code here by page link or simply copy paste page element
My #1 rule is use a strict doctype. HTML or XHTML is fine, but using the strict doctype removes pretty much every browser quirk there is, especially in IE7+.
Imagine you opened a paragraph tag and never closed it. If you then open a list tag, did you mean it to be inside the paragraph or not?
Actually you can't put any other block tags inside a <p> tag, that's why the spec allows you to omit the closing tag. If you start a list without closing a paragraph, then the paragraph is implicitly closed. And the validator won't complain.
That's not to say you shouldn't close tags, because it generally makes code easier to skim (you don't need to remember the above rules).
Consider programming you web-site's UI using Google Web Toolkit. With GWT you write all code in Java programming language which GWT then cross-compiles into optimized JavaScript that automatically works across all major browsers.
I think using best practice is the way to go, progressive enhancement is designing with the user in mind and needs to be done with all designers. I believe that a lot of testing on browsers is a good way to ensure proper content is being displayed, many developers over look this.