HTML Feature Suggestion

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

HTML Feature Suggestion

DocMoD

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

 

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.

 

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

 

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.

I do agree that framesets in its current form should be degraded. However, with a replacement such as Media Frameset (or the like). This should also have some restrictions as such:

    1) The mediaframeset cannot be indexed by search engines.

    2) The mediaframeset cannot be the sites primary delivery mechanism. It can only be launched from within the domain (e.g. button click etc)

    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.

    4) The mediaframeset should allow cross-frame scripting only if the script exists in the domain.

 

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.

    2) The mediaframeset should have the child tags <mediaframe /> and <contentframe /> only for example.

    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. The user should receive the benifit of the media presentation without restriction of proper bookmarking, url paths etc.

 

There are more considerations here, but by now, you get the idea.

Regards

 

Reply | Threaded
Open this post in threaded view
|

Re: HTML Feature Suggestion

herenvardo


On Wed, Apr 6, 2011 at 10:38 PM, DocMoD <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

RE: HTML Feature Suggestion

Paul Cotton

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

 

/paulc

HTML WG co-chair

 

Paul Cotton, Microsoft Canada

17 Eleanor Drive, Ottawa, Ontario K2E 6A3

Tel: (425) 705-9596 Fax: (425) 936-7329

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Eduard Pascual
Sent: Friday, April 08, 2011 11:41 AM
To: DocMoD
Cc: [hidden email]
Subject: Re: HTML Feature Suggestion

 

 

On Wed, Apr 6, 2011 at 10:38 PM, DocMoD <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: HTML Feature Suggestion

herenvardo
On Fri, Apr 8, 2011 at 5:50 PM, Paul Cotton <[hidden email]> 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