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.
Related
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.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is putting a div inside an anchor ever correct?
I want to have a link on a complex element (containig images, paragraphs and other stuff).
I know it works, but is it ok to have a <div> element inside an <a> element ?
Yes … and no.
No complete HTML or XHTML recommendation allows it.
The HTML 5 draft does permit it, but you may have to do things such as explicitly setting display: block on the anchor to get it to work in some browsers. You may find that others simply don't support it (I'd like to be able to link to a reference that shows browser support for this, but don't know of one, please comment if you do.)
That said, while have nice big click targets can be useful, it isn't an approach that is friendly to the "skim through links mode" that some browsers (especially screen readers) have. You might be better off using a regular link in the content, and applying some JavaScript to react to a click on the whole element.
In XHTML1.0 and HTML4.01: no. a is an inline element that can only contain other inline elements (but not another a).
In HTML5: yes, you are allowed to do that. BUT consider why you would've hundreds of characters in a link.
It's bad for SEO (dilution I believe) and bad for many disabled users ("Hey screen reader, tell me what does this link do?" - "Let me read to you aloud this link for half a minute") and perhaps bad for usability.
Another solution would be to put a link on say your heading in your div or some meaningful text. Then in JS make your div behave like what you wanted to do initially. Then it'll work for users using an assitive technology (screen readers and alike), for keyboard users (they can tab through the link) AND for sighted mouse users with JS.
No, unless you don't care about IE7 and down. The link will not function properly in IE7, even if set to display:block.
I'm working on a website project w/ a team. And they started the code, it seems messy for me.
we're having php includes for some sections of a page.
e.g. in the part of index.php we have:
<?php include("pages/header.tpl");?>, and inside this, we also have:
`<?php include("pages/submenus/commercial.sbm");?>`
inside, header.tpl are the menu bar,
and inside commercial.sbm are the pop-up hover submenu items.
The thing is, in these 3 files, we have <html>, <head>, <body>, <script>,<style> tags
so, these tags now are being repeated in one page -eg. when i view source index.php
I know this is not a valid HTML mark-up right?
My question is, what would be the outcomes having this kind of code/ html markup.
Thanks!
This really depends on which browser you're using and how it parses the file. If you use the developer tools in chrome, safari, or firefox (via firebug), you can see the end result of the parse. Browsers that implement the HTML 5 parser algorithm should all give the same result for malformed markup such as duplicate head and html tags, but there are still many browsers in use that don't.
The best option is really just to fix the bad markup.
i am working on a project using html5 properties like <header>,<article> etc... it's work fine.
but when i review it & saw that i wrote <heder></heder> instead of <header></header> but the structure work well in all browsers.
so can anyone explain it.
Browsers don't do anything special with elements they don't recognise.
If the page didn't depend on any particular rendering of that element then replacing it with a different one (that had no default styles applied to it) wouldn't make a difference to the visual rendering.
I've seen many uses of rich-text or at least natural-looking text editing being made available with seemingly any of a page's text-containing elements. What are my options to have this for myself?
I think you may be referring to the contenteditable attribute in HTML5. This attribute allows any arbitrary HTML element to literally become editable. It has a fairly wide support, mainly because before its appearance in the HTML5 specs it is actually a proprietary Internet Explorer attribute.
The downside of this is that, like any other form element, the appearance and capabilities of this varies wildly from browser to browser, and the quality of the HTML produced is truly atrocious. Still, if you want to have a look, go ahead and hit some of these links:
http://html5demos.com/contenteditable
http://blog.whatwg.org/the-road-to-html-5-contenteditable
Are you looking some some thing like tinymce ? If so check this