| 00:23 | <jlebar> | Hixie, ping |
| 00:23 | <jonnybarnes> | say your page is in english, so has html lang=en at start, and your quoting some french, is there any way of marking that up in the document? |
| 00:24 | <Hixie> | jlebar: pong |
| 00:24 | <Hixie> | jonnybarnes: yes, put lang=fr around the bit that's french |
| 00:24 | <Hixie> | as in <blockquote lang=fr> say |
| 00:24 | <jlebar> | Hixie, I'm having difficulty keeping up with these changes: |
| 00:24 | <jonnybarnes> | ah cool, thanks Hixie |
| 00:25 | <jlebar> | Hixie, if I type http://google.com into my address bar, does Google get a popstate? |
| 00:25 | <jlebar> | Hixie, https://bugs.webkit.org/show_bug.cgi?id=41372 |
| 00:25 | jlebar | has re-read the relevant sections too many times now to make any sense of it. :) |
| 00:27 | <Hixie> | jlebar: search for "popstate" in the spec, it doesn't happen often :-) |
| 00:27 | <Hixie> | there are exactly two times popstate is fired |
| 00:27 | <Hixie> | 1. during history traversal, if the document readiness is already "complete" |
| 00:28 | <Hixie> | 2. after the browser stops parsing |
| 00:28 | <Hixie> | does that answer your question? |
| 00:30 | <jlebar> | Hixie, I think so, yes. Thanks. |
| 00:33 | <Hixie> | np |
| 00:40 | <jlebar> | Hixie, this seems to be a point of a lot of confusion. People see "traverse the history" and assume that it means "go back to a page that you've been to before." Perhaps you could clarify this. |
| 00:44 | <Hixie> | jlebar: any suggestion on how to do that? |
| 00:44 | <Hixie> | jlebar: i could rename the algorithm somehow |
| 00:44 | <Hixie> | jlebar: dunno what to rename it to, though |
| 00:45 | <Hixie> | jlebar: that you traverse the history in more cases than just going back is clear just from clicking the name of the algorith, which lists where it is mentioned (assuming you're using the single-page version of the spec) |
| 00:51 | <cardona507> | what args does lineTo() take? |
| 00:51 | <Hixie> | x,y |
| 00:52 | <cardona507> | cool - thnx Hixie |
| 00:53 | <cardona507> | darn FF is acting like IE |
| 00:54 | <jlebar> | cardona507, :( How? |
| 00:55 | <cardona507> | for some weird reason FF is not liking an AJAX call that I am doing to populate the jQuery graph plugin visualizer |
| 00:55 | <jlebar> | Hixie, you could add a note under 6.5.9 saying "This algorithm is triggered by: * navigating to a fragment identifier (always) * navigating across documents (sometimes)" or whatever. |
| 00:55 | <cardona507> | I am only joking about FF acting like IE |
| 00:55 | <cardona507> | nothing could be that bad :) |
| 00:55 | <jlebar> | ha. |
| 00:59 | <Hixie> | jlebar: i don't like doing that because when i change how the algorithm is invoked, i forget to update the note, and then things get out of sync, and people get even more confused |
| 01:00 | <MikeSmithX> | http://techcrunch.com/2010/08/24/motorola-snaps-up-280-north-for-20-million/ |
| 01:01 | <MikeSmithX> | good on them |
| 01:02 | <jlebar> | Hixie, Hm...that's fair. You could just be vague and say "Note: One need not traverse the history to an existing history entry. See e.g. #navigating-across-documents." |
| 01:07 | <jlebar> | Hm...that wording is pretty bad. |
| 01:07 | <jlebar> | Note: The UA can traverse the history to either an existing history entry or a new history entry. |
| 01:07 | <jlebar> | s/can/may |
| 01:08 | <Hixie> | jlebar: never use "may" in a note, "may" has normative meaning and notes are non-normative |
| 01:08 | <Hixie> | however, i've put in some text |
| 01:08 | <Hixie> | regenning now |
| 01:08 | <Hixie> | let me know what you think when it's up |
| 01:14 | <jlebar> | Hixie, Looks great to me. We'll see if it helps the WebKit devs figure things out. :) |
| 01:21 | <Hixie> | jlebar: :-) |
| 02:40 | <boblet> | hixie: re: bug 9743, the lack of examples meant it was unclear that four different styles were valid. The examples you added make it much clearer, thanks. |
| 02:41 | <boblet> | it would still be nice to link to 12.1.2.3, but I think it’s clear enough as it is |
| 02:42 | <boblet> | changing to resolved:fixed |
| 03:50 | <annevk5> | is there a known bug of some kind of the spec not defining what should be on the object versus what should be on the prototype chain? |
| 03:50 | <annevk5> | e.g. w(HTMLElement.prototype.title) gives wildly different results |
| 03:51 | <annevk5> | same for HTMLElement.prototype.onclick etc. |
| 03:51 | <annevk5> | actually, that one always returns undefined, but WebIDL suggests it shouldn't |
| 04:42 | <MikeSmith> | so I'm wanting to change the spam-management I've been using with my mail server .. what's the recommended solution for dealing with spam these days? |
| 04:42 | <MikeSmith> | I'm runnin Exim |
| 04:43 | <MikeSmith> | and have been using spamassassin and sa-exim |
| 04:48 | <wirepair> | forward it to gmail and let them worry about it |
| 04:48 | <wirepair> | s'what i do ;D |
| 04:50 | <MikeSmith> | heh |
| 04:51 | <MikeSmith> | yeah, I guess that's the easiest way |
| 04:51 | <wirepair> | seriously, my sh0dan.org domain has the mx forwarding to gmail ehe |
| 04:51 | <wirepair> | wow only 25,926 spams |
| 04:51 | <boblet> | but doing that would take all the masochism out of running your own mail server |
| 04:52 | <wirepair> | boblet, good point! |
| 04:52 | <wirepair> | then i suggest sendmail 8.10 with a perl script filtering emails by hand |
| 04:52 | <wirepair> | ;) |
| 04:52 | <boblet> | and that basically removes the reason for managing your own mail server, no? |
| 04:53 | <wirepair> | 'Would you like to accept this as spam? [y/n]: ' |
| 04:53 | <boblet> | wirepair: yeah, much more like it |
| 04:53 | <wirepair> | ehe |
| 04:55 | <MikeSmith> | I guess I should quit running my own web server also |
| 04:55 | <wirepair> | thanks MikeSmith, that actually reminded me to check my email |
| 04:55 | <wirepair> | and my first email says your domain will expire in 3 days |
| 04:56 | <MikeSmith> | heh |
| 04:56 | <wirepair> | so |
| 04:56 | wirepair | tips hat to MikeSmith |
| 05:07 | <MikeSmith> | rolandsteiner: hey |
| 05:07 | <MikeSmith> | have you guys all moved to a new office? |
| 05:17 | <volkmar> | Hixie: can you have a look at that: https://bugzilla.mozilla.org/show_bug.cgi?id=590363 ? |
| 06:09 | <MikeSmith> | wirepair: I also run my own name server |
| 06:13 | <micheil> | MikeSmith: if I heard rightly a few weeks back, some smart node.js developers are writing a node.js powered nameserver (yes, taking over the world by stealth almost) |
| 06:14 | <MikeSmith> | wow |
| 06:15 | <MikeSmith> | well, I guess that's sort to be expected |
| 06:15 | <MikeSmith> | a natural evolution |
| 06:15 | <MikeSmith> | like how CSS is eventually going to become Turing-complete |
| 06:16 | <MikeSmith> | man, I just did a massive upgrade of my Debian server to the latest testing |
| 06:16 | <MikeSmith> | after many months of having done no package updates at all |
| 06:16 | <MikeSmith> | maybe even a year or more |
| 06:17 | <MikeSmith> | and I had to manually deal with some package conflict problems |
| 06:17 | <MikeSmith> | but otherwise, I got everything upgraded |
| 06:17 | <MikeSmith> | and amazingly, everything actually seems to be working |
| 06:18 | <Ankheg> | it's so unusual for Debian? |
| 06:19 | <MikeSmith> | well, I had some conflicts before |
| 06:19 | <MikeSmith> | which is why I had held off on upgrading |
| 06:19 | <Hixie> | volkmar: what about it? |
| 06:20 | <MikeSmith> | Ankheg: upgrades were totally borking my mail delivery, among other things |
| 06:20 | <MikeSmith> | but I found that the main problem was spamassassin |
| 06:20 | <MikeSmith> | so I solved it by removing spamassassin |
| 06:20 | <MikeSmith> | now I need to find some other other way of dealing with spam |
| 06:20 | <Ankheg> | So much for the stable releases ) |
| 06:21 | <MikeSmith> | well, it's what I get for running the testing distro |
| 06:21 | <MikeSmith> | I guess |
| 06:21 | <MikeSmith> | anyway, it wasn't anything I couldn't deal with |
| 06:21 | <MikeSmith> | in the long run |
| 06:21 | <Ankheg> | that's the case, I presume |
| 06:21 | <MikeSmith> | just took me a while to get back to it |
| 06:22 | <Ankheg> | then I hope this update will be of without much trouble |
| 06:24 | <volkmar> | Hixie: do you think the spec should take into considering this behavior? |
| 06:24 | <Hixie> | volkmar: you mean the old firefox behaviour? |
| 06:25 | <volkmar> | the old firefox behavior and the current webkit/opera |
| 06:25 | <Hixie> | that behaviour was taken into account |
| 06:25 | <Hixie> | and considered silly :-) |
| 06:25 | <Hixie> | or inconsistent |
| 06:25 | <Hixie> | or some such |
| 06:26 | <Hixie> | this was stuff i studied quite carefully at the time |
| 06:26 | <volkmar> | ok, good to know it's kwown :) |
| 06:26 | <volkmar> | and do you have any idea how much that could break the web? |
| 06:27 | <volkmar> | ... or you are expecting us to test that :) |
| 06:27 | <Hixie> | i expect it won't break the web at all |
| 06:27 | <Hixie> | but i don't know off-hand |
| 06:27 | <Hixie> | iirc, IE didn't let you change the type at all dynamically |
| 06:27 | <Hixie> | so i doubt much content relies on it |
| 06:27 | <volkmar> | ok, fine |
| 06:35 | <rsteiner> | MikeSmith: hey! sorry for the late response (was having lunch) |
| 06:37 | <rsteiner> | MikeSmith: yep, new and shiny office! :D |
| 06:39 | <MikeSmith> | rsteiner: I will be stopping by there around 4pm |
| 06:39 | <MikeSmith> | today |
| 06:39 | <MikeSmith> | (to talk with Eiji Kitamura) |
| 06:40 | <MikeSmith> | rsteiner: btw, have you see the Mozilla bug about implementing CSS support for ruby? |
| 06:40 | <MikeSmith> | https://bugzilla.mozilla.org/show_bug.cgi?id=256274 |
| 06:41 | <MikeSmith> | hmm, I see that Anne has already commented there as well |
| 06:42 | <MikeSmith> | https://bugzilla.mozilla.org/show_bug.cgi?id=256274#c86 |
| 06:42 | <MikeSmith> | [[ |
| 06:42 | <MikeSmith> | So is Mozilla planning on supporting more of ruby than the other browsers? I.e. |
| 06:42 | <MikeSmith> | more than HTML5 requires? I am asking because comment 84 mentions various |
| 06:42 | <MikeSmith> | concepts not present in HTML5 or implementations of WebKit/Trident. |
| 06:42 | <MikeSmith> | ]] |
| 06:42 | <MikeSmith> | which seems like exactly the right question to be asking |
| 06:42 | <rsteiner> | MikeSmith: Interesting - let me catch up on that thread |
| 06:42 | <MikeSmith> | k |
| 06:43 | <MikeSmith> | roc is usually around on this channel, btw |
| 06:43 | <MikeSmith> | if you end up wanting to ask him for any clarification |
| 06:43 | <MikeSmith> | (Robert O'Callahan) |
| 07:05 | <rsteiner> | MikeSmith: interesting thread - confirms that complex ruby is a headache in implementation details... ;) |
| 07:07 | rsteiner | wonders if pointing out Mozilla is working on this will make WebKit folks more receptive to a complex ruby implementation |
| 08:05 | <annevk5> | in response to my own question earlier |
| 08:05 | <annevk5> | it seems WebIDL has this sentence |
| 08:05 | <annevk5> | "If a host object implements an interface, then for each attribute defined on the interface, there must be a corresponding property on the host object" |
| 08:06 | <annevk5> | which suggests properties are not on the prototype chain |
| 08:13 | <nessy> | hsivonen: great to see you back! |
| 08:14 | <hsivonen> | nessy: great to be back :-) (and caught up with email!) |
| 08:14 | <nessy> | congrats - that would have been hard work! |
| 08:17 | <nessy> | your question made me wonder if I should put the effort in to add a processing model to the WMML spec |
| 08:18 | <nessy> | what would you want to see in a processing model? Something like a DTD or XML schema? |
| 08:18 | <hsivonen> | nessy: neither of those! |
| 08:19 | <nessy> | I didn't think so ;-) but what are you after? |
| 08:19 | <hsivonen> | nessy: I think it makes sense to put effort into the processing model if you want to push the proposal despite the discussions we had at Whistler |
| 08:19 | <hsivonen> | nessy: if not, then not |
| 08:19 | <nessy> | the mapping to display it in an iframe-like construct? |
| 08:20 | <myakura> | Hixie: typo in http://whatwg.org/C#boolean-attribute . the example uses checked and disabled attributes but the text above says "The checked and readonly attributes..." |
| 08:20 | <nessy> | hsivonen: if nobody wants to implement a xml format, I am not going to push it |
| 08:20 | <hsivonen> | nessy: what I'd like to see is a detailed description of what parser what, how it integrates with the task queues, etc. |
| 08:20 | <nessy> | ah ok, that would be simple - mostly a copy of what WebSRT describes, I guess... |
| 08:21 | <hsivonen> | my point is that I don't expect it to be at all simple if done in sufficient detail |
| 08:21 | <nessy> | like this bit? http://www.whatwg.org/specs/web-apps/current-work/websrt.html#parsing |
| 08:22 | <hsivonen> | nessy: parsing isn't enough. also the task queue interaction of how stuff is displayed is needed, etc., etc. |
| 08:22 | <nessy> | hmm… I wonder if that is specified for WebSRT yet even |
| 08:22 | <nessy> | might be more useful to try doing that for WebSRT |
| 08:23 | <hsivonen> | nessy: it's less important to define it for WebSRT on that level of detail, because WebSRT reuses CSS in a limited way and doesn't import all possible HTML/DOM interactions with the task queue |
| 08:24 | <nessy> | hsivonen: unless we stick innerHTML into WebSRT, right? |
| 08:24 | <hsivonen> | nessy: the reason why my WebSRT with innerHTML cues is so simple is that it defines everything in terms of existing operations, so everything flows out of that |
| 08:24 | <nessy> | hsivonen: I don't understand - why would that be different for WMML? |
| 08:24 | <hsivonen> | nessy: if we stick innerHTML in WebSRT, the task queue interactions need to be answered |
| 08:25 | <hsivonen> | nessy: I already have proposed an answer, but foolip's second to last email to the thread suggests he might not like my answer... |
| 08:25 | <hsivonen> | nessy: you haven't defined how WMML works to the point I have defined how my WebSRT with innerHTML would work |
| 08:26 | <nessy> | hsivonen: probably because I don't know enough about that part to define it and just assumed that what you defined would work the same in WMML as in WebSRT |
| 08:26 | <nessy> | hsivonen: I could just basically copy your proposal then? |
| 08:27 | <hsivonen> | nessy: to do that, you'd have to define how you extract from WMML the string you assign to innerHTML |
| 08:27 | <hsivonen> | nessy: and as we already discussed, that step would suck more with a markup-like framing than with WebSRT-like framing of the strings |
| 08:28 | <nessy> | hsivonen: is that difficult or unclear? it's just what's in a <cue> element |
| 08:28 | <hsivonen> | nessy: you need to define "what's in the cue" element |
| 08:29 | <hsivonen> | nessy: does it work like "what's in the noscript element" or "what's in the div element" or in another way |
| 08:29 | <nessy> | hsivonen: as in: take the text and throw it into a <body> element of a iframe |
| 08:29 | <hsivonen> | nessy: I mean "take the text" needs defining |
| 08:30 | <nessy> | hsivonen: ok … |
| 08:30 | <hsivonen> | nessy: and I can't think of how to define it in a way that wouldn't be bad |
| 08:30 | <nessy> | hsivonen: what would be a bad way? (sorry if you have to repeat this from Whistler - I seem pretty clueless here but do want to understand) |
| 08:31 | <hsivonen> | bad way #1: Parse as XML, take .innerHTML. Bad because the whole document needs to be well-formed. Bad because the XML people would object to no end. |
| 08:32 | <hsivonen> | bad way #2: Define a custom parser that takes the text with whatever mechanism. Bad because such a custom parser would have to have a tokenizer that's of comparable complexity to the HTML tokenizer and it's not at all a good idea to have to develop another one of those. |
| 08:33 | <nessy> | yup, #1 was my thinking, but if XML people would object, then there is no reason to go with XML in the first place |
| 08:33 | <nessy> | so, I'm happy to just drop it (until somebody asks for a XML version again and then we can have this whole argument again) |
| 08:33 | <annevk5> | I really don't want XML for subtitles btw |
| 08:34 | <annevk5> | I'd object to no end, too |
| 08:34 | <nessy> | hehe :) |
| 08:34 | <nessy> | what are your reasons annevk5? |
| 08:34 | <annevk5> | XML failing was the whole reason we started HTML5 |
| 08:34 | <nessy> | ah, but XML failed for HTML - that doesn't mean XML failed for the whole industru |
| 08:35 | <nessy> | I don't like namespaces either and XSL-FO is just… why does it even exist? |
| 08:35 | <annevk5> | some people think XML is salvation |
| 08:35 | <annevk5> | so everything ought to be expressed in it |
| 08:35 | <nessy> | but XML is being used in a lot of places successfully to define exchange formats and re-use a well-defined parser |
| 08:36 | <annevk5> | XQueryX is probably the worst example of that |
| 08:36 | <hsivonen> | bad way #3: Use the HTML tokenizer with a custom tree builder that treats <cue> like <iframe>. Bad because the two-level parsing would be non-obvious (people are already confused by how the contents of iframe and noscript work). Bad because the appearance of the markup document as a whole suggests CSS selectors match on the whole tree when they'd actually match on a different tree. |
| 08:36 | <annevk5> | nessy, not really on the scale HTML is used |
| 08:36 | <nessy> | I am just developing a video application for somebody who has all their formats in XML and I have to use all the XML stuff including XSLT, XML schema etc - but it's actually helpful to some extent |
| 08:36 | <annevk5> | nessy, and most of those uses are generated and not hand edited |
| 08:37 | <Ms2ger> | ... unlike HTML and subtitles |
| 08:37 | <annevk5> | (if you're thinking of Atom / RSS) |
| 08:37 | <hsivonen> | bad way #4: Use the HTML tokenizer *and* a hacked HTML tree builder and get rid of the two-level parsing. Bad because you'd have to hack the tree builder not to implicitly generate the html and body elements. |
| 08:37 | <nessy> | no, no, subtitles will be a lot more generated in future |
| 08:37 | <hsivonen> | bad way #5: Rename wmml to html and cuelist to body, then use the HTML parser as a whole without the innerHTML step but instead clone the subtrees. Bad because of the CSS reason above. |
| 08:38 | <annevk5> | Ms2ger, I expect way more people to touch HTML (either directly or via templates) than they touch e.g. Atom |
| 08:38 | <Ms2ger> | Exactly |
| 08:38 | <annevk5> | nessy, "the future" is what people said about HTML too |
| 08:38 | <hsivonen> | I think those are pretty much the cases I recall discussing at Whistler. |
| 08:39 | <annevk5> | if we can prevent requiring tools to generate something as simple as subtitles (and we can) we should |
| 08:39 | <nessy> | I am actually not sure if there are more html pages on the planet than xml files - you don't know what's going on behind closed doors in companies |
| 08:39 | <nessy> | hsivonen: you have a fair number there! wow! |
| 08:40 | <annevk5> | closed systems using XML is not really a convincing argument imo |
| 08:40 | <annevk5> | of course closed systems will work fine |
| 08:40 | <annevk5> | they're easy to get right |
| 08:42 | <hsivonen> | having a lot of XML behind close doors isn't a particularly relevant point for the Web |
| 08:43 | <nessy> | annevk5: I was just making an argument about the number of documents in existence and therefore the importance of a format - I am by no means suggesting to move HTML to XML (we know that failed) |
| 08:44 | <nessy> | XML as an of itself is not a bad format just because it didn't work for HTML |
| 08:44 | <Ms2ger> | It's not really a fair comparison, though |
| 08:45 | <Ms2ger> | XML and HTML are on rather different levels |
| 08:46 | <nessy> | Ms2ger: I know - and thus I don't really see why a subtitle format should not be XML just because XML didn't work for HTML - but hsivonen obviously has a lot of arguments against a subtitle format that is meant to work with HTML, so that makes sense |
| 08:46 | <annevk5> | It is a bad format for formats that will be hand generated or with string concatenation, etc. as making errors is easy (and they slip in easily as e.g. Philip` has demonstrated lots of times). I expect subtitles to be much closer to HTML in this regard than to e.g. Atom. Especially if I look at the SRT files I often fetch when looking at a movie. |
| 08:48 | <nessy> | annevk5: this is an argument about enforcing strict parsing rather than about XML |
| 08:48 | <hsivonen> | the issues arising from Draconian failure and Namespaces apply to any prospective Web formats based on XML |
| 08:49 | <hsivonen> | nessy: strict parsing is a key part of the XML package |
| 08:49 | <annevk5> | nessy, strict parsing is intrinsic to XML |
| 08:49 | <nessy> | annevk5: foolip found a lot of SRT files that do not have empty lines as separaters between caption cues, which would not be conformant with WebSRT - would you want a WebSRT parser to accept that? |
| 08:49 | <annevk5> | nessy, until everyone does XML5 XML is just not a suitable format for any kind of language that web authors need to deploy |
| 08:50 | <hsivonen> | (it wouldn't have to be that way, but to change it, you'd need to take action against the wishes of the XML community--compare with your argument not to use SRT due to community concerns) |
| 08:50 | <Ms2ger> | Look, another thread about the HTML6 doctype! |
| 08:50 | <hsivonen> | Ms2ger: yeah, it's so sad |
| 08:50 | <nessy> | annevk5: I don't see strict parsing as inherently bad either - in fact, I am really annoyed that Firefox lets me get away with broken JavaScript, that then breaks other browsers - I do like to develop in Firefox... |
| 08:50 | <annevk5> | nessy, maybe it should; but that seems rather separate discussion |
| 08:51 | <hsivonen> | nessy: there's going to be the ES5 strict mode, but as I understand it, it hasn't been designed to be a stable equilibrium, so who knows how long it's going to last... |
| 08:52 | <annevk5> | nessy, JavaScript is somewhat resilient to authoring errors as well; e.g. it's per script element, per event handler attribute, etc. |
| 08:53 | <annevk5> | nessy, http://lists.w3.org/Archives/Public/www-tag/2008Dec/0132.html might of interest to you |
| 08:53 | <nessy> | hsivonen, annevk5: so, what I wanted with WMML was a XML format that doesn't have any of these restrictions - namespaces, XSL-FO, strict parsing - but that seems to be a bit ahead of the curve |
| 08:54 | <annevk5> | nessy, strict parsing and namespaces are intrinsic to XML; you do not just get rid of them |
| 08:54 | <annevk5> | nessy, unless you replace XML wholesale, as I proposed at some point |
| 08:55 | <nessy> | I want a different word for it then - it seems using the single word "XML" makes everyone go religious ;) |
| 08:55 | <hsivonen> | nessy: there's no point is using almost-XML, since you don't get the reuse benefits that are typically used to justify XML in the first place |
| 08:55 | <annevk5> | nessy, euh, didn't I give a bunch of arguments? it's a bit more than a belief |
| 08:56 | <nessy> | hsivonen: yes, that's correct - and I am not religious about it and I understand where you come from (mostly) |
| 08:56 | <hsivonen> | nessy: note that my list of bad solutions included solutions that didn't use an XML parser but would have parsed similar tags by other means |
| 08:57 | <nessy> | hsivonen: yeah, but mostly because you went from XML to HTML, which I don't see as a solution |
| 08:58 | <hsivonen> | nessy: bad way #2 used neither XML nor HTML parser |
| 08:59 | <nessy> | then WebSRT falls under bad way #2, too - I don't really accept #2 to be honest |
| 08:59 | <nessy> | but I accept that there are issues and I have accepted that nobody wants a XML based format |
| 09:00 | <hsivonen> | nessy: WebSRT does require a new parser for the container format, but the container doesn't have gratuitously XML/HTML-like complexity like attributes and character references |
| 09:01 | <annevk5> | or DOCTYPEs / <script> |
| 09:01 | <nessy> | hsivonen: it will get there once all the requirements are satisfied by WebSRT |
| 09:02 | <nessy> | it will hopefully stay simpler though, I agree |
| 09:02 | <hsivonen> | nessy: we can say "no" to any requirement that isn't about making the HTML5 feature set from before the supposed feature freeze accessible |
| 09:02 | <nessy> | hsivonen: did you see the requirements list of the a11y group? |
| 09:03 | <nessy> | http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements |
| 09:03 | <hsivonen> | nessy: if you ask any accessibility group for requirements, they'll require the kitchen sink, because this looks like the one opportunity to get more features since the introduction of U.S. TV captioning |
| 09:04 | <nessy> | hsivonen: wouldn't you in their situation? |
| 09:04 | <hsivonen> | nessy: maybe, though I would like to think I'd be able to show the kind of restraint I'd now like them to show |
| 09:05 | <nessy> | hsivonen: if you are a disabled user and have not had the possibilities that the Web allows you to have to make your life easier, wouldn't you want it all, too? |
| 09:05 | <nessy> | hsivonen: so, it's a matter or managing what is achievable now and what is important to meet without obstructing to meet further needs later |
| 09:06 | <nessy> | s/or/of/ |
| 09:06 | <annevk5> | note that adding a bunch of features does not necessarily improve the situation |
| 09:06 | <hsivonen> | nessy: well, let's put it this way: on the internationalization front, the people who are supposed to be advocating on my behalf in Working Groups claim that I need this and that to be able to write my mother tongue, but I don't really need all they claim I need |
| 09:06 | <annevk5> | e.g. longdesc was at some point added to the language also based on requirements, but it didn't work at all |
| 09:06 | <hsivonen> | nessy: I agree we should address true user needs, though |
| 09:08 | <nessy> | hsivonen: I think there are bare needs, things that are really important, and then there are things that are less important - and we just have to find a way to find out which is which and then manage to create a path to achieve the bare needs without obstructing the later introduction of the more fancy features |
| 09:09 | <nessy> | hsivonen: I say "just", but that is the really difficult part and it is particularly difficult because those that understand the needs don't know what is difficult and those that understand what is difficult don't understand the needs |
| 09:10 | <nessy> | but I'm sure we will get there :) |
| 09:13 | <salty-horse> | hey. why doesn't the first <article> get styled correctly? the border appears on the two <time> elements instead: http://pastehtml.com/view/1ar9mj2.html |
| 09:13 | <Ms2ger> | salty-horse, works for me, try article { display: block; } |
| 09:13 | <salty-horse> | articles aren't blocks by default? :/ |
| 09:14 | <Ms2ger> | Only in recent browsers |
| 09:15 | <salty-horse> | you're right. it works in firefox nightly |
| 09:15 | <salty-horse> | if it's not a block, the "bleeding" onto the "time" elements is correct? |
| 09:15 | <MikeSmith> | Hixie: (or anybody else who has insight into this) - |
| 09:15 | <MikeSmith> | I notice here - |
| 09:15 | <MikeSmith> | http://dev.w3.org/html5/spec-author-view/semantics.html#html-documents-16 |
| 09:15 | <MikeSmith> | "character encoding used must be an ASCII-compatible character encoding" |
| 09:16 | <MikeSmith> | does that mean that <meta charset=utf-16> is not conformant? |
| 09:16 | <MikeSmith> | because UTF-16 is not ascii-compatible, is it? |
| 09:17 | <salty-horse> | thanks Ms2ger |
| 09:17 | <MikeSmith> | I notice a related statement here: |
| 09:17 | <MikeSmith> | http://dev.w3.org/html5/spec-author-view/semantics.html#html-documents-15 |
| 09:17 | <MikeSmith> | prefaced with "If an HTML document does not start with a BOM..." |
| 09:18 | <MikeSmith> | which would seem to apply to the non-UTF-16 case |
| 09:18 | <MikeSmith> | but the other one is not qualified in any way |
| 09:19 | <hsivonen> | MikeSmith: yeah, <meta charset=utf-16> is non-conforming. (Very deliberately.) |
| 09:19 | <MikeSmith> | ok, thanks |
| 09:21 | <MikeSmith> | so at the risk of revealing my ignorance as usual, what is the reason for it being deliberately non-conforming? |
| 09:22 | <MikeSmith> | abarth|adoptPtr: XBL is the thing that's eventually going to save us all |
| 09:22 | <MikeSmith> | XBL2 at least |
| 09:22 | <abarth|adoptPtr> | oh yeah? |
| 09:22 | <abarth|adoptPtr> | currently it doesn't build and is full of memory errors |
| 09:22 | <MikeSmith> | well, I'm partly being facetious, but I don't mean the specific Webkit code |
| 09:22 | <abarth|adoptPtr> | :) |
| 09:23 | <abarth> | MikeSmith: what do you think this does / should do: |
| 09:23 | <abarth> | <div>&$footer;</div> |
| 09:23 | <abarth> | ? |
| 09:23 | <MikeSmith> | http://www.w3.org/TR/xbl/ |
| 09:23 | <MikeSmith> | abarth: it does something fun I hope |
| 09:24 | <abarth> | i'm toying around with the idea of letting authors define their own entities |
| 09:24 | <MikeSmith> | holy christ |
| 09:24 | <MikeSmith> | I hope you're joking |
| 09:24 | <abarth> | to avoid name conflicts, they'll need to start with $ |
| 09:24 | <MikeSmith> | you aren't... |
| 09:24 | <abarth> | :) |
| 09:24 | <MikeSmith> | oh man |
| 09:24 | <MikeSmith> | you are serious? |
| 09:24 | <abarth> | why did you fall out of your chair? |
| 09:25 | <annevk5> | where is that entity defined? |
| 09:25 | <MikeSmith> | abarth: it's one of those "now you have two problems" solutions |
| 09:25 | <MikeSmith> | [[ |
| 09:25 | <abarth> | https://docs.google.com/document/edit?id=1Uye7FCE7sIouru_9ayiyYRDP_ibjY6ZcOeImWH1pFrE&hl=en&authkey=CLO4uYIN |
| 09:26 | <abarth> | is the doc i'm writing about it |
| 09:26 | <MikeSmith> | [[ |
| 09:26 | <MikeSmith> | [[ |
| 09:26 | <MikeSmith> | The XML Binding Language (XBL) describes the ability to associate elements in a document with script, event handlers, CSS, and more complex content models, which can be stored in another document. This can be used to re-order and wrap content so that, for instance, simple HTML or XHTML markup can have complex CSS styles applied without requiring that the markup be polluted with multiple semantically neutral div elements. |
| 09:26 | <MikeSmith> | ]] |
| 09:26 | <MikeSmith> | abarth: (for the record, about XBL2 ↑) |
| 09:26 | <abarth> | annevk5: you define them with a JS API call |
| 09:26 | <abarth> | you pass in a JSON object |
| 09:27 | <abarth> | i haven't written that part of the doc yet |
| 09:27 | MikeSmith | reads abarth "Custom HTML Entities" doc |
| 09:27 | <abarth> | it's only half written |
| 09:28 | <MikeSmith> | stop typing |
| 09:28 | <MikeSmith> | " kind of goofy and invites injection." |
| 09:28 | <abarth> | :) |
| 09:28 | <MikeSmith> | :) |
| 09:28 | <annevk5> | why not just use <iframe srcdoc> ? |
| 09:29 | <abarth> | can you put an iframe srcdoc in an attribute? |
| 09:29 | <abarth> | also, that's huge overkill to display someone's name |
| 09:30 | <annevk5> | no and fair enough |
| 09:32 | <abarth> | <link rel="entities" href="entites.json"> seems better than the script API |
| 09:36 | <jgraham> | abarth: Please, no :) |
| 09:36 | <abarth> | annevk5: also, <firame srcdoc> is rectangular. you might want the text to flow around a float, for example |
| 09:36 | <abarth> | jgraham: i think we want some kind of templating system |
| 09:36 | <abarth> | jgraham: so folks don't have to worry too much about escaping |
| 09:37 | <abarth> | to prevent XSS |
| 09:37 | <abarth> | i'm certainly open to other ideas. this was the simplest thing i could think of |
| 09:38 | <hsivonen> | MikeSmith: the reason is that it never has an effect, so using it is always a sign of deep author confusion of how stuff works |
| 09:39 | <hsivonen> | MikeSmith: umm. actually, it's worse than that. Sometimes it has an effect but a non-obvious effect (says UTF-16 but means UTF-8). |
| 09:40 | <jgraham> | abarth: It seems pretty complex one you take DOM into account. And the fallback isn't exacly wonderful |
| 09:40 | <abarth> | jgraham: what do you mean by taking DOM into account? |
| 09:41 | <abarth> | yeah, i need to experiment with what sort of fallback options exist |
| 09:41 | <jgraham> | abarth: Well presumably you need to be able to inject an entity through the DOM somehow |
| 09:41 | <abarth> | and entity definition? |
| 09:41 | <hsivonen> | abarth: your entity proposal scares me |
| 09:41 | <abarth> | or an entity itself? |
| 09:41 | <jgraham> | abarth: Both a new definition and a reference to an existing entity |
| 09:41 | <abarth> | elmt.innerHTML = "Hi there &$name;" |
| 09:42 | <jgraham> | sure innerHTML works |
| 09:42 | <jgraham> | But if you don;t use that? |
| 09:42 | <jgraham> | Also, you have to block load on the entity <link> |
| 09:42 | <abarth> | document.decodeEntity("$name") |
| 09:42 | <annevk5> | why make it more complicated than innerHTML? |
| 09:42 | <jgraham> | so what happens if you want to load a new entity definition file and use it |
| 09:43 | <MikeSmith> | hsivonen: OK |
| 09:43 | <abarth> | yeah, there's a basic tension of wanting to put the untrusted content in a different resource |
| 09:44 | <abarth> | and needing two network requests to render your document |
| 09:44 | <hsivonen> | the untrusted content could be put in a data: URL! :-) |
| 09:44 | <abarth> | if you like |
| 09:44 | <abarth> | i wouldn't recommend it |
| 09:45 | <hsivonen> | (I wouldn't, either.) |
| 09:45 | <abarth> | another option, and this might be crazy, |
| 09:45 | <jgraham> | I wonder if the two resource thing would be enough to stop people actually using this |
| 09:45 | <abarth> | :) |
| 09:45 | <jgraham> | I mean Facebook or whoever |
| 09:45 | <abarth> | is that you could define the parsing so that the entities always got their own text nodes |
| 09:45 | <abarth> | and as long as you didn't mutate them |
| 09:45 | <abarth> | they'd be "live" |
| 09:45 | <abarth> | so when you later encountered an entity |
| 09:45 | <abarth> | it would magically fill in those text nodes |
| 09:46 | <abarth> | i'm not sure that's a great idea |
| 09:46 | <abarth> | but it's a way to make the system lazy instead of synchronous |
| 09:46 | <abarth> | in the implementation, you'd keep some sort of hashmap |
| 09:46 | <abarth> | to find them |
| 09:48 | <hsivonen> | this morning, I was thinking of arguing for the definite WONTFIXing of the request to support XML external entities in Gecko on the grounds that the combination of the expat API and off-the-main-thread parsing would make it suck even more from impl. POV |
| 09:48 | <hsivonen> | but then I thought there was no point in poking that bug when it's quiet |
| 09:48 | <abarth> | jgraham: Facebook will always roll their own whatever |
| 09:49 | <abarth> | jgraham: we should be targeting the mid-level authors |
| 09:49 | <hsivonen> | (I intend to put non-chrome XML parsing off the main thread in Gecko when schedule permits) |
| 09:49 | <abarth> | we should try that with webkit |
| 09:49 | <abarth> | (html parsing that is) |
| 09:50 | <abarth> | i worry the context switches are expensive |
| 09:50 | <abarth> | but preload scanning definitely should not be on teh main thread :) |
| 09:52 | <MikeSmith> | hsivonen: so the proper way to declare the encoding for a UTF-16 text/html document is just by use of the BOM? |
| 09:52 | <hsivonen> | MikeSmith: yes |
| 09:52 | <MikeSmith> | ok |
| 09:55 | <myakura> | "i think we want some kind of templating system" here comes XInclude! |
| 09:55 | myakura | hides |
| 09:56 | <abarth> | XInclude? /me googles |
| 09:57 | <abarth> | myakura: yeah, i considered a similar design |
| 09:57 | <abarth> | that one seems to make a network request for each variable in the template though |
| 09:57 | <abarth> | it seems more suited for processing on the server |
| 09:57 | <abarth> | where fetching the resource is fast |
| 09:58 | <abarth> | of course, you can fix that by putting all the values in a single resource and then using an element to go get them |
| 09:58 | <abarth> | but you still can't use it in attribute values |
| 09:58 | <abarth> | <img alt="&$name;'s Profile Picture" src="..."> |
| 09:59 | <annevk5> | shouldn't the server languages deal with this? |
| 09:59 | <abarth> | they try, but they suck |
| 09:59 | <annevk5> | like echo_html_string(name) |
| 10:00 | <abarth> | the problem is that different contexts need different escaping rules |
| 10:00 | <abarth> | for example htmlspecialchars isn't always safe |
| 10:01 | <annevk5> | interesting |
| 10:01 | <abarth> | <img alt=<?php= htmlspecialchars($name) ?> src="..."> |
| 10:01 | <abarth> | => XSS |
| 10:01 | <abarth> | <img alt=&$name; src="..."> |
| 10:01 | <abarth> | => safe |
| 10:02 | <hsivonen> | I have this problem solved for the UI of validator.nu, but apparently other people aren't so interested in designing the architecture of their UI generation around this constraint |
| 10:02 | <annevk5> | abarth, oh like that |
| 10:02 | <annevk5> | yeah that's silly |
| 10:02 | <annevk5> | I wonder if people generating HTML like that can handle the additional level of abstraction |
| 10:03 | <annevk5> | because if they can't this won't help them |
| 10:03 | <hsivonen> | abarth: is http://trac.webkit.org/export/LATEST/trunk/LayoutTests/fast/tokenizer/write-on-load.html the only test case on the onload topic? |
| 10:03 | <abarth> | hsivonen: that's the main one. i think there might be some other variations |
| 10:03 | <abarth> | annevk5: yeah, it needs to be very easy to use |
| 10:04 | MikeSmith | notices the XPointer-in-Webkit bug is still alive - https://bugs.webkit.org/show_bug.cgi?id=17491 - comment added today |
| 10:04 | <hsivonen> | I guess I'll need to edit that one to make doubleWrite generate "external" scripts instead of inline scripts in order to form my opinion |
| 10:04 | <MikeSmith> | annevk5: do you guys get requests for XPointer support in Opera? |
| 10:04 | <annevk5> | abarth, having the data be in a separate file seems like too much complexity to me |
| 10:04 | <abarth> | annevk5: you could imagine a PHP function that registered all the keys in some collection |
| 10:04 | <abarth> | and then you could just use the names in that collection without having to jump back into php |
| 10:05 | <annevk5> | MikeSmith, dunno |
| 10:06 | <MikeSmith> | hsivonen: you were referring to the PageEmitter stuff in the v.nu code? |
| 10:06 | <abarth> | annevk5: yeah, having some way of registering the template values inline seems like it would be valuable |
| 10:06 | <abarth> | maybe require them to be base64 encoded? |
| 10:07 | <abarth> | document.registerEntities("dksflasjdfoifoenaoenae+asvesvesv=") |
| 10:07 | <annevk5> | MikeSmith, doesn't seem like it |
| 10:07 | <hsivonen> | MikeSmith: yeah |
| 10:07 | <abarth> | where's that's that base64 of a JSON blob |
| 10:10 | <annevk5> | it seems like too complex for authors to use |
| 10:10 | <annevk5> | they would just echo the string instead |
| 10:10 | <annevk5> | that's also better supported |
| 10:10 | <annevk5> | and if they did think about XSS, they would likely fix their bugs (e.g. add quotes) rather than make it complicated |
| 10:11 | <hsivonen> | http://hsivonen.iki.fi/test/write-on-load.html doesn't look so nice... |
| 10:11 | <abarth> | annevk5: yeah, providing a nice fallback in non-supporting browsers is important |
| 10:12 | <hsivonen> | http://hsivonen.iki.fi/test/write-on-load.html shows different results in old Gecko and in Safari |
| 10:12 | <abarth> | base64_encode(json_encode($TemplateValues)) |
| 10:12 | <abarth> | isn't that hard |
| 10:12 | <MikeSmith> | anybody have recommendations for an XMPP server (that is, server daemon to run for providing XMPP services) |
| 10:13 | <abarth> | where $TemplateValues is a PHP associative array of the template values |
| 10:13 | <annevk5> | abarth, but usually it's something like echo htmlspecialchars($_POST["name"]) |
| 10:14 | <abarth> | right, so that becomes$TemplateValues["name"] = $_POST["name"] |
| 10:15 | <abarth> | echo "&$name;" |
| 10:15 | <abarth> | ... |
| 10:15 | <annevk5> | i.e. no need for script to register entities, no need for a fallback script |
| 10:15 | <abarth> | yep |
| 10:15 | <annevk5> | $TemplateValues is something magic? |
| 10:15 | <abarth> | nope, but you can just collect up all the values and register them at some point |
| 10:17 | <abarth> | there's another design point |
| 10:17 | <abarth> | in which you don't register the templates at all |
| 10:17 | <abarth> | but you have a syntax for a self-decoding entity |
| 10:17 | <abarth> | &%domicm30j30w0hfw0fh; |
| 10:17 | <abarth> | where that just base64 decodes itself |
| 10:17 | <annevk5> | that seems far more reasonable |
| 10:18 | <annevk5> | tbh |
| 10:18 | <annevk5> | s/tbh// |
| 10:18 | annevk5 | was honest before too :) |
| 10:19 | <abarth> | i appreciate honesty |
| 10:19 | <abarth> | both positive and negative feedback is helpful |
| 10:19 | <annevk5> | switching from base64_encode() to htmlspecialchars() is something I can see authors doing |
| 10:20 | <abarth> | the fallback story isn't great |
| 10:20 | <abarth> | unless you do something like UA sniff |
| 10:21 | <annevk5> | you can go through the DOM and fix test nodes that contain &% |
| 10:21 | <abarth> | that's true |
| 10:22 | <annevk5> | would be a rather trivial library |
| 10:22 | <abarth> | this proposal is also trivial to implement in a UA |
| 10:22 | <annevk5> | &% you mean? |
| 10:22 | <abarth> | yeah |
| 10:23 | <annevk5> | it seems like the simplest thing that could work addressing the stated problem |
| 10:23 | <hsivonen> | abarth: is it a goal to make the same syntax work in XHTML5? |
| 10:23 | <abarth> | i don't care about XHTML |
| 10:23 | <abarth> | if it's easy, then i'd be up for it |
| 10:23 | <annevk5> | if you are using XML you cannot use string concat anyway |
| 10:23 | <annevk5> | as an author that is |
| 10:23 | <annevk5> | so the XSS issues are not the same |
| 10:24 | <abarth> | plus, XML has XSLT |
| 10:24 | <hsivonen> | annevk5: for some definition of "cannot" |
| 10:24 | <annevk5> | hsivonen, simplifying, yes |
| 10:25 | <annevk5> | I realize Sam Ruby can, though Philip` found a bug there too :) |
| 10:27 | <abarth> | ok, thanks for all your help |
| 10:27 | <abarth> | i think it's time for me to sleep on it |
| 10:28 | MikeSmith | install prosody |
| 10:47 | <hsivonen> | Opera 10.50 alpha after self-updating but not to 10.60.something beachballs on http://hsivonen.iki.fi/test/write-on-load.html |
| 10:50 | <hsivonen> | kinda sad that the first-run page in Opera 10.61 shows a youtube video *in Flash* |
| 10:51 | <hsivonen> | (as opposed to WebM) |
| 10:51 | <hasather> | hsivonen: it's not really supposed to, I think there was some issue with the Mac version (if you're using that) |
| 10:52 | <hsivonen> | hasather: Mac, yes |
| 10:53 | <hasather> | hsivonen: is the issue with http://hsivonen.iki.fi/test/write-on-load.html filed, or should I do it? |
| 10:53 | <hsivonen> | hasather: not filed, so it's ok to file |
| 10:54 | <hsivonen> | hasather: except it doesn't beachball in 10.61 anymore |
| 10:55 | <hasather> | hsivonen: ah |
| 10:56 | jgraham | wonders if it is a truth universially acknowledged that anyone who posts "This is my last email to this list" will inevitably continue to send email to that list |
| 11:52 | <annevk5> | vertical layout is gonna be such a pain |
| 11:52 | <annevk5> | and full of crashers |
| 11:52 | <annevk5> | and perf ... ah well |
| 11:53 | <Rik`> | vertical layout ? |
| 11:53 | <annevk5> | job security |
| 11:53 | <annevk5> | ;p |
| 11:53 | <annevk5> | Rik`, vertical text et al |
| 11:54 | <MikeSmith> | heh |
| 11:54 | <MikeSmith> | (job security) |
| 11:55 | <TabAtkins_> | Lachy: Yo, I owe you dinner tonight. |
| 11:57 | <Lachy> | ok |
| 11:59 | <hsivonen> | https://twitter.com/glazou/status/21942648163 seriously? |
| 12:03 | <hsivonen> | does anyone happen to have correct data about which browsers support <meta http-equiv="pragma" value="no-cache">? |
| 12:05 | <TabAtkins_> | hsivonen: Yes. Seriously. |
| 12:06 | <TabAtkins_> | It was after some drinks, but still. |
| 12:09 | <hsivonen> | TabAtkins_: :-( |
| 12:09 | <hsivonen> | TabAtkins_: what will we be using instead? |
| 12:10 | <annevk5> | nothing to get upset about really |
| 12:10 | <annevk5> | Bert Bos just has a different world view |
| 12:12 | <hsivonen> | hmm http://support.apple.com/kb/HT1222 is blank. I wonder what the latest securit update is about |
| 12:13 | <MikeSmith> | I hope it's about making the macports boost build faster |
| 12:14 | <Rik`> | hsivonen: http://support.apple.com/kb/HT4312 |
| 12:14 | <hsivonen> | Rik`: thanks |
| 12:14 | <MikeSmith> | because I am trying to installed boost now and it's taking forever |
| 12:15 | <Rik`> | it seems there is the same PDF fix as iOS |
| 12:15 | hsivonen | wonders if OS X 10.4.x has the same hole... |
| 12:16 | <TabAtkins_> | hsivonen: Yeah, bert just lives in a different world. |
| 12:16 | <Philip`> | MikeSmith: Sounds like you don't want to be using a system where all development library packages have to be compiled from source |
| 12:16 | <Philip`> | MikeSmith: You should try Windows, or Ubuntu |
| 12:16 | <hsivonen> | I'm just curious what people use instead of browsers in that world |
| 12:17 | <hsivonen> | hmm. my OS X session has gone crazy in such a way that it no longer reads new hi-res icons |
| 12:17 | <MikeSmith> | Philip`: I like this system well enough, it just need to response better when I press the "Compile faster" button a bunch of times |
| 12:17 | <hsivonen> | all newly launched apps have fuzzy icons in cmd-tab |
| 12:19 | <MikeSmith> | hsivonen: a mystery of that world is revealed in http://twitter.com/glazou/status/21942696879 |
| 12:19 | <MikeSmith> | dunno how you missed that one |
| 12:20 | <hsivonen> | MikeSmith: by working instead of reading every tweet. thanks. |
| 12:20 | <MikeSmith> | heh |
| 12:20 | <MikeSmith> | that's the problem with working |
| 12:20 | MikeSmith | kicks working |
| 12:21 | <MikeSmith> | maybe the "Compile faster" button on my keyboard is broken or something |
| 12:23 | <jgraham> | Dear lazy irc: I have a directory full of files checked into SVN. I would like to produce a diff containing all the contents of all the files that are actually in SVN i.e. what you might have thought that svn diff -r revision_before_directory_was_created:HEAD would produce |
| 12:23 | <jgraham> | Needless to say this does not actually work because svn is lame |
| 12:24 | <jgraham> | Is there any way to do this that will not cause me to want to stab my own eyes out |
| 12:24 | <jgraham> | (hint: having to write a script to do this will cause me to want to stab my own eyes out) |
| 12:24 | <jcranmer> | generate a list of all files, exclude those not found in the svn repository, and then concatenate those? |
| 12:26 | <jgraham> | jcranmer: That sounds plausible, if I can make diff get the base path right for files in subdirectories |
| 12:27 | <jgraham> | It also sounds like I need to write a script |
| 12:27 | <jgraham> | Which I was trying to avoid |
| 12:27 | <jcranmer> | if you want a diff of the new files |
| 12:27 | <jcranmer> | well |
| 12:27 | <jcranmer> | why not clone the svn into a new directory, say /tmp/svnsucks |
| 12:27 | <jcranmer> | and then make the diff from that ? |
| 12:29 | <jgraham> | You mean checkout into a new directory? |
| 12:29 | <jcranmer> | yes |
| 12:33 | <Philip`> | mkdir /tmp/empty; diff -rN /tmp/empty . |
| 12:33 | <Philip`> | perhaps? |
| 12:33 | <Philip`> | after doing an svn export to get a clean copy of the files without .svn directories |
| 12:33 | <Rik`> | jgraham: you're diff will only have + lines, no ? |
| 12:35 | <annevk5> | hmm |
| 12:38 | <jgraham> | Rik`: Yes |
| 12:39 | <jgraham> | Philip`: Something like that seems like it is mostly good enough |
| 12:39 | <Rik`> | can't you use the standard diff between your directory and an empty one ? |
| 12:40 | <jgraham> | Rik`: That seems to be the approach that I am taking (see e.g. what Philip` wrote above) |
| 12:40 | <Rik`> | oh yeah, sorry :) |
| 13:24 | <hsivonen> | WebKit's HTMLElement::deprecatedCreateContextualFragment is interesting |
| 13:25 | <hsivonen> | doesn't HTML5 allow innerHTML to be set on any HTML element? |
| 13:33 | <hsivonen> | is the HTML5 parser supposed to be in the Chrome dev channel? |
| 13:34 | <Peter`> | The tokenizer is/was, tree builder seems to be in nightlies |
| 13:35 | <hsivonen> | nightlies != dev channel? |
| 13:36 | <hsivonen> | does anyone happen to know if Outlook Web Access works in WebKit-based browsers? |
| 13:37 | <Peter`> | No, dev channel are weekly, human-tested builds |
| 13:37 | <Peter`> | Google Canary is more like nighlies, updates several times a week but won't be tested by humans |
| 13:37 | <hsivonen> | Peter`: oh. how do I get a real nigthly update channel? |
| 13:37 | <Peter`> | though is branded as well. Real nightlies are Chromium, there's no auto-updater for that |
| 13:38 | <hsivonen> | that's inconvenient |
| 13:39 | <hsivonen> | so WebKit nightlies seem to have the HTML5 tree builder for document.open/write |
| 13:39 | <hsivonen> | but do WebKit nightlies use it for createContextualFragment or innerHTML, yet? |
| 13:40 | <Peter`> | abarth and eseidel are progressively removing the old parser |
| 13:40 | <Peter`> | for the tree builder I think it's likely, but am not sure |
| 13:44 | <hsivonen> | abarth|zZz: when createContextualFragment is called in WebKit with html as the context node, does WebKit behave as if the context node had been body accidentally or intentionally? |
| 13:45 | <hsivonen> | can anyone from Opera disclose whether Opera considers it a bug that createContextualFragment with html as the context doesn't behave as if the context had been body instead? |
| 13:45 | jgraham | wonders how up to date the ubuntu PPA for chromium is |
| 13:46 | <hsivonen> | that is, in Opera, the body element (but not head!) is implicitly created |
| 13:47 | <hsivonen> | I'm pretty sure that the original Gecko behavior was an accident |
| 13:47 | <hsivonen> | (behaving as if the context had been body when it is html) |
| 13:48 | <hsivonen> | but now I can't tell if WebKit had the same accident or carefully cloned that quirk on purpose |
| 13:48 | <hsivonen> | and whether Opera is aware of imprecise cloning and whether that's considered a bug or not |
| 13:49 | <hsivonen> | (I'm trying to figure out if the quirk should go away in Gecko or if it should become a permanent part of "correct" createContextualFragment behavior) |
| 13:49 | <hsivonen> | Does Outlook Web Access work in Opera? |
| 13:50 | <hsivonen> | looks like IE9 PP doesn't have DOM Ranges |
| 14:14 | <jgraham> | hsivonen: No idea |
| 14:14 | <hsivonen> | jgraham: ok |
| 14:19 | hsivonen | wonders if http://html5.org/tools/web-apps-tracker?from=5296&to=5297 is stable |
| 14:19 | <hsivonen> | or if this stuff is gonna change tomorrow again |
| 14:28 | <hsivonen> | What's the rev that fixed http://www.w3.org/Bugs/Public/show_bug.cgi?id=8966? |
| 14:29 | hsivonen | sees http://html5.org/tools/web-apps-tracker?from=5299&to=5300 |
| 14:30 | <jorlow> | any webIDL experts here? |
| 14:31 | <jorlow> | I have an interface that has methods that I want to be accessible from the interface object |
| 14:31 | <jorlow> | but I can't figure out how to spec such a thing |
| 14:36 | <jgraham> | jorlow: Like MyInterfaceObject.foo() |
| 14:36 | <jgraham> | ? |
| 14:36 | <jorlow> | yes |
| 14:37 | <jgraham> | Hmm |
| 14:37 | <jgraham> | I can look of course |
| 14:37 | <jgraham> | But I don't know |
| 14:37 | <jorlow> | do you know where to look? |
| 14:37 | <jorlow> | i've spent some time trying to understand what the WebIDL spec has to say on the matter |
| 14:37 | <jorlow> | but have gotten no where |
| 14:39 | <jgraham> | Not really, I find WebIDL pretty impeneterable |
| 14:40 | <cheeser> | what is webidl for? i can't get corba out of my head when i see that |
| 14:40 | <jorlow> | glad i'm not the only one :-) |
| 14:43 | <hsivonen> | cheeser: it's supposed to be a nice shorthand for saying which ones of the many JS API behavior patterns are required for a given API |
| 14:44 | <cheeser> | oh... ugh. |
| 14:45 | <cheeser> | so basically it allows an api to define which js spec version it supports? |
| 14:45 | <cheeser> | or do you mean it can speciy things like jquery or prototype? |
| 14:45 | <jgraham> | cheeser: No, it is just a convenient way of saying how host objects map to js |
| 14:45 | <cheeser> | oh, i see. |
| 14:45 | <cheeser> | like the idl of old :) |
| 14:45 | <jgraham> | Just like that |
| 14:46 | <jgraham> | But more "web" |
| 14:46 | <cheeser> | i just died a little inside ;) |
| 14:46 | <hsivonen> | cheeser: it's for saying stuff like whether a given argument behaves as "", "null" or null if you pass something that's null-ish |
| 14:46 | cheeser | nods. |
| 14:46 | <jgraham> | Where "web" in this case is a shorthand for "having a bunch of confusing special cases that no sane person would ever design" |
| 14:47 | <jgraham> | jorlow: I don't see any way to do what you are trying to do |
| 14:47 | <jorlow> | jgraham: thanks for looking |
| 14:47 | <jgraham> | Nor can I think of any precedent in DOM |
| 14:47 | <jorlow> | me neither |
| 14:48 | <jgraham> | So maybe you should want to do something different :) |
| 14:48 | <jorlow> | agreed |
| 14:48 | <jorlow> | in case you're wondering, the reason I'm asking is this: http://www.w3.org/TR/IndexedDB/#idl-def-IDBKeyRange |
| 14:49 | <jorlow> | as specced, the methods at the end can't be used |
| 14:51 | <kkaefer> | is this a place to ask canvas questions? |
| 14:53 | <jgraham> | kkaefer: Possibly |
| 14:53 | <kkaefer> | heh, okay :) |
| 14:53 | <kkaefer> | has anyone figured out a way to inverse the clip() mask? |
| 14:53 | <kkaefer> | i.e. so that the contents /outside/ of the mask are drawn but not the one within the clip() path? |
| 14:55 | <kkaefer> | I know that drawing it on a separate canvas, then using destination-out and copying over the result is an option too |
| 14:55 | <kkaefer> | but I don't want to create separate canvases all the time |
| 14:57 | <Philip`> | kkaefer: You could try to invert the area contained within the path |
| 14:57 | <Philip`> | like have a clockwise shape then add a large anticlockwise square around it, so that the region between the two shapes is the inside |
| 14:59 | <kkaefer> | ah, interesting idea |
| 14:59 | <kkaefer> | let me try that |
| 15:00 | <kkaefer> | yeah, that seems to work |
| 15:01 | <kkaefer> | so I only have to have the dimensions of the anticlockwise shape outside of the canvas |
| 15:01 | <kkaefer> | so that when I stroke, the stroke doesn't appear inside the canvas |
| 15:01 | <kkaefer> | Philip`: thanks |
| 15:35 | <hsivonen> | hrm. twitter's widget JS supports transitions only with the -webkit- prefix. :-( |
| 15:36 | <Rik`> | hsivonen: hopefully, it's hosted on their servers, so fixable |
| 15:38 | <Rik`> | hsivonen: hmm, what widget JS do you mean ? |
| 15:38 | <hsivonen> | http://widgets.twimg.com/j/2/widget.js |
| 15:40 | <Rik`> | where is it used? |
| 15:40 | <kkaefer> | Philip`: hm, while the anticlockwise shape is interesting, it doesn't work in all cases; e.g. when using drop shadows, the drop shadows are inverted to |
| 15:40 | <kkaefer> | my goal is to draw "knockout" dropshadows |
| 15:41 | <kkaefer> | e.g. when you have a transparent shape, you don't want to have the shadow behind the shape, just around it |
| 15:41 | <kkaefer> | so I'm trying to just draw the shadow, minus the shape |
| 15:43 | <kkaefer> | http://i.kkaefer.com/canvas-20100825-174900.png |
| 15:46 | <hsivonen> | Rik`: seen at http://uglyducklinghouse.blogspot.com/ |
| 15:46 | <kkaefer> | problem is when I set the fill color to transparent, it doesn't draw a dropshadow either |
| 15:50 | <Philip`> | kkaefer: Can you draw the anticlockwise+shape path, call clip(), then beginPath() and draw the original path and fill() with shadows? |
| 15:54 | <kkaefer> | Philip`: whoa, that did the trick |
| 15:54 | <kkaefer> | thanks |
| 16:06 | <kkaefer> | however, it doesn't seem to properly reset when calling beginPath() after that |
| 16:06 | <kkaefer> | .save()/.restore() helps, though |
| 16:11 | <kkaefer> | dang, it draws the shadow twice :/ |
| 16:12 | <cheeser> | 1 |
| 16:59 | <TabAtkins_> | Lachy: You around? We're adjourned. |
| 16:59 | <Lachy> | TabAtkins_, yes |
| 17:00 | <TabAtkins_> | You wanna come down to the meeting room? |
| 17:00 | <Lachy> | Are you in Zap? |
| 17:01 | <Lachy> | or other meeting room? |
| 17:01 | <TabAtkins_> | mezzo |
| 17:01 | <Lachy> | ok, be there in a sec |
| 17:14 | <abarth|zZz> | hsivonen: you still there? |
| 19:04 | <Hixie> | othermaciej: http://www.w3.org/mid/20100825200142793866.be0be8e7⊙xn is another report on the ease of use of the rel registry, effectively |
| 19:05 | <AryehGregor> | I get an error message. |
| 19:07 | <Hixie> | ok i finally got a reply from microsoft |
| 19:07 | <Hixie> | they intend to completely violate HTTP and just completely ignore the MIME type for <video> |
| 19:07 | <Hixie> | so i guess we know where they stand on standards compliance |
| 19:08 | <theMadness> | I'm only 27, I shouldn't be so jaded, but i kinda expected it. |
| 19:08 | <AryehGregor> | Isn't that what everyone does for images already, for example? |
| 19:08 | <Hixie> | yes |
| 19:08 | <Hixie> | but microsoft were on a "honour mime types" kick recently |
| 19:08 | <Hixie> | so there was still hope |
| 19:09 | <Hixie> | now the question is can i hold the other browsers back, or should i just give up and make <video> sniff for everything |
| 19:09 | <Hixie> | and if the latter, can i get something specced that says how to recognise the video types |
| 19:09 | <AryehGregor> | I thought we concluded that honoring MIME types for video was only useful for theoretical purity anyway. |
| 19:09 | <Hixie> | and can we get WebM changed to lost its leading ASCII nonsense (matroska would be a lost cause presumably) |
| 19:09 | <Hixie> | to lose, rather |
| 19:10 | <Hixie> | well it's useful for avoiding tons of network wastage |
| 19:10 | <micheil> | btw, Hixie, not sure if I mentioned it, but I got TLS/SSL websockets working |
| 19:10 | <Hixie> | since you don't have to download the bytes if you know the type is one you don't support |
| 19:10 | <micheil> | so, wss:// |
| 19:10 | <Hixie> | micheil: cool |
| 19:10 | <AryehGregor> | Everyone is still honoring <source type="">, no? |
| 19:10 | <Hixie> | haven't checked that |
| 19:10 | <AryehGregor> | Once you can read the MIME type from the network, you can already read the first handful of bytes anyway. |
| 19:11 | <AryehGregor> | Unless you send a separate HEAD, which is a waste of a round trip. |
| 19:11 | <AryehGregor> | No? |
| 19:12 | <theMadness> | Some UA do that tho. |
| 19:12 | <theMadness> | Iinm proxies too. |
| 19:12 | <Hixie> | if anyone wants to test whether browsers (and IE9 in particular) honour <Source type>, that wouldn't be a bad thing to test |
| 19:13 | <Hixie> | i might test it when i get back |
| 19:14 | <Hixie> | bbiab |
| 19:21 | <Ms2ger> | "As you all know, MathML is a part of HTML5" |
| 19:21 | Ms2ger | didn't |
| 19:24 | <theMadness> | One might joke that is anything exists, it's part of HTML5 :P |
| 19:27 | <Ms2ger> | http://ismathml.partofhtml5.com/ |
| 19:29 | <Philip`> | http://ishtml5.partofhtml5.com/ - how rude :-( |
| 19:31 | Ms2ger | wasn't surprised by Philip` trying that |
| 19:32 | <Philip`> | http://istheblinktag.partofhtml5.com/ seems buggy in Opera - the blink speed is irregular, and sometimes it mispaints the text shadow |
| 19:34 | <matjas> | Philip` Opera designed it to resemble the rhythm of your ♥ |
| 19:36 | <AryehGregor> | Ms2ger, it should be extremely unsurprising, since he probably went to partofhtml5.com directly and then followed all the links, as I did. :) |
| 19:36 | <miketaylr> | oh dear, i swear i didn't make that first link :/ |
| 19:36 | miketaylr | blames Alex |
| 19:37 | <Philip`> | AryehGregor: Actually I went to ishtml5 first by guessing the URL :-) |
| 19:38 | <AryehGregor> | Good job, then. |
| 19:38 | <Philip`> | and only saw the list after that |
| 19:41 | <chronossc> | html5 have some kind of stuff to auto numerate as chapters nested lists, ex, li = 2, nested li = 2.1, etc |
| 19:41 | <chronossc> | ? |
| 19:41 | <AryehGregor> | That's CSS. |
| 19:41 | <AryehGregor> | CSS defines such things, I think, but I don't know if they work yet. |
| 19:42 | <chronossc> | hm |
| 19:42 | <chronossc> | k |
| 19:42 | <hdhoang> | there are no list-style like that, but css generated content should work |
| 19:43 | <chronossc> | I think that I found some example here: http://stackoverflow.com/questions/2729927/number-nested-ordered-lists-in-html |
| 19:45 | <chronossc> | ouch, works perfectly |
| 19:45 | <chronossc> | thx people |
| 20:06 | <Hixie> | 118.132.82.38 has spent days requesting files from hixie.ch with an IE9 previous build |
| 20:06 | <Hixie> | presumably microsoft's chinese testing subsidiary |
| 20:07 | <Hixie> | 7 of my apache instances have been running for days and have so far sent over 180,000 files from this directory: http://hiixe.ch/tests/evil/page-loading/alternative-content/investigation/ |
| 20:07 | <Hixie> | makes you wonder about the competence of their testing |
| 20:08 | Ms2ger | bets it wasn't from hiixe.ch |
| 20:08 | <Hixie> | er yeah, typo |
| 20:09 | <Ms2ger> | That would be particularly incompetent |
| 21:53 | <jlebar> | Hixie, since pushState doesn't cause a history traversal, there's no language saying that the UA should save the scroll position of the previous history entry. |
| 21:54 | <Hixie> | jlebar: is this a problem? |
| 21:55 | <jlebar> | Hixie, well...inasmuch as the UA can do whatever it wants with the scroll position, it's not a problem. But maybe it should be there, since it merits being mentioned in the history traversal algorithm. |
| 21:56 | <jlebar> | At least, I forgot to do it when I implemented pushState. :) |
| 21:56 | <Hixie> | i mean, should the state be saved? |
| 21:56 | <jlebar> | Oh, I think so. |
| 21:56 | <jlebar> | Say you scroll down, pushState, scroll around, and then go back. Shouldn't you get the old scroll position back? |
| 21:57 | <Hixie> | i dunno |
| 21:57 | <jlebar> | Well, it's still broken even if you don't think so: |
| 21:57 | <Hixie> | most apps i can imagine using pushState() would either not have any scroll position or would change the page so much on popstate that it'd be academic |
| 21:58 | <jlebar> | Suppose you scroll down, pushState, then go visit some other page entirely. Then you go back to the first history entry. We should restore your scroll position, but we never saved it! |
| 21:58 | <Hixie> | yeah, good point |
| 21:58 | <Hixie> | ok |
| 21:59 | <Hixie> | can you file a bug or send mail? |
| 21:59 | <jlebar> | Hixie, sure thing. |
| 21:59 | <Hixie> | ta |
| 22:14 | <annevk5> | hsivonen, createContextualFragment is something we copied from Gecko |
| 22:14 | <annevk5> | hsivonen, we did not want to have it |
| 22:14 | <annevk5> | hsivonen, so if Gecko changes it we can change it too |
| 22:16 | <annevk5> | ah, finally someone registered ispartofhtml5.com |
| 22:18 | <hober> | i think it's jsut partofhtml5.com |
| 22:20 | <paul_irish> | http://whatis.partofhtml5.com/ |
| 22:20 | <abarth> | hsivonen, annevk5: createContextualFragment is evil sauce |
| 22:20 | <annevk5> | I wish it was not there :) |
| 22:20 | <GPHemsley> | Hixie: Isn't Base64 limited to ASCII? |
| 22:20 | <annevk5> | abarth, I kind of like this new entity thing now, btw |
| 22:21 | <abarth> | annevk5: cool |
| 22:21 | <abarth> | GPHemsley: the output is binary. we're going to need to translate it to characters |
| 22:21 | <abarth> | GPHemsley: probably as UTF8 |
| 22:21 | <GPHemsley> | I meant input |
| 22:22 | <abarth> | the input language is A-Za-Z0-0 |
| 22:22 | <abarth> | plus a few random characters |
| 22:22 | <abarth> | if (!isBase64Character(cc)) |
| 22:22 | <abarth> | break; |
| 22:22 | <abarth> | char codeLetter = static_cast<char>(cc); |
| 22:22 | <abarth> | where cc is UTF16 |
| 22:23 | <annevk5> | GPHemsley, per the PHP manual it should work fine for arbitrary octets |
| 22:24 | <annevk5> | in fact "This encoding is designed to make binary data survive transport through transport layers that are not 8-bit clean, such as mail bodies." |
| 22:24 | <Hixie> | base64 encoding is binary -> text, decoding is text -> binary |
| 22:24 | <Hixie> | so it can carry anything |
| 22:25 | <Hixie> | we just have to define the encoding |
| 22:25 | <Hixie> | (presumably utf-8) |
| 22:25 | <annevk5> | yeah, utf-8, anything else is not really acceptable |
| 22:25 | <GPHemsley> | oh |
| 22:26 | <GPHemsley> | so you can encode anything with base64? |
| 22:26 | <gsnedders> | yeah |
| 22:26 | <Hixie> | sure |
| 22:26 | <Workshiva> | As long as you don't mind the size increase :) |
| 22:27 | <Hixie> | GPHemsley: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEUAAAD///+l2Z/dAAAAM0lEQVR4nGP4/5/h/1+G/58ZDrAz3D/McH8yw83NDDeNGe4Ug9C9zwz3gVLMDA/A6P9/AFGGFyjOXZtQAAAAAElFTkSuQmCC |
| 22:27 | <Hixie> | GPHemsley: that's a base64 encoded PNG |
| 22:27 | <GPHemsley> | oh, of course |
| 22:27 | <GPHemsley> | I don't know where my head was at |
| 22:27 | <Hixie> | probably left it with your sense of logic, by the door! |
| 22:27 | <GPHemsley> | (somewhere where base64 is also smaller than its source) |
| 22:27 | <Hixie> | :-D |
| 22:27 | <GPHemsley> | :) |
| 22:28 | <GPHemsley> | ah, see, I listen to the rules :) |
| 22:28 | <gsnedders> | Wow, your life must be dull. |
| 22:29 | <GPHemsley> | no comment |
| 22:30 | <Workshiva> | Only boring people need to break the rules to have fun |
| 22:31 | GPHemsley | likes Workshiva |
| 22:31 | <gsnedders> | I just break the rules to escape the norm and make people feel uneasy |
| 22:32 | <gsnedders> | Being like everyone else is boring. |
| 22:32 | <GPHemsley> | the rules were made for a reason |
| 22:32 | <annevk5> | this is too ;p |
| 22:33 | <gsnedders> | GPHemsley: To be broken. ;P |
| 22:33 | <GPHemsley> | meh |
| 22:35 | jgraham | tries to think of a rule gsnedders has broken |
| 22:35 | jgraham | fails |
| 22:35 | <jgraham> | Wait |
| 22:35 | <gsnedders> | Because I'm so perfect? |
| 22:35 | <jgraham> | Maybe "don't lie" is a rule |
| 22:35 | <jgraham> | But he is lying aout breaking rules |
| 22:36 | <jgraham> | He is a paradoxical rule breaker! |
| 22:36 | <gsnedders> | jgraham: I thought I'd at least broken your rules. E.g., no metal. |
| 22:37 | <gsnedders> | (as in the music genre) |
| 22:37 | <jgraham> | No that is just violting the boundaries of good taste |
| 22:37 | <jgraham> | *violating |
| 22:47 | <eric_carlson> | Hixie: should a media element delay the load event when it is not in a document? |
| 22:47 | <Hixie> | jlebar: btw re http://people.mozilla.org/~jlebar/respkg/ you can use "the document's address", pushState() doesn't change that (it changes "the document's current address") |
| 22:47 | <Hixie> | eric_carlson: per spec, yes |
| 22:48 | <Hixie> | eric_carlson: i think this makes sense; in particular, images do the same thing iirc |
| 22:48 | <jlebar> | Hixie, I'll fix that. Thanks. |
| 22:48 | <Hixie> | and audio is useful even when not in the doc |
| 22:48 | <Hixie> | (since you can play them) |
| 22:48 | <Hixie> | jlebar: np |
| 22:48 | <eric_carlson> | Hixie: I agree |
| 22:48 | <eric_carlson> | Hixie: thanks for the confirmation! |
| 22:48 | <Hixie> | eric_carlson: np |
| 22:49 | <Hixie> | jlebar: any news on that btw? i'm just looking at it now, would love to hear any experience you've had with it. |
| 22:50 | <jlebar> | Hixie, well, I'm waiting on someone here to do the incremental zip extraction part. I've been hearing it's coming Real Soon Now for a bit longer than I'd like. |
| 22:50 | <Hixie> | i know the feeling |
| 22:50 | <jlebar> | Hixie, :) My rough, unscientific tests gave pretty positive results. But what I'm really interested is seeing whether people can get a speedup on their real pages. |
| 22:51 | <Hixie> | cool |
| 22:51 | <Hixie> | i love the detailed spec |
| 22:51 | <Hixie> | makes a refreshing change to see someone be as detailed! :-) |
| 22:52 | <jlebar> | Thanks! |
| 22:52 | <Hixie> | jlebar: heh, you used the html5 "library" :-) |
| 22:53 | <AryehGregor> | dbaron posted substantive feedback to public-html. Will you catch that, Hixie, or do we need to tell people not to use public-html for that? |
| 22:53 | <jlebar> | lol, I guess so! |
| 22:53 | <Hixie> | AryehGregor: i'll see it |
| 22:53 | <AryehGregor> | k. |
