<p> errors -don't understand the missing "li" problem in my paragraph - paragraph

I keep trying to validate my webpage and I keep getting the same errors below...and all I have are text in paragraphs. They are not meant to be lists or anything like that. See errors below.
Line 61, Column 3: document type does not allow element "p" here; assuming missing "li" start-tag
<p>Try a fun way to raise money for a worthy cause with your neighbors, girl sc…
✉
Line 62, Column 40: end tag for "li" omitted, but OMITTAG NO was specified
Read more</p></ul><!-- end zachadtext -->
✉
You may have neglected to close an element, or perhaps you meant to "self-close" an element, that is, ending it with "/>" instead of ">".
Line 61, Column 1: start tag was here
<p>Try a fun way to raise money for a worthy cause with your neighbors, girl sc…

It sounds like you opened a <ul> or <ol> element prior to the <p>. Such elements can only contain <li> elements. (If you want more detailed help, paste your code somewhere.)

Related

How do you accept the automated HTML tags from Brackets text editor?

Can somebody please explain in detail how to accept the automated tags that Brackets suggests/adds?
Example: I start typing out an element...
<abbr title="World Health Organization">
and immediately Brackets will add an ending tag...
<abbr title="World Health Organization"></abbr>
where my cursor is between the opening and closing tags. It's perfect because I can just type out the abbreviated content...
<abbr title="World Health Organization">WHO</abbr>
However, this is where I have a problem. My mouse is at the end of the content and right before the closing tag. If I press the "Tab" key, then suddenly Brackets turns my abbreviated content into another tag...
<abbr title="World Health Organization"><WHO></WHO></abbr>
If I instead try pressing the "Enter" key, then Brackets just makes a new line for my cursor...
<abbr title="World Health Organization">WHO
and my cursor is still stuck before the ending abbr tag. I want to accept the ending tag Brackets added and move on. If I were to just type the ending tag anyway, ignoring the tag Brackets added, then I will have two ending tags...
<abbr title="World Health Organization">WHO</abbr></abbr>
At this point, I'm guessing when you're done typing the content, and Brackets has that ending tag added automatically, you just use your mouse to move the cursor past the ending tag to keep coding?
Or if you want to stay typing on your keyboard, you move your hand to the arrow keys and press the right arrow 7 times until the cursor is past the ending tag that Brackets added to keep coding?
If this is the case, then it seems more efficient to use Notepad to just type the ending tags yourself. I just feel like I'm missing something extremely simple that everyone else gets and is efficient using, and I can't find any answer beyond "just use tab" or "just use enter." Thanks to anyone who helps!
There is a key in your keyboard called "End". Press that key when you need to go to the end of any line. It doesn't matter where you are writing, it'll send your caret to the end of the line. So that you can press enter then.
And The "Home" key does the opposite. It sends the caret to the start of a line.
Have a great day.

Indenting HTML tags on multiple lines

I can't find a guideline on how to indent HTML tags on multiple line, and the solution I am currently using doesn't really satisfy me.
Imagine we have an extremely long div declaration, such as:
<div data-something data-something-else data-is-html="true" class="html-class another-html-class yet-another-html-class a-class-that-makes-this-declaration-extremely-long" id="just-a-regular-id">
In order to avoid scrolling horizontally when I find these huge lines, I usually indent them in the following way:
<div
data-something
data-something-else
data-is-html="true"
class="html-class another-html-class yet-another-html-class a-class-that-makes-
this-declaration-extremely-long"
id="just-a-regular-id"
>
<p>Some element inside the DIV</p>
</div>
Which I think works pretty well in terms of readability, but I have some concern.
Is this way considered a good practice?
Would you find more readable to leave the closing > in the opening HTML Tag inline with the last element, or on a new line as I did in the example above?
Do you have any other preferred way to deal with extremely long HTML declaration?
Feel free to share if you know some good resource about style guidelines for HTML that cover this special case, because I didn't find anything specific online.
The Google HTML/CSS Style Guide suggests wrapping long lines when it significantly improves readability, and offers three techniques, each of which include the closing > with the last line of attributes:
Break long lines into multiple lines of acceptable length:
<div class="my-class" id="my-id" data-a="my value for data attribute a"
data-b="my value for data attribute b" data-c="my value for data attribute c">
The content of my div.
</div>
Break long lines by placing each attribute on its own indented line:
<div
class="my-class"
id="my-id"
data-a="my value for data attribute a"
data-b="my value for data attribute b"
data-c="my value for data attribute c">
The content of my div.
</div>
Similar to #2 except the first attribute is on the initial line, and subsequent attributes are indented to match the first attribute:
<element-with-long-name class="my-class"
id="my-id"
data-a="my value for data attribute a"
data-b="my value for data attribute b"
data-c="my value for data attribute c">
</element-with-long-name>
In my opinion, #3 would not improve readability when the element contains content.
Personally I find it to be a good practice and I find it more readable using multiple lines. I use the same convention for websites that I make.
In my college we are taught the same convention and it clearly states:
Avoid Long Code Lines
When using an HTML editor, it is inconvenient to scroll right and left to read the HTML code.
Try to avoid code lines longer than 80 characters.
The rest of the convention can be found here:
https://www.w3schools.com/html/html5_syntax.asp
Would you find more readable to leave the closing > in the opening HTML Tag inline with the last element, or on a new line as I did in the example above?
I think leaving the closing > is more readable but when use vscode it can't fold properly.
Unexpected,
Expected,
The following, is my preferred method:
<div
class="my-class"
id="my-id"
data-a="my value for data attribute a"
data-b="my value for data attribute b"
data-c="my value for data attribute c"
>The content of my div.
</div>
The crucial detail here is the lack of space between the closing > and the actual content.
All the following examples can be checked online:
€<span itemprop="price">13.50</span>
results in €13.50
€<span
itemprop="price"
Arbitrary carriage returns and spaces here
BUT before closing the tag
>13.50
</span>
also results in €13.50
However
€<span
itemprop="price"> <!-- Carriage return + spaces in this line -->
13.50
</span>
or
€ <!-- Carriage return + spaces in this line -->
<span
itemprop="price"> <!-- Carriage return + spaces in this line -->
13.50
</span>
Both result in € 13.50 (Mind the gap!)

W3C Validation results don't match source code in console?

I'm trying to validate a page, however, I'm getting some confusing results.
The W3C validation results are below: Errors 1,2,3 and 5,6,7 are all the same issue, where there is a mismatch with a h3 and h2.
This is what the W3C Validator shows for the source:
This is what I see in the console:
RESULTS FROM W3C VALIDATOR
HOME PAGE - http://web1c.snow.studiocoast.com.au/
https://validator.w3.org/nu/?showsource=yes&doc=http%3A%2F%2Fweb1c.snow.studiocoast.com.au%2F#l282c50
Error 1: End tag h2 seen, but there were open elements.
From line 282, column 46; to line 282, column 50
CURRENT NEWS****
Error 2: End tag h2 seen, but there were open elements.
From line 295, column 46; to line 295, column 50
SUBSCRIPTION****
Error 3: End tag h2 seen, but there were open elements.
From line 308, column 48; to line 308, column 52
OUR PHILOSOPHY****
Warning 4: Article lacks heading. Consider using h2-h6 elements to add identifying headings to all articles.
From line 329, column 3; to line 329, column 100
area">↩↩ ↩↩
CLAIMS PAGE - http://web1c.snow.studiocoast.com.au/claims/
https://validator.w3.org/nu/?showsource=yes&doc=http%3A%2F%2Fweb1c.snow.studiocoast.com.au%2Fclaims%2F#l282c50
Error 5: End tag h2 seen, but there were open elements.
From line 326, column 45; to line 326, column 49
ESTIMONIAL****↩
Error 6: End tag h2 seen, but there were open elements.
From line 338, column 45; to line 338, column 49
ESTIMONIAL****↩
Error 7: End tag h2 seen, but there were open elements.
From line 350, column 45; to line 350, column 49
ESTIMONIAL****↩
Error 8: Forbidden code point U+0003.
At line 409, column 219
rney claim form
The w3c validator sends a request to the server (exactly the same way your browser does), gets the result (a text content, which is probably HTML structured) run the validation against this content.
However - when your browser receives the content of the page, it needs to parse it and make sure it's structure is valid (otherwise the browser will not be able to render the code), so it "fixes" some of the problems that you see in the validator. Moreover - your browser also runs any javascript code that exists in the page (which the validator don't), so if there is any changes to the DOM in your page that is done by javascript - the validator will not see these changes (while your browser will - when you "inspect" the elements).
If (for example) you will have the code <h2>some title</h3>, which is not valid - your browser will automatically change this to <h2>some title</h2> in order to render it correctly.
Note that when you "view source" in your browser - you get exactly the same thing that the validator does. When you "inspect element" (or go to the elements tab in the developers tool bar) you get the DOM of the pages after the browser fixed it and all javascript run).
Looks like that screenshot of your code is from the Chrome Inspector. Right click your page and click "View Source". That's your raw source code.
Browsers will try their best to interpret what you mean when they find an error like a missing closing tag or mismatched tags.

How to delete HTML tags, not the contents in Vim

I have the following piece of code in a file that I opened in Vim:
<p>Hello stackoverflow!</p>
How can I delete <p> and </p> tags but keep the contents between them? That is, what should I press to end with:
Hello stackoverflow!
I know pressing d i t will do opposite.
I'm using Janus.
With the surround.vim plugin installed, press d s t to delete surrounding tag.
Similar shortcuts:
d s ( - delete surrounding parentheses ()
d s " - delete surrounding double quotes ""
d s ' - delete surrounding single quotes ''
and so on...
A simple solution would be (with the cursor anywhere inside the tag):
yitvatp
What this does is:
y - yanks
it - the inside of the tag
vat - selects the entire tag
p - pastes the previously yanked text over it
Love Randy's (+1) answer and I just learned about tag blocks! This is just a supplemental answer.
So yit means "yank inner tag block" and vat means "go to visual mode and select a (whole) tag block".
This is just for those that are too lazy to read the help file:
Tag blocks *tag-blocks*
For the "it" and "at" text objects an attempt is done to select blocks between
matching tags for HTML and XML. But since these are not completely compatible
there are a few restrictions.
The normal method is to select a <tag> until the matching </tag>. For "at"
the tags are included, for "it" they are excluded. But when "it" is repeated
the tags will be included (otherwise nothing would change). Also, "it" used
on a tag block with no contents will select the leading tag.
"<aaa/>" items are skipped. Case is ignored, also for XML where case does
matter.
In HTML it is possible to have a tag like <br> or <meta ...> without a
matching end tag. These are ignored.
The text objects are tolerant about mistakes. Stray end tags are ignored.
Map this to a key of your choice:
vat<Esc>da>`<da>
Taken from http://vim.wikia.com/wiki/Delete_a_pair_of_XML/HTML_tags
I tried the dst solution with surround.vim on a larger html block. It works but it indents all child tags to the same level. It shouldn't change the indentation, messes everything up.
Randys solution with yitvatp works too, but leaves me with a blank line before and after the pasted tag.
Any perfect solution out there?

How does HTML deal with white space in the markup?

I am not talking about white space in the content, but the code itself.
I had a bunch of validation errors in my HTML and discovered it was because I was missing a space in my markup -
<td class="col_title"colspan="2">
Line 1, Column 80: attributes construct error
Line 1, Column 80: Couldn't find end of Start Tag td line 1
Line 1, Column 80: Opening and ending tag mismatch: tr line 1 and td
Line 1, Column 80: Opening and ending tag mismatch: tbody line 1 and tr
Line 1, Column 80: Opening and ending tag mismatch: table line 1 and tbody
Line 1, Column 80: Opening and ending tag mismatch: div line 1 and table
Line 1, Column 80: Opening and ending tag mismatch: body line 1 and div
Line 1, Column 80: Opening and ending tag mismatch: html line 1 and body
Line 1, Column 80: Extra content at the end of the document
All were highlighting the following line (I was validating local HTML if it makes any difference)
…1.0 Transitional//EN" "http://www.w3.**o**rg/TR/xhtml1/DTD/xhtml1-transitional.dt…
I assumed this wouldn't matter, but the W3C validator states otherwise. Adding a space between them fixed the errors -
<td class="col_title" colspan="2">
It means you have to be extra careful when writing HTML, and errors like this are a real pain to find. I was looking for missing closed tags within the table.
Does HTML deal with white spaces the same as this for every tag?
As the quotation marks are optional in HTML, the spaces can't be. The browser would not be able to tell where the value ended and the next attribute started:
<td class=col_titlecolspan=2>
Some browsers are more picky about these things than other, and it differs between HTML and XHTML. The validator is a good tool, as it's stricter about syntax than any browser. If it works there, no browser will have a problem understanding the syntax.
The W3C recommendation requires spaces:
Elements may have associated
properties, called attributes, which
may have values (by default, or set by
authors or scripts). Attribute/value
pairs appear before the final ">" of
an element's start tag. Any number of
(legal) attribute value pairs,
separated by spaces, may appear in an
element's start tag. They may appear
in any order.
http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.2
Of course, browsers are supposed to fix the errors they find and that's why your HTML works properly. However, you should try to produce valid HTML: the rendering of valid HTML is defined and (more or less) predictable but the rendering of invalid HTML is basically random ;-)