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.
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!
A website I am working on uses Adobe Search&Promote (SP) as it's internal website indexing and searching tool.
I need to exclude common parts of each web page from being indexed by SP (such as the header, nav, footer) because they are the same on every single page.
SP's documentation states the following:
"To prevent parts of individual web pages from being searched, you can exclude portions of a page from indexing. Surround the text with <noindex> and </noindex> tags. This method is useful if you want to exclude navigation text from searches."
Of course, <noindex>, is not a standard HTML tag/element.
Is there javascript or something I should be doing to register/create this fake tag in browsers so I don't have to worry about any strange behavior as a result of having a non-standard HTML tag just hanging out in my code? Or should I just not care because browsers will ignore this non-existent element?
Note: There is absolutely no styling that needs to be done on this <noindex> element. It simply needs to wrap around content in the HTML.
There is nothing you need to do. Browsers are expected to ignore unknown tags, and they do, so they see <noindex>foo</noindex> just as foo. Well, not quite. Technically, modern browsers construct an element node (of type HTMLUnknownElement) in the DOM. But the element has no associated default styling and no associated action, so it’s really a dummy element and represents its content only.
It would be possible to remove such elements nodes using client-side JavaScript, but that would be quite unnecessary.
The only real risk is that some day some specification or some browser or some web-wide indexing robot might start treating noindex as a real element with some defined meaning, possibly with default rendering and default functionality. Then you would be in trouble if these differ from what you expected. But it’s a rather small risk, and it seems that you don’t have a choice.
Although it's not in the documentation, our team consulted an Adobe consultant regarding this. He told us that we can use a 'noindex' class instead of the <noindex> element. He was even recommending us to use the class instead of the tag.
A warning though, the 'noindex' class is only working with <div> elements but not on other elements such as <ul>, <header>, or <footer>.
So a usage will be something like this:
<div class="noindex">
<p>This should not be indexed.</p>
</div>
I am using <p> tag for inserting Arabic text into the html page, and giving the CSS property text-align: justify; with particular width and height in pixels.
With this, there would be the paragraph including inconsistent space between the paragraph words; how can we use the same with proper word-stretching (with proper tatweel/kashida) inside the word?
I have tried it with the text-justify: kashida CSS property, but it's only working with IE, not for any other browser! As per the image shows, it is clear that the text-justify: kashida is not supported by Mozilla, and other browsers expect the IE.
How can I get the same behaviour in all browsers, to display the same as Internet Explorer?
Unfortunately seems kashida is dropped from CSS3 text and deferred for CSS4 text, so if you want justify your text with Kashida, you should try porting harfbuzz-old adding kashida algorithm (that its algorithm is removed from newer generation of harfbuzz, ref) which is based on a Microsoft specification that is archived here. Here is Microsoft's kashida insertion priority table that you should try to implement somehow:
ّAdding Kashida («ـ») for text styling on HTML itself is not a good idea (because if user copy the text it will contains added Kashidas and it will make problem for browsers find-in-page) however as current webkitbug/blinkbug (Safari/Chrome) versions do not support joining cursive script characters (like Arabic/Persian) during inline (pseudo)elements there seems there is not any chance you get this type of justification without inserting Kashida (or you should handle oncopy event by your own that has its own problems).
It is also interesting that Microsoft is extended IE Kashida justification implementation to support more interesting things like text-kashida-space (configure ratio of kashida to white space expansion while text justifying). Seems we must wait another decade to these get implemented across all major browsers.
The text-justify property was implemented in IE, and it is not part of any completed CSS specification. It exists in the Working Draft CSS Text Module Level 3, but even there, it is marked as being at risk: “The following features are at risk and may be cut from the spec during its CR period if there are no (correct) implementations: [...] the ‘text-justify’ property, particularly its ‘kashida’ value”.
From the authoring perspective, the best you can do is to hope that other browsers will catch up. The styling requested is relatively complicated and probably not anything you can imitate with JavaScript in the same sense as you can “polyfill” CSS properties
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.
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