So I am just learning to HTML , as I wanted to become a web developer.
I used the <pre> tag for the proper alignment in my code.
But the alignment seems to come little fuzzy.
But the output of 3 and 4 i.e Reason to live and Happiness are not properly align with respect to the above quotes.
<p>For me you are:</p>
<pre>
1.Love
2.Life
3.Reason to Live
4.Happiness
</pre>
I've tested your code and it seems to line up fine, you could always put the content in a list like the below:
<ol>
<li>Love</li>
<li>Life</li>
<li>Reason to Live</li>
<li>Happiness</li>
</ol>
If this isn't what you need, please could you show us how it appears for you?
I have tested your code, it works fine
You can share how it appears in your machine.
Related
i try to launch my code to crete a simple elearning website which use pymongo as database. i write the codes in google docs before it save it in pymongo.
the main problem is, my code didnt break(br) like it use to and even trying to fill all line. this only occur to short code but doesnt do the same with long one. it happen sometimes but i cant seems to get it fix. i did try to remove the css to see if the problem is from there but same thing happens. i dont know what seems to be the problem.
<h4>i love food</h4>
<p>there are many food i like.</p>
<p>the food are as follow:</p>
<ul>
<li>chicken</li>
<li>fish</li>
<li>nugget</li>
</ul><br>
<p>all from above is my favourite</p>
<h4>MA 7 & EMA 26</h4><br>
here are a simple code similar to mine. but the problem is the code stacks.
result :
i love food
there are many food like.
the food are as follow: .chicken all from above is my favourite
.fish
.nugget
MA 7 & EMA 26
as you can see, some stack and some dont. im preatty sure is not the code. but cant think of another problem.
Your code works fine !
https://jsfiddle.net/zvdqk0mr/
Use <div class="clear"> </div> and CSS .clear{clear:both;}
instead of <br> if you facing this line break issue
https://jsfiddle.net/zvdqk0mr/1/
According to the HTML5 Standard:
It is suggested that newlines be inserted after the DOCTYPE, after any comments that are before the root element, after the html element's start tag (if it is not omitted), and after any comments that are inside the html element but before the head element.
What is the reasoning behind this recomendation? Is there a difference between writing
<!DOCTYPE html>
<html>
<head>...
and
<!DOCTYPE html><html><head>...
?
It just helps improve readability, the code is processed exactly the same way.
There are some issues with parsing self-closing tags that can be a bit odd in certain situations.
For example, in HTML5 it is perfectly valid to write an unordered list like so:
<ul>
<li>Hello
<li>World
</ul>
The <li> tag implies </li><li> if there is no closing </li> present immediately before it. What's weird about this is the new lines in your code actually affect the way your list renders to the browser.
Unfortunately you cannot see this in jsfiddle, but you can see how the spacing issues affect a normally written list differently due to spacing, like this:
<ul>
<li>Hello</li><li>World</li>
</ul>
Differs from
<ul>
<li>Hello</li>
<li>World</li>
</ul>
Here's a little demo: http://jsfiddle.net/LGq9k/1/
I would imagine that the weird spacing oddities are the reason they suggest generally-accepted syntactical spacing and line breaks should be used, but who knows?
I'm validating my website using the W3C HTML validation, and I'm getting errors for adding a line break in an ordered list.
E.g.:
<ol>
<li>Stuff</li><br/>
<li>Stuff2</li><br/>
</ol>
with successful validation would print
Stuff Stuff2
but it should be
Stuff
Stuff2
Without the line breaks it validates fine, but the list elements aren't on individual lines.
Is there a way that the site validates WHILE line breaking each stuff element?
I feel WOW on <br/> between <li>. <li> itself puts things in next line always..and you don't have anything in <ol> except <li>,
If you want some extra gap between <li>'s than use margin in CSS.
And how you say that:
with successful validation would print
Stuff Stuff2
This will not going to happen with <li> though.
You cannot have anything other than <li> inside a <ol> or <ul>. Something in your CSS may be messing up your lists.
So I'm trying to do a pretty simple contenteditable list with HTML that looks like this:
<article contenteditable="true">
<p>Text in doc</p>
<ol>
<li><p>Text in first LI</p><p>Has another para</p>
<ol>
<li><p>Text in nested LI</p></li>
<li><p>Text in nested LI2</p><p>And then some</p></li>
</ol>
</li>
<li><p>Text in second LI</p></li>
</ol>
</article>
In Webkit based browsers if you have a play around with it you find that it works pretty reasonably, inserting paragraphs when you hit enter, deleting list items if you hit backspace on them and things like that.
However if you try and delete the first item in the list (whilst there are still other things in the list), things get weird. You pretty much can't do it. And in fact what it does is move the text to the previous paragraph and leave you with an empty list item that you can no longer get to.
Maybe this is a defect in Webkit, but Firefox works the same way... In any case, can anyone suggest a workaround? I was thinking if I had some javascript that detected if it was the first character of the list then it would at least stop some of the unintuitive behaviour but you can still highlight across the item and hit del and still have an unreachable 1.
I have also tried making them divs and using the bleeding edge chrome, same behaviour.
See http://jsfiddle.net/2Unmz/14/ though it does act differently there than it does in my browser directly.
Despite it being the recommended method of nesting lists (http://developer.mozilla.org/en/HTML/Element/ol), it seems that you should end the list item before embedding another list inside it. This HTML works much more how I'd expect:
<p>Text in doc</p>
<ol>
<li><p>Text in first LI</p><p>Has another para</p></li><!-- Ending the LI now -->
<ol>
<li><p>Text in nested LI</p></li>
<li><p>Text in nested LI2</p><p>And then some</p></li>
</ol>
<!-- This is where it used to be -->
<li><p>Text in second LI</p></li>
</ol>
</article>
So looks like it's not a good idea to do nested lists as mozilla.org suggests if you want contentEditable to do logical things with your document.
I'm currently trying to come up with a good and accessible way to format a status indicator which should be rendered within a set of wizard-like pages on a website. The website should provide a multipage form with a status indicator on top of it as demonstrated in the wireframe below:
Given the new progress-tag in HTML my first thought was to do something like this:
<progress value="2" max="3">
<ul>
<li>Beginning</li>
<li class="now">Right now</li>
<li>End</li>
</ul>
</progress>
... but since <progress> only accepts phrasing content using a list is not really an option. So right now I would probably go with something like this, integratinng the ARIA progressbar-role:
<ul aria-role="progressbar" aria-valuenow="2" aria-valuemin="1" aria-valuemax="3" aria-describedby="state2" aria-valuetext="Right now">
<li id="state1">Beginning</li>
<li id="state2" class="now">Right now</li>
<li id="state3">End</li>
</ul>
But again, I'm not really sure if the progressbar role can be applied in such a way to a list.
Another problem is, that <progress> is rendered as progress bar in Opera, for instance, so >progress> itself is probably not really a viable solution altogether :-(
Can anyone perhaps recommend an accessible status bar that does not only rely on using a single image?
Current solution
For now I will go with following markup:
<section class="progress">
<h1 class="supportive">Your current progress</h1>
<ol>
<li><span class="supportive">Completed step:</span> Login</li>
<li class="now"><span class="supportive">Current step:</span> Right now</li>
<li><span class="supportive">Future step:</span> End</li>
</ol>
</section>
All elements of the class "supportive" will be positioned off-screen. IMO this way we should have a nice compromise of semantic markup (the state succession is in my opinion really an ordered list ;-)) and accessibility thanks to the additional header and status text for each step.
According to whatwg, you're not supposed to assign progressbar role to <ul> elements.
I'd just ditch <ul> and describe progress using (surprise) phrasing content:
<section role="status">
<h2>Task Progress</h2>
<p>You're now at <progress value=2 max=3>"Right now" step</progress>.
</section>
Update: You're right, progress doesn't suit here, it's more like an interactive form widget. I should've checked first, before taking it from your first example. But anyway, the point is there's no need to use a list (even more so, unordered list), when you can just describe what's going on in plain text. In the case that the list of past and future steps is necessary, I'd just add two more paragraphs, one before the status (‘You've completed the "Beginning" step’), and one after (‘Next step will be the "End" step’).
However, I admit that this isn't a complete answer to your question.
Also, I'd say some aria attributes look redundant to me. For example, aria-valuetext perhaps would make more sense in the context of interactive widget, when there's no other human-friendly description of its state. Though I may be wrong here.