Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM
On Sun, Mar 24, 2013 at 3:50 PM, Elliott Sprehn espr...@gmail.com wrote:
On Mon, Mar 18, 2013 at 4:48 AM, Dominic Cooney domin...@chromium.orgwrote:
...
I think the offset{Parent, Top, Left} properties should be adjusted. This
means that in the above example, b.offsetParent would be body and
b.offsetLeft would be silently adjusted to accumulate an offset of 10px
from c. I think this makes sense because typical uses of offsetParent and
offsetLeft, etc. are used to calculate the position of one element in the
coordinate space of another element, and adjusting these properties to work
this way will mean code that naively implements this use case will continue
to work.
This behavior is unfortunately slightly lossy: If the author had #c and
wanted to calculate the position of #b in the coordinate space of #c, they
will need to do some calculation to work it out via body. But presumably
a script of this nature is aware of the existence of Shadow DOM.
The question of what to do for offset* properties across a shadow
boundary when the shadow *is* traversable is a vexing one. In this case
there is no node disclosed that you could not find anyway using
.shadowRoot, etc. tree walking. From that point of view it seems acceptable
for offsetParent to return an offsetParent inside the (traversable) shadow.
This seems like correct behavior. We should walk up to find a traversable
parent and then offsetLeft/offsetTop should be relative to those.
(Note in webkit this is trivial since offsetLeft, offsetTop both call
offsetParent internally and then compute their value from it)
On the other hand, this violates the lower-boundary encapsulation of the
Shadow DOM spec. This means that pages that are using traversable shadows,
but relying on convention (ie don't use new properties like .shadowRoot)
to get the encapsulation benefits of Shadow DOM, now have to audit the
offsetParent property. It also means you need to have two ways of dealing
with offsetParent in both user agents and author scripts. So for simplicity
and consistency I think it makes sense to treat both traversable and
non-traversable shadows uniformly.
I disagree with this
Which part?
Returning an element inside Shadow DOM in an attribute of a node outside
Shadow DOM violates lower boundary encapsulation.
If offsetParent returns an element inside traversable Shadow DOM, pages
that are using traversable shadows but relying on convention to get
encapsulation benefits will have to audit uses of the offsetParent property.
If offsetParent returns an element inside traversable Shadow DOM (but not
non-traversable Shadow DOM), there are two ways of dealing with
offsetParent in the user agent.
If offsetParent returns an element inside traversable Shadow DOM (but not
non-traversable Shadow DOM), there are two ways of dealing with
offsetParent in author scripts.
It makes sense to treat both traversable and non-traversable shadows
uniformly.
since it means offsetParent returns a nonsensical value for elements in,
or projected into, traversable shadow roots as it traverses all the way up
into the main page until it's not inside a ShadowRoot anymore.
In what way is that nonsensical? The return value makes sense at the level
of abstraction the code calling innerParent is working at.
offsetParent is very useful to find your positioned parent, and you're
crippling that feature and making authors use distributedParent +
getComputedStyle() repeatedly which is considerably more expensive.
What are those use cases, except finding the position of an element
relative to another element, which I think is not excessively complicated
by what I am proposing here?
Dominic
[Bug 21386] New: Should specify how to present d-pads/triggers as buttons
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21386 Bug ID: 21386 Summary: Should specify how to present d-pads/triggers as buttons Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Gamepad Assignee: t...@mielczarek.org Reporter: t...@mielczarek.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org, scott.w3bugzi...@h4ck3r.net Currently the spec requires implementations to express the set of controls on a controller in two arrays: buttons and axes. All of the platform APIs I've used expose a set of buttons and a set of axes, so this makes sense. However, there are also frequently some controls that aren't exposed as either of those, so some internal mapping is required. For example, d-pads are frequently exposed as a POV hat (since the USB HID was written in the days of actual flight-stick like joysticks). I think we need to have some spec text that speaks to how to put these controls into the list of buttons/axes so that the list of controls are consistent across browsers (at least for the same OS+driver combination). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 21387] New: Need to spec better support for control mapping
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21387 Bug ID: 21387 Summary: Need to spec better support for control mapping Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Gamepad Assignee: t...@mielczarek.org Reporter: t...@mielczarek.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org, scott.w3bugzi...@h4ck3r.net The spec text that talks about a standard gamepad layout is a good start, but I think we need to go a little farther. We should spec a way for implementations to provide mapping data for known controllers as well as for content to fill in mappings for devices that the implementation doesn't know about. There are two things content will want to know: 1) The mapping of controls to the physical layout of the controller. For example, most modern gamepads have a left analog stick that's the natural control for movement, and a set of buttons that are naturally under the right thumb when holding the controller. Content should be able to locate those to map them to actions. 2) The naming of controls on the actual gamepad. This is important for providing feedback to a user, content will want to be able to say Press A. Scott has a JS library he wrote that provides this: https://github.com/sgraham/gamepad.js/ I've also started sketching some thoughts in data form of what a useful presentation of controller data might look like: https://github.com/luser/gamepad-data -- You are receiving this mail because: You are on the CC list for the bug.
Re: File API for Review
On Tue, Mar 19, 2013 at 5:57 PM, Arun Ranganathan a...@mozilla.com wrote: On Feb 13, 2013, at 11:37 AM, Anne van Kesteren wrote: We're not actually leaving what exactly to return open to implementors. They *must* return a 500. They *may* additionally provide a message, which is akin to console messages. No, an HTTP status message is an actual thing and exposed via XMLHttpRequest. Also, networkerror isn't really strongly defined; XMLHttpRequest uses this to throw on network errors (NetworkError), and there isn't currently a Fetch in HTML that leverages networkerrors. This is not obviously reusable here in the blob: URL context. I think it is. Network error is for whenever something goes wrong with the request. Otherwise this would give a load event rather than an error event. data: URLs use network errors too now: http://xhr.spec.whatwg.org/#data:-urls-and-http -- http://annevankesteren.nl/
[Bug 21388] New: handling of analog vs. digital buttons
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21388 Bug ID: 21388 Summary: handling of analog vs. digital buttons Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Gamepad Assignee: t...@mielczarek.org Reporter: t...@mielczarek.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org, scott.w3bugzi...@h4ck3r.net Currently the spec represents buttons as an array of double values, to handle analog buttons (like the trigger buttons on most modern gamepads). However, I'm starting to think this might not be sufficient. The Playstation 3 controller, for example, has pressure-sensitive buttons which provide both a digital (pressed/not pressed) and an analog (how hard is it being pressed) value. It seems like it would be unfortunate to lose part of that data. Should we spec button values to include both a boolean and a double value? -- You are receiving this mail because: You are on the CC list for the bug.
window.event and Event.srcElement
WebKit and IE both support these kinda disastrous APIs. Turns out more and more content starts to rely on them as with every bug you keep around for too long. Unless someone sees a plan to keep them out of the platform, I'll add them per https://www.w3.org/Bugs/Public/show_bug.cgi?id=20713 and then Firefox will follow suit. :-( -- http://annevankesteren.nl/
Re: window.event and Event.srcElement
What content depends on them, and why cater to such code? On Mon, Mar 25, 2013 at 6:44 AM, Anne van Kesteren ann...@annevk.nl wrote: WebKit and IE both support these kinda disastrous APIs. Turns out more and more content starts to rely on them as with every bug you keep around for too long. Unless someone sees a plan to keep them out of the platform, I'll add them per https://www.w3.org/Bugs/Public/show_bug.cgi?id=20713 and then Firefox will follow suit. :-( -- http://annevankesteren.nl/
Re: File API for Review
- Anne vK said: - On Tue, Mar 19, 2013 at 5:57 PM, Arun Ranganathan a...@mozilla.com wrote: On Feb 13, 2013, at 11:37 AM, Anne van Kesteren wrote: We're not actually leaving what exactly to return open to implementors. They *must* return a 500. They *may* additionally provide a message, which is akin to console messages. No, an HTTP status message is an actual thing and exposed via XMLHttpRequest. You're right; this should be defined better in the File API. Also, networkerror isn't really strongly defined; XMLHttpRequest uses this to throw on network errors (NetworkError), and there isn't currently a Fetch in HTML that leverages networkerrors. This is not obviously reusable here in the blob: URL context. I think it is. Network error is for whenever something goes wrong with the request. Otherwise this would give a load event rather than an error event. data: URLs use network errors too now: http://xhr.spec.whatwg.org/#data:-urls-and-http So just to be clear, do you think we should remove 500-style responses altogether, and *completely defer* to network error, which essentially involves throwing on expired / revoked / invalid Blob URLs? I'm ok with that if so. -- A*
Re: File API for Review
On Mon, Mar 25, 2013 at 5:45 PM, Arun Ranganathan aranganat...@mozilla.com wrote: So just to be clear, do you think we should remove 500-style responses altogether, and *completely defer* to network error, which essentially involves throwing on expired / revoked / invalid Blob URLs? I'm ok with that if so. Yeah, I would prefer if we used network error consistently throughout the platform for something went wrong with this URL rather than try to re-imagine a non-HTTP situation in terms of HTTP. Because it gives nicer to work with events and such out of the box and because it makes exposing more detailed information in the future easier. -- http://annevankesteren.nl/
Re: window.event and Event.srcElement
On 3/25/13 3:19 PM, Dave Methvin wrote: Basically, either UAs that currently implement window.event remove it or it's clearly required for web compat and hence needs to be specified so other UAs can implement it. I don't see any other sane options; do you? I'm okay with the first one. Is that a real option? That's something to ask the implementors of UAs shipping window.event, no? Apart from the mobile cases that popped up recently it hasn't been a serious problem for Gecko, apart from the author confusion. seems like the uses on SO could easily be from clueless people doing the copy-pasta on very old code. It's just clueless (read: normal) people writing code and forgetting to pass event from the handler, and it Just Working in some browsers but not others. -Boris
Re: window.event and Event.srcElement
On Mon, Mar 25, 2013 at 7:19 PM, Dave Methvin dave.meth...@gmail.com wrote: Basically, either UAs that currently implement window.event remove it or it's clearly required for web compat and hence needs to be specified so other UAs can implement it. I don't see any other sane options; do you? I'm okay with the first one. Is that a real option? I've never seen anything but old IE code intentionally use window.event, and it seems like the uses on SO could easily be from clueless people doing the copy-pasta on very old code. If you can get it removed from WebKit or even just Chrome, it might be. If that's not happening soon (e.g. indication of it happening nowish, removal within a month or so), I think we're stuck with this and we'll standardize and move on. Gecko needs at least one look it breaks in browser X too leg to stand on, really. -- http://annevankesteren.nl/
[webcomponents]: Naming the Baby
Hello folks! It seems that we've had a bit of informal feedback on the Web Components as the name for the link rel=component spec (cc'd some of the feedbackers). So... these malcontents are suggesting that Web Components is more a of a general name for all the cool things we're inventing, and link rel=component should be called something more specific, having to do with enabling modularity and facilitating component dependency management that it actually does. I recognize the problem, but I don't have a good name. And I want to keep moving forward. So let's come up with a good one soon? As outlined in http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0742.html Rules: 1) must reflect the intent and convey the meaning. 2) link type and name of the spec must match. 3) no biting. :DG
Re: window.event and Event.srcElement
Basically, either UAs that currently implement window.event remove it or it's clearly required for web compat and hence needs to be specified so other UAs can implement it. I don't see any other sane options; do you? I'm okay with the first one. Is that a real option? I've never seen anything but old IE code intentionally use window.event, and it seems like the uses on SO could easily be from clueless people doing the copy-pasta on very old code.
Re: window.event and Event.srcElement
Le 25/03/2013 20:00, Boris Zbarsky a écrit : On 3/25/13 2:47 PM, David Bruant wrote: For the latter case, a scoping trick might work. In essence, on* code could run within a scope located between the code scope and the global scope. It already does: the scope is the element, with some more complications as to what's on the scope chain above that. I wasn't aware of that, but I see it now. Step 6 of: http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-handler-content-attributes (Lexical Environment Scope stuff) We could complicate the scoping setup for event handlers even more, of course. Would any UAs actually be willing to implement that (given that e.g. Chrome doesn't even implement the current, simpler, scoping setup sanely)? Any info on why they don't implement the spec scoping rules? Is it going to be a case of de-facto standard too? For the former case, things cannot be as easy as naively inserting an intermediate scope, because the function definition is somewhere else, but maybe we can get away with an equivalent trick. Thoughts? I can't see any equivalent tricks given the scoping rules in JavaScript. Basically, either UAs that currently implement window.event remove it or it's clearly required for web compat and hence needs to be specified so other UAs can implement it. I don't see any other sane options; do you? Only an insane option. Sharing as food for thoughts: when about to call a function from an eval'ed on* attribute string, change the function's [[Scope]] to contain an extra scope with an event variable. Restore the [[Scope]] to its original value when the frame is dropped. But of course, as soon as I talked about changing [[Scope]], I definitely fell in the insane category as I warned :-/ Since that case apparently requires window.event, no need to add extra work on on* scoping, I guess. If you want specific site examples www.ocn.ne.jp (on mobile only, natch, thanks to only testing in WebKit) is the most recent one I came across. Is it the on* case? (how do you test for mobile only?) It's using event handlers, yes. You test for mobile only by loading the site in Firefox on some desktop platform and Firefox on Android and observing that the site is UA-sniffing and sending different content, and that the site sent to desktop browsers works in Firefox but the site sent to mobile browsers does not. Now I realize my question was stupid... David
Re: window.event and Event.srcElement
On 3/25/13 2:47 PM, David Bruant wrote: For the latter case, a scoping trick might work. In essence, on* code could run within a scope located between the code scope and the global scope. It already does: the scope is the element, with some more complications as to what's on the scope chain above that. We could complicate the scoping setup for event handlers even more, of course. Would any UAs actually be willing to implement that (given that e.g. Chrome doesn't even implement the current, simpler, scoping setup sanely)? For the former case, things cannot be as easy as naively inserting an intermediate scope, because the function definition is somewhere else, but maybe we can get away with an equivalent trick. Thoughts? I can't see any equivalent tricks given the scoping rules in JavaScript. Basically, either UAs that currently implement window.event remove it or it's clearly required for web compat and hence needs to be specified so other UAs can implement it. I don't see any other sane options; do you? A brief look at stackoverflow will show that this is something authors run into a lot. And that's just the ones that are bothering to test in multiple browsers. From what you've seen is it the on* case? The cases I've seen on stackoverflow are the onclick=something() and then the something uses bareword event. If you want specific site examples www.ocn.ne.jp (on mobile only, natch, thanks to only testing in WebKit) is the most recent one I came across. Is it the on* case? (how do you test for mobile only?) It's using event handlers, yes. You test for mobile only by loading the site in Firefox on some desktop platform and Firefox on Android and observing that the site is UA-sniffing and sending different content, and that the site sent to desktop browsers works in Firefox but the site sent to mobile browsers does not. -Boris
[Bug 21392] New: FileReader does not specify behavior on invalid input
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21392 Bug ID: 21392 Summary: FileReader does not specify behavior on invalid input Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: david.les...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org No behavior is specified for when a readAs method on FileReader is called with invalid input. In Chromium 26.0.1410.40, no exception is thrown and the onerror callback is not invoked. Chromium discussion thread: https://groups.google.com/a/chromium.org/d/topic/chromium-discuss/wEMo0jnlM-w/discussion Chromium behavior discussed on StackOverflow: http://stackoverflow.com/questions/628/html5-filereader-functions-not-getting-called -- You are receiving this mail because: You are on the CC list for the bug.
Re: window.event and Event.srcElement
On Mon, Mar 25, 2013 at 3:47 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Mar 25, 2013 at 7:19 PM, Dave Methvin dave.meth...@gmail.com wrote: Basically, either UAs that currently implement window.event remove it or it's clearly required for web compat and hence needs to be specified so other UAs can implement it. I don't see any other sane options; do you? I'm okay with the first one. Is that a real option? I've never seen anything but old IE code intentionally use window.event, and it seems like the uses on SO could easily be from clueless people doing the copy-pasta on very old code. If you can get it removed from WebKit or even just Chrome, it might be. I've filed an issue to see if there's any chance of getting it removed from Chrome: https://code.google.com/p/chromium/issues/detail?id=223749
[Bug 21392] FileReader does not specify behavior on invalid input
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21392 David Leston david.les...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug.
Re: window.event and Event.srcElement
On 3/25/13 4:36 PM, David Bruant wrote: We could complicate the scoping setup for event handlers even more, of course. Would any UAs actually be willing to implement that (given that e.g. Chrome doesn't even implement the current, simpler, scoping setup sanely)? Any info on why they don't implement the spec scoping rules? Because it happened to be easy in their implementation to do something with with() instead, last I checked. On the other hand, I just double-checked the bug report and they claim to have fixed it (see http://code.google.com/p/chromium/issues/detail?id=80911 and I wish I'd get mail to some sane mail address from that bug reporting system). So maybe they'd be willing to do something more complicated Is it going to be a case of de-facto standard too? I doubt it. Only an insane option. Sharing as food for thoughts: when about to call a function from an eval'ed on* attribute string, change the function's [[Scope]] to contain an extra scope with an event variable. Restore the [[Scope]] to its original value when the frame is dropped. I think that qualifies as insane, yes. ;) -Boris
