| 00:01 | <Hixie> | don't you "just" draw the text on a straight line, figure out all the advances and the total width, then figure out the width of the path, then figure out the alignment, then "just" start at one end and put all the glyphs down, tangential to the path at the point, advancing the point by the advance you calculated earlier for each glyph? |
| 00:03 | <zewt> | do you warp the individual glyph boxes along the path? |
| 00:04 | <Hixie> | no |
| 00:04 | <Hixie> | at least not in svg |
| 00:04 | <astearns> | tangential to the path is one method, but it tends to produce collisions for concave paths |
| 00:04 | <zewt> | sounds like it'd be sort of fugly if it doesn't |
| 00:05 | <astearns> | glyphs can be unmodified (in which case you probably need to flex the spacing depending on the path characteristics) |
| 00:05 | <astearns> | or the glyphs can be transformed to match path characteristics |
| 00:08 | <Hixie> | for transforming the glyphs, i think we should "just" provide a warping method that takes on path and warps it along another path |
| 00:09 | <Hixie> | so you would draw the text straight, then curve it along another path |
| 00:10 | <abarth> | Hixie: AES128 should fine |
| 00:10 | <zewt> | couldn't you almost do that by hand, if there were a few basic hooks into glyph metrics? |
| 00:10 | <abarth> | Hixie: more specifically, AES128-CTR |
| 00:11 | <Hixie> | abarth: if i take a key as input, any harm in accepting 128, 192, and 256? |
| 00:11 | <abarth> | no harm |
| 00:11 | <Hixie> | zewt: there's no hooks into the path data currently |
| 00:11 | <Hixie> | abarth: cool, thanks |
| 00:12 | <zewt> | i suppose warping actual glyph rendering might just be really hard to implement, if font engines simply don't support doing that |
| 00:14 | <Hixie> | abarth: hm, i suppose AES-CTR means i can't do arbitrary seeking |
| 00:15 | <zewt> | iirc, it does allow that |
| 00:15 | <abarth> | you can |
| 00:15 | <Hixie> | abarth: oh ok |
| 00:15 | <abarth> | you just set the counter to whatever block you want |
| 00:15 | <Hixie> | k |
| 00:15 | <zewt> | pick your block number, encrypt it with AES, use that as the mask |
| 00:15 | <abarth> | it's CBC that doesn't allow seeking |
| 00:17 | <zewt> | http://tavmjong.free.fr/blog/?p=249 |
| 00:17 | <zewt> | sort of neat |
| 00:21 | <heycam> | Hixie, SVG currently does glyphs tangential to the path, and yes it is kind of fugly with anything but gentle slopes |
| 00:22 | <heycam> | zewt, yeah would be cool to have actual warping of text like that |
| 00:22 | <heycam> | hard though :( |
| 00:22 | <zewt> | heycam: if implementors are willing to implement it |
| 00:22 | <zewt> | no point if they're going to throw up their arms and give up |
| 00:22 | <heycam> | yep |
| 00:22 | <zewt> | i wonder how it would look if you rendered the text to a large backbuffer, warp the buffer and then downscale |
| 00:22 | <heycam> | I tried writing a simple JS thing to subdivide the paths for the glyphs and warp them, ended up being horribly slow |
| 00:23 | <heycam> | zewt, that's an option I guess |
| 00:23 | <heycam> | could work on the gpu too |
| 00:23 | <zewt> | it wouldn't antialias/grid align nicely, but that's probably not going to happen anyway |
| 00:23 | <divya> | hsivonen: w.r.t api.html5please.com it is definitely not complete |
| 00:23 | <divya> | hsivonen: only reason UA detection exists is to return a smaller set of recommended browsers. |
| 00:23 | <Hixie> | zewt: again, for that kind of thing i don't think it makes sense to special-case text |
| 00:23 | <Hixie> | zewt: we should just add path warping |
| 00:23 | <divya> | e.g. no point returning IE for Mac/Linux users. |
| 00:24 | <divya> | hsivonen: or returning mobile browsers for desktop users. |
| 00:24 | <heycam> | Hixie, "just" |
| 00:24 | <divya> | hsivonen: also the point is to get out of the way of users when feature is supported and api is still called. |
| 00:24 | <Hixie> | heycam: as opposed to adding path warping and text warping |
| 00:24 | <zewt> | but if you can do that, is there a point to having a weaker, "non-warping" text warp in the first place? |
| 00:24 | <heycam> | Hixie, ok, same level of difficulty though |
| 00:24 | <Hixie> | heycam: same code, even, yeah |
| 00:25 | <Hixie> | zewt: this isn't text warping, it's text placement along a line that just isn't straight |
| 00:25 | <zewt> | but when would you want to do that, if you have another API that can do full-blown warping |
| 00:26 | <zewt> | provided that implementation is good enough that it never looks worse; that, I don't know |
| 00:26 | <Hixie> | looking around me, i see a lot of text drawn on very slight curves, that doens't look warped |
| 00:26 | <zewt> | but would they be worse if the glyphs themselves did warp? (i don't know the answer) |
| 00:27 | <Hixie> | hard to say |
| 00:27 | <Hixie> | the api would presumably be rather more complicated |
| 00:27 | <Hixie> | and it's not clear to me implementations are up for it |
| 00:27 | <Hixie> | but i'm certainly open to api suggestions and implementor commitments :-) |
| 00:28 | <heycam> | Hixie, btw if you come across things you want to reference from SVG 1.1 (like say glyph-along-path placement) that you find are badly specced or difficult to reference, let me know and I'll track them to fix in SVG 2 |
| 00:28 | <Hixie> | heycam: k |
| 00:28 | <Hixie> | heycam: i dunno if text along a path i badly specced, i haven't tried speccing it yet. it just seems rather long and i can't work out why :-) |
| 00:29 | <heycam> | at a high level the algorithm is simple… just move along the path the advance distance between each glyph, place the glyph tangential to the path half way through its advance |
| 00:29 | <heycam> | there's probably a bunch of edge cases for path discontinuities |
| 00:34 | <Hixie> | bbl |
| 01:44 | <zewt> | exhausted with circular vtt "roll-ups" thread |
| 04:51 | <atdt> | anyone alive? |
| 05:48 | <MikeSmith> | atdt: hey |
| 05:50 | <atdt> | hi mike |
| 05:50 | <MikeSmith> | hi |
| 05:50 | <atdt> | so i have this idea i'd like to propose, but before spamming the mailing list i thought i'd run it by some people here, to see if it has legs or not |
| 05:50 | <atdt> | could i run it by you quickly? |
| 05:54 | <atdt> | well, i'll just explain quickly rather than ask. the idea has to do with <a> elements. it's very common practice to have links that have the URL they point to as their text node. |
| 05:55 | <MikeSmith> | yeah |
| 05:55 | <atdt> | the way they're written now is like this: <a href="http://www.example.com/">http://www.example.com/</a>; |
| 05:55 | <MikeSmith> | right |
| 05:55 | <atdt> | that's rather ugly, imo. it'd be nicer to do one of the following: |
| 05:55 | <atdt> | <a>http://www.example.com/</a>; |
| 05:55 | <atdt> | or <a href>http://www.example.com/</a>; |
| 05:56 | <atdt> | the first idea would break the currently specced interpretation of hrefless a tags as being placeholders, but i don't think that use caught on -- i haven't encoutnered it, anyway, and it seems a bit bogus to me |
| 05:56 | <MikeSmith> | so do it that way in your source and use JS to transform it in the DOM |
| 05:57 | <atdt> | well, you're right that it's easy to do with JS, but i think it's a point in favor, not against (makes it easy to write a polyfill, which i did -- http://jsfiddle.net/atdt/tbSv6/) |
| 05:58 | <atdt> | it seems much more expressive, which makes it an attractive candidate for standardization, since it makes code easier to read, IMHO. |
| 05:59 | <MikeSmith> | well |
| 05:59 | <atdt> | note that current draft of the spec has a huge block of these right at the top: http://dev.w3.org/html5/spec/Overview.html :) |
| 05:59 | <MikeSmith> | making code easier to read is generally not a high priority or standardization |
| 06:01 | <atdt> | that surprises me, since it has been one of the most attractive things about recent revisions to the specs |
| 06:02 | <MikeSmith> | really? like what for example? |
| 06:02 | <MikeSmith> | also, what would you expect the behavior to be for <a>foo.html</a> |
| 06:02 | <MikeSmith> | or <a>README</a> |
| 06:02 | <atdt> | optional quotes around attribute values, optional closing tags for certain elements |
| 06:02 | <MikeSmith> | those are not new |
| 06:03 | <MikeSmith> | that is just HTML |
| 06:03 | <MikeSmith> | as it always has been |
| 06:04 | <atdt> | ok, the leaner prologue. maybe that's not new, either. |
| 06:04 | <MikeSmith> | no, that's new |
| 06:04 | <atdt> | i simply think that the way the <a> tag was designed reflects an earlier relationship with URLs wherein they were presumed to be unfriendly or barely-friendly |
| 06:04 | <MikeSmith> | and <meta charset=utf-8> is new too |
| 06:05 | <atdt> | so it was implicitly presumed to be ugly to show them |
| 06:05 | <MikeSmith> | eh? |
| 06:05 | <atdt> | er, let me try that again |
| 06:07 | <atdt> | i can't presume to know what exactly tim berners-lee et al had in their head, but i suppose that they couldn't imagine that http URIs will become as common as they did on the surface of things (business cards, other printed matter, etc.) but it's common now for the url to be not just an low-level implementation detail but part of the "human" identity of certain sites or pages |
| 06:07 | <atdt> | earlier today i noticed that GNU links to themselves as "GNU.org" in lots of places |
| 06:08 | <atdt> | so i take the <a> element to reflect this prejudice: you never want to just show a url; you always want to describe it in plain prose |
| 06:09 | <atdt> | but i don't think that captures the particular use i'm describing, which is very (very) widespread |
| 06:09 | <atdt> | did that make sense? |
| 06:11 | <atdt> | regarding your earlier question (regarding <a>README</a> and the likes), i propose that the textContents of <a> elements with a null (absent) href attribute be interpreted as the href |
| 06:13 | <atdt> | i don't remember encountering bare <a> tags in the wild. they're currently allowed as "placeholders", but as i mentioned earlier, i think that's bogus. (should we have <img> for placeholder images, etc.?) |
| 06:14 | <MikeSmith> | I'm sure there you'd find plenty of href-less <a> elements in Web content if you went looking |
| 06:15 | <atdt> | i did in a casual way over the past couple of days and couldn't find any |
| 06:16 | <atdt> | but even so: they're not functional |
| 06:16 | <atdt> | so this wouldn't be breaking them |
| 06:16 | <MikeSmith> | yeah, your proposal would make them functional |
| 06:16 | <MikeSmith> | sure it would break them |
| 06:16 | <MikeSmith> | it would change their existing behavior to something the authors didn't intend them to have |
| 06:16 | <MikeSmith> | anyway, as far as taking this to a mailing list, I think that'd be fine if you're just interested in having a philosophical discussion about it |
| 06:17 | <smaug____> | isn't <a name="foo"> pretty common |
| 06:17 | <MikeSmith> | but you are going to find that browser implementors have zero interest |
| 06:18 | <atdt> | smaug____: yeah, you'd exempt them |
| 06:18 | <MikeSmith> | smaug____: yeah but I assume atdt would say that the presence of the name attribute would cause the text content to be not handled as a URL |
| 06:19 | <atdt> | right |
| 06:19 | <smaug____> | strange special cases |
| 06:19 | <smaug____> | well, not that strange |
| 06:19 | <smaug____> | but makes the "API" behave a bit strangely |
| 06:20 | <atdt> | not that strange. in ff and chrome unstyled <a>foo</a> aren't underlined, but both <a href=...> and <a name=...> are |
| 06:20 | <atdt> | so there is already some distinction between links that point at something and links that aren't really links |
| 06:21 | <MikeSmith> | smaug____: multi-column support broken in nightly |
| 06:22 | <smaug____> | MikeSmith: hmm, do you have nested multicolumn ? |
| 06:22 | <MikeSmith> | no |
| 06:22 | <MikeSmith> | http://platform.html5.org/ |
| 06:22 | <MikeSmith> | updating now to see if that fixes it.. |
| 06:23 | <smaug____> | atdt: we're changing web platform all the time so much, that I wish at least some things stay stable, like <a> handling :) |
| 06:23 | <smaug____> | MikeSmith: have you filed a bug? |
| 06:24 | <MikeSmith> | smaug____: no, will check first to see if anybody else has |
| 06:24 | <MikeSmith> | I would be very surprised if it hasn't been reported already |
| 06:24 | <smaug____> | multicolumn is used rarely |
| 06:24 | <MikeSmith> | atdt: btw, <a href> is the same as <a href=""> |
| 06:24 | <MikeSmith> | smaug____: really? I thought all the designers loved it |
| 06:25 | <atdt> | i use it :) |
| 06:25 | <smaug____> | I could be wrong, but I think it isn't that common yet |
| 06:25 | <smaug____> | roc would know better, but he is on vacation |
| 06:26 | <atdt> | smaug____: well, i don't have an answer for implementors' headaches, obviously. but this would standardize something around which there are currently many ugly hacks |
| 06:26 | <MikeSmith> | oh yeah, I heard roc was in the UK |
| 06:27 | <smaug____> | MikeSmith: https://bugzilla.mozilla.org/show_bug.cgi?id=731516 |
| 06:27 | <smaug____> | (sorry, didn't remember your bugzilla email) |
| 06:27 | <MikeSmith> | smaug____: thanks |
| 06:27 | <MikeSmith> | mike⊙wo |
| 06:27 | <MikeSmith> | will cc myself there |
| 06:29 | <smaug____> | atdt: it is even more web devs headache, if the basic building blocks keep changing |
| 06:30 | <atdt> | smaug____: 99.99999% of <a> tags won't be affected. the fraction of a percent that do would acquire a behavior where there wasn't one before, which isn't as bad as all that |
| 06:32 | <atdt> | and it's very easy to add support to <a>http://gnu.org/</a>; via a js polyfill -- not sure if you saw my link earlier http://jsfiddle.net/atdt/tbSv6/ |
| 06:32 | <smaug____> | MikeSmith: you could add "don't use these web technologies" to your list |
| 06:32 | <smaug____> | Sync XHR in window context |
| 06:33 | <smaug____> | or perhaps W3C or WhatWG could have such list |
| 06:33 | <MikeSmith> | yeah |
| 06:33 | <MikeSmith> | though there is smaug____: http://html5please.com/ |
| 06:33 | <atdt> | and finally, if you don't use a polyfill and just have a <a>http://www.example.com/</a>; in a browser that doesn't implement the spec i'm proposing you would be left with something quite usable still: a link you can copy and paste. |
| 06:33 | <smaug____> | Sync XHR, perhaps localStorage |
| 06:35 | <MikeSmith> | hmm, yeah, localStorage |
| 06:36 | <MikeSmith> | smaug____: I'm editing https://github.com/h5bp/html5please/blob/master/posts/localstorage.md now |
| 06:37 | <MikeSmith> | what should I add? |
| 06:37 | <MikeSmith> | I don't know if "race condition" is the right way to explain it in this context |
| 06:38 | <smaug____> | warning about using sync API |
| 06:38 | <smaug____> | the situation is not good though |
| 06:39 | <smaug____> | since IndexedDB isn't available everywhere yet |
| 06:39 | <smaug____> | but UI thread shouldn't have sync data fetching APIs |
| 06:40 | <paul_irish> | MikeSmith: thx for that, and good call on making a note along those lines. |
| 06:40 | <MikeSmith> | oh hey paul_irish |
| 06:41 | <atdt> | heyoo paul |
| 06:41 | <MikeSmith> | yeah, I will take a shot at the wording and send a pull request |
| 06:41 | <MikeSmith> | paul_irish: feel free to change it however you want of course |
| 06:41 | <paul_irish> | awesome. atdt, hey ori |
| 06:41 | <paul_irish> | certainly. |
| 06:44 | <atdt> | MikeSmith: http://paul.kinlan.me/we-need-to-kill-off-the-localstorage-api "LocalStorage has poor querying capabilities, terrible performance, small storage in many browsers, crazily inconsistent eventing and a nasty habit of locking." |
| 06:44 | <atdt> | MikeSmith: i don't know the specifics, unfortunately |
| 06:44 | <MikeSmith> | yeah |
| 06:44 | <MikeSmith> | some of those are implementation shortcomings |
| 06:44 | <smaug____> | but the main problem is the API itself |
| 06:45 | <MikeSmith> | atdt: thanks for the link |
| 06:45 | <MikeSmith> | didn't know Paul had written this up |
| 06:45 | <smaug____> | MikeSmith: I assume you've seen this about sync XHR http://blogs.msdn.com/b/wer/archive/2011/08/03/why-you-should-use-xmlhttprequest-asynchronously.aspx |
| 06:45 | <smaug____> | 8.4% is a huge number |
| 06:46 | <MikeSmith> | smaug____: had not seen that article |
| 06:46 | <paul_irish> | also http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs |
| 06:47 | <paul_irish> | oh mike knows that one. |
| 06:47 | <MikeSmith> | paul_irish: yeah, the bugs there |
| 06:47 | <MikeSmith> | mandreel problem |
| 06:47 | <atdt> | imho there's something of a missed opportunity with web workers.. most people see them as a source of complexity, suitable for crazy performance hacks |
| 06:48 | <MikeSmith> | dunno if the mandreel devs have figured out how to deal with that yet |
| 06:48 | <MikeSmith> | Jarred's comment |
| 06:49 | <MikeSmith> | "sync XHR still works in Workers (where it belongs). Can you utilize workers and run Mandreel's processing in a worker, and post message notifications on UI updates?" |
| 06:49 | <atdt> | but because workers can block without blocking the UI they can actually simplify code because they allow you to write synchronous code |
| 06:51 | <atdt> | smaug____, MikeSmith: regarding the <a> thing i brought up earlier, were you at all persuaded? and do you think this has a snowball's chance in hell if i bring it up on the mailing list? i'm not especially interested in philosophical discussions if they don't stand a chance of having an impact |
| 06:52 | <MikeSmith> | atdt: no chance, imho :( |
| 06:52 | <MikeSmith> | it's an interesting "what if" kind of idea |
| 06:52 | <smaug____> | yeah |
| 06:53 | <smaug____> | I don't see it important enough to change the behavior |
| 06:53 | <MikeSmith> | the platform has a lot of suboptimal stuff we're stuck with |
| 06:54 | <atdt> | do you think it'd have a better chance if i had some hard data about how common bare <a> tags are? |
| 06:55 | <MikeSmith> | atdt: I honestly don't think it would make any difference |
| 06:55 | <MikeSmith> | but I think you might be surprised by the data you find |
| 06:55 | <MikeSmith> | there probably is already some data out there |
| 06:56 | <atdt> | MikeSmith: i'll look, for sheer curiosity if nothing else. |
| 06:56 | <MikeSmith> | I mean in some reports |
| 06:56 | <smaug____> | atdt: in your case, couldn't you just have <a href="http://foo.fi"></a>; and style that a:empty:before { attr(href); } |
| 06:57 | <MikeSmith> | http://dev.opera.com/articles/view/mama-hyperlinks/#a |
| 06:57 | <MikeSmith> | 3,304,834 out of 3,307,397 a elements have href attributes |
| 06:58 | <MikeSmith> | atdt: so you're right and I'm wrong :) |
| 06:58 | <atdt> | 2,563 don't -- but i would bet my liver that the vast majority of those have name attr |
| 06:59 | <MikeSmith> | yeah, I'm surprised the number is that small |
| 06:59 | <atdt> | well, keep in mind that the very fact that bare <a>s aren't really treated as links means that web devs have the habit of implementing dummy links as either <a href="#"> or <a href="javascript:void()"> |
| 07:01 | <atdt> | MikeSmith: i wonder if their data set is available |
| 07:02 | <MikeSmith> | paul_irish: I was thinking about adding links on platform.html5.org to htmlplease, but it seems there are no IDs at htmlplease to link to :( |
| 07:02 | <paul_irish> | we have permalinks! |
| 07:02 | <MikeSmith> | atdt: I think their data was not publicly available |
| 07:02 | <paul_irish> | search for something |
| 07:02 | <paul_irish> | and there's a Link to This |
| 07:02 | <MikeSmith> | paul_irish: ah, OK |
| 07:02 | <paul_irish> | thing |
| 07:03 | <MikeSmith> | ah, OK |
| 07:03 | <MikeSmith> | cool |
| 07:03 | <MikeSmith> | I shall use that |
| 07:05 | <atdt> | anyhow, thanks very much for the useful input, all. i think i'll try to find some more hard data and reassess. |
| 07:06 | <atdt> | smaug____: just noticed your suggestion above. yeah, that might do the trick. i'll have to think about it |
| 07:07 | <smaug____> | atdt: seems to work in Gecko and Opera |
| 07:07 | <smaug____> | old Chrome has problems |
| 07:07 | <smaug____> | but that is just an implementation bug |
| 07:09 | <atdt> | smaug____: i don't think i love that idea, because part of my point is precisely that "eponymous" URLs are part of the text flow of the document |
| 07:11 | <atdt> | it looks a bit weird to say "check out our website at <a href="http://gnu.org/"></a>";. the style would be necessary for that to make any sense at all. |
| 07:22 | <atdt> | ok, i'm off -- thanks again for the input. |
| 07:41 | <MikeSmith> | smaug____, paul_irish: "As part of keeing things simple, localStorage has a synchronous API that runs on the main UI thread in browsers; as a consequence of that, a race condition can occur if a user has the same site open in multiple windows or tabs running as separate processes. For many applications, that’s never really a problem in practice. But it can cause data corruption—so applications where it’s important to try to ensure |
| 07:41 | <MikeSmith> | absolutely no data corruption can occur should instead use a more robust storage mechanism such as IndexedDB." |
| 07:41 | <MikeSmith> | man that's a lot of words |
| 07:41 | <MikeSmith> | but dunno how to say it with fewer |
| 07:50 | <paul_irish> | MikeSmith: lets go with it |
| 07:51 | <MikeSmith> | paul_irish: OK, thanks |
| 07:51 | <MikeSmith> | just sent the pull request |
| 07:51 | <paul_irish> | :) thank you! |
| 07:51 | <MikeSmith> | cheers |
| 07:51 | <smaug____> | MikeSmith: even worse problem is that since localStorage is stored in file system, using the API may cause the UI thread to hang if the data isn't in memory |
| 07:51 | <MikeSmith> | really? |
| 07:51 | <smaug____> | yes |
| 07:51 | <MikeSmith> | I didn't know about that one |
| 07:51 | <MikeSmith> | wow |
| 07:51 | <MikeSmith> | that sucks even worse |
| 07:52 | <smaug____> | of course browsers try cache the data in memory when possible |
| 07:52 | <smaug____> | try to |
| 07:52 | <zcorpan> | do cookies do that also? |
| 07:52 | <MikeSmith> | I guess with cookies it's far less data |
| 07:54 | <zcorpan> | does indexeddb have an equivalent to sessionStorage? |
| 08:02 | <MikeSmith> | paul_irish: I think http://html5please.com/#localstorage should take me down to the actual localstorage section/article |
| 08:02 | <MikeSmith> | rather than the top of the page |
| 08:02 | <paul_irish> | i agree with that |
| 08:02 | <MikeSmith> | will raise an issue |
| 08:02 | <MikeSmith> | especially that's harsh for mobile |
| 08:03 | <paul_irish> | yeah file it. |
| 08:33 | <hsivonen> | heh. Hixie and I thought about the untrusted CDN case in *very* similar ways |
| 08:35 | <annevk> | zewt: Encoding spec should define the encoder for UTF-8 |
| 10:44 | zcorpan | adds status boxes to http://simon.html5.org/specs/quirks-mode |
| 10:44 | <zcorpan> | maybe i should move it to dvcs.w3.org |
| 11:25 | <izhak> | What encoding is used by mozilla's nsString internally? Or there's no encoding there, just a 4byte sequense? |
| 11:26 | <izhak> | And yet, what encoding is suggested to use by whatwg for internal needs? Say, when storing parsed tokens, for storing parsed tree and so on. |
| 11:27 | <hsivonen> | izhak: (potentially invalid) UTF-16 |
| 11:28 | <hsivonen> | izhak: that is, it's UTF-16 potentially containing unpaired surrogates |
| 11:28 | <hsivonen> | izhak: the whatwg doesn't suggest an internal encoding |
| 11:29 | <hsivonen> | izhak: there's some confusing language in the whatwg HTML spec that tries to abstract over the reality of the DOM being UTF-16 potentially containing unpaired surrogates |
| 11:29 | <izhak> | And I started to thought that I misunderstood that wchar_t typedef... |
| 11:30 | <izhak> | *to think |
| 11:30 | <hsivonen> | wchar_t is full of FAIL |
| 11:30 | <izhak> | yeah |
| 11:30 | <hsivonen> | PRUnichar is wchar_t on Windows where wchar_t is 16 bits |
| 11:30 | <hsivonen> | PRUnichar is not wchar_t on Linux/GCC |
| 11:30 | <izhak> | I would be just happy to see utf-8 in there |
| 11:30 | <hsivonen> | PRUnichar is always 16 bits |
| 11:31 | <hsivonen> | wchar_t is whatever (16 bits on Windows, 32 in glibc) |
| 11:31 | <izhak> | I wouldn't say that PRUnichar does better than wchar_t :) in general |
| 11:31 | <hsivonen> | well, at least PRUnichar has a stable meaning in terms of number of bits |
| 11:32 | <hsivonen> | makes it superior to wchar_t in my book |
| 11:33 | <izhak> | But why utf-16, only to make character wise traversal more efficient and convinient? |
| 11:33 | <annevk> | zcorpan: using some kind of repo would be nice at least for history |
| 11:33 | <annevk> | zcorpan: and backups |
| 11:33 | <hsivonen> | izhak: because in the late nineties, people weren't enlightened about the virtues of UTF-8 |
| 11:33 | <zcorpan> | annevk: yeah |
| 11:34 | <annevk> | man |
| 11:34 | <annevk> | I just realized last night that if UTF-16 was not there, surrogates would not have been there either |
| 11:34 | <annevk> | it was a nice dream |
| 11:35 | <zcorpan> | annevk: btw html-diffs needs updating again |
| 11:36 | <izhak> | hsivonen: clear, thanks. |
| 11:36 | <annevk> | zcorpan: isn't that your job now? |
| 11:36 | <zcorpan> | annevk: yeah, though i don't have anolis set up yet |
| 11:37 | <annevk> | if you update the source I can generate |
| 11:37 | <zcorpan> | ok, cool |
| 11:41 | <annevk> | agreed :) |
| 11:41 | <asmodai> | Anyone know which BNF form the w3.org typically uses (like in the XML spec)? |
| 11:41 | <annevk> | avoid-BNF |
| 11:41 | <hsivonen> | IIRC, XML has its own flavor |
| 11:41 | <zcorpan> | i can use xspec xref now, right? |
| 11:41 | <annevk> | yes |
| 11:41 | hsivonen | wants rectangular selections in Eclipse |
| 11:41 | <zcorpan> | k |
| 11:42 | <annevk> | XML has its own BNF, lots of specs avoid BNF, if you really want to use BNF, you should use ABNF I think as standardized in some RFC |
| 11:42 | <hsivonen> | ooh. alt+shift+a |
| 11:50 | <asmodai> | annevk / hsivonen: Thanks. Was just seeing if this was a defined BNF or not. |
| 12:05 | <zcorpan> | hsivonen: what's alt+shift+a? |
| 12:06 | <zcorpan> | oh, eclipse |
| 12:44 | <hsivonen> | unfortunately, http://dbaron.org/log/2006-08#e20060818a is still relevant today |
| 12:46 | <hsivonen> | it's still sad that companies whose devices "don't try to support browsing the web at large" get to buy attention of the W3C |
| 12:53 | <jgraham> | Well has the W3C process changed substantially in the past 5.5 years? |
| 13:10 | <annevk> | Community Groups were added to work around it |
| 14:16 | <bga> | strict typed js and s-expr instead html is pretty popular idea |
| 14:17 | <jgraham> | By "pretty popular" you mean "lots of people talk about it, no one does it"? |
| 14:17 | <jgraham> | (for small values of "lots") |
| 14:17 | <bga> | lots of ppl |
| 14:18 | <bga> | s-expr has native macroses |
| 14:18 | <bga> | good for temlpating |
| 14:18 | <bga> | *templating |
| 14:18 | <jgraham> | Well some people write templating languages in lisp, yes |
| 14:19 | <jgraham> | I'm not sure that's the same thing |
| 14:19 | <bga> | sorry. away |
| 14:55 | <zcorpan> | annevk: how do i fix https://www.w3.org/Bugs/Public/show_bug.cgi?id=14319 ? |
| 14:56 | <annevk> | wontfix? |
| 14:56 | <annevk> | doesn't seem overly important |
| 14:57 | <annevk> | or maybe change HTML5 to HTML in the abstract |
| 14:57 | <annevk> | that's prolly best |
| 14:58 | <annevk> | I guess everyone is just ignoring Charles Pritchard now otherwise the notion that WebKit can be bought would have generated some traffic I suppose |
| 14:59 | <annevk> | cf http://lists.w3.org/Archives/Public/public-html/2012Feb/0494.html |
| 15:00 | <nisci> | what does the 'wg' in whatwg stand for? |
| 15:00 | <annevk> | Working Group |
| 15:02 | <zcorpan> | i thought this document was about describing the w3c html5 spec, so the references should maybe go there |
| 15:02 | <annevk> | it's mostly about giving a rough overview over how HTML changed since HTML4 |
| 15:03 | <annevk> | I'm sure someone will change the reference before publishing though |
| 15:03 | <annevk> | plh is good at that |
| 15:04 | <zcorpan> | if we want the spec to describe the whatwg spec, there are several things that should be changed, i think |
| 15:04 | <annevk> | do we have to be so granular? |
| 15:05 | <zcorpan> | well currently it aims to accurately describe the w3c spec, but the references go to whatwg, which is a bit weird |
| 15:06 | <jgraham> | zcorpan: see /topic :p |
| 15:06 | <annevk> | changing the references is a bit of a hassle |
| 15:06 | <annevk> | I think Ms2ger is planning on something to change that, but it might take a while |
| 15:07 | <annevk> | I wouldn't worry too much about it |
| 15:07 | <zcorpan> | maybe i should just cover both specs in cases where they disagree |
| 15:07 | <Ms2ger> | You could always add a [HTML5] to spec-data |
| 15:07 | <Ms2ger> | It might even exist already |
| 15:10 | <zcorpan> | where is spec-data? |
| 15:10 | <Ms2ger> | Bitbucket |
| 15:11 | <zcorpan> | seems it doesn't exist |
| 15:11 | <Ms2ger> | https://bitbucket.org/ms2ger/specification-data/ |
| 15:13 | <annevk> | see also http://wiki.whatwg.org/wiki/Anolis |
| 15:15 | zcorpan | meant that [HTML5] doesn't exist |
| 15:30 | <Ms2ger> | Yeah |
| 15:31 | <jgraham> | HTML5 doesn't exist? Better keep that one a secret |
| 15:59 | <annevk> | can someone check the WHATWG blog for that comment? |
| 15:59 | <annevk> | nobody has done it yet... |
| 16:09 | <nisci> | wow, this is really great -- thanks for the suggestion! |
| 16:09 | <nisci> | oops, wrong chanel |
| 16:47 | <annevk> | hmm |
| 16:48 | <annevk> | so MutationObserver objects are scoped by browsing contexts that can reach each other |
| 16:48 | <annevk> | this dependency game is annoying |
| 16:54 | <annevk> | man |
| 17:01 | <annevk> | so you have a list |
| 17:01 | <annevk> | at some point the mutation observer thing happens |
| 17:01 | <annevk> | you go through the list |
| 17:01 | <annevk> | and for each item where the record queue is non-empty, you invoke the callback |
| 17:01 | <jgraham> | ["eggs", "yoghurt", "milk"] |
| 17:02 | <annevk> | the problem is the scope of the list |
| 17:02 | <annevk> | the DOM has no notion of scripts or browsing contexts |
| 17:03 | <jgraham> | Wrong kind of list it seems :( |
| 17:03 | <annevk> | Each scripting-environment has an associated list of MutationObserver objects maybe? |
| 17:03 | <annevk> | and then a note that says the scripting-environment needs to carefully define the context and when to invoke "notify" or whatever we call it |
| 17:04 | <annevk> | I guess that can work |
| 17:06 | <annevk> | jgraham: I like your list better :) |
| 17:18 | <annevk> | hmm |
| 17:18 | <annevk> | still not dealing with transient observers |
| 17:18 | <annevk> | and aklein is away |
| 17:24 | <kennyluck> | "Thou shalt not refer to the WHATWG version of HTML." |
| 17:24 | <Ms2ger> | s/HATWG/3C/ |
| 17:24 | <annevk> | I guess another problem might be garbage collection |
| 17:25 | <annevk> | I loathe garbage collection |
| 17:25 | <annevk> | also the non-virtual kind |
| 17:37 | <dglazkov> | good morning, Whatwg! |
| 17:43 | <ksweeney> | good morning! |
| 18:23 | <Ms2ger> | "Should "just work" assuming the methods on EventTarget.prototype are generic and flexible enough to work on any object." |
| 18:24 | <Ms2ger> | That sounds awful |
| 18:34 | <annevk> | aklein: so steps 1-4 could be substeps of step 1 of the new invoke algorithm, and step 2 would be to invoke them again if any of the mutationobserver objects has a non-empty record queue |
| 18:34 | <annevk> | aklein: that would address that problem, right? |
| 18:36 | <annevk> | aklein: still need to know what to do with transient observers |
| 18:36 | <aklein> | annevk: that sounds right (and also handles the case of new observers being added during invokation) |
| 18:36 | <aklein> | annevk: let me look at the code real quick... |
| 18:38 | <aklein> | annevk: as for transient: |
| 18:38 | <Velmont> | Mozilla announces HTML5-based phone - http://lwn.net/SubscriberLink/484288/989987e3efcc1fc7/ - The article will open up in 7 days, but thought it'd be interesting for you to read it now :] |
| 18:39 | <Ms2ger> | Oh, did we? |
| 18:39 | <aklein> | annevk: between steps 3 & 4, remove all transient registrations |
| 18:39 | <aklein> | annevk: for the observer you're about to call, that is |
| 18:40 | <Velmont> | Ms2ger: Only copied the title |
| 18:40 | <annevk> | aklein: that sounds surprisingly easy |
| 18:40 | <annevk> | ok I'll write up some next text as it seems this Junta game will delay our dinner plans a little longer :) |
| 18:40 | <annevk> | new text* doh |
| 18:40 | <Velmont> | lol |
| 18:41 | <aklein> | annevk: yeah, it's actually pretty simple. the idea is that since the observer is about to get a chance to run, it no longer needs those transient observers (it can go add new observations wherever it cares to) |
| 18:49 | <annevk> | https://bitbucket.org/ms2ger/dom-core/changeset/c6ad9b7a9dff |
| 18:51 | <annevk> | Ms2ger: "just work" lalala |
| 18:52 | <annevk> | just add some electricity to the water and it'll just work |
| 18:52 | <annevk> | or something |
| 18:58 | <annevk> | aklein: fyi http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-mo-invoke |
| 18:59 | <aklein> | annevk: looks good! |
| 19:00 | <annevk> | good good |
| 19:00 | <annevk> | now Hixie needs to make a change and then we should figure out setting innerHTML / textContent |
| 19:00 | <aklein> | the discussion of simplifying that stuff sort of died out |
| 19:01 | <annevk> | I can see how treating "remove all" and "insert DF" completely separate is somewhat easier, but combining them does not seem that much harder |
| 19:02 | <annevk> | especially as this will only be invoked when the DocumentFragment can be inserted without issue (so you don't need to run the complex insertion steps) |
| 19:04 | Philip` | wonders if there's a good explanation somewhere of why B2G is better than Android plus a web browser |
| 19:04 | <aklein> | the trouble is that "remove all" can trigger synchronous events, so more DOM mutation code can run before we get around to the "insert DF" part |
| 19:05 | <annevk> | well ideally we get rid of mutation events |
| 19:05 | <aklein> | even leaving aside mutation events, there's blur |
| 19:05 | <Ms2ger> | Wasn't the idea to batch such changes up into one listener? |
| 19:05 | <annevk> | oh blur, didn't we have something for that? |
| 19:06 | <annevk> | "The methods are not generic, as WebIDL clearly says." thank god |
| 19:06 | <aklein> | I guess that technically happens _before_ the removal |
| 19:06 | <aklein> | so maybe I shouldn't have to worry about blur... |
| 19:07 | <annevk> | i hope not |
| 19:08 | <annevk> | I think ryosuke had something else, but I forgot |
| 19:08 | <annevk> | <iframe> unload maybe? |
| 19:08 | <annevk> | hmm |
| 19:19 | <Hixie> | annevk, aklein: so calling a callback is itself a microtask... |
| 19:20 | <Hixie> | annevk, aklein: i suppose i don't fire any observers if i'm already busy firing the observers? |
| 19:21 | <aklein> | Hixie: exactly |
| 19:22 | <Hixie> | k |
| 19:23 | <Hixie> | so i invoke the observers after a script runs, unless it's an observer. Then after doing that, I do it again if there's new observers? |
| 19:23 | <Hixie> | or what? |
| 19:24 | <aklein> | Hixie: annevk changed that algorithm to re-invoke itself, so you should only have to call that algorithm once |
| 20:24 | jwalden | belatedly high-fives rniwa as another Fedora user |
| 20:24 | <rniwa> | jwalden: hehe, hi |
| 20:24 | <Ms2ger> | Ubuntu, anybody? :) |
| 20:24 | <TabAtkins> | Right here! |
| 20:24 | jwalden | is still on 14, keeps not finding the time to back up fully before updating to 15 |
| 20:25 | <TabAtkins> | (Well, Gubuntu, but still.) |
| 20:25 | <jwalden> | at the rate I'm going I might just wait to 16, but I really probably shouldn't do that :-) |
| 20:25 | <TabAtkins> | (Or Goobuntu, I think.) |
| 20:25 | <Ms2ger> | I read that as "* jwalden is still 14" |
| 20:25 | Ms2ger | high-... fours TabAtkins |
| 20:25 | <jwalden> | "I know you are but what am I" |
| 20:25 | <jwalden> | and I could even be right! :-P |
| 20:29 | <Ms2ger> | "I'm filing the bug as I type against W3C's HTML5, so we can get the opinion of the DOM people as well." |
| 20:36 | <TabAtkins> | Heh. |
| 20:59 | <Hixie> | aklein: k |
| 21:07 | <kennyluck> | Heh. I wanted to quote that line too. |
| 21:08 | TabAtkins | wonders why random lines from my emails are quotable. |
| 21:13 | <Hixie> | annevk5: yt? |
| 21:14 | <Ms2ger> | TabAtkins, because the DOM people are in WebApps :) |
| 21:14 | <TabAtkins> | True, but the relevant ones follow the list sufficiently well. |
| 21:15 | <TabAtkins> | I'M TRYING TO BE CROSS-DISCIPLINARY. |
| 21:15 | <Hixie> | the relevant ones probably have public-html filtered to /dev/null... |
| 21:15 | <TabAtkins> | But then I talk about it in here, so it's all good again. |
| 21:40 | <annevk> | Hixie: am now |
| 21:40 | <annevk> | Hixie: we went to get some food finally |
| 21:40 | <annevk> | but back now |
| 21:41 | <jgraham> | Philip`: I assume that the value proposition of all-apps-as-webapps over a simple webbrowser is that instead of having to remember the url for every app you want to run you can visit a single page that will conveniently let you search for apps and, if you find one you like, store a link to it locally so it is convenient to find in the future |
| 21:42 | <Velmont> | I still haven't bothered to do the rain dance required to follow public-html. |
| 21:42 | <annevk> | you can email chaals, but the question is whether you really want to read the email |
| 21:42 | <Ms2ger> | You think you'll get away with a rain dance? |
| 21:43 | <Velmont> | annevk: Yes, I keep getting told I really don't want to subscribe anyway. So I'm stuck in the limbo. |
| 21:43 | <Velmont> | Lots of dance methaphors here. |
| 21:44 | <annevk> | Dance Dance Dance is an okay read |
| 21:46 | <jgraham> | Pretty good, but not his best work |
| 21:46 | <jgraham> | One of the early ones to be translated iirc? |
| 21:47 | <jgraham> | Velmont: You could read my public-html mail if you like |
| 21:47 | <annevk> | "I’d loved and been loved, but I had nothing to show. It was a singularly plain, featureless landscape. I felt like I was in a video game. A surrogate Pacman, crunching blindly through a labyrinth of dotted lines. The only certainty was my death." |
| 21:47 | <Velmont> | Don't say too much stuff that require googling, the internet here is pretty darn slow, and I'm sharing it with annevk. |
| 21:47 | <annevk> | jgraham: not sure, I reckon that would have been Norwegian Wood, but I'm not sure |
| 21:48 | <jgraham> | annevk is a walking mine of Murakami facts |
| 21:49 | <bga> | http://webcache.googleusercontent.com/search?q=cache:http://johnbender.us/2012/02/29/faster-javascript-through-category-theory/ |
| 21:50 | <jgraham> | Wikipedia says that "Pinball, 1973" and "Hear the Wind Sing" were first to be translated, but I have never read them |
| 21:50 | <annevk> | those are his first two books |
| 21:50 | <jgraham> | Then "A Wild Sheep Chase" and "Hard Boiled Wonderland and the End of the World" |
| 21:50 | <annevk> | if I remember I'll bring them next time I go to Sweden, whenever that is |
| 21:51 | <jgraham> | Then "Dance Dance Dance" |
| 21:51 | <jgraham> | Norwegian Wood was written earlier but translated later |
| 21:51 | <jgraham> | annevk: That would be totally excellent |
| 21:51 | <annevk> | yeah I was about to say, interesting |
| 21:52 | <Velmont> | I should read one of his books. |
| 21:52 | <jgraham> | s/one/all/ |
| 21:52 | <Velmont> | jgraham: Well, let's not get ahead of ourselves here. |
| 21:53 | <annevk> | Hixie: in https://www.w3.org/Bugs/Public/show_bug.cgi?id=16142 your comment regarding GC got trimmed |
| 21:53 | <jgraham> | Velmont: Well I probably wouldn't start with Dance Dance Dance. |
| 21:54 | <Velmont> | jgraham: Nope. Maybe Norwegian Wood, since that is so well known? Or is there a better one to start at? |
| 21:55 | <jgraham> | Norwegian Wood is a fine choice. I think I read The Wind Up Bird Chronicle first. Or perhaps Kafka on the Shore |
| 21:56 | <annevk> | I want to read Kafka on the Shore again, read it in Dutch initially |
| 21:58 | <jgraham> | Well if you ever make it to Lkpg you are welcome to borrow my copy |
| 21:59 | <Velmont> | I want to go to Lkpg too. |
| 22:00 | <Velmont> | Never been much in Sweden. |
| 22:00 | <Hixie> | annevk: actually it didn't, i never wrote anything and apparently forgot to delete it :-) |
| 22:00 | <Hixie> | annevk: never wrote anything after what you see, i mean |
| 22:01 | <jgraham> | Velmont: Well I'm sure you would be quite welcome if you could find a half decent excuse :) |
| 22:02 | <annevk> | heh |
| 22:04 | <Velmont> | jgraham: annevk suggested working on the XHR testsuite. :] No real reason to do it there, but could classify as half-decent. |
| 22:06 | <annevk> | reason might be waste: http://annevankesteren.nl/2010/12/waste |
| 22:06 | <annevk> | cf Dance Dance Dance |
| 22:07 | <jgraham> | Velmont: Or come over and give an opera:talk on something |
| 22:11 | <Hixie> | css people might want to review my naive TextMetrics proposal at http://wiki.whatwg.org/wiki/Canvas#TextMetrics |
| 22:12 | <TabAtkins> | Hixie: Ping www-style? |
| 22:12 | <Hixie> | i never get any useful feedback when i do that |
| 22:12 | <TabAtkins> | Well, I can't give very useful feedback - text isn't my thing. |
| 22:13 | <Hixie> | (and if i get any feedback at all, it's usually along the lines of "oh, we should provide that, let us write a spec and reference that" and then i never heard back) |
| 22:13 | <Hixie> | s/heard/hear/ |
| 22:14 | <gsnedders> | Velmont: I started with Kafka on the Shore (jgraham's copy thereof!), which I loved. |
| 22:15 | <othermaciej> | Hixie: I'm not a text expert, but you seem to have a copy-paste error on "// distance from textBaseline to hanging baseline" |
| 22:15 | <othermaciej> | seems copied a few times where it does not apply |
| 22:15 | <Hixie> | oops |
| 22:15 | <Hixie> | fixed, thanks |
| 22:16 | <othermaciej> | also you define many things as distances relative to textBaseline but the textBaseline property itself is not there |
| 22:17 | <othermaciej> | (maybe it's 0 by definition in your model?) |
| 22:17 | <Hixie> | textBaseline is a property on the context |
| 22:17 | <othermaciej> | our text expert says "the definitions of the metrics look sane to me, i’m assuming “the text” and a CSS font are in the context somehow" |
| 22:17 | <Hixie> | (that already exists) |
| 22:17 | <othermaciej> | the property on the context is a string though |
| 22:17 | <Hixie> | yeah |
| 22:19 | <TabAtkins> | othermaciej: Any clue who I would talk to about killing the restriction on webkit bugzilla that your passwords must be <= 16 character? |
| 22:20 | <othermaciej> | TabAtkins: my guess is that this restriction exists only because we are using an old version of bugzilla, assuming it is fixed in newer bugzilla instances |
| 22:20 | <Hixie> | why does canvas only do affine transforms? |
| 22:20 | <othermaciej> | if so, the person to talk to is Lucas Forschler, but I am not sure how soon he'll be able to update us to a newer version |
| 22:20 | <TabAtkins> | Hixie: Becaue that's what CSS transforms are? |
| 22:20 | <TabAtkins> | And SVG? |
| 22:20 | <Hixie> | but why? |
| 22:20 | <othermaciej> | most 2D graphics systems only have affine transforms built in |
| 22:20 | <TabAtkins> | Shrug. They're simple. |
| 22:20 | <othermaciej> | which non-affine transforms do you think it should do? |
| 22:21 | <TabAtkins> | You can efficiently transform most curves if you stick to affine. |
| 22:21 | <Hixie> | i dunno, there's a bug here saying we should allow non-affine transforms, and i was just wondering if it was just a matter of allowing it, or if there was some reason we were avoding it |
| 22:21 | <Hixie> | avoiding |
| 22:21 | <TabAtkins> | And can always represent the current transform with a 4x4 matrix. |
| 22:22 | <TabAtkins> | Bezier curves can only be efficiently transformed if you restrict yourself to a limited set of transforms. |
| 22:22 | <othermaciej> | affine transforms in 2D space can be represented with a 3x3 matrix |
| 22:22 | <othermaciej> | (or 3x2 if you want to make it more compact) |
| 22:22 | <othermaciej> | does the bug say what other kinds of transforms should be supported? |
| 22:23 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=9235 is the bug |
| 22:23 | <othermaciej> | "non-affine transform" doesn't define a specific thing |
| 22:23 | <Hixie> | "perspective" is the term the guy uses |
| 22:23 | <othermaciej> | ah |
| 22:23 | <othermaciej> | I don't think perspective projections make sense in an otherwise 2D API |
| 22:23 | <othermaciej> | you want 3D, use WebGL |
| 22:23 | <TabAtkins> | I don't really agree with that. But lemme see... |
| 22:24 | <Hixie> | i commented on the bug that if they wanted it they should get a us to implement it first |
| 22:24 | <othermaciej> | 3D perspective projections require more space to store, are slower to apply, and often aren't supported natively by the relevant 2D graphics APIs |
| 22:25 | <TabAtkins> | I think you need to convert your curves up into NURBS to get efficient perspective transforms. |
| 22:26 | <TabAtkins> | But yeah, getting a UA to implement them first seems like a good thing to require. |
| 22:28 | gsnedders | waits for nobody to implement it because it's non-standard |
| 22:28 | <TabAtkins> | gsnedders: Just pay someone to put it in webkit. |
| 22:28 | <othermaciej> | I don't really see the point of adding them to the 2D API |
| 22:28 | <annevk> | oh, list of new canvas features keeps growing |
| 22:28 | <othermaciej> | you don't really want to be doing perspective transforms in software |
| 22:29 | <TabAtkins> | othermaciej: Some types of 3d transforms are useful even within the limited canvas2d api. It's kinda sucky to require someone to go learn webgl for simple effects like that when they're not actually needing the power of it. |
| 22:29 | <othermaciej> | even for "2.5D" type effects you need more than just 3d transforms as such |
| 22:30 | <othermaciej> | they make sense in CSS transforms because the UA can compute intersections and occlusions and such |
| 22:30 | <gsnedders> | TabAtkins: 20k USD? :P |
| 22:30 | <othermaciej> | (and can also hardware accelerate everything) |
| 22:31 | <TabAtkins> | gsnedders: Wired straight to my bank account, yes. |
| 22:42 | <jamesr__> | gsnedders, TabAtkins: don't forget you need to bribe a webkit reviewer too |
| 22:43 | <TabAtkins> | jamesr__: Shhh! |
| 22:43 | <TabAtkins> | You'll cost me 20k! |
| 23:04 | <Hixie> | anyone know if anyone is using mozFillRule? |
| 23:10 | <Hixie> | hmmmm |
| 23:10 | <Hixie> | instead of having pattern.offsetX and pattern.offsetY |
| 23:10 | <Hixie> | why not just put all the transformation logic into CanvasPattern |
| 23:10 | <Hixie> | so you can arbitrarily transform the pattern |
| 23:11 | <TabAtkins> | +1 |
| 23:11 | <Hixie> | i guess we'd have to add an explicit .resetPattern() so that people don't have to keep calling .setTransform(...) with an identity matrix |
| 23:12 | <Hixie> | er |
| 23:12 | <Hixie> | resetTransform() |
| 23:17 | <Hixie> | heycam, shepazu: any idea whether i should be referring to svg 1.1 or 1.2 for SVGMatrix? they seem to be different. |
| 23:18 | <heycam> | Hixie, 1.1 |
| 23:18 | <Hixie> | k |
| 23:18 | <Hixie> | so er |
| 23:18 | <Hixie> | where is it defined? |
| 23:18 | <heycam> | coords.html I think |
| 23:18 | <heycam> | or types.html |
| 23:19 | <Hixie> | i found the idl, and a bunch of non-normative text like the html spec's "domintro" blocks that introduces each member |
| 23:19 | <Hixie> | but i can't find the requirements |
| 23:19 | <heycam> | remember that the spec was written in a time when MUSTs weren't littered about everywhere |
| 23:19 | <heycam> | or without necessarily a lot of detail :) |
| 23:20 | <Hixie> | there's "without a lot of detail" and then there's no detail at all... |
| 23:20 | <heycam> | unfortunately the DOM parts of SVG 1.1 are often the areas that lack detail |
| 23:20 | <Hixie> | ok |
| 23:20 | <Hixie> | well |
| 23:20 | <heycam> | what specifically are you looking for? |
| 23:20 | <Hixie> | apparently i'm gonna be referring to this from the HTML spec |
| 23:21 | <Hixie> | so if you wanted something to focus on for SVG2, consider this a candidate :-) |
| 23:21 | <heycam> | ok! :) |
| 23:21 | <heycam> | are you looking for steps on what the SVGMatrix methods do? or...? |
| 23:21 | <othermaciej> | is canvas going to use SVGMatrix to represent transforms? |
| 23:21 | <Hixie> | heycam: i'm looking for something sufficiently detailed that we can make sure it's tested in the html test suite |
| 23:22 | <Hixie> | othermaciej: yeah, apparently it's what mozilla does |
| 23:22 | <Hixie> | othermaciej: so i'm looking at how feasible it is |
| 23:22 | <othermaciej> | makes sense |
| 23:22 | <othermaciej> | there is also SVGTransform, I can't remember how it is supposed to be different |
| 23:22 | <heycam> | there was discussion on the FX list recently about a unified Matrix interface -- that was more merging CSSMatrix/SVGMatrix |
| 23:22 | <Hixie> | so there is |
| 23:22 | <Hixie> | heycam: yeah |
| 23:22 | <heycam> | othermaciej, SVGTransform is the list of transform items like "scale(4)" etc. |
| 23:23 | <Hixie> | ah, yeah, SVGTransform is just to represent the lexical form |
| 23:23 | <Hixie> | not to represent an actual transform |
| 23:23 | <othermaciej> | there also appears to be an SVGTransformList |
| 23:23 | heycam | frowns at SVGMatrix.rotate() not even defining if the argument is radians or degrees or what |
| 23:23 | <heycam> | sorry |
| 23:23 | <heycam> | SVGTransform is one item |
| 23:23 | <heycam> | in an SVGTransformList |
| 23:23 | <Hixie> | SVGTransformList is the list of SVGTransforms |
| 23:23 | <Hixie> | that <svg:* transform=""> is represented by |
| 23:24 | <Hixie> | heycam: i got stuck at the definition of "a" |
| 23:24 | <heycam> | lol |
| 23:25 | <heycam> | above the IDL it shows what a, b, c, etc. correspond to in the matrix |
| 23:25 | <Hixie> | well i can guess what might make sense to happen, sure |
| 23:26 | <othermaciej> | CSSMatrix seems to be a 3d transform |
| 23:26 | <othermaciej> | it seems useful to be a 2d-transform-specific interface |
| 23:26 | <othermaciej> | though the name difference being "SVG" vs "CSS" for 2d vs 3d isn't the world's best naming convention |
| 23:26 | <heycam> | yeah, that sucks |
| 23:26 | <Hixie> | i find it amusing that neither SVGMatrix and CSSMatrix both to define a method to reset the matrix to the identity transform |
| 23:27 | <jamesr__> | just make a new one! |
| 23:27 | <Hixie> | i wonder whether i should not bother adding such a method to the context/path/pattern interfaces and instead assume that Matrix will spawn it, or if i should just continue the design of canvas and have a method parallel to the object |
| 23:28 | <Hixie> | christ, CSSMatrix is defined about as badly |
| 23:28 | <othermaciej> | SVGMatrix operations generally return a new matrix rather than mutating the existing one |
| 23:28 | <Hixie> | all these specs use the old DOM style of defining interface members |
| 23:28 | <heycam> | Hixie, will the canvas allow assignment of a different matrix object on to the context? |
| 23:28 | <Hixie> | single worst way to define an interface ever invented |
| 23:28 | <Hixie> | yet everyone thinks it's so cool and copies it everywhere |
| 23:28 | <Hixie> | gah |
| 23:29 | <heycam> | what is "old DOM style"? |
| 23:29 | <Hixie> | the three nested <dl>s you see in all the old DOM specs |
| 23:29 | <heycam> | ah right |
| 23:29 | <heycam> | yeah it does take a bit too much vertical space for my liking |
| 23:29 | <Hixie> | heycam: not planing on allowing assignment currently, but i suppose we could |
| 23:29 | <Hixie> | sure, why not |
| 23:30 | <othermaciej> | I think it's generally better to apply value semantics to transform matrices, so that to alter the transform in use for something you give it a new matrix rather than attempting to mutate the one returned by a getter |
| 23:30 | <othermaciej> | a method to reset a specific matrix to the identity matrix would not be useful in that model |
| 23:30 | <Hixie> | k, external method it is |
| 23:31 | <othermaciej> | all you need is an easy way to make a fresh identity matrix |
| 23:31 | <jamesr__> | matrices are a bit on the large side to copy all the time |
| 23:32 | <othermaciej> | yeah, but having to map mutation operations to operations on some arbitrary other object that owns the matrix is also crazy |
| 23:33 | <othermaciej> | (also, for the 3x2 representation of an affine transform matrix, it's barely more expensive to copy than a rect) |
| 23:47 | <Hixie> | heh, this e-mail's use case is making a google Wave extension |
| 23:47 | <Hixie> | problem solved! |
| 23:56 | <Hixie> | shepazu: won't be able to give feedback for d="" processing this week, will keep you posted |
| 23:56 | <shepazu> | Hixie: ok |