| 00:06 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#server-sent-events updated |
| 00:06 | <Hixie> | comment away. brb. |
| 00:17 | <annevk> | having custom events name was a very useful feature |
| 00:19 | <Hixie> | well, it's gone |
| 00:19 | <Hixie> | opera never supported it anyway, as i understand it |
| 00:19 | <annevk> | we supported custom event names |
| 00:19 | <Hixie> | (and it was way more complexity than necessary) |
| 00:19 | <Hixie> | oh? |
| 00:19 | <Hixie> | oh but not known events? |
| 00:19 | <Hixie> | like, foo-click but not click? |
| 00:19 | <annevk> | we didn't do the interface crap |
| 00:20 | <annevk> | but that's not really the point |
| 00:20 | <Hixie> | *shrug* |
| 00:20 | <annevk> | you'd want several messages on a single stream to dispatch on different listeners |
| 00:20 | <Hixie> | if you only do one interface, why bother with different names. just do manual dispatch. |
| 00:20 | <annevk> | that requires putting that data in "data" and parsing it manually |
| 00:20 | <annevk> | that's not nice |
| 00:21 | <Hixie> | it's easy |
| 00:21 | <Hixie> | there's even an example in the spec |
| 00:21 | <Hixie> | just hit .split() or some such |
| 00:21 | <Hixie> | or substr |
| 00:22 | <annevk> | why not have a convenient api on the client? |
| 00:22 | <annevk> | the additional cost is small |
| 00:23 | <Hixie> | it's not that convenient. you suddenly have to start using addEventListener instead of onmessage="", you have to keep track of two things in the UA, etc |
| 00:23 | <Hixie> | (the spec as defined makes it possible to define this in v2, mind you) |
| 00:24 | <annevk> | i think that every usage this api had used that feature |
| 00:27 | <annevk> | the other stuff looks good though |
| 00:40 | <Hixie> | annevk: fine, i'll support alternative names :-P |
| 00:51 | <Hixie> | annevk: what do you want me to have happen when the event name doesn't match the NCName production? |
| 00:52 | <Hixie> | and should the event name be "sticky", or should it reset to 'message' with each block? |
| 02:03 | <takkaria> | Hixie: http://diveintomark.org/archives/2008/02/19/all-these-years#comment-11314 |
| 02:04 | <Hixie> | already fixed |
| 02:04 | <Hixie> | mark pointed it out tome |
| 02:05 | <Hixie> | (mark and i work together) |
| 02:06 | <takkaria> | ah |
| 02:06 | <takkaria> | noted for future reference |
| 02:06 | <Hixie> | wow, the comments on that blog entry are scary |
| 02:07 | <Hixie> | some of them anyway |
| 02:07 | <Hixie> | mostly those from people who don't seem to be able to read... |
| 02:07 | <Hixie> | i'm also amused by the number of people who read mark's post as being a comment against the spec... |
| 02:07 | <takkaria> | the problem with comment forms is that they start appearing on the screen before you've finished rading |
| 02:08 | <Hixie> | heh |
| 02:08 | <takkaria> | *reading |
| 02:08 | <takkaria> | we need a screen-break-before CSS property to avoid that |
| 02:08 | <Hixie> | heh |
| 02:41 | <dglazkov> | Hixie, you there? |
| 02:42 | <Hixie> | yo |
| 02:44 | <dglazkov> | can you help me figuring out a db API bit? |
| 02:44 | <Hixie> | sure |
| 02:44 | <dglazkov> | If the Database object that the SQLTransaction object was created from has an expected version that is neither the empty string nor the actual version of the database, then mark the statement as bogus. (Error code 2.) |
| 02:44 | <dglazkov> | how can this happen? |
| 02:45 | dglazkov | sees no light |
| 02:45 | dglazkov | needs to see light |
| 02:45 | <Hixie> | if another page changes the version of teh database |
| 02:45 | <dglazkov> | interesting |
| 02:47 | <dglazkov> | so, I either need to read version value at each preflight or keep track of all version changes in the implementation |
| 02:47 | <dglazkov> | did that make any sense? |
| 02:51 | <Hixie> | yeah |
| 02:51 | <dglazkov> | and webkit guys did the latter |
| 02:51 | <dglazkov> | in their impl. |
| 02:51 | <dglazkov> | thanks! |
| 02:51 | <dglazkov> | that's all I needed |
| 02:51 | <Hixie> | basically whenever the version changes you need to make anything that's happening stop if the version no longer matches |
| 02:51 | <Hixie> | np |
| 02:51 | <Hixie> | hth |
| 02:51 | <dglazkov> | it definitely h |
| 02:51 | <dglazkov> | :) |
| 03:43 | <jruderman> | Hixie: do you have an opinion on https://bugzilla.mozilla.org/show_bug.cgi?id=395110 ? |
| 05:16 | <markp_> | jruderman: ping |
| 05:16 | <Hixie> | holy machrel, microsoft actually sent feedback |
| 05:16 | <jruderman> | markp_: pong |
| 05:16 | Hixie | falls off his chair |
| 05:17 | <Hixie> | jruderman: i'm in favour of honouring content-type |
| 05:17 | <markp_> | if you had the ability to SELECT * FROM INTERNET, including markup and HTTP headers, how would you go about testing the condition described in https://bugzilla.mozilla.org/show_bug.cgi?id=395110 |
| 05:17 | <Hixie> | but if that's not an option, i'll spec the other behaviour |
| 05:17 | <jruderman> | i hope you fell off of your chair from laughing, not from your chair being possessed by steve ballmer |
| 05:17 | <Hixie> | not laughing |
| 05:17 | <Hixie> | shock |
| 05:17 | <Hixie> | anyway. afk bbl |
| 05:17 | <jruderman> | ok |
| 05:18 | <markp_> | i mean, testing for the presence of that mismatch in a web page |
| 05:18 | <markp_> | every web page |
| 05:18 | <markp_> | to see how common the problem was |
| 05:19 | <jruderman> | that would be neat. can you also look at the contents of the file itself to guess which mime type is "correct"? |
| 05:20 | <markp_> | hmm, probably not |
| 05:21 | <markp_> | or at least, that would be a harder problem |
| 05:21 | <markp_> | i guess that would be required, though |
| 05:22 | <jeremyb> | Hixie: microsoft's comments are public? |
| 05:22 | <jruderman> | sicking suggests testing not for exact matches, but for whether the type attribute and the content-type would result in the same plugin being executed |
| 05:23 | <jruderman> | bz suggests ignoring <object>s that have a classid attribute |
| 05:25 | <markp_> | would it be helpful to know on how many pages the type attribute and the content-type http header on the target page differ? |
| 05:25 | <jruderman> | can you join #developers on irc.mozilla.org, which is where sicking and bz are? :) |
| 05:25 | <markp_> | without sniffing to see which one is correct |
| 05:25 | <markp_> | actually i'm about to retire for the night |
| 05:25 | <markp_> | but let's pick this up tomorrow |
| 05:26 | <jruderman> | having example URLs, and knowing what the mismatches are, would be more useful than just knowing the number of sites |
| 05:26 | jeremyb | wonders if markp_ is considering adding a task to some google botnet :) |
| 05:26 | <markp_> | a sampling of example urls is within my power |
| 05:26 | <markp_> | jeremyb: yes, i'm looking for ideas for simple map-reduce programs |
| 05:26 | <markp_> | to teach myself how to write them |
| 05:27 | <markp_> | bonus points for actually injecting facts into a discussion |
| 05:27 | <markp_> | but mostly just to teach myself how to write them |
| 05:27 | markp_ | wonders if i could sort the results by pagerank |
| 05:27 | <markp_> | pretty sure i could |
| 05:28 | jeremyb | reads up on map-reduce |
| 05:28 | <markp_> | it's not a big secret, we've published numerous whitepapers |
| 05:29 | <jeremyb> | yeah, there's a wiki page and a google labs page |
| 05:29 | <markp_> | http://www.google.com/search?q=mapreduce+site%3Alabs.google.com |
| 05:29 | <markp_> | yeah |
| 05:30 | <markp_> | been at google almost a year and have never written one |
| 05:30 | <markp_> | there's a first time for everything |
| 09:11 | <Philip`> | jeremyb: http://lists.w3.org/Archives/Public/public-html-comments/2008Feb/0024.html looks like the public comments |
| 09:12 | <annevk> | funny that they initially tried sending them to the WHATWG list |
| 09:12 | Philip` | guesses that got stuck in the non-member moderation eternity |
| 09:12 | <annevk> | yeah |
| 09:21 | <hsivonen> | zcorpan: thanks |
| 09:28 | <annevk> | Philip`, it just got through |
| 09:28 | annevk | wonders if Hixie waved his magic wand |
| 09:33 | <Philip`> | Ah, it's easier to read when it's displayed as HTML rather than plain text |
| 09:51 | <annevk> | http://diveintomark.org/archives/2008/02/21/the-bolero-of-troll :) |
| 09:52 | <Hixie> | wow, he posted it |
| 09:52 | <Hixie> | i didn't think he'd ever post that |
| 09:52 | <Hixie> | go mark |
| 09:59 | <hsivonen> | markp++ |
| 10:06 | <Hixie> | what's his comment policy? |
| 10:07 | <annevk> | i think he disables comments now and then |
| 10:07 | <Hixie> | k |
| 10:08 | <hsivonen> | it seems to me that his comment disabling works like anne's. when it's obvious ahead of time that the anticipated comments would require too much refuting, the comments are disabled :-) |
| 10:21 | <annevk> | Hixie, <event-source> is still being considered for removal in the spec but your comments suggest otherwise |
| 10:21 | Lachy | wonders why text/event-stream was chosen over application/event-stream |
| 10:21 | <annevk> | Hixie, I'll ask the folks in Opera regarding the need for RemoteEventTarget |
| 10:22 | <annevk> | Lachy, it's a text format? |
| 10:22 | <annevk> | and it's shorter :) |
| 10:23 | zcorpan | thinks we should go back to text/xml, text/javascript, etc |
| 10:23 | <annevk> | yes |
| 10:23 | <Philip`> | text/xhtml+xml |
| 10:23 | <zcorpan> | Philip`: no, just text/xml |
| 10:24 | <Philip`> | text/pbm |
| 10:24 | <hsivonen> | the MIME folks at the IETF are not doing anyone any good by sticking to email backwards compat in the HTTP context |
| 10:24 | <Philip`> | (or text/ppm is more useful) |
| 10:24 | <Hixie> | annevk: updated markers. but feel free to do that yourself too. :-) |
| 10:24 | <Hixie> | Lachy: for the reasons anne gave |
| 10:24 | <annevk> | Hixie, I'm still waiting for an Opera build with a fix :) |
| 10:24 | <Hixie> | heh |
| 10:29 | <Lachy> | I just feel uncomfortable with text/* since RFC 2046 and 2616 define default charsets (US-ASCII and ISO-8859-1, respectively) in the absense of a charset parameter. Although, those specs need to be updated to remove that nonsense anyway |
| 10:29 | <Hixie> | HTTP is changing to not have a default |
| 10:29 | <Lachy> | oh good |
| 10:30 | <Lachy> | then problem solved :-) |
| 10:30 | <Hixie> | and i don't see why we can't define defaults for text/ types on a per-type basis if we can do to for the other types. it's also what we've done so far anyway. |
| 10:31 | <Lachy> | yeah, that's how it should be |
| 10:32 | <Hixie> | man, a lot of feedback asks for <lh> |
| 10:32 | <Hixie> | i guess i should deal with <figure> feedback first and make <figure> take lists |
| 10:32 | <Hixie> | that would solve the problem of <lh> |
| 10:32 | <Lachy> | is <lh> a list header? |
| 10:32 | <Hixie> | yeah |
| 10:33 | <Lachy> | <figure> should take just about anything |
| 10:33 | <Hixie> | agreed |
| 10:33 | <Hixie> | we need to fix the caption issue though |
| 10:33 | <Hixie> | since apparently <legend> isn't good enough for some people |
| 10:33 | <Lachy> | oh right |
| 10:34 | <Hixie> | though i'm very unhappy about the idea of introducing a 12 element for marking up titles |
| 10:34 | <Lachy> | that's cause it makes it difficult to use a figure within a fieldset |
| 10:34 | <annevk> | nice, the SVG WG is making an errata for getSVGDocument() to make it identical to contentDocument |
| 10:34 | <Hixie> | (the 11 existing ones being <caption>, <legend>, <label>, <h1>-<h6>, <header>, and <title>) |
| 10:35 | <Lachy> | label isn't really a title though |
| 10:36 | <Hixie> | can't use caption and legend because parsers drop them. can't use label because that screws up forms. can't use h1-h6 or header as it screws up outlining. can't use title as it has special parsing behaviour. |
| 10:36 | <Hixie> | <h1>-<h6> also have unfortunate styling behaviour right now |
| 10:36 | <Hixie> | oh, add <th> to the list. |
| 10:36 | <Hixie> | so this would be a 13th element for headers/titles/whatever you call them. |
| 10:39 | <annevk> | <dt> is sort of similar too |
| 10:42 | <hsivonen> | all of those need to be generalized to <object role='...'> |
| 10:46 | <Hixie> | ok everyone's homework now is to come up with a solution for <figure> that introduces a caption without introducing a new element, without using anything that can be mistaken for prose content, without breaking forms or outlines, with a good default presentation, and that is compatible with styliing in legacy UAs. |
| 10:47 | <Hixie> | meanwhile i'm going to bed. |
| 10:47 | <Hixie> | nn |
| 11:07 | <annevk> | g'night |
| 11:13 | <roc> | woah |
| 11:13 | <roc> | IE team feedback! |
| 11:13 | <annevk> | :) |
| 11:25 | <Philip`> | <table role="figure"><tr><td><img src="foo.png"><tr><th>Caption</table> |
| 11:27 | <hsivonen> | Sun hires Nick Kew |
| 11:44 | <Lachy> | Philip`, <table role="figure"><caption>Caption</caption><tr><td><img src="foo.png"></table> would be better |
| 11:47 | <Philip`> | That wouldn't give the right presentation, since usually captions go below the figure |
| 12:03 | <Lachy> | Philip`, table { caption-side: bottom; } |
| 12:03 | <annevk> | spammers have found a new way to by pass spam filters |
| 12:03 | <annevk> | "GenericPharmacyProducts" |
| 12:04 | <annevk> | "FriendlySupportAllProductsHealthyLife" smart |
| 12:05 | <Philip`> | Lachy: Doesn't work in legacy UAs |
| 12:05 | <Lachy> | which legacy UAs? |
| 12:05 | <Philip`> | IE6, Opera 9.2 |
| 12:06 | <Philip`> | Hmm, caption{caption-side:bottom} works in Opera |
| 12:34 | <zcorpan> | Philip`: table{caption-side:bottom}caption{caption-side:inherit} works in 9.2 too, so apparently we had a redundant rule in the ua style sheet or something |
| 12:48 | <hsivonen> | Philip`: do you have Validator.nu installed locally? Did you check whether it can fetch documents from IPv6 hosts if IPv6 is being routed? |
| 12:55 | <Philip`> | hsivonen: I do; I think I remember it being able to fetch from http://[::1]/ correctly (but I don't have any proper IPv6 network access) |
| 12:55 | <hsivonen> | Philip`: ok. thanks |
| 12:55 | <Philip`> | I would test it again to make sure I'm not misremembering, but I get "Malformed spec: Expected dt to be categories dt but it was not." |
| 12:57 | <hsivonen> | Philip`: you need --html5load=http://about.validator.nu/spec2.html until I fix the source of the problem |
| 13:02 | <Philip`> | Aha, thanks |
| 13:03 | <Philip`> | http://localhost:8888/?doc=http://[::1]/ does work fine |
| 13:03 | <hsivonen> | Philip`: thanks |
| 13:04 | <Philip`> | (but I still have no IPv6 routing to anywhere non-local) |
| 13:07 | <Philip`> | Actually I can do http://localhost:8888/?doc=http://[::ffff:66.249.91.99]/ which works, but I don't know where that's doing the magical translation to IPv4 |
| 14:11 | <Dashiva> | I wonder if there's room for ancestor/precending sibling selectors in the selector API, or if it's going to stick to the CSS one-way-street approach |
| 14:34 | <Philip`> | Seems easier to use a combination of selectors API + JS DOM if you want to do fancier things |
| 14:35 | <Philip`> | (document.querySelector(':target').parentNode.className += ' highlighted' etc) |
| 14:37 | <zcorpan> | or xpath |
| 15:07 | <hsivonen> | I'm reading the IPv6 slides linked from Slashdot |
| 15:08 | <hsivonen> | it seems that the definers of IPv6 really did not have a good here-to-there transition plan |
| 15:12 | <Philip`> | When people are worrying about internet routers running out of memory to store an exponentially-growing number of routes, it seems not the most wonderful of ideas to need double the number of routes to support IPv6 as well as IPv4 |
| 15:13 | <Philip`> | (since it's not like IPv4 is going to go away even after IPv6 is widely supported) |
| 15:13 | <hsivonen> | Philip`: did you see slide #45 already? |
| 15:14 | <Philip`> | I haven't seen any of them yet |
| 15:14 | Philip` | looks |
| 15:15 | <zcorpan> | do we need an IP5? |
| 15:15 | <hsivonen> | zcorpan: looks like we would have needed IP5 ten years ago |
| 15:16 | <Philip`> | It's hard enough trying to deploy an IPv4.01 |
| 15:22 | Philip` | wonders how much people will be willing to change IPv6 to make transitions easier, and how much they'll claim they can't change it because it'll break compatibility with existing IPv6 implementations |
| 15:23 | <zcorpan> | Philip`: propose changes and see what happens :) |
| 15:24 | <hsivonen> | Philip`: the slide author argues that IPv6 should be frozen now and the IETF should stop adding features. |
| 15:25 | <Philip`> | I know far too little to be able to make sensible proposals :-) |
| 15:26 | Philip` | knows a bit more about routing now than he used to, but nobody here seems very interested in IPv6 and we're just looking at IPv4 routing protocols |
| 15:41 | <Philip`> | hsivonen: (Did you mean #47 rather than #45?) |
| 15:42 | <hsivonen> | Philip`: no, #45 IVTF (sic.) vs. Reality |
| 15:47 | <hsivonen> | hmm. looks like the V is not a typo |
| 15:47 | <Philip`> | Hmm, it looks like "IV[endor]TF" is a term used solely by Randy Bush |
| 15:48 | <Philip`> | Ah, like what you said |
| 15:49 | <hsivonen> | Philip`: google finds others using it |
| 15:50 | <Philip`> | Oh, I don't see any others in the first ~30 results on Google |
| 15:58 | <zcorpan> | http://ejohn.org/blog/selectors-that-people-actually-use/ -- would be nice to review which selectors are used in css |
| 16:01 | <Philip`> | http://www.potaroo.net/ispcol/2008-02/tui.html sounds more optimistic about using IPv6 in an IPv4 world |
| 16:02 | <Philip`> | zcorpan: http://www.triin.net/2006/06/12/CSS#figure-30 and http://www.triin.net/2006/06/12/CSS#figure-31 ? |
| 16:02 | <SadEagle> | Philip`: there is a non-trivial amount of HW outthere which has problems with AAAA queries... |
| 16:04 | <Philip`> | SadEagle: What kind of problems do you mean? |
| 16:06 | Philip` | once had problems with accessing ietf.org, because his computer supported IPv6 and so it used the AAAA response for that domain, and his network didn't support IPv6 so it had to time out and then retry with IPv4 before it'd get anywhere |
| 16:07 | <SadEagle> | Philip`: some routers return bogus IP addresses. |
| 16:07 | <Philip`> | By "routers" do you mean "DNS servers"? |
| 16:08 | <SadEagle> | Sort of. I mean the local firewall + routers boxes, that tend to take over DNS themselves. |
| 16:08 | <Philip`> | Ah, okay |
| 16:08 | <SadEagle> | Used to be that the DNSs of some ad sites would have problems, too. Not sure what happened w/that now.. |
| 16:11 | Philip` | uses Windows Server 2003 Internet Connection Sharing, which seems to handle it perfectly well :-) |
| 16:11 | <annevk> | http://www.paciellogroup.com/blog/?p=39 |
| 16:11 | <zcorpan> | Philip`: thanks |
| 16:12 | <zcorpan> | Philip`: so #id is a lot less common in css than in js |
| 16:13 | <Philip`> | zcorpan: It's hard to compare the numbers, since the CSS one is number of pages with >= 1 occurrence, while the JS one is total number of occurrences |
| 16:14 | <zcorpan> | ah |
| 16:14 | zcorpan | didn't read carefully |
| 16:14 | <Camaban> | #id selectors is gimped by some cms'/frameworks as well, they use id's for their own purplses, which effectively makes them useless for css, issues I've run up against with JSF and some ASP.NET stuff |
| 16:14 | <Camaban> | *purposes |
| 16:15 | <Philip`> | Incidentally, I always get slightly worried when people say "51.290%" with a sample of 2790 - that's at least two too many decimal places |
| 16:18 | SadEagle | would guess that element + id + classname + descendant are the most widely used ones, w/o any stats, and with a far worse sample :-) |
| 16:19 | <Camaban> | from helping people with css, people often don't know about the more advanced selectors, and even if they do, they probably assume they won't work in IE :) |
| 16:20 | <Philip`> | It took me years to discover the existence of "E F" descendant selectors |
| 17:39 | <hsivonen> | use case for <font color>: http://blogs.msdn.com/ie/archive/2008/02/21/the-internet-explorer-8-user-agent-string.aspx |
| 17:43 | <Philip`> | Shouldn't that be <em>? |
| 17:44 | <Philip`> | or <strong> |
| 17:44 | <Philip`> | (I can never tell the difference...) |
| 18:21 | <takkaria> | Philip`: I thnk |
| 18:21 | <takkaria> | er |
| 18:21 | <takkaria> | Philip`: I think that <mark> is probably the most appropriate |
| 18:22 | <SadEagle> | <ins>/<del> ? ;-) |
| 19:28 | <webben> | yeah, with the current semantics, mark would be most appropriate since it's in a blockquote. |
| 19:29 | <webben> | can't see how it's a use case for font color. |
| 19:58 | Hixie | comments on http://blog.mozilla.com/rob-sayre/2008/02/21/thoughts-on-whatwg/#comments |
| 20:05 | <othermaciej_> | the original post there is an odd sentiment |
| 20:06 | <othermaciej> | particularly the premise that it would be better for Mozilla to extend web technologies unilaterally rather than collaborate inside a standards process |
| 20:08 | <othermaciej> | though I do think some of the more complex parts should possibly be dropped if they don't get implementation traction |
| 20:08 | <othermaciej> | but that's a totally separate question from things that are seeing multiple active implementations |
| 20:11 | <jgraham> | I don't think it's constructive to make a list of "things I personally think should be dropped" and not provide any justification |
| 20:13 | <roc> | FWIW I agree... |
| 20:13 | <hsivonen> | jgraham++ |
| 20:14 | <roc> | er, I agree with you guys |
| 20:15 | <othermaciej> | roc: I inferred that from your comment on rsayre's blog |
| 20:16 | <othermaciej> | WHATWG has been a remarkably effective forum for cross-vendor collaboration on improving web technology |
| 20:16 | <othermaciej> | it's pretty clear to me that it is *way* better than either stopping progress or each vendor doing things unilaterally in their own way |
| 20:16 | <othermaciej> | even if it results in a "bloated" spec |
| 20:17 | <othermaciej> | and I know from experience that it's hard to deliver that level of quality even for a much smaller chunk of the spec |
| 20:19 | <Hixie> | it's a full time job |
| 20:19 | <Hixie> | as soon as people employing spec editors realise that, things will improve :-) |
| 20:19 | <jgraham> | I was about to say, we've been very lucky that Hixie has been paid to work on it full time |
| 20:19 | <Hixie> | yes |
| 20:19 | <Hixie> | i have been very very lucky |
| 20:21 | <roc> | who are the great spec editors who are unemployed? |
| 20:21 | <Hixie> | to my knowledge there aren't any |
| 20:21 | <Hixie> | the problem is companies won't let people work on specs full time |
| 20:22 | <Hixie> | they try to "get more value" out of them by e.g. making them do QA work |
| 20:22 | <Hixie> | e.g. opera wouldn't let me do 100% spec work, only 50% spec work and 50% qa |
| 20:22 | <Hixie> | that's one reason i quit |
| 20:22 | <jgraham> | It's not clear to me there is even a huge pool of great spec editors who are employed |
| 20:22 | <Hixie> | yeah well that's a problem too |
| 20:23 | <Hixie> | the problem there is that you pretty much have to fall into this job after having gotten your hands dirty in a variety of more practical things |
| 20:23 | <Hixie> | and that you have to not care that it's not an especially lucrative career |
| 20:28 | <roc> | surely it's about the same as most other browser-related jobs |
| 20:30 | <Hixie> | in my experience software engineering has a much higher ceiling in terms of pay increases than spec writing does |
| 20:34 | <roc> | ok, here's the plan. We'll get an article in TIME about you, titled "Is Ian Hickson the most powerful man on the Web?" That should fix it |
| 20:35 | <krijn> | Google should allow more people to be powerful on the web :) |
| 20:39 | <Hixie> | roc: hah |
| 20:41 | gsnedders | runs in fear from the great Hixie |
| 20:42 | <roc> | but seriously, if you need outside feedback on how awesome you are to impress your managers, I'm sure that could be obtained |
| 20:43 | <Hixie> | eh |
| 20:43 | <Hixie> | thanks for the offer |
| 20:43 | <Hixie> | er, "heh", not "eh" |
| 20:43 | <Hixie> | i might take you up on that at our next eval cycle :-) |
| 21:19 | <Hixie> | othermaciej: (you got a reply btw) |
| 21:21 | <csarven-> | "Any content model that expects prose content also expects phrasing content." hmm |
| 21:23 | <csarven-> | Prosing content doesn't have to include <p> correct (i.e., It could be <ul>)? |
| 21:23 | <csarven-> | Err. *Prose content |
| 21:27 | <Hixie> | how do you mean? |
| 21:30 | <csarven-> | If I understan it correctly, phrasing content is generally referring to a set of paragraphs, whereas prose content is referring to a set of elements that are composed of some sort of content elements (including paragraphs). |
| 21:32 | <csarven-> | Prose_Content = { Phrasing_Content, ... } is the way I interpret it. Is this correct? If so, it is not necessarily true that prose content must have a phrasing content as it may contain something else (e.g. an unordered list) -- hence my confusion with the original statement. |
| 21:36 | <csarven-> | More specifically what is "content model" referring to? |
| 21:43 | <othermaciej> | Hixie: to what? |
| 21:43 | <Hixie> | http://blog.mozilla.com/rob-sayre/2008/02/21/thoughts-on-whatwg/#comment-7648 |
| 21:44 | <Hixie> | csarven-: your interopretation is wrong |
| 21:44 | <Hixie> | csarven-: phrasing content = any element claiming to be phrasing content, any element claiming to be prose content, and text |
| 21:44 | <Hixie> | csarven-: prose content = any element claiming to be prose content |
| 21:44 | <Hixie> | where by "claiming to be" i mean defined as such by the element's definition in the spec |
| 21:45 | <Hixie> | e.g. p is prose content, span is prose and phrasing content |
| 21:45 | <Hixie> | bbiab, going to work |
| 21:49 | <othermaciej> | I re-replied |
| 21:49 | <othermaciej> | I must say though that the comment responding to mine did not really address my point at all |
| 21:50 | <othermaciej> | (not sure why my latest reply isn't showing up) |
| 21:50 | <aroben> | othermaciej: remove the fragment from the URL |
| 21:50 | <othermaciej> | I did |
| 21:51 | <othermaciej> | aroben: do you see anything here past rsayre's last comment? <http://blog.mozilla.com/rob-sayre/2008/02/21/thoughts-on-whatwg/>; |
| 21:51 | <aroben> | othermaciej: yes |
| 21:51 | <othermaciej> | hmmm |
| 21:51 | <aroben> | Thezilch: oh |
| 21:51 | <aroben> | othermaciej: |
| 21:51 | <aroben> | othermaciej: remove the trailling / |
| 21:51 | <aroben> | othermaciej: this website's wacky |
| 21:52 | <othermaciej> | aroben: indeed |
| 21:52 | <othermaciej> | aroben: thanks for helping me work around it |
| 21:52 | <aroben> | othermaciej: anytime |
| 21:53 | <gavin_> | bah, silly caching by the netscalar |
| 21:53 | <gavin_> | I usually just add ?pie when that happens |
| 21:53 | <gavin_> | everything is better with ?pie |
| 21:56 | <csarven-> | [16:50:12] <Hixie> e.g. p is prose content, span is prose and phrasing content -- This confuses me. Can you provide more examples? What is <ul>, <li>, <div>, <em>, <abbr>? |
| 21:58 | csarven- | looks it up |
| 23:44 | <Hixie> | csarven-: it says in the spec, right at the top of each element definition |