Virtual Remote / Status Panel

[Black Hole]

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.

 

[MymsMan]

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 enabled

 

[prpr]

It 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.

 

[MymsMan]

It 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.

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 buttons

It should be positioned lower in the same position as on the Main menu and either push down the remote control if needed or collapse when you mouse over anywhere on the status box

 

[prpr]

I've done an update to the CSS to try and improve this. See what you think. I dislike CSS and am not very good at it.
You'll need to force refresh the page after installing the upated ir package (Ctrl-F5 or such like) to get it to update (no, I don't understand why either).
It's in the Beta section currently.

 

[EEPhil]

I dislike CSS and am not very good at it.

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!

 

[prpr]

I don't know. Crap like this illustrates your point:

        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;

I have no idea whether all of those others are necessary or do anything at all, nor what the leading '-' may or may not mean or do.

 

[Black Hole]

I've done a tiny bit of CSS, and you have to jump through hoops to make all browsers behave the same (if you try to do anything complicated), and mainly it seems to be Apple who want to ignore standards and do their own thing.

However, this

        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).

I generally use w3schools.com as my primary reference, but it can be difficult to search (WTF does their search box produce a cascade of results from the wider Internet and not focus on results from w2schools?) and in this case Stack Exchange says this:

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 have no idea why Safari and Chrome are connected! You'd have thought Google and Apple were the antithesis.)

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), and ought to be previewed using one of those rendering testers (which show how a web page will look on a huge range of platforms and browsers without having to install said browsers or have access to those platforms, but tend to cost money).

Perhaps the break-outs were auto-generated by a design package (maybe an outdated one).

In case anyone's wondering: the box-shadow property adds a drop shadow to a rendered element, and has many potential variations. In this case, with four parameters, they are (in order) horizontal displacement, vertical displacement, amount of blur, and shadow colour. W3schools provides useful "try it" pages where you can edit the preset example code and see the result: https://www.w3schools.com/css/css3_shadows_box.asp (click "Try it Yourself" for any specific usage, the web page is in two panels with fully editable code on the left and the render of it on the right). My iPad Safari responds perfectly well to box-shadow without the -webkit prefix!

 

[prpr]

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 think that's the same conclusion as I came to.

I generally use w3schools.com as my primary reference

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.

 

[Black Hole]

I find it annoyingly primitive quite a lot of the time - a bit like primary school mentality

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.

 

[Black Hole]

Reading and thinking further, I've come to the conclusion those break-outs are not needed now, and probably never were.

The purpose of a break-out is to modify the behaviour for any particular browser type, specifically for that browser type only. If (say) Safari responds to -webkit-xxx it will also respond to just plain xxx, but if that response is different from other browsers' implementation of xxx you might have xxx followed by a slightly different -webkit-xxx.

xxx is responded to by all browsers (which implement it at all), and then overridden by -webkit-xxx for Safari browsers (non-Safari browsers will ignore that line).

Therefore, if the parameters for any particular break-out version are identical to the default version, the break-out is unnecessary. This strengthens the idea that they were created by a generator, because I find it hard to believe God put them in deliberately.

 

[prpr]

I find it hard to believe God put them in deliberately.

AKA af123.

 

[prpr]

It updates dynamically (every 30s) whereas the normal hover over one doesn't

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.

 

[Black Hole]

I didn't realise it didn't.

 

[EEPhil]

Crap like this illustrates your point:

Looks even more complicated than I remember. Can't easily dig out a 15-20 year old example.