| 00:04 | <TabAtkins> | Alternately, we just build randomness in, but nobody ever seriously considers that. :/ |
| 00:05 | <zewt> | not sure how you could do that in the general case |
| 00:06 | <zewt> | without making things worse in some cases |
| 00:08 | <zewt> | i guess a minimal "randomness", without going all the way, could have the wanted effect, like occasionally breaking a push of 1000 bytes into two callbacks of 300 and 700 bytes, just to exercise the "this isn't always 1000 bytes at a time" code path |
| 00:10 | <zewt> | (which is probably a real case--if you're sending 1000 bytes, and you're on a 1500 MTU network, and you're only testing with a local server, you might never see your 1000-byte-data-chunks get split up) |
| 00:18 | <roc> | TabAtkins: http://robert.ocallahan.org/2014/03/introducing-chaos-mode.html |
| 00:19 | <roc> | TabAtkins: it would be nice to make randomness mandatory. The problem is it makes debugging harder for everyone. |
| 00:19 | <TabAtkins> | Yeah, I know. :/ |
| 00:19 | <TabAtkins> | But an occasional thin, like zewt said, might work sufficiently. |
| 00:21 | <roc> | Sooner or later we'll have the record-and-replay technology we need to make the debugging easy. |
| 00:55 | <zewt> | well, there's a certain level of randomness in real-world networking anyway, so in a sense simulating it in the browser so that randomness is *always* there makes some sorts of testing/debugging easier |
| 00:56 | <zewt> | (of course, it doesn't have to be mandatory to fulfill that part) |
| 01:48 | <roc> | gah |
| 01:48 | <roc> | Chrome still doesn't support the unprefixed "transform" property? |
| 01:52 | <JosephSilber> | gah indeed |
| 03:17 | <foolip_> | roc: it's happening finally: https://codereview.chromium.org/98663004/ |
| 03:18 | <roc> | created 2 months ago |
| 03:18 | <roc> | ? |
| 03:19 | <roc> | but, that's great |
| 03:45 | <foolip> | roc: I guess he worked on it for a while, the blink-dev thread is only a few days old |
| 05:00 | <cabanier> | foolip: it's still to early to remove theprefix |
| 06:19 | <krit> | cabanier: roc: foolip: smfr and I worked on a proposal to make 3D transforms interoperable. smfr published the early spec text as a google doc in one of his mails to www-style. This will require smaller to bigger changes in all Implementatuons. But I do believe it is going into the right direction and is more logical. That said, I think Blink should wait |
| 06:19 | <krit> | before unprefixing and add the chanes first. |
| 07:53 | <niloy> | is there any api to communicate between open tabs/windows? |
| 07:53 | <foolip> | cabanier: ok, you should tell blink-dev |
| 07:54 | <ondras> | niloy: postMessage would work |
| 07:54 | <niloy> | postMessage requires handle to the other window, I want to broadcast to all open windows |
| 07:55 | <ondras> | tough luck I guess. People are doing this by abusing localStorage events, IIRC |
| 07:56 | <niloy> | ok thanks, I would do that too |
| 08:41 | <krit> | foolip: Rik and I did previously... just responded again |
| 09:04 | <zcorpan> | Hixie: why does <dialog>.close() throw (instead of being no-op)? |
| 09:05 | <zcorpan> | niloy: http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts (i guess it's not implemented yet though) |
| 09:12 | <MikeSmith> | per the DOM spec is there any case in which when a UA fires an event, it doesn't initialize the isTrusted attribute to "true"? |
| 09:13 | <MikeSmith> | any case in which that's conforming |
| 09:13 | <Ms2ger> | I don't think so |
| 09:13 | <MikeSmith> | OK, specifically, blink fires the "focus" and "blur" events without isTrusted=true |
| 09:14 | <MikeSmith> | so that's non conforming, right? |
| 09:16 | <Ms2ger> | Mmm |
| 09:16 | <Ms2ger> | I suspect it would be |
| 09:17 | <MikeSmith> | ok |
| 09:17 | <zcorpan> | there's no proper spec for focus/blur i think, but it's certainly wrong |
| 09:19 | <zcorpan> | hmm http://www.w3.org/TR/DOM-Level-3-Events/#trusted-events actually says something about it |
| 09:19 | <zcorpan> | (sorry for TR/) |
| 09:19 | <zcorpan> | https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#trusted-events |
| 09:21 | <zcorpan> | "Most untrusted events should not trigger default actions, with the exception of click or DOMActivate events." ... "All other untrusted events must behave as if the Event.preventDefault() method had been called on that event." |
| 09:21 | <zcorpan> | so is that SHOULD NOT or MUST? |
| 09:21 | MikeSmith | looks |
| 09:22 | <MikeSmith> | zcorpan: the HTML spec itself put requirements on focus/blur |
| 09:22 | <zcorpan> | MikeSmith: oh |
| 09:23 | <MikeSmith> | http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focus-update-steps |
| 09:23 | <zcorpan> | well then |
| 09:26 | <MikeSmith> | zcorpan: but gecko makes both of them cancelable, and in blink both are isTrusted=undefined |
| 09:34 | <zcorpan> | undefined? looks like it's not supported on any event? |
| 09:38 | <zcorpan> | wonder what should happen with HTMLDialogElement.prototype.returnValue = { set:function(v) { alert(v); } }; <dialog open>.close('x'); |
| 09:51 | <darobin> | heh, evil zcorpan |
| 10:00 | <jgraham> | QA zcorpan only has one setting |
| 10:09 | <zcorpan> | :-) |
| 12:38 | <ondras> | so, a question re. <template> element |
| 12:38 | <ondras> | who is the best person for this? |
| 12:42 | <Ms2ger> | dglazkov |
| 12:42 | <ondras> | dglazkov: ? |
| 12:43 | <ondras> | dglazkov: do I understand correctly that template.content has a different ownerDocument than the document containing the <template> itself? |
| 13:26 | <annevk> | ondras: test it |
| 13:26 | <annevk> | ondras: but I believe that's true, yes |
| 14:01 | <abarth> | ondras: I think they all share a common document that's different from the active document |
| 14:02 | <ondras> | and yet, it looks like one can append template.content (or template.content.cloneNode()) into the current document |
| 14:02 | <ondras> | which is normally not true, IIRC |
| 14:02 | <ondras> | (that's why importNode exists, right?) |
| 14:02 | <abarth> | doesn't appendChild adopt automatically these days? |
| 14:02 | <ondras> | hmmh, that would explain it |
| 14:02 | <abarth> | I think annevk changed that a year or so ago |
| 14:02 | <annevk> | yes, implicit adopt is the norm |
| 14:03 | <annevk> | in fact, I don't think there's anything that does not do implicit adopt these days |
| 14:03 | <annevk> | too convenient |
| 14:03 | <ondras> | annevk: I tried in one browser and the ownerDocument differed, yes |
| 14:03 | <ondras> | annevk: but this stuff is still pretty raw, so I wanted to make sure it adhers to the spec |
| 14:04 | <annevk> | ondras: just read the spec, it's per spec |
| 14:04 | <annevk> | ondras: http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#template-contents is quite easy to follow |
| 14:05 | <ondras> | annevk: I saw the spec, but the fact that I can append template.content to a different document made me unsure |
| 14:06 | <ondras> | annevk: cause automatic adoption is something new to me |
| 14:09 | <ondras> | also; <script> nodes in <template> are ignored until appended, but <script> nodes in <link rel="import"> are executed immediately? |
| 14:09 | <ondras> | even if the latter case also has a different ownerDocument? |
| 14:13 | <abarth> | ondras: that's correct |
| 14:13 | <abarth> | script elements in template documents are just like script nodes in documents created via createDocument |
| 14:13 | <abarth> | imported documents are different in that they execute |
| 14:13 | <abarth> | (otherwise they'd be kind of useless) |
| 14:14 | <ondras> | abarth: okay, thanks for explanation. I am considering the best layout of features (html, js, imports, ...) for a "web components" overview talk + sample realization |
| 14:15 | <abarth> | neat |
| 14:15 | <ondras> | abarth: so typically a custom element is defined within an imported document; furthermore, its dom is specified in a <template> local to that import? |
| 14:17 | <annevk> | abarth: if HTML imports become DocumentFragment, they'd no longer execute I guess, might need tweaks for that... |
| 14:17 | <abarth> | ondras: correct |
| 14:18 | <ondras> | abarth: and the <template> is generally not accidentaly accessible from within the host page |
| 14:18 | <ondras> | abarth: one would need to do link.import.querySelector(...) to reach it |
| 14:24 | <abarth> | ondras: that I'm not sure how best to answer |
| 14:25 | <abarth> | you're right that the contents of the template aren't part of the document and so aren't accidentially accessible via querySelector |
| 14:26 | <ondras> | abarth: I understand that typically the host is not going to access the template |
| 14:26 | <ondras> | because it contradicts the best practices |
| 14:26 | <ondras> | or does it? |
| 14:26 | <abarth> | someone needs to access the template, but typically you'll use a templating library that does that work for you |
| 14:27 | <ondras> | that is what I am somewhat missing. The specs are available, introductory articles as well. But "recommended practices" along with relevant argumentation... |
| 14:27 | <ondras> | abarth: I was expecting a script inside the import to access it |
| 14:27 | <abarth> | e.g., you'll have {{ ... }} in your template that the library will fill in |
| 14:27 | <ondras> | and to use it as a shadowRoot for a customElement |
| 14:27 | <abarth> | there are different layers to the system |
| 14:27 | <abarth> | layers like <template> don't have much of an opinion |
| 14:27 | <ondras> | let's assume I want to use only existing standards |
| 14:27 | <ondras> | so no library code |
| 14:28 | <abarth> | in that case, you'll need to form your own opinion about how best to use these tools |
| 14:28 | <abarth> | <template> is a way of building a DOM "off to the side" |
| 14:28 | <abarth> | which is useful for making a template system |
| 14:29 | <abarth> | but it doesn't itself provide a syntax or mechanism for filling in the template and generating the DOM to display |
| 14:29 | <abarth> | that's left open for JavaScript libraries to decide |
| 14:29 | <ondras> | hmm |
| 14:29 | <Domenic_> | <template> is just <script type="text/x-my-template"> but with some preparsing advantages |
| 14:29 | <ondras> | I thought custom elements / shadow dom is a natural way to do so |
| 14:30 | <abarth> | yes, these tools are designed to work well together |
| 14:30 | <abarth> | but they don't force you to combine them in any specific way |
| 14:30 | <ondras> | Domenic_: well it is not suggested to put a valid HTML markup inside a <template> ? |
| 14:30 | <Domenic_> | ondras: i don't understand the question |
| 14:30 | <ondras> | Domenic_: because some people put unholy shit into <script type="my-own-template-system"> |
| 14:30 | <abarth> | you can put HTML markup inside <template> |
| 14:31 | <abarth> | the script approach defers parsing |
| 14:31 | <ondras> | yes, I know I can. and I thought I *should* |
| 14:31 | <abarth> | it just contains a sequence of characters |
| 14:31 | <abarth> | <template> does the parsing at the same time as everything else |
| 14:31 | <abarth> | so it produces a DOM tree outside of the main document |
| 14:31 | <ondras> | yeah, but <template> implies a valid DOM inside of it |
| 14:31 | <Domenic_> | nope |
| 14:31 | <ondras> | which is not the case for <script type="custom"> |
| 14:31 | <ondras> | nope? hm. |
| 14:31 | <Domenic_> | or, well, yes, but pretty much everything is a valid dom |
| 14:33 | <Domenic_> | i guess what i mean is "parseable" not "valid" |
| 14:33 | <ondras> | okay |
| 14:33 | <ondras> | I see your point |
| 14:34 | <ondras> | people should put whatever they want into <template> and make sure they fill it with data accordingly |
| 14:34 | <ondras> | so my question probably is, what is the recommended way of passing the filled-with-data template to the host document |
| 14:35 | <ondras> | Failed to execute 'write' on 'Document': It isn't possible to write into a document from an asynchronously-loaded external script unless it is explicitly opened. |
| 14:35 | <ondras> | darn! |
| 14:35 | <ondras> | (doc.write inside of an import) |
| 14:36 | <ondras> | so this api will need an async way of loading. |
| 14:36 | <abarth> | ondras: there isn't a recommend way |
| 14:36 | <abarth> | ondras: that's up to library authors to decide |
| 14:36 | <ondras> | ok |
| 14:37 | <abarth> | ondras: I can give you some links to libraries that have opinions on that topic, but they all do things differently |
| 14:37 | <abarth> | ondras: <template> is a hammer. What you build with it is up to you. |
| 14:37 | <ondras> | abarth: I will try a non-library approach and see what comes out. Thanks anyway. |
| 14:38 | <abarth> | a simple thing you can try |
| 14:38 | <abarth> | is cloning the contents of the template |
| 14:38 | <abarth> | and appending them to the DOM |
| 14:38 | <ondras> | obviously |
| 14:38 | <ondras> | (and that works fine, yes) |
| 14:38 | <Domenic_> | it's a pretty cool hammer though. e.g. consider how annoying it was to change <img src="{{src}}"> to <img src="real-src.gif"> with just <script type="text/my-template">. |
| 14:38 | <ondras> | but what part of the host-import duet shall do that? |
| 14:39 | <ondras> | Domenic_: how exactly would you re-word this example using a <template>? |
| 14:39 | <Domenic_> | ondras: which example? |
| 14:39 | <ondras> | 715:38 < Domenic_> it's a pretty cool hammer though. e.g. consider how annoying it was to change <img src="{{src}}"> to <img src="real-src.gif"> with just <script type="text/my-template">. |
| 14:40 | <Domenic_> | sure. with <script> you had to do string manipulation. with <template> you can just access the inert DOM inside the template |
| 14:40 | <ondras> | ah, ok |
| 14:40 | <ondras> | I thought the <script> version could leverage some DOM manipulation as well |
| 14:40 | <Domenic_> | nah, cuz it's just a blob of unparsed text |
| 14:40 | <ondras> | Domenic_: well one can put it inside a <div> or so... |
| 14:41 | <Domenic_> | then you get a 404 for {{src}} |
| 14:41 | <ondras> | true. |
| 14:41 | <Domenic_> | <template> gives you the inertness |
| 14:41 | <ondras> | which is cool, indeed |
| 14:41 | <ondras> | but probably not the best tool for my current use case of an interactive map |
| 14:42 | <ondras> | which does not have any relevant templatable content, I guess |
| 14:42 | <Domenic_> | yeah, if you're not looking for "a better <script type="text/my-template">," you probably don't want <template>. |
| 14:42 | <ondras> | I am not |
| 14:42 | <ondras> | 15:14 < ondras> abarth: okay, thanks for explanation. I am considering the best layout of features (html, js, imports, ...) for a "web components" overview talk + sample realization |
| 14:43 | <ondras> | my company is offering a mapping JS API (similar to gmaps api), so it would be natural to demo web components using <our-own-map> or so |
| 14:43 | <Domenic_> | yeah, just custom elements, maybe shadow DOM, are probably what you want here |
| 14:44 | <abarth> | ondras: yep |
| 14:44 | <abarth> | ondras: when your custom element gets created, you might have a template to instantiate |
| 14:44 | <abarth> | ondras: and you can put the instance in the shadow |
| 14:44 | <abarth> | ondras: that's the general idea : |
| 14:44 | <abarth> | :) |
| 14:44 | <ondras> | that is what I see in many examples |
| 14:44 | <ondras> | but not very suitable for a map |
| 14:45 | <ondras> | custom elements, shadowdom, imports |
| 14:45 | <ondras> | sounds like a useful combo for my case. |
| 14:45 | <ondras> | template will be demoed elsewhere |
| 14:46 | <abarth> | it still might be useful... consider the case where there are many our-own-map elements |
| 14:47 | <abarth> | you might want to parse the DOM for the inside of the element once |
| 14:47 | <abarth> | and then just clone it for each instance |
| 14:47 | <abarth> | maybe for a map you don't expect many instances per page |
| 14:47 | <ondras> | the DOM for the inside is built by the JS API script |
| 14:47 | <ondras> | which loads all the map layer tiles, draws controls etc |
| 14:47 | <abarth> | that works too |
| 14:51 | <ondras> | one more question |
| 14:51 | <ondras> | http://w3c.github.io/webcomponents/explainer/ |
| 14:51 | <ondras> | the this._root property name. chosen arbitrarily, or is the "_root" some pre-defined reserved name? |
| 14:52 | <abarth> | it's just arbitrary |
| 14:52 | <abarth> | could be anything you like |
| 14:52 | <ondras> | okay |
| 14:53 | <abarth> | the idea is that you don't want to lose track of the shadow root |
| 14:53 | <abarth> | because it's your window into the hidden part of the element |
| 15:10 | <ondras> | abarth: so now my custom element is lacking a display:block declaration, although it extends HTMLDivElement.prototype |
| 15:11 | <ondras> | abarth: I wonder what am I doing wrong |
| 15:11 | <abarth> | ondras: yep. extending HTMLDivElement.prototype doesn't make you a block |
| 15:11 | <abarth> | you need to use CSS for that |
| 15:11 | <ondras> | interesting |
| 15:11 | <abarth> | <style>my-map { display: block; }</style> |
| 15:12 | <abarth> | if you're in shadow dom: |
| 15:12 | <abarth> | <style>:host { display: block; }</style> |
| 15:12 | <abarth> | lets you avoid repeating the name of your element |
| 15:12 | <ondras> | neat |
| 15:13 | <abarth> | that's just because unknown elements are display: inline in browsers |
| 15:13 | <ondras> | now these styles |
| 15:13 | <ondras> | shall be inside of my <template> I guess |
| 15:13 | <ondras> | the only reason for its existence! |
| 15:13 | <ondras> | also, <style scoped>, right? |
| 15:14 | <abarth> | styles are automatically scoped to their shadow tree |
| 15:14 | <abarth> | if you're using JS to build the test of your dom, you can just add the style element with JS too |
| 15:15 | <ondras> | I will be using <template> in the end, for two reasons |
| 15:15 | <ondras> | first, to provide a <style> node for that :host declaration |
| 15:15 | <ondras> | second, the map needs a container to build itself in |
| 15:15 | <ondras> | and the shadow root is not a suitable container itself. |
| 15:16 | <ondras> | so my template will be like <template> <style> :host { display:block; } div { width:100%;height:100%; }</style> <div></div></template> |
| 15:16 | <abarth> | you can give you div an ID if you like |
| 15:17 | <abarth> | as long as you put the instance in the shadow, it won't collide with any ids used by the host document |
| 15:17 | <ondras> | ok |
| 15:17 | <abarth> | the shadow root has a getElementById |
| 15:17 | <ondras> | well that is not necessary, querySelector("div") will retrieve it anyway |
| 15:17 | <abarth> | that looks inside the shadow |
| 15:17 | <abarth> | that's true |
| 15:19 | <ondras> | abarth: the attributeChangedCallback does not apply when a width changes, for instance? |
| 15:32 | <TabAtkins> | abarth: :host does more than just allow you to avoid repeating the name of your element - you actually *can't* select the host element by its tagname from within the shadow DOM. |
| 15:32 | <TabAtkins> | The only thing that matches the host element is :host. |
| 15:37 | <Hixie> | zcorpan: dunno, maybe we should changhe it |
| 16:23 | <dglazkov> | good morning, Whatwg! |
| 16:27 | <SamB> | hmm, what do people think of abusing web fonts for icons (when those icons lack standardized Unicode codepoints)? |
| 16:28 | <SamB> | the fallback story seems pretty terrible ... |
| 16:29 | <wilhelm_> | I use them all the time, together with text. It's great. |
| 16:29 | <wilhelm_> | On their own, I agree, they're tricky. |
| 16:29 | <SamB> | I mean, what about user-agents that can't handle web fonts? |
| 16:30 | <wilhelm_> | They see nothing, in the same way as browsers that don't support border-radius don't see rounded corners. What's the problem with that? |
| 16:33 | <wilhelm_> | For real-world use, you're down to Android 2.* and Opera Mini lacking proper web font support. They can live with minor cosmetic flaws. |
| 16:34 | <wilhelm_> | (I'm assuming you are using icons in addition to text, not as a replacement.) |
| 16:40 | <SamB> | wilhelm_: er, how would you arrange that they see nothing, rather than seeing at best a U+FFFD ? |
| 16:45 | <wilhelm_> | SamB: s/nothing/U+FFFD |
| 16:45 | <wilhelm_> | But retesting this in Android 2.2, my icons are visible... |
| 17:00 | <SamB> | I guess it probably doesn't matter as much on sites that demand JavaScript, though I don't know what screenreaders do with such icons ... |
| 17:02 | <SamB> | or rather, what you can do with such icons to get screenreaders to leave them alone |
| 17:03 | <SamB> | I suppose it's probably fairly safe to use :before rules to add them? (Does anyone support :before but not web fonts?) |
| 17:05 | <SamB> | but, anyway, if such icons are present in the HTML as, say, some CJK character, that's going to look VERY bad in elinks, w3m, or any of the Emacs-based browsers ... |
| 17:06 | SamB | imagines a new font-family keyword "none" ... |
| 17:07 | <SamB> | (which would be used to end lists) |
| 18:15 | <Hixie> | is there a way these days (maybe with flex) to format "label text: [input element]" such that the input element takes up the remaining room on the line? |
| 18:20 | <Domenic_> | flex seems like the right tool for that... |
| 18:26 | <SamB> | Hixie: takes it up how? |
| 18:27 | <Hixie> | like, if the page is like this: |
| 18:27 | <Hixie> | | left edge... ... right edge | |
| 18:27 | <Hixie> | | my label: [my control ] | |
| 18:27 | <SamB> | oh |
| 18:27 | <Hixie> | | my other label: [my other control ] | |
| 18:28 | SamB | may have been mixing up <input> with <sample> or whatever ... |
| 18:29 | SamB | kind of likes tabular forms sometimes |
| 18:31 | <Hixie> | hey, why does firefox not support HTMLInputElement.labels |
| 18:31 | <Hixie> | boo |
| 18:55 | gsnedders | is having one of those days where his life would be simpler if the spec's tokenizer was finite state |
| 18:55 | <gsnedders> | (it's not, the temporary buffer has an unbounded finite length, so there are infinitely many possible values it can hold, thus the whole machine is infinite state) |
| 18:57 | <gsnedders> | Also CDATA sections (through depending on the stack of open elements) makes it infinite state. |
| 19:20 | <SamB> | gsnedders: hmm. |
| 19:20 | <SamB> | can you say "denial of service"? |
| 19:20 | <SamB> | though I guess just a big DOM does the same ... |
| 19:46 | <gsnedders> | SamB: It's linear in the input size, so it's no worse than any other long input. |
| 19:47 | <SamB> | yeah |
| 19:47 | <gsnedders> | It's not a problem, it's just annoying to model, because finite state models are easier to work with :) |
| 19:48 | <SamB> | you mean like modeling it in coq or something? |
| 19:48 | <gsnedders> | Well, in a model checker and not a theorem prover, but yes. |
| 19:49 | <SamB> | hmm, I guess I don't know what a model checker actually is ... |
| 19:49 | <gsnedders> | Model checking is essentially checking that a proper holds given a model of a system. |
| 19:50 | <gsnedders> | *property |
| 19:50 | <gsnedders> | Theorem proving is essentially proving an arbitrary theorem. :) |
| 19:51 | <SamB> | so ... a sort of specialized theorem prover then? |
| 19:51 | <gsnedders> | Essentially, yes |
| 20:10 | <Hixie> | TabAtkins: yt? |
| 20:10 | <Hixie> | TabAtkins: i'm trying to use flex with some <input> elements. Does the fact that inputs always have a non-auto 'width' mess up my ability to make them stretch? |
| 22:31 | <erlehmann> | gsnedders |
| 22:31 | <erlehmann> | gsnedders http://gsnedders.html5.org/outliner/process.py?url=file:///etc/passwd |
| 22:31 | <gsnedders> | Um… |
| 22:31 | <gsnedders> | That's not good. |
| 22:31 | <erlehmann> | http://gsnedders.html5.org/outliner/process.py?url=file:///dev/urandom |
| 22:31 | <erlehmann> | :DDDDDDDD |
| 22:32 | <erlehmann> | I AM SO CLEVER |
| 22:32 | <gsnedders> | Well done, you've found a bug in html5lib. |
| 22:32 | <gsnedders> | From /dev/urandom. |
| 22:33 | <erlehmann> | gsnedders lol |
| 22:33 | <gsnedders> | urllib2.urlopen supports file://!?? |
| 22:33 | <erlehmann> | snibedi snab |
| 22:34 | <erlehmann> | in before i have to change some of my code as well |
| 22:34 | <erlehmann> | lel |
| 22:34 | <erlehmann> | gsnedders let me look it up what it does open |
| 22:34 | <gsnedders> | erlehmann: fixed |
| 22:34 | <erlehmann> | gsnedders the bug in html5lib? ;) |
| 22:34 | <gsnedders> | erlehmann: nah, that it supported file |
| 22:35 | <gsnedders> | Apparently also supported ftp ;P |
| 22:35 | <gsnedders> | Now limited to http |
| 22:36 | <erlehmann> | gsnedders it is literally the first sentence in the documentation http://docs.python.org/2/library/urllib.html#urllib.urlopen |
| 22:36 | <erlehmann> | okay the second |
| 22:36 | <erlehmann> | > Open a network object denoted by a URL for reading. If the URL does not have a scheme identifier, or if it has file: as its scheme identifier, this opens a local file (without universal newlines); otherwise it opens a socket to a server somewhere on the network. |
| 22:36 | <gsnedders> | I know. |
| 22:36 | <gsnedders> | :) |
| 22:36 | <gsnedders> | Why would I read the manual? ;P |
| 22:36 | <Hixie> | man, that's a frightening default |
| 22:36 | <erlehmann> | Hixie why? |
| 22:37 | <erlehmann> | it opens arbitrary urls |
| 22:37 | <erlehmann> | just as it says |
| 22:37 | <Hixie> | because people like gsnedders will write software like process.py and let themselves get owned |
| 22:37 | <Hixie> | (and people like me) |
| 22:37 | <erlehmann> | well gsnedders should have used requests |
| 22:37 | <erlehmann> | but i use urllib as well |
| 22:37 | <erlehmann> | so i have an application that goes over a gigabyte dataset |
| 22:37 | <gsnedders> | erlehmann: Dude, the whole outliner is just a hack :P |
| 22:38 | <erlehmann> | gsnedders don't worry, i just used it to teach a friend the concept of outlines |
| 22:38 | <erlehmann> | but i am prone to breaking things |
| 22:38 | <gsnedders> | erlehmann: Also, I didn't use requests because it didn't exist until two years after I wrote the outliner |
| 22:38 | <erlehmann> | my web hoster even sent me a mail that their new setup has explicitly considered stuff that broke when i tried things in the past |
| 22:38 | <erlehmann> | gsnedders you win! |
| 22:38 | <erlehmann> | gsnedders the outliner is nice |
| 22:38 | <erlehmann> | it helps people to grok outlines |
| 22:38 | <erlehmann> | :) |
| 22:38 | <gsnedders> | I was going to claim it was because I didn't know about it then. Turns out it didn't exist. |
| 22:38 | <erlehmann> | thank you for it |
| 22:39 | <erlehmann> | good defense! |
| 22:39 | <erlehmann> | best defense |
| 22:39 | <gsnedders> | (For the curious, I implemented the algo for the sake of generating TOCs in Anolis. Then people asked me to make it standalone. So I did.) |
| 22:39 | <erlehmann> | Hixie i do think the frightening default is thinking „url = http“ |
| 22:39 | <gsnedders> | (Thus why it's a bit of a hack.) |
| 22:39 | <erlehmann> | gsnedders what is anolis? |
| 22:39 | <zewt> | Hixie: that's nothing, python's https stuff silently doesn't check server certificates by default |
| 22:39 | <erlehmann> | yeah, or imaplib |
| 22:40 | <zewt> | i guess they're both insane |
| 22:40 | <erlehmann> | offlineimap has this fun thing in the man page |
| 22:40 | <gsnedders> | erlehmann: I wouldn't consider file a URL. HTTP, FTP, sure… |
| 22:40 | <erlehmann> | Unfortunately, by default we will not verify the certificate of an IMAP |
| 22:40 | <erlehmann> | TLS/SSL server we connect to, so connecting by SSL is no guarantee |
| 22:40 | <erlehmann> | against man-in-the-middle attacks. |
| 22:40 | <erlehmann> | gsnedders o.0 |
| 22:40 | <zewt> | file://foo is a url, of course |
| 22:41 | <gsnedders> | erlehmann: file is magic in more ways than one, like javascript |
| 22:41 | <zewt> | everything on the web is magic |
| 22:41 | <gsnedders> | Well, right. It's a URL, obviously. But it's totally unlike every other URL. |
| 22:41 | <Hixie> | javascript: is actually more or less dead as a url scheme! |
| 22:41 | <Hixie> | it's limited to special processing during navigation |
| 22:42 | <zewt> | seems like lots of urls are totally unlike every other url, heh |
| 22:42 | <erlehmann> | gsnedders you are right yes |
| 22:42 | <erlehmann> | javascript is the stupidest thing. |
| 22:42 | <erlehmann> | zewt yes and i hate it. |
| 22:42 | <erlehmann> | blob URLs are magic as well |
| 22:42 | <erlehmann> | and i never understood why they were needed. optimization efforts? |
| 22:43 | <zewt> | they're the only sensible way to load big blobs into APIs that expect URLs |
| 22:43 | <zewt> | (... that we have today, of course) |
| 22:44 | <erlehmann> | so it is like „our implementation cannot handle data uri so large“ ? |
| 22:44 | <gsnedders> | https://github.com/gsnedders/outliner in case anything else wants to check stuff out |
| 22:44 | <zewt> | i guess you could call not using 50 MB data: urls "optimization", i call it not being insane |
| 22:44 | <erlehmann> | zewt optimization can always happen behind the scenes. |
| 22:44 | <erlehmann> | zewt think lisp machines |
| 22:45 | <zewt> | every api that accepts URLs shouldn't have to be optimized to handle being passed a 2 GB string as a URL |
| 22:45 | <gsnedders> | erlehmann: How? By somehow magically detecting foo.src = x.url or something? |
| 22:45 | <gsnedders> | https://github.com/gsnedders/outliner has the outliner on it |
| 22:48 | <erlehmann> | gsnedders i have no idea. let me take my ritalin and look at some use cases. |
| 22:50 | <erlehmann> | gsnedders you know the application i wrote could upload arbitrary sound or video files to wikimedia commons! |
| 22:51 | <erlehmann> | from the users system |
| 22:51 | <erlehmann> | not that it is a bad thing |
| 22:51 | <erlehmann> | but similar to your case of having the „outline“ of /etc/passwd, there is nothing tooo bad |
| 22:51 | <erlehmann> | unless … /etc/passwd could have triggered a bug in html5lib |
| 22:51 | <erlehmann> | like /dev/random |
| 22:51 | <erlehmann> | so … |
| 22:51 | <erlehmann> | the stack trace would probably have included it |
| 22:51 | <gsnedders> | the html5lib bug is harmless |
| 22:52 | <gsnedders> | And will get fixed at some point :P |
| 22:55 | <erlehmann> | gsnedders MAYBE I FIND A HARMFUL ONE :3 |
| 22:57 | <gsnedders> | erlehmann: I'm more disconcerted about the fact the default Python version there appears to be 2.6.6! |
| 22:58 | <erlehmann> | gsnedders what does that imply? |
| 22:58 | <zewt> | 2.6 dead long live 2.7 |
| 23:00 | <erlehmann> | OH LOL |
| 23:00 | <erlehmann> | gsnedders wait |
| 23:00 | <erlehmann> | this is funny |
| 23:00 | <erlehmann> | don't upgrade! |
| 23:01 | <gsnedders> | It's not my server! :P |
| 23:01 | <erlehmann> | gsnedders okay. |
| 23:01 | <erlehmann> | then you CANNOT :D |
| 23:01 | <zewt> | "hey this has python 2.6" "it's not mine, baby" |
| 23:01 | <erlehmann> | let me confirm some suspicion |
| 23:05 | <erlehmann> | gsnedders http://gsnedders.html5.org/outliner/process.py?url=http%3A%2F%2Fdaten.dieweltistgarnichtso.net%2Ftmp%2Fetc_passwd |
| 23:06 | <erlehmann> | ; curl -sI http://daten.dieweltistgarnichtso.net/tmp/etc_passwd | grep Location |
| 23:06 | <erlehmann> | Location: file:///etc/passwd |
| 23:06 | <erlehmann> | not my fault urllib2 is so bad! |
| 23:06 | <gsnedders> | oh ffs |
| 23:07 | <erlehmann> | this is probably like 1% of how homakov must feel every day! |
| 23:07 | <erlehmann> | :D |
| 23:08 | <erlehmann> | that reminds me of that one time i „audited“ (as in: inserted crap into) a friend's startup web site. i actually got bored of all the XSS. |
| 23:08 | <erlehmann> | gsnedders i wonder how to fix that, btw. |
| 23:09 | <erlehmann> | like, with still using urllib. |
| 23:09 | <Hixie> | (you also have to prevent http:// urls to your intranet) |
| 23:09 | <gsnedders> | Hixie: Bah, that's annevk's problem! His server! |
| 23:10 | <Hixie> | i jsut mean in general |
| 23:10 | <Hixie> | in other news, why is it that every time i want to do a multi-table select, i have to relearn joins from scratch |
| 23:10 | <gsnedders> | Did anything except Presto warn at redirects across network boundaries? |
| 23:11 | <Hixie> | you'd think it would eventually stick |
| 23:11 | <erlehmann> | „Hou also have to prevent http:// urls“ – Ian Hickson, CEO of HTML |
| 23:11 | <Hixie> | gsnedders: old IE did |
| 23:11 | Hixie | would be happy to be quoted saying that |
| 23:11 | <Hixie> | (https:// everywhere!) |
| 23:12 | <erlehmann> | hehe |
| 23:12 | <gsnedders> | Hixie: Just prod Xiven, that (was) my normal approach. :P |
| 23:12 | <erlehmann> | presto is dead |
| 23:12 | <erlehmann> | ;_; |
| 23:13 | <gsnedders> | Now can I get back to watching TV shows and not worrying about security bugs? |
| 23:13 | <gsnedders> | I'm not too worried, it's not like I have anything on there anyway ;) |
| 23:13 | <erlehmann> | dunno |
| 23:14 | <erlehmann> | TO THE MOON |
| 23:14 | <erlehmann> | i think that /etc/passwd trick could be funny |
| 23:15 | <gsnedders> | Yeah, totally. |
| 23:15 | <gsnedders> | But in this case not that useful unless it thinks it is in a section heading :P |
| 23:16 | <erlehmann> | i don't know |
| 23:16 | <erlehmann> | i once did do a timing attack on a home grown blog software that used „if input == password“ |
| 23:16 | <erlehmann> | i could measure it over a high latency umts connection |
| 23:16 | <erlehmann> | when having enough trials |
| 23:16 | <erlehmann> | (like, hundreds) |
| 23:17 | <erlehmann> | just let me think of something. |
| 23:17 | <gsnedders> | Is there any JS library anywhere for iterating over the whole document (or a subset thereof) in document order, even in old browsers with non-tree DOMs? |
| 23:19 | <Hixie> | gsnedders: you mean even in old IE, or do you really mean even in Netscape 4? |
| 23:19 | <Hixie> | or 3 or whatever predates the DOM but still had document.images etc |
| 23:19 | <zewt> | not like any system puts passwords in /etc/passwd, heh |
| 23:20 | <gsnedders> | Hixie: IE >= 6 mostly |
| 23:20 | <Hixie> | you can just walk the DOM in IE6 |
| 23:20 | <Hixie> | you just have to be careful to not do it via the nextSibling links et al |
| 23:20 | <gsnedders> | Just do it based on childNodes? |
| 23:21 | <Hixie> | something like that |
| 23:21 | <Hixie> | i have a script on hixie.ch that does it |
| 23:22 | <gsnedders> | If you can drop me a link to it (doesn't have to be now), would appreciate it |
| 23:22 | <Hixie> | http://hixie.ch/tests/adhoc/html/parsing/compat/viewer.html |
| 23:23 | <Hixie> | seems to be bitrotted |
| 23:23 | <Hixie> | maybe i'm thinking of something else |
| 23:23 | <Hixie> | anyway it's not too hard |
| 23:23 | <gsnedders> | if ((navigator.appVersion.indexOf("MSIE") != -1) && |
| 23:23 | <gsnedders> | (navigator.appVersion.indexOf("Mac") == -1)) { |
| 23:23 | <gsnedders> | // sweet mother of god *whimper* |
| 23:23 | <gsnedders> | :) |
| 23:24 | <erlehmann> | lel |
| 23:24 | <gsnedders> | Thankfully, I don't care about Tasman. |
| 23:24 | <gsnedders> | > badmouths Tasman |
| 23:24 | <gsnedders> | > tantek instantly leaves |
| 23:24 | <Hixie> | that's specifically not tasman |
| 23:25 | <erlehmann> | such cases |
| 23:25 | <erlehmann> | reminds me to read HTML5 Super Friends |
| 23:25 | <erlehmann> | i have not read it in a long time |
| 23:25 | <erlehmann> | but recently i started moving my MH folder to the maildir and the whatwg is cause of slow imap access! |
| 23:25 | <gsnedders> | Hixie: bah! |
| 23:25 | <gsnedders> | Hixie: Like I can read |
| 23:26 | <gsnedders> | Hixie: I'm suffering from what I'm calling "dissertation mush" :) |
| 23:30 | <TabAtkins> | Hixie: Here now. <input>s should work just fine with flexing. More details? |
| 23:31 | <Hixie> | TabAtkins: i couldn't get it to work. hold on, let me make a live-dom-viewer thing showing the problem |
| 23:31 | <TabAtkins> | kk |
| 23:32 | <Hixie> | well ok so it worked fine when trying to create a test just now -_- |
| 23:32 | <Hixie> | wtf |
| 23:33 | <TabAtkins> | Haha |
| 23:34 | <Hixie> | TabAtkins: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2898 is what i was trying to do. dunno what i was doing wrong before. |
| 23:34 | <Hixie> | does firefox do flex yet? maybe i was testing in a non-supporting browser? |
| 23:35 | <TabAtkins> | Yeah, it does. |
| 23:40 | <kbrosnan> | 28 for multi |
| 23:41 | <kbrosnan> | https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexible_boxes |
| 23:42 | <TabAtkins> | kbrosnan: Yeah, but Hixie's example doesn't use multi-line. |