| 06:34 | zcorpan | marks Future discussions as read |
| 07:52 | <jgraham> | Hmm, so roc's delaying the content load event proposals are scaring me, but I'm not entirely sure I can entirely defend my git-reaction of "run away" |
| 07:52 | <jgraham> | *gut |
| 07:53 | <Ms2ger> | http://www.youtube.com/watch?v=KAp9sFVdERQ |
| 07:57 | <jgraham> | I think what frightens me is tying in a script controlled flag to something that is already intimately connected with the lifecycle of the document |
| 07:59 | <Ms2ger> | Clearly we need a reallyload event |
| 08:38 | <smaug____> | well, you can implement the thing using script libraries |
| 08:38 | <smaug____> | some hacky iframe doing document.write or such |
| 08:39 | <jgraham> | Sure |
| 08:39 | <jgraham> | But there's a difference between "X is possible" and "X is encouraged" |
| 09:04 | <SimonSapin> | Is http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html missing something like th { text-align: center }? Or is it encoded as prose somewhere in there? |
| 09:07 | <Ms2ger> | I think that's in prose somewhere... |
| 09:07 | Ms2ger | looks |
| 09:08 | <SimonSapin> | searching for "th" doesn’t really help ;) |
| 09:08 | <Ms2ger> | User agents are expected to have a rule in their user agent stylesheet that matches th elements that have a parent node whose computed value for the 'text-align' property is its initial value, whose declaration block consists of just a single declaration that sets the 'text-align' property to the value 'center'. |
| 09:10 | <SimonSapin> | oh … |
| 09:10 | <SimonSapin> | that sucks |
| 09:10 | <Ms2ger> | Yeah, it's weird |
| 09:13 | <SimonSapin> | I guess WeasyPrint is gonna ignore the part about the parent with an initial value |
| 09:15 | <SimonSapin> | I wish the whole chapter could be encoded as CSS to be used in a UA stylesheet, even if that means having a few magic CSS keywords |
| 10:06 | <aleray> | what is the license of html5lib-python? |
| 10:10 | <SimonSapin> | aleray: the source says MIT |
| 10:21 | <jgraham> | Yes, MIT |
| 10:22 | <jgraham> | Of course we prefer patches than forks :) |
| 10:32 | <zcorpan> | does anyone want to help me importing http://dev.w3.org/cvsweb/html5/html4-differences/ to https://github.com/whatwg/html-differences (preserving history)? |
| 10:34 | <jgraham> | zcorpan: git cvsimport seems to be what you want |
| 10:36 | <jgraham> | http://stackoverflow.com/questions/11362676/what-is-the-best-way-to-import-a-cvs-repository-in-git-and-use-it-locally |
| 10:36 | <jgraham> | I think you also have to have CVS set up right in the first place |
| 10:37 | <jgraham> | http://maymay.net/blog/2008/04/15/how-to-import-cvs-code-repositories-into-git-using-git-cvsimport/ |
| 10:39 | <aleray> | SimonSapin, jgornick |
| 10:39 | <aleray> | oups jgraham |
| 10:39 | <aleray> | thanks |
| 10:39 | <aleray> | I'm writing a writer |
| 10:39 | <aleray> | for ConText |
| 10:39 | <aleray> | (http://wiki.contextgarden.net/Main_Page) |
| 10:39 | <aleray> | super crude |
| 10:40 | <aleray> | so maybe I'll wait a little bit more, but since I copied the htmlserializer to start with I will keep the mit license |
| 10:41 | <aleray> | no fork on the roadmap :) |
| 10:53 | <zcorpan> | jgraham: i tried following the maymay.net steps but get: |
| 10:53 | <zcorpan> | Running cvsps... |
| 10:53 | <zcorpan> | connect error: Permission denied |
| 10:54 | <jgraham> | I am not the best person to help here |
| 10:55 | <jgraham> | Since I haven't used CVS for 7 years or something |
| 10:55 | <jgraham> | and don't have W3C CVS access |
| 10:55 | <jgraham> | But, are you sure that your CVS access is correctly set up? |
| 10:56 | <zcorpan> | I logged in with the anonymous credentials at http://dev.w3.org/cvsweb/ |
| 10:56 | <zcorpan> | ~/.cvspass exists |
| 10:57 | <zcorpan> | i could do a checkout |
| 10:57 | <jgraham> | Hmm |
| 10:57 | <jgraham> | I note that no other instructions I can see require cvsps |
| 10:59 | <zcorpan> | or maybe they do but don't say so :-) |
| 11:00 | <jgraham> | Could be :) |
| 11:01 | <jgraham> | (you could also try cvs2git I guess: http://cvs2svn.tigris.org/cvs2git.html) |
| 11:23 | <zcorpan> | screw it |
| 11:33 | <zcorpan> | MikeSmith: can http://dev.w3.org/cvsweb/html5/html4-differences/ be made read-only? |
| 12:21 | <hallvors> | hm.. the problem with learning Git is that all one's mistakes seem to cause somebody else trouble.. Working on https://github.com/whatwg/xhr/pull/2 I'm wondering if I can cut down the long list of commits associated with the pull request |
| 12:22 | <hallvors> | the code changes under "Files changed" are near perfect, only those I want included.. |
| 12:22 | <hallvors> | so why does Git (or GitHub) reference all those commits, and isn't there a way I can delete some of them from the list? |
| 12:22 | <Ms2ger> | I think the term is "squash"? |
| 12:23 | Ms2ger | pokes jgraham |
| 12:24 | <jgraham> | Yes, you can |
| 12:24 | <jgraham> | I suggest closing the pull request though; I'm not sure what happens if you rewrite history and then push to a existing PR |
| 12:25 | <hallvors> | I've heard rumours of squash.. ;-) |
| 12:25 | <jgraham> | The way that you rewrite the history to reduce the number of commits is to use git rebase -i (i.e. --interactive) |
| 12:26 | <hallvors> | however, what I really don't understand is that the PR also lists changes like "add more IDs.." that are really quite old.. |
| 12:26 | <hallvors> | and pushed before I made this branch that I wanted to make a PR from |
| 12:26 | <jgraham> | Hmm, well let me start by talking about how to use git rebase if you have a clean branch |
| 12:26 | <jgraham> | Then we can figure out if your branch is clean :) |
| 12:27 | <hallvors> | hm.. what's a "clean" branch in the first place? |
| 12:27 | <hallvors> | 8-) |
| 12:27 | <jgraham> | So the easiest thing to do is something like git rebase -i master |
| 12:27 | hallvors | appreciates having Git gurus around |
| 12:27 | <jgraham> | This should bring up a text editor with a list of commits on your branch |
| 12:28 | <hallvors> | OK - at what point? after committing stuff to master? to other branch? |
| 12:28 | Ms2ger | likes how hg doesn't require gurus to be around :) |
| 12:28 | <jgraham> | (protip: make sure that your $EDITOR is not set to vi before doing this) |
| 12:28 | <jgraham> | (protip2: :q) |
| 12:29 | <jgraham> | hallvors: I am assuming that you made the commits on some non-master branch |
| 12:29 | <hallvors> | yes |
| 12:29 | <hallvors> | so now I say rebase -i master. OK |
| 12:30 | <jgraham> | If you made the commits directly on master a) don't do that and b) look back through history to find some SHA1 before you started adding stuff |
| 12:30 | <jgraham> | Well, I guess it might even be easier to take it in two steps |
| 12:30 | <jgraham> | "git rebase master" |
| 12:30 | <jgraham> | This will move your commmits so they are on top of whatever master is |
| 12:31 | <hallvors> | OK - but they should already be.. anyway :) |
| 12:31 | <jgraham> | Hmm, let's take a step back |
| 12:31 | <jgraham> | Yeah, I think this doesn't all apply to your situation |
| 12:31 | <jgraham> | So the full process I would do is: |
| 12:31 | <jgraham> | git fetch origin |
| 12:31 | <jgraham> | git rebase origin/master |
| 12:31 | <hallvors> | I've done that |
| 12:31 | <jgraham> | git rebase -i origin/master |
| 12:32 | <hallvors> | (with some "merge conflict" resolution where I just told it to use Anne's version and discard any local edits) |
| 12:32 | <hallvors> | ah |
| 12:32 | <jgraham> | The two rebases are just to make things easier; the first will move your commits on top of the latest upstream without otherwise changing history |
| 12:32 | <hallvors> | I haven't done the rebase origin/mastr thing |
| 12:33 | <jgraham> | and the second one is to do the history rewrite |
| 12:33 | <hallvors> | OK, so that's why changes that predate me creating the branch still are in the PR |
| 12:33 | <jgraham> | Let's say you get as far as the interactive rebase |
| 12:34 | <hallvors> | thanks, now I understand a bit more :) |
| 12:34 | <jgraham> | Then you have an editor listing all the commits on your branch |
| 12:34 | <jgraham> | And some instructions down the bottom |
| 12:34 | <jgraham> | To the left of each SHA1 is the word "pick" |
| 12:34 | <jgraham> | You can change this, depending on what you want to do with the commit |
| 12:34 | <hallvors> | yes |
| 12:35 | <jgraham> | Notably "squash" will merge it into the previous commit and try to keep the commit message |
| 12:35 | <jgraham> | "fixup" will merge it into the previous commit and discard the commit message |
| 12:35 | <jgraham> | Deleting the line will remove that commit |
| 12:36 | <jgraham> | Changing the order allows you to reorder commits (but note that this can lead to merge conflicts) |
| 12:36 | <jgraham> | So you edit this until the branch looks how you want |
| 12:36 | <jgraham> | and save it |
| 12:36 | <jgraham> | and then you might get another editor allowing you to change some commit messages |
| 12:36 | matjas | refreshes http://html-differences.spec.whatwg.org/ like crazy |
| 12:36 | <jgraham> | and then history will be rewritten |
| 12:37 | <hallvors> | I'll try with a fresh branch and see if I can make a reaaaaly clean PR.. |
| 12:37 | <jgraham> | Ms2ger: That explains why there are never blog posts from Mozilla people describing crazy gymnastics with mq |
| 12:39 | <jgraham> | (or to put it differently: describe how to go from commits A-B-C-D to commits AB'-D'-C' in hg that describe an identical change to the original branch) |
| 12:40 | <jgraham> | (and convince me this is something that would be obvious to a newcomer without consulting external help) |
| 12:43 | <SimonSapin> | jgraham: not Mozilla people, but still :) http://www.logilab.org/blogentry/88203 |
| 12:45 | <jgraham> | SimonSapin: Maybe I needed a </sarcasm>? I have seen *many* blog posts about how to achieve simple-sounding things in hg |
| 12:46 | <jgraham> | (that phases thing sounds like it wouldn't work well with code review on a branch) |
| 12:46 | <SimonSapin> | well, I’ve seen this guy give a talk on hg phases, and it didn’t quite sound simple |
| 12:49 | <jgraham> | Right, I think we are agreeing that things aren't always as simple as Ms2ger claimed |
| 12:50 | <Ms2ger> | Hg phases make a lot of sense unless you push unfinished commits to a public repo, like we do with our tryserver |
| 12:51 | <jgraham> | Or we do with critic |
| 12:52 | <hallvors> | Ms2ger, jgraham: I had no intention of starting a religious war between the two of you. :-o Peace :) |
| 12:52 | <jgraham> | So basically it's a great idea as long as you don't worry about the real world |
| 12:52 | <Ms2ger> | Hah |
| 12:54 | <hallvors> | Meanwhile, I've successfully achieved some of what I wanted in https://github.com/whatwg/xhr/pull/3 but not all - right now I'll just wait for Anne getting to it and move on to the next opportunity for trying to make Git understand me and vice versa |
| 12:55 | <Ms2ger> | hallvors, you know about vim vs emacs, right? |
| 12:55 | <hallvors> | ugh |
| 12:56 | <hallvors> | I don't want to "know" more than I do because everybody who really "knows" is fighting, right? :-p |
| 12:56 | hallvors | likes peace |
| 12:57 | <Ms2ger> | hg vs. git is the same thing, with the difference that your choice actually affects the people you work with :) |
| 13:01 | <zcorpan> | matjas: meanwhile i was talking to a colleague and then getting a cup of tea :-P |
| 13:04 | <zcorpan> | matjas: (i've asked anne & hixie to create that url) |
| 13:08 | <MikeSmith> | zcorpan: about the dev.w3.org diffs doc, I can't make it read-only but I can add a redirect |
| 13:09 | <zcorpan> | MikeSmith: ok |
| 13:09 | <zcorpan> | MikeSmith: i guess the new url for the w3c editor's draft is https://rawgithub.com/whatwg/html-differences/master/Overview.html |
| 13:10 | <zcorpan> | MikeSmith: or we could keep the old url but sync it from github maybe? |
| 13:10 | <zcorpan> | either way |
| 13:21 | <Ms2ger> | annevk; http://critic.hoppipolla.co.uk/r/86 |
| 13:31 | <hallvors> | Ms2ger: should I create a new branch for the rest of the XHR test changes (to let you/anne/whoever review and merge the current stuff)? |
| 13:32 | <hallvors> | I can either make a new branch and pull request or keep checking in to the current, depending on what you think is better |
| 13:32 | <Ms2ger> | I'm not going to review them, I don't think :) |
| 13:33 | <hallvors> | so "no opinion", basically? :) |
| 13:34 | <Ms2ger> | Yep |
| 13:39 | <zcorpan> | hallvors: i'll probably review your changes but i don't mind either way |
| 13:44 | <MikeSmith> | zcorpan: better to just redirect it, I think |
| 13:44 | <zcorpan> | MikeSmith: OK |
| 14:46 | <Ms2ger> | <bz> if I'm going to review the futures spec |
| 14:46 | <Ms2ger> | <bz> should I read the promises/A+ spec first? |
| 14:50 | <jgraham> | No |
| 16:17 | <lecuyer> | where are css decorators defined? |
| 16:58 | <MikeSmith> | oh man this is rich |
| 16:59 | <MikeSmith> | Opera suing Trond Hansen |
| 16:59 | <MikeSmith> | for giving away secrets to Mozilla |
| 16:59 | <nimbu> | MikeSmith: OMG |
| 17:00 | <MikeSmith> | maybe they should instead be suing him for not doing the actual job he was paid for even while he was working there |
| 17:00 | <MikeSmith> | or even bothering to, say, show up for work |
| 17:00 | <nimbu> | this is just |
| 17:00 | <nimbu> | fucked up |
| 17:00 | <nimbu> | so fucked up |
| 17:00 | <nimbu> | i dont know what to say |
| 17:00 | <MikeSmith> | nimbu: strange times |
| 17:00 | <nimbu> | sighhhhhh |
| 17:01 | <nimbu> | MikeSmith: i suppose you and I should be wary too :) |
| 17:01 | <MikeSmith> | heh |
| 17:01 | <odinho> | quite the shock yeah. |
| 17:01 | <MikeSmith> | yeah, look out! |
| 17:01 | <MikeSmith> | "describes himself as an artist, songwriter, and designer" |
| 17:01 | <nimbu> | ahahaha |
| 17:01 | <MikeSmith> | in that order, I bet |
| 17:02 | <MikeSmith> | to be fair I guess he did some years trying to get some UI innovations into Opera only to have Jon reject all of them |
| 17:03 | <MikeSmith> | so maybe he just gave up |
| 17:03 | <nimbu> | :( |
| 17:03 | <MikeSmith> | would be really ironic for Opera to sue him for "stealing" his own ideas that Opera management rejected |
| 17:03 | <nimbu> | gawddd |
| 17:04 | <nimbu> | everybody working for Opera please dont open your mouths |
| 17:05 | <MikeSmith> | new meme |
| 17:05 | <MikeSmith> | "Opera, Please Don't Sue Me" |
| 17:06 | <MikeSmith> | wait maybe this is the new business strategy |
| 17:07 | <nimbu> | :( |
| 17:07 | <MikeSmith> | wait for all Opera employees to implement new ideas at other companies |
| 17:07 | <MikeSmith> | then sue them |
| 17:07 | <nimbu> | MikeSmith: be careful they may sue you also |
| 17:08 | <MikeSmith> | s/Opera employees/former Opera employees/ |
| 17:08 | <MikeSmith> | nimbu: blood from a stone |
| 17:08 | <MikeSmith> | they are welcome to share my debts |
| 17:09 | <MikeSmith> | I already drank up all the profits I made from business ideas I stole from Opera |
| 17:09 | <nimbu> | ahahahhaha |
| 17:22 | <TabAtkins> | gsnedders: I'm using html5lib in Python2.7, but that's largely because the libraries I wanted seemed easiest to install there. On the other hand, I'm probably fine with just not receiving updates, so long as the Python2 version is archived somewhere I can point to. ^_^ |
| 17:23 | <gsnedders> | TabAtkins: It's not happening. |
| 17:24 | <gsnedders> | TabAtkins: It'd be nice for when I get around to rewriting the InputStream (as it avoids the one case we reparse currently), but we'll see how the ecosystem is then. |
| 17:24 | <gsnedders> | TabAtkins: Quite possibly will do that and just reparse under Py2. |
| 17:25 | <gsnedders> | TabAtkins: Or try and work out some hack to avoid it under Py2, dunno. |
| 17:26 | <SimonSapin> | gsnedders: is html5lib dropping python 2 support? |
| 17:26 | <gsnedders> | SimonSapin: "It's not happening". |
| 17:26 | <gsnedders> | SimonSapin: I was cursing yesterday I wish we could. |
| 17:26 | <SimonSapin> | ok, good :) |
| 17:26 | <gsnedders> | SimonSapin: Only thing that's at risk is 3.0/3.1 support |
| 17:27 | <gsnedders> | And that's mostly because it's untested, rather than anything fundemental. |
| 17:27 | <SimonSapin> | nobody uses 3.0 |
| 17:27 | <gsnedders> | Indeed. |
| 17:27 | <SimonSapin> | and I’m thinking of dropping 3.1 support in weasyprint and various libs |
| 17:27 | <SimonSapin> | so I wouldn’t miss it |
| 17:27 | <gsnedders> | Likely we'll drop "official" support but practically it's unlikely to break. |
| 17:28 | <TabAtkins> | I like Python 3. :/ |
| 17:28 | <SimonSapin> | TabAtkins: you still have 3.2 and 3.3 |
| 17:28 | <gsnedders> | TabAtkins: 3.0.3/1 aren't everything. :P |
| 17:28 | <TabAtkins> | Oh! Okay, never mind then. |
| 17:29 | <gsnedders> | TabAtkins: The main reason html5lib might drop old Py3 is the lack of testing on them. |
| 17:29 | <gsnedders> | We're well tested on 2.6/2.7/3.2/3.3 |
| 17:45 | <MikeSmith> | I wonder what "packability of the DOM code" means |
| 18:04 | <Garbee> | Can dialog elements be used outside of <th> and <dt> elements? The spec says they are where it *can* be used, but it doesn't say only may be used within. http://developers.whatwg.org/commands.html#the-dialog-element |
| 18:05 | <TabAtkins> | "Where flow content is expected". |
| 18:05 | <TabAtkins> | The weird special cases are because <th> and <dt> don't accept arbitrary flow content. |
| 18:06 | <TabAtkins> | So, any element with "Content Model: flow content;" can contain a dialog. |
| 18:09 | <Garbee> | Yea. I'd assume W3Schools simply used a table in their demo since that is pointed out as a use-case for a dialog. But their tip on it is wrong. |
| 18:14 | <TabAtkins> | Garbee: W3Schools is often wrong, and often terrible. Don't learn from them. ^_^ |
| 18:15 | <TabAtkins> | Use a better learning resource, like HTMLDog.com, or pretty much anything, anywhere. |
| 18:21 | <Garbee> | TabAtkins, nah, I was trying to figure out an issue someone reported on W3Fools. |
| 18:21 | <TabAtkins> | Ah, carry on then. |
| 18:21 | <Garbee> | I tend to read the spec itself and then learn implementation from seeing people do things. |
| 18:30 | <Garbee> | TabAtkins, Also, I feel obligated to say also that http://www.webplatform.org is a great doc resource. ;) That should be first to mind when recommending somewhere for people to learn from. |
| 18:30 | <Garbee> | (Yes, it still has issues but we are working on them.) |
| 18:33 | <Ms2ger> | Can you get rid of the references to initProgressEvent, then? |
| 18:33 | <Ms2ger> | And the other init*Events, for that matter |
| 18:42 | <Garbee> | Ms2ger, Were you talking to me about removing those references from WPD? |
| 18:44 | <Ms2ger> | Sounds like work on it? |
| 18:46 | <Garbee> | Well, we have references to it. But I don't see any reason to remove them. |
| 18:47 | <Ms2ger> | It's being removed from implementations |
| 18:49 | <Garbee> | It is a CR spec. So where is confirmation of it being removed? If it is being dropped then it is something I should bring up with the mailing list on how we should deal with it. |
| 18:50 | <Ms2ger> | It's not in the spec either: http://xhr.spec.whatwg.org/#interface-progressevent |
| 18:52 | <Garbee> | What isn't in the spec? |
| 18:52 | <jgraham> | Anyone know anything about pointer events? https://critic.hoppipolla.co.uk/r/90 isn't super-convincing at first glance but I don't know the spec |
| 18:53 | <Ms2ger> | assert_equals(typeof ev[name], "DOMString" |
| 18:53 | <Ms2ger> | No, not terribly convincing |
| 18:59 | <jgraham> | Hmm, I wonder who Cathy Chan is |
| 20:42 | <TabAtkins> | Hixie: How do you come up with such believable attack scenarios? |
| 20:43 | <Hixie> | is that sarcasm or sincere? :-) |
| 20:44 | <Hixie> | i didn't think it was that believable... |
| 20:44 | <TabAtkins> | Sincere! |
| 20:44 | <gsnedders> | "Being evil" is the answer Tarquin would give. |
| 20:44 | <Hixie> | TabAtkins: i dunno man |
| 20:45 | <Hixie> | anyone here have opinions on margin collapsing quirks? |
| 20:45 | <TabAtkins> | I might? |
| 20:46 | <Hixie> | i'm looking at https://www.w3.org/Bugs/Public/show_bug.cgi?id=15993 |
| 20:46 | <Hixie> | trying to work out whether to do it in some sort of CSS syntax, or in prose |
| 20:46 | <Hixie> | i'm thinking prose might be the only sane way to do it |
| 20:46 | <jgraham> | I assume zcorpan would have opinions |
| 20:46 | <jgraham> | If he was here |
| 20:47 | <Hixie> | he's made them known on the bug, luckily :-) |
| 20:47 | <jgraham> | Then I was right! |
| 20:47 | <jgraham> | Hurrah! |
| 20:47 | <jgraham> | ;) |
| 20:47 | <TabAtkins> | Okay, I don't have an opinion on this, except that it should be defined in Quirks, not in HTML. Put all that shit together. |
| 20:48 | <Hixie> | surely "quirks" shouldn't exist |
| 20:48 | <Hixie> | should just be in the various specs |
| 20:48 | <TabAtkins> | Sure it should - you have a nice, compact list of crazy exceptions. |
| 20:48 | <TabAtkins> | Rather than spreading them around. |
| 20:48 | <Hixie> | there's "quirks" in the html parser, and i'm pretty sure we don't want the html parser spec split into multiple files |
| 20:48 | <TabAtkins> | I mean, really individual quirks, sure, put them next to the stuff they're quirking. |
| 20:48 | <TabAtkins> | But margin collapsing in table cells? |
| 20:49 | <TabAtkins> | Sure, parsers are different. ^_^ |
| 20:49 | <Hixie> | almost the entire rendering section in the html spec is just a long list of "quirks" |
| 20:49 | <Hixie> | this is just one more in that section :-) |
| 20:51 | <TabAtkins> | Well, if it's expressible in CSS like Gecko does, then whatever. |
| 20:54 | <Hixie> | CSS uses proprietary selectors to express it |
| 20:54 | <TabAtkins> | :moz-only-whitespace isn't proprietary any longer - it's now :blank in the Selectors 4 draft. |
| 20:55 | <Hixie> | ooo |
| 20:58 | <jgraham> | blank? |
| 20:58 | <jgraham> | that's a... surprising name |
| 20:58 | <TabAtkins> | Needed a name that was the same as :empty, but not :empty. |
| 20:58 | <TabAtkins> | :blank is short and a close synonym, so whatever. |
| 20:59 | <jgraham> | Why "the same as empty"? |
| 20:59 | <jgraham> | It seems like expressing something different to :empty with a synonym for "empty" is an expressway to confusion |
| 21:00 | <TabAtkins> | Shrug, we got :empty wrong. |
| 21:00 | <TabAtkins> | But probably can't kill it. |
| 21:01 | <TabAtkins> | I think I'm supposed to track usage of it in Blink and see what pops out. |
| 21:01 | <jgraham> | So to make up for it you will get :blank wrong too? |
| 21:01 | <jgraham> | Interesting strategy |
| 21:01 | <TabAtkins> | Hm? |
| 21:01 | <jgraham> | s/get it worg/give it a bad name/ is you like |
| 21:01 | <jgraham> | *wrong |
| 21:02 | <jgraham> | Anyway, I think I should try sleeping or something |
| 21:02 | <jgraham> | *if |
| 21:02 | <jgraham> | (see) |
| 21:02 | <jgraham> | (sleeping++) |
| 21:04 | <Hixie> | man, i hope microsoft appreciates the pain i'm going through trying to test their browser |
| 21:07 | <Hixie> | there's like, no interop in edge cases around margin collapsing |
| 21:08 | <Hixie> | <style>html { background: purple; } body { background: lime; } div { margin: 1px; }</style><div><h1>Test</h1></div> |
| 21:08 | <Hixie> | different in every rendering engine |
| 21:08 | <lecuyer> | am I the only one who thinks :blank and :empty aren't that bad of names? |
| 21:09 | <Hixie> | firefox doesn't collapse even if the div has no margin, chrome/safari collapse if the div doesn't have a margin but do otherwise, IE doesn't give the <h1> margins regardless of the <div>'s |
| 21:10 | <Hixie> | man, IE tries hard to avoid giving margins to stuff at the top |
| 21:11 | <Hixie> | even with <body><div><span></span></div><div><h1> the h1 still has no margins unless i give the span a border |
| 21:12 | <Hixie> | hm, chrome/safari are pretty enthusiastic about this too |
| 21:13 | <Hixie> | hmmmm |
| 21:16 | <Hixie> | hypothesis: any UA-set margin that would collapse with the <html>'s top margin collapses to zero. |
| 21:16 | <Hixie> | (in IE) |
| 21:16 | Hixie | ponders how to disprove that hypothesis |
| 21:32 | <Hixie> | i cannot find any way to disprove this hypothesis |
| 21:32 | <Hixie> | could it really be this simple? |
| 22:03 | <Hixie> | TabAtkins: is there a CSS equivalent to :-moz-first-node/:-moz-last-node? (matches same as :first-child/:last-child but only if there's no non-whitespace text nodes before/after the node) |
| 22:12 | <Hixie> | man, describing elements that match :-moz-first-node is a maze of twisty negations |
| 22:13 | <lecuyer> | Hixie: is that meaning that with <div>here's text<span>hi</span></div> that `div span:-moz-first-node` wouldn't match? |
| 22:19 | <Hixie> | lecuyer: yeah |
| 22:20 | <Hixie> | anyone got a good term to mean "an element or a text node that is not merely inter-element whitespace"? |
| 22:21 | <lecuyer> | Hixie: "unfortunate" ;) |
| 22:24 | <Hixie> | I'm going with "purple" until someone has a better term. :-) |
| 22:26 | <lecuyer> | Hixie: are you trying to name a pseudo selector or describe TEXT_NODEs in a spec? |
| 22:27 | <Hixie> | just trying to describe "an element or a text node that is not merely inter-element whitespace" for spec purposes |
| 22:28 | <astearns> | Hixie: didn't you use 'palpable' for something similar? |
| 22:28 | <Hixie> | that's something else |
| 22:28 | <Hixie> | but yes |
| 22:29 | <Hixie> | unfortunately i went to the thesaurus and none of "palpable"'s synonyms are words i can use |
| 22:29 | <Hixie> | (https://www.w3.org/Bugs/Public/show_bug.cgi?id=15993 for context) |
| 22:33 | <astearns> | Hixie: how about 'substantial' |
| 22:34 | <Hixie> | that could work |
| 22:34 | <Hixie> | noted on the bug |
| 22:35 | <TabAtkins> | Hixie: There is no equivalent to :moz-first-node/last-node. |
| 22:44 | <lecuyer> | astearns: how do you feel about arbitrarily nested pseudo-elements? |
| 22:45 | <TabAtkins> | Hixie: The phrasing we use in CSS for "purple" is "not an anonymous inline containing only collapible whitespace". |
| 22:51 | <Hixie> | TabAtkins: hm, good point, white-space:pre should stop this too, huh |
| 22:51 | <Hixie> | though i guess gecko doesn't |
| 22:53 | <Hixie> | hm, no, gecko _is_ affected |
| 22:53 | <Hixie> | wtf |
| 22:55 | <MikeSmith> | .win 14 |
| 22:56 | <Hixie> | TabAtkins: so: |
| 22:56 | <Hixie> | A node is significant if it generates a box that is not an inline box |
| 22:56 | <Hixie> | containing only collapsible whitespace. |
| 22:56 | <Hixie> | ...? |
| 22:56 | <zewt> | let's let win 8 run its course |
| 22:58 | <TabAtkins> | anonymous inline box |
| 22:58 | <TabAtkins> | ("inline box" also describes inline elements) |
| 22:59 | <Hixie> | is it anonymous if it has an explicit node? |
| 23:00 | <Hixie> | so: |
| 23:00 | <Hixie> | A node is significant if it is an element or if it generates a box that is not |
| 23:00 | <Hixie> | an anonymous inline box containing only collapsible whitespace. |
| 23:00 | <Hixie> | ...? |
| 23:00 | <TabAtkins> | anonymous boxes come from bare text only. |
| 23:00 | <Hixie> | bare text has a node :-) |
| 23:00 | <Hixie> | aren't table rows and such anonymous too? |
| 23:00 | <Hixie> | the ones that are implied? |
| 23:01 | <TabAtkins> | Those aren't anonymous inlines. ^_^ |
| 23:01 | <Hixie> | you said "anonymous boxes"! :-P |
| 23:01 | <TabAtkins> | Bah. |
| 23:01 | <Hixie> | anyway the dfn above is right, right? |
| 23:02 | <TabAtkins> | If you can use HTML node concepts, just say "element node, or text node that doesn't just contain collapsible whitespace". |
| 23:04 | <Hixie> | that's what i had, but as you made me realise, it's wrong |
| 23:04 | <Hixie> | because what matters is whether the white-space actually gets collapsed or not |
| 23:04 | <Hixie> | that is, white-space:pre matters |
| 23:06 | <TabAtkins> | Yeah, wrong word. I have the right wording in antoher spec. One sec. |
| 23:07 | <TabAtkins> | http://dev.w3.org/csswg/selectors/#the-blank-pseudo "characters affected by whitespace processing". |
| 23:07 | <TabAtkins> | Oh wait, you *want* white-space pre to matter? |
| 23:07 | <Hixie> | apparently |
| 23:08 | <TabAtkins> | In that case, "collapsed whitespace". |
| 23:08 | <Hixie> | (i mean, what i actually want is neither here nor there on this issue) |
| 23:08 | <TabAtkins> | "doesn't contain only collapsed whitespace" |
| 23:09 | <Hixie> | as in: |
| 23:09 | <Hixie> | A node is significant if it is an element or if it is a Text node that does not |
| 23:09 | <Hixie> | contain only collapsed whitespace. |
| 23:09 | <Hixie> | ..? |
| 23:10 | <TabAtkins> | Now it's easier to phrase it in positive terms: "or if it is a Text node that contains anything other than collapsed whitespace". |
| 23:11 | <Hixie> | is "collapsed whitespace" actually defined anywhere? http://www.w3.org/TR/css3-text/#white-space-rules vaguely defines "collapsible", but it seems what i actually want is to invoke hte word "removed" from that algorithm |
| 23:11 | <Hixie> | "A node is significant if it is an element or if it is a Text node that contains preserved white space or text that is not collapsible" ? |
| 23:12 | <Hixie> | "A node is significant if it is an element or if it is a Text node that contains preserved white space or characters that are not collapsible white space" ? |
| 23:12 | <Hixie> | with [CSS] at the end :-) |
| 23:13 | <Hixie> | (Note that this means :-moz-empty and :blank aren't the same after all) |
| 23:13 | <Hixie> | (unless i'm mistaken) |
| 23:14 | <TabAtkins> | i like the last one, though it's verbose. It feels pretty precise. |
| 23:14 | <TabAtkins> | You mean :-moz-only-whitespace? |
| 23:14 | <Hixie> | yeah |
| 23:14 | <Hixie> | i'm wrong though |
| 23:15 | <TabAtkins> | Yes, that is a different condition than Moz's - the selector *cannot* depend on whether white-space:pre is set. |
| 23:15 | <TabAtkins> | It can only rely on whether characters in the content are "normally" collapsible. |
| 23:15 | <Hixie> | the selector doesn't seem to depend on white-space, now i'm just confused |
| 23:16 | <Hixie> | oh duh |
| 23:17 | <Hixie> | i am dumbo |
| 23:17 | <TabAtkins> | Heh. |
| 23:17 | <Hixie> | had a newline, made it look like it was margin plus the line with whitespace |
| 23:18 | <zewt> | wow, new gmail is even worse than i thought |
| 23:18 | <zewt> | i try to scroll down past a compose box, and it scrolls the whole compose instead of letting me leave the compose box scrolled where it is and scroll the whole box |
| 23:18 | <zewt> | gripegripe |
| 23:19 | <Hixie> | WebKit/Blink are affected by white-space, but Gecko isn't |
| 23:19 | <Hixie> | interestingly IE isn't either; I really think my hypothesis above is correct |
| 23:20 | <astearns> | lecuyer: I have started to become convinced that pseudo-element use cases are better served by HTML templates |
| 23:20 | <Hixie> | TabAtkins: amusingly i tried to give you credit for the big breakthrough i had an now it just looks in the bug like you were wrong, sorry about that :-) |
| 23:20 | <astearns> | lecuyer: CSS doesn't do structure, HTML does. Why invent CSS structure when you can re-use HTML? |
| 23:21 | <TabAtkins> | zewt: I find the new compose *really* useful. It's an interesting behavioral mix of "as tall as all the contents" and "no taller than the screen", which works really well for me most of the time. |
| 23:21 | <TabAtkins> | zewt: In the case you're complaining about, I pop the message out instead, because that's typically what I really want to do anyway. |
| 23:22 | <zewt> | i edit replies nonlinearly, and i often want to skim down to a reply (past the point where the compose box landed) then go back to what I was writing, but now I can't leave the compose box where it is |
| 23:22 | <zewt> | i guess, or i can leave the cursor in place and hit an arrow key to scroll to it |
| 23:22 | <TabAtkins> | That works too (and I'm already used to doing that for text editors, when I need to quickly check another section of the spec for the text I'm currently writing). |