| 00:23 | <Hixie_> | "as soon as possible" is commonly written "asap". is there an equivalent for running something as late as possible, at the last minute? |
| 00:23 | <TabAtkins> | "at the last possible moment [before X]" |
| 00:23 | <TabAtkins> | "immediately before X" |
| 00:24 | <Hixie_> | nothing nice and short like "asap"? this is something i'm considering for an attribute value. |
| 00:24 | <Hixie_> | i'm not beyond making "at the last possible moment" the value, but people will hate me for it. |
| 00:28 | <heycam> | just in time? |
| 00:28 | <Hixie_> | jit |
| 00:28 | <Hixie_> | hm, yeah, that might work |
| 00:28 | <Hixie_> | asap and jit |
| 00:38 | <jannis_> | is there somewhere to get only notified on changes interesting for web developers (new attributes, changed definitions, …)? |
| 00:42 | <jannis_> | or changes to the developers.whatwg.org part of the spec? |
| 00:42 | <Hixie_> | not really sure what's interesting to whom |
| 00:43 | <Hixie_> | you can register to be notified for changes to various subparts of the HTML spec, have you looked at that? |
| 00:45 | <jannis_> | I’m mainly interested in newly added elements and attributes, changes in the meaning of elements or attributes and dropped elements or attributes |
| 00:46 | <jannis_> | e.g. the table border attribute, which still was in the spec a year ago or two and is dropped now |
| 00:47 | <Hixie_> | oh you mean things that affect conformance criteria? |
| 00:47 | <Hixie_> | in theory, i mark all those checkins with "c" |
| 00:48 | <Hixie_> | which makes them appear with a little yellow doc with a checkmark on http://html5.org/tools/web-apps-tracker |
| 00:48 | <Hixie_> | e.g. r8109 |
| 00:49 | <TabAtkins> | Hixie_: What attribute value might this be? |
| 00:49 | <Hixie_> | dunno yet, still trying to figure out a proposal. scripts loading stuff. |
| 00:49 | <jannis_> | great, thanks! |
| 00:49 | <jannis_> | is there some sort of filter for those checkins? |
| 00:49 | <Hixie_> | jannis_: i warn you, i'm not very good at marking them :_( |
| 00:50 | <Hixie_> | jannis_: there was some filter, dunno about now |
| 00:50 | <Hixie_> | should be easy enough to hack one up if you want to though |
| 00:50 | <Hixie_> | the format is fixed |
| 00:50 | <Hixie_> | it's in the commit messages |
| 00:50 | <Hixie_> | should be trivial to parse |
| 00:58 | <jannis_> | yep, that seems to be what I was looking for |
| 00:59 | <jannis_> | now if you only mark them accordingly … ;-) |
| 01:11 | <jannis_> | another question: why is <a><p></p></a> fine but <ul><a><li></li></a></ul> isn’t? |
| 01:34 | <Hixie_> | jannis_: because the latter makes walking the list items very non-trivial |
| 01:39 | <jannis_> | I see :-) |
| 02:36 | <Hixie_> | wtf english |
| 02:37 | <Hixie_> | "A is a dependency of B" and "A's dependency on B" mean the same thing, but are opposite meanings of the word "dependency" |
| 03:33 | <zewt> | they mean the opposite thing to me: "b requires a" and "a requires b" ("foo.c is a dependency of foo.exe" <-> "foo.exe's dependency on foo.c", not "foo.c's dependency on foo.exe") |
| 03:48 | <Hixie_> | zewt: a "dependency" is a country that belongs to (depends on) another. it's also something that someone depends on. |
| 03:48 | <Hixie_> | i.e. it has both opposite meanings |
| 08:08 | <zcorpan> | am i the only one having trouble following https://www.w3.org/Bugs/Public/show_bug.cgi?id=22772 ? |
| 08:19 | <smaug____> | hmm, removing microdata |
| 08:21 | <Ms2ger> | Sounds like the rdfa people had their way |
| 09:39 | <mpt> | zcorpan, thank you for that datetime data last week. The reason I was asking is that I was designing combo date+time pickers for the Ubuntu Phone browser, and I was asked how needed they were. I guess the answer is, not much. <https://wiki.ubuntu.com/TimeAndDatePickers#datetime-local>; |
| 10:33 | <annevk> | Okay, seems IDNA thread is dead until people get back from vacation... Still unclear what needs to happen :/ |
| 10:34 | <annevk> | Seems Domenic_ is solving promises. |
| 10:37 | <zcorpan> | mpt: np. though, as i said, the data is only of front pages, so not really representative of the long tail web etc |
| 12:04 | <zcorpan> | heycam|away: is 'double screenX = 0;' bogus webidl dictionary member? (i don't see it being invalid, but maybe it should be) |
| 12:07 | <Ms2ger> | Why? |
| 12:07 | <zcorpan> | 0 is integer |
| 12:08 | <Ms2ger> | Doesn't seem like a problem to me |
| 12:09 | <Ms2ger> | Does anyone support select.selectedOptions? |
| 12:09 | <zcorpan> | maybe not. but what about 'double screenX = "";' should that be invalid webidl? |
| 12:09 | <Ms2ger> | Yes |
| 12:11 | <Ms2ger> | Doesn't seem to be |
| 12:15 | <zcorpan> | filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23077 |
| 12:35 | <annevk> | So it seems for Zip we need a file extension -> Content-Type mapping. Kinda ugly, but seems fine. |
| 12:39 | <zcorpan> | does widgets spec have that? |
| 12:43 | <annevk> | zcorpan: yes |
| 12:44 | <annevk> | zcorpan: it does content-type sniffing too, which seems kinda ugly |
| 12:46 | <gsnedders> | jgraham: I used closing to be proper, under the assumption people will just copy/paste the code. |
| 12:46 | <annevk> | And file names are byte sequences. Anything else is luck. |
| 12:47 | <jgraham> | gsnedders: Well it's a note because I didn't think it was worth arguing over, but I do think it makes the example less clear |
| 12:47 | <annevk> | So supporting nested Zips requires some kind of escaping. E.g. #path=nested.zip!image.jpg |
| 12:47 | <gsnedders> | jgraham: Would try/finally make it clearer? |
| 12:47 | <annevk> | But then if your file was named that way you'd write #path=nested.zip\!image.jpg |
| 12:47 | <annevk> | And if your file was named that way you'd write #path=nested.zip\\\!image.jpg |
| 12:48 | <jgraham> | gsnedders: Yes |
| 12:48 | <gsnedders> | jgraham: Will change, then |
| 12:48 | <jgraham> | gsnedders: OK |
| 12:49 | <annevk> | Not sure if any other \ should cause a network error... |
| 12:51 | <hsivonen> | annevk: what kind of zip files are you dealing with? |
| 12:52 | <SimonSapin> | annevk: do we really want to do nested zip files? |
| 12:52 | <hsivonen> | annevk: fwiw, EPUB invented a manifest for this even though their supported file types are heuristically detectable. |
| 12:52 | <hsivonen> | magic numbers FTW |
| 12:52 | <annevk> | hsivonen: any kind of zip file really |
| 12:52 | <gsnedders> | hsivonen: There's a hard-coded list of formats in EPUB? |
| 12:52 | <hsivonen> | gsnedders: for the ones that are required to support. |
| 12:53 | <hsivonen> | gsnedders: i.e. useful |
| 12:53 | <annevk> | hsivonen: using XMLHttpRequest you could override the type you get back though |
| 12:53 | <annevk> | SimonSapin: yes |
| 12:53 | <hsivonen> | Images have magic numbers |
| 12:53 | <hsivonen> | so do media files |
| 12:54 | <hsivonen> | the content files in EPUB are known to be XHTML or SVG, so you may assume an XML parser |
| 12:54 | <annevk> | Yeah so the way this would work is that you have the extension -> Content-Type mapping. That makes CSS and such work |
| 12:54 | <hsivonen> | CSS files are always referenced from a context where you know that you want CSS file |
| 12:54 | <annevk> | And then even though .gif will get image/gif the loader will sniff it anyway |
| 12:54 | <hsivonen> | in the EPUB case, that is. |
| 12:55 | <annevk> | hsivonen: not sure I'd like that kind of magic on the web |
| 12:55 | <gsnedders> | jgraham: Eh, all the advise I can find people giving from the past five years uses closing. |
| 12:55 | <annevk> | hsivonen: context is https://gist.github.com/annevk/6295844 |
| 12:55 | <gsnedders> | jgraham: So I'm just going to run with it. Looking closely, you need nested try blocks, which just gets ugly. |
| 12:56 | <hsivonen> | annevk: Why are you doing this as fragment identifiers instead of using the jar: scheme? |
| 12:57 | <hsivonen> | Because Architecture does not recognize nested schemes? |
| 12:57 | <SimonSapin> | annevk: shouldn’t nested zips work like nested anything? foo.zip#path=bar.zip#path=image.png#xywh=160,120,320,240 |
| 12:57 | <annevk> | hsivonen: kinda, nested schemes also creates a whole sleuth of problems with origin determination and such |
| 12:57 | <hsivonen> | annevk: What's the use case for this stuff? |
| 12:57 | <SimonSapin> | and %23 of you need # in a path |
| 12:57 | <jgraham> | gsnedders: OK |
| 12:57 | <annevk> | hsivonen: basically you'd need to special case more stuff |
| 12:57 | <annevk> | SimonSapin: no |
| 12:58 | <SimonSapin> | why not? |
| 12:58 | <hsivonen> | annevk: any reason not to use ! for path inside zip and # for regular fragment id? |
| 12:58 | <annevk> | hsivonen: distributing resources in a Zip basically. People want it for ES6 modules, sets of images, games, etc. |
| 12:59 | <hsivonen> | annevk: so why not ! ? |
| 12:59 | <annevk> | hsivonen: how do you know it's not part of the path? |
| 12:59 | <hsivonen> | like http://example.com/package.zip!dir/foo.html#heading |
| 12:59 | <annevk> | hsivonen: also, fragment is designed for this |
| 12:59 | <SimonSapin> | hsivonen: this would require server-side support |
| 12:59 | <hsivonen> | annevk: I think saying that it's "designed for this" is stretching it |
| 13:00 | <annevk> | SimonSapin: you only have one fragment identifier |
| 13:00 | <annevk> | hsivonen: fragment identifiers are for client-side resource-specific processing |
| 13:00 | <hsivonen> | ah right. can't make ! special without a new scheme |
| 13:00 | <annevk> | hsivonen: Zips fit that perfectly |
| 13:00 | <hsivonen> | annevk: fair enough |
| 13:01 | <SimonSapin> | annevk: can’t we define that a fragment for a zip file is a stuff (including path) followed by #frag for the inner resource? |
| 13:01 | <gsnedders> | You just define what the fragment identifier means for Zip files and that's it. Possibly with a # within the fragment identifier. |
| 13:01 | <gsnedders> | SimonSapin: +1 |
| 13:02 | <SimonSapin> | # is legal inside framgents, right? |
| 13:02 | <annevk> | Why not just use media fragments which already addresses this? |
| 13:02 | <gsnedders> | From an opaque URL parsing POV, there's only one. But the Zip fragment id-handling is up to whatever you define. |
| 13:02 | <gsnedders> | SimonSapin: Yes. |
| 13:02 | <SimonSapin> | annevk: because you want nesting |
| 13:03 | <gsnedders> | annevk: It's far more obvious to users, IMO |
| 13:03 | <annevk> | So # is not allowed inside a fragment. |
| 13:03 | <SimonSapin> | annevk: how do you link to an anchor/ID in an HTML file in a zip file? |
| 13:03 | <gsnedders> | annevk: Who are used to just throwing #foo on the end of a URL. |
| 13:03 | <annevk> | It's unlikely we'll have this supported for navigation |
| 13:03 | <annevk> | At least initially |
| 13:03 | <SimonSapin> | why not? |
| 13:04 | <hsivonen> | annevk: You may want to check out the EPUB prior art. I expect you end up doing something different, so be prepared for the EPUB folks yelling at you. |
| 13:04 | <annevk> | SimonSapin: complexity |
| 13:05 | <annevk> | hsivonen: I guess I should read http://www.idpf.org/epub/30/spec/epub30-ocf.html |
| 13:05 | <hsivonen> | annevk: http://www.idpf.org/epub/linking/cfi/epub-cfi.html |
| 13:05 | <annevk> | Oh, interesting |
| 13:05 | <SimonSapin> | so would it look like this? foo.zip#xywh=160,120,320,240&path=bar.zip!baz.png |
| 13:06 | <annevk> | SimonSapin: yeah |
| 13:07 | <SimonSapin> | looks backwards |
| 13:07 | <annevk> | then reorder -_- |
| 13:08 | <SimonSapin> | I picked the order on purpose, but I dislike that it’s possible to make it backwards |
| 13:08 | <gsnedders> | Not a problem, IMO |
| 13:08 | <annevk> | hsivonen: so yeah, it would not be compatible with that at all |
| 13:13 | <SimonSapin> | # in fragment seems to work fine: data:text/html,<script>document.write(window.location.hash)</script>#a#b |
| 13:15 | <gsnedders> | It works fine but is against spec. |
| 13:16 | <annevk> | Also, media fragments pioneered this already. Not really sure why we'd need yet another mechanism. |
| 13:18 | <SimonSapin> | arbitrary nesting instead of declaring media fragments are the one and only thing you want to do with URL fragments |
| 13:18 | <annevk> | I don't follow. |
| 13:20 | <SimonSapin> | if zip files have fragments like #<path>#<fragment for the inner resource>, the inner fragment doesn't have to be Media Fragments |
| 13:20 | <SimonSapin> | it could be EPUB’s thing, a bare anchor name, or anything |
| 13:28 | <annevk> | The problem with that is you'd need to type %23 and it's not very clear what the advantages are. |
| 13:28 | <annevk> | And you lose extensibility. |
| 13:30 | <annevk> | And you'd need an escape for %23 as it could occur in a file name. |
| 13:32 | <SimonSapin> | why not change the spec to allow # in fragments? |
| 13:32 | <SimonSapin> | implementations seem to be doing this already |
| 13:33 | <SimonSapin> | and it’s not ambiguous AFAIU |
| 13:33 | <annevk> | Even if you replace %23 with # in my arguments above I don't think there's much of a change |
| 13:36 | <SimonSapin> | well, # for "start of the nested fragment" and %23 for "path that contains #", just like in the actual path of an URL |
| 13:38 | <SimonSapin> | could be #path=foo.png#xywh=… if you want Media Fragment-style extensibility |
| 13:40 | <annevk> | ew |
| 13:44 | <zcorpan> | annevk: so how would you do this? not support it? zip#path=foo.html#toc |
| 13:44 | <annevk> | zcorpan: id= is a thing |
| 13:45 | <zcorpan> | ok |
| 13:45 | <annevk> | zcorpan: but as I said earlier, there's a bunch of complexity with supporting navigation so that wouldn't work at the start |
| 13:50 | <zcorpan> | http://w3c-test.org/web-platform-tests/master/html/semantics/forms/the-form-element/form-elements-nameditem-02.html - wonder if testharness.js should omit the end tag in the message |
| 13:51 | <jgraham> | zcorpan: ? |
| 13:52 | <zcorpan> | jgraham: it says "expected Element node <input type="radio" name="radio0" id="r0" value="0"></input>" |
| 13:52 | <zewt> | SimonSapin: #path=foo.png&xywh=whatever |
| 13:52 | <zewt> | not multiple #'s, that's weird |
| 13:52 | <jgraham> | Oh, it passes in gecko, so I didn't see that. Duh. |
| 13:52 | <jgraham> | (btw the Mozilla bug I cc'd you on is about testing in workers, in case you didn't realise that. I seem to recall that you had some thoughts on this) |
| 13:54 | <zewt> | (still catching up...) |
| 13:54 | <zcorpan> | jgraham: which bug? |
| 13:54 | <annevk> | I guess the \! thing is not needed. Can just use ! and it's percent-encoded variant |
| 13:55 | <jgraham> | zcorpan: https://bugzilla.mozilla.org/show_bug.cgi?id=909726 |
| 13:55 | <SimonSapin> | annevk: yes, please do not add yet one more escaping mechanism |
| 13:55 | <annevk> | Actually, that may not work |
| 13:56 | <annevk> | Not given the generic media fragment processing anyway |
| 13:56 | <SimonSapin> | how about this? #path=foo.zip&path=nested.png |
| 13:57 | <zcorpan> | jgraham: (seems i had disabled emails for when only cc changes. fixed that now) |
| 13:57 | <zewt> | annevk: so, is the basic hope that the restriction of not supporting navigation (which is needed anyway) will essentially avoid web-compat issues with using the fragment? |
| 13:57 | <annevk> | zewt: no |
| 13:58 | <SimonSapin> | http://www.w3.org/TR/media-frags/#processing-name-value-components has an example of repeated name |
| 13:58 | <jgraham> | zcorpan: Oh, that might be the default. Possibly quite sensible |
| 13:58 | <zewt> | (sitting here hoping for better than a two-letter response...) |
| 13:58 | <jgraham> | Although you would have thought that getting an email when someone adds you as a cc would be a good idea |
| 13:59 | <annevk> | SimonSapin: seems somewhat awkward |
| 14:00 | <zcorpan> | jgraham: yeah. i've ticked the box that makes cc changes notify me if i'm cc-ed. i guess that means i'll be notified when others add themselves to cc if i'm also cc-ed, but there doesn't seem to be a way to get notified only if i'm newly cc-ed... |
| 14:00 | <zewt> | well if there are web-compat issues with using fragments then I guess this is a pointless discussion, then |
| 14:00 | <annevk> | SimonSapin: also looks like generic media fragment processing cannot be done because we cannot use utf-8 necessarily so maybe that's fine |
| 14:00 | <zewt> | heh |
| 14:00 | <annevk> | zewt: what kind of web-compat issues? |
| 14:01 | <SimonSapin> | annevk: what do you mean? |
| 14:01 | <zewt> | uh, well the whole reason for not using fragments in the first place is because fragments are used all over the place, so some weirdo escaping or something would be needed |
| 14:02 | <annevk> | SimonSapin: we can probably make #path=s!s work |
| 14:02 | <annevk> | zewt: at the end of Zip files? |
| 14:02 | <SimonSapin> | annevk: because zip paths are bytes rather than unicode? |
| 14:02 | <zewt> | at the end of urls, you don't know if a url points to a zip at parse time |
| 14:02 | <zcorpan> | jgraham: speaking of workers https://critic.hoppipolla.co.uk/r/56 |
| 14:03 | <annevk> | SimonSapin: yeah |
| 14:03 | <annevk> | zewt: huh? |
| 14:03 | <annevk> | zewt: you fetch before you start looking at the fragment... |
| 14:04 | <zcorpan> | jgraham: or maybe "I'm added to or removed from this capacity" does that |
| 14:07 | <SimonSapin> | oh. http://marcosc.com/2008/12/zip-files-and-encoding-i-hate-you/ |
| 14:10 | <zewt> | so having to look at the fragment within the fetch algorithm? i guess, does anything do that now? |
| 14:11 | <zewt> | SimonSapin: zips theoretically have a flag for utf-8, but nothing uses it, so it's not much help... |
| 14:12 | <annevk> | zewt: yes, no |
| 14:12 | <smaug____> | hmm, I should figure out how to submit tests to w3c/web-platform-tests |
| 14:12 | <zewt> | i think my take on encodings for zips is to just pretend they're all utf-8 and accept the mojibake and hope clients catch up |
| 14:12 | <smaug____> | do I need a github account for that? |
| 14:13 | <annevk> | zewt: my plan was to support byte sequences, so you can open old stuff too |
| 14:13 | <zewt> | :| |
| 14:14 | <SimonSapin> | zewt: there is no display of zip filenames here afaik, but we need to extract one file given some part of the URL fragment |
| 14:14 | <zewt> | i guess it matters more for urls than js apis, since it's "can't open it at all" vs. mojibake |
| 14:15 | <SimonSapin> | oh, yes there could be mojibake with the api |
| 14:16 | <jgraham> | zcorpan: Yeah, I wonder if I can delegate that review |
| 14:19 | <annevk> | Not entirely sure what the best API would be given the byte sequence mess |
| 14:20 | <annevk> | Maybe getRawFileNames(); getDisplayFileNames(); (looks at encoding of zip, falls back to windows-1252 or so; otherwise uses utf-8, falling back to windows-1252 for invalid sequences) |
| 14:21 | <annevk> | And getFile((ArrayBuffer or DOMString)) (does same encoding trick?) |
| 14:21 | <annevk> | seems real ikcy |
| 14:26 | <SimonSapin> | or http://xkcd.com/927/ the zip format |
| 14:29 | <annevk> | that's not really an option if you want to support opening existing stuff like .docx or .epub |
| 14:30 | <annevk> | I think the API could have ArrayBuffer and String, and the latter would only go to utf-8 |
| 14:30 | <annevk> | plus list of ArrayBuffer names and list of ArrayBuffer decoded as utf-8 names |
| 14:31 | <SimonSapin> | ah, jokes taken literally :) |
| 14:32 | <annevk> | why? zip file resource names are bytes |
| 14:34 | <SimonSapin> | the suggestion to make a new archive format was a joke |
| 14:34 | <annevk> | Yeah I'm asking where I took it literally |
| 14:34 | <SimonSapin> | "not really an option…" |
| 14:34 | <annevk> | oh like that |
| 14:35 | annevk | needs sleep |
| 14:41 | <gsnedders> | annevk: It should fall back to the current locale, not necessarily windows-1252. |
| 14:41 | <annevk> | gsnedders: see the revised proposal a bit lower |
| 14:41 | <annevk> | gsnedders: less magic, more pain if you didn't use utf-8 |
| 14:41 | <gsnedders> | Also plenty of ZIP files are broken when it comes to file names. |
| 14:42 | <gsnedders> | Like, the directory index often has totally bogus stuff in it. |
| 14:42 | <gsnedders> | EPUBs especially. |
| 14:42 | <annevk> | I guess eventually we'll end up defining the parser and doing a variant of 927... |
| 14:44 | <gsnedders> | AFAIK most impls just ignore the dictionary at the end entirely. |
| 14:45 | <zewt> | err, no... |
| 14:45 | <zewt> | most implementations treat the central directory as authoritative |
| 14:45 | <zewt> | (in my experience) |
| 14:45 | <zewt> | otherwise you have to scan the entire file to get a directory listing |
| 14:46 | <gsnedders> | And then ignore filenames like \xFA\x23\xA2? |
| 14:46 | <zewt> | they don't ignore them, they just mojibake them |
| 14:46 | <gsnedders> | Last time I looked into this (with broken epub zip files) they seemed to just get ignored |
| 14:47 | <zewt> | parsers for specific formats may do things differently |
| 14:47 | <zewt> | general-purpose clients in my experience skip right to the end and read the central record |
| 14:47 | <gsnedders> | I was looking at general-purpose ones. |
| 14:48 | <gsnedders> | UnZip 6.00 seems to treat central over local filename. |
| 14:49 | <annevk> | I was just told Gecko looks at the end |
| 14:49 | <zewt> | you really need to use the central record for remote fetches, since otherwise you have to do a zillion tiny fetches to read the local headers |
| 14:50 | <gsnedders> | Yeah, indeed. |
| 14:50 | <gsnedders> | A lot of epub ZIPs have broken central dictionaries for whatever reason, though. Which is fun. zip -FF recreates it from scanning through, which suddenly makes them work everywhere. |
| 14:52 | <zewt> | yeah, the "fix zip" thing in zip clients just rewrites central from local records |
| 14:52 | <zewt> | (and maybe recalculates crcs and whatever) |
| 14:53 | <gsnedders> | Zip 3.0 at least explicitly does not recalculate CRC |
| 14:55 | <gsnedders> | explorer.exe I believe just goes through local records |
| 14:56 | <gsnedders> | Ergh, all the sanitizer tests need rewritten. |
| 14:57 | <annevk> | https://etherpad.mozilla.org/zipurls |
| 14:58 | <gsnedders> | jgraham: Thoughts on moving serializer/htmlserializer.py to serializer.py |
| 15:03 | <gsnedders> | Does removing the CDATA section state from the tokenizer have any effect on expressibility of the parser? |
| 15:20 | <smaug____> | annevk: ping |
| 15:23 | <smaug____> | or Ms2ger |
| 15:24 | <annevk> | smaug____: yo |
| 15:24 | <smaug____> | annevk: about tokenlist serialization |
| 15:25 | <Ms2ger> | Here |
| 15:25 | <smaug____> | it uses set serializer |
| 15:25 | <smaug____> | so what guarantees the order |
| 15:25 | <annevk> | I should probably rename those to ordered set parser and ordered set serializer |
| 15:26 | <smaug____> | but the idea is that it is ordered |
| 15:26 | <annevk> | yeah |
| 15:26 | <annevk> | that's why the set parser uses append and not set |
| 15:27 | <smaug____> | then "list of tokens" |
| 15:27 | <smaug____> | where is that defined |
| 15:28 | <smaug____> | if I look at http://dom.spec.whatwg.org/#dom-domtokenlist-add for example |
| 15:28 | <annevk> | "A DOMTokenList object has an associated list of unique tokens, which is initially empty." |
| 15:28 | <smaug____> | k |
| 15:28 | <annevk> | I guess I could make that ordered set of tokens and xref tokens |
| 15:29 | <annevk> | I'll make some clarifications in a bit |
| 15:29 | <SimonSapin> | is that tokens of the HTML parser? |
| 15:34 | <Ms2ger> | No |
| 15:34 | <Ms2ger> | Tokens in the class attribute |
| 15:35 | <smaug____> | annevk: what about the initial list. where is it defined how it is parsed? |
| 15:38 | <annevk> | smaug____: somewhat below http://dom.spec.whatwg.org/#concept-class |
| 15:40 | <smaug____> | hmm, per HTML spec the value is not updated when class is set to empty string |
| 15:42 | <smaug____> | "...when an element's class attribute is set to a value other than the empty string, set the element's classes to the new value, parsed." |
| 15:42 | <smaug____> | "When an element's class attribute is removed, set the element's classes to the empty list. " |
| 15:42 | <smaug____> | but what about empty string as value |
| 15:42 | <Ms2ger> | That seems like a bug |
| 15:43 | <smaug____> | Hixie_: ^ |
| 15:49 | <annevk> | smaug____: once browsers implement class="" for all elements, the HTML spec is obsolete... |
| 15:50 | <annevk> | smaug____: landed a patch in DOM around token usage btw |
| 15:50 | <annevk> | smaug____: and ordered sets |
| 15:52 | <smaug____> | annevk: thanks |
| 15:53 | <smaug____> | annevk: well, DOM spec will need to then define how the initial classList is constructed |
| 15:53 | <annevk> | smaug____: I just pointed you to where it does that |
| 15:55 | <smaug____> | (again an example how a feature has been implemented at least once, yet the specs are unclear what to implement. Specs tend to become less buggy only after 2-3 implementations. ) |
| 15:55 | <smaug____> | (which is why it is sad there isn't Presto anymore) |
| 15:57 | <smaug____> | annevk: oops, sorry, I thought that was in HTML spec :) |
| 15:58 | <annevk> | oh, so I should remove empty string? |
| 15:58 | <smaug____> | yeah |
| 15:58 | <annevk> | I wonder why we had that |
| 15:59 | <annevk> | ooh, maybe copypasta from the ID case |
| 16:01 | <annevk> | smaug____: fixed |
| 16:01 | <smaug____> | kiitos |
| 16:39 | <Hixie_> | smaug____: file a bug |
| 16:41 | <smaug____> | Hixie_: nm, I was confused. It was a bug in DOM spec and annevk fixed it |
| 16:42 | <Hixie_> | k |
| 16:42 | GPHemsley | still thinks it would be useful to allow multiple IDs point to a single element using space-separated @id |
| 16:45 | <annevk> | GPHemsley: where? |
| 16:49 | <GPHemsley> | annevk: In HTML, at least. |
| 16:49 | <GPHemsley> | But that's just a thought with no understanding of any possible implications. |
| 16:53 | <annevk> | I see... |
| 17:02 | <gavinc> | GPHemsley: well, other then breaking the heck out of element.id? ;) |
| 17:02 | <matjas> | my interpretation of the spec for the `hidden` attribute is that it should not be used for content that will _never_ become visible |
| 17:02 | <matjas> | is that correct? (http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#the-hidden-attribute) |
| 17:02 | <GPHemsley> | gavinc: It may indeed break the heck out of a lot of things. |
| 17:02 | <annevk> | matjas: it might never become visible for any given user |
| 17:03 | <matjas> | “When specified on an element, it indicates that the element is not yet, or is no longer, directly relevant to the page’s current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user.” |
| 17:03 | <matjas> | i.e. there exists a situation in which the `hidden` state is removed |
| 17:04 | <matjas> | but if i just want to hide something in the document, for everyone, in all cases, doesn’t that mean i shouldn’t use `hidden`? |
| 17:04 | <matjas> | since it’s _never_ “directly relevant to the page’s current state” |
| 17:05 | <matjas> | sounds to me like it does, but maybe i’m wrong |
| 17:11 | <Hixie_> | matjas: if you want to hide something in the document, for everyone, in all cases, just don't put it in? |
| 17:19 | <matjas> | Hixie_: here’s the use case http://mathiasbynens.be/notes/json-dom-csp#hidden-element |
| 17:19 | <Hixie_> | why would CSP not be satisfied with inlined JSON? |
| 17:20 | <Hixie_> | <script> is the appropriate element to use here |
| 17:20 | <Hixie_> | hidden="" is wrong. display:none is even more wrong. |
| 17:20 | <matjas> | CSP blocks inline <script>s |
| 17:20 | <Hixie_> | "blocks" how? |
| 17:20 | <matjas> | doesn’t execute its contents |
| 17:20 | <Hixie_> | it's JSON, you're not supposed to execute it? |
| 17:21 | <Hixie_> | <script type="application/json"> ... </script> |
| 17:21 | <matjas> | you want to assign it to a variable or something like that so you can use it in JS |
| 17:21 | <matjas> | so you’d use <script type=application/json> (also mentioned on that page) |
| 17:21 | <matjas> | k got it |
| 17:21 | <Hixie_> | yeah |
| 17:21 | <Hixie_> | (just got there) |
| 17:21 | <Hixie_> | that's the way to include data blobs in html |
| 17:22 | <matjas> | i asked about this a few weeks back and the suggested solution was to use a custom data-* attribute |
| 17:22 | <matjas> | (here in #whatwg, i mean) |
| 17:22 | <Hixie_> | well it depends what you're doing |
| 17:23 | <Hixie_> | if you have a big blob, not associated with an element, then <script> data blocks are the way to go |
| 17:23 | <Hixie_> | if you have data associated with an element, data-* is good |
| 17:23 | <matjas> | would you mind leaving a comment there saying just that? thanks |
| 17:24 | <Hixie_> | can't right now but feel free to copy/paste commentsa bove |
| 17:26 | <annevk> | Anyone with shorter names for getFileNames and getRawFileNames? |
| 17:27 | <annevk> | (assume I just lowercased the "N" per established convention) |
| 17:27 | <gsnedders> | jgraham: Do you understand the sanitizer at all? |
| 17:29 | <jgraham> | gsnedders: Yes. But the bar for not understanding something "at all" is rather high. |
| 17:32 | <gsnedders> | jgraham: Explain how disallowed_token doesn't break everything? |
| 17:38 | <jgraham> | Wow, that's terrible code |
| 17:39 | <jgraham> | But I'm not clear that it necessarily has to break everything |
| 17:39 | <jgraham> | I'mm not clear that it doesn't either |
| 17:39 | <jgraham> | Like I said |
| 17:39 | <jgraham> | Oh, right |
| 17:39 | <jgraham> | It shouldn't break everything |
| 17:40 | <jgraham> | It is trying to convert all disallowed tokens to character tokens |
| 17:41 | <gsnedders> | Yeah, I eventually worked that out just before you said that. |
| 17:41 | <gsnedders> | Big problem: attribute/element lists are namespace unaware. |
| 17:41 | <gsnedders> | Do I deal with this by post-processing the lists, or do I change the lists? |
| 17:42 | <jgraham> | Well |
| 17:42 | <jgraham> | I would say that you could use a syntax like svg:foo and post-process that |
| 17:44 | <gsnedders> | Yeah, indeed. |
| 17:44 | <gsnedders> | That's what I meant. |
| 17:44 | <gsnedders> | That's what it currently does. |
| 17:44 | <gsnedders> | Without the post-processing. |
| 17:45 | <jgraham> | Oh |
| 17:47 | <gsnedders> | Oh, this is really quite the mess. |
| 18:02 | <jwalden> | Hixie_: Link: foo.xbl to style plaintext is one of the scariest things I've ever heard of here |
| 18:17 | <Hixie_> | jwalden: why is it scary? |
| 18:18 | <jwalden> | Hixie_: XBL, mutating random content, the usual scary |
| 18:18 | <Hixie_> | pah |
| 18:18 | <Hixie_> | :-) |
| 18:18 | jwalden | shakes fist at QA ;-) |
| 18:36 | <annevk> | During dinner I decided on getNames() / getRawNames() |
| 18:36 | <annevk> | Rough overview of the entire thing is at https://etherpad.mozilla.org/zipurls |
| 18:37 | <annevk> | Will add it to Fetch in due course. Constructing Zip files isn't added yet. Starting conservatively. |
| 18:38 | <annevk> | Domenic_: for zlib APIs... Any ideas as to how those should look? |
| 18:40 | <Domenic_> | annevk: probably http://nodejs.org/api/zlib.html#zlib_convenience_methods but with ArrayBuffer instead of Node's custom Buffer and promises instead of callbacks. Streaming versions would be nice once we figure out streams. |
| 18:44 | <annevk> | Domenic_: so it seems kinda bad to expose the name zlib like that, given that it's a specific implementation |
| 18:44 | <annevk> | Domenic_: but okay, deflate(any) -> promise makes sense |
| 18:45 | <Domenic_> | annevk: sure, it doesn't have to be `zlib.`. Ideally it would be `import { unzip, deflate } from "@web/compress"` or similar. |
| 18:46 | <annevk> | It'll be interesting to see when the module thing happens... |
| 18:47 | <Domenic_> | sigh, yes. |
| 19:51 | <zcorpan> | is there a webkit or blink browser that supports switching style sheet sets? |
| 19:51 | <Hixie_> | using ui? |
| 19:52 | <zcorpan> | yeah |
| 19:52 | <Hixie_> | not to my knowledge :-( |
| 19:55 | <zcorpan> | it seems webkit/blink don't support switching with JS either, unless i'm missing something |
| 19:56 | <Hixie_> | i thought there was some api |
| 19:56 | <Hixie_> | that webkit implemented |
| 19:56 | <Hixie_> | as hyatt |
| 19:56 | <Hixie_> | er, ask hyatt, rather |
| 20:04 | <zcorpan> | hmm, i see selectedStylesheetSet but the spec has selectedStyleSheetSet. and setting it doesn't switch stylesheets |
| 20:06 | <Hixie_> | i think the name may have been changed in the spec to avoid clashing when the semantics were changed? |
| 20:12 | <zcorpan> | annevk: ^ |
| 20:17 | <annevk> | zcorpan: that's when Hixie_ changed the semantics, not I |
| 20:17 | <annevk> | zcorpan: that API is kinda hopeless, nobody is really interested |
| 20:18 | <gsnedders> | jgraham: #110 may be on interest. Gets the tokenizer working roughly as a treewalker |
| 20:18 | <Hixie_> | yeah, alternative style sheets in general have rather failed |
| 20:18 | <zcorpan> | maybe we should drop it |
| 20:18 | <Hixie_> | as much as it would pain me to agree, yeah |
| 20:18 | <annevk> | There's a lot of potential simplicity gain there |
| 20:18 | <Hixie_> | yeah |
| 20:18 | <Hixie_> | should see if mozilla would drop it |
| 20:19 | <Hixie_> | i think it's very sad that we'd remove it, but it is a lot of complexity for something that virtually nobody uses |
| 20:19 | <annevk> | We accept bug reports / patches :) |
| 20:19 | <gsnedders> | jgraham: Nothing's been done about getting tests running yet, though |
| 20:19 | <Hixie_> | annevk: i don't believe in pushing my agenda in bug reports and even less in patches |
| 20:20 | <annevk> | More visible than G+ :p |
| 20:21 | <Hixie_> | visible how? |
| 20:22 | <Hixie_> | i have like 10,000 people following me on g+ :-P |
| 20:23 | <annevk> | I do file bug reports, mostly to get a sense of what people think about a particular issue... Why don't you believe in them? |
| 20:33 | <Hixie_> | i don't want to make people do things without them thinking they're a good idea, and i'm worried that if i file a bug saying "do X", some browser vendors will do it without thinking about whether i'm wrong or not |
| 20:33 | <Hixie_> | i figure if i'm right, someone else will agree enough to file a bug |
| 20:33 | <Hixie_> | and if nobody can be bothered, i'm probably not right |
| 20:34 | <jgraham> | DODo |
| 20:34 | <jgraham> | oops |
| 20:34 | <jgraham> | Bad connection |
| 20:34 | <Hixie_> | you using irssi? |
| 20:34 | <jgraham> | File a bug saying "do X iff bz think's it's a good idea" |
| 20:34 | <jgraham> | Yeah |
| 20:35 | <Hixie_> | can you understand wtf is up with irssi acting weird when the connection is bad? |
| 20:35 | <Hixie_> | i don't understand how it's possible |
| 20:35 | <Hixie_> | ssh runs over tcp |
| 20:35 | <Hixie_> | surely that means that there should be no way to tell when the connection is bad |
| 20:36 | <jgraham> | Well I think what just happened wasn't an irssi problem, more that I thought the connection was dead and tried to escape ssh, but irssi eventually sent some of the characters |
| 20:37 | <Hixie_> | ah |
| 20:37 | <Hixie_> | i find that when i get a lot of packet loss, i start seeing ansi sequences in my irssi input |
| 20:37 | <Hixie_> | from pressing arrow keys, etc |
| 20:37 | <Hixie_> | and i have zero understanding of how that is possible |
| 20:38 | <Hixie_> | (running ssh in a mac Terminal, to a machine running screen with irssi in a buffer) |
| 20:44 | <gsnedders> | Anyone here understand regexp engines here? |
| 20:44 | <gsnedders> | s/here\?/?/ |
| 20:44 | <Ms2ger> | You |
| 20:45 | <jgraham> | gsnedders: Just ask your question :p |
| 20:48 | <gsnedders> | Given a string like "aaabaaabaaad" and a regexp like /a+ba+d/, if you match that as a DFA you get to the second "b" in the input string before you reject the string from the DFA. How do you know where in the input string to start matching again? Can you avoid doing the naïve one starting offset at a time? |
| 21:03 | <gsnedders> | http://swtch.com/~rsc/regexp/regexp3.html deals with this, actually |
| 21:14 | <Hixie_> | how am i supposed to know from script when the html parser has finished parsing an element? o_O |
| 21:28 | <rillian> | Hixie_: is there a reason not to write some trivial display rules for TextTrackCue and give it a plain-text constructor? |
| 21:28 | <rillian> | I mostly say this because I don't approve of all the positional stuff in WebVTT |
| 21:29 | <Hixie_> | rillian: why wouldn't we just fix webvtt instead? |
| 21:40 | <jannis_> | When I have <pre><img></pre>, is the alt="" subject to pre? |
| 21:44 | <rillian> | Hixie_: didn't you resign as editor because no one wanted to fix WebVTT? |
| 21:44 | <Hixie_> | no, i handed WebVTT to Silvia because I was trying to offload work and she volunteered |
| 21:44 | <Hixie_> | (that, and implementors didn't want to do what i wanted) |
| 21:44 | <rillian> | heh |
| 21:45 | <Hixie_> | jannis_: yes |
| 21:45 | <rillian> | I did like your idea to standardizing a file format for the legacy CC streams |
| 21:45 | <rillian> | that seemed the only way to meet implementor concerns without adding all these features to webvtt |
| 21:46 | <jannis_> | Hixie_: thx |
| 21:48 | <jannis_> | but there is no way (and no way intended) to use html elements in the img’s alternate content, is it? |
| 21:54 | <Hixie_> | jannis_: yeah, just use <object> instead of <img> |
| 21:55 | <Hixie_> | script preloading proposal on the list |
| 21:55 | <jannis_> | oh, does that work? |
| 21:55 | <Hixie_> | jannis_: should do |
| 21:55 | <jannis_> | great :) |
| 22:24 | <TabAtkins> | Hixie_: How do you match the urls in your needs='' attribute? Split on spaces, fully resolve, then compare url-wise? |
| 22:24 | <TabAtkins> | Ah, I see, yes, that's exactly it. |
| 22:39 | <Hixie_> | TabAtkins: yeah |
| 22:39 | <Hixie_> | i realised after posting that i should also fire an event if the script doesn't run |
| 22:49 | <heycam> | zcorpan, I think 'double screenX = 0;' is not bogus, due to the "The type of an integer token is the same as the type of the constant, dictionary member or optional argument it is being used as the value of." sentence |