| 05:08 | <yoav> | Domenic: Following our discussion from yesterday, can you take a look at https://github.com/whatwg/html/pull/3774 just as a sanity check? (to make sure the technical spec bits are in order) |
| 05:49 | <yoav> | foolip: in case you're around, I'd appreciate a look at https://github.com/whatwg/html/pull/3774 to make sure I'm not Holding It Wrong™ |
| 06:24 | <domfarolino> | yoav: I believe he's OOO till July 5th or so |
| 06:24 | <domfarolino> | foolip that is |
| 06:24 | <yoav> | domfarolino: ok, thanks |
| 09:40 | <foolip> | yoav: afraid I'm also OOO, until July 5 in my case. Not sure exactly when annevk is back. |
| 09:48 | <annevk> | July 19 |
| 10:53 | <yoav> | foolip & annevk: ok, have fun! :) |
| 11:37 | <hsivonen> | I have vague recollection that WPT used to have a copy of the html5lib tests, but now I don't see them. Have they been removed? |
| 11:38 | <hsivonen> | also: Are the html5lib encoding tests actually valid? Some seem to assume <meta> scanning beyond 1024 bytes |
| 11:39 | <hsivonen> | does there exist a browser test harness for html5lib encoding tests? |
| 11:39 | <foolip> | hsivonen: gsnedders would know |
| 11:40 | <gsnedders> | hsivonen: only of the parser tests |
| 11:40 | <gsnedders> | hsivonen: the encoding tests there's some issue on the html5lib-tests repo that is essentially "fix this" |
| 11:40 | <hsivonen> | gsnedders: ok. :-( thanks. |
| 11:48 | <hsivonen> | everything is a rathole. I thought I'd fix this easy bug while waiting for a try run for another patch and now testing this properly is basically a matter of adding the html5lib encoding tests to WPT... |
| 11:53 | <hsivonen> | I take it that I should write a Python Handler per https://wptserve.readthedocs.io/en/latest/handlers.html#python-handlers that parses a .dat file and takes a number indicating which test in the .dat file to serve as text/html? |
| 11:54 | <hsivonen> | and then also parse the .dat file in JS to retrieve the corresponding expected encodings |
| 11:56 | <Ms2ger> | Or add a build step |
| 11:57 | <hsivonen> | Ms2ger: what documentation should I read for that? |
| 11:57 | <hsivonen> | Ms2ger: or do you mean a manual import script? |
| 11:57 | <Ms2ger> | Basically, yes |
| 11:57 | <hsivonen> | Ms2ger: I see |
| 11:57 | <Ms2ger> | gsnedders probably has more thoughts |
| 12:06 | <hsivonen> | ah, the html5lib tests are there but not in .dat form |
| 12:06 | <hsivonen> | so it looks like they are imported with a manually-run import script |
| 12:22 | <hsivonen> | is it guarateed that os.getcwd() from within a Python Handler returns the path to the top-level directory of WPT? |
| 12:27 | <Ms2ger> | Probably not, but I don't suppose it'll change |
| 12:28 | <Ms2ger> | Might be worth filing an issue to make sure we test that |
| 12:36 | <hsivonen> | Ms2ger: ok. thanks |
| 14:10 | <gsnedders> | hsivonen, Ms2ger: we should document that either way |
| 14:13 | <Domenic> | yoav: sure I can take a look for sanity check |
| 14:14 | <yoav> | Domenic: awesome, thanks! :) |
| 18:01 | <domfarolino> | Domenic: have you gotten around to seeing https://github.com/web-platform-tests/wpt/pull/11584 by chance? |
| 18:01 | <Domenic> | domfarolino: ah yeah, it slipped out, let me review |
| 18:01 | <domfarolino> | no worries, thanks |
| 21:36 | <Domenic> | rniwa: I don't quite understand what you're saying at https://github.com/w3c/webcomponents/issues/468#issuecomment-400454801 . We're working from your preferences already; the choice is between an existing cascading order (UA level) and fake shadow root. Given that there are no new cascading orders involved, what are your thoughts? |
| 22:00 | <rniwa> | Domenic: the literal UA cascading order wouldn't work because then user stylesheet would be overridden |
| 22:01 | <Domenic> | rniwa: right, it's changed so that !important is not parsed |
| 22:01 | <rniwa> | Domenic: yeah, that would be a new cascading behavior, which we don't want |
| 22:01 | <Domenic> | Hmm, OK, in our implementation that was not a whole new cascading order. |
| 22:01 | <rniwa> | Domenic: it doesn't matter how many more changes you make, we always prefer fake-shadow-root approach |
| 22:02 | <rniwa> | Domenic: you don't need to keep asking me which one we prefer because we always prefer fake shadow root approach |
| 22:02 | <Domenic> | rniwa: that's a little unfortunate; you seem to be saying you're not interested in hearing reasoned discussion, but always want your idea to win, instead of debating on merits. |
| 22:02 | <Domenic> | We were hoping we could have a discussion based on what was good for web developers, instead of on whose idea it is. |
| 22:02 | <rniwa> | Domenic: i'm not arguing based on whose idea it was |
| 22:03 | <rniwa> | Domenic: we've repeatedly stated that we don't want to have a new cascading order or any other new behavior distinct from the way existing stylesheets work |
| 22:03 | <Domenic> | rniwa: Hmm OK, then could you help us understand the reasons, instead of just stating thta you always like your idea best, no matter what we say? |
| 22:03 | <rniwa> | Domenic: in order to avoid create author confusions |
| 22:03 | <rniwa> | Domenic: look, i've stated this reasoning 2-3 times already |
| 22:03 | <rniwa> | Domenic: i really don't want to keep repeating myself |
| 22:03 | <Domenic> | It's the "any other new behavior" that you haven't stated before |
| 22:03 | <rniwa> | Domenic: we have |
| 22:03 | <Domenic> | rniwa: I understand it's hard to engage in a dialogue some times, but I hope you can find the time |
| 22:04 | <Domenic> | We're concerned about the new behavior of a fake shadow root being confusing for authors. |
| 22:04 | <rniwa> | Domenic: i really don't have a time to keep stating the exact same preference over and over |
| 22:04 | <Domenic> | Can you see where we're coming from with that? |
| 22:04 | <Domenic> | rniwa: stating preferences is not what we're interested in; discussing tradeoffs is what I'm hoping you can help us with. |
| 22:04 | <rniwa> | Domenic: well, we've already discussed that internally |
| 22:05 | <Domenic> | rniwa: oh, OK, if you don't have time to engage, maybe some of the folks you've discussed internally with could help? |
| 22:05 | <rniwa> | Domenic: we've considered all those options you've stated and concluded that we'd like to use fake-shadow-root approach |
| 22:05 | <Domenic> | rniwa: that's great, we understand that part. We're hoping you, or someone else, could help us work through the reasoning and tradeoffs. |
| 22:05 | <rniwa> | Domenic: maybe you can ask hober |
| 22:06 | <Domenic> | OK, yeah, perspectives appreciated, hober or othermaciej |
| 22:07 | <rniwa> | Domenic: the reasoning is simple: we have shadow root, and worked through many issues to get it work to support both components defining its own style & letting users of components override it. we've also defined a way for component to specify important rule in a way which doesn't prevent user stylesheet from overriding it |
| 22:07 | <rniwa> | given this, we have no reason to create a brand new cascading order, or a brand new style behavior such as ignoring important! rule |
| 22:08 | <rniwa> | furthermore, the last time we added the support for shadow root's cascading order support, we observed a serious performance hit which is inherent to introducing a new cascading order |
| 22:08 | <rniwa> | note that i've stated all of this at F2F in Tokyo before |
| 22:09 | <rniwa> | i find it extremely frustrating that i flew all the way to Tokyo to state all of this and i've been asked to state the exact same stuff again. |
| 22:09 | <Domenic> | rniwa: I appreciate your patience, even if you believe that you're repeating yourself. Note that the discussion has changed, as we are explicitly taking into account your requirement of no new cascading order to accomodate WebKit's performance constraints; we explicitly made an alternative with an existing cascading order but tweaked !important parsing to accomodate you. |
| 22:09 | <rniwa> | i understand that you're not gonna remember everything i state anywhere but i feel like this is 3rd or 4th time i've been asked to repeat myself |
| 22:10 | <Domenic> | I do not believe it was ever stated that any new behavior was unacceptable, as at the F2F you stated it was a performance issue with WebKit and new cascading orders, not any changes to their CSS infrastructure at all. |
| 22:10 | <rniwa> | Domenic: i've already said that that wouldn't work because it wouldn't let components to set an important rule which prevent users of components from overriding |
| 22:11 | <Domenic> | Sorry, I apologize for not remembering that was a requirement. That kind of requirement was what rakina and I were trying to draw out from you with the tables and such. |
| 22:11 | <rniwa> | Domenic: i'm pretty sure our statement was that the behavior of this styling mechanism should be identical to that of using a shadow root |
| 22:11 | <Domenic> | I appreciate you engaging on the level of actual use cases and requirements like "components must be able to create styles that users of the component cannot override" instead of "we always prefer the fake SR approach because we discussed it internally and it's best" |
| 22:13 | <rniwa> | another big concern we have with this constructible stylesheet & custom element combo is the developer tools |
| 22:13 | <rniwa> | today, it's pretty easy to find a stylesheet because it's in the DOM tree |
| 22:13 | <rniwa> | with this new mechanism, stylesheet is not in the DOM so we'd need a new mechanism to display & let authors interact with it. |
| 22:13 | <rniwa> | which would require a new UI, etc... in our developer tool |
| 22:13 | <rniwa> | i'm not saying that we wouldn't do it because of it |
| 22:14 | <rniwa> | but this feature already has a high cost of implementation just because of that aspect |
| 22:14 | <rniwa> | there is no way we'd accept any other complication from more custom behaviors |
| 22:15 | <Domenic> | It's good to hear about what engineering tradeoffs make it harder to implement things in WebKit. For our part it seems most things are implementable; we're concerned about the developer-facing issues like how to explain the use of :host/:host-context/::slotted selectors on something that doesn't have a shadow DOM. |
| 22:16 | <rniwa> | Domenic: we can disallow those if you'd like |
| 22:16 | <rniwa> | Domenic: and use :root instead |
| 22:16 | <rniwa> | Domenic: but i don't think :root makes much sense |
| 22:17 | <rniwa> | Domenic: so maybe we'd need a new pseudo class? |
| 22:17 | <Domenic> | Hmm, interesting, I thought that would go against your requirement of no changes to your CSS infrastructure. |
| 22:17 | <rniwa> | Domenic: no, adding a new pseudo class would be re-using the existing machinary |
| 22:17 | <rniwa> | Domenic: adding a new cascading order or ignoring !important is not |
| 22:17 | <Domenic> | OK, good to know. |
| 22:18 | <Domenic> | This is really helpful; with that in hand I'm hopeful we can make progress on the fake-SR approach. |
| 22:19 | <Domenic> | Thanks for taking the time, and having the patience. |
| 22:19 | <rniwa> | Domenic: np |
| 23:53 | <gsnedders> | if I create a document with document.implementation.createDocument, can I somehow get a iframe containing that document? |
| 23:54 | <gsnedders> | given a Document object, how can I apply CSS styles to that? There's no Element.style, and I can't see a way to append a stylesheet to a document? |