| 08:08 | <annevk> | I feel somewhat conflicted with whether to respond to https://github.com/w3c/dom/issues/91 |
| 08:09 | <annevk> | It seems like publishing a WD that's essentially the same as the broken REC will waste a lot of folks their time looking through it |
| 10:43 | <No_se> | Hello! Are you running the Nu Html checker service on w3.org? |
| 10:44 | <No_se> | I just created an issue on github and wonder if I got the markup right. |
| 10:53 | <Ms2ger> | MikeSmith, ^ |
| 10:58 | <No_se> | After simply copy pasting from the github issue into the validator: Nvm the markup question. Just worry about the issue ;-) |
| 11:03 | <hsivonen> | so hard to write commit messages without a trailing period for the WHATWG when m-c has taught me to use a trailing period |
| 11:14 | <zcorpan_> | hsivonen: you can let the merger worry about the commit message :-) |
| 11:14 | <hsivonen> | zcorpan_: ok |
| 11:35 | <MikeSmith> | No_se: yeah I run the W3C instance of the Nu Html Checker |
| 11:35 | <MikeSmith> | No_se: do you mean https://github.com/validator/validator/issues/446? |
| 11:35 | <No_se> | yes |
| 11:36 | <No_se> | I can give a live URL with the issue, if that's faster than my minimal example |
| 11:36 | <No_se> | https://www.videolan.org/vlc/download-ubuntu.html but you do not want to look at that code... |
| 11:37 | <MikeSmith> | well regardless the answer is that the checker is behaving as expected |
| 11:37 | <MikeSmith> | you can't put a <ul> tag as a child if a <p> tag in your markup |
| 11:38 | <MikeSmith> | it will not end up in the DOM that way after parsing |
| 11:38 | <No_se> | Sorry fir the noise then. Gonna check the spec again |
| 11:38 | <MikeSmith> | well this is not completely obvious from the spec |
| 11:38 | <MikeSmith> | it causes confusion regularly |
| 11:39 | <MikeSmith> | and the error message from the checker for this case it not very helpful |
| 11:40 | <MikeSmith> | but what happens is, the parser closes that <p> element in the DOM before it starts the <ul> element |
| 11:41 | <No_se> | So, giving a message at opening the <p> woud be the way to go for the validator? |
| 11:41 | <MikeSmith> | so then later when it comes across the closing </p> tag after the <ul> element, it says “No p element in scope but a p end tag seen” |
| 11:41 | <MikeSmith> | we can’t easily make the checker emit an additional message in this case |
| 11:42 | <MikeSmith> | well we could but it would add unnecessary noise for other normal cases |
| 11:42 | <MikeSmith> | because closing </p> tags are not required in many normal cases |
| 11:42 | <MikeSmith> | well even a lot of people would consider this <p><ul> a normal case |
| 11:43 | <MikeSmith> | they would just not have a closing </p> anywhere in their markup in that case |
| 11:44 | <MikeSmith> | arguably you can make your life easier by not using closing </p> tags anywhere |
| 11:44 | <MikeSmith> | not closing </li> tags or others that aren’t strictly required |
| 11:45 | <No_se> | So consider <p> similar as <br /> and be done with it? |
| 11:45 | <MikeSmith> | yup |
| 11:45 | <MikeSmith> | that is what I do personally |
| 11:45 | <MikeSmith> | that is was <p> was originally when HTML was created |
| 11:46 | <AutomatedTester> | what is the state of web components these days? |
| 11:46 | <MikeSmith> | it was defined as a “paragraph break” when it was created |
| 11:46 | <MikeSmith> | No_se: the notiion of the p element being a container was something bolted on later |
| 11:47 | <MikeSmith> | No_se: anyway, others would disagree with me about whether you should use </p> end tags or not |
| 11:47 | <MikeSmith> | AutomatedTester: supported quite well in Blink and WebKit |
| 11:48 | <AutomatedTester> | MikeSmith: ok, and the spec is "stable" ? |
| 11:48 | <MikeSmith> | yes, stable |
| 11:49 | <MikeSmith> | Apple and Google have gotten past the previous big disagreements they had, and what is in the spec now represents strong consensus |
| 11:50 | <MikeSmith> | modulo normal open issues where discussion is still going on |
| 11:50 | <AutomatedTester> | yea, I last heard about the disagreements and wasnt sure if they had been cleared up and if the spec was close to what was agreed |
| 11:50 | <MikeSmith> | and Mozilla and Microsoft also supportive of current spec, and actively worked on getting it made |
| 11:50 | <AutomatedTester> | MikeSmith: thank you! |
| 11:50 | <MikeSmith> | cheers |
| 12:01 | <hsivonen> | is "dismiss review" the right UI to use for indicating that all issues in the review have been addressed? |
| 12:02 | <hsivonen> | doesn't sound like it but that UI removes the red X |
| 12:07 | <Ms2ger> | It's what I use; possibly the intended workflow is that the reviewers does a new review that's marked as approved |
| 12:11 | <annevk> | Yeah I think the reviewer can hit approve |
| 12:11 | <annevk> | Or dismiss themselves |
| 12:41 | <zcorpan> | MikeSmith: the real paragraph break is to always use </p>, never <p> :-D |
| 12:42 | <zcorpan> | No_se: not using an initial <p> or a <p> after a list or a table seems like it would give less control or unexpected results with styling |
| 12:44 | <zcorpan> | like p { margin: 2em 0 } would not apply the extra spacing to text not in p |
| 13:51 | <MikeSmith> | annevk: so I made some changes to the MDN “HTTP access control (CORS)” both to add a note about the WebKit “non-standard” header-values thing and also to fix some other inaccuracies and bring it closer in sync with the current spec |
| 13:52 | <annevk> | MikeSmith: cool |
| 13:55 | <MikeSmith> | annevk: if you have time to sanity-check the changes, the content is in the https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS?document_saved=true#Simple_requests section and in the https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS?document_saved=true#Preflighted_requests |
| 13:56 | <MikeSmith> | and the info is essentially duplicated in those sections |
| 13:56 | annevk | looks |
| 13:57 | <MikeSmith> | but that duplication is because, from seeing Stackoverflow questions, some people read one of those sections but not the other |
| 13:57 | <annevk> | MikeSmith: I kinda dislike we still call them "preflight requests" although I guess they don't really have a name anymore in Fetch |
| 13:57 | <MikeSmith> | well |
| 13:58 | <MikeSmith> | Fetch also does not have “simple requests” |
| 13:58 | <annevk> | sorry, that's what I meant |
| 13:58 | <MikeSmith> | yeah I am reluctant to change that right now at least |
| 13:58 | <annevk> | preflight requests are still a thing, it's simple requests that's kinda wrongish |
| 13:58 | <MikeSmith> | right |
| 13:58 | <MikeSmith> | but that section is linked to in quite a lot of places I think |
| 13:58 | <annevk> | conditions look okay from a quick skim |
| 13:58 | <MikeSmith> | OK |
| 13:59 | <hsivonen> | as seen in zcorpan's review of my PR, Python's narrow vs. wide build distinction is even worse than I thought |
| 13:59 | <annevk> | Yeah I ran into that when writing IDNA tests |
| 14:00 | <annevk> | Python is rather terrible when it comes to Unicode |
| 14:04 | <annevk> | hsivonen: I might be able to look later today again, but might take a little longer today |
| 14:04 | <annevk> | hsivonen: kid was unexpectedly sick |
| 14:04 | <hsivonen> | no hurry |
| 14:15 | <MikeSmith> | annevk: is there actually any equivalent term for “simple request” in the current Fetch spec? |
| 14:20 | <MikeSmith> | oh I see you said earlier, “although I guess they don't really have a name anymore in Fetch” |
| 14:27 | <Ms2ger> | An interesting find: https://bitbucket.org/prestocore-fan/presto/ |
| 14:28 | <MikeSmith> | holy god |
| 14:30 | MikeSmith | clones a copy before it disappears |
| 14:30 | <MikeSmith> | zcorpan: ⬆ |
| 14:45 | <zcorpan> | hsivonen: per https://docs.python.org/3/whatsnew/3.3.html#functionality a possibility would be to switch to 3.3 |
| 16:03 | <wanderview> | annevk: I updated the doodle for the fetch meeting, but unfrotunately my schedule is not very flexible due to taking my kids to school in the monring |
| 16:03 | <wanderview> | feel free to schedule without me if that makes sense |
| 16:27 | <annevk> | wanderview: the doodle isn't flexible for similar reasons, hopefully it'll work out |
| 16:28 | <wanderview> | well, I noticed I am the exact opposite time availability with other people on there :-\ |
| 16:37 | <annevk> | Oh 😞 |
| 16:38 | <annevk> | For Chrome bugs, is there a URL to file a new one that puts it in Blink triage? rbyers, maybe you know? |
| 16:40 | <Domenic> | annevk: mostly it's a matter of adding appropriate components. Does your UI allow that? |
| 16:40 | <Domenic> | If not we should probably add you to some list that does. |
| 16:42 | <annevk> | Domenic: I can, but looking to reduce clicks |
| 16:43 | <annevk> | Domenic: and not forgetting about it |
| 16:44 | <Domenic> | Hmm I see. Maybe there is a URL that pre-fills form fields but that'll always have the disadvantage of requiring an extra round of triage: Blink -> more specific component via human triage -> actual owner |
| 16:45 | <Domenic> | Seems ideal if you can figure out the more specific component yourself so it gets routed to the appropriate team immediately instead of going through the first round |
| 17:03 | <gsnedders> | MikeSmith: I presume you have no intention to extend validator.nu to check CSS too? |
| 17:30 | <annevk> | Oh, someone translated the DOM4 document into Russian |
| 17:31 | <annevk> | That's kinda sad as the document is way out of date |
| 17:48 | <nox> | annevk: In Russia, DOM outdates you. |
| 17:49 | <annevk> | In Russia, W3C DOM is relevant. |
| 17:49 | <nox> | Ah ah. |
| 17:49 | <annevk> | But really, the translator got duped |
| 17:50 | <nox> | Yeah that sucks. :( |
| 17:53 | <tantek> | annevk, if you can share with me the links (out of date doc, translation, any apparent context about how/why it happened), I'll document it as another problem W3C TR is causing |
| 18:00 | <annevk> | tantek: https://lists.w3.org/Archives/Public/www-dom/2017JanMar/0009.html https://lists.w3.org/Archives/Public/www-dom/2017JanMar/0010.html https://lists.w3.org/Archives/Public/www-dom/2017JanMar/0011.html |
| 18:01 | <tantek> | tx |
| 19:00 | <Domenic> | I continue to be amused by bugs of the form "when arbitrary script runs inside my page, feature X is no longer secure!" |
| 19:06 | <hsivonen> | zcorpan: does Apple ship Python 3? |
| 19:06 | <zcorpan> | hsivonen: don't think so |
| 19:07 | <hsivonen> | zcorpan: Python 3 in general is a bad idea. It would be better for the project formerly known as Python 2.8 to eliminate the narrow vs. wide variability |
| 19:22 | <rbyers> | annevk, domenic: regarding filing blink bugs - non-project-members get sent to the wizard by default (which anyone can reach at http://crbug.com/wizard) which, once you specify it's a developer issue, let's you pick the component which gets it directly to the right team. |
| 19:23 | <rbyers> | But for you that's probably a couple more clicks than you'd like. Do you already have chromium edit-bugs access to set your own labels? If not, I can give you that. |
| 19:23 | <rbyers> | Or I can give you a URL to file bugs with a pre-specified set of labels. Eg. If it has Component>Blink then it'll be triaged by our (pretty effective IMHO) web platform triage process. |
| 19:24 | <rbyers> | (Crap, that reminds me I'm on triage duty today for such bugs - better get working on that!) |
| 20:03 | <annevk> | rbyers: I have edit-bugs, would like that link |
| 20:03 | <annevk> | rbyers: at some point an API maybe, could be nice coupled with a GitHub bot… |
| 20:32 | <tobie> | jyasskin: wondering if you were back |
| 20:35 | <tobie> | rbyers: would love one too for WebIDL: https://github.com/heycam/webidl#breaking-changes-should-be-filed-against |
| 20:36 | <jyasskin> | tobie: I'm back as of today. |
| 20:37 | <tobie> | jyasskin: oh really? wow. well, good luck with those emails. :D |
| 20:37 | <jyasskin> | :) |
| 20:37 | <tobie> | jyasskin: should I send help? |
| 20:38 | <jyasskin> | tobie: I've ordered a shovel, but it's held up in the PDX ice storm. |
| 20:38 | <tobie> | jyasskin: darn. poor timing. |
| 20:39 | <tobie> | jyasskin: would like to catch up on permissions. Not urgent. But sooner would be better than later. |
| 20:40 | <jyasskin> | tobie: Sounds good. |
| 20:40 | <tobie> | jyasskin: I'll send you and email with some details and maybe you could spare an hour next week to discuss those? |
| 20:41 | <jyasskin> | tobie: I should be able to spare an hour this week. What time zone are you in again? Does tomorrow work? |
| 20:42 | <tobie> | GMT + 1 |
| 20:42 | <tobie> | jyasskin: So 9 hours ahead of you, I suppose. |
| 20:43 | <tobie> | Yeah tomorrow would work. |
| 20:44 | <tobie> | jyasskin: noon? |
| 20:44 | <jyasskin> | My noon, your 9pm? Works for me. |
| 20:46 | <tobie> | jyasskin: awesome. |