As far as I can see, a piece of code like:
/ This is a comment that will never get displayed, even in the source code
Will never be seen, and so seems to have no use? Why would a person ever use it when there is
/! This is a comment that will only get displayed in the source code
Which will comment the code when it is compiled to HTML.
Is there something that I am not getting? Why would anyone make an invisible comment?
I think you mean /! - you had them the other way around in your example.
/! produces an HTML comment
/ produces a comment in the code which doesn't compile to HTML
Sometimes you want to published your comments so the outside world can see them. Code copyright, attribution or legal notices would be a good example of comments you want everyone to see when this compiles to HTML.
Code comments stay in your slim templates so will only be visible by people working with the template. Since comments are usually there to help developers and people working with the code rather than the general public, it makes sense to not compile most of this stuff into HTML. So "invisible" comments are actually visible to the people that need to see them.
The "invisible" comment will be seen by the coder reading the slim template, so it can be useful for a future coder to understand why you did something. This comment won't be seen by anyone checking the generated html source code once the page is online.
The other type of comment will also add html comments, so thru will be visible online.
Related
I have a website and need to transport a form to another website. I however only need certain tags not the whole form block with all it's tables and divs.
When selecting a html-tag in inspector, I can copy inner HTML, outer HTML or CSS styles but how can I just copy that very exact tag I selected without it's child nodes, just the selected line in HTML code?
I ask this because the HTML is minified and I can't just select and copy a tag in source. Same when I chose "copy outer HTML" I get the whole HTML subtree minified, means everything in one line.
How can I quickly search and copy certain tags from the three without grabbing everything in the branch?
Edit: People, thanks for all your suggestions but please note that I wrote about a MINIFIED HTML page I have here.
Just open Debugger near Inspector
Then find page file... then copy with any select range as you want
UPDATE
if it minify click here
If I understood what you want try this
Since your question seems unsolved yet, let me come up with a creative approach I use for similar tasks from time to time:
(1) Creative solution: Page manipulation
If you don't have a javascript framework of your choice (e.g. jQuery) on that page, add it using a browser-extension that adds it when page has loaded.
Then you write a bit of javascript code that removes unwanted child elements of the desired parents in a loop or so. That sounds like lots of work but since you asked this question I assume you need dozens if not hundreds of elements so it might be worth taking the time to write such loop(s).
When the code you injected processed the page and removed everything you don't want, you can then copy the code like mentioned by others here.
(2) Alternative solution: Beautify the code beforhand
If the given solution(s) don't work for you, one could try to beautify the code by copying the source to a webpage that auto-indends html/js code. You could then optionally save it into a html-file and approach that one again like mentioned here before.
Sidenote
If either this idea is too much work or you need this frequently you are probably approaching this on the wrong side. When working on frontend (only) you are always limited to what you have. If you could approach from the backend you could then build from the data/information whatever you need. If you could provide a bit more information about why you need this and how much code you are talking about one could maybe come up with a more sustainable solution!
I know near to nothing of html, but I do maintain a blog.
I want that blog to be on bloglovin, but they tell me the RSS feed is not valid. What they give me is this tool that "checks" my code
here the instructions.
here the tool.
http://validator.w3.org/check?uri=http%3A%2F%2Fmisbollosyotrascosas.blogspot.com.es%2F&charset=%28detect+automatically%29&doctype=Inline&group=0&user-agent=W3C_Validator%2F1.3+http%3A%2F%2Fvalidator.w3.org%2Fservices
So main problem is, I dont know what doctype my blog has, nor I've been able to find info about it, so I don't know if checking said code on html5 is correct, or no. It's set to "detect automatically" so I'd guess it's getting it right, but I can't really be sure.
So, 1st problem: I don't know how to check the doctype.
2nd and more important, IF it has guessed the doctype properly, and it is html5, when I look for the piece of code the tool says it's wrong, said code does not appear. So I can't change code that isn't there.
Please mind 90% of the code is auto-generated, I do know programming, just not on web.
If anyone can point me of a way to fix this issue, much appreciated.
If you nothing about HTML, then brother you first need to either learn HTML and then come here for help. Or you should go to the forum or the place provided by the CMS (Blog service provide) for the users to chat about the product usage.
However, the DOCTYPE is provided in the very first line. If you open Document Inspector, you'll see a grey line in Chrome as: <!doctype html>. That is the declaration for HTML5.
Here is the w3.org's doc for the HTML syntax: http://www.w3.org/TR/html5/syntax.html
And here is the declaration for the doctype: http://www.w3.org/TR/html5/syntax.html#the-doctype
Secondly, if they didnot find the document to meet the standards for the HTML5 then there might have been an error.
On the page, where you tested your DOCUMENT's code. They provided you with 113 errors in your document.
Please go and edit and fix them one after the other. To get help, go and Google the problem. 99% problems are solved by just Googling the problem and following the first 5 links if first 4 don't work. Otherwise, you can come back here and start a new question related to that problem. Programmers here would help you in doing that.
I recently was handed an old template to make changes to. Its a really long horribly indented one. In the process of adding new design, I seem to have deleted </div> tags in several places, and the whole thing now seems to have taken an entirely new shape. Is it possible to easily identify which <div>'s don't have a </div>. Dreamweaver was good at this, but we don't use it anymore.
Can you please suggest tools, browser add-ons or anything else that can help do this?
The program you are looking for is HTML Tidy
From the documentation:
When editing HTML it's easy to make mistakes. Wouldn't it be nice if
there was a simple way to fix these mistakes automatically and tidy up
sloppy editing into nicely layed out markup? Well now there is! Dave
Raggett's HTML TIDY is a free utility for doing just that. It also
works great on the atrociously hard to read markup generated by
specialized HTML editors and conversion tools, and can help you
identify where you need to pay further attention on making your pages
more accessible to people with disabilities.
I remember reading a while back on some random website about a program that would look at multiple pages on an HTML site and detect the differences/similarities between the pages to automatically detect which parts were template "boilerplate" and which parts were new content, and then based on this, automatically spit out just the parts that are content.
Unfortunately, I didn't remember enough details about this utility to actually find it on google, so I wonder if any of you guys have run across anything like this, and CAN remember the name of it.
Thanks.
Murphy's Law (or is it some other law) has stricken, and I've found it just moments after I'd given up and posted this question. The project I am thinking of is this:
http://code.google.com/p/boilerpipe/
Thanks.
I have worked a few places which haven’t used source control. They seemed to get into the habit of putting comments around code they changed explaining the change so that things could be reverted.
I have found that this makes the code very difficult to read, and have been fairly adamant that such comments are not needed after introducing source control as the revision history will let you match up tickets with changes.
However now, I am not so sure, I think it may be good to document major revisions to a file in a file as well as in the commit messages. This should make the code more readable. Do people have a best practices way of documenting changes to code, so that it is not too cluttered but is still explanatory to someone trying to read it?
Just to be clear, I am not talking about a list of changes in the head of the file (which is a whole other argument) but comments in the code.
Most source control systems have an "Annotate" or "blame" command. It shows what code changed with each revision.
Since this information does not change the behavior of the program, or make it easier to understand the program, it doesn't belong in the program.
The documentation present in code should describe the code it is near. If the code changes, the documentation should also change accordingly. The version control system should take care of managing what changed and why it changed. Let the code and it's documentation do it's job (Doing things, and describing how/why those things are done), and let the version control system do it's job (controlling/documenting versions and changes).
Whenever you start indicating history in the present(current code), you are asking for trouble. Just think what a particularly change-heavy area of code would look like if it had a number of changes?!
If the comment is time sensitive don't do it it's a bad idea. Put a comment on the source file in the version control system instead.
I see this problem all the time at work. The code base I am currently working on extends back to 1979. You can imagine the difficulty with comments like the one below which have built up over that time:
"Line below seems to fix bug xyz, will revert if unforseen issues occur"
I realise it's not a very descriptive comment in the first place but that sort of thing in svn/cvs/etc. is actually very handy. A comment like that in the code sows the seeds of doubt. Can the comment be removed? Is the unforseen issue that has caused me to have to look back at the code related to this comment? etc.
I'm just wondering how knowing what the program USED to do helps understanding it now? You say it aids readability. How?
Now, when something is changed because the old way didn't work and the new way is counter-intuitive, I think that should be commented in code, because it's necessary to know for all time "This didn't work, don't do it again. I know it looks like it would make more sense. Still don't do it." Otherwise, I don't see that it helps.
Don't think that commenting changes inside a code is ever possible in a explanatory way.
But I'd like to say about "Modification history at the file begin". I doubt that this is useful at all. Unless I wanted to know which to versions of a file to compare to see the difference that were introduced with some "NNNN" task. In the file begin there is a line "NNNN date - small description". And our source control can "say" who and in which version this line was introduced.
So without this line I would look through all versions to find correct one.
I think it's good to document major changes or refactorings as comments in the code. I agree that it does get a little messy to read around copious amounts of comments, but I think it's easy enough to ignore the comments and try to just read the code. If anything is confusing, or you are tempted to change something, and there is a comment near by, you will be much more inclined to read the comment, as opposed to doing diffs with previous versions to see what had changed and why.
Each method in our codebase has its own change history. When the code of a method is changed its header gets a new entry. The code itself does not get cluttered with history comments, only the method header. Each change history entry consists of one or two lines briefly describing the reason for the code change in general terms. The entry also contains a number that refers to a change document, The change document also contains links to bug reports, development projects, design documents etc.
Such entries are invaluable, as they often give you an insight as to why the code is as it is. If you are there to fix a bug the history trace will invariably tell what code change introduced the bug, what the change was attempting to do, and therefore what else you need to be aware of when deciding on a fix.
OTOH - Reams of comments in the body of the code describing what it does and who changed it when are just noise.
Going to have a stab at answering this myself.
Documenting every change in the source makes it difficult to read, however if there is a particularly counterintuitive piece of code in there and it was introduced for a particular ticket put a note by it as to why the code is strange.
But the code should still be documented. So while you make not put in
/* ticket 101: add blink tag to headers, JF - 20010102 */
You may want to put in
/* make headers blink */
Quite often when people stop doing the former type of comments, they cut down massively on their comments and this is bad.