Re: HTML Feature Suggestion

On Fri, Apr 8, 2011 at 5:50 PM, Paul Cotton <Paul.Cotton@microsoft.com>wrote:

>  >1) Use cases: list some cases on which there is an unsolved need.
> Describe the need and why it can't be solved with current technologies.
>
> >2) Requirements: trim out the side stuff from the use cases, and take the
> "needs" together. From there, elaborate on them: what is required for those
> needs to be properly fulfilled?
>
>
>
> At this point in time providing just the use cases and requirements for
> possible HTML.next features is fine.
>
>
>
> While I agree that providing “Proposal details” and “Justification” will be
> required later, I do not see that they are required at this early stage.
>

I didn't say those where "required", just suggested them as ways to improve
the proposal.

Indeed, if someone's goal is to bring attention of the group to a need that
should be addressed, then use cases + requirements are definitely enough, so
a solution can be built from there.

However, if I understood DocMoD's post, he was actually proposing a specific
solution. If he wants to advocate for that solution, he will definitely need
to describe it more clearly and back it up with some degree of
justification.

As a matter of fact, while I disagree with the proposal itself*, I do agree
that the presented use case* deserves some attention (* take this with a
grain of salt: I'm still unsure if I understood what he meant properly).
In the aim to bring the topic forward, I'm going to try to review the use
case I inferred from the original post and derive some requirements from
there (DocMoD, please let me know if I misunderstood something):

It is a reasonable aim for many artists to want a website where they can
show off some of their work _and_ provide information about themselves. Both
of these goals can be fulfilled, separately, with current technologies:
sharing information was one of the earliest uses of Internet, and HTML has
been good at it since it exists; while HTML5 specifically provides solutions
to serving multimedia content through the Web. There are some cases,
however, where both of these clash quite inconveniently:

A user who is reading the information on a musician's website may be
listening to some background music from that artist, but navigating around
the site interrupts the playback (and would even require the user to
actively choose to start it again).

As of now, the workarounds that have been used to deal with this are just
that, workarounds, and suffer from significant issues:
* "Flash sites" and similar: sites built in entirely as an opaque object
that requires some plugin technology to be rendered. These sites are hardly
indexable or bookmark-able, often require significant programming skills to
develop, and are heavily inaccessible.
* Frames (both iframes and framesets) allow having the media playback and
the main content on separate browsing contexts, so navigating within the
content context doesn't interfere with the playback. While things have
improved noticeably over the years, these techniques are still troublesome
for indexing, bookmarking, using navigational aids (like the back/forward
button), and accessibility.
* AJAX and other JS-based techniques: with enough skill and care, and
abusing fragment identifiers, it is _possible_ to build a site with
uninterrupted media (audio or video) playback that is still navigable,
indexable, and even accessible. However, such sites are in fact a
non-trivial software development project; and getting all the details right
is often out of the reach of most authors other than professional,
experienced programmers.

The primary requirement that derives from this pattern is a mechanism to
provide uninterrupted playback (controlled by the user, of course, but
navigating shouldn't interrupt it as a side-effect), without interfering
with the web's most common navigation mechanisms.
Since the use case is mostly focused on artists' needs, a secondary
requirement would be for the solution to _not_ require programming or other
technical skills, as not many artists are also engineers.
While not a hard requirement, it is still a worthwhile goal to look for a
solution that is as accessible as possible. It must be noted that some forms
of artwork are inherently unsuitable for some persons. For example, it's
probably _not_ worth the effort (if it's doable at all) to make music
samples "accessible" to a deaf person; or a video presentation of paintings
to a blind person. OTOH, and following with those examples, a blind person
should be able to get the information published on a musician's site, and
listen to the music there.


Now, as a form of brain-storming, I'll mention some possible approaches to a
solution:
- DocMoD's proposal described some flavor of framesets specifically tailored
for this case. Personally, I fail to see how a new frame model could work
better than just improving upon iframes.
- So, another possible approach would be add some attribute to iframes (like
"main-content") to hint to the browser that the primary content for the page
is within that frame, and everything else is secondary (navigation, headers
+ footers, background media, etc). The UA should then rely on this hint to
alter the behaviour of navigation controls (back/forward buttons, bookmarks,
etc) accordingly. This is, in essence, a generalization of DocMoD's proposal
that, for a similar (or probably cheaper) spec and implementation cost could
address the requirements while being much more flexible.
- And yet another alternative would be to flag audio or video elements that
are supposed to keep playing continuously (for example, with a "poppable"
boolean attribute). When a user navigates away of the page providing the
media element, the browser should present some option to "pop" that element
outside of the current browsing context, so it keeps playing until the user
explicitly stops it. An example of how this could be implemented (for
<audio> elements) could be a miniplayer on a corner of the browser, similar
to Microsoft's Windows Media Player's "player toolbar" feature (for those
unfamiliar with this: on Windows systems, the player can be configured so,
when minimized to the taskbar, it displays a few basic controls instead of
the typical button, but taking roughly the same space); similarly, an audio
player could be "minimized" to a non-intrusive location within the browser.
Of course, many other implementations are possible, this is just an example.

At this point, it would be nice to hear from DocMoD's whether these
alternatives would indeed address his needs; from other web-authors about
their opinion on these or any other approach; and from UA vendors about what
would be cheapest or most viable to implement.

Regards,
Eduard Pascual