| 00:00 | <esprehn> | Hixie: it doesn't seem we can convince each other |
| 00:01 | <Hixie> | esprehn: i'm open to suggestions (though again, in future, please send them when i ask for feedback, not after i've done all the work), but so far i haven't any idea what you're suggesting. |
| 00:01 | <Hixie> | esprehn: i'm not trying to convince you, i'm trying to understand what you are proposing. |
| 00:02 | <esprehn> | I'm proposing that you explain what <dialog> does in terms of APIs script can use |
| 00:02 | <Hixie> | i have no idea what that means. |
| 00:02 | <Hixie> | you want _more_ APIs? in your blink e-mail you were saying there were too many (so i didn't end up including them). |
| 00:03 | <Hixie> | why can't scripts use <dialog>? |
| 00:03 | <Hixie> | what is it that your scripts want to do? like, what are your concrete use cases? |
| 00:03 | <Hixie> | please file a bug with the answers to these questiosn so that i can track it: http://whatwg.org/newbug |
| 00:05 | <esprehn> | I don't understand how to explain this more clearly |
| 00:06 | <Hixie> | well, let's start with: why can't scripts use <dialog>? |
| 00:08 | <esprehn> | Because they want to use <jquery-dialog>, and they want the top layer behavior but not the focus behavior (or the opposite) |
| 00:09 | <Hixie> | i think i need a concrete use case to understand what you're proposing |
| 00:09 | <Hixie> | what does <jquery-dialog> do, exactly? |
| 00:10 | <Hixie> | do you have a sample page i could look at that shows the kind of behaviour you want that isn't possible with <dialog>? |
| 00:10 | <Hixie> | (and for which <dialog> is relevant, obviously ;-) ) |
| 00:10 | <esprehn> | this isn't a matter of what is/isn't possible with dialog |
| 00:11 | <esprehn> | if you keep adding features to dialog you can make everything possible |
| 00:11 | <Hixie> | right, then problem solved |
| 00:11 | <Hixie> | isn't that what you wanted? an api to do something? |
| 00:11 | <esprehn> | no, because we want the system to be build on small parts you can put together, not big parts full of lots of APIs and features |
| 00:12 | <Hixie> | but you literally just said you wanted a new api |
| 00:12 | <Hixie> | <dialog> is a "small part you can put together". |
| 00:12 | <Hixie> | that's the whole point of <dialog> |
| 00:12 | <Hixie> | to be the simplest thing we can provide that lets you do accessible dialogs |
| 00:13 | <esprehn> | Dialog.prototype.show = () { document.toplayer.add(this); document.documentElement.inert = true; this.inert = false; } |
| 00:13 | <esprehn> | you should be able to explain what's going on that way |
| 00:13 | <Hixie> | we do (though we use english instead of pseudocode) |
| 00:13 | <esprehn> | that's not pseudo code, we want a toplayer API, and an inert API |
| 00:14 | <Hixie> | ??? |
| 00:14 | <Hixie> | wait, what? |
| 00:14 | <Hixie> | how is that simpler |
| 00:14 | <esprehn> | yes, full screen and dialog use some magic system to put themselves on top |
| 00:14 | <esprehn> | it's top layer, and we should just let you use it |
| 00:14 | <Hixie> | it's not magic, it's carefully designed |
| 00:14 | <esprehn> | that's the core of the extensible web platform |
| 00:15 | <Hixie> | i think that's actively the opposite of what we should be aiming for. |
| 00:15 | <Hixie> | we should provide primitives that let you create web apps |
| 00:15 | <Hixie> | not primitives that let you create web app platforms |
| 00:16 | <Hixie> | we _are_ a platform |
| 00:17 | <esprehn> | right, so you disagree with the extensible web concept |
| 00:17 | <Hixie> | i'm not sure what "the extensible web concept" is |
| 00:17 | <Hixie> | the web is hugely extensible already |
| 00:17 | <Hixie> | i mean, it's the world's most successful platform |
| 00:17 | <esprehn> | you just said "i think that's actively the opposite of what we should be aiming for." |
| 00:18 | <Hixie> | i think that having a dialog box should be as simple as just saying you want a dialog box, yes. i don't think everyone should need to say "and i want my dialog on the top layer, and i want it to be focusable, and i want it to be accessible", etc. |
| 00:19 | <Hixie> | obviously if there are concrete use cases for which we need other primitives, like the top layer, then we should study them and provide for them. |
| 00:19 | <Hixie> | but we shouldn't just provide everything willy nilly; there's a huge cost to every feature and doign that harms both authors and users. |
| 00:19 | <Hixie> | authors because it makes everything way more complicated than necessary |
| 00:19 | <Hixie> | and users because if the platform is complicated, apps in the platform will be more buggy. |
| 00:19 | <esprehn> | That's fine, but you should be able to explain the dialog bits in terms of small APIs that a widget can cobble together without using <dialog> |
| 00:19 | <Hixie> | just look at dialogs now, everyone does it there own way and it's all different and buggy. |
| 00:19 | <Hixie> | their |
| 00:20 | <Hixie> | why? |
| 00:20 | <Hixie> | i don't understand why "you should be able to explain the dialog bits in terms of small APIs that a widget can cobble together without using <dialog>" |
| 00:20 | <Hixie> | should we be able to explain CSS 'color' and 'margin-top' and form submission and so on in the same way? |
| 00:20 | <esprehn> | yes, we plan to propose a form submission API |
| 00:20 | <esprehn> | color and margin are sort of build on <canvas>, but there's more work to explain that |
| 00:20 | <Hixie> | should we "explain 'http'"? |
| 00:21 | <Hixie> | and explain page navigation? |
| 00:21 | <Hixie> | and CSP? |
| 00:21 | <Hixie> | and iframs? |
| 00:21 | <Hixie> | iframes |
| 00:21 | <Hixie> | and mouse events? |
| 00:21 | <esprehn> | slightlyoff plans to explain iframes too |
| 00:21 | <Hixie> | i don't even know what explaining half these things would mean |
| 00:21 | <esprehn> | yes, there's a lot of work to do |
| 00:21 | <Hixie> | we already have a form submission API |
| 00:21 | <Hixie> | we have two, even |
| 00:22 | <Hixie> | this is all make-work. it doesn't actually improve the platform at all. |
| 00:22 | <Hixie> | it just makes it more complicated and harder to optimise. |
| 00:22 | <esprehn> | sure it does, it means <polymer-input> can add fields to the enclosing <form> |
| 00:22 | <Hixie> | (and more complicated means it's harder to write web apps, and that means more buggy web apps) |
| 00:22 | <esprehn> | it means <tizen-dialog> can be in the top layer, but have totally different focusing behavior |
| 00:22 | <Hixie> | esprehn: but how do you explain <form>? |
| 00:22 | <Hixie> | "totally different focusing behavior" is a bug! |
| 00:23 | <Hixie> | the whole point of <dialog> is to _not_ have "totally different focusing behavior" |
| 00:23 | <esprehn> | it's not though, why should a web app suck on Android because the focusing behavior doesn't follow the native one? |
| 00:23 | <Hixie> | it _should_ follow the native one |
| 00:23 | <Hixie> | automatically |
| 00:23 | <Hixie> | it should also follow the iOS 9.1 focus model that the web author doesn't know about |
| 00:23 | <Hixie> | and the Windows 2103 focus model |
| 00:24 | <Hixie> | and the author shouldn't have to write one line of code for that to just work |
| 00:24 | <Hixie> | that's what <dialog> does |
| 00:24 | <Hixie> | and <input> |
| 00:24 | <Hixie> | and the rest of HTML |
| 00:25 | <esprehn> | you're at odds with the extensible web idea, that you should be able to build up complex widgets from building blocks and explain how the existing widgets work |
| 00:28 | <Hixie> | esprehn: i'm all for being able to build up complex widgets from building blocks, and my job is to explain how the existing widgets work. |
| 00:28 | <Hixie> | esprehn: those both seem orthogonal to the issue at hand, though. |
| 00:28 | <esprehn> | You seem to be arguing "why have contenteditable at all, just add a richtext attribute to <textarea> and <input>" |
| 00:29 | <esprehn> | "keep expanding the API on <textarea> until it fits all the use cases" |
| 00:30 | <Hixie> | i've argued that many times, yes. i think it's supported by how wacked contenteditable is. |
| 00:31 | <Hixie> | contenteditable doesn't fit HTML very well at all, and it's universally hated. |
| 00:31 | <Hixie> | but even contenteditable doesn't "explain the platform" |
| 00:31 | <esprehn> | sure, so add a sensible editing API with text measurement |
| 00:32 | <esprehn> | and caret positions and such, and then let <textarea> use it |
| 00:32 | <othermaciej> | you need something for the use case of "edit some rich text with a starting point of arbitrary html, then output html as your final product" |
| 00:32 | <othermaciej> | there are cases of rich text editing which are not that, but a comprehensive solution needs to hit that case |
| 00:33 | <Hixie> | esprehn: i'm all for a better API than contenteditable, but I don't see how it helps. How do you explain the caret? it just becomes magic behind yet another API. |
| 00:33 | <Hixie> | esprehn: at the end of the day, there's always some platform feature. |
| 00:33 | <Hixie> | esprehn: how do you determine which is the "most explained" feature? |
| 00:34 | <Hixie> | esprehn: and how do you know which features to expose in this editing API? |
| 00:35 | <Hixie> | esprehn: it always comes back to concrete use cases, and APIs that address those use cases. |
| 00:35 | SamB | wonders who he should report firefox's treatment of "Refresh: " HTTP headers to: a working group (which?), or bugzilla.mozilla.org ... |
| 00:35 | <esprehn> | Hixie: all the features necessary to build what contenteditable and <textarea> do today |
| 00:35 | <Hixie> | esprehn: <textarea> and contenteditable today already exist, so no new features are needed. |
| 00:35 | <esprehn> | that's where we disagree |
| 00:36 | <Hixie> | you literally just said you just wanted the features necessary to build what they do. we can already do that, since they exist. |
| 00:36 | <Hixie> | "<textarea></textarea>" is an implementation of textarea. |
| 00:36 | <esprehn> | huh? |
| 00:36 | <SamB> | what was the problem with contenteditable? why not ... fix the problem? |
| 00:36 | <SamB> | or did you want some kind of XBL successor |
| 00:36 | <esprehn> | Hixie: that doesn't follow |
| 00:37 | <Hixie> | esprehn: i don't understand what you mean by "all the features necessary to build what contenteditable and <textarea> do today" then |
| 00:37 | <SamB> | Hixie: he wants to NIH it for some reason |
| 00:37 | <esprehn> | What if we wanted to ship a browser without <textarea>, that downloaded the implementation on first usage? |
| 00:37 | <Hixie> | SamB: that seems unlikely, esprehn is not prone to such thinking |
| 00:37 | <SamB> | I don't know why he's not happy to use browser-specific extensions in his browser-specific implementation of textarea |
| 00:38 | <esprehn> | This isn't about NIH :) |
| 00:38 | <Hixie> | esprehn: that seems highly hypothetical, i don't know how to apply reasoning to such a situation. |
| 00:38 | <othermaciej> | to the extent I understand the "explain" idea, it seems to be about "what if I wanted to do something almost like this, but different enough that I can't use the built-in extensibility hooks - are there primitives I could use to build it?" |
| 00:38 | <esprehn> | Hixie: how would you implement <textarea> in script as a library |
| 00:38 | <othermaciej> | of course at some point you always come down to a primitive that's not explainable |
| 00:38 | <SamB> | yeah, "what if I want something that acts *almost* like <textarea>" is a much more interesting question |
| 00:39 | <othermaciej> | in terms of something else |
| 00:39 | <Hixie> | othermaciej: the only way to make progress on such a line of reasoning that i can see is to have a concrete example to evaluate, because the entirety of the difficulty of answering that question lies in the specifics of "almost". |
| 00:39 | <SamB> | yes, you have to come up with a specific difference |
| 00:39 | <Hixie> | esprehn: i would do document.createElement('textarea') and be done, since hte browser has native support for it. |
| 00:39 | <esprehn> | Hixie: but it doesn't! |
| 00:39 | <othermaciej> | Hixie: I tend to agree with your point of view on this; but I think the Extensible Web Manifesto POV is that it's not necessary to specify the details of "different in what way" so as to provide for unexplained ways |
| 00:39 | <Hixie> | esprehn: well it better, the web kinda relies on it. |
| 00:40 | <esprehn> | Hixie: your browser downloads a JS library that implements textarea the first time you visit a page with it |
| 00:40 | <othermaciej> | Hixie: I feel like similar reasoning in the past has led to XML Namespaces so I am a bit wary of it |
| 00:40 | <Hixie> | othermaciej: every time people have tried that, it's fallen flat on its face. q.v. XML, XHTML2, etc. |
| 00:40 | <SamB> | othermaciej: is there some reason you can't do it with contenteditable and some XBL-successor? |
| 00:40 | <Hixie> | esprehn: that sounds like a performance nightmare |
| 00:40 | <othermaciej> | SamB: contentEditable doesn't have provisions for being plaintext only |
| 00:40 | <Hixie> | esprehn: what's wrong with the built-in <textarea>? |
| 00:41 | <esprehn> | Hixie: what if it has a bug? |
| 00:41 | <esprehn> | Apple only ships Safari once a year, why can't a install the textarea.js with a patch? |
| 00:41 | <Hixie> | esprehn: if there's a bug you use a different browser. |
| 00:41 | <esprehn> | you can do that on Android, you can monkey patch the ObjC classes on OS X |
| 00:41 | <SamB> | or install a different build of WebKit maybe? |
| 00:41 | <esprehn> | on Android you can include the java source with a patch if you want |
| 00:41 | <othermaciej> | because our implementation of lowlevel-primitives-that-textarea-uses won't ever have bugs |
| 00:42 | <SamB> | othermaciej: lol |
| 00:42 | <othermaciej> | and it's easier to add that feature than to fix the bug it helps you workaround I guess? |
| 00:42 | <esprehn> | othermaciej: sure, but your OS has bugs too, why not bake libxml into the kernel? |
| 00:42 | <esprehn> | you can't just concede that |
| 00:43 | <Hixie> | esprehn: the whole point of the web is that there's multiple implementations that compete on quality, it's the one huge difference between the web and every other platform, and is one of its biggest strengths. One big implication of this is that when there's a platform implementation bug, as an author, it's not your problem. |
| 00:43 | <esprehn> | obviously we'll have bugs, but you should be able to patch the platform. People use custom ruby installs and custom rails installs all the time |
| 00:43 | <othermaciej> | libxml has approx the same update cycle as the kernel on our platform, though in fairness you can bring your own more easily than you can bring your own kernel |
| 00:44 | <SamB> | esprehn: usually, textarea doesn't have any particularly grave flaws |
| 00:44 | <othermaciej> | a more on-point analogy is that OS X has both NSTextView and much lower-level text primitives that in theory you could use to build your own text editing and layout engine (of which WebKit is one) |
| 00:44 | <esprehn> | othermaciej: that's my point, I can bring my own libxml in Foo.app if needed, you can't bring your XNU |
| 00:44 | <Hixie> | in practice, btw, authors already commonly work around implementation bugs and it's not a huge deal. bugs in things like <textarea> exists, though, and nobody cares to work around it. I certainly trust Web authors a heck of a lot less than my browser vendor to ship a sane <textarea>. |
| 00:44 | <othermaciej> | but very few people do cause it's hard and tends to lack correct platform integration |
| 00:44 | <Hixie> | i mean, just compare the textarea that OSes ship, with teh text fields in video games. |
| 00:45 | <Hixie> | the custom-built video game text fields are a disaster. |
| 00:45 | <Hixie> | they're a poster-child for not having authors reinvent the wheel like this. |
| 00:45 | <SamB> | esprehn: so, where did you get stuck in your textarea.js anyway? |
| 00:46 | <SamB> | hmm, the main motivation *I've* seen for wanting to clone <textarea> in JavaScript is syntax highlighting |
| 00:46 | <Hixie> | SamB: we should definitely provide an API for stuff like that, that's come up several times. |
| 00:47 | <SamB> | I assume you've seen https://www.mediawiki.org/wiki/User:Remember_the_dot/Syntax_highlighter then? |
| 00:47 | <othermaciej> | I am sympathetic to the argument that sometimes people want to customize in ways that are hard to predict, or so niche that it would be weird to provide for them directly |
| 00:47 | <Hixie> | SamB: but implementing syntax highlighting shouldn't require re-implementing bidi editing, text selection, mouse placement of the caret, text-search in textareas, spell-checking, copy-and-paste, scrolling, dragging of bidirectional text selections, ... |
| 00:48 | <SamB> | Hixie: quite so |
| 00:48 | <othermaciej> | though I also feel it is a potentially dangerous argument that can be used to justify things with no real use case |
| 00:49 | <Hixie> | othermaciej: i'm totally on board with the idea that we should provide extension points for things like that, and indeed we do. for example, tabindex="" lets you hook into the focus system. but it's impossible to design good APIs for such things without use cases, IMHO. |
| 00:49 | <SamB> | which is why it would probably be best if you could implement it in terms of contentEditable, but still be compatible with a real textarea ... |
| 00:50 | <Hixie> | TabAtkins: on an unrelated note, the definition of :focus says that something matches :focus when it "accepts ... mouse events", which seems unlikely to be intended |
| 00:51 | <SamB> | othermaciej: Yes, which is why you should look at the places they've already run up against the boundaries. And, while you're at it, be amazed at what they've accomplished anyway (and how) |
| 00:51 | <SamB> | Hixie: using the old understatement, are we? |
| 00:51 | <rafaelw> | hixie: qq. for clients of "await a stable state", why not instead have them enqueue a microtask? |
| 00:52 | <Hixie> | rafaelw: microtasks didn't exist at the time |
| 00:52 | <Hixie> | rafaelw: but more importantly, the idea is that all the "await a stable state" cases can run in parallel |
| 00:52 | <Hixie> | rafaelw: whereas microtasks are serialised |
| 00:52 | <rafaelw> | why is it important for those clients to run in parallel? |
| 00:52 | <SamB> | so, is dot's syntax highlighter something or what? |
| 00:53 | <Hixie> | rafaelw: well, if we maintain that invariant it allows for a more optimal mutlithreaded implementation |
| 00:53 | <Hixie> | multithreaded |
| 00:53 | <SamB> | Hixie: you need magic dust to sleep in parallel now? |
| 00:54 | <rafaelw> | are there clients that do cpu-intensive algorithms? |
| 00:54 | <Hixie> | SamB: not to sleep, to do the work |
| 00:54 | <slightlyoff> | SamB: RE: custom textarea, I've had many others |
| 00:54 | <SamB> | oh, so you want them to wake up in parallel somehow? |
| 00:54 | <Hixie> | rafaelw: media stuff, dunno how cpu-intensive it is. probably not much. |
| 00:54 | <slightlyoff> | SamB: for instance, I once implemented a shortcut-expansion system for doctors |
| 00:54 | <rafaelw> | seems like premature optimization. |
| 00:55 | <Hixie> | rafaelw: it wasn't an optimisation at all, originally, microtasks didn't exist. |
| 00:55 | <slightlyoff> | they entered their content in their pidgen language and hit "tab" to expand or skip through the boilerplate |
| 00:55 | <rafaelw> | i'm not complaining about the past. i'm asking if we can unify now. |
| 00:55 | <SamB> | wouldn't it make more sense to have some kind of *abstraction* that allows some kind of potentially-parallel tasks to be enqueued? |
| 00:55 | <Hixie> | rafaelw: ah, ok, i thought you were asking why they were like that before |
| 00:55 | <slightlyoff> | SamB: and implementing it on top of textarea was downright painful. Would have been happier for lower-level control of the data and focus models |
| 00:55 | <Hixie> | rafaelw: let's see... |
| 00:56 | <slightlyoff> | SamB: that neither you nor I thought of that ahead of time is the key reason that extensibility and layering matter. We won't think of everything |
| 00:56 | <Hixie> | rafaelw: one case where stable states run but not microtasks is when you call alert(), that might be relevant... |
| 00:57 | <Hixie> | rafaelw: other than that, doesn't look like there's much reason one way or the otehr |
| 00:57 | <rafaelw> | i only see two clients of awaiting a stable state: img & media. |
| 00:57 | <SamB> | whenever I see something like "wait for" in these specs I'm never quite sure what is meant |
| 00:57 | <rafaelw> | it's a bit hard to tell, but it seems like the reason they are awaiting a stable state is basically "wait until i'm done being configured" (IOW, when script has exited). |
| 00:57 | <rafaelw> | am i misunderstanding? |
| 00:58 | <Hixie> | rafaelw: microtasks are more heavyweight, and tend to be more author-visible (e.g. they involve DOM mutations or script callbacks), whereas stable states are just about async algorithms having step they want to run when the DOM is in a known stable state. |
| 00:58 | <Hixie> | rafaelw: it's more about getting a lock on the DOM than anything else |
| 00:58 | <Hixie> | rafaelw: read lock |
| 00:58 | <Hixie> | (*having steps) |
| 00:59 | <Hixie> | rafaelw: changing some of these algorithms to use microtasks would be kinda awkward, but in principle i suppose it would be equivalent. |
| 00:59 | <Hixie> | rafaelw: i don't see much benefit to changing it though. |
| 01:00 | <rafaelw> | in blink i'd prefer to have one mechanism for "running soon when there's no script below me", rather than two. |
| 01:00 | <Hixie> | yeah i think it'd be quire reasonable to implement the stable state stuff as a microtask. |
| 01:00 | <Hixie> | quite |
| 01:01 | <Hixie> | foolip was working on the stable state stuff recently, fwiw |
| 01:01 | <rafaelw> | ok. shall i open a bug for that? |
| 01:01 | <Hixie> | (in blink) |
| 01:01 | <Hixie> | open a bug for what? |
| 01:01 | <Hixie> | there's still the alert() difference |
| 01:02 | <rafaelw> | aw. sorry. nm. you prefer to keep the notion of stable state in the spec. |
| 01:02 | <Hixie> | i mean i can make sure there's a note saying that they can be implemented as the same thing |
| 01:02 | <Hixie> | but i would imagine it depends a lot on how it's implemented |
| 01:02 | <rafaelw> | why does alert() provide a stable state? |
| 01:03 | <Hixie> | because you don't want <script> new Audio('myradio').play(); alert('ok, listen up!'); </script> to not even start the download until you hit ok |
| 01:03 | <Hixie> | you want it to just play |
| 01:03 | <rafaelw> | seems like a misfeature. |
| 01:03 | <Hixie> | the way the spec specs the stable states is more akin to joining the main thread than pushing a task on a queue, fwiw. so i think it is conceptually different, even though they can be implemented in terms of each other. |
| 01:03 | <Hixie> | what's a misfeature? |
| 01:04 | <rafaelw> | alert() providing a stable state. |
| 01:04 | <Hixie> | why? |
| 01:04 | <Hixie> | you think in that example the file shouldn't download until you hit ok? |
| 01:04 | <Hixie> | that seems highly unintuitive and annoying for users |
| 01:05 | <esprehn> | rafaelw: stable state is "hit the event loop" for us, alert() spins a nested event loop so you get that behavior "for free" I think |
| 01:05 | <rafaelw> | alert blocks the thread. if i'm an app and I use alert, no code after the alert runs. it's super weird if audio starts playing. |
| 01:06 | <Hixie> | <script> var a = new Audio('hugefile.ogg'); alert('hit ok to start music'); a.play(); </script> |
| 01:06 | <Hixie> | you don't want the download to wait until you hit ok. |
| 01:07 | <SamB> | rafaelw: you'd get the same thing on practically any toolkit |
| 01:07 | <jamesr__> | what part of this awaits a steady state? play() ? |
| 01:08 | <Hixie> | the constructor calls load(), effectively, and load() waits |
| 01:08 | <Hixie> | so that it can read the src="" or <source> without clashing with DOM manipulation code |
| 01:08 | <Hixie> | (since it's running async -- it basically joins the main thread to read the DOM) |
| 01:10 | <rafaelw> | basically, it's not worth it to me to weird-up a core notion of separation of concerns (microtasks/stable state/etc..) in order to accomodate alert |
| 01:10 | <rafaelw> | or showModalDialog for that matter. |
| 01:10 | <rafaelw> | showModalDialog should die in a fire. |
| 01:10 | <jamesr__> | well i think this is orthogonal to the discussion but i don't see any reason to await a steady state to read a dom attribute |
| 01:10 | <rafaelw> | alert should only be used for debugging. |
| 01:10 | <Hixie> | jamesr__: well you need to join the main thread, right? |
| 01:11 | <Hixie> | rafaelw: i don't disagree with you in principle, but i also think it's critical that the download start before you hit ok in the case above. I think a simpler solution would just be to have alert() and friends do a microtask checkpoint, but then it would make debugging harder. so maybe it's just best to have some microtask checkpoints only do the stable state microtasks. |
| 01:11 | <Hixie> | rafaelw: either way, it seems trivial to implement once you can do it anywhere else. |
| 01:12 | <Hixie> | rafaelw: i mean, it's just a flag "only include these microtasks", right |
| 01:12 | <rafaelw> | alert() cannot do a microtask checkpoint(). |
| 01:12 | <rafaelw> | it violates the central invariant. |
| 01:12 | <Hixie> | right, so like i just said, you'd just do a checkpoint that excludes the tasks that aren't currently "stable state" cases |
| 01:13 | <Hixie> | just like some algorithms spin the main event loop while having put a block on certain task sources. |
| 01:14 | <rafaelw> | why is it critical that the download start in that case? |
| 01:14 | <jamesr__> | Hixie: var a = new Audio('data:...').play(); while(1) {} - why can't that play? |
| 01:15 | <Hixie> | jamesr__: that case probably could, but consider the case of var a = new Audio(); a.appendChild(document.createElement('source')); ... |
| 01:15 | <Hixie> | jamesr__: the constructor starts the load asynchronously. |
| 01:15 | <Hixie> | jamesr__: that algorithm then starts running, but it's not on the main thread |
| 01:16 | <Hixie> | jamesr__: at some point that algorithm needs to inspect the <video> or <audio> element to figure out what attributes and children elements it has, so it can kick off loads of the media file, the text tracks, etc. |
| 01:16 | <Hixie> | jamesr__: those loads are themselves async, and sometimes the loads fail, and then the algorithm needs to reinspect the media element to work out what next to try to load |
| 01:17 | <Hixie> | jamesr__: and so on |
| 01:17 | <Hixie> | jamesr__: this is especially relevant while parsing, since the parser itself is just doing one bit at a time as a task on the event loop |
| 01:17 | <Hixie> | jamesr__: so it might parse enough to add the media element, but not enough to get the first <source> |
| 01:17 | <Hixie> | jamesr__: <video> <!-- network delay... --> <source ...> |
| 01:30 | <Hixie> | esprehn: so, i'm studying what it would take to hook into the focus model like you were saying. The main thing I specced that wasn't specced before, and for which there's no "hook", isn't actually related to dialogs, it's about things like the viewport and 'overflow:scroll' scroll regions. |
| 01:30 | <Hixie> | esprehn: is it ok that you can hook into the focus model with tabindex="" at the element level, but not at the CSS box level? |
| 01:31 | <Hixie> | esprehn: or, in the "extensible Web" model, should it also be possible to add focusable CSS boxes somehow? |
| 01:31 | <esprehn> | how do you get a css box that doesn't have an associated element? |
| 01:31 | <Hixie> | well e.g. the viewport doesn't have an associated element |
| 01:32 | <Hixie> | also you could have multiple boxes for one element |
| 01:32 | <Hixie> | e.g. div::before { overflow: scroll } |
| 01:32 | <esprehn> | I think all engines transfer focus to the "nearest" (there's a vague definition of this) element when you hit an anonymous thing |
| 01:32 | <esprehn> | the viewport being focused is like the document being focused I suppose |
| 01:32 | <Hixie> | what do you mean by "transfer focus"? |
| 01:33 | <esprehn> | if you click a ::before {} thing, we make appear like you actually clicked the thing that owns the ::before |
| 01:33 | <esprehn> | it's a sort of weird version of Shadow DOM retargeting |
| 01:34 | <Hixie> | sure but for keyboard access we presumably still want them to _actually_ be individually focusable, right? |
| 01:34 | <Hixie> | so my question is, how would you create one of these from script? |
| 01:35 | <esprehn> | That's an interesting question, I don't think a lot of thought has gone into focusing anonymous content |
| 01:36 | <esprehn> | we do some strange things, I don't think browsers agree on where the caret goes if you click a ::before in a content editable |
| 01:36 | <Hixie> | so is it ok if the API doesn't "explain" that ::before might be focusable? |
| 01:36 | <esprehn> | Hixie: Gecko, Blink and Webkit all create a real Element for ::before/::after and ::backdrop |
| 01:37 | <esprehn> | yeah, at some point we need to explain ::before, and we can deal with it being individually focusable at that point |
| 01:37 | <esprehn> | I don't think any browser lets you individually focus anonymous content today |
| 01:37 | <Hixie> | sure, but that's a bug, right? |
| 01:37 | <Hixie> | i mean, it's an accessibility and keyboard access problem that it's not possible today |
| 01:38 | <Hixie> | how about Document objects and browsing contexts? |
| 01:38 | <esprehn> | Hixie: yeah, I think the idea was that someday you could do element.getPseudoElement("before") and then add event listeners, tabindex, aria roles etc. |
| 01:38 | <Hixie> | how do we "explain" those? |
| 01:39 | <esprehn> | That's harder, I think slightlyoff has some deeper insight into the innards of them. I couldn't give you a concrete set of primitives on the spot here. |
| 01:39 | <Hixie> | k... |
| 01:39 | <Hixie> | is there a spec anywhere that i could look at that tries to explain these things? |
| 01:39 | <Hixie> | so i can integrate with it? |
| 01:39 | <slightlyoff> | pseudo elements are mostly BS. they should have DOM |
| 01:39 | <slightlyoff> | Shadow DOM actually helps you there |
| 01:39 | <JosephSilber> | slightlyoff: really? |
| 01:40 | <slightlyoff> | you can explain that all elements have existing SD that isn't populated |
| 01:40 | <slightlyoff> | and that the pseudo elements populate it |
| 01:40 | <esprehn> | Hixie: that's a really good question, I don't think we have a good spec for the "foundations of the web" primordial goop. Perhaps we should have a long term plan. |
| 01:40 | <slightlyoff> | maybe you don't make it available to scripting, but at least you're out of the conceptual woods |
| 01:40 | <slightlyoff> | document objects and browsing contexts need more work. We haven't done the archeology yet |
| 01:40 | <slightlyoff> | it's an important project |
| 01:40 | <esprehn> | Hixie: slightlyoff has written a bunch about it, but I don't think there's a doc that says "Documents do X, we need to explain it" with bugs to fill in the sections |
| 01:40 | <slightlyoff> | one we should stop delaying |
| 01:41 | <Hixie> | esprehn: fwiw, looking at the <dialog> stuff specifically, it's actually the least magical of all the stuff here. A straight <dialog open> where you haven't invoked showModal() is just basically a <div> that hooks into the focus model as an owner, just like a <div tabindex=""> is a <div> that hooks into the focus model as an area. So in a way, <dialog> actually _is_ explaining the model. |
| 01:42 | <Hixie> | slightlyoff: fwiw, the HTML spec documents the status quo on those in more or less complete detail now (this focus stuff being the last big missing piece, i think) |
| 01:42 | <esprehn> | Hixie: I'm not sure I understand |
| 01:42 | <Hixie> | slightlyoff: so feel free to use that as a resource |
| 01:42 | <esprehn> | what is <dialog> explaining? |
| 01:43 | <Hixie> | esprehn: it's basically the "explained" version of being a Document in the focus mdoel |
| 01:43 | <Hixie> | mdoel |
| 01:43 | <Hixie> | m o d e l |
| 01:43 | <slightlyoff> | Hixie: its' really good that way. Thank you. |
| 01:44 | <esprehn> | Hixie: interesting. |
| 01:44 | <Hixie> | esprehn: there's two kinds of primitives in the focus model, basically. Areas (things you can focus), and owners (things that can group areas so you can tab between them). Before, there was just Documents in the second category. In the first category there's all kinds of magical stuff, plus anything on which you put tabindex="0", which is basically the "explain hook" for focusable areas. |
| 01:45 | <Hixie> | esprehn: so now, <dialog open> acts as the "explain hook" for owners |
| 01:45 | <esprehn> | Hixie: exactly, that's why I was saying you should add a tabgroup attribute that is the "owners" category |
| 01:45 | <Hixie> | esprehn: so to answer your earlier question about tab groups, i think the answer is you just use a <dialog open> as each tab group |
| 01:45 | <esprehn> | spec that dialog's tabgroup attribute should compute to something like we do for tabindex on <input> |
| 01:45 | <Hixie> | esprehn: and you flip between them, making whichever one is active not inert, and all the others inert |
| 01:46 | <Hixie> | esprehn: is an attribute more "explainy" than an element? |
| 01:46 | <esprehn> | yes |
| 01:46 | <Hixie> | esprehn: the advantage of doing it on an element only is that it avoids tons of crazy complexity and edge cases that have little value |
| 01:47 | <esprehn> | I should be able to trap the tab index cycling inside an arbitrary area of the page without adding <dialog open> around it. |
| 01:48 | <Hixie> | why? or rather, why should it be possible without adding <dialog open>, but not without adding <div tabgroup="">? |
| 01:48 | <Hixie> | i don't understand the difference |
| 01:48 | <esprehn> | Hixie: because the only part of dialog I care about is the focusing behavior. That's why tabgroup is a primitive. I only need to use the tabgroup if that's all I want |
| 01:49 | <esprehn> | <dialog> has showModal(), but calling it on that part of the page is nonsense, it's not a modal dialog |
| 01:49 | <esprehn> | Hixie: XMLHttpRequest can decode JSON, but we still expose JSON.parse since creating an XHR object to decode JSON is silly. You don't need that whole thing just for the one part of it. |
| 01:51 | <esprehn> | If you want to be in the top layer, use the top layer API. If you want to trap focus use tabgroup. If you want both, and center positioning and other API stuff use <dialog>. |
| 01:52 | <Hixie> | esprehn: but <div tabgroup> has forceSpellCheck(), which you don't care about either. Why is it ok for it to have that, but not ok for it to have showModal()? |
| 01:53 | <Hixie> | esprehn: JSON.parse() is different because it's simpler to use JSON.parse() than to cycle content through XHR. In this case, though, it's more or less the same, just syntactic sugar that's different. |
| 01:53 | <Hixie> | <div tabgroup> vs <dialog open> |
| 01:53 | <Hixie> | the dialog one is even shorter by one character :-) |
| 01:53 | <esprehn> | I'm not sure any arbitrary element should support forceSpellCheck() either, does any browser implement that? |
| 01:54 | <esprehn> | I guess it sort of lines up with contenteditable |
| 01:54 | <Hixie> | yeah, it's for contenteditable. |
| 01:54 | <esprehn> | Hixie: having forceSpellCheck on Element seems like a bug, you're missing a real editing API so you're adding API surface to Element |
| 01:54 | <Hixie> | contenteditable is on HTMLElement also |
| 01:55 | <esprehn> | yeah |
| 01:55 | <Hixie> | click() is on every element also |
| 01:55 | <Hixie> | you don't care for click() on the tabgroup element |
| 01:55 | <esprehn> | you can imagine that adding contenteditable does something like "new Editor(this)" |
| 01:55 | <esprehn> | and that editor has spellchecking and such |
| 01:56 | <esprehn> | Hixie: why don't you? It's rendered if the things inside it are focusable. |
| 01:56 | <esprehn> | perhaps the group has a border and background, why can't a simulate a click on it? |
| 01:56 | <Hixie> | so? why would you ever want to fake a click to a non-interactive element? |
| 01:56 | <Hixie> | anyway |
| 01:56 | <esprehn> | why is it not interactive? Maybe it's draggable. |
| 01:56 | <Hixie> | click() wouldn't help you with that |
| 01:57 | <esprehn> | true, but it could have other behavior on click |
| 01:57 | <Hixie> | my point is i don't understand why it's ok to have these APIs but not the five <dialog> APIs |
| 01:57 | <Hixie> | heck, i would even argue that <dialog>'s form integration is something you _would_ want |
| 01:58 | <esprehn> | you mean the properties on Document? (the 5 APIs?) |
| 01:58 | <Hixie> | i mean <dialog>.open, .returnValue, .show(), .showModal(), and .close() |
| 01:58 | <esprehn> | I don't understand, I'm not arguing about the API surface on <dialog> itself |
| 01:59 | <Hixie> | what did you mean when you said "because the only part of dialog I care about is the focusing behavior" then ? |
| 01:59 | <esprehn> | Hixie: you want to be a tabgroup so that going to the last control and hitting tab again goes back to the first |
| 02:00 | <Hixie> | right, that's one of the main things <dialog> does. |
| 02:00 | <Hixie> | so why is it not ok to use <dialog>, but it is ok to use <div tabgroup>? |
| 02:01 | <Hixie> | my point is both <div> and <dialog> have other baggage, so why is one ok but not the other? |
| 02:01 | <esprehn> | Because we decided <div> is a building block, I think slightlyoff might argue that even that isn't enough, and we should provide a real FocusController API someday that <div> calls when you set tabgroup. |
| 02:01 | <slightlyoff> | yep! |
| 02:02 | <Hixie> | well we certainly shouldn't require that the author use script to do this |
| 02:02 | <esprehn> | today <div> is like NSView, it's pretty bare metal and way below <dialog> |
| 02:02 | <Hixie> | <div> and <dialog> are almost identical. |
| 02:02 | <slightlyoff> | Hixie: don't confuse "can" with "require" |
| 02:02 | <slightlyoff> | Hixie: I only ask that <div> (et. al.) be explained, not that we stop adding high-level stuff |
| 02:03 | <esprehn> | Hixie: The spec says we should treat <input> as if it had a tabindex IIRC |
| 02:03 | <esprehn> | "Modulo platform conventions, it is suggested that for the following elements, the tabindex focus flag be set" |
| 02:03 | <Hixie> | esprehn: right. i wouldn't have added tabindex="" if i had anything to do with it, i think it's a poor way to solve the problem. :-) |
| 02:04 | <Hixie> | i really have to go. i'll look into this some more. it'd be easy to retrofit a tabgroup="" attribute into this if for some reason <dialog open> isn't a good enough "explanation", anyway. |
| 02:04 | <esprehn> | Hixie: thanks for looking into it, lets continue this later. |
| 02:04 | <Hixie> | maybe we can skip the attribute and explain it directly in terms of something slightlyoff would like, so we would have two layers instead of having three layers :-) |
| 02:04 | <Hixie> | ttyl |
| 02:04 | <slightlyoff> | later |
| 02:18 | <Domenic_> | hahaha http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Feb/0086.html |
| 02:18 | <Domenic_> | my first thought was "this is whatwg@whatwg, not public-html" |
| 02:19 | <Domenic_> | but then i saw he brought public-html into the conversation |
| 07:58 | <MikeSmith> | reading http://www.whatwg.org/specs/web-apps/current-work/multipage/edits.html#attributes-common-to-ins-and-del-elements can anybody tell me if they see any UA requirements that actually testable there? |
| 07:58 | <MikeSmith> | I see that the spec says "User agents must parse the datetime attribute according to the parse a date or time string algorithm. If that doesn't return a date or a global date and time, then the modification has no associated timestamp" |
| 07:59 | <MikeSmith> | but it never requires the UA to actually do anything with the parsed value |
| 07:59 | <MikeSmith> | it doesn't state any specific means for exposing the parsed value |
| 08:30 | <zcorpan> | jgraham: do you know if table_inspector.py is around somewhere? |
| 09:39 | <vmatva> | Hi everybody. I'm new to all this things around IRC. |
| 09:40 | <vmatva> | I'm about to post a bug about DOM3 Events spec. Is it right place to discuss it before to post to bugzilla? |
| 10:13 | <zcorpan> | vmatva_: it seems like an appropriate place, although i think the editors of that spec aren't regulars here. also some of that spec is obsoleted by http://dom.spec.whatwg.org/#events |
| 10:19 | <zcorpan> | foolip: Hixie: whether a load starts in the face of alert() seems not so relevant. in fact if alert() is used for debugging it seems like it would be better if it did not start to load stuff while the alert is showing |
| 10:23 | <foolip> | zcorpan: good point, that would be pretty confusing |
| 10:24 | <foolip> | zcorpan: here are three bugs you may want to follow: |
| 10:24 | <foolip> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=24361 |
| 10:24 | <foolip> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=24707 |
| 10:24 | <foolip> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=24724 |
| 10:24 | <vmatva_> | zcorpan: Thank you. I have already created a bug in the appropriate W3C bugzilla section. I read document 'DOM 3 Events' by W3C (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html) as it contains more details than one referenced by you. |
| 10:26 | <zcorpan> | vmatva_: it actually contains less details |
| 10:27 | <vmatva_> | zcorpan: this is URL of bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24729 |
| 10:29 | <vmatva_> | zcorpan: Ok. I look at section http://dom.spec.whatwg.org/#events And I do not see any description of MouseEvent of WheelEvent. But I see it in W3C document. |
| 10:29 | <zcorpan> | vmatva_: thx. ok yeah for WheelEvent, dom3events is the right spec, or possibly https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm |
| 10:32 | <vmatva_> | zcorpan: Yep. I looks at latest versions of both W3C specs (DOM3 Events and UI Events). But still see that inconsistence that I described in bug. |
| 10:33 | <zcorpan> | vmatva_: yeah |
| 10:38 | <zcorpan> | vmatva_: it also gets CustomEvent and CustomEventInit wrong |
| 10:39 | zcorpan | never got the point of CustomEvent |
| 10:41 | <zcorpan> | MikeSmith: "This value may be shown to the user" |
| 10:42 | <zcorpan> | MikeSmith: so a manual test, with the condition that the UA does show it to the user |
| 10:45 | <MikeSmith> | zcorpan: ok |
| 10:59 | <jgraham> | zcorpan: I think it was once on html5.org. But I'm not sure |
| 11:00 | <zcorpan> | jgraham: http://james.html5.org/tables/table_inspector.py |
| 11:02 | <jgraham> | Interesting. Then "i'm not sure". I could have a dig around at home I guess |
| 11:04 | <zcorpan> | ok. i wanted to try it on hixie's focus table :-) |
| 11:15 | <zcorpan> | jgraham: should we ask youennf for an opinion on https://github.com/w3c/web-platform-tests/pull/556 or just merge? |
| 11:20 | <vmatva_> | zcorpan: I don't see any mention of CustomEvent in UI Events at all. |
| 11:24 | <zcorpan> | vmatva_: i mean in dom3events |
| 11:24 | <jgraham> | zcorpan: merged |
| 11:53 | <zcorpan> | TabAtkins: yoav: can you have a look at https://github.com/ResponsiveImagesCG/picture-element/pull/103 please? |
| 11:56 | <marcosc> | zcorpan: lgtm |
| 11:57 | <zcorpan> | marcosc: thx. can you merge? :-) |
| 11:57 | <marcosc> | zcorpan: done |
| 11:58 | <zcorpan> | neato |
| 11:58 | <marcosc> | zcorpan: yoav will have to regenerate the spec tho. I don't know if I have what I need to regenerated the spec on this machine. |
| 11:58 | <zcorpan> | yeah |
| 12:00 | <yoav> | Willdo |
| 12:00 | <yoav> | s/d/ d/ |
| 12:37 | <zcorpan> | hmm. "select an image source" should work even when there's no <picture> parent |
| 18:27 | <JonathanNeal> | Is ARIA a part of ADA? |
| 18:44 | <TabAtkins> | marcosc: There's a network version of Bikeshed, you know, linked in the docs. Just curl to it (or use the webform to do it manually). |
| 18:45 | <Domenic_> | still trying to wean people off ReSpec? :P |
| 18:46 | <TabAtkins> | Domenic_: Really I'm just trying to kill off the old CSSWG processor. ^_^ |
| 18:46 | <TabAtkins> | But the picture spec is bikeshedded. |
| 18:46 | <TabAtkins> | Bikeshedded already, I mean. |
| 18:47 | <Domenic_> | i was considering bikeshed, but like anolis, it seems hard to install on Windows. |
| 18:47 | <TabAtkins> | Indeed it is. Nobody's seriously tried it yet, so I dont' have install instructions, and it's probably difficult to do anyway. |
| 18:47 | <TabAtkins> | Fucking *everything* is hard to do on Windows. |
| 18:48 | <TabAtkins> | But that's why we have a network service for it. |
| 18:48 | <TabAtkins> | (Though curling is *also* hard on Windows...) |
| 19:49 | <gsnedders> | Anyone around with Opera BTS access able to tell me what CARAKAN-871 is about? |
| 19:54 | <erlehmann> | units! |
| 19:54 | <erlehmann> | i like that kind of thing |
| 19:58 | <aklein> | annevk-cloud: still around by any chance? |
| 19:59 | <aklein> | annevk-cloud: curious about what you had in mind with forcing <link rel=import> to have UTF-8 encoding |
| 20:23 | <gsnedders> | mathiasbynens: Why are Object.prototype.__defineGetter__ and __defineSetter__ defined to do stuff with black magic instead of creating a getter/setter property on the object? It leaves a lot undefined. |
| 20:24 | <gsnedders> | mathiasbynens: Like, at step four you set [[Enumerable]] of the property to true… but it might not exist yet! |
| 20:28 | <Hixie> | MikeSmith: <ins>/<del> are mostly just legacy from HTML4, so yeah, there's not much for UAs to do with them unless they're conformance checkers or analysis tools of sorts |
| 20:32 | <Domenic_> | Hmm I use <ins> and <del> a lot |
| 20:32 | <Domenic_> | What is preferred? |
| 20:38 | <Hixie> | Domenic_: preferred for what? |
| 20:38 | <Domenic_> | Hixie: marking up edits to a document or post, for example. |
| 20:39 | <Hixie> | <ins> and <del> are the only dedicated way to do that in html as far as i know |
| 20:40 | <Domenic_> | So in what sense do you mean they're legacy from HTML4? |
| 20:41 | <Hixie> | they came from HTML4, we didn't invent them since |
| 20:41 | <Hixie> | like <p> is legacy from the first draft of HTML |
| 20:41 | <Domenic_> | ah ok, so not "bad" legacy |
| 20:41 | <Hixie> | and <table> is legacy from like HTML2 or so |
| 20:42 | <Hixie> | no, i meant it in its sense of "a thing handed down by a predecessor" |
| 20:42 | <Hixie> | not "denoting software or hardware that has been superseded but is difficult to replace because of its wide use" |
| 20:42 | <Hixie> | sorry for the confusion |
| 20:43 | <erlehmann> | i use ins and del as well |
| 20:43 | <erlehmann> | i even wrote stylesheets there! |
| 20:43 | <erlehmann> | http://daten.dieweltistgarnichtso.net/src/css-del-ins.html |
| 20:49 | <gsnedders> | mathiasbynens: https://github.com/whatwg/javascript/issues/18 |
| 20:50 | <Hixie> | jgraham: zcorpan: looks like some version of the source is at http://html5.googlecode.com/svn/trunk/tables/web/cgi-bin/table_inspector.py |
| 21:11 | <mathiasbynens> | gsnedders: nice, thanks. got a link to that bz mail? |
| 21:11 | <gsnedders> | mathiasbynens: Nah, it was somewhat tangential anyawy |
| 21:11 | <gsnedders> | mathiasbynens: (personal email, about stuff around opjsunit) |
| 21:11 | <gsnedders> | (Nothing that interesting in it) |
| 21:36 | <zewt> | things that strongly discourage me from bothering with html validation: pages of bogus warnings about custom ports, and equally bogus warnings about rel=noreferer |
| 21:40 | <Hixie> | custom ports? |
| 21:46 | <zewt> | local development server is on port 81; validators spew dozens of warnings about https://foo.com:81 links |
| 21:47 | <zewt> | (internal, rather; not on the local network, not that it matters) |
| 21:48 | <zewt> | is there a validator that'll let me shut up particular warnings that I'm not interested in "fixing"? |
| 21:51 | <Hixie> | why would validators spew dozens of warnings about https://foo.com:81 links? |
| 21:51 | <Hixie> | what's the warning? |
| 21:52 | <zewt> | "ports under 1024 should be accessed using the appropriate scheme name" |
| 21:52 | <Hixie> | o_O |
| 21:53 | <zewt> | i can't even think of a case where that warning makes sense |
| 21:53 | <Domenic_> | 80 or 443? |
| 21:53 | <Hixie> | especially since 81 is unassigned... |
| 21:54 | <zewt> | no, 81 (some random arbitrary port; I think it used to be an alternate HTTP server dropped on 80+1, then later became https) |
| 21:55 | <Hixie> | have you filed a bug with the validator in question? |
| 21:56 | <zewt> | no, since it happened on two validators in a row (html5.validator.nu, validator.w3.org; based on the output I assume they're basically the same thing) |
| 21:56 | <Hixie> | you found the same bug on two instances of the same validator and so you didn't file a bug? |
| 21:56 | <Hixie> | file a bug dude. |
| 21:59 | <zewt> | file a bug where? likely not on those websites if there's some underlying codebase, and the usefulness I find in validators doesn't motivate me to figure that out, or to debate with whoever it goes to |
| 22:00 | <Hixie> | http://bugzilla.validator.nu/enter_bug.cgi |
| 22:00 | <Hixie> | if you can't be bothered to file a bug, please don't complain here :-) |
| 22:01 | <zewt> | filing bugs risks a high time investment |
| 22:02 | <gsnedders> | Hixie: Wait, what, we can't bitch here about random shit? :( |
| 22:02 | <Hixie> | gsnedders: you can, you file bugs when you bitch. |
| 22:02 | <Hixie> | pretty much everyone who bitches here files bugs as they're bitching, even when they are pretending to not care :-) |
| 22:04 | <Hixie> | but saying that validators are useless because they have a bug, passively aggressively "threatening" to not use them any more, and then saying that helping make validators better is a "risky investment", seems kinda ridiculous even for #whatwg. |
| 22:04 | <gsnedders> | Hixie: Bah! When I don't care I just prod people who will. :) |
| 22:04 | <Hixie> | like i said :-) |
| 22:05 | <gsnedders> | And I dunno, doesn't seem that ridiculous. There again, my logic *is* all the way over by the door, so I might not be thinking rationally. :) |
| 22:24 | <Hixie> | how the heck do you find the element that a touchmove event is over? |
| 22:25 | <Hixie> | like, if i want to get the list of elements that a user swiped over |
| 22:35 | <TabAtkins> | elementFromPoint()? |
| 22:36 | TabAtkins | isn't familiar with the touch* events, so can't tell if there's an easier way. |
| 22:37 | <Hixie> | yeah, looks like elementFromPoint() is the only way |
| 22:37 | <Hixie> | would be good if those methods took a MouseEvent or TouchEvent |
| 23:08 | <Hixie> | oh man |
| 23:08 | <Hixie> | touch events are non-trivial to use |
| 23:08 | <Hixie> | i wish each touch would just be its own object with events firing on it |
| 23:08 | <Hixie> | instead of having to track touch.identifier |
| 23:50 | <Hixie> | ok, got it working. http://damowmow.com/playground/demos/touch/001.html |
| 23:53 | <marcosc> | TabAtkins: thanks, sorry I missed that in the docs |