| 02:37 | <MikeSmith> | smola_: java -cp /opt/workspace/checker/dependencies/galimatias-0.0.2.jar io.mola.galimatias.cli.CLI "foo" -> "Error: Missing scheme" |
| 02:38 | <MikeSmith> | smola_: why doesn't it just handle that as a relative URL? |
| 02:39 | <MikeSmith> | oh I guess it has not base URL in scope |
| 02:41 | <MikeSmith> | it seems like in the case of examining a URL in isolation, it shouldn't require a base URL |
| 02:55 | <MikeSmith> | hmm per the URL spec "foo bar" (with a base URL in scope) and "http://example.com/foo bar" are not parse errors? |
| 03:14 | <MikeSmith> | nm |
| 03:15 | MikeSmith | found io.mola.galimatias.StrictErrorHandler |
| 05:04 | <SamB> | hmm, do you have an actual motto and/or slogan? |
| 09:53 | <MikeSmith> | smola_: you around? when you have time I wanted to chat with you about handling of relative URLs in galimatias |
| 10:52 | <davve> | https://github.com/w3c/web-platform-tests mentions references to http://w3c-test.org/... under Publication but the links seem to be stale. Is there a replacement or something? |
| 10:52 | <davve> | I'm particulary interested in https://w3c-test.org/web-platform-tests/submissions/ |
| 10:54 | <Ms2ger> | Why? |
| 10:54 | <Ms2ger> | https://w3c-test.org/web-platform-tests/submissions/ is only to aid reviews |
| 10:54 | <davve> | Yes, I have a review I'd like to demo. |
| 10:54 | <Ms2ger> | And your PR isn't on there? |
| 10:55 | <davve> | Hm, I can't connect to it. |
| 10:56 | <jgraham> | davve: w3c-test.org is migrating to wptserve |
| 10:56 | <Ms2ger> | Oh, that's now? |
| 10:56 | <jgraham> | http://w3c-test.org/submissions has some submissions |
| 10:57 | <davve> | Not mine though. (r/938) |
| 10:57 | <jgraham> | I think you will have to talk to denis/MikeSmith |
| 10:57 | <jgraham> | Try #testing on irc.w3.org |
| 10:58 | <davve> | Thanks. |
| 11:09 | <MikeSmith> | davve: yeah let's deal with it on #testing. though I'm away from my PC for the next two hours |
| 11:10 | <deniak> | davve, what's the number of your PR? |
| 11:11 | <deniak> | I got it |
| 11:11 | <deniak> | http://w3c-test.org/submissions/718/ |
| 11:13 | <MikeSmith> | deniak: thanks. davve should probably be added so he can do wc-test:mirror himself next time. he works for opera |
| 11:16 | <darobin> | we can certainly add davve, though if we add him he normally won't need to do w3c-test:mirror since he'll be in the admins list :) |
| 11:17 | <darobin> | davve: your PR should be automatically mirrored from now on |
| 11:53 | <davve> | Thanks all! |
| 12:02 | <wirepair> | x-frame-options, CORS, x-xss-protection, strict-transport-security, public-key-pins, content-security-policy, x-content-type-options am i missing any other security related headers? (draft specs OK) |
| 12:05 | <wirepair> | er minus Authorization from that list |
| 13:38 | <MikeSmith> | does the URL spec really require that parsing "foo" results in a failure instead of a URL? |
| 13:39 | <SimonSapin> | MikeSmith: without a base URL, I think it does |
| 13:39 | <SimonSapin> | the idea being that the result of parsing is always an absolute URL |
| 13:40 | <MikeSmith> | SimonSapin: ok |
| 13:40 | <SimonSapin> | but maybe there is a use case for parsing relative URLs independently of a base, and change the spec |
| 13:41 | <MikeSmith> | I guess there's not, in that a relative URL has to have something to be relative against |
| 13:42 | <MikeSmith> | and I think in practice all non-absolute URLs are used in some context where they're relative to something |
| 13:42 | <MikeSmith> | otherwise they don't really mean anything |
| 13:45 | <SimonSapin> | I think they do, in the browsers |
| 13:46 | <SimonSapin> | In other contexts maybe not. Should an HTTP server use the URL parser to parse the request? |
| 13:48 | <MikeSmith> | true that's a different case |
| 14:36 | <SimonSapin> | actually in that case we just need to provide a separate thing to parse abs_path, not any relative URL http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.2 |
| 17:03 | <TabAtkins> | The only reason to parse something to a relative url is so that you can get some work done "eagerly", and then canonicalize it against a base url later when you actually want to use it. Relative urls aren't actually useful for anything, as far as I can tell, by themselves. |
| 17:15 | <Hixie> | MikeSmith: without a base url, you can't know what "foo" means. Consider if the base URL is "http://example.com/"; vs if it's "about:blank". |
| 17:19 | <Hixie> | sicking: looks like inert="" was added just so you could do <dialog> without <dialog>. |
| 17:19 | <Hixie> | sicking: i guess i'll drop it for now |
| 17:19 | <sicking> | Hixie: cool, thanks |
| 17:21 | <sicking> | Hixie: is there some way to use <dialog> such that you get a centered window on a desktop browser, but a fullscreen window on a small-screen device like mobile? |
| 17:21 | <Hixie> | hopefully that would be the default behaviour |
| 17:21 | <Hixie> | at lease for showModal() |
| 17:21 | <Hixie> | but i don't have per-device default CSS currently |
| 17:22 | <Hixie> | sicking: what would you have happen on a tablet? |
| 17:22 | <Hixie> | sicking: i.e. is it a dimension-based decision? |
| 17:22 | <Hixie> | sicking: what should happen if you make a desktop window narrower? |
| 17:23 | <TabAtkins> | Ugh, dropping a piece of <dialog> functionality is bad. <dialog> is not the primitive, it's just a convenient package for several things all together. |
| 17:23 | <sicking> | Hixie: yes, i think it's a screen-size thing |
| 17:23 | <Hixie> | TabAtkins: having to implement inert="" as it was specced would be a performance drag |
| 17:24 | <sicking> | TabAtkins: the primitivies for <dialog> is already there. Just use CSS and JS |
| 17:24 | <Hixie> | TabAtkins: we can always introduce an API that just makes a subtree non-inert without <dialog> if there's a use case for that |
| 17:24 | <TabAtkins> | sicking: Except for the inertness of the rest of the document. |
| 17:24 | <Hixie> | sicking: k. i can add an @media rule to the default style sheet. What should the cut-off be? |
| 17:24 | <TabAtkins> | Hixie: That's fine, I just don't like excessively magical things. |
| 17:24 | <sicking> | Hixie: no idea |
| 17:24 | <Hixie> | TabAtkins: nothing magical here, it's all specced :-) |
| 17:25 | <sicking> | TabAtkins: true, the find-as-you-type inertness is magical still |
| 17:25 | <TabAtkins> | Hixie: You know that's not the definition of "magic" I'm using. ^_^ |
| 17:25 | <sicking> | TabAtkins: the "supress mouse/touch events" isn't really magical though |
| 17:25 | <Hixie> | TabAtkins: not really sure what you mean by "magic" then |
| 17:26 | <Hixie> | sicking: (dialog also stops tab from moving focus into the inert section, fwiw) |
| 17:26 | <TabAtkins> | Probably best understood as an analogy to axioms. You try to make your axioms as simple as possible, and build on top of them. The axioms are ultimately unexplained and taken as Truth within your system, but everything else is explainable with them. |
| 17:26 | <sicking> | Hixie: true |
| 17:26 | <Hixie> | the spec explains it all. |
| 17:27 | <TabAtkins> | You're misinterpreting still. |
| 17:27 | <TabAtkins> | This is an analogy. ^_^ |
| 17:27 | <Hixie> | yeah. i don't understand this whole "explain things" thing |
| 17:27 | <Hixie> | the more i try to understand it the less i get it |
| 17:27 | <Hixie> | i like the "use cases" approach much more |
| 17:27 | <TabAtkins> | Here, being "unexplained" means "being able to do something that you can't otherwise do". |
| 17:28 | <Hixie> | it's the "can't otherwise" part i have a problem with |
| 17:28 | <TabAtkins> | An unreproducible ability is an axiom. |
| 17:28 | <Hixie> | how do you "explain" the javascript "if" statement? |
| 17:28 | <TabAtkins> | You don't - "if" is a primitive. |
| 17:28 | <Hixie> | how do you "explain" the screen? |
| 17:28 | <Hixie> | how do you "explain" tab focus? |
| 17:28 | <TabAtkins> | Chill for a sec, you're jumping way ahead. |
| 17:28 | <Hixie> | we have zillions of primitives. Why are some "magic" and some "not"? |
| 17:29 | <Hixie> | i just don't get it |
| 17:29 | <Hixie> | it seems completely arbitary |
| 17:29 | <TabAtkins> | All primitives are magic, that's the point. The two words are synomyms for this purpose. |
| 17:29 | <Hixie> | ok. Then magic is good? |
| 17:29 | <Hixie> | i think abstractions are good. they make platforms simpler to use. |
| 17:29 | <TabAtkins> | No. Small magic is good. Orthogonal magic is good. Giant chunks of interrelated magic that solves a narrow use-case is bad. |
| 17:29 | <Hixie> | ok |
| 17:29 | <Hixie> | then what's the problem? |
| 17:30 | <TabAtkins> | At least, those giant chunks are bad *when they're irreducible*. |
| 17:30 | <Hixie> | dialog is hardly narrow. |
| 17:30 | <TabAtkins> | The things that dialog can do are useful elsewhere. |
| 17:30 | <Hixie> | like where? if there's a use case, then we can support them. |
| 17:30 | <TabAtkins> | We've learned *so many times* that when you design an irreducible system, you can only design in so much flexibility. |
| 17:31 | <TabAtkins> | As soon as an author needs to stretch it a little bit further than what you've designed in, they're screwed, and have to rebuild the entire thing from the ground up. |
| 17:31 | <Hixie> | we've learnt *so many times* that when you design without strictly looking at use cases, you get horribly unusable platforms |
| 17:31 | <TabAtkins> | The smaller the primitives are, the more reducible to base concepts everything is, the less levels you have to move down. |
| 17:31 | <TabAtkins> | Yes, these two facts are not in conflict. |
| 17:31 | <Hixie> | the smaller the primtives are, the harder it is to implement anything, and the less likely any specific use case is to be well supported. |
| 17:32 | <TabAtkins> | Which is why you find good use-cases, figure out how to solve them, then carve up the solution into separable pieces. |
| 17:32 | <Hixie> | ok |
| 17:32 | <Hixie> | that's what we did here |
| 17:32 | <Hixie> | at least, what we did once i dropped inert |
| 17:32 | <Hixie> | before that we had done it, then had inert hanging on the side for no good reason |
| 17:32 | <TabAtkins> | No, you're still left with <dialog> as the smallest piece. |
| 17:32 | <Hixie> | right |
| 17:32 | <TabAtkins> | Which is a pretty fucking big piece. |
| 17:33 | <Hixie> | we "find good use-cases, figure out how to solve them, then carve up the solution into separable pieces" |
| 17:33 | <TabAtkins> | You're stuck on step 2 - <dialog> is a good solution to a common use-case. |
| 17:33 | <Hixie> | and we end up with <dialog>, <form method=dialog>, the top layer, focus, etc. |
| 17:33 | <Hixie> | what concretely do you think should be done here? |
| 17:33 | <TabAtkins> | You haven't carved it up sufficiently yet. Too much of the ability is still tied to the tagname. |
| 17:34 | <Hixie> | how do i know when it's carved up sufficiently? |
| 17:35 | <Hixie> | i think i've finally figured out why i dislike this "explain it" approach rather than the "use case" approach. The "explain it" approach feels like too much has to be done on faith. It isn't an actionable design strategy. With the use case approach, I collect the use cases, then I design, and I know I'm done when all the use cases are handled. |
| 17:35 | <TabAtkins> | It's hard to tell, but a good rule of thumb is when someone can, without heroic efforts, create something equivalent while using a <div>. |
| 17:35 | <Hixie> | so "if" isn't sufficiently carved up because you can't build it with a <div>? |
| 17:35 | <TabAtkins> | Dude, really? |
| 17:35 | <TabAtkins> | I'm clearly talking about HTML here. |
| 17:35 | <Hixie> | well then give me an actionable answer! |
| 17:35 | <Hixie> | not a language-specific one |
| 17:36 | <TabAtkins> | I gave you a rule-of-thumb. |
| 17:36 | <Hixie> | it sucks |
| 17:36 | <Hixie> | you can't do lang="" with <div> either |
| 17:36 | <Hixie> | is lang="" not sufficiently carved up? |
| 17:36 | <TabAtkins> | Sigh. |
| 17:36 | <Hixie> | right now i have a design philosophy that's easy to follow and works in all spaces. |
| 17:36 | <TabAtkins> | Let me be more specific. My rule-of-thumb is talking about *HTML elements*. |
| 17:36 | <Hixie> | this "explain" thing doesn't. |
| 17:36 | <TabAtkins> | It doesn't work ina ll spaces, is the thing. |
| 17:37 | <Hixie> | so unless you have a way to define this "Explain" thing in generic terms that works for any language, i'm gonna stick with use cases. |
| 17:37 | <TabAtkins> | It works well sometimes, when your answer happens to land on something small and factorable. It fails badly when your answer ends up being something large. |
| 17:37 | <Hixie> | what's the failure with <dialog>? |
| 17:37 | <TabAtkins> | Like AppCache, which works fine for the cases it was designed for, but can't be used outside of those, without severe distortion. |
| 17:38 | <Hixie> | yep, appcache is a good example of how you have to collect use cases. but "explain it" with the exact same use cases wouldn't have done any better. |
| 17:38 | <TabAtkins> | We haven't hit an obvious failure yet, but <dialog> is a bundle of seperable powers. The moment someone is designing something and could use one of those powers, but doesn't need or want the rest of the <dialog> suite, that's a failure. |
| 17:38 | <sicking> | TabAtkins: fwiw, inert wasn't really the primitive that really let you build <dialog>. Since <dialog> made the parent chain of the <dialog> element inert too. It also seems like inert was a bit of a magical thing on its own |
| 17:38 | <TabAtkins> | Hixie: "Explain it" is what's driving Service Worker. |
| 17:38 | <TabAtkins> | sicking: Sure, not disputing that. |
| 17:38 | <Hixie> | TabAtkins: yeah, how well is that going again? |
| 17:39 | <TabAtkins> | Hixie: Well? |
| 17:39 | <Hixie> | where's the spec? |
| 17:39 | <TabAtkins> | Over in github? |
| 17:39 | <Hixie> | what other vendors are on board? |
| 17:39 | <Hixie> | TabAtkins: (and actually, service worker isn't just based on "explain it", it's based on additional use cases too.) |
| 17:40 | <TabAtkins> | Um, of course it's based on use-cases. The point is that it's attempting to address those use-cases by designing smaller interlocking pieces, so that when someone has a *new* use-case, it's likely they can repurpose one of the existing pieces. |
| 17:40 | <TabAtkins> | Rather than having to reinvent everything themselves. |
| 17:41 | <Hixie> | there's no more chance that it'll fit new use cases than appcache will. |
| 17:41 | <Hixie> | appcache fits some new use cases fine. |
| 17:41 | <Hixie> | and others it fails utterly. |
| 17:41 | <TabAtkins> | That's an interesting hypothesis you have, but one that I'm very confident will be wrong. |
| 17:42 | <Hixie> | the "explain it" approach is basically "i'm going to make something that fits those use cases and happens to fit my preferred aesthetic for language design" |
| 17:42 | <TabAtkins> | "Big" solutions fail, because they're inflexible. "Small" solutions suck, because they're too fiddly to work with. You have to hit somewhere in the middle, and you have an unfortunate tendency to swerve toward the "big" side of things, and then not understand anyone's arguments for shrinking them down a bit. |
| 17:43 | <Hixie> | (there's not really any core primitives in service workers, btw, as far as i can tell. It's just as much a "Big" solution. It just happens to be a different one, one similar to something I suggest we extend appcache to do.) |
| 17:43 | <Hixie> | "big" is another word for "simple" in this context |
| 17:43 | <Hixie> | to which i say: guilty as charged :-) |
| 17:44 | <Hixie> | it's not "unfortuate", it's "the whole point" |
| 17:44 | <TabAtkins> | Simple for the things it was designed to do, yes. And as soon as you step outside the circle that it's carved out, there's nothing underneath you. You have to rebuild from a very low level. |
| 17:44 | <Hixie> | yeah... that's just nonsense. |
| 17:44 | <TabAtkins> | The ideal thing exists in layers, with small primitives at the bottom, larger things built out of those, and still larger things built out of *those*. |
| 17:45 | <Hixie> | you're describing <dialog> here. |
| 17:45 | <TabAtkins> | That way, if something isn't doing it for you, you can just skip one layer down and build back up. |
| 17:45 | <Hixie> | but you're not describing service workers. |
| 17:45 | <TabAtkins> | No, dialog is "give your tag a particular name, and it gains this suite of interconnected powers". |
| 17:45 | <TabAtkins> | That's a high-level object. |
| 17:45 | <Hixie> | <dialog> is layered on a focus model, a rendering model, a form submission model. |
| 17:45 | <Hixie> | what is service workers layered on? |
| 17:45 | <TabAtkins> | We're getting somewhere! |
| 17:46 | <Hixie> | i've been here the whole time dude |
| 17:46 | <TabAtkins> | All of those models exist in specs, and can't be easily interacted with by authors. The hooks that <dialog> gets for interacting with them *are the types of things I'm talking about when I say "magic"*. |
| 17:47 | <Hixie> | if authors ever need to interact with them, then we can provide targetted small APIs to deal with those use cases. |
| 17:47 | <Hixie> | we don't randomly go about adding APIs that make the platform harder to extend, harder to implement, harder to refactor, etc, just in case |
| 17:47 | <Hixie> | that's irresponsible platform design |
| 17:47 | <TabAtkins> | The problem is that I know you're going to be resistant to adding those, because you'll point to <dialog> and say it can already be done. |
| 17:47 | <Hixie> | i am offended |
| 17:48 | <Hixie> | given a use case, i am trivial to convince |
| 17:48 | <TabAtkins> | And when you do propose some API, it wont' be something that'll work with <dialog> - you wont' be able to tweak <dialog>'s own interaction. |
| 17:48 | <Hixie> | what i resist, is adding unnecessary cruft |
| 17:48 | <Hixie> | what _are_ you talking about |
| 17:48 | <Hixie> | there's lots of APIs in HTML that tweak existing features. |
| 17:48 | <Hixie> | look at the forms API extensions! |
| 17:48 | <TabAtkins> | I'd be super happy to be convinced otherwise, but you've pushed against things like this for years. :/ |
| 17:48 | <Hixie> | pushing against things is a spec writer's job |
| 17:49 | <Hixie> | if as a spec writer you don't push against things, you just end up with a messy spec with zillions of messy interconnected features. |
| 17:49 | <TabAtkins> | I'm aware of this. |
| 17:49 | <Hixie> | then why ":/" instead of ":-)" ? |
| 17:50 | <TabAtkins> | As much as I'm casting you into an unfair light, you're casting me in one too, implying that I just want to put a bunch of useless/messy stuff into a spec. |
| 17:50 | <Hixie> | i'm just arguing against what you're saying, not what you're doing |
| 17:51 | <TabAtkins> | Maybe me too? |
| 17:51 | <Hixie> | no, you're calling out things i've done by name. |
| 17:51 | <Hixie> | "you've pushed against things like this for years" |
| 17:51 | <Hixie> | "you'll point to <dialog> and say it can already be done" |
| 17:51 | <Hixie> | "you wont' be able to tweak <dialog>'s own interaction" |
| 17:51 | <Hixie> | "dialog is ..." |
| 17:51 | <TabAtkins> | You have done that. You continue to claim that <dialog> is a reasonable primitive. |
| 17:52 | <Hixie> | "there's nothing underneath you" |
| 17:52 | <TabAtkins> | That one wasn't addressing you. |
| 17:52 | <TabAtkins> | It was the generic "you". |
| 17:53 | <Hixie> | it was in the context of me saying i designed simple APIs, and you said "Simple for the things it was designed to do, yes. And as soon as you step outside the circle that it's carved out, there's nothing underneath you" (yes, the "you" is not me, it's the user of my APIs) |
| 17:53 | <TabAtkins> | Yes. |
| 17:53 | <Hixie> | (but saying there's nothing under my APIs for my users to fall back to seems like a specific statement of my actions, not my words) |
| 17:54 | <Hixie> | in what sense is <dialog> _not_ a reasonable primitive? My argument is "here are the use cases: [...]. <dialog> handles the use cases." Your argument is "<dialog> isn't <div>". |
| 17:54 | <TabAtkins> | More precisely, "<dialog> isn't <div>+ some CSS/JS abilities, wrapped up in a convenient package". |
| 17:55 | <TabAtkins> | <dialog> has magical positioning rules that only it gets to use, by virtue of having a particular tagname. |
| 17:55 | <TabAtkins> | <dialog> has magical form interaction that only it gets to use, by virtue of ahving a particular tagname. |
| 17:55 | <TabAtkins> | Focus interaction, etc. |
| 17:55 | <Hixie> | my point is that i don't understand what design philosophy is leading to age". |
| 17:55 | <Hixie> | uh |
| 17:56 | <Hixie> | my point is that i don't understand what design philosophy is leading to "<dialog> isn't <div>+ some CSS/JS abilities, wrapped up in a convenient package" being even considered a target. |
| 17:56 | <TabAtkins> | I just pointed it out. |
| 17:56 | <TabAtkins> | If I want to make an element that gets positioned in a way similar to <dialog>, but I dont' want the rest of <dialog>'s stuff, I can't do it. |
| 17:56 | <Hixie> | "<dialog> has magical positioning rules that only it gets to use, by virtue of having a particular tagname" is a statement of fact, but it doesn't have any explanation as to why that is bad. |
| 17:56 | <TabAtkins> | Same with form interaction, focus interaction, etc. |
| 17:56 | <Hixie> | why would you _want_ to do that? |
| 17:57 | <Hixie> | you can't make <em> out of <div> either, so what? |
| 17:57 | <TabAtkins> | Because we've never designed a positioning scheme in the past that hasn't been used for a remarkable variety of crazy things we never anticipated, and I don't expect <dialog>'s positioning rules to be any different. |
| 17:57 | <Hixie> | you mean the alignment scheme? |
| 17:57 | <TabAtkins> | Flip it around - why do *you* think that no one will ever design anything that wants to be positioned like <dialog> is? |
| 17:58 | <Hixie> | the alignment scheme is specifically designed to be reusable. I'm just waiting for hte CSSWG to take it over. There's even a note in the spec about it. |
| 17:58 | <Hixie> | i don't think "no one will ever design anything that wants to be positioned like <dialog> is". That's why I made the scheme reusable. |
| 17:59 | <TabAtkins> | I distinctly recall bug conversations in which you found it acceptable for the CSS positioning algorithms to have a branch where they ask if the thing being positioned is a <dialog>. |
| 17:59 | <Hixie> | i have a theory as to the difference in our approaches. I design things so that they have lots of extension points, but I don't expose them until they are needed. You think every extension point should be exposed immediately. Is that right? |
| 18:00 | <Hixie> | i'm not really sure what precise positioning logic you mean. There's at least three separate things going on with <dialog> and positioning/CSS. |
| 18:00 | <Hixie> | if you mean 'align-point', it's designed to be reusable. If you mean the top layer, it's designed to be reusable. The rest is mostly just glue. |
| 18:01 | <Hixie> | sorry, 'anchor-point', not 'align-point'. |
| 18:01 | <TabAtkins> | Not necessarily immediately, but definitely way sooner than you do. Standards are slow enough that by the time you notice, address, and implement something that's "needed", it's already several years after the point someone first needed it. |
| 18:01 | <Hixie> | How do you know what to expose? |
| 18:02 | <TabAtkins> | Historical supposition, mostly. And when you don't know, you seek out preliminary data and carve things up as soon as you've got a good enough idea. |
| 18:02 | <Hixie> | <dialog> has dozens of potential extension points, by design. Which should I expose, and more importantly, for each one, why that one and not another? |
| 18:02 | <TabAtkins> | I can't list those off the top of my head right now. ^_^ |
| 18:02 | <Hixie> | i can. and i have already exposed those i think make sense, and for the rest, i'm waiting for author experience with <dialog>. |
| 18:03 | <Hixie> | just like with appcache, once it was shipped, i started designing alternatives (though alex took over, so i didn't bother going on my own path with it) |
| 18:03 | <TabAtkins> | But the couple of CSS bits are definitely one. I recall you having to be convinced about them being separable things, rather than <dialog>-specific things. |
| 18:03 | <Hixie> | s/alternatives/extensions/ |
| 18:03 | <Hixie> | you recall incorrectly. |
| 18:03 | <Hixie> | anchor-point and the top layer were both extensible from the start. |
| 18:04 | <Hixie> | s/designing/exposing/, i guess would be a better change. |
| 18:04 | <TabAtkins> | It's possible I misinterpreted the conversations, or that you had a more subtle point in the arguments than I could tell. |
| 18:04 | <Hixie> | (though i have to say, service workers really doesn't strike me as something that exposes extensions at all. It seems like exactly like everything you're arguing against.) |
| 18:05 | <Hixie> | i wonder if it's just that i'm not vocal about the extension points i design into my systems, so you somehow _think_ that they're designed in a hermetically inseparable way, rather than seeing them as groups of separable solutions. |
| 18:05 | <Hixie> | in which case, you really should just give me more credit. I _have_ been doing this for like 15 years now. |
| 18:05 | <TabAtkins> | Well, if you don't tell us anything, how are we supposed to know? |
| 18:05 | <Hixie> | read the spec? :-) |
| 18:06 | <TabAtkins> | And length of experience is hardly an argument for good design, as I'm sure you know. ^_^ |
| 18:06 | <Hixie> | i'm not saying my length of experience is an argument for good design, just that it's an argument for not assuming bad design, and checking first instead. :-) |
| 18:08 | <TabAtkins> | I'm just asking for the same courtesty - I and some others on our team have been designing APIs for many years as well, and have a good intuition for when something is going to be useful as a separable ability, even if we don't have convincingly articulated use-cases yet. |
| 18:09 | <Hixie> | you're not "just asking" for that. You're asking for changes to specific things in the HTML spec. This all started from "Ugh, dropping a piece of <dialog> functionality is bad". |
| 18:09 | <Hixie> | I haven't said anything one way or the other about anything you've designed. |
| 18:10 | <Hixie> | because I _do_ extend you that courtesy. |
| 18:10 | <TabAtkins> | My reaction was that I know inertness is a usefully seperable ability, and "inert" was a way to get that. It might not be a very *good* way to separate it, and that's fine, but having *some* way to do it is useful. |
| 18:11 | <TabAtkins> | And your reaction that there isn't a need for it is why I pushed back. |
| 18:11 | <Hixie> | you could definitely convey that in a more productive fashion than "ugh" and "trust me, I have been designing APIs for many years, and have a good intuition for when something is going to be useful as a separable ability" |
| 18:12 | <Hixie> | lots of people say "trust me, i need this". And the way that I know who to trust, is that I trust the ones who can articulate a convincing use case. |
| 18:12 | <TabAtkins> | Sorry that I made an off-the-cuff comment, and a statement that mirrored your own justification of your design skills. ^_^ |
| 18:13 | <Hixie> | apology accepted :-) |
| 18:13 | <TabAtkins> | Nope, retracted now. |
| 18:14 | <Hixie> | now, since i _do_ trust your judgement, maybe you can help me with something I was going to ask sicking (but looks like we scared him off). Do you think, on mobile, we should make all <dialog>s full-screen, or just modal ones? |
| 18:15 | <TabAtkins> | Good question, and I'm not quite sure. |
| 18:15 | <TabAtkins> | I'd probably want to think about some specific examples of <dialog>s in a mobile environment. |
| 18:16 | <TabAtkins> | And how ones designed only for the desktop worked. |
| 18:16 | <Hixie> | the only native non-modal dialog i can think of in a mobile environment would be a speedometer app i have that overlays a window on top of other apps |
| 18:16 | <TabAtkins> | Actually, it might come down to how the positioning model works with the virtual viewport. |
| 18:18 | <jgraham> | Don't <select>s work kinda like non-fullsceen dialogs on mobile? |
| 18:18 | <Hixie> | does @media max-width give you the width of the fake viewport, on mobile? or of the device? |
| 18:18 | <Hixie> | the fake viewport, right? |
| 18:19 | <TabAtkins> | Which one are you calling fake? |
| 18:19 | <TabAtkins> | It gives you the viewport that the page lays out in. |
| 18:19 | <Hixie> | right |
| 18:19 | <TabAtkins> | The device-* queries are based on the screen. |
| 18:20 | <Hixie> | the "real" viewport is the one that is physically visible |
| 18:20 | <Hixie> | the one that changes during pinch-zoom |
| 18:20 | <wilhelm> | Fake, in that case. |
| 18:20 | <Hixie> | k |
| 18:20 | <Hixie> | thanks |
| 18:22 | <TabAtkins> | jgraham's argument is somewhat convincing - <dialog> *is* something like the <select> popup. |
| 18:22 | <TabAtkins> | On the other hand, we dont' know how to interact with it, unlike <select> with its very restricted content model. |
| 18:22 | <Hixie> | ok. filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=24991 on this, if anyone has any opinions. |
| 18:23 | <TabAtkins> | And making it full-screen means you can't use non-modal <dialog> for small, less-important things. |
| 18:23 | <TabAtkins> | So, since non-model dialogs can be relatively unimportant on desktop, we should allow them the same ability on mobile, and not fullscreen them. |
| 18:24 | <Hixie> | agreed |
| 19:35 | <esprehn> | Hixie: I ran into an issue of needing a toplayer API just this weekend. I want to show an info bar at the top of the screen outside the <dialog>, but the ::backdrop is always on top and <dialog> is positioned absolute so I can't get out without negative positioning which is awful. I need to be able to do document.toplayer.add(infobar) just like <dialog> does |
| 19:35 | <esprehn> | internally |
| 19:35 | <Hixie> | why isn't position:absolute inside the dialog enough? |
| 19:36 | <esprehn> | because the dialog is also position: absolute, so my position is relative to it |
| 19:36 | <Hixie> | position:fixed? |
| 19:36 | <esprehn> | I don't want fixed, it shouldn't scroll with the page |
| 19:36 | <Hixie> | oh you want it at the top of the page, no the screen? |
| 19:36 | <Hixie> | interesting |
| 19:36 | <esprehn> | yes |
| 19:36 | <esprehn> | Gmail does this, the little yellow bar with info. |
| 19:37 | <Hixie> | that goes under dialogs though doesn't it? |
| 19:37 | <esprehn> | not if the infobar is related to the dialog |
| 19:37 | <Hixie> | i thought the infobars related to the dialogs went inside the dialogs |
| 19:37 | <esprehn> | that's a design choice |
| 19:37 | <esprehn> | I should be able to put it at the top of the screen |
| 19:37 | <esprehn> | (document really) |
| 19:38 | <Hixie> | kinda weird design choice, but granted. |
| 19:38 | <Hixie> | file a bug on anne i guess |
| 19:38 | <esprehn> | :) |
| 19:39 | <Hixie> | (what i think would be the way to fix this would be to add a way in css to position:absolute but set the containing block to something else than the default) |
| 19:40 | <Hixie> | (that way you could put the butter bar info inside the dialog in question, but have it positioned properly) |
| 19:41 | <Hixie> | (so maybe file a bug on the CSS side rather than on the top layer) |
| 19:42 | <Domenic_> | +1 to that idea Hixie! |
| 19:53 | <TabAtkins> | Been on my radar for a while too - plan to do something about that in Positioning. |
| 20:26 | <esprehn> | That's not something we can easily do |
| 20:26 | <esprehn> | the containing block is the thing that handles your layout, we can't have you be in one place and do layout with another without a bunch of system changes |
| 20:27 | <esprehn> | it's much simpler to just add toplayer.add() which both explains <dialog> and gives you the same power as other platforms (ex. android lets you put whatever you want on top) |
| 20:28 | <esprehn> | (we can do the positioning thing someday perhaps too) |
| 20:29 | <Hixie> | author needs really have to come ahead of implementor needs :-) |
| 20:30 | <Hixie> | if we designed features around what would be easy to implement, authors would have a heck of a time using them |
| 20:30 | <Hixie> | the problem here isn't that you can't put things on top -- you can. If it's in the dialog, it's on top. |
| 20:30 | <Hixie> | it's that you can't position it. |
| 20:30 | <Hixie> | I'm sure Android lets you position things too :-) |
| 20:31 | <Hixie> | after all, how do we explain positioning if you can't set the containing block? |
| 21:45 | <zewt> | aaaand now google has made search results completely unreadable |
| 21:45 | <zewt> | it's pretty neat how google can single-handedly make the internet worse at a whim, and there's nothing anyone can do about it |
| 21:46 | <TabAtkins> | zewt: What's wrong with them today? |
| 21:48 | <esprehn> | Hixie: Breaking a fundamental invariant in layout that the thing that sizes you and the thing you're positioned relative to are the same is different than explaining what already happens |
| 21:48 | <esprehn> | We probably should have an onlayout and expose setRect() / setClip() etc. so you can implement a layout algorithm yourself |
| 21:48 | <TabAtkins> | +1 to something like that. |
| 21:49 | <esprehn> | and in terms of the author, I the author, want a single global info bar that's always on top. It shouldn't be inside the <dialog>. |
| 21:49 | <TabAtkins> | I think we need to (1) expose a simple constraint-based layout engine to CSS, and (2) expose some more fundamental layout/painting primitives to JS directly. (1) will let you do a lot of customized layouts on your own pretty easily, and (2) is the escape hatch for when everything else fails. |
| 21:49 | <esprehn> | eah |
| 21:49 | <esprehn> | yeah |
| 21:50 | <zewt> | https://zewt.org/~glenn/ugly%20google.png |
| 21:51 | <zewt> | removed the underlining from the link in each result, so now it's a floaty, undelimited mess |
| 21:51 | <esprehn> | I'm not sure it would be too difficult to expose such a layout hook, we have to figure out how it interacts with the existing layout though since you have a cycle (script wants layout info, and layout algorithm wants script's layout rects) |
| 21:51 | <esprehn> | the CSS algorithms are designed to avoid the cycle, but they hooking your stuff that way would mean running script inside our C++ layout logic :/ |
| 22:02 | <TabAtkins> | zewt: The link is the big blue text. I'm not sure how that's unreadable. |
| 22:02 | <TabAtkins> | There's no other text that big or that blue. |
| 22:02 | <TabAtkins> | Also: first text below each gap. |
| 22:03 | <TabAtkins> | esprehn: Android addresses this - it gives you stale data during the before-paint callback. |
| 22:04 | <zewt> | i know, but that isn't a delimiter to my mental parser |
| 22:04 | <esprehn> | TabAtkins: interesting. The problem there is we don't definite when layout (or how much of it) we really do. So different browsers would give different stale results |
| 22:04 | <TabAtkins> | esprehn: Yeah, it'd require more parsing. |
| 22:04 | <TabAtkins> | I mean, more speccing. |
| 22:05 | <zewt> | exposing when layout happens sounds ... hairy |
| 22:06 | <zewt> | (but then I'm not that familiar with that part of the platform) |
| 22:06 | <TabAtkins> | It is somewhat hairy, but not intractable. |
| 22:06 | <TabAtkins> | And required, in the end, if we want to give authors real ability to design their own layout systems. |
| 22:06 | <TabAtkins> | Fun part is exposing it in a way that doesn't harm efforts to do parallel layout. |
| 22:07 | <Hixie> | esprehn: i wasn't suggesting uncoupling the sizing and positioned-relative-to aspects |
| 22:07 | <TabAtkins> | Yeah, literally breaking the element out of its container to attach it to something else, in the layout tree, is more tractable. |
| 22:07 | <zewt> | someone jog my memory--what's the entry point to get the currently-selected radio box (without iterating over inputs by hand) |
| 22:07 | <Hixie> | esprehn: i was suggesting just changing the containing block to something other than the weird one you're forced to have via 'position' |
| 22:08 | <esprehn> | ah okay, that seems reasonable |
| 22:15 | <zewt> | (am I imagining that that existed) |
| 22:15 | <Hixie> | wtf is the origin of a blob: url? |
| 22:16 | <Hixie> | the spec says "This scheme should have an origin policy and a lifetime stipulation, to allow safe access to binary data from web applications" but I can't find anywhere where they actually define it?? |
