| 01:11 | <Hixie> | well, so far tricky01.dat is living up to its name |
| 01:11 | <Hixie> | test 1 was a huge pain to fix |
| 01:11 | <Hixie> | and now test 2 is failing |
| 01:39 | <zewt> | http://www.libpng.org/pub/png/libpng-1.4.0-manual.pdf that's one funny-looking "libpng.txt" |
| 02:08 | <Hixie> | good grief |
| 02:08 | <Hixie> | tricky01 sure is living up to its name |
| 02:38 | <SamB> | Hixie: the scariest part has got to be the "01" |
| 02:38 | <Hixie> | yeah, though sadly there's no 02 |
| 02:39 | <SamB> | wait, you *like* scary testsuites? |
| 02:40 | <Hixie> | uh, yeah, they're awesome |
| 02:40 | <Hixie> | :-D |
| 02:51 | <Hixie> | ok test 8 in trick01 is just wrong. it's missing a bunch of parse errors. |
| 06:03 | <MikeSmith> | zcorpan: question about file:///opt/workspace/picture-element/index.html#parse-srcset-attr |
| 06:04 | <MikeSmith> | oofs |
| 06:04 | <zcorpan> | MikeSmith: yep? |
| 06:04 | <MikeSmith> | http://picture.responsiveimages.org/#parse-srcset-attr |
| 06:04 | <annevk> | https://github.com/nolanw/HTMLReader |
| 06:04 | <annevk> | I wonder how many languages are left without a decent HTML parser these days |
| 06:04 | <MikeSmith> | zcorpan: "descriptors" vs "descriptor list" |
| 06:05 | <MikeSmith> | annevk: Swift? |
| 06:05 | <annevk> | It would still be good if libxml2 added support I think, due to all the binding support for it all over |
| 06:05 | <annevk> | MikeSmith: heh |
| 06:05 | <MikeSmith> | heh on me :) I hadn't actually looked at that page before I made that comment.. |
| 06:06 | <MikeSmith> | I mean it's not Swift but it's not what I was expecting |
| 06:06 | <zcorpan> | MikeSmith: "descriptor list" is set to "descriptors" in step 9 |
| 06:06 | <MikeSmith> | oh |
| 06:06 | MikeSmith | looks again |
| 06:07 | <MikeSmith> | I guess I shouldn't try to read specs with my screen dimmed way down to save battery |
| 06:07 | <MikeSmith> | zcorpan: wait though |
| 06:07 | <MikeSmith> | 9. Add candidate: Add url to raw candidates, associated with descriptors. |
| 06:08 | <MikeSmith> | that part is clear |
| 06:08 | <zcorpan> | MikeSmith: i'll probably tweak this to be less confusing, there's a bug about running the parser for each candidate as they are parsed instead of first adding to raw candidates |
| 06:08 | <MikeSmith> | zcorpan: ok |
| 06:09 | <MikeSmith> | that won't effect me at least because I parse them right away anyway |
| 06:09 | <MikeSmith> | I don't ever actually store the URLs |
| 06:09 | <zcorpan> | yeah |
| 06:10 | <zcorpan> | so is something not clear still? |
| 06:10 | <MikeSmith> | zcorpan: anyway I think it would be worth making descriptors -> list descriptor list more clear |
| 06:10 | <MikeSmith> | or really, I don't understand why you're using both |
| 06:11 | <MikeSmith> | why not just consistently use one or the other? |
| 06:12 | <zcorpan> | yeah so when i fix the bug i can get rid of "raw candidates" completely |
| 06:12 | <MikeSmith> | oh, ok |
| 06:13 | <zcorpan> | i haven't touched it yet because it's editorial so low prio |
| 06:13 | <MikeSmith> | sure |
| 06:15 | <MikeSmith> | zcorpan: so anyway my other question is, why does the parsing algorithm allow for multiple descriptors in image candidate strings at all? |
| 06:16 | <zcorpan> | MikeSmith: for future compat |
| 06:16 | <MikeSmith> | aha |
| 06:16 | <MikeSmith> | I guess I'm pretty skeptical about the value of writing future compat into specs |
| 06:17 | <MikeSmith> | e.g., hearing that it, is reminds me of ARIA allowing multiple roles in @role values |
| 06:17 | <MikeSmith> | but I guess that's an unfair comparison |
| 06:18 | <annevk> | MikeSmith: how are you going to address the integrity attribute? |
| 06:18 | <annevk> | MikeSmith: context: http://w3c.github.io/webappsec/specs/subresourceintegrity/ |
| 06:18 | <zcorpan> | aria should have banned multiple roles for authors but the parsing was good |
| 06:18 | <MikeSmith> | zcorpan: so as long you're going to be making editorial changes, you might consider adding a note about that future-compat reason |
| 06:18 | <zcorpan> | MikeSmith: ok thx |
| 06:19 | <MikeSmith> | annevk: I think somebody mentioned that to me the other day and my thought was, that should be in the HTML spec if they want it to be part of the language |
| 06:21 | <MikeSmith> | but I think that what somebody mentioned to me was actually another attribute from a different webappsec spec that's also not in HTML yet |
| 06:21 | <MikeSmith> | yeah |
| 06:21 | <MikeSmith> | it was "nonce" |
| 06:21 | <MikeSmith> | annevk: kinda seems like they're making a habit of it |
| 06:22 | <MikeSmith> | annevk: I propose that they open bugs against the HTML spec for those |
| 06:22 | <MikeSmith> | I wonder if Hixie even knows about them yet |
| 06:22 | <zcorpan> | MikeSmith: the integrity thing might end up as a srcset descriptor later :-) |
| 06:22 | <MikeSmith> | I guess he knows about "nonce" |
| 06:22 | <annevk> | oh, that's CSP stuff? |
| 06:22 | <annevk> | Yeah, we should open bugs for that |
| 06:23 | <MikeSmith> | zcorpan: can't tell if you're trolling but I hope so |
| 06:23 | <zcorpan> | MikeSmith: no |
| 06:23 | <MikeSmith> | oh geez |
| 06:24 | <zcorpan> | how else would you do it if you want to use integrity + srcset? |
| 06:24 | <MikeSmith> | dunno |
| 06:24 | <zcorpan> | well then :-P |
| 06:24 | <MikeSmith> | because I don't really know anything about the "integrity" attribute so I don't count |
| 06:25 | <MikeSmith> | incidentally, "SRI" doesn't seem like such a great choice for a shortname |
| 06:26 | <MikeSmith> | annevk: maybe ask Mike West if he can raise the bugs |
| 06:26 | <MikeSmith> | since he's a friendly and clueful |
| 06:26 | zcorpan | notices http://w3c.github.io/webappsec/specs/subresourceintegrity/#the-noncanonical-src-attribute-todo ... |
| 06:26 | <annevk> | MikeSmith: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26081 |
| 06:27 | <MikeSmith> | damn man, these specs |
| 06:27 | <MikeSmith> | "Nonce sources require a new attribute to be added to both script and style elements: nonce." |
| 06:27 | <MikeSmith> | really? |
| 06:27 | <annevk> | MikeSmith: I'm not as concerned with WebAppSec |
| 06:28 | <annevk> | MikeSmith: now WebPerf... |
| 06:28 | <MikeSmith> | no comment there |
| 06:28 | <MikeSmith> | annevk: I'm glad you have the patience and perseverence there |
| 06:29 | <annevk> | I haven't really joined the WebPerf list, maybe I should... |
| 06:29 | <MikeSmith> | there's actually not a large amount of traffic on that list |
| 06:29 | <MikeSmith> | considering the state of things, I guess that's probably bad |
| 06:30 | <MikeSmith> | that is, there should be more traffic there |
| 06:33 | <MikeSmith> | anyway, I wonder in what universe it's OK that we have experienced spec writers writing stuff like "Nonce sources require a new attribute to be added to both script and style elements: nonce." into specs, and not actually attempting to normatively define the "nonce" attribute nor raise an HTML bug so that Hixie can properly define it |
| 06:33 | <MikeSmith> | (end rant) |
| 06:34 | <MikeSmith> | speaking of which, as far as I can see, dglazkov has not gotten around to normatively defining the "is" attribute |
| 06:34 | <MikeSmith> | or actually I think he's essentially said that it doesn't need to be normatively defined |
| 06:34 | <MikeSmith> | or something |
| 06:35 | <MikeSmith> | (end follow-up rant) |
| 06:35 | MikeSmith | goes back to working on picture validation |
| 06:38 | zcorpan | sends an email about noncanonical-src |
| 06:42 | <annevk> | MikeSmith: you could complain about the former on public-webappsec⊙wo and the latter on public-webapps⊙wr |
| 06:43 | <annevk> | MikeSmith: the latter seems useful to complain about |
| 06:44 | <annevk> | zcorpan: "I think the noncanonical-src feature is going to be insanely complicated to get right." probably requires some justification as I think this might have been prototyped in Blink already |
| 06:45 | <zcorpan> | do you have a pointer? |
| 06:47 | <zcorpan> | hmm, possibly pretending that it is a redirect might dodge complications. but it's not clear what was intended from the handwavy spec text |
| 06:48 | <zcorpan> | funny how sometimes browsers just ignore the spec (e.g. r8678) |
| 06:50 | <MikeSmith> | zcorpan: you mean, everybody ignores it consistently but nobody bothers to file a bug? |
| 06:51 | <zcorpan> | MikeSmith: yeah. or more likely in this case they don't realise that they were violating the spec |
| 06:52 | <zcorpan> | i.e. they implement what they think the spec says, but it's not literally what the spec says |
| 06:55 | <MikeSmith> | ah right |
| 06:58 | <MikeSmith> | zcorpan: I guess it's pretty hard for an editor to catch that kind of potential problem ahead of time |
| 06:58 | <zcorpan> | yes |
| 07:37 | <MikeSmith> | zcorpan: so another piece of feedback on picture is that I think you should consider making the parsing algorithms error-reporting |
| 07:37 | <MikeSmith> | zcorpan: as in, the thing of defining certain cases as parse errors but not requiring implementations to report them |
| 07:38 | <zcorpan> | MikeSmith: can you file a bug? https://github.com/ResponsiveImagesCG/picture-element/issues |
| 07:38 | <MikeSmith> | ok |
| 07:38 | <zcorpan> | thanks! |
| 07:40 | <zcorpan> | MikeSmith: i guess the algorithm for a validator needs to be a bit different since it will want to look at the whole value for sizes while a browser will want to abort parsing asap |
| 07:47 | <MikeSmith> | zcorpan: right. And in the case of srcset, handling the parse errors makes the implementation somewhat more complicated. e.g., if you're not reporting errors, your implementation of the splitting loop can just handle commas and whitespace there exactly the same |
| 07:48 | <zcorpan> | MikeSmith: yeah |
| 07:52 | <MikeSmith> | annevk: fwiw I really like the wording of your definition of "parse error" in the URL spec |
| 07:52 | <MikeSmith> | "a non-fatal mismatch between input and requirements" |
| 08:01 | SamB | wonders why it's not called a "warning" ...... |
| 08:05 | <zcorpan> | SamB: it's an error because it violates authoring requirements |
| 08:50 | <SteveF> | JonathonNeal: yes |
| 08:50 | <SteveF> | JonathanNeal:yes |
| 09:00 | <jgraham> | Hixie: The tests in general are known to not be parse error complete |
| 09:00 | <jgraham> | Patches welcome |
| 10:29 | <annevk> | jungkees: when do you expect to simply reference Fetch? |
| 10:30 | <jungkees> | annevk: I'll be working on it next week |
| 10:31 | <annevk> | jungkees: cool, it's starting to become a bit confusing |
| 10:34 | <jungkees> | annevk: alright. Let's get it done sooner |
| 10:34 | <jungkees> | annevk: do you have anything particular that I need to be aware of? Re the design of Request/Response that we came up within the SW spec |
| 10:35 | <jungkees> | annevk: I've noticed that AbstractResponse has gone some such |
| 10:35 | <annevk> | jungkees: one thing seems to be that we want to move client/context to Request |
| 10:35 | <annevk> | jungkees: indeed, there's only a single Response class now |
| 10:36 | <annevk> | jungkees: the constructors are a bit different aligned with the discussions JakeA and I had |
| 10:36 | <annevk> | jungkees: toBlob() is now body.to("blob") |
| 10:36 | <jungkees> | annevk: alright. I'll catch up things from the Fetch spec esp. the API part |
| 10:37 | <annevk> | jungkees: I think best would be to just depend on those objects, just like you depend on other bits from Fetch |
| 10:39 | <jungkees> | annevk: Agreed. I'll have that in mind and will update the text |
| 10:39 | <jungkees> | annevk: Let's get it shaped next week. I'll ask things while working on it |
| 10:40 | <annevk> | jungkees: sounds good |
| 10:40 | <annevk> | jungkees: for .client I figured we want to define some kind of tuple thing |
| 10:40 | <annevk> | jungkees: (Client or Window or WorkerGlobalScope) |
| 10:41 | <annevk> | jungkees: though maybe if it's the current global we could just make it null |
| 10:41 | <annevk> | might be okay |
| 10:52 | <jungkees> | annevk: I found in HTTP fetch, it's being used to see whether the request came from SW context or not. What's the other use of .client in fetch algorithms? |
| 10:55 | <annevk> | jungkees: CSP / Mixed Content / ... specs make use of client |
| 10:56 | <annevk> | jungkees: in combination with context |
| 10:56 | <annevk> | jungkees: however, maybe you are right and that only makes sense in SW to be exposed |
| 10:57 | <annevk> | jungkees: would make my life easier |
| 10:57 | <jungkees> | annevk: Yeah guess so |
| 10:58 | <jungkees> | annevk: One quest about the queuing a task out of my own curiosity |
| 10:58 | <annevk> | jungkees: the argument for putting them on Request would be that they are there in the model, exposing them elsewhere in SW is somewhat odd |
| 10:58 | <annevk> | jungkees: sure |
| 10:59 | <jungkees> | annevk: is it technically wrong to queue a task from already async step? or is it a anti-practice? |
| 10:59 | <annevk> | jungkees: the only reason you queue a task is to sync state with the main thread |
| 11:00 | <annevk> | jungkees: so you have an async algorithm (that runs separately from the main thread by definition (although not formally defined yet)); and at some point you need to change a property and dispatch an event in the main thread, for that you'd queue a task |
| 11:00 | <annevk> | jungkees: if you just want to run some steps from an algorithm that's async, you just run them, you don't queue a task for that |
| 11:01 | <jungkees> | annevk: I see. thanks for the explanation |
| 11:05 | <annevk> | jungkees: I'll open an issue for context/client |
| 11:05 | <jungkees> | annevk: sure |
| 11:12 | <jgraham> | darobin: FWIW I disagree that shallow liking is more informative than shallow disliking. I think both indicate "I have a mild emotional reaction to this" |
| 11:12 | <darobin> | [dislike] |
| 11:13 | <darobin> | it depends what you mean by "more informative" |
| 11:13 | <darobin> | it does not carry more information if you're bit counting, but "like" carries all the information that it needs to IMHO, whereas "dislike" doesn't |
| 11:13 | <jgraham> | No, that's what I disagree with |
| 11:13 | <darobin> | if I propose something and you say you like it, that's all I need to know; if you say you dislike it then I want to know more |
| 11:14 | <darobin> | only one of those cases calls for change |
| 11:14 | <jgraham> | No, because if you are making a proposal that is itself a call for change |
| 11:15 | <darobin> | change *to the proposal* |
| 11:15 | <jgraham> | Knowing that people "like" a proposal isn't useful if you don't also know that they have thought through the consequences of that proposal rather than just having a shallow reaction to it |
| 11:23 | <annevk> | A good example of what jgraham means is parent selectors back when they were not feasible, you get a lot of popular support, but that doesn't mean it's good |
| 11:36 | <darobin> | sure, but those are two completely different metrics |
| 11:36 | <darobin> | it is useful to know that people like the use cases you liberate |
| 11:36 | <darobin> | that's an entirely different data point from the fact that people have thought it through |
| 12:27 | <annevk> | Apparently there's still promise-skeptics |
| 12:28 | <annevk> | I sort of that thought that after the async/await syntax was unveiled all debate would be over |
| 12:28 | <annevk> | So naïve |
| 12:28 | <caitp> | you people the people who aren't happy with the performance of the implementations in spidermonkey/v8? |
| 12:28 | <odinho> | *g* |
| 12:28 | <caitp> | or some other kind of skepticism |
| 12:30 | <annevk> | Not sure |
| 12:31 | <caitp> | it's mostly, as far as I can tell, the node.js people who are upset with the performance of native promises and prefer something like bluebird or just callbacks, awful as they are |
| 12:32 | <caitp> | but maybe there's more to it :> |
| 12:33 | <darobin> | annevk: you should know by now that for any proposal, there will in perpetuity be some skeptics — it's sort of its own Rule 34 |
| 12:34 | <caitp> | but less enticing |
| 12:34 | <darobin> | caitp: for some people, I have my doubts that they're not more enticed |
| 12:35 | <caitp> | well, at least it's constructive, if you squint really hard |
| 12:36 | <darobin> | I try not to squint too hard anywhere in the vicinity of Rule 34, even if a variant |
| 12:41 | <caitp> | obscures the view too much? |
| 12:53 | <darobin> | well played caitp, well played |
| 14:12 | <annevk> | Domenic: not sure what you're talking about |
| 14:12 | <annevk> | Domenic: what properties are there for network errors? |
| 14:12 | <Domenic> | annevk: I haven't looked into it hard yet; will do so. But e.g. how many places in the spec cause network errors? A property could distinguish those. |
| 14:12 | <annevk> | Domenic: no we don't distinguish network errors |
| 14:13 | <Domenic> | annevk: so for example it would be *very* useful for the dev to know that they were blocked by CSP |
| 14:13 | <annevk> | Domenic: I don't think we want to reveal that |
| 14:13 | <Domenic> | :-/ |
| 14:13 | <annevk> | Domenic: you can use CSP's error reporting feature though |
| 14:13 | <Domenic> | i think people will end up filtering on error strings in that case |
| 14:14 | <Domenic> | or mixed content... |
| 14:14 | <Domenic> | or cors... |
| 14:14 | <Domenic> | or too many redirects |
| 14:17 | <annevk> | Domenic: we don't expose those errors now anywhere, I'm not sure why fetch() would be any different |
| 14:17 | <Domenic> | because it's supposed to be better than XHR? |
| 14:18 | <annevk> | I'm not sure we want to reveal more sensitive information |
| 14:24 | <annevk> | Domenic: but if you get that past security guys, we could make network error more granular I guess |
| 14:27 | <annevk> | Domenic: it's better, but no less secure |
| 15:13 | <annevk> | JakeA: your fetch example gets even better with the new small functions |
| 15:14 | <JakeA> | annevk: arrow functions? |
| 15:14 | <annevk> | JakeA: fetch(url).then((response) => response.body.to("json")).then((json) => /* yey! */ ) |
| 15:14 | <Domenic> | (and the parens aren't even needed) |
| 15:15 | <annevk> | JakeA: fetch(url).then(response => response.body.to("json")).then(json => /* yey! */ ) |
| 15:15 | <JakeA> | \o/ |
| 15:15 | <annevk> | and then you shorten response to r, etc. :-) |
| 15:15 | <JakeA> | I wonder when Chrome's planning to ship arrow functions… |
| 15:17 | <annevk> | prolly before async/await |
| 15:17 | <Domenic> | arrow functions are in progress by one of the igalia guys |
| 15:18 | <caitp> | the status of that isnt actually recorded on the launchbug, iirc |
| 15:18 | <Domenic> | i believe it's his first v8 contribution though so it's taking a bit of time |
| 15:18 | <annevk> | JakeA: I closed a bunch of SW issues btw |
| 15:19 | <annevk> | JakeA: maybe we should organize a virtual meeting day where we go through all the things again here on #whatwg |
| 15:19 | <JakeA> | annevk: I saw, cheers! I'm on I/O lockdown for the next few days, although it means there'll be a session on serviceworker (and a video) |
| 15:20 | <annevk> | also JakeA, you ruined my "Notifications" tab on Twitter |
| 15:20 | <JakeA> | haha, people like fetch |
| 15:20 | <JakeA> | annevk: Yeah, those meeting were really productive, if they're even half as productive via IRC they're worth doing |
| 15:20 | <annevk> | JakeA: heh, I saw you guys are going to announce <meta name=brand-color> |
| 15:20 | <annevk> | JakeA: major spoilers on blink-dev |
| 15:21 | <JakeA> | annevk: yey more meta tags |
| 15:21 | <annevk> | JakeA: is yey British yay? |
| 15:22 | <JakeA> | annevk: hmm, maybe, or maybe I've just been spelling it wrong all my life |
| 15:22 | <annevk> | http://www.urbandictionary.com/define.php?term=yey |
| 15:23 | <JakeA> | *every* letter combination < 8 chars means drugs/blowjobs on urban dictionary |
| 15:25 | <caitp> | what else are you going to use cant for? |
| 15:26 | <annevk> | Domenic: are you keeping track somewhere of concept operations on a stream? |
| 15:27 | <annevk> | Domenic: if you copy an object that holds onto a stream, you want to tee the stream, no? |
| 15:27 | <Domenic> | annevk: not yet |
| 15:28 | <Domenic> | annevk: I am not sure but probably. |
| 15:28 | <Domenic> | annevk: where is your structured clone repo? i wanna solve promises there and then move on to streams |
| 15:28 | <annevk> | Domenic: https://github.com/dslomov-chromium/ecmascript-structured-clone |
| 15:29 | <annevk> | Domenic: ask dslomov for edit rights |
| 15:29 | <Domenic> | annevk: meh just wanna figure out strategy in the issue tracker first |
| 15:30 | <annevk> | Domenic: https://github.com/dslomov-chromium/ecmascript-structured-clone/issues/5 |
| 15:31 | <annevk> | Domenic: I'll add <!-- XXX streams --> markers in the Fetch source code so we can look through this stuff later |
| 15:32 | <annevk> | Domenic: we are getting very close to the point where we are going to make an attempt to implement Request/Response and FetchBodyStream et al btw |
| 15:32 | <Domenic> | annevk: yep, I'm full speed on streams now, as I want to be not-too-far-behind |
| 15:33 | <JakeA> | Would be great if node.append() could take a stream & progressively parse |
| 15:33 | <Domenic> | just wanna prioritize things that might affect fetch etc. first, so that's why i think the cloning/transferring is top priority |
| 15:33 | <annevk> | JakeA: I think that should work the other way around |
| 15:34 | <JakeA> | annevk: as in pipe a stream to an element? |
| 15:34 | <annevk> | JakeA: have a convenience method on an iterable that invokes node.append() with the next iterable as soon as it is there |
| 15:35 | <annevk> | JakeA: we'll have things like that on promises too |
| 15:35 | <annevk> | JakeA: otherwise you put all the complexity in node.append() and methods all over the place, where that isn't really justified |
| 15:37 | <annevk> | promise.callWithValue(node.append) or some such |
| 15:38 | <JakeA> | hmm, I was looking for something that'd hook into the html parser that's used to load the page, since we don't expose that to js at the moment. |
| 15:39 | <JakeA> | As in, you can't provide "<p>hello " and " world</p>" as seperate chunks at the moment |
| 15:39 | <JakeA> | separate* |
| 15:39 | <JakeA> | but the browser handles it fine during page load |
| 15:40 | <annevk> | That's called document.write() |
| 15:42 | <JakeA> | true |
| 15:44 | <JakeA> | element.write() would do it |
| 15:44 | <annevk> | Domenic: are you cautiously planning promises v2? Lots of https://github.com/kriskowal/q/wiki/API-Reference seems ready for inclusion |
| 15:45 | <JakeA> | The case I'm thinking of is fetch('some-largish-content.html').then(streamDataToElement) |
| 15:47 | <Domenic> | annevk: maybe, although async/await removes a lot of the need. |
| 15:47 | <Domenic> | annevk: .finally is my only high-priority thing |
| 15:47 | <annevk> | Domenic: how would you rewrite get for instance? |
| 15:48 | <Domenic> | annevk: and also maybe a version of .allSettled, or .any |
| 15:48 | <Domenic> | annevk: (await promise).property |
| 15:48 | <annevk> | var method = (async fetch(url)).method |
| 15:48 | <annevk> | oh await, doh |
| 15:48 | <annevk> | yeah nice |
| 16:12 | <annevk> | Domenic: should I ping es-discuss with https://github.com/dslomov-chromium/ecmascript-structured-clone/issues/6 or will you? |
| 16:16 | <Domenic> | annevk: I'll do it. I wonder how well it will go over to say "discuss this over on that other forum, not on this mailing list" :P |
| 16:17 | <annevk> | Domenic: well they are typically ignoring anything structured clone so I expect not too much trouble |
| 16:21 | <caitp> | what about #jslang? they seem to have time to talk about things |
| 16:55 | <Hixie> | jgraham: oh there will be patches |
| 16:56 | <Hixie> | jgraham: just as soon as i figure out how the heck to push a pull request |
| 16:56 | <Hixie> | or whatever is the terminology you kids use these days |
| 16:56 | <Hixie> | :-P |
| 16:57 | <jgraham> | You're not *that* much older than me |
| 16:57 | <jgraham> | I'm not gsnedders :p |
| 16:58 | <Hixie> | :-P |
| 17:00 | <Hixie> | i even have a few extra tests |
| 17:04 | <annevk> | HTML parser talk is one of my favorite pastimes |
| 17:04 | <annevk> | (context: es-discuss) |
| 17:05 | <Hixie> | how is <module> still not dead |
| 17:06 | <caitp> | what exactly was <module> supposed to be? i've been researching it a bit and haven't really had that cleared up |
| 17:06 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=25868 |
| 17:06 | <caitp> | because I think there are potential plans for our product to make use of it, and i want to make sure those plans disappear if they're terrible ideas |
| 17:07 | <Hixie> | just use <script type=module> |
| 17:07 | <Hixie> | which isn't valid yet but almost certainly will be |
| 17:07 | <Hixie> | though i dunno how we're going to fix the problem of non-js modules |
| 17:08 | <Hixie> | holy cow, i finally hit a test that checks <noscript> |
| 17:08 | <Hixie> | i was wondering if that'd ever come up |
| 17:08 | <caitp> | i'm not sure if it's still in the cards, but for the next iteration of angular, initially we were doing this weird thing involving es6 modules + html imports, somehow coupled together, I can't recall how that hack worked |
| 17:09 | <caitp> | but iirc the module tag was involved somewhere in there |
| 17:09 | <caitp> | or at least a fake version of it |
| 17:14 | <Hixie> | uh |
| 17:14 | <Hixie> | interesting |
| 17:14 | <Hixie> | html5lib tests assume that you parse scripts |
| 17:19 | <jgraham> | Yeah |
| 17:20 | Hixie | introduces a new #script-off directive for tests |
| 17:24 | <annevk> | JakeA: to get back to your streaming thing, it seems like you want a streaming HTML parser in JavaScript |
| 17:25 | <annevk> | JakeA: however, HTML cannot be streamed at the moment, so we might have to "fork" the parser (by adding a mode) to make such a thing actually feasible |
| 17:25 | <annevk> | JakeA: as for why it cannot be streamed, check out <table><x></table> |
| 17:28 | <Hixie> | it can be streamed, just not in a naive way like xml or json |
| 17:29 | <annevk> | Hixie: it would be kind of nice to provide naive HTML streaming at some point |
| 17:30 | <Hixie> | in what contexgt? |
| 17:30 | <annevk> | Hixie: Jake's example was loading some data over the network and incrementally streaming the data into the page |
| 17:30 | <Hixie> | like, XHR -> innerHTML |
| 17:30 | <Hixie> | ? |
| 17:30 | <annevk> | Hixie: yes |
| 17:31 | <Hixie> | we could provide that |
| 17:31 | <Hixie> | just have XHR have a method like "xhr.sendOutputTo(element)" |
| 17:31 | <caitp> | xhr.pipe(node) |
| 17:31 | <Hixie> | but i don't know if we want to be encouraging treating HTML in that way |
| 17:31 | <Hixie> | better to stream the data in an app-internal format, then create the HTML on the client |
| 17:32 | <annevk> | JakeA: ^ |
| 17:32 | <annevk> | I don't really like the sendOutputTo() |
| 17:32 | <annevk> | It seems like you want to provide the underlying primitive so people can build their own setups |
| 17:33 | <annevk> | Anyway, probably not high-priority, but worth thinking about |
| 17:33 | <Hixie> | the underlying primitive is "insertAdjacentHTML" |
| 17:34 | <Hixie> | though i guess you need to handle mid-token streaming |
| 17:34 | <Hixie> | so you need to keep the parser alive somehow |
| 17:34 | <Hixie> | yeah that could get complicated |
| 17:34 | <Hixie> | anyway the solution is to not stream HTML, imho |
| 17:35 | <caitp> | can you actually stream JSON, currently? because you could see that as being pretty useful |
| 17:35 | <Hixie> | you can certainly write a streaming parser |
| 17:36 | <caitp> | but do progress events actually give you chunks of data? |
| 17:36 | <annevk> | Hixie: structured cloning of promises is happening btw: https://github.com/dslomov-chromium/ecmascript-structured-clone/issues/6 |
| 17:36 | <annevk> | Hixie: hopefully you don't have to define it in HTML, but I thought I'd let you know |
| 17:37 | <Hixie> | thanks |
| 17:37 | <Hixie> | wow, that's ambititous |
| 17:37 | <Hixie> | cloning without neutering |
| 17:37 | <Hixie> | ambitious, even |
| 17:38 | <Ms2ger> | http://www.w3.org/XML/2014/03/xproc-charter.html |
| 17:47 | <Hixie> | wtf is "XXX-undefined-error" |
| 17:49 | <Hixie> | i've reached the point where i'm finding more bugs in the tests than in my implementation |
| 17:49 | <Hixie> | that's a good sign |
| 17:51 | <jgraham> | https://github.com/html5lib/html5lib-python/search?q=XXX-undefined-error&ref=cmdform |
| 17:51 | <Hixie> | ah |
| 17:51 | <Hixie> | well it seems in this case it was a bogus error |
| 17:51 | <Hixie> | as was a later one "unknown-doctype element" |
| 17:52 | <Hixie> | finally hit a test of the Script data double escape start state |
| 17:53 | <jgraham> | Yeah, the later script states aren't so well tested |
| 17:53 | <jgraham> | later additions I mean |
| 17:54 | <Hixie> | well the order i'm doing the tests in is pretty random |
| 17:54 | <jgraham> | Since they postdate Philip` generating a whole load of tests |
| 17:54 | <Hixie> | i mean, i did tricky01.dat before tests1.dat |
| 17:54 | <Hixie> | tricky01, btw, was by far the most tricky to fix so far! |
| 17:54 | <Hixie> | it found bugs in my dom implementation, in my test logic, in the AAA, everything |
| 17:56 | <jgraham> | I think those tests were mainly from abarth |
| 17:58 | <abarth> | yay for tricky01.dat! |
| 18:04 | <Hixie> | damnit, there's a bug SOMEWHERE in the script states |
| 18:04 | <Hixie> | how the heck am i supposed to find that |
| 18:05 | <Ms2ger> | Rewrite it all |
| 18:06 | <jgraham> | ERROR http://localhost:8000/resources/testharness.js:1840 - TypeError: location is null |
| 18:06 | <jgraham> | Uh |
| 18:06 | <jgraham> | That's not good |
| 18:07 | <Ms2ger> | Servo? ;) |
| 18:07 | <Ms2ger> | I think I saw you mention that before |
| 18:07 | <JakeA> | annevk: Hixie: I imagine a page loads by streaming html text to a parser which creates nodes and updates them as the stream is read. Curious about opening that up to developers by piping an html stream into an element |
| 18:08 | <Hixie> | JakeA: the problem is that the parser works on a Document |
| 18:08 | <jgraham> | Ms2ger: Gecko :( |
| 18:08 | <Hixie> | JakeA: whereas innerHTML is on an element |
| 18:08 | <Hixie> | JakeA: what you could do is load the page in an iframe, then put all the content in a <div>, and as soon as that is parsed, move the <div> into wherever you want hte content streamed |
| 18:09 | <Hixie> | JakeA: but honestly, the solution is to generate the html client-side |
| 18:10 | <JakeA> | Hixie: wouldn't streaming html into a fragment be very similar to the initial page load? |
| 18:11 | <Hixie> | the HTML parser parses into a Document |
| 18:11 | <Hixie> | innerHTML does all the parsing into a Document, then moves it into the element all at once |
| 18:12 | <JakeA> | Hixie: is that how it's implemented or just how it's specced |
| 18:13 | <Hixie> | both |
| 18:13 | <Hixie> | as far as i know |
| 18:13 | <JakeA> | Fair enough |
| 18:23 | <Hixie> | woah, i found one of these tests that had a bogus output |
| 18:23 | <Hixie> | how did that not get caught by all the browsers using these tests |
| 18:24 | <Hixie> | oh |
| 18:24 | Hixie | hides head in shame |
| 18:24 | <Hixie> | (it was in one of my new tests) |
| 18:24 | <Ms2ger> | Silly |
| 18:26 | <Hixie> | oh hey |
| 18:26 | <Hixie> | i hadn't implemented in-template yet |
| 19:27 | <Hixie> | <table><template><td></template></table> - currently this is a parse error because "Generate Implied End Tags" doesn't do table-related (e.g. </td>) tags |
| 19:28 | <Hixie> | should i have </template> "Generate implied end tags harder" so this is not a parse error? |
| 19:28 | <caitp> | yes |
| 19:29 | <caitp> | lets make the parser do even more stuff that the author didn't explicitly ask it to do |
| 19:30 | <TabAtkins> | Sarcasm: less helpful than you'd think. What a surprise. |
| 19:30 | <caitp> | was it sarcasm? |
| 19:35 | <TabAtkins> | Based on what I remember of your opinions, you telling Hixie to "make the parser do even mroe stuff that the author didn't explicitly ask it to do" does sound like a serious response. Pretty sure you meant the exact opposite, which makes it sarcastic. |
| 19:35 | <caitp> | you caught me :( |
| 19:38 | <caitp> | I am not sure how to be helpful with discussions like that, other than to try and nudge things in the right direction. unless you think sarcasm might nudge it in the wrong direction, that would be less helpful |
| 19:38 | <TabAtkins> | It would be better to just be direct. "No, I don't think the parser should do even more stuff the author didn't explicitly ask it to do" |
| 19:39 | <caitp> | being direct is kind of like, there's a phrase for it but it's kind of inappropriate |
| 19:39 | <caitp> | it's not very colourful, there's no vibrancy or life to it |
| 19:39 | <TabAtkins> | ??? That's just a direct answer to the question. |
| 19:39 | <caitp> | not as fun =) |
| 19:40 | <TabAtkins> | Point isn't to have fun, it's to have a technical discussion. You can be as sarcastic and fun as you like during the non-technical conversations that go on. ^_^ |
| 19:43 | <annevk> | JakeA: I've decided I'm not going to reply to all questions asked on Twitter, just the trickier ones |
| 19:44 | <annevk> | Favorite answer I gave so far has to be https://twitter.com/annevk/status/477535987783192576 |
| 19:47 | <JakeA> | annevk: hah, yes |
| 20:18 | <Hixie> | no opinions on the </td> thing? |
| 20:18 | <Hixie> | (note that i'm not talking about changing what the parser does, so caitp's comment kinda misses the point) |
| 20:18 | <Hixie> | (i'm just talking about what's a parse error) |
| 20:20 | <annevk> | Hixie: I don't understand why that shouldn't be a parse error |
| 20:20 | <caitp> | you were saying "should we generate end tags, or should we call it an error" |
| 20:20 | <Hixie> | annevk: because </td> is optional |
| 20:20 | <Hixie> | caitp: "generate end tags" is a term of art that doesn't affect the parsing |
| 20:20 | <Hixie> | caitp: it only affects whether it's an error |
| 20:20 | <caitp> | it affects the behaviour |
| 20:20 | <annevk> | Hixie: so is <template><dt></template> an error? |
| 20:20 | <Hixie> | caitp: if you're going to be so critical, it would help if you would at least learn about what you're criticising |
| 20:20 | <Hixie> | annevk: no |
| 20:21 | <Hixie> | annevk: that's why i'm suggesting we change it |
| 20:21 | <jcgregorio> | I'd be surprised if that was a parse error |
| 20:21 | <annevk> | Hixie: sounds good to me |
| 20:21 | <Hixie> | k |
| 20:21 | <caitp> | I don't think anything you've said invalidates what I'm saying --- error throwing or not throwing is behaviour |
| 20:21 | <annevk> | caitp: there's no throwing |
| 20:21 | <Hixie> | caitp: the DOM is the same either way |
| 20:21 | <caitp> | that's not the point, really |
| 20:21 | <caitp> | when I say throw, I'm not always talking about a JS context |
| 20:22 | <annevk> | caitp: can we just talk about this in terms of the HTML parser then? |
| 20:22 | <annevk> | caitp: arbitrary terms are confusing for everyone |
| 20:22 | <annevk> | Domenic: IDL for Headers initialization: http://logs.glob.uno/?c=mozilla%23content&s=13+Jun+2014&e=13+Jun+2014#c218158 |
| 20:23 | <caitp> | in terms of the HTML parser, you're saying "should we do the crazy work necessary to hide the error in a way which doesn't really reflect what the author wrote, OR should we consider it an error (this does not mean an Exception)" |
| 20:23 | <caitp> | anyways, I would opt for the latter, preferably with a message for developers |
| 20:24 | <annevk> | caitp: what are you talking about? It does reflect what the author wrote. Many end tags are optional in HTML |
| 20:24 | <caitp> | which is one of the problems with HTML, not one of the solutions --- why should the template tag hang onto old badness? |
| 20:25 | <annevk> | caitp: if you don't like the format, use XML, but changing it's inherent consistency is just creating more badness imo |
| 20:26 | <caitp> | I don't think those optional tags are widely used anyways, I mean yeah the plural of anecdote is not data, but I read a lot of peoples code, and I've yet to see anything like that in use |
| 20:26 | <Domenic> | annevk: seems ok. not sure i have much to contribute. |
| 20:26 | <Hixie> | caitp: we're not doing any different work. We're going to be closing these tags anyway (we already do). The question is just, should we report missing end tags in this one specific situation as an error or not, given that they are optional elsewhere, and that we don't report an error even here for some other elements with optional end tags. |
| 20:26 | <caitp> | and besides, if new HTML features start getting rid of old badness, maybe eventually, the old badness can be discarded entirely |
| 20:27 | <Hixie> | implied end tags are used all _over_ the place |
| 20:27 | <Hixie> | especially the table ones, which is what we're talking about |
| 20:27 | <annevk> | Domenic: great |
| 20:27 | <caitp> | i'm sure they are, but how many of them are used in template contexts |
| 20:27 | <Hixie> | however, everything here is about <template> contexts, which are used almost nowhere. |
| 20:27 | <caitp> | exactly |
| 20:28 | <annevk> | I use optional end tags all the time |
| 20:28 | <annevk> | Whenever I have to write a <table> it's such a blessing |
| 20:28 | <annevk> | Or <li> with nested <p> for that matter |
| 20:28 | Philip` | wonders if "use" means "include" or "omit" |
| 20:28 | <TabAtkins> | Using the optionality aspect. |
| 20:28 | <TabAtkins> | So, "omit". |
| 20:30 | <caitp> | I dunno, I'm aware of those optional end tags and I literally never use them, because there's no way to logically consider stuff using those a well-formed consistent document |
| 20:30 | <TabAtkins> | ...okay. |
| 20:30 | <TabAtkins> | That's nonsense, but sure, whatever. |
| 20:31 | <caitp> | it's not nonsense --- for a language to be simple, it must be consistent |
| 20:31 | <caitp> | this is why people suck at english, it's not consistent at all |
| 20:31 | <TabAtkins> | You didn't say "simple". You said "well-formed consistent". |
| 20:32 | <TabAtkins> | And a markup language that defines a tree structure with implied end tags is plenty "well-formed consistent". |
| 20:32 | <caitp> | a markup language "should" be simple |
| 20:32 | <caitp> | the structure "should" be easy to reason about |
| 20:32 | <TabAtkins> | ...are you trying to talk about the AAA and table fixup? |
| 20:33 | <TabAtkins> | Because that's not at all relevant to what's been under discussion today. |
| 20:33 | <caitp> | hixie puts two things foreward, I favour one over the other |
| 20:33 | <caitp> | that is relevant, and not at all invalidated by intentionally misunderstanding things =) |
| 20:34 | <Hixie> | optional end tags do not in any way reduce the precision of the language or ability to reason about it |
| 20:34 | <Hixie> | their rules are simple, and well-defined |
| 20:34 | <caitp> | they're not actually |
| 20:34 | <TabAtkins> | Well, I wouldn't call <p> auto-closing "simple", but they're at least well-defined. |
| 20:34 | <TabAtkins> | The rest, yeah. |
| 20:34 | <caitp> | they're easy for _you_, they're less easy for _other_ people |
| 20:35 | <TabAtkins> | <li>, <dt>, <tr>, all those auto-closing rules are super simple. |
| 20:35 | <caitp> | boe can't even name all 3 of those elements |
| 20:35 | <caitp> | let alone all of the other ones with similar rules |
| 20:35 | <TabAtkins> | "boe"? |
| 20:35 | <caitp> | are you going to tell me that Boe can't be an HTML author because he can't reason about all this nonsense? |
| 20:35 | <Hixie> | <p> auto-closing is simple. The <p> closes when it comes across something that isn't allowed in the <p>. |
| 20:35 | <TabAtkins> | Hixie: The list of "things that aren't allowed in <p>" isn't trivial. |
| 20:35 | <caitp> | the fact that "things aren't allowed in a <p>" exists at all |
| 20:35 | <caitp> | is totally bogus |
| 20:36 | <Hixie> | TabAtkins: sure, it's the same list that someone needs to know to use HTML whether or not </p> is implied. |
| 20:36 | <TabAtkins> | caitp: Are you saying that Boe literally doesn't know what the <li> element is? |
| 20:36 | <TabAtkins> | Hixie: ??? |
| 20:36 | <caitp> | Boe probably can't name <tt> or <em> or know the difference between <ol> or <ul> |
| 20:36 | <caitp> | Boe doesn't know what <tbody> means |
| 20:36 | <TabAtkins> | Who is this Boe? |
| 20:36 | <Hixie> | TabAtkins: if you don't know that <h1> isn't allowed in <p>, then you have bigger problems than not knowing that </p> will get implied if you put <h1> in <p> |
| 20:37 | <caitp> | Boe is a hypothetical author who is new to this language |
| 20:37 | <TabAtkins> | Hixie: <figure>, yay nay? |
| 20:37 | <SamB> | caitp: how about <p> |
| 20:37 | <Hixie> | TabAtkins: yay nay what? |
| 20:37 | <SamB> | I don't figure that should be allowed (directly) in <p> |
| 20:37 | <SamB> | it doesn't make any sense |
| 20:37 | <TabAtkins> | caitp: Sounds like Boe hasn't completed the first part of their "Learn you an HTML for great justice" course. |
| 20:37 | <caitp> | semantically it doesn't make much sense, sure |
| 20:37 | <TabAtkins> | Hixie: On the allowed list, or not? |
| 20:37 | <caitp> | as far as layout goes it doesn't make much sense |
| 20:37 | <Hixie> | TabAtkins: a paragraph cannot contain a figure, no |
| 20:37 | <caitp> | but even so, there's no reason why the language shouldn't allow for it |
| 20:38 | <TabAtkins> | That's non-obvious to me. |
| 20:38 | <caitp> | and no reason why the language should re-arrange it |
| 20:38 | <TabAtkins> | Thus my statement that "the list of things not allowed in <p> is non-obvious". |
| 20:38 | <Hixie> | TabAtkins: i am happy to concede that |
| 20:38 | <Hixie> | TabAtkins: my point is just that that is a bigger problem than </p> implied end tags |
| 20:38 | <Hixie> | TabAtkins: and once you've solved that problem, you've solved the implied end tag problem also |
| 20:38 | <TabAtkins> | Well, it's the same problem, no? |
| 20:38 | <Hixie> | you need the same information, yes |
| 20:38 | <caitp> | the fact that we re-arrange these things is because mistakes were made and now nobody wants to fix them for fear of upsetting people |
| 20:38 | <TabAtkins> | The content model of <p> is non-obvious, is what I"m saying. ^_^ |
| 20:39 | <TabAtkins> | caitp: We know that you don't understand what the words "legacy compat" mean. You don't need to keep reinforcing that. |
| 20:39 | <Hixie> | caitp: we've given you several ideas for how you can try to address this problem, repeatedly whining here isn't productive to your goals |
| 20:39 | <caitp> | and if every new feature to the platform has to accommodate those old mistakes, then HTML is fundamentally and permanently broken |
| 20:39 | <TabAtkins> | They do, and it is, and yet we persist. |
| 20:39 | <Hixie> | TabAtkins: lots of HTML is non-obvious, unfortunately, yeah :-( |
| 20:40 | <Hixie> | caitp: i am happy to concede that HTML is fundamentally and permanently broken |
| 20:40 | <TabAtkins> | Hixie: Not challenging that. Just saying, that particular thing is non-obvious, where you said it was simple. ^_^ |
| 20:40 | <Hixie> | caitp: also, wildly successful |
| 20:40 | <caitp> | no, I know what legacy compat means and I understand it Tab, what I don't understand is the strong desire to keep it that way, even for new things |
| 20:40 | <Hixie> | TabAtkins: i said the auto-closing rule is simple |
| 20:40 | <caitp> | new things shouldn't be held back by old brokenness |
| 20:40 | <TabAtkins> | If you don't understand why legacy compat is important, then you don't understand "legacy compat". |
| 20:40 | <caitp> | even if it makes things inconsistent, so what |
| 20:40 | <TabAtkins> | Hixie: Only by referencing complicated things! |
| 20:40 | <Hixie> | TabAtkins: that it relies on less simple stuff, is a secondary issue :-) |
| 20:40 | <caitp> | new stuff should use a simpler, less whacky model |
| 20:41 | <caitp> | that's my opinion, you're welcome to disagree and I suspect you do |
| 20:41 | <TabAtkins> | I don't need full transitive closure on "simplicity", but at least a few hops. ^_^ |
| 20:41 | <Hixie> | TabAtkins: all of this stuff eventually relies on electronics and microelectronics and i don't understand any of that, but it doesn't mean the higher layers aren't simple :-) |
| 20:41 | <Hixie> | hehe |
| 20:41 | <caitp> | TabAtkins, I understand why it's important to people who find it important |
| 20:42 | <Hixie> | caitp: new stuff should use as simple and as less wacky a model as it can while still standing a chance of being deployed |
| 20:42 | <caitp> | I don't believe that NEW things, which don't exist as far as legacy clients are considered, should have to accomodate those old rules |
| 20:42 | <TabAtkins> | The people who find it important are the users who look at the trillion existing pages, and the browser vendors serving those users. |
| 20:42 | <Hixie> | caitp: but there's no point us doing something that doesn't stand a chance of getting deployed |
| 20:42 | <TabAtkins> | Spec authors bemoaning complexity are nothing compared to them. |
| 20:42 | <caitp> | what makes you think it wouldn't be deployed |
| 20:42 | <caitp> | authors literally don't care |
| 20:42 | <Hixie> | (i'm an author and i care) |
| 20:43 | <Hixie> | caitp: browser vendors have told me they would not deploy breaking changes |
| 20:43 | <caitp> | you care about the sloppy version of table content breaking <template> tags when oyu can easily type the other 4 characters to make it work? |
| 20:44 | <caitp> | it's not a breaking change, legacy browsers aren't going to fall apart because the html parser treats <template> content differently |
| 20:44 | <Hixie> | it's not sloppy |
| 20:44 | <caitp> | it is sloppy |
| 20:44 | <Hixie> | it's not sloppy |
| 20:44 | <Hixie> | it's well-defined and unambiguous |
| 20:44 | <caitp> | it's the act of being unwilling to explicitly specify the end of the nodes content |
| 20:44 | <caitp> | this is sloppy in and of itself |
| 20:45 | <Hixie> | and we're not talking about treating <template> content differently; as mentioned before, this entire discussion involves zero changes to the DOM. We're only talking about how many errors are reported. |
| 20:45 | <Hixie> | wtf |
| 20:45 | <Hixie> | are "// foo" comments sloppy? |
| 20:45 | <caitp> | I don't think you can compare a programming language to a markup language |
| 20:46 | <caitp> | they serve different purposes and different authors |
| 20:47 | <caitp> | I think you'd have a problem if say, scope in a language which didn't care about indentation could have an optional "end" marker |
| 20:47 | <TabAtkins> | Hah, I specify the end of my <li> *by putting another <li> in* (or a </ul>, etc). |
| 20:47 | <Hixie> | are csv files sloppy? |
| 20:47 | <TabAtkins> | That's not sloppy, that's just omitting unnecessary crap. |
| 20:47 | <caitp> | yes, arguably CSV files are sloppy, is that a real question? |
| 20:47 | <SamB> | TabAtkins: yeah, that's why I mentioned <p> in <p> |
| 20:48 | <TabAtkins> | SamB: Yeah, that part of the rules is easy; it's all the other things that auto-close <p>. |
| 20:48 | <TabAtkins> | <div> implies a </p>, etc. |
| 20:48 | <Hixie> | ok, if you consider CSV files "sloppy" then by that definition HTML is "sloppy". But by that definition, "sloppy" is also "good", so I'm fine with it. |
| 20:48 | <caitp> | > make language needlessly more complicated |
| 20:48 | <caitp> | > features that most people never use |
| 20:49 | <SamB> | Hixie: CSV is loads worse |
| 20:49 | <SamB> | there's no HTML<del>5</del> spec/WHATWG of CSV |
| 20:49 | <caitp> | there's no spec of CSV period, it's pretty vendor-specific |
| 20:50 | <Hixie> | caitp: it's not "needless", it makes the language easier to author and more compatible with legacy UAs and content. It's not features that most people never use, tag omission is extremely widely used. |
| 20:50 | <TabAtkins> | I mean, there's http://tools.ietf.org/html/rfc4180 |
| 20:50 | <SamB> | CSV is like maildir^N |
| 20:50 | <caitp> | it means typing fewer characters, this does not make it easier to author |
| 20:50 | <TabAtkins> | I used that when writing my CSV parser. |
| 20:50 | <caitp> | it makes it harder to read and write, because this is a markup language where we have start tags and end tags denoting when content starts and ends |
| 20:50 | <SamB> | I mean rfc822-style has more damn meaning than CSV has |
| 20:51 | <caitp> | then some markers are optional sometimes |
| 20:51 | <caitp> | this is weird and confusing |
| 20:51 | <caitp> | and then, parsers have to rearrange stuff sometimes |
| 20:51 | <caitp> | this is weird and confusing |
| 20:51 | <Hixie> | <table> <tr> <td> A <td> B <tr> <td> C <td> D </table> is a hell of a lot easier to maintain than <table> <tbody> <tr> <td> A </td> <td> B </td> </tr> <tr> <td> C </td> <td> D </td> </tr> </tbody> </table> |
| 20:51 | <caitp> | it's profoundly broken |
| 20:51 | <caitp> | there is nothing good about any of this |
| 20:51 | <Hixie> | anyway |
| 20:51 | <SamB> | (you just have to pick between actual mail/news format and deb822, based on the context) |
| 20:51 | <Hixie> | you're ignoring our arguments, so i'm done here |
| 20:51 | <TabAtkins> | Complaining about the rearranging is very different from complaining about omitted end tags. |
| 20:51 | <caitp> | i'm not ignoring your argument |
| 20:51 | <SamB> | caitp: yeah, there's lots of legacy crap :-( |
| 20:53 | <Hixie> | caitp: you're repeating arguments that have been countered, without taking into account the countering arguments, so, yeah. |
| 20:53 | <caitp> | they haven't been countered |
| 20:53 | <SamB> | I can't think of anything besides <h[1-n]> | <hr> w/ <p> on the TOS (normal notation) and </[something-higher-up-the-stack]> that should actually force a </p> |
| 20:53 | <caitp> | you haven't shown me how someone would consider your whacky markup "simple" or "useful" and not "confusing" |
| 20:54 | <SamB> | or, well, I guess with only inliney stuff on the stack |
| 20:54 | <SamB> | not, say, in a mid-paragraph <article> |
| 20:55 | <TabAtkins> | caitp: Besides several people literally saying "I find it simple, useful, and not confusing"? |
| 20:56 | <SamB> | otherwise, you start needing ways to mark paragraphs as "wait no this paragraph isn't actually interrupted by that display formula/example code/etc.", no? |
| 20:56 | <SamB> | what was "it" again? |
| 20:56 | <caitp> | look, it's not that I don't respect Ian or his opinion, but I think his opinion on the simplicity of HTML might not be as useful as he thinks, since he's so close to it |
| 20:57 | <caitp> | you have to look at the 12 year old kids, the college and highschool students, the secretaries, the soccer moms |
| 20:57 | <TabAtkins> | I just treat some part of HTML as similar to Python (I use indentation in my HTML in the same way) or like a streaming format where you only indicate boundaries. |
| 20:57 | <caitp> | their opinions on simplicity matter here |
| 20:57 | <Hixie> | SamB: a "paragraph" in HTML is just a run of text. If it contains a figure, it's not a paragraph, it's two paragraphs and a figure. Yes, this is not quite what English majors would have you say, but there we have it. |
| 20:57 | <caitp> | look at the algorithm for parsing HTML |
| 20:57 | <Hixie> | caitp: the long and short of it is you're 23 years too late for this argument. |
| 20:57 | <caitp> | is that not crazy to you? |
| 20:57 | <TabAtkins> | caitp: All those kids seems to get it fine. The omitting rules got added *because* people were omitting them and browsers were accommodating them. |
| 20:57 | <Hixie> | (nobody is arguing that HTML parsing is simple.) |
| 20:57 | <TabAtkins> | caitp: Most of HTML parsing's complexity is in <script>. |
| 20:57 | <caitp> | a good chunk of it is |
| 20:58 | <caitp> | i agree |
| 20:58 | <TabAtkins> | With a bit of crazy from things showing up in <table> that shouldn't be there. |
| 20:58 | <SamB> | Hixie: yeah, when I said "mark paragraphs as", I mean if you want to format it traditionally, you need ways to mark <p> nodes as actually part of a larger paragraph |
| 20:58 | <Hixie> | TabAtkins: nah, that's not complex, it's just long. The complexity is in the AAA. |
| 20:58 | <Hixie> | and noah's ark |
| 20:58 | <Hixie> | and foster parenting |
| 20:58 | <TabAtkins> | "Long" and "complex" are pretty similarly bad for understanding. ^_^ |
| 20:58 | <Hixie> | SamB: ah if you want to mark english-major paragraphs, use <div>, not <p> |
| 20:58 | <caitp> | the adoption agency is crazy |
| 20:58 | <caitp> | i don't think it's limited to that |
| 20:58 | <SamB> | I think TeX actually keeps track of the tightness of the last line of the previous chunk of paragraph |
| 20:58 | <Hixie> | TabAtkins: fair enough |
| 20:58 | <TabAtkins> | A lot of CSS Syntax I was able to "simplify" just by making it shorter. |
| 20:59 | <Hixie> | the adoption agency is the least crazy of the four utterly crazy options we had at our disposal, sadly |
| 20:59 | <SamB> | Hixie: hmm, how'd the CSS look to get proper indentation then? |
| 20:59 | <caitp> | i'd hate to see the alternatives then, because the adoption agency makes me really sad |
| 20:59 | <SamB> | I guess you'd use :first and :last? |
| 20:59 | <Hixie> | SamB: "proper" indentation of paragraphs is no indentation, so... :-) |
| 20:59 | <TabAtkins> | SamB: What sort of indentation are you looking for? |
| 21:00 | <SamB> | Hixie: I mean if for some reason you were trying to vaguely approximate traditional typesetting |
| 21:00 | <Hixie> | caitp: yeah, the alternatives were so much worse. One dependended on the TCP packet boundaries. Another required changes to CSS to not render styles that didn't map to the tree. The last involved the tree structure actually being a graph. |
| 21:00 | <Hixie> | caitp: there's some discussion of this stuff on ln.hixie.ch if you go back far enough |
| 21:01 | <SamB> | in terms of the overall shape more so than particular fonts |
| 21:01 | <Hixie> | SamB: you'd probably wrap the first part of the paragraph in a <p> in the <div> and style it using div>p:first-child |
| 21:01 | <caitp> | anyways, I understand why you don't want to change the AAA stuff at this point, maybe that ship sailed a long time ago |
| 21:01 | <caitp> | but I think, just maybe, for new tags like <template>, we could do better |
| 21:01 | <Hixie> | caitp: people copy-and-paste their existing content into new contexts |
| 21:02 | <SamB> | caitp: what do you mean? |
| 21:02 | <Hixie> | caitp: they don't want it to change behaviour |
| 21:02 | <SamB> | do you mean <template> itself shouldn't force </template> ? |
| 21:02 | <SamB> | otherwise, I think you're doomed |
| 21:02 | <SamB> | that's probably the only real negotiable here |
| 21:02 | <caitp> | I don't think it should force </template>, I don't think it should have any concept of content that is allowed to be in it |
| 21:03 | <caitp> | the only case where it should force </template> is at the end of the document |
| 21:03 | <TabAtkins> | SamB: It doesn't force </template>, iirc. You can nest templates. |
| 21:03 | <SamB> | TabAtkins: cool |
| 21:03 | <SamB> | caitp: not even </[something further up the stack]>? |
| 21:04 | <caitp> | not even |
| 21:04 | <SamB> | that could be done, but it sounds pretty crazy to me |
| 21:04 | <caitp> | function C() { function D() { } |
| 21:04 | <caitp> | what should happen |
| 21:05 | <TabAtkins> | In what language? |
| 21:05 | <caitp> | in ECMAScript, since we're here =) |
| 21:05 | <TabAtkins> | I forget whether it hoists D out of C or not, but it's definitely allowed. |
| 21:05 | <caitp> | it's not allowed, C hasn't been closed |
| 21:06 | <TabAtkins> | Oh, didn't see that that's the point you were making. |
| 21:06 | <caitp> | the one higher in the stack doesn't get closed first |
| 21:06 | <TabAtkins> | ...yes? |
| 21:06 | <caitp> | this is logical and makes sense |
| 21:06 | <TabAtkins> | Why would you think it would be? |
| 21:06 | <Hixie> | caitp: btw i think you're confusing the idea of what is valid with the idea of how the parser works |
| 21:07 | <TabAtkins> | Both C and D use } to close, so } isn't equivalent to "</[something further up the stack]>". |
| 21:07 | <Hixie> | caitp: it's important that we say that e.g. <h1><h2>foo</h2></h1> is invalid, since that's what validators use to flag mistakes to the author |
| 21:07 | <TabAtkins> | It might make sense for EOF to auto-close C (CSS does this), but that's it. |
| 21:07 | <Hixie> | caitp: just like how type checking compilers say there's a problem when you add a string to an integer |
| 21:07 | <Hixie> | caitp: quality assurance tools are important |
| 21:08 | <caitp> | quality assurance tools are important, no argument there =) |
| 21:08 | <caitp> | but ideally they'll tell you to close your tags explicitly instead of making the parser acommodate your awful markup |
| 21:08 | <Hixie> | the two parts of that sentence are unrelated |
| 21:09 | <gsnedders> | jgraham: gosh darn it, I'm still 2/3rds your age! :P |
| 21:09 | <TabAtkins> | "Your page is bad, and we wont' display it until you fix it" was already tried. It was a complete and utter failure. |
| 21:09 | <caitp> | which was that? you can write some pretty bad xhtml pages that will still render _something_ |
| 21:10 | <SamB> | caitp: yeah, </$FOO> only grabs the first $FOO |
| 21:11 | <caitp> | i think you can find a happy medium between "abort on error" and "don't rearrange peoples gunk" |
| 21:11 | <TabAtkins> | caitp: No, XHTML just fails. It fails hard. If you see it render "something", that's because it's not XHTML. It's HTML that you are writing in an XHTML-like syntax. Maybe you don't *realize* it's HTML, maybe you dont' know that what you did triggered HTML parsing, but it happened. |
| 21:11 | <caitp> | it's not one or the other, you know? |
| 21:12 | <Hixie> | caitp: what should happen if the page has <table><tr><td>A</td></tr>B<tr><td>C</td></tr></table> |
| 21:12 | <caitp> | layout would come up with something to do with the text node |
| 21:13 | <caitp> | we could find out |
| 21:13 | <Hixie> | how about <p>A<b>B<i>C</b>D</i>E</p> ? |
| 21:16 | <caitp> | http://jsfiddle.net/azjVF/ try it for yourself |
| 21:17 | <caitp> | if layout engines can figure out what to do with it, I'm not convinced the parser should have to |
| 21:17 | <gsnedders> | TabAtkins: WebKit and I presume Blink render up to the error |
| 21:17 | <TabAtkins> | THEY ARE VIOLATING THE SPEC |
| 21:17 | <gsnedders> | TabAtkins: You only have to abort normal parsing, you don't have to discard what you've already parsed |
| 21:18 | <TabAtkins> | THE INTENTION |
| 21:18 | <gsnedders> | They're not though. |
| 21:18 | <Hixie> | gsnedders is actually right on this. you're allowed to keep what you parsed so far and render it. |
| 21:18 | <gsnedders> | Because otherwise SAX parsers could never follow the spec — and their existance was a goal. |
| 21:18 | <gsnedders> | Hixie: you say this like I'm always wrong! |
| 21:19 | <Hixie> | no, the "actually" was more about TabAtkins than you :-) |
| 21:19 | <TabAtkins> | I choose to interpret it like gsnedders did. |
| 21:19 | <gsnedders> | Damn it guys! |
| 21:19 | <TabAtkins> | "gsnedders is actually right on this (unlike his usual wrong-as-hell self)" |
| 21:20 | <Hixie> | gsnedders: i'm gonna have a bunch of fixes to the tests |
| 21:20 | <TabAtkins> | "I know it's hard to believe, what with it being gsnedders and all, who's wrong all the time." |
| 21:20 | <Hixie> | gsnedders: how do you want them? |
| 21:20 | <zewt> | strict parsing is pretty nasty for file formats authored by humans rather than machines |
| 21:20 | <gsnedders> | Hixie: a pull request, which I presume is what you and jgraham were discussing while I was watching X-Men. |
| 21:20 | <TabAtkins> | "But hey, even a wrong clock is right twice a day." |
| 21:20 | <Hixie> | gsnedders: for the whole batch at once? |
| 21:20 | <TabAtkins> | "Though that, sadly, is way more right than gsnedders is on a given day." |
| 21:21 | <gsnedders> | Hixie: Are they all just fixing them to match the spec? |
| 21:21 | <zewt> | which make xhtml not terrible for machine-generated markup, but useless for the rest |
| 21:21 | <Hixie> | gsnedders: also adding a few features to the test format |
| 21:21 | <Hixie> | gsnedders: (#script-on / #script-off, to indicate if scripting is enabled or not) |
| 21:21 | <gsnedders> | Hixie: I'd rather that was kept as a separate PR |
| 21:21 | <Hixie> | k |
| 21:21 | <gsnedders> | (I agree it's needed) |
| 21:21 | <Hixie> | also a few new tests |
| 21:21 | <Hixie> | minor variations on existing ones |
| 21:22 | <Hixie> | most of the changes are fixing the #errors sections |
| 21:22 | <gsnedders> | Keep them in a separate commit, but they can probably piggy-back one of those PRs |
| 21:22 | <zewt> | wish there was a way i could convince google search to blacklist scrape-and-paste sites, it's getting pretty bad particularly for SO |
| 21:22 | <gsnedders> | I tend not to be too fussed unless I disagree with the code :) |
| 21:23 | <Hixie> | k |
| 21:23 | <gsnedders> | Hixie: git add --patch may be useful, allows you to select specific changes when committing |
| 21:23 | <zewt> | i type -p, i assumed it meant "pick" |
| 21:24 | <gsnedders> | zewt: why the hell do I ever know what it is an abbr for? |
| 21:24 | <Hixie> | blimey template.dat is long |
| 21:25 | <zewt> | dunno, you typed it :P |
| 21:25 | <Hixie> | gsnedders: k, i'll probably get back to you when i'm ready |
| 21:25 | <Hixie> | gsnedders: to figure out how to do it :-) |
| 21:25 | <gsnedders> | Hixie: The split between files is pretty random, as I've mentioned before :) |
| 21:26 | <Hixie> | these tests have been invaluable so far |
| 21:26 | <gsnedders> | We need more! And a way to check they're right and stay right! |
| 21:26 | gsnedders | mumbles mumbles mumbles |
| 21:26 | <Hixie> | well, that's kind of what i'm doing. |
| 21:27 | <gsnedders> | Is your impl actually going to strictly stay up to date with the spec? |
| 21:28 | <Hixie> | dunno, but since it's going to be used by the spec pipeline, it has a higher chance than average of keeping up to date |
| 21:40 | <Hixie> | the spec's a bit inconsistent about how many parse errors you get with an unexpected EOF |
| 21:40 | <Hixie> | but i'm not gonna fix it |
| 21:40 | <Hixie> | (e.g. <template><script> -> 2, <template><table> -> 1) |
| 21:43 | <gsnedders> | Hixie: Only in the template case? It certainly used to be the case you only got one |
| 21:43 | <Hixie> | yeah, it's templates that mess this up i think |
| 21:45 | <Hixie> | actually |
| 21:45 | <Hixie> | no |
| 21:45 | <Hixie> | <table><script> -> 2 also, as far as i can tell |
| 21:45 | <Hixie> | <template><template><template> -> 3 |
| 21:46 | <jgraham> | git add -p is an immediately sufficient answer to "why does git give you access to the staging area" |
| 22:01 | <Hixie> | <dummy><table><template><table><template><table><script> gives you four EOF messages |
| 22:01 | <Hixie> | but can you guess which four? :-) |
| 22:02 | <TabAtkins> | jgraham: Preach it. |
| 22:28 | <SimonSapin> | jgraham: I use git-cola to do the same by click-selecting lines |
| 22:54 | <gsnedders> | Hixie: I now want to see if there's an upper-bound on the number of EOF errors… :) |
| 23:06 | <Hixie> | gsnedders: well each <template> gives one, so not strictly |
| 23:06 | <Hixie> | gsnedders: but if you count all those as one... then yeah, probably |
| 23:07 | <zewt> | target=_blank needs to be shot into the sun |
| 23:07 | <zewt> | preferably hard enough that it shoots out the other side of the sun, so it can fall into the sun a second time |
| 23:08 | <gsnedders> | Hixie: strictly, because why would I care about anything but being technically correct? :) |
| 23:08 | <gsnedders> | All other forms of correct are just secondary to that. |
| 23:11 | <gsnedders> | hahaha. So apparently here any vehicle over 3m tall must have a sign in the cab giving the height… in feet and inches. |
| 23:18 | <Hixie> | ok who was the joker who put "Not Known" as the parse error |
| 23:19 | <gsnedders> | Hixie: ezyang |
| 23:20 | <gsnedders> | We only sorted out the format of the errors about a year ago, before them all that was checked was number |
| 23:25 | <Hixie> | oh my version way back when didn't haver errors? |
| 23:28 | <gsnedders> | It may well have |
| 23:28 | <gsnedders> | But no impl paid attention to the format, just the number |
| 23:28 | <gsnedders> | So they ceased being at all meaningful except for the number |
| 23:29 | <Hixie> | well that's all that's meaningful now, still, no? |
| 23:30 | <gsnedders> | In *theory* we should now have (col, row): [meaningless] |
| 23:30 | <Hixie> | ah |
| 23:30 | <Hixie> | well i'm not doing that, and a lot of them don't have that :-) |
| 23:30 | <gsnedders> | As I said, in theory. :) |
| 23:30 | <Hixie> | also, the ones that do have col,row almost always have the row off by one |
| 23:30 | <Hixie> | compared to what mine outputs |
| 23:31 | <gsnedders> | zero/one-base? |
| 23:31 | <Hixie> | no, i think they're both 1-based, but i for "<foo>" i output the error at 1,6, and the tests have it at 1,5 |
| 23:31 | <Hixie> | after the token, vs on the last character of the token |
| 23:32 | <Hixie> | (mine leads to a better experience when integrated with an IDE, imho) |
| 23:32 | <gsnedders> | i.e., we give the position of the next character to be consumed? |
| 23:33 | <Hixie> | i do, you give the position of the last consumed character |
| 23:33 | <Hixie> | but really the positions are debatable |
| 23:33 | <Hixie> | i mean, the position of a missing doctype is before the token that discovers it, for example |
| 23:33 | <Hixie> | not after it |
| 23:34 | <gsnedders> | so we give the position of what the spec calls the "current input character"? |
| 23:34 | <gsnedders> | which seems sensible from an API POV |
| 23:34 | <Hixie> | yeah, i think so |
| 23:34 | <Hixie> | anyway, that's not documented |
| 23:34 | <annevk> | My memory of these things is not great, but I think to remember when we started hacking we just cared about parse errors as a boolean; if it expected any and we reported any, it was good |
| 23:34 | <Hixie> | so it doesn't exist :-P |
| 23:35 | <gsnedders> | Hixie: Indeed. :) |
| 23:35 | <Hixie> | annevk: i'm updating the tests to have an accurate number, at least |
| 23:36 | <annevk> | I haven't really touched any HTML parsing code for a long time now. WebVTT was fun to do. Hopefully some other other format comes along at some point |
| 23:36 | <annevk> | WebVTT was actually really nice. Wrote it while hanging out with MikeSmith eating cookies and drinking tea in his neighbourhood |
| 23:50 | <gsnedders> | jgraham: speaking of html5lib, what do I need to get code-review of anything nowadays? bah! |
| 23:50 | <Hixie> | blimey |
| 23:50 | <Hixie> | i pass 8109 tests, but "<a><b><b><p></a>" is enough to take me down |
| 23:51 | <gsnedders> | The AAA really needs more test coverage. :( |
| 23:51 | <Hixie> | (hard, to, that's a null deref crash) |
| 23:51 | <Hixie> | too |
| 23:51 | <Hixie> | the problem with the AAA is that it's like the bidi model and margin collapsing and the inline box model |
| 23:51 | <Hixie> | at any given time, nobody actually understands it |
| 23:51 | <gsnedders> | :) |
| 23:52 | <Hixie> | for brief periods of time, there'll be one person who actually groks it |
| 23:52 | <Hixie> | but they don't grok it for long enough to write many tests |
| 23:52 | <Hixie> | because otherwise they'll go mad |
| 23:52 | <gsnedders> | I remember when I was fixing CSS 2.1 tests originally by various Opera people |
| 23:53 | <gsnedders> | I reached the bidi ones and just nope'd straight outta there |
| 23:53 | <Hixie> | hah |
| 23:53 | <Hixie> | the trick with bidi ones |
| 23:53 | <Hixie> | is to write it all on pieces of paper |
| 23:53 | <Hixie> | and cut them up |
| 23:53 | <Hixie> | and then do it by hand that way |
| 23:53 | <Hixie> | (seriously) |
| 23:54 | <jgraham> | gsnedders: Ummm. Good question |
| 23:54 | jgraham | sleep |
| 23:54 | <gsnedders> | I think in one of the cases I went, "oh, hey fantasai… see these tests you wrote years ago? yeah, could you fix them?" |
| 23:55 | <gsnedders> | jgraham: I only really care about my PRs, I can review other people's code. :P |
| 23:56 | <gsnedders> | Hixie: What I really want is a formal model of the spec so I can just model things as satisfaction problems and get tests like that :) |
| 23:57 | <Hixie> | good luck |
| 23:58 | <gsnedders> | really all I need is a decent formal model that I'm relatively sure matches the spec |
| 23:58 | <Hixie> | crap now i only pass 6928 tests |
| 23:58 | <Hixie> | what did i do! |
| 23:58 | <gsnedders> | you broke stuff! |
| 23:58 | <gsnedders> | damn it Hixie, you're meant to be the all-knowing master of HTML, and you can't even parse it? pff! |
| 23:59 | <Hixie> | ohhhh.... i had a bogus assert |
| 23:59 | <Hixie> | where the spec says "if any", it really means "if any", not "there will be one and you should assert there is one" |