| 02:12 | <MikeSmith> | TabAtkins: you around? |
| 02:13 | <TabAtkins> | MikeSmith: Yo. |
| 02:13 | <MikeSmith> | hey man |
| 02:13 | <MikeSmith> | I saw your message about postings being held |
| 02:14 | <MikeSmith> | that you sent to the a11y list |
| 02:14 | <TabAtkins> | Yeah. |
| 02:14 | <MikeSmith> | to be clear, you mean the public-html-a11y⊙wo list? |
| 02:14 | <TabAtkins> | Yes. |
| 02:15 | <MikeSmith> | so I'm looking at the admin interface for that list but I don't see any messages being held for moderation |
| 02:16 | <TabAtkins> | Hrm. |
| 02:17 | <TabAtkins> | Frex, I sent one at 16:20 GMT today, in response to the "<summary> element and Issue 32" thread. |
| 02:17 | <TabAtkins> | And got an automated response from public-html-a11y-request⊙wo that my message had been sent to the list maintainer for approval. |
| 02:18 | <MikeSmith> | OK |
| 02:19 | <MikeSmith> | can you please forward that response to me? |
| 02:19 | <MikeSmith> | I'll pass it on to systems team and see if we can figure out what the problem is |
| 02:19 | <TabAtkins> | mikesmith⊙wo? |
| 02:19 | <MikeSmith> | mike⊙wo |
| 02:20 | <TabAtkins> | done |
| 07:50 | <hsivonen> | Hixie: did you fix about:blank on Friday? |
| 07:51 | <hsivonen> | Dashiva: H.264 authoring for Flash is equally tollboothed and freedom-deprived as H.264 authoring for HTML5, so Flash is not free for a child in $COUNTRY in that sense |
| 07:54 | <Hixie> | not yet |
| 08:12 | <MikeSmith> | Hixie: minor editorial nit - you have '<strong class="impl">Authoring requirements</strong>: ' at the beginning of the paragraph about the value attribute on the meter element |
| 08:13 | <MikeSmith> | with the colon outside the strong element |
| 08:13 | <MikeSmith> | so when I flip to the author view that colon still shows up |
| 08:13 | <MikeSmith> | seems like the colon needs to be inside the strong element |
| 08:15 | <Dashiva> | hsivonen: But surely it's better to depend only on h264, and not both h264 and flash |
| 08:18 | <MikeSmith> | hsivonen: is the term "tollbooth" in this context in wide use? I noticed Mike Shaver used it in a blog posting and you used it elsewhere recently also, but I can't recall seeing it before |
| 08:18 | <MikeSmith> | or maybe I just don't read enough |
| 08:19 | <Dashiva> | I've seen it, although only for cases where you have to actually pay. Not free as in free. |
| 08:19 | <Dashiva> | *as in beer |
| 08:19 | <Hixie> | MikeSmith: oh i thought i'd fixed those. Can you file a bug? |
| 08:20 | <MikeSmith> | Hixie: I find only one that one instance of it so far, but yeah, I will file a bug for it |
| 08:20 | <hsivonen> | MikeSmith: I think "tollbooth" has been used before shaver used it, but I don't have references. |
| 08:20 | <MikeSmith> | OK |
| 08:20 | <MikeSmith> | i |
| 08:20 | <MikeSmith> | oops |
| 08:21 | <MikeSmith> | anyway, it's a good term |
| 08:21 | <Hixie> | MikeSmith: thanks |
| 08:21 | <hsivonen> | Dashiva: it's not like you could now use Google properties without a Flash dependency |
| 08:24 | <Dashiva> | Google is changing, that's where all the fuss comes from. |
| 08:37 | jgraham | notes tht WebKit and Gecko support literal # in data urls |
| 08:44 | <Dashiva> | So fragments are impossible? |
| 08:45 | <roc> | the lack of fragment support in data: URIs is a real pain |
| 08:50 | <jgraham> | roc: How did it end up like that? |
| 08:50 | <roc> | I'm not sure, but I think it was an accident |
| 08:50 | <jgraham> | Ah |
| 08:50 | <roc> | because fragments were defined by HTTP |
| 08:50 | <roc> | data: URLs are not HTTP |
| 08:50 | <roc> | QED |
| 08:52 | jgraham | assumes the theoretical architecture where there is one and only one uri parsing function does not quite see eye-to-eye with reality |
| 08:52 | <Dashiva> | And the people who designed data: didn't bother to make them compatible with the best protocol ever(tm) |
| 09:02 | <hsivonen> | Hixie: is a second <html> tag with an offline manifest meant to take effect? |
| 09:05 | <roc> | jgraham: in fact, I believe in the theoretical architecture, each scheme determines how the rest of the URI is parsed |
| 09:07 | <hsivonen> | roc: it seems useful to have a class of URIs whose parsing is http-like (https, ftp, etc.). too bad you can't tell from an unknown scheme if the scheme is in that class |
| 09:07 | <roc> | yeah |
| 09:25 | <Hixie> | hsivonen: in text/html? |
| 09:25 | <Hixie> | hsivonen: is the spec ambiguous? |
| 09:27 | <hsivonen> | Hixie: well, it's not ambiguous, but I'm not 100% sure that what I read is what was intended |
| 09:27 | <hsivonen> | Hixie: currently the spec supports what I want to read |
| 09:28 | <hsivonen> | i.e. only the first <html> processes the cache manifest |
| 09:41 | <Hixie> | that is intended |
| 09:42 | <hsivonen> | Hixie: thanks |
| 09:43 | <MikeSmith> | gsnedders: a you aware of any known issues with the "--filter" option in anolis? |
| 09:44 | <MikeSmith> | I'm finding at least one case where it doesn't seem to be working as expected |
| 09:44 | <MikeSmith> | it removes an element as expected but leaves behind the text content of that element |
| 09:45 | <MikeSmith> | actually, it seems to be removing the text node that *follows* the element whose contents it should be removing |
| 09:46 | <MikeSmith> | the specific case is this: |
| 09:46 | <MikeSmith> | <strong class="impl">Authoring requirements</strong>: The <code>... |
| 09:46 | <MikeSmith> | that results in : |
| 09:47 | <MikeSmith> | Authoring requirements<code>... |
| 09:50 | <gsnedders> | MikeSmith: --filter? jgraham wrote that. |
| 09:57 | <Philip`> | Hooray for lxml .tail |
| 09:57 | <MikeSmith> | gsnedders: ah.. I will ping him later |
| 09:58 | <MikeSmith> | Philip`: hooray why? |
| 09:59 | <gsnedders> | MikeSmith: That'll be the cause of the bug |
| 09:59 | <MikeSmith> | ah |
| 10:00 | <MikeSmith> | anyway, I need to drop off for now |
| 10:00 | <MikeSmith> | bbiab |
| 10:52 | jgraham | confesses that he wrote that code and agrees with Philip` that .tail sounds likely |
| 10:53 | <jgraham> | Although I don't remember the code and MikeSmith isn't here anyway so I don't really think I am contributing anything useful |
| 10:59 | <hsivonen> | so much public-html email over the weekend... |
| 10:59 | jgraham | can no longer keep up |
| 11:00 | <jgraham> | (although that is partially due to a large volume of non-public-html related things to do) |
| 11:01 | <jgraham> | (and, I suppose, the desire to spend some small fraction of my life not in front of a computer) |
| 11:06 | Philip` | fails to understand such desires |
| 11:07 | <Philip`> | I suppose it might be bearable if the time you spend not in front of a computer is perhaps behind or beside a computer, or at least in close vicinity, and you interact with it via audio |
| 11:09 | <hsivonen> | public-html on speech synth day and night FTW |
| 11:14 | <zcorpan__> | should the timeupdate event skip missed frames too? |
| 11:18 | <MikeSmith> | jgraham: so I find this: http://hg.hoppipolla.co.uk/hgwebdir.cgi/anolis/file/16550726fd0d/anolislib/processes/filter.py |
| 11:20 | <MikeSmith> | def remove(element): |
| 11:20 | <MikeSmith> | if element.tail: |
| 11:20 | <MikeSmith> | etc. |
| 11:20 | <MikeSmith> | not having any idea what lxml .tail is supposed to do, I can't tell if that's doing what it should be doing or not |
| 11:20 | MikeSmith | goes to read up on .tail |
| 11:21 | <zcorpan__> | isn't tail the same as dom's nextSibling if it's a text node? |
| 11:22 | <MikeSmith> | yeah, seems so |
| 11:23 | MikeSmith | don't understand why it wants to check the following node at all anyway |
| 11:27 | <MikeSmith> | so what it seems to do is, if there's a text node following the element it wants to remove, it gets the element before the one it wants to remove, checks to see if that has a following text node, then concatenates that with the text node that follows the element it removes |
| 11:27 | <foolip> | zcorpan__: did I miss some discussion on timeupdate? |
| 11:27 | <zcorpan__> | foolip: don't think so |
| 11:27 | <MikeSmith> | I assume that the intent of this must be to preserve some whitespace that'd otherwise get dropped |
| 11:28 | <MikeSmith> | or something |
| 11:28 | <jgraham> | MikeSmith: Yes, you need to del with the case <p>This is <span>not</span> a paragraph</p> |
| 11:28 | <jgraham> | and wanting to remove the <span> without removing " a paragraph" |
| 11:29 | <hsivonen> | http://twitter.com/jdowdell/status/8159459869 |
| 11:31 | <Philip`> | I think a node in lxml is like "<tag>text <child nodes ...></tag>tail" so I guess if you're removing the tag then the tail needs to merge into the previous sibling's tail (if any) or the parent's text |
| 11:31 | <Philip`> | but that seems to be exactly what filter.py is doing |
| 11:35 | <jgraham> | Er what Philip` said |
| 11:35 | jgraham | is trying to do too many things at once |
| 11:46 | <zcorpan__> | "INVALID_STATE_ERR or INVALID_ACCESS_ERR when attempting to write into XML documents" - hmm, are ms implementing xhtml? |
| 11:48 | <Philip`> | Maybe they're simply reviewing the spec, and happened to notice an inconsistency there |
| 11:50 | <hsivonen> | hmm. it looks like Launchpad renumbers comments |
| 11:50 | <hsivonen> | so permalinks aren't perma |
| 12:00 | <zcorpan__> | i do not like subversion |
| 12:00 | <zcorpan__> | at least not when dealing with thousands of files |
| 12:03 | gsnedders | doesn't like Subversion. |
| 12:04 | <gsnedders> | Regardless of anything. |
| 12:07 | <zcorpan__> | also, i want foreign lands in html |
| 12:08 | <zcorpan__> | typing namespace decls sucks |
| 12:09 | Philip` | likes most of Subversion, except for performance and lack of networkless operation |
| 12:09 | hsivonen | prefers the way hg does branch merging |
| 12:10 | <hsivonen> | or, rather, does divergent trunk clone merging |
| 12:10 | hsivonen | hasn't merged between "real" mercurial branches |
| 12:13 | <jgraham> | Philip`: So you like all of subversion apart from its distinguishing features? |
| 12:13 | jgraham | realises this is not quite true |
| 12:15 | <Dashiva> | I like revision numbers |
| 12:15 | <Philip`> | jgraham: I like that you can check out subdirectories and don't need the whole history and can have access control on repositories, without needing any strange and uncommon and probably-poorly-tested extensions |
| 12:16 | <Philip`> | and I like that its newline handling is largely sensible |
| 12:16 | <Philip`> | and that it has good documentation and that the command-line client makes sense and that TortoiseSVN is good |
| 12:17 | <Philip`> | I don't think I care much about revision numbers - hashes seem fine |
| 12:17 | hsivonen | wonders what newline handling counts as sensible here |
| 12:18 | hsivonen | wishes Windows had sensible newline handling |
| 12:18 | <Philip`> | hsivonen: "sensible" means you can choose which files to apply special newline handling to and it defaults to off, and then Linux and Windows clients both see native newlines |
| 12:21 | <Philip`> | (I'm not sure what minor variations would still count as sensible) |
| 12:21 | <Philip`> | (It'd be nice to fix Windows but it's far too late for that, so tools should do their best to cope in such an environment) |
| 12:23 | <jgraham> | Philip`: I loathe the newline handling of subversion |
| 12:23 | <gsnedders> | +1 |
| 12:27 | <Philip`> | jgraham: Why? |
| 12:27 | <Philip`> | Also, what alternative is less loathsome? |
| 12:28 | <jgraham> | Philip`: Because magically changing files is bad |
| 12:29 | <jgraham> | I want the same bytes out of the repository that I put in |
| 12:29 | <Philip`> | Not being able to look at files in Notepad is more bad |
| 12:29 | <jgraham> | Not really |
| 12:29 | <Philip`> | Yes it is :-p |
| 12:31 | <Philip`> | (particularly when it's something aimed at relatively normal users, rather than developers) |
| 12:31 | <Philip`> | (like the data and configuration files that are included with the program) |
| 12:32 | <jgraham> | When are you ever in a situation where all you have is a windows computer with notepad and you can get hold of a svn co but can't get hold of a proper editor? |
| 12:33 | gsnedders | makes sure everyone knows that him and jgraham are separate person. |
| 12:33 | <gsnedders> | s/person/people/ |
| 12:33 | <jgraham> | If you really need windows line endings, just put windows line endings in the file |
| 12:34 | <Philip`> | It takes effort to find a decent editor and find out how to associate it with .txt files and context menu Edit and so on |
| 12:34 | <hsivonen> | Philip`: it seems like a bad idea to mangle the linefeeds in test cases and such |
| 14:36 | <foolip> | zcorpan__: ping |
| 14:39 | <Dashiva> | <details><teaser> |
| 14:41 | <jgraham> | Clearly we need to rename <details> <strip> |
| 14:42 | <zcorpan__> | foolip: pong |
| 14:42 | <Dashiva> | And one day we'll have an <accordion> element |
| 14:44 | <zcorpan__> | we should use single-letter elements more |
| 14:44 | <zcorpan__> | fill up the alphabet |
| 14:44 | <zcorpan__> | <d><c> for details/caption |
| 14:45 | <zcorpan__> | <f><c> for figure/caption |
| 14:46 | <Dashiva> | <0> |
| 14:46 | <zcorpan__> | can't use numbers for the first char |
| 14:46 | <Dashiva> | Why not? |
| 14:46 | <hsivonen> | Dashiva: legacy |
| 14:47 | <Dashiva> | How does it break? |
| 14:47 | <zcorpan__> | all browsers treat that as <0> |
| 14:47 | <zcorpan__> | most likely content relies on it |
| 14:48 | <hsivonen> | and in the case of XML, it's prohibited either as some kind of SGML compat trick or as the WG imposing its aesthetics on everyone |
| 14:48 | <zcorpan__> | also, in xml it's not well-formed |
| 14:48 | <zcorpan__> | oops |
| 14:48 | <daedb> | <o0> |
| 14:48 | <jgraham> | hsivonen, like zcorpan but 10% faster and 100% more cynical ;) |
| 14:49 | <AryehGregor> | <o_0> |
| 14:49 | <zcorpan__> | that'd be an awesome element name |
| 14:49 | <zcorpan__> | write a change proposal for the figure thing |
| 14:50 | <Dashiva> | What about <_0>, or is _ impossible to use first too? |
| 14:50 | <daedb> | <_0> breaks |
| 14:50 | <AryehGregor> | Well, it's possible to use in C, and that's about as strict as things usually get. |
| 14:50 | <zcorpan__> | only a-z for text/html works |
| 14:50 | <AryehGregor> | Oh, guess not. |
| 14:50 | <zcorpan__> | _ works in xml though |
| 14:52 | <Dashiva> | Wow, xml being more forgiving, that's a rare event |
| 14:53 | <Philip`> | <０/> |
| 14:53 | <Philip`> | That's fine in XML5e (though not XML4e) |
| 14:54 | <Dashiva> | <Ø> is sort for <O/> |
| 14:54 | <Dashiva> | *short |
| 14:54 | <zcorpan__> | what's the adoption rate for 5e? |
| 14:55 | Philip` | notices that libxml's xmllint has a "--oldxml10" option for enabling pre-5th-edition rules, which seems to express an expectation or hope that it's not going to change incompatibly again and need a --notsooldxml10 option |
| 14:55 | <AryehGregor> | Dashiva, XML has always allowed lots of things text/html didn't, like <p><div></div></p>. |
| 14:56 | jgraham | wonders if XML allows <𐂄> |
| 14:56 | <gsnedders> | jgraham: yes |
| 14:56 | <jgraham> | .me wonders if that character worked for anyone |
| 14:56 | <Dashiva> | The empty space? :) |
| 14:56 | gsnedders | got U+FFFD |
| 14:56 | jgraham | was aiming for U+10084 |
| 14:57 | <zcorpan__> | wfm |
| 14:57 | <Dashiva> | Make a dialect that's like HTML but using Japanese full-width character |
| 14:57 | <hsivonen> | the concept of "old XML 1.0" makes versioning look awesome |
| 14:57 | <jgraham> | (Linear B Ideogram Mare, to symbolise the nightmare of choosing names) |
| 14:58 | <gsnedders> | jgraham: What about Unicode 5.2 Carakan characters? |
| 14:58 | <gsnedders> | jgraham: Who cares about old Linear B? :P |
| 14:58 | <zcorpan__> | looks kind of like a horse's head to me |
| 14:58 | jgraham | wonders what U+10097 is supposed to be |
| 14:59 | <jgraham> | The caracter description doesn't say but if I were guessing I'd go for "drag queen" |
| 14:59 | <TabAtkins> | jgraham: I got 10084. It's a box saying that, not a character, but still. |
| 14:59 | <jgraham> | *character |
| 15:00 | <zcorpan__> | TabAtkins: get better fonts |
| 15:00 | <TabAtkins> | Yeah, I need to. |
| 15:00 | <TabAtkins> | I suspect I could view it on my work machine. |
| 15:01 | <zcorpan__> | it's vital to be able to see the spec's hour glasses and jgraham's horse heads |
| 15:01 | AryehGregor | can't :( |
| 15:01 | AryehGregor | shakes fist at Ubuntu |
| 15:01 | <AryehGregor> | http://www.fileformat.info/info/unicode/char/10084/index.htm |
| 15:20 | <Philip`> | TabAtkins: I think Shelley's discussion of comments is relevant for srcdoc - the sandbox feature apparently has ads as a use case, but nobody would use sandbox+srcdoc for ads, whereas it is claimed they would use sandbox+srcdoc for comments, so if sandbox+srcdoc didn't work for comments then a sensible solution would be to remove srcdoc |
| 15:21 | <TabAtkins> | That's true, but still irrelevant for @srcdoc itself. She's discussing @sandbox's features/limitations. |
| 15:21 | <Philip`> | (not to remove sandbox, because that has other use cases) |
| 15:21 | <Philip`> | TabAtkins: sandbox's features/limitations in the context of the use case which motivates the existence of srcdoc |
| 15:21 | <TabAtkins> | Yes. |
| 15:22 | <Philip`> | and if it's too limited to be useful then there's no longer any motivation for the existence of srcdoc |
| 15:22 | <TabAtkins> | But we're not going to change @srcdoc if we find that @sandbox needs to be changed for comments. We might remove it, but we won't change it. @srcdoc's abilities are irrelevant. |
| 15:22 | <AryehGregor> | Unless sandbox is conceptually useless for comments altogether. |
| 15:22 | AryehGregor | hasn't looked yet |
| 15:23 | <Philip`> | TabAtkins: Removing srcdoc is what she's suggesting |
| 15:24 | <zcorpan__> | i'm a bit skeptical about sandbox for comments -- i think serverside whitelisting is better |
| 15:24 | <TabAtkins> | Philip`: Yes, I understand. But she's talking about @sandbox. |
| 15:24 | <TabAtkins> | zcorpan__: Not better, I'd say. Useful in conjunction, yes. |
| 15:24 | <zcorpan__> | if you use serverside whitelisting then you don't need an iframe at all |
| 15:24 | <TabAtkins> | @sandbox's features for limiting scripts are still quite useful, I think, even if you employ serverside filtering to remove particular things. |
| 15:25 | <TabAtkins> | zcorpan__: Sure, but you have to be very conservative then. |
| 15:25 | <zcorpan__> | yes |
| 15:25 | <Philip`> | Server-side whitelisting is likely to have bugs, or be more restrictive than you want |
| 15:25 | <zcorpan__> | browsers are also likely to have bugs or be more or less restrictive than you want |
| 15:25 | <Philip`> | particularly if you want to allow some CSS |
| 15:26 | <AryehGregor> | Server-side whitelisting is just much more complicated. |
| 15:26 | <Philip`> | zcorpan__: Sure, so you use both, and it's no more restrictive than the server-side whitelisting and bugs are only a problem if they coincide |
| 15:26 | <AryehGregor> | It's the better solution if you can be bothered, but it would be nice to be able to just write up something secure by hand in an hour. |
| 15:27 | <Philip`> | You need whitelisting to stop people being irritating and filling your page with platypuses, regardless of whether the browser successfully prevents comments from stealing your admin session cookies |
| 15:27 | <zcorpan__> | maybe you can use an off-the-shelf sanitizer |
| 15:28 | <Philip`> | They're complicated and easy to misconfigure |
| 15:28 | <Philip`> | so they don't seem like a complete solution to the problem |
| 15:31 | <AryehGregor> | Philip`, how would whitelisting stop people from filling your page with (possibly ASCII-art) platypuses? |
| 15:33 | <Philip`> | Nobody would object to ASCII-art platypuses |
| 15:33 | <Philip`> | Anyway, you could just configure your whitelist to only allow dolphins and eagles, not platypuses |
| 15:34 | <AryehGregor> | I would support that. Dolphins and eagles are much prettier than platypuses. |
| 15:34 | gsnedders | starts argument about the plural of platypus |
| 15:34 | <workmad3> | platypii? |
| 15:34 | <Philip`> | Maybe a better example is people putting autoplaying <audio> in comments, which you'd want to prevent even though it's not an XSS vulnerability of any sort |
| 15:34 | <gsnedders> | workmad3: Certainly wrong |
| 15:35 | <workmad3> | gsnedders: most likely :) |
| 15:35 | <Philip`> | "Plural platypuses, platypi, (rare) platypusses, (rare) platypodes." |
| 15:35 | <workmad3> | I only added an extra i then :) |
| 15:36 | <TabAtkins> | "radii" has poisoned people into thinking that two i's are appropriate. |
| 15:36 | <workmad3> | what's the current argument about anyway? can't spot the start of it in my chat log |
| 15:36 | <gsnedders> | workmad3: If it were a second declension Latin noun, the norm. plural is -i |
| 15:37 | <Philip`> | TabAtkins: It'd be appropriate for platypius, I guess |
| 15:37 | <TabAtkins> | Indeed. |
| 15:37 | <gsnedders> | 'platypus (plural: platypuses, or platypus; common, pseudo-latin: platypi; rare, pedantic: platypodes)' |
| 15:38 | <TabAtkins> | Like all the other blatantly wrong grammar rules drilled into us as kids, I'm pretty sure that the -i plural was invented in the 19th century. |
| 15:38 | <AryehGregor> | gsnedders, the problem is that lots of those nouns happen to have a stem ending in -i. |
| 15:38 | <AryehGregor> | TabAtkins, er, it's from Latin. |
| 15:38 | <AryehGregor> | Dates to several hundred years BCE at least. |
| 15:39 | <AryehGregor> | Second-declension nouns, as gsnedders says. |
| 15:39 | <TabAtkins> | AryehGregor: Indeed it is. The application of Latin rules to English, a language not derived from Latin in any significant way, is much more recent. |
| 15:39 | <gsnedders> | AryehGregor: Indeed |
| 15:39 | <AryehGregor> | TabAtkins, English has vast amounts of vocabulary from Latin, both directly and indirectly. |
| 15:39 | <AryehGregor> | "radius" is taken directly from Latin, I suspect. |
| 15:39 | <AryehGregor> | So are lots of other nouns like "focus". |
| 15:39 | <TabAtkins> | Vocabulary, yes. Not conjugations. |
| 15:39 | <TabAtkins> | We mug languages the world over for vocabulary. |
| 15:39 | <AryehGregor> | This isn't a conjugation, it's a declension. :P |
| 15:40 | <TabAtkins> | The distinction is irrelevant and meaningless to me. |
| 15:40 | <TabAtkins> | I conjugate my nouns into a plural state. |
| 15:40 | <Philip`> | But platyp* weren't discovered until 1798, so it's not like you could ask a Roman what they'd call two of them |
| 15:40 | <AryehGregor> | Often we use the original plural for loan words. |
| 15:40 | <gsnedders> | AryehGregor: But also a fair bit of Latinized Greek words, where the rules are often sutly different |
| 15:40 | <AryehGregor> | Not just in Latin's case. |
| 15:40 | <TabAtkins> | I doubt it would be "often". |
| 15:40 | <TabAtkins> | Some cases. Like "children". |
| 15:40 | <AryehGregor> | gsnedders, yes, and also some straight Greek words, or Greek-derived words. |
| 15:40 | <AryehGregor> | TabAtkins, "child" isn't a loan word. |
| 15:41 | <AryehGregor> | Anyway, the problem here is that Greek "pous", meaning "foot", plural "podes", got transliterated as "pus", which then looked like a Latin second-declension noun. |
| 15:41 | <gsnedders> | Like, analyse and realize where the fact that one uses s and the other uses z is because one is of French origin, and the other Latinized Greek |
| 15:41 | <TabAtkins> | It came straight from our German language-ancestry. |
| 15:41 | <AryehGregor> | Much like "octopus". |
| 15:41 | <AryehGregor> | TabAtkins, right. But we have irregular plurals from loan words too. |
| 15:41 | <TabAtkins> | Sometimes, yes. |
| 15:42 | <TabAtkins> | On the other hand, the -i rule is taught as an absolute that applies to all nouns ending in -us. |
| 15:42 | <TabAtkins> | Luckily we don't have too many of them. |
| 15:42 | <AryehGregor> | It's only taught that way by ignorami. :) |
| 15:42 | <AryehGregor> | I don't think anyone educated says it should be used that way. For some words it's just totally wrong. |
| 15:42 | <gsnedders> | TabAtkins: Much like -ise and -ize, where it's often taught that only one is right. |
| 15:42 | <AryehGregor> | Like "platypus". |
| 15:42 | <TabAtkins> | Similarly, the occasionaly -a pluralization applied to words ending in -um. |
| 15:42 | <AryehGregor> | -um because -a, -a becomes -ae. |
| 15:42 | <AryehGregor> | In Latin, typically. |
| 15:42 | <TabAtkins> | AryehGregor: You're wrong. Plenty of educated people say it should be used that way. They're wrong, but still. |
| 15:43 | <TabAtkins> | The -i pluralization is, in fact, more an education tip-off than not. |
| 15:43 | <AryehGregor> | TabAtkins, not educated enough, then. :P (Source, though?) |
| 15:43 | <workmad3> | for example, I'm an educated person... just not educated in english :P |
| 15:43 | <workmad3> | (as in all the esoteric language mechanics, not the language in general) |
| 15:43 | <AryehGregor> | TabAtkins, I really doubt anyone who's not a patent moron (admittedly, there are some of those) would seriously argue that the plural of "medium" (as in someone who speaks to spirits) is "media". |
| 15:43 | <TabAtkins> | Down here in Texas, at least, the less-educated segment of the populous typically pluralizes with the standard english rules. |
| 15:43 | <AryehGregor> | populace. |
| 15:43 | <AryehGregor> | :P |
| 15:43 | <TabAtkins> | AryehGregor: Education and patent idiocy are not antagonistic. |
| 15:43 | <TabAtkins> | Also: d'oh! |
| 15:44 | <AryehGregor> | But right, this is all a social status thing. |
| 15:44 | jgraham | notes the interesting fact that louse is irreguloar in plural in Swedish also |
| 15:44 | <AryehGregor> | I mean, education is largely a status thing anyway. |
| 15:44 | <jgraham> | (I have no idea what it is in the singular or plural but I do remember it is irregular) |
| 15:44 | <workmad3> | AryehGregor: medium - media would more likely be used by some pedantic jackass trying to prove a point rather than a moron :) |
| 15:44 | <TabAtkins> | In fact, the *only* people who would attempt to argue that "medium" pluralizes to "media" are the highly-educated, or those aspiring to be. You have to be an idiot as well, of course. |
| 15:45 | <gsnedders> | What is it that boy is in Latin? That's got fun irregularity too. |
| 15:45 | <AryehGregor> | gsnedders, puella is girl, right? |
| 15:45 | <gsnedders> | puer |
| 15:45 | <AryehGregor> | Right, puer. |
| 15:45 | <gsnedders> | AryehGregor: yeah |
| 15:45 | <gsnedders> | And then all the fun with hic, haec, hoc |
| 15:45 | <AryehGregor> | I'd expect puer to go puer, . . . hmm. Not sure, actually. It can't go like pater, patri. |
| 15:45 | AryehGregor | never actually took a Latin lesson in his life, but has picked up a bit |
| 15:45 | <gsnedders> | puer, puer, puer, and then something else. |
| 15:46 | <Philip`> | puer sounds dirty |
| 15:46 | <gsnedders> | puer is second declension masculine with -er stem. |
| 15:46 | <gsnedders> | Whcih means, looking it up, -, -i, -o, -um, -o, -, -i |
| 15:47 | <gsnedders> | And the nominative case plural is… pueri. |
| 15:47 | <AryehGregor> | Common words tend to be the most irregular, in all languages. |
| 15:47 | <gsnedders> | In what language is "to be" regular? |
| 15:47 | <AryehGregor> | Look at English words like "women", or "of". Those have totally arbitrary spelling even by English standards. |
| 15:47 | <TabAtkins> | In my conlong. |
| 15:48 | <TabAtkins> | s/conlong/conlang/ |
| 15:48 | <AryehGregor> | gsnedders, not in English, or Hebrew, or . . . well, that's all the languages I know. |
| 15:48 | <AryehGregor> | Probably in Lojban. |
| 15:48 | <AryehGregor> | And Esperanto. |
| 15:48 | <AryehGregor> | Dunno. |
| 15:48 | <gsnedders> | Not in Latin, either, and that has quite few irregular verbs |
| 15:48 | <TabAtkins> | So, yeah, conlangs. |
| 15:49 | <gsnedders> | Latin has 10 irregular verbs, IIRC |
| 15:49 | <gsnedders> | Anyhow, I decided not to do a Eng. lang. and linguistics degree, so I am wholly ignorant |
| 15:49 | <TabAtkins> | Seriously, IE? I have to actually say style{display:none;}, or else you'll render a border around it? Wtf. |
| 15:57 | <Dashiva> | It's half regular in Japanese |
| 15:57 | <Dashiva> | Since they have separate verbs for predicate designation and existence :) |
| 15:59 | <Philip`> | If something's half regular, that means it's not regular, which surely means it's irregular |
| 16:04 | <TabAtkins> | Argh, FF is ignoring my content-type header and interpreting this file as text/plain. >_< Everyone else pays proper attention to it and lets me download it, FF just barfs the binary all over the screen. |
| 16:06 | <gavin> | TabAtkins: what file? |
| 16:06 | <TabAtkins> | igofigure.com/glados/emails/DoorAccessInformation.oft |
| 16:06 | <TabAtkins> | for one |
| 16:06 | <gavin> | I get a prompt to save the file |
| 16:06 | <TabAtkins> | In FF? |
| 16:06 | <gavin> | yes |
| 16:07 | <TabAtkins> | What version? |
| 16:07 | <gavin> | windows and mac |
| 16:07 | <gavin> | trunk and 3.6 |
| 16:07 | <TabAtkins> | How weird. Both me and my coworker are on Windows and 3.6, and we're getting the same response. |
| 16:09 | <gavin> | do you have a handler configured for that mime type? |
| 16:09 | <gavin> | (Options->Applications) |
| 16:09 | <TabAtkins> | No, but I have a "ForceType application/vnd.ms-outlook" directive in the .htaccess in that directory. |
| 16:10 | <gavin> | try clearing your cache? |
| 16:12 | <TabAtkins> | … Yeah, that was it. I kept clicking on the same file. Clicking on a new one works. |
| 16:12 | <TabAtkins> | Good enough! |
| 16:13 | <Dashiva> | Philip`: 2/3, even, since they have separate existence verbs for animate and inanimate objects |
| 16:18 | <AryehGregor> | Crazy Japanese. |
| 16:18 | AryehGregor | tries to think what aspects of Hebrew are weird. |
| 16:18 | <TabAtkins> | The numbering system. |
| 16:18 | <Dashiva> | (And that's without going into all the various politeness levels, with their separate verbs) |
| 16:19 | <AryehGregor> | That's not weird, it's ripped straight off the Greeks and makes a lot of sense. |
| 16:19 | <AryehGregor> | Ian just thought it was weird because he was given some crazy version modified to allow arbitrarily large numbers. |
| 16:19 | <AryehGregor> | The traditional one only goes up to 999,999 in a standard way. |
| 16:19 | <TabAtkins> | Go tell that to Hixie, who *still* can't get people to agree that the Hebrew list-style is correct. |
| 16:19 | <TabAtkins> | Heh, you beat me. |
| 16:19 | <AryehGregor> | It was changed after he wrote it to a much simpler version. |
| 16:19 | <AryehGregor> | Due to me, actually. That was how I first joined www-style. |
| 16:19 | <Dashiva> | Danish numbers are also silly |
| 16:20 | <gsnedders> | TabAtkins: Heh, that one |
| 16:20 | <AryehGregor> | Dashiva, are there different verbs to say that an inanimate object exists, and to *politely* say it exists? |
| 16:20 | <Dashiva> | The animate/inanimate distinction is removed in most cases when being polite |
| 16:20 | <Philip`> | English numbers are silly too |
| 16:21 | <Philip`> | They ought to be little-endian |
| 16:21 | <TabAtkins> | lolwut |
| 16:21 | <Dashiva> | Pssh |
| 16:21 | <gsnedders> | Philip`: x86 has corrupted you |
| 16:21 | <TabAtkins> | bigendian 4 eva |
| 16:21 | <Dashiva> | Danes switch to counting scores halfway to 100 |
| 16:21 | <Dashiva> | I mean, what the hell |
| 16:21 | <TabAtkins> | Dashiva: So do the French, I believe? |
| 16:21 | <AryehGregor> | Philip`, huh? English numbers *are* little-endian. The least significant digit is last. |
| 16:21 | <daedb> | Dashiva: Everything is silly in danish :p |
| 16:22 | <jgraham> | I thought no-one understood Danish numbering? |
| 16:22 | <Dashiva> | 10, 20, 30, 40... half three scores |
| 16:22 | <Philip`> | When you do something as simple as addition by hand, you align the two numbers to the right and start calculating the result from the rightmost digit and carry leftwards |
| 16:22 | <TabAtkins> | AryehGregor: You have it backwords. |
| 16:22 | <AryehGregor> | What? |
| 16:22 | <Philip`> | which is backwards compared to the left-to-right flow of normal English |
| 16:22 | <TabAtkins> | Little-endian means lsd is first. |
| 16:22 | <AryehGregor> | "little-endian" means "the end is small", no? |
| 16:22 | <Philip`> | It'd make much more sense to write the least significant digits first |
| 16:23 | <TabAtkins> | The little end comes first. |
| 16:23 | <TabAtkins> | As opposed to the big end coming first. |
| 16:23 | <AryehGregor> | "end" means the *first* byte? |
| 16:23 | <AryehGregor> | How absurd. |
| 16:23 | <TabAtkins> | http://en.wikipedia.org/wiki/File:Big-Endian.svg |
| 16:23 | <AryehGregor> | Philip`, but in division, you start from the most significant digit. |
| 16:23 | <Philip`> | Little-endian means you eat the least significant end of the egg first |
| 16:23 | <Dashiva> | But that's the outside |
| 16:23 | <Dashiva> | Much help you are, Philip` |
| 16:24 | <AryehGregor> | Also, we pronounce the most significant part first, which makes a lot of sense. |
| 16:24 | <AryehGregor> | On the other hand, when reading, you do have to scan to the end of the number to figure out how large it is before you can begin pronouncing it. |
| 16:24 | <TabAtkins> | Argh, this flashing SHODAN is distracting. Which is the point, of course. |
| 16:24 | <Dashiva> | If you use zero extension, you can do big-endian division |
| 16:24 | <AryehGregor> | We have to do a two-pass algorithm to read written numbers. :() |
| 16:24 | <AryehGregor> | :( |
| 16:25 | <Philip`> | It's more exciting to read out big numbers starting with the least significant digit |
| 16:25 | <Dashiva> | ... I might start doing that |
| 16:25 | <Philip`> | It leaves the listener in suspense, waiting for the revelation of the MSDs |
| 16:26 | <Dashiva> | Yes, excellent plan |
| 16:26 | <AryehGregor> | But that's non-standard. |
| 16:26 | <Dashiva> | Japanese avoids this problem by having components |
| 16:26 | <Dashiva> | But even there you have to scan some for bigger numbers |
| 16:26 | <Dashiva> | (more than 100,000) |
| 16:26 | <AryehGregor> | Biblical Hebrew is sometimes big-endian and sometimes little-endian. |
| 16:26 | <AryehGregor> | Dashiva, well, if it's less than 100,000, you hardly have to scan much ahead in any case. |
| 16:27 | <AryehGregor> | Of course, Biblical Hebrew has no digits, it just spells out the words. |
| 16:27 | <Dashiva> | Well, being able to stream process is still preferable |
| 16:28 | <Dashiva> | A eight-character buffer should be sufficient for arbitrarily large numbers |
| 16:28 | <Philip`> | Maybe people mixed up the digit ordering in the Bible and the number of the beast is not actually 666, it's 666 |
| 16:28 | <Philip`> | Oh, wait |
| 16:28 | <AryehGregor> | Philip`, wrong Bible, too. :P |
| 16:28 | <Dashiva> | I hear they mixed it up and it's actually 616 |
| 16:29 | <TabAtkins> | You got it backwards, Dashiva. 616. |
| 16:29 | TabAtkins | overplays a joke. |
| 16:29 | <Dashiva> | You got it backwards, TabAtkins. That was the joke. |
| 16:29 | <TabAtkins> | Hoisted by my own petard! |
| 16:30 | <AryehGregor> | Maybe they got it backwards and it's really 999. |
| 16:33 | <Dashiva> | Hey Philip` |
| 16:33 | <Dashiva> | When reading numbers backwards, should you say like "one forty six hundred" or "one and forty and six hundred" |
| 16:34 | <Philip`> | I suggest "one four six" |
| 16:34 | <Philip`> | You can insert a little pause for thousands markers |
| 16:35 | <Dashiva> | That seems inefficient |
| 16:35 | <Dashiva> | Since you'd have to pronounce all the trailing zeroes in large numbers |
| 16:36 | <Philip`> | Use run-length encoding |
| 16:36 | <Philip`> | or scientific notation |
| 16:37 | <Dashiva> | Maybe I'll do a mix-endian approach |
| 16:37 | <Dashiva> | Sixhundred and forty-one, seven hundred thousand, twenty million, etc |
| 16:37 | <Philip`> | "nine e nine two point four" etc |
| 16:38 | <jgraham> | We could say numbers big endian and write them little endian |
| 16:39 | <AryehGregor> | How about we just say stuff totally at random and rely on telepathy for actual communication? |
| 16:39 | <Dashiva> | I like the mixed one. It reuses the existing terminology, but has the additional benefit of leaving the viewer with the overall magnitude fresh in mind when the number ends |
| 16:39 | <Dashiva> | s/viewer/listener/ |
| 16:40 | <jgraham> | It limits you to 99 balls in the lottery though |
| 16:40 | <jgraham> | Since elleven one hundred could be one ball or two |
| 16:40 | <Dashiva> | No, 999 |
| 16:41 | <Dashiva> | Digits are grouped in threes |
| 16:41 | <jgraham> | Hmm I guess that is OK |
| 16:42 | <Dashiva> | If needed, you could always start a number explicitly by saying "point zero" |
| 16:42 | <Philip`> | A lottery with 111 balls? You need to give players *some* chance of winning |
| 16:42 | <FireFly> | "ninety-nine and nine hundred"? |
| 16:43 | <Dashiva> | Philip`: The chance of winning depends on the number of balls selected too, not just the total |
| 16:44 | <Philip`> | I suppose so, but it'd be really dull if you only had to pick four numbers |
| 16:44 | <jgraham> | It's pretty dull already, statistically speaking |
| 16:45 | <Philip`> | I think anyone who speaks statistically is not the target audience for lotteries |
| 16:46 | <Dashiva> | You could have billions and billions of balls, and let people pick all except one |
| 16:46 | <Dashiva> | And then draw all except one ball |
| 16:46 | <Dashiva> | You'd get so many right! So close! |
| 16:47 | <GarethAdams|Work> | you could let them pick up to 199, but actually have balls numbered up to 200 |
| 16:48 | <FireFly> | "choose a number between 1 and 199." "And the number is... 200!" |
| 16:48 | <FireFly> | (not the factorial of 200, that is) |
| 16:49 | <Philip`> | You could be like ERNIE and do a million draws per month, so surely one of them will match your number |
| 16:51 | <AlicanC> | does xhtml spec always follow the html spec or are they like developed (spec'd) seperately? |
| 16:51 | <Dashiva> | XHTML 1.0 is a delta spec |
| 16:51 | <AlicanC> | thanks for random fact |
| 16:51 | <gsnedders> | With quite a few undocumented changes |
| 16:52 | <AlicanC> | so when html5 hits final will there be a new release of xhtml spec with <video> and stuff? |
| 16:52 | <Philip`> | AlicanC: If you mean XHTML5/HTML5, they're defined in the same document as different syntaxes for the same language |
| 16:52 | <AlicanC> | xhtml5? so the version jumps from 1.1 to 5? |
| 16:52 | <Philip`> | so there's (almost) no difference in functionality |
| 16:53 | <Philip`> | AlicanC: Consider it to be "X HTML5" rather than "XHTML 5" |
| 16:53 | <Philip`> | since it's basically just an XML syntax for HTML5 |
| 16:53 | <Philip`> | rather than being an evolution of XHTML1 |
| 16:54 | <AlicanC> | ok ty |
| 16:58 | <AlicanC> | this is not a technical question but, should we expect more cross-browser compatibility after the realease of HTML5? |
| 16:58 | <Dashiva> | Yes |
| 16:59 | <Dashiva> | Or rather, it's already happening |
| 16:59 | <AlicanC> | yeah but i still had to follow one method for each browser to capture some mouse events |
| 17:00 | <AlicanC> | its not really related to the HTML spec but I just thought that release of it might trigger something like that |
| 17:01 | <Philip`> | "release" doesn't have much significance |
| 17:01 | <AryehGregor> | Browsers are mostly converging in this sort of thing, thankfully. |
| 17:01 | <AryehGregor> | But it's not going to change overnight. |
| 17:01 | <Philip`> | People are always writing specs, and people are always fixing bugs in browsers to hopefully match the specs better |
| 17:01 | <AryehGregor> | HTML5 is doing a lot to weed out corner-cases where browsers diverge. |
| 17:01 | <Dashiva> | The IE event model is probably not going to change soon |
| 17:02 | <Philip`> | I guess mouse events are a Web Apps WG thing? |
| 17:02 | <Dashiva> | Yeah |
| 17:02 | <AlicanC> | i dont know if html specs contain stuff about events etc. |
| 17:02 | <AlicanC> | so it does? |
| 17:02 | <Philip`> | (It's strange how browsers spend lots of time with flashy videos and 3D graphics and fancy fonts but haven't bothered to get mouse and keyboard input working decently yet) |
| 17:02 | <Dashiva> | Only the HTML-specific stuff |
| 17:03 | <AlicanC> | to be honest the whole javascript is a disaster |
| 17:03 | <Dashiva> | It's not that strange |
| 17:03 | <Dashiva> | It's easier to invent something new than to fix a trainwreck |
| 17:03 | <AlicanC> | i guess theres no spec for javascript developers to follow for function naming / etc. |
| 17:04 | <Dashiva> | I'm sure shepazu can regale us with stories about those who tried |
| 17:06 | <AlicanC> | actually companies can spare some time for fixing those trainwrecks since new standartd like HTML5 and CSS3 is nearing their releases |
| 17:07 | <AlicanC> | and also, on the rendering side, stuff being rendered by Direct2D etc.. |
| 17:13 | <AryehGregor> | HTML5 and CSS3 are nowhere near finished. |
| 17:13 | <AryehGregor> | Nor anywhere near fully implemented. |
| 17:13 | <AryehGregor> | Even the high-profile features like HTML5 <video> still have a lot of work to be done on them in shipping implementations. |
| 17:14 | <AryehGregor> | We only just got a <video> implementation that even supports fullscreen. |
| 17:16 | Philip` | saw a Firefox 3.6 announcement saying it has the "world’s best implementation" of <video>, now with fullscreen support |
| 17:17 | <AlicanC> | im not saying that HTML5 will be released tomorrow and the day after, all browsers will be recoded from scratch and be shipped in cashmere CD cases with fluffy bears and kittens on them |
| 17:17 | <AlicanC> | no one is that optimisic |
| 17:17 | <Philip`> | (It seems kind of disappointing that that kind of feature is not just taken for granted) |
| 17:18 | <Philip`> | AlicanC: I don't think they'll be shipped on CDs - digital distribution is much cheaper |
| 17:18 | <Philip`> | The rest sounds good to me, though |
| 17:20 | <AlicanC> | i just dont want people to judge my thoughts with 100% shallowness |
| 17:21 | <AlicanC> | HTML 4.01 is dated 1999. if html5 is going to be released in next 1 year i call it near compared to 11 year passed |
| 17:23 | <Dashiva> | Philip`: And the fullscreen support seems rather weak, considering all the complaints I've read in blog posts about <video> |
| 17:23 | <gsnedders> | AlicanC: Nowadays for a spec to become a REC it needs two interoperable implementations, with a full test suite. HTML 4.01 doesn't have that after 11 years, I'd be absolutely amazed if HTML 5 did within a year or two. |
| 17:24 | <AryehGregor> | AlicanC, HTML5 is probably not going to have multiple, full, interoperable implementations of *every* feature for ten years. So that's not what you should be looking for. Look at it feature-by-feature. |
| 17:24 | <AryehGregor> | "Is <video> support in shipping browsers good enough for me to use yet?" |
| 17:25 | <AryehGregor> | (if you're YouTube, evidently "yes") |
| 17:25 | <Dashiva> | Nice gallery links. "Older stuff" and "next page" go back in time, whereas "Newer stuff" and "previous page" go forward. |
| 17:25 | <TabAtkins> | Argh, I *hate* it when things work like that. |
| 17:25 | <AlicanC> | i wouldnt take fullscreen support into consideration |
| 17:25 | <Dashiva> | But it gets better |
| 17:26 | <Dashiva> | They're paired together "Previous page" with "Older stuff", and "Newer stuff" with "Next page" |
| 17:26 | <TabAtkins> | That's… That's disgusting. |
| 17:26 | <TabAtkins> | The pairing makes perfect sense if you pay attention to the words. The links, though… |
| 17:27 | <AlicanC> | thats innovation lol |
| 17:27 | <AlicanC> | :D |
| 18:03 | <Philip`> | AryehGregor: src is fallback for srcdoc |
| 18:03 | <AryehGregor> | Hmm. |
| 18:03 | <AryehGregor> | Then why bother with srcdoc? |
| 18:03 | <Philip`> | Saves network requests |
| 18:04 | <AryehGregor> | Hmm. |
| 18:04 | <AryehGregor> | I guess that makes sense. |
| 18:05 | <AryehGregor> | Why would you want to use a sandboxed iframe for any content you know at the time the page is being created, though, rather than whitelisting? Only for apps that are too small to bother with whitelisting? |
| 18:05 | <AryehGregor> | Could this be better solved by improved libraries? |
| 18:05 | <TabAtkins> | AryehGregor: I can't parse your question. |
| 18:05 | <AryehGregor> | TabAtkins, the use of a sandboxed iframe for content that's completely out of your control, like ads, makes sense to me. |
| 18:06 | <TabAtkins> | Ah, k. |
| 18:06 | <AryehGregor> | But to use srcdoc, you need to have the content available to your app anyway. You could just as well do parse and whitelist it. |
| 18:06 | <AryehGregor> | What's a good reason you wouldn't do that? |
| 18:06 | <Dashiva> | AryehGregor: It's hard |
| 18:06 | <TabAtkins> | I'd certainly do that *too*. |
| 18:06 | <AryehGregor> | I can only think of fairly weak reasons, compared to the flexibility of whitelisting. |
| 18:06 | <TabAtkins> | But removing scripting is difficult, while @sandbox handles it securely and trivially. |
| 18:06 | <Philip`> | Whitelisting can be easy |
| 18:06 | <AryehGregor> | Dashiva, so is this only a feature to compensate for the lack of good libraries in any given language? |
| 18:07 | <Philip`> | e.g. if you allow no HTML elements |
| 18:07 | <Dashiva> | AryehGregor: It's not just the whitelisting infrastructure, you also have to know what to whitelist |
| 18:07 | <Dashiva> | A browser knows better what's safe and what isn't |
| 18:07 | <AryehGregor> | Dashiva, a good library could do that well too. |
| 18:07 | <Philip`> | It's probably more compelling when you want a much wider whitelist than most blogs etc typically allow |
| 18:07 | <AryehGregor> | Philip`, MediaWiki has an extremely wide whitelist, but we do still blacklist certain particular things. |
| 18:08 | <Philip`> | like you want people to embed little scripted widgets in their comments, without interfering with the rest of your page |
| 18:08 | <AryehGregor> | For instance, we don't permit <img>, but we do permit style="". |
| 18:08 | <AryehGregor> | If you want to allow some type of untrusted script, then it makes sense. |
| 18:08 | <AryehGregor> | You can't do server-side whitelisting of nontrivial script. |
| 18:08 | <AryehGregor> | But does anyone actually want this? |
| 18:08 | <AryehGregor> | Has anyone said they'd be interested in using it? |
| 18:08 | <AryehGregor> | The use-cases seem weak. |
| 18:08 | <Philip`> | If you allow style you've got to worry about style="expression(script)" etc and it becomes far more complex |
| 18:09 | <AryehGregor> | Philip`, actually, not that complex at all. |
| 18:09 | <Philip`> | (Do you happen to have a link to Mediawiki's filtering code?) |
| 18:09 | <AryehGregor> | Philip`, grep for "function checkCss". http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Sanitizer.php?view=markup |
| 18:09 | <Dashiva> | AryehGregor: Is there a problem with using sandbox on content you believe to safe, though? Defense in depth. |
| 18:09 | <AryehGregor> | It's blacklist-based, but has worked well for years. |
| 18:09 | <Dashiva> | *to be |
| 18:10 | <AryehGregor> | Dashiva, that seems like a weak use-case. How many people are going to bother to use srcdoc="" just for defense in depth? |
| 18:10 | <Dashiva> | Not just for |
| 18:10 | <AryehGregor> | Does anyone here have any particular cases where they, personally, would actually want to use srcdoc? |
| 18:11 | <Dashiva> | srcdoc has its own uses, e.g. reducing network traffic |
| 18:11 | <Dashiva> | Once you're using srcdoc, sandbox is free |
| 18:11 | <AryehGregor> | By "srcdoc" I mean "sandboxed iframes where you could plausibly use srcdoc". |
| 18:11 | <AryehGregor> | Does anyone have a case where you'd want to use a sandboxed iframe rather than server-side sanitizing? Or in addition to server-side sanitizing? |
| 18:12 | <AryehGregor> | (as opposed to cases where server-side sanitizing is impossible, I agree sandbox makes sense there) |
| 18:12 | <TabAtkins> | I've already provided a case where I'd want to use it in addition to server-side processing. |
| 18:12 | <AryehGregor> | Philip`, eight lines, doesn't seem too complicated. Found any problems with it yet? |
| 18:13 | <AryehGregor> | TabAtkins, which is what? And do you want it enough for it to be worth implementers spending time on it rather than other features that give you things you can't have right now at all? |
| 18:14 | <othermaciej> | AryehGregor: I do think the case for srcdoc is somewhat weaker than for sandboxed iframes in general |
| 18:14 | <AryehGregor> | Philip`, background-image: attr(title, url) is a problem, but happily, not implemented yet anywhere. |
| 18:14 | <TabAtkins> | Simplest one is trusting that there really is no scripting going on, as history shows that people are very clever at slipping stuff through sanitizers. |
| 18:14 | <AryehGregor> | TabAtkins, I don't think we've ever had anything get through the MediaWiki sanitizer. |
| 18:14 | <AryehGregor> | Not since very early days, anyway. |
| 18:15 | <TabAtkins> | Still, every high-profile XSS case is high-profile precisely because it slipped through sanitizers. |
| 18:15 | <AryehGregor> | We've had the usual XSS stuff, but I don't think any were because of the sanitizer misbehaving. |
| 18:15 | <AryehGregor> | I might be wrong, though. |
| 18:15 | karlushi | sees big wreckage at the horizon in terms of ugliness of the pages. :) I think we will be surprised by the creativity of people using srcdoc |
| 18:15 | <othermaciej> | one key difference that I guess I have been overlooking is that srcdoc has a different fallback model |
| 18:15 | <AryehGregor> | No, XSS is caused by a totally different failure, usually. |
| 18:15 | <othermaciej> | namely that you get a dead iframe box instead of your desired content |
| 18:15 | <AryehGregor> | XSS is typically when something is being injected into trusted content and isn't escaped at all. |
| 18:15 | <othermaciej> | XSS does in fact occur because of bad sanitizers |
| 18:16 | <AryehGregor> | I'm sure it does sometimes, but that's not the leading cause, unless you construe "sanitizers" very broadly. |
| 18:16 | <othermaciej> | remember the MySpace worm? |
| 18:16 | <AryehGregor> | No, I don't touch social networking sites with a ten-foot barge pole. :P |
| 18:16 | <othermaciej> | http://namb.la/popular/tech.html |
| 18:16 | <othermaciej> | that was a rather spectacular failure of filtering |
| 18:18 | <othermaciej> | I wonder if your favorite content filter has considered this attack vector... |
| 18:27 | <AryehGregor> | othermaciej, IMO, any useful whitelisting system has to whitelist URL protocols. |
| 18:27 | <AryehGregor> | That seems like MySpace's failure here. |
| 18:27 | <AryehGregor> | (MediaWiki simply prohibits URLs everywhere in CSS.) |
| 18:27 | <AryehGregor> | Anyway, yes, whitelisting is hard to get right. |
| 18:28 | <othermaciej> | AryehGregor: I'm betting they did whitelist URL protocols, they just didn't think about URLs inside CSS |
| 18:28 | <AryehGregor> | So I guess some people might want to use srcdoc. |
| 18:28 | <othermaciej> | point is, a sandboxed iframe would have neutralized this attack |
| 18:28 | <othermaciej> | (I'm not sure that you'd specifically need srcdoc for it) |
| 18:28 | <AryehGregor> | It depends how much was sandboxed, no? |
| 18:28 | <AryehGregor> | Where was the code injected, exactly? |
| 18:28 | <othermaciej> | In a user's profile page (controlled by that user) |
| 18:29 | <othermaciej> | in one of the many parts where MySpace lets you provide the content |
| 18:29 | <AryehGregor> | I guess it doesn't matter, you just have to split it up into "script allowed" and "script not allowed" and make sure all user-provided content is in the latter pigeonhole. |
| 18:29 | <othermaciej> | social networks are probably a more realistic and interesting use case for sandboxed iframes than blog comments |
| 18:29 | <AryehGregor> | Wikis would be similar. |
| 18:31 | <othermaciej> | in fact, even a sandboxed iframe with allow-script on would have prevented the worm aspects of this attack |
| 18:32 | <othermaciej> | and this is just one of the most well known breakdowns of whitelisting because it got so bad that it affected backbone traffic.... |
| 18:32 | <TabAtkins> | Argh, all I want for Xmas is a way to link a <input type=file> to a <progress> trivially and declaratively. |
| 18:32 | <AryehGregor> | Okay, so this has some reasonable uses. |
| 18:32 | <AryehGregor> | TabAtkins, that would be cool. |
| 18:33 | <AryehGregor> | It would actually make <progress> useful. :P |
| 18:33 | <TabAtkins> | I keep having to screw around with various different uploaders solely so I can provide a progress bar, and none of them are without issues. |
| 18:33 | <AryehGregor> | Well, I guess <progress> isn't really useful until it's style-able. |
| 18:33 | <AryehGregor> | What I want to know is, why the heck don't browsers provide progress bars for uploads themselves? |
| 18:34 | <AryehGregor> | They provide them for downloads. |
| 18:34 | <TabAtkins> | I don't care all that much, actually. Set the attributes on it, and fire progress events that I can capture to handle the styling myself. |
| 18:35 | <TabAtkins> | Seriously, some simple upload indicator in the browser UI would fit my needs perfectly too. I just can't have customers uploading 50+MB files without some progress indicator. |
| 18:35 | <AryehGregor> | https://bugzilla.mozilla.org/show_bug.cgi?id=249338 |
| 18:36 | <othermaciej> | if you are willing to do all the drawing of the progress bar completely yourself, then at least in Safari you can give good progress UI |
| 18:36 | <othermaciej> | just use <input type=file> to pick one or more files, and XHR to upload, and listen for its progress events |
| 18:38 | <AryehGregor> | Would that work in any browser supporting the File API? |
| 18:38 | <TabAtkins> | Looks like it works in FF too. |
| 18:39 | <TabAtkins> | But, of course, I need IE7 support. |
| 18:44 | <TabAtkins> | Hm, apparently YUI can handle it. Interesting. |
| 18:45 | <AryehGregor> | In pure JS? How, I wonder? |
| 18:45 | <TabAtkins> | That's a great question. |
| 18:45 | <Bo> | Hi! how's html5 going? will it make flash extinct? |
| 18:45 | <AryehGregor> | Bo, yes, just give it a few years. |
| 18:45 | <Bo> | cool! good luck guys! |
| 18:46 | <AryehGregor> | I predict that in two years, normal people using new browsers won't need to have Flash installed. |
| 18:46 | AryehGregor | just made up that prediction off the top of his head |
| 18:46 | <AryehGregor> | To be fair, I should check whether I was right. |
| 18:47 | <AryehGregor> | $ at January 25, 2012 |
| 18:47 | <AryehGregor> | warning: commands will be executed using /bin/sh |
| 18:47 | <AryehGregor> | at> echo "Right or wrong? #whatwg [100125 13:52:46] <AryehGregor> I predict that in two years, normal people using new browsers won't need to have Flash installed." |
| 18:47 | <AryehGregor> | at> <EOT> |
| 18:47 | <AryehGregor> | job 102 at Wed Jan 25 13:53:00 2012 |
| 18:52 | <othermaciej> | AryehGregor: it would work in any browser supporting enough of the File API |
| 18:52 | <othermaciej> | TabAtkins: I bet YUI uses Flash |
| 18:53 | <othermaciej> | TabAtkins: Flash is (sadly) the canonical solution for AJAXey file upload, upload progress, and e.g. multi-file selection |
| 18:53 | <TabAtkins> | I know - that's what I'm using now, but apparently not a good one. |
| 18:56 | <othermaciej> | it would be nice to have a JS lib that can use HTML5 + XHR2 when available and fall back to Flash |
| 18:56 | <TabAtkins> | Indeed. |
| 18:58 | <TabAtkins> | Huh. nixbox.com/demos/jquery-uploadprogress.php doesn't seem to use any flash, and it works in IE8 at least. |
| 18:59 | <AryehGregor> | Java? |
| 18:59 | <TabAtkins> | Nah, php. |
| 18:59 | <AryehGregor> | I mean: client-side Java? |
| 18:59 | <TabAtkins> | Ah, it uses an uploadprogress PECL plugin. |
| 18:59 | <AryehGregor> | (instead of Flash) |
| 18:59 | <AryehGregor> | Oh, I see. |
| 18:59 | <AryehGregor> | Right, that works. |
| 19:00 | <AryehGregor> | You could just get the upload progress from the server. |
| 19:00 | <AryehGregor> | Kind of stupid, but . . . |
| 19:00 | <TabAtkins> | Yeah, but you can't do that by default with PHP. It slurps the whole request before running the destination script. |
| 19:00 | <AryehGregor> | Right, but I mean in principle, that's an alternate approach you could take. |
| 19:01 | <TabAtkins> | I have a working uploader that uses perl to do it, but I had way too many problems getting it to run. |
| 19:01 | <AryehGregor> | Since you often control the server completely. |
| 19:01 | <AryehGregor> | So you can deploy whatever you want there, in theory. |
| 19:06 | <erlehmann> | gsnedders, you should blog moar. me likey |
| 19:14 | <AryehGregor> | gsnedders.com? What a horrible misuse of the TLD for US commercial websites. |
| 20:57 | <TabAtkins> | AryehGregor: I put up some ideas for improving sandbox for comment use. Can you see any other major areas we could possibly hit, based on your mx experience? |
| 20:57 | <TabAtkins> | s/mx/mw/ |
| 20:57 | <AryehGregor> | TabAtkins, I'll probably look at my spec e-mail tomorrow. |
| 20:58 | <TabAtkins> | k. just for reference, it's in the whatwg thread about sandbox. |
| 21:01 | Lachy | *facepalms* |
| 21:01 | <Lachy> | Where on earth did anyone get the idea that sandboxing had anything at all to do with protecting against SQL injection? |
| 21:01 | <TabAtkins> | From Shelley. |
| 21:01 | <TabAtkins> | And now she's confused Leif. |
| 21:01 | <Lachy> | yeah, but where the hell did she get it from?! |
| 21:01 | <TabAtkins> | I have no idea. |
| 21:02 | <Lachy> | it's as if they have no clue about the security issues involved, and are just arging for the sake of arguing |
| 21:02 | <Lachy> | and also, why are all the arguments that are supposedly against srcdoc, actually solely focussed on sandbox? |
| 21:02 | <TabAtkins> | Because of your previous line. |
| 21:04 | <Lachy> | well, the one argument against srcdoc is that markup in attriubtes is an anti-pattern, which is somewhat true, but unavoidable in this case. |
| 21:04 | <AryehGregor> | The other question is how useful it is, really. |
| 21:05 | <AryehGregor> | Anyway, seriously. If someone is posting things that don't make much sense, don't respond to them. If they make any good points, someone else will make them too, and you can respond to the other person. |
| 21:05 | <AryehGregor> | There's no point in getting into a debate where both sides are talking past each other. |
| 21:06 | <TabAtkins> | Markup in attributes is an anti-pattern, but I'm not seeing why data: urls are any better. Same thing, just a different attribute and different escaping requirements. |
| 21:06 | <Lachy> | wow. It looks like Shelley doesn't even understand what SQL injection actually is. |
| 21:07 | <AryehGregor> | She doesn't do server-side development, does she? |
| 21:07 | <Lachy> | or, at least, she's confusing SQL injection with embedding malicious client side scripts in user input |
| 21:07 | <Lachy> | I don't know what she does. |
| 21:11 | <TabAtkins> | Restarting apache is enough to get php.ini changes to be recognized, right? |
| 21:15 | <Philip`> | TabAtkins: No, you have to format your disk and reinstall from scratch |
| 21:15 | <TabAtkins> | Philip`: Damn, okay. |
| 21:17 | <Philip`> | (I'd expect it to be fine with just a "apachectl graceful", though maybe PHP is stupid and doesn't work with that) |
| 21:26 | <AryehGregor> | It does. |
| 21:26 | <AryehGregor> | graceful restarts everything, it just lets all currently-running requests run to completion before replacing their worker process. |
| 21:32 | <Lachy> | are there any use cases for srcdoc that wouldn't call for sandboxing too? |
| 21:32 | <TabAtkins> | Not really, I think. |
| 21:33 | <Philip`> | You could use it to reset styles |
| 21:34 | <Philip`> | or to do little scrolly windows without having to learn the CSS syntax for it |
| 21:36 | <Philip`> | You could use it for pages containing lots of test cases that run independently |
| 21:39 | <AryehGregor> | In other words, no. :P |
| 21:44 | <Lachy> | using it to reset styles doesn't seem like a compelling use case, since you'd most likely want to specify it with seamless, so that the parent document's styles are applied to the iframe's srcdoc document. |
| 21:45 | <Lachy> | if you don't specify seamless, then you just get an ordinary iframe |
| 21:46 | <Philip`> | You get an ordinary iframe without the effort of making a separate file for it |
| 21:54 | <erlehmann> | TabAtkins, may I ask what problem srcdoc solves that data URIs don't ? |
| 21:54 | <erlehmann> | I mean, I read the example but am obviously a bit confused. |
| 21:55 | <TabAtkins> | They solve the same problem, but data urls are slightly different in ways that are annoying. |
| 21:56 | <erlehmann> | Okay. Thought I had missed a beat or something. |
