| 07:42 | <hsivonen> | When XPIDL says an argument is [array, size_is(aLength)] in uint8_t aBytes, is an ArrayBuffer accepted from a JS caller? |
| 07:42 | <hsivonen> | oops. wrong channel. sorry. |
| 15:24 | <zcorpan> | annevk: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5000 has different results in webkit, chromium, and gecko. :-( do you know if it's tested and reported? |
| 15:31 | <annevk> | zcorpan: not sure about ?? |
| 15:32 | <annevk> | zcorpan: url/setters_tests.json (or some such) should make that clear (the corresponding HTML resource tests <a>, <area>, and URL |
| 15:36 | <zcorpan> | annevk: there's "new_value": "??lang=fr", |
| 15:37 | <zcorpan> | and "new_value": "?", |
| 15:37 | <zcorpan> | which i think covers the buggyness in webkit and chromium |
| 15:48 | <zcorpan> | https://bugs.chromium.org/p/chromium/issues/detail?id=682150#c7 |
| 15:58 | <zcorpan> | https://bugs.webkit.org/show_bug.cgi?id=170452 |
| 16:45 | <MikeSmith> | TabAtkins: Is there any CSS spec that defines what it means for a UA to “apply styles”? |
| 16:45 | <MikeSmith> | the context is https://html.spec.whatwg.org/#attr-style-media |
| 16:45 | <MikeSmith> | > The media attribute says which media the styles apply to. The value must be a valid media query list. The user agent must apply the styles when the media attribute's value matches the environment and the other relevant conditions apply, and must not apply them otherwise. |
| 16:46 | <MikeSmith> | in “The user agent must apply the styles” the “apply the styles” part does not link to any definition anywhere |
| 16:47 | <MikeSmith> | also at https://html.spec.whatwg.org/#interactions-of-styling-and-scripting |
| 16:47 | <MikeSmith> | > When a style sheet is ready to be applied, its style sheet ready flag must be set. |
| 16:47 | <MikeSmith> | “to be applied” does not link to any definition anywhere |
| 16:48 | <MikeSmith> | and within https://html.spec.whatwg.org/#the-link-element |
| 16:48 | <MikeSmith> | > The exact behavior for links to external resources depends on the exact relationship, as defined for the relevant link type. Some of the attributes control whether or not the external resource is to be applied (as defined below). |
| 16:49 | <MikeSmith> | “the external resource is to be applied” does not link to any definition anywhere |
| 16:49 | <TabAtkins> | MikeSmith: Nah, "apply styles" is just English for, uh, applying styles. |
| 16:49 | <TabAtkins> | "ready to be applied" should probably get a dfn somewhere, I agree. |
| 16:50 | <MikeSmith> | OK |
| 16:51 | <MikeSmith> | well as far as that “external resource is to be applied”, I wonder if we actually have any types of external resources other than CSS stylesheets that do get “applied” |
| 16:52 | <MikeSmith> | seems like, e.g., rel=icon doesn’t cause anything to be “applied” |
| 16:52 | <TabAtkins> | It "applies" the icon to the tab? |
| 16:53 | <MikeSmith> | I guess so but that seems like stretching the normal meaning of the word |
| 16:54 | <TabAtkins> | eh |
| 16:54 | <MikeSmith> | I think that language has been there in the spec that way since the very beginning |
| 18:19 | <annevk> | zcorpan++ |
| 20:52 | <tobie> | I have an interface that has state we don't want expose for now (it'll reside in a slot). What should I use for this? |
| 20:55 | <TabAtkins> | tobie: What do you mean? |
| 20:57 | <tobie> | TabAtkins: well originally, it was an enum. Now that it's no longer exposed, what should it be turned into? |
| 20:57 | <tobie> | TabAtkins: just infra strings? |
| 20:57 | <TabAtkins> | Yeah. |
| 20:58 | <TabAtkins> | Or, you don't need actual strings. |
| 20:58 | <TabAtkins> | Just *handwave* values. |
| 21:07 | <tobie> | TabAtkins: do you just turn them into regular dfns in Bikeshed? |
| 21:08 | <TabAtkins> | No, slots should be dfn'd as IDL attributes, ideally with `[[...]]` names. |
| 21:08 | <TabAtkins> | Then you can ref them like `{{[[foo]]}}` |
| 21:08 | <TabAtkins> | Which is an unfortunate level of stacking, but hey. |
| 21:10 | <tobie> | what about the values? |
| 21:10 | <tobie> | No linking, just ""? |
| 21:12 | <TabAtkins> | Depends on if you think they're useful to link or not. If so, yeah, probably make them "dfn" type, with a `for` to help scope them. |
| 21:12 | <tobie> | makes sense. thanks. |
| 21:17 | <tobie> | So <dfn interface>\[[state]]</dfn>? |
| 21:22 | <TabAtkins> | <dfn attribute for=Foo>\[[state]]</dfn> |
| 21:23 | <tobie> | ty |
| 21:27 | <KiChjang> | does anyone here know what webkit uses as their javascript engine? |
| 21:30 | <TabAtkins> | JavaScriptCore |
| 21:42 | <tobie> | Considering three states "idle", "activating" and "activated", which one would you favor? |
| 21:42 | <tobie> | a) If |sensor_state| is either "activating" or "activated", then return. |
| 21:42 | <tobie> | b) If |sensor_state| is not "idle", then return. |
| 21:42 | <tobie> | c) Unless |sensor_state| is "idle", return. |
| 21:43 | <KiChjang> | my pick is a) |
| 21:43 | <TabAtkins> | a |
| 21:43 | <KiChjang> | speaking as an implementor, this is the least confusing statement |
| 21:44 | <tobie> | KiChjang: you mean the clearest? |
| 21:44 | <tobie> | ;) |
| 21:45 | <tobie> | Alright a) it is. Thanks! |
| 21:47 | <KiChjang> | yes, my other pet peeve when reading a spec like this is that usually the definition of the possible states are elsewhere |
| 21:48 | <KiChjang> | and being a live document, it doesn't necessarily have to stay constant through time - we may add more states as necessary in the future |
| 22:11 | <TabAtkins> | Yup, that's exactly my reasoning too - the states can change, and (a) is least subject to accidentally changing meaning due to the editor forgetting to update the reference. |
| 23:37 | <jyasskin> | tobie: `1. If |sensor_state| is either "activating" or "activated", then return. 2. Assert: |sensor_state| is "idle". 3. …` |
| 23:38 | <TabAtkins> | Or "Otherwise, |sensor_state| is "idle": ..." |
| 23:41 | <jyasskin> | Bikeshed gives "Assert:" nice styling. ;) |
| 23:41 | <jyasskin> | But I don't care much. :) |
| 23:44 | <TabAtkins> | Oh yeah, I forgot about that. |