| 00:02 | <Hixie> | zcorpan: nobody is suggesting a single API for all types of devices |
| 00:03 | <Hixie> | zcorpan: <device> doesn't have an API for the devices, it just returns the APIs, which are device-specific |
| 00:04 | <zcorpan> | ah, so a bit like NPAPI? |
| 00:04 | <Hixie> | in what way? |
| 00:05 | <Hixie> | more like a bit like how different events have different interfaces |
| 00:05 | <zcorpan> | <object> implements a plugin-specific interface |
| 00:05 | <Hixie> | or how createElement() returns different objects based on its input |
| 00:06 | <Hixie> | except for <device>, the input is from the user (based on a filter given by the author -- like <input type=file> and accept=""), and the output is an object, not a DOM Node |
| 00:06 | <Hixie> | <device> doesn't implement the interface |
| 00:07 | <Hixie> | it returns an object that implements the interface |
| 00:07 | <zcorpan> | ok |
| 00:16 | <roc> | I agree with maciej, <device> seems too overloaded |
| 00:16 | AryehGregor | also is skeptical |
| 00:16 | <roc> | it's totally unclear what it means to "implement <device>" |
| 00:17 | <roc> | if a device is going to have its own Web-standard API, why shouldn't it have its own element? |
| 00:17 | <MikeSmith> | it' seems pretty similar to canvas in that it's thin markup hook to hang APIs on |
| 00:18 | <MikeSmith> | some would say it doesn't need any element/markup at all, can just all be done with script |
| 00:18 | <roc> | I'm not too thrilled by the canvas getContext() approach either, but at least 2D and 3D <canvas>es have a lot of properties in common |
| 00:18 | <othermaciej> | aye |
| 00:18 | <MikeSmith> | true |
| 00:21 | <doublec> | I agree about <device> being overloaded |
| 00:21 | <doublec> | I often see discussions about some wanted feature in HTML and someone saying "hey, isn't device supposed to do that" |
| 00:21 | <doublec> | from video conferencing to serial port communication |
| 00:23 | <Hixie> | MikeSmith: <device> and <canvas> are very similar, yes |
| 00:24 | <Hixie> | doublec: video conferencing and serial port communication are the two things in the spec. :-) |
| 00:25 | <othermaciej> | <device>: it's a floor wax *and* a desert topping |
| 00:26 | <Hixie> | i really don't understand what is overloaded about it |
| 00:26 | <Hixie> | it's like <select> |
| 00:26 | <Hixie> | is <select> overloaded because it can be used for pizza toppings and airline destinations? |
| 00:27 | <MikeSmith> | fwiw, https://lists.webkit.org/pipermail/webkit-dev/2011-January/015822.html seems to indicate chromium engineer has already written a device implementation |
| 00:27 | <othermaciej> | I think that is too high a level of abstraction for users and for typical programmers |
| 00:27 | <MikeSmith> | input element is overloaded for sure |
| 00:28 | <Hixie> | othermaciej: there's no abstraction at all. it's concrete. <device type=media> gives a popup of media sources, user picks one, UA fires an event with an object implementing a media stream API. |
| 00:28 | <roc> | the input element was a mistake |
| 00:28 | <roc> | and <device> repeates the problems with a mutable type attribute |
| 00:28 | <Hixie> | othermaciej: <device type=rs232> gives a popup of RS232 devices, user picks one, UA fires an event with an object implement an RS232 API |
| 00:29 | <Hixie> | <input> is overloaded because it does many things |
| 00:29 | <Hixie> | <device> does one thing |
| 00:29 | <othermaciej> | Hixie: to the user, the feature is "use my camera" or "use whatever is connected to my serial port", not "pick a device" |
| 00:29 | <jamesr_> | sounds more like <device> does zero things |
| 00:29 | <roc> | Hixie: that's subjective. <input> does one thing: it accepts user input |
| 00:29 | <Hixie> | roc: but it has many different UIs. <device> has one. |
| 00:29 | <othermaciej> | also, it will be very common to have exactly one microphone or exactly one camera |
| 00:30 | <othermaciej> | at which point a popup is a poor UI |
| 00:30 | <Hixie> | roc: and <input> has many different APIs, <device> has one. |
| 00:30 | <roc> | I don't understand how <device> can have one UI |
| 00:30 | <Hixie> | I don't understand how it could have more than one :-) |
| 00:30 | <roc> | the browser is going to offer the same UI for picking cameras, microphones, RS232 ports, and connection peers? |
| 00:30 | <othermaciej> | a popup menu that says "Front-facing camera" and "Rear-facing camera" in a menu would also be terrible UI for the more common devices with two cameras |
| 00:31 | <Hixie> | othermaciej: what would good secure UI be? |
| 00:31 | <roc> | or is connection peer totally unrelated? I don't understand "This section will be moved to a more appropriate location in due course; it is here currently to keep it near the device element to allow reviewers to look at it." |
| 00:31 | <othermaciej> | I don't know, good secure UI is hard |
| 00:31 | <Hixie> | connectionpeer is as related to <device> as XHR is to <input type=file> |
| 00:32 | <Hixie> | othermaciej: well, this is what we have for now. I'm open to improvements if people can suggest any. But "no" isn't an improvement. |
| 00:32 | <othermaciej> | I would probably show previews of what the two cameras are showing and have a record button or something |
| 00:32 | <othermaciej> | and probably have a persistent record indicator in the UI |
| 00:33 | <othermaciej> | that scales reasonably to either one or two cameras |
| 00:33 | <othermaciej> | but I don't think it scales to serial ports |
| 00:33 | <Hixie> | i'll have to draw up some mockups |
| 00:35 | <othermaciej> | tying this to an element is only really helpful if something useful shows up in page by default (actual video output of camera? soundwave of audio input for mic-only?), or if requiring a real user click is somehow part of the security value |
| 00:35 | <Hixie> | an icon representing the device, and yes, respectively |
| 00:35 | <roc> | I don't think requiring a real user click has real security value |
| 00:35 | <othermaciej> | given clickjacking type techniques, I'm not even sure an element is a helpful tool to ensure a real user click |
| 00:36 | <Hixie> | how do we ensure the user confirms which device he wants without popping up a separate window after a user click? |
| 00:36 | <Hixie> | if we have better ideas i'm all for it |
| 00:37 | <roc> | in Firefox we have standard UI for confirming geolocation requests, offline storage, and other things |
| 00:37 | <roc> | I think we'd want to hook into that |
| 00:37 | <othermaciej> | I think it might be more useful for us to implement a UI we think is good by way of a proposal |
| 00:37 | <Hixie> | roc: the infobar? i thought it was established that that was a disaster |
| 00:38 | <othermaciej> | I'm not sure an icon representing a camera is a super useful part of video conferencing UI |
| 00:38 | <roc> | it's changed in Firefox 4 |
| 00:38 | <roc> | I don't know if the new design is considered a disaster |
| 00:38 | <othermaciej> | a popup might be useful for choosing purposes, but then you have to think about how it works when there is only one thing to choose, and at that point I am not sure "real user click" is a useful security feature |
| 00:43 | <Hixie> | roc: is there a test page that brings them up? i tried google maps but nothing came up when i got it to ask for the location |
| 00:43 | <Hixie> | which is fine ui but not very secure :-) |
| 00:43 | <roc> | did it use your location or not? |
| 00:43 | <roc> | perhaps you set it to always-allow in the past |
| 00:43 | <Hixie> | it found where i was, dunno if it was based on IP or something better |
| 00:43 | <roc> | bring up page-info and go to the permissions pane |
| 00:44 | <jamesr_> | a web page can often get your location quite accurately without any participation from the browser |
| 00:44 | <roc> | select always-ask |
| 00:44 | <doublec> | I just tried google maps in a ff 4 nightly and it asked for permission |
| 00:44 | <roc> | jamesr_: probably not to within a city block, I'm guessing |
| 00:44 | <roc> | that makes a difference to me |
| 00:44 | <jamesr_> | roc: why not? |
| 00:45 | <jamesr_> | depends on the city, i suppose |
| 00:45 | <Hixie> | ah, yes, i had granted it permission |
| 00:45 | <Hixie> | roc: is there a page that shows the quota dialog? |
| 00:45 | <kbrosnan> | most desktops firefox can get as close as geoip can get |
| 00:45 | <jamesr_> | but why couldn't some enterprising web authors know the IP address + location of every starbucks in the world? |
| 00:45 | <roc> | because ISP subnet blocks will be distributed across many city blocks |
| 00:46 | <roc> | maybe you're right about Starbucks |
| 00:46 | <roc> | but you're not right about my house |
| 00:46 | <jamesr_> | sure. depends on the house |
| 00:46 | <roc> | Hixie: dunno |
| 00:47 | <Hixie> | the geo ui in ff4 is ok. not sure how well it would scale if there were multiple requests at once. |
| 00:54 | <gavin> | we only show one request (of a given type) at a time |
| 00:54 | <Hixie> | ah interesting |
| 00:54 | <Hixie> | well we can certainly do something along these lines with a callback like geolocation |
| 00:55 | <othermaciej> | the main in-page element that makes sense for a camera (IMO) is something in-page to show you what's being recorded, without having to route through JavaScript first |
| 00:56 | <roc> | we have considered an approach where you give a magic URL to <video src> like "camera:" |
| 00:56 | <othermaciej> | I am not sure infobar is the right model for camera access |
| 00:57 | <Hixie> | roc: that's the URL you get from Stream |
| 00:57 | <roc> | othermaciej: it may not be, but I would certainly not be happy with in-page clicks serving as confirmation UI |
| 00:58 | <Hixie> | with <device> the confirmation UI is out-of-page |
| 00:58 | <Hixie> | the in-page click is the one that brings up the confirmation UI |
| 00:58 | <othermaciej> | roc: that definitely is not good for the confirmation UI |
| 00:58 | <othermaciej> | roc: that has to be out-of-page |
| 00:58 | <Hixie> | (can't the geolocation thing in ff4 be click-jacked? it always appears in a predictable place, no?) |
| 00:58 | <gavin> | yes |
| 00:59 | <gavin> | (bug 583175) |
| 01:01 | <Hixie> | that's one of the things the <device> design works around |
| 01:01 | <Hixie> | but i'm certainly open to better suggestions |
| 01:09 | <AryehGregor> | jgraham or gsnedders or other random Opera person: how different is Opera's innerText from textContent? And how different is its Selection.toString() from Range.toString()? Do you know of web-compat issues that would prevent them from being made the same, just scrapping all plaintext conversion in favor of concatenating text nodes? |
| 01:22 | <AryehGregor> | othermaciej, what do you think of the last five paragraphs of <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030210.html>;? |
| 01:25 | <othermaciej> | AryehGregor: innerText is pretty pointless if it does the exact same thing as textContent |
| 01:25 | <othermaciej> | AryehGregor: that will just mislead pages that try to sniff for it |
| 01:26 | <othermaciej> | I don't know enough about Selection.toString() to have an opinion |
| 01:26 | <AryehGregor> | othermaciej, the overwhelming majority of pages that use innerText use it as a simple substitute for textContent. |
| 01:26 | <othermaciej> | I don't think we'd have a major problem with making innerText more IE-like |
| 01:26 | <AryehGregor> | For the rest, textContent isn't a particularly bad substitute. |
| 01:26 | <othermaciej> | well, if they work in Mozilla they can use textContent |
| 01:27 | <AryehGregor> | Opera and IE9 also have innerText that behaves a lot more like textContent than like WebKit's innerText. |
| 01:27 | <othermaciej> | is IE9 different from older IE? |
| 01:27 | <AryehGregor> | Yes, totally different. |
| 01:27 | <AryehGregor> | At least in my testing. |
| 01:27 | <othermaciej> | weird |
| 01:27 | <othermaciej> | I wonder if that's intentional |
| 01:27 | <othermaciej> | anyway |
| 01:28 | <othermaciej> | we almost surely have legacy WebKit-specific content that will break if we change here |
| 01:28 | <othermaciej> | if there was a lot of interop value to be gained, we might consider breaking it |
| 01:28 | <AryehGregor> | WebKit has by far the most complicated innerText implementation of any browser, AFAICT. |
| 01:28 | <AryehGregor> | What sort of content would actually break in practice? |
| 01:28 | <othermaciej> | but it seems like the only interop we'd be getting is with Mozilla's refusal to have the feature of plaintext conversion |
| 01:28 | <othermaciej> | no idea |
| 01:28 | <othermaciej> | there's lots of content coded only to WEbKit |
| 01:29 | <AryehGregor> | Plaintext conversion is a very rare use-case. |
| 01:29 | <othermaciej> | when we adopted the HTML5 parsing algorithm, lots of things broke |
| 01:29 | <othermaciej> | not on the public web |
| 01:29 | <AryehGregor> | And when it is used, the result is generally just going to be displayed to the user, so at worst it will look a bit weird. |
| 01:29 | <othermaciej> | but dashboard widgets, Mac native apps (maybe iOS native apps too), Apple intranet sites... |
| 01:30 | <othermaciej> | that pain was worth it, I suppose, to gain WEb compatibility and inteop on something major |
| 01:30 | <AryehGregor> | That could all break if you change your innerText implementation substantially at all, though, including to a hypothetical plaintext conversion spec. |
| 01:30 | <othermaciej> | doesn't seem worth it for something minor, especially when it's just to satisfy Mozilla's ideological desire for the feature to not exist |
| 01:30 | <othermaciej> | that's probably true |
| 01:30 | <othermaciej> | we'd have to test it a lot |
| 01:30 | <othermaciej> | we have changed it in minor ways over time |
| 01:30 | <othermaciej> | I know that if <br> doesn't produce newlines, stuff will break |
| 01:30 | <othermaciej> | past that, hard to say |
| 01:31 | <AryehGregor> | So if you're really saying that WebKit is not willing to change its innerText algorithm much at all no matter what, either we have to spec a close match to its algorithm or give up on WebKit interoperating here. |
| 01:31 | <AryehGregor> | In the first case, no one will implement the algorithm because it's not worth it. |
| 01:31 | <othermaciej> | I'm saying we have to do a lot of testing |
| 01:31 | <AryehGregor> | In the second case, at least we have all other engines on the same page. |
| 01:31 | <othermaciej> | so an interoperable specification would have to be worth the cost of testing and of fixing the content that breaks |
| 01:32 | <othermaciej> | if the spec neuters the feature and we have to add a prefixed version, that doesn't seem worth it |
| 01:32 | <othermaciej> | better to just have the feature remain nonstandard in that case |
| 01:32 | <othermaciej> | at least IMO |
| 01:32 | <AryehGregor> | It doesn't have to be exactly the same as textContent, we can add whatever adjustments are needed for web compat. E.g., something simple like adding newlines for <br> would probably be fine. |
| 01:32 | <othermaciej> | I am sure lots of minor changes are possible |
| 01:32 | <othermaciej> | it's hard for me to judge without a specific proposal |
| 01:33 | <othermaciej> | I'm pretty sure "identical to textContent" won't fly |
| 01:33 | <AryehGregor> | The proposal would be "identical to textContent except for whatever implementers say is necessary for compat". |
| 01:33 | <AryehGregor> | Opera might have useful input here. |
| 01:33 | <othermaciej> | IE probably still gets compat benefit from their old version due to their multiple engines |
| 01:33 | <othermaciej> | so they might be more willing to change than us, but only in IE9 standards mode |
| 01:33 | <AryehGregor> | Yes, IE has devised its own way to evade compat problems. |
| 01:34 | <AryehGregor> | If people keep on writing so much WebKit-only code and WebKit has complicated WebKit-only features like this unprefixed, it's going to be forced to do the same someday. |
| 01:35 | <AryehGregor> | At least that's my prediction. |
| 01:35 | <othermaciej> | well, we don't add new nonstandard features unprefixed these days |
| 01:35 | <othermaciej> | even in this case, we didn't make it up, we copied it from IE |
| 01:35 | <AryehGregor> | This one sort of snuck in as kind of an attempt to copy IE except actually not really because WebKit's implementation is more sophisticated in most ways. |
| 01:35 | <AryehGregor> | (like IE doesn't even handle display: none) |
| 01:36 | <othermaciej> | I suspect IE magically applies formatting based on certain HTML tags, and ours actually looks at the rendering |
| 01:36 | <roc> | isn't there a record of why Webkit added that complexity? There must have been some use-case |
| 01:36 | <AryehGregor> | No, I'm pretty sure that's not true. I think IE8 handles <div style=white-space:pre-line> nicely in my test. |
| 01:37 | <othermaciej> | we inherited innerText from KHTML |
| 01:37 | <AryehGregor> | Gecko's the one that mostly ignores CSS. |
| 01:37 | <gsnedders> | AryehGregor: It's a completely different code-path to textContent, so kinda hard to tell what exactly is different |
| 01:37 | <othermaciej> | then we made it more IE-compatible (original version was dumb) |
| 01:37 | <roc> | well, then they should have a record |
| 01:37 | <othermaciej> | I don't think KHTML has records extending to more than 10 years ago |
| 01:37 | <AryehGregor> | gsnedders, textContent is trivial, it just concatenates all the text nodes. Presumably innerText does that but with some extra processing, yes? |
| 01:38 | <othermaciej> | anyway, at some point I think we merged it with the plaintext conversion code we use for other purposes, e.g. copy |
| 01:38 | <AryehGregor> | Yeah, WebKit's the only one that does that AFAICT. |
| 01:38 | <gsnedders> | AryehGregor: I also don't understand quite how our impl works :) |
| 01:38 | <AryehGregor> | (didn't test Opera or IE8, I guess) |
| 01:38 | <AryehGregor> | gsnedders, well, I can do some black-box testing if necessary. |
| 01:38 | <othermaciej> | we can split it from regular plaintext conversion if some compatible-enough version would work better |
| 01:38 | <othermaciej> | I can't commit resources to do interop research on this in the short term though |
| 01:39 | <gsnedders> | AryehGregor: I can ask others if I remember tomorrow |
| 01:39 | <gsnedders> | AryehGregor: My reading of the code when I tried to work out what it did was that it always returned the empty string. This is quite obviously wrong. :) |
| 01:40 | <AryehGregor> | gsnedders, surprisingly, that matches what Opera does for Selection.toString() in my test page. Maybe you're on to something. |
| 01:40 | <gsnedders> | (Now you know why I don't get paid to do white-box QA) |
| 01:41 | <gsnedders> | AryehGregor: That'll just be ranges stuff, I suspect. |
| 01:41 | <AryehGregor> | Yeah, I know, I was kidding. :P |
| 01:42 | <AryehGregor> | Unless my eyes deceive me, the only thing Opera does differently here for innerText is that it adds newlines for <br>: http://aryeh.name/spec/innertext/test/innerText.html |
| 01:42 | <AryehGregor> | (there's a diff at the end) |
| 02:39 | <TabAtkins> | Damn, I missed the <device> conversation today. |
| 03:25 | <othermaciej> | TabAtkins: do you have an opinion on the topics discussed relating to <device>? |
| 10:40 | <annevk> | I wonder if I should write a change proposal for http://www.w3.org/html/wg/tracker/issues/140 |
| 10:41 | <annevk> | Introducing a special term "conforming HTML5 document" is bound to lead to pointless arguments |
| 10:41 | <annevk> | though the lack of it will presumably do too |
| 10:42 | <jgraham> | If you don't enjoy pointless arguments, why ever did you get involved with specs work? |
| 10:43 | <Ms2ger> | jgraham, that sounds like logic |
| 10:44 | <annevk> | heh, meta |
| 10:44 | <jgraham> | I can't tell, my reference point was left at the door |
| 11:49 | <annevk> | thanks volkmar |
| 11:50 | <volkmar> | annevk: np |
| 12:15 | <hsivonen> | stuff I just learned: Gecko doesn't use .xsl as signal of XSLTness but wants a type pseudo-attribute on the <?xml-stylesheet?> PI |
| 12:15 | <hsivonen> | when loading from local disk |
| 12:39 | <hsivonen> | sigh. trying to learn XSLT in a hurry. having trouble with template precedence |
| 12:40 | <annevk> | simple examples here: http://annevankesteren.nl/test/xml/xslt/ |
| 12:41 | <annevk> | though I guess you can find those anywhere |
| 12:45 | <annevk> | that HTTP status code problem is annoying |
| 12:45 | <annevk> | similarly with images not existing and such |
| 12:52 | <zcorpan> | hsivonen: doesn't gecko want type="" even when loading over HTTP? |
| 12:52 | <hsivonen> | zcorpan: I didn't test |
| 12:53 | <hsivonen> | annevk: thanks. I think I now have roughly what I want except I have an insane amount of pointless whitespace |
| 12:53 | <hsivonen> | wondering what tool is the quickest for zapping the extra space |
| 13:19 | <annevk> | jgraham, http://tc.labs.opera.com/apis/EventSource/eventsource-constructor-url-bogus.htm why is that again? |
| 13:19 | <annevk> | jgraham, should I update testharness.js? |
| 13:20 | <jgraham> | annevk: It is a confusing error that doesn't reflect what is actually going on |
| 13:20 | <jgraham> | But I don't think it is fixed |
| 13:22 | <jgraham> | annevk: Probably it is because e.name !== SYNTAX_ERR |
| 13:22 | <jgraham> | iirc there is some debate about whether you will require than in web dom vore anyway |
| 13:23 | <jgraham> | So the check could probably be removed |
| 13:23 | <annevk> | hmm yeah |
| 13:23 | <annevk> | or at least be made a separate assert |
| 13:23 | <annevk> | because that piece of code violates all the nicety the harness provides |
| 13:24 | <annevk> | (i.e. not needing pass1 && pass2 && pass3 |
| 13:24 | <annevk> | ) |
| 13:24 | <jgraham> | OK, I will do that. In the meantime you could patch your copy by looking for e.name === code_or_object |
| 13:24 | <jgraham> | and removing it |
| 13:24 | <annevk> | yeah, I guess that is best for now |
| 13:35 | Ms2ger | approves of removing that check |
| 13:47 | <annevk> | is X-Frame-Options discussed on some mailing list? |
| 13:47 | <annevk> | if the font community can be convinced of http://annevankesteren.nl/2011/02/from-origin it would be nice to replace it with that over time |
| 13:51 | <jgraham> | annevk: Does from-origin need multiple domains or wildcards or something? |
| 13:51 | <jgraham> | e.g. From-Origin *.example.com |
| 13:52 | <jgraham> | or rather http://*.example.com or something |
| 13:52 | <annevk> | I'd prefer not to |
| 13:53 | <annevk> | but it could be extended in such a way |
| 13:53 | <annevk> | or turned into that if that is what is needed |
| 13:53 | <annevk> | most of the time you simply want From-Origin: same |
| 14:06 | <annevk> | oh EventSource, I dislike updating your tests so much |
| 14:09 | <Philip`> | Could From-Origin be easily worked around for image hotlinking by doing <object data="data:text/html,<script>location='http://example.org/image'</script>"></object>; ? |
| 14:10 | <annevk> | no |
| 14:11 | <Philip`> | Oh, I'm confused and thinking of it like Not-From-Origin or something |
| 14:12 | <annevk> | the name is not that great |
| 14:12 | <Philip`> | (where if the origin data has been stripped by redirects/etc then it's allowed) |
| 14:13 | <annevk> | no, the check is made relative to the context where the resource ends up in |
| 14:13 | <annevk> | redirects are futile |
| 14:14 | <Philip`> | Hmm, how is the context determined when you have multiple nested levels of embedding (each perhaps at different origins)? |
| 14:15 | <annevk> | the context is the API issuing the request |
| 14:18 | <annevk> | oh joy |
| 14:18 | <annevk> | WebKit still has .URL |
| 14:19 | <annevk> | I heard somewhere you get more follow-up if you file a Chromium bug than a WebKit bug, is that still true? |
| 14:20 | <annevk> | Peter`, do you know? |
| 14:21 | <Peter`> | In my experience, yes |
| 14:21 | <Peter`> | although there's about 10k unconfirmed Chromium issues too |
| 14:21 | <annevk> | joy |
| 14:22 | <annevk> | given that WebKit still has not resolved the .URL issue I wonder if it is worth filing issues on resolving URLs and 2xx responses per Hixie's recent change |
| 14:23 | <Peter`> | Has it been filed somewhere? |
| 14:29 | <annevk> | https://bugs.webkit.org/show_bug.cgi?id=40899 |
| 14:29 | <annevk> | ap apparently wanted to convince people to change the spec yet again but that has not happened and meanwhile Opera shipped with .url |
| 14:30 | <annevk> | I suspect nobody is using that attribute as it is fairly useless, but still... |
| 14:33 | <benschwarz> | zcorpan: updates some issues. |
| 14:33 | <benschwarz> | now, sleep time. *whew |
| 14:33 | <annevk> | zcorpan, hey, I 386'd that for you and won |
| 14:34 | <annevk> | zcorpan, one Internet in return please |
| 14:35 | <zcorpan> | annevk: what did you win? |
| 14:36 | <annevk> | the argument |
| 14:44 | <annevk> | AryehGregor, you around? |
| 15:04 | <zcorpan> | hmm. there's a race condition with autoplay="" and events |
| 15:11 | <annevk> | I wish there was an easy way to check null/undefined handling across a large number of methods/attributes |
| 15:11 | <annevk> | but I guess it's just going to be manual labor of coming up with a large list |
| 15:12 | <annevk> | should have a set of summer interns for these things :) |
| 15:20 | <Ms2ger> | annevk, I can tell you what Gecko does ;) |
| 15:21 | <annevk> | Ms2ger, oh really? |
| 15:21 | <annevk> | Ms2ger, that would be sufficient I think |
| 15:21 | <Ms2ger> | null -> "", undefined -> "undefined" |
| 15:21 | <annevk> | right, and the exceptions are? |
| 15:22 | <annevk> | cause last I heard this is not 100% consistent |
| 15:22 | <Ms2ger> | DOMTokenList |
| 15:22 | <Ms2ger> | querySelector(All) |
| 15:23 | <Ms2ger> | createHTMLDocument |
| 15:23 | <Ms2ger> | textarea.wrap |
| 15:23 | <Ms2ger> | a.text |
| 15:23 | <Ms2ger> | And actually, I seem to have caused all of them |
| 15:24 | <annevk> | I could swear sicking said there was more to it |
| 15:24 | <annevk> | because those indeed do not sound like they need to be this way |
| 15:24 | <Ms2ger> | Hmm |
| 15:25 | <annevk> | maybe it is mostly with method calls |
| 15:25 | <annevk> | e.g. xhr.open() or xhr.send() |
| 15:26 | <annevk> | as specced xhr.send(null) / xhr.send() is different from xhr.send("") |
| 15:26 | <annevk> | former has no entity body latter has |
| 15:27 | <zcorpan> | annevk: send() isn't DOMString in the IDL, though, right? |
| 15:27 | <zcorpan> | so null isn't converted at all |
| 15:27 | <Ms2ger> | It's a UTF-8 string |
| 15:28 | <annevk> | it's void send([AllowAny] DOMString? data); atm |
| 15:28 | <annevk> | I guess DOMString? makes it not a DOMString... |
| 15:28 | <annevk> | or not fully one |
| 15:28 | <zcorpan> | what's [AllowAny]? |
| 15:29 | <Ms2ger> | I guess you'd get undefined -> null, null -> null for DOMString? |
| 15:29 | <annevk> | to make sure that Object does not throw a TypeError |
| 15:29 | <AryehGregor> | annevk, I'm around now. |
| 15:29 | <annevk> | just DOMString should do the undefined -> "undefined" and null -> "null" thing |
| 15:30 | <annevk> | AryehGregor, I wondered whether you tested setting string content attributes to null/undefined, but from looking at the source I got the impression you did not |
| 15:31 | <AryehGregor> | At the time I wrote my reflection tests, I hadn't read WebIDL, so I didn't know what the behavior was supposed to be, so I didn't test it. |
| 15:31 | <AryehGregor> | They could easily be updated, though. |
| 15:32 | <annevk> | the behavior isn't really defined yet |
| 15:32 | <annevk> | from what Ms2ger is saying though and looking at http://lists.w3.org/Archives/Public/public-webapi/2008May/0449.html I think maybe Gecko has been consistent here |
| 15:32 | <Ms2ger> | Looks like undefined -> "", null -> "" for cstrings |
| 15:33 | jgraham | wishes this just follwed ECMAScript |
| 15:33 | <jgraham> | kind of late now I guess |
| 15:35 | <annevk> | I know null -> "" is needed for compat, so no |
| 15:36 | <zcorpan> | can't we specify DOMString? for stuff that need null -> "" ? |
| 15:36 | jgraham | doesn't like animations |
| 15:37 | <annevk> | zcorpan, no |
| 15:38 | <annevk> | zcorpan, DOMString? means it can be set to null |
| 15:38 | <jgraham> | Specifically TCs involving animation that therefore take forever to run |
| 15:38 | <annevk> | with null being different from the empty string |
| 15:38 | <zcorpan> | annevk: yeah. so then say in prose that null means empty string |
| 15:38 | <annevk> | such as xhr.send() and the alternate style sheets API |
| 15:39 | <annevk> | zcorpan, there's different semantics between null and empty string so that would not work |
| 15:39 | <annevk> | zcorpan, oh |
| 15:39 | <annevk> | zcorpan, why not just have that be the behavior for "DOMString" |
| 15:39 | <annevk> | then you need not worry about defining that |
| 15:39 | <annevk> | http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0011.html is where othermaciej states different attributes need different things |
| 15:39 | <zcorpan> | annevk: if it can be done everywhere, sure |
| 15:39 | <annevk> | maybe he was wrong |
| 15:40 | <annevk> | I have not found examples |
| 15:41 | <annevk> | apart from what Ms2ger just mentioned, but those are bugs he introduced |
| 15:42 | <Ms2ger> | Looks like document.open has something else too |
| 15:44 | <zcorpan> | seems like foolip should file his CP as a bug |
| 15:45 | <annevk> | and then hixie should fix it before we get to vote on the other CP |
| 15:45 | <annevk> | and then I'd like to find out what happens |
| 15:45 | <zcorpan> | before or after, who cares |
| 15:45 | <annevk> | apparently, I do |
| 15:45 | <zcorpan> | heh |
| 15:45 | <annevk> | but not too much |
| 15:46 | <zcorpan> | time for weekend |
| 15:46 | <zcorpan> | see ya |
| 15:52 | <annevk> | Opera will prolly change its defaults to do null -> "" for bindings as well |
| 15:57 | <annevk> | hopefully then heycam can change the spec and this can be resolved closed :) |
| 15:57 | <annevk> | or the other way around |
| 16:04 | <AryehGregor> | Yay on ISSUE-41. |
| 16:08 | <acroyear2> | ??heroism |
| 16:10 | <jgraham> | Philip`: http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html |
| 16:15 | <Philip`> | Modern C compilers can inline across compilation units, then they'd dead-code-eliminate so the loop disappears entirely (which it looks like PyPy doesn't), and the shared library thing is mostly irrelevant since you can easily avoid writing performance-critical loops that cross shared library boundaries |
| 16:18 | <Philip`> | Also there's loads of decent profiling tools for C so you can easily find bottlenecks and then it's usually clear how to fix them, whereas profiling JITted code seems rare and you can never really tell what source changes will result in the desired machine code improvements |
| 16:18 | <Philip`> | So I think it's a silly comparison, like almost all "X is faster than C" comparisons :-p |
| 16:19 | <jgraham> | Philip`: They were very clear that it was a well-choden example :) |
| 16:19 | <jgraham> | *chosen |
| 16:24 | <Philip`> | Yeah, I don't mean they're being misleading about what's being measured, they're just measuring something that seems pretty irrelevant for real code - there's not much value in being faster than poorly-designed C code |
| 16:27 | <jgraham> | Well, I don't think people are going to be chosing python over C for speed anytime soon |
| 16:27 | Philip` | has forgotten what the context of this discussion was, anyway |
| 16:28 | jgraham | too, I just remember that there was one and the link seemed relevant |
| 16:28 | <jgraham> | s/I/he/ s/ber/bers/ |
| 16:31 | webr3 | looks at http://www.momkai.com/ nice done in html/css/js site |
| 16:32 | <jgraham> | webr3: They should creatively leave my scrollbars alone |
| 16:32 | <Philip`> | I suppose I just get mildly irritated by performance comparisons vs C which always seem to miss the point by doing things that are inefficient C and could be easily worked around |
| 16:34 | <Philip`> | There are some things that are inefficient in C and hard to work around, like pointer aliasing or struct-of-array vs array-of-struct data structures (which can make a huge difference due to cache usage) |
| 16:34 | <Philip`> | so it'd be nice if other languages tackled that kind of thing, I think |
| 16:35 | <Philip`> | (C can't fix them because it's constrained by having given programmers access to pointers, so it can't e.g. rearrange a data structure without breaking lots of assumptions) |
| 16:36 | <jgraham> | Philip`: IIRC you were suggesting that PyPy wasn't giving notable performance improvments given the rate of improvements in javascript |
| 16:36 | jgraham | remembers the context at last |
| 16:37 | <Philip`> | Oh, that might have been it |
| 16:38 | <Philip`> | If they have an exponentially decaying graph of performance on a non-trivial benchmark suite then I'd be happy, I guess :-) |
| 16:40 | <jgraham> | http://speed.pypy.org/timeline/ |
| 16:40 | <jgraham> | The graphs look more linear to me |
| 16:45 | <Philip`> | The changes don't look quite as radical as e.g. in http://ieblog.members.winisp.net/images/Dean_MIX10_2.png |
| 16:48 | <AryehGregor> | gsnedders, did you remember to ask people about Opera's innerText implementation? (How it differs from textContent, and whether it has known compat issues.) |
| 16:49 | <jgraham> | Philip`: Well some tests do. And there seems to be a similar amount of progress compared to CPython |
| 16:49 | <gsnedders> | AryehGregor: No, I got to sleep at 7am this morning and slept in |
| 16:49 | <jgraham> | as between IE8 and IE9 |
| 16:49 | <jgraham> | Although I am not actually looking at the numbers, so that "similar amount" could be quite different |
| 16:50 | webr3 | lols at these test results http://www.bestresizer.com/2011/01/sunspider-javascript-benchmark-results-in-my-browsers/ fire fox 4, chrome 10, ie... 6! |
| 16:50 | webr3 | thinks somebody is trying to infer ie is a bag o shite to stay away from |
| 16:52 | bfrohs | wonders why they used IE 6 |
| 17:18 | <TabAtkins> | othermaciej: Yeah, I've got some opinions. I think that overall, the structure of <device> is sound and useful, in that it's the API for requesting hardware access from the user. It hands back an object specialized for that hardware/access-mode, which is also good design. |
| 17:19 | <TabAtkins> | The only thing I would change in the overall design is making it just a JS constructor, not an HTML element. I don't see any value in making it an HTML element - it seems to have the same weirdness that <eventsource> did. |
| 17:19 | <othermaciej> | TabAtkins: it seems extremely silly to me, compared to having dedicated elements and interfaces for particular kinds of hardware |
| 17:20 | <othermaciej> | "requesting hardware access from the user" is not an abstraction that is useful at the UI level |
| 17:21 | <TabAtkins> | Hm, really? I'd naively think that saying "hey, the webpage wants to stream from your webcam" and "hey, the webpage wants to use your xbox controller" would be similar. |
| 17:23 | <othermaciej> | I imagine the xbox controller, like the mouse and keyboard, is not something that needs permission at all |
| 17:23 | <othermaciej> | for the camera, the UI I would imagine is something like this: |
| 17:24 | <othermaciej> | pops up a window that shows a preview of what the camera is currently seeing, with record and cancel buttons |
| 17:24 | <othermaciej> | if you have both front and back cameras, there is an affordance to switch, and the preview updates |
| 17:24 | <othermaciej> | if you start recording, there is a persistent "record light" type visual indicator in the UI |
| 17:24 | <TabAtkins> | That seems like the UI for <input type=file accept=video/*>, not for allowing the script access to the camera to do what it wishes. |
| 17:25 | <othermaciej> | what would you imagine? |
| 17:26 | <othermaciej> | that is the best I can think of so far |
| 17:26 | <TabAtkins> | I'm not completely certain, but I'd think it'd be more like a standard one-time-permission dialog, without an intrusive display or indicator that it is recording. |
| 17:26 | <othermaciej> | agree that it would be better to make more clear that the recording will continue indefinitely, but I am not sure how to do that (other than the record light telling you it hasn't stopped) |
| 17:27 | <bfrohs> | othermaciej: It's like access to your location (or anything else that requires permission). You can have the choice to allow this session, allow permanently, or deny |
| 17:27 | <othermaciej> | why would a permission dialog with text be better than something that shows you a preview of what the camera is showing, and lets you pick which camera to use? |
| 17:28 | <TabAtkins> | That can be a part of the permissions dialog, sure. It makes a lot of sense. But it shouldn't stay up after permission has been granted. |
| 17:28 | <othermaciej> | permission dialogs are the worst security UI ever designed |
| 17:28 | <othermaciej> | I didn't say it should stay up after |
| 17:29 | <othermaciej> | anyway, I don't see how any of this UI could meaningfully be shared with access to an RS232 port |
| 17:29 | <othermaciej> | (which I don't exactly see us leaping to do, but never say never, I suppose) |
| 17:29 | <TabAtkins> | I don't even know what an RS232 port is, so I can't comment. Right now I'm interested in cam/mic access, and usb HID access. |
| 17:29 | <bfrohs> | TabAtkins: http://en.wikipedia.org/wiki/RS-232 |
| 17:30 | <othermaciej> | the result of throwing texty permissions dialogs at the user is this: <http://krebsonsecurity.com/2011/01/exploit-packs-run-on-java-juice/>; |
| 17:30 | <TabAtkins> | The latter is what all video game controllers use. |
| 17:30 | <AryehGregor> | TabAtkins, http://www.xscables.com/prodimages/CC2045-06_LR.jpg |
| 17:30 | <TabAtkins> | AryehGregor: Ah, kk. |
| 17:30 | <othermaciej> | TabAtkins: I think Hixie invented <device> so he can piggy back controlling his model trains on camera/microphone access |
| 17:30 | <othermaciej> | it is a mostly obsolete thing in modern computers, no one plugs stuff into their serial port |
| 17:31 | <TabAtkins> | Hehe. |
| 17:31 | <jgraham> | But some USB devices could be more serial-like than camera-like |
| 17:31 | <Philip`> | (Game controllers shouldn't be accessed via the USB HID level of abstraction, they should be accessed via the joystick level) |
| 17:32 | <TabAtkins> | Philip`: Is that well-defined? |
| 17:32 | <Philip`> | It's as well-defined as keyboard and mouse input |
| 17:32 | <Philip`> | i.e. everybody makes up their own APIs for the same basic concepts |
| 17:32 | <TabAtkins> | That's less useful. |
| 17:32 | <Philip`> | so the web can make up its own API for joystick-like input devices too |
| 17:33 | <AryehGregor> | othermaciej, a permission dialog is all that stops a user from installing arbitrary executables on most platforms, so an attacker who can get a user to click through a scary permission dialog can already run arbitrary code. |
| 17:33 | <Philip`> | (though probably based partially on polling, rather than on events (like mouse/keyboard input)) |
| 17:33 | <AryehGregor> | Except on iOS, Chrome OS, and similar platforms. |
| 17:33 | <TabAtkins> | Philip`: Eww, you don't want to run a video game on polling. |
| 17:34 | <Philip`> | Sure you do - every frame you look for the current controller stick position |
| 17:34 | <othermaciej> | AryehGregor: there is a difference between "install" and "run", but yes, I would agree that it's pretty terrible regardless |
| 17:34 | <Philip`> | and analogue trigger positions |
| 17:34 | <Philip`> | though buttons should presumably be done via events |
| 17:34 | <AryehGregor> | I think permission dialogs are about the only sensible thing to do for features that are useful but would infringe privacy if used without permission. |
| 17:35 | <AryehGregor> | At least I've never heard of a better way to handle it. |
| 17:35 | <TabAtkins> | Philip`: Note that buttons tend to be fully analog on modern controllers, too. |
| 17:35 | <TabAtkins> | On the 360, everything but Start and Back are analog. |
| 17:35 | <AryehGregor> | When it comes to purely technical attacks, you can do a fair amount of stuff on the user's behalf without asking them, because you can automatically judge what they'll want better than they can in many cases. But privacy issues hinge on consent. |
| 17:35 | <AryehGregor> | Hard to avoid making the UI hinge on consent. |
| 17:36 | <AryehGregor> | I wish people wouldn't use permission dialogs for more technical stuff, though, the way (for instance) the Android Market does. |
| 17:36 | <AryehGregor> | And apparently the Chrome Web Store too. |
| 17:37 | <othermaciej> | even for privacy related things, permissions dialogs are poor if they don't let the user meaningfully understand the consequences of saying yes |
| 17:37 | <AryehGregor> | "This application will have the right to: [list of coarse-grained privileges that most users won't understand] Do you want to install?" |
| 17:37 | <AryehGregor> | That's true. |
| 17:37 | <othermaciej> | and even then, something user initiated is better than an app-initiated dialog |
| 17:38 | <TabAtkins> | Anyway, back to video. I just don't want to force UI on page designers unless it's obvious and helpful. If the user is recording a video to submit a form, definitely pop up some UI that stays up while they're recording and is very obvious. But if the page is wanting to script the video stream (to do motion tracking, for example), I don't want to force the page to contain a confusing panel showing the raw video. |
| 17:38 | <AryehGregor> | Not sure about that. |
| 17:38 | <AryehGregor> | Why? |
| 17:38 | <AryehGregor> | Or really, what do you mean by user-initiated? |
| 17:39 | <AryehGregor> | Do you think the current standard geolocation UI could have been improved upon? |
| 17:39 | <AryehGregor> | Sites need some way of telling the user to let them use geolocation. |
| 17:39 | <AryehGregor> | One way or another. |
| 17:39 | <Philip`> | TabAtkins: It's not all analogue on at least more-than-a-few-months-old 360 controllers, as far as I'm aware - on e.g. Windows it's exposed as 6 analogue axes and about 10 digital buttons, I think |
| 17:40 | <TabAtkins> | Though, it might make sense to run with something smaller - have <device> render as a button that, when pressed, runs the permissions dialog, and then alters its UI to show when the page has the stream open or not. |
| 17:40 | <TabAtkins> | The page author can still display:none the thing once they get permission, but they don't need to if it's unintrusive. |
| 17:41 | <AryehGregor> | That's awkward. |
| 17:41 | <TabAtkins> | Philip`: I know for a fact that my 360 controller has two analog sticks, two analog triggers, and four analog face buttons. Not sure about two of the other buttons, or the dpad, but I suspect they're analog too. |
| 17:41 | <AryehGregor> | In a lot of cases, you'd expect users to give permanent camera access to a site. |
| 17:41 | <AryehGregor> | So it gets the <device> sticking around forever by default? |
| 17:41 | <TabAtkins> | Dunno what Windows has access to, but my Xbox gets them as analog at least. |
| 17:42 | <TabAtkins> | AryehGregor: Sure, yeah. |
| 17:42 | <AryehGregor> | Blech. |
| 17:42 | <TabAtkins> | It's either that, or the user doesn't know whether the site is actively recording or not. |
| 17:42 | <Philip`> | TabAtkins: http://en.wikipedia.org/wiki/Gamepad#Xbox_360 - "The pressure-sensitivity feature on the face buttons was removed" |
| 17:42 | <AryehGregor> | I think the geolocation API is okay. Add some discreet in-chrome UI whenever you visit the site that says what permissions it has and lets you change them. |
| 17:43 | <bfrohs> | Well, webcams typically have a hardware light that turns on when it's active |
| 17:43 | <TabAtkins> | Philip`: wut |
| 17:43 | <AryehGregor> | A little icon someplace. |
| 17:43 | <bfrohs> | And the OS also sometimes provides an icon noting it is in use |
| 17:44 | <bfrohs> | I don't think there needs to be an additional indication that the webcam is currently in use (only a dialog requesting permission to use) |
| 17:44 | <TabAtkins> | Philip`: I stand corrected. Wtf. |
| 17:45 | <Philip`> | TabAtkins: See also e.g. http://google.com/codesearch/p?hl=en#PPdD7__6Qbg/src/xboxmsg.hpp&q=xboxmsg.hpp&l=44 |
| 17:45 | <Philip`> | which has a load of 1-bit values for all the buttons |
| 17:46 | <Philip`> | (with the d-pad counting as four buttons) |
| 17:46 | <Philip`> | and only the triggers (8-bit) and sticks (16-bit) being analogue |
| 17:46 | <Philip`> | (The non-360 definition below has 8-bit buttons, presumably for the older controllers) |
| 17:50 | <Philip`> | If game controllers were exposed to the web, I wonder if you'd need a permissions check before using the rumble feature |
| 17:50 | <TabAtkins> | You don't need permission to rumble anything I own. |
| 17:51 | <Philip`> | I suppose a malicious page unexpectedly rumbling is not much worse than them playing loud audio without permission |
| 18:18 | webr3 | wonders if the tipping point is when apps have to ask if they ask, then we're screwed |
| 18:18 | webr3 | /s/they/they can |
| 19:07 | <Hixie> | othermaciej: a number of the issues on http://dev.w3.org/html5/status/issue-status.html that are in state "Call for Alternate/Counter Proposals" don't have a deadline |
| 19:07 | <Hixie> | othermaciej: is that intentional? |
| 19:08 | <Hixie> | annevk: i highly recommend writing a CCP for http://lists.w3.org/Archives/Public/public-html/2011Jan/0239.html -- i'll help out if you want |
| 19:08 | Hixie | is utterly swamped dealing with all these CPs and would really welcome the help |
| 19:13 | <AryehGregor> | Hixie, you could assign me to help with some of them if you want, if that's okay with Google. |
| 19:14 | <Hixie> | sure |
| 19:14 | <Hixie> | the issue-status file is getting really hard to read, with all the issues pending decisions and so on |
| 19:14 | <Hixie> | and weird issues like -31 that I don't understand the status of |
| 19:23 | <AryehGregor> | jgraham, annevk, or whoever: could you figure out what innerText does in Opera and tell me, and also tell me whether there are known compat issues with it? |
| 19:24 | <AryehGregor> | It seems like it's the simplest possible behavior that won't have serious compat problems. |
| 19:25 | <gsnedders> | AryehGregor: Including script elements is the only site compat bug I can find with it |
| 19:26 | AryehGregor | adds that to his tests |
| 19:26 | <AryehGregor> | Oh, wait, it's already there. |
| 19:26 | <AryehGregor> | What site is the compat problem with? |
| 19:27 | <gsnedders> | AryehGregor: http://dirty.ru |
| 19:30 | gsnedders | finds a line of code he'd missed before and has the whole thing start to make sense |
| 19:31 | AryehGregor | doesn't see where the compat issue comes from, since it doesn't seem to use innerText in Opera except where it uses textContent in Firefox, so does the issue occur in Firefox too? |
| 19:31 | <AryehGregor> | What were the steps to reproduce? |
| 19:32 | <gsnedders> | It's an old bug report, it's entirely possible the site doesn't use it any more |
| 19:33 | <gsnedders> | Yeah, doesn't appear to reproduce any more |
| 19:33 | <hsivonen> | I'm still shocked that <devide> in being designed on the level on waht kind of harware bus is being used instead of what type of device is being used |
| 19:34 | <TabAtkins> | It's not being "designed", at least. It was "written in a throwaway proposal by Hixie that he put into the spec". |
| 19:35 | <gsnedders> | AryehGregor: CDATA blocks gets <[!CDATA[…]]> put around them, <br> causes \n, and that's it pretty much. There's some odd code for lastDescendent which may well do broken stuff for innerText. |
| 19:36 | <AryehGregor> | Weird, why would you need <[!CDATA[...]]> around CDATA blocks? |
| 19:37 | <AryehGregor> | Actually, how can you even get CDATA blocks in text/html? |
| 19:38 | <TabAtkins> | I didn't think the concept even existed. |
| 19:38 | <gsnedders> | AryehGregor: I guess it's become it's what the innerHTML stuff does, pretty much |
| 19:38 | <AryehGregor> | But how can you even get a CDATA node in the DOM? |
| 19:38 | <AryehGregor> | Is it possible from parsing text/html? |
| 19:38 | <gsnedders> | AryehGregor: It's the same code used for both HTML and XML, and {inner,outer}{Text,HTML}. |
| 19:38 | <AryehGregor> | Ah. |
| 19:39 | <gsnedders> | AryehGregor: You can get it from DOM manipulation. |
| 19:39 | <AryehGregor> | Well, I assume there's no compat risk there, so I won't spec it. |
| 19:39 | <gsnedders> | I think we output end tags in a few cases with lastDescendent, but that just seems buggy |
| 19:40 | <Hixie> | hsivonen: there's nothing in <device> designed to be hardware-bus-related. The stuff in the spec other than "media" is just throwaway filler for the moment (indeed the spec says so somewhere, iirc) |
| 19:48 | <AryehGregor> | gsnedders, do you know how I can actually set the contents of a Selection in Opera? I can't figure out any way that works. |
| 19:49 | <AryehGregor> | Whatever I do seems to produce selection.rangeCount == 0. |
| 19:59 | <hsivonen> | it seems that security experts can't decide which plug-in (Java, Flash Player, Adobe Reader) is the "top" avenue for exploits |
| 20:00 | <othermaciej> | Hixie: I'll fix issue-status shortly - setting up new computer at the moment |
| 20:01 | <Hixie> | cool |
| 20:01 | <othermaciej> | finally, I should have build times less than an hour |
| 20:03 | <hsivonen> | othermaciej: thanks for finally deciding issue 41 |
| 20:03 | <othermaciej> | you're welcome, though Sam deserves the thanks more than me |
| 20:03 | <karlcow> | http://www.w3.org/2001/tag/2011/02/security-web.html |
| 20:03 | <othermaciej> | I am surprised that posting the 41 decision did not spawn a flamewar |
| 20:03 | <karlcow> | http://www.w3.org/2001/tag/2010/10/interaction-examples.html |
| 20:04 | <gsnedders> | AryehGregor: Where's your TC? |
| 20:04 | <AryehGregor> | gsnedders, http://aryeh.name/spec/innertext/innertext.html |
| 20:04 | <AryehGregor> | Er. |
| 20:04 | <AryehGregor> | http://aryeh.name/spec/innertext/test/innerText.html |
| 20:05 | <hsivonen> | karlcow: gotta love URLs thathave two years |
| 20:05 | <hsivonen> | a decade apart even |
| 20:06 | <karlcow> | hsivonen: I don't know. I never look at the date as something meaningful. For me there are just identifier. |
| 20:06 | <gsnedders> | AryehGregor: I'm confused what you're trying to do there |
| 20:06 | <AryehGregor> | gsnedders, to do where? |
| 20:08 | <gsnedders> | AryehGregor: You create a range consisting of #test, select that, then collapse in document.body |
| 20:08 | <AryehGregor> | Um, wait. |
| 20:08 | <AryehGregor> | Look now. |
| 20:08 | <AryehGregor> | I was experimenting. :) |
| 20:11 | <gsnedders> | Okay, I don't understand what's going on in that case either. |
| 20:11 | <AryehGregor> | I'm just creating a Range for what I want to be selected, using removeAllRanges() on the Selection, then adding the range. |
| 20:11 | <AryehGregor> | So that Range should be what's selected. No? |
| 20:11 | <gsnedders> | Yeah. |
| 20:11 | <gsnedders> | In simple TCs, it works fine |
| 20:16 | <gsnedders> | Oh well, I'm outta here. |
| 21:25 | <TabAtkins> | Argh, IE is changing list bullet behavior between 8 and 9. |
| 21:26 | <TabAtkins> | I suppose that means that there isn't a significant compat impact in changing the behavior, which is good for me, but still. |
| 21:26 | <TabAtkins> | Makes it weird to spec. |
| 21:35 | <benschwarz> | here, I be |
| 22:07 | <benschwarz> | zcorpan: so, we should use the embedded-opentype string after all? |
| 22:11 | <zcorpan> | benschwarz: well, dunno - if you want ie9 to use woff instead of eot, then don't use embedded-opentype |
| 22:12 | <zcorpan> | benschwarz: however, using 'eot' or 'ie9-please-use-woff-instead' makes the style sheet invalid |
| 22:13 | <zcorpan> | i guess the main benefit with ie9 using woff is that woff is compressed, but you could configure the server to gzip the eot font and get much the same result |
| 22:48 | <zcorpan> | weird bug in chrome (or i guess recent webkit - works as intended in safari 5) http://software.hixie.ch/utilities/js/live-dom-viewer/saved/826 |
| 22:49 | <zcorpan> | devtools shows 'clear:left' in inherited styles |
| 22:50 | <TabAtkins> | Works as intended in Chrome9. |
| 22:51 | <zcorpan> | i'm using up-to-date dev |
| 22:52 | <TabAtkins> | Ah, I'm not. |
| 22:52 | <TabAtkins> | (Haven't restarted in a while.) |
| 23:05 | zcorpan | filed http://code.google.com/p/chromium/issues/detail?id=72005 |
| 23:07 | zcorpan | chooses to not work around the issue on his mom's dog's site and instead wait for the bug to be fixed |
| 23:10 | <TabAtkins> | Oh, wow, *that's* the issue? We broke the adjacent sibling combinator? Wtf. |
| 23:10 | <TabAtkins> | (Also, file at bugs.webkit.org, please? You can crosslink the bugs, if you want.) |
| 23:12 | <zcorpan> | done |
| 23:12 | <TabAtkins> | Danke. |
| 23:15 | <zcorpan> | hey, it's a site compat bug! you better go fix it :) |
| 23:16 | <TabAtkins> | Actually, it almost certainly *is* a site compat bug. |
| 23:16 | <TabAtkins> | Breaking combinators is no fun. |
| 23:20 | jgraham | is somewhat surprised you don't have regression tests covering that |
| 23:20 | <TabAtkins> | Me too. |
| 23:21 | <jgraham> | Although maybe it is more complex than I think? |
| 23:22 | <zcorpan> | jgraham: do *we* have regression tests covering that? |
| 23:22 | <jgraham> | zcorpan: I expect that depends how broken it is |
| 23:23 | <jgraham> | I might imagine that the CSS2.1 testsuite covers it |
| 23:23 | <jgraham> | If not, this is the ideal time for someone to make a test (although I guess it would have to go into the Selectors 3 TS) |
| 23:25 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/827 shows the bug as well |
| 23:27 | <jgraham> | If we don't have a test that the adjacent sibling combinator only applies to the adjacent sibling, we should launch an investigation into why not |
| 23:30 | <jgraham> | http://test.csswg.org/suites/css2.1/20110111/html4/sibling-selector-001.htm |
| 23:30 | <jgraham> | Also, that test is lame |
| 23:30 | <jgraham> | Who uses green as a fail condition? |
| 23:30 | <zcorpan> | regarding atob(), is the compat problem for not throwing for whitespace or for not throwing for other garbage? |
| 23:31 | <zcorpan> | if it's for other garbage, we could allow whitespace but throw for other garbage |
| 23:31 | jgraham | discovers <link rel="author" title="Microsoft" href="http://www.microsoft.com/">; |
| 23:31 | <zcorpan> | heh |
| 23:32 | <zcorpan> | that test indeed covers the issue |
| 23:34 | <jgraham> | I am quite worried by how strongly I react to tests that offend my sense of aesthetics |
| 23:35 | <jgraham> | Does it count as a work related injury if I can't see the text "The following line should be green\nFiller Text" without thinking "No, you should never use 'Filler Text' for the pass condition, that should be rewritten 'This text should be green'"? |
| 23:35 | <zcorpan> | yes |
| 23:37 | bfrohs | would be worried if you *didn't* think that |
| 23:38 | <zcorpan> | my work injury is that i have a hard time resisting filing bugs (or equivalent as appropriate) when i find them, even if it's not related to browsers or even the web |
| 23:39 | <zcorpan> | the problem usually is finding out who i should report the bug *to* |
| 23:39 | <jgraham> | What about non-software? |
| 23:40 | <zcorpan> | yeah, non-software too |
| 23:41 | <wilhelm> | It's affecting my private life too. I try to file bugs on my friends. It usually doesn't have the desired effect. |
| 23:42 | Hixie | files a bug on wilhelm to get a PC so he can play BC2 with all his friends instead of having to play on PS3 with wilhelm and PC with everyone else |
| 23:42 | <zcorpan> | e.g. if there's a sign that says that i can pay with mastercard but it only accepts visa, i feel an urge to make someone aware of the problem and fix the sign |
| 23:42 | <benschwarz> | zcorpan: if the @font-face is working, I'm happy for now |
| 23:42 | <benschwarz> | hah |
| 23:42 | <jgraham> | zcorpan: You will be slowly driven mad |
| 23:42 | <benschwarz> | Hixie: few things fixed overnight |
| 23:42 | <wilhelm> | Hixie: :P |
| 23:42 | <Hixie> | benschwarz: i saw |
| 23:42 | <benschwarz> | tracking pretty well I think |
| 23:43 | <Hixie> | benschwarz: looks good |
| 23:43 | <zcorpan> | but it's remarkable that employees of the company that governs the sign are totally uninterested in fixing the sign themselves or passing the information on to another employee who should be fixing the sign |
| 23:43 | <jgraham> | Also, I don't understand how the CSS tests (subset I looked at) turned out so bad. I mean they have http://www.w3.org/Style/CSS/Test/guidelines.html |
| 23:43 | <jgraham> | It's like the people read it but failed to understand important points |
| 23:44 | <Hixie> | anyone recall if i've invented terminology to mean "the Window or the WorkerGlobalScope, whichever is appropriate"? |
| 23:44 | <Hixie> | we have "cache host" for appcache, but that's Document or WGS |
| 23:46 | jgraham | notes that Hixie's example tests on that document are not uniformly compliant to the document |
| 23:46 | <jgraham> | Or afaict uniformly demonstrating the thing that they intend |
| 23:47 | <zcorpan> | Hixie: you should write a hack so that you can play on the PC on your end and wilhelm can play on the PS3 on his end |
| 23:47 | <Hixie> | that would be quite the hack |
| 23:47 | <benschwarz> | zcorpan: have you updated your special element thing to use the correct font now? |
| 23:48 | jgraham | goes to bed before he finds anything else to make him unhappy |
| 23:49 | <zcorpan> | benschwarz: no. i was going to ask you if you wanted to host a style sheet that i could point to in html5-elements so that the styles are up-to-date when you change stuff |
| 23:50 | <Hixie> | jesus |
| 23:50 | Hixie | reads the video content-type issue thread |
| 23:50 | <Hixie> | this bureaucracy is becoming ludicrous |
| 23:53 | <TabAtkins> | "becoming"? |
| 23:54 | <Hixie> | well it used to be that it wasted our time, but at least each time wasting resulting in movement forwards |
| 23:54 | <Hixie> | now apparently we have to waste our time going sideways |
| 23:55 | <Hixie> | and we're likely to end up with our furst normative difference between the whatwg and w3c specs, with the w3c one requiring that UAs honour content types, despite only one UA doing it, and the WHATWG one doing what foolip suggests (and using abarth's sniff spec and ignoring content-type for <video>) |
| 23:56 | <Hixie> | though apparently this would then only be a temporary thing because a few months later the wg would do the same thing |
| 23:56 | <Hixie> | i mean, that's literally process for process' sake and not for progress' sake |
| 23:56 | <Hixie> | at least until now there was some indication that the process was intended to make progress as well |
| 23:57 | <zcorpan> | Hixie: that's not how i understand the situation: the bug was about an editorial issue, and foolip's CP is considered out of scope for the original bug and should instead be filed as a separate bug which you can choose to accept regardless of the outcome of the editorial issue |
| 23:57 | <Hixie> | which julian would then object to |
| 23:57 | <Hixie> | and i'd have to revert it |
| 23:58 | <zcorpan> | did he say that he would object to it? |
| 23:58 | <Hixie> | i assume so |
| 23:58 | <Hixie> | he didn't say it, but i assume he would object |
| 23:58 | <Hixie> | otherwise why would he object now? |
