URL bugs and next steps
[resending with Anne and public-webapps. I was asked to add both and forgot. Apologizes for the omission] Things haven't been moving at fixing the bugs in the URL specification. Sam has circulated a list of issues but did not receive much feedback. I figured the best way to understand to make progress would be to have a call so we can figure out the path forward and how we're going to fix the specification and the implementations. I create a doodle at http://doodle.com/r6h68swhyq86k2r4 If you can attend, this would be helpful to make progress. Thank you in advance, Philippe
Re: Custom Elements: is=
On 6/12/2015 11:19 PM, Anne van Kesteren wrote: On Fri, Jun 12, 2015 at 7:41 PM, Léonie Watson lwat...@paciellogroup.com wrote: Is there a succinct explanation of why the is= syntax is disliked? Rather than button is=my-button/button you want my-button/my-button that just gets all the button goodness through composition/inheritance. When I first learned about web components, the biggest disappointment for me was learning that if I wanted to base my new custom element on a native element like button, I could no longer have a custom tag name. So instead of having my-button, I had to use the funky and awkward button is=my-button. I realize there are good reasons for this, but it's very disappointing because it broke my idea of custom elements. I created a pull request for this in the Drawbacks section of the summary doc. Mark
Re: URL bugs and next steps
On 06/16/2015 10:33 AM, Anne van Kesteren wrote: On Tue, Jun 16, 2015 at 4:25 PM, Philippe Le Hegaret p...@w3.org wrote: Things haven't been moving at fixing the bugs in the URL specification. Sam has circulated a list of issues but did not receive much feedback. I figured the best way to understand to make progress would be to have a call so we can figure out the path forward and how we're going to fix the specification and the implementations. I'm in the process of fixing bugs and adding tests, actually. That's great but are we getting the implementations aligned? If you can attend, this would be helpful to make progress. There's quite a bit of outstanding feedback from various vendors that can be addressed first, I think. Not sure what you expect to resolve on this call? My understanding is that implementations are still differing from the spec and we weren't getting them to move. Reasons for that are differing between the vendors. My expectation for the call would be that we understand why that's the case and see if we can get a common understanding on how we can move forward to achieve interop. For example, the idea of having a f2f meeting was floated before and more recently. I'd like to know if there is indeed such interest before asking folks to cross continents or oceans. Philippe
Re: URL bugs and next steps
On Tue, Jun 16, 2015 at 6:00 PM, Philippe Le Hegaret p...@w3.org wrote: That's great but are we getting the implementations aligned? Yes, slowly. My understanding is that implementations are still differing from the spec and we weren't getting them to move. Reasons for that are differing between the vendors. That is probably in part due to the specification having known outstanding issues and in part because changing URLs is tricky. Even small changes we made in Gecko have not been without issue. In any event, it seems somewhat premature to consider meeting over this (if that's at all warranted, it's all technical) given the state of the specification and testsuite. -- https://annevankesteren.nl/
Re: URL bugs and next steps
On Tue, Jun 16, 2015 at 4:25 PM, Philippe Le Hegaret p...@w3.org wrote: Things haven't been moving at fixing the bugs in the URL specification. Sam has circulated a list of issues but did not receive much feedback. I figured the best way to understand to make progress would be to have a call so we can figure out the path forward and how we're going to fix the specification and the implementations. I'm in the process of fixing bugs and adding tests, actually. If you can attend, this would be helpful to make progress. There's quite a bit of outstanding feedback from various vendors that can be addressed first, I think. Not sure what you expect to resolve on this call? -- https://annevankesteren.nl/
RE: URL bugs and next steps
[+Sebastian] From: Anne van Kesteren [mailto:ann...@annevk.nl] the state of the specification and testsuite. Worth pointing out, since I guess it hasn't been publicized beyond IRC: as part of the jsdom project [1] (which is a hobby of mine), Sebastian has been working on a reference implementation of the URL Standard that follows the spec fairly exactly [2]. Notably, this has allowed us to recover coverage numbers [3] for the web-platform-tests test suite. Currently they are not so great, at ~70% of the reference implementation, and thus presumably ~70% of the specification, covered by tests. We plan to work on expanding this to 100%, and to contribute those tests back to web-platform-tests as we go. This of course becomes even more powerful when combined with Sam's tooling for comparing cross-browser (and indeed cross-platform) results of the test suite. From there of course we fall back to the usual pattern, of evaluating UA compatibility vs. the spec, and fixing instances where the spec is misaligned with reality. But with 100% coverage we should be in a better starting position. [1]: https://github.com/tmpvar/jsdom [2]: https://github.com/jsdom/whatwg-url [3]: https://github.com/jsdom/whatwg-url/issues/8#issuecomment-109705181
Re: [Clipboard] Web API for clipboard changes.
My pleasure. Here is the link to a more detailed design doc. Please feel free to comment. https://docs.google.com/document/d/1z1-IW4-Y0NQEAQqzdPdbn5yz0jX4pvfugHU0_L4iIog On Tue, Jun 16, 2015 at 4:11 AM Arthur Barstow art.bars...@gmail.com wrote: On 6/16/15 6:58 AM, James M. Greene wrote: Please share it with the rest of the group. Thanks! Agree. Kelvin - please do. -Thanks, AB
[Bug 28823] New: Course of action even after Event Source retry failure.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28823
Bug ID: 28823
Summary: Course of action even after Event Source retry
failure.
Product: WebAppsWG
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Server-Sent Events (editor: Ian Hickson)
Assignee: i...@hixie.ch
Reporter: hiremathprasha...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
As per the spec
https://html.spec.whatwg.org/multipage/comms.html#processing-model-10 , when
EventSource fail to establish the connection first time,
it should retry to connect to given URL after time specified in the retry
field/UA default value. But Spec doesn't tell specifically what should be
done if retry attempt fails.
And since this retry field is in seconds, Browser should try only once or is
it retry interval(i.e browser should keep on retrying after every retry
seconds).
For eg:
var evtSource = new EventSource(http://www.test.not;)
evtSource.onerror = function() {
console.log(evtSource.readyState);
}
In above case Browsers behavior is :
Firefox retries only once and if it fails to establish the connection to given
URL it closes the connection.
But Blinks keep on retrying for given URL with readyState set to CONNECTING.
Can spec be more specific on this i.e what should be done if it fails to
connect even after retry?
--
You are receiving this mail because:
You are on the CC list for the bug.
Re: [Clipboard] Web API for clipboard changes.
Please share it with the rest of the group. Thanks! Sincerely, James M. Greene On Jun 15, 2015 5:48 PM, Kelvin Poon kelv...@google.com wrote: Thank you for your interest Arthur. I have drafted up a more detailed implementation doc and shared it with you and Hallvord. Please feel free to take a look and comment. Kelvin On Thu, Jun 11, 2015 at 3:57 AM Arthur Barstow art.bars...@gmail.com wrote: On 6/2/15 4:05 PM, Kelvin Poon wrote: Hi public-webapps We are exploring a new web API for content to be notified of clipboard changes and would like to discuss it here. The problem For certain classes of web apps, it is necessary to determine when new clipboard contents have been set, e.g. in order to fetch and display them, to update context menus, or synchronize the content with another application or device. The problem is that the web standard currently provides no explicit notifications when new content is copied from another application to the clipboard. As a result, these web apps typically re-fetch the clipboard every time they regain focus, and only act on the contents if they have changed since last time (e.g. passing it to a remote system, updating context menu, etc). This polling mechanism is generally inefficient, especially when the clipboard contains a large image file. We currently have interest from Citrix and Chrome Remote Experience teams in improving Chrome's clipboard support. The proposal Google propose to update the W3C Clipboard API and events specification http://www.w3.org/TR/clipboard-apis/with an onClipboardChangedevent on the document object. The user agent should only signal the event if 1. a frame re-gains focus AND 2. the clipboard has changed since it last had focus. In addition, the user agent should not signal clipboard change events while a frame has focus. This will relieve the web app from the burden of filtering out notifications in response to clipboard changes generated by the app itself. We think this new API will avoid fetching large clipboard content repeatedly and unnecessarily for clipboard changes. Does the community think this API would be useful? Hallvord, All - do you have any feedback for Kevlin? We can go into more details and work on a detailed design together if the community is interested. Kelvin, if there is a resource that includes details, please let us know. (I suppose another option is a Pull Request but it might make sense to first wait for some feedback from the group.) -Thanks, ArtB
Re: [Clipboard] Web API for clipboard changes.
On 6/16/15 6:58 AM, James M. Greene wrote: Please share it with the rest of the group. Thanks! Agree. Kelvin - please do. -Thanks, AB
