Re: HTML Feature Suggestion

On Wed, Apr 6, 2011 at 10:38 PM, DocMoD <doc.mod@comcast.net> wrote:

> I tried to post this on your web, but there was a javascript error on the
> page.
>
>
>
> I am suggesting a replacement for the "Frameset". IMO, there is still a
> need for this type of presentation in specific context. The example I will
> use here is uninterrupted media presentation along with the document
> (specifically audio).
>

In general, a "frameset" can be built using a table and iframes. This
approach does work for uninterrupted media. The only issue with the table +
iframe approach is that it currently requires non-trivial scripting to
emulate the "resizeable" behavior available on framesets.



> Case: With the social media boom of today, there are more established and
> undiscovered Songwriters / Composers, Music Producers, Vocalist and
> Musicians (herein referred to as Artist) that are establishing a web
> presence. This has become so big that Billboard created a chart specific to
> this; <a href="http://www.billboard.com/charts/social-50">Billboard Social
> 50</a>.
>
> As a developer and a composer, I see the desire for an artist to want to
> present relevant content to their user base. Relevant content meaning (in
> this context) copy and music. I also see the desire for the user to have
> this presentation in a manner to where one does not disrupt the other.
>

Is there any aspect of that case that can't be solved with the tables +
iframes approach? If so, please elaborate on what are the actual
requirements, and why currently existing solutions are not enough to fulfill
them.



> Before I continue, I have to state that I do not advocate any kind of audio
> starting immediately when a site first loads (as a matter of fact, I HATE
> THIS). I also acknowledge the past problems with framesets and agree with
> the developers coined statement that, "Frames Are Evil".
>
Oh, poor frames! They ain't evil. They are just unanimated chunks of markup,
they aren't even _able_ to be evil. OTOH, Frameset was a bad implementation
of the frame concept.



> Now, with today's available technology, there are several ways to achieve
> un-interrupted media presentation while the user progresses through a site:
>
>     1) Use Ajax to prevent the entire document from flushing.
>
>     2) Use a plug-in type technology (i.e. Silverlight or Flash) to deliver
> the presentation
>
>     3) Use a Frameset.
>
> I personally would like to see this delivery option stay within HTML,
> especially with the merging of media presentation in the HTML 5 spec.
>
Personally, I would like to see framesets dying ASAP. Again, you have
iframes to deal with those tasks (most of the features with only some of the
issues).

I do agree that framesets in its current form should be degraded.
>
What do you mean with that? I'll assume you meant "deprecated" (ie: marked
as bad/obsolete practice) rather than "degraded" (ie: making them even
worse).


> However, with a replacement such as Media Frameset (or the like). This
> should also have some restrictions as such:
>
Why should there be those restrictions? What problems are you aiming to
prevent with them?


>     1) The mediaframeset cannot be indexed by search engines.
>
Don't tell search engines what search engines can do. If you want to tell
them that they _shouldn't_ index something, robots.txt is there for that
job. Other than that, this would be an interesting field for them to compete
in (and healthy competition is always good!)


>     2) The mediaframeset cannot be the sites primary delivery mechanism. It
> can only be launched from within the domain (e.g. button click etc)
>
These two aren't really related. A site can put up a page with just a button
as big as the viewport that launches the frame, killing the purpose of the
restriction and needlessly annoying the user. Why shouldn't a site whose
primary content is media use a media feature as its primary delivery
mechanism? If that can really be justified, then we should think of a
solution that actually solves that.


>     3) The mediaframeset should only present content from within the
> domain. This is with the exception of communicating with an API of an
> external service.
>
Current iframes already provide mechanisms to provide, at the author's
choice, origin-restricted or unrestricted content.


>     4) The mediaframeset should allow cross-frame scripting only if the
> script exists in the domain.
>
In general, both browser vendors and the HTML5 WG try their best to shut
down any possibility of cross-domain scripting. So, this seems redundant
with current practice; but at least it's also consistent with such practice.


> The mediaframeset should also have some enhancements as such:
>
>     1) The mediaframeset should be stylable with CSS for the purpose of
> creating skinlike themes. Would need properties closely related to what is
> available to the body tag.
>
Again, by styling an iframe _and_ the document it displays, you should be
able to achieve that and more.


>     2) The mediaframeset should have the child tags <mediaframe /> and
> <contentframe /> only for example.
>
And how is that an enhancement? Also, you should try to be more specific: if
you are making a proposal, you are supposed to define your proposal.


>     3) The mediaframeset should expose its head section to the contents
> frames server side or client side code / script so that the site url's and
> meta data can be properly presented.
>
HTML has no control on what happens on the server. Aside from that, I don't
think the requirement you are describing here is rather unclear. Would you
mind elaborating further on that? How is supposed to interfere the
availability of data to scripts with the way metadata is presented?


> The user should receive the benifit of the media presentation without
> restriction of proper bookmarking, url paths etc.
>
Now, that's a legitimate goal: having the benefits of frames without the
issues. Or, more specifically, being able to present uninterrupted media
without the annoyances derived from the use of frames. However, is
resurrecting framesets (the genuine culprits of the issues) the best
approach to address them? Here are a couple alternative approaches, from the
top of my head:

 - An attribute "poppable" for <audio> and <video> that allows a user to
keep the media content on a frame-like context, while navigation on the main
browsing context continues as normal.
 - An attribute "main-content" for <iframe> that informs the browser that
the main content of the page is actually presented through that iframe (ie:
the outer part is just navigation, media, headers + footers, etc), so the
browser can adjust the way it manages the navigation-related features
(bookmarking, back/forward buttons, etc) accordingly.

Both of these seem simpler to implement, have less impact on the current
structure of the language (framesets needed an entire DTD just for
themselves, remember? That's not something to be taken lightly, even if HTML
doesn't explicitly relies on DTDs anymore), and yield greater flexibility
than your proposal (for example, a poppable <audio> could be initially
positioned wherever the author feels, instead of being forced to be at
top/side/bottom of the content). So please, give these ideas some thought;
maybe you can come up with something even better ;-)


> There are more considerations here, but by now, you get the idea.
>
Do we? I have barely managed to infer the goal of your proposal (enabling
uninterrupted media playback without interfering with main content's
navigation), and still have no idea how your proposal is supposed to fulfill
such goal. Wait, I'm not even sure about what you are proposing.
I don't want to sound harsh, but just an idea without propper work to define
and polish it won't be enough. Here are some hints on how you can improve
your proposal:
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?
3) Proposal details: describe your proposed solution _in detail_. If you are
not used to write spec-style text, here is an alternative that can work: put
together the markup that would be used if your proposal is adopted, and
explain how each addition to that markup differs from current browser
behaviour.
4) Justification: describe how your proposal actually solves the needs and
fulfills the requirements. This may seem pointless before you try, but if
your requirements are well-defined and your proposal is not, you should be
able to spot the proposal's issues while trying to justify it. This will
help you to polish your proposal, and to be taken more seriously by the WG.

Regards,
Eduard Pascual