Black Hole
May contain traces of nut
I've noticed the status panel in the WebIF can obscure the mute (and other) buttons on the virtual remote, if there's enough going on, but there doesn't seem to be a way to dismiss it.
It seems uneeded since it duplicates the normal hover over status info available on all webif pages if the slide down toolbar is enabledI've noticed the status panel in the WebIF can obscure the mute (and other) buttons on the virtual remote, if there's enough going on, but there doesn't seem to be a way to dismiss it.
It does collapse to a single line if you hover over the top line - but then expands again as soon as you try to move to the remote buttonsIt updates dynamically (every 30s) whereas the normal hover over one doesn't, but it also overlays stuff on the main bar (e.g. Idle time) which is annoying.
It's always struck me as a bit odd.
Same here. A long time since I used it. Are there still problems with constructs working for one type of browser that don't work in another? PITA!I dislike CSS and am not very good at it.
box-shadow: 2px 2px 11px #666;
-moz-box-shadow: 2px 2px 11px #666;
-webkit-box-shadow: 2px 2px 11px #666;
border-radius: 5px;
-moz-border-radius: 5px;
...looks bloody ridiculous, in as much as the break-outs all have the same parameters as the default. You would think that if Mozilla (-moz) or Safari (-webkit) offer property box-shadow at all, they would respond to the vanilla box-shadow property! I could understand it if each break-out was a tweak for a specific browser, and contained different values (but they don't).Code:box-shadow: 2px 2px 11px #666; -moz-box-shadow: 2px 2px 11px #666; -webkit-box-shadow: 2px 2px 11px #666; border-radius: 5px; -moz-border-radius: 5px;
Stack Exchange said:These are the vendor-prefixed properties offered by the relevant rendering engines (-webkit for Chrome, Safari; -moz for Firefox, -o for Opera, -ms for Internet Explorer). Typically they're used to implement new, or proprietary CSS features, prior to final clarification/definition by the W3.
This allows properties to be set specific to each individual browser/rendering engine in order for inconsistencies between implementations to be safely accounted for. The prefixes will, over time, be removed (at least in theory) as the unprefixed, the final version, of the property is implemented in that browser.
To that end it's usually considered good practice to specify the vendor-prefixed version first and then the non-prefixed version, in order that the non-prefixed property will override the vendor-prefixed property-settings once it's implemented
I think that's the same conclusion as I came to.It seems to me (in this case) the break-outs could be left out, but doing so might lose support on some browsers (especially if outdated)
I find it annoyingly primitive quite a lot of the time - a bit like primary school mentality; tells you the basics but not the nitty-gritty nor anything like complete.I generally use w3schools.com as my primary reference
That's my level! But it's one thing knowing what the code is supposed to do, and another thing entirely what it actually does in practice.I find it annoyingly primitive quite a lot of the time - a bit like primary school mentality
AKA af123.I find it hard to believe God put them in deliberately.
Does the panel think that the status bar on the main index page should update dynamically? It's always irritated me that it doesn't. If so, how often? I've picked 60s as a reasonable compromise.It updates dynamically (every 30s) whereas the normal hover over one doesn't
Looks even more complicated than I remember. Can't easily dig out a 15-20 year old example.Crap like this illustrates your point: