| 00:18 | <Philip`> | Google Translate is great |
| 00:18 | <Philip`> | "Creative Commons Attribuzione-Non opere derivate 2.5 Italia License" apparently translates into "Creative Commons Attribution-No Derivative Works 2.5 Canada License" |
| 00:20 | <Hixie> | yeah, that's the risk with that learning method |
| 00:21 | <Philip`> | It makes it really hard to trust the results, when they might arbitrarily substitute the semantics with something completely different |
| 00:22 | <Hixie> | not completely different |
| 00:23 | <Hixie> | it's the same, it's just it's using a different point of reference |
| 00:24 | <Philip`> | When you think somebody's talking about one particular country, and the translation service gives the appearance of great confidence, when actually they're talking about a different country, that's not really good at all if it's a situation where you care what the person is talking about |
| 00:24 | <Hixie> | i'm not saying it's useful :-) |
| 00:25 | <Hixie> | it's like if a car repair shop replaced your tires with big round rocks |
| 00:25 | <Hixie> | "what, it's a wheel! why are you complaining!" |
| 00:25 | <Hixie> | you wanted them replaced, so they replaced them with something equivalent -- a round thing with no air in it |
| 00:26 | <Hixie> | sadly the "air" part was the part you cared about, and you wanted it replaced with something equivalent -- a round rubber thing designed to hold air |
| 00:26 | <Philip`> | It's not like that at all, because it's immediately obvious if your car has big round rocks instead of tires |
| 00:26 | <Philip`> | It's more like they replaced your petrol engine with a diesel engine and didn't tell you about it |
| 00:27 | <Hixie> | there you go |
| 06:02 | heycam | notices the revised melbourne weather forecast for the next two days: 43°C (=109°F) |
| 06:15 | <rubys1> | Lachy: re: http://lists.w3.org/Archives/Public/public-html/2009Jan/0433.html: Exactly. :-) |
| 07:30 | <hsivonen> | Philip`: good catch. yes, indeed I made the time complexity of rare operations like insertBefore suck in order to make common operations as fast as I could make them |
| 07:31 | <hsivonen> | Philip`: this together with calling SAXTreeBuilder.insertCharactersBefore per character or so is not cool when your have a quarter million characters instead of a handful |
| 07:31 | <Hixie> | unfortunately, on the web there are so many different characteristics that it seems the only good algorithm is a uniformally fast one that doesn't use much memory and is secure. :-P |
| 07:33 | <hsivonen> | at least it's only the SAX Tree insertBefore whose time complexity is intentionally bad--not the parser itself |
| 07:34 | <hsivonen> | Philip`: basically, the issue is that SAX Tree has only nextSibling links but not previousSibling links |
| 07:35 | <Hixie> | a streaming api with forward links on a tree? that sounds unbelievably painful. i assume i misunderstand. |
| 07:36 | <annevk> | wow, what a bunch of hopeless discussions on public-html |
| 07:36 | annevk | is glad he's not involved |
| 07:37 | <hsivonen> | Hixie: SAX Tree is an XML tree implementation that is optimized to be fast for building from SAX events and for replaying as SAX events |
| 07:37 | <Hixie> | fast building from sax events with forward links? |
| 07:37 | <hsivonen> | Hixie: for XML and for conforming HTML, you never need to traverse a previousSibling link |
| 07:37 | <Hixie> | how can that possibly be fast |
| 07:37 | <hsivonen> | Hixie: there's also a lastChild link for making append fast |
| 07:37 | <Hixie> | (for building) |
| 07:38 | <Hixie> | i assume you can't access this tree while it's being built |
| 07:39 | <hsivonen> | it isn't meant to be accessed by anything but the tree builder while it's being built |
| 07:39 | <Hixie> | ok |
| 07:40 | <Hixie> | then i guess it can be built fast since you don't have to set the pointers until you're ready |
| 07:40 | <hsivonen> | it does set everything so that the tree is coherent after each operation |
| 07:41 | <Hixie> | so lastChild gets updated each time you add a node? |
| 07:41 | <Philip`> | hsivonen: That sounds like a plausible explanation |
| 07:41 | <hsivonen> | Hixie: yes |
| 07:41 | <Philip`> | hsivonen: I think it's still a bug even if it's by design :-) |
| 07:41 | <Hixie> | and there's a stack of nodes waiting for their nextSibling to be set? |
| 07:42 | <hsivonen> | Hixie: no |
| 07:42 | <Hixie> | so how is nextSibling set? |
| 07:42 | <hsivonen> | Hixie: take the lastChild of parent, set its nextSibling, set the lastChild of parent to the new sibling |
| 07:42 | <Philip`> | hsivonen: If this only affects the foster-parenting case, could you do something like cache a reference to the node that's just before the table, so you don't have to search for it again every time you insert a bit more? |
| 07:43 | <hsivonen> | Philip`: possibly |
| 07:43 | <Hixie> | hsivonen: fair enough |
| 07:48 | <BenMillard> | IE Blog gives details of their counter-clickjacking mechanism: http://blogs.msdn.com/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx |
| 07:49 | <BenMillard> | "Web developers can send a HTTP response header named X-FRAME-OPTIONS with HTML pages to restrict how the page may be framed." |
| 07:49 | <BenMillard> | "[...] E8 will prevent the page from rendering if it will be contained within a frame." |
| 07:49 | <BenMillard> | oops, I mean "[...] IE8 will prevent the page from rendering if it will be contained within a frame." |
| 07:50 | <BenMillard> | "[...] a local error page is presented that explains the restriction and provides a link which opens the frame in a new window." ouch |
| 07:50 | <BenMillard> | perhaps it means s/new window/current window/ although the screenshot could be showing either |
| 07:51 | <Philip`> | That's going to make your page work really well in e.g. Google Cache or Translate |
| 07:52 | <Hixie> | actually won't affect google cache |
| 07:52 | <Hixie> | gonna be a bitch in image search though |
| 07:52 | <Hixie> | and reddit's toolbar mode |
| 07:52 | <Hixie> | and so on |
| 07:53 | <BenMillard> | ah yes: "If the value contains the token SAMEORIGIN, IE will block rendering only if the origin of the top level-browsing-context is different than the origin of the content containing the X-FRAME-OPTIONS directive." |
| 07:53 | <Hixie> | it's the equivalent of saying "we're going to stop the problem of people breaking the encryption on our remote car key fobs by allowing people to not have a remote car key fob" |
| 07:54 | <Philip`> | Oops, yes, don't know why I thought of Cache |
| 07:54 | <BenMillard> | Hixie, you're really getting into these car analogies. :) |
| 07:54 | <BenMillard> | in more positive news, "Today, the IE Team is submitting 3,784 new test cases to the CSS 2.1 Working Groupfor inclusion into the CSS 2.1 test suite.": http://blogs.msdn.com/ie/archive/2009/01/27/microsoft-submits-thousands-more-css-2-1-tests-to-the-w3c.aspx |
| 07:55 | <BenMillard> | s/Groupfor/Group for/ due to a copy-paste error on my part |
| 07:59 | <Philip`> | In my new collection of pages, I only see <canvas> on three distinct sites |
| 07:59 | <Philip`> | http://www.precisionsoftware.com/ - <canvas id="clk4" class="CoolClock:myClock:::-5"></canvas> |
| 07:59 | <Philip`> | http://www.ourcampaigns.com/cgi-bin/r.cgi/RaceDetail.html?RaceID=6993 - some kind of graph thing |
| 08:00 | <BenMillard> | Philip`, it was a good idea to recollect web pages, glad to see you've done that and cool that it'll perform better. B) |
| 08:00 | <Philip`> | http://www.city-data.com/city/Hubbard-Lake-Michigan.html plus a load more from the same site - more graphs |
| 08:01 | <Philip`> | Graphs and clocks are really dully :-( |
| 08:05 | Philip` | tries to resist the temptation to download more pages until it gets really slow again |
| 08:06 | <Philip`> | (I guess the main reason it's much faster is that it's now 600MB instead of 3.1GB to store the 130K pages, so it can all be buffered in RAM pretty easily) |
| 08:17 | <Hixie> | aw man, i'm so gonna have to restructure the innerHTML/document.write section |
| 08:18 | <Hixie> | I wonder what a better way to organise that section would be |
| 08:18 | <Hixie> | (http://www.whatwg.org/specs/web-apps/current-work/#dynamic-markup-insertion) |
| 08:18 | <jruderman> | "Don't. But if you do..." |
| 08:18 | <annevk> | it might help if you explain why |
| 08:19 | <Hixie> | the current structure defines the apis twice, once for xml and once for html, with the two sets in two different sections |
| 08:19 | <Hixie> | i think what would be simpler is to have one section per api point, and have the definition of the html and xml versions together. |
| 08:19 | <Hixie> | for each one. |
| 08:19 | <virtuelv> | Philip`: I'm not sure searching for occurences of <canvas in your corpus is an accurate means of measuring |
| 08:20 | <Hixie> | that way you don't have to have the table at the top to work out where on earth the feature is, etc. |
| 08:21 | <annevk> | Dynamic Stream Insertion and Dynamic Fragment Insertion or some such? |
| 08:21 | <annevk> | seems easy enough to merge the rest |
| 08:22 | <Hixie> | i was thinking more like "document.write" "innerHTML" "outerHTML" and "insertAdjacentHTML" |
| 08:23 | <annevk> | that would certainly make TOC searching easier :) |
| 08:49 | <Philip`> | http://news.bbc.co.uk/1/hi/uk/7853400.stm - "In 2007, the DVLA (Driver and Vehicle Licensing Agency) raised £83m by auctioning off previously unissued numbers." - I wish I could work out how to make a fortune by selling arbitrary numbers that have zero intrinsic value |
| 08:49 | <Philip`> | HTML5 needs to add some centrally-adminstered artificially scarce resources; the domain name people have got the right idea |
| 08:50 | <Hixie> | what do you think i'm refusing to allow extensibility of the element names? |
| 08:51 | <Philip`> | virtuelv: Depends what you're measuring - it's a fairly accurate means of measuring how many pages listed on dmoz.org use a <canvas> element in their markup :-) |
| 08:51 | <Philip`> | and it's not too hopelessly inaccurate to extrapolate that to a larger portion of the web |
| 08:52 | <virtuelv> | Philip`: yes, as long as you don't conflate use of <canvas> with use of canvas |
| 08:54 | <virtuelv> | also I suspect use of canvas is bigger off the traditional web |
| 08:54 | <virtuelv> | look at widgets/gadgets |
| 08:57 | <Philip`> | virtuelv: I think it's hard for me to find scripted uses of <canvas> since I haven't downloaded any scripts |
| 08:58 | <Philip`> | though I don't suppose there's any real reason why I couldn't add code to download scripts |
| 08:58 | <Philip`> | other than laziness |
| 09:00 | <ap> | Hixie: so, with the new redaction of the appcache spec, all HTML documents in an application need to have a manifest attribute, not just the main one. why is this helpful? |
| 09:02 | <ap> | Hixie: I thought of the manifest attribute as something that was only needed once, at the root level |
| 09:02 | <Hixie> | that's always how it's been, no? as far as i recall it's always has been my intent. why would you serve a page differently based purely on whether you'd loaded another page first? |
| 09:02 | <Hixie> | i don't understand what you mean |
| 09:03 | <ap> | Hixie: I'm fairly sure that previously, a document that was loaded from cache and that didn't have a manifest attribute was associated to the cache, and not marked as foreign |
| 09:03 | <ap> | Hixie: and that seemed like reasonable behavior to me |
| 09:04 | <Hixie> | hm |
| 09:04 | <Philip`> | Also: XHTML is dying - I saw 39 pages sent as application/xhtml+xml a year ago, and only 35 yesterday |
| 09:04 | <Philip`> | (Don't bother telling me about standard deviations or any of that nonsense - it's definitely dying!) |
| 09:04 | <ap> | Hixie: "serve a page differently based purely on whether you'd loaded another page first" - sure, it's a part of a locally installed offline application |
| 09:05 | <Hixie> | so once a page has had a manifest, even if you remove the manifest="" attribute, it'll keep being served from that manifest? |
| 09:06 | <ap> | Hixie: yes - I think I asked you about this a couple of weeks ago, and you answered that the manifest must become 404, and that's the only way |
| 09:06 | <Hixie> | ok well fair enough :-) |
| 09:09 | <Hixie> | ap: can you drop me a mail? i'm in the middle of a big reorg and i'm going to go to bed before i finish it. |
| 09:09 | <ap> | Hixie: will do |
| 09:09 | <Hixie> | thanks |
| 09:14 | <Hixie> | nn |
| 09:37 | <annevk> | http://andrewdupont.net/2009/01/27/thought-html5-and-the-alt-attribute/ |
| 09:38 | <annevk> | on twitter someone asked about getElementsByAttribute() |
| 09:38 | <annevk> | seems more like a Web DOM addition |
| 09:38 | <annevk> | zcorpan ^^ |
| 09:41 | <hsivonen> | annevk: sigh. still rampant point missing on the alt topic |
| 09:42 | <annevk> | I was mostly amused by that post "and the number of people on earth who care about valid HTML — but don’t care even a little about accessibility — could fit into my pants" |
| 09:44 | <hsivonen> | where's the spec for CSS :not()? |
| 09:45 | <hsivonen> | http://www.w3.org/TR/css3-selectors/ apparently |
| 09:50 | <Lachy> | annevk, we have querySelectorAll("[attribute]"); |
| 09:51 | <annevk> | not live |
| 09:51 | <annevk> | but yeah |
| 09:51 | <hsivonen> | annevk: why would anyone actually *want* live? |
| 09:51 | <hsivonen> | liveness is a design bug, IMO |
| 09:53 | <hsivonen> | hmm. I guess that looks weird if taken out of context |
| 09:56 | <annevk> | hmm, svg > video, svg :not(foreignObject) > video |
| 09:56 | <annevk> | and remove the > from the second selector |
| 09:56 | <annevk> | I think that would work fine |
| 09:57 | <annevk> | Lachy, ^^ |
| 09:57 | <hsivonen> | annevk: does that mean that none of the elements between svg and video is foreignObject or that there is at least one element there that isn't foreignObject? |
| 09:58 | <annevk> | you're right, it wouldn't work |
| 09:58 | <annevk> | :/ |
| 09:59 | <Lachy> | annevk, hsivonen, the only way to make it work effectively is to do this: |
| 09:59 | <Lachy> | "svg>a, |
| 09:59 | <Lachy> | svg>:not(foreignObject)>a |
| 09:59 | <Lachy> | svg>:not(foreignObject)>:not(foreignObject)>a |
| 09:59 | <Lachy> | svg>:not(foreignObject)>:not(foreignObject)>:not(foreignObject)>a |
| 09:59 | <Lachy> | ..." |
| 09:59 | <annevk> | indeed :/ |
| 09:59 | <annevk> | given that this use case is extremely minor anyway, it does not seem worth the effort |
| 10:00 | <Lachy> | given that no use cases have been presented yet, indeed |
| 10:06 | <annevk> | http://twitter.com/grorg/status/1131211278 :) |
| 10:08 | <Lachy> | haha |
| 10:09 | <Lachy> | annevk, what are you coming to Oslo for and how long are you staying? |
| 10:09 | <annevk> | meeting up with chaals and marcos, mostly |
| 10:09 | <annevk> | staying until Feb 15 |
| 10:11 | <Lachy> | cool. You're arriving just in time for the Global Village thing that Opera's doing for Friday beer this week |
| 10:12 | <annevk> | yeah, I heard that was on but wasn't sure whether I would want to represent the Dutch there :) |
| 10:55 | <Philip`> | "this discussion is going to become unbelievably verbose and tedious." - why use future tense? |
| 10:57 | <jgraham> | Philip`: No comment |
| 10:59 | <annevk> | I'm not really against the markup language specification, but it feels dodgy that nobody just says what it is for. Given that several people want it to be normative without really explaning why makes it seem like there is a hidden agenda. |
| 10:59 | <annevk> | s/explaning/explaining/ |
| 11:04 | <Lachy> | annevk, the hidden adgenda is to use it as leverage to split the language definition from the implementation requirements |
| 11:05 | <Lachy> | well, I guess it's not so hidden really |
| 11:06 | <hsivonen> | Lachy: if that's the agenda, it would be forthcoming to say that that indeed is the agenda, who wants it and why |
| 11:08 | <jgraham> | annevk: I have nothing against the markup language spec existing in non-normative form either. But people indeed seem to be wedded to the idea of it being normative despite the substantive arguments made against that |
| 11:09 | <annevk> | the main problem is that they're not explaining why; they use side step arguments such as that is not important to decide right now, etc. |
| 11:09 | <jgraham> | I wonder if it is percieved as a way to reduce the influence of browser vendors |
| 11:10 | <hsivonen> | jgraham: Gregory seems to perceive it that way: http://lists.w3.org/Archives/Public/wai-xtech/2009Jan/0060.html |
| 11:20 | <annevk> | "fullblown spec" how neutral |
| 11:25 | <Lachy> | hsivonen, with the moratorium on discussing spec splitting still effective within the group, discussing why isn't really an option yet. The point seems to be to sneak this through without having such a discussion |
| 11:25 | <rubys1> | i disagree |
| 11:25 | <rubys1> | the point is what annevk said a few hours ago |
| 11:26 | <rubys1> | "wow, what a bunch of hopeless discussions on public-html" |
| 11:27 | <rubys1> | http://lists.w3.org/Archives/Public/public-html/2009Jan/0453.html |
| 11:28 | <annevk> | hold on, I'm about to contribute... o_O |
| 11:30 | <Lachy> | rubys1, we have "an express lane" list already. It's called whatwg |
| 11:30 | <rubys1> | http://wiki.whatwg.org/wiki/FAQ#Are_there_plans_to_merge_the_groups.3F |
| 11:31 | rubys1 | wonders why /nick rubys doesn't work... |
| 11:31 | <Lachy> | rubys1, have you registered "rubys"? |
| 11:32 | <annevk> | there is a rubys already |
| 11:33 | <rubys> | ah, better |
| 11:39 | <rubys> | I am deeply skeptical that splitting the spec is possible. But "rational" discussion on the topic (which seems rare these days) isn't convincing anyone. I'd like to give the peole who wish to do so equal opportunity to succeed. We've noted that section 1.5.4 in hixie's draft sucks and moved on. I'd like to note that section 1.3 of Smith's draft sucks and move on. |
| 11:40 | <annevk> | rubys, I agree that complaining about that section is the wrong thing to do here |
| 11:41 | <Lachy> | But so far, unlike Hixie, Mike hasn't indicated that he will be revising that particular section in due course, and also unlike Hixie, Mike doesn't have a 6 month backlog to get through first |
| 11:41 | <annevk> | rubys, the problem seems to be that Mike is not upfront about why it needs to be normative |
| 11:41 | <jgraham> | rubys: I am sympathetic to that desire but it seems, at least, highl unusual for a W3C group to have two WDs that claim normativity about the same thing |
| 11:41 | <annevk> | Lachy, still, that section is not the reason people do not want to publish the draft |
| 11:42 | <annevk> | Lachy, also, several people have already stated they like that draft regardless of what that section says |
| 11:42 | <Lachy> | annevk, but we need to understand the intended audience and scope in order to understand the purpose of it and why it needs to be normative |
| 11:42 | <rubys> | jgraham: it is highly unusual to have one working draft that doesn't operate based on consensus. This working group is destined to be unusual. |
| 11:43 | <annevk> | Lachy, it seems better to just ask why it needs to be normative than to approach it indirectly |
| 11:43 | <rubys> | what I would like to do is capture an Issue on whether it needs to be normative or not, and block the draft from progressing past a WD state until that point is addressed. |
| 11:44 | <Lachy> | rubys, how about asking Mike to move forward with the draft as a non-normative FPWD at this stage, which will allow for wider, formal public review. And then if compelling evidence is presented for it to become normative later, it's easier to move it on to the REC track at that time |
| 11:45 | <rubys> | Lachy: how about I ask that Ian does the same? (no: I am *not* serious) |
| 11:45 | <annevk> | rubys, I have the feeling that leaving that unaddressed will make many people object which will then be subsequently be ignored because TimBL is in favor (well, I have that feeling, anyway) |
| 11:45 | <annevk> | rubys, but I suppose that if you want to get it published and cwilso agrees none of that should be an issue anyway |
| 11:46 | <Lachy> | annevk, I'm not sure even TimBL could get away with ignoring all the formal objections that seem likely to come from Mozilla, WebKit and presumably Opera, and many other individuals, if it goes forward with a normative status. |
| 11:47 | <jgraham> | rubys: It doesn't seem too unreasonable to treat all "incubator" projects as non-normative until they have proven their worth. So far the group has decided that HTML 5 ("Hixie's Document") has worth in fulfilling our charter requirements |
| 11:49 | takkaria | sighs |
| 11:49 | <annevk> | Lachy, we'll see; it seems most people have made their mind up so I guess we'll know soon enough unless something changes |
| 11:49 | <annevk> | Lachy, not sure I'd raise a FO over this by the way |
| 11:51 | <rubys> | jgraham: this group is clearly not all of one mind on "Hixie's document". |
| 11:51 | <Lachy> | annevk, I think we should. But we can discuss that if and when the question arises |
| 11:52 | <jgraham> | rubys: No but we had a vote and so on. I don't think we will do better than that on anything. |
| 11:53 | <rubys> | we had a vote. I even participated and eventually said yes. |
| 11:53 | <rubys> | the vote was on publishing a draft. |
| 11:53 | <rubys> | the vote was not on blocking others from doing the same |
| 11:54 | <annevk> | that's a strawman |
| 11:55 | <rubys> | I am very serious that I doubt that splitting the spec will be feasible. My site isn't called intertwingly for nothing. |
| 11:55 | <jgraham> | rubys: The vote was on adopting HTML 5 as the basis for our deliverable "A language evolved from HTML4 for describing the semantics of documents and applications on the World Wide Web" |
| 11:55 | <rubys> | (and, no, that's not a strawman) |
| 11:55 | <jgraham> | rubys: That deliverable must presumably have normative content |
| 11:56 | <annevk> | rubys, "the vote was not on blocking others from doing the same" is a misrepresentation of the other's opinion afaict |
| 11:56 | <Lachy> | rubys, why is your site called intertwingly? What does it mean? |
| 11:56 | <rubys> | annevk: fair enough |
| 11:57 | <rubys> | lachy: it facinates me that the further I delve into any topic, the more I am convinced that what some people view as clean layers turn out to be interdependent in a very twisted way. |
| 11:58 | <Lachy> | oh, is intertwingly a portmanteau of "intertwined" and something else? |
| 11:59 | <rubys> | http://en.wikipedia.org/wiki/Intertwingularity |
| 12:00 | <annevk> | rubys, you'd have fun being on the TAG |
| 12:00 | <rubys> | no I would not |
| 12:00 | <annevk> | ;) |
| 12:08 | <rubys> | oh, cool. I had forgotten that my blog is actually linked off of that wiki page |
| 12:11 | <MikeSmith> | parts of some recent discussions remind me of the made, way back when, against the Web API WG publishing the Web Forms 2.0 draft as a WD |
| 12:11 | <MikeSmith> | s/of the made/of the objections that were made/ |
| 12:12 | <rubys> | and how did that work out? |
| 12:12 | <MikeSmith> | the group published it, over the objections |
| 12:13 | <MikeSmith> | objections that went right up to the Director and the CEO and just about everybody else under the sun |
| 12:14 | <MikeSmith> | and which were stated in what some described in a fairly strident and shrill tone |
| 12:14 | <MikeSmith> | s/described/described as being/ |
| 12:15 | <MikeSmith> | denial-of-spec attacks are a lot more fun to watch from the sidelines |
| 12:18 | <annevk> | I tried staying out of this debate, but I have to say, that is a rather different story |
| 12:19 | <annevk> | WF2 defined new functionality for HTML4, XHTML1, and DOM2HTML forms. It did not define, say, a subset of SVG that just describes the markup language in a normative way. |
| 12:20 | <MikeSmith> | yeah, I wasn't trying to say that it was the same kind of spec debate |
| 12:20 | <annevk> | okidoki |
| 12:21 | <MikeSmith> | I was referring more to the character of parts the debate, and the nature of the way the objections were stated |
| 12:23 | <annevk> | yeah, objecting to the audience section is silly |
| 12:24 | <rubys> | Ian's objection is sane and appropriate. It should be noted, tabled (in the American sense of the word), and revisited at the appropriate time. |
| 12:25 | <annevk> | well, it might be an issue, but it's not the kind of issue that would stop publication |
| 12:25 | <rubys> | I very much like the way Ian points to specific sections in Mike's document and questions their readability. |
| 12:25 | <annevk> | if that's the case for not knowing the intent of the spec (why it needs to be normative) is a harder question imo |
| 12:26 | <rubys> | My take, and I will openly admit that it is just my take: many people here take it as a given that Ian's document will progress, and that previous votes entitle it to do so at the exclusion of all other proposals. |
| 12:27 | <rubys> | I do *not* see it as a given that Ian's draft will progress any further than as a Working Group Note. |
| 12:27 | <MikeSmith> | rubys: yeah, definitely. hard to argue that the regex Hixie pointed out isn't horribly ugly |
| 12:28 | <annevk> | rubys, I did have the feeling the HTML WG was formed to work on that document, yes, but I see your point |
| 12:29 | <rubys> | http://www.w3.org/2005/10/Process-20051014/tr.html#tr-end |
| 12:31 | <annevk> | I'm familiar with that document |
| 12:31 | <rubys> | lol. |
| 12:32 | <MikeSmith> | rubys: as far as the wrongness of that regex, it may well be wrong. I don't know, because I didn't write it. Or at least I don't think I did. |
| 12:32 | <rubys> | "I don't know" is a very profound statement, and goes to the heart of Ian's argument. |
| 12:32 | <jgraham> | rubys: Indeed. Practically it is hard to see how we can fulfil our charter without producing something substantially like Hixie's Document. If we don't fulfill our charter then the group will have failed which, I think would be very bad for W3C |
| 12:34 | <rubys> | jgraham: Putting aside the question of feasibility for a moment, I claim that a set of four documents that collectively cover the same material that Ian's does is "something substantially like Hixie's Document" |
| 12:34 | <rubys> | (no special meaning is intended by the number four, I could have picked twelve) |
| 12:36 | <rubys> | I found it very amusing that Roy Fielding chose to name his weblog "Untangled". |
| 12:36 | <annevk> | heh |
| 12:36 | <jgraham> | rubys: Well yes. That just follows if you believe that Hixie's document covers basically what we are required to cover. |
| 12:37 | <jgraham> | Of course not all possible splittings will result in combined works that are equally useful |
| 12:38 | <rubys> | ...including the one that puts everything into a single doc |
| 12:38 | <annevk> | I guess the idea might be to remove the need for Hixie being editor. DanC did talk about that in the past if I remember correctly... |
| 12:39 | <rubys> | I do *not* think that removing Hixie would be a good idea. |
| 12:39 | <rubys> | I also very much appreciate that he is not standing in the way of others |
| 12:39 | <annevk> | Would be cool if the W3C Team just stated that doing the markup language thing was part of fulfilling that goal... Or if not, what the goal is. |
| 12:40 | <MikeSmith> | "removing" Hixie as editor is a non-goal |
| 12:41 | <rubys> | Given that we have people willing to do the work, I would much rather be in a position to pick from the best (and to cross-polinate as much as possible) than to proceed in a waterfall fashion. |
| 12:42 | <rubys> | If splitting out the markup language is not technically feasible (and that has not been proven at this point), then I would much rather not establish that as a goal. |
| 12:46 | <annevk> | but splitting up the specification in markup language, API, parsing bits, etc. is somewhat of a goal? |
| 12:47 | <annevk> | it's certainly possible, with enough cross-references |
| 12:47 | Philip` | sees the main problem as being that people are implementing tools based on the current HTML5 draft, and people outside the WG are writing tutorials and pages based on it, and publishing two different drafts and giving them equal normative weight seems likely to cause confusion among those people because they wouldn't know which to rely on |
| 12:48 | <Philip`> | (Nobody cares that the current draft is just a draft and could change at any time - they still want to rely on it like they would on a published Recommendation) |
| 12:48 | <rubys> | Philip`: if they are consistent, it doesn't matter. If they aren't that's a bug. |
| 12:49 | <Philip`> | rubys: Even if they're consistent, I can imagine it would be confusing to people if it wasn't clear which one they should read |
| 12:50 | <takkaria> | it can be made clear, I'm sure |
| 12:50 | <Philip`> | rubys: But that could probably be solved by having a clear statement somewhere about the relationship between the documents |
| 12:50 | <jgraham> | rubys: That implies that the publication of the Markup Language spec as a normative FPWD places a significant burden on the group to keep them in sync at all times |
| 12:51 | <rubys> | jgraham: What implies that? |
| 12:51 | <rubys> | or are you merely asserting that? |
| 12:52 | <Philip`> | e.g. the Markup Language spec could state that it's been derived largely from implementations and has had far less review than the other document, and in case of discrepancies you should prefer the other document, and this document is just here as a work-in-progress attempt to make an easier-to-read document and if you think it's easier/harder to read then please send feedback etc |
| 12:53 | <rubys> | I like that |
| 12:53 | <zcorpan_> | annevk: http://simon.html5.org/dump/daddy2.svg http://simon.html5.org/dump/daddy3.svg - smaller and smaller still versions (the latter is a bit less accurate though) |
| 12:53 | <jgraham> | rubys: I guess I as making the assumption that the group doesn't want to unnecessarily confuse people who are interested in, and perhaps relying on, our work |
| 12:55 | <rubys> | Labelling the controversial areas (in both documents, BTW) is an excellent idea. |
| 12:55 | Philip` | doesn't care whether there's a line at the top saying "This document is informative" or "This document is non-normative", because he doesn't see that it makes any difference in practice |
| 12:55 | <Philip`> | Oops |
| 12:55 | <Philip`> | s/non-normative/normative/ |
| 12:57 | zcorpan_ | used http://tinyurl.com/avogmt (live dom viewer) to create daddy3 from daddy2 |
| 12:58 | <rubys> | I've learned to love firebug for that same purpose. |
| 13:12 | <MikeSmith> | rubys: have you used the Web Inspector in WebKit? and/or Opera Dragonfly? |
| 13:13 | <rubys> | Haven't found a version of webkit that runs well on Ubuntu; haven't tried Dragonfly. |
| 13:13 | <MikeSmith> | Philip`: I like your wording above ("...derived largely from implementations and has had far less review", etc.) |
| 13:14 | <MikeSmith> | rubys: arora |
| 13:14 | <MikeSmith> | it's fairly simple UI |
| 13:14 | <MikeSmith> | but includes a Web Inspector UI |
| 13:14 | <MikeSmith> | requires Qt |
| 13:15 | <MikeSmith> | http://code.google.com/p/arora/ |
| 13:15 | <rubys> | sweet: $ apt-cache search arora |
| 13:15 | <rubys> | arora - Simple cross-platform QtWebKit web browser |
| 13:16 | <MikeSmith> | its has some other problems/limitations that are related to the fact that it relies on Qt libraries that have limitations |
| 13:16 | <rubys> | something new to play with when I get back home |
| 13:16 | <Philip`> | The WebKit Gtk+ port seems nice, but I don't know if a nice browser interface exists for it |
| 13:16 | <Philip`> | MikeSmith: I don't like my wording at all :-) |
| 13:17 | <Philip`> | or at least I don't like the words |
| 13:17 | <Philip`> | but the concepts seem useful to convey to casual readers |
| 13:17 | <Philip`> | (and it would explain why e.g. some of the regexps are so ugly) |
| 13:18 | <MikeSmith> | yeah |
| 13:18 | <rubys> | I'm not thrilled with "prefer the other document". I like simple statements of facts that allow people to make informed judgements. |
| 13:18 | <rubys> | Openly state all the failings of the document, up front, and without any histrionics. |
| 13:19 | <jgraham> | The webkit-gtk demo browser turns out to be nice if you like minimal; it seems to have a back button, a forward button and a location bar |
| 13:19 | <jgraham> | and that's it |
| 13:19 | <MikeSmith> | btw, I'm wondering how much effect the LPGL'ing of Qt is going to have on the future of Gtk |
| 13:19 | <jgraham> | Oh and the location bar seems to be broken :) |
| 13:20 | <jgraham> | No wait, I forgot the http:// |
| 13:20 | <Philip`> | Maybe it could say something more "this document is derived from implementations that are derived from the other spec", which might sufficiently imply that the other spec is more authoritative |
| 13:20 | <Philip`> | s/more/more like/ |
| 13:20 | <Philip`> | and s/derived/partly derived/g |
| 13:21 | <Philip`> | and "authoritative" is probably not the right word either |
| 13:21 | <rubys> | there's more a symbionic relationship that that doesn't reflect. Henri's implementation has certainly exposed a number of issues that has caused Hixies draft to be improved. |
| 13:22 | <MikeSmith> | I'd wonder what the webkit-gtk demo browser relies on for other non-UI stuff, like caching, cookies, network code |
| 13:22 | <rubys> | At a much higher level, it is also true that Hixie's draft have been dervied largely from implementations... |
| 13:22 | <MikeSmith> | right |
| 13:23 | <Philip`> | MikeSmith: The minimalist demo browser relies on the seemingly quite complete WebKit/Gtk+ port, which seems to use libraries like those listed at http://trac.webkit.org/wiki/BuildingGtk#MacOSX |
| 13:23 | <Philip`> | (e.g. cURL for networking) |
| 13:23 | <MikeSmith> | you could just as well say that the whattf.org schema is "derived from" HTML4 |
| 13:23 | <MikeSmith> | or from the set of HTML that is supported in the real world in browsers |
| 13:24 | <jgraham> | epiphany-webkit also seems to work quite well but is a bit minimalist even for my tastes |
| 13:24 | <Philip`> | rubys: You could always use Safari in Wine :-) |
| 13:25 | <annevk> | zcorpan_, cool, they both seem fine |
| 14:58 | <annevk> | jgraham, any chance you'll visit Oslo in the next two weeks? |
| 14:58 | <annevk> | I'm not sure how to get that memory card to you |
| 14:59 | <zcorpan_> | rubys: http://simon.html5.org/tools/js/svg-optimizer/ |
| 15:00 | <annevk> | zcorpan_, maybe you should use a real parser :) |
| 15:00 | <zcorpan_> | annevk: yeah |
| 15:01 | <zcorpan_> | it's very naïve, but it works |
| 15:02 | <zcorpan_> | this is the sort of interface i'd like to see when saving as svg in illustrator |
| 15:03 | <jgraham> | annevk: None that I know of |
| 15:03 | <jgraham> | I guess post should work? |
| 15:04 | <annevk> | that sounds boring |
| 15:04 | <annevk> | I'll put it in my bag so it gets to Oslo and then figure something out :) |
| 15:04 | <jgraham> | Well I am happy to wait for an interesting solution :) |
| 15:05 | <zcorpan_> | annevk: for correctness, not only is an xml parser required but also css parser and transform="" parser, and then having knowledge of what to scale and what not to scale |
| 15:05 | <annevk> | the interesting solution is me getting to Linköping, but that is not going to happen before March |
| 15:05 | <annevk> | (at least) |
| 15:08 | <zcorpan_> | rubys: it'd be nice to have smiilar interface for SVG tidy |
| 15:08 | <zcorpan_> | similar |
| 15:10 | <Philip`> | zcorpan_: "XML parsing failed: syntax error (Line: 1, Character: 17)" |
| 15:10 | <Philip`> | <?xml version="1" encoding="UTF-8" standalone="no"?> |
| 15:12 | <zcorpan_> | Philip`: oops |
| 15:13 | <Philip`> | zcorpan_: and if I set quality to 2, I get <?xml version="2" encoding="UTF-16" standalone="no"?> |
| 15:17 | <zcorpan_> | Philip`: fixed |
| 15:22 | <rubys> | is the source to svg-optimizer available someplace? |
| 15:24 | <annevk> | rubys, view source :) |
| 15:28 | <jgraham> | zcorpan_: Can't you just use the browser to parse the SVG? |
| 15:28 | <rubys> | hmmm. maybe I should convert from ruby to javascript. |
| 15:29 | <zcorpan_> | jgraham: that only helps with the xml parsing part |
| 15:29 | <zcorpan_> | well and maybe css parsing part |
| 15:30 | <zcorpan_> | which are indeed the most annoying parts to implement |
| 15:48 | <zcorpan_> | maybe i can work around the problems while still having a naïve implementation by looking at the previous few characters (notably "xmlns", "#", "rotate(", etc) |
| 15:50 | <Philip`> | zcorpan_: Are you intending this to be a quick hack, or a serious usable tool? |
| 15:51 | <zcorpan_> | Philip`: the former |
| 15:53 | <Philip`> | In that case, your suggestion does not sound insane :-) |
| 16:08 | <zcorpan_> | hsivonen: validator.nu doesn't seem too useful for validating svg since it doesn't seem to validate the css parts (e.g. stroke="#0" passes) |
| 17:19 | Philip` | tries to work out the difference between LaTeX's "quote" environment and its "quotation" environment |
| 17:19 | <Philip`> | Hmm, apparently the latter adds paragraph indentation |
| 17:20 | <Philip`> | Not much of a semantic difference really :-( |
| 17:21 | <MikeSmith> | Philip`: do you edit LaTeX in a text editor, or use LyX or something? |
| 17:24 | <Philip`> | MikeSmith: Kile |
| 17:25 | <MikeSmith> | Philip`: does it have table editor? |
| 17:25 | <Philip`> | MikeSmith: which is a text editor with relevant buttons (like a list of fancy symbols) and some limited autocomplete, and key commands to run pdflatex and the PDF viewer |
| 17:25 | <MikeSmith> | I see |
| 17:25 | <Philip`> | MikeSmith: It has a menu item which causes the text "\begin{tabular}{} \end{tabular}" to be inserted into your document, and prints a brief syntax summary to a window at the bottom of the screen |
| 17:26 | <MikeSmith> | OK |
| 17:26 | <Philip`> | MikeSmith: It's not exactly WYSIWYG |
| 17:26 | <MikeSmith> | yeah, sounds like |
| 17:27 | <Philip`> | Hmph, Gmail tricked me into clicking an advert by making the little "New Message" popup window let my mouse clicks pass straight through |
| 17:34 | <MikeSmith> | Philip`: is there a sane way to specify row spans and column spans in LaTeX? |
| 17:40 | <Philip`> | MikeSmith: \multicolumn does colspans and sounds reasonably sane |
| 17:41 | <Philip`> | MikeSmith: I don't know about rowspans, and Kile's help page doesn't mention them at all |
| 17:43 | <Philip`> | http://osdir.com/ml/tex.brazilian/2003-04/msg00069.html suggests using \raisebox to have a cell contain a value that is lying about how tall it is and thus will overlap the following rows |
| 17:43 | <Philip`> | but that doesn't sound entirely sane |
| 17:44 | <MikeSmith> | Philip`: tbl tool that groff relies on relies on a markup mechanism where you have to specify the table structure in a sort of ascii prologue to the table itself. really seems to me like the worst way to do it |
| 17:44 | <MikeSmith> | for the man-page thing I did, I wrote an HTML-to-tbl converter |
| 17:45 | <MikeSmith> | which would really have been just dead simple except for needing to deal with generating the arcane table prologue thing for the case where there are rowspans or colspan |
| 17:45 | <Philip`> | It seems a reasonable way when the table has a consistent structure - for each row you just want to be entering the data, not worrying about writing all the right cell divisions and spacings and lines and everything |
| 17:46 | <MikeSmith> | true |
| 17:46 | <Philip`> | so in LaTeX you write something ugly like \begin{tabular}{r|l|l|l|l|l|l} at the start, but then each data row is just like "$S$ & $S$ & $\otimes$ & $M$ & $\Diamond$ & $\Diamond$ \\" |
| 17:46 | <gsnedders> | Ugly. |
| 17:46 | <MikeSmith> | hmm, that's pretty much like what tbl requires |
| 17:46 | <Philip`> | You wouldn't want to write a web page with nested layout tables in LaTeX |
| 17:47 | <gsnedders> | MikeSmith: I live. |
| 17:47 | <MikeSmith> | I've never written directly in LaTeX or groff, so I never really considered the markup from the perspective of actually writing it |
| 17:48 | <Philip`> | (You only need those "$"s if you're writing everything in math mode, not for normal plain text tables) |
| 17:48 | <MikeSmith> | just instead from perspective of converting into it |
| 17:48 | <MikeSmith> | gsnedders: I'm glad :) |
| 17:48 | <Philip`> | MikeSmith: Got to remember the priorities of constituencies :-) |
| 17:48 | <MikeSmith> | gsnedders: so the "SVG likely for IE9" statement was never actually made in IE chat? |
| 17:49 | <gsnedders> | MikeSmith: It was said it was something that had been requested a lot. Nothing more was said. |
| 17:49 | <gsnedders> | MikeSmith: (requested wrt IE9) |
| 17:49 | <MikeSmith> | OK |
| 17:49 | <Philip`> | (Requested wrt IE8 too) |
| 17:49 | <MikeSmith> | Philip`: have you used ConTeXt? |
| 17:50 | <Philip`> | MikeSmith: No |
| 17:50 | <MikeSmith> | it seems like there's all kinds of crazy cool stuff in that |
| 17:51 | <Philip`> | "including extensive support for colors, backgrounds, hyperlinks, presentations, figure-text integration, and conditional compilation" |
| 17:51 | <Philip`> | Those don't sound like things I'd personally find useful |
| 17:52 | <Philip`> | and anyway I'm mostly attempting to write things for conferences, who provide LaTeX style files that you really ought to use |
| 18:04 | <MikeSmith> | Philip`: I see. yeah, I guess ConTeXt is more focused on producing PDFs |
| 18:26 | <Dashiva> | Those who forget HTML4 are doomed to repeat it |
| 18:30 | <jcranmer> | what abou those who forget HTML 1? |
| 18:32 | <Dashiva> | HTML1's lessons are part of HTML4 |
| 18:35 | <Dashiva> | But really, when it's hard enough to state something clearly and correctly in one place, attempting to do it twice with different sentences is madness. |
| 20:34 | <Hixie> | i think it is time for me to just bite the bullet and write an "xml parser" spec-like-thing for html5 |
| 20:35 | <Hixie> | not like the html parser, of course |
| 20:35 | <Hixie> | but defining things like the steps for parsing a fragment |
| 20:35 | <Hixie> | serialising a fragmen |
| 20:35 | <Hixie> | etc |
| 20:35 | <Hixie> | basically the XML<->DOM glue spec |
| 20:35 | <gsnedders> | Hixie: Based on xml5? |
| 20:35 | <Hixie> | no |
| 20:35 | <Hixie> | this wouldn't be defining anything new |
| 20:35 | <gsnedders> | Or just defining XML 1.0 parsing? |
| 20:35 | <Hixie> | it would just simplify the spec a lot |
| 20:36 | <Hixie> | not defining any parsing |
| 20:36 | <Hixie> | just how to glue the xml rules to the dom |
| 22:54 | <annevk> | . |
| 22:55 | <Hixie> | % |
| 23:03 | <Philip`> | ※ |
| 23:03 | <hober> | @ |
| 23:03 | <xydyx> | ♥ |
| 23:04 | <Philip`> | hober: You broke the exponential growth of the dots :-( |
| 23:04 | <Hixie> | it didn't take many steps to get out of ASCII |
| 23:05 | <Hixie> | i was tempted to do it myself but i've had bad luck pasting non-ASCII into Terminal -> screen -> irssi |
| 23:06 | <Philip`> | I find it works fine once I've set LANG to be something with utf8 |
| 23:06 | <Philip`> | (in the environment into which screen is opened, and also in the environment into which irssi is opened) |
| 23:06 | <Hixie> | ※ |
| 23:06 | <Hixie> | i guess it works ok |
| 23:06 | <Hixie> | ※ |
| 23:07 | <Philip`> | It'll be nice in the future when we can always take Unicode support for granted |
| 23:08 | <Hixie> | most people already can |
| 23:08 | <Hixie> | it's only in the legacy guts like the command line that we have issues really |
| 23:09 | <smedero> | http://www.google.com/search?rls=en-us&q=%E2%98%83&ie=UTF-8&oe=UTF-8 |
| 23:09 | <smedero> | that always bums me out |
| 23:21 | <Philip`> | smedero: That's quite impressive - the fairly plain but armed snowman in the search box has turned into an armless but snow-surrounded snowman further down the page |
| 23:22 | <Lachy> | hey, Hixie, I added a scope and audience statment to the authoring guide. Do you think this accurately covers who it's for? http://dev.w3.org/html5/html-author/#scope |
| 23:23 | <Lachy> | oops, I should either finish or remove that last sentence of the audience section |
| 23:25 | <Hixie> | seems fine except that last sentence |
| 23:26 | <Lachy> | I'll remove it cause I can't think of a useful way to finish it |
| 23:36 | Lachy | attempts to coax some real use cases for adding namespace support to selectors api. Not having much luck. |
| 23:49 | <rubys> | namespace as in xml? |
| 23:53 | <Lachy> | rubys, yes. The ability to do document.querySelector("svg|a", namespaceResolver); |
| 23:55 | <Lachy> | so far, my assessment is that the majority of use cases can be done without worrying about namespaces, since most localName's don't clash between HTML, SVG and MathML, and where they do, there are trivial workarounds |
