| 00:22 | <hober> | Hixie: here |
| 00:23 | <TabAtkins> | hober: Lunch sometime next week with Hixie and me (and tantek)? |
| 00:23 | <hober> | sure |
| 00:23 | <TabAtkins> | To talk about CSS and <dialog>/fullscreen? |
| 00:23 | <TabAtkins> | Kk, choose a date/place. |
| 00:23 | <hober> | i can head up to google, or i could host you guys here |
| 00:23 | <tantek> | sounds like a good plan. |
| 00:23 | <hober> | (i could also head to moz, of course) |
| 00:26 | <tantek> | I have a feeling I know where Hixie wants to eat lunch :) |
| 00:26 | <hober> | tuesday 3 april & thursday 5 april work for me |
| 00:27 | <TabAtkins> | Let's do Tuesday then. |
| 00:27 | <hober> | i guess monday would work as well for that matter |
| 00:27 | <hober> | ok |
| 00:29 | <hober> | noon? any particular google cafeteria? |
| 00:29 | <TabAtkins> | Dont' care that much. Gotta get to my bus now, though, so I can't do any more planning tonight. |
| 00:29 | <hober> | k |
| 00:30 | hober | is already on my bus |
| 02:59 | <roc> | why don't people understand the little-endian typed arrays issue? it seems so obvious |
| 03:06 | <zewt> | seems like just kenneth who's digging in his heels |
| 03:07 | <Hixie> | roc: you mean the way that we've basically made the web little-endian? |
| 03:07 | <roc> | yes |
| 03:07 | <Hixie> | i pointed that out literally years ago |
| 03:07 | <Hixie> | nobody seemed to care then either |
| 03:08 | <roc> | I don't care |
| 03:08 | <zewt> | IMO, if he refuses to budge on this, someone should fork the typed array spec and fix it; this is too important to let it be broken by an inexperienced developer |
| 03:08 | <roc> | not caring is the correct response. |
| 03:08 | <Hixie> | seems kinda short-sighted but certainly making it little-endian explicitly would be better than making it machine-endian specific |
| 03:09 | <zewt> | that's what's going to happen anyway (if a real big-endian browser ever actually exists, which may never happen) |
| 03:09 | <Hixie> | (i don't know what else we could do; asking authors to check the endianness and byte swap themselves is a non-starter0 |
| 03:09 | <Hixie> | s/0/)/ |
| 03:09 | <zewt> | ("real" meaning a nontrivial number of actual users use it, and it actually has modern API support, so this issue would have to be dealt with) |
| 03:10 | <roc> | if someone wants to push a big-endian architecture in the future, they need to give it byte-swapping loads and stores |
| 03:11 | <roc> | that's not hard at all, and would make the performance argument irrelevant as far as I can tell |
| 03:11 | <Hixie> | would the JS have to be different? |
| 03:11 | <zewt> | the performance argument is laughable |
| 03:12 | <roc> | Hixie: no, I think a big-endian machine could emulate little-endian behavior as far as JS could observe, quite easily |
| 03:12 | <zewt> | it goes like this: "every web developer should jump hoops for an optimization on a system that doesn't exist, may never exist, and which may not be a performance issue even if it ever does exist" |
| 03:12 | <roc> | :-) |
| 03:13 | <zewt> | Hixie: he's just saying (I think) that views would always be little-endian, hiding the big-endianness (as it should be) |
| 03:13 | <roc> | of course, even if you could persuade them to jump through those hoops, they'll probably get it wrong by accident anyway and will never know |
| 03:13 | <zewt> | the short-term problem is that we need big-endian views as well |
| 03:14 | <zewt> | and this make-believe of pretending views are native-endian means it's hard to get them |
| 03:14 | <Hixie> | so long as we're not exposing the machine's actual endianness, i don't really care what the api is |
| 03:14 | <Hixie> | native-endian just isn't workable |
| 03:14 | <zewt> | we all agree :) |
| 03:14 | <Hixie> | since there's no real big endian cpus out there, though, it doesn't much matter what the spec says |
| 03:14 | <zewt> | it's just the typed array editor who's (literally) refusing to even discuss it |
| 03:15 | <Hixie> | it'll be little-endian de facto |
| 03:15 | <zewt> | i know :) |
| 03:15 | <Hixie> | so why do you think the spec needs forking? |
| 03:15 | <zewt> | 1: having a spec that's wrong is bad, and needs to be fixed, and 2: we need big-endian views, not just (de-facto) little endian views |
| 03:17 | <zewt> | but since the editor is pretending views aren't little endian, there's no way to get him to add big-endian oens |
| 03:17 | <zewt> | also ones |
| 03:17 | <roc> | I will attempt to reason with him |
| 03:18 | <zewt> | i don't think i can write a diplomatic mail at the moment since his reply irritated me so much ("this won't be changed, no matter what arguments anyone gives"--really?), so I'm not going to reply tonight |
| 03:18 | <Hixie> | just implement what you want, the spec will follow |
| 03:20 | <zewt> | i suppose for now I'll just suggest in the encoding API thread that it just make up its own big-endian view type; that's lame, though |
| 03:28 | <Sirisian> | Hixie, Are you busy? |
| 03:28 | <Hixie> | have to be offline every few minutes for a bit but if you don't mind occasional latency i'm around |
| 03:28 | <Sirisian> | Did you ever have a chance to look at this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=11517 I replied to it a while back. not sure if the bug tracker sends out emails for replies to resolved bugs. I know it kind of seems unintuitive bug I think canvas could do well to implement simpler rendering methods that are capable of being more heavily optimized (that is no transforms). This goes along with the stencil operation bu |
| 03:28 | <Sirisian> | g. (I was going to post, but I accidently deleted a post I wrote a while ago that was basically using createImageData to make a binary stencil then allowing drawImageData to set it allowing for extremely optimized rendering). This original one: https://www.w3.org/Bugs/Public/show_bug.cgi?id=8396 |
| 03:28 | <Sirisian> | I took that as a yes. :) |
| 03:29 | <Hixie> | i generally go through all the feedback (1000s of e-mails and 100s of bugs) on a first-come-first-served basis |
| 03:29 | <Hixie> | so i'm sure i'll get to the bug in time |
| 03:30 | <Hixie> | looking at it quickly now i see no clear indication of what you want me to do though |
| 03:30 | <Sirisian> | ah okay. No rush. |
| 03:33 | variable | wonders if any browser vendor would consider adding an option to ignore autocomplete=off |
| 03:41 | <Hixie> | Sirisian: if you want me to do something you'll have to make a clear statement in the spec, or when i do get to it i'll probably just mark it needsinfo :-) |
| 03:42 | <Sirisian> | I'm thinking |
| 03:47 | <Sirisian> | drawImageData would just render without transforms taking in a raw ImageData object and only reference binary alpha (no complex blending is possible) and can optionally reference a set stencil buffer (another ImageData object). Then if you want to use a stencil you'd create it like: var stencil = context.createImageData(width, height); An addition I'd like is the ability to define the number of channels, but it's not necessar |
| 03:47 | <Sirisian> | y. That would look like createImageData(width, height, channels) so a person can specify the number of channels to create. Same for getImageData(x, y, width, height, channels) where channels would be an array to select channels like [0] to create a 1 channel ImageData of just the red channel. Then you can bind a stencil via context.stencil = stencil; Then you can render using drawImage(ImageData) which the stencil would only |
| 03:47 | <Sirisian> | work with. When drawing it would only use the first channel of the ImageData rendering the pixel only if the stencil isn't 0 at that place. (Context2D's Clip would still exist for everything else). This allow implementors to specialize the rendering code for with and without a stencil. |
| 03:47 | <Sirisian> | I actually typed this all out before like a few weeks ago and closed my browser at work and forgot about finishing it. |
| 03:52 | <Hixie> | i don't understand |
| 03:52 | <Hixie> | what's the use case? |
| 03:54 | <Sirisian> | Mostly so you don't have to incur the cost of rendering to canvas objects when manipulating imageData then rendering it back to a form to get simple alpha blending. The stencil is just an optimized clip algorithm that would be useful when rendering textures in say a canvas UI. |
| 03:55 | <Sirisian> | s/form/canvas |
| 03:56 | <Sirisian> | I might have to think about it some more. I think I wrote something down a while ago that made me rethink the binary alpha blending. |
| 03:57 | <Hixie> | that's not a use case, that's a solution |
| 03:57 | <Hixie> | or an optimisation |
| 03:57 | <Hixie> | or something |
| 03:57 | <Hixie> | a use case is something like "i want a platform game" |
| 03:58 | <Hixie> | (and then you slowly work up to the actual concrete problem you've run into that canvas can't do yet) |
| 04:07 | <Sirisian> | Yeah I'll create some use cases and post a more thorough explanation tomorrow. Thanks for the feedback. |
| 04:07 | <Sirisian> | If I don't argue myself out of requiring it :P |
| 04:08 | <Hixie> | :-) |
| 04:25 | <Hixie> | how do i _create_ an svg matrix? |
| 04:25 | <Hixie> | SVGMatrix, that is |
| 04:25 | <heycam> | Hixie, you can't create a standalone SVGMatrix |
| 04:25 | <Hixie> | ...oh. |
| 04:25 | <heycam> | they are only used as part of reflecting attributes |
| 04:25 | <heycam> | they will gain a constructor in SVG2 |
| 04:25 | <Hixie> | well that's gonna put a crimp in my comprehensive use of it in canvas. :-P |
| 04:26 | <Hixie> | what's the constructor look like in svg2? |
| 04:26 | <heycam> | it's not there yet, but it will at the very least include [Constructor()] |
| 04:26 | <Hixie> | looks like all the methods on SVGMatrix return an SVGMatrix |
| 04:26 | <heycam> | and probably one that takes components |
| 04:27 | <heycam> | oh |
| 04:27 | <heycam> | wait |
| 04:27 | <heycam> | I misremembered |
| 04:27 | <heycam> | the way you create an SVGMatrix *currently* is: anSVGSVGElement.createSVGMatrix() |
| 04:27 | <heycam> | i.e. you need an <svg> DOM object around |
| 04:28 | <Hixie> | ah ok |
| 04:28 | <heycam> | of course that sucks, and that's why we'll have constructors soon |
| 04:29 | <Hixie> | seems a bit wasteful the way that if you want to create a matrix that skews, rotates, and scales, you need to create a whole bunch of temporaries |
| 04:30 | <heycam> | I think there are pros and cons for both designs -- certainly would be nice to be able to modify the existing matrix tho |
| 04:31 | <zewt> | both are pretty equally common in matrix apis, in my experience |
| 04:31 | <heycam> | I think dino's proposed matrix interface had methods that modify the existing matrix |
| 04:31 | <zewt> | with the return-a-new-matrix looking prettier and the in-place approach usually being faster |
| 04:31 | <zewt> | (whether it is in JS, on modern archs, i'm not sure) |
| 04:37 | <zewt> | i guess mobile means the ubiquity of "modern archs" are set back by a good number of years... |
| 04:49 | <rniwa> | yay! undomanager is finally on w3c repository :D http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html |
| 04:49 | <Hixie> | publish an fsa :-) |
| 04:50 | rniwa | updates the date |
| 05:09 | <smaug____> | rniwa: so does the undomanager spec define how many managers per page? |
| 05:10 | <rniwa> | smaug____: it's supposed to be per document. |
| 05:10 | <rniwa> | smaug____: but i'm still not sure. |
| 05:10 | <rniwa> | smaug____: i'd have to talk with enrica about it at the contributor's meeting. |
| 05:11 | <rniwa> | smaug____: given that firefox and opera do this already, it might be okay for us to change our behavior |
| 05:11 | <rniwa> | smaug____: also from our last discussion, having one undo manager per editable field matches platform conventions |
| 05:11 | <Hixie> | on which platforms? |
| 05:11 | <smaug____> | Given this is a new API, I would prefer doing it right ;) |
| 05:11 | <rniwa> | smaug____: of course, you can also define undoScope attribute to define new undo manager |
| 05:11 | <rniwa> | smaug____: yes, that's why i haven't finalized it or started implementing it |
| 05:12 | <rniwa> | smaug____: editing is a mess |
| 05:12 | <rniwa> | smaug____: i don't want to create another mess :) |
| 05:12 | <smaug____> | it is |
| 05:12 | <rniwa> | Hixie: both Windows and Mac from what we could tell |
| 05:12 | <smaug____> | looks like the spec isn't too long... I'll try to look at is asap |
| 05:13 | <rniwa> | smaug____: yeah, I tried to be as brief as possible. |
| 05:13 | <Hixie> | rniwa: don't forget there are many other platforms that may act in weird ways... it's fine to optimise for windows and mac, but let's not make the other platforms impossible |
| 05:13 | <rniwa> | smaug____: as an implementor, i hate reading long specs |
| 05:13 | <rniwa> | Hixie: sure, but neither iOS or Android seem to support undos |
| 05:13 | <rniwa> | Hixie: what are other relevant platforms? |
| 05:14 | <smaug____> | linux |
| 05:14 | <Hixie> | some of the more esoteric platforms i was thinking of are those based on WordStar editing conventions, and Emacs. though in both cases i think they also do per-field undo. |
| 05:14 | <rniwa> | Hixie: i don't think emacs is a good example to follow here. |
| 05:14 | <Hixie> | it is if you're writing a web browser in emacs |
| 05:15 | <Hixie> | my point is "platform conventions" means the platform the browser is in, not "mac+windows" |
| 05:15 | <rniwa> | Hixie: sure. |
| 05:15 | <Hixie> | which today might usually be mac and windows, but the whole point of being platform agnostic is that we don't hardcode that kind of thing in :-) |
| 05:15 | <rniwa> | Hixie: but I don't think it makes sense for me to over-generalize the spec |
| 05:15 | <rniwa> | untile someone complains |
| 05:15 | <Hixie> | it'll be too late if you wait 20 years for a new platform to come along and someone to complain |
| 05:16 | <rniwa> | Hixie: i'm fine with making it platform dependent as well |
| 05:16 | <Hixie> | the web isn't supposed to be platform dependant |
| 05:16 | <rniwa> | Hixie: but then there will be script-visible behavior differences |
| 05:16 | <rniwa> | Hixie: huh? i don't understand your proposal then |
| 05:17 | <Hixie> | i'm saying the api should be designed such that it abstracts out platform differences and there are no script-visible differences regardless of what the platform's conventions are |
| 05:17 | <smaug____> | rniwa: I didn't see Hixie to propose anything ;) |
| 05:17 | <rniwa> | Hixie: we can either specify one behavior or make it platform dependent and define what behaviors are allowed |
| 05:17 | <rniwa> | Hixie: in this case, it's impossible. |
| 05:17 | <Hixie> | or at least, not any script-visible differences that can be distinguished from the user doing something |
| 05:17 | <Hixie> | rniwa: things that are impossible just take longer :-) |
| 05:17 | <rniwa> | Hixie: well but it is impossible in this case. |
| 05:18 | <rniwa> | Hixie: i don't want to explain all the details since i've already explained it once to smaug____ and Aryeh other day |
| 05:18 | <rniwa> | but there are many existing APIs that already expose this particular behavior. |
| 05:18 | <smaug____> | and to ehsan ... |
| 05:18 | <rniwa> | smaug____: right |
| 05:19 | <rniwa> | there's no point for us to add another layer of abstraction here since it's already visible to the scripts. |
| 05:19 | <smaug____> | but we can make the platform better now that we're adding a new API |
| 05:19 | <rniwa> | smaug____: we can specify it explicitly |
| 05:20 | <rniwa> | smaug____: or define possible behaviors that UAs can implement |
| 05:20 | <rniwa> | smaug____: the latter is harder but that'll let WebKit and Trident keep their current behavior |
| 05:20 | <MikeSmith> | rniwa: draft looks good -- I wouldn't worry much about adding more formatting to it at this point |
| 05:20 | <rniwa> | MikeSmith: ok. |
| 05:20 | <MikeSmith> | Hixie: fsa? |
| 05:21 | <Hixie> | final specification agreement |
| 05:21 | <MikeSmith> | ah |
| 05:21 | <Hixie> | the step in a CG that causes people to firmly commit their patents |
| 05:21 | <MikeSmith> | yeah |
| 05:26 | <MikeSmith> | Hixie: I just made date changes to the spec boilerplate |
| 05:27 | <MikeSmith> | so if you not otherwise planning to commit any more changes today, please push to W3C so that the W3C HTML and microdata specs get updated |
| 05:28 | <MikeSmith> | but if you are going to be committing again later today, then I'll just wait |
| 05:31 | <Hixie> | MikeSmith: roger, i can do that now |
| 05:33 | <Hixie> | MikeSmith: done |
| 05:33 | <MikeSmith> | thanks |
| 05:33 | <Hixie> | np |
| 05:41 | <rniwa> | Hixie, MikeSmith: speaking of which, I think our microdata APi implementation is near completion aside of vCard support and propertyNodeList |
| 05:41 | <rniwa> | (one of our contributors is working on propertyNodeList now) |
| 05:42 | <MikeSmith> | rniwa: excellent |
| 05:42 | <MikeSmith> | I think I'm cc'ed on the microdata api bug |
| 05:42 | <Hixie> | vcard support? |
| 05:43 | <MikeSmith> | rniwa: you know about http://w3c-test.org/html/tests/submission/Opera/microdata/001.html right? |
| 05:43 | <rniwa> | MikeSmith: oh nice |
| 05:43 | <rniwa> | MikeSmith: has opera implemented vcard support as well? |
| 05:43 | <MikeSmith> | dunno |
| 05:44 | <MikeSmith> | I don't know what implementing vcard support means .. |
| 05:44 | <MikeSmith> | seems maybe Hixie doesn't either |
| 05:44 | <MikeSmith> | with drag and drop? |
| 05:47 | <rniwa> | huh maybe it has been removed from the spec :\ ? |
| 05:47 | <rniwa> | MikeSmith: I swear the spec had mentioned vCard at some point |
| 05:47 | <MikeSmith> | yeah, it did |
| 05:47 | <rniwa> | MikeSmith: was it removed? |
| 05:48 | <MikeSmith> | it's in the whatwg spec |
| 05:48 | <MikeSmith> | http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#vcard |
| 05:49 | <MikeSmith> | ah |
| 05:49 | <MikeSmith> | http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#conversion-to-vcard |
| 05:49 | <rniwa> | MikeSmith: right, that. |
| 05:49 | <MikeSmith> | the conversion algorithm is what's being implemented for that I guess |
| 05:49 | <MikeSmith> | yeah |
| 05:49 | <Hixie> | i don't understand what a browser would do with that |
| 05:49 | <rniwa> | Hixie: yeah, i don't think it's a high priority for us |
| 05:49 | <rniwa> | Hixie: in theory, we could be exposing that using some UI |
| 05:50 | <rniwa> | Hixie: but as far as I know, it's not high priority for us |
| 05:50 | <rniwa> | so i've suggested not to proceed with that change for now |
| 05:50 | <rniwa> | especially since adding code like that to webkit could be rather controvertial |
| 05:51 | <Hixie> | i don't understand what it would mean for you to implement it |
| 05:51 | <Hixie> | it isn't intended for browsers to implement, certainly :-) |
| 05:51 | <rniwa> | Hixie: meaning that we would implement API for embedders to use. |
| 05:51 | <rniwa> | Hixie: webkit is also used by mail clients, etc... :) |
| 05:51 | <Hixie> | oh so not part of the web-exposed api? |
| 05:52 | <rniwa> | Hixie: oh, no. |
| 05:52 | <rniwa> | Hixie: i mean http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#conversion-to-vcard doesn't really define a web-facing API, does it? |
| 05:52 | rniwa | checks the spec. |
| 05:52 | <rniwa> | yeah i don't think it does |
| 05:52 | <matjas> | hsivonen: I was wondering why you use document.write("\u003C/script>") etc. on https://hg.mozilla.org/integration/mozilla-inbound/rev/e82fc6f3bceb |
| 05:53 | <Hixie> | rniwa: that's why i was confused :-) |
| 05:53 | <matjas> | hsivonen: "\u003Cscript>" could be just "<script>" and "\u003C/script>" could be just "<\/script>", right? or did gecko at some point implement HTML4 ETAGO parsing? |
| 05:54 | <rniwa> | Hixie: yeah, sorry for the confusing. i should have not really mentioned :) |
| 05:55 | <rniwa> | s/really // |
| 05:55 | <rniwa> | too much wekbit-ism there :P |
| 06:12 | <hsivonen> | matjas: Escaping < as \u003C is the single piece of advice that works for all problems. |
| 06:13 | <hsivonen> | matjas: even when I know I could use something else depending on context, I try to follow the advice I give to others |
| 06:13 | <matjas> | hsivonen: could you elaborate on that? what are the problems with using "</script>" and "<\/script>"? |
| 06:14 | <matjas> | i thought i had it figured out at http://mths.be/etago :( |
| 06:14 | <hsivonen> | matjas: "</script>" would break out of the script |
| 06:14 | <hsivonen> | matjas: "<\/script>" would work |
| 06:14 | <matjas> | yeah… so why bother with the Unicode escapes? |
| 06:14 | <hsivonen> | matjas: so I could have used "<\/script>" here |
| 06:15 | <hsivonen> | matjas: because they work for "\u003C!--" too |
| 06:15 | <matjas> | aah, there it is. that’s what i was missing, thanks! |
| 06:15 | <hsivonen> | matjas: and I want to give advice that works for both </script> and <!-- |
| 06:15 | <hsivonen> | matjas: and JSLint hates "<\!--" |
| 06:16 | <matjas> | btw, '\x3c' == '\u003c' if you wanna be concise ;) |
| 06:16 | <hsivonen> | matjas: so my canned advice is "replace < with \u003C and you are safe" |
| 06:17 | <Hixie> | i advise "don't do anything that requires strings involving <!-- or </script>" :-P |
| 07:21 | <zcorpan> | jslint should just accept <\!-- |
| 07:24 | zcorpan | fixed calc() and rgb() etc for hashless and unitless quirks |
| 07:36 | <hsivonen> | zcorpan: good luck getting JSLint changed to accept conforming JS |
| 07:41 | <zcorpan> | uh, maybe js*hint* |
| 07:49 | <zcorpan> | filed https://github.com/jshint/jshint/issues/499 |
| 08:08 | <zcorpan> | annevk: -76 had the random bytes after the first "request", and that's what firefox and opera implemented |
| 08:08 | <annevk> | k |
| 08:09 | <zcorpan> | i guess there was no evidence that the random bytes helped mitigate the attack completely |
| 08:10 | <annevk> | poor bz |
| 08:10 | <zcorpan> | ? |
| 08:10 | <annevk> | arguing with CP |
| 08:11 | <zcorpan> | oh |
| 08:14 | <roc> | hey, I started it |
| 08:16 | <tomasf> | yes you did; you invaded Poland |
| 08:19 | <wilhelm> | We were invited. Punch was served. |
| 08:23 | <annevk> | the whole typed array spec is kind of horrid |
| 08:23 | <annevk> | but then TC39 was way slow delivering something nice :( |
| 08:28 | gsnedders | wonders if TC39 should move to something easier to add new language APIs to, but then remembers that there are deliberately few APIs in ES iteslf |
| 08:29 | <hsivonen> | oh now it's harmful to speak the truth about aggregate Web developer behavior |
| 08:30 | <gsnedders> | ? |
| 08:30 | <hsivonen> | gsnedders: see chuck@jumis on the whatwg list in the thread referred to above |
| 08:33 | <matjas> | good catch, zcorpan: https://github.com/jshint/jshint/issues/499 |
| 08:33 | <matjas> | funny how everyone gave up on trying to get js_L_int fixed |
| 08:34 | <gsnedders> | Some people just are too self-righteous… |
| 08:35 | <annevk> | I think paying attention to him is the real problem here |
| 08:35 | <hsivonen> | seems like chuck@jumis is positing the existence of angel developers (per terminology defined in http://web.archive.org/web/20110501062035/http://diveintomark.org/archives/2004/08/16/specs ) |
| 08:44 | <hsivonen> | now there's an XSD approximation of XHTML5: http://xmlmind.com/xhtml5_resources.shtml |
| 08:50 | <zcorpan> | matjas: i now filed https://github.com/douglascrockford/JSLint/issues/114 as well, let's see how it goes |
| 08:50 | <matjas> | prediction: Crockford will just close it without even commenting |
| 08:51 | <zcorpan> | hsivonen: the first paragraph inspires great confidence |
| 08:54 | <zcorpan> | translation to English: "XMLmind has developed an initial version of an experimental, self-contained, W3C XML Schema for XHTML 5 which is implemented to the obsolete W3C Working Draft 25 May 2011 and has several limitations inherent to W3C XML Schema." |
| 09:07 | <MikeSmith> | hsivonen: looking at that schema now |
| 09:10 | <MikeSmith> | doesn't do case-insensitive matching of enumerated attribute values |
| 09:20 | <zcorpan> | ok so it needed another sentence, "Hasn't been properly reviewed yet is probably riddled with bugs." |
| 09:22 | <MikeSmith> | hsivonen: that schema is also using built-in xsd datatypes in ways that are not faithful to the spc |
| 09:22 | <MikeSmith> | *spec |
| 09:22 | <hsivonen> | So Android Market was rebranded to Google Play in order to cover movies and music, but in Europe only Android apps are available? |
| 09:22 | <hsivonen> | MikeSmith: not surprising |
| 09:22 | <MikeSmith> | yeah |
| 09:22 | <MikeSmith> | (about it not being surprising) |
| 09:23 | <MikeSmith> | hsivonen: fwiw in Japan at least I think it does have movies and music |
| 09:24 | <MikeSmith> | though I've never bought any myself |
| 09:24 | <MikeSmith> | and that part of the service is Japan-specific |
| 09:25 | <MikeSmith> | as in if there isn't a Japanese companies with rights to sell some movie in Japan, I'm sure it won't be in there |
| 09:43 | <annevk> | hmm not sure how to proceed with the big5 mess |
| 09:43 | <annevk> | the datasets are quite far apart |
| 09:48 | <charlvn> | hsivonen: some guy in the netherlands was able to install some google play apps (music, books and movies) on one of his devices but not the other |
| 09:48 | <charlvn> | hsivonen: http://www.androidworld.nl/113707/google-brengt-google-play-meer-onder-de-aandacht/ |
| 09:50 | <charlvn> | i'm more worried about what the heck is going on with that russian app; to think it's possible to cause that level of mayhem by using some application identifier... |
| 09:53 | <annevk> | out of the 19782 code points you can get, 6280 are distinct among the implementations |
| 09:56 | <hsivonen> | annevk: does any of them match some official truth from unicode.org? |
| 09:56 | <hsivonen> | them being the data sets |
| 09:57 | <hsivonen> | charlvn: what's "the russian app"? |
| 09:57 | <annevk> | 19782 - 6280 prolly does |
| 09:57 | <annevk> | I'm assuming the rest are proprietary extensions |
| 09:59 | <annevk> | I just generated all possible "valid" lead/trail byte combinations and then let various browsers generate the code points for me |
| 09:59 | <charlvn> | hsivonen: http://www.theverge.com/2012/3/26/2904389/google-play-bug-russian-email-app-samsung-android-seven |
| 10:01 | Ms2ger | ignores the TypedArray thread |
| 10:30 | <karlcow> | hsivonen: another issue of css vendor, that I came across a few days ago. Archived HTML. Be |
| 10:30 | <karlcow> | * packages |
| 10:30 | <karlcow> | * epub |
| 10:30 | <karlcow> | * html emails |
| 10:30 | <karlcow> | * saved files as… |
| 10:30 | <karlcow> | all of these will never be updated. |
| 10:56 | <hsivonen> | karlcow: there's probably quite a bit of -webkit-CSS in epubs by now... |
| 10:57 | <karlcow> | yup and in emails |
| 10:57 | <hsivonen> | karlcow: mail client-generated emails or separately-authored advertising mail? |
| 11:05 | <Ms2ger> | localStorage.clear(); |
| 11:05 | <Ms2ger> | w("foo" in localStorage); |
| 11:06 | <gsnedders> | Ms2ger: You will claim that that is always true in Opera. |
| 11:06 | <gsnedders> | Yes. |
| 11:06 | <gsnedders> | Known. |
| 11:06 | <Ms2ger> | Thanks |
| 11:06 | <karlcow> | hsivonen: mail client-generated email |
| 11:08 | <Ms2ger> | gsnedders, you know, a non-public BTS isn't too bad if someone can verify the existence of bugs from code snippets :) |
| 11:27 | <annevk> | giving times for meetings in something other than UTC when it's across country boundaries is just annoying |
| 11:31 | <annevk> | timezone boundaries* |
| 11:44 | <zcorpan> | annevk: about big5, just pick one (e.g. IE) |
| 11:46 | <annevk> | I guess I should have given some more data in that email |
| 11:47 | <zcorpan> | yeah i looked at the json file and didn't know what to do with it :-P |
| 11:47 | <annevk> | Personally I think IE would be fine too, but it maps an awful lot to PUA, which some people dislike; then there's the Firefox Taiwan team which provided custom mappings for Firefox which is radically different from most browsers, but they say works better... |
| 11:48 | <annevk> | If you have ideas on how to usually present the 6000 differences, they're welcome |
| 11:49 | <annevk> | maybe I should prefilter the lists and replace PUA with FFFD, and then count the differences again |
| 11:50 | <zcorpan> | if the firefox taiwan team have a mapping that works better, why not use that? |
| 11:51 | <annevk> | Firefox does not have majority market share |
| 11:52 | <annevk> | http://www.wantchinatimes.com/news-subclass-cnt.aspx?id=20110906000028&cid=1206 seems somewhat recent on that |
| 11:52 | <annevk> | which indicates it's mostly IE |
| 11:52 | <annevk> | and then Chrome |
| 11:54 | <annevk> | Chrome is pretty close to IE for big5 |
| 11:54 | <annevk> | only 62 differences |
| 11:54 | <annevk> | but big5-hkscs has about 6000 differences |
| 11:54 | <annevk> | IE treats it as an alias for big5 |
| 11:54 | <annevk> | afaict |
| 11:55 | <annevk> | that is, decoding as big5 and big5-hkscs gives identical arrays |
| 11:57 | <zcorpan> | how do the firefox taiwan team know that their mapping "works better"? |
| 11:58 | <annevk> | not sure |
| 11:58 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=310299 |
| 11:58 | <zcorpan> | i guess you should ask them :-) |
| 12:00 | <annevk> | basically Microsoft fucked Unicode |
| 12:00 | <annevk> | by supporting HKSCS via a font, for some set of their users |
| 12:01 | <annevk> | so if you install that font, big5 Hong Hong pages will look fine, but big5 Taiwan pages won't |
| 12:01 | <annevk> | or some such |
| 12:02 | <annevk> | all the other browsers have tried a different approach, but pages still declare the encoding incorrectly (big5 instead of big5-hkscs) so Hong Kong users either install extensions or manually override the encoding |
| 12:02 | <annevk> | this is what I read on the subject thus far |
| 12:03 | <annevk> | so you can't win |
| 12:03 | <annevk> | except by some expensive widespread evangelism maybe |
| 12:03 | <zcorpan> | so it seems to me that big5 and big5-hkscs should be aliases, but there should be two locale-specific encodings |
| 12:04 | <zcorpan> | one for hong kong and one for taiwan |
| 12:05 | <annevk> | that still doesn't help anyone else trying to read either |
| 12:05 | <zcorpan> | right |
| 12:05 | <annevk> | but that might be an improvement over the current situation |
| 12:07 | <zcorpan> | what do the extensions do? just override the encoding to one or the other? |
| 12:08 | <annevk> | http://www.google.com/support/forum/p/Chrome/thread?tid=466c210af3fb6d08 suggests so |
| 12:08 | <annevk> | which basically means they want to change the underlying table |
| 12:10 | <annevk> | PUA count: |
| 12:10 | <annevk> | opera-hk 0 |
| 12:10 | <annevk> | firefox 290 |
| 12:10 | <annevk> | chrome 6217 |
| 12:10 | <annevk> | firefox-hk 2985 |
| 12:10 | <annevk> | opera 0 |
| 12:10 | <annevk> | chrome-hk 664 |
| 12:10 | <annevk> | internetexplorer 6217 |
| 12:12 | <annevk> | now PUA, FFFD: |
| 12:12 | <annevk> | opera-hk 0 1199 |
| 12:12 | <annevk> | firefox 290 0 |
| 12:12 | <annevk> | chrome 6217 62 |
| 12:12 | <annevk> | firefox-hk 2985 0 |
| 12:12 | <annevk> | opera 0 6008 |
| 12:12 | <annevk> | chrome-hk 664 751 |
| 12:12 | <annevk> | internetexplorer 6217 0 |
| 12:14 | <hsivonen> | seems odd that totally different mappings in a non-market leader could work better. very odd. URL for the "works better" claim? |
| 12:14 | <zcorpan> | running a heuristic detector isn't reliable enough for people in hong kong or taiwan, i guess? |
| 12:14 | <annevk> | hsivonen: see the bugzilla URL above |
| 12:15 | <annevk> | the IE situation is basically that IE always uses the same mapping (to PUA) and then the font on Windows does the rest |
| 12:16 | <annevk> | it seems Chrome has better interoperability with IE there for at least big5 |
| 12:16 | <zcorpan> | but the font being present is acting like an override to the "other encoding", right? |
| 12:16 | <annevk> | no, it just shows different glyphs |
| 12:17 | <annevk> | the byte -> code point mapping is the same |
| 12:17 | <annevk> | it's like wingdings |
| 12:17 | <annevk> | a terrible solution |
| 12:17 | <zcorpan> | sure, i mean both taiwan users and hong kong users don't use the same font, right? |
| 12:17 | <annevk> | yeah |
| 12:17 | <hsivonen> | annevk: oh. IE depends on PUA fonts. I guess then different mapping might indeed be better |
| 12:18 | <annevk> | http://www.microsoft.com/hk/hkscs/ |
| 12:20 | <annevk> | hsivonen: yeah dunno |
| 12:21 | <annevk> | hsivonen: IE still has insanely high market share there, reportedly pages rarely use the big5-hkscs label, and Chrome has the same mapping as IE for big5 (apart from 62 out of ~20000 code points) |
| 12:27 | <annevk> | hsivonen: it would probably be good to flag big5 usage in Validator.nu |
| 12:35 | <hsivonen> | annevk: I guess, yeah. |
| 12:35 | <hsivonen> | annevk: no idea what tables V.nu has... |
| 13:22 | <charlvn> | http://www.internetsociety.org/20th/defining-moments-internet |
| 13:26 | <dinesh___> | lol |
| 13:27 | <dinesh___> | i believe that there was no internet before "www", "tcp/ip", "dns", "emails", "arpanet", "emails" and perhaps even rfc |
| 13:28 | <dinesh___> | so perhaps search engines.. |
| 13:28 | <zcorpan> | internet existed before www |
| 13:29 | <mainerror> | Before "Arpanet"!? |
| 13:29 | <dinesh___> | perhaps but that's not what most people think |
| 13:29 | <dinesh___> | ;) |
| 13:31 | <zewt> | what, are you saying "internet" and "web" aren't the same thing |
| 13:31 | <zewt> | crazytalk |
| 13:31 | <zcorpan> | seems rfc1 is dated 7 april 1969 |
| 13:31 | <zewt> | rfc1: "hello? is anybody out there?" |
| 13:33 | <zcorpan> | [ This RFC was put into machine readable form for entry ] |
| 13:33 | <zcorpan> | [ into the online RFC archives by Celeste Anderson 3/97 ] |
| 13:34 | <karlcow> | http://tools.ietf.org/html/rfc1 |
| 13:36 | <karlcow> | not sure what it tells me, but I'm almost as old as the first RFC. dinosaur. |
| 13:45 | <zcorpan> | annevk: heavenly? yeah, maybe, dunno :-) |
| 13:47 | <annevk> | euh lol |
| 13:50 | <zcorpan> | hmmmm. calc() needs to support unitless. argh |
| 13:51 | <zcorpan> | er |
| 13:51 | <zcorpan> | i mean rect() |
| 14:03 | <annevk> | aah, The Economist finally caught up and disabled my online access |
| 14:04 | <annevk> | there's only a GBP 30 difference or so between online and online + print |
| 14:05 | <annevk> | a little less for the first year; is print distribution really that cheap, or is online covering the costs? |
| 14:17 | <karlcow> | annevk: the paper/delivery bill is certainly a small percentage of the salaries. |
| 14:23 | <annevk> | but is it only 30 per year per printed magazine |
| 14:23 | <annevk> | a little less even |
| 15:25 | <smaug____> | hmm, should I add EventReceiver |
| 15:33 | <karlcow> | http://www.w3.org/community/webapps-ui/ |
| 15:43 | <annevk> | foolip: the arrays in big5.json are the code points found for these bytes: |
| 15:43 | <annevk> | while (leadbyte < (0xFE-0x81+1)): |
| 15:43 | <annevk> | while (byte < (0xFE-0x40+1)): |
| 15:43 | <annevk> | file.write(chr(leadbyte+0x81)) |
| 15:43 | <annevk> | file.write(chr(byte+0x40)) |
| 15:43 | <annevk> | if byte == 0x7E-0x40: |
| 15:43 | <annevk> | byte += (0xA1 - 0x7F) |
| 15:43 | <annevk> | byte += 1 |
| 15:43 | <annevk> | leadbyte += 1 |
| 15:43 | <annevk> | byte = 0; |
| 15:44 | <foolip> | annevk, as reported by charCodeAt I guess? |
| 15:44 | <annevk> | so 0x81 0x40 -> array[0] |
| 15:44 | <annevk> | foolip: almost |
| 15:44 | <annevk> | foolip: I combine surrogates |
| 15:45 | <annevk> | and for Opera I ignore a few code points less than 0x80 that follow a 0xFFFD |
| 15:45 | <annevk> | foolip: some stuff to get the data is here: http://dump.testsuite.org/encoding/big5/ |
| 15:45 | <foolip> | annevk, ok, are the PUA points that are mapped not in the BMP, or is it just that some stuff maps to CJK C? |
| 15:46 | <foolip> | annevk, do you already have a hunch for how you're going to spec this, or is it all just broken? |
| 15:47 | <annevk> | foolip: I don't know for big5; ideally someone tells me |
| 15:47 | <annevk> | foolip: the PUA is all in BMP |
| 15:47 | <foolip> | annevk, have you looked at what mapping iconv uses? |
| 15:47 | <dglazkov> | good morning, Whatwg! |
| 15:48 | <gsnedders> | foolip: On what system? |
| 15:48 | <foolip> | gsnedders, for which question? |
| 15:49 | <annevk> | foolip: no, but I think that would be the same as Chrome here |
| 15:49 | <foolip> | annevk, oh, Chrome more or less uses iconv? |
| 15:49 | <annevk> | foolip: but maybe not, but I don't really care about non-browser consumers, they're likely even more wrong :) |
| 15:50 | <foolip> | Perhaps |
| 15:50 | <gsnedders> | foolip: iconv varying between POSIX impls |
| 15:50 | <foolip> | gsnedders, oh, then I mean the one in GNU libc I guess |
| 15:51 | gsnedders | was no idea whether OS X has uts iwb ub this case |
| 15:51 | <gsnedders> | *its own in |
| 15:51 | <foolip> | annevk, mapping things to the PUA when they exist in Unicode proper seems worth avoiding, so some idea about what the compatible subset is would be sweet |
| 15:51 | <foolip> | Does Opera map to the PUA, for example? |
| 15:51 | <annevk> | no we don't |
| 15:52 | <annevk> | we map almost all of those to U+FFFD |
| 15:52 | <annevk> | apart from a few |
| 15:52 | <annevk> | big5 and big5-hkscs are also incompatible I'm told |
| 15:53 | <foolip> | As in, there are de-facto extensions to Big5 that conflict with Big5-HKSCS? |
| 15:54 | <annevk> | think so, not exactly sure how it relates to the standards |
| 15:54 | <annevk> | let me check our bug database, Peter explained somewhere |
| 15:55 | <foolip> | If IE is able to treat Big5 and Big5-HKSCS as synonyms it sounds like it's possible to sort out |
| 15:55 | <annevk> | foolip: see CORE-35726 |
| 15:55 | <foolip> | Unless the horrible truth is that the same code points are used for different glyphs in popular fonts in Taiwan and Hong Kong :{ |
| 15:55 | <annevk> | that's the thing |
| 15:55 | <annevk> | Microsoft ships HKSCS package for Hong Kong users |
| 15:56 | <annevk> | a package* |
| 15:56 | <annevk> | and that package includes different glyph mappings for some PUA code points |
| 15:56 | <foolip> | Ugh... |
| 15:56 | <annevk> | yeah, it's insane |
| 15:57 | <foolip> | Knowing which exact characters are in conflict would be useful |
| 15:58 | <Ms2ger> | Velmont, commented |
| 16:00 | <foolip> | annevk, from Peter's comments it looks like the conflicts are pretty trivial, where there exists duplicates in Unicode or at least very similar glyphs |
| 16:00 | <annevk> | http://coq.no/character-tables/chinese-traditional/en has some analysis, but not that much |
| 16:01 | <foolip> | annevk, I'd be happy to help out with this since I love both Chinese and Unicode, but it sounds like right now you don't really know where to start? |
| 16:03 | <annevk> | if we assume Microsoft is the dominant force I guess what you want is a) the difference in glyph mapping between users with and without the HKSCS plugin and b) the Unicode code points for all the ~6000 glyphs |
| 16:04 | <annevk> | and then maybe if they are not too incompatible provide a combined set of sorts |
| 16:04 | <annevk> | but presumably Microsoft would have done that if it were possible |
| 16:04 | <foolip> | Perhaps |
| 16:05 | <annevk> | if the difference is huge we could attempt to still avoid PUA (if the fonts work with that anyway, that might be another issue), and have different tables depending on locale |
| 16:05 | <foolip> | If possible, it would be great to have a look at the byte sequences that map to something different (in IE on Windows) in Big5 and Big5-HKSCS and screenshots of how those are actually rendered on a system with and without Microsoft's font package |
| 16:06 | <annevk> | the byte sequences map to the same code point afaict |
| 16:06 | <annevk> | although I have not tried installing the hkscs pack |
| 16:07 | <foolip> | They probably do, it would be odd for the mappings to depend on installed fonts. |
| 16:07 | <annevk> | hmm |
| 16:07 | <annevk> | "This HKSCS-2001 add-on software package is not compatible with Windows Vista™. Windows Vista has built-in support for HKSCS-2004." |
| 16:07 | <annevk> | I've been using Windows 7 |
| 16:08 | <foolip> | Sounds like they've already unified things somewhat? |
| 16:08 | <annevk> | maybe |
| 16:08 | <annevk> | guess I should ask someone from Microsoft how they deal with it now |
| 16:09 | <foolip> | Yeah, let me know if you need help staring at glyphs and telling if they are the same or not. |
| 16:09 | <foolip> | Time to leave now, bye! |
| 16:11 | <annevk> | thanks foolip |
| 16:29 | <annevk> | foolip: http://lists.w3.org/Archives/Public/www-archive/2012Mar/0046.html |
| 17:16 | <annevk> | I wonder if http://www.microsoft.com/download/en/details.aspx?DisplayLang=en&id=12080 is available as source code or something |
| 17:16 | <annevk> | what is .msi? |
| 17:17 | <annevk> | Windows installation it seems |
| 17:23 | <TabAtkins> | zewt: roc: I just talked with Ken about the Typed Array stuff, and he offered a pretty convincing defense of his position. |
| 17:23 | <TabAtkins> | Which was basically: |
| 17:24 | <TabAtkins> | 1) If you're generating data on the CPU for export to the GPU on the same device (common case for WebGL and WebAudio), endianness is irrelevant, because you don't really introspect the data. Using native endianness is best for performance, which is critical here. |
| 17:25 | <TabAtkins> | 2) If you're pulling data from the network, DataView handles the testing and byteswapping easily and automatically - all you need to know is the endianness of the incoming data. |
| 17:25 | <TabAtkins> | (Which can reasonably be big or little, depending entirely on file format.) |
| 17:25 | <TabAtkins> | If you're exporting to the network, DataView also takes care of that, automatically swapping to your desired endianness as necessary. |
| 17:25 | <gsnedders> | TabAtkins: However, almost all WebGL demos do more than just generate data, so 1 isn't relevant |
| 17:25 | <TabAtkins> | The problem is that FF only implemented DataView last week, so a lot of bad advice was given. |
| 17:26 | <gsnedders> | TabAtkins: 2 is good and fine in theory… but nobody does it. |
| 17:26 | <gsnedders> | Almost no WebGL demos work on BE devices. |
| 17:26 | <TabAtkins> | Existing WebGL demos that generate data solely on the device? |
| 17:27 | <gsnedders> | Nah, a few people did a while ago evangelize stuff for this. |
| 17:27 | <gsnedders> | bz probably more than anyone else, IIRC. |
| 17:27 | <TabAtkins> | I'm just curious about the exact shape of the failing demos. |
| 17:27 | <gsnedders> | Mostly 2, and assuming the typed array is LE |
| 17:28 | <TabAtkins> | Because Ken claimed that existing ones (that didn't rely on network data without using DataView) should work fine on either architecture. |
| 17:28 | <gsnedders> | Oh, they do. |
| 17:28 | <gsnedders> | But most WebGL stuff relies on network data without using DataView. |
| 17:28 | <TabAtkins> | And he argues that the reason nobody has used DataView is to a large extent because FF didn't implement it originally. |
| 17:28 | <gsnedders> | And as long as that's possible, web devlopers will do it, because nobody will test on BE. |
| 17:29 | <gsnedders> | Modulo people targetting TVs, who likely will. |
| 17:30 | <gsnedders> | (The Opera Devices SDK has been shipping WebGL for over a year now) |
| 17:30 | <TabAtkins> | He also argues that, based on long experience with the JVM, you can't do automatic endianness-swapping without killing performance. |
| 17:31 | <gsnedders> | I totally agree. But provided we make it possible to have web devs easily break stuff on platforms almost nobody uses, they will. |
| 17:31 | <Philip`> | TabAtkins: "performance, which is critical here" - the cost of swapping bytes when uploading to the GPU sounds like it should be generally quite trivial compared to the other costs of copying the memory to the GPU when implemented sanely (though I'm not basing that on any experience) |
| 17:32 | <gsnedders> | It's either have it not work or do endianness-swapping, practically. |
| 17:32 | <TabAtkins> | Philip`: Ken argues that it's not, because you have to hold onto a schema for the data in the CPU so you can do the swap properly just before exporting. |
| 17:32 | <gsnedders> | TabAtkins: I expect most people would use LE DataViews, so the cost is there on BE anyway |
| 17:33 | <TabAtkins> | gsnedders: I don't understand. DataViews don't have endianness - they're native too. You specify what the endianness of the incoming data is, and it swaps there. |
| 17:34 | <Philip`> | TabAtkins: I imagine an implementation that cared about performance would JIT the memcpy-with-fancy-byte-swapping code, rather than using an explicit schema representation |
| 17:35 | <TabAtkins> | Philip`: According to Ken, that hasn't been possible in the years of compiler research in the JVM. It breaks down into lots of virtual gets. |
| 17:35 | <gsnedders> | TabAtkins: You can do the same with the typed array, no? |
| 17:35 | <TabAtkins> | gsnedders: I'm not entirely sure I understand what you're asking. |
| 17:35 | <Philip`> | Virtual gets? |
| 17:36 | <gsnedders> | TabAtkins: You store the underlying array as native endianness. [[Get]] and [[Put]] convert the words they touch. Copying the array from CPU to GPU is quick (due to native endianness), as is taking a subarray. |
| 17:36 | <TabAtkins> | virtual calls when getting the data. I'm more-or-less quoting from memory there, I don't know about shit. |
| 17:37 | <gsnedders> | Or maybe [[Get]] and [[Put]] are perf critical |
| 17:38 | <gsnedders> | But that's basically what DataViews do, AIUI |
| 17:38 | <Philip`> | TabAtkins: I don't see why you'd want to do any virtual method calls when just copying an array of bytes (with no fancy getters or anything) into a new array of bytes |
| 17:39 | Philip` | wonders whether GPUs actually have the same endianness as their host CPUs |
| 17:39 | <TabAtkins> | Philip`: Because you need to byteswap sometimes? |
| 17:39 | <TabAtkins> | Philip`: According to Ken, yes. |
| 17:39 | <TabAtkins> | gsnedders: All I know is that Ken says DataViews solve the problem in a way that automatic swapping can't. Presumably that means swapping is done early. |
| 17:40 | <gsnedders> | Just do that for accesses of the whole array, have dataviews always have endianness, and then if you're using dataview you get high-perf 50% of the time. |
| 17:40 | <gsnedders> | Philip`: They do, by design, for just that reason. |
| 17:40 | <gsnedders> | TabAtkins: I don't believe we swap early, at least. |
| 17:43 | <Philip`> | TabAtkins: I don't see why the byteswapping would involve virtual method calls - it'd just involve reading 4 bytes from the input, doing a byte-swap instruction, then writing to the output array, and repeat for each field in the data structure that needs swapping, then loop, or whatever |
| 17:43 | <TabAtkins> | Ah, now that I've looked at the spec I see what's happening. This design seems somewhat suboptimal. |
| 17:44 | <TabAtkins> | There's no reason to have the desired endianness on the get calls unless you're trying to optimize for the case where a file is mixed-endian. |
| 17:44 | <TabAtkins> | It should be specified on the constructor I guess. |
| 17:45 | <gsnedders> | TabAtkins: It depends. |
| 17:45 | <TabAtkins> | That still doesn't let you swap early, though, unless you know the data's schema. |
| 17:45 | <gsnedders> | TabAtkins: There are cases when you want to read in a file of non-native endianness, change one word, and then write it out. |
| 17:46 | <TabAtkins> | Hm, I think I need to see an example of DataView being used with WebGL. |
| 17:46 | <gsnedders> | In that case, it will normally be quicker to just convert the one thing you want to change |
| 17:59 | <annevk> | success |
| 17:59 | <annevk> | well some |
| 17:59 | <annevk> | http://blogs.msdn.com/b/shawnste/archive/2007/03/12/cp-951-hkscs.aspx |
| 18:02 | <annevk> | http://lists.w3.org/Archives/Public/www-archive/2012Mar/0051.html sounds promising |
| 18:03 | <annevk> | so IE treats them as aliases, no longer has different mappings depending on locale |
| 18:03 | <annevk> | so IE's mapping, perhaps with some PUA code points replaced with actual code points, sounds like the best way forward |
| 18:03 | <annevk> | including merging big5 and big5-hkscs |
| 18:06 | <zcorpan> | nice |
| 18:10 | zcorpan | created http://simon.html5.org/tools/js/unicodeize/ for spec writing |
| 18:13 | <annevk> | hmm |
| 18:13 | <annevk> | now I know my name is full of boring code points |
| 18:29 | <TabAtkins> | zcorpan: Yay, useful! |
| 18:46 | <zcorpan> | if anyone knows why the selection thing doesn't work in firefox and chrome when tabbing away from the textarea, lemme know |
| 18:47 | <zcorpan> | or get firefox/chrome fixed :-P |
| 18:48 | <smaug____> | zcorpan: what selection thing? |
| 18:48 | <zcorpan> | in http://simon.html5.org/tools/js/unicodeize/ |
| 18:48 | <smaug____> | I guess I should try what happens in Opera |
| 18:48 | <smaug____> | ah, I see |
| 18:49 | <zcorpan> | http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#dom-selection-selectallchildren is the spec |
| 18:52 | <smaug____> | zcorpan: does the output element get focus event in FF/CH ? |
| 18:53 | <smaug____> | yes... |
| 18:54 | <zcorpan> | i don't seem to get an event in http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1437 |
| 18:55 | <zcorpan> | in chrome... get it in firefox when tabbing |
| 18:55 | <zcorpan> | not when clicking |
| 18:59 | <Hixie> | sweet kittens, our industry has a buzzword problem |
| 18:59 | <Hixie> | looks like "internet of things" is going to be the next "mobile web" |
| 19:00 | <zcorpan> | "internet of things"? |
| 19:01 | <rubys> | Hixie: I'd like to invite you to publish your complete Canvas 2D API editor's draft (including r7023 through r7038) at http://dev.w3.org/html5/2dcontext-hixie/ |
| 19:04 | <smaug____> | o_O |
| 19:04 | <smaug____> | will there be a separate canvas spec in W3C ? |
| 19:05 | <rubys> | eventually, there will be something after HTML5, yes. |
| 19:06 | <annevk> | what is going to be published at 2dcontext then? |
| 19:07 | <rubys> | At the moment, that's frozen at March 7th. It will certainly have the result of the issue 201 decision folded into it. At this point, Hixie's draft goes beyond that with other new features. |
| 19:08 | <Hixie> | rubys: a "hixie" version of the canvas spec would just be the html spec with the 2d api in the canvas section, i'm not sure it makes sense to have a "hixie" version of just the 2d api |
| 19:08 | <rubys> | ultimately this may need to be done to all the specs, but we don't need to do all at once, and it makes sense to delay that for as long as is reasonable for the base HTML5 spec. |
| 19:09 | <annevk> | so why not call it -next then? |
| 19:09 | <annevk> | or -dev |
| 19:10 | <annevk> | seems kind of weird to put the nick of the editor in the URL |
| 19:10 | <rubys> | -next may be presumptuous and spur lots of extraneous discussions. I simply would like to see it get out there to be discussed. That's the best way to lead to a discussion about what should be in "-next"... I would much rather see leading by doing than yet another argument over who gets the pen. |
| 19:10 | <rubys> | annevk: the IETF does that all of the time, no? |
| 19:10 | <rubys> | we could go with Hickson I guess |
| 19:11 | <Hixie> | the ietf is a perfect example of the mess that happens when we do that :-) |
| 19:11 | <zcorpan> | can't http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext be used for discussion? |
| 19:12 | <rubys> | Apple has patent concerns; Microsoft has other concerns. Simply republishing it in W3C space hopefully can get the technical discussions going instead of the non-technical ones. |
| 19:12 | <Hixie> | rubys: anyway, i'm happy to check in a draft that is a true "editor's draft" as opposed to the "majority draft" or whatever it is we have now; but as editor the only draft i'd be writing is a single html spec, like the whatwg's, not a split out set of specs. if you think that'd be helpful, though, i'd be happy to do that. |
| 19:13 | <Hixie> | the patent concerns are moot unless we publish a REC of the draft in question |
| 19:13 | <Hixie> | merely having it on dev.w3.org doesn't make any difference there |
| 19:14 | <rubys> | Hixie: I think it would be helpful if you were to publish a clearly separate Canvas 2D API spec, preferably under your name or nick, in W3C space. I am not suggesting that you change anything else about how you develop such a spec. I would prefer if this were not yet done for the other W3C specs at this time. |
| 19:15 | <annevk> | rubys: IETF also publishes in ASCII and text/plain |
| 19:15 | <Hixie> | rubys: i do not support having a separate canvas spec, so i would like to not frame it in such a way that it appears to be my choice |
| 19:15 | <rubys> | Hixie: I would be glad to frame it as something that I requested. |
| 19:16 | <Hixie> | rubys: there's a 2dcontext-LC/ directory in cvs right now that is woefully out of date, would it makes sense to copy what is currently in 2dcontext/ to 2dcontext-LC/ and then put 2dcontext/ back to tip-of-tree? |
| 19:16 | <annevk> | rubys: and actually, IETF only does that before a WG is formed |
| 19:16 | <annevk> | rubys: WG drafts don't have it |
| 19:16 | <Hixie> | rubys: (that seems like it would address your concerns and mine, if i understand yours correctly) |
| 19:17 | <rubys> | 2dcontext-LC is what went into LC1. We likely will need to have an LC2. What goes into those drafts will increasingly be locked down. |
| 19:17 | <rubys> | I think we need another draft that doesn't have those locks in place. I think the Canvas doc would be a great way to start. |
| 19:18 | <annevk> | didn't you just say you want to freeze it? |
| 19:19 | <rubys> | annevk: there will at least be the need to apply the decision that is made for issue 201 to the W3C LC2 Canvas API draft. |
| 19:19 | <annevk> | and that cannot happen in 2dcontext-LC? |
| 19:19 | <rubys> | but at the moment, nobody is proposing adding ellipse support to the W3C HTML5 version of Canvas. |
| 19:20 | <annevk> | well it seems several people are |
| 19:20 | <annevk> | but they are not jumping through hoops |
| 19:20 | <annevk> | so for some definition of "proposing" I guess they are indeed not |
| 19:20 | <rubys> | annevk: agreed that we aren't disagreeing here :-) |
| 19:20 | <zcorpan> | hsivonen: jslint fixed. jshint not yet. |
| 19:21 | <annevk> | zcorpan: myth busted |
| 19:21 | <karlcow> | - Mike "Pomax" Kamermans |
| 19:21 | <karlcow> | processing.js |
| 19:21 | <karlcow> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=14562 |
| 19:21 | <zcorpan> | now i should probably file separate bugs to *do* whine about "<!--" and "</script>" |
| 19:21 | <karlcow> | did ask |
| 19:22 | <karlcow> | which led to https://www.w3.org/Bugs/Public/show_bug.cgi?id=14579 |
| 19:22 | <rubys> | I stand by my original recommendation. I would really rather not have any name that appears presumptuous to the point where people feel the need to challenge it. |
| 19:22 | <Hixie> | rubys: is there any problem with using the existing 2dcontext-LC/ directory for the cherrypicked draft and 2dcontext/ for the wg draft? i don't understand your objection to that |
| 19:23 | <Hixie> | rubys: my objection to creating a third directory is that we are already littering the w3c space with obsolete copies of the canvas spec |
| 19:23 | <Hixie> | rubys: i keep getting people coming across old copies and asking me obsolete questions about them |
| 19:23 | <Hixie> | rubys: it's truly hurting interop |
| 19:23 | <Hixie> | rubys: mike did some work getting rid of some old ones, but there's still at least 3 already |
| 19:23 | <rubys> | hixie that will start a flame war that I simply don't want to fight right now. |
| 19:24 | <Hixie> | why would it start a flame war? |
| 19:25 | <rubys> | At the moment, what is in 2dcontext is what the HTML WG intends to be as a part of HTML5, and is subject to the revert policy in place. |
| 19:25 | <Hixie> | so just change that to be 2dcontext-LC/ |
| 19:26 | <rubys> | I am not willing to fight that battle at this time. If you wish, feel free to decline my request to publish this separately. |
| 19:26 | <zcorpan> | or, i guess the html validator already whines about <!-- and </script> |
| 19:27 | <Hixie> | well it's already published separately, the request is to publish a version of the spec that fulfills certain chair decisions but not others, right? |
| 19:27 | <Hixie> | i mean, i'm not really sure whose draft this would be |
| 19:27 | <Hixie> | it doesn't represent what i would like, so it's not an editor's copy; it doesn't represent what the wg would like, so it's not a majority copy, it's not what we're going to publish so it's not a TR/ copy... |
| 19:28 | <Hixie> | whose draft would it be? what process would it be under? what would decide what it contains? |
| 19:28 | <rubys> | What I am suggesting is a Hixie version of the spec be published. Whether parts of it are cherry picked for the HTML5 time frame or are fodder for an HTML.next has yet to be determined. |
| 19:28 | <Hixie> | a hixie version of the spec is already published: http://whatwg.org/html |
| 19:29 | <Hixie> | it has the exact same patent situation as a draft in dev.w3.org |
| 19:29 | <rubys> | My experience is that such a document will not attract participation by Microsoft, and in my opinion, that situation is suboptimal. |
| 19:30 | <Hixie> | nor does a dev.w3.org draft, really. the amount of microsoft input in the htmlwg has been so minimal as to be de minimis |
| 19:30 | <zcorpan> | rubys: you said microsoft has "other concerns". are they secret? |
| 19:31 | <rubys> | I am willing to make my request be an official request of a W3C co-chair. |
| 19:31 | <Hixie> | so then it'd be a chair's copy of the spec? |
| 19:32 | <rubys> | zcorpan: I haven't had that discussion with Microsoft, nor am I likely to. |
| 19:32 | <Hixie> | seems weird for the chairs to maintain (or ask someone to have maintain for them) a copy of the spec that doesn't match the very decisions they're handing down... |
| 19:33 | <rubys> | Hixie: the HTML WG has had a policy for a while allowing individuals to post specs. Mostly that demonstrated (as expected) that there is a sincere desire to converge. |
| 19:34 | <rubys> | We have asked you to revert 7023 pending a decision on 201. Now I see that there are other changes that haven't been proposed. I'd like to see those get published in W3C space and to have a version of the spec that evolves slower and stabilizes. |
| 19:36 | <Hixie> | i'm happy to push the changes to dev.w3.org so long as we don't increase the number of different copies of the 2d api spec fragment in doing so |
| 19:36 | <Hixie> | i'm pretty open to a variety of ways in which we could avoid doing that |
| 19:38 | <rubys> | I believe that the LC one is pointed to by an announcement at some point. Once we complete this LC work, we should be able to archive that one and point to the latest stable spec. |
| 19:39 | <rubys> | As I see it, there are two active threads, one that is winding down, and one that is ramping up. |
| 19:39 | <annevk> | cannot really find that announcement fwiw |
| 19:40 | <annevk> | also, it violates W3C policy to use the WD style sheet on dev.w3.org so that draft would have to change anyway |
| 19:40 | <Hixie> | it's not the announcements i'm worried about, it's people randomly running into the draft and thinking it's the latest copy |
| 19:41 | <Hixie> | i've found about 5 different copies of the canvas api and extensions to it in the last few minutes in w3.org space, none of which are up to date (since there isn't a mainline one currently, which is what sam is asking for me to add). |
| 19:43 | <rubys> | Microsoft appears to feel strongly about issue-201, so different people will have different perspectives on what is considered up to date. |
| 19:44 | <rubys> | Heck, I would gladly invite Microsoft to produce a copy of the 2D Canvas spec to their liking (and have a history of making exactly such request). |
| 19:45 | <Hixie> | that would probably not resolve my concerns of there being too many different copies of the spec. :-) |
| 19:46 | <rubys> | I'm Darwinian in that respect. I think it would, just perhaps not quickly. |
| 19:47 | <rubys> | Found the post I was looking for: http://intertwingly.net/blog/2009/08/06/Disappearing-Silverware |
| 19:48 | <Hixie> | well the last time you asked them to do that it resulted in an additional spec that is still there on dev.w3.org, in an Attic directory, so I think evidence suggests otherwise. :-) |
| 19:48 | <jgraham> | The problem with many copies of the spec is that the harm they cause is in the short term not the long term |
| 19:49 | <Hixie> | indeed |
| 19:51 | <rubys> | I don't see the harm caused by a directory clearly labeled as attic, and can see an argument that the W3C needs to put a plan in place to move the 1st LC draft into such. |
| 19:52 | <rubys> | I do see considerable harm as labeling a spec that contains one of two competing proposals as "the latest". |
| 19:53 | <Hixie> | you're not the one fielding e-mails from people every day asking for clarifications about issues in the spec that were fixed months or years earlier, caused merely because they are looking at the TR/ page, or some random CVS-deleted Attic/ file, or whatnot. |
| 19:54 | <Hixie> | an alternative way to solving this problem, if we can't come to an agreement on how to have the latest copy in dev.w3.org, would be for the relevant issue to be resolved sooner rather than later. |
| 19:55 | <rubys> | at the moment, we have no counter proposal to issue 201, nor any proposal for the other additions that you have been making. |
| 19:55 | <rubys> | I've also seen reference to your plans for a v6 and beyond. |
| 19:56 | <Hixie> | well, to be fair, you do have a counter proposal, you just don't have one that's been written up in the bureaucratic way you'd like. You even asked for the counter-proposal to be reverted, so you can't say you don't know about it. :-) |
| 19:57 | <rubys> | To me a complete proposal would include rationale. |
| 19:58 | <Hixie> | the rationale is presumably the same |
| 19:59 | <Hixie> | rubys: looking at the existing -201 issue, i can confirm that the exact same rationale would apply to what was reverted |
| 20:00 | <rubys> | In any case, I've made my request. If there is anything I can do to convince you to leave the stable copy as it stands and publish a -hixie version along side it, please let me know. |
| 20:00 | <Hixie> | rubys: if you like i can submit a CP that is identical in every way except the details section, but that just seems like bureaucracy for the sake of bureaucracy |
| 20:00 | <rubys> | would that CP include ellipse? |
| 20:00 | <Hixie> | sure, why not |
| 20:01 | <Hixie> | they're part of the Path object, after all |
| 20:01 | <Hixie> | how else would you make accessible ellipsoid hit regions? |
| 20:02 | <Hixie> | gotta go, lunch |
| 20:02 | <Hixie> | bbiab |
| 20:03 | <rubys> | looking at http://html5.org/tools/web-apps-tracker I see a number of changes that appear to go beyond hit testing. |
| 20:04 | <rubys> | I'll wander off, but I would like to see a -hixie draft and a Change Proposal that describes why what appears in that draft is a better fit for HTML5 than what is in http://www.w3.org/wiki/Canvas_hit_testing . |
| 20:58 | <annevk> | why does data:text/html,&%23x26BD; (soccer ball) not render in browsers other than Safari? |
| 21:13 | <TabAtkins> | Because most people don't have a font that'll display it, but Safari's last resort font has a bunch of emoji stuff, and so maybe has a soccer ball too? |
| 21:13 | <TabAtkins> | There's nothing wrong with the url - it produces the correct character in the page. |
| 21:16 | <annevk> | seems like a bug of sorts to me |
| 21:18 | <TabAtkins> | What, the non-rendering? |
| 21:19 | <TabAtkins> | That's not a bug, it's font support. There's nothing buggy about it. |
| 21:20 | <TabAtkins> | Change your url to a character that the default font stack can render, and it works fine. |
| 21:20 | <annevk> | given that my OS has such a font, I would expect browsers to render it |
| 21:21 | <TabAtkins> | They can't realistically search your entire set of OS fonts when attempting to render a page. |
| 21:21 | <TabAtkins> | And I don't think OSes provide a utility for quickly asking "do you have a font that can render this character?". |
| 21:21 | <TabAtkins> | You can bug them to improve their default stack, of course. |
| 21:22 | <annevk> | doesn't mean it doesn't seem like a bug of sorts :) |
| 21:22 | <annevk> | right |
| 22:04 | jwalden | sees the soccer ball in Firefox in F15 |
| 22:04 | <jwalden> | guess I have enough fonts installed for it |
| 22:10 | <zewt> | TabAtkins: that's not convincing at all, because it assumes incorrectly that views are only ever used for creating data that you hand off to WebGL |
| 22:10 | <zewt> | that's just obviously false |
| 22:13 | <gsnedders> | See: pdf.js. |
| 22:13 | <zewt> | the solution is to define both these views and all WebGL access as little endian, say "if you're big-endian, you're on your own", and then ignore big endian because big endian is dead |
| 22:14 | <TabAtkins> | Using a DataView, particularly once it's been expanded to be as easy to use as the other array views, seems to be the preferred answer. |
| 22:14 | <zewt> | dataview is completely irrelevant |
| 22:14 | <TabAtkins> | Why so? |
| 22:14 | <zewt> | views exist, so people will use them; dataview existing doesn't change taht |
| 22:14 | <zewt> | also that |
| 22:14 | <zewt> | we can't remove alert() just because there are other ways to display messages; people use alert |
| 22:15 | <TabAtkins> | DataView is meant to be *the* way to send/receive from servers. |
| 22:15 | <zewt> | but it *isn't* |
| 22:15 | <TabAtkins> | Right now, sure. Because DataView wasn't widely implemented. |
| 22:15 | <zewt> | views exist, and people use them (and I'll use them, because it's much nicer to have an array view of an array instead of calling a function) |
| 22:15 | <zewt> | doesn't matter--views still exist and will still be used |
| 22:15 | <TabAtkins> | And so any advice about how to use TypedArrays *today* can't reasonably tell people to use DataViews. |
| 22:16 | <gsnedders> | zewt: Big endian is *not* dead because typed arrays are done for things apart from WebGL. pdf.js, for example. |
| 22:16 | <TabAtkins> | The "array view of an array" thing is the "once DataViews are fixed up to be as convenient as the other arrays" thing. |
| 22:16 | <zewt> | gsnedders: find me a marketshare % of big endian systems and tell me it's not dead, heh |
| 22:16 | <zewt> | (of big endian systems that implement modern APIs, including ArrayBuffer and WebGL) |
| 22:17 | <TabAtkins> | From what I understand, a number of file formats (that you may want to read with an arraybuffer) are big-endian. |
| 22:17 | <gsnedders> | zewt: Well, of BE systems, yes, but file formats are still often BE. |
| 22:17 | <smaug____> | aklein: ping |
| 22:17 | <zewt> | (why is Firefox's address bar autocomplete so utterly broken? I type "typed arrays", hit enter; I see that it had the typed array spec selected when I was at "typed", but then it decided to jump to some random google search when I finished typing) |
| 22:17 | <aklein> | smaug____: pong |
| 22:17 | <zewt> | gsnedders: file formats aren't the issue (there *should* be explicitly big-endian views) |
| 22:17 | <smaug____> | aklein: about attribute filters |
| 22:18 | <smaug____> | aklein: sicking suggested that attribute filter applies only to non-namespaced attributes |
| 22:18 | <jgraham> | TabAtkins: Surely you have done the web thing long enough to know that if there are two ways to do something and one is wrong, authors will do the wrong way 80% of the time, the right way 10% and invent an entirely new and wrong way 10% |
| 22:18 | <smaug____> | aklein: what do you think about that |
| 22:18 | <zewt> | TabAtkins: DataView is an inherently less convenient API than views, for accessing arrays |
| 22:18 | <TabAtkins> | I'd say the percentages are more balanced, overall. They don't *instinctively* reach for the bad one. They just do it randomly, like a gas filling a room. Brownian motion and all that. |
| 22:18 | <TabAtkins> | zewt: Yes. Right now. |
| 22:19 | <zewt> | jgraham: (I object to the idea that accessing arrays inside a file format via views is "wrong"; it's the right, clean thing to do, and the "design" is wrong) |
| 22:19 | <zewt> | TabAtkins: what is "right now"? who is proposing changes to it? |
| 22:19 | <smaug____> | aklein: I don't care too much, but would could change my patch (which sicking is reviewing) if you agree with the change |
| 22:19 | <smaug____> | s/would// |
| 22:19 | <zewt> | the only thing needed are eg. Int16BEArray, etc |
| 22:19 | <TabAtkins> | zewt: Ken? |
| 22:19 | <jgraham> | zewt: Sure. I was thinking of an abstract example |
| 22:19 | <aklein> | smaug____: I don't care too much either, but I think we'd have to change our code too |
| 22:20 | <sicking> | aklein: it seems to me that if someone observes the "value" attribute, and a page modifies the "xlink:value" attribute and we notify the observer, it seems unlikely that the observer would check that it's the "correct" value attribute that is changed and just assume that any notifications is to the attribute that it cares about |
| 22:20 | <zewt> | one thing I need to recommend is that Int16LEArray (and friends) be added, so people can at least sidestep the issue |
| 22:20 | <jgraham> | My point was just that saying "but there is a way to get this right" has never been good enough |
| 22:20 | <TabAtkins> | zewt: I don't know how you'd use a normal view to access data from a BE file format with varying-width records. |
| 22:20 | <zewt> | but kenneth has dug in his heels on this so far he seems unwilling to do anything at all |
| 22:20 | <jgraham> | There is a way to generate well-formed XML, but that didn't happen either |
| 22:20 | <zewt> | TabAtkins: views are used for arrays (fixed-width); variable-width (eg. structs) *is* what DataView is good for |
| 22:20 | <TabAtkins> | zewt: I now understand his reasoning a bit better. It seems correct that trying to do LE everywhere would just mean "BE devices get *really slow* WebGL". |
| 22:21 | <zewt> | TabAtkins: that's the only possible thing that can happen |
| 22:21 | <zewt> | the alternative is "big-endian devices get broken WebGL" |
| 22:21 | <jgraham> | TabAtkins: Instead they will get broken WebGL |
| 22:21 | <TabAtkins> | Rather than the current one, which is "BE devices break when you're reading data that you assumed was LE". |
| 22:21 | <zewt> | that's not correct; that's wrong |
| 22:21 | <TabAtkins> | I've been told that, right now, BE devices work just fine in WebGL with typed arrays. |
| 22:21 | <zewt> | you *should* be able to assume everything is little-endian. because nobody is, and nobody should have to, test on obscure big-endian devices; this is web 101--interoperability |
| 22:22 | <TabAtkins> | They fail when you pull binary data off the network without using a dataview. |
| 22:22 | <zewt> | which is broken |
| 22:22 | <sicking> | aklein, smaug____: It seems to me that only observing the null-namespace is less bug-prone, and at least in the gecko implementation simpler since we wouldn't have a attributeNamespace property on MutationRecord |
| 22:22 | <zewt> | you should never have to care about the endianness of the system you're on; it should have no visible effects on code, ever; and you should definitely not have to test on it |
| 22:23 | <aklein> | sicking: now I'm a bit confused, are you saying attributeFilter won't stop the observer from telling me about _all_ namespaced attributes? |
| 22:23 | <zewt> | it doesn't matter that fixing it makes big-endian systems slow--and who cares? nobody's making big-endian platforms anymore |
| 22:23 | <smaug____> | sicking: it wouldn't change the record |
| 22:23 | <smaug____> | sicking: only about filtering |
| 22:23 | <jgraham> | TabAtkins: I am 100% sure that wih the current setup BE devices will be broken on most real sites that depend on binary data |
| 22:23 | <smaug____> | sicking: record must have the namespace |
| 22:23 | <sicking> | smaug____: how so? |
| 22:23 | <TabAtkins> | zewt: Shrug. From what I've heard, making the LE-everywhere assumption means that the common WebGL/WebAudio/other APIs that both generate and consume data in-page will be unacceptably slow on BE devices. |
| 22:23 | <smaug____> | because you need to know which attribute changed |
| 22:23 | <TabAtkins> | They're "work", but that's irrelevant. |
| 22:23 | <sicking> | smaug____: oh, for when you are observing all attribute changes? |
| 22:24 | <TabAtkins> | *They'll |
| 22:24 | <zewt> | what BE devices? |
| 22:24 | <smaug____> | sicking: yes |
| 22:24 | <jgraham> | TabAtkins: I would like some proof of that with actual hardware |
| 22:24 | <TabAtkins> | zewt: Aren't you assuming that BE devices exist and are important? |
| 22:24 | <TabAtkins> | jgraham: Ask Ken. He alluded to years of experience with Java's NIO. |
| 22:24 | <sicking> | aklein: sorry, yeah, so it wouldn't simplify the implementation a lot, but it seems less bugprone when attribute filters are used |
| 22:25 | <jgraham> | Then I would like someone that actually ships in those devices to say taht they would prefer the site to not work than to be slow |
| 22:25 | <jgraham> | s/in/on/ |
| 22:25 | <zewt> | no, I want this fixed so other APIs (eg. encoding API) don't keep getting derailed with "well we can't return UTF-16LE as Int16Array because it's native endian!" nonsense |
| 22:25 | <TabAtkins> | jgraham: "Slow", past a certain point, is a synonym for "doesn't work". |
| 22:25 | <aklein> | sicking: I assume this discussion is happening on a review, can you send the link? |
| 22:25 | <TabAtkins> | jgraham: You wouldn't play a videogame running at 3fps. ^_^ |
| 22:25 | <zewt> | also, because it's a major, infrastructural API, and shouldn't have serious fundamental errors in the spec that everyone has to wink and ignore |
| 22:25 | <jgraham> | TabAtkins: Do you have any data to say we are remotely at that point? |
| 22:26 | <sicking> | aklein: still reviewing, but when i submit the review it'll appear here: https://bugzilla.mozilla.org/show_bug.cgi?id=641821 |
| 22:26 | <TabAtkins> | jgraham: Ken asserts that we are. I have no further data than that. |
| 22:26 | <jgraham> | That's not useful |
| 22:26 | <TabAtkins> | jgraham: Sorry. He provided some limited assertions in his recent emails. If you want more detail, respond there. |
| 22:26 | <jgraham> | (someone who has already made up their mind backing up their position with an assertion but no data) |
| 22:27 | <aklein> | sicking: ah, ok, was hoping you'd laid out your suggestion there. what I'm wondering is, if I observe with attributeFilter == ['foo'], will I hear about changes to someNamespace:bar? or will I not hear about any namespaced attributes if I have an attributeFilter? |
| 22:27 | <smaug____> | (aklein: sicking is shouting comments about the patch and API from the other side of the table) |
| 22:27 | <TabAtkins> | zewt: From what I understand, we're screwed anyway. If it's not native-endian, performance-critical stuff like WebGL won't work. If it is native-endian, naive use of the API will break on unexpected endianness. |
| 22:28 | <jgraham> | (and "doesn't work" is always a synonym for "doesn't work". The only way the curent situation could end well is if BE devices became so common that people had to test on both. I would bet on the opposite) |
| 22:28 | <TabAtkins> | Luckily, the "worst case" that's been talked about (the author having to test and manually reorder bytes) doesn't exist once you have DataView. |
| 22:28 | <sicking> | aklein: sorry, i don't remember enough of the spec. If you observer with attributeFilter == ['foo'], would you hear about changes to bar (in null namespace)? |
| 22:28 | <jgraham> | Which authors won't use... |
| 22:28 | <TabAtkins> | DataView still isn't maximally convenient, but it doesn't seem hard to come up with usability improvements. |
| 22:28 | <zewt> | TabAtkins: web-compat trumps performance |
| 22:28 | <aklein> | sicking: no |
| 22:28 | jgraham | -> sleep |
| 22:29 | <TabAtkins> | zewt: Make up a new LE-only binary data that you can use for non-performance-critical stuff, then. |
| 22:29 | <sicking> | aklein: ok. Then no. I don't think you should hear about someNamespace:bar, nor someNamespace:foo either |
| 22:29 | <zewt> | especially since the performance thing is meaningless (what BE platforms are there that this is actually optimizing for?) |
| 22:29 | <smaug____> | aklein: so the if you have filter you wouldn't get records about any namespaced attribute changes |
| 22:29 | <sicking> | aklein: i.e. there would be an implicit "null:" on everything in the filter |
| 22:29 | <zewt> | TabAtkins: ... sorry, what? |
| 22:29 | <TabAtkins> | zewt: I'm confused. You are questioning whether there are any BE platforms worth optimizing for. But then you complain that other APIs will break on BE platforms. |
| 22:29 | <TabAtkins> | Do you care about BE platforms or not? |
| 22:30 | <sicking> | aklein: namespaced attributes are used extremely rarely. It's only used in SVG and XBL1 as far as I know |
| 22:30 | <TabAtkins> | sicking: And SVG is dropping them in SVG2. |
| 22:30 | <aklein> | sicking: yeah, I'd be fine with this for that reason |
| 22:30 | <sicking> | TabAtkins: woohoo!!!! |
| 22:30 | <aklein> | seems like DOM4 is trying to deprecate them too |
| 22:30 | <TabAtkins> | Fucking XLink. |
| 22:30 | <zewt> | i've never claimed to care about BE platforms, but the argument that we need a broken spec that nobody would ever implement (if there ever were any) in order to optimize for those systems is just nonsense |
| 22:30 | <aklein> | (at least by deemphasizing them in the spec text) |
| 22:30 | <smaug____> | aklein: how is DOM4 trying to deprecate them? |
| 22:31 | <TabAtkins> | zewt: I'm still confused, though. Your *vehement* objection to the current spec seems to be predicated on things breaking in BE platforms. |
| 22:31 | <aklein> | smaug____: sorry, not "deprecate" so much as emphasizing the null namespace case |
| 22:31 | <shepazu> | sicking: doesn't RDFa use namespaced attributes? |
| 22:31 | <TabAtkins> | But then you dismiss arguments about performance on BE platforms. |
| 22:31 | <sicking> | shepazu: please god no! |
| 22:31 | <TabAtkins> | shepazu: No. |
| 22:31 | <shepazu> | it did at one point, I thought... |
| 22:31 | gsnedders | cares about web-compat and perf. on BE platforms |
| 22:31 | <zewt> | TabAtkins: my objection is that the spec is unimplementable, and doesn't reflect reality |
| 22:31 | <aklein> | smaug____: but this is why I don't care much about dropping them: I never use 'em |
| 22:31 | <smaug____> | :) |
| 22:31 | <gsnedders> | However, I don't think there's a solution that solves both. |
| 22:32 | <zewt> | (unimplementable due to web compat, that is) |
| 22:32 | <TabAtkins> | zewt: Your charge of "unimplementable" is based on BE platforms having problems with it due to breakage. |
| 22:32 | <TabAtkins> | So once again, do you care about BE platforms or not? |
| 22:32 | <smaug____> | aklein: sicking: I'll file a spec bug |
| 22:32 | <zewt> | why are you asking me questions that I just answered? |
| 22:32 | <TabAtkins> | Because you'r enot answering them. |
| 22:32 | <zewt> | i type fast enough already; I don't need practice |
| 22:32 | <sicking> | smaug____: awesome, thanks! |
| 22:32 | <TabAtkins> | gsnedders: That's my fear. |
| 22:33 | <TabAtkins> | gsnedders: If Ken can be proved wrong regarding the perf concerns, great. But he is experience in this, so I'm inclined to trust him. But I'm also clueless about this, so shrug. |
| 22:33 | <gsnedders> | TabAtkins: I'd rather go for web-compat and slow than no web-compat and fast in the short term. |
| 22:33 | <shepazu> | which devices are BE? ARM-based, or what? |
| 22:33 | <gsnedders> | I don't know what the relative bottle-necks are with this stuff. Depends on what you're using them for. |
| 22:34 | <TabAtkins> | zewt: You keep dismissing the "native endianness is needed for perf" by saying "who cares about perf on BE platforms?". But then you argue against native-endianness by saying that it breaks on BE platforms. |
| 22:34 | <gsnedders> | shepazu: ARM is almost entirely LE now. Some MIPS stuff is. |
| 22:34 | <TabAtkins> | shepazu: Yes, ARM is the major one. |
| 22:34 | <gsnedders> | TabAtkins: What major ARM device is BE? |
| 22:34 | <gsnedders> | (That can run a web browser) |
| 22:34 | <TabAtkins> | gsnedders: Maybe, but like I said, past a certain point "slow" means "broken" for things like games. |
| 22:34 | <TabAtkins> | gsnedders: I have no clue. I thought I'd been told that ARM is BE. |
| 22:35 | <gsnedders> | Android, iOS, Sybmian, Windows Phone… they all use LE mode. |
| 22:35 | <zewt> | TabAtkins: specs that are interoperable and don't expose platform obscurities is much more important than performance on obscure platforms |
| 22:35 | <gsnedders> | TabAtkins: Many RISC CPUs, ARM inc., are bi-endian. |
| 22:35 | <gsnedders> | Most bi-endian CPUs nowadays are used in LE mode. |
| 22:35 | <zewt> | gsnedders: qualify: "run a modern web browser" (eg. with WebGL, ArrayBuffers, the rest) |
| 22:35 | <gsnedders> | zewt: Pretty much that dfn |
| 22:36 | <TabAtkins> | zewt: Once again, that doesn't answer my question. Bad perf, in certain contexts, is equivalent to "broken". So you're saying that it's bad that the API is broken in BE platforms under some circumstances, but it doesn't matter that it's broken in BE platforms under other circumstances. |
| 22:37 | <zewt> | you can always get bad performance; you can't make that go away (you can always write WebGL apps that tax the GPU so that it's only practically usable on a desktop); so no, I don't consider slow as equivalent to broken |
| 22:37 | <gsnedders> | TabAtkins: Bad perf in certain contexts or broken in most contexts is the option here. |
| 22:37 | <TabAtkins> | Your argument is thus inconsistent. You could instead be arguing that you think perf is an irrelevant circumstance, but you haven't made that argument so far. |
| 22:37 | <zewt> | you're the only one claiming that slow == broken |
| 22:38 | <TabAtkins> | zewt: For games, it is. Do you challenge that assertion? |
| 22:38 | <TabAtkins> | For a game designed for 30fps, you can't reasonably play it at 3fps. |
| 22:38 | <TabAtkins> | It's functionally equivalent to the game throwing an error immediately, for all the good it does you. |
| 22:39 | <gsnedders> | TabAtkins: Most BE hardware with modern web browsers, even if content was delivered in BE form with native arrays, couldn't really push a 30fps game. |
| 22:39 | <zewt> | so you're saying WebGL is broken because it's possible to write a game that requires the fill rate of a $500 Geforce, and runs at .1FPS on a phone? |
| 22:39 | <zewt> | the game doesn't work, but that's not a bug in the spec or the API |
| 22:39 | <zewt> | likewise, if byte swapping makes your app too slow to run, that's unfortunate but not a bug |
| 22:39 | <TabAtkins> | zewt: Strawman. It's definitely possible to design a game optimized for phone-level hardware. The perf drop is then significant. |
| 22:40 | <TabAtkins> | I'm unsure why you think "too slow to run" isn't a problem. |
| 22:40 | <zewt> | it's not at all equivalent to the API being broken, which the spec currently is |
| 22:41 | <gsnedders> | TabAtkins: Somehow we need a solution that allows interop in all cases, even with bad perf if you use the wrong API on the wrong hardware. |
| 22:41 | <TabAtkins> | ...it's exactly the same. You use the API, it runs fine on your platform, but it's unusable on other platforms. |
| 22:41 | <gsnedders> | That's my opinion, on the whole. |
| 22:41 | <TabAtkins> | That's equivalent to using the API and it erroring out on other platforms. |
| 22:41 | <zewt> | i'm also a bit appalled that anyone with any web experience is actually seriously arguing that it's okay to force web developers to care about endianness |
| 22:41 | <gsnedders> | However, I think the shit has mostly sailed. |
| 22:42 | <gsnedders> | So practically we might be unable to do little more than spec stuff as LE |
| 22:42 | <Hixie> | any web intents people around? |
| 22:42 | <TabAtkins> | gsnedders: I'm normally with you, but bad perf is *really* killer for gaming, which is a case I'd like to strongly support. So I'd prefer something that doesn't have bad perf, and is easy to use in a compat way. |
| 22:43 | <gsnedders> | TabAtkins: What I'm basically suggesting there is always a way to get native perf on a certain endianness, but there may be more ways to get bad, byte-swapping perf on it too, though the behaviour will always be consistent. |
| 22:44 | <TabAtkins> | Maybe. |
| 22:44 | <TabAtkins> | I wonder if we can do something like make XHR return a DataView for "arraybuffer"? |
| 22:44 | <TabAtkins> | Probably not, now. |
| 22:45 | <gsnedders> | A Uint8DataView makes the most sense, IMO |
| 22:45 | <zewt> | ouch, that's the most confusing name imaginable :P |
| 22:45 | <TabAtkins> | A DataView with UInt8 array-like behavior? |
| 22:46 | <gsnedders> | Better than ClampedUint8DataView |
| 22:46 | <gsnedders> | Oh, no, I'm thinking of the arrays again. |
| 22:46 | <gsnedders> | Duh. |
| 22:46 | <gsnedders> | For some reason I always think they're data views. |
| 22:46 | <roc> | TabAtkins, annevk: "They can't realistically search your entire set of OS fonts when attempting to render a page." ... well, that's exactly what Firefox does |
| 22:46 | <roc> | if necessary |
| 22:47 | TabAtkins | liked the ES record stuff that progressed too slowly and got preempted by this, because it could have let you describe the fields of your data so you get automatic byte-swapping. |
| 22:47 | <TabAtkins> | roc: I didn't know that! |
| 22:47 | <TabAtkins> | I assumed you had a normal font-stack with Last Resort at the end. |
| 23:04 | <TabAtkins> | So what's this "LE mode" I'm hearing about? And what's its relevance to the discussion? |
| 23:05 | <roc> | I discovered yesterday that ARM CPUs can switch endianness on the fly with a single instruction |
| 23:06 | <Hixie> | wow |
| 23:06 | <Hixie> | that's hardcore |
| 23:06 | <zewt> | how does that actually work? i'd think changing the endianness of your pointers would do ... bad stuff |
| 23:06 | <zewt> | only affects math, maybe? |
| 23:06 | <roc> | "carefully" |
| 23:06 | <zewt> | heh |
| 23:06 | <zewt> | "wear a helmet" |
| 23:06 | <roc> | I assumed it affects all loads and stores |
| 23:07 | <zewt> | is the opcode MSHRMCLD? |
| 23:07 | <roc> | http://www.doulos.com/knowhow/arm/Hints_and_Tips/Byte_Swapping/ |
| 23:07 | <TabAtkins> | Oh, wow: "Oops! Google Chrome could not connect to hint.fm |
| 23:07 | <TabAtkins> | Other users are also experiencing difficulties connecting to this site, so you may have to wait a few minutes." |
| 23:07 | <TabAtkins> | That's pretty cool. <3 anonymous usage data. |
| 23:08 | <TabAtkins> | roc: I suppose that wouldn't help the GPU, though? |
| 23:08 | <roc> | There is a way to make the Web safe for BE machines. Have Chrome randomly emulate BE 10% of the time. |
| 23:08 | <Hixie> | i've proposed that kind of thing in the past |
| 23:08 | <zewt> | what about big-endian systems with little-endian GPUs? |
| 23:08 | <zewt> | (sorry, I had to say it) |
| 23:08 | <roc> | TabAtkins: yeah, I think what actually matters here is BE *GPUs* |
| 23:08 | <Hixie> | e.g. my websocket design required the ua to randomise the order of headers in the handshake |
| 23:09 | <TabAtkins> | I keep proposing stochastic prefix inclusion. It hasn't yet made it past the laugh test. |
| 23:09 | <zewt> | Hixie: that sounds challenging to test, heh |
| 23:09 | <TabAtkins> | But I feel like it's kinda close. |
| 23:09 | <zewt> | (a bit unreasonable to expect of servers, though) |
| 23:09 | <TabAtkins> | (That is, only release prefixed things to the release channel in X% of browsers.) |
| 23:09 | <zewt> | (er, clients, I guess) |
| 23:10 | <zewt> | seems sort of questionable to expect people to introduce complexity (and therefore bugs) in order to reduce bugs |
| 23:10 | <TabAtkins> | That's pretty much been the argument against it, yeah. |
| 23:10 | <TabAtkins> | But randomness is so useful! |
| 23:10 | <TabAtkins> | So many things can be solved easier with randomness than with a deterministic process. |
| 23:10 | <zewt> | especially since it's expecting people to introduce bugs in *their* stuff, to reduce bugs in someone else's |
| 23:13 | <roc> | It seems to me that WebGL performance issues on BE machines could be solved in the driver. |
| 23:15 | <TabAtkins> | No clue. |
| 23:16 | <TabAtkins> | roc: Btw, if you're still interested in measurement APIs and such (improvements in the vein of getBoundingClientRect, etc.), we're gaining someone who wants to do spec/impl work and is interested in this. |
| 23:23 | <Philip`> | ARMv7 apparently always reads instructions as little-endian (except for a legacy mode in the "real-time" profile which can optionally be hardwired to do big-endian); otherwise the endianness just affects all load/store instructions (including NEON ones) (not registers or arithmetic or anything) |
| 23:24 | <TabAtkins> | Looking at DataView in practice, I see why it's not expected to be used. http://code.google.com/p/webglsamples/source/browse/hdr/hdr.js#235 |
| 23:24 | <TabAtkins> | Sheesh. |
| 23:24 | <TabAtkins> | You need to take an array buffer, wrap it in a data view, iterate over it with some moderately long boilerplate, and copy it into another array buffer. |
| 23:25 | <TabAtkins> | This could be made *enormously* more convenient to use. |
| 23:26 | <Philip`> | (I don't see anything saying SETEND can only be used from privileged modes, so maybe it can actually be used arbitrarily by applications?) |
| 23:29 | <TabAtkins> | Hixie: If you didn't see it, lunch next week on tuesday. |
| 23:30 | <Hixie> | TabAtkins: awesome. at goog? |
| 23:30 | <TabAtkins> | Yeah. |
| 23:30 | <TabAtkins> | Hopefully with tantek too. |
| 23:30 | <Hixie> | any idea what time? |
| 23:30 | <TabAtkins> | Let me check scrollback... |
| 23:31 | <TabAtkins> | noon |
| 23:31 | <Hixie> | k |
| 23:31 | <Hixie> | added to calendar |
| 23:32 | <Hixie> | do we have a meeting place planned? |
| 23:33 | <TabAtkins> | not yet |
| 23:33 | <Hixie> | k |
| 23:34 | <Hixie> | ok, i'm outta here. i'll be at San Jose's FRC regional the next three days. back monday. |
| 23:45 | <roc> | zewt: what do you mean, "Benoit's email"? |
| 23:48 | <roc> | hmm, I'm missing email |
| 23:51 | <zewt> | roc: "FWIW, here is a way to do this that will always work and won't rely on "luck". The key idea is that by the time one draws stuff, all the information about how vertex attributes use buffer data must be known. ..." |
| 23:51 | <roc> | I found it in the archives |
| 23:53 | <zewt> | uh, wait, what the |
| 23:54 | <zewt> | kenneth is actually talking about polymorphism dispatch overhead in Java as if it has any relevance to JS? |
| 23:55 | <TabAtkins> | The implication, I assume, is that similar JITing concerns may apply. |
| 23:55 | Philip` | supposes the most irritating case is if you have overlaps like "char data[] = { 0x01, 0x02, 0x03 }; glVertexAttribPointer(a, 1, GL_SHORT, 0, 0, data); glVertexAttribPointer(b, 1, GL_SHORT, 0, 0, data+1);", which should give one value 0x0102 and one 0x0203 |
| 23:56 | <zewt> | but there's really no parallel, i think, between the way JS and Java dispatch works and optimizes |
| 23:56 | <TabAtkins> | Philip`: Ooh, that's true. |
| 23:56 | <Philip`> | (so you'd have to expand into non-overlapping arrays if you wanted to swap bytes) |
| 23:56 | <zewt> | Philip`: is "shoot the programmer in the head" an acceptable answer? |
| 23:56 | <TabAtkins> | Damn, if you pack that way you can't early-swap at all. |
| 23:57 | <Philip`> | zewt: I don't think it's explicitly undefined behaviour, so shooting the programmer is unlikely to be permitted, especially since it will violate the invariance requirements |
| 23:57 | <zewt> | Philip`: it violates the "you really, seriously need to be shot in the head" requirement |
| 23:58 | <zewt> | if WebGL was designed sanely, it just wouldn't allow that--but they're obsessed with trying to make WebGL just like OpenGL (a serious design mistake, if you ask me) |
| 23:58 | <zewt> | (making it an overlay of it, so they don't have to actually define it all, is good, of course) |