| 10:26 | <zcorpan> | @media (scripting) { |
| 10:26 | <zcorpan> | noscript { display: none !important; } |
| 10:26 | <zcorpan> | } |
| 10:26 | <zcorpan> | https://html.spec.whatwg.org/#hidden-elements |
| 10:26 | <zcorpan> | Where is "scripting" defined? Can't see it in https://drafts.csswg.org/mediaqueries/ |
| 10:42 | <annevk> | It seems the CSS WG might have dropped it without notifying dependencies... |
| 10:42 | <annevk> | zcorpan: https://drafts.csswg.org/mediaqueries-5/#mf-scripting |
| 10:43 | <zcorpan> | annevk: thanks |
| 10:45 | <annevk> | Seems that was done in https://github.com/w3c/csswg-drafts/commit/8677d3ea21533f151143784846992f2cdcdf07ae#diff-86306790afb9d5330bbdda192a7b99f6 |
| 10:45 | <annevk> | But latest version still referencing -4 is what makes this so confusing |
| 12:23 | <annevk> | hsivonen: if you're around, could you look at https://github.com/whatwg/html/pull/3111? |
| 12:29 | <hsivonen> | annevk: looking |
| 12:33 | <annevk> | hsivonen: it basically seems like another all encodings decoding path in the platform, but one that might not use the BOM at all |
| 12:34 | <annevk> | hsivonen: I'm hoping we can restrict it to UTF-8 given that the URL parser already always uses UTF-8 to encode, but who knows |
| 12:38 | <hsivonen> | annevk: It's likely that I didn't understand the question in the issue |
| 12:39 | <annevk> | hsivonen: part of the problem here is that if an ID contains U+00FF and the document encoding is windows-1252, a %FF fragument will find that ID in most implementations |
| 12:39 | <annevk> | hsivonen: meaning that the fragment is not UTF-8 decoded, but decoded using the document encoding |
| 12:40 | <annevk> | hsivonen: furthermore, if the fragment starts with an encoded BOM, that's ignored for decoding purposes (so it doesn't use the generic decode hook) |
| 12:40 | <hsivonen> | annevk: when you say "ignored", is it removed or retained if the document encoding is UTF-8? |
| 12:41 | <annevk> | hsivonen: retained |
| 12:42 | <hsivonen> | annevk: encoding_rs has https://docs.rs/encoding_rs/0.7.1/encoding_rs/struct.Encoding.html#method.decode_without_bom_handling and https://docs.rs/encoding_rs/0.7.1/encoding_rs/struct.Encoding.html#method.decode_without_bom_handling_and_without_replacement , so it seems that no new encoding_rs API surface would be needed |
| 12:42 | <annevk> | hsivonen: I meant ignored in that it doesn't override the document encoding |
| 12:42 | <hsivonen> | also https://docs.rs/encoding_rs/0.7.1/encoding_rs/struct.Encoding.html#method.new_decoder_without_bom_handling |
| 12:42 | <hsivonen> | annevk: ok. |
| 12:43 | <annevk> | hsivonen: it seems like I was right to worry about the encoding_rs <> Encoding Standard hook mismatch |
| 12:44 | <hsivonen> | annevk: in what sense? |
| 12:45 | <annevk> | hsivonen: if we want to do what implementations do here the Encoding Standard needs a new hook |
| 12:47 | <hsivonen> | annevk: yeah. I suggest calling it "decode without BOM handling" :-) |
| 12:48 | <annevk> | hsivonen: seems unfortunate though to have that just for this one caller |
| 12:59 | <hsivonen> | annevk: only if you consider "UTF-8 decode without BOM" a separate thing as opposed to considering it this new thing performed with UTF-8 as the encoding |
| 13:00 | <annevk> | hsivonen: I consider it separate as UTF-8 decode without BOM is not a legacy code path |
| 13:01 | <hsivonen> | ok. probably worthwhile re-defining "UTF-8 decode without BOM" in terms of "decode without BOM handling" if you end up introducing the latter |
| 13:04 | <annevk> | hsivonen: is it easy to find other callers of "decode without BOM handling" that might use it for an encoding other than UTF-8? |
| 13:05 | <annevk> | hsivonen: or is this indeed the only place? |
| 13:05 | <annevk> | I wonder how much effort I should put into trying to get rid of this |
| 13:10 | <hsivonen> | let's see. most of these are non-Web-exposed internal legacy |
| 13:10 | <hsivonen> | https://searchfox.org/mozilla-central/search?q=symbol:_ZNK7mozilla8Encoding24DecodeWithoutBOMHandlingERK12nsTSubstringIcERS2_&redirect=false |
| 13:10 | <hsivonen> | https://searchfox.org/mozilla-central/search?q=symbol:_ZNK7mozilla8Encoding28NewDecoderWithoutBOMHandlingEv&redirect=false |
| 13:10 | <hsivonen> | https://searchfox.org/mozilla-central/search?q=symbol:_ZNK7mozilla8Encoding24DecodeWithoutBOMHandlingENS_4SpanIKhLm18446744073709551615EEER12nsTSubstringIDsE&redirect=false |
| 13:14 | <hsivonen> | annevk: looks like URL fragments are the only Web-exposed non-UTF-8 case |
| 13:15 | <hsivonen> | the script loader stuff uses this primitive internally but performs BOM handling, so the Web-exposed behavior is with BOM handling |
| 14:04 | <annevk> | hsivonen: thanks, I guess I'll make an effort to make it either use "UTF-8 decode without BOM" or "decode" (and handle the BOM) in that case |
| 14:15 | <Ms2ger> | Is there an easy way to test iOS Safari? |
| 14:24 | <annevk> | Ms2ger: BrowserStack? |
| 14:43 | <gsnedders> | Ms2ger: buy an iPod Touch on expenses? |
| 14:44 | <gsnedders> | (I have literally done that before. But I was needing to test touch behaviour, which is hard with the simulator locally yet alone remotely) |
| 14:44 | <Ms2ger> | Would be a good idea if I had any other use for apple devices :) |
| 14:45 | <gsnedders> | Oh, mine just sits in a drawer almost all of the time. :) |
| 14:45 | <Ms2ger> | Sounds a little wasteful |
| 14:45 | <Ms2ger> | I should figure out if we have a corporate browserstack account |
| 14:46 | <gsnedders> | Well you can't exactly do much with a 16GB iPod Touch |
| 14:46 | <gsnedders> | given the OS takes up some ridiculous percentage of that |
| 14:46 | gsnedders | wonders if they still make the 16GB model |
| 15:57 | <annevk> | foolip: does https://travis-ci.org/whatwg/fetch/builds/318150547 look familiar? |
| 15:57 | <annevk> | foolip: seems something is wrong with the build script |
| 15:59 | <annevk> | foolip: think I found the mistake |
| 16:05 | <annevk> | foolip: https://github.com/whatwg/whatwg.org/pull/135#issuecomment-352470978 |
| 16:46 | <Shreya> | Hello everyone! I would like to be a part of whatwg. |
| 16:46 | <foolip> | annevk: restarted https://travis-ci.org/whatwg/fetch/builds/318150547 after (maybe) fixing |
| 16:47 | <Shreya> | How can I become a member of this? |
| 16:53 | <annevk> | Shreya: welcome, does https://whatwg.org/faq help? |
| 16:53 | <annevk> | foolip: ta |
| 16:59 | <annevk> | foolip: did not work |
| 16:59 | <annevk> | foolip: Travis tries rsync apparently |
| 17:00 | <Shreya> | Thanks annevk! |
| 17:02 | <annevk> | foolip: at least Fetch is still online… |
| 17:02 | <foolip> | foolip: maybe it hadn't deployed to resources yet, try again? |
| 17:03 | <annevk> | I can try in an hour or so |
| 17:04 | <annevk> | foolip: however seems like a different error; failing at a later step |
| 17:05 | <foolip> | annevk: okay, different error is interesting. Poke me when it doesn't resolve itself in a bit. |
| 17:05 | <annevk> | foolip: pretty sure the rsync block has the wrong guard |
| 17:06 | <annevk> | foolip: will poke when back |
| 17:06 | <foolip> | annevk: it tried to deploy for a PR then? |
| 17:06 | <foolip> | That would be very wrong |
| 17:15 | <annevk> | foolip: log suggests as much |
| 17:17 | <foolip> | annevk: oh now I see, it's missing the master branch check :( |
| 17:20 | <foolip> | annevk: https://github.com/whatwg/whatwg.org/pull/140 |
| 17:39 | <SimonSapin> | https://blog.whatwg.org/copyright-license-change talks about the license of the HTML Standard but I couldn’t find from https://html.spec.whatwg.org/multipage/ or https://github.com/whatwg/html what it is currently or what it was before |
| 17:40 | <Domenic> | License changes haven't quite rolled out yet; I guess that's pretty confusing. Was planning to do it this week. |
| 17:41 | <Domenic> | Current license is the bottom of https://html.spec.whatwg.org/multipage/acknowledgements.html#acknowledgments |
| 17:43 | <SimonSapin> | thanks |
| 17:46 | <ato> | tobie: I just learned about pr-preview. That is fantastic. |
| 17:58 | <tobie> | ato: glad you like it! |
| 18:09 | <domfarolino> | annevk: regarding my fetch PR, what do you think should be done about referencing the request object's members vs the concept members? |
| 18:11 | <annevk> | domfarolino: it seems somewhat reasonable to reference the concepts since we end up returning those, but I'm not sure how understandable that is |
| 18:11 | <ato> | tobie: Deploying it on the WebDriver spec now. |
| 18:13 | <domfarolino> | Agreed, I mean the current way still sort of references the concepts, just by going through the object members first so there's one more layer of indirection, but I'm open to either |
| 18:14 | <annevk> | domfarolino: up to you |
| 18:19 | <domfarolino> | annevk: "Event" in the DOM spec doesn't seem to suffer the same duplication between the concept members and object members. Is this because events are designed to be always exposed to/created by JavaScript, so the internal properties and exposed properties are more 1:1? |
| 18:19 | <Domenic> | Heh, big question |
| 18:19 | <Domenic> | It's partially legacy |
| 18:19 | <Domenic> | i.e. it's pretty bad right now that specs say "initialize the foo member of the event to bar" |
| 18:19 | <Domenic> | because that isn't defined anywhere |
| 18:19 | <Domenic> | It should be saying "initialize the event's foo [concept] to bar" |
| 18:19 | <Domenic> | But... |
| 18:20 | <Domenic> | Events are a bit special because there's a precise 1:1 correspondence |
| 18:20 | <Domenic> | So it'd be kind of annoying to just create a bunch of concepts (aka internal slots) for this purpose |
| 18:21 | <Domenic> | annevk likes the solution proposed in https://github.com/heycam/webidl/pull/495 of having internal slots be generated for all Web IDL attributes (JS properties) |
| 18:21 | <Domenic> | I am not a big fan, as I feel like Events are the only case where that's a clear win |
| 18:23 | <annevk> | Domenic: it's a win whenever the getter just returns the internal slot |
| 18:23 | <annevk> | Domenic: as you won't have to define the getter |
| 18:23 | <Domenic> | Well... but only for classes where *every* getter has a backing internal slot |
| 18:23 | <Domenic> | Otherwise, you have to add a bunch of annotations to say "but not this one" |
| 18:24 | <domfarolino> | Domenic: Yes that makes sense, with the 1:1 and all. |
| 18:24 | <annevk> | I think that's the common case |
| 18:24 | <Domenic> | My impression is the opposite |
| 18:24 | <domfarolino> | Reading PR link thanks a lot for sending! |
| 18:24 | <Domenic> | But this is an empirical question |
| 18:25 | <domfarolino> | Ok that's an interesting solution |
| 18:25 | <annevk> | Need something for events though |
| 18:26 | <Domenic> | Yeah, agreed on that front. |
| 18:26 | <domfarolino> | Because of Event's missing internal slots? |
| 18:26 | <Domenic> | That PR isn't great for events though as it still requires listing all the internal slots (either in syntax or elsewhere) |
| 18:27 | <Domenic> | You really want something, maybe in DOM, that says "all events have a corresponding internal slot" |
| 18:27 | <domfarolino> | That sounds nice |
| 18:27 | <annevk> | Well slot per getter |
| 18:27 | <annevk> | That PR could get there |
| 18:28 | <annevk> | But maybe getter slots should be opt-in then |
| 18:29 | <annevk> | For DOM, Fetch, XHR most getters need a slot though |
| 18:29 | <annevk> | I wonder where that stops being true |
| 18:31 | <Domenic> | "most" might be true, but if it's like 80% need slots, the 20% remaining is pretty awkward, I think. |
| 18:33 | <annevk> | Domenic: so we add [Slot] instead? |
| 18:34 | <Domenic> | Hmm maybe, that does feel better for some reason |
| 18:34 | <annevk> | It makes some sense to not encourage slots and requiring a little hassle |
| 18:34 | <annevk> | It makes less sense imo to require prose for the object layout |
| 18:40 | <annevk> | domfarolino: sorry for the long sidebar, the basic answer is that Event (and anything like it) is wrong as-is |
| 18:41 | <domfarolino> | With this potential [slot] syntax, where would you describe the behavior of a slot that is specific to its non-javascript usage? Like if an internal slot has a set of possible behaviors/values, but only a subset of those are used in/available to JavaScript where would you describe its "only-internal" usage. |
| 18:41 | <domfarolino> | Hm if that doesn't make sense I can reword |
| 18:42 | <annevk> | domfarolino: you manipulate slots as you see fit from various algorithms |
| 18:42 | <annevk> | domfarolino: what you expose through public JavaScript API is up to you, the getter might not reflect the internal value 1:1 |
| 18:43 | <Domenic> | It would reflect it 1:1 though for events |
| 18:43 | <Domenic> | And presumbly other cases where you use [Slot] |
| 18:50 | <domfarolino> | Yeah, I feel that using [Slot] on a getter that doesn't reflect internal value 1:1 might be a little confusing maybe |
| 18:52 | <domfarolino> | annevk: Ok I'm cool with the domintro boxes pointing to the object members then, because they themselves point to the concepts. I feel that that includes everything well even tho might be a little indirect |
| 18:52 | <domfarolino> | But I could be swayed either way |
| 18:54 | <annevk> | domfarolino: ok |
| 19:01 | <jyasskin> | Domenic/annevk: How important is it to make sure that the generic IDL language doesn't create unused slots? I'm thinking that the 20% remaining could just not use their slots, and implementations wouldn't need to allocate space for them. |
| 19:01 | <Domenic> | I think it'd be confusing. Not fatal, but definitely confusing. |
| 19:38 | <tobie> | Domenic, annevk, jyasskin, domfarolino: just to clarify, the current [slot] proposal "allocates" a slot per attribute, defaults getters and setters to read and write from slots unless their behavior is specified in prose, and allows adding custom slots on top of those. |
| 19:41 | <tobie> | jyasskin: it doesn't really bother me that slots get "allocated' and then not used. They're spec'ing devices anyway, not accessible in ES at all. |
| 19:42 | <jyasskin> | tobie: That seems totally reasonable to me. It loses a tiny bit of redundancy with which we might be able to notice spec bugs, but we have that redundancy today and so many violations of it in otherwise-correct specs, that I'd rather have your proposal. |
| 19:44 | <tobie> | jyasskin: that said, that PR is an initial proposal for discussion. |
| 19:46 | <tobie> | jyasskin: It's based on my understanding of folks need/have asked for. |
| 19:46 | <tobie> | jyasskin: of *what |
| 19:50 | <tobie> | jyasskin: Note another option would be doing this in reverse, they way Ruby does it. That is, specify all the slots you need, and have a way to create attribute getters/setters that just reflect those (see: https://stackoverflow.com/a/5046915/6197646) |
| 19:53 | <tobie> | jyasskin: possibly even with an extended attribute, e.g.: [reflects=foo] attribute DOMString bar; |
| 20:04 | <domfarolino> | tobie: FWIW I like the reverse way a lot, since the internal slots will always exist and we can cherry pick which ones will be exposed to ES |
| 20:05 | <tobie> | domfarolino: the one I just described above? |
| 20:05 | <domfarolino> | tobie: yep, the Ruby way. I kind of like it |
| 20:06 | <Domenic> | I too find it fairly nice. |
| 20:07 | <tobie> | oh, would we be moving towards consensus? |
| 20:08 | <tobie> | TabAtkins, annevk: thoughts on the Ruby-inspired slot proposal? |
| 20:16 | <annevk> | Fine with me |
| 20:17 | <annevk> | Seems better than always slots, suspect that will not work for TC39 and also feels a bit unclean |
| 21:08 | <jyasskin> | tobie: I see 3 options: 1, the current proposal) interface I { [[SlotWithoutAttr]]; readonly attribute DOMString attrReflectsSlot; attribute DOMString computedAttr; }; In prose: computeAttr's getter MUST...; its setter MUST .... |
| 21:08 | <jyasskin> | tobie: 2, Domenic's option) interface I { [[SlotWithoutAttr]]; [Slot] readonly attribute DOMString attrReflectsSlot; attribute DOMString computedAttr; }; In prose: computeAttr's getter MUST...; its setter MUST .... |
| 21:09 | <jyasskin> | 3, Ruby-style) interface I { [[SlotWithoutAttr]]; [ReflectReadonly] DOMString [[reflectedSlot]]; attribute DOMString computedAttr; }; In prose: computedAttr's getter MUST...; its setter MUST .... |
| 21:10 | <jyasskin> | Those are pretty similar, so I'd be fine with all of them. I *think* 2's my favorite. |
| 21:39 | <tobie> | jyasskin: it's funny (3) is quite a bit different the way you write from what I had imagined. |
| 21:44 | <jyasskin> | tobie: Your way's probably fine too? |
| 21:48 | <tobie> | jyasskin: ^ updated the issue |
| 21:50 | <jyasskin> | tobie: Thanks! Now I stand corrected: I don't like your Ruby-style option because it adds a line of declaration. It's still better than the status quo, but the other options DRY better. |
| 21:53 | <tobie> | jyasskin: frankly, I think they all have different tradeoffs. |
| 21:55 | <tobie> | jyasskin: if folks have interfaces that would showcase those well, send them to me; I'll just try them out and post the results somewhere. |
| 21:59 | <TabAtkins> | tobie: no idea, I'm on vacation, please write it up in an organized way in the issue and don't make decisions over Xmas-ish. 😀 |
| 22:00 | <TabAtkins> | Also: who's in charge of @intenttoship, and can they figure out what part of the pipeline is (incorrectly) doing HTML parsing? https://twitter.com/intenttoship/status/942818202349948930 |
| 22:00 | <tobie> | TabAtkins: :D |
| 22:01 | <tobie> | TabAtkins: I will not comment on the fact that you are answering irc during your vacation. |
| 22:01 | <TabAtkins> | We were resting between exhibits, I already delayed my answer by a few hours. 😀 |
| 23:14 | <domfarolino> | Domenic: In light of https://github.com/whatwg/console/issues/121#issuecomment-352587781 do you think this issue can be closed? |
| 23:34 | <Domenic> | domfarolino: yeah, I would. |
| 23:42 | <Domenic> | Hmm I guess https://github.com/whatwg/console/issues/27 is mostly done, just need some -historical.html web platform tests and browser bugs perhaps? |