>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: [email protected] [mailto:[email protected]] On Behalf Of Eduard Pascual Sent: Friday, April 08, 2011 11:41 AM To: DocMoD Cc: [email protected] Subject: Re: HTML Feature Suggestion On Wed, Apr 6, 2011 at 10:38 PM, DocMoD <[email protected]<mailto:[email protected]>> 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
