Re: Busy indicator API
On 06/07/2015 03:22 , Mike Connor wrote: Does it need to be an API, or would dispatching an event be sufficient? Something like busy and idle events would be easy to send from JS, and UAs would be free to honour or ignore based on context. On the face of it it's certainly useful: writing your own busy indicator is one of the first things you get to do when producing a Web application. If we can get this built-in, it's a win. I'm slightly worried about the possibility of actually getting it right, though. It's not uncommon for Web app above a certain level of complexity to be doing more than one thing at once. If I'm conducting two operations, and have therefore dispatched two busy events (or whatever API equivalent) I would probably expect there to have to be two idle events before the UI state returns to idle (i.e. there's a busy counter). This could possibly seem acceptable, but what happens when the app transitions to a different internal page? Today wiping the DOM is enough to remove the spinners, so no one bothers maintaining state for this, but with the API you'd have to. History.pushState() could wipe the busy flag, but that might be the wrong thing to do if a busy part of your UI stays there. Also: what does the busy indicator do in fullscreen? I'm not trying to shoot this down, just pointing at potential pitfalls to avoid adding a feature that will just largely get ignored except perhaps in the simplest cases. -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Linked Data and a new Browser API event
On 04/06/2015 12:34 , Benjamin Francis wrote: On 4 June 2015 at 03:27, Michael[tm] Smith m...@w3.org wrote As came up in some off-list discussion with Anne, is the “Manifest for a web application” spec at https://w3c.github.io/manifest/ not relevant here? (Nothing to reverse engineer, since it has an actual spec—with defined processing requirements—and at least one other browser-engine project is also contributing to it and implementing it.) Yes, we already support W3C web app manfiests in our prototype, and it's a key part of the implementation. A manifest provides metadata for a website as a whole, whereas Linked Data provides metadata to a particular web page. When you pin a whole site we use the manifest (and fall back to other metadata when not available), and when you pin a page we use Linked Data (and fall back to other metadata when not available). Pinning based on Linked Data also makes a lot of sense because it's already massively deployed (to millions of domains), whereas manifest isn't. To reinforce Benjamin's point imagine a flight booking site. The manifest would get you to pin the site as an app with which you could book flights in the future; LD would allow you to pin a ticket you've bought in such a way that it displays just the essential time/location information you want to see at a glance. The use cases are totally different. -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: longdesc
On 07/01/2015 13:23 , JW Clements wrote: If View Description is the same as View Image Info then be advised that I use this fairly frequently. Therefore the claim that there's ZERO clicks is extremely inaccurate. No, it's not. View Image Info is always present for images, View Description is only afforded if there is a longdesc attribute. Honestly, I'm not sure how many people know that who aren't either on this list or involved in standards somehow. -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: HTML5
Hi David, On 20/09/2014 02:23 , L. David Baron wrote: One of the open issues being raised in this review is the status of the spec's normative reference to the URL specification. The specification currently references http://www.w3.org/TR/url/ ; it might be possible for us to suggest that it instead reference either http://url.spec.whatwg.org/ or https://whatwg.org/specs/url/2014-07-30/ (although if we did so, it would probably be best for somebody to raise the issue elsewhere in addition to it just being part of our review). I think the world would be better place if we could pacify the WHATWG/W3C relationship. Of course, I realise that this can be a relatively ironic statement to make in the context of a vote on publishing W3C HTML, but I am making it nevertheless because I believe that baby steps can help get us there. I was hoping that we could simply reference WHATWG URL as a (small) token of good faith and normalisation, adding a small cobblestone to pave the way to cooperation. Sadly, this has proven contentious. But as with all polarised discussions, it is hard to tell if there is genuine opposition or just a small group of angry agitators. Therefore, if you believe that making such a reference would be a good step forward, I would encourage you to make a comment in that direction (note that we can reference both the latest version and the snapshot). You don't need to raise the issue elsewhere, it has already been raised, burnt, buried, and zombified a few times over. Mentioning it in your review (as several others have done already) would already carry weight (and wouldn't cost you the trouble that entering the fray otherwise might). Thanks! -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: HTML5
On 20/09/2014 11:20 , Anne van Kesteren wrote: On Sat, Sep 20, 2014 at 11:03 AM, Karl Dubost kdub...@mozilla.com wrote: My biggest issue with HTML5 spec is that it is too big to be meaningfully implementable and/or testable. Yeah the W3C crowd keeps saying that, yet hasn't invested any meaningful effort into creating modules. I'm not sure who the W3C crowd are (it sounds like an arbitrary moniker designed to encourage us vs them thinking) but the only meaningful investment into creating modules that I know of is starting pretty much now. So I'm relatively certain that we don't have the hindsight to evaluate it much. Unless you're thinking of XHTML Modularisation. But that would be like blaming Mozilla for LAYER: not entirely fair :) -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: HTML5
Hi Kyle, On 20/09/2014 17:26 , Kyle Huey wrote: On Sat, Sep 20, 2014 at 2:41 AM, Karl Dubost kdub...@mozilla.com wrote: Le 20 sept. 2014 à 18:20, Anne van Kesteren ann...@annevk.nl a écrit : Yeah the W3C crowd keeps saying that Here the W3C crowd. We (Mozilla) have a conflict ;) http://www.w3.org/2000/09/dbwg/details?group=40318public=1order=org#_MozillaFoundation I categorically reject this idea that all W3C and/or WG members have equal responsibility for any action the W3C and/or WG takes. I agree with your general sentiment but I would qualify it. If you are participating *and* have made a bona fide attempt at fixing the issues you see with the group then you can certainly distance yourself from the group's actions. But if you haven't tried to change things constructively, complaining about it elsewhere doesn't seem all that helpful. -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: HTML5
Hi James, On 21/09/2014 15:00 , James Graham wrote: Obviously I agree that good testing of implementations is key to interoperability. I also agree that we should encourage vendors to create and run shared tests for the web technologies that we implement. I am substantially less convinced that tying these tests to the spec lifecycle makes sense. The W3C Process encourages people to think of interoperability as a binary condition; either implementations are interoperable or they are not. This leads to ideas like the CSS WG's rule that two implementations must pass every test. On the face of it this may appear eminently sensible. However the incentives for testing under such a regime are not well aligned with the goal of finding bugs in implementations; in essence people are encouraged to write as many tests as are needed to satisfy the letter of the rules but to make them all as shallow and unlikely to find bugs as possible to avoid causing unwanted holdups in the specification process. I would much prefer to have a testsuite written by people making a genuine effort to find errors in implementations even if the result is that no one passes every single test. I couldn't agree more. In fact, part of my hope when we were setting up Web Platform Tests was that having a continuously updated test suite instead of a bunch of hasty rushes to get enough coverage of a spec for it to ship would help people realise that specs should be handled in a similar manner too. I can't say it has brought about a revolution yet, but it has certainly helped change minds. It's hard to argue against a continuously updated test suite. It's hard to imagine that such an animal wouldn't find spec bugs in addition to implementation bugs. It's hard to justify knowing about bugs and not shipping an update. Things tend to make their own way from there. My concrete suggestion is that we, as an organisation, work to achieve parity between the tests we require to ship our own code and those we release in ways that can be used to support a spec and, more importantly, those that can be used verify that different implementations match up. In practice this means not writing tests in Mozilla-specific formats, and making sure that we have a way to upstream tests that we've written. Making this process as low-overhead as possible is something that I'm working on. A very strong +1. However if we as an organisation really care about testing core platform features which already have an implementation in gecko, one way to achieve that would be to give someone working on Servo the explicit job of creating testsuites for the big-ticket features they implement as they implement them. That would certainly be helpful. In addition, I would note that while a shared test suite benefits everyone. At this point Mozilla has proven to be a huge contributor to the WPT project (with Opera's massive release of tests another notable help) but we have not yet seen comparable commitments from the other browser vendors. So any help you can provide in convincing people to contribute is very welcome. Maybe it all doesn't matter too much as long as implementors keep reading the whatwg spec instead. In terms of HTML at the W3C it's pretty clear that they've dropped the ball, and haven't even realised it yet. There was a thread started five days ago about the future of HTML after this release and so far it has gained exactly no responses from implementors. The WG turned into an unproductive, bureaucratic, nightmare and succeeded in driving out their core constituency leaving the remaining participants to debate topics of little consequence. If we were to complain about the lack of testing for HTML, we would be told in no uncertain terms that we (or at least the WG) had agreed to the Plan 2014 which explicitly chose to forego testing in certain areas, and specification accuracy, in favour of shipping at a defined time. This idea of shipping on a date-based schedule isn't actually obviously bad, as long as you set the expectations correctly, which is something the W3C will get wrong. It would indeed be nice if W3C would embrace this fully and move to a WHATWG-style model with no eratta but a spec kept continually up-to-date in the areas where there is a need for change, and absolute rigidity in the areas where reality dictates that change is impossible. However moving them there is a longer term goal that seems to be met with extreme resistance from people who haven't fully grasped how shipping a web browser works. Well, my plan is to move pretty much there in a matter of months. For me that's the biggest value in putting HTML5 out of the door: it frees up a lot of flexibility (and energy) in how things are done from now on. Constructive input is certainly welcome :) -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https
Re: W3C Proposed Recommendation: HTML5
On 21/09/2014 00:29 , Karl Dubost wrote: Le 21 sept. 2014 à 03:23, Boris Zbarsky bzbar...@mit.edu a écrit : The important part to me about implementations is that implementations shouldn't follow the known-bogus parts of the HTML5 REC once said bogosity if fixed in the WHATWG spec and HTML5.1 (with the former more likely to happen sooner). Maybe it's an actionable feedback. To propose a notes for implementers section saying something along: (text can be improved, better suggestions, etc.) This published recommendation has switched to a non maintenance mode. It may contain mistakes or things may have changed since the publication. Please make sure to check the most up to date document BLAH [with link to the whatwg spec] before implementing any features. Would that partly solve your concerns? I am currently thinking about some text that would include something like the above and the goal of which is to indicate how a given document ought to be used. At the heart of the idea is the notion that different constituencies may have different needs, some needing a (relatively) stable snapshot while others need a (relatively) up to date document. Additionally, we can't presume to know who would need which when. The usual distinction made between lawyers and implementers is overly simplistic (e.g. a lawyer could need either, implementers of some specific tools might need a snapshot for some reason). Instead we can try something crazy new and trust readers not be radically dumb by providing them with the information they need to make up their minds. This is a quick draft of the idea, it's very much open to evolution. ## Usage of this Document Web standards are available in two flavours: snapshots, which are immutable versions made at a point in time and guaranteed never to change, and live versions which capture as much as possible the latest state of the technology and are intended to be continuously maintained and kept up to date. Which version you should rely on and reference depends on your needs. If your specific situation demands am unchanging document, understanding that it is likely to contain defects that have been addressed elsewhere, then you will want to use the snapshot. If however you require a document that is as up-to-date as possible, then the live version is for you. If in doubt, we recommend you rely on the live document. This document is a snapshot document. For the live version, please visit [link]. One suggestion in this space is to also drop the style sheet from snapshots to make it clear that they're not nice things to use (as in https://whatwg.org/specs/url/2014-07-30/). I understand the thinking but I am concerned that it could introduce issues (in some cases losing information). I do agree however that the styling of snapshots and live documents are altogether too often too close to one another. Workable suggestions in this space are very welcome (I'll be trying some stuff in my corner, which I'll make available soon). -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: HTML5
On 22/09/2014 14:40 , Henri Sivonen wrote: On Mon, Sep 22, 2014 at 2:41 PM, Robin Berjon ro...@w3.org wrote: I was hoping that we could simply reference WHATWG URL as a (small) token of good faith and normalisation, adding a small cobblestone to pave the way to cooperation. If that was the goal, changing the Goals section of the spec to cast doubts about whether the direction the W3C envisions for the spec is consistent with the goal that are the actual reason for the spec's existence was a rather bad way to go about it. For context, you are talking about changing the Goals section of the URL spec, right? That part is largely out of my hands, but it is certainly something that referencing the WHATWG specification directly would have solved directly. As for whether it's a small-group concern, I wish there was less confrontational rhetoric, so I don't want to show up to make a group of angry agitators larger Actually I was talking about the small group of people who *object* to referencing a WHATWG specification. but I think there should be a spec that defines how URLs work in a way that's well-defined realistically implementable in browser engines (and in other software that wishes to work with content that's written mainly to be consumed by browser engines). Considering how long the IETF has had to deliver such a spec but hasn't delivered and how practically infeasible it seems to get the kind of work that Anne is doing done within the framework of an IETF WG, I think Anne's spec should be given a chance without casting doubts from the start about it getting changed over motivations other that Web compatibility in a later revision. Well yes, that's pretty much my point. -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Will we ever get element queries in browsers?
On 23/05/2014 15:23 , Chris Mills wrote: I was just thinking about element queries[1] again, recalling all the discussion on it from some time ago. Has thinking on this advanced at all in more recent times? Do you think we’ll ever see element queries native in browsers? There clearly is demand and people are thinking about the problem, so if it's solvable in an acceptable way I don't why it wouldn't eventually work out. http://discourse.specifiction.org/t/element-queries/26 -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Timed Text Working Group (WebVTT and TTML)
On 22/03/2014 07:30 , L. David Baron wrote: I'm inclined to think that it's not worth putting up a massive fight over the group's organization here, which I think is what it would take to change this plan. I think I'd rather focus the bandwidth of our communication with W3C management on other issues. I haven't tracked this group very closely, but my understanding is that the idea really is to operate as two subgroups, with the common venue mostly useful to ensure maximal IP coverage and workable conversion to WebVTT for people who have a large stake in TTML. (On the other hand, I think it is worth listening to the real needs of producers who have large libraries of captions that they'd like to convert to WebVTT.) It really is. There is a *lot* of high quality TTML content that currently isn't available on the Web. Making sure that it can be liberated would be very useful. I suppose I should at least send late feedback over the decision process, and perhaps also that there should be more mention of the working group operating as two subgroups than Teleconferences: Weekly for TTML, and as needed for WebVTT. I think you'll be better off speaking directly to the group's chairs and team contacts than bringing further feedback into WBS. -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should we disable autoplay feature of HTMLMediaElement on mobile?
On 08/12/2013 15:03 , Robert Kaiser wrote: That said, I think we should think about how we can enable more user control of such features. If I open media tabs in the background, I probably don't want them to autoplay at all. I think that's the key part. Is there any common usage scenario in which autoplay on an inactive tab is not a nuisance? Who hasn't reopened Firefox with a bunch of tabs loading and then had to scramble through them to find which ones were making noise? I reckon that making autoplay depend on page visibility would be enough to remove the need for user control here, so as to keep things simple. IMHO the only question is whether that would break content and possibly require a spec change. I suspect not for content; on the spec side it already says that UAs don't have to support it. -- Robin Berjon - http://berjon.com/ - @robinberjon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
