I have the following code within my HTML, which seems simple enough:
<div>
<a" class="test">Test</span>
</div>
But when I go to render it, the a element gets replicated all over the page. Any idea on why this is happening?
Modern browsers use HTML5 parsing algorithm which has special rules for misnested tags: http://www.w3.org/TR/html5/syntax.html#an-introduction-to-error-handling-and-strange-cases-in-the-parser. Different behavior with inline display, I guess, is due to different white space processing models for inline and block formatting contexts, resulting in different text content that appears in the implicit elements created by this algorithm.
You're not using your HTML tags correctly.
<div>
<a class="test">Test</a>
</div>
The code above should render correctly. You must close your anchor tags with < /a> and not a < /span> tag.
(Pardon the space, it wouldn't render the HTML without it.)
I ran into this issue earlier and found a number of things after diving deeper into it and I thought it was worth sharing my findings. I was able to replicate the issue with this simple code:
<div id="one">
<div id="two">
<a class="test">Test</span>
</div>
</div>
<div id="three>
<div id="four">
</div>
</div>
The above code will render with not one, not two, but three instances of the a element, without the content, but with css classes intact.(in one after two, and wrapping three and four).
But wait, it gets weirder:
If you replace the ending span tag with </div> the link is still
replicated, but now only twice, with the link wrapping three and four no longer present.
If you add style="display:inline;" to the version with an ending </div> the behaviour will be the same as with an ending span. Even stranger once you realize that a is already an inline element.
The results are consistent across browsers, meaning it is most likely not just a quirk of one engine, but something inherent to HTML. (Tried on webkit and Gecko browsers, but haven't tried Trident yet).
Hope you find this interesting/useful. Certainly threw me for a loop the first time I saw it.
Related
I need to hide a
</div>
without JavaScript or Jquery. I tried
<span style="display: none;"></div></span>
but it didn’t work at all.
Any help is much appreciated.
EDIT:
Thanks for confirming that it is NOT possible!
That’s what I wanted to know.
I solved my problem by changing my markup a little bit.
In my case it would have been logic because it simply would have saved some lines of code. (Basically I wanted to insert a div into another when a user activates an option, hiding just one closing tag and one new div opening tag when the option is disabled, showing them when the option is activated. It’s a tumblr theme with some closing tags rendered in {block:Posts} after every post. No need to get further in detail, i think it would be unnecessary complicated because the problem is already solved. Thanks!
I can think of absolutely no logical reason for doing this. even though a div tag may look like two elements to some, it is in fact one element and neither the starting nor the closing tag function on their own.
The fact that a
</div>
tag is being displayed suggests that you have an extra closing tag - there is no corresponding
<div>
opening tag. These tags should never be displayed on a page if implemented correctly.
Try looking through your code and checking every opening
<div>
has a corresponding
</div>
In html all tags must be in pairs, having one opening and one closing tag. e.g.
<div id "test">
Test text!
</div>
JP
Will inserting line breaks in HTML like this affect the output?
<header>
<div id="someid">
something here
</div>
</header>
I've been trying to study web development, and different tutorials use different formats. Will the extra lines between tags affect the output? I personally would prefer it that way since as a newbie, it looks more readable to me.
No - whitespace is collapsed in the output.
Primarily that means two things:
1 - Leading/trailing whitespace in an HTML element is not displayed, so these two divs will display the same:
<div>Some stuff</div>
<div> Some stuff
</div>
2 - Multiple whitespace characters in a row will be collapsed into one space. That means these two divs will display the same:
<div>Some stuff</div>
<div>Some stuff</div>
Here's a nice article for further reading.
No, it does not. I think what you are looking for is something like this:
<header>
<div id="someid">
<br>
something here
<br>
</div>
</header>
The <br> tag produces a newline in text.
Whitespaces are ignore from the output, at one or two exceptions (fortunately, you can see this at an advanced level only)
You can put 1 blank line or 1000, the result will be the same
Linebreaks won't affect the rendering, but multiple whitespaces are collapsed into a single space, which might make a difference.
For example, when you're indenting tags for readability the output will have a space between the tags. When your intention is for those elements to sit directly next to each other you'll find they don't.
See this link for examples and techniques to combat the unwanted space.
No,.. but sometimes yes.
At an old job they had to remove newlines and indents from divs because of some bad bootstrap grid CSS (an early unofficial copy that mutated over time) that they used across all their sites.
This was a really weird issue that baffles me and we basically had to always make sure our closing tags for 'cols' were on the same line as the next opening tag with no whitespace at all.
Eventually, I stopped this by convincing them to use an official bootstrap grid.
I've been working with contenteditable recently within a HTML5 page and encountering bugs when using it with certain elements, and I'd like to know where and how I can actually safely use it.
I've discovered that making a span element contenteditable results in some buggy behaviour in both Firefox1 and Chrome2. However, making a div or section contenteditable appears completely safe3.
A guideline a couple of people have mentioned is that only block-level elements should be made contenteditable. However, the Mozilla Developer Network lists the heading elements h1 through to h6 as block-level elements, and making a heading element contenteditable is buggy in Firefox4 and can crash the page in Chrome5.
I'd like to be able to use more than just divs and sections, but I'm not clear on what elements I can actually safely make contenteditable. By safely, I mean that using the element under normal conditions, I should be able to perform normal editing tasks without it doing unexpected or buggy things. I should be able to write in it, delete content, cut, copy, paste, and move my text cursor about and highlight text without unexpected or strange behaviour.
So, which elements can I really make contenteditable safely? Is there a specific category? Are there certain criteria the safely-contenteditable element must match?
Bug notes:
Firefox 21 w/ span: Element loses focus if the text cursor is brought to the beginning or end of the element, but not if it got there by deleting content. Highlighting part of the element, cutting and then pasting will split the element in two at that point then insert a blank element between the two parts - without actually putting the text you were trying to paste anywhere.
Chrome 27 w/ span: If the span covers multiple lines e.g. by being wordwrapped, cutting and pasting content will often insert a linebreak after the pasted content.
Unless you make the div display:inline, in which case it can still lose focus as in 1, but apparently only if you bring the text cursor to the end. I don't consider this "normal" usage of the element though.
Firefox 21 w/ heading: Selecting part of the content then cutting and pasting will, similarly to 1, split the heading element in half at that point, and insert a third heading element between the two halves. It will, at least, have your pasted content inside it, but now you have three heading elements where there was originally one.
Chrome 27 w/ heading: Select some content and cut and paste. The page crashes. You get an "Aw snap!" message. That's it.
Demo code
Here's a demo for reproducing the above. It's pretty simple, though at the moment the only thing it isn't reproducing is the lose-focus bug.
[contenteditable=true] {
border: 1px dotted #999;
}
<article style="width: 100px">
<h1 contenteditable="true">Heading</h1>
<p>
<strong>Some adjacent content</strong>
<span contenteditable="true">Span! This is long enough it will spread over multiple lines.</span>
</p>
<div style="display: inline" contenteditable="true">An inline div also with multiple lines.</div>
</article>
In my opinion, I'd say div is the safest bet across the board. Any element you wish to truly edit (be it a span, header, etc), you can place inside the div and edit as if it were just that element. Also, to account for the display:inline issue you mentioned, you could always use float:left or float:right on your editable div to give it an "inline feel" without having it actually be inline.
Hope that helps!
Since this is an evolving feature with, apparent, low priority from the browser vendors support has been sketchy and regressions not uncommon. The current state of affairs is evolving, so check the Googles, CanIUse etc and make sure support is there for your sites visitors, everything else is moot ...
Support in Firefox seems to be solid, at least for some elements, now https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content
It works well in Chrome as well as far as my testing goes.
And CanIUse looks good: http://caniuse.com/#feat=contenteditable
There are a number of different bugs related to the feature in the different browsers though, but for simple use cases it should be ok now, as of August 2016.
JS Fiddle Link http://jsfiddle.net/Xfvpu/1/
Okay so I have a document with xhtml doctype and I use the proper br / tag
but for some reason the gap between two images renders differently in Firefox than it does every other browser.
The page is can be found at http://www.safaviehhome.com/Rugs/Area-Rugs.html
the CSS is all mixed up unfortunately so I can't explicitly post it, but the two images are within a DIV wrapper, and the images themselves are not in seperate divs. They both have image maps, and the size between the two images width only differ by around 20px.
In between the two images are two br /
tags, I tried fiddling around in Firebug but could not figure it out .. And I won't be happy until I figure this out .. it's pissing me off! :)
The difference between other browsers and Firefox is around a 10px difference .. Firefox adds extra spacing .. I'm not asking for any help specifically, just wanted to see if there is some rendering issues I'm not aware of so I can put this issue to rest.
Look in other browsers vs Firefox to see what I mean .. I would really appreciate some help I need to figure this out for my own knowledge.
You cannot rely on using <br/> for vertical spacing. You need to use styles, such as
<div style="margin-top:5px">image goes here</div>
Or even:
<img style="margin-top:5px" src="yourimg.jpg" />
In my experience browsers are sufficiently consistent if you use this approach.
Edited to add:
But (and I can't stress this strongly enough): browsers will never be entirely consistent. Designs which assume that 100% consistency is possible will fail. (If this seems harsh, try getting through one day using only your smartphone's browser. Yuck.)
While I do not know the exact reason why Firefox acts like it does, I can offer an advice. From my experience using br tags for layout are, er, not the wisest idea, since you easily lose control of the exact spacing it creates. Like in this case, where it seems that Firefox intreprets two br tags as two lines, whereas at least Opera take the first one as a line break after the map and the second one creates this empty space.
You didn't ask for a workaround, but I can't resist: take a look at br-less alternative.
I'm wondering if anybody knows the meaning of this tag I found in a valid html file I've downloaded.
<div style="clear: both;"> </div>
Thanks for help in advance.
It clears the floats from both left and right in order to bring the content after it back into the main flow of the page.
Official definition.
The technique is known as a "spacer div" - the article is now ten years old and at the time this was a good solution to a common problem. It typically appears in scenarios like this:
<div class="container">
<div style="float:left">
...
<div style="float:left">
...
</div>
<div style="clear:both"> </div>
</div>
The inner divs are floated - if you simply left out the "spacer div" the container element would not completely enclose its contents (unless you float it itself, which is often impractical). The is needed in some older browsers (you know which one) to ensure it behaves as expected in all situations, i.e. a simple <div style="clear:both"/> didn't always work - you really needed a div with actual (though invisible and nonsensical) content to make it work everywhere.
It's a working solution to a common problem, but there are more elegant ways to solve this, e.g. using the :after CSS pseudo class. This is more elegant because it doesn't require us adding semantically worthless markup elements that are just there for styling purposes. Another great article with a different solution.
This tag will not allow any float to be place either left or right of this tag.