| 00:06 | Yuhong | working my series about the history of CSS |
| 00:06 | Yuhong | working on my series about the history of CSS |
| 00:07 | <Yuhong> | People have forgotten about the effects of the Netscape monopoly from 1995. |
| 00:07 | <erlehmann> | Hixie, are there people who hate <time>? |
| 00:07 | <erlehmann> | or is it just not used? |
| 00:07 | <Hixie> | <time> hasn't been particularly well-loved |
| 00:08 | <erlehmann> | or are you thinking about general machine readable equivalents like geodata usw.? |
| 00:08 | <erlehmann> | i only use it for automagic chat log timestamp markup and blog post creation timestamps. |
| 00:09 | <erlehmann> | i hereby propose a @spacetime attribute to the <time> element, to give a local frame of reference. |
| 00:10 | <erlehmann> | ;-) |
| 00:10 | <Yuhong> | CSS1 has existed since October 1994. |
| 00:10 | <Yuhong> | I mean the first draft of CSS1 existed since October 1994. |
| 00:11 | <Yuhong> | I mean the first draft of CSS1 was released in October 1994. |
| 00:11 | <Hixie> | erlehmann: i meant replacing it with the general case |
| 00:11 | <boogyman> | Yuhong: there's no need to keep double posting |
| 00:12 | <Yuhong> | Sorry, I made several mistakes. |
| 00:12 | <Yuhong> | Anyway, this is what the part 1 of this series is about. |
| 00:12 | <erlehmann> | Hixie, sounds reasonable. but wouldn't that lead to yet another dictionary incompatible with microdata/microformat/RDFas |
| 00:12 | <erlehmann> | ? |
| 00:13 | <erlehmann> | s/dictionary/namespace/g |
| 00:13 | <Hixie> | erlehmann: e.g. <foo itemprop=when content="2011-01-01">the first day of this year</foo>, <foo itemprop=who content="userid-213456">i</foo> went to <foo itemprop=where content="123,12">to barland</foo>. |
| 00:14 | <Hixie> | heycam: thanks dude, that patch is awesome. Only a few conflicts when I applied it, too, should be quick to fix. |
| 00:15 | <heycam> | Hixie, great! |
| 00:15 | Hixie | tries to work out how to fix them! |
| 00:15 | <boogyman> | patch for what? |
| 00:15 | <Hixie> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=10640 |
| 00:16 | <Hixie> | heycam: you didn't do the commented-out bits in idl? |
| 00:16 | <heycam> | Hixie, ah, I thought I did -- maybe I missed some? |
| 00:16 | <heycam> | oh, were there some completely commented out interfaces? |
| 00:16 | <Hixie> | this particular chunk that failed happened to include some that you didn't do |
| 00:17 | <Hixie> | no idea if it was just an oversight or not |
| 00:17 | <Hixie> | DataTransferItems's add() method had some commented out overloads |
| 00:17 | <Hixie> | (now DataTransferItemList, in case you're wondering about the conflict) |
| 00:17 | <Yuhong> | Published part 1: http://yuhongbao.blogspot.com/2011/06/history-of-css-part-1.html |
| 00:17 | <Hixie> | oh here's one that you did do in a comment |
| 00:18 | <heycam> | Hixie, you're right, I think I did overlook that particular one |
| 00:18 | <heycam> | I'm afraid then I might not have consistently looked at all commented out ones |
| 00:18 | <Hixie> | no worries |
| 00:19 | <erlehmann> | Hixie, i see what you did there. but why not use span then? to have a known dictionary of itemprop values? to see that there is machine-readable data? seems awfully non-necessary. |
| 00:19 | <erlehmann> | (to me, at least) |
| 00:19 | <heycam> | Hixie, I guess you can work them out, but let me know if you have any questions on the commented out ones |
| 00:19 | <Hixie> | erlehmann: adding content="" to <span> would work too |
| 00:20 | <Hixie> | erlehmann: the main reason for not doing that would be so that the microdata algorithm doesn't have to distinguish between <span itemprop=x>value</span> and <span itemprop=x content=value>nothing</span> |
| 00:20 | <Hixie> | erlehmann: i'm not talking about a dictionary here |
| 00:23 | <erlehmann> | is that distinction so complicated for UAs/consumers? i have no idea. but it might make it more obvious for human authors. |
| 00:24 | <Hixie> | for consumers it's trivial i'm sure |
| 00:24 | <Hixie> | for producers anything we can do to make this less subtle is a win |
| 00:35 | <roc> | I have some advice |
| 00:35 | <roc> | never, ever trust anyone who writes "PhD" after their name |
| 00:37 | <boogyman> | lol |
| 00:38 | <Yuhong> | <zcorpan> did tim write a spec for html before implementing it? |
| 00:40 | <Yuhong> | I don't think TimBL wrote a formal spec. |
| 00:40 | <Yuhong> | Back then HTML was not formally based on SGML. |
| 00:41 | <Hixie> | what is a "formal" spec? |
| 00:42 | <Yuhong> | TimBL did wrote a document describing the tags, because they had to. |
| 00:43 | <Hixie> | foolip: yt? |
| 00:44 | <Yuhong> | It was DanC that made the decision that HTML should be based on SGML. |
| 00:45 | <Yuhong> | Which happened in 1992 or so. |
| 00:45 | <gsnedder1> | Yuhong: TimBL didn't every really describe it at all, AFAIK, initally. |
| 00:47 | <Yuhong> | http://1997.webhistory.org/www.lists/www-talk.1992/0081.html |
| 00:55 | <erlehmann> | >Now I'm going back to the idea of writing a DTD for the existing HTML format. I can't seem to do it. |
| 00:55 | <erlehmann> | hehehe |
| 00:55 | <erlehmann> | :D |
| 00:56 | <Yuhong> | Anyway: |
| 00:56 | <Yuhong> | http://1997.webhistory.org/www.lists/www-talk.1992/0346.html |
| 00:58 | <erlehmann> | Yuhong, fun stuff |
| 01:05 | <Yuhong> | http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Connolly/MarkUp.html |
| 01:06 | <Yuhong> | Finally found it. |
| 01:07 | <Yuhong> | Defines HTML in terms of SGML. |
| 01:08 | <Yuhong> | http://1997.webhistory.org/www.lists/www-talk.1992/0407.html |
| 01:08 | <Yuhong> | Anyway, next year came Mosaic, which was even less compliant with SGML than libwww was. |
| 01:09 | <Yuhong> | For example, parsing of <MISSING QUOTE="SSDSDDD>. |
| 01:10 | <Yuhong> | Mosaic made the Web and HTML became popular. |
| 01:15 | <erlehmann> | oh, HTML, is po·pu·lar? good, that keeps out the hipsters. |
| 01:15 | <Yuhong> | And many wrote HTML markup based on what it looked like in Mosaic. |
| 01:17 | <jcranmer> | <bar /> |
| 01:17 | <jcranmer> | horribly malformed according to SGML, necessary in XML |
| 01:18 | <Yuhong> | Yep I know, the SHORTTAG fiasco. |
| 01:19 | <Yuhong> | IMO they should have changed it when they moved to "ISO 8879:1986 (WWW)" for HTML 4.01. |
| 01:19 | <Yuhong> | i.e. the SGML WebTC. |
| 01:20 | <Yuhong> | XHTML was in Proposed Recommendation by the time HTML 4.01 became Recommendation, as mentioned in the HTML 4.01 spec itself. |
| 01:21 | <Yuhong> | http://www.w3.org/TR/html401/references.html#ref-XHTML |
| 01:29 | <Yuhong> | Anyway, back to CSS history. |
| 01:32 | <tiglionabbit> | how does the clipboard API work? |
| 01:33 | <tiglionabbit> | I just captured a "paste" event but it doesn't have any data in it |
| 01:40 | <zewt> | heh, okay, logins on the w3c tracker are officially incomprehensible |
| 01:40 | <zewt> | i open a tab to log in and close the tab, as i do on most sites, refresh the original page and ... i'm logged out again |
| 02:11 | <Hixie> | abarth: yt? |
| 02:12 | <abarth> | hi |
| 02:12 | <abarth> | what can i do for you sir? |
| 02:12 | <Hixie> | hey |
| 02:13 | <Hixie> | what do you think about complicating the <object> type determination thingy EVEN MORE, to add an attribute that requires that the type="" and Content-Type match? |
| 02:14 | <abarth> | Hixie: that would solve a security problem :) |
| 02:14 | <Hixie> | that's the idea, yeah |
| 02:14 | <Hixie> | (well it wouldn't solve it so much as provide authors with a tool to solve it for themselves) |
| 02:14 | <abarth> | lcamtuf had some idea for solving this without extra markup |
| 02:15 | <Hixie> | did he mail it anywhere? i'm replying to a mail from him about this but i don't see an idea |
| 02:15 | <abarth> | do you have the flowchart handy? |
| 02:15 | <Hixie> | (well i see an idea but it's unworkable, it changes the default behaviour) |
| 02:15 | <Hixie> | yeah |
| 02:16 | <Hixie> | you want it uploaded somewhere to edit? |
| 02:16 | <abarth> | i just want to stare at it for a sec |
| 02:16 | <Hixie> | one sec |
| 02:17 | <Hixie> | http://junkyard.damowmow.com/470 |
| 02:17 | <Hixie> | where I put the X is where i suggest putting "if there's an attribute foo, and type="" and Content-Type don't match, then fallback" |
| 02:18 | <Hixie> | not 100% sure what to do if they do match, whether to short-circuit or follow the algorithm |
| 02:19 | <Hixie> | the only difference i believe is if the type and header both are a/octet-stream, in which case it would then use the extension |
| 02:19 | <abarth> | so, the compat case to worry about is type="something/insane" and a reasonable Content-Type |
| 02:20 | <abarth> | that seems like something we could measure |
| 02:21 | <Hixie> | there are so many edge cases here i don't think we should touch that algorithm again frankly, except for putting things at the head or tail of it |
| 02:21 | <abarth> | so, the simple thing I would add |
| 02:22 | <abarth> | if you want an opt-in mechanism |
| 02:22 | <abarth> | is to prevent the loading |
| 02:22 | <abarth> | if type isn't a recognized plugin |
| 02:22 | <abarth> | so in the "Is there a type="" attribute whose value is a plugin type?" step |
| 02:22 | <abarth> | in the NO branch |
| 02:22 | <abarth> | check for the new thing |
| 02:23 | <abarth> | if the new thing is there, don't load anything |
| 02:23 | <abarth> | which I guess translates to FALLBACK |
| 02:24 | <abarth> | something like "isplugin" |
| 02:24 | <Hixie> | i was thinking authors might want to use this even for other cases, e.g. the content they want to embed is text/html and they don't want it to be treated as flash |
| 02:24 | <abarth> | i see |
| 02:25 | <abarth> | that seems reasonable for an opt-in mechanism |
| 02:25 | <abarth> | it's only going to protect advanced sites that know to turn it on, but that's true for any opt-in mechanism |
| 02:25 | <Hixie> | though i guess that works already today if you say type="text/html" |
| 02:26 | <Hixie> | so maybe nevermind |
| 02:26 | <abarth> | does it? |
| 02:26 | <abarth> | the flowchart seems to say "use Content-Type" |
| 02:26 | <abarth> | but that could be application/swf |
| 02:26 | <Hixie> | oh right |
| 02:26 | <Hixie> | sorry i was thinking of the a/o-s case |
| 02:26 | <Hixie> | yeah |
| 02:27 | <Hixie> | ok so what i said originally |
| 02:27 | <abarth> | your approach has the virtue of being secure and not breaking things |
| 02:28 | <abarth> | which are good virtues :) |
| 02:28 | <Hixie> | heh |
| 02:28 | <Hixie> | i mainly like it cos it's easy to spec :-) |
| 02:28 | <abarth> | i bet the thing i was thinking of won't work anyway |
| 02:28 | <abarth> | because folks will typo their type attribute |
| 02:28 | <abarth> | or put something crazy there |
| 02:29 | <abarth> | and it will work today if the Content-Type is right |
| 02:29 | <Hixie> | well so will mine, right |
| 02:29 | <Hixie> | (mine being bz's suggestion of a feature that breaks if they don't match) |
| 02:30 | <abarth> | the main risk of your attribute is folks cargo-cult adding it without testing |
| 02:30 | <abarth> | and then UAs having an incentive not to implement |
| 02:30 | <abarth> | but if we get it into WebKit and FF quickly, that shouldn't be too much of a problem |
| 02:31 | <Hixie> | yeah |
| 02:31 | <Hixie> | i guess |
| 02:31 | <Hixie> | should i nerf clsid="" when this attribute is present? |
| 02:31 | <Hixie> | or just leave it? i guess it's up to the author |
| 02:31 | <Hixie> | so it doesn't much matter |
| 02:31 | <Hixie> | i'll just leave it |
| 02:31 | <Hixie> | clsid="" is invalid anyway |
| 02:32 | <Hixie> | where's zcorpan when you need him |
| 02:32 | <abarth> | clsid is a mystery to me |
| 02:32 | <Hixie> | i need a member of the hyphens-in-attributes police, anyone around? |
| 02:33 | <Hixie> | <object type="" typemustmatch data="">...</object> |
| 02:39 | <abarth> | nosniff |
| 02:39 | <abarth> | :) |
| 02:39 | <abarth> | strict-type |
| 02:39 | <abarth> | ^^^ actually, that one is bad |
| 02:40 | <Hixie> | nosniff doesn't really convey what happens |
| 03:03 | <Hixie> | k i added typemustmatch |
| 03:19 | <heycam> | Hixie, since you're not reading bugmail, would you be able to reply to http://www.w3.org/Bugs/Public/show_bug.cgi?id=12845 at some point? |
| 05:22 | <Hixie> | heycam: replied |
| 05:23 | <heycam> | thanks |
| 07:47 | <hsivonen> | http://www.jenitennison.com/blog/node/157#comment-11011 looks like schema.org doesn't have the WHATWG spec writing culture even as a principle to aspire for :-( |
| 07:59 | <hsivonen> | does anyone want to guess how long it will take for the geolocation meta keywords and the dublin core keywords to get registered |
| 07:59 | <hsivonen> | as opposed to people filing bugs about them not being registered |
| 08:00 | <hsivonen> | also, guesses about the IE9 taskbar pinning stuff, anyone? |
| 08:02 | <Hixie> | the IE9 stuff seems surprisingly unused |
| 08:02 | <Hixie> | at least from what i've seen |
| 08:59 | <foolip> | foolip, I'm here |
| 08:59 | <foolip> | different timezones rock |
| 09:04 | <Ms2ger> | foolip, talking to yourself? :) |
| 09:04 | <foolip> | blargh |
| 09:04 | <foolip> | Hixie, ^ |
| 09:05 | <foolip> | Ms2ger, thanks :) |
| 09:05 | <Hixie> | what was i going to ask you |
| 09:05 | <Hixie> | something about microdata |
| 09:05 | <Hixie> | oh, yeah |
| 09:05 | <foolip> | itemref stuff? |
| 09:05 | <Hixie> | in the e-mail you said that i shouldn't worry about the performance of the algorithms |
| 09:05 | <Hixie> | but that wasn't really my point |
| 09:05 | <foolip> | ok |
| 09:05 | <Hixie> | my point was that the algorithm, however it is expressed in the spec, needs to be something that can be implemented quickly |
| 09:05 | <foolip> | of course |
| 09:06 | <foolip> | wait |
| 09:06 | <Hixie> | you don't want every call to .properties or whatever it's called to require a walk of the entire dom |
| 09:06 | <foolip> | do you mean "quickly" as in "few engineering hours" or as in "efficient" |
| 09:06 | <foolip> | the later I suppose? |
| 09:06 | <zcorpan> | typemustmatch? can we bikeshed that name a bit? looks like typemustache |
| 09:06 | <Hixie> | as in few cpu cycles |
| 09:07 | <foolip> | certainly |
| 09:07 | <Hixie> | zcorpan: you have convinced me that it is the right name! |
| 09:08 | <foolip> | Hixie, is there something I'm missing about why eliminating loops by the criteria we suggested wouldn't be implementable at least as fast as what is spec'd? |
| 09:08 | <foolip> | both could be implemented with a recursive check just like what is in the spec |
| 09:08 | <Hixie> | foolip: not sure, i need to study it more closely |
| 09:08 | <Hixie> | foolip: i just wanted to make sure that we were on the same page re efficiency first :-) |
| 09:08 | <Hixie> | foolip: your proposal is to define it in terms of starting at the root and lopping off anything that involves a loop, right? |
| 09:09 | <foolip> | certainly |
| 09:09 | <foolip> | Hixie, perhaps it could be expressed like that also, I'm not sure |
| 09:10 | <Hixie> | foolip: if that is the case, then what happens if you ask the UA for the properties of an item that is part of a lopped off loop? |
| 09:10 | <foolip> | I could express it similar to what is in the spec, but adjusted to ensure that only properties that are *in* a loop are removed |
| 09:10 | <Hixie> | what the spec says now is clearly bogus |
| 09:10 | <foolip> | agreed :) |
| 09:10 | <Hixie> | so i'm not sure it's a useful starting point for debate :-) |
| 09:11 | <foolip> | Hixie, you'd get an empty item, simlar to what you get if you get .properties of an element without itemscope |
| 09:12 | <foolip> | Unfortunately Tomasz is still away, so I think we need to hold off any spec changes until he's had a look at the discussion too |
| 09:12 | <Hixie> | foolip: and i guess to determine that that is the case you'd just need to walk down the tree until you get back to the element, right? and then you realise the element is in a loop and so you return nothing |
| 09:12 | <foolip> | Hixie, right (you don't have to traverse the whole tree, just starting at that item and following itemref) |
| 09:12 | <Hixie> | foolip: i can delay this, sure. was just trying to get it done since you said it was high priority :-) |
| 09:12 | <Hixie> | yeah i meant walk down the tree from that itemscope'd element |
| 09:13 | <foolip> | it does, but Tomasz is implementing it so I'd like to sync it with him first |
| 09:13 | <Ms2ger> | There's more than enough other bugs to work on ;) |
| 09:14 | <foolip> | assuming that we can implement it as O(n) with a sane criteria X, I assume that you'd be happy to spec criteria X? |
| 09:15 | <foolip> | we don't want to waste our time, obviously :) |
| 09:15 | <Hixie> | well there's a lot of crazy things one can implement in O(n) |
| 09:15 | <Hixie> | so i can't say yes to that :-) |
| 09:15 | <foolip> | ok, with a sane X, for example the suggested one :) |
| 09:15 | <Hixie> | but i don't have strong views on this particular topic, it's pretty unconstrained |
| 09:15 | <Hixie> | so probably, yes |
| 09:16 | <foolip> | I think there are only two really sane high-level criteria |
| 09:16 | <foolip> | 1. eliminate everything that would lead into infinite recursion |
| 09:16 | <Hixie> | what we discuss above is basically what i intended for the spec except that i was intending to cut it off at the property of the item, not the item itself |
| 09:16 | <Hixie> | but i can live with either |
| 09:17 | <foolip> | right, that is a facet which I think we haven't fully considered |
| 09:18 | <foolip> | it's either marking the items or the properties as "loopy", neither seems obviously easier to do or more useful |
| 09:18 | <Hixie> | the advantage of doing it at the item is you get a consistent view |
| 09:18 | <foolip> | right |
| 09:18 | <Hixie> | the advantage of doing it at the property is that you can get useful data for each item |
| 09:19 | <Hixie> | it's a toss-up, imho |
| 09:19 | <foolip> | yeah |
| 09:19 | <slartsa> | Hey, quickie: Might it be possible for a server to record stuff from <device>? |
| 09:19 | <Hixie> | slartsa: <device> is gone but its replacement supports that, yes |
| 09:19 | <slartsa> | uh, oh? |
| 09:19 | <foolip> | since it's only for fixing invalid markup, I don't think it matters a great deal, the only important part is how easy it is for authors to look at it and guess why it's broken |
| 09:19 | <slartsa> | I should rtfm more |
| 09:19 | <Hixie> | foolip: yeah |
| 09:20 | <Hixie> | slartsa: search for getUserMedia and PeerConnection in the spec |
| 09:21 | <slartsa> | Hixie: thank you |
| 09:21 | hsivonen | wonders if Sam drafted othermaciej's CfC email or if othermaciej has picked up Sam's email wording patterns |
| 09:22 | <othermaciej> | I wrote it myself |
| 09:22 | <othermaciej> | I tend to go into a particular style when drafting this sort of thing, I do not know if it particularly resembles Sam |
| 09:23 | <hsivonen> | othermaciej: seems to resemble Sam's style |
| 09:23 | <othermaciej> | "at this time" and "concrete proposal" are phrases he uses a lot |
| 09:25 | <hsivonen> | so we have a parsing algorithm change today |
| 09:25 | <othermaciej> | "lively discussion", "a proper Working Draft", "for clarity" and most of all having a numbered list of things are more hallmarks of my own style |
| 09:25 | <othermaciej> | o rly |
| 09:25 | <othermaciej> | what is the change? |
| 09:26 | <hsivonen> | othermaciej: making rp and rt start tags not pop all the way up to the nearest ruby |
| 09:26 | <othermaciej> | hopefully limited in impact then, though unfortunate since now many HTML5 parser implementations have shipped with relatively good compliance to the old spec |
| 09:26 | <Hixie> | it's pretty minimal, yeah |
| 09:27 | <Hixie> | only affects invalid <ruby> (including ruby using the xhtml advanced ruby syntax) |
| 09:27 | <hsivonen> | pretty substantial for deployability of Complex Ruby |
| 09:27 | <Hixie> | and on that note i should go to bed |
| 09:27 | <Hixie> | nn |
| 09:27 | <hsivonen> | othermaciej: has WebKit implemented the annotation-xml stuff etc. that got changed after Chrome 8? |
| 09:28 | <othermaciej> | I'm not sure offhand (not even sure I remember what annotation-xml is), but I'd be happy to try a test case on a recent build if you have one handy |
| 09:29 | hsivonen | goes read the parser code in order to formulate a test case |
| 09:30 | <hsivonen> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1027 |
| 09:31 | <hsivonen> | othermaciej: It appears that the HTML parser in Chrome 13 has not been substantially updated since Chrome 8 |
| 09:31 | <zcorpan> | hsivonen: when you implement typemustmatch in v.nu, pls add it to the list of things that get a warning |
| 09:32 | <asmodai> | I don't get this, why do I suddenly have this "move mouse to allow firefox to get cycles" issue again. Can it be something JavaScript triggers? Need to move my mouse in order to get pages to draw, JavaScript to run, etc. |
| 09:32 | <hsivonen> | zcorpan: ok |
| 09:32 | <othermaciej> | hsivonen: how do I interpret the results of the test case? |
| 09:32 | <hsivonen> | (Hixie's viewer would show FOO in upper case if Chrome had an up-to-date parser) |
| 09:32 | <hsivonen> | othermaciej: ^ |
| 09:32 | <othermaciej> | ok, doesn't do that |
| 09:33 | <othermaciej> | (in Safari 5.1 developer preview + very recent WebKit) |
| 09:34 | <hsivonen> | asmodai: sounds more like a window server thing |
| 09:35 | <hsivonen> | asmodai: like a system-owned event loop not firing non-user events |
| 09:36 | <asmodai> | Mmm |
| 09:36 | <asmodai> | Then the question is, what and why is this triggering. Grr |
| 09:36 | <hsivonen> | I have no idea |
| 09:37 | <asmodai> | yeah, need to see if I can find it |
| 09:40 | <asmodai> | Mmm, seems like restarting ff cleared it though. |
| 09:52 | <hsivonen> | jgraham, zcorpan, abarth: are you OK with adding <rb> to the elements closed by "generate implied end tags"? doing that would bring the parsing algorithm back to IE8 compat for simple Ruby (while not precluding the introduction of Complex Ruby in the future) |
| 09:57 | <zcorpan> | hsivonen: rb was a typo, i meant rt. i have to look up rb to know what it is |
| 09:57 | <zcorpan> | ruby base? |
| 09:58 | <hsivonen> | zcorpan: yes |
| 09:58 | <zcorpan> | ie doesn't support rb and it's not a valid element in html5 |
| 09:59 | <hsivonen> | zcorpan: IE8 pops rb when it sees <rt> |
| 09:59 | <hsivonen> | zcorpan: so it's plausible that there's Simple Ruby out there that uses the kind of markup the XHTML spec requires |
| 10:00 | <zcorpan> | hsivonen: doesn't it just make rb a void element? |
| 10:00 | <hsivonen> | except omits </rb> |
| 10:00 | <zcorpan> | like any other unknown tag |
| 10:00 | <jgraham> | hsivonen: I am not informed enough to have a sensible opinion about ruby, but I trust your judgment. So yes, I am fine with that :) |
| 10:02 | <hsivonen> | zcorpan: oh. good point |
| 10:02 | hsivonen | should have read the live dom more closely |
| 10:02 | <hsivonen> | zcorpan: still, I think it's just bizarre to make "generate implied end tags" close rt but not close rb |
| 10:02 | <zcorpan> | *shrug* |
| 10:02 | <zcorpan> | i don't mind either way |
| 10:04 | <hsivonen> | jgraham: my judgement has already been bad and corrected by zcorpan on this bug |
| 10:05 | <jgraham> | hsivonen: Oh. Well in that case I trust zcorpan :) |
| 10:05 | <jgraham> | I can see that I should stop being so trusting... |
| 10:05 | <hsivonen> | oh. and we should also make <rb> generate implied end tags |
| 10:05 | <hsivonen> | to make things sane if we ever do Complex Ruby |
| 10:06 | <zcorpan> | i suggest we worry about <rb> when and if we want to implement complex ruby |
| 10:07 | <hsivonen> | zcorpan: Mozilla might implement it imminently |
| 10:07 | <zcorpan> | oh |
| 10:08 | <jgraham> | hsivonen: Why? |
| 10:11 | <hsivonen> | jgraham: as I understand it, someone wrote a patch while reading the old specs and there doesn't seem to be a good reason not to support it |
| 10:11 | <hsivonen> | jgraham: though fantasai and bz would know better |
| 10:11 | <hsivonen> | jgraham: I know next to nothing about the justification for Complex Ruby |
| 10:12 | <hsivonen> | jgraham: I'm just trying to undo painting ourselves in a corner with the parser |
| 10:13 | <hsivonen> | "justification" typography pun not intended above |
| 10:14 | <jgraham> | hsivonen: "a good reason to to support it" might be that it introduces unnecessary complexity into the platform for everyone |
| 10:14 | <jgraham> | *not to |
| 10:14 | <jgraham> | Although I don't really know what is necessary complexity in this area |
| 10:15 | <hsivonen> | jgraham: I realize that. |
| 10:15 | <hsivonen> | jgraham: I'm not competent to argue about this either way. fantasai is. |
| 10:16 | <zcorpan> | i thought complex ruby was expressible with nested simple ruby |
| 10:17 | <hsivonen> | zcorpan: depends on whether you care more about graceful degradation in simple ruby-only UAs or fully rubyless UAs |
| 10:18 | <matjas> | in how many different ways can HTML entities be written? |
| 10:18 | <matjas> | am I missing any here? http://jsfiddle.net/mathias/WMTMv/ |
| 10:19 | <hsivonen> | matjas: I think you are missing leading zeros in the decimal case |
| 10:19 | <hsivonen> | unless I'm missing a gotcha |
| 10:20 | <matjas> | hsivonen: you’re not, thanks |
| 10:20 | <matjas> | anything else? |
| 10:21 | <zcorpan> | & |
| 10:21 | <hsivonen> | matjas: invalid cases without a colon and a suitable next character |
| 10:21 | <matjas> | zcorpan: that’s not encoded at all :P |
| 10:21 | <zcorpan> | but it's valid |
| 10:22 | <matjas> | only when followed by > or whitespace. no? |
| 10:22 | <zcorpan> | not quite |
| 10:22 | <matjas> | errr, < |
| 10:22 | <matjas> | zcorpan: enlighten me please :) |
| 10:24 | <matjas> | hsivonen: I only care about valid cases here, but thanks |
| 10:24 | <hsivonen> | hmm. I may have forgotten to update the validator on this topic as far as attribute values go |
| 10:24 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/complete/syntax.html#syntax-ambiguous-ampersand |
| 10:25 | <matjas> | hsivonen: this is exactly why I’m asking |
| 10:25 | <matjas> | I assumed the validator was up to date |
| 10:25 | <zcorpan> | "Normal elements ... must not contain ... an ambiguous ampersand." |
| 10:26 | <zcorpan> | "Attribute values are a mixture of text and character references, except with the additional restriction that the text cannot contain an ambiguous ampersand." |
| 10:26 | <matjas> | I thought ambiguous ampersands were unencoded & chars that are followed by something that is not whitespace, < (start of a tag), or another & |
| 10:26 | <matjas> | i.e. ambiguous ampersands are cases where & is left unencoded resulting in non-conformant (invalid) code |
| 10:26 | <zcorpan> | it was something like that before |
| 10:26 | <zcorpan> | but it was changed to allow href="?foo=1&bar=2" |
| 10:27 | <matjas> | ah yeah, validator.nu doesn’t like that |
| 10:27 | <matjas> | so I assumed it was (still) invalid |
| 10:27 | <matjas> | thanks for clarifying, zcorpan |
| 10:28 | <Philip`> | <script>document.write('&');</script>amp; |
| 10:28 | <matjas> | now that’s ambiguous |
| 10:28 | <zcorpan> | it's not! :) |
| 10:28 | <matjas> | :D |
| 10:37 | <matjas> | hmmm, http://bugzilla.validator.nu/buglist.cgi?quicksearch=ampersand |
| 10:38 | <matjas> | hsivonen: should I file a new bug? |
| 10:43 | <hsivonen> | matjas: yes, please |
| 10:47 | <matjas> | hsivonen: http://bugzilla.validator.nu/show_bug.cgi?id=841 |
| 10:52 | <hsivonen> | matjas: thanks |
| 11:00 | <hsivonen> | http://geotags.com/geobot/add-tags.html that might work as a "spec" for geo.position |
| 11:00 | <hsivonen> | but not for geo.region |
| 11:00 | <hsivonen> | it doesn't say what a "region code" is |
| 11:01 | <hsivonen> | http://geourl.org/add.html might be the "spec" for ICBM |
| 12:27 | <jgraham> | Ms2ger: Thanks for the review. |
| 12:27 | <jgraham> | Ms2ger: I have passed it on to the test author |
| 12:28 | <Ms2ger> | Always happy to complain :) |
| 12:28 | <jgraham> | I doubt we will make the strict mode tests |
| 12:28 | <jgraham> | On the other points, I got the feedback |
| 12:28 | <Ms2ger> | Sure |
| 12:28 | <jgraham> | 3. window.undefined is for old compat. change it as you see fit. |
| 12:28 | <jgraham> | 4. toString can be called explicitly, but the intention was actually to prove that implicit casts worked |
| 12:29 | <Ms2ger> | Yes, but I'd appreciate both :) |
| 12:29 | <jgraham> | everything else seems to be uncontroversial and we will fix |
| 12:29 | <Ms2ger> | Thanks |
| 12:29 | <jgraham> | Both is possible |
| 13:16 | <jgraham> | In other news roc is 100% right about the PhDs thing. Not just PhD though: never trust anyone who puts any academic credentials after their name as a matter of course |
| 13:19 | <Philip`> | I like how the blog system displayed the name as "..., Ph.D. (not verified)" |
| 13:22 | <hsivonen> | Philip`: which blog? |
| 13:23 | <jgraham> | hsivonen: JenniT's I think |
| 13:23 | <jgraham> | Oh, wrong number of "n"s |
| 13:24 | <jgraham> | http://www.jenitennison.com/blog/node/157#comment-11004 |
| 13:27 | Philip` | assumed that was what roc was referring to, but now realises he had absolutely no evidence it was anything to do with that and was probably wrong |
| 13:28 | jgraham | also wondered if he had that in mind, but has noticed the more general phenomonon |
| 13:28 | <jgraham> | It is especially a red flag when used on a book cover |
| 13:30 | <roc> | Philip`: I'd actually forgotten, but I think you're probably right! |
| 13:30 | <roc> | it's less of a red flag on a book cover |
| 13:30 | <roc> | IMHO |
| 13:31 | <roc> | depends on the book I guess |
| 13:31 | <roc> | if it's "Dr Phil's Sex Secrets" or something like that, sure |
| 13:32 | <roc> | If it's "The Complete Idiot's Guide To Category Theory", it's OK |
| 13:41 | <jgraham> | Well sure on an academic book it's fine but probably unnecessary |
| 13:43 | <jgraham> | It's other types of book, particularly self-help, where it reads as a unsubstantiated attempt to boost credibility |
| 13:44 | <hsivonen> | Someone in the comment gathering a lynch mob. My comment not answered. http://www.actionforblindpeople.org.uk/your-community/blogs/sandi-wassmer/html5-and-web-accessibility-is-there-hope-for-inclusion/ |
| 13:45 | <hsivonen> | *the comments |
| 13:47 | <nessy> | what do you do if you've actually spent 5 years of your life doing a PhD successfully - why should you need to hide the title and even feel ashamed? |
| 13:49 | <zcorpan> | because roc and jgraham will ignore you? |
| 13:51 | <nessy> | I'm trying to fight prejudice - you cannot put the same measure on everyone |
| 13:51 | <jgraham> | nessy: You shouldn't feel ashamed or need to hide the title. But you shouldn't try to use it in a way that suggests that you expect more weight to be given to your opinion because of the PhD |
| 13:52 | jgraham | has a PhD fwiw |
| 13:52 | <nessy> | yup, agreed - it just sometimes feels like a witch-hunt |
| 13:54 | <jgraham> | There are good uses of course. Like making sure to use "Dr" as your title on airline reservations in the hope that it increases the chance of a free upgrade (I have no idea if it does or not) :) |
| 13:55 | <nessy> | I've never tried |
| 13:55 | <nessy> | I find that silly actually ;-) |
| 13:55 | <nessy> | it might just get the crew to think you're a medical doctor |
| 13:55 | <jgraham> | I didn't claim that it wasn't silly :) Things can be good and silly :) |
| 13:55 | <jgraham> | Ha. Well yes that would be a bad side effect |
| 13:56 | <nessy> | unfortunate, really :-) |
| 13:57 | <nessy> | ok, time to grab some sleep … nn |
| 13:57 | <jgraham> | gn |
| 13:57 | hsivonen | wonders how badly Web stuff is interfering with Philip` becoming a PhD |
| 13:58 | <hsivonen> | so I made a backup to an external disk using Ubuntu and told it to encrypt the underlying device |
| 13:58 | <hsivonen> | now mounting the partition is taking forever |
| 13:59 | <hsivonen> | is it supposed to take a long time? |
| 14:00 | <hsivonen> | udevd seems to be quite busy |
| 14:04 | <hsivonen> | aargh. I want something like Mac's encrypted .dmgs that just works! |
| 14:09 | <hsivonen> | stuff learned today: encrypted volumes buggy in Ubuntu. Can be used from Disk Utility. Don't count on Nautilus. |
| 14:09 | <Philip`> | "jgraham has a PhD fwiw" - are you saying that because you expect it to give more weight to your opinions on PhDs? :-p |
| 14:16 | <Lachy> | hsivonen, have you tried TrueCrypt? That can make encrypted files that can be mounted |
| 14:17 | <hsivonen> | Lachy: truecrypt has gotten kicked out of the Ubuntu repos |
| 14:17 | <hsivonen> | dunno why |
| 14:18 | <hsivonen> | Lachy: and on some forum someone was complaining about upstream binaries not working correctly on 64-bit Ubuntu |
| 14:18 | <hsivonen> | Lachy: so I didn't want to try my luck with software sources other than Ubuntu's own repos |
| 14:20 | <Philip`> | Was Truecrypt ever in its repositories? |
| 14:20 | Philip` | can't see any references to that |
| 14:20 | <Lachy> | hsivonen, why can't you just download the package from the website? |
| 14:21 | <hsivonen> | Philip`: I think it was, because I have installed it on an Ubuntu box previously and I think I was only installing stuff from Ubuntu's repos (incl. Universe and Multiverse) |
| 14:21 | <hsivonen> | Lachy: I didn't bother, because someone else said it sucked on 64-bit |
| 14:21 | <Lachy> | ok |
| 14:22 | <hsivonen> | anyway, it's sad that Mac OS X works better even when it comes to crypto, file systems and disk images that stereotypically should be the kind of stuff you'd expect Linux to handle |
| 14:23 | Philip` | uses Truecrypt on 64-bit Gentoo with no problem, but that's compiled from source rather than pre-built binaries |
| 14:23 | <hsivonen> | Philip`: does truecrypt need kernel modules and stuff like that? |
| 14:25 | <Philip`> | hsivonen: It needs http://en.gentoo-wiki.com/wiki/TrueCrypt#Requirements which I imagine Ubuntu's kernels would enable by default |
| 14:26 | <erlehmann> | hsivonen, Philip`, why not use the standard dm-crypt with LUKS? |
| 14:27 | <erlehmann> | Last time I looked, TrueCrypt was an abomination to install. Also, Ubuntu has jumped the shark several years ago when they started to go from “usable linux distribution” to “latest bling-bling” |
| 14:27 | <Philip`> | erlehmann: I wanted to use the disk under Windows too, and TrueCrypt seemed the easiest cross-platform tool |
| 14:28 | <hsivonen> | erlehmann: I am using LUKS, it seems. It or its front ends are buggy, though |
| 14:28 | <hsivonen> | Philip`: I guess next time I'll use truecrypt |
| 14:28 | <erlehmann> | ah ok. |
| 14:30 | <zcorpan> | did somebody have an up-to-date extract of all idl blocks from html5 and other specs? |
| 14:30 | <erlehmann> | hsivonen, it's still probably a good idea to try out to do stuff with plain old debian before venturing into the truecrypt nether. |
| 14:30 | <hsivonen> | it doesn't inspire confidence in my backup to have it encrypted using a system that looks so flaky that I wouldn't be surprised at all if decryption and mounting failed the next time |
| 14:31 | <hsivonen> | erlehmann: Ubuntu is an ancient African word for "Don't want to configure Debian." |
| 14:32 | <erlehmann> | hsivonen, it's been a long time since that was truthiness. |
| 14:32 | <erlehmann> | okay, maybe 3 years ;) |
| 14:34 | <jgraham> | Philip`: I think I was saying that to prove that I am not ashamed of the fact :) |
| 14:48 | <AryehGregor> | hsivonen, "Yeah, I can do it, but it kind of defeats the whole point of a distribution for me. So I like the ones that have a name of being easy to use. I've never used plain Debian, for example, but I like Ubuntu." --Linus Torvalds |
| 19:09 | <AryehGregor> | Crazy Opera range mutation bug: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1028 |
| 19:09 | <AryehGregor> | Sets a range's offset to greater than the length of its node. |
| 19:10 | <AryehGregor> | Unpredictably breaks some of my tests in Opera. :( |
| 21:05 | <hober> | Is @boriszbarksy actually him? |
| 21:05 | <Ms2ger> | bz is @bz_moz, I think |
| 21:06 | <hober> | ahh, indeed, thanks |
| 21:33 | <smaug____> | AryehGregor: I think you'll find strange bugs in all the range implementations if you do some mutation event trickery ;) |
| 21:33 | <AryehGregor> | smaug____, I'm not touching mutation events. |
| 21:33 | <AryehGregor> | My current theory is that if I pretend they don't exist, they'll go away. |
| 21:33 | <AryehGregor> | Also, none of the specs I depend on define how they behave. |
| 21:34 | <AryehGregor> | If I wanted to handle them in any meaningful way, they'd have to be precisely defined in DOM Core or such first. |
| 21:34 | <smaug____> | I don't really care about DOM core yet |
| 21:34 | <smaug____> | I mean the Web DOM core |
| 21:36 | <AryehGregor> | What do you mean? |
| 21:36 | <smaug____> | I mean anything in it may still change |
| 21:36 | <smaug____> | it is not reviewed etc. |
| 21:36 | <AryehGregor> | Well, the same is true for any standard of significance. |
| 21:37 | <AryehGregor> | It won't get reviewed if implementers don't care about it. :) |
| 21:38 | <smaug____> | it is also not clear why it needs to have the event stuff |
| 21:38 | <smaug____> | I could understand if it had mutation events |
| 21:38 | <smaug____> | since they are about DOM tree |
| 21:39 | <AryehGregor> | All I know is, it's the only DOM Core spec around that's actively maintained or tries to match implementations exactly, so it's the only one I use. |
| 21:39 | <AryehGregor> | I report bugs when I find them. |
| 21:39 | <smaug____> | it doesn't only try to match implementation but also make some (good) major changes |
| 21:40 | <smaug____> | so yes, I support the work |
| 21:40 | <smaug____> | but I just feel it is still quite early draft |
| 21:42 | <jgraham> | That may be true but it is still more useful than the decade-old DOM 3 stuff |
| 22:02 | <Hixie> | jgraham: for http://www.w3.org/Bugs/Public/show_bug.cgi?id=12299 do you mind if i just don't mention in the domintro cases what happens if the value is out of range? |
| 22:06 | <Hixie> | hm i guess that doesn't help for propertyNodeList.namedItem() vs [] |
| 22:12 | <jgraham> | Hixie: I will just let you answer your own questions |
| 22:12 | <jgraham> | :) |
| 22:13 | <jgraham> | But yeah in general I am not that bothered about the non-normative text covering this; I would much rather it was missing than wrong |
| 22:15 | <Hixie> | k |
| 22:15 | <Hixie> | i wonder how to fix this |