Issue with HTML5 <audio> element
473 views
Skip to first unread message
Philip Goddard
Oct 21, 2016, 4:25:10 AM10/21/16
to bluegriffon
On my website's CD store pages, for excerpts of the CDs for people to listen to I have been using straightforward hyperlinks to the respective MP3 soundfiles, each attached to a 'play' button. That would of course then leave it to the site visitor's browser as to whether the file is played directly, and on what, or is simply downloaded. It tends to be a bit clunky for playing, however, because for most people what would happen is that by default the file would play via Flash in either the same tab (having exited the parent page) or a new tab / window, and I would rather that Flash was not involved anyway.
So, what I started doing was to replace each of those hyperlinked 'Play' buttons with the corresponding HTML5 <audio> element so that people could play the excerpts directly on the page, using HTM. This appeared to work really well, but as a compatibility backup (especially as I had no intention to duplicate the soundfiles in OGG format) I put a plain hyperlink for the respective file immediately below each <audio> element.
However, despite my having the <audio> elements each configured for preload="none", I noticed that as I worked through the page replacing the old Play buttons, page loading time in my browser was increasing, and in BG scrolling and other actions were getting increasingly sluggish, often with confusing delays in execution. I saw no obvious sign of excessive use of system resources (I have tray icons from Anvir Task Manager, which show if there are any such issues). In the browser I didn't get that sluggishness, although, as I say, page loading time was somewhat increased. Eventually BG became really frustrating in its sluggishness, and I had no sensible option to abandon the change and revert to my backup of the page, so restoring all the hyperlinked Play buttons.
This would not be an issue for me if only there were just a few of the excerpts for people to listen to, but my CD catalogue for natural soundscapes is a big one, so naturally there are lots of excerpts, and that would mean very many <audio> elements if I were to follow the HTML5 route (which I definitely want to). So, I wonder if there's any way that BG could be made to be less slowed down by multiple <audio> elements.
--
Philip
So, what I started doing was to replace each of those hyperlinked 'Play' buttons with the corresponding HTML5 <audio> element so that people could play the excerpts directly on the page, using HTM. This appeared to work really well, but as a compatibility backup (especially as I had no intention to duplicate the soundfiles in OGG format) I put a plain hyperlink for the respective file immediately below each <audio> element.
However, despite my having the <audio> elements each configured for preload="none", I noticed that as I worked through the page replacing the old Play buttons, page loading time in my browser was increasing, and in BG scrolling and other actions were getting increasingly sluggish, often with confusing delays in execution. I saw no obvious sign of excessive use of system resources (I have tray icons from Anvir Task Manager, which show if there are any such issues). In the browser I didn't get that sluggishness, although, as I say, page loading time was somewhat increased. Eventually BG became really frustrating in its sluggishness, and I had no sensible option to abandon the change and revert to my backup of the page, so restoring all the hyperlinked Play buttons.
This would not be an issue for me if only there were just a few of the excerpts for people to listen to, but my CD catalogue for natural soundscapes is a big one, so naturally there are lots of excerpts, and that would mean very many <audio> elements if I were to follow the HTML5 route (which I definitely want to). So, I wonder if there's any way that BG could be made to be less slowed down by multiple <audio> elements.
--
Philip
Greg Chapman
Oct 21, 2016, 5:56:06 AM10/21/16
to blueg...@googlegroups.com
Hi Philip,
On 21/10/16 09:25, Philip Goddard
wrote:
On my website's CD store pages, for excerpts of the CDs for people to listen to I have been using straightforward hyperlinks to the respective MP3 soundfiles ... so, what I started doing was to replace each of those hyperlinked 'Play' buttons with the corresponding HTML5 <audio> element ... as a compatibility backup ... I put a plain hyperlink for the respective file immediately below each <audio> element.
I see no reason for a "compatibility backup". If you reckon users are used to right-clicking over a hyperlink to get download/save options, they'll soon discover it's just the reverse with the <audio> tag. Right-click over it and you get Save/Copy link options.
However, despite my having the <audio> elements each configured for preload="none", I noticed that as I worked through the page replacing the old Play buttons, page loading time in my browser was increasing, and in BG scrolling and other actions were getting increasingly sluggish, often with confusing delays in execution. ... In the browser I didn't get that sluggishness, although, as I say, page loading time was somewhat increased. Eventually BG became really frustrating in its sluggishness, and I had no sensible option to abandon the change and revert to my backup of the page, so restoring all the hyperlinked Play buttons.
I guess you would expect page loading time to increase. if you're
doubling the volume of code to provide two approaches to accessing
audio files.
<audio controls="controls" preload="metadata" src="clips/myfile.mp3"></audio>
and styling code for the tag of "width:100%" but I
have not tried it with a "big" number of files. How many are you
taking about on the page? What styling do have attached to the
tag. Perhaps there are conflicts in the style file that is causing
rendering delays?
-- Greg Chapman http://www.gregtutor.co.uk Still helping users of KompoZer but using BlueGriffon
Philip Goddard
Oct 22, 2016, 7:05:08 AM10/22/16
to bluegriffon
Thanks for your thoughts, Greg. You prompted me to make a more concerted attempt, reducing code to the minimum possible, including omitting the 'backup' straight hyperlinks (I saw that there were indeed options in the right-click menu on each audio element for copying the link or saving the source), and just managed to complete not only the conversion of the Premium CD-store page, but also that of the much longer Main CD-store page, with the number of preview samples probably running into a few hundred. However, that was a struggle, leaving the Main CD-store page virtually uneditable by BG. And then, to cap it all, I found that my regular browser Pale Moon (and one can reasonably expect Firefox to respond similarly) was struggling with that page, with an unduly long loading (or rather, I assume, rendering) time and then jerky scrolling and usually somewhat delayed response to any mouse clicks or keystrokes, with over a GB memory usage. Internet Explorer couldn't cope, displaying its atrociously unacceptably big and ugly HTML5 audio player thingies but they were mostly non-functioning, and the tab soon crashed each time. Chrome was the one browser that coped well, and it was the only one that had a decent-looking player UI.
So, reluctantly, I've put my converted CD-store pages into my little purgatory store for such pages that I don't know what to do with, and have restored the originals of those pages, with the simple hyperlinked buttons, and have no plans to try using HTML5 audio again anytime soon for pages with a lot of audio to play. Clearly most browsers so far have only primitive implementation of HTML5 audio, and it's not worth my time trying to follow that route for the time being. -- Oh well!
--
Philip
So, reluctantly, I've put my converted CD-store pages into my little purgatory store for such pages that I don't know what to do with, and have restored the originals of those pages, with the simple hyperlinked buttons, and have no plans to try using HTML5 audio again anytime soon for pages with a lot of audio to play. Clearly most browsers so far have only primitive implementation of HTML5 audio, and it's not worth my time trying to follow that route for the time being. -- Oh well!
--
Philip
Greg Chapman
Oct 22, 2016, 7:26:46 AM10/22/16
to blueg...@googlegroups.com
Hi Philip,
I understand your frustration, but it's very difficult to know what's
going on with your page unless we see it or give more information about it.
You still haven't said how many links/audio clips there are on the page,
so anyone else can see if they can produce a similar page with the
issues you complain about.
Could you, at least, provide a link to the current page without use of
the <audio> tag.
It's always foolish for a doctor to attempt diagnosis without seeing the
patient. It's possible that introducing the audio tag is a red herring
and the problem really lies elsewhere.
Greg
I understand your frustration, but it's very difficult to know what's
going on with your page unless we see it or give more information about it.
You still haven't said how many links/audio clips there are on the page,
so anyone else can see if they can produce a similar page with the
issues you complain about.
Could you, at least, provide a link to the current page without use of
the <audio> tag.
It's always foolish for a doctor to attempt diagnosis without seeing the
patient. It's possible that introducing the audio tag is a red herring
and the problem really lies elsewhere.
Greg
Philip Goddard
Oct 22, 2016, 10:12:05 AM10/22/16
to bluegriffon
Thanks for your continuing interest / concern, Greg!
For what it's worth, the two pages in question are http://www.philipgoddard.com/shop/store-premium.htm and http://www.philipgoddard.com/shop/store.htm - the latter being by far the longer (especially in terms of number of preview excerpts). The corresponding converted pages, renamed with filenames suffixed with 'audiotags', are at http://www.philipgoddard.com/shop/store-premium-audiotags.htm and http://www.philipgoddard.com/shop/store-audiotags.htm (they are put there just for enabling me to link to them from here - they are officially in my 'purgatory bin' folder).
It is very definitely the use of large numbers of audio elements that has caused the sluggishness for BG and browsers - though of course I take the point that other issues could be involved too.
I wouldn't spend much time on this, for I have a gut feeling about this, that a radical rewrite of the HTML5 audio player code in BG and various browsers would be needed before one could have a whole lot of <audio> elements on a page without performance problems. Still, if there were a quick fix, that would be really nice! :-)
--
Philip
For what it's worth, the two pages in question are http://www.philipgoddard.com/shop/store-premium.htm and http://www.philipgoddard.com/shop/store.htm - the latter being by far the longer (especially in terms of number of preview excerpts). The corresponding converted pages, renamed with filenames suffixed with 'audiotags', are at http://www.philipgoddard.com/shop/store-premium-audiotags.htm and http://www.philipgoddard.com/shop/store-audiotags.htm (they are put there just for enabling me to link to them from here - they are officially in my 'purgatory bin' folder).
It is very definitely the use of large numbers of audio elements that has caused the sluggishness for BG and browsers - though of course I take the point that other issues could be involved too.
I wouldn't spend much time on this, for I have a gut feeling about this, that a radical rewrite of the HTML5 audio player code in BG and various browsers would be needed before one could have a whole lot of <audio> elements on a page without performance problems. Still, if there were a quick fix, that would be really nice! :-)
--
Philip
Greg Chapman
Oct 22, 2016, 12:04:04 PM10/22/16
to blueg...@googlegroups.com
Hi Philip,
On 22/10/16 15:12, Philip Goddard wrote:
>
> For what it's worth, the two pages in question are
> http://www.philipgoddard.com/shop/store-premium.htm and
> http://www.philipgoddard.com/shop/store.htm - the latter being by far
> the longer (especially in terms of number of preview excerpts). The
> corresponding converted pages, renamed with filenames suffixed with
> 'audiotags', are at
> http://www.philipgoddard.com/shop/store-premium-audiotags.htm and
> http://www.philipgoddard.com/shop/store-audiotags.htm (they are put
> there just for enabling me to link to them from here - they are
> officially in my 'purgatory bin' folder).
First, I can confirm that the "store" page with <audio> tags chokes
completely in Firefox. The first time I loaded it, my whole browser
locked up. (There were several other tabs open including the non-audio
tag version of the page.)
It eventually freed up after a Script error message appeared. I don't
recall the full message.
After attempting a reload much the same happened, but this time there
was no script error. As you say it appears to take a long time to load,
with the spinning "working" icon appearing on the tab as it attempts to
render the page.
So the first thing I did was check both pages for differences in the one
(Facebook) script. There were none. Then I ran the page through the W3C
validator to discover that both the pages show HTML errors.
There are 342 on the audio tag page and 119 on the other. Perhaps more
significant was that both pages have a HTML 4.01 Transitional DOCTYPE,
but audio tags are not valid with that doctype. Modern browsers are very
forgiving of poor code, but I strongly suspect that the real problem is
that with so many errors even Firefox just gets overwhelmed.
If I was tackling the problem, the first thing I'd do would be to give
the audio tag page an HTML5 doctype and then push it through the
validator again begin to tackle any errors it found.
Generally, I find that BlueGriffon is remarkably good at generating
compact and valid code, but, unfortunately, it does not check that
everything that it is asked to do is valid. You could argue that it is a
serious flaw not to check whether it is being asked to insert an
HTML5-only tag in an HTML4 document. In your case, it seems, that it
relies on the browser to cope, and in this case Firefox fails. The fact
that your non-audio tag page runs successfully with over a hundred
errors is proof at how forgiving modern browsers are. However, it seems
that Firefox can't cope with the additional ones that having audio tags
in an HTML4.01 document causes.
On 22/10/16 15:12, Philip Goddard wrote:
>
> For what it's worth, the two pages in question are
> http://www.philipgoddard.com/shop/store-premium.htm and
> http://www.philipgoddard.com/shop/store.htm - the latter being by far
> the longer (especially in terms of number of preview excerpts). The
> corresponding converted pages, renamed with filenames suffixed with
> 'audiotags', are at
> http://www.philipgoddard.com/shop/store-premium-audiotags.htm and
> http://www.philipgoddard.com/shop/store-audiotags.htm (they are put
> there just for enabling me to link to them from here - they are
> officially in my 'purgatory bin' folder).
completely in Firefox. The first time I loaded it, my whole browser
locked up. (There were several other tabs open including the non-audio
tag version of the page.)
It eventually freed up after a Script error message appeared. I don't
recall the full message.
After attempting a reload much the same happened, but this time there
was no script error. As you say it appears to take a long time to load,
with the spinning "working" icon appearing on the tab as it attempts to
render the page.
So the first thing I did was check both pages for differences in the one
(Facebook) script. There were none. Then I ran the page through the W3C
validator to discover that both the pages show HTML errors.
There are 342 on the audio tag page and 119 on the other. Perhaps more
significant was that both pages have a HTML 4.01 Transitional DOCTYPE,
but audio tags are not valid with that doctype. Modern browsers are very
forgiving of poor code, but I strongly suspect that the real problem is
that with so many errors even Firefox just gets overwhelmed.
If I was tackling the problem, the first thing I'd do would be to give
the audio tag page an HTML5 doctype and then push it through the
validator again begin to tackle any errors it found.
Generally, I find that BlueGriffon is remarkably good at generating
compact and valid code, but, unfortunately, it does not check that
everything that it is asked to do is valid. You could argue that it is a
serious flaw not to check whether it is being asked to insert an
HTML5-only tag in an HTML4 document. In your case, it seems, that it
relies on the browser to cope, and in this case Firefox fails. The fact
that your non-audio tag page runs successfully with over a hundred
errors is proof at how forgiving modern browsers are. However, it seems
that Firefox can't cope with the additional ones that having audio tags
in an HTML4.01 document causes.
Philip Goddard
Oct 22, 2016, 12:15:57 PM10/22/16
to bluegriffon
Thanks indeed for that, Greg.
Now, that makes perfect sense. So, as you say, the real need is to endeavour to get my pages, or at least those ones, HTML5-compliant. Then most likely there would be no issue.
In the meantime, with only small numbers of 'play' links per page, I'm just now in the middle of converting the hyperlinked 'play' buttons for excerpts from my music compositions into HTML5 <audio> tags. In practice that isn't causing any noticeable browser or BG problems - though clearly it'll make sense for me to go through my sites (5 of them, with a hell of a lot of pages between them) to make them HTML5-compliant as soon as reasonably possible - a huge task, I'd think!
--
Philip
Now, that makes perfect sense. So, as you say, the real need is to endeavour to get my pages, or at least those ones, HTML5-compliant. Then most likely there would be no issue.
In the meantime, with only small numbers of 'play' links per page, I'm just now in the middle of converting the hyperlinked 'play' buttons for excerpts from my music compositions into HTML5 <audio> tags. In practice that isn't causing any noticeable browser or BG problems - though clearly it'll make sense for me to go through my sites (5 of them, with a hell of a lot of pages between them) to make them HTML5-compliant as soon as reasonably possible - a huge task, I'd think!
--
Philip
Philip Goddard
Oct 23, 2016, 4:49:07 PM10/23/16
to bluegriffon
Right, now I've been working hard to get my sites converted for HTML5,
and although I've got some tricky work to do on many pages to get all
details compliant, my two CD-store pages with the audio tags are now showing no errors
in the online W3C validation service. The loading time and sluggishness
is quite a bit reduced on the Premium page, which is the shorter one, but only slightly reduced on the other one - so, while I'm actually very pleased (yes, really! :-) ) to have had this prompt to get to work to make all my sites HTML5-compliant, it appears still that for BG, Pale Moon (and I therefore assume Firefox) and Internet Explorer, so many audio elements really do choke the respective programs. It looks therefore as though I'll have to abandon use of the audio tags for those two CD-store pages and stay with the rather amateurish-looking hyperlinked 'play' buttons. The audio tags are okay for my music compositions' excerpts on my music site, because there are no more than nine audio elements on a page, and that many doesn't appear to upset anything. Haven't uploaded any of the updated pages yet, though, apart from the two CD-store ones with the audio tags, because I've got a lot of details to thrash out on individual pages to make them fully compliant, only certain of which can be addressed by a global search / replace in PowerGrep. -- Many thanks for your assistance, Greg! :-)
--
Philip
--
Philip
On Saturday, October 22, 2016 at 5:04:04 PM UTC+1, GregTutor wrote:
Greg Chapman
Oct 24, 2016, 10:32:52 AM10/24/16
to blueg...@googlegroups.com
Hi Philip,
I recognise that this might be an inappropriate work around, as I
haven't studied the content in any detail, but many would argue that
excessively long pages break web usability "rules" and it could be a
better approach to classify the content in some way and then break it up
into shorter pages that would need less scrolling adding instead
reciprocal links, or a menu system, to move between pages.
Greg
On 23/10/16 21:49, Philip Goddard wrote:
> Right, now I've been working hard to get my sites converted for HTML5,
> and although I've got some tricky work to do on many pages to get all
> details compliant, my two CD-store pages with the audio tags are now
> showing no errors in the online W3C validation service. The loading
> time and sluggishness is quite a bit reduced on the Premium page,
> which is the shorter one, but only slightly reduced on the other one -
> so, while I'm actually very pleased (yes, really! :-) ) to have had
> this prompt to get to work to make all my sites HTML5-compliant, it
> appears still that for BG, Pale Moon (and I therefore assume Firefox)
> and Internet Explorer, so many audio elements really do choke the
> respective programs. It looks therefore as though I'll have to
> abandon use of the audio tags for those two CD-store pages and stay
> with the rather amateurish-looking hyperlinked 'play' buttons. The
> audio tags are okay for my music compositions' excerpts on my music
> site, because there are no more than nine audio elements on a page,
> and that many doesn't appear to upset anything. Haven't uploaded any
> of the updated pages yet, though, apart from the two CD-store ones
> with the audio tags, because I've got a lot of details to thrash out
> on individual pages to make them fully compliant, only certain of
> which can be addressed by a global search / replace in PowerGrep. --
> Many thanks for your assistance, Greg! :-)
--
I recognise that this might be an inappropriate work around, as I
haven't studied the content in any detail, but many would argue that
excessively long pages break web usability "rules" and it could be a
better approach to classify the content in some way and then break it up
into shorter pages that would need less scrolling adding instead
reciprocal links, or a menu system, to move between pages.
Greg
On 23/10/16 21:49, Philip Goddard wrote:
> Right, now I've been working hard to get my sites converted for HTML5,
> and although I've got some tricky work to do on many pages to get all
> details compliant, my two CD-store pages with the audio tags are now
> showing no errors in the online W3C validation service. The loading
> time and sluggishness is quite a bit reduced on the Premium page,
> which is the shorter one, but only slightly reduced on the other one -
> so, while I'm actually very pleased (yes, really! :-) ) to have had
> this prompt to get to work to make all my sites HTML5-compliant, it
> appears still that for BG, Pale Moon (and I therefore assume Firefox)
> and Internet Explorer, so many audio elements really do choke the
> respective programs. It looks therefore as though I'll have to
> abandon use of the audio tags for those two CD-store pages and stay
> with the rather amateurish-looking hyperlinked 'play' buttons. The
> audio tags are okay for my music compositions' excerpts on my music
> site, because there are no more than nine audio elements on a page,
> and that many doesn't appear to upset anything. Haven't uploaded any
> of the updated pages yet, though, apart from the two CD-store ones
> with the audio tags, because I've got a lot of details to thrash out
> on individual pages to make them fully compliant, only certain of
> which can be addressed by a global search / replace in PowerGrep. --
> Many thanks for your assistance, Greg! :-)
--
Philip Goddard
Oct 24, 2016, 10:49:11 AM10/24/16
to bluegriffon
Thank you for that, Greg.
Actually the CD store pages do have sections and for a long while I'd periodically been thinking about splitting them up as you suggest. I've rather shied away from that previously, but probably, in view of this issue it would be the best thing for me to do. I'll get the work finished on making all pages properly HTML5-compliant first. Fortunately, the probably biggest practical issue there - changing a myriad different configurations of name anchors to id's, each inside the the respective container tag, has proved possible to achieve largely through a very careful use of a succession of different regex search strings in PowerGrep, and now there's a more manageable hard core that I'd have to do manually, but in EditPad, not BG, as noted in another correspondence here. :-) Then, after doing all that, making a really nice and effective split-up version of each CD-Store page should seem a pretty small and straightforward task!
--
Philip
Actually the CD store pages do have sections and for a long while I'd periodically been thinking about splitting them up as you suggest. I've rather shied away from that previously, but probably, in view of this issue it would be the best thing for me to do. I'll get the work finished on making all pages properly HTML5-compliant first. Fortunately, the probably biggest practical issue there - changing a myriad different configurations of name anchors to id's, each inside the the respective container tag, has proved possible to achieve largely through a very careful use of a succession of different regex search strings in PowerGrep, and now there's a more manageable hard core that I'd have to do manually, but in EditPad, not BG, as noted in another correspondence here. :-) Then, after doing all that, making a really nice and effective split-up version of each CD-Store page should seem a pretty small and straightforward task!
--
Philip
Reply all
Reply to author
Forward
0 new messages