| 00:17 | <TabAtkins> | Hixie: I'm not sure what you find hard to understand about the appcache use-case in https://www.w3.org/Bugs/Public/show_bug.cgi?id=14702 |
| 00:17 | <TabAtkins> | The desired behavior is basically: |
| 00:17 | <TabAtkins> | (1) If you're online, proceed as normal. Fetch everything from online or the HTTP cache as appropriate, and update appcached resources as appropriate. |
| 00:18 | <TabAtkins> | (2) If you're offline, use the appcache. |
| 00:18 | <TabAtkins> | And that's it. |
| 00:19 | <TabAtkins> | This is desirable over http caching because (1) http cache doesn't reliably work offline, and (2) http cache entries can disappear non-atomically, creating a broken app. |
| 00:19 | <TabAtkins> | Whereas the appcache for a site expires all at once, so it's easy to tell why the page is "broken", since it doesn't work offline at all. |
| 00:20 | <TabAtkins> | You even allude to precisely the benefit being sought ("other than making the file available offline") in comment #24, but don't seem to understand that's all that's desired. |
| 00:28 | <Hixie> | TabAtkins: everyone i've spoken to about this says "it's easy, the desired behaviour is just X" with a different value of X each time :-P |
| 00:29 | <Hixie> | TabAtkins: what i don't understand about the description you just gave, though, is why people so desperately want to avoid restructuring their page to separate their data from their structure |
| 00:29 | <TabAtkins> | Because it's a *very significant* restructuring. |
| 00:29 | <Hixie> | TabAtkins: sure, it's not cheap to do, but it has such radical benefits that i don't understand the reluctance |
| 00:30 | <Hixie> | TabAtkins: it's nowhere near as hard as people seem to make out |
| 00:30 | <Hixie> | TabAtkins: you can even do it incrementally, where initially your "data" is just the whole page which you innerHTML in |
| 00:30 | <TabAtkins> | And it's not all rainbows and sunshine. Sending an empty <body> and filling it with script is bad for spiders and accessibility generally. |
| 00:30 | <Hixie> | i don't see why it's bad for a11y |
| 00:31 | <TabAtkins> | I don't know what the effects of filling in the body from script are to common a11y tools. |
| 00:48 | <heycam> | Hixie, apart from onerror, do all of the remaining event listener attributes only ever get called with a single Event object? |
| 00:49 | <Hixie> | i believe so |
| 00:49 | <Hixie> | but wouldn't be willing to stake money on it |
| 00:49 | <Hixie> | MikeSmith: cvs lock issue |
| 00:49 | <Hixie> | MikeSmith: nevermind |
| 00:49 | <heycam> | Hixie, ok thanks |
| 00:49 | <Hixie> | bbiab |
| 00:49 | <MikeSmith> | Hixie: ok, but if the lock problem happens again lemme know |
| 00:49 | <Hixie> | roger |
| 00:50 | <zewt> | cvsin' like it's 1995 |
| 00:53 | <MikeSmith> | anybody round here on the Google+ dev team? |
| 00:53 | <MikeSmith> | I could use help with something... |
| 00:57 | <divya> | MikeSmith: on twitter @codedread is there. |
| 01:10 | MikeSmith | pings Malte Ubl |
| 05:33 | <Hixie> | in XML, <p/>x means an empty <p> with an "x" after it |
| 05:33 | <Hixie> | in HTML, <p/>x means a <p> that contains an "x" (and is invalid) |
| 05:35 | <mikenton> | :) |
| 05:35 | <mikenton> | Thank you. |
| 09:52 | <asmodai> | Anyone happen to know Firefox/Mozilla's timeframe on the Web Audio API? |
| 09:55 | <annevk> | heycam|away: +1 for the new callback syntax |
| 09:55 | <annevk> | guess I'll email that to the list |
| 10:05 | <jgraham> | asmodai: Do people even think that API's a good idea? Last time I looked it seemed super-complex |
| 10:06 | <jgraham> | I tought roc had an alternative suggestion which looked (to my untrained eye) much nicer |
| 10:08 | <asmodai> | jgraham: I got some gamedevs asking about when firefox will implement it. |
| 10:08 | <asmodai> | I guess the recent port of Bastion to NaCL for Chrome also helped act as a catalyst. |
| 10:09 | <asmodai> | But let me ask them about the complexity of that API. |
| 10:32 | <annevk> | Web IDL updates excite me |
| 10:32 | <annevk> | #weird |
| 10:32 | <jgraham> | That's one hell of a fetish you've got going there |
| 10:33 | <Ms2ger> | ^ |
| 10:33 | <annevk> | I think the Encoding Standard is a weirder one |
| 10:36 | zcorpan | doesn't want to know what annevk does together with the Encoding Standard at night |
| 10:36 | <Ms2ger> | "Think" about it |
| 10:36 | annevk | doesn't want to tell |
| 10:38 | <hendry> | can the help list please be moderated? http://lists.whatwg.org/pipermail/help-whatwg.org/2011-December/000969.html is junk |
| 10:39 | <annevk> | email Hixie |
| 10:44 | <annevk> | http://dev.chromium.org/developers/how-tos/make-a-web-standards-proposal |
| 10:48 | <MikeSmith> | annevk: abarth wrote that I guess |
| 10:50 | <jgraham> | MikeSmith: Yep |
| 10:52 | <annevk> | so single-octet encodings works |
| 10:52 | <Ms2ger> | Automated tests please? :) |
| 10:52 | <annevk> | it seems putting multi-octet encodings inline might be problematic |
| 10:53 | <annevk> | some are gigantic |
| 10:53 | <annevk> | Ms2ger: yes I should make those |
| 10:54 | <annevk> | Ms2ger: but it's fairly trivial for anyone to do so |
| 10:57 | <zcorpan> | annevk: how gigantic? |
| 11:00 | zcorpan | finds a table for big5 |
| 11:03 | <gsnedders> | annevk: Nothing is as gigantic as GB18030. |
| 11:24 | <asmodai> | jgraham: response: |
| 11:24 | <asmodai> | I found it pretty straight forward. At least for just playing a simple sound. Problem is getting same behaviour from FF and Chrme |
| 11:30 | <jgraham> | asmodai: (I like to think that getting proper cross-browser support would be the problem not just "FF and Chrome") |
| 11:39 | <asmodai> | jgraham: IE is not interesting enough to develop on |
| 11:39 | <asmodai> | and Opera, pardon me saying it, just doesn't have the market share as target |
| 11:39 | <asmodai> | so that leaves FF and Chrome. |
| 11:40 | <asmodai> | At least, that's my interpretation on what I am seeing from these dev folks. |
| 11:50 | <asmodai> | response: Pretty much, Opera support would be nice, but not a huge |
| 11:50 | <asmodai> | issue for me right now. IE: Chrome Frame makes it works as Chrome. |
| 11:51 | <bga> | khtml! |
| 11:51 | <asmodai> | jgraham: Does that help? :) |
| 11:53 | <annevk> | argh expenses |
| 11:53 | <bga> | asmodai btw chrome will get 70+% in 2013 |
| 11:53 | <annevk> | hate hate hate |
| 11:53 | <bga> | => chrome only dev |
| 11:54 | <asmodai> | bga: market share? Time will tell how it will go. |
| 11:54 | <asmodai> | If there's one thing that the last 15 years have shown is that browsers and their market share come and go. :) |
| 11:54 | <bga> | http://en.wikipedia.org/wiki/File:Usage_share_of_web_browsers_(December_2011,_Source_StatCounter).jpg |
| 11:55 | <bga> | extrapolate that :) |
| 11:56 | <asmodai> | Sure, and time has the uncanny effect of changing charts like that as well. :) |
| 11:56 | <asmodai> | I'll just stick to as much cross-platform as I can. |
| 11:57 | <asmodai> | It's a bit funny. When people were IE-only devs they got called names, but when you do chrome-only it should suddenly be alright? :-P |
| 11:57 | <bga> | chrome is new IE |
| 11:58 | <bga> | tons of features |
| 11:58 | <asmodai> | That statement in and of itself is scary :) |
| 11:58 | <bga> | activex! |
| 11:58 | <bga> | aka nacl |
| 11:59 | <jgraham> | OMG! By 2020 Chrome will have 200% market share! |
| 12:00 | <bga> | 99% :) |
| 12:00 | <bga> | and 1% - lynx |
| 12:00 | <asmodai> | jgraham: Anyway, did those responses help you a bit? :) |
| 12:01 | <jgraham> | Alternative theory: linear extrapolation without regrad for the actual dynamics is bad |
| 12:01 | <jgraham> | asmodai: Well sort of. I don't kow much about the audio work |
| 12:01 | <jgraham> | I just know that the chrome API looks really complicated |
| 12:01 | <asmodai> | jgraham: Ah ok |
| 12:01 | <asmodai> | I haven't played with it yet. |
| 12:02 | <beverloo> | It's a much more declarative approach |
| 12:02 | <asmodai> | But I know many gamedevs are looking at the webbrowser for implementing more involved games than the social ones available now |
| 12:02 | <asmodai> | and also to build their tools in |
| 12:02 | <jgraham> | Possibly all that complexity is needed, but my expectation is that it's not |
| 12:02 | <asmodai> | IIRC Insomniac Games already deployed some tools to browser-only. |
| 12:02 | <beverloo> | First steps are harder than usual, as you have to get used to the concept behind the nodes |
| 12:02 | <beverloo> | but after that it's really easy to work with |
| 12:03 | <asmodai> | I was just curious if and when FF will support Web Audio API as well :) |
| 12:03 | <beverloo> | An umbrella draft was published about a week ago |
| 12:03 | <beverloo> | The Audio Working Group is still in flux about which proposal they're going to pursue |
| 12:04 | <asmodai> | So is Chrome a bit too early with their implementation? |
| 12:04 | <beverloo> | no earlier than Mozilla is |
| 12:05 | <Ms2ger> | Which are prefixed? |
| 12:05 | <asmodai> | beverloo: Sorry, not up to date on all implementation details, so bear with me please :) Mozilla/Gecko already has it in Nightly or so? |
| 12:05 | <beverloo> | Ms2ger, yes, both are. |
| 12:06 | <beverloo> | asmodai, Mozilla has the Audio Data API, which provides similar (though through a more imperative way) functionality |
| 12:06 | <beverloo> | https://wiki.mozilla.org/Audio_Data_API |
| 12:07 | <beverloo> | The umbrella document is here: http://www.w3.org/2011/audio/drafts/1WD/ |
| 12:07 | <asmodai> | beverloo: thanks, forwarding and adding to my own reading list |
| 12:11 | <erlehmann> | is there any abstraction for all that? |
| 12:11 | <erlehmann> | i am thinking about porting libglitch |
| 13:18 | <asmodai> | wrt that Mozilla implementation of Audio API, I got told: |
| 13:18 | <asmodai> | Yep, I've been using the two specs. I prefer the web audio one over mozilla. Using xhr to fetch buffer seems to offer more ctrl |
| 13:50 | <hsivonen> | next time Mozilla proposes an API, it needs to be named "Web [noun]" |
| 13:54 | <annevk> | Ms2ger: if you can change Gecko for ibm864 that works for me |
| 13:54 | <annevk> | Ms2ger: our encoding guy claims that the encoding is not usable for Arabic anyway because it's in visual order rather than the way HTML works |
| 13:55 | <annevk> | Ms2ger: and therefore we don't support it and because there's no page out there using it (at least as far as we know) |
| 13:55 | <hsivonen> | annevk: Gecko has (used to have) special magic for visual Arabic and visual Hebrew |
| 13:55 | <hsivonen> | annevk: maybe the magic is just an implicit bidi override |
| 13:56 | <hsivonen> | annevk: dunno how relevant visual Arabic and visual Hebrew are on the Web today |
| 13:56 | <annevk> | I wonder why nobody ever bothered to more formally standardize the rules |
| 13:56 | <hsivonen> | s/(used to have)/(used to have?)/ |
| 13:57 | <hsivonen> | annevk: support was contributed by IBM in the early days when people thought information flows from the W3C to vendors but not back |
| 13:58 | <annevk> | fair enough |
| 13:58 | <annevk> | hopefully I can fix some of that |
| 14:31 | <hsivonen> | it's sad that stuff like this has happened this year https://bugzilla.mozilla.org/show_bug.cgi?id=673680 |
| 14:32 | <gsnedders> | hsivonen: Sad, but not surprising. |
| 14:34 | <Ms2ger> | And Google is to blame, once more |
| 15:26 | <bga> | ppl want analogs of opera.collect() in other browsers to wakeup GC |
| 15:34 | <hsivonen> | Is GB18030 the only CJK-oriented encoding that can encode all of Unicode? |
| 15:34 | <hsivonen> | can Shift_JIS encode everything? |
| 15:36 | <zewt> | no |
| 15:37 | <zewt> | (to SJIS) |
| 15:49 | <abarth> | annevk5, MikeSmith: i'm open to feedback on that "how to" if you think we should be doing things differently |
| 16:44 | <smaug____> | hmm |
| 16:44 | <smaug____> | does some spec define VoidCallback ? |
| 16:46 | <smaug____> | apparently no |
| 16:46 | <zewt> | is that an old (removed) webidl thing? |
| 16:47 | <smaug____> | or it is in some File system API |
| 16:47 | <smaug____> | but it is buggy even there |
| 16:47 | <smaug____> | and copied to Mouse Lock |
| 16:47 | <zewt> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015239.html |
| 16:47 | <smaug____> | but MouseLock is still very buggy |
| 16:48 | <zewt> | not a fan of the fs-api spec, personally... too much an old-style listing of requirements and too few clear algorithms |
| 16:48 | <zewt> | (not to say I don't like the features it defines; I do) |
| 16:49 | <smaug____> | file system APi is rather bad, and not reviewed |
| 16:51 | smaug____ | is always so positive :) |
| 16:52 | <zewt> | i really want to see the use cases it addresses implemented (being able to drag a directory to a page to let a page access native files would be *really* useful) |
| 16:57 | <zewt> | i don't know which is worse, people who send emails in gigantic fonts, or people who completely ignore requests to reset their font |
| 16:58 | <smaug____> | zewt: or people who send html email |
| 16:58 | <zewt> | eh it's too late for that |
| 16:58 | <smaug____> | given we're actively trying to break the web, we can try to change email handling too :) |
| 16:58 | <zewt> | raging over html mail is like raging over cookies, the world has moved on :) |
| 16:59 | <erlehmann> | zewt, send emails back using a big U+1F438 FROG FACE |
| 16:59 | <zewt> | if ever there was a valid use case for PILE OF POO |
| 17:01 | <erlehmann> | π° π΄ππΏπ΄ππ πΏππΎπΆππ°πΌπΌπ΄ππ |
| 17:02 | <zewt> | default glyph ahoy |
| 17:28 | <dglazkov> | good morning, Whatwg! |
| 17:30 | <jhawkins> | good morning dglazkov! |
| 17:35 | <bga> | http://img716.imageshack.us/img716/8493/fatfox.png |
| 17:37 | <rillian> | looks more like pregnantfox |
| 17:38 | <Ms2ger> | Did you know Chrome has been using 64bit machines for a few years because they're way past the limit Firefox is hitting? |
| 17:46 | <zewt> | off-hand, can anyone name an API that performs a resource fetch from a queued task, other than server-sent events? seems like there'd be a lot, but I can't find any others |
| 17:46 | <zewt> | (most fetches are started from synchronous sections, not tasks) |
| 17:47 | <zewt> | (rather, with "run the rest of this stuff asynchronously" sections) |
| 17:50 | <zewt> | "ilhan y" with the most nonsequitur mail I've seen in a while |
| 18:25 | <zewt> | yuck, chrome seems to reload the page when you hit enter on the address bar with a fragment id |
| 18:26 | <zewt> | i do that a lot in FF to quickly jump back to where I started and it doesn't reload anything (which matters with the single-page HTML spec) ... i guess it's better in other cases |
| 19:13 | <rniwa> | question: don't we want to remove SVG font support? |
| 19:13 | <shepazu> | rniwa: depends on who "we" are? |
| 19:13 | <rniwa> | shepazu: major browser vendors |
| 19:14 | <rniwa> | shepazu: I thought we are going to remove that from acid3 even |
| 19:14 | <rniwa> | annevk5: ? |
| 19:14 | <smaug____> | I thought we want to have sane spec for SVG fonts first, and then decide whether it is good for the web |
| 19:14 | <smaug____> | rniwa: acid3 doesn't test svg fonts anymore |
| 19:14 | <rniwa> | smaug____: so we want to keep SVG fonts? |
| 19:14 | <rniwa> | smaug____: yeah |
| 19:14 | <smaug____> | I didn't say we want to keep svg fonts |
| 19:15 | <smaug____> | I said there should be a sane spec |
| 19:15 | <rniwa> | smaug____: ok. |
| 19:15 | <rniwa> | smaug____: https://bugs.webkit.org/show_bug.cgi?id=68179 |
| 19:15 | <smaug____> | spec which someone might implement |
| 19:15 | <smaug____> | but I'm sure roc has more to say about svg fonts |
| 19:15 | <rniwa> | smaug____: I'd rather not enable the feature on webkit by default if we're either removing or changing the spec radically |
| 19:15 | <shepazu> | I think SVG fonts are given short shrift, they are actually quite useful |
| 19:16 | <rniwa> | shepazu: usefulness things are good only if they're also sane |
| 19:16 | <rniwa> | for implementors |
| 19:17 | <rniwa> | e.g. deadlock free operating system is useful but nobody wants to implement that. |
| 19:17 | <Ms2ger> | I read "deadlocking the operating system is useful" |
| 19:17 | <Ms2ger> | And was rather confused |
| 19:18 | <rniwa> | Ms2ger: hehe. deadlocking the operating system might indeed be useful if you're an attacker ;) |
| 19:18 | <rniwa> | Ms2ger: deadlocking the OS will be one perfect DoS attack indeed. |
| 19:45 | <annevk> | where is sicking? |
| 19:45 | <annevk> | http://test.s0.no/cors/status.htm should not throw |
| 20:12 | <annevk> | rniwa: my understanding is that those that have implemented SVG fonts implemented a subset |
| 20:12 | <annevk> | rniwa: so I suspect that if they are to stay someone has to write a spec on how they actually should work |
| 20:13 | <annevk> | rniwa: and if that spec has sufficient implementor feedback it might be something that's useful to have |
| 20:13 | <annevk> | sicking: http://test.s0.no/cors/status.htm |
| 20:13 | <annevk> | sicking: fix bugs! |
| 20:13 | <annevk> | ;) |
| 20:14 | <smaug____> | annevk: please file a bug and assign it to sicking :) |
| 20:15 | <sicking> | annevk: how do i find the actual tests |
| 20:15 | <annevk> | sicking: view source? |
| 20:15 | <sicking> | annevk: also, you seem to be missing redirect tests since I know we don't use the correct "Origin" header for those |
| 20:16 | <annevk> | these are not mine |
| 20:16 | <annevk> | and these are not what Opera's going to submit when we get around to that |
| 20:16 | <annevk> | I'm sure there's more bugs, this one just seemed quite weird :) |
| 20:17 | <sicking> | ugh, these tests are hard to read |
| 20:18 | <annevk> | http://mediamatters.org/blog/201112120005 o_O |
| 20:19 | <annevk> | newnewtwitter so slow |
| 20:19 | <annevk> | meh |
| 20:21 | <sicking> | annevk: oh, it's because we have a special exception for "X-Custom". We always allow that header to be set and read |
| 20:22 | <annevk> | proprietary extensions? |
| 20:23 | <annevk> | we can standardize that if you want... |
| 20:23 | <annevk> | will get the web littered with x-custom I guess |
| 20:23 | <sicking> | naah, just kidding, we don't have anything like that |
| 20:23 | annevk | is getting confused |
| 20:24 | <sicking> | i suspect that would introduce CSRF everywhere :) |
| 20:24 | <annevk> | TabAtkins: MutationObserverInit is a dictionary, not an interface |
| 20:24 | <sicking> | i have no idea why these tests fail |
| 20:24 | <sicking> | because i still don't understand what they do |
| 20:24 | <TabAtkins> | annevk: Ah, I didn't realize there was a significant difference. |
| 20:24 | <annevk> | sicking: because you throw on .status I guess |
| 20:25 | <annevk> | sicking: they give back custom status codes for either preflight or response |
| 20:25 | <sicking> | annevk: but we only throw when people would otherwise return 0, right? |
| 20:25 | <annevk> | sicking: see the table above |
| 20:25 | <annevk> | sicking: I think per spec you should return the actual response code |
| 20:25 | <annevk> | as happens in WebKit |
| 20:26 | <annevk> | WebKit fails 5, because it doesn't fail preflight requests that have a non-200 status |
| 20:26 | <sicking> | i thought we returned the real code as soon as it's available |
| 20:26 | <sicking> | tests that don't give any feedback other than pass/fail sort of suck :( |
| 20:27 | <sicking> | oh, i guess there's the message thing |
| 20:27 | <sicking> | but it doesn't tell me everything that the real exception contains, like line number |
| 20:27 | <annevk> | seems pretty clear why it fails to me |
| 20:27 | <annevk> | TabAtkins: yeah, dictionaries are not exposed |
| 20:28 | <annevk> | TabAtkins: not sure if that's a feature or not, maybe we should have something to inspect dictionaries |
| 20:28 | <sicking> | annevk: so yeah, 1,2,5 probably fail because we throw rather than return 0. File a bug on smaug for that :) |
| 20:29 | <zewt> | annevk: the general pattern of interfaces + dictionaries that look almost identical is sort of annoying... |
| 20:29 | <smaug____> | no no, sicking, cors is yours |
| 20:29 | <zewt> | i think it would be more annoying if it exposed two very similar objects, though |
| 20:29 | <zewt> | (to scripts, I mean) |
| 20:29 | <sicking> | smaug____: this isn't cors specific. Our XHR implementation always throws for .status when it should return 0 |
| 20:29 | <zewt> | at least right now the repetition is only internal |
| 20:29 | <sicking> | smaug____: i.e. when the channel failed |
| 20:29 | <smaug____> | though, I did change status handling at some point to be closer to what the spec wanted |
| 20:34 | <annevk> | per spec status should work from 2 |
| 20:35 | <rniwa> | sicking, annevk: would you care to comment on https://bugs.webkit.org/show_bug.cgi?id=68179 ? |
| 20:36 | <rniwa> | eric wants some clarification on the state of SVG fonts |
| 20:36 | <WeirdAl> | Ms2ger: ping re DOM4 spec |
| 20:36 | <sicking> | rniwa: https://plus.google.com/107429617152575897589/posts/JdHnqpuUER4 |
| 20:36 | <sicking> | rniwa: that's the announcement for SVG fonts being dropped from ACID3 |
| 20:36 | <rniwa> | sicking: thanks! |
| 20:37 | <sicking> | rniwa: http://robert.ocallahan.org/2010/06/not-implementing-features-is-hard_03.html |
| 20:37 | <sicking> | rniwa: that's the context of mozilla pushing back against svg fonts |
| 20:37 | <annevk> | rniwa: done |
| 20:38 | <sicking> | rniwa: there's also been discussions on the SVG lists regarding dropping them from future versions of the SVG spec, but i don't have links for that |
| 20:38 | <rniwa> | sicking: thanks! |
| 20:38 | <rniwa> | sicking: I've added a comment with those URLs |
| 20:39 | <rniwa> | sicking: do you know where what SVG WG discussion is? |
| 20:39 | <rniwa> | is webkit currently the only engine that supports SVG fonts? |
| 20:39 | <rniwa> | or do other engines support it? |
| 20:39 | <sicking> | rniwa: i don't know no. I would imagine on the svg list |
| 20:40 | <sicking> | rniwa: i know microsoft is pushing back against them too. |
| 20:40 | <sicking> | rniwa: i believe they are not in IE9 or IE10 |
| 20:40 | <smaug____> | Opera supports SVG fonts |
| 20:40 | <smaug____> | some of it |
| 20:40 | <rniwa> | smaug____: ah, ok. |
| 20:40 | <smaug____> | webkit supports also some subset of svg fonts |
| 20:40 | <rniwa> | smaug____: is that "some" same as what webkit implements? |
| 20:40 | <smaug____> | and IIRC Opera and webkit don't support the same subset |
| 20:40 | <rniwa> | smaug____: or their symmetric different non-empty? |
| 20:41 | <rniwa> | difference* |
| 20:41 | <smaug____> | but it is probably quite close |
| 20:41 | <gsnedders> | rniwa: I'm pretty certain that what WebKit implemented isn't the same as what Opera implements |
| 20:41 | <rniwa> | :( |
| 20:41 | <gsnedders> | I believe Opera implements quite a lot more than WebKit. |
| 20:41 | <rniwa> | that's horrible |
| 20:41 | <gsnedders> | It's possibly WebKit is mostly a subset of what Opera supports |
| 20:41 | <gsnedders> | *popssible |
| 20:41 | <rniwa> | gsnedders: so Opera implements a superset of what WebKit implements, I hope? |
| 20:41 | <gsnedders> | *possible |
| 20:42 | <gsnedders> | rniwa: More or less, I believe. There are a few things I think you support that we don't, though. |
| 20:43 | <gsnedders> | My understanding is WebKit supports not that much more than what Acid3 tested. |
| 20:43 | <rniwa> | sicking: found: http://lists.w3.org/Archives/Public/www-svg/2011Oct/0124.html |
| 20:43 | <WeirdAl> | bah, once again I have to remind myself that a good idea for me isn't always a good idea for the Web |
| 20:44 | <smaug____> | sicking: annevk: did you file that XHR bug? |
| 20:45 | <WeirdAl> | annevk: spec question on XHR timeout: is it possible / permitted for the user to write the following |
| 20:46 | <WeirdAl> | var xhr = new XMLHttpRequest(); xhr.timeout = 1200; xhr.open(url, "GET", false) /* signifying sync */; |
| 20:46 | <WeirdAl> | the order of calls on XHR is what I'm concerned about |
| 20:47 | <WeirdAl> | ah, the spec covers that, never mind |
| 20:47 | rniwa | flees from XHR discussion |
| 20:48 | <gsnedders> | Trying to find out on Google how much of SVG Fonts WebKit supports is just showing up loads of cases of bz's article which claims that both WebKit and Opera only support the subset needed to pass Acid3, which isn't really helpful. |
| 20:48 | <smaug____> | WeirdAl: I thought your patch handled that |
| 20:48 | <gsnedders> | (Our implementation goes back to 2005 or so, so predates Acid3, and supports way more than Acid3 requires) |
| 20:49 | <WeirdAl> | no, I think I missed that particular case |
| 20:49 | <WeirdAl> | it handles the reverse, for sure |
| 20:49 | <smaug____> | WeirdAl: my bad |
| 20:49 | <WeirdAl> | mine too :p |
| 20:49 | <smaug____> | WeirdAl: but I did ask for tests for sync xhr |
| 20:49 | <WeirdAl> | right, that's why I started thinking about it |
| 20:50 | <annevk> | WeirdAl: open() throws |
| 20:51 | <sicking> | smaug____: yeah, the problem is that .status is throwing when accessed in readyState === 1 |
| 20:51 | <annevk> | smaug____: I haven't filed it |
| 20:51 | <smaug____> | I just filed |
| 20:51 | <annevk> | during readyState 1 .status should not be available |
| 20:51 | <annevk> | maybe testcase bug? |
| 20:51 | <smaug____> | WeirdAl: hmm, did rest of the sync XHR changes land already |
| 20:51 | <annevk> | but it should not throw either |
| 20:51 | <smaug____> | maybe hsivonen did land them |
| 20:52 | <WeirdAl> | dunno, my tree's out of date anyway |
| 20:55 | <sicking> | annevk: yeah, the test sets up a readystatechange listener which checks that .status is the expected value before calling .send |
| 20:55 | <sicking> | annevk: so the first thing it'll do is to check .status during readystate 1 |
| 20:55 | <sicking> | annevk: don't know why this doesn't make the test fail everywhere |
| 20:56 | <sicking> | annevk: shouldn't assert_equals make the test fail if the two values are different? |
| 20:57 | <sicking> | annevk: i.e. looks to me that tests 3,4 should fail everywhere |
| 20:58 | <sicking> | annevk: fix bugs! |
| 20:58 | <sicking> | :) |
| 21:02 | <smaug____> | sicking: so never-throwing passes 1, 2, 5 |
| 21:02 | <smaug____> | 3 and 4 expect 400, but we'd give 0 |
| 21:02 | <sicking> | smaug____: as we should |
| 21:02 | <sicking> | smaug____: the test is just wrong |
| 21:02 | <smaug____> | k |
| 21:03 | <smaug____> | who wrote those tests? |
| 21:03 | <sicking> | smaug____: at least the first time it gets .status |
| 21:03 | <sicking> | smaug____: possibly all other times when it gets .status should we return 400 |
| 21:04 | <sicking> | smaug____: ask annevk |
| 21:04 | <smaug____> | er, what? |
| 21:04 | <smaug____> | first time 0 then 400 o_O |
| 21:11 | <sicking> | smaug____: we should return 0 when .readystate is 1 |
| 21:11 | <sicking> | smaug____: and 400 once readystate is 2 and we've received the http head |
| 21:11 | <sicking> | smaug____: it gets .status from the readystatechange handler |
| 21:17 | <Ms2ger> | WeirdAl, ack |
| 21:17 | <WeirdAl> | Ms2ger: never mind... I had an idea for an ElementWalker, but then I realized: who needs that besides me? On the Web? Nobody. |
| 21:18 | <Ms2ger> | I won't argue with that :) |
| 21:21 | <zewt> | annevk: just out of curiosity, in async XHR2, is there any point to setting the synchronous flag in send() step 9, since 8.5 makes all of step 9 async already? |
| 21:22 | <Velmont> | annevk: lol, I see you're an effective test user :P |
| 21:50 | <Ms2ger> | \o/ Event constructors! |
| 21:52 | <smaug____> | Ms2ger: some. We need spec changes to add support for more event ctors |
| 21:52 | <Ms2ger> | smaug____, you saw the D4E proposal? |
| 21:52 | <smaug____> | yeah |
| 21:52 | <smaug____> | it has some |
| 21:52 | <smaug____> | UIEvent |
| 21:52 | <smaug____> | and MouseEvent |
| 21:52 | <smaug____> | ah, I could add still compositionevent |
| 21:53 | <smaug____> | oh, also progress event |
| 21:54 | <smaug____> | Ms2ger: if you find any specs for event init dictionaries which Gecko doesn't support, please file bugs |
| 21:54 | <Ms2ger> | Will do |
| 21:54 | <Ms2ger> | Touch events? |
| 21:54 | <zewt> | (havn't checked, but I'd guess WebGLContextEventInit, FWIW) |
| 21:55 | <smaug____> | I don't know what will happen to touch events :( |
| 21:55 | <smaug____> | Apple isn't playing nicely |
| 21:55 | <Ms2ger> | As usual |
| 21:58 | <zewt> | how do mails like this get sent by @google users in 2011? http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-December/034185.html |
| 21:58 | <zewt> | it is |
| 21:58 | <zewt> | somewhat |
| 21:58 | <zewt> | hard to read |
| 21:59 | <timeless> | oh |
| 21:59 | <timeless> | that's easy |
| 21:59 | <timeless> | you have two different apps "helping" you do word wrapping |
| 22:00 | <timeless> | one of them is gmail, the other is whatever you composed your letter in |
| 22:00 | <timeless> | it bites me often enough |
| 22:03 | <timeless> | anyone know how to get gmail /mu/ to flush its pending tasks? |
| 22:16 | <heycam> | rniwa, also not sure you're aware but there's an effort underway to allow SVG glyphs inside OpenType fonts |
| 22:16 | <heycam> | rniwa, so that's not the SVG Fonts format per se; it's using all the normal OT tables to do glyph substitution etc., but just using SVG content inside a table for the glyph |
| 22:27 | jwalden | thinks of XML, and two problems |
| 22:27 | <Ms2ger> | Now you've got a dozen |
| 22:36 | <rniwa> | heycam: interesting |
| 22:37 | <heycam> | rniwa, http://lists.w3.org/Archives/Public/public-svgopentype/ if you're interested |
| 22:40 | <rniwa> | heycam: we probably need to limit the SVG features we can use there? |
| 22:41 | <heycam> | rniwa, yes. definitely no external resources, at least. :) |
| 22:41 | <heycam> | rniwa, also script. but animation should be allowed. |
| 22:41 | <shepazu> | yes, probably only shapes would be reasonable |
| 22:41 | <heycam> | shepazu, just rectangles |
| 22:41 | <shepazu> | heycam: SVGPoint |
| 22:42 | <shepazu> | (yes, the object, not the element) |
| 22:42 | <shepazu> | ONLY CATMULL-ROM CURVES!! |
| 22:48 | <rniwa> | heycam: also.. it probably doesn't make sense for it have text inside |
| 22:48 | <rniwa> | heycam: i don't want my glyph to contain letters of some other font |
| 22:49 | <zewt> | infinite font recursion D: |
| 22:49 | <heycam> | rniwa, certainly doesn't make sense to have the same font being used inside. but text in general? |
| 22:49 | <heycam> | rniwa, what do we gain from disallowing it |
| 22:49 | <rniwa> | heycam: how do you detect recursions then? |
| 22:49 | <heycam> | rniwa, you'd have to do some work for that, sure |
| 22:49 | <rniwa> | heycam: e.g. if you have font1 -> font2 -> font1 |
| 22:49 | <heycam> | (yeah for mutually recursive fonts) |
| 22:49 | <zewt> | any number of ways (check the stack explicitly; limit the stack depth; etc) |
| 22:50 | <Ms2ger> | So, given the document "<img id=foo><img id=foo>" |
| 22:50 | <Ms2ger> | What does document.body.children.item("foo") return? |
| 22:50 | <rniwa> | Ms2ger: it could be the first element, no? |
| 22:50 | <rniwa> | s/could/should/ |
| 22:50 | <Ms2ger> | Why? :) |
| 22:52 | <Ms2ger> | And how about if the document is "<img><img id=foo><img id=foo>"? |
| 22:53 | <rniwa> | Ms2ger: oh wait... neither DOM3 nor DOM4 appear to specify the behavior for looking up children via id. |
| 22:54 | <Ms2ger> | Hint: item takes an unsigned long |
| 22:54 | <rniwa> | oh wait it does: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#htmlcollection |
| 22:54 | <rniwa> | Ms2ger: "Returns the first item with ID or name name from the collection." |
| 22:54 | <Ms2ger> | That's namedItem |
| 22:55 | <rniwa> | oh.. |
| 22:55 | <rniwa> | Ms2ger: good point. |
| 22:55 | <rniwa> | should probably throw in that case? |
| 22:55 | <Ms2ger> | Another hint: ToUint32("foo") is 0 |
| 22:55 | <rniwa> | Ms2ger: huh. we'll get the first element anyway huh? |
| 22:55 | <rniwa> | Ms2ger: that might be confusing. |
| 22:56 | <Ms2ger> | That's what should happen, indeed |
| 22:56 | <Ms2ger> | Now test in Chrome :) |
| 22:56 | <rniwa> | Ms2ger: it's broken? |
| 22:56 | <Ms2ger> | It returns a nodelist with the two last imgs |
| 22:56 | <rniwa> | Ms2ger: I happen to be refactoring the code implementing all of that |
| 22:56 | <rniwa> | Ms2ger: so I'm more than happy to fix that |
| 22:56 | <Ms2ger> | \o/ |
| 22:56 | <rniwa> | Ms2ger: huh odd |
| 22:57 | <Ms2ger> | Code is here, fwiw: http://www.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/bindings/js/JSHTMLCollectionCustom.cpp&exact_package=chromium&q=HTMLCollection&l=74 |
| 22:57 | <rniwa> | Ms2ger: could you file a bug on bugs.webkit.org? |
| 22:57 | <Ms2ger> | Sure |
| 22:58 | <Ms2ger> | HTML DOM? |
| 22:58 | <rniwa> | Ms2ger: yup |
| 22:58 | <rniwa> | Ms2ger: cc me (rniwaβwo) |
| 22:58 | <Ms2ger> | Will do, thanks |
| 22:59 | <rniwa> | Ms2ger: to begin with, I don't think item() should be returning a list of item |
| 22:59 | <rniwa> | of nodes* |
| 22:59 | <rniwa> | Ms2ger: it should be returning a node |
| 22:59 | <rniwa> | wtf... |
| 23:01 | <zewt> | // FIXME: HTML5 specifies that non-HTMLOptionsCollection collections should return |
| 23:01 | <zewt> | // the first matching item instead of a NodeList. |
| 23:01 | <zewt> | seems strange to release code with that big of a FIXME |
| 23:01 | <Ms2ger> | HTML5 probably didn't exist when the code was written |
| 23:02 | <rniwa> | zewt: it's funny how we do it correctly for html option element |
| 23:03 | <rniwa> | zewt: which is probably like 0.01% of usage of that API |
| 23:03 | <annevk> | zewt: different synchronous flags |
| 23:03 | <annevk> | zewt: one is tied to XMLHttpRequest, one is tied to fetch |
| 23:03 | <zewt> | but the fetch is happening within an algorithm that itself is already async |
| 23:04 | <annevk> | zewt: only if the asynchronous flag is unset |
| 23:04 | <annevk> | euh synchronous flag |
| 23:04 | <annevk> | 8.5 does not happen if the synchronous flag is set |
| 23:05 | <zewt> | i mean, if the synchronous flag is unset, then you go async, then run fetch and tell it to go async when it's already async |
| 23:05 | <zewt> | (i don't think this breaks anything, which is why it was just a curiosity, just seems redundant) |
| 23:06 | <annevk> | it matters for the case where the synchronous flag is set I think |
| 23:06 | <zewt> | but step 9 could just always set the fetch synchronous flag |
| 23:06 | <annevk> | no |
| 23:07 | <zewt> | for async xhr, step 9 itself is already async (due to 8.5), and the fetch is part of that |
| 23:07 | <annevk> | and the fetch needs to happen async |
| 23:07 | <annevk> | because other things happen during the fetch |
| 23:07 | <annevk> | in the async case |
| 23:07 | <zewt> | but it is, since the calling algorithm is already async |
| 23:07 | <annevk> | right |
| 23:07 | <annevk> | and in the sync case, the fetch needs to be sync |
| 23:07 | <annevk> | because nothing should happen during the fetch |
| 23:08 | <zewt> | which it also is (since 8.5 doesn't happen) |
| 23:08 | <annevk> | send() returning has no effect on how the message loop works per se |
| 23:09 | <zewt> | well |
| 23:09 | <zewt> | i read step 8.5 as "return the send() call, and continue running this algorithm asynchronously" (since there's no other way you can keep running the algorithm) |
| 23:10 | <zewt> | (it doesn't actually say "asynchronously", but if that's not what's intended I'm not sure what it means) |
| 23:11 | <zewt> | eg. step 8.5 causes step 9 itself to happen asynchronously, so anything it does (eg. the fetch) is asynchronous, so the fetch algorithm doesn't need to do that again |
| 23:14 | <annevk> | so you say the fetch algorithm should not have a synchronous flag because it is implied? |
| 23:14 | <zewt> | no (because other things use it--I assume) |
| 23:14 | <annevk> | e.g. you think the way http://www.whatwg.org/specs/web-apps/current-work/#dom-xmldocument-load is defined is wrong? |
| 23:14 | <zewt> | i just mean that XHR can always set the synchronous flag |
| 23:14 | <zewt> | because it's redundant with 8.5 which already makes the fetch async |
| 23:15 | <annevk> | if you set the synchronous flag fetch will not update you intermediately |
| 23:15 | <annevk> | so switching states and such breaks |
| 23:15 | <zewt> | ah k |
| 23:16 | <annevk> | there's probably a better way to define this and we'll figure it out in a decade or so |
| 23:16 | <zewt> | heh |
| 23:16 | <annevk> | this is the first iteration of defining fetching and it's not always awesome |
| 23:17 | <annevk> | defining HTML properly took twenty years or so |
| 23:17 | <annevk> | encodings: ongoing |
| 23:17 | <zewt> | seems like it's also pretty hard to find the boundary of where it's worth banging your head trying to clean up and tighten a spec, and where it really is "good enough" |
| 23:17 | <annevk> | URLs: ew |
| 23:17 | <annevk> | zewt: I think the boundary is "good enough for now" |
| 23:17 | <Ms2ger> | DOM: ew |
| 23:17 | <zewt> | which I guess comes down to how much you trust implementors |
| 23:17 | <annevk> | where "for now" means the next five years |
| 23:18 | <Ms2ger> | Not at all |
| 23:18 | <zewt> | if you don't trust them *at all* then you try to turn specs into legal documents and everyone wants to kill themselves |
| 23:18 | <annevk> | and then we'll find a better way and maybe five-ten years later someone will write it up that way |
| 23:18 | <annevk> | Ms2ger: hey, DOM is becoming pretty decent |
| 23:18 | <annevk> | good idea about nn |
| 23:18 | <zewt> | you missed |
| 23:19 | <annevk> | I do appreciate you taking a close look |
| 23:19 | <annevk> | you are one of the rare few that do :) |
| 23:19 | <zewt> | don't want to waste your time on stuff that works, i do want to figure out why things are the way they are though :) |
| 23:19 | <annevk> | and imo it's definitely worth it |
| 23:21 | <annevk> | oh hey, for those who care, I wrote something somewhat "lenghty" (compared to my usual posts) in Dutch: http://fronteers.nl/blog/2011/12/het-platform-bouwen |
| 23:22 | <annevk> | it's rambling on building the platform |
| 23:24 | <zewt> | gaah |
| 23:25 | <zewt> | i just typed "document.body.children" into the chrome console ... in a tools window attached to the single-page html spec |
| 23:25 | <zewt> | quite possibly the worst idea imaginable |
| 23:25 | <annevk> | we spec editors love not using anything but <hx> and <p> inside <body> :) |
| 23:25 | <zewt> | well, the problem being that the console froze :P |
| 23:26 | <gsnedders> | zewt: Surprising. :P |
| 23:26 | <gsnedders> | zewt: File a perf bug. :P |
| 23:26 | <zewt> | yeah i'll get riiiight on that |
| 23:27 | <annevk> | HTML has perf bugs. Film at 11. |
| 23:27 | <annevk> | if reddit was not mainstream I'm sure it would be a meme :p |
| 23:30 | <zewt> | fwiw, IE9 agrees with Chrome about document.body.children[string] returning a collection rather than the first item |
| 23:30 | <zewt> | re earlier conversation |
| 23:33 | <Hixie> | anyone know if anyone implements dropzone="" yet? |
| 23:33 | <zewt> | (looks like Opera returns a collection, too) |
| 23:35 | <zewt> | rniwa: ^ |
| 23:35 | <rniwa> | zewt: pong |
| 23:36 | <MikeSmith> | yall dutch MCs got a nice language to work with |
| 23:36 | <rniwa> | zewt: wait, so children returns a collection? |
| 23:36 | <rniwa> | on IE9? |
| 23:36 | MikeSmith | reading http://fronteers.nl/blog/2011/12/het-platform-bouwen |
| 23:39 | <MikeSmith> | rniwa: hey, you have a test suite of any kind started for undomanager? |
| 23:39 | <rniwa> | MikeSmith: not yet |
| 23:39 | <MikeSmith> | ok |
| 23:39 | <MikeSmith> | would be a bit premature, I guess |
| 23:40 | <rniwa> | MikeSmith: my plan is to start implementing it in webkit and write test suites as I do |
| 23:40 | <MikeSmith> | cool |
| 23:40 | <rniwa> | s/test suite/tests/ |
| 23:40 | <zewt> | rniwa: one sec, making a quick test page |
| 23:40 | <rniwa> | MikeSmith: it's hard to write good tests without any implementation |
| 23:40 | <MikeSmith> | I'm in the process now of looking at specs in development and figuring out which are priorities for testing |
| 23:40 | <MikeSmith> | rniwa: yeah, sure |
| 23:41 | <smaug____> | priorities for testing? all of them? |
| 23:41 | <zewt> | http://zewt.org/~glenn/test-htmlcollection.html |
| 23:41 | <zewt> | rniwa: IE returns an HTMLCollection containing both items for both children["x"] and children.item("x") |
| 23:42 | <MikeSmith> | smaug____: well, more in terms of "what are we lacking any test suites at all for right now but that we could have tests for if somebody were to write test cases" |
| 23:42 | <rniwa> | zewt: that seems wrong |
| 23:42 | <zewt> | chrome returns an array containing the same (but it's not an HTMLCollection) |
| 23:42 | <rniwa> | zewt: :( |
| 23:42 | <zewt> | (but they're both similar--they're both arrays of results) |
| 23:42 | <zewt> | only Firefox actually returns a single result for both of those |
| 23:42 | <rniwa> | zewt: that sucks |
| 23:42 | <zewt> | basically, IE (and almost Chrome) treats those functions as filters instead of getters |
| 23:42 | <rniwa> | zewt: maybe there are some web contents that depend on this behavior then |
| 23:43 | <zewt> | in IE9 you can say document.body.children["x"]["x"]["x"]["x"]["x"] since each returns another HTMLCollection |
| 23:43 | <rniwa> | zewt: that's funny |
| 23:44 | zewt | hunts around opera trying to find the console, which seems to be quite well-hidden now |
| 23:44 | <zewt> | gaaaaah, opera is yet different, heh |
| 23:44 | <zewt> | let me dump the results into a static page |
| 23:46 | <zewt> | gah, copying text from ff8's console and pasting into notepad is doing something evil |
| 23:47 | <smaug____> | zewt: what does it do? |
| 23:47 | <smaug____> | on FF9 it seems to work just fine |
| 23:47 | <smaug____> | (linux) |
| 23:47 | <zewt> | not entirely sure, i ended up with some kind of non-printing characters at the end of the line which confused it |
| 23:47 | <zewt> | i jumped to gvim, i'll poke at it in a few |
| 23:49 | <Velmont> | zewt: CTRL+ALT+I for DragonFly, then you can either ESC to get a console, or click it. -- Or Error Console, CTRL ALT O. I think :-) |
| 23:50 | <annevk> | whoa |
| 23:50 | <annevk> | data:text/html,<style>input:hover{background:lime}</style><label>hover this text<input></label> |
| 23:50 | <sicking> | zewt: wait, wht does body.children.x return? |
| 23:50 | <annevk> | in WebKit/Gecko |
| 23:50 | <annevk> | that's pretty wild |
| 23:50 | <sicking> | zewt: all elements with name <x> in the children list? |
| 23:51 | <zewt> | sicking: one sec |
| 23:51 | <zewt> | http://zewt.org/~glenn/test-htmlcollection-results.txt |
| 23:51 | <zewt> | for those three, literally every implementation is significantly different, heh |
| 23:51 | <sicking> | annevk: ugh, gecko has a pretty nasty bug there |
| 23:51 | <sicking> | annevk: hover the label, then the <input> and then the label again |
| 23:52 | <TabAtkins> | annevk: Yeah, exposing dictionaries somehow would be good, so you can trivially feature-test. |
| 23:52 | <annevk> | sicking: oops |
| 23:52 | <sicking> | annevk: nice, webkit has the same bug |
| 23:52 | <annevk> | sicking: prolly because of the magic |
| 23:52 | <sicking> | annevk: harder to trigger, but it's still there |
| 23:53 | <rniwa> | zewt: seems like IE9's behavior is most sane |
| 23:53 | <rniwa> | zewt: of course FF8's behavior matches the spec but is inconsistent with the rest. |
| 23:54 | <rniwa> | zewt: I think we should just change the spec to always return HTMLCollection |
| 23:54 | <rniwa> | zewt: given that IE, WebKit, and Opera all returns array-like objects for [] and namedItem, I don't think it makes sense for us to match the spec. |
| 23:55 | <Hixie> | anyone know if making atob() skip spaces has broken anything? |
| 23:55 | <Hixie> | gsnedders said that opera not throwing exceptions in atob was causing compat issues |
| 23:55 | <Hixie> | but i don't seem to have any up to date info on atob() compat for opera since it was updated to throw exceptions but not for whitespace |
| 23:55 | <zewt> | sicking: added children.x to http://zewt.org/~glenn/test-htmlcollection-results.txt |
| 23:55 | <zewt> | rniwa: agreed (odd-looking api but oh well) |
| 23:56 | <rniwa> | zewt: well but I suppose FF8 also returns HTMLCollection for option element |
| 23:56 | <rniwa> | zewt: so this change makes things more consistent across the board |
| 23:56 | <zewt> | http://zewt.org/~glenn/test-htmlcollection.html in case anyone wants to stupid-check my test |
| 23:57 | <rniwa> | zewt: can we also test IE6/IE7? |
| 23:57 | <zewt> | need to dig out my vms |
| 23:57 | <zewt> | (i dream of distributed browser code testing~~~) |
| 23:57 | <annevk> | nn |
| 23:58 | <zewt> | later |
| 23:58 | <sicking> | zewt: ugh! .children shouldn't be a HTML collection |
| 23:58 | <sicking> | zewt: it might be worth trying FF10. I think we turned a lot of HTMLCollections into NodeLists there |
| 23:59 | <rniwa> | sicking: oh dear... |
| 23:59 | <rniwa> | sicking: we're improving engines too fast LOL |
| 23:59 | <sicking> | rniwa: i disagree, we're not doing it fast enough :) |
.jpg){kind=link}
