| 02:56 | <MikeSmith> | is there an online JS linter to which you can just feed the URL for an HTML document and it'll check the contents of the <script> elements in the document ? |
| 05:00 | <Domenic_> | dun-dun-DONE.... https://github.com/domenic/promises-unwrapping |
| 05:02 | <TabAtkins> | Is it implied that, when defining a foo() operation that calls bar() in one of its substeps, that if bar() throws an exception it'll propagate up and foo() will automatically throw it as well unless it specifically catches it? |
| 05:02 | <TabAtkins> | Like normal JS? |
| 05:02 | <TabAtkins> | Or do we have to explicitly catch and throw exceptions to avoid them being swallowed when doing spec-ese? |
| 05:11 | <zewt> | tab: i'm strongly in favor of always explicitly saying what to do with all exceptions from sub-algorithms; it should always be possible to read an algorithm in isolation and see what *all* of the logic paths are, without having to dig all the way into everything it calls in case something four levels deep might throw an exception |
| 05:14 | <zewt> | which really means specs shouldn't throw exceptions at all (all that makes exceptions exceptions is implicit stack unwinding); "exceptions" should really be return values, and only become actual exceptions when they propagate out of an API call |
| 05:23 | <TabAtkins> | zewt: Well, I'm using API calls within spec definitions (with the implication that it's the internal operation, not the user-facing function object), so I can't easily do that. |
| 05:23 | <TabAtkins> | But sure, I can explicitly throw the exception. |
| 08:12 | <annevk> | TabAtkins: I'm in favor of adopting JS semantics for that |
| 08:13 | <annevk> | TabAtkins: i.e. rethrow if an invoked algorithm throws, return terminates, throw terminates, etc. |
| 08:14 | <annevk> | TabAtkins: haven't really spelled the conventions out yet though |
| 09:24 | <annevk> | http://tomdale.net/2013/09/maybe-progressive-enhancement-is-the-wrong-term/ "This is a little bit like arguing that we should still be laying out our websites using tables and inline styles in case users disable CSS." I am disappoint |
| 09:31 | <jgraham> | annevk: Who is "everyone else"? |
| 09:31 | <jgraham> | Microsoft don't comment on whatwg |
| 09:32 | <annevk> | They actually did comment on that thread, forgot about that |
| 09:37 | <annevk> | jgraham: but e.g. Apple, Opera, Intel, Samsung? |
| 09:39 | <wilhelm> | annevk: Why disappoint? |
| 09:45 | <annevk> | wilhelm: because the argument doesn't make sense? |
| 10:02 | <annevk> | Hixie_: replied |
| 10:06 | <wilhelm> | annevk: It'a silly strawman, I agree. But his point still stands. Disabling JS was fine in 2003, but now it's a bit optimistic. (c: |
| 10:07 | <annevk> | wilhelm: I agree with JS being non-optional. I don't really agree with CSS being non-optional, although maybe it's true today. |
| 10:07 | <annevk> | wilhelm: although for many sites JS is optional still |
| 10:08 | <annevk> | hsivonen: are there bugs on Gecko for decoder EOF handling? |
| 10:10 | <wilhelm> | Then we are in agreement. (c: |
| 10:33 | <zcorpan> | jgraham: https://critic.hoppipolla.co.uk/r/257 the PR is closed. would it make sense for critic to drop reviews whose PR is closed? |
| 10:56 | <hsivonen> | annevk: Yes. Gecko decoders don't know about EOF. |
| 10:57 | <annevk> | hsivonen: also see email, per jsbell we do the correct thing for the API |
| 11:02 | <annevk> | Domenic_: https://github.com/domenic/promises-unwrapping/blob/master/README.md#propagatetoderivedp seems the note should refer to step 3 |
| 11:17 | <jgraham> | zcorpan: It is supposed to do that |
| 11:17 | <jgraham> | But for some reason it doesn't work |
| 11:18 | <jgraham> | I'm not sure if we never get the message from github, or if the implementation is broken |
| 11:27 | <annevk> | Domenic_: seems I have commit access, fixed |
| 12:26 | <zcorpan> | jgraham: ok |
| 14:49 | <tobie_> | annevk: re your question about test licensing this morning, the idea is to prevent an implementor from picking an choosing just the tests it passes then claiming full W3C conformance. You're still free to do that, but you can't claim the test suite created that way has anything to do with W3C. |
| 14:50 | <Hixie_> | you don't need copyright or a license to do that |
| 14:50 | <Hixie_> | just use trademark law |
| 14:50 | <jgraham> | Right |
| 14:50 | <tobie_> | I'm not suggesting this is the best/only way to do so. just describing the intent behind it. |
| 14:51 | <jgraham> | For all intents and purposes the tests are BSD licensed |
| 14:52 | <tobie_> | Would trademark law work outside of the U, though? (not a lawyer) |
| 14:52 | <tobie_> | s/U,/US/ |
| 14:53 | <jgraham> | I'm not sure that there's anywhere that would respect copyright more than trademark law, but I might be wrong |
| 14:54 | <Hixie_> | the real question is, is anyone really going to sue anyone if someone _does_ try to claim that they pass a twisted test suite? |
| 14:55 | <wilhelm> | Public shaming may be much more effective. And cheap. |
| 14:55 | <tobie_> | ^ that |
| 14:55 | <jgraham> | Hixie_: BTW I looked and afaict all the implementations I have access to treat the element-in-scope stuff as an algorithm that takes a tag name and operates on the stack of open elements at the time the information is required, rather than as an ambient property of the environment that is kept up to date |
| 14:55 | <Hixie_> | well yeah |
| 14:56 | <Hixie_> | doing it the other way would be massively inefficient |
| 14:56 | <Hixie_> | the goals of a spec and the goals of implementations aren't the same |
| 14:56 | <Hixie_> | (obviously) |
| 14:56 | <jgraham> | Well it doesn't really make the spec more understandable if the way that you implement it and the way that you read the spec intentionally diverge |
| 14:57 | <Hixie_> | there's very few parts of the spec where they _don't_ diverge |
| 14:57 | <Hixie_> | (and since implementations vary in how they implement things, that'll always be true) |
| 14:58 | <jgraham> | In this case the implementations all implement things in roughly the same way, and the spec could easily use that way, but instead uses something different and, apparently, confusing |
| 14:58 | <Hixie_> | yeah. i don't understand what's confusing about it, but certainly some people are confused by it. |
| 15:03 | <annevk> | jgraham: is there a pointer on how I contribute to web-platform-tests? |
| 15:03 | <jgraham> | annevk: Ask tobie_ |
| 15:03 | <annevk> | jgraham: I might be just awake enough to move the tests from my URL repo |
| 15:04 | <annevk> | tobie_: ^^ |
| 15:04 | <jgraham> | I don't understand the documentation situation anymore |
| 15:04 | <jgraham> | There is some replacement for the testtwf site that's supposed to have all this stuff on |
| 15:04 | <tobie_> | Working on getting this out asap |
| 15:05 | <tobie_> | was delayed by personal matters over the last couple of weeks. |
| 15:06 | <jgraham> | Do you have an expected timeline? |
| 15:06 | <tobie_> | annevk: you probably want to look at https://github.com/w3c/testtwf-website/blob/gh-pages/docs/migration-process.md in the meantime |
| 15:06 | <tobie_> | jgraham: by the end of the week |
| 15:06 | <jgraham> | That sounds good |
| 15:07 | <tobie_> | (or early next) |
| 15:24 | <annevk> | Hixie_: some people on Twitter got upset with your definition of resource |
| 15:25 | <annevk> | Hixie_: although I think you know and I don't really and none of it was constructive :/ |
| 15:25 | <annevk> | care /\ |
| 15:27 | <Hixie_> | annevk: my definition of resource? |
| 15:27 | <annevk> | Hixie_: https://twitter.com/mnot/status/375439468343209984 and onwards |
| 15:31 | <Hixie_> | oh, \/\/hatever. it's a non-normative statement of fact. if they disagree they can learn to send feedback using real mechanisms. |
| 15:33 | <jgraham> | Your feedback has been ignored because: [x] It was posted in a medium designed for sharing cat pictures |
| 15:36 | <Hixie_> | more like, your feedback has been considered and rejected but you have not received a personalised response becouse: [x] it was posted in a medium not designed for useful debate |
| 15:37 | <zewt> | more like "designed to prevent useful debate" |
| 15:38 | <Hixie_> | i doubt it was literally designed to prevent useful debate |
| 15:38 | <jgraham> | Well |
| 15:38 | <jgraham> | it's hard to imagine that they thought people would try and have debates in 140 characters |
| 15:38 | <Hixie_> | right |
| 15:38 | <Hixie_> | hence the way i phrased it |
| 15:39 | <jgraham> | I imagine that they conciously optimised for other use cases (sharing links to cat pictures) |
| 15:39 | <Hixie_> | yeah |
| 15:39 | <Hixie_> | can you dispatchEvent() the event you are currently handling? |
| 15:39 | <Hixie_> | or does that fail |
| 15:40 | <Hixie_> | and if it fails, is there a way to clone an event? |
| 15:41 | <annevk> | no way to clone |
| 15:41 | <annevk> | Hixie_: "If event's dispatch flag is set, or if its initialized flag is not set, throw an "InvalidStateError" exception. " |
| 15:42 | <Hixie_> | k |
| 15:42 | Hixie_ | manually creates a new event and copies all the state over |
| 15:49 | <annevk> | Hixie_: I hope this isn't in a spec |
| 15:50 | <annevk> | Hixie_: also, if you have a use case... |
| 15:50 | <Hixie_> | not in a spec |
| 15:50 | <Hixie_> | my use case is, when i get a resize event, i want to dispatch it to the currently visible "panel" |
| 15:50 | <annevk> | new Event(evObj) could work maybe |
| 15:51 | <annevk> | although there's some trickery with regards to types and what to clone, etc. |
| 15:51 | <annevk> | I guess each event object would only clone from the passed event what they know about, although even then you have to be careful about identically named members |
| 15:52 | <zewt> | iirc i've had to manually "clone" events, in cases where i intercept a real event in a capture, do something else, then want to re-fire the original event later |
| 16:03 | <annevk> | Too bad people don't really report those kind of things as annoyances... Btw zewt, are you gonna update the Zip wiki entry? |
| 16:23 | <zewt> | haven't had a chance, I want to go through the appinfo again first, see what needs additional specification and how brittle doing it by delta instead of clean slate seems... |
| 16:29 | <annevk> | zewt: aight |
| 16:29 | <annevk> | zewt: no hurry I suppose, need to figure out a ton of other stuff anyway |
| 17:02 | <reyre> | zcorpan: ping |
| 17:02 | <zcorpan> | reyre: pong |
| 17:02 | zcorpan | is on a flaky connection |
| 17:02 | <reyre> | zcorpan: can you point out to me where <track> has 'onload' and 'onerror'? i'm having trouble finding it |
| 17:03 | <Ms2ger> | Probably on HTMLElement or whatever |
| 17:03 | <Ms2ger> | http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#globaleventhandlers |
| 17:03 | <reyre> | Ms2ger: i'm looking at HTMLTrackElement, but don't see it |
| 17:03 | <Ms2ger> | HTMLElement implements GlobalEventHandlers; |
| 17:03 | <Ms2ger> | interface HTMLTrackElement : HTMLElement { |
| 17:04 | <reyre> | Ms2ger: ah okay |
| 17:05 | <reyre> | so we have to specify when HTMLTrackElement should emit these events |
| 17:05 | <reyre> | correct? |
| 17:05 | <reyre> | otherwise it would just be the default from HTMLElement |
| 17:06 | <zcorpan> | reyre: "Queue a task to first change the text track readiness state to failed to load and then fire a simple event named error at the track element." http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#start-the-track-processing-model |
| 17:07 | <zcorpan> | reyre: and: |
| 17:07 | <zcorpan> | If the file was successfully processed, fire a simple event named load at the track element. |
| 17:07 | <zcorpan> | Otherwise, the file was not successfully processed (e.g. the format in question is an XML format and the file contained a well-formedness error that the XML specification requires be detected and reported to the application); fire a simple event named error at the track element. |
| 17:08 | <reyre> | zcorpan: okay cool, thank you for that |
| 17:09 | <reyre> | this should be enough for our needs |
| 17:09 | <reyre> | in regards to that bug |
| 17:09 | <zcorpan> | ok. i think there are tests for the events in https://critic.hoppipolla.co.uk/r/74 |
| 17:11 | <zcorpan> | at least the CORS tests rely on load/error events |
| 17:11 | <reyre> | zcorpan: nice, book marking that now, thanks :) |
| 17:12 | <zcorpan> | reyre: if you find issues with the tests, please raise in the review |
| 17:13 | <reyre> | zcorpan: will do |
| 17:14 | <zcorpan> | reyre: what does gecko do wrt the MIME type for <track>? (see yellow box in the spec linked to above) |
| 17:22 | <reyre> | zcorpan: we check for 'text/vtt', and i'm not exactly sure *what* happens in the underlying code there as it goes through the networking library which i don't know much about |
| 17:36 | <zcorpan> | reyre: ok. presto ignores the mime type for <track>. check http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2509 and change the type or the signature in opera 12.x |
| 18:06 | <GPHemsley> | Even employees of the Government of Canada don't know how to read directions. |
| 18:06 | <GPHemsley> | And yet somehow I have more empathy for them. |
| 20:33 | <Ms2ger> | ... CSS3Test.com? |
| 20:33 | <miketaylr> | looks legit, has ads |
| 20:34 | <Ms2ger> | I thought Lea had more brains than that |
| 20:37 | <TabAtkins> | The numbers are useless as always, but the actual results look useful. |
| 20:40 | <jgraham> | TabAtkins: Isn't this the opposite? The numbers are "useful" but the results are useless (except in a caniuse sense) |
| 20:40 | <jgraham> | (of course the numbers aren't actually useful) |
| 20:40 | <TabAtkins> | No, knowing that a browser does/doesn't parse something is pretty useful. |
| 20:41 | Hixie_ | really is at a loss as to what mnot and company were complaining about |
| 20:42 | <Hixie_> | oh well |
| 20:42 | jgraham | refers Hixie to the previous conversation about twitter |
| 20:42 | <jgraham> | But at a guess, your concept of "resource" doesn't map exactly to the http concept |
| 20:43 | <Hixie_> | what on earth is the http concept of origin, if it doesn't match the change mnot was complaining about? |
| 20:44 | <jgraham> | s/origin/resource/ |
| 20:44 | <jgraham> | ? |
| 20:44 | <Hixie_> | uh, yeah, sorry |
| 20:45 | <Hixie_> | too many balls in the air over here |
| 20:45 | <Hixie_> | TabAtkins: what's the place to look for for the definition of "replaced element" these days? |
| 20:45 | <TabAtkins> | css 2.1 |
| 20:45 | <Hixie_> | is http://www.w3.org/TR/CSS2/ the latest version of that? |
| 20:45 | <TabAtkins> | Yes. |
| 20:46 | <Hixie_> | thanks |
| 20:47 | <Domenic_> | hmm interesting css 2.1 base spec is still useful for things? |
| 20:47 | <SimonSapin> | yes, many parts of it do not yet have a level 3 equivalent |
| 20:48 | <TabAtkins> | Yeah, we obsolete parts as we write specs to replace them. |
| 20:48 | <TabAtkins> | Until then 2.1 is still authoritative. |
| 20:48 | <Domenic_> | huh, interesting |
| 20:48 | <Domenic_> | Location: http://css3test.com/ Access has been blocked as the threat Mal/HTMLGen-A has been found on this website. O__o |
| 20:48 | <SimonSapin> | TabAtkins: are any parts explicitly obsoleted? |
| 20:48 | <SimonSapin> | I mean other by the existence of another document |
| 20:49 | <TabAtkins> | SimonSapin: No, unfortunately. It would be nice to maintain such a list. Perhaps in the snapshot. |
| 20:49 | <TabAtkins> | I expect we'll be publishing another one of those this year, since we have several specs in CR or Rec now. |
| 20:50 | Ms2ger | would just pull all the parts of css2 that are still relevant into modules and publish those as recs as-is |
| 20:50 | <SimonSapin> | interesting |
| 21:01 | <gsnedders> | Ms2ger: As CSS 3 modules? |
| 21:02 | <gsnedders> | https://github.com/html5lib/html5lib-python/issues/111 — is that expectation right? |
| 21:02 | <SimonSapin> | I we would still call them "Level 2", but as CSS modules yes |
| 21:02 | <gsnedders> | I'd just push them as CSS 3 FPWDs |
| 21:02 | <SimonSapin> | I think* |
| 21:02 | <gsnedders> | Lot less work to get them as FPWDs than RECs |
| 21:08 | <Hixie_> | TabAtkins: "technically" in what sense? |
| 21:08 | <Hixie_> | i don't understand your e-mail |
| 21:08 | <TabAtkins> | In "it's treated as replaced element by the spec". |
| 21:08 | <Hixie_> | which spec? the html spec doesn't, that's what bz was asking for |
| 21:08 | <TabAtkins> | But browsers treat it as something much closer to a normal element. |
| 21:09 | <TabAtkins> | Hmm, actually not quite sure. Does HTML define other elements as replaced? |
| 21:10 | <Hixie_> | http://whatwg.org/html#replaced-elements |
| 21:11 | <TabAtkins> | I don't see *any* of the form controls here. |
| 21:11 | <cballenar> | whatup :) |
| 21:11 | <Hixie_> | TabAtkins: correct :-) |
| 21:12 | <SimonSapin> | Domenic_: IMO, the parts of CSS 2.1 that are still relevant are most of chapters 8 to 12, and appendix E. Everything else has a Level 3 spec that I consider "good" |
| 21:12 | <TabAtkins> | Well, that's definitely wrong. Form elements have definitely been *considered to be* replaced elements, at least, for a very long time. Browsers allow an inconsistent set of properties to affect them, though. |
| 21:12 | <cballenar> | @lilmonkey, I apologize for my attitude, I see what you meant, clearly the example I posed was incorrect and went against all good practices for the web. |
| 21:14 | <gsnedders> | SimonSapin: Not App H? |
| 21:14 | <cballenar> | lilmonkey: though u weren't exactly the easiest person to deal with… ok now i'm done… :) |
| 21:14 | <lilmonkey> | cballenar: if you have something to tell me, you can PM me. It is of no concern to this channel. |
| 21:15 | <cballenar> | i never use IRC, this thing still confuses the hell out of me… |
| 21:15 | <SimonSapin> | gsnedders: Appendix H? That doesn’t seem to exist… |
| 21:15 | <gsnedders> | SimonSapin: Go to App G and press next. It exists. |
| 21:16 | <SimonSapin> | oh |
| 21:16 | <Hixie_> | TabAtkins: well, buttons are just inline-block elements. similar things apply to some of the others. |
| 21:16 | <SimonSapin> | well, we probably don’t need to make a new L3 spec for this one :) |
| 21:16 | <gsnedders> | Hixie_: We don't care about parse errors that can only be hit in the scripting enabled case, do we? |
| 21:16 | <gsnedders> | Hixie_: Given they cannot be checked by a conformance checker. |
| 21:17 | <gsnedders> | Hixie_: Unless, of course, it has solved the halting problem. :) |
| 21:17 | <Hixie_> | gsnedders: you can report such errors in a js console |
| 21:17 | <gsnedders> | Hixie_: I am aware. |
| 21:17 | <Hixie_> | so we care |
| 21:18 | <gsnedders> | Hixie_: You don't define "control character" anywhere. |
| 21:19 | <rniwa> | wycats: yt? |
| 21:19 | <Hixie_> | gsnedders: is it used in a normative sense? |
| 21:20 | <Hixie_> | ah, yes |
| 21:20 | <Hixie_> | it's a term from unicode |
| 21:20 | <gsnedders> | "must not contain control characters other than space characters", phrasing content. |
| 21:20 | <gsnedders> | Yes, obviously. |
| 21:21 | <gsnedders> | Just whether you care about defining it explicitly. |
| 21:21 | <gsnedders> | (Presumably to be all characters in Gc C*) |
| 21:21 | <gsnedders> | (Or just Cc?) |
| 21:22 | <gsnedders> | Cc is control. |
| 21:24 | <Hixie_> | yeah working on it |
| 21:27 | <Ms2ger> | SimonSapin, you knew that people spent time to make sure the first letters of the appendix titles matched up, right? :) |
| 21:27 | <gsnedders> | SimonSapin, Ms2ger: it is rather obvious given how contrived they end up. |
| 21:27 | <gsnedders> | (Sorry Hixie) |
| 21:27 | <Ms2ger> | Yeah... I mean, "Elaborate description"? |
| 21:28 | <Hixie_> | well, it _is_ elaborate |
| 21:28 | <Hixie_> | the most telling sign is the lack of an "H" appendix |
| 21:28 | <gsnedders> | Well, yes. But you'd still not ordinarily call it that. |
| 21:28 | <Hixie_> | IT IS ELABORATE. |
| 21:28 | Ms2ger | pats Hixie_ on the back |
| 21:28 | <SimonSapin> | Ms2ger: I did not |
| 21:28 | <gsnedders> | Hixie_: So is the HTML parser. Rename that to the Elaborate description of the HTML Parsing algorithm. |
| 21:29 | gsnedders | awaits the next commit |
| 21:29 | <SimonSapin> | I got involved after 2.1 became REC |
| 21:30 | <SimonSapin> | that probably explains why appendix E is an appendix at all, although it seems like a bad reason |
| 21:31 | <Hixie_> | it was an appendix before the naming joke started |
| 21:32 | <Hixie_> | gsnedders: the html spec has lots and lots of jokes, doesn't need to copy css' :-) |
| 21:34 | <gsnedders> | Are there any Cc characters outwith latin1? |
| 21:35 | <SimonSapin> | http://www.fileformat.info/info/unicode/category/Cc/list.htm says no |
| 21:35 | <Hixie_> | no |
| 21:35 | <Hixie_> | they're C0 and C1 and that's it |
| 21:35 | <gsnedders> | Right, okay. |
| 21:38 | <wycats> | rniwa: what's up? |
| 21:39 | <rniwa> | wycats: hi |
| 22:08 | <gsnedders> | Wait, I should be submitting bugs, not emails, shouldn't I? Not that Hixie cares. |
| 22:11 | <gsnedders> | jgraham: Does html5lib need to match the current spec for 1.0? |
| 22:11 | gsnedders | votes no |
| 22:11 | <gsnedders> | For the sake of shipping. |
| 22:14 | <Hixie_> | gsnedders: bugs and e-mails are equivalent for html |
| 22:14 | <Hixie_> | just don't do both |
| 22:14 | <zewt> | it's like crossing the streams |
| 22:16 | <gsnedders> | :) |
| 22:16 | <gsnedders> | Also, we should totally make expected behaviour clearer for when the input stream is a sequence of Unicode codepoints. |
| 22:17 | <gsnedders> | e.g., parsing a unicode string in most modern languages. |
| 22:17 | <Hixie_> | i thought we did that recently |
| 22:17 | <gsnedders> | Did we? |
| 22:17 | <gsnedders> | It's better, but not entirely clear. |
| 22:17 | <Hixie_> | there's a new section or something |
| 22:17 | <gsnedders> | Will look later. |
| 22:26 | <MikeSmith> | anybody know what people normally use for parsing json in java? I see there's a javax.json but that seems to be separate jsr |
| 22:26 | <zewt> | Hixie_: are you still going through the "blurry lines" thread? my suggestion was essentially to allow optional pixel snapping (as well as a way to make pixel alignment easier), without making it the default and screwing up animations |
| 22:27 | <Hixie_> | i just replied to that entire thread |
| 22:27 | <zewt> | (i made an attempt at describing how the actual mechanics would work, but I don't know enough about the details of canvas paths, so it's probably not a very good attempt) |
| 22:27 | <Hixie_> | pixel snapping just makes things ugly |
| 22:27 | <zewt> | well, you asked how exactly we want it to work, and I already gave one answer to that |
| 22:28 | <zewt> | depends on what you're rendering; it definitely shouldn't be the default |
| 22:28 | <Hixie_> | i didn't see anything in the thread that was detailed enough to count as an answer :-) |
| 22:32 | <zewt> | http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0342.html i think any more detail than that would be getting ahead of the discussion |
| 22:32 | <zewt> | (i don't know enough about canvas paths or implementations to know if it's a direction even worth following in any more detail) |
| 22:34 | <zewt> | afk |