| 01:42 | <MikeSmith> | so I’m wondering why UAs can’t/don’t process the value of the “is” attribute case-insensitively |
| 01:42 | <MikeSmith> | given that the parser puts HTML elements into the DOM in lowercase |
| 01:42 | <MikeSmith> | including custom elements |
| 01:44 | <MikeSmith> | I don’t understand why at https://html.spec.whatwg.org/multipage/scripting.html#valid-custom-element-name we are requiring that valid custom element names not contain uppercase ASCII characters |
| 01:46 | <MikeSmith> | it seems like we should allow them to contain uppercase ASCII just as we allow all other HTML element names to contain uppercase ASCII |
| 02:21 | <MikeSmith> | and document.registerElement(...) also lowercases the element name |
| 02:27 | <MikeSmith> | ah... but window.customElements.define(...) doesn’t lowercase the name, and throws if it contains uppercase |
| 03:47 | <MikeSmith> | https://github.com/w3c/webcomponents/issues/604#issuecomment-259608657 |
| 03:56 | <MikeSmith> | I notice at the time of https://github.com/w3c/webcomponents/issues/403 at least, there was an explicit step, “If DOCUMENT is an HTML document, let NAME be converted to ASCII lowercase” |
| 03:56 | <MikeSmith> | wonder why that was dropped |
| 03:57 | MikeSmith | finds https://www.w3.org/Bugs/Public/show_bug.cgi?id=25290 “Ban uppercase and leading "xml" in custom element names?” from zcorpan |
| 04:03 | <MikeSmith> | so I guess the problem is that unlike HTML parsers, XML parsers do not lowercase element names |
| 08:18 | <annevk> | MikeSmith: yeah, it's about XML compat |
| 08:23 | <MikeSmith> | annevk: yeah I can see now it makes sense |
| 08:23 | <annevk> | We do the same thing for data-* |
| 08:25 | <MikeSmith> | OK |
| 08:26 | <MikeSmith> | but now to me what make less sense is that we do not (yet) make it parse error in the parsing algorithm if a hyphen-containing tag name has uppercase characters |
| 08:26 | <MikeSmith> | I think we should |
| 08:26 | <MikeSmith> | I guess I’ll make a PR and see what others think |
| 08:26 | <MikeSmith> | if we make a change for that it will not affect the DOM |
| 08:27 | <MikeSmith> | DOM result will be no different, just that error-reporting parsers can report it |
| 08:27 | <MikeSmith> | and the HTML checker can report it |
| 08:27 | <MikeSmith> | because the problem is, without that, I have no way to report an error if a document has <Foo-Bar> or whatever |
| 08:28 | <MikeSmith> | because the parser silently lowercases it |
| 08:28 | <MikeSmith> | and it is exposed to the rest of the checker code as already-lowercased |
| 08:29 | <MikeSmith> | and then I end up a weird situation where the checker reports an error for <button is="Foo-Bar"> but not for <Foo-Bar> |
| 08:34 | <annevk> | MikeSmith: but that is as expected I think |
| 08:34 | <annevk> | MikeSmith: the HTML syntax for element names is case-insensitive, whereas for attributes it depends |
| 08:35 | <annevk> | MikeSmith: so it's perfectly fine to write a custom element name as HA-HA, since that ends up being ha-ha, which doesn't contain ASCII upper alpha |
| 08:35 | <MikeSmith> | I think it is not necessarily what users would expect in this case |
| 08:36 | <annevk> | It's the same for data-* |
| 08:36 | <MikeSmith> | well I think users will be surprised that is="HA-HA" causes a checker error but <HA-HA> does not |
| 08:36 | <annevk> | You can write data-TEST, but it will mean data-test |
| 08:37 | <MikeSmith> | yeah I think users would expect that is="HA-HA" should just end up as is="ha-ha" |
| 08:37 | <MikeSmith> | if "ha-ha" is an element name |
| 08:37 | <annevk> | Hmm, I guess we could make that work, but I'm not sure it's worth it |
| 08:37 | <MikeSmith> | it’s not just a normal attribute value, it’s a reference to an element name |
| 08:37 | <MikeSmith> | yeah not sure either |
| 08:37 | <annevk> | Seems better if everyone just uses lowercase |
| 08:38 | <MikeSmith> | maybe nobody other than me would care |
| 08:47 | <MikeSmith> | annevk: the problem the checker tries to help solve is, what happens when somebody doesn’t use lowercase and goes to check a document |
| 08:48 | <annevk> | tobie: FWIW, I think tackling mixin syntax would be better as a somewhat large feature |
| 08:48 | <annevk> | tobie: at least, I thought we singled that out as somewhat high priority during TPAC |
| 08:49 | <annevk> | MikeSmith: yeah, but if you use uppercase in markup and uppercase in the API, it won't work |
| 08:49 | <annevk> | MikeSmith: the custom element will only work if you know what you're doing (uppercase in markup, lowercase in API) |
| 08:50 | <annevk> | MikeSmith: but maybe the validator should at least warn about it? |
| 08:50 | <annevk> | MikeSmith: or measure how often it happens to see if it's worth worrying about |
| 08:51 | <MikeSmith> | yeah I could add a use counter for teh checker I guess |
| 08:57 | <MikeSmith> | annevk: not to beat this into the ground, but it comes down to whether <HA-HA> in a document is document-conformance error or not |
| 08:57 | <MikeSmith> | by a strict reading of the current spec, it is a conformance error |
| 08:58 | <MikeSmith> | because the spec says that custom elements must have a “valid custom element name”, and HA-HA is not a valid custom element name |
| 09:03 | <annevk> | MikeSmith: that's not how it works |
| 09:03 | <annevk> | MikeSmith: <A> is a conformance error too |
| 09:03 | <annevk> | MikeSmith: but you cannot write <A> in text/html and have it turn out as <A> |
| 09:04 | <annevk> | MikeSmith: so <A> ends up being conforming, due to the way the parser works, as it turns out as <a> |
| 09:04 | <annevk> | <HA-HA> is no different |
| 09:04 | <MikeSmith> | I don |
| 09:04 | <MikeSmith> | I don' |
| 09:05 | <MikeSmith> | oofs |
| 09:05 | <MikeSmith> | I think most users do not see things that way |
| 09:06 | <annevk> | If they see it as <A> and <a> being equivalent and that's what you want to push for, we should change the DOM APIs to lowercase |
| 09:06 | <annevk> | But I don't think that will necessarily go over well |
| 09:06 | <annevk> | Also, as for most users, I would expect them to not hit this |
| 09:07 | <MikeSmith> | yeah I guess that’s true |
| 09:58 | <MikeSmith> | OK I pushed checker support for custom-element-name checking conforming to https://html.spec.whatwg.org/multipage/scripting.html#valid-custom-element-name |
| 09:58 | <MikeSmith> | pushed to https://checker.html5.org/ and https://validator.w3.org/nu/ |
| 09:59 | <MikeSmith> | with that I think the checker now has complete support for checking of custom-elements document-conformance requirements |
| 09:59 | <MikeSmith> | as far as the markup for custom elements at least |
| 10:58 | <smaug> | annevk: happy to see this https://github.com/whatwg/dom/issues/211#issuecomment-267918029 . I wonder if you could have some helper tool/script to automate that. And at least bugzilla bugs could perhaps have some "spec-change" annotation or such |
| 11:01 | <MikeSmith> | annevk: https://stackoverflow.com/questions/40939857/fetch-with-readablestream |
| 11:13 | <annevk> | smaug: overholt at some point was working on something, but guessing he got too busy with other things |
| 11:14 | <annevk> | MikeSmith: follow issue link in second comment, I guess I can add an answer there too |
| 11:50 | <MikeSmith> | annevk: yeah was just FYI in case you wanted to add anything there |
| 12:02 | <zcorpan> | annevk: https://xhr.spec.whatwg.org/#dom-xmlhttprequest-open step 1, in which cases is there no responsible document? |
| 12:03 | <zcorpan> | in a worker? |
| 12:06 | <zcorpan> | seems so |
| 12:28 | <Ms2ger> | Yeah |
| 13:56 | <annevk> | JakeA: I just reread OP of issue 27; it's fun that we're back to the couple of alternatives we came up with 18 months ago |
| 13:57 | <annevk> | JakeA: I had totally forgotten about FetchController since which is why I didn't understand the reference in the later comments |
| 14:42 | <wanderview> | JakeA: should ServiceWorker globals be exposed as Client objects? Seems that there can be existing SW threads that are same origin and captured by the existing Clients.matchAll({includeUncontrolled:true}) |
| 14:52 | <JakeA> | annevk: :D maybe we can get promise subclassing now |
| 14:53 | <JakeA> | wanderview: yeah, I mentioned that in the fetch event (for notifications) issue |
| 14:53 | <JakeA> | wanderview: it'd be a new type & uncontrolled |
| 14:54 | <wanderview> | JakeA: oh, sorry I missed that... I'll write an issue |
| 14:54 | <wanderview> | JakeA: do you think Clients.matchAll() should return a Client for the current environment? or exclude that explicitly |
| 14:56 | <JakeA> | wanderview: huh, good question. I guess this is the first time we've had to think about that. Um, my first instinct is to exclude the "self" client |
| 14:57 | <wanderview> | JakeA: agreed (affects my desire to expose on window.clients as well) |
| 14:57 | <wanderview> | JakeA: we can add an includeSelf:true option if people ask for it |
| 15:05 | <JakeA> | +1 |
| 15:06 | <Ms2ger> | <script type="text/javascript">document.write('</div>')</script> |
| 15:07 | <Ms2ger> | <noscript></div></noscript> |
| 15:07 | <Ms2ger> | Just for good measure |
| 15:08 | <annevk> | zcorpan: did we fix the timing of when allowpaymentrequest is consulted? |
| 15:09 | <annevk> | zcorpan: I thought that was a blocker |
| 15:10 | <zcorpan> | annevk: you mean snapshot vs live? |
| 15:10 | <annevk> | zcorpan: yeah |
| 15:10 | <zcorpan> | annevk: that is still open |
| 15:11 | <annevk> | zcorpan: I thought bz wanted that to be fixed first |
| 15:11 | <annevk> | zcorpan: or least have that be snapshots for any new additions |
| 15:12 | <annevk> | It's rather hard to find the original statement though since there's many issues |
| 15:13 | <annevk> | zcorpan: last paragraph of https://github.com/whatwg/html/issues/2143#issuecomment-265514585 |
| 15:15 | <zcorpan> | annevk: i guess the important thing is what behavior is shipped in a browser |
| 15:15 | <annevk> | zcorpan: sure, but now the signalling is that allowpaymentrequest is standardized, while it's actually broken |
| 15:21 | <zcorpan> | annevk: do you think i should decouple allowpaymentrequest from allowfullscreen in https://github.com/whatwg/html/pull/2187 ? |
| 15:21 | <wanderview> | JakeA: btw, now that we have reserved Clients, I think its perhaps more reasonable to expose some kind of "unloaded" Client attribute to handle the case where chrome has unloaded a tab for memory purposes... we should discuss again |
| 15:21 | <annevk> | zcorpan: if doing it for fullscreen is not compatible, I think so |
| 15:22 | <zcorpan> | annevk: i guess there is some uncertainty about the compat for fullscreen. So yeah, I can fix that tomorrow + write snapshot tests for allowpaymentrequest |
| 15:23 | <annevk> | ta |
| 15:29 | <gsnedders> | foolip: I'll have a car if it's somewhere near the airport. Whether you should trust me driving in the States is another question altogether. :) |
| 15:44 | <JakeA> | wanderview: tricky part is it'd be the first time they're recognised in specs |
| 15:45 | <wanderview> | JakeA: given mobile, I think its a common and realistic problem, though... we such entries in firefox for android and I expect other mobile browsers do as well |
| 15:45 | <wanderview> | JakeA: I agree we should discuss more, but I'm less opposed than I was before |
| 15:46 | <wanderview> | JakeA: of course, I can't speak for anyone else at mozilla and we are likely to have 20 different opinions |
| 15:49 | <JakeA> | wanderview: haha. But yeah, I'm happy to look at it again too |
| 15:50 | <inoas> | Could a declarative Shadow-DOM-Tag + <link rel="preload" /> + HTTP2 Prefetching allow for CSS encapsulation/modularization without adding tons of transfer-channels/request? e.g. hit two nails with one head? |
| 15:53 | <inoas> | Here are some details https://discourse.wicg.io/t/declarative-shadow-dom/1904/7 |
| 15:54 | <inoas> | and some more https://github.com/whatwg/html/issues/552#issuecomment-266546301 |
| 15:58 | <wanderview> | JakeA: btw, I'm planning to build my window.clients thing behind a flag... might enable it in FF nightly to experiment |
| 16:05 | <annevk> | inoas: I doubt folks want to modify the HTML parser further |
| 16:06 | <inoas> | annevk, beyond that, can you see the benefit? |
| 16:06 | <inoas> | it would just create a shadow dom instance instead of through js |
| 16:06 | <annevk> | inoas: there is no beyond if it does not change |
| 16:07 | <inoas> | There needs to be a good reason to add things |
| 16:07 | <inoas> | and a good reason would be separation of concerns of "modules" on web pages (their html, css, js) and at the same time speedy delivery (through http2 push) |
| 16:07 | <inoas> | wouldn't that help a lot? |
| 16:08 | <inoas> | with maintainability etc |
| 16:08 | <inoas> | and it would be closely related to the existing shadow dom tech |
| 16:08 | <annevk> | I'm not sure |
| 16:14 | <JakeA> | wanderview: ohhh good idea! I wonder if it'll be weird that messages land in serviceWorker.onmessage when they're not from service workers |
| 16:15 | <wanderview> | JakeA: I think I would only target message events there if they are coming from a service worker |
| 16:15 | <wanderview> | JakeA: but that is the most annoying thing to work around, yea |
| 16:15 | <wanderview> | JakeA: otherwise, I plan to fire message events at clients.onmessage |
| 16:23 | <JakeA> | wanderview: hah, thought the same. We could fire it there and work to deprecate serviceWorker.onmessage |
| 16:25 | <JakeA> | wanderview: clients API becomes another thing to break out of the SW spec |
| 16:26 | <wanderview> | JakeA: I think so yes... I think its a good primitive that can live on its own an underpin a lot of other stuff... I think Client should be defined next to "browsing context+environment+etc" in html... or maybe one day replace environment, etc |
| 16:26 | <wanderview> | well, given my short view of web history anyway... others probably have a better perspective than I do |
| 16:27 | <wanderview> | JakeA: and it would be nice to have something to suggest as a replacement for window.open |
| 16:29 | <wanderview> | async, avoids window.opener difficulties |
| 16:29 | <wanderview> | can be cross-process as a result |
| 16:30 | <foolip> | gsnedders: could you be more reckless than the average driver? I doubt it. |
| 16:31 | <gsnedders> | foolip: I'm used to neither LHD cars nor automatics, and US-101 scares me. |
| 16:31 | <foolip> | I would trust AI over you though, so know your days are counted! |
| 16:32 | <gsnedders> | foolip: I'm not sure *I* really trust myself to drive in the States. Mostly because I don't have the awareness of body language and unwritten habits of driving there. |
| 16:32 | <gsnedders> | I seem to keep doing so, though. :( |
| 16:35 | <foolip> | gsnedders: I've never driven in the US, not as brave/reckless as you are ;) |
| 16:37 | <gsnedders> | really what I should do is spend a few days driving around Sweden, where I'm familiar with the road laws, and get used to driving a LHD car, and then it'll probably start to be easier, given I won't have the overload of everything unknown at once :) |
| 16:39 | <foolip> | seriously, though, why bother driving at all, the long-distance trips will be rather few, right? |
| 16:43 | <gsnedders> | foolip: in part because practically I have the Sunday after I arrive and most of the Saturday before leaving to do stuff |
| 16:43 | <foolip> | Ah, but don't you know that walking around Mountain View on foot is great? The sights, the smells! |
| 16:44 | <gsnedders> | foolip: also, who even knows if the Google shuttles take contractors? etc. |
| 16:45 | <gsnedders> | foolip: also finding information about them is next to impossible, and flexibility with getting places in evenings, etc. |
| 16:47 | <foolip> | gsnedders: looks "TVCs" can use GBus for a symbolic amount for tax reasons. |
| 16:47 | <foolip> | gsnedders: but that won't help you have fun in the weekend, so... |
| 16:49 | <gsnedders> | I mean if we end up meeting in SF on Monday like hell am I driving up there. |
| 16:49 | <gsnedders> | I've driven in SF before; really the problems are the same as any big city with busy traffic where you don't know your way, but it still doesn't make me keen. |
| 16:50 | <JakeA> | wanderview: +1 |
| 18:11 | <annevk> | gsnedders: why do you stay in MTV? |
| 18:12 | <annevk> | gsnedders: just go to SF and walk/cycle around there |
| 18:13 | <tantek> | yes ^^^ |
| 18:18 | <Ms2ger> | Domenic, ping |
| 18:18 | <Domenic> | Ms2ger: pong |
| 18:18 | <Ms2ger> | Domenic, I'm trying to make sense of fetch/api/response/multi-globals/url-parsing.html in wpt, and failing miserably |
| 18:19 | <Ms2ger> | Domenic, it seems to call the Response constructor with one argument, "url", and checking |
| 18:19 | <Ms2ger> | assert_equals(res.headers.get("Location"), new URL("current/url", location.href).href); |
| 18:20 | <Domenic> | Ms2ger: it's calling Response.redirect(url) |
| 18:20 | <Ms2ger> | I am blind indeed |
| 18:20 | <Ms2ger> | Thanks :) |
| 18:20 | <Domenic> | Phew, glad it wasn't something more complicated :) |
| 18:26 | <TabAtkins> | MikeSmith: The ZWJ and ZWNJ *are* printing characters (as much as any other modifier character is), and they *do* survive copy-paste iirc. They're a necessary part of formatting words in some languages. |
| 18:27 | Ms2ger | formats TabAtkins |
| 18:29 | <Ms2ger> | TabAtkins, did you file a bug for https://github.com/w3c/csswg-drafts/issues/695 ? |
| 18:29 | <TabAtkins> | gsnedders: If you have a G badge, you can ride the bus. fantasai's done it plenty. The bus schedules are semi-private, but I'm happy to share them with you; there's a nice spreadsheet-masquerading-as-app that has all the info. |
| 18:30 | <TabAtkins> | Ms2ger: I did not. I'll get on that, thanks. |
| 18:30 | <Ms2ger> | Takk |
| 18:31 | <Ms2ger> | TabAtkins, also wanna fight Hixie in https://lists.w3.org/Archives/Public/www-archive/2016Oct/0009.html ? :) |
| 18:32 | <TabAtkins> | I'll fight him after the change is made; it's not gonna be worth it before then. ^_^ |
| 19:01 | <TabAtkins> | Ms2ger: https://bugs.chromium.org/p/chromium/issues/detail?id=675670 |
| 19:01 | <Ms2ger> | Thanks |
| 19:03 | <gsnedders> | annevk: BlinkOn is in MV. There *may* be a meeting in SF the day before. |
| 19:04 | <gsnedders> | annevk: The meeting the day before may also be in MV. And I've already got a hotel in MV for the whole week. |
| 19:04 | <annevk> | gsnedders: you can still stay in SF and take the "wonderful" Caltrain |
| 19:04 | <gsnedders> | ehhh. I'd be sufficiently scarcely in SF it wouldn't really be worth it. |
| 19:05 | <annevk> | gsnedders: anyway, I'd just take the train into the city on your free days |
| 19:05 | <gsnedders> | TabAtkins: I need to get a badge on the Monday; that's one of the things I need to do |
| 19:08 | <Domenic> | [EnsureUTF16] was replaced with USVString, right? |
| 19:08 | <gsnedders> | Yes. |
| 19:09 | <Domenic> | Ah I see already filed https://github.com/w3c/FileAPI/issues/9 |
| 19:16 | <Ms2ger> | Yeah, we had an editor for a moment there, but he disappeared too :/ |
| 19:17 | <smaug> | Domenic: ok, I'm totally lost now what you're asking |
| 19:18 | <smaug> | oh, hmm |
| 19:18 | <smaug> | you mean the DataTransfer part |
| 19:18 | <Domenic> | Yes, if you want a DataTransfer constructor, how would you spec/implement it |
| 19:19 | <smaug> | Domenic: what is the issue with that? |
| 19:19 | <smaug> | DataTransfer has setData |
| 19:19 | <smaug> | and such |
| 19:19 | <smaug> | so, I think I'm still missing what you mean |
| 19:19 | <Domenic> | smaug: yes, which set data on an active drag data store, associated with a user drag |
| 19:20 | <smaug> | oh, that part |
| 19:20 | <smaug> | yeah, "untrusted" DataTransfer would just keep the data alive |
| 19:20 | <smaug> | and do nothing else |
| 19:20 | <Domenic> | e.g. what does setting dropEffect/effectAllowed do |
| 19:20 | <smaug> | nothing |
| 19:20 | <smaug> | just keep the state there |
| 19:20 | <Domenic> | You end up just creating a parallel universe where every part of DataTransfer has an "if in the special testing mode, do X" branch |
| 19:21 | <smaug> | not much different to say trusted vs untrusted events |
| 19:22 | <smaug> | whether it actually would be used is unclear |
| 21:44 | <inoas> | annevk: Did you take a look at the concept, does it sound solid? |
| 23:02 | <tantek> | what specs defines encodeURI? |
| 23:02 | <tantek> | *spec |
| 23:05 | <Domenic> | tantek: https://tc39.github.io/ecma262/#sec-encodeuri-uri |
| 23:09 | <tantek> | ty. now digging into https://github.com/tc39/test262 |
| 23:10 | <terinjokes> | Domenic: looks like supporting `%d` as an alias for `%i` is going to be a breaking change for Node.js |
| 23:10 | <Domenic> | terinjokes: weird. Where are these discussions happening? |
| 23:10 | <terinjokes> | https://github.com/nodejs/node/issues/10292 |
| 23:11 | <terinjokes> | where i sent Fishrock123 to the console issue tracker (albeit, looks like he was still using the old DevToolsWG spec) |
| 23:13 | <Domenic> | Good stuff |
| 23:14 | <Domenic> | terinjokes: you should work on https://github.com/whatwg/console/issues/74 :) |
| 23:14 | <terinjokes> | i just assigned myself |
| 23:15 | <tantek> | Domenic: background: seeing inconsistent encodeURI behavior between FF/Chrome and trying to track down which to fix: FF, Chrome, spec |
| 23:16 | <terinjokes> | Domenic: maybe worth closing the console.assert issue, or marking it as good first bug (to add the note) imho |
| 23:16 | <Domenic> | tantek: oh wow, I thought we ironed that out a long time ago; nice catch |
| 23:16 | <Domenic> | terinjokes: which one? |
| 23:16 | <botie> | i think which one is it? |
| 23:16 | <terinjokes> | Domenic: https://github.com/whatwg/console/issues/62 |
| 23:16 | <tantek> | Jeremy Keith (adactio) came across the problem, Kartik Prabhu narrowed it down, and then someone has to dig into which bug databases / spec(s) / test suite(s) |
| 23:17 | <Domenic> | terinjokes: hmm yeah. You should fix it or write up a summary of what a good first PR would say and tag it :) |
| 23:17 | <terinjokes> | kk |
| 23:18 | terinjokes | goes back to his day job Java work |
| 23:18 | <terinjokes> | :'( |
| 23:29 | <terinjokes> | Domenic: does Edge not support global.performace? |
| 23:29 | <terinjokes> | or something similar? |
| 23:29 | <terinjokes> | i agree a bit here |
| 23:29 | <Domenic> | terinjokes: seems supported |
| 23:30 | <terinjokes> | in that it seems like a weird thing to tack onto console |
| 23:34 | <gsnedders> | tantek: which case are you hitting? |
| 23:35 | <tantek> | gsnedders, here's the user scenario, as documented: https://adactio.com/journal/11632#confuses%20the%20fragmention |
| 23:35 | <tantek> | still tracking down exactly where the incompat is happening |
| 23:35 | <tantek> | possibly to do with text selection handling too |
| 23:37 | <gsnedders> | tantek: oh, that I don't know about |
| 23:38 | <tantek> | gsnedders, yeah we're still narrowing it down |
| 23:38 | <tantek> | looking at suspects :) |
| 23:39 | <gsnedders> | Well, yeah. Just doesn't look like anything I'm aware of. |
| 23:39 | <gsnedders> | :) |
| 23:39 | gsnedders | -> bed |