The following problem occurs for my <audio> tag with iOS Safari, Firefox and Dolphin browsers, but not on any OS browser = the audio control moves up with zooming+ and ultimately overlaps the object above it.
The static layout, no zooming, is great ... zooming throws everything over the cliff.
FWIW, I did mess with the meta "viewport" tag, but no luck.
<audio> object is at the bottom of the layout. It obeys my css code, except when I zoom. When I zoom via pinching out, the object moves up and overlaps the <section> above it.
html {
font-size: 20px; /* baseline for all descendants */
font-size: 2.5vw;
}
.caroler {
text-align: center;
font-size: 1.70em;
color: blue;
padding-bottom: 1.0em;
}
.aSongControl {
display: block; /* center ... */
margin: 0 auto;
width: 90%; /* squeeze width because of .content's rounded corners */
font-size: 120%; /* for non-support text ... */
color: #990099;
}
/*
This is the audio control-specific Selector.
Other Selectors handle position and sizing.
*/
audio {
background-color: white;
}
#theSong {
/*
deliberately empty just to initialize
certain <audio> parms, e.g., the volume
*/
}<meta name="viewport" content="width=device-width, initial-scale=1">
Inside <body>
<section class="caroler">
as sung by an unknown Caroler<br>
in front of the White House<br>
on December 24th, 2018
</section>
<audio id="theSong" class="aSongControl" controls preload="auto">
<source src="audio/Lafayette_Square.m4a" type="audio/mp4">
<a href='http://www.apple.com/quicktime/download/' title='Get Quicktime' onclick='window.open(this.href); return false'>
Install Quicktime to hear this awesome Hymn
</a><br>
</audio>
<audio>As General Custer probably yelled "HAALP!"
NEW ADDITIONS TO OP:
1) a reader below strongly urged to disable zooming via a small change to the <meta> tag. Easy enough, but I can only echo what another member of STO said "It's just not nice to disable zooming, especially for those who depend on this feature".
2) Anyway, let's press on. I have 'regressed' to using JS and ditched the Viewport units, vw and vh:
document.body.setScaledFont = function(f) {
var s = this.offsetWidth, fs = s * f;
this.style.fontSize = fs + '%';
return this
};
document.body.setScaledFont(0.10);
window.onresize = function() {
document.body.setScaledFont(0.10);
}
Guess what? The <audio> STILL MOVES UP and eventually covers the <div> immediately prior to the <audio>. This undeniably means that the use of vw, vh units are not the problem.
Here is a repeat of the code for the <audio> above:
<audio id="theSong" class="aSongControl" controls preload="auto">
<source src="audio/Lafayette_Square.m4a" type="audio/mp4">
<a href='http://www.apple.com/quicktime/download/' title='Get Quicktime' onclick='window.open(this.href); return false'>
Install Quicktime to hear this awesome Hymn
</a><br>
</audio>
<audio>
with:
.aSongControl {
display: block; /* center ... */
margin: 0 auto;
width: 90%;
font-size: 120%; /* for non-support text ... */
color: #990099;
}
audio {
background-color: white;
}
At this point, I do not understand why I have to place the class="aSongControl" inside the <audio> tag in order to get the <audio> to fill the window's width via width: 80%
If I try:
<section class="aSongControl">
<audio id="theSong" controls preload="auto">
...
</audio>
</section>
there is no block centering and no window-filling, both of which are called for within .aSongControl.
I wish I knew the answer because just maybe this answer holds a clue as to why the <audio> control exhibits a mind of its own by mysteriously moving up and covering the <div> above the <audio>.
Again, no problem on OS browsers ... just the iOS browsers.
It's New Year's folks, take pity on me!
