| 00:00 | <myndzi> | p is an element in the html namespace yes? |
| 00:00 | <Hixie> | could involve closing some other elements, doing things with formatting elements, etc |
| 00:00 | <Hixie> | foster parenting |
| 00:00 | <Hixie> | all kinds of stuff |
| 00:00 | <Hixie> | depends where you have to do it |
| 00:00 | <myndzi> | oh right, i was thinking it would reprocess the end tag (which it will) |
| 00:00 | <myndzi> | but first it must process the opening tag |
| 00:02 | <myndzi> | well that's beyond the scope of what i have to do, so i'll have to treat it like the others for now |
| 00:02 | <myndzi> | it looks like in general i can simply have a list of scope delimiters to search for, and when i get a non-matching tag, look up which scope it's in and either ignore or fix as specified |
| 00:03 | <myndzi> | ignore if there isn't an open tag in scope, fix if there is |
| 00:03 | <Hixie> | are you writing an html parser? |
| 00:03 | <myndzi> | patching one |
| 00:03 | <myndzi> | it's not structured favorably for proper implementation |
| 00:03 | <myndzi> | but it's choking on missing li and td tags |
| 00:03 | <Hixie> | i recommend just starting over then |
| 00:03 | <myndzi> | i may at some point |
| 00:03 | <myndzi> | but for now i need a working fix asap |
| 00:03 | <Hixie> | it's probably less work than patching it, and we have a ton of tests :-) |
| 00:04 | <myndzi> | i'd try to use aredridel's parser but i can't figure out HOW, it has no documentation haha |
| 00:04 | <myndzi> | rather, i can't figure out how to integrate it into cheerio |
| 00:04 | <myndzi> | and anyway, as long as the rules are simple, the patch is easy |
| 00:04 | <myndzi> | i just needed to come up with a generalization that will work sufficiently for our purposes :P |
| 00:05 | <myndzi> | i get where you're coming from but my boss is already on my ass all the time about trying to do things Right instead of Fast |
| 00:05 | <myndzi> | and when it affects business it's not a good time to argue hehe |
| 00:06 | <myndzi> | some of these rules are fairly confusing/irritating |
| 00:06 | <myndzi> | for example, closing non-special tags says to close implied end tags |
| 00:07 | <myndzi> | but closing implied end tags only does anything if the current tag is special |
| 00:08 | <myndzi> | i guess that means it must happen in some other situation, but man my head! :\ |
| 00:09 | <Hixie> | you mean "generate implied end tags"? |
| 00:09 | <myndzi> | yeah |
| 00:10 | <myndzi> | i guess it could reach a special tag as part of the loop process |
| 00:10 | <Hixie> | <div><p></div> has to close the <p> |
| 00:10 | <myndzi> | except it says to abort in that case |
| 00:10 | <Hixie> | i guess i don't understand what you mean exactly |
| 00:11 | <Hixie> | do you have an example that invokes the algorithm that is pointless? |
| 00:31 | <myndzi> | i could try, but not right now |
| 00:31 | <myndzi> | here is one that's worth looking at though |
| 00:31 | <myndzi> | (This will never fail, since the loop will always terminate in the previous step if the top of the stack — an html element — is reached.) |
| 00:32 | <myndzi> | but the list for element in select scope does not include 'html' |
| 00:41 | <Hixie> | myndzi: if you're in select scope, then you'll stop at the select. |
| 00:41 | <Hixie> | myndzi: (everything is in the list for select, except optgroup and option) |
| 00:42 | <myndzi> | yeah, presumably it relies on having inserted the select earlier |
| 01:46 | <muyyatin> | I wish pointer-events would apply to Canvas elements in IE. It's not really MORE of a security risk, since you could replace the canvas with an embedded SVG image using toDataURL(). </rant> |
| 09:49 | <hsivonen> | Ms2ger: I sync the html5lib tests manually when I happen to be working on related stuff |
| 09:53 | <jgraham> | hsivonen: Would you care if they were in git instead of hg? |
| 09:54 | <hsivonen> | jgraham: not really |
| 09:55 | <jgraham> | hsivonen: Excellent :) |
| 16:27 | <slightlyoff> | annevk: about the on()/addEventListener() return... |
| 16:27 | <slightlyoff> | you around? |
| 16:35 | <dglazkov> | good morning, Whatwg! |
| 16:40 | <JonathanNeal> | Good morning! |
| 16:41 | <slightlyoff> | howdy dglazkov |
| 17:35 | <annevk> | slightlyoff: am now |
| 17:36 | <annevk> | slightlyoff: middle of meeting week |
| 17:36 | <slightlyoff> | yeah, sorry to pounce durring your first week |
| 17:38 | <annevk> | I'm thinking next week will be better |
| 17:38 | <annevk> | there's also all these silly UK forms I need to fill out |
| 17:41 | <slightlyoff> | annevk: was thinking that the returned object should have a method that allows you to disconnect (and perhaps reconnect) |
| 17:42 | <annevk> | yeah, that's the idea |
| 17:42 | <zewt> | if anybody's bored and feels like taking a stab at explaining this behavior before i file a bug on webkit: https://zewt.org/~glenn/test-webkit-transition-bug.html run test(); the text appears on top of the blue box above it at weird times |
| 17:42 | <annevk> | well, initially Jake came up with the idea of just returning a function, but people didn't like that |
| 17:42 | <zewt> | annevk: hi |
| 17:42 | <zewt> | heh |
| 17:43 | <annevk> | still need to ask some people about memory usage around that |
| 17:44 | <zewt> | annevk: i'm curious if you find anything out, since i'd expect creating an object and creating a closure function to be pretty much the same thing |
| 17:44 | <zewt> | but of course reality doesn't always meet expectations, so |
| 17:44 | <annevk> | well, if you have an object you still need the function |
| 17:45 | <annevk> | so you'd have at least twice the stuff |
| 17:45 | <zewt> | but it'd be the same function on all of the objects, just a value hanging off the interface like any other interface function |
| 17:47 | <annevk> | yeah, not sure how that works, guess that varies per engine |
| 17:47 | <zewt> | either way you (at least naively) have references to two objects: either the observation and an interface, or the observation and a function |
| 17:47 | <slightlyoff> | note: functions are objects =) |
| 17:48 | <zewt> | slightlyoff: right, but the important thing is that this is a closure, not just a function |
| 17:48 | <zewt> | that is, you aren't returning the same function every time, you still have to allocate something to stash what it's for |
| 17:48 | <zewt> | anyway, yeah, let me know what you find out |
| 17:49 | <slightlyoff> | there's no difference (aside from optimization) between allocating a new function and a new object of some other sort |
| 17:49 | <slightlyoff> | zewt: closures aren't magic |
| 17:49 | <zewt> | slightlyoff: that's what i'm saying :) |
| 17:50 | <slightlyoff> | yes, it's possible to optimize away internal storage for a function that closes over no free variables |
| 17:50 | <slightlyoff> | but not all engines will (or do) |
| 17:50 | <slightlyoff> | and we can't require that in the spec |
| 17:50 | <zewt> | not really related here |
| 17:51 | <zewt> | since it *does* have storage (the function would have to have a reference to the event handler it manipulates) |
| 17:51 | <slightlyoff> | correct |
| 17:58 | <JonathanNeal> | Y U NO ALLOW NEGATIVE PADDING? |
| 17:58 | <Hixie> | what would it mean? |
| 18:00 | <JonathanNeal> | Well, before I answer that, let me admit that "padding" is the wrong word to describe the problem I'm trying to solve. I'm trying to give an element a negative inset for its contents, similar to what a negative padding might do, in theory. |
| 18:03 | <zewt> | (negative margins won't work for your case for some reason?) |
| 18:03 | <JonathanNeal> | I'll put an example online. |
| 18:03 | <zewt> | or do you want to extend the contents beyond the box? |
| 18:06 | <zewt> | reduced weird webkit bug, and still not sure how to work around it; bleh |
| 18:10 | <annevk> | hmm smaug____ doesn't even care |
| 18:10 | <annevk> | well I guess that's settled then |
| 18:10 | <annevk> | now I just need to find some time |
| 18:13 | <JonathanNeal> | I have a container with 4 panels. These panels have gutters between them, like columns in print, but there are no gutters between the edge of the panels and the container. Since this is being done on the web, I'm taking advantage of media queries. At high resolutions, the panels have these widths: 50%, 50%, 50%, and 50%, so that visually they look like 2 rows. At smaller resolutions, the panels have these widths: 100%, 50%, 50%, |
| 18:13 | <JonathanNeal> | 100%, so that visually they look like 3 rows. |
| 18:14 | <zewt> | annevk: btw. not sure i got a reply to just extending addEventListener instead of adding a whole new entry point |
| 18:14 | <annevk> | I think that'd be just confusing |
| 18:15 | <annevk> | and doesn't improve on the long name complaint |
| 18:15 | <zewt> | how so? handler = elem.addEventListener("click", handler, { alwaysBubble: true, capture: false }) |
| 18:15 | <Hixie> | JonathanNeal: this seems reasonably easy, is there more to it? |
| 18:15 | <slightlyoff> | zewt: you're still typing "addEventListener", which sucks |
| 18:15 | <zewt> | while i'm happy to have shorter names, it's not a good enough reason to add a new, different API |
| 18:16 | <JonathanNeal> | Hixie: that's it. |
| 18:16 | <zewt> | (alias on = addEventListener if anything, no need for distinct APIs) |
| 18:17 | <slightlyoff> | zewt: cart before the horse. Lets make something good and *then* see if we can work back to patching addEventListener to support it (which is likely ,but should not be a key goal) |
| 18:17 | <Hixie> | JonathanNeal: and what is your markup? just four elements back to back? |
| 18:17 | <slightlyoff> | zewt: also, naming is important. Those who say "short names are not enough" are not paying attention to the history of libraries |
| 18:17 | <JonathanNeal> | In one container, yes. |
| 18:18 | <zewt> | no, don't start by making a whole new API; start with the features and use cases you want, and design an API for them |
| 18:18 | <slightlyoff> | zewt: uh...you just pre-disposed and outcome and then said "design for your use-case", which is defeated by pre-supposing the outcome |
| 18:19 | <zewt> | and i'm pretty sure the interface I proposed handles the use cases people want (being able to remove the handler without retaining a reference to the function; being able to ignore the bubble flag for event delegation; event delegation filtering) |
| 18:19 | <slightlyoff> | zewt: honestly, this is like the second day in a row that you're making me regret signing onto IRC |
| 18:19 | <zewt> | slightlyoff: okay, you're apparently not capable of civil conversation, so i'm not having one with you |
| 18:19 | <zewt> | wow, first time i've been tempted to /ignore someone on this channel |
| 18:19 | <zewt> | congrats, etc |
| 18:20 | <annevk> | zewt: I think having a new API map to the same abstract concept is better than retrofitting old APIs |
| 18:20 | <annevk> | zewt: because you then a) double the testing and b) need to handle cases like boolean or dictionary |
| 18:20 | <zewt> | annevk: why? this seems like a straightforward extension |
| 18:21 | <annevk> | if we want to advocate on() anyway there's no need to touch the old code |
| 18:21 | <zewt> | a) it definitely doesn't double the testing (what?), and b) that's what webidl is for |
| 18:21 | <annevk> | just needs to speak the same language |
| 18:22 | <annevk> | it's more confusing too imo |
| 18:22 | <zewt> | ... why? |
| 18:23 | <annevk> | because suddenly addEventListener returns an object that allows for removal rather than using removeEventListener for that, etc. |
| 18:23 | <annevk> | seems kinda obvious |
| 18:23 | <Hixie> | JonathanNeal: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2080 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2081 |
| 18:23 | <Hixie> | JonathanNeal: i sadly had to add a wrapper div around each one because we don't have ::outside yet |
| 18:24 | <zewt> | annealtf4 |
| 18:27 | <zewt> | for the irc log record, there's nothing confusing about adding a feature to addEventListener to make it return an object instead of nothing |
| 18:27 | <JonathanNeal> | Hixie: got it, so you can't use the wrapper div. |
| 18:27 | <JonathanNeal> | I see. |
| 18:29 | smaug____ | does care |
| 18:31 | <JonathanNeal> | Hixie: you've also got overflow in your example |
| 18:31 | <JonathanNeal> | the body is scrolling x |
| 18:31 | <Hixie> | JonathanNeal: yeah it probably needs minor tweaks |
| 18:31 | <Hixie> | overflow-x:hidden e.g. |
| 18:35 | <JonathanNeal> | Right, which has its own issues. That's where I'm at too. |
| 18:35 | <JonathanNeal> | I don't wrap each panel though, I put a wrapper just inside the container. |
| 18:35 | <Hixie> | the wrapping of each panel lets you more easily just set the horizontal width at the margin level |
| 18:36 | <Hixie> | you can probably get it to work with box-sizing too |
| 18:36 | <Hixie> | if you don't care about the boxes being _exactly_ equal width, you can easily get rid of the scrollbar by setting the left margin on the first one and the right margin on the last one to 0 |
| 18:36 | <Hixie> | and then removing the negative margins |
| 19:23 | <JonathanNeal> | I'm using box-sizing: border-box. |
| 19:24 | <JonathanNeal> | I wish it were the default anyway. |
| 21:24 | <zewt> | i ooooi |
| 21:47 | <zewt> | did i just vim all over the channel |
| 22:55 | <zewt> | i guess one problem with the "clone a DocumentFragment then appendChild it" template pattern is you lose any reference to the nodes when they're inserted :| |
| 23:15 | smaug____ | wonders why table sorting has anything to do with microtasks |
| 23:58 | <volkmar> | Hixie: by any chance, do you know how the size of the <input type='file'> in webkit is computed? |
| 23:59 | <Hixie> | like, in pixels? |
| 23:59 | <Hixie> | no idea |
| 23:59 | <Hixie> | i would assume it's fixed? or based on the font-size? |