08:03
<ondras>
hmh, is "-webkit-any-link" handled specially with respect to specificity? the UA's "a:-webkit-any-link" does not seem to be more specific/strong than my plain "a"...
08:49
<ondras>
or perhaps the UA origin is always weaker than Author origin, right
11:13
<MikeSmith>
annevk: not WPT tests for AbstractRange?
11:13
<annevk>
MikeSmith: tests in what sense?
11:14
<annevk>
MikeSmith: there must be IDL tests by now
11:14
<MikeSmith>
yeah there are IDL tests
11:15
<annevk>
MikeSmith: so btw, if this is about the upcoming DOM RD / W3C ?, note that I haven't seen any activity on infrastructure support for the W3C ? bit
11:15
<annevk>
MikeSmith: and I think I did mention to people that needed to be done
11:16
<MikeSmith>
annevk: yes, it is about that and what activity on infrastructure support do you mean?
11:17
<MikeSmith>
FYI https://w3c.github.io/mdn-spec-links/less-than-2.html?spec=dom&url=https://dom.spec.whatwg.org is something I set up to identify features that don’t have two implementations
11:17
<annevk>
MikeSmith: getting the second logo and some additional text in the draft, flipping some colors
11:17
<MikeSmith>
ah
11:17
<MikeSmith>
well we are a ways off from needing to do that yet
11:18
<MikeSmith>
but regardless I guess I am the person who will need to do the activity on that
11:18
<MikeSmith>
so lack of anything being done about it so far is just because of me not doing it
11:18
<annevk>
well, about six weeks and it involves changes to bikeshed and whatwg repos I think, so some coordination required
11:19
<annevk>
okay, I guess all I'm saying is that it would be good to have that sorted some time in advance so that when it comes to publishing that isn't a hurdle
11:22
<MikeSmith>
OK. I guess I should know what the publication schedule is, but anyway I have not been given a deadline yet
11:23
<annevk>
MikeSmith: I plan to publish the RDs, which include DOM, December 16, it's in your calendar as well I think
11:23
<MikeSmith>
yeah
11:23
<MikeSmith>
I know that
11:23
<MikeSmith>
from the WHATWG side
11:24
<annevk>
MikeSmith: since it's one document it'll have to be the same date
11:24
<MikeSmith>
OK I see now
11:24
<MikeSmith>
well, I have been neglecting it
11:25
<MikeSmith>
it’s not due to lack of others asking me to get some stuff done
11:25
<MikeSmith>
so I guess I need to get it all lined up soon-ish
11:49
<MikeSmith>
annevk: so https://wpt.fyi/results/dom/idlharness.window.html%3Fexclude%3DNode?label=experimental&label=master&aligned seems to be saying that AbstractRange is only supported in Firefox?
11:52
<annevk>
MikeSmith: could be, I think I filed bugs on other browsers; they implemented StaticRange before we created AbstractRange
11:52
<MikeSmith>
ok
11:52
MikeSmith
will look for the browser bugs
13:57
<Domenic>
annevk: MikeSmith: I think the plan was to update the RD after the fact with W3C logo/change in warning color/warning text/etc. Although not updating the date. This seems necessary because we need to first change it to CR and then to REC, so some in-place updating is necessary anyway.
13:58
<Domenic>
That said given that we don't have a mechanism to use "Bikeshed and linking database as of a specific date", there's a possibility the spec will start failing to build during the lag time, which will need some finesseing. I guess maybe we could just turn off warnings-as-errors if necessary.
14:01
<MikeSmith>
Domenic: yeah about the logo and addition of Status/boilerplate stuff, I had just been assuming it could wait til the actual W3C publication
14:02
<MikeSmith>
as far I understand, to do the W3C publication will require the usual process of steps of the W3C WG requesting transition, getting approval
14:02
<MikeSmith>
it also requires some statement of exit criteria
14:03
<MikeSmith>
but anyway I’ve been neglecting it all
14:03
<MikeSmith>
so I need to get on the ball
14:04
<MikeSmith>
there’s nothing I love more than process, so I always procrastinate so I and really savor every moment of it
14:04
<Domenic>
:)
16:10
<annevk>
Domenic: I thought those transitions would always take six months
16:10
<Domenic>
I don't remember anything about that... Not sure how it would work.
16:11
<annevk>
Not super enthusiastic about mutating what are supposed to be immutable documents. Are you sure the sg shares that understanding?
16:12
<Domenic>
I'm not sure. I just don't see how the W3C would approve something for CR and then approve something with 6 months worth of changes as REC.
16:14
<annevk>
Hmm, I thought that’s why we had annotations, but yeah
18:19
<Domenic>
annevk: dumb question, but I thought multiple headers got concatenated with commas, at least in the model? Or is that only request headers? https://github.com/WICG/origin-policy/issues/36
18:23
<annevk>
Domenic: yeah, that comment is somewhat dated, ideally they get combined with a comma first and then parsed
18:23
<Domenic>
OK good
18:24
<annevk>
Domenic: https://fetch.spec.whatwg.org/#concept-header-list-get-decode-split has a primitive
18:24
<annevk>
Domenic: if you don't allow multiple values you can use a simpler primitive of course and fail on a comma being present
18:24
<Domenic>
Hmm right
18:25
<Domenic>
Well structured headers use commas
18:25
<Domenic>
I guess they use it within the multiple values framework
18:32
<annevk>
Oh yeah, for structured headers we should probably define a high-level "get as structured value" that gives you typed things back
18:33
<annevk>
Mike added set a structured header the other day as a start
18:36
<Domenic>
I feel like if you squint and say dictionaries = ordered maps, lists = lists, the structured headers spec is already pretty good
18:37
<Domenic>
It was so cool to see actual defined error handling, omg. https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#rfc.section.4.2.2 tells me what to do on duplicate dictionary keys.
18:38
<annevk>
mnot slowly moving the IETF to the early 2000s
19:51
<annevk>
Domenic: did you see https://github.com/w3c/aria/issues/1058?
19:51
<annevk>
Domenic: also, do you know why they are all strings and not nicer types?
19:51
<Domenic>
annevk: yeah, they are basically enums with misleading names. E.g. there are a lot of things that are "true" / "false" / "some third value"
19:54
<Domenic>
annevk: did not see that issue; will respond
19:55
<annevk>
Domenic: there's a bunch of things that are effectively numbers
19:56
<annevk>
Domenic: and the enums aren't restricted to known values it seems
19:56
<annevk>
Domenic: which is generally how we prefer to reflect those
19:56
<Domenic>
Hrm
19:56
<annevk>
Domenic: and yeah, ARIA not using the proper boolean attribute syntax is annoying, I think I raised a formal objection over that, which got ignored
19:58
<annevk>
Oh no, it was a higher-level concern, https://annevankesteren.nl/2011/01/wai-aria-objection
19:59
<Domenic>
annevk: open a new issue for the integers? I think we just missed that :-/
20:01
<Domenic>
In particular I think all the debates were around true/false vs. "true"/"false" and so when we felt that was settled we thought we were done.
20:02
<annevk>
Domenic: https://github.com/w3c/aria/issues/1110
20:03
<annevk>
Domenic: and when they only accept true and false a boolean seems better? Though you need a new type of reflect
20:03
<annevk>
Domenic: ARIA boolean reflect or whatever
20:04
<annevk>
nn
20:04
<Domenic>
annevk: I don't think that's a good idea, in particular it breaks the current model that setting `el.x = false` will delete the `x=""` attribute. Also it prevents future extension of the value space which the ARIA WG has disliked.