freenode :: #whatwg

17 Mar 2017
00:18wanderviewJakeA: its possible we could have an initial implementation of that in nightly for the meeting
00:23wanderviewI just need to review the patches in here: https://bugzilla.mozilla.org/show_bug.cgi?id=1341738
00:58TabAtkinsannevk: Just FYI, I saw your pings, but was busy all day working with fantasai, and am about to be gone for a week. I'll get back to you on or soon after the 27th.
01:14JakeAwanderview: fetch cancellation? Oh wow, that'd be ace
01:15wanderviewyea
01:15wanderviewbaku already wrote it... I just have to find the time to review it
01:16wanderviewJakeA: are you still on holiday?
01:18JakeAwanderview: half and half. I've been working this week but off next week
01:19wanderviewcool
01:21wanderviewJakeA: I was thinking maybe we could do a "what have we been doing in the last 6 months" segment
01:21wanderviewJakeA: to give some context about what each team has been focusing on and is probably going to focusing on in near future
01:30JakeAwanderview: that's a great idea. Will ask our team to do the same
05:03annevkJakeA: there was some other issue I pointed out
05:04annevkJakeA: exposing sw mode
08:33jochen__annevk: why is createProcessingInstruction() on an HTMLDocument supported?
08:34annevkjochen__: probably because restricting it is rather meaningless?
08:37jochen__hum, according to mdn it used to be restricted to XMLDocuments
08:38annevkjochen__: I think that's true, but I think we removed the restriction because the restriction doesn't actually restrict anyone from creating one
08:39annevkjochen__: looks like it was changed six years ago: https://github.com/whatwg/dom/commit/7c03f8dff921371e36b755cbb6370eea6a0e8a37
08:40annevkjochen__: unfortunately we didn't file bugs for all implementations back then
08:41jochen__seems to work in blink :)
08:41annevkjochen__: so just MDN that's wrong then?
08:54annevkmkwst: you never got back to me in https://github.com/w3c/web-platform-tests/pull/2356
08:55mkwstWow. That's an old PR.
08:55mkwstI'll take a look.
09:00KiChjangdoes anyone know why script tags MUST have a </script> closing tag in order to properly close it?
09:01KiChjangi hear that if you do something like <script src=&quot;...&quot; /> in some browsers, anything that goes after it would be treated as inline JS until the next </script> tag is encountered
09:02KiChjangthat doesn&#39;t sound like intended behaviour to me, or is this actually specc&#39;d out?
09:02annevkKiChjang: /> is a thing invented by XML that HTML didn&#39;t support until it got support for inline SVG and MathML and then it only supported it there
09:02annevkKiChjang: the HTML parser is very much specified in detail
09:03annevkmkwst: I&#39;m cleaning up web-platform-tests a bit and that includes my own forgotten stuff
09:06KiChjangannevk, ah, so the self-closing tag on script didn&#39;t follow XML semantics?
09:06annevkKiChjang: I&#39;m not sure what that means
09:07KiChjangi&#39;d expect that a self-closing script tag (<script src=&quot;...&quot; />) would not treat anything after it as inline JS
09:08annevkKiChjang: again, HTML doesn&#39;t have self-closing tags, apart from the SVG and MathML islands which are very much contained
09:08KiChjangwait if that&#39;s so, then this syntax is actually invalid HTML?
09:09annevkKiChjang: yes
09:09* KiChjang mindblown
09:09annevkKiChjang: you can use it on void elements, e.g., <img/>
09:10annevkKiChjang: but not on arbitrary elements
09:10annevkKiChjang: and we only allow it on void elements because of the XHTML craze in the 00s
09:11KiChjangdid <br> became a void element just because of this?
09:11KiChjangi think i recall it not being one before
09:11annevkIt was always a void element
09:11annevkWhat changed is that it&#39;s now valid to write <br/>
09:12annevk(It also used to have a different name from void element, just an element without end tag I think, but that doesn&#39;t matter much)
09:18KiChjangit&#39;s kinda surprising how everything i learnt lately about HTML tags are actually all wrong
09:19annevkMaybe you&#39;re reading books from the early 00s?
09:19KiChjangi do recall that back during 00s, closing tags must always be written in HTML
09:19KiChjangit&#39;s sometime in the future it became unnecessary and /> was the new syntax that everyone was going for
09:20annevkThat was the XML dream that never panned out
09:20KiChjangyes, i remember reading something that says you need to specify the HTML document version before the <head> tag
09:21KiChjangand if you want XHTML, you also need to specify it and its version
09:21KiChjanglooks like we&#39;ve come a long way just to use HTML again
09:21annevkversion?
09:21KiChjangyes, 1.0 IIRC
09:21annevkKiChjang: https://annevankesteren.nl/2007/04/html-red-pill
09:22KiChjangah, i&#39;m talking about during the XHTML craze
09:22annevkah
09:22KiChjangwasn&#39;t that the case?
09:23annevkYeah, you&#39;d have the 1.0 or 1.1 DOCTYPE
09:23annevkAnd then it could be transitional or strict
09:23KiChjanglol this brings back memories
09:23annevkAnd all kinds of other nonsense that didn&#39;t actually have a meaningful processing model attached to it
09:23KiChjangi never figured out the difference between trasitional and strict
09:23annevkKiChjang: comes down to https://quirks.spec.whatwg.org/ mostly
09:53noxShould reparented text nodes be coalesced when parsing?
09:55noxLet me check if the test mentioned in https://github.com/servo/servo/issues/15979 passes in Firefox...
12:54mkwstDoes HTML expose a concept of &quot;active&quot; browsing contexts? That is, I would like to say something about the tab a user is interacting with, and not the thirtieth tab on a background window the user forgot they&#39;d opened.
13:32wanderviewmkwst: I was going to say you could use the has-focus-steps... but I think they are busted atm
13:35mkwstStep 1 of https://html.spec.whatwg.org/#has-focus-steps talks about &quot;the top-level browsing context&quot;. Which top-level browsing context?
13:36wanderviewmkwst: right... it incorrectly says any top level window has focus
13:36wanderviewI think JakeA wrote an issue against it
13:36mkwstwanderview: Got it.
13:36wanderviewhttps://github.com/whatwg/html/issues/2391
13:37wanderviewof course we still have stuff depending on this algorithm
13:37wanderviewin service workers clients.matchAll() is intended to be ordered such that windows most recently interacted with are first
13:38mkwstI see. I guess from a practical perspective, this seems like the right algorithm to reference, and I can just assume that annevk, et al will fix it up? :)
13:39wanderviewprobably
13:39annevkHmm, if you have bandwidth apart from coming up with Q1 goals that&#39;d be great
13:40mkwstI still have a good ~2 weeks to come up with my plans for Q1.
15:58annevkIf anyone fancies reviewing Infra PRs, I put up a bunch
16:10annevkThanks mkwst! Will reply to the rest later today most likely, gotta collect the kid and food
16:10mkwstNo worries! Thanks for your work!
17:18DomenicPosted https://github.com/tabatkins/bikeshed/issues/958 (/cc zcorpan)
17:19Domenicannevk: excited to review infra PRs, I was just thinking yesterday how it needed a bit more love
17:20annevkDomenic: four PRs left
17:20annevkDomenic: I guess you&#39;re correct about label research, probably often it can be solved by using a different &quot;function&quot; instead as well
17:21DomenicYeah, although that&#39;s generally an area where specs do less breaking things into functions than software does... not sure exactly why though
17:26annevkDomenic: maybe no labels indeed: http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html
17:27annevkDomenic: perhaps in part standards do that to avoid having other standards rely on what they consider internal methods
17:27DomenicAh that&#39;s an interesting point
17:27annevkDomenic: we don&#39;t really have a good public/private API story for standards
17:28annevkDomenic: the &quot;host&quot; convention from JavaScript doesn&#39;t really work for us I think
17:30DomenicAgreed, and that isn&#39;t really quite solving the same problem
17:31DomenicI&#39;m not sure what an unobtrusive convention could be
17:31DomenicI&#39;m thinking like a little &quot;E&quot; box next to the <dfn> or something? I dunno.
17:35annevkDomenic: maybe we should mark public DFNs green?
17:35Domenicooh color that might work...
17:35annevkDomenic: just like headers
17:36annevkDomenic: and we just tag them somehow, we don&#39;t base it off export, since there&#39;s often folks wanting to refer to private stuff anyway
17:37Domenicwait why wouldn&#39;t we base it off export?
17:39annevkDomenic: I&#39;m not sure if it happens just with monkey patches, but for those you often want to refer to things that you&#39;d not normally consider a public API
17:40annevkDomenic: the other example is CSP explaining how it interleaves with various sub-fetch algorithms such as HTTP-network fetch that shouldn&#39;t be invoked on their own
17:40annevkSo yeah, that&#39;s why you sometimes want to export private entry points
17:42DomenicHmm
17:42DomenicI&#39;d maybe make that opt-out
17:42DomenicE.g. <dfn export notpublic>
17:44annevkSeems reasonable
17:44annevkWe should probably do it through Bikeshed since you want some kind of title attribute generated as well, so it&#39;s at least somewhat accessible
18 Mar 2017
No messages
   
Last message: 9 days and 23 hours ago