| 00:01 | <boogyman> | Hixie: I've yet to come across a valid use-case for a block level element inside of an anchor. I've been given a multitude of suggestions, but I disagree with all of them... eg I'd like to make an entire table row clickable <---- lolwut??? |
| 00:02 | <boogyman> | makes me think of clientsfromhell.com every time someone says something as idiotic as that |
| 00:02 | <bga_> | ok http://www.w3.org/Bugs/Public/show_bug.cgi?id=12639 |
| 00:20 | <erlehmann> | boogyman, “don't allow block level elements inside anchors” seems like a bad case of “stop liking what i don't like” |
| 00:21 | <boogyman> | erlehmann: That is very much the case, however, I am open to the thought of a use-case that makes sense |
| 00:24 | <erlehmann> | boogyman, browsers already handle links wrapped around block level elements. html5 is descriptive. deal. with. it. |
| 00:24 | erlehmann | puts on glasses. |
| 00:25 | <boogyman> | erlehmann: previously it wouldn't validate |
| 00:25 | <erlehmann> | boogyman, imagine a magazine style page with teasers … |
| 00:26 | <Hixie> | boogyman: look at whatwg.org. it has an example of block-like elements in links that i think is reasonable. |
| 00:28 | <boogyman> | Hixie: are you speaking about the <section> bit? If so, I disagree with that as well. The title can be the link, what semantic value comes from making the entire section an anchor? |
| 00:31 | <boogyman> | erlehmann: I'm not following? if there are multiple teasers, use an anchor tag per teaser, with the "teaser" being an image and/or text <a href=""><img src="" alt="contextual image"> Some description</a>, then use CSS to properly determine layout |
| 00:31 | <erlehmann> | boogyman, but my hypothetical teasers are <divs>, with complex inner workings! |
| 00:32 | <boogyman> | erlehmann: sounds like you have a non-semantic layout then |
| 00:33 | <boogyman> | the standards shouldn't be lenient or empathetic to un-semantic markup |
| 00:33 | <erlehmann> | boogyman, well, should they be considered <articles>, then? |
| 00:34 | <erlehmann> | the standards shouldn't be lenient! yellow screen of death and destruction for all! |
| 00:37 | <boogyman> | erlehmann: possibly an aside/section as exampled on whatwg.org, but again, I don't believe any semantic meaning value is gained by allowing the full "module" be a link |
| 00:38 | <erlehmann> | boogyman, „the teaser links to the full-blown article“ is somewhat more in line with reality than „the teaser contains multiple links to the full-blown article“ |
| 00:38 | <Hixie> | boogyman: i mean the boxes, "HTML", "News", etc. look at the source. |
| 00:38 | <Hixie> | boogyman: the whole box each time is a link |
| 00:38 | <erlehmann> | i'd argue it is “more semantic” based upon that |
| 00:38 | <Hixie> | boogyman: it makes no sense to put the link _in_ the box |
| 00:39 | <erlehmann> | what the man said |
| 00:40 | <erlehmann> | also sorry for my quotes |
| 00:43 | <boogyman> | Hixie: I'm not seeing those examples in the source |
| 00:43 | <boogyman> | erlehmann: <a href="">This is some complex <span>advert</span></a> a span {...} |
| 00:44 | <boogyman> | I just don't see the semantic value :-s |
| 00:45 | <erlehmann> | boogyman, then don't. others do and use it already. we like what you don't like. :) |
| 00:46 | <boogyman> | erlehmann: It's not a matter of emotional opinion; It's a matter of semantics |
| 00:48 | <Hixie> | boogyman: the second element child of the <body> on http://whatwg.org/ |
| 00:48 | <erlehmann> | boogyman, describe a scenario where you opine that wrapping a block in a link lacks semantic value opposed to a inline alternative |
| 00:50 | <Hixie> | boogyman: (there's not much else to that document, i'm not sure how you're missing it!) |
| 01:58 | <boogyman> | erlehmann: the page that Hixie is referring to is another example... http://jsfiddle.net/NXZLc/ is how I would write it up semantically |
| 01:58 | <Hixie> | there's no list there |
| 01:59 | <Hixie> | why do you have a list? |
| 01:59 | <boogyman> | because your markup is more aptly described as a list of options/links |
| 01:59 | <Hixie> | ew no, that's not at all a list |
| 01:59 | <Hixie> | it's just a bunch of links |
| 02:00 | <boogyman> | most*, could possibly even encapsulate it all within a "nav" too |
| 02:00 | <Hixie> | how would you handle it if the boxes had two paragraphs in them instead of the current one-paragraph solution? |
| 02:01 | <boogyman> | can you describe a scenario where multiple paragraphs are semantically appropriate for a single anchor? |
| 02:07 | <boogyman> | erlehmann: http://whatwg.com vs http://jsfiddle.net/NXZLc/ |
| 02:07 | <Hixie> | well the example on whatwg.org frankly i think the current markup (just one <p>) is a bit dubious. I was thinking of changing it to something and a <p>, just not sure what the first one should be |
| 02:07 | <Hixie> | matbe a <p><strong> |
| 02:07 | <Hixie> | maybe |
| 02:08 | <erlehmann> | boogyman, PS1="\w > rm \w" |
| 02:08 | <boogyman> | eh? |
| 02:08 | <erlehmann> | :D |
| 02:08 | erlehmann | puts on his troll hat. |
| 02:09 | <erlehmann> | boogyman, you realize this *will* degrade less gracefully then just using block elements? |
| 02:10 | <erlehmann> | li a span {display:block} … and nothing of value was gained |
| 02:11 | <boogyman> | erlehmann: it's cosmetic, therefore, by definition its to be done via css |
| 02:12 | <erlehmann> | boogyman, tell that to the guy with spec edit rights, not me. %) |
| 02:12 | <Hixie> | it's not cosmetic |
| 02:12 | <Hixie> | the whole thing is a link, and the whole thing is a paragraph |
| 02:12 | <Hixie> | arguably two paragraphs |
| 02:13 | <erlehmann> | “the whole thing is a link”, there is the point. boogyman, do you think that the whole thing is not a link? |
| 02:13 | <boogyman> | I'd think of it more of a dl, or section with a heading and description |
| 02:14 | <Hixie> | it's clearly not a bunch of name-value pairs :-P |
| 02:14 | <Hixie> | you seem to have drunk some semantic koolade :-P |
| 02:15 | <boogyman> | koolade is for the birds, but erm, i think it's a very loose fit. But anyway, this is the first example I've seen that could potentially be semantically appropriate. I just disagree with the principle |
| 02:17 | <boogyman> | but, it's still a list of links |
| 02:17 | <Hixie> | it's not more a list of links than a book is a list of paragraphs |
| 02:21 | <boogyman> | correct, but a paragraph has semantic meaning in both a single and group setting. This is a group of links that navigate the user to specific pieces of the website |
| 02:23 | <erlehmann> | boogyman, a web site is a list of links. |
| 02:23 | <erlehmann> | :3 |
| 02:23 | <erlehmann> | (thanks, I'll be here all week) |
| 02:23 | <boogyman> | badum, chee |
| 02:26 | <boogyman> | Hixie: please tell me you're not considering <a href=""><p><strong>Category</strong></p><p>foo description</p></a> |
| 02:29 | <erlehmann> | s/strong/h1/ge |
| 03:10 | <MikeSmith> | very cool to see that doublec is working on a media fragments implementation |
| 03:10 | <MikeSmith> | hopefully the questions and feedback will drive some changes to the spec |
| 03:14 | <doublec> | thanks MikeSmith! |
| 03:16 | <MikeSmith> | doublec; was also reading foolip comments in the bug, and your reply |
| 03:17 | <MikeSmith> | whatever subset you end up supporting, hopefully other implementors can implement that subset also |
| 03:17 | <doublec> | yes, I'm hoping we can agree. foolip and I seem to be in agreement from what I can tell. |
| 03:18 | <doublec> | At the Foundations of Open Media workshop in 2010 we (firefox media devs) gave similar feedback to those working on the fragment spec |
| 03:29 | <MikeSmith> | doublec: I guess the feedback sometimes doesn't get treated seriously enough until the implementation work starts in earnest |
| 03:30 | <MikeSmith> | hey jamesr - I think you mentioned something about needing mercurial help here a while back |
| 03:30 | <MikeSmith> | I just wanted to say if it was in the context of using the W3C mercurial repo, I am always glad to help with that |
| 03:44 | <jamesr> | MikeSmith: hi! i had some trouble using the wrong acct name, but sorted that |
| 03:44 | <jamesr> | MikeSmith: i don't understand how properly to handle merges |
| 03:44 | <jamesr> | but i have to run and eat dinner now. i might ask you about best practices for multiple editors/merges when using the w3c mercurial repo at some point in the future if you're willing to explain things |
| 03:45 | <jamesr> | i think i grok the git model, but i'm not sure if that is helpful or harmful to understanding the hg model |
| 03:45 | <MikeSmith> | ok |
| 03:45 | <MikeSmith> | feel free to ping me any time |
| 03:45 | <MikeSmith> | I'm always on this channel when I'm online |
| 04:01 | <eboyjr> | Hello, just curious as to why the TextMetrics object only contains a `width` property |
| 04:02 | <eboyjr> | why it's been decided that way |
| 04:30 | <Hixie> | eboyjr: we'll add more in due course |
| 04:33 | <eboyjr> | Hixie: okay, cool. what's due course? |
| 04:33 | <Hixie> | once the browsers have caught up with what the spec already says |
| 04:33 | <Hixie> | no point adding features when they still haven't implemented the last bunch :-) |
| 04:35 | <eboyjr> | hrm i'da figured it would be good to come up with a full set of features and let browsers implement it at its own will and discretion |
| 04:38 | <eboyjr> | bounding-box metrics would be more valuable, imo |
| 05:43 | <MikeSmith> | hmm, the dfn for term "space character" is marked up with class=impl |
| 05:43 | <MikeSmith> | so it only appears in the full version of the spec |
| 05:43 | <MikeSmith> | but not in the non-implementor view |
| 05:44 | <MikeSmith> | so non-implementors don't get to know what the space characters actually are |
| 08:04 | Retrieving | #whatwg modes... |
| 09:07 | <MikeSmith> | zcorpan: about the links in the developer versin |
| 09:07 | <MikeSmith> | *version |
| 09:07 | <MikeSmith> | I think there are some references that it's acceptable to have be links back to the full spec |
| 09:08 | <MikeSmith> | in the case of the W3C Web Author Edition, the build process I set up to create that takes any broken links it finds, and rewrites them to point to the full spec |
| 09:09 | <zcorpan> | MikeSmith: oh they're not just broken links? |
| 09:09 | <zcorpan> | aha |
| 09:09 | <MikeSmith> | yeah, would be broken if it weren't for the rewriting |
| 09:09 | <MikeSmith> | Ben uses a different build setup than the one I do |
| 09:10 | <MikeSmith> | so I'm not sure if he is doing the fixup thing or not |
| 09:11 | <MikeSmith> | anyway, for example, there are a lot of links in the IDLs that reference stuff which is only in the impl view |
| 09:11 | <zcorpan> | well then there are other ways to find which links are "broken" |
| 09:11 | <MikeSmith> | true |
| 09:11 | <zcorpan> | maybe a user style sheet and casual browsing is effective |
| 09:11 | <MikeSmith> | but my point is, a lot of them are human-judgement cases, I think |
| 09:11 | <MikeSmith> | yeah |
| 09:11 | <MikeSmith> | could help |
| 09:12 | <MikeSmith> | as far as finding the ones that need fixing |
| 09:12 | <zcorpan> | yes |
| 09:12 | <MikeSmith> | the way the stylesheet is for the author view now, those links to the full spec do show up differently on hover |
| 09:12 | <MikeSmith> | but not normally |
| 09:13 | <MikeSmith> | but of course it'd be possible to have them show up even not on hover |
| 09:13 | <MikeSmith> | I think for my build at least they may all have class=full_spec or something on them |
| 09:14 | <MikeSmith> | so wouldn't even have to use any fancy selector stuff to select them |
| 09:35 | <zcorpan> | it's impossible to draw eillipses with canvas? surely it isn't? |
| 09:39 | <Hixie> | describe it using beziers, or stretch an arc with a transform |
| 10:09 | <foolip> | Philip`, still waiting for http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#getting-media-metadata to become http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#getting-media-metadata ;) |
| 10:11 | <MikeSmith> | zcorpan: about the u change |
| 10:11 | <MikeSmith> | in the Changed Elements section |
| 10:11 | <MikeSmith> | minor formatting nit |
| 10:11 | <MikeSmith> | you put no <code> around the "u" |
| 10:12 | <MikeSmith> | so it's not rendered the same as the other element names in that section |
| 10:15 | <zcorpan> | oops |
| 10:16 | <zcorpan> | fixed |
| 10:16 | MikeSmith | checks |
| 10:16 | <MikeSmith> | cool |
| 10:16 | <MikeSmith> | thanks |
| 10:17 | <MikeSmith> | what we really need is a specific element for marking up Chinese proper names |
| 10:17 | <MikeSmith> | just as with the proposed element for markup up ship names |
| 14:49 | <alystair> | ugh - you'd think browsers would be able to implement alpha transparency based word-wrapping :) |
| 14:51 | <Lachy> | what? |
| 14:52 | <alystair> | well, we have nice block wrapping of text, but nothing more advanced, eg. having an image of a black circle with transparent background |
| 14:52 | <alystair> | then have browser detect parts that are 'empty' and allow text flow around it |
| 14:53 | <Lachy> | oh, right. I think there might be some CSS proposals for that somewhere, and I'm pretty sure it can be done in SVG by specifying the path. I'm not sure of the details though. |
| 14:54 | <alystair> | looks like I get to write a fun article if it's possible via svg |
| 14:54 | <Lachy> | alystair, is this what you're looking for? http://dev.w3.org/csswg/css3-exclusions/ |
| 14:55 | <Philip`> | People will presumably complain about security implications, so it'd have to be restricted to word-wrapping around same-origin images |
| 14:55 | <alystair> | neat! |
| 14:56 | <alystair> | security implications? |
| 14:56 | <Lachy> | alystair, being able to detect the content of the image at all is a security risk for non-same-origin images |
| 14:57 | <hsivonen> | alystair: using the feature to probe the alpha channel of a confidential image |
| 14:57 | <alystair> | .... |
| 14:57 | <alystair> | the program would be doing that, not a human being |
| 14:57 | <Lachy> | but that CSS proposal works by specifying an explicit path, rather than any image heuristics or edge detection |
| 14:57 | <alystair> | oh. |
| 14:58 | <hsivonen> | with clever SVG filters applied, it might be possible to move each of R, G and B to alpha channel, too |
| 14:58 | <alystair> | so what you're saying is that by using automatic edge detection one could externally somehow identify it's content by the edges? :P |
| 14:58 | <hsivonen> | alystair: yeah |
| 14:58 | <Lachy> | depending on what the image is, yes |
| 15:00 | <alystair> | it's a fun concept to think of using 2px fontsize, but realistically what sort of image with transparency would have some sort of secret information |
| 15:01 | <alystair> | an email address perhaps? |
| 15:01 | <Philip`> | http://top-secret-project-intranet-server/logo-containing-secret-project-name.gif |
| 15:01 | <alystair> | you'd then have to OCR the edges... |
| 15:01 | <alystair> | and not the entire shape |
| 15:01 | <jgraham> | Which you could maybe do |
| 15:02 | <alystair> | somehow I doubt OCR has advanced that much :P |
| 15:02 | <Philip`> | You don't need OCR, you just send the raw outline data back to the attacker's server |
| 15:02 | <Lachy> | as hsivonen said, you could use SVG filters, clipping regions or other effects to adjust which colours are rendered transparently, which means you can probe the image to find edges |
| 15:02 | <Philip`> | where they can read it manually |
| 15:02 | <jgraham> | Right, that's basically what I meant |
| 15:03 | <alystair> | talk about an edge case :P |
| 15:04 | <Lachy> | alystair, these are similar reasons to why canvases become tainted, and restrict the ability to obtain pixel data, when a non-same-origin image is added |
| 15:04 | <Philip`> | Security is all about edge cases, since it only takes one to break the security model |
| 15:05 | <alystair> | realistically can't the wrap script just have a certain limit on scan resolution of the image? |
| 15:05 | <alystair> | eg. 12px blocks as a minimum |
| 15:06 | <jgraham> | (the "edge case" thing scored 1 comedy drumroll btw) |
| 15:07 | <jgraham> | You could try making a limit like that but it seems hard to justify |
| 15:07 | <Philip`> | (But with images it seems pretty futile to try squashing all attacks, because there's various (hypothetical?) timing-related attacks and presumably the performance cost of protecting against them is unacceptable in a benchmark-driven browser marketing environment) |
| 15:07 | <Lachy> | alystair, that all depends on the target image and what level of detail is really necessary to obtain the information. Even a crude outline might be enough in some cases |
| 15:07 | Philip` | wonders if anyone has actually got such attacks working in practice |
| 15:08 | <alystair> | I find it silly that things like this even need to be discussed because we're trying to shelter even the dumbest programmer from an attack like that |
| 15:08 | <jgraham> | whereas disallowing this kind of functionality for cross domain images seems like a quite reasonable solution that has the normal properties of the web security model |
| 15:08 | <jgraham> | Uh |
| 15:08 | <alystair> | if someone is able to inject something that sends data back to a 3rd party server then they have much much larger issues |
| 15:08 | <Philip`> | It's not about injecting something |
| 15:08 | <jgraham> | There are no programmers involved |
| 15:09 | <Philip`> | It's about a user visiting http://attacker.com/ which runs scripts on the user's machine (i.e. behind their firewall) |
| 15:09 | <Lachy> | alystair, <img src="http://intranet/top-secret/image.png">; |
| 15:10 | <jgraham> | Evil site A convinces a user to visit their page and loads a resource from secret IP-restricted server B into A. It then uses some technique to extract information from that resource |
| 15:10 | <jgraham> | Allowing them to discover secrets held on B |
| 15:13 | <alystair> | like a flash uploader since they happen to know the EXACT address of the secret image url :P |
| 15:42 | <alystair> | http://www.google.com/events/io/2011/index.html <- pretty :) |
| 15:45 | jgraham | notes that the person who designed that never tried it on a laptop screen |
| 15:46 | <Lachy> | jgraham, looks perfect on my laptop screen. |
| 15:48 | <alystair> | perhaps they are running the assumption that many of the people visiting the page would have high resolution screens |
| 15:48 | <jgraham> | Lachy: You have the world's biggest laptop screen |
| 15:48 | <jgraham> | Roughly |
| 15:48 | <jgraham> | On a 13" screen it doesn't work |
| 15:48 | <Lachy> | not quite. I only have 17". Dell makes a 19" |
| 15:49 | <Philip`> | It looks alright on mine, which is only 1280x800 |
| 15:49 | <jgraham> | It might depend on how much other stuff you have |
| 15:49 | <Philip`> | (as long as I don't want to read the first two digits) |
| 15:49 | <jgraham> | On a pretty standard OSX setup the other day the QR code blocked the time |
| 15:49 | <karlcow> | The QR code is on top of the counter |
| 15:50 | <jgraham> | Ah, yes, quite broken |
| 15:50 | <alystair> | hehe I see that |
| 15:50 | <Philip`> | I thought that was intentional at first |
| 15:50 | <alystair> | if you drag it up enough it overlaps everything else :) |
| 15:50 | <karlcow> | houla and the CPU is screaming |
| 15:51 | <alystair> | do most of the people in the whatwg participate on the mailinglist or do many contribute/edit the spec without talking on it? |
| 15:53 | <karlcow> | COMMAND %CPU |
| 15:53 | <karlcow> | Opera 88.6 |
| 15:53 | <jgraham> | The WHATWG is basically the mailing list |
| 15:53 | <jgraham> | Plus this channel |
| 15:53 | <jgraham> | Plus an evil cabal |
| 15:53 | <jgraham> | Who evilly do nothing |
| 15:54 | <jgraham> | The only person who directly edits the spec is Hixie |
| 15:58 | <jgraham> | (the "evil cabal" is actually just a mailing list of some people who can, theoretically, do things like change the editor. Apparently they have hardly had any email on that list ever) |
| 15:59 | <jgraham> | (and they are likely unneeded anyway since one could change the editor by forking the spec. Of course it would only work if people wanted to follow the fork rather than the original. But that is basically an isomorphic problem to getting the people on that list to agree to change the editor) |
| 16:02 | <alystair> | haha alright |
| 16:02 | <alystair> | there's actually an easteregg on the google.io site |
| 16:02 | <alystair> | when you drag the logo it allows you to move the buttons and stuff around as well |
| 16:02 | <alystair> | which work as blockers for the balls :) |
| 16:32 | <jgraham> | Why doesn't input type=email allow one to set the IDL attribute to a unicode string and have it converted to punycode, or something? |
| 16:34 | <jgraham> | Or even better, have it stored as unicode and converted to punycode for submission |
| 17:08 | <alystair> | http://www.google.com/events/io/2011/index.html <- live streaming from event now |
| 17:16 | <Rik`> | alystair: can't get it to work from France |
| 17:16 | <alystair> | streaming movie rental |
| 17:16 | <alystair> | really? lame |
| 17:16 | <alystair> | neither live stream? |
| 17:18 | <alystair> | http://www.youtube.com/watch?v=RhmWg7Lp0i0 direct link :S |
| 17:19 | <Rik`> | yeah, it says the video is not available |
| 18:40 | <AryehGregor> | Reproducible crash for me in Opera 11.10 on Ubuntu 10.10: go to http://aryeh.name/spec/editcommands/autoimplementation.html#insertunorderedlist, click "Run tests" under "insertorderedlist". Can anyone else reproduce? |
| 18:40 | <AryehGregor> | (It seems I have an amazing talent for finding crash bugs, especially in Opera) |
| 18:41 | <AryehGregor> | (it really makes me appreciate Chrome and IE, where you can just reload the tab) |
| 18:45 | <reggna> | AryehGregor: I was just about to say that the test worked for me, but then Opera crashed. :P |
| 18:45 | <reggna> | AryehGregor: So, reproduced. |
| 18:52 | <gsnedders> | AryehGregor, reggna: submit a crash log? what email? |
| 18:52 | <AryehGregor> | gsnedders, I didn't get prompted to submit a crash log. |
| 18:52 | <AryehGregor> | Can you reproduce? |
| 18:52 | <gsnedders> | AryehGregor: Not tried |
| 18:56 | <gsnedders> | AryehGregor: Yeah, repro with no crash dialog |
| 18:56 | <AryehGregor> | k. |
| 18:57 | <AryehGregor> | Please tell me if you figure out what the problem is so I can update the page. |
| 18:59 | gsnedders | is downloading more recent debug build… |
| 19:00 | gsnedders | wants quicker internets |
| 19:03 | <gsnedders> | AryehGregor: Trying to clear a selection is failing to remove an element not in the range. |
| 19:03 | <AryehGregor> | What do you mean? Selection.removeAllRanges() is what's crashing? |
| 19:03 | <gsnedders> | Yeah. |
| 19:04 | <gsnedders> | Because there's something in the range that isn't in the range. |
| 19:04 | <AryehGregor> | Oh. |
| 19:05 | gsnedders | accidentally opens link in his main Opera install |
| 19:05 | <gsnedders> | woops. |
| 19:09 | <zewt> | heh, the only time I've ever really found browser themes to be useful is when debugging a browser side-by-side with my real browser--to make it easy to remember which is which |
| 19:10 | <gsnedders> | I just idlely right clicked -> open link |
| 19:10 | <AryehGregor> | It doesn't crash when you just open the link, though, right? |
| 19:10 | <gsnedders> | There's a reason why I know quite a lot of browser people who have a browser they don't work on as their main browser |
| 19:10 | <gsnedders> | AryehGregor: Right, but close enough to not be nice. |
| 19:10 | <AryehGregor> | Ah, okay. |
| 19:11 | <AryehGregor> | Of course, browsers usually do pretty well these days on restoring after a crash. |
| 19:11 | <zewt> | at least session restoration has made browser crashes marginally less annoying than they used to be :) |
| 19:11 | <zewt> | let's say the same thing; ready, go |
| 19:12 | <gsnedders> | AryehGregor: Yeah, it's pretty much fine, just means restarting browser, which when you have far too many tabs open can take a bit |
| 19:14 | <zewt> | i have something like 100 right now :| |
| 19:17 | <erlehmann> | zewt, gsnedders, on firefox i use bar tab, it only loads tabs that are accessed. |
| 19:18 | <erlehmann> | but still i once had a crash where the restart would crash again … the session restore tab would restore a session restore tab! |
| 19:18 | <erlehmann> | it was session restore tabs all the way down. |
| 19:19 | <zewt> | ff4 seems to try to preferentially restore tabs when they're accessed when loading a session, though i find the end result is just slower |
| 19:19 | <erlehmann> | bar tab then |
| 19:20 | <erlehmann> | like, built-in? |
| 19:20 | <zewt> | standard ff with a vertical tab addon (doesn't change behavior) |
| 19:20 | <Ms2ger> | Built-in, yes |
| 19:21 | <erlehmann> | fine :) |
| 19:32 | <gsnedders> | AryehGregor: http://pastebin.com/yjDymymq is a more minimal copy of the inline script |
| 19:33 | <AryehGregor> | gsnedders, okay, thanks. |
| 19:33 | gsnedders | doesn't have time to take it further |
| 19:35 | <AryehGregor> | Meaning you don't have time to reduce it further, but you'll still make sure that the crash bug is fixed, because this might be happening on real sites? |
| 19:36 | AryehGregor | isn't sure whether implementers prioritize crash bugs as all super-high priority or what |
| 19:39 | <jamesr> | AryehGregor: many crashes like this tend to have security implications and are prioritized pretty high because of that |
| 19:39 | <jamesr> | speaking of, if you find any more in webkit i'd appreciate if you'd file a security bug about it first and not post the repro in public IRC channels :). i think other vendors would appreciate the same |
| 19:40 | <AryehGregor> | jamesr, hmm, really? Okay. Didn't realize they were that likely to have security implications. I don't think I've found any crashes in WebKit lately. |
| 19:40 | <jamesr> | not all will, but many will |
| 19:40 | <AryehGregor> | I found one in Firefox a day or two ago, but no one else could reproduce it, so I figured it wasn't worth reporting. |
| 19:41 | <AryehGregor> | I've found a few in Opera that I mentioned here, and no one from Opera said they'd prefer it privately. |
| 19:41 | <jamesr> | if it's something like a double free or use after free then the crash might not be reliable |
| 19:41 | <jamesr> | i'm not familiar with opera's policies |
| 19:44 | <erlehmann> | jamesr, isn't full disclosure standard? |
| 19:44 | <erlehmann> | except with webkit? |
| 19:44 | <jamesr> | what? no |
| 19:44 | <jamesr> | you don't just 0-day everyone |
| 19:44 | <AryehGregor> | I don't think anyone appreciates full disclosure without first at least informing the vendor. |
| 19:45 | <jamesr> | people argue about details but the IMO reasonable behavior is to disclose to vendor, give them a chance to patch users, then disclose publicly |
| 19:46 | <erlehmann> | I once published a short script crashing a chat client and it made people angry and they fixed the bug. But, it made people angry :> |
| 19:46 | <erlehmann> | Otherwise, I have no idea how bugs should be handled. |
| 19:51 | <AryehGregor> | The annoying thing is it's considerably more effort for me to actually file a bug report, and the response is likely to be considerably longer, compared to just saying it here. But I guess I'll be more careful in the future. |
| 19:51 | <jamesr> | why is it considerably more effort? |
| 19:52 | <gsnedders> | jamesr: this almost certainly isn't exploitable, at least |
| 19:52 | <AryehGregor> | Because over here I can just type one line in a chat, and someone will probably answer in a few minutes. To file a bug I have to make a permanent link, go through a bunch of forms, and then wait who knows how long for a response. |
| 19:53 | <gsnedders> | My normal approach is to file a bug and poke people on IRC |
| 19:54 | <gsnedders> | AryehGregor: Basically the policy for things that might be security issues is to treat them as security issues until proven otherwise. |
| 19:55 | <gsnedders> | Whether you treat all crash bugs like that or not is a good question |
| 19:55 | <AryehGregor> | I've been assuming they don't need to be treated like that. |
| 19:56 | <gsnedders> | I have no idea what our policy is :) |
| 19:59 | <gsnedders> | All the range crash bugs you've found have just been null-pointer dereferences, nothing interesting from a security POV |
| 20:01 | <AryehGregor> | Generally the bugs I find are in pages I'm rapidly changing anyway, and in a few hours it won't be reproducible from the instructions I gave in the chat. |
| 20:02 | <AryehGregor> | (since it's not very useful for me to have my tests crash) |
| 20:02 | <AryehGregor> | So I'm not going to worry too much. |
| 20:04 | <gsnedders> | AryehGregor: Uh, I think there may well be more than one crash bug there. |
| 20:04 | <AryehGregor> | Interesting. |
| 20:05 | <gsnedders> | AryehGregor: Like that reduced script gives an entirely different crash |
| 20:06 | <AryehGregor> | Kind of weird for me to hit two crashes at once. |
| 20:20 | <jgraham> | Not really if that code happens to be buggy |
| 20:30 | <gsnedders> | AryehGregor: Back to looking at it after all |
| 20:42 | <gsnedders> | AryehGregor: http://pastebin.com/Uxv2Nczw |
| 20:43 | <AryehGregor> | Interesting. |
| 20:55 | <Philip`> | "* Philip` wonders if anyone has actually got such attacks working in practice" - turns out they have - http://www.contextis.com/resources/blog/webgl/ |
| 20:56 | Philip` | wonders if it's possible without using WebGL, based on the performance of 2D canvas operations |
| 20:58 | <jamesr> | Philip`: that'd be pretty tricky |
| 20:59 | <Philip`> | "pretty tricky" sounds different to "impossible" :-) |
| 20:59 | <jamesr> | well, side channel attacks are always crazy |
| 21:00 | <jamesr> | but to make this attack work you need the draw time to vary as much as possible based on the value of the pixels |
| 21:00 | <jamesr> | and that's hard to do with the canvas2d ops |
| 21:01 | <jamesr> | much easier if you can write your own shader |
| 21:01 | <jamesr> | this attack also depends a lot on how the graphics driver+card evaluate shaders |
| 21:07 | <AryehGregor> | Ugh. br elements are a huge pain in the neck. |
| 21:07 | <erlehmann> | br { display: none; } |
| 21:07 | <erlehmann> | :3 |
| 22:19 | <wilhelm_> | Will those who cannot live with the upvoted licenses now commit seppuku? |
| 22:21 | <TabAtkins> | If only they were so honorable. |
| 22:22 | <TabAtkins> | I love writing about character references in HTML. &amp; all over the place. |
| 22:37 | <AryehGregor> | wilhelm_, why should they? Is the W3C going to adopt them? |
| 22:37 | <AryehGregor> | I mean, it was a non-binding survey, wasn't it? |
| 22:40 | <jgraham> | So you aren't bound by your statement that you couldn't live with it? |
| 22:40 | <wilhelm_> | Well, then a different subset of the surveyed should commit seppuku. Unless they were lying, and can live with it. |
| 22:41 | <AryehGregor> | No, I'm saying you should only expect anyone to commit seppuku once a particular license is actually adopted. |
| 22:41 | <wilhelm_> | True. |
| 22:43 | <Philip`> | Presumably people who can't live with any non-forking licences also can't live with the spec's current non-forking licence, in which case they wouldn't be alive to object to it even if it'll change later |
| 23:22 | <AryehGregor> | The per-organization breakdown of the license survey is interesting. |
| 23:23 | <AryehGregor> | Implementers and unaffiliated people are overwhelmingly in favor of some type of free license. |
| 23:24 | <AryehGregor> | But if you do a count by organization and ignore unaffiliated people, non-free licenses would win, because the non-implementer organizations lean strongly against free licenses. |
| 23:25 | <AryehGregor> | In fact, only one non-implementer organization (Intel) said that it couldn't live with option 3, while eight non-implementer organizations said they preferred or could live with it. |
| 23:25 | <AryehGregor> | This pattern is interesting, because the AC is made up almost entirely of non-implementer organizations, and unaffiliated people get no say. |
| 23:26 | <AryehGregor> | And, of course, it voted against free licenses. |
| 23:26 | <TabAtkins> | I always find it interseting that there is such a disconnect between the orgs that actually have a stake in the tech and those that don't. |
| 23:27 | <AryehGregor> | It suggests to me that perhaps implementers and individuals are involved in the W3C because they have a stake in the issue and don't care so much about the W3C itself, while non-implementer organizations are more likely to be interested in influencing the standards through the W3C, and so would be unhappy with the W3C losing power. |
| 23:27 | <AryehGregor> | Implementers will control the specs anyway, and unaffiliated individuals have no say anyway, so it doesn't make a big difference to them whether the specs are edited at the W3C or someplace else. |
| 23:28 | <AryehGregor> | Except Microsoft. Who knows who made Microsoft's decision and why. |
| 23:28 | <AryehGregor> | Of course, the W3C is dependent on having lots of members that don't have a big stake in things, because that's the only way it can get enough membership dues to support its bureaucracy. |
| 23:29 | <AryehGregor> | So I don't think the W3C is likely to be fixable, in the end. |
| 23:29 | <AryehGregor> | To fix it, you'd have to give the power to the people who have an actual stake in things, and that would disenfranchise the other members. |
| 23:29 | <AryehGregor> | Who would either not permit it, or leave and take away the W3C's funding. |
| 23:30 | <AryehGregor> | I guess the implementers aren't going to actually leave the W3C anytime soon, though, since the job it does isn't sufficiently bad to warrant the trouble, so we're stuck with the status quo. |
| 23:45 | <Hixie> | jgraham: yt? (or any other opera peeps) |
| 23:47 | <wilhelm_> | \o |
![http://intranet/top-secret/image.png">](http://intranet/top-secret/image.png">){kind=link}