Re: [whatwg] video element not ready for prime time
On Thu, 07 Jun 2012 04:06:10 +0200, Kit Grose k...@iqmultimedia.com.au wrote: On 06/06/2012, at 7:44 AM, Ian Hickson wrote: On Fri, 13 Jan 2012, Kit Grose wrote: I'd argue that while we did receive in WebM a common codec it does not enjoy the sort of universal adoption required to be able to mandate its support in the spec, so on that logic, I think establishing a declarative fallback mechanism is probably required to prevent a situation where you cannot write a robust HTML5 page with video and without resorting to JS. I don't think it's time to give up yet, but maybe I'm overly optimistic... Is there any reason why it wouldn't be prudent to render the content of the video element as HTML if the video cannot be played, given that fallback content in the video element is already supported for legacy browsers in the spec: Content may be provided inside the video element. User agents should not show this content to the user; it is intended for older Web browsers which do not support video, so that legacy video plugins can be tried, or to show text to the users of these older browsers informing them of how to access the video contents. How are legacy UAs without video support appreciably different from a UA with restrictive or limited video support? Surely the author's intent in either case is delivering the content in a different way or delivering appropriate alternate content. Even if we eventually get a common codec (which I—perhaps overly pessimistically—feel is unlikely), authors are already using the video element without supplying whatever that eventual codec will be, and users are suffering without reasonable fallbacks. As it stands, it's almost better (and certainly easier) for authors to default to Flash video and use the existing, declarative fallback behaviour of the object element to use a video element instead. That can't be in the best interest of the open web. This was discussed in the thread HTML 5 video tag questions in 2009: http://lists.w3.org/Archives/Public/public-whatwg-archive/2009Jul/thread.html#msg278 The resource selection algorithm never fails - it simply waits for another source to be inserted - so the the hard part is when to show the fallback content. At the time I was very skeptical of switching back and forth between fallback and trying to load a video as more source elements are added, and I still am. -- Philip Jägenstedt Core Developer Opera Software
[whatwg] binary encoding
http://wiki.whatwg.org/wiki/StringEncoding defines a binary encoding (basically the official iso-8859-1 where it is not mapped to windows-1252). Is it an idea to move that http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html somehow? I do not think we want to give it an officially supported label, but it does make some sense to define it using the same infrastructure. http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html has the same need for converting certain types of DOMString. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] binary encoding
On Mon, Jun 11, 2012 at 6:03 AM, Anne van Kesteren ann...@annevk.nl wrote: http://wiki.whatwg.org/wiki/StringEncoding ... hasn't been getting much attention from me recently. I'll recap the open issues and proposed resolutions to this list soonish. defines a binary encoding (basically the official iso-8859-1 where it is not mapped to windows-1252). which is residue from earlier iterations. Intended use case was interop with legacy JS that used the lower 8 bits of strings to hold binary data, e.g. with APIs like atob()/btoa(). Is it an idea to move that http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html somehow? On its own, this use case is probably not strong enough to merit slipping a pseudo-encoding into the platform, but...On its own, this use case is probably not strong enough to merit slipping a pseudo-encoding into the platform, but... I do not think we want to give it an officially supported label, but it does make some sense to define it using the same infrastructure. http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html has the same need for converting certain types of DOMString. ... as there are other use cases then we should codify it. I have no preferences as to label; the proposed JS API could specify a label for it, but defer the specifics of the encoding to the Encoding spec. (I believe as written I currently call out the special case that BOM detection should never be done for binary which is already a special case, although BOM detection vis-a-vis the API is itself an open issue)
Re: [whatwg] Proposal for change in recommendation for loading behavior of non-applicable stylesheets
Thanks again, Boris. These are fair answers, but I can't help but think that the problem is critical enough to warrant spec-level consideration. As device contexts are increasing, authors are referencing more stylesheets to address them, and the existing behavior across most browsers ensures that every last byte of those stylesheets will be loaded - often in a synchronous/blocking manner. This is less about author convenience and more of a benefit to users: deferring the load of inapplicable stylesheets would surely have a large impact on perceived page performance. I'd be happy to provide some demos of existing sites with my shim included for profiling sake. Further, judging by the response received on twitter when I posted that research last week, I think the current behavior is not at all what most authors expect to happen. But we also don't really have any other options aside from using JavaScript to make it work the way it seems like it really should. I think you've rightfully pointed out that the lazy-loading idea probably won't fly with vendors and could even cause problems in certain cases. In the past, there were similar concerns for @media print stylesheets, which are always requested (like all other non-applicable media) up-front, perhaps in the off-chance that connectivity would be lost when the user tries to print. That's at least the reasoning I'd seen cited before, and that behavior led to authors embedding @media print styles inside their @media all stylesheet just to prevent that HTTP overhead. Unfortunately, these days inlining every media query does nothing to solve this problem, aside from reducing HTTP requests by shifting all our weight into a single heavy request. Even assuming that implementing this feature would mean delaying CSS prefetching until the metaviewport tag was parsed, wouldn't the tradeoff in page loading speed be worth it? I'd imagine many pages could have several fewer blocking requests as a result. Thanks again and if you feel this isn't the proper forum for addressing this issue, do you have any suggestions where I should take it? Scott
Re: [whatwg] Proposal for change in recommendation for loading behavior of non-applicable stylesheets
On 6/10/12 11:26 PM, Scott Jehl wrote: These are fair answers, but I can't help but think that the problem is critical enough to warrant spec-level consideration. Oh, yes. The question is how to spec this in a way that doesn't overconstrain future implementations to behave suboptimally. I think you've rightfully pointed out that the lazy-loading idea probably won't fly with vendors and could even cause problems in certain cases. I think it would be quite doable and the spec should be changed to allow it. I'm just not sure that the spec should _require_ it in all cases, because we can end up in situations where simply detecting whether something should be lazy-loaded or not is more expensive than just loading it. Even assuming that implementing this feature would mean delaying CSS prefetching until the metaviewport tag was parsed, wouldn't the tradeoff in page loading speed be worth it? It depends on the use cases Consider a page that has no meta viewport at all (i.e. most of them). Your proposed change right above would disable CSS prefetching altogether on such a page, which is pretty undesirable. Thanks again and if you feel this isn't the proper forum for addressing this issue, do you have any suggestions where I should take it? This list is the right forum. -Boris
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Thu, Jun 7, 2012 at 9:21 AM, Charlie Reis cr...@chromium.org wrote: On Wed, Jun 6, 2012 at 11:47 PM, Adam Barth w...@adambarth.com wrote: On Wed, Jun 6, 2012 at 6:59 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jun 6, 2012 at 8:26 PM, Bjartur Thorlacius svartma...@gmail.comwrote: On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote: Please don't encourage yet more sites to open new tabs when I didn't ask for it. I don't see this as any different from using target=_blank or window.open. The same popup restrictions would apply. This link type wouldn't make much sense on a same-window navigation, in my opinion. It's merely a new browsing context IIUC, not necessarily a new window (frame, tab, tile or whatever it's called this year). Someone that understands the codebase of a modern browser could even make the back button work, although he would have to restrict write access to the history stack or tree as well, for security reasons. He's saying he wants it to force target=_blank, though. That doesn't seem necessary. Why not navigate the current window to a new document in an unrelated browsing context? Adam That would hit all the problems Michal brought up, where you might target an existing window or iframe, causing existing references to the window to no longer be valid. That could be harder for browser vendors to implement. I do think it would be cleanest to have it open in a new window, using target=_blank. Charlie Any other feedback on this proposal? http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts Thanks, Charlie
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On May 29, 2012, at 6:49 AM, Florian Rivoal wrote: * It has two attributes that could easily be confused as doing the same job. There's little clear logic as to why they're split, from an authors viewpoint. It might be confusing, but there is logic in the splitting: srcset=. lets you describe the properties of a set of equivalent images, and the browser decides which one is more appropriate given the environment. picturesource media=... lets you decide which image should be displayed based on the properties of the medium you're displaying on. This makes perfect sense, and certainly seems to cover all of the potential use cases of `picture` and `srcset` alone — even so far as preserving the brevity of the original proposal, in cases where that markup pattern is most appropriate. Is it fair to say that `srcset` will likely remain drafted as a solution to the resolution issue alone, and that `picture` with `srcset` functionality added should be handled as a separate proposal altogether? Just looking for some guidance on how to proceed from here. Thanks, Mat Marquis
Re: [whatwg] Image cache behaviour
On Wed, 21 Mar 2012, Andrew Oakley wrote: I've noticed that some browsers (Firefox, Opera, IE) cache images without following the HTTP expiry rules. This does not appear to be permitted by the HTML5 specification. I've got a test case for this (with explanation) here: http://ado.is-a-geek.net/expired/tests/image_cache_test.html Boris Zbarsky believes this behaviour is required for compatibility so I think it is worth adding to HTML5. This was discussed on the Mozilla bug tracker here: https://bugzilla.mozilla.org/show_bug.cgi?id=295942 How do other browsers handle this? It seems to be possible to get Opera and IE to throw the image away by changing the src attribute on the img. Are there similar caches for any other type of object or is this just images? For images in img elements I've now explicitly added spec-level support for such a cache. Not my favourite part of the spec, but if it's what implementors do interoperably... The spec is a bit vague, let me know if there's anything I can do to tighten it up while still being compatible with what UAs will implement. http://html5.org/tools/web-apps-tracker?from=7127to=7128 On Wed, 21 Mar 2012, Boris Zbarsky wrote: Gecko has a similar (different in mechanism, but not too different in effect) cache for stylesheets. I seem to recall that there was explicit text about this as well, but I can't find it now. The closest I can locate at the moment is the first paragraph at http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetch If the resource is identified by an absolute URL, and the resource is to be obtained using an idempotent action (such as an HTTP GET or equivalent), and it is already being downloaded for other reasons (e.g. another invocation of this algorithm), and this request would be identical to the previous one (e.g. same Accept and Origin headers), and the user agent is configured such that it is to reuse the data from the existing download instead of initiating a new one, then use the results of the existing download instead of starting a new one. Right now I haven't specced anything like this. Ideally I'd like to move all the CSS logic out of the HTML spec, since e.g.I assume that any caching for link rel=styleseet would also need to happen for @import. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] metadata attribute for media
Recently, we've been considering adding a 'tags' or 'metadata' attribute
to HTML media elements in Firefox, to allow webcontent access to
metadata from the playing media resource. In particular we're interested
in tag data like creator, title, date, and so on.
My recollection is that this has been discussed a number of times in the
past, but there was never suffient motivation to support the interface.
Our particular motivation here is webapps that present a media file
library. While it's certainly possible to parse the tag data out
directly with javascript, it's more convenient if the HTML media element
does so, and the underlying platform decoder libraries usually provide
this data already.
As such I wanted to raise the issue here and get design feedback and
levels of interest for other user agents.
Here's a first idea:
partial interface HTMLMediaElement {
readonly attribute object tags;
};
Accessing media.tags provides an object with a key: value data, for example:
{
'title': 'My Movie',
'creator': 'This User',
'date': '2012-06-18',
'license': 'http://creativecommons.org/licenses/by-nc-sa/'
}
The keys may need to be filtered, since the files can contain things
like base64-encoded cover art, which makes the object prohibitively
large. The keys may need to be mapped to some standard scheme (i.e.
dublic core) since vocabularies vary from format to format.
This is nice because it's easy to access, can be simply enumerated,
and extensible. Which is helpful when if gets added the img for exif data.
-r
Re: [whatwg] Image cache behaviour
On 6/11/12 5:48 PM, Ian Hickson wrote: Right now I haven't specced anything like this. Ideally I'd like to move all the CSS logic out of the HTML spec, since e.g.I assume that any caching forlink rel=styleseet would also need to happen for @import. It does in Gecko, yeah. -Boris
[whatwg] Machine translation and related proposals
On Mon, 26 Mar 2012, Adam Barth wrote: On Mon, Mar 26, 2012 at 3:17 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 26 Mar 2012, Adam Barth wrote: WebKit recently implemented http://www.whatwg.org/specs/web-apps/current-work/#attr-translate, but that caused us to break orange.fr on mobile: https://bugs.webkit.org/show_bug.cgi?id=82246 The problem is that http://www.winktoolkit.org/documentation/symbols/HTMLElement.html#translate has a the following code: if (wink.isUndefined(HTMLElement.prototype.translate)) � � HTMLElement.prototype.translate = HTMLElement.prototype.winkTranslate; The web site expects HTMLElement.prototype.translate to be Wink's translate function rather than the HTML translate attribute. Would it make sense to change the name of the translate attribute to avoid this conflict? �Should we try to evangalize the Wink Toolkit to change their code and everyone who uses Wink to update to the fixed version? How widely used is it? (In particular, how widely used is .translate() rather than .winkTranslate()?) The documentation lists only .translate(), not .winkTranslate(), so I would expect most folks using the library to use the former rather than the latter. On Mon, 26 Mar 2012, Edward O'Connor wrote: It would be unfortunate to have to reserve the use of a name as generic as translate for a particular library. Indeed. That said, the name translate already means something in the platform—it's used by CSS transforms and by the canvas 2D Context API. Wink's usage of the term matches the existing use of the term on the platform. Maybe we should rename the is this element translatable or not attribute to, say, translatable. On Tue, 27 Mar 2012, jerome.gir...@orange.com wrote: We had already planned on finding a replacement for our HTML Element extensions and I think the current discussions will force us to speed things up, which is a good thing :) This was a legacy feature that we decided we should get rid of a long time ago for these obvious conflicts reasons, though we had never imagined the translate would be used on HTMLElements in an i18n context (so +1 for Edward O'Connors comment if I may) I already warned the persons in charge of the Orange portal and they will replace the HTMLElement.translate calls. We will warn our users and prepare the necessary changes for our next release. Since you are on top of this I have not changed the attribute name in the spec. Please do let me know if this ends up being a less tractable problem than it currently appears. On Wed, 2 May 2012, Charles Pritchard wrote: There has been some discussion on the w3c/whatwg mailing lists about how far we can mark up content with linguistic tags, such as marking word and/or sentence boundaries. In my authoring of web apps, I often write a short manual into a hidden div, so that the vocabulary of my application can be processed by translation services such as Google translate. Having content in the DOM seems the most appropriate way to handle translation. I'd like the group to consider the costs/benefits/alternatives to a lang- attribute. Such as span lang-role=sentenceThis is a sentence./span The data- and aria- attributes have worked out well. We may want to make room for one more. Such a structure could be used to markup typical subject/object/verb and clause sections; it could also be used to markup poetic texts as well as defined meanings of content. http://www.omegawiki.org/Expression:orange This is an span lang-meaning=DefinedMeaning:orange_(5821)orange/span. Now this, this is span lang-meaning=DefinedMeaning:orange_(5822)orange/span. In most cases there's no need to define sentence boundary, meaning or otherwise. But, it'd sure be nice to have the ability to do so in a standard manner. I'd recommend role, meaning and prosody/pronunciation as the primary targets. Character markup may be something to consider as it's come up in SVG (rotate) and in CSS before. Doing a span for each character is not practical, so we'd want a shorthand much as SVG has shorthand for rotate. On Wed, 2 May 2012, Tab Atkins Jr. wrote: Do you expect outside services to do anything useful with this information? If not, the data-* attributes seem appropriate. If you do expect that, have you evaluated the existing mechanisms for embedding custom data in the page and found them wanting? If so, how? On Wed, 2 May 2012, Charles Pritchard wrote: Yes, that's the primary reason. services such as Google translate. 1. Google translate gets a little loose with some markup, to where the translated content may be placed outside the span tag. Such as: div id=oneMy potato is spanhot/span/div. 2. Some words can be ambiguous to the point that even a human reader may not know what the meaning is. It'd be great to have a mechanism to disambiguate. 3. Speech
[whatwg] Accept-Language DOM API proposal
On Thu, 29 Mar 2012, Matthew Nuzum wrote: Hello, on every HTTP request your browser sends header called Accept-Language with a value something like this: en-gb,en-us;q=0.7,en;q=0.3 This is sent to all domains wither your request is for an image, an html file, a js script, or whatever. This gives server-side code some nice capabilities, one of the foremost being the ability to localize content. As you all are well aware, more and more application logic is being done on the client side. In some cases, even HTML templating is being done there. In a few project I've been involved with recently it would have been nice to be able to identify the user's preferred language client side. Browsers support a value called navigator.language but it does not convey the same information as the HTTP header. On many browsers it simply indicates which language the browser is localized in. For example, if you speak Spanish but buy a computer in America which comes with Firefox pre-installed then despite what language you prefer it will be en-us. Some browsers have gotten smarter and now send the first value from the user's language preference, which is definitely an improvement. I suspect this was done in order to preserve backwards compatibility, so much of the useful information is left out. What would be great is if client side scripts could access the same information the server side code could access. That could be done simply be creating a new property that contains the same string as is sent to the server. It's easily parseable. But if we're going to make a new interface then maybe it would be good to make one that reduces the amount of work that client side developers would need to do. [...] On Fri, 30 Mar 2012, Henri Sivonen wrote: Is there a reason to believe that this client-side solution would be used significantly considering that the HTTP header has not been used that much? On Fri, 30 Mar 2012, Matthew Nuzum wrote: I've used the HTTP header numerous times and I know many people that have. It is so commonly used that Apache even has built in support to make use of it when serving content. For example, if you visit http://start.ubuntu.com/9.04/ you'll be presented with a page that is probably in your language (we translated it into 42 languages). The way the content negotiation feature of Apache works is that you name pages in a pattern like this: index.html.en, index.html.fi, etc. You can see how we did that here: http://bazaar.launchpad.net/~ubuntu-start-page/ubuntu-start-page/trunk/files/head:/www/9.04/ It's quite easy to make use of this feature and I think it might be more commonly done than you suspect. And if we were to make it even easier to do I think that it would increase in use. For example, maybe a site can't afford translation but a small library could be included that formats dates and numbers based on a user's language preference. No more wondering if 2/3/12 is in March or in February. On Fri, 30 Mar 2012, Henri Sivonen wrote: The reader doesn't know that the site tries to be smart about dates (but not smart enough to just use ISO dates), so scrambling the order of date components not to match the convention of the language of the page is probably worse than using the convention that's congruent with the language of the page. On Wed, 4 Apr 2012, Mark Callow wrote: I would love it, if more sites would use these headers. As someone else pointed out, some web servers make it very easy. I would support an equivalent client-side query. The current favourite algorithm among servers seems to be to serve a language based on their perception of your current location. There are so many reasons why this causes them to serve the wrong language, it is beyond my understanding why so many sites do it. As a native English speaker living in Japan, I suffer from it every day. The HTTP headers provide a much better mechanism. I haven't added anything to expose this; it's not clear to me that it would actually be worth it in practice, since there doesn't seem to be much chance of many authors using it, the browsers don't really expose the relevant settings UI well, and pragmatically most sites that do translation are going to want to be shipping different bits in the first place for performance reasons (you don't want to wait a round-trip to get the UI strings, and you don't want to send all the UI strings, typically), so HTTP headers would be enough. However, I'd love to be proved wrong, so my recommendation would be to advocate this to browser vendors and see what they are willing to implement. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Readiness of script-created documents
On Fri, 30 Mar 2012, Henri Sivonen wrote: On Fri, Jan 13, 2012 at 2:26 AM, Ian Hickson i...@hixie.ch wrote: Jonas is correct. Since there was no interop here I figured we might as well go with what made sense. I'm somewhat unhappy about fixing IE-introduced APIs to make sense like this. The implementation in Gecko isn't particularly good. When trying to make it better, I discovered that doing what IE did would have lead to simpler code. On Fri, 30 Mar 2012, Jonas Sicking wrote: That's not a particularly strong argument. The question is what's better for authors. On Mon, 2 Apr 2012, Henri Sivonen wrote: Gratuitously changing features introduced by IE does not help authors when they have to support the old IE behavior for years. Either authors don't use the API in the uninteroperable situation or they will have to deal with different browsers returning different things. The easiest path to get to the point where all browsers in use return the same thing would have been for others to do what IE did. On Mon, 2 Apr 2012, Jonas Sicking wrote: Everyone returning the same thing isn't the only goal. First of all what's the purpose of all browsers doing the same thing if that same thing isn't useful? Second, you are assuming that people are actually aware of this edge case and account for it. Here it seems just as likely to me that generic code paths would result in buggy pages given IEs behavior, and correct behavior given the specs behavior. Third, if no-one is hitting this edge case, which also seems quite plausible here, then it having a while longer without interoperability won't really matter what we do and doing the most useful thing seems like the best long-term goal. On Tue, 3 Apr 2012, Henri Sivonen wrote: No one is worse off and stuff works even if an author somewhere relies on a crazy edge case behavior. On the other hand, for cases no one is hitting, it's probably not worthwhile to spend time trying to get the behavior to change from what was initially introduced. On Tue, 3 Apr 2012, Jonas Sicking wrote: I think we should aim higher than that for the web platform. I agree with Jonas here. If browsers are going to have to change anyway, why not change to the better solution, even if that isn't the solution that is most trivial to implement or the solution that the first implementation happened to have? The platform has enough crazy without us adding more to it when we don't have to. On Mon, 23 Apr 2012, Henri Sivonen wrote: On Mon, Jun 20, 2011 at 3:10 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 20, 2011 at 4:26 AM, Henri Sivonen hsivo...@iki.fi wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039 It says complete in Firefox, loading in Chrome and Opera and uninitialized in IE. The spec requires complete. readyState is originally an IE API. Why doesn't the spec require uninitialized? (The implementation in Gecko is so recent that it's quite possible that Gecko followed the spec and the spec just made stuff up as opposed to the spec following Gecko.) complete seems like the most useful and consistent value which would seem like a good reason to require that. Why don't aborted documents reach complete in Gecko? It seems weird to have aborted documents stay in the loading state when they are not, in fact, loading. On Wed, 25 Apr 2012, Jonas Sicking wrote: Sounds like a bug, I don't think this was done on purpose. I agree that we should ideally only be in loading when we're actually loading. When a document is aborted the state is more or less left exactly as it was when it was aborted. This includes the readiness state. It also means no events fire (e.g. no 'load', 'unload', or 'error' events), a number of scripts just get abandoned without executing, appcache stuff gets abandoned, queued calls to window.print() get forgotten, etc. Aborting a document is a very heavy-handed measure. Documents are not expected to last long after they have been aborted, typically. Pages aren't expected to remain functional beyond that point. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 'Applicable Specifications'' Relevance Authors
On Wed, 11 Apr 2012, Smylers wrote: The definition of an 'applicable specification' is marked as only having relevance for implementations: http://www.whatwg.org/html#other-applicable-specifications I think that the paragraph which defines an applicable specification and the note that follows it are relevant to authors, too -- in particular authors wondering if they can extend HTML. Currently 'HTML5 for Web Developers' has a link 'other applicable specifications' which doesn't go anywhere: http://developers.whatwg.org/elements.html I have changed the internal labeling accordingly. Let me know if you want even more of that section exposed to the author version. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Dialogs and prompts
On Wed, 11 Apr 2012, Tab Atkins Jr. wrote: On Wed, Apr 11, 2012 at 6:28 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 11 Apr 2012, Tab Atkins Jr. wrote: Note that dialog's model is FILO, while Darin was asking for FIFO. I'm not sure I understand when one would want to queue a dialog to show after another dialog has been closed. Does anyone have an example of that in a Web app today? Some games I've played on Plus or Facebook, when you first log in for the day, show multiple dialogs for different information, one after another. For example, I might see a dialog for the daily log-in bonus, a dialog for a building that was completed while I was logged out, and a dialog summarizing the results of an attack that some made against me while I was logged out. Since all of these are managed by the same app, it's not difficult for the app to just use their own queue, having each dialog's onclose handler look in the queue and open the next one if it exists. I'm not sure if there's any examples of mashups wanting to do this sort of dialog-ordering. I haven't added anything to support this. As you say, it seems reasonable to expect the app to handle this itself. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] communicating plugin state (primarily for click-to-play)
Mozilla has been working on a click-to-play feature for plugins. The feature currently breaks a large number of sites because it interacts poorly with scripting and fallback schemes. For example, quite a bit of plugin usage doesn't involve user-visible content but rather plugin instances that exist for scripting alone. When instances aren't created as expected for script calls, the resulting exceptions cause problems. In order for click-to-play to be a viable feature we'll probably need to allow pages with complex plugin usage (i.e. scripting) to query for click-to-play state. This could be expressed via a Web IDL enum property on embed and object elements. The property could be called something like pluginState. The states might be (with apologies for the rough names): - not-plugin (object/embed is some other type like image or document) - active (plugin instance created, running) - inactive (e.g. crashed) - no-handler (e.g. missing plugin) - click-to-play (click-to-play UI is diplayed, should become active upon click) Thoughts? -- Josh Aas Mozilla Corporation
Re: [whatwg] metadata attribute for media
On Tue, Jun 12, 2012 at 7:53 AM, Ralph Giles gi...@mozilla.com wrote:
Recently, we've been considering adding a 'tags' or 'metadata' attribute
to HTML media elements in Firefox, to allow webcontent access to
metadata from the playing media resource. In particular we're interested
in tag data like creator, title, date, and so on.
My recollection is that this has been discussed a number of times in the
past, but there was never suffient motivation to support the interface.
Our particular motivation here is webapps that present a media file
library. While it's certainly possible to parse the tag data out
directly with javascript, it's more convenient if the HTML media element
does so, and the underlying platform decoder libraries usually provide
this data already.
As such I wanted to raise the issue here and get design feedback and
levels of interest for other user agents.
Here's a first idea:
partial interface HTMLMediaElement {
readonly attribute object tags;
};
Accessing media.tags provides an object with a key: value data, for example:
{
'title': 'My Movie',
'creator': 'This User',
'date': '2012-06-18',
'license': 'http://creativecommons.org/licenses/by-nc-sa/'
}
The keys may need to be filtered, since the files can contain things
like base64-encoded cover art, which makes the object prohibitively
large. The keys may need to be mapped to some standard scheme (i.e.
dublic core) since vocabularies vary from format to format.
This is nice because it's easy to access, can be simply enumerated,
and extensible. Which is helpful when if gets added the img for exif data.
Did you know that the W3C media annotations WG has specified such an
API in http://www.w3.org/TR/2011/WD-mediaont-api-1.0-2022/#api-description
. Essentially, their suggestion is to add the following IDL functions:
void getMediaProperty (DOMString[] propertyNames, PropertyCallback
successCallback, ErrorCallback errorCallback, optional DOMString
fragment, optional DOMString sourceFormat, optional DOMString
language);
void getOriginalMetadata (DOMString sourceFormat, MetadataCallback
successCallback, ErrorCallback errorCallback);
I actually think their API is too complicated and prefer your simple
approach. Returning a JSON object also allows hierarchical tags to be
returned in a structured way, which is nice. You lose the
normalisation that the W3C media ann WG has worked on across different
media resources, but that normalisation can always be done on top of
the JSON objects that your API returns.
Cheers,
Silvia.
Re: [whatwg] communicating plugin state (primarily for click-to-play)
I'm somewhat skeptical whether adding such an DOM property will actually solve the problem. I would expect that many sites that use hidden plug-ins won't update to use the new DOM property, which means you'll need a solution that doesn't involve the web site changing its code. One approach is to provide a UI affordance for playing the plug-in outside of the web page itself. Adam On Mon, Jun 11, 2012 at 5:29 PM, Josh Aas josh...@gmail.com wrote: Mozilla has been working on a click-to-play feature for plugins. The feature currently breaks a large number of sites because it interacts poorly with scripting and fallback schemes. For example, quite a bit of plugin usage doesn't involve user-visible content but rather plugin instances that exist for scripting alone. When instances aren't created as expected for script calls, the resulting exceptions cause problems. In order for click-to-play to be a viable feature we'll probably need to allow pages with complex plugin usage (i.e. scripting) to query for click-to-play state. This could be expressed via a Web IDL enum property on embed and object elements. The property could be called something like pluginState. The states might be (with apologies for the rough names): - not-plugin (object/embed is some other type like image or document) - active (plugin instance created, running) - inactive (e.g. crashed) - no-handler (e.g. missing plugin) - click-to-play (click-to-play UI is diplayed, should become active upon click) Thoughts? -- Josh Aas Mozilla Corporation
