Does This Jquery Color Picker Have All #Hex Colors

I am sorry for the newbie question but does this color picker here:

https://bgrins.github.io/spectrum/

Have all the 16.7M hex colors that are available to be selected by using the mouse input?

I know you can input manually what hex color, I just am wondering if this can be done just by using the mouse? thanks alot!

 

Nice, I can't quite get the color to auto update in Javascript. It needs to grab the results of the color pick event so you don't have to reload. What's the code to do that?

<ul> <h1>HTML5 color picker</h1>
    <input id="color_picker" type="color" style="background-color:gray;width:300px;height:240px;padding:12px;">
    <br> </br>
    <ul>
        <input type="button" value="Find the color" onClick="window.location.reload()">   
        <strong>
            <script>
            var mycolor = document.querySelector("#color_picker").value;
            document.write(mycolor);
            </script>
        </strong>
    </ul>
</ul>

HTML:

 

Aha, I got it. Thanks.

<ul><h1>HTML5 color picker</h1>
    <input id="color_picker" onchange="color_update()" type="color" style="background-color:gray;width:300px;height:240px;padding:12px;">
    <br> </br>
    <ul>
        <strong id="color_result"></strong>
    </ul>
</ul>
<script>
    function color_update() {
    var mycolor = document.querySelector("#color_picker").value;
    document.getElementById("color_result").innerHTML = "You selected: " + mycolor;
    }
</script>

HTML:

 

Uhm... you do know that a H1 CANNOT be the direct child of a UL, right? What makes the result recieve emphasis or makes it a list?

You REALLY might want to back away from fancy stuff like colour pickers until you learn how to use HTML properly; your markup is gibberish.

 

DS,

Hmm, thanks. Never bothered to look that up. I can't seem to find a reference to that rule anywhere.

http://www.w3.org/TR/html401/struct/global.html#edef-H1

They even use a Div before the h1 to define it's style. Obviously in this case, I just wanted to move it from the edge. Do you have a link that shows H1 inside a ul violates a rule?

I think you convinced me to quit code all together. Was that your intention? Is it satisfying to do that to people? Do your friends tell you how nice they feel when you tell them off? Just wondering.

 

The ONLY element allowed directly inside a <ul> is a <li>. The <h1> should be outside the <ul>, and moved to whereever you want it to be with CSS.
Nothing wrong with putting a <div> around a <h1> although it's rarely needed.
The rest of your list-code is also broken - all elements, including sub-lists (the <ul> inside the <ul>) needs to be put into <li> elements - and, I dunno about this, but I hope you have a <form> start tag somewhere outside the <ul>, since you have <input> inside it - <input> is only allowed inside a <form>-tag.
@deathshadow might be crude, but he IS more often than not right - you need to learn the tools before you use them, and knowing basic HTML syntax is crucial to both proper HTML, using CSS correctly and not to mention understanding javascript, and get it to behave as intended.

 

Gonna answer you out of order here...

Apologies if you took it that way. I've got the Winston Wolf approach to instruction; I tell it how it is in a very blunt manner.

"If I’m curt with you it’s because time is a factor. I think fast, I talk fast, and I need you to guys to act fast if you wanna get out of this. So pretty please, with sugar on top, clean the ******* car."

I'm not trying to offend, I just figure it's better someone tell you this stuff without the soothing syrup back-patting namby-pampy soft limp-wristed "If you can't say anything nice" asshattery. Slapping the rose coloured glasses on your head, putting a tasty-drop in your mouth and leading you down the garden path to sing Kumbaya is NOT actually helping -- no matter how good that might feel.

The rules of what can go in what is usually on the PARENT tag, not the child. You're not going to find it in the docs for H1, you'll find it in the docs for UL... or OL... or the deprecated / has no blasted business on any website written after 1997 MENU and DIR tags.

http://www.w3.org/TR/html401/struct/lists.html#edef-UL

That's what this part means:

<!ELEMENT UL - - (LI)+                 -- unordered list -->

Code (markup):

It can only contain multiple LI as direct children. Block level (aka "flow") elements like H1 can be put inside the LI, but that doesn't make a lot of sense since an H1 is the "heading under which everything on the page is a subsection" -- just as h2 indicates the start of a subsection of the h1, and so forth down the line just as heading 'levels' work in the professional writing standards TBL was working with when he created HTML in the first place.

Saying you have a list is gibberish if you don't have "List Items". That's also why having only one tag as a child of a UL kind-of defeats the point of saying it's an unordered list. I'm not sure why you seem to think a UL even goes there in the first place, unless you've been learning from some really garbage sources.

Sadly, there are a LOT of garbage sources out there; W3Schools and 90%+ of books on shelves for example.

I can understand how hard that is to follow and how easy it is to screw up semantics (aka the sick euphemism for "using HTML properly") -- there are TWO major issues with the HTML specifications when it comes to learning HTML and using it:

1) It's written in "engineering legalese" designed by it's very nature to take something simple, and make it as impossible to decipher and ambiguous as possible. Just take how "empty tag" doesn't mean a tag that's empty, or how they use the word "deprecated" when you aren't talking down to it in baby-talk like most re-re adults do to anyone under the age of 7; or specific to this particular case how nesting rules are only specified in DTD language, so if you don't know how to interpret DTD lines you're up a fouled tributary without a means of locomotion.

2) It's not written for people who write websites... at ALL. It is entirely written from the point of view of implementing it in a browser, and NOT how to actually use it from a site creation standpoint. If all you want to do is know how to use it to build sites, the specification is a train wreck of pointless crap site-builders shouldn't give a flying purple fish about in the first place.

This is an older reference, but like that matters since HTML 4 Strict is circa 1998 and HTML 5 is pointless crap if you learn to use 4 Strict properly. (in fact HTML 5 seems bound and determined to drag us back to the worst of 1997 style development practices -- there's a reason I call it "the new transitional".)

http://htmlhelp.com/reference/html40/

It does probably the best job I've ever seen of taking the HTML specification and translating it into plain english normal people can understand. In particular it has these handy "contents" and "contained in" sections that take the gibberish DTD rules and turns it into something digestible by the layman.

For example, the UL:
http://htmlhelp.com/reference/html40/lists/ul.html

Is a lot easier to understand than:

<!ELEMENT UL - - (LI)+                 -- unordered list -->

Code (markup):

Just as this:

Is far, FAR simpler than being expected to back-track through every possible parent element to see if the element you are trying to use is listed.

A good reference is important, and it's a crying shame (and entirely typical of the W3C) there's no official one worth two cents plain in a whiskey distillery.

I started to say "what does moving it from the edge have to do with anything" as that's nonsense -- then it hit me. You're using HTML to say what things look like, NOT what they mean. That's NOT HTML's job, that's CSS' job. HTML is for saying what things ARE, NOT WHAT THEY LOOK LIKE! -- a major disconnect in many people's heads particularly since that intent was pissed all over by Microshaft and Nyetscape in the mid to late 1990's. HTML 4 Strict was created to drag us kicking and screaming back into using HTML properly with CSS to do user-side what TBL originally intended to be at the discretion of the user-agent. (what today we call a browser).

IF you are choosing your tags based on their default appearance, you've completely missed what HTML is for and how to use it. Your tags should be saying what things are and providing logical document structure akin to how professional writing works. Appearance? That's CSS' job!

... and it's important that too; not all people using you site are going to be sited; search engines sure aren't sighted and don't give a flying fig leaf about your layout; much less there are concepts like "media targets" and "media queries" as you can have multiple layouts and appearances for all sorts of different devices, device sizes and capabilities which is why "separation of presentation from content" is so important.

It's also why the STYLE tag has no real business on any modern website, and if you are using the STYLE attribute in all but the rarest of cases you are doing things ALL WRONG. You might have no appearance at all, so saying what the content IS (like headings, lists and paragraphs) becomes far more important.

You don't HAVE a list, there's only one item. If you have a heading you are declaring the start of a section of the page, so it's VERY unlikely that's a list item. IF you are declaring a H1 that's what EVERYTHING on the page is a subsection of, so it's most certainly NOT a list... much less a list of short bullet points. (bullet points as in bullet points, not as in show bullets before it. Even if that is the default appearance that's not what it MEANS)

That's why I said you need to learn more HTML. We can help with that -- go through that WDG website I linked to one tag at a time and read the nesting rules and the text actually explaining each tag's purpose.

... and don't get discouraged, we all start somewhere. Honestly when I was starting out with websites 15 years ago, despite having some two decades of coding already under my belt I wish someone had smacked me around with a wet trout sooner on how to use HTML properly. There's SO much disinformation, sloppy practices and outright bad advice; much less people who just sleaze it out any old way that I truly pity anyone starting out in the field.

Particularly with the asshat bloated pointless redundant nitwit nonsense known as HTML 5 crapping all over everything.

 

DS,

I've been working on the Internet since '93, and with computers since '75, with maybe 60 contracts. Obviously, much of the work I do is not up to perfect use and since that is the case, why do I bother trying to still find work in the industry? This example worked and I didn't bother to use a separate css style and div's. I understand the difference in usage. Some of css code, and js I do is over 2000 lines long per file, some sites I have admined and developed have over 80,000 interactive video pages. I was admin domain registrar for 2 million domains. I think this knee-jerk reaction that one thing is out of place and I get you don't have any knowledge of code... reaction, I'm just tired of dealing with it.

 

If you're that experienced, and that clueless, I really feel bad for the industry - I really do.
2000-line files? Uhm... so what? (Apart from that sounding like waaaaaay too long for your own good).
Besides, it was not "one thing out of place" - it was a LOT of things out of place, in less than 15 lines of code. I'm not saying you suck a coding - but I AM saying that the example you provide does not give any confidence in your abilities. Simplifying is not the same as breaking - and the code you have is broken, and will in no way validate, and it's so simple to fix.
Are we sticklers for details? Yes. Is that a bad thing? No, it isn't, because it's so simple to do it right the first time around.

 

Ok, Thanks, I appreciate the input. I don't think I represent the industry standard, I just represent me. No more asides on this post, please. We have hijacked it enough.

 

In other words about as long as I have -- since I started out computing on a Cosmac Elf... and have dealt with the Internet since it was called Darpanet... and that makes PoPSicLe's response about right; that long and you don't even know the basic grammar of HTML?

Ok, maybe not as much as I have -- I've done far more than that over the past three and a half decades.

Though the rest of your post I'm having trouble decyphering; is English your second language? The structure you used makes it hard for me to tell if you are stating, quoting, or asking.

... and it was indeed more than just one thing out of place. Pretty much you had UL for nothing, a slew of tags as direct children of UL that can't be children of UL such as H1, BR, STRONG... Not sure why your result would be receiving "more emphasis" -- aka what STRONG means -- and I probably wouldn't use querySelector just to pull one ID as it has more overhead than document.getElementById; and good scripting should hook the markup NOT the other way around. Hence why I think the various onevent attributes should be deprecated... Though to be fair I say the same thing about the STYLE attribute and tag.

REALLY done properly it should probably also be manipulating the DOM instead of using innerHTML given the latter forces a reflow making it slower and less efficient than a node flush and createTextNode.

 

DS,

If you have time and interest, please do post an example to solve the original question with DOM manipulation. That would, at least, give Phaze3131, the original poster, a better answer. I would certainly like to see it too.

As far as, my previous postings, which do have a few run on phrases and are missing some commas, your assumption that my mother language is not English, is wrong. I can certainly try to be more clear. I also speak German, French and some Italian.

 

You're right, I should do that. I'm in a project right this moment, but after dinner I'll toss together an example of that. It will actually more code, but it is faster, cleaner, and extensible since I'd be using attachEvent / addEventListener instead of the onevent attribute. I'll probably write it so the attach method can target multiple results WITHOUT crapping on the markup... which is to say scripting only elements will be added by the scripting.

That could be me -- missing comma's and structure often loses me badly. REALLY broken Engrish often makes me ask "could you repost that in ENGLISH?"

Often seems like what passes today for "modern English" is getting more and more confusing a mess; admittedly I am guilty myself of archaic sentence structure. Stems from learning Olde Englisc alongside modern English as a child... and of course regionalisms never help. I still fight daily to try and use color instead of colour; or gray instead of grey. (which is GREAT when CSS and HTML can accept the latter pair both ways even though they are NOT actually part of either specification). Sometimes people from the west coast will form a sentence and my brain refuses to accept it as English. ...or sanity, but that's a second unrelated issue. Crystal wearing tofu loving millivegan psuedo-science anti-science freaks driving around in their Prius.

 

Ok, here we go... markup is pretty simple. Since we're using a form element let's actually put it in a FORM (sorry scripttards, but form elements without a form is gibberish -- see that mouth-breathing abuse of "SELECT" for navigation nonsense you see ALL the damned time)

<form id="colorPickerDemo" action="#">
	<fieldset>
		<legend>HTML5 color picker Demo</legend>
		<label for="colorPicker">Choose a color:</label>
		<input type="color" id="colorPicker" name="color" />
		<noscript>
			<p>
				This form requires JavaScript to be enabled to show your color selection.
			</p>
		</noscript>
	</fieldset>
</form>

Code (markup):

No scripting in the markup, no indication of any scripting in the markup other than the noscript fallback warning.

The scripting attaches itself:

(function(d) {

	// a couple handy lib functions

	function makeAfter(e, tagName, content) {
		var result = e.parentNode.insertBefore(
			d.createElement(tagName), e.nextSibling
		);
		if (content) result.appendChild(
			typeof content == 'object' ? content : d.createTextNode(content)
		);
		return result;
	}
	
	function eventAdd(e, event, handler) {
		if (e.addEventListener) e.addEventListener(event, handler, false);
			else e.attachEvent('on' + event, handler);
	}
	
	function textReplace(e, text) {
		while (e.firstChild) e.removeChild(e.firstChild);
		e.appendChild(d.createTextNode(text));
	}
	
	// now the actual grunt-work
	
	var picker = d.getElementById('colorPicker');
	picker.samp = makeAfter(picker, 'samp', 'Awaiting Selection');
	makeAfter(picker, 'br');
	eventAdd(picker, 'change', function(e) {
		e = e || window.event;
		var src = e.target || e.srcElement;
		textReplace(src.samp, 'You Selected: ' + src.value.toUpperCase());
	});
		
})(document);

Code (markup):

I put it in a self-invoking anonymous function (something that there are no less than six different names for now :/) so that scope is isolated and the script cannot interfere with others. It passes document to itself to reduce the code size (handy trick even Google uses now). I tossed in a few handy lib functions to make working with the DOM easier: makeAfter for creating new DOM elements, textReplace for flushing all child nodes and appending a new one (either a literal node or a new text node if you pass a string), and eventAdd for obvious reasons.

Once we get into the meat of it, we just get hold of the desired INPUT by it's ID, add the SAMP tag after it to hold the result storing a link to said SAMP on the input's object. Some people balk at extending objects this way -- I prefer it since it means our event can be self-contained and not rely on anything but the source of the event, and not have to waste processing time doing a getElementById every time the user clicks on it.

We then add a line-break. As it's added after the picker it's put before the SAMP we just made. We then use eventAdd to attach our onevent handler, which is just a simple text-replace based on the source of the event.

It's a bit more code, but it would actually run faster due to not going out and "get by Id" every blasted time, and because it manipulates the DOM so the entire HTML document doesn't have to be run through the parser again; something that on a small sample like this might seem like nothing, but if you are on a page with a massive and complex DOM it can really have an impact. So often you'll see jQuery or other scripting where something like this has a two to five second delay between choosing and the page changing, and that reflow/reparse of the entire document as well as searching the entire DOM for ID's every time are the direct cause of it. Even though it's more code and looks harder than innerHTML, it runs many many times faster as we basically bypass the parser by going straight to the DOM, so all that's needed is a reflow AFTER the changed element.

It's good practice and what the ECMA says we should be doing instead of innerHTML. It's a hefty chunk of why sending markup as strings from JS is frowned upon by the "elite" despite it being the bread and butter of "Joe Sixpack and Susie Sunshine" developers. Honestly you toss together a few simple helper functions and it's no more or less work and is often easier to follow code-wise than a giant mess of markup in the scripting.

... and of course, scripting can be cached if put in an external file, markup cannot -- so getting the scripting only stuff out of the markup means faster page-loads if you use this on more than one page or the user revisits the same page. That separation is why the "pageloads are evil" ajax-tardery and ridiculous obsession with client-side validation is a bunch of BS. If your markup and and any form data is so large that resending it on failure is going to be any more or less painful than using client side scripting, there is probably something wrong with how your markup is built. PARTICULARLY since it should be the same number of handshakes to the server -- ONE! Not like it's more code either since ANY validation or checks you do client-side MUST be re-checked server side since no user response is trustworthy.

A concept lost on the majority of people sleazing out HTML, CSS and JS these days.