Re: Screen Orientation Feedback
If only someone had pointed out these problems earlier ;)
On Aug 5, 2014 11:17 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
I think the current interaction between the screen orientation and
device orientation specs is really unfortunate.
Any time that you use the device orientation in order to render
something on screen, you have to do non-obvious math in order to get
coordinates which are usable. Same thing if you want to use the device
orientation events as input for objects which are rendered on screen.
I would argue that these are the by far most common use cases for
I agree that the main problem here is that the deviceorientation spec
defined that their events should be relative to the device rather than
to the screen. However we can still fix the problem by simply adding
partial interface DeviceOrientationEvent
{
readonly attribute double? screenAlpha;
readonly attribute double? screenBeta;
readonly attribute double? screenGamma;
}
No new events needs to be defined.
I guess we can argue that this should be added to the
DeviceOrientation spec, but that seems unlikely to happen in practice
anytime soon. I think we would do developers a disservice by blaming
procedural issues rather than trying to solve the problem.
I think mozilla would be happy to implement such an addition to the
DeviceOrientation event (I'm currently checking to make sure). Are
there other UAs that have opinions (positive or negative) to such an
addition?
/ Jonas
Re: Screen Orientation Feedback
Yup. Well.. sounds like people, including you, pointed out these
problems. No idea why it was ignored since I wasn't there.
/ Jonas
On Wed, Aug 13, 2014 at 11:28 PM, Lars Knudsen lar...@gmail.com wrote:
If only someone had pointed out these problems earlier ;)
On Aug 5, 2014 11:17 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
I think the current interaction between the screen orientation and
device orientation specs is really unfortunate.
Any time that you use the device orientation in order to render
something on screen, you have to do non-obvious math in order to get
coordinates which are usable. Same thing if you want to use the device
orientation events as input for objects which are rendered on screen.
I would argue that these are the by far most common use cases for
I agree that the main problem here is that the deviceorientation spec
defined that their events should be relative to the device rather than
to the screen. However we can still fix the problem by simply adding
partial interface DeviceOrientationEvent
{
readonly attribute double? screenAlpha;
readonly attribute double? screenBeta;
readonly attribute double? screenGamma;
}
No new events needs to be defined.
I guess we can argue that this should be added to the
DeviceOrientation spec, but that seems unlikely to happen in practice
anytime soon. I think we would do developers a disservice by blaming
procedural issues rather than trying to solve the problem.
I think mozilla would be happy to implement such an addition to the
DeviceOrientation event (I'm currently checking to make sure). Are
there other UAs that have opinions (positive or negative) to such an
addition?
/ Jonas
Re: [Streams API] Add load-using-streams functionality to XHR or only to Fetch API?
On Thu, Aug 14, 2014 at 6:20 AM, Takeshi Yoshino tyosh...@google.com wrote: We're implementing Streams API and integration of it and XHR experimentally in Blink. I think the question is not so much how far along XMLHttpRequest and fetch() are, but how far along streams is. E.g. a chat I had yesterday http://krijnhoetmer.nl/irc-logs/whatwg/20140813#l-592 suggests there's still many things to sort through. -- http://annevankesteren.nl/
Re: [Streams API] Add load-using-streams functionality to XHR or only to Fetch API?
Streams API itself still has many issues, right. We'd like to continue prototyping in Blink anyway to provide feedback to the spec as browser developer's point of view, but if we're sure that we won't add it to XHR, we want to stop the work on XHR (both spec and impl) at some early stage after figuring out very basic issues and focus on the Fetch. Takeshi On Thu, Aug 14, 2014 at 4:03 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Aug 14, 2014 at 6:20 AM, Takeshi Yoshino tyosh...@google.com wrote: We're implementing Streams API and integration of it and XHR experimentally in Blink. I think the question is not so much how far along XMLHttpRequest and fetch() are, but how far along streams is. E.g. a chat I had yesterday http://krijnhoetmer.nl/irc-logs/whatwg/20140813#l-592 suggests there's still many things to sort through. -- http://annevankesteren.nl/
Re: RfC: pre-LC version of Screen Orientation; deadline August 18
Le lundi 04 août 2014 à 08:19 -0400, Arthur Barstow a écrit : Marcos and Mounir, the Editors of WebApps' Screen Orientation API, consider their spec feature complete with only a few minor [Bugs] open. As such, we seek wide review on their pre-LC version: https://w3c.github.io/screen-orientation/ If you have any comments, please send them to public-webapps by August 18 (and if you and/or your group need more time, please let me know.) We also welcome data about silent reviews, f.ex. I reviewed section N.N and have no comments. A few comments: * Promiseundefined should be Promisevoid from my reading of WebIDL * in the last paragraph of 5.1, the phrase the screen as it is drawn was unclear to me until I read the lock orientation algorithm where the phrase the viewport is drawn made it clearer; maybe the two can be alined * shouldn't the apply an orientation lock algorithm make reference to the event firing? I was having trouble understanding steps 8.2 and 8.3 in the former until I arrived to the latter * while I understand there is ongoing discussion on alignments with DeviceOrientation, I'm less clear there is work to ensure consistency with css-device-adapt; in particular, it seems like it would be useful to understand how the two approaches work together when use simultaneously HTH, Dom
Re: [Streams API] Add load-using-streams functionality to XHR or only to Fetch API?
On Thu, Aug 14, 2014 at 9:19 AM, Takeshi Yoshino tyosh...@google.com wrote: We'd like to continue prototyping in Blink anyway to provide feedback to the spec as browser developer's point of view, but if we're sure that we won't add it to XHR, we want to stop the work on XHR (both spec and impl) at some early stage after figuring out very basic issues and focus on the Fetch. I recommend putting all your energy on Fetch and Streams then. We can still add features to XMLHttpRequest if there's compelling reasons (e.g. we hit deployment issues with fetch()), but we should not put our focus there. -- http://annevankesteren.nl/
Re: [Streams API] Add load-using-streams functionality to XHR or only to Fetch API?
On Thu, Aug 14, 2014 at 4:29 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Aug 14, 2014 at 9:19 AM, Takeshi Yoshino tyosh...@google.com wrote: We'd like to continue prototyping in Blink anyway to provide feedback to the spec as browser developer's point of view, but if we're sure that we won't add it to XHR, we want to stop the work on XHR (both spec and impl) at some early stage after figuring out very basic issues and focus on the Fetch. I recommend putting all your energy on Fetch and Streams then. We can still add features to XMLHttpRequest if there's compelling reasons (e.g. we hit deployment issues with fetch()), but we should not put our focus there. Thanks. I'd like to hear opinions from others too. BTW, Anne, as the fetch() is planned to be available in non-ServiceWorker scopes, could you please do either of: a) discuss issues about fetch() at public-webapps@ b) add a link to https://github.com/slightlyoff/ServiceWorker/labels/fetch in http://fetch.spec.whatwg.org/ as well as the link to public-webapps@ I guess you don't want to do (a). (b) is fine. Then, readers of http://fetch.spec.whatwg.org/ can easily know that discussions about fetch() are happening at the ServiceWorker issue tracker even if he/she is not familiar with ServiceWorker, and join it if want.
[Bug 26580] New: Not enough element in for an element
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26580 Bug ID: 26580 Summary: Not enough element in for an element Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Fullscreen Assignee: ann...@annevk.nl Reporter: phil...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://fullscreen.spec.whatwg.org/#fullscreen-element-ready-check All other places say If an element element in and similar. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [Streams API] Add load-using-streams functionality to XHR or only to Fetch API?
On Thu, Aug 14, 2014 at 9:39 AM, Takeshi Yoshino tyosh...@google.com wrote: I guess you don't want to do (a). (b) is fine. Then, readers of http://fetch.spec.whatwg.org/ can easily know that discussions about fetch() are happening at the ServiceWorker issue tracker even if he/she is not familiar with ServiceWorker, and join it if want. That makes sense, done. I'm not sure why I would want to encourage readers to post about Fetch on yet another mailing list so I have not added this mailing list. -- http://annevankesteren.nl/
[Bug 26583] New: [Custom]: Add the possibility to extend the custom element
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26583
Bug ID: 26583
Summary: [Custom]: Add the possibility to extend the custom
element
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: Component Model
Assignee: dglaz...@chromium.org
Reporter: lohentertainm...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Example:
var Modal = document.registerElement('x-modal', {
prototype: Object.create(HTMLElement, {/* modal generic prototype */})
})
var WebcamModal = document.registerElement('x-webcam', {
extends: 'x-modal',
prototype: Object.create(Modal, {
/* webcam modal specific prototype */
show: {
value: function() {
Modal.prototype.show.call(this)
// run webcam
}
}
})
})
x-modal/x-modal
x-modal is=webcam/x-modal
And will be cool if will be possible to have a non-dashed name of extend name
(is=webcam instead is=x-webcam).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug 26580] Not enough element in for an element
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26580 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Anne ann...@annevk.nl --- https://github.com/whatwg/fullscreen/commit/28cb149938a7c58a232595ace523e5d2b934d9b2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26587] New: Element removal order is undefined in fully exit fullscreen
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26587 Bug ID: 26587 Summary: Element removal order is undefined in fully exit fullscreen Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Fullscreen Assignee: ann...@annevk.nl Reporter: phil...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://fullscreen.spec.whatwg.org/#model says: 3. Remove elements from doc's fullscreen element stack until there is one element left. This doesn't say which elements to remove. WebKit/Blink currently removes all elements except the top element. The spec should do, because: 1. It doesn't cause document.fullscreenElement to change until the fullscreenchange event is fired. 2. If the top element was an iframe (no other element could be), the cross-document chain of fullscreen elements remains intact. Anything else can temporarily leave you with a gap in the chain. Having simple unbroken chains seems like a good invariant, then the implementation can assert it whenever pushing or popping to a fullscreen element stack and maybe prevent some bugs. -- You are receiving this mail because: You are on the CC list for the bug.
Re: RfC: pre-LC version of Screen Orientation; deadline August 18
On August 14, 2014 at 3:23:23 AM, Dominique Hazael-Massieux (d...@w3.org) wrote: HTH, It does! thank you. I've filed a bug for each on GH. https://github.com/w3c/screen-orientation/issues/ Hope to fix 'em up soon!
