| 03:09 | <Domenic> | Wait so what is the relationship between composed events and event retargeting |
| 03:10 | <Domenic> | composed = false means the event doesn't make it past the shadow root boundary? |
| 06:48 | <MikeSmith> | anybody awake who has written web-platform-test tests and ever run into the error “Cannot read property 'has_extended_attribute' of undefined” when running idlharness.js tests on an interface |
| 06:54 | <annevk> | Domenic: correct |
| 06:55 | <annevk> | Domenic: well, the shadow root boundary that is the event's target root, if any |
| 07:18 | <Ms2ger> | zcorpan, welcome back :) |
| 07:18 | <zcorpan> | Ms2ger: thx |
| 08:12 | <MikeSmith> | det var länge sedan zcorpan |
| 08:12 | <zcorpan> | MikeSmith: o/ |
| 08:12 | <MikeSmith> | glad you had a nice vacation but also glad you’re back :) |
| 08:15 | <zcorpan> | :-) |
| 08:15 | <zcorpan> | is there something i should deal with pronto? |
| 08:17 | <MikeSmith> | zcorpan: nope, though I reckon I will start recalling various things I’d wanted to ask you about |
| 08:17 | <MikeSmith> | zcorpan: dunno if you saw yet but I landed the ignore-template-subtree support in the HTML checker |
| 08:18 | <MikeSmith> | and it seems to work as expected |
| 08:18 | <MikeSmith> | it was a bit more complicated to implement than I had expected |
| 08:19 | <MikeSmith> | oh also you will find some interesting info at https://validator.w3.org/nu/stats.html if you scroll down |
| 08:20 | <MikeSmith> | zcorpan: ah one thing I wanted to ask you is please think about anything you think we should have the checker collect statistics on |
| 08:20 | <zcorpan> | MikeSmith: yeah i saw, nice |
| 08:21 | <MikeSmith> | e.g., I recently added a counter for <style> in body |
| 08:22 | <zcorpan> | Manually set character encoding 0 haha |
| 08:23 | <zcorpan> | hmm does v.nu still use us-ascii as default for text/xml? |
| 08:23 | <hsivonen> | zcorpan: possible |
| 08:23 | <botie> | hsivonen, at 2016-08-05 06:42 UTC, Ms2ger said: it :) |
| 08:23 | <zcorpan> | where is mozillaquestquest.com when you need it |
| 08:24 | <hsivonen> | :-) |
| 08:24 | <Ms2ger> | Thank you botie |
| 08:24 | <hsivonen> | fun fact: you can show the encoding UI even in the HTML5 UI using a magic URL: https://html5.validator.nu/?charset |
| 08:24 | <MikeSmith> | oh |
| 08:26 | annevk | runs git blame source |
| 08:26 | <annevk> | Maybe I should go make some tea |
| 08:27 | <MikeSmith> | hah |
| 08:27 | <MikeSmith> | for the HTML spec I find I have a lot more success just grepping through git log output than using blame |
| 08:29 | <MikeSmith> | because often the first blame doesn’t tell me what I want to know and then I have to recurse |
| 08:30 | <zcorpan> | MikeSmith: i recall hsivonen collected statistics of most common errors back in the day |
| 08:30 | <MikeSmith> | oh yeah? |
| 08:31 | <MikeSmith> | I wonder now how |
| 08:31 | <hsivonen> | zcorpan: very long ago. I haven't had that logging running in the recent years. |
| 08:31 | <annevk> | MikeSmith: grep failed to find it, or I did not know what to search for… 😞 |
| 08:32 | <MikeSmith> | ah |
| 08:32 | <MikeSmith> | annevk: if you have to recurse you might find https://github.com/scottgonzalez/recursive-blame useful |
| 08:33 | <MikeSmith> | though it’s broke for me in my environment right now |
| 08:34 | <zcorpan> | MikeSmith: https://lists.w3.org/Archives/Public/public-html/2008Jan/0305.html |
| 08:34 | <hsivonen> | MikeSmith: https://github.com/validator/validator/blob/cbca37f2a633edcb512395e260e5e5887882b28f/src/nu/validator/messages/MessageEmitterAdapter.java#L745 is the logger than needs to be enabled in the log4j config |
| 08:35 | MikeSmith | looks |
| 08:35 | <MikeSmith> | oh wow |
| 08:36 | <MikeSmith> | hsivonen: will that just log all the messages? but not count them, right? |
| 08:36 | <MikeSmith> | zcorpan: thanks |
| 08:37 | <annevk> | zcorpan: gsnedders: do you happen to know where the parser handles duplicate attributes? |
| 08:38 | <hsivonen> | MikeSmith: counting was with post-processing using traditional shell tools |
| 08:38 | <MikeSmith> | hsivonen: though I realize it would not be hard to just post-process that with some sort+uniq or whatever |
| 08:38 | <MikeSmith> | hsivonen: yeah |
| 08:38 | <annevk> | Or maybe MikeSmith / hsivonen knows? |
| 08:38 | <annevk> | As far as I can tell the tokenizer hands duplicates to the tree builder, but they're not handled there |
| 08:38 | <annevk> | We have a patch to fix it there: https://github.com/whatwg/html/pull/1637 |
| 08:39 | <annevk> | But I wonder whether I'm missing something |
| 08:39 | <zcorpan> | "When the user agent leaves the attribute name state (and before emitting the tag token, if appropriate), the complete attribute's name must be compared to the other attributes on the same token; if there is already an attribute on the token with the exact same name, then this is a parse error and the new attribute must be removed from the token." |
| 08:40 | <zcorpan> | we should inline that |
| 08:40 | <MikeSmith> | annevk: https://github.com/validator/htmlparser/blob/master/src/nu/validator/htmlparser/impl/Tokenizer.java#L1125 |
| 08:40 | <annevk> | zcorpan: that might make sense |
| 08:40 | <hsivonen> | annevk: paragraph at the end of the Attribute name state: https://html.spec.whatwg.org/multipage/syntax.html#attribute-name-state |
| 08:41 | <MikeSmith> | code comment in the htmlparser source is the same zcorpan quoted |
| 08:41 | <annevk> | zcorpan: where is <html test > <html test=2 x> handled? |
| 08:41 | <MikeSmith> | and same hsivonen just cited |
| 08:43 | <annevk> | zcorpan: never mind, found it |
| 08:47 | <MikeSmith> | zcorpan: OK, I' experiment |
| 08:47 | <MikeSmith> | oofs |
| 08:48 | <MikeSmith> | zcorpan: OK, for the checker I’ll experiment with turning on logging of all error messages so we can have raw logs to get most-common-errors data from |
| 08:49 | <zcorpan> | MikeSmith: ok cool |
| 08:49 | <MikeSmith> | not sure how long I can keep it running for the W3C instances given how much they get hit, but I reckon even just 24 hours of logs should give us what we need |
| 08:50 | <MikeSmith> | altogether they process about a million document requests every day |
| 08:51 | <MikeSmith> | and I reckon each document on average must have a dozen or more errors |
| 08:51 | <MikeSmith> | documents with hundreds of errors are not uncommon |
| 08:52 | <MikeSmith> | anyway, will need to wait til later this week. Today I have to work on writing tests for the Payment Request API |
| 08:54 | <MikeSmith> | hey a somewhat interesting side effect of the language-detection stuff I added is that I also created a specific (n-gram) profile to detect "Lorem ipsum" text |
| 08:55 | <MikeSmith> | and it turns out that "Lorem ipsum" documents are one of the top-20 most common “languages” detected |
| 08:56 | <MikeSmith> | about 0.3% of all documents checked |
| 08:58 | <MikeSmith> | 0.3% is more than, e.g., the number of Norwegian documents |
| 09:23 | <MikeSmith> | zcorpan: (and all) I notice that the HTML spec never normatively states what html@lang is |
| 09:23 | <MikeSmith> | instead it just says, “Authors are encouraged to specify a lang attribute on the root html element, giving the document's language.” |
| 09:23 | <MikeSmith> | should we make that normative |
| 09:24 | <zcorpan> | MikeSmith: it has normative text for the language of a node |
| 09:25 | <zcorpan> | https://html.spec.whatwg.org/multipage/dom.html#language |
| 09:29 | <MikeSmith> | ah OK |
| 09:31 | <MikeSmith> | so of node=HTMLHtmlElement, then it is the language for the entire document |
| 10:29 | <gsnedders> | annevk: the tokenizer does |
| 10:29 | <gsnedders> | annevk: gimme a min |
| 10:29 | <gsnedders> | annevk: oh, hsivonen already said |
| 10:30 | gsnedders | can't skim read when sleep depreived, obviously |
| 11:09 | <annevk> | Supporting the HTTP trailer is actually a whole lot of work |
| 12:32 | smaug____ | wonders if one should follow wicg |
| 12:32 | <smaug____> | I guess no |
| 14:00 | <annevk> | Domenic: I noticed fetch() is using entry setting objects |
| 14:14 | <MikeSmith> | is there a way to run chromium third_party/WebKit/LayoutTests from the web? |
| 14:14 | <MikeSmith> | just whatever is in the trunk I mean |
| 14:16 | <caitp> | doubt it |
| 14:17 | <caitp> | since layout tests often depend on special APIs not exposed to the web, it seems like it would be hard to run them from the web |
| 14:49 | <MikeSmith> | caitp: ok, makes sense |
| 20:41 | <Domenic> | annevk: :( |
| 21:38 | <jsbell> | let the record show that boris zbarsky is an awesomely helpful person |
| 21:40 | <astearns> | in my understanding, the record is littered with those sentiments |
| 22:48 | <smaug____> | could someone explain why https://w3c.github.io/webappsec-mixed-content/#categorize-settings-object works |
| 22:49 | <smaug____> | it just goes through from document to subdocument and possibly its descendants |
| 22:49 | <smaug____> | but doesn't go through all the subdocuments of the top level doc |
| 22:49 | <smaug____> | mkwst: ^ |
| 22:52 | <smaug____> | maybe I don't understand what "embedding document" means |
| 22:52 | <smaug____> | yes, I don't |
| 22:52 | <smaug____> | I don't know whether "embedding document" is ancestor or descendant |
| 22:53 | <smaug____> | Domenic: you might be awake |
| 22:54 | <smaug____> | or annevk |
| 23:10 | <jyasskin> | smaug____: It'll be the ancestor. Follow https://w3c.github.io/webappsec-mixed-content/#embedding-document and https://html.spec.whatwg.org/multipage/browsers.html#browsing-context-nested-through |
| 23:10 | <smaug____> | yup |
| 23:11 | <smaug____> | the language could be a bit simpler to read... or I should not read it at 2am |
| 23:17 | <jyasskin> | I think it could use "parent document" by analogy to "parent browsing context" (https://html.spec.whatwg.org/multipage/browsers.html#parent-browsing-context). It gives me a bit of pause that https://www.w3.org/TR/html51/browsers.html#sec-nested-browsing-contexts is quite different from |
| 23:17 | <jyasskin> | https://html.spec.whatwg.org/multipage/browsers.html#nested-browsing-contexts. |
| 23:56 | <Domenic> | Yeah, webappssec linking to the wrong spec causes a lot of problems for people trying to understand the specs :( |
| 23:56 | <Domenic> | Would be better to follow CSSWG policy and link to the fork only for REC snapshots, and leave EDs linking to the HTML Standard. |