Web Analytics Made Easy -
StatCounter CSS Toggle switch to mute html5 audio problems - CodingForum

Announcement

Collapse
No announcement yet.

CSS Toggle switch to mute html5 audio problems

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • CSS Toggle switch to mute html5 audio problems

    All I want is to make a CSS switch to mute audio. I have put this code together but it doesn't work and I am not sure why. If I remove the id=mute" the css animation works but the sound doesn't mute obviously. At the moment it mutes but the switch doesnt work. I am a cowboy coder at best and I would like A: a colution to a nice mute switch and B: to understand why what I have doesnt work.

    cheers the General

    CODE below

    Code:
    <!doctype html>
    <html>
    <head>
    <meta charset="UTF-8">
    <title>Untitled Document</title>
    
    <style>
    .switch {
      position: relative;
      display: inline-block;
      width: 60px;
      height: 34px;
    }
    
    .switch input {display:none;}
    
    .slider {
      position: absolute;
      cursor: pointer;
      top: 0;
      left: 0;
      right: 0;
      bottom: 0;
      background-color: #ccc;
      -webkit-transition: .4s;
      transition: .4s;
    }
    
    .slider:before {
      position: absolute;
      content: "";
      height: 26px;
      width: 26px;
      left: 4px;
      bottom: 4px;
      background-color: white;
      -webkit-transition: .4s;
      transition: .4s;
    }
    
    input:checked + .slider {
      background-color: #2196F3;
    }
    
    input:focus + .slider {
      box-shadow: 0 0 1px #2196F3;
    }
    
    input:checked + .slider:before {
      -webkit-transform: translateX(26px);
      -ms-transform: translateX(26px);
      transform: translateX(26px);
    }
    
    /* Rounded sliders */
    .slider.round {
      border-radius: 34px;
    }
    
    .slider.round:before {
      border-radius: 50%;
    }
    </style>
    
    </head>
    
    <body>
    
            <div class="audio">
            <audio id="background_audio" autoplay loop>
              <source src="http://j1presents.co.nz/loy0037/audio/wishlist_01.mp3" />
            </audio> 
             <label class="switch">
              <input type="checkbox" id="mute">
              <div class="slider round"></div>
            </label>
            </div>
            
            
    <script type="text/javascript">
        var audio = document.getElementById('background_audio');
    
    document.getElementById('mute').addEventListener('click', function (e)
    {
        e = e || window.event;
        audio.muted = !audio.muted;
        e.preventDefault();
    }, false);
        </script>
    
    
    </body>
    </html>
    Last edited by VIPStephan; Oct 4, 2016, 04:54 PM. Reason: added code BB tags

  • #2
    The reason is this:
    Code:
    e.preventDefault();
    It switches off the default action for the click which is toggling the checkbox. Sometimes this is useful but in your case it is not as you need the default action.

    Comment


    • #3
      @Sempervivum has it right, the preventDefault is what's biting you on this in terms of preventing it from working. By doing so you're actually preventing the checkbox from becoming checked.

      Code:
      <script>
      	var audio = document.getElementById('background_audio');
      
      	document.getElementById('mute').addEventListener('click', function (e) {
      		e = e || window.event;
      		audio.muted = !audio.muted;
      	}, false);
      </script>
      Will work just fine. * note that you no longer have to say type="text/javascript" on <script> tags... about blasted time IMHO

      That said, you got a bit too complicated IMHO for something so simple in terms of your markup... There is likely little legitimate reason for it to be more than:

      Code:
      <div class="audio">
      	<audio id="background_audio" loop>
      		<source src="http://j1presents.co.nz/loy0037/audio/wishlist_01.mp3" />
      	</audio> 
      	<input type="checkbox" id="mute" class="cssToggle">
      	<label for="mute">Mute</label>
      </div>
      You really don't need that extra DIV, and the label wrapping the input isn't as reliable as one would hope... The CSS for that would be something more like:

      Code:
      .cssToggle {
      	position:absolute;
      	left:-999em;
      }
      
      .cssToggle + label {
      	display:inline-block;
      	position:relative;
      	text-indent:-999em;
      	height:34px;
      	width:60px;
      	background:#CCC;
      	-webkit-border-radius:34px;
      	border-radius:34px;
      }
      
      .cssToggle + label:before {
      	content:" ";
      	position:absolute;
      	left:0;
      	top:0;
      	width:26px;
      	height:26px;
      	background:#FFF;
      	border:4px solid #CCC;
      	-webkit-border-radius:50%;
      	border-radius:50%;
      }
      
      .cssToggle + label,
      .cssToggle + label:before {
      	-webkit-transition:0.4s;
      	transition:0.4s;
      }
      
      
      .cssToggle:focus + label {
      	box-shadow:0 0 1px #29F;
      }
      
      .cssToggle + label:hover {
      	background:#EEE;
      }
      
      .cssToggle:checked + label {
      	background:#29F;
      }
      
      .cssToggle:checked + label:before {
      	left:26px;
      }
      I use absolute positioning to hide the checkbox as if you set display:none IE and Edge doesn't let the value/state of the checkbox be changed. sucks. For some reason they treat display:none checkboxes as if they were disabled.

      Using the label as the styled toggle is pretty simple, and since you're already absolute positioning the :before there's no reason to screw around with translate, just adjust "left' appropriately. Rather than using multiple elements for the border and fill, just use border on the :before. Pretty simple, and less markup.

      Less markup and less DOM elements are ALWAYS a good thing. Also I put text inside the label since otherwise, why have a label. Gives the checkbox meaning should you have anyone using the page CSS off but scripting on... graceful degradation; a must-have.

      Also, try not to auto-play background music, you're just going to piss off visitors to the point they are FAR more likely to just close the tab as soon as it opens instead of hunting for your mute toggle.
      Walk the dark path, sleep with angels, call the past for help.
      https://cutcodedown.com
      https://medium.com/@deathshadow

      Comment


      • #4
        Thanks you guys!

        Comment


        • #5
          Originally posted by deathshadow View Post
          I use absolute positioning to hide the checkbox as if you set display:none IE and Edge doesn't let the value/state of the checkbox be changed. sucks. For some reason they treat display:none checkboxes as if they were disabled.
          Also, that’s better for accessibility. Anything that has “display: none” is ignored by screen readers, so you should always use means like absolute positioning to visually “hide” content that’s important otherwise.
          Stop solving problems you don’t yet have!

          Comment


          • #6
            Originally posted by deathshadow View Post
            I use absolute positioning to hide the checkbox as if you set display:none IE and Edge doesn't let the value/state of the checkbox be changed. sucks. For some reason they treat display:none checkboxes as if they were disabled.
            If you want full stylistic control without using hacks involving absolute positioning or text-indent, there's always custom checkboxes using WAI-ARIA, though it requires a bit of work to make it keyboard and no-CSS accessible:

            demo.xhtml:
            Code:
            <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-Latn-US">
            	<head>
            		<title>Demo Document</title>
            		<style>
            			h1 {
            				font-size: inherit;
            			}
            			[id="mute_control"],
            			[id="mute_control"]::before {
            				transition-duration: 0.4s;
            				transition-property: background-color, left;
            			}
            			[id="mute_control"] {
            				border-radius: 34px;
            				color: hsla(0, 0%, 0%, 0);
            				cursor: pointer;
            				display: inline-block;
            				height: 34px;
            				-moz-outline-radius: 34px;
            				position: relative;
            				width: 60px;
            			}
            			[id="mute_control"]:not(:focus):not(:hover) {
            				background-color: hsla(0, 0%, 80%, 1);
            			}
            			[id="mute_control"]:focus {
            				outline: 2px solid hsla(0, 0%, 80%, 1);
            			}
            			[id="mute_control"]:hover:not(:focus),
            			[id="mute_control"][aria-checked="false"]:focus {
            				background-color: hsla(0, 0%, 93%, 1);
            			}
            			[id="mute_control"][aria-checked="true"]:not(:focus) {
            				background-color: hsla(239, 100%, 57%, 1);
            			}
            			[id="mute_control"][aria-checked="true"]:focus {
            				background-color: hsla(239, 100%, 80%, 1);
            			}
            			[id="mute_control"]::before {
            				background-color: hsla(0, 0%, 100%, 1);
            				border: 4px solid hsla(0, 0%, 80%, 1);
            				border-radius: 50%;
            				content: "";
            				height: 26px;
            				position: absolute;
            					left: 0;
            				width: 26px;			
            			}
            			[id="mute_control"][aria-checked="true"]::before {
            				left: 26px;
            			}
            		</style>
            	</head>
            	<body>
            		<h1>Demo</h1>
            		<div class="audio">
            			<audio id="background_audio" loop="loop" autoplay="autoplay">
            				<source type="audio/mpeg" src="http://j1presents.co.nz/loy0037/audio/wishlist_01.mp3"/>
            			</audio>
            			<span id="mute_control" role="checkbox" aria-checked="false" aria-label="Mute" tabindex="0">☐</span>
            		</div>
            		<script>
            			/* <![CDATA[ */
            			(function () {
            				"use strict";
            				var events = Object.create(null, {
            					"click_end": {
            						"value": "mouseup"
            					},
            					"key_press_end": {
            						"value": "keyup"
            					}
            				});
            				var namespaces = Object.create(null, {
            					"none": {
            						"value": ""
            					}
            				});
            				var mute_audio = function (mutation_records) {
            					let audio = this;
            					let muted_state = mutation_records[0].target.getAttributeNS(namespaces.none, "aria-checked");
            					if (muted_state === "true") {
            						audio.muted = true;
            					}
            					else {
            						audio.muted = false;
            					}
            				};
            				var toggle_ARIA_checkbox = function (event) {
            					if (event instanceof KeyboardEvent && event.key === " " || event instanceof MouseEvent) {
            						let checkbox = this;
            						let checked_state = checkbox.getAttributeNS(namespaces.none, "aria-checked");
            						if (checked_state === "false") {
            							checkbox.setAttributeNS(namespaces.none, "aria-checked", "true");
            							checkbox.firstChild.data = "☑";
            						}
            						else {
            							checkbox.setAttributeNS(namespaces.none, "aria-checked", "false");
            							checkbox.firstChild.data = "☐";
            						}
            					}
            				};
            				var audio = document.getElementById("background_audio");
            				var mute_control = document.getElementById("mute_control");
            				var mute_control_observer = new MutationObserver(mute_audio.bind(audio));
            				var mute_control_observer_options = Object.create(null, {
            					"attributes": {
            						"value": true
            					},
            					"attributeFilter": {
            						"value": [
            							"aria-checked"
            						]
            					}
            				});
            				mute_control_observer.observe(mute_control, mute_control_observer_options);
            				mute_control.addEventListener(events.click_end, toggle_ARIA_checkbox);
            				mute_control.addEventListener(events.key_press_end, toggle_ARIA_checkbox);
            			})();
            			/* ]]> */
            		</script>
            	</body>
            </html>
            Last edited by Arbitrator; Oct 7, 2016, 06:14 PM. Reason: Indicated that the code is XHTML (not HTML).

            Comment


            • #7
              Originally posted by Arbitrator View Post
              If you want full stylistic control without using hacks involving absolute positioning or text-indent, there's always custom checkboxes using WAI-ARIA, though it requires a bit of work to make it keyboard and no-CSS accessible
              Sadly the methodology doesn't gracefully degrade all that great, has spotty to nonexistent browser support, and like everything else ARIA related seems to just be about seeing how much bloat you can add to a page for nothing while telling users with accessibility needs to go **** themselves.

              The laugh being the people behind Aria then make up fairy tale BS about it aiding in accessibility; not if not one legitimate UA builder is going to implement support for it.

              I lump ARIA in with the pointlessly redundant HTML 5 'structural' tags and mouth-breathing idiocy like microformats. At best it's code bloat, at worst it's telling actual users to sod off just to satiate the wants and needs of the THIEVES who masquerade their intent behind the phrase "data scraping".

              Besides, if I needed that much JavaScript to do this, I'd consider sucking the business end of a shotgun Kobain style. Poster child for everything WRONG with Aria roles and what people do with them -- though understandable to see such bloat in the age of people slopping together dozens of separate scripts and dozens of separate CSS files any-old-way whilst using 50k of markup to do 10k's job, 500k of CSS to do 32k's job, and a megabyte of scripting on pages that don't even need scripting... all to then call the resultant train-wreck "easier".
              Walk the dark path, sleep with angels, call the past for help.
              https://cutcodedown.com
              https://medium.com/@deathshadow

              Comment


              • #8
                Originally posted by deathshadow View Post
                Sadly the methodology doesn't gracefully degrade all that great,
                Uh, I really don't think it matters what the checkbox looks like in a page without stylesheets as long as the checkbox is obviously a checkbox. Even caring about that is mostly academic since people don't browse pages without stylesheets.

                Originally posted by deathshadow View Post
                has spotty to nonexistent browser support, and like everything else ARIA related seems to just be about seeing how much bloat you can add to a page for nothing while telling users with accessibility needs to go **** themselves.

                The laugh being the people behind Aria then make up fairy tale BS about it aiding in accessibility; not if not one legitimate UA builder is going to implement support for it.
                According to MDN, every major browser supports ARIA. (The page is old and Microsoft Edge isn't mentioned, but if IE8 supports it...) See https://developer.mozilla.org/en-US/...ARIA_Supported. Of course, I don't have access to a screen reader to test that assertion.

                ARIA is a nice, standard, non-hacky way around the real BS: not being able to simply make a checkbox disappear by setting its dimensions to zero.

                Originally posted by deathshadow View Post
                Besides, if I needed that much JavaScript to do this, I'd consider sucking the business end of a shotgun Kobain style.
                I'm not of your apparent opinion that less code is always better. However, if verbosity is really an issue, that can be addressed with this modified script:

                Code:
                checked = "aria-checked";
                observer = new MutationObserver(function () { background_audio.muted = mute_control.getAttribute(checked) == "true" ? true : false; });
                observer.observe(mute_control, { attributes: true, attributeFilter: [checked] });
                mute_control.onmouseup = mute_control.onkeyup = function (e) {
                	if (e.key == " " || e.type == "mouseup") {
                		state = this.getAttribute(checked) == "false" ? this.setAttribute(checked, "true") : this.setAttribute(checked, "false");
                		this.innerHTML = state ? "☑" : "☐";
                	}
                };
                Edit: This is even less to object to:

                Code:
                c = "aria-checked";
                (new MutationObserver(function () { background_audio.muted = mute_control.getAttribute(c) == "true" ? true : false; })).observe(mute_control, { attributes: true });
                mute_control.onmouseup = mute_control.onkeyup = function (e) {
                	if (!e.key == " " && !e.type == "mouseup") return;
                	state = this.getAttribute(c) == "false" ? this.setAttribute(c, "true") : this.setAttribute(c, "false");
                	this.innerHTML = state ? "☑" : "☐";
                };
                Edit: Final take:

                Code:
                m = mute_control, c = "aria-checked", c_get = m.getAttribute.bind(m, c), c_set = m.setAttribute.bind(m, c);
                (new MutationObserver(function () { background_audio.muted = c_get() == "true" ? 1 : 0; })).observe(m, { attributes: 1 });
                m.onmouseup = m.onkeyup = function (e) {
                	if (!e.key == " " && !e.type == "mouseup") return;
                	m.innerHTML = (c_get() == "false" ? c_set("true") : c_set("false")) ? "☑" : "☐";
                };
                Last edited by Arbitrator; Oct 8, 2016, 01:08 AM. Reason: See the post.

                Comment


                • #9
                  Originally posted by Arbitrator View Post
                  Even caring about that is mostly academic since people don't browse pages without stylesheets.
                  Excepting all the people on screen readers, braille readers, or intentionally blocking it (along with images) thanks to idiotic BS like bandwidth caps, bandwidth restrictions, or less capable devices who most certainly DO browse without stylesheets -- hence why we have SEMANTIC markup that should be providing ALL the meaning (along with the content itself) you should need for accessibility without slopping a massive specification of bloated pointless asshat redundancies on top.

                  ... and much like HTML 5's ultimately pointless idiotic halfwit dumbass ignorant <section>, <article>, <nav>, <aside>, <header>, and <footer> that's ALL it is, pointless redundancies that do NOTHING you couldn't do from 4 Strict on its own in terms of delivering a useful page of content to users!

                  Originally posted by Arbitrator View Post
                  According to MDN, every major browser supports ARIA.
                  "supports" and "supports properly and does anything USEFUL with it" are two different things... and I really have NEVER seen anything USEFUL done with it that couldn't be done without it apart from content theft. The whole point just seems to be code bloat and dragging things back to the WORST of pre-strict 3.2/4 tranny style development methodologies.

                  It feels like a sloppy kludgy hack to do nothing of actual value... as evidenced by actually having to use screen readers and braille readers as my vision is starting to go south.

                  Originally posted by Arbitrator View Post
                  ARIA is a nice, standard, non-hacky way around the real BS: not being able to simply make a checkbox disappear by setting its dimensions to zero.
                  Other than sliding it off the screen where it will still function, setting it to visibility hidden, or if we could get Microsoft to pull IE's head out of its arse, display:none.

                  Originally posted by Arbitrator View Post
                  I'm not of your apparent opinion that less code is always better.
                  First lesson I had drilled into me 38 years ago for programming. The less code you use, the less there is to break... admittedly at the time I was entering hand assembled RCA 1802 machine language one bit at a time on toggle switches, but it's served me well over the decades -- certainly far better than today's nonsensical asshat approach of "Just keep throwing more code and hardware at the problem".

                  Originally posted by Arbitrator View Post
                  Edit: Final take:
                  Still not blowing my skirt up, partly from the rubbish CSS that remained unaddressed... partly from having to recreate functionality a checkbox already has... partly from the fact that it is using innerHTML forcing a reparse of the entire document -- the pinnacle of "epic fail" at writing JavaScript... on something that to be frank could just as easily be done FROM the JS since the ONLY thing the JS should have to be doing here is muting/unmuting. You use an ACTUAL checkbox you have ALL the semantic hooks (including REAL text in the markup not scripttardery generation) to handle it CSS off... and any GOOD progressive enhancement site building should do that.

                  Only way I'd allow that type of garbage into a codebase is if it were for a local crapplet built on something like nw.js or electron... sure as shine-ola wouldn't crap all over a website that way... even then, you want the behavior of a checkbox, use a bloody checkbox not some pointless aria role BS where you have to hardcode the actual functionality! More so with that bleeding edge "mutation" crap that seems to just make event handling even harder, less compatible, and more convoluted. Because what JavaScript REALLY needs at this point is to be even MORE convoluted.

                  413 bytes on your final to do ~243 bytes job... at MOST I'd have:

                  Code:
                  var audio = document.getElementById('background_audio');
                  
                  document.getElementById('audioMute').addEventListener('click', function() {
                  	e = e || window.event;
                  	if (!e.target) e.target = e.srcElement;
                  	audio.muted = e.target.checked;
                  });
                  As my scripting... EVERYTHING else belongs in the CSS.

                  Though I have to ask...

                  Code:
                  [id="mute_control"]
                  Code:
                  hsla(0, 0%, 0%, 0)
                  Code:
                  outline: 2px solid hsla(0, 0%, 80%, 1);
                  REALLY? What would possess ANYONE to write CSS that way?!? VERY strange to see anyone screwing around with HSL as if they were designing for PRINT... particularly for #000... or using the attribute selector for an ID? WHY?!? Apart from making CERTAIN you're slopping in more code than neccessary and making it even MORE complex for no legitimate reason (much less making the system work harder by having to do the HSL to RGB conversion which isn't even precise) what possible purpose does that serve?

                  ... and outline? Given the headaches that is shouldn't that be reserved for debugging purposes, not regular style? I thought that's why we had box-shadow now.

                  Code:
                  box-shadow:0 0 0 2px #CCC;
                  Should be functionally identical, just doesn't need that -moz-outline rubbish.

                  Much less all that ::not garbage... just set the normal state and override for when it's TRUE.

                  I mean:
                  Code:
                  [id="mute_control"]:not(:focus):not(:hover) {
                  Feels like a pointless garbage mess compared to just:

                  Code:
                  .cssToggle + label {
                  Just as:

                  Code:
                  [id="mute_control"][aria-checked="true"]::before {
                  Doesn't feel like much of an improvement over:

                  Code:
                  .cssToggle:checked + label:before {
                  To me using ARIA for this -- or anything really -- feels like taking something simple and making it as bloated, convoluted, and difficult to work with and maintain as possible. I see ZERO legitimate advantages to it's use -- but it DOES feel very familiar in terms of the same asshat bull we saw with the microformats trash of the early '00's and the same mindset that led to the train wreck of a disaster that was HTML 3.2 and the proprietary crap that followed -- including the chazerei that wormed its way into HTML 4 tranny.

                  But as I'm often saying, it seems like the target audience for things like HTML 5 and Aria roles are the people who never pulled their cranium out of 1997's rectum, and continued to sleaze out buggy bloated HTML 3.2 and propreitary tags slappy 4 tranny atop it... now they just get to wrap 5 lip-service around the same broken methodologies and slap each-other on the back over how "modern' they are. It sure as shine-ola doesn't seem to have been crafted for the folks who embraced the superior methodologies of HTML 4 Strict, semantic markup, content oriented development, separation of presentation from content, or progressive enhancement.

                  If anything, it's telling the people who understood such things to go **** themselves... but Joe forbid we respond back in kind.

                  Of course in the age where mouth-breathers DUMB ENOUGH to think that idiotic nonsense like bootcrap and jquery actually make things simpler and easier (they don't)... well, for the HTML being vomited up by these inept fools to follow that same path can hardly be considered a surprise.
                  Last edited by deathshadow; Oct 8, 2016, 06:17 AM.
                  Walk the dark path, sleep with angels, call the past for help.
                  https://cutcodedown.com
                  https://medium.com/@deathshadow

                  Comment


                  • #10
                    Originally posted by deathshadow View Post
                    Though I have to ask...

                    Code:
                    [id="mute_control"]
                    Code:
                    hsla(0, 0%, 0%, 0)
                    Code:
                    outline: 2px solid hsla(0, 0%, 80%, 1);
                    REALLY? What would possess ANYONE to write CSS that way?!? VERY strange to see anyone screwing around with HSL as if they were designing for PRINT... particularly for #000... or using the attribute selector for an ID? WHY?!? Apart from making CERTAIN you're slopping in more code than neccessary and making it even MORE complex for no legitimate reason (much less making the system work harder by having to do the HSL to RGB conversion which isn't even precise) what possible purpose does that serve?
                    I use attribute selectors instead of ID (and class) selectors because I use period (.) characters in those names and would have to escape them otherwise; code with escapes is less readable. Additionally, arcane CSS syntax rules prevent ID and class names from starting with numbers (#1 and .1 are illegal CSS) because of CSS' esoteric relationship with SGML; attribute selectors avoid unexpected errors related to those rules. Consistency requires that I always use attribute selectors.

                    I use HSLA colors because it is author readable—unlike most RGB values—and allows creation of colors and color schemes without consulting a color picker for anyone familiar with the CSS3 syntax. For consistency, all color values are written using one notation.

                    As for the "PRINT" and "make the system work harder" comments, you either don't know what you're talking about or are willfully trolling. All CSS colors are mapped to the sRGB color space and three-character hex values must be converted into decimal RGB values, likewise "mak[ing] the system work harder" (in a negligible way).

                    Originally posted by deathshadow View Post
                    ... and outline? Given the headaches that is shouldn't that be reserved for debugging purposes, not regular style? I thought that's why we had box-shadow now.

                    Code:
                    box-shadow:0 0 0 2px #CCC;
                    Should be functionally identical, just doesn't need that -moz-outline rubbish.
                    You should know full well that these do not produce the same style effects. Box shadows cannot overlap the border box and the blur radius does not produce a solid border. Furthermore, the "border" that you did create is barely perceptible in Firefox (I didn't test other browsers), defeating its purpose as a keyboard navigation aid. In order to "Cut Code Down", you may as well just delete the box shadow rule.

                    Originally posted by deathshadow View Post
                    I mean:
                    Code:
                    [id="mute_control"]:not(:focus):not(:hover) {
                    Feels like a pointless garbage mess compared to just:

                    Code:
                    .cssToggle + label {
                    My coding paradigm is to have style rules apply one at a time to an element except in certain circumstances where it would be difficult to do so. Your code styles the same element multiple times if a :focus or :hover rule applies and then requires the browser to resolve styles based on specificity. Neither method is incorrect.

                    Originally posted by deathshadow View Post
                    Just as:

                    Code:
                    [id="mute_control"][aria-checked="true"]::before {
                    Doesn't feel like much of an improvement over:

                    Code:
                    .cssToggle:checked + label:before {
                    :: indicates a pseudo-element. That is the CSS3/4 paradigm.

                    (Pro Tip: If omission of a colon character is that important to you, I see a lot of semicolons that you can also omit to save a few bytes.)

                    Comment


                    • #11
                      Originally posted by Arbitrator View Post
                      I use attribute selectors instead of ID (and class) selectors because I use period (.) characters in those names and would have to escape them otherwise; code with escapes is less readable. Additionally, arcane CSS syntax rules prevent ID and class names from starting with numbers (#1 and .1 are illegal CSS) because of CSS' esoteric relationship with SGML; attribute selectors avoid unexpected errors related to those rules. Consistency requires that I always use attribute selectors.
                      That's not CSS relationship to SGML, it's HTML's relationship and that means if you're starting with numbers and using periods in classes or ID's, you're basically using invalid markup and completely ignoring HTML's rules. Yes, EVEN HTML 5's... I mean, sure I scoff at HTML 5 validation as a whole and dismiss it *****ing at me about "projection,tv" on media targets, but that's a whole new level of derp.

                      So what you are saying, is that you are making classes and ID's that start with numbers and have periods in them? Wow, epic fail.

                      Originally posted by Arbitrator View Post
                      I use HSLA colors because it is author readable—unlike most RGB values—and allows creation of colors and color schemes without consulting a color picker for anyone familiar with the CSS3 syntax. For consistency, all color values are written using one notation.
                      RGB isn't rocket science, introducing alpha introduces overhead, and the conversion between the two colour-spaces are lossy if the bit-depth is the same. The full RGB colour space cannot be expressed in the same bit-depth HSL and vice-versa -- same way YCrCb doesn't map the same either as they all map to a different level of expression with strengths and weaknesses.

                      See how HSL at zero saturation is always the same L regardless of H... congratulations, just cost yourself 8 bits of depth. It's a narrower colourspace.

                      Which is why HSL if better used for print, since it converts to four channel CMYK better than it does RGB.

                      I mean really if you can't handle the red yellow green cyan blue magenta color wheel, one probably shouldn't be designing for screen media.

                      ... and the hex values ARE RGB, in hex... character to hex conversion of the EXACT SAME COLOURSPACE AS THE HARDWARE is a hell of a lot simpler than converting some arbitrary colourspace using floating point math... particularly when that too has the same character to numeric conversion first. (well not entirely the same, RGB is integer math, HSL is not)

                      The video card stores it as 24 bits of RGB... each nybble is 4 bits. To even compare the two is serious derp.

                      Originally posted by Arbitrator View Post
                      You should know full well that these do not produce the same style effects. Box shadows cannot overlap the border box and the blur radius does not produce a solid border.
                      Look closer.... there are FOUR parameters you can use, not just three. x offset, y offset, blur radius and SPREAD RADIUS. As such:

                      border:5px solid #000;
                      box-shadow:0 0 0 5px #F00;

                      Will give you a SOLID red 5px around the 5px black border. Also not sure why you'd even want it to overlap the border-box, and even if one did, you can also layer box shadows so...

                      Which is why outline is best reserved for debugging purposes, not deployment style -- particularly when tools like firebug, dragonfly, and other document inspector type tools use exactly that property. (though I really miss classic Opera's user.css tools, but stylish is helping with that now)

                      Originally posted by Arbitrator View Post
                      Furthermore, the "border" that you did create is barely perceptible in Firefox (I didn't test other browsers), defeating its purpose as a keyboard navigation aid. In order to "Cut Code Down", you may as well just delete the box shadow rule.
                      I was pretty much copying the OP's style. Honestly, I'd probably just use a normal border on it... but tried to make it do what the original did.

                      Originally posted by Arbitrator View Post
                      My coding paradigm is to have style rules apply one at a time to an element except in certain circumstances where it would be difficult to do so. Your code styles the same element multiple times if a :focus or :hover rule applies and then requires the browser to resolve styles based on specificity. Neither method is incorrect.
                      Apart from that it's basically how HTML is supposed to work, why we have specificity... what you just described is the same garbage as that "keep selectors flat" idiocy or the gibberish that led to nonsense like OOCSS -- making sure people use twice the markup AND twice the CSS. ... and then making wild claims about it being "faster" or "better".

                      As George Carlin joked, not every ejaculation deserves a name... in that way slopping endless attributes for no legitimate reason (sorry Aria)

                      Originally posted by Arbitrator View Post
                      :: indicates a pseudo-element. That is the CSS3/4 paradigm.
                      I wasn't even pointing out the :: vs. : there, so much as the painfully pointlessly convoluted attribute selectors that WILL be slower since most browsers don't index those. Classes and ID's on the other hand usually have a index table to help speed up CSS application... functioning much like JS nodeList since, well... that's exactly what they are. I mean at least adjacent sibling selector can walk the DOM looking for nodetype 1...
                      Walk the dark path, sleep with angels, call the past for help.
                      https://cutcodedown.com
                      https://medium.com/@deathshadow

                      Comment

                      Working...
                      X