| 06:32 | SamB | wonders why you can't use an SSH key to authenticate with an http[s] server ... |
| 08:40 | <MikeSmith> | U+000C isn't whitespace in CSS? |
| 08:41 | <Ms2ger> | What is whitespace, really, if you think about it |
| 08:56 | <caitp> | how often are those control characters used these days in web documents? |
| 09:08 | <MikeSmith> | caitp: probably not at all. But the problem is, the HTML spec defines U+000C as a space character but CSS doesn't, and I'm writing code to parse CSS in HTML "sizes" and "media" attributes but I can't reuse the existing space-processing code I have for HTML |
| 09:08 | <caitp> | mm |
| 16:29 | <Ms2ger> | MikeSmith, is irc.w3.org still down? |
| 16:29 | <gsnedders> | down for me |
| 16:38 | <Ms2ger> | Hm, all of w3.org seems to be down |
| 16:52 | <Ms2ger> | Back up |
| 16:53 | <Ms2ger> | (IRC, at least) |
| 20:00 | <zcorpan> | MikeSmith: i thought it was whitespace in css also |
| 21:04 | <MikeSmith> | zcorpan: http://drafts.csswg.org/css-syntax/#whitespace-diagram and http://drafts.csswg.org/css-syntax/#whitespace |
| 21:06 | <zcorpan> | MikeSmith: drafts.csswg.org/css-syntax/#input-preprocessing |
| 21:06 | MikeSmith | looks |
| 21:07 | <MikeSmith> | zcorpan: ah OK good |
| 21:07 | <MikeSmith> | FF -> LF I see |
| 22:04 | <SimonSapin> | "User agents are encouraged to expose parse errors somehow." Does anyone care about this in practice, outside of validators? http://url.spec.whatwg.org/#parse-error |
| 22:05 | <SamB> | SimonSapin: you mean, like, the Console? |
| 22:05 | <SimonSapin> | SamB: yeah, for example, does any browser report non-fatal URL parse errors in their Console? |
| 22:06 | <SamB> | SimonSapin: I'm not sure; at the time when it would be doing that, the console usually gets cleared anyway |
| 22:42 | <zcorpan> | SimonSapin: i think several browsers log HTML parse errors |
| 22:43 | <SimonSapin> | zcorpan: There is at least one URL parse error that neither Chromium nor Firefox logs (this is how much testing I’ve done so far) |
| 22:43 | <SimonSapin> | (one URL parse error in the spec) |
| 22:44 | <zcorpan> | SimonSapin: the URL so spec isn't implemented yet is it? |
| 22:44 | <zcorpan> | -so |
| 22:44 | <SimonSapin> | zcorpan: I don’t know, maybe not |
| 22:45 | <SimonSapin> | I’m implementing it in Rust, but it seems so far that only annevk cares about non-fatal URL parse errors |
| 22:46 | <SimonSapin> | detecting parse errors slightly increases the code complexity |
| 22:46 | <SimonSapin> | but then I have no good way to log them, for a library that way be used outside of a browser |
| 22:47 | <SimonSapin> | Does html5lib log parse errors? |
| 22:47 | <SimonSapin> | gsnedders: ^ |
| 22:47 | <zcorpan> | yes |
| 22:48 | <SimonSapin> | where do they go? |
| 22:50 | <gsnedders> | SimonSapin: it can |
| 22:50 | <gsnedders> | SimonSapin: I think it always does |
| 22:50 | <gsnedders> | SimonSapin: there's some API from the parser, maybe errors or something? |
| 22:50 | <gsnedders> | idk |
| 22:51 | <SimonSapin> | looks like HTMLParser().errors is a list of tuples |
| 22:52 | <SimonSapin> | gsnedders: any opinion on URL parse errors? |
| 22:54 | <gsnedders> | SimonSapin: what sort of opinions? :P |
| 22:54 | <SimonSapin> | should they be logged, or does nobody care? |
| 22:54 | <gsnedders> | out of scope |
| 22:54 | <gsnedders> | much like we don't report CSS parse errors |
| 22:55 | <SimonSapin> | I mean for a URL parsing library |
| 22:55 | <gsnedders> | It'd be nice to log them, at least optionally |
| 23:06 | <gsnedders> | SimonSapin: Also, note that people said nobody cared about exposing parse errors until HTML5 parsers suddenly started doing so |
| 23:08 | <SamB> | gsnedders: how else are they supposed to test that they had correctly *detected* them? |
| 23:08 | <gsnedders> | there's no requirement to detect them |
| 23:08 | <gsnedders> | just handle them correctly |
| 23:09 | <gsnedders> | and handling can be tested by checking the output DOM |
| 23:09 | <SamB> | yes, but it makes it harder to tell whether or not you keeping your branches straight if you don't report them ;-) |
| 23:09 | <SamB> | +'re |
| 23:10 | gsnedders | only very briefly had anything to do with any browser impl |
| 23:10 | <gsnedders> | very very briefly |
| 23:28 | <SimonSapin> | SamB: I’m not very familiar with the HTML parser, but I believe it’s similar to URL: the spec defines what implementations should do in all cases. Additionally, in some cases, it says "this is a parse error". Which in itself does not affect the implementation (except if it chooses to log such errors), it only expresses author requirements |
| 23:28 | <SimonSapin> | a validator would check author requirements |
| 23:28 | <gsnedders> | SimonSapin: browsers log parse errors when the console is open |
| 23:29 | <gsnedders> | SimonSapin: or at least WebKit, Blink, and Presto do. I think Trident too. |
| 23:29 | <gsnedders> | I'm pretty sure Gecko logs them, um, somewhere. |
| 23:29 | <SamB> | SimonSapin: yes, well, I assume it's a lot easier to verify that the parser logic has been accurately translated into code if you can see those parse errors ;-) |
| 23:30 | <SamB> | or at least to sanity-check it |
| 23:32 | <SimonSapin> | hum, I wouldn’t say "a lot easier" |