| 00:08 | <marcosc> | Hixie: I added the basic abuse case - http://w3c-webmob.github.io/wake-lock-use-cases/#potential-for-abuse |
| 00:08 | <marcosc> | I'm asking on Twitter for more |
| 00:08 | marcosc | heading home now... but if anyone has any others please let me know |
| 00:10 | <caitp> | i guess that would be a fun bug for some college kids to work on at least, so it's got that going for it |
| 12:00 | <JakeA> | Anyone awake enough to set me up an account on the whatwg wiki? |
| 12:03 | <jgraham> | JakeA: Sure I can do it |
| 12:04 | <JakeA> | jgraham: Cheers! |
| 12:05 | <JakeA> | jgraham: jakearchibald jaffathecake⊙gc |
| 12:31 | <MikeSmith> | the "polyglot" document is very consistent about being really sloppy |
| 12:32 | <Ms2ger> | Ha |
| 12:33 | <MikeSmith> | if you look at the Status section at http://www.w3.org/TR/2014/WD-html-polyglot-20140204/ and find the link with the hypertext "facilitate migration to and from XHTML" and you follow it.. it goes to http://www.w3.org/html/wg/drafts/html/master/document-metadata.html#charset "Specifying the document's character encoding" |
| 12:33 | <MikeSmith> | ...which says nothing about how to "facilitate migration to and from XHTML" |
| 12:34 | <MikeSmith> | and there's a pattern of instances of stuff like that throughout the document |
| 12:37 | <Ms2ger> | You're not supposed to click the links |
| 12:42 | <MikeSmith> | no, you're supposed to put yourself in the mind of the authors before you click the links |
| 16:04 | <Domenic> | Has nobody built something that auto-generates JS function headers from WebIDL? |
| 16:08 | <MikeSmith> | Domenic: as opposed to C++ function headers? I would that somebody from a browser project had moved some feature completely to JS might must have |
| 16:08 | <MikeSmith> | I mean I think there have been some cases of things being moved to JS |
| 16:09 | <Domenic> | MikeSmith: well, I am starting that browser project to move features completely to JS, so... not here at least :P |
| 16:09 | <caitp> | do optional parameters in webidl affect the arity of a function / are they supposed to? |
| 16:09 | <MikeSmith> | not just abarth's marquee implementation, but other things earlier |
| 16:10 | <MikeSmith> | Domenic: maybe something over there in gecko (me waves hands around a bit) |
| 16:20 | <jgraham> | We can do you C++ or Rust, but not js |
| 16:28 | <Ms2ger> | Domenic, we have JS-implemented stuff, but I don't think anything to generate stub implementations |
| 16:29 | <Domenic> | Ms2ger: thanks... I'll probably start something on GitHub then ^_^ |
| 16:31 | <Domenic> | Oh wait, I guessed a URL and found marcosc's https://www.npmjs.org/package/webidl |
| 16:36 | <MikeSmith> | さすがmarcosc |
| 16:44 | <TabAtkins> | caitp: Yes, they do affect the arity. |
| 16:44 | <TabAtkins> | caitp: ...pretty sure. |
| 16:45 | <caitp> | weird, that's pretty different behaviour from the standard library |
| 16:45 | <TabAtkins> | ? |
| 16:46 | <caitp> | from JS builtins |
| 16:46 | <TabAtkins> | Is it? |
| 16:47 | <TabAtkins> | Really, it depends on whether they translate to JS as just a normal arg (and only affect the arity/type checking), or if they translate as an arg defaulted to undefined. |
| 16:47 | <caitp> | well, it probably varies a lot, but it's frequently "this function has 3 parameters, but a length of 1" |
| 16:47 | <cryptic> | should you set content-type to "application/csv" for csv files? |
| 16:47 | <TabAtkins> | caitp: Oh, you might have misunderstood me. |
| 16:47 | <TabAtkins> | I meant that optional args should *not be counted* in the arity. |
| 16:47 | <cryptic> | my browser doesn't recognize that mime type, which seems dumb |
| 16:47 | <caitp> | ah |
| 16:48 | <TabAtkins> | cryptic: Try text/csv? |
| 16:48 | <cryptic> | TabAtkins: doesn't text imply ascii? |
| 16:48 | <TabAtkins> | No. |
| 16:48 | <cryptic> | oh, perfect |
| 16:49 | <TabAtkins> | text/html certainly doesn't, for example. |
| 16:49 | <TabAtkins> | It just implies that it's a textual format, as opposed to one of the binary formats. |
| 16:49 | <cryptic> | but html is ascii |
| 16:49 | <TabAtkins> | No, HTML is definitely not ASCII. |
| 16:49 | <TabAtkins> | All of the language-defined stuff is ASCII, yes, but HTML pages are not. |
| 16:49 | <TabAtkins> | (Rather, is within the ASCII range, which is far different from *being* ASCII.) |
| 16:50 | <cryptic> | right, that's what I mean: "text/html" refers to the language of the page content, which is html (ascii) |
| 16:50 | <cryptic> | that the browser ultimately does with that information is beyond the jurisdiction of http |
| 16:50 | <TabAtkins> | No. The page content is some HTML tags and a bunch of textual content. The latter is not required to be ASCII, and often is not. |
| 16:51 | <TabAtkins> | HTML doesn't distinguish between tags and text as being "HTML content". |
| 16:51 | <cryptic> | it's all html content |
| 16:51 | <TabAtkins> | And HTML tags use characters in the ASCII range of unicode, which may or may not be ASCII-compatible in your chosen encoding. |
| 16:51 | <TabAtkins> | cryptic: I know it's all HTML content. That's what I"m saying. |
| 16:54 | <cryptic> | at the end of the day, it doesn't matter between text/csv and application/csv; I'm just not sure which one comports with the specifications (that some browsers correctly display unescaped unicode characters is not behavior the specs would lead one to expect) |
| 16:55 | <cryptic> | but I guess if text meant ascii, it'd be ascii/* and not text/* |
| 16:56 | Ms2ger | notes the topic |
| 16:58 | <gsnedders> | Defining "text" is hard :) |
| 17:06 | <TabAtkins> | cryptic: If you've been specifying an ASCII charset and escaping all your non-ASCII character in HTML all this time, just in case someone was following some obsolete directive from some ancient version of the text/* definition, then I"m very sorry. ^_^ |
| 17:07 | <gsnedders> | TabAtkins: hey, Hixie publishes the spec as US-ASCII! |
| 17:07 | <TabAtkins> | ...why? |
| 17:07 | <Ms2ger> | So that he can push it to the IETF, duh |
| 17:07 | <gsnedders> | he got fed up of having issues with dev.w3.org and Content-Type headers specificing charset |
| 17:08 | <gsnedders> | IIRC |
| 17:08 | <gsnedders> | and just changed it to use US-ASCII everywhere |
| 17:08 | <TabAtkins> | Oh, huh. I have no idea what those issues might be, since we all use utf-8 in CSS. |
| 17:08 | <gsnedders> | source is UTF-8, but the published specs are ASCII |
| 17:08 | <gsnedders> | idk, this was years ago this was chnged |
| 17:08 | <gsnedders> | *changed |
| 17:08 | <TabAtkins> | That's silly. |
| 17:09 | <Ms2ger> | W3C? It happens |
| 17:09 | <Hixie> | gsnedders: actually source is ascii but i now publish as utf-8 |
| 17:09 | <Hixie> | then again, i don't publish on the w3c site anymore |
| 17:11 | <gsnedders> | Hixie: well you parse source as utf-8 from memory! :P |
| 17:11 | <gsnedders> | or rather used to |
| 17:11 | <Hixie> | i do parse as utf-8 |
| 17:11 | <Hixie> | i mean, utf-8 is a superset of ascii, so... |
| 17:11 | <Hixie> | anyway, i don't use anolis anymore |
| 17:12 | <Hixie> | and once i've written my splitter, i won't use html5lib at all anymore :-) |
| 17:12 | gsnedders | remembers he was meant to see how fast Hixie's parser was |
| 17:13 | <Hixie> | oh, yeah |
| 17:13 | <Hixie> | how should we do that? |
| 17:14 | <Hixie> | can i get you a binary or something? |
| 17:14 | <Hixie> | what should it do? |
| 17:14 | <Hixie> | or do you want to compile from source? |
| 17:14 | <gsnedders> | well I'm on holiday now with nothing more than a kinda weak laptop, so let's not worry for now |
| 17:14 | <Hixie> | k |
| 17:15 | <gsnedders> | also what seems like a ridiculously slow internet connection :) |
| 17:37 | <Hixie> | ok i'm not entirely done yet but this patch is getting out of hand so i'm going to commit it soon |
| 17:37 | <Hixie> | anyone see any blockers? http://www.whatwg.org/specs/web-apps/current-work/ |
| 17:38 | <Hixie> | (if you see them, mention them here. i'm going to be afk for about an hour, then i'll commit it) |
| 18:13 | <Hixie> | no comments, huh |
| 18:13 | <Hixie> | ok |
| 18:27 | <Ms2ger> | Hixie, my browser still doesn't like the single-page spec :) |
| 18:27 | <Hixie> | yeah |
| 18:27 | <Hixie> | that's unlikely to change |
| 18:28 | <Hixie> | in fact the pipeline change made it quite a bit fatter |
| 18:28 | <Hixie> | since i have way more IDs now |
| 18:30 | <jgraham> | The spec's not done until Mozilla* won't run? [*on Ms2ger's laptop] |
| 18:31 | <Ms2ger> | I wonder what it does in Servo |
| 18:37 | <gsnedders> | Hixie: can I bat my eyelids and ask for ids on all parse errors again? ;P |
| 18:58 | GPHemsley | wonders aloud (again?) about whether there will ever be an Acid4 test |
| 18:59 | <Ms2ger> | No |
| 19:07 | <caitp> | so end-tags can have attributes? |
| 19:07 | <caitp> | huh |
| 19:17 | <Hixie> | gsnedders: unique unchanging ones? |
| 19:18 | <Hixie> | gsnedders: what's the use case again? |
| 19:21 | <gsnedders> | Hixie: yeah; for the sake of html5lib-tests being able to assert the correct parse-error is being hit |
| 19:21 | <gsnedders> | instead of just "a parse error was hit here" |
| 19:22 | <Hixie> | is that a good thing? i mean, we don't want to make implementations have to track exactly what parse error was hit |
| 19:22 | <Hixie> | it prevents quite a few interesting optimisations |
| 19:22 | <Hixie> | e.g. several times i coallesced parse errors |
| 19:22 | <gsnedders> | AFAICT you either want to track them exactly or ignore them entirely |
| 19:22 | <Hixie> | nah |
| 19:23 | <Hixie> | the point of parse errors is to tell the author that there's a problem |
| 19:23 | <Hixie> | the author doesn't care whether it came from section 12.6.34.2.4 or section 12.6.33.1.6.4 |
| 19:23 | <Hixie> | the author just wants to know that their < is missing |
| 19:23 | <Hixie> | or whatever |
| 19:24 | <Domenic> | TabAtkins: fix the missing </pre> in http://dev.w3.org/csswg/css-color/ so I can tweet about how cool it is? |
| 19:24 | <gsnedders> | so html5lib-python I think uses strings that aren't actually entirely unique to deal with stuff like this |
| 19:24 | <gsnedders> | so maybe we don't want actual ids |
| 19:24 | <gsnedders> | maybe an @data-parse-error='missing <' or smth |
| 19:25 | <TabAtkins> | Domenic: Where is it? |
| 19:25 | <TabAtkins> | Whoops, it's a missing <code> I think. |
| 19:25 | <TabAtkins> | </code>, rather. |
| 19:26 | <Hixie> | gsnedders: again, i don't think that works. There are places where I just fire "something's wrong" and it could be any number of parse errors. |
| 19:26 | <Hixie> | gsnedders: other places the spec has one parse error line, but the message should vary dramatically in an implementation giving useful advice |
| 19:28 | <gsnedders> | I want something that makes sense to test that the implementation does useful advice. I don't care how we do this! |
| 19:28 | <TabAtkins> | Domenic: fixed |
| 19:28 | <Domenic> | TabAtkins: ah right yeah, code makes more sense |
| 19:29 | <Domenic> | TabAtkins: still there "custom stringifiers on the stringifiers object..." |
| 19:29 | <TabAtkins> | Sorry, forgot to commit. |
| 19:29 | <Hixie> | gsnedders: i'm not sure how the spec can help there |
| 19:29 | <TabAtkins> | It was fixed in my local copy, I don't see what the problem si. |
| 19:30 | <Hixie> | gsnedders: "useful" is something that is too subjective |
| 19:40 | gsnedders | concludes playing Super Mario Bros is more fun than working out what "useful" is :) |
| 20:13 | <Domenic> | Ms2ger: are these the only tests that exist for select? https://github.com/w3c/web-platform-tests/tree/175953ab7f14aedbcf2a5219ede4387bc86a3b91/html/semantics/forms/the-select-element |
| 20:13 | <Ms2ger> | Possibly |
| 20:15 | <gsnedders> | does anyone have data for how common with/direct-eval are in JS on the web as a whole? |
| 20:15 | <caitp> | can we add a test that asserts one particular way to behave when options are dynamically added to a select control? |
| 20:15 | <TabAtkins> | Ask on es-discuss, I'm sure someone's got some data. |
| 20:15 | <caitp> | i want browsers to do something consistent there :[ |
| 20:16 | <gsnedders> | TabAtkins: bah, I'm not subscribed to es-discuss any more! |
| 20:17 | <jgraham> | gsnedders: Seems unlikely? Well unless people are instrumenting actual js engines I suppose. Are they? |
| 20:17 | <Ms2ger> | Good call |
| 20:20 | <gsnedders> | jgraham: you could do it at an AST level, and you guys definitely have some instrumentation in SM |
| 20:20 | <gsnedders> | jgraham: so you can do it cheaply |
| 22:11 | <smaug____> | dglazkov_: so do you or someone else from blink team have plans to go through all the in-doc vs. not-in-doc cases and file spec bugs when stuff should work also in shadow DOM ? |
| 22:11 | <smaug____> | currently implementing shadow dom in interoperable way isn't really a trivial task |
| 22:12 | smaug____ | will be going through about 800 cases when gecko uses IsInDoc or GetCurrentDoc |
| 22:14 | <smaug____> | oh, it wasn't quite that much |
| 22:14 | <smaug____> | perhaps only 400 |
| 22:17 | <mitchell> | Hello. Would you guys please help me find a list or table of 63 established *-English Braille symbols (1 cell, 6-dots) and their correlating ASCII characters? |
| 22:19 | <mitchell> | for instance, http://www.duxburysystems.com/braillechart.asp but limited to one cell |
| 22:20 | <mitchell> | actually, words 63 words instead of characters would be okay too |
| 22:37 | <TabAtkins> | mitchell: You looking for the character information? Here's all of Braille in Unicode: http://symbolcodes.tlt.psu.edu/bylanguage/braillechart.html |
| 22:37 | <TabAtkins> | But that doesn't help with the definitino of them. What are you having trouble finding, precisely? |
| 22:46 | <mitchell> | TabAtkins: yea, I need an alphabet which gives meaning to those symbols. my goal is write a 2 character identifier on ~2,000 pieces of paper in both English and Braille. |
| 22:47 | <mitchell> | s/alphabet/dictionary |
| 22:47 | <TabAtkins> | What's lacking in http://www.duxburysystems.com/images/bana_black.pdf ? |
| 22:49 | <mitchell> | I thought it was what I needed at first, and maybe I'm misunderstanding it, because it seems to use multiple cells |
| 22:49 | <TabAtkins> | For some words, yes. |
| 22:49 | <TabAtkins> | But the letters are single-cell. |
| 22:49 | <mitchell> | so, for example "child". that is 1 cell, and "children" is 2? |
| 22:51 | <mitchell> | I think I'm getting a little more clear with it. I think I'll just need to cross out the multi-cell terms and then it'll be good, hopefully |
| 22:51 | <TabAtkins> | The word "child" appears to be, yes. |
| 22:52 | <TabAtkins> | Note that "child" apparentlyl has the special rule that it must be surrounded by spaces. |
| 22:52 | <mitchell> | whoa, good point |
| 22:54 | <jsbell> | nifty, didn't know Braille had an extra layer |
| 22:54 | <mitchell> | the pattern that I'm seeing is that I'm basically picking up 2-letter combinations with the remaining 36 (63-27) symbols |
| 22:54 | <mitchell> | jsbell: what do you mean by layer? |
| 22:55 | <jsbell> | That it's not just 1:1 with English glyphs. |
| 22:55 | <TabAtkins> | mitchell: Yeah, it seems like the remaining symbols are for word shortening. |
| 22:56 | <jsbell> | Like a standard set of abbreviations that include special use non-letter "glyphs" |
| 22:56 | <jsbell> | I wish I was young enough to learn Classic Mayan script. :P |
| 22:56 | <caitp-> | you are! |
| 22:57 | <mitchell> | jsbell: yea, shortened words seems to be common across different Braille systems (as far as my reading today shows) |
| 22:57 | <mitchell> | TabAtkins: thanks for helping me understand this chart better |
| 22:58 | <TabAtkins> | mitchell: No problem. |