00:29:51  * bradleymeckjoined
00:53:02  * bradleymeckquit (Quit: bradleymeck)
01:06:58  * bradleymeckjoined
01:06:58  * bradleymeckquit (Client Quit)
01:47:22  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
03:21:56  <ljharb>i mean wouldn't `<nav>` be the right semantics
04:17:14  <jmdyck>?
04:47:49  * jmdyckquit (Quit: Leaving.)
05:44:58  * gskachkovquit (Quit: gskachkov)
06:20:17  * not-an-aardvarkjoined
07:22:58  * gskachkovjoined
08:25:13  * gskachkovquit (Read error: Connection reset by peer)
08:29:17  * gskachkovjoined
09:19:59  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
10:25:06  * mylesborinsquit (Quit: farewell for now)
10:25:37  * mylesborinsjoined
10:46:48  * jmdyckjoined
13:31:53  * AtumTjoined
14:10:31  * caridyquit (Remote host closed the connection)
14:11:15  * caridyjoined
14:15:08  * bradleymeckjoined
14:22:31  * bradleymeckquit (Quit: bradleymeck)
14:25:08  * Draggor1changed nick to Draggor
14:32:28  * cloudshujoined
14:44:40  * bradleymeckjoined
14:50:29  * bradleymeckquit (Quit: bradleymeck)
14:51:06  * gskachkovquit (Read error: Connection reset by peer)
14:59:01  * gibson042quit (Ping timeout: 240 seconds)
14:59:40  * Fishrock123joined
15:13:47  * gibson042joined
15:13:57  * chicoxyzzyjoined
15:13:57  * chicoxyzzyquit (Client Quit)
15:40:40  * Fishrock123quit (Remote host closed the connection)
15:41:18  * Fishrock123joined
15:41:26  * Fishrock123quit (Remote host closed the connection)
15:44:46  * bradleymeckjoined
15:45:22  * gskachkovjoined
15:46:39  * duanebjoined
15:49:04  * Fishrock123joined
15:50:23  * bradleymeckquit (Quit: bradleymeck)
15:54:31  * duanebquit (Quit: Textual IRC Client: www.textualapp.com)
16:02:04  * bradleymeckjoined
16:18:17  * Havvyquit (Read error: Connection reset by peer)
16:19:05  * Havvyjoined
17:23:50  * bradleymeckquit (Quit: bradleymeck)
17:30:11  * Fishrock123quit (Remote host closed the connection)
17:47:27  <TabAtkins>jmdyck: I presume the ids are autogenerated from the text, thus there's no need to have them written in explicitly.
17:47:56  <TabAtkins>The point of oldids is to tell the generator to insert more anchors into the h1 so that links will still work.
18:12:07  <jmdyck>The ids in the spec when it moved from Word to ecmarkup were copied from jorendorff's html-ification of ES6. I believe those ids were autogenerated from the text, although there were a few cases that didn't seem to fit. Ids added since then haven't always followed the pre-existing scheme (which is undestandable, since the scheme wasn
18:12:15  <jmdyck>wasn't documented.)
18:14:39  <jmdyck>And yes, I understand the point of oldids: that's why I 'invented' it. (And then you told me that Bikeshed already had it.)
18:15:49  * bradleymeckjoined
18:18:32  <TabAtkins>Ah, didn't realize you'd invented. ^_^ (In that case I don't really understand your previous comments.)
18:18:51  <jmdyck>which ones?
18:35:55  * AtumT_joined
18:37:52  * AtumTquit (Ping timeout: 248 seconds)
18:38:27  * paulfryzeljoined
18:47:30  * Fishrock123joined
18:48:06  * AtumTjoined
18:48:44  * AtumT_quit (Ping timeout: 255 seconds)
19:30:08  * gskachkovquit (Quit: gskachkov)
19:52:28  * gskachkovjoined
20:02:22  * Fishrock123quit (Remote host closed the connection)
20:10:35  * Fishrock123joined
20:40:23  * not-an-aardvarkjoined
20:47:41  <TabAtkins>jmdyck: Your comments suggesting that oldids can ever result in a change to the `id`attribute on the element; it should always be adding extra anchors to the element's children with the specified ids.
20:50:03  <ljharb>that sounds right to me?
20:50:39  <ljharb>every ID in `oldids` must always be present in the document; the main `id` shouldn't be in `oldids` (because it's not "old"), and if the main `id` ever changes, the previous value must move to `oldids`
20:50:51  <jmdyck>Hm, don't think I ever said that oldids would result in a *change* of an 'id' attribute.
20:51:17  <jmdyck>Maybe you're thinking of...
20:51:23  <TabAtkins>"(If there's multiple ids in the oldids, you can't put them all in the h1, so maybe better to create <a id=> for each)"
20:51:32  <TabAtkins>Which implies you can put one of them on the h1.
20:52:14  <jmdyck>Yes, you can, in fact that's how the current spec.html handles a few old ids.
20:52:42  <jmdyck>but of course that doesn't scale to more than one old id per clause.
20:52:54  <TabAtkins>That's some pretty inconsistent semantics, then. :(
20:53:14  <jmdyck>which is what I was saying in that quote.
20:53:56  <jmdyck>not sure what is inconsistent with what.
20:58:58  <jmdyck>Note that (as i pointed out later), in the currrent spec.html, <h1> elements don't have 'id' attributes except for the old id purpose above. So using h1@id for this purpose doesn't *change* an h1's attribute, nor is it inconsistent with some other intended semantic for h1@id.
20:59:26  <jmdyck>However, it's not a good idea for other reasons, which is why I have a PR to get rid of it.
21:11:41  <TabAtkins>Yeah, I assumed that <h1>s always auto-gen their ID, and thus implicitly always have an id in the output aside from anything specified in `oldids`.
21:12:19  <TabAtkins>(That's how Bikeshed works. It just, separately, also complains if you don't give <h1>s an ID, since their text contents change too often to be a source of stable autogen ids.)
21:17:24  <jmdyck>(I was talking about <h1>s in the source doc, but it looks like it's true of the rendered doc as well.)
21:20:08  <jmdyck>The render doc does have some generated id attrs, but only for <emu-xref>s, I think.
21:22:53  <jmdyck>Ah, also <emu-nt>.
21:24:34  <jmdyck>afk
22:15:22  <bterlson>bah just appending child as child is hard when I have first-child css rules
22:15:33  <bterlson>err, appending oldids as children
22:51:04  * Fishrock123quit (Quit: Leaving...)
22:58:52  <TabAtkins>(I append to end, partially to avoid that sort of thing.)
22:59:13  <bterlson>doesn't that cause the link to go to a different place?
23:00:05  <TabAtkins>No? Why would it? I guess if the heading text wraps to multiline it'll scroll to the last line of the heading text, but eh.
23:01:08  <bterlson>ahh for header ids it would work
23:10:13  <bterlson>jmdyck: I like `in` better than `within` (re: https://github.com/tc39/ecma262/pull/971/commits/34848155ee8ba255414abf182fe0268e87627b35)
23:12:58  <bterlson>maybe I like `of` even more
23:24:14  * bradleymeckquit (Quit: bradleymeck)
23:57:09  <jmdyck>bterlson: I don't much mind which. I picked "within" for the reason in the commit msg, but that's not a hugely compelling reason.