why jupyter notebook cannot display html 'table', but other html elements are okay, and how can I solve this problem?
below is my source code and my result
source code
<table style="width:20%">
<tr>
<td> **L1** </td>
<td> 1.1 </td>
</tr>
</table>
result
<tr>
<td> **L1** </td>
<td> 1.1 </td>
</tr>
it only removes tag <table> and does nothing else.
That's interesting, because the table (created by pasting your code) comes out just fine for me:
From my personal experience, I can definitely say that Markdown in jupyter notebooks is somehow volatile/unpredictable when it comes to HTML. For example, I myself have been looking for a fix for Jupyter just arbitrarily doing line breaks in the table header (esp. in formulas) and I have found this fix, but it doesn't work for me at all.
I know this is not particularly helpful, but at least it demonstrates that the table not being rendered correctly in your case was either some unexpected behaviour or some bug which maybe, or maybe not, has been fixed in the course of the last year.
You can also add the magic command before the table tag, which worked for me.
Here are my HTML test codes using Google HTML/CSS guide.
<table>
<thead>
<tr>
<th>Date
<th>Country
<tbody>
<tr>
<td>24/07/2018
<td>Myanmar
<tr>
<td>31/06/2018
<td>France
</table>
The following is how browser interprets it.
<table>
<thead>
<tr>
<th>Date
</th>
<th>Country
</th>
</tr>
</thead>
<tbody>
<tr>
<td>24/07/2018
</td>
<td>Myanmar
</td>
</tr>
<tr>
<td>31/06/2018
</td>
<td>France
</td>
</tr>
</tbody>
</table>
Here is my questions.
How the browser detect the lack of closing tag and how they interprets it.
It is preferable to use without closing elements? If it is, when should I use?
If it is not preferable, why?
Will it be impact on styling and adding interactivity on HTML semantic style?
Answers:
This is beyond the scope of SO, but just like any compiler detects something that opened is not closed. You can try and program something that identifies a valid bracket series, it would probably be similar.
Not using closing elements may break your page beyond being horribly un-maintainable. Always use closing elements.
See 2.
See 2.
Browsers sometimes can guess what you meant (better say, they parse luckily in a way that produces what you meant), but might also be wrong. See this:
<div>Hello<span>world
is this:
<div>Hello</div><span>world></span>
or
<div>Hello<span>world></span></div>
both are valid, and the browser has no idea which you meant. If you really want to get into how browsers are supposed to parse HTML, see this great link by
#modu and #kalido: http://w3c.github.io/html/syntax.html#tokenization . You may be able to workout how a browser should parse the above line.
I am starting a 'business push' campaign and would like to fire out a few very simple HTML emails, something with a basic bit of branding to catch the recipients eye. I have a good knowledge HTML and CSS and understand the fundamental rules of 'designing like its 1997' when it comes to HTML email. However, I am adding very basic code, in this case a table, into my email window, firing it off to myself to open, only to find there is nothing there, besides completely un-rendrered HTML.
Below is the code I am adding
<table style="width:300px">
<tr>
<td>Hello</td>
<td>is it me</td>
<td>you're looking for</td>
</tr>
<tr>
<td>Nightfever</td>
<td>Nightfever</td>
<td></td>
</tr>
</table>
Could any one please help me with this a little.
Any tips would be really appreciated.
Thanks in advance.
If you're simply pasting HTML code in to a new email window then it treats it as plain text so you will see the code you typed.
HTML emails have to be "processed" before sending in order to receive the design. A service such as Active Campaign will process your code for you and let you see the HTML email.
There are also a number of free templates you can look at from tutorials, boilerplates, Mailchimp and Campaign Monitor to name a few that you can play with.
I've got a Wiki which uses Textile to markup text. I'm trying to put a list within a table cell, and I can't seem to figure out how. I'm trying to replicate the following HTML in Textile:
<table>
<tr>
<td>Cell One</td>
<td>
Cell Two
<ol>
<li>Lorem</li>
<li>Ipsum</li>
</ol>
</td>
</tr>
</table>
Tried a lot of things but couldn't get anything to work. Is it possible todo this without using <li> HTML tags in Textile?
I have the same problem currently in RubyMine. I have a solution that works on Textile, perhaps it helps you:
|Cell One|Cell Two ==<ol><li>Lorem</li>
<li>Ipsum</li></ol>== test|
It doesn't work in Redmine, though :(
According to w3c </TD> and </TR> tags are optional, so the following table is perfectly valid.
<table>
<tr>
<td>google
<td>chrome
</table>
And all browsers I've tested it with render the table fine. I just wanted to ask if this is generally considered safe to use, or if older browsers, which I don't have access to, cause problems. Thanks.
It reduces gzip html size on a page with many tables by a few percent.
This is valid HTML but invalid XHTML.
There's nothing intrinsically wrong with it.
If you look at the source for Google's privacy policy (or any of their other pages), you'll find some much terser HTML.
It does mean that your page will not be usable by an XML parser.
It is safe, since optionality in the standard means that all the browsers (at least the ones which even remotely matter) would have implemented this - and the browser standards compliance usually runs to the opposite side, into trying to work correctly with even invalid HTML as opposed to failing on missing optional tags.
Having said that, I find that omitting such tags makes things harder to read, which may or may not matter to you if the goal is size optimization.
P.S. Also, if you have very large tables, I wonder whether there's any overhead incurred by the browser's HTML parser when dealing with such constructs? I am not sure without benchmarking or really deep thinking about how HTML parser works in detail, but it is something that could possibly be a factor if it happens.
I strongly recommend against doing that, though it is valid in HTML4 (and 5). The bandwidth savings are miniscule when compared to the technical debt you are incurring. Also keep in mind it is not valid in XHTML, so be sure your doctype is set appropriately.
There have been optional tags in HTML since the very beginning — they are a feature inherited from SGML, and so the early browsers must have been able to deal with them. While XHTML moved away from this and required a much more uniform syntax, this doesn’t affect you unless you explicitly tell the browser to parse in XML mode. I’ve never seen a problem when using the standard parsers of HTML 4/5.
Since HTML5 so carefully describes when certain tags are optional, I would read that to imply that someone did lots of testing to make sure that in these cases, most browsers produce the same document tree.
And while the space savings are negligible, I find that leaving off the closing tags of <p>, <li>, <td>, and <tr> simply makes my life easier when I’m working in the markup, and makes me less likely to make an error.
Personally I don't consider it good practice. Looking at the spec it didn't give a whole lot of information. I know it's required for XHTML so I looked up the HTML 5 spec. HTML 5 seems to take the same take on it as HTML 4 which is what you've linked to, but gives a little more information:
A td element's end tag may be omitted if the td element is immediately followed by a td or th element, or if there is no more content in the parent element.
I advise always closing your tags. There's not really too good of a reason not to. Browsers can handle some improperly closed tags, but just to be on the safe side (and it's good programming practice!), close your tags!
Close all tags in HTML for a few reasons:
Not closing tags is tolerated, but it is not correct modern XHTML. It's deprecated much in the same way that HTML style attributes are in favor of CSS
It's more readable for the next guy if you close the tags
Browsers will actually have an easier time parsing your source if it more strictly adheres to the rules, even if that makes the source longer
Certainly if you are using only HTML there is absolutly no problem thats not the case with XHTML nevertheless i don't think you can get that much, also i suggest dont abuse tables remember div are better than tables
It’s Ok with Static Pages not for Dynamic Pages …to debug
You should close your <TR> and <TD>tags if possible, but NOT ALWAYS because in some scenarios it may disturb you. This is because the <TR> and <TD>tags could be styled to display:none while the </TR> tag couldn't. It means that a scenario in which you want to extend / limit your display with media queries, will fail if you use </TR>. Consider the following code:
<style>
#media (max-width : 480px) {
.hidden-class {display:none;}
}
</style>
<table>
<tr>
<td>cell 1</td>
</tr class="hidden-class"> <!-- this will fail! -->
<tr class="hidden-class">
<td>cell 2</td>
</tr> <!-- this could stay -->
</table>
It means that you would write it as:
<table>
<tr>
<td>cell 1</td>
</tr> <!-- this will now close the TR for every screen width, which will destroy your extenstion -->
<tr class="hidden-class">
<td>cell 2</td>
</tr> <!-- this could stay -->
</table>
Which means that the only way to do so is by OMITTING THE in the first place:
<table>
<tr>
<td>cell 1</td>
<tr class="hidden-class">
<td>cell 2</td>
</tr> <!-- this could stay -->
</table>