00:29 | <AnselmBradford> | hi all, I'm looking at the example for the "dirname" attribute in the specification 4.10.7.2.2 |
00:29 | <AnselmBradford> | and the example has 'dirname="comment.dir"' |
00:30 | <AnselmBradford> | doesn't that mean there should be an input field in the form with the id='comment.dir'? |
00:31 | <AnselmBradford> | as dirname is supposed to specify the form control that contains directionality information for a particular input |
00:31 | <AnselmBradford> | here's the example: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-dirname-attribute |
00:31 | <TabAtkins> | You misunderstand how it works. @dirname tells the form what name to use to submit the directionality of the input. |
00:31 | <TabAtkins> | The directionality of the input is inherent to the input itself; it's not given by another control. |
00:33 | <AnselmBradford> | TabAtkins: Thanks, yeah I'm confused by it... particularly this bit: |
00:33 | <AnselmBradford> | "A form control dirname attribute on a form control element enables the submission of the directionality of the element, and gives the name of the field that contains this value during form submission." |
00:34 | <TabAtkins> | "field" does not mean "form control". It means the key part of the form submission, like "example.com?key=value" |
00:35 | <AnselmBradford> | ahh, right okay |
00:36 | <AnselmBradford> | is this supported by any browsers... I can't seem to get the examples I've found to work? |
00:36 | <TabAtkins> | Don't think anyone does it yet. |
00:37 | <AnselmBradford> | okay, thanks, that makes sense now :) |
00:37 | <TabAtkins> | excellent |
06:54 | <Hixie> | othermaciej: thanks (re mail to public-html) |
07:31 | <annevk> | zcorpan, are you sure parsing is the problem? |
07:31 | <annevk> | zcorpan, and not say, the painting? |
07:31 | <annevk> | zcorpan, and layout |
07:37 | <annevk> | Hixie, which differences were removed? |
07:37 | <Hixie> | some paragraph that was only in the w3c copy was removed after someone filed a bug on it |
07:38 | <Hixie> | (it was a pretty meaningless paragraph) |
07:38 | <Hixie> | (with lots of errors) |
07:44 | <annevk> | doesn't HTML suggest using <pre><code>? |
07:44 | <annevk> | re: replacement <xmp> |
08:44 | <zcorpan> | Hixie: "To represent a block of computer code, the pre element can be used with a code element" http://www.whatwg.org/specs/web-apps/current-work/complete/grouping-content.html#the-pre-element |
10:01 | <annevk> | "Just make every object constructable, it'll work!" |
10:01 | <annevk> | tralalala |
10:05 | <zcorpan> | Hixie: thanks for fixing racyness with video |
10:42 | <annevk> | zcorpan, btw, see the logs |
10:42 | <annevk> | I doubt parsing is that slow |
10:50 | <jgraham> | annevk: If it is on XHR, how would painting or alyout make a difference? |
10:51 | <jgraham> | The original complaint was that getting responseXML was slow |
10:52 | <jgraham> | Which it could be if you XHR in tens of megabytes of document |
10:58 | <annevk> | I thought it was getting and inserting it |
10:59 | <jgraham> | Hmm, possibly I didn't read closely, I'm not sure. You would have thought that someone complaining would do basic profiling of where the slowness actually is |
10:59 | <jgraham> | But, yeah… |
11:00 | <hsivonen> | annevk: why is SVG fonts only on a "maybe" list for Acid3 update? after Mozilla and Microsoft refusing to implement and after seeing that Opera and WebKit aren't aiming for a complete impl |
11:00 | <hsivonen> | (and the typical arguments in favor of SVG fonts assume a complete impl) |
11:00 | <annevk> | I did not put it there |
11:00 | <jgraham> | Today's lesson: living standards need living testsuites |
11:03 | <hsivonen> | so about 15% of Acid3 is suspect |
11:04 | <annevk> | If you go by the number of tests, but the actual problems are within those tests, so it's probably more like 5% |
11:05 | <annevk> | Well, SVG Animation and SVG Fonts are 5% together, so a little more |
11:08 | <annevk> | So the political party I support just launched a magazine fully in Flash. Uh what. |
11:09 | <hsivonen> | annevk: I guess you have to stop voting for them now. |
11:10 | <smaug____> | dropping SVG animation is new to me |
11:12 | <zcorpan> | annevk: what was it about parsing? |
11:12 | <zcorpan> | oh, async api? |
11:12 | <annevk> | zcorpan, yes |
11:13 | <zcorpan> | i thought the use case didn't involve layout at all but just parse a big chunk of xml |
11:13 | <zcorpan> | the bug said that the parsing operation was blocking the main thread and that was a problem |
11:14 | <zcorpan> | but we need to study use cases before designing new apis... |
11:15 | <zcorpan> | maybe we should have a way to parse right into an element in an async way so that it gets rendered incrementally if the use case is to get it on the screen |
11:15 | <annevk> | EV fail / Apple fail: http://www.computerworld.com/s/article/9219669/Mac_OS_X_can_t_properly_revoke_dodgy_digital_certificates |
11:16 | <annevk> | By the way, is there any copy of HTML still alive that has that data provider idea still in it? |
11:16 | <annevk> | I think Philip` experimented a bit with it and then it got removed |
11:16 | <annevk> | So not <datagrid>, but the other one |
11:17 | <zcorpan> | the repetition template replacement? |
11:18 | <annevk> | yeah maybe |
11:20 | <jgraham> | The one that 3 people understood? |
11:22 | <zcorpan> | i think it's not kept alive anywhere |
11:23 | <zcorpan> | if you want it you need to find a rev that has it |
11:24 | <annevk> | damn it |
11:25 | <annevk> | data templates |
11:25 | <annevk> | http://html5.org/r/2319 |
12:04 | <zcorpan> | removing SMIL from SVG seems overly optimistic |
12:05 | <zcorpan> | maybe SMIL in SVG can be simplified but i doubt it can be removed altogether at this point |
12:08 | <zcorpan> | heh http://xkcd.com/949/ |
12:08 | <annevk> | see publix-fx |
12:08 | <annevk> | also Microsoft does not support it |
12:10 | <annevk> | Yet another language from Google: http://gotocon.com/aarhus-2011/presentation/Opening%20Keynote:%20Dart,%20a%20new%20programming%20language%20for%20structured%20web%20programming |
12:13 | <annevk> | More on Dart here: http://markmail.org/message/uro3jtoitlmq6x7t |
12:18 | <wilhelm> | … Computational theologist. |
12:21 | <jgraham> | Is it only me that is reminded of ES4? |
12:21 | <jgraham> | I wonder if Google will succeed where Mozilla failed |
12:25 | <annevk> | I also wonder how they intend this fork to work. |
12:25 | <annevk> | Switching the scripting language on a page might be tricky. |
12:27 | <jgraham> | Allowing javascript and another language to both operate on the same page seems… tricky |
12:27 | <jgraham> | Using a "first langauge wins" policy might be easier |
12:27 | <jgraham> | But it makes it even harder to deploy |
12:28 | <Philip`> | jgraham: I thought the problem with ES4 is that browser vendors couldn't agree on it, which Google seems to be avoiding by being willing to do everything itself |
12:28 | <jgraham> | I thought the problem was the Microsoft vetod it |
12:29 | <jgraham> | I assume that Google won't implement it for IE |
12:29 | <Philip`> | (Then other vendors will be pressured into implementing it so that Gmail isn't much slower in their browser than in Chrome) |
12:29 | <jgraham> | Well that is the interesting thing |
12:29 | <jgraham> | Whether people will have to implement it because of Google properties |
12:31 | <benjoffe> | has twitter made a public statement as to why they're preferring '#!' urls over using the html5 history api? |
12:32 | <benjoffe> | I mean they have full time front-end devs, this must be intentional |
12:32 | <miketaylr> | they blogged once about some bug in safari's implementation |
12:32 | <miketaylr> | http://www.adequatelygood.com/2011/2/Thoughts-on-the-Hashbang |
12:33 | <miketaylr> | hmm maybe wrong link |
12:39 | <zcorpan> | annevk2: should getElementsByTagNameNS use [TreatNullAs=Empty] for the first argument? |
12:40 | <annevk> | namespaceURI returns null never the empty string |
12:40 | <annevk> | so we want to treat the empty string as null |
12:40 | <annevk> | not the other way around... |
12:41 | <annevk> | next time we design this API namespaceURI would return the empty string of course |
12:47 | <zcorpan> | i don't follow. my question is if we want teh following to be equivalent: ...NS(null, 'foo') and ...NS('', 'foo') |
12:47 | <zcorpan> | or ...NS(null, 'foo') and ...NS('null', 'foo') |
12:51 | <annevk> | the former I think with the empty string being treated as null |
12:51 | <annevk> | does seem like that requires changes |
12:53 | <annevk> | see http://www.w3.org/TR/DOM-Level-3-Core/core.html#Namespaces-Considerations :( |
12:54 | <annevk> | "In programming languages where empty strings can be differentiated from null, empty strings, when given as a namespace URI, are converted to null." |
12:54 | <annevk> | So all NS-methods need to be changed to accepting "DOMString?" and the corresponding algorithms need to match |
12:55 | <annevk> | Do you agree? |
12:55 | <annevk> | e.g. this is a problem for createElement etc. too |
12:56 | <annevk> | hmm |
12:57 | <annevk> | i see elsewhere we use [TreatNullAs=Empty] and then in the algorithm change empty to null |
12:57 | <zcorpan> | yeah |
12:57 | <annevk> | TreatEmptyAs=Null would be cool |
12:58 | <annevk> | or DOMStringNS :p |
12:58 | <zcorpan> | whether we use DOMString? or [TreatNullAs=Empty] seems like an editorial issue |
12:58 | <annevk> | I think I will go with DOMString? then |
12:59 | <annevk> | so you don't need double-conversion if your implementation generates stuff based on the IDL |
13:21 | <annevk> | http://www.mnot.net/blog/2011/08/24/distributed_hungarian_notation_doesnt_work |
13:21 | <annevk> | Instead of using Sec- to prevent XMLHttpRequest clients, update the list of headers to block by XMLHttpRequest and have aggressive browser update cycles... |
13:24 | <Philip`> | Doesn't need to be part of the browser upgrade cycle, it could just be a centrally-located list that they download every few days |
13:26 | <annevk> | It seems rather complicated though |
13:27 | <annevk> | But maybe it's worth it, Sec- isn't everything either |
13:28 | <jgraham> | It feels a bit fragile |
13:32 | <heycam> | just dropping in to say I'm on vacation for the next 4 weeks, see you all later |
13:33 | <jgraham> | It's not nice to gloat :p |
13:33 | heycam | smiles, waves |
13:34 | <annevk> | zcorpan, changed the specification |
13:35 | <annevk> | Damn it, now I can't complain about exceptions for a month |
13:35 | <annevk> | Maybe I should go on vacation too :) |
13:35 | <jgraham> | You can *complain* |
14:57 | <donri> | i'm sure this has been asked before so please excuse me :) why does html5 keep the form[@method] restriction and leave out other useful verbs? |
14:58 | <annevk> | because other verbs would need a same-origin restriction |
14:58 | <donri> | is it different from POST? |
14:58 | <annevk> | and because we could not figure out the details of how that would work |
14:59 | <annevk> | to deployed servers everything is different from POST/GET when it comes to requests carrying cookies |
14:59 | <annevk> | or to requests where you identify with IP address or some such |
15:01 | <donri> | not sure i understand. isn't it up to the application that probably also sent the form? |
15:06 | <annevk> | donri, those are same-origin typically |
15:06 | <annevk> | with cross-origin all bets are off |
15:07 | <annevk> | and forms can request cross-origin by default, so changing what they can request is dangerous |
15:08 | <donri> | don't quite see the issue if it's a different method to have different behavior but ok, thanks ): |
15:08 | <donri> | :) * |
16:02 | <AryehGregor> | zcorpan, I'd reply, but you vanished. :( Not sure what the context of your message was: is this review of the spec, or explanation of Opera's behavior, or whaT? |
16:02 | <AryehGregor> | what? |
16:02 | <annevk> | http://www.guardian.co.uk/books/2011/sep/07/michael-moore-hated-man-america is terrible, but "You ever see a Navy Seal get stabbed? The look on their face is the one we have when we discover we're out of shampoo." is pretty funny |
16:20 | <timeless> | hrm, webidl people? |
16:21 | <timeless> | [Callback=FunctionOnly, NoInterfaceObject] interface MyCallback { void looped(); } |
16:22 | <timeless> | interface Silly { [Constructor] Silly([TreatNonCallableAsNull] MyCallback looped); } |
16:22 | <timeless> | afaict, that isn't allowed and probably isn't allowed for a couple of reasons |
16:22 | <timeless> | none of which seem good |
16:23 | <timeless> | grr, no heycam either? |
16:24 | <Philip`> | timeless: "13:35 < heycam> just dropping in to say I'm on vacation for the next 4 weeks, see you all later" |
16:24 | <timeless> | Philip`: thanks |
16:24 | <timeless> | Philip`: do you happen to speak webidl at all? :) |
16:25 | <timeless> | or perhaps jwalden ? |
16:25 | <Philip`> | Only the really easy bits |
16:25 | <jwalden> | timeless: not fluently, I've only really interacted with it to the extent needed to describe how it affects JS bindings |
16:25 | <timeless> | that should be sufficient |
16:26 | <jwalden> | and even there it's been more hands-offish |
16:26 | <timeless> | can i get you to consider: |
16:26 | <timeless> | [Callback=FunctionOnly, NoInterfaceObject] interface MyCallback { void looped(); } |
16:26 | <timeless> | interface Silly { [Constructor] Silly([TreatNonCallableAsNull] MyCallback looped); } |
16:27 | <jwalden> | these verbs may exceed my vocabulary, but go on |
16:27 | <timeless> | so... |
16:27 | <timeless> | use case, i want to have a Silly interface which demands a MyCallback |
16:27 | <timeless> | it doesn't want a null MyCallback, that would be too silly |
16:27 | <timeless> | oh, hrm |
16:28 | <timeless> | i guess i don't need treatnoncallableasnull |
16:28 | <timeless> | because normally it'd just get a type error |
16:28 | timeless | is too used to JS coersion in gecko |
16:28 | <timeless> | ok, ... some handwaving as i change my example :) |
16:30 | <timeless> | assume i was ok w/ people passing garbage, so i had s/MyCallback looped/MyCallback? looped/ |
16:31 | timeless | sighs |
16:31 | timeless | rewrites the example |
16:31 | <timeless> | thanks for listening :) |
16:38 | <dglazkov|away> | good morning, Whatwg! |
18:30 | <jgraham> | OK, this is not hard people |
18:31 | <jgraham> | If, for whatever dumb reason, you decide to use tabs to indent in a file |
18:31 | <jgraham> | and you have one line of code that is split over multiple lines in the file |
18:32 | <jgraham> | and, for aesthetic reasons you want some special alignment on the lines that doesn't correspond to a whole number of tabstops at the start of each line |
18:32 | <jgraham> | You have to use *tabs then spaces* to get the right alignment |
18:32 | <jgraham> | *not just spaces at whatever retarded tab width you happen to be using* |
18:33 | <jgraham> | Alternatively *avoid the whole problem* and *don't use tabs* |
18:33 | <jgraham> | Thank you |
19:02 | <Hixie> | wait, <xmp> is display:block? damnit i always forget that. |
19:18 | <zewt> | jgraham: welcome to pointless waste-of-time holy war |
19:19 | <zewt> | make sure your tabs are on the standard multiple-of-8-spaces so it works everywhere and move on with life |
19:39 | <Hixie> | anyone know about 'caller' being removed? do i just have to remove 'caller' from all my IDLs and then add this for document.all?: |
19:39 | <Hixie> | <p>In addition to the above, <code>HTMLAllCollection</code> objects, |
19:39 | <Hixie> | in JavaScript, must be callable. Calling such an object must |
19:39 | <Hixie> | implicitly invoke the index getter with the same arguments.</p> |
20:20 | <TabAtkins> | jgraham: Alternately, use tabs like a sane person, and let your code editor intelligently do a visual wrap for you. |
20:20 | <TabAtkins> | jgraham: But otherwise, yes, a thousand times yes, tab to the same indent, then use spaces. |
20:30 | <Hixie> | TabAtkins: would you be interested in giving a talk at https://sites.google.com/site/doceng2011/symposium/workshops ? it's at google |
20:30 | <Hixie> | or anyone else for that matter |
20:33 | <TabAtkins> | Hixie: Looking at th eother talks, I don't think I can contribute anything topical. |
20:45 | <Hixie> | they're just looking for someone who can give an "inspirational talk" on html5 |
20:48 | <Hixie> | what's the right list to e-mail to get input on browser vendors' future plans regarding svg? |
20:48 | <Hixie> | www-svg? |
20:48 | <Hixie> | public-svg? |
20:50 | <shepazu> | www-svg, I'd think |
20:52 | <Hixie> | k |
22:27 | <AryehGregor> | Ouch, I didn't even think of this: http://www.daemonology.net/blog/2011-09-01-Iran-forged-the-wrong-SSL-certificate.html |
22:30 | <AryehGregor> | (Chrome isn't vulnerable, of course, due to cert pinning) |
22:45 | <zewt> | personally, i'm not thrilled about the idea of giving google the ability to run scripts on all of those sites in the first place |
22:45 | <AryehGregor> | There's not much alternative if you want the functionality. |
22:50 | <zewt> | there could be; maybe if there was a way of creating cross-origin workers |
22:57 | <AryehGregor> | How would that help? |
22:57 | <AryehGregor> | What might make sense is putting it in an iframe instead of a <script>. |
22:58 | <AryehGregor> | I assume there's some reason they don't do that, though. |
22:58 | <AryehGregor> | Realistically, it's a convenience-security tradeoff that leans toward convenience for almost all sites. |
23:00 | <zewt> | well, a sandboxed API (messaging) |
23:00 | <zewt> | there's also a performance tradeoff, though, which I'm sure is critical for GA |
23:21 | <Hixie> | jgraham: 504 again |
23:38 | <Hixie> | does hallvord ever hang out on irc? |
23:39 | <zewt> | MICROSOFT PROPOSAL: Close the bug - This bug is from an anonymous contributor ... |
23:39 | <zewt> | heh |
23:40 | <Hixie> | annevk: you around? |
23:40 | <Hixie> | what is it i have to do to make events constructible again? |