| 03:59 | <GPHemsley> | annevk: r- from me, per my comment. But I've actually been meaning to talk you about mimesniff ownership. |
| 04:32 | <MikeSmith> | howdy GPHemsley |
| 05:48 | <annevk> | nox: maybe, what do browsers do? |
| 05:49 | <annevk> | GPHemsley: anytime |
| 08:13 | <annevk> | TabAtkins: I want a custom <dt> at the top, called !Translation(s), but I cannot seem to include markup there |
| 08:13 | <annevk> | TabAtkins: my idea was "!Translation <small>(non-normative and can be out-of-date)</small>:" |
| 08:13 | <annevk> | TabAtkins: but bikeshed ends up escaping the < |
| 08:13 | <annevk> | TabAtkins: I guess I'll leave out the <small> for now |
| 08:14 | <TabAtkins> | Right, except in a few places, I use nice safe DOM methods, so text stays text. ^_^ |
| 08:15 | <TabAtkins> | But I can of course add a Translation header officially, and have it display such a warning in a <small> (which would be well-warranted and should be on more links to translations imo) |
| 08:15 | <annevk> | Maybe I should even add "likely" given how often we update |
| 08:21 | <annevk> | TabAtkins: https://notifications.spec.whatwg.org/ has an example now |
| 08:22 | <annevk> | TabAtkins: without <small> though |
| 08:22 | <TabAtkins> | Cool. File an issue on me so I"ll remember to get on it on Tuesday when I get back to work? |
| 08:22 | <annevk> | sure |
| 08:39 | <annevk> | TabAtkins: that reference system picked up https://html.spec.whatwg.org/multipage/infrastructure.html#concept-request-origin despite it having data-noexport |
| 08:39 | <annevk> | TabAtkins: what is going on? |
| 08:39 | annevk | can't update URL because of this now |
| 09:03 | <TabAtkins> | What, precisely, is happening with your request? All four of the "origin" dfns in HTML are indeed unexported. |
| 09:05 | <annevk> | TabAtkins: see the PR against URL |
| 09:05 | <annevk> | TabAtkins: for some reason "origin" starts linking to the URL above, rather than the one definition of origin in HTML that does not have data-noexport |
| 09:06 | <TabAtkins> | All four of the HTML dfns are unexported, tho. (And I just pulled fresh datafiles.) |
| 09:07 | <annevk> | TabAtkins: https://html.spec.whatwg.org/multipage/browsers.html#origin-2 does not have data-noexport |
| 09:09 | <TabAtkins> | Right, but "dfn" type definitions are unexported by default. |
| 09:09 | <TabAtkins> | You can explicitly export it with data-export. |
| 09:09 | <annevk> | TabAtkins: last time you told us to annotate things with data-noexport |
| 09:09 | <TabAtkins> | Yes, for selectors. ^_^ |
| 09:09 | <annevk> | TabAtkins: if that's the default that advice wouldn't have made much sense |
| 09:10 | <TabAtkins> | (All other types export by default, but specs often define local terms for all sorts of things that they don't want to expose.) |
| 09:10 | <annevk> | TabAtkins: no also for this and other things |
| 09:10 | <annevk> | Why would we have to annotate selectors with the default? Why would they have a different default? |
| 09:11 | <TabAtkins> | You're misreading. "dfn" types are not exported by default. All other types are exported by default. |
| 09:11 | <TabAtkins> | You had some selector dfns in HTML that were interfering with Selectors, so I asked you to annotate them. |
| 09:12 | <TabAtkins> | (The spider has some intelligence that lets it give types to some things based on text contents or IDs, which is how it knew those were selectors in the HTML spec despite lacking annotations.) |
| 09:12 | <annevk> | TabAtkins: I'm pretty sure you also said this about origin somewhere |
| 09:13 | <TabAtkins> | Seems unlikely, but it's possible I wasn't thinking clearly at the time. Shrug. |
| 09:13 | <TabAtkins> | Anyway, what's the problem you're having, and what's the effect you wanted? |
| 09:15 | <annevk> | TabAtkins: see how https://github.com/whatwg/url/pull/92 changes the link of origin |
| 09:17 | <TabAtkins> | Hm, are you now getting a warning saying that there are two possible anchors, and it's arbitrarily choosing one? |
| 09:17 | <annevk> | TabAtkins: it says "Arbitrarily chose the one in html." |
| 09:18 | <TabAtkins> | Yup, not the most helpful message in this circumstance, I need to spend more effort on detecting exactly what error situation you're in and reporting better. |
| 09:18 | <TabAtkins> | Anyway, the one you want (#origin-2) is apparently for=origin |
| 09:19 | <annevk> | I don't understand how it can even link to the other one given that it has explicitly opted out of this scheme |
| 09:19 | <annevk> | data-noexport shouldn't mean that you can still link to it, that kinda defeats the purpose |
| 09:19 | <TabAtkins> | Because you specified a spec. That is the explicit signal for "fuck it, I really do mean to link the term from this spec". |
| 09:19 | <TabAtkins> | Unexported terms aren't put into the big bag of global refs, but they're still linkable. |
| 09:20 | <TabAtkins> | (If you don't want them to be a ref at all, there's a way to do that.) |
| 09:20 | <annevk> | That is not what I mean when I say spec=html... I would never really mean that |
| 09:20 | <TabAtkins> | And again, note that *all four* of the html "origin" dfns are unexported. |
| 09:21 | <TabAtkins> | It generally is. It's very rare for a spec to both define a term locally and want to link to another spec's definitino of the same term. |
| 09:21 | <annevk> | If I added data-export="" to <dfn>origin</dfn> it'd be okay? |
| 09:21 | <annevk> | Specifications sharing terms seems likely to be quite common |
| 09:22 | <annevk> | I thought that's why we had spec= in the first place, as a namespace |
| 09:22 | <TabAtkins> | Different specs using the same word for different defs, yes. Specs using a word for a local ref *and* linking into another spec's ref for that word (meaning something different), that's rare. |
| 09:23 | <TabAtkins> | The spec='' attribute lets you specify which of the several sources for a given term you want, if they're identical in all other respects. |
| 09:23 | <TabAtkins> | What you want is to change the for=/ (which is wrong for the term you want) to for=origin. |
| 09:23 | <TabAtkins> | Run `bikeshed refs --text=origin --type=dfn --spec=html` to see all the refs and their attributes. |
| 09:25 | <TabAtkins> | And if you want HTML to actually be the definitive reference for one or more of those terms, put data-export on their <dfn> so they'll show up in the global ref set. |
| 09:28 | <annevk> | I see |
| 09:28 | <annevk> | I guess we should do that and stop doing the no-export thing where it doesn't matter anyway |
| 09:29 | <TabAtkins> | For any "dfn" type terms (god DAMN i wish i'd come up with a different name for that category), yeah, no need to write noexport on them. |
| 09:29 | <TabAtkins> | Unless you just like being explicit, which isn't bad. I do that sometimes just to be clear about what I intended to export and what I didn't. |
| 09:58 | <JakeA> | TabAtkins: http://jsbin.com/nomega/edit?css,output - I can't decide if this custom property behaviour is a bug or not |
| 09:59 | <JakeA> | Firefox & Chrome agree on the output, but I can't see why this would happen in the spec |
| 09:59 | <JakeA> | I thought in var(--bar, green) the value would be green if --bar was initial |
| 10:00 | <TabAtkins> | --bar is *the keyword initial*. It's not the initial value of a custom property. |
| 10:00 | <TabAtkins> | So it successfully substitutes in var(--bar), giving background-color the value "initial", which gives you the result you want. |
| 10:01 | <TabAtkins> | This is honesty an unanticipated scenario, but sure, it makes sense and I'm glad browsers agree. |
| 10:04 | <JakeA> | TabAtkins: so, why isn't the keyword "initial" carried through here? http://jsbin.com/nomega/edit?css,output |
| 10:04 | <TabAtkins> | Because there's a line in the spec defining that situation, and it says that the global keywords work normally on custom properties. ^_^ |
| 10:05 | <JakeA> | Hah, gotcha. Fair enough. |
| 10:05 | <TabAtkins> | (I thought this meant that I lost the ability for a custom prop to carry a global keyword, but evidently that's not true! If I remember, I'll add a note to the spec talking about that.) |
| 10:06 | <JakeA> | I guess there's no reason to do var(--foo, initial), but through some stupidity I'd ended up with it and got confused by the behaviour, but if this is a way to set a custom property to the value "initial", then I guess that's potentially useful |
| 10:06 | <TabAtkins> | On second thought, maybe that behavior doesn't actually make sense, but browsers do it, so ehhhhh. |
| 10:07 | <TabAtkins> | Wait, do your first example again, but with "inherit", and put a background on a parent. |
| 10:07 | <TabAtkins> | Just to make sure it's actually carrying the keyword around. |
| 10:09 | <JakeA> | TabAtkins: http://jsbin.com/nomega/edit?css,output |
| 10:09 | <TabAtkins> | sweet, confirmed |
| 10:09 | <TabAtkins> | so yeah: doesn't actually make a ton of sense, but eh |
| 10:10 | <JakeA> | Ohh, I didn't realise "inherit" was an 'unsetter' too |
| 10:10 | <TabAtkins> | it just means browsers are special-casing custom properties to only look for global keywords in their original, unsubstituted values. |
| 10:10 | <TabAtkins> | wait DUH that makes sense |
| 10:10 | <TabAtkins> | no wait nm |
| 10:10 | <TabAtkins> | i'll think about this later when it's not 2am |
| 10:10 | <TabAtkins> | what's this about "unsetter"? |
| 10:11 | <JakeA> | As in, if I have a custom property that has a value, and I later want it to be "unset", as in it'd use the fallback in var() |
| 10:12 | <JakeA> | I guess "inherit" will become "initial" |
| 10:12 | <TabAtkins> | no... |
| 10:12 | <TabAtkins> | inherit means inherit |
| 10:12 | <TabAtkins> | (tho the root element inherits the initial value |
| 10:12 | <TabAtkins> | ) |
| 10:13 | <JakeA> | yeah, sorry, that's what I meant by becomes "initial" |
| 10:13 | <JakeA> | for the purposes of var(--foo, fallback) it sees --foo as initial and falls back |
| 10:14 | <TabAtkins> | yeah. |
| 10:14 | <TabAtkins> | the easiest way to unset a custom prop, btw, is to set it to itself. --foo: var(--foo); immeidately unset it |
| 10:15 | <TabAtkins> | well hey tho, --foo: initial does too |
| 10:15 | <TabAtkins> | so whatever |
| 10:15 | <TabAtkins> | it's 2am |
| 10:15 | <TabAtkins> | (i'm archive-binging a comic and almost done) |
| 10:15 | <JakeA> | hah GET SOME SLEEP. Oh wait, it's a holiday over there isn't it? Meh, stay up all night! |
| 10:16 | <TabAtkins> | YUP |
| 10:18 | <JakeA> | Well, thanks for helping me through that. I'm using custom properties to build a rendering dependency tree when async-loading CSS |
| 10:19 | <JakeA> | It works |
| 11:10 | <yoav> | What's the best way to get some discussion around https://www.w3.org/Bugs/Public/show_bug.cgi?id=29078 going? Copy it over to GH? |
| 11:12 | <MikeSmith> | yoav: yeah I think that would get it more visibility |
| 11:24 | <TabAtkins> | JakeA: I'd love to see it when I'm more rested. And now that I'm done archive-binging, to bed I go. |
| 11:25 | <JakeA> | Goodnight! |
| 11:47 | <yoav> | https://github.com/whatwg/dom/issues/167 |
| 12:04 | <MikeSmith> | yoav: super |
| 12:04 | <annevk> | That was an HTML bug |
| 12:04 | <MikeSmith> | yoav: but why is it a DOM |
| 12:05 | <MikeSmith> | yeah |
| 12:05 | <yoav> | oops :/ |
| 12:05 | <yoav> | Will move it |
| 12:05 | <MikeSmith> | hai |
| 12:07 | <yoav> | https://github.com/whatwg/html/issues/694 |
| 12:15 | <ritsyy> | this bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=26942 has a pretty cool researches :) |
| 12:32 | <zcorpan> | yay the gradient is now smooth! (maybe it has been a while, but noticed now) |
| 14:48 | <JakeA> | annevk: can't work it out from the spec… why can't you create a request of mode "navigate"? |
| 14:49 | <wanderview> | JakeA: I think because navigations have special rules we don't want to expose to fetch() |
| 14:49 | <wanderview> | fetch() in the window |
| 14:49 | <JakeA> | ah ok |
| 14:49 | <JakeA> | ta! |
| 14:50 | <JakeA> | I figured it'd be something security-like |
| 14:50 | <wanderview> | JakeA: if we could get rid of all "if navigation" special cases, maybe it would be safe... but navigations are still a bit hand-wavy I think |
| 14:50 | <annevk> | Maybe we could open it up, but I'd like to make sure we understand navigate a lot better first |
| 14:50 | <annevk> | What wanderview said |
| 14:51 | <annevk> | wanderview: do you happen to know if Gecko supports any argument to new Headers()? |
| 14:51 | <wanderview> | I guess it makes you wonder about the differences between fetch() and a function wrapping iframe+onload |
| 14:52 | <annevk> | Seems like we do |
| 14:52 | <wanderview> | annevk: our webidl says we optionally take HeadersInit: https://dxr.mozilla.org/mozilla-central/source/dom/webidl/Headers.webidl#21 |
| 14:59 | <annevk> | wanderview: https://github.com/whatwg/fetch/issues/165 |
| 14:59 | <annevk> | wanderview: (and thanks for the IDL pointer) |
| 15:01 | <wanderview> | annevk: not sure what your last comment is saying |
| 15:03 | <wanderview> | annevk: I was trying to say that for no-cache I'd like to remove this part of the current spec text: "and the response in the HTTP cache for httpRequest does require revalidation" |
| 15:03 | <wanderview> | annevk: so the revalidation headers are added regardless of the age of the entry in the http cache |
| 15:05 | <annevk> | wanderview: if you have a response in the cache that doesn't require revalidation, how'd you go about adding headers for that? |
| 15:06 | <wanderview> | annevk: the revalidation headers go on the request, no? |
| 15:06 | <annevk> | wanderview: sure, but they're based on the response in the cache |
| 15:07 | <wanderview> | annevk: what information is needed from the response in the http cache? |
| 15:07 | <annevk> | wanderview: the etag? |
| 15:07 | <annevk> | wanderview: or a date? |
| 15:07 | <wanderview> | annevk: which date? date stored or current age? I'm saying, use the info from the http cache, but don't make that depend on the http cache entry being aged |
| 15:08 | <wanderview> | if there is no http cache entry at all, then don't set revalidation headers |
| 15:08 | <annevk> | wanderview: stored, but more common is etags |
| 15:09 | <wanderview> | all I'm trying to say is skip the age check part of "response in the HTTP cache for httpRequest does require revalidation" if no-cache is set |
| 15:09 | <annevk> | wanderview: "does require revalidation" will almost always be true, fwiw |
| 15:09 | <annevk> | hmm |
| 15:09 | <wanderview> | annevk: where is "does require revalidation" defined? |
| 15:09 | <annevk> | yeah it's not, integration is hand-wavy |
| 15:10 | <annevk> | HTTP does not define this in detail either because they don't really require things from caches |
| 15:12 | <wanderview> | well, that makes it hard to define a primitive to skip these undefined behaviors |
| 15:12 | <annevk> | Yeah, perhaps we added the cache modes to early or we added too many of them |
| 15:13 | <wanderview> | annevk: but I think this type of behavior is something you really want to use in service worker install event handlers |
| 15:14 | <annevk> | wanderview: so no-cache basically means that Fetch has to create a conditional request, I guess we'll just have to refine its definition over time to make sure it meets expectations |
| 16:29 | <Krinkle> | Hm.. we're running into some unexpected measures when retroactively comparing SPDY to HTTP/1 performance. Wikipedia's been SPDY for a few months now, but in a recent webpagetest with chrome and disabled spdy support, we see a minor improvement, correlated to the size of the html payload. Our suspicion is that this is due to how html is prioritised over css. |
| 16:29 | <Krinkle> | Previously HTML and CSS loaded in separate connections more or less sharing bandwidth equally. Meaning when the CSS is finished and the first section of html, Blink can paint. |
| 16:29 | <Krinkle> | But with SPDY, it is blocked on downloading all of the html before css stream gets any breathing room. |
| 16:30 | <Krinkle> | This is in a 2G bandwidth emulation though |
| 16:30 | <Krinkle> | JakeA: ^ any thoughts? Was just reading your css loading article. |
| 16:31 | <annevk> | Krinkle: I guess you can force separate connections by hosting the CSS on a distinct hostname and not share the TLS connection |
| 16:32 | <Krinkle> | maybe chrome (or nginx on our side) is too naive in its interpretation of prioties. Not sure if the SPDY spec means priority to be absolute or relative (e.g. less bandwidth or no bandwidth) |
| 16:32 | <annevk> | Krinkle: note that SPDY is about to be disabled, but I guess you mean HTTP/2 |
| 16:32 | <Krinkle> | This is SPDY |
| 16:32 | <JakeA> | Krinkle: is the server controlling the priority here? |
| 16:32 | <Krinkle> | But yeah, I'm aware of it sunsetting very soon |
| 16:32 | <Krinkle> | JakeA: Afaik it's Chrome (html = highest, css= high) |
| 16:32 | <Krinkle> | I'm hoping this'll be better in H2 |
| 16:33 | <Krinkle> | Basically start render for large articles is significantly worse with SPDY than without |
| 16:33 | <Krinkle> | Not the joy we usually get from streaming |
| 16:33 | <JakeA> | Krinkle: can you share the wpt links? |
| 16:33 | <JakeA> | I'd like to make a bug for this |
| 16:34 | <Krinkle> | I'll pull it up. Thx |
| 16:35 | <Krinkle> | JakeA: Our issues are https://phabricator.wikimedia.org/T125979 - https://phabricator.wikimedia.org/T125208 ; TL:DR; As for median nav timing, SPDY is still a win overall. So the SPDY-off experiment will be terminated soon. It's mostly affected large articles which is a minority. (large for us, that is) |
| 16:37 | <Krinkle> | Last I checked, we're blocked on nginx support for spdy3+h2 rather than just spd3 or h2 (for which we currently pick spd3 due to higher coverage). Chrome switching will improve that balance though, so I hope we'll switch soon. |
| 16:39 | <JakeA> | Krinkle: https://code.google.com/p/chromium/issues/detail?id=586938 |
| 16:39 | <Krinkle> | annevk: Yeah, but we actually just finished last year folding our static domain into the main content domain (under a /static path) |
| 16:40 | <Krinkle> | saving the extra connection proved quite improving on the timing metrics. |
| 16:41 | <annevk> | Krinkle: it sound like under certain conditions having extra connections is more beneficial |
| 16:41 | <Krinkle> | JakeA: I suspect either 1) Chrome should use priority "Highest" for html + css (given that it blocks render on css arriving), or 2) if SPDY spec is intending for Highest and High to run along side (with relative preference, not absolute preference) to the higher one - then maybe our nginx is being too naive about the priorities. |
| 16:41 | <Krinkle> | I'm not sure. |
| 16:42 | <Krinkle> | annevk: Yeah |
| 16:42 | <annevk> | Krinkle: that is, I'm assuming that for HTTP/1.1 you actually get multiple connections here |
| 16:42 | <Krinkle> | Yep. |
| 16:42 | <Krinkle> | on H1 it does the typical N connections per origin. |
| 16:42 | <JakeA> | Krinkle: agreed, but no idea if it's Chrome or Nginx getting it wrong |
| 16:43 | <Krinkle> | Yeah |
| 16:43 | <Krinkle> | I wouldn't be surprised if its Nginx. I hear the implementation may've been a bit rushed/minimal. |
| 16:43 | <Krinkle> | Or it could be abiguity in the SPDY spec, which might be better in H2 |
| 16:48 | <Krinkle> | annevk: Hm.. interesting point though. Maybe there is a balance to be made with regards to hostname coalesce |
| 16:49 | <Krinkle> | We were actually considering folding the SSL connection for our static thumbnail host (upload.wikimedia.org) into the main wikipedia domains as well. Not literally the same origin, but it would use the same connection, again. |
| 16:49 | <Krinkle> | That's currently the last remaining hostname that isn't sharing connection. |
| 16:51 | <annevk> | Krinkle: I don't really know how those things play out today, but given how efficient torrents seem to be multiple connections might not be all bad |
| 16:51 | <annevk> | Krinkle: I haven't really seen much on multiple connections in a H2 world though |
| 16:55 | <Krinkle> | annevk: It's also not bug free. Last quarter we had a major issue in Firefox due to it re-using the same connection for different domains when (arguably) it shouldn't have re-used the connection. One domain had IPv4-only, the other v4 and v6. The main connection was Ipv6, and it re-used the connection for the Ipv4-only domain. |
| 16:55 | <Krinkle> | https://phabricator.wikimedia.org/T121922 |
| 16:55 | <Krinkle> | It became part of a cascading failure eventually resulting in fundraising banners not showing up in FIrefox for Ipv6 users due to geolocation depending on the ipv4-only domain (now fixed). |
| 16:56 | <Krinkle> | upstreamed at https://bugzilla.mozilla.org/show_bug.cgi?id=1235068 |
| 16:57 | <Krinkle> | it's no longer relevant today, but was a fun adventure |
| 16:59 | <annevk> | Interesting |
| 18:06 | <annevk> | You can really tell when the US is on holiday |
| 18:14 | <wanderview> | annevk: everyone busy dressing up as their favorite american president |
| 18:20 | <annevk> | smaug____: I might look into integrating some of the Shadow DOM stuff into HTML |
| 18:20 | <annevk> | smaug____: such as the "in a document" vs "in a composed document" stuff |
| 18:20 | <annevk> | smaug____: do you think that's worthwhile to do now, or should we wait longer? |
| 18:20 | <annevk> | hayato: ^^ |
| 18:21 | <smaug____> | hmm, not sure what waiting could give us |
| 18:21 | <annevk> | (not today, but soonish) |
| 18:21 | <smaug____> | it has been an issue since...2012 or 2013 |
| 18:21 | <smaug____> | major issue even, so would be good to get it finally fixed |
| 18:22 | <smaug____> | and great, thanks for doing it whenever you end up doing it! |
| 18:24 | annevk | finds https://www.w3.org/Bugs/Public/show_bug.cgi?id=24379, https://www.w3.org/Bugs/Public/show_bug.cgi?id=28748, and https://www.w3.org/Bugs/Public/show_bug.cgi?id=27406 |
| 18:25 | <annevk> | I remember Hixie also writing down a proposed solution somewhere, maybe that was in the Shadow DOM collection of bugs |
| 18:31 | <smaug____> | annevk: I think in the w3c bugzilla bug about is in doc |
| 18:32 | <smaug____> | or perhaps you mean some other proposal |
| 18:35 | <GPHemsley> | oh no, I pushed the green button |
| 18:51 | <GPHemsley> | annevk: It appears I don't have push rights to xref |
| 19:00 | <GPHemsley> | annevk: Oh shoot, I totally obliterated your Makefile commit. |
| 19:00 | <GPHemsley> | s/Makefile/README/ |
| 19:00 | GPHemsley | is gonna back away now |
| 19:58 | <annevk> | GPHemsley: can you fix it? |
| 19:58 | <annevk> | GPHemsley: oh, you force pushed? |
| 19:59 | annevk | wonders how to fix that |
| 19:59 | <wanderview> | annevk: can you sanity check me here? are importScripts() in a service worker supposed to be restricted to same origin? |
| 20:00 | <annevk> | wanderview: I don't know, doubt it? |
| 20:00 | annevk | opens https://slightlyoff.github.io/ServiceWorker/spec/service_worker/ |
| 20:01 | <annevk> | wanderview: nope |
| 20:01 | <wanderview> | ok, thanks |
| 20:04 | <annevk> | GPHemsley: I enabled master branch protection |
| 20:04 | <annevk> | GPHemsley: I also restored my commit |
| 20:08 | <annevk> | GPHemsley: I don't really have time right now to talk about things like you wanted unfortunately, would email be okay for you? |
| 20:10 | <annevk> | GPHemsley: if not, let me know what time works for you, but keep in mind my timezone is A'dam/Zurich |
| 20:11 | <annevk> | GPHemsley: also, someone from Mozilla might be providing some more PRs for sniffing things we implemented |
| 21:28 | <Domenic> | " |
| 21:43 | <wanderview> | SyntaxError: unterminated string literal |
| 22:18 | <mawkgawk> | is there an event that fires when fetch completes xhr? I want to hook into all completed requests |
| 22:23 | <boogyman> | mawkgawk: research promise.all |
| 23:08 | <smaug____> | Hmm, how is 'strictly split a string' supposed to work if there are several delimiters next to each others |
| 23:09 | <smaug____> | per algorithm we get empty strings in the array |