| 00:03 | <taptapir> | roc, can you give little example? |
| 00:03 | <roc> | var a = new Audio(); |
| 00:05 | <roc> | a.innerHTML = "<source type='video/webm' src='potatoes.webm'><source type="video/ogg' src='potatoes.ogg'"; |
| 00:05 | <roc> | a.play(); |
| 00:05 | <roc> | that should work I think |
| 00:05 | <aho> | if you add some escape backslashes |
| 00:05 | <aho> | :> |
| 00:05 | <roc> | yeah? |
| 00:05 | <roc> | depends on the contxt I guess |
| 00:05 | <roc> | I also missed a closing > |
| 00:05 | <aho> | ye |
| 00:06 | <taptapir> | thanks |
| 00:06 | <taptapir> | will try |
| 00:06 | <aho> | i liked my approach better though .> |
| 00:07 | <aho> | i.e. not touching the dom and not invoking the html parser as well |
| 00:07 | <aho> | <: |
| 00:07 | <roc> | either way's fine, but my way's less code to write |
| 00:09 | <aho> | well, my personal use-case is somewhat different... i check codec is supported in order to download the right resource-blob (which contains everything) |
| 00:09 | <aho> | +which |
| 02:38 | <TheFuzzball> | Hi, I am trying to use <ul> and <li> recursively to make a list of lists, but it's not validating, can someone suggest an alternative? |
| 02:38 | <annevk> | yes, put the nested <ul> inside the <li> as per the specification |
| 02:40 | <TheFuzzball> | Ah, that makes sense, I was putting it outside of </li> |
| 02:40 | <TheFuzzball> | Thanks for that |
| 04:00 | <MikeSmith> | http://code.google.com/p/epub-revision/wiki/F2FDayTwo#EPUB_&_the_Web |
| 04:01 | <MikeSmith> | http://code.google.com/p/epub-revision/wiki/F2FDayTwo#CSS_2.1_/_CSS_3 |
| 04:02 | <MikeSmith> | rather: http://code.google.com/p/epub-revision/wiki/F2FDayTwo#relationship_to_CSS_2.1_and_CSS_3 |
| 04:02 | <MikeSmith> | oops |
| 04:02 | <MikeSmith> | ah un-oops |
| 04:02 | <MikeSmith> | that's the right links |
| 04:02 | <MikeSmith> | *link |
| 04:03 | <MikeSmith> | see this part: |
| 04:03 | <MikeSmith> | "Markus: trial close - we as WG want to have a preferred/core grammar which is compatible with a subset of HTML5" |
| 04:03 | <MikeSmith> | and this: |
| 04:03 | <MikeSmith> | http://code.google.com/p/epub-revision/wiki/F2FDayTwo#STRAW_POLL_=_overwhelming_support_for_Markus's_proposition |
| 04:03 | <MikeSmith> | "STRAW POLL = overwhelming support for Markus's proposition" |
| 04:05 | <annevk> | also contains commentary from Norman Welsh on HTML5 -- rare |
| 04:06 | <MikeSmith> | yeah |
| 04:06 | <MikeSmith> | I believe Norm joined the ePub 2.1 WG recently |
| 04:06 | <MikeSmith> | I'm trying to find a public mailing list for the group |
| 04:06 | <MikeSmith> | I think there isn't one |
| 04:06 | <MikeSmith> | but they do seem to at least publish their telcon and f2f minutes |
| 04:07 | <MikeSmith> | e.g., most recent telcon: http://code.google.com/p/epub-revision/wiki/Telcon20100624 |
| 04:08 | <MikeSmith> | the recent huge growth in the e-book market would seem to make this ePub 2.1 update especially important |
| 04:08 | <MikeSmith> | draft requirements for global language support - |
| 04:08 | <MikeSmith> | http://code.google.com/p/epub-revision/wiki/EGLS_requirement_list |
| 04:11 | <roc> | that transcript pretty annoying |
| 04:15 | <MikeSmithX> | roc: what particular part of it? |
| 04:15 | <roc> | the Webkit == HTML5 stuff |
| 04:15 | <MikeSmithX> | the fact that they seem to think Webkit is the only HTML5 browser engine on the market? |
| 04:15 | <MikeSmithX> | ah |
| 04:15 | <MikeSmithX> | yeah, we need to educate them about that |
| 04:16 | <MikeSmithX> | roc: would behoove us to try to get some browser people in that group |
| 04:16 | <MikeSmithX> | I think most of their f2f meetings are in NYC |
| 04:16 | <roc> | get Rob Sayrer in their group, that'd shake them up |
| 04:16 | <MikeSmithX> | heh |
| 04:16 | <MikeSmithX> | that'd shake any group up |
| 04:17 | <roc> | the other annoying thing is their complaining about CSS 2.1 being unstable |
| 04:17 | <MikeSmithX> | yeah, there clearly seem to be some misperceptions there about a few things |
| 04:18 | <roc> | there are all these W3C specs that made it to REC because they didn't have good test suites, or wide implementation, or real-world content to deal with |
| 04:18 | <MikeSmithX> | annevk: I suggest you might want to bring the ePub 2.1 stuff to that attention of Lars-Erik and Chaals |
| 04:18 | <MikeSmithX> | annevk: and bug them about getting some people into that group |
| 04:18 | <roc> | so a lot of people think that stuff like XSL-FO is somehow "more mature" than CSS 2.1 |
| 04:18 | <roc> | which is laughable |
| 04:19 | <MikeSmithX> | yeah |
| 04:19 | <MikeSmithX> | but in that transcript there does at least seem to be a hint of pragmatism and understanding about market realities |
| 04:20 | <roc> | yeah |
| 04:20 | <roc> | that's good |
| 04:21 | <MikeSmithX> | e.g., "Markus: rational for supporting XML with DAISY was that web was evolving to XML vocabularies as first-class, but in practice this hasn't happened" |
| 04:21 | <MikeSmithX> | nattokirai: good timing |
| 04:21 | <annevk> | "Brady: multi-column layout is eligible for exiting CR in next few days, maybe it's time to go to W3C and use muscle" -- they're in for a surprise :) |
| 04:21 | <nattokirai> | MikeSmithX: what's up? |
| 04:21 | <MikeSmithX> | nattokirai: we were just talking about the new ePub 2.1 work |
| 04:22 | <nattokirai> | oh lordy |
| 04:22 | <MikeSmithX> | nattokirai: ePub 2.1 seems likely to end up being based on what's actually being implemented in current browsers |
| 04:22 | <MikeSmithX> | nattokirai: btw, I had lunch with Makoto Murata the other day |
| 04:23 | <MikeSmithX> | part of what we talked about was... vertical text |
| 04:23 | <MikeSmithX> | see http://code.google.com/p/epub-revision/wiki/EGLS_requirement_list |
| 04:24 | <MikeSmithX> | nattokirai: I think it would be really helpful to get technical people from some browser projects involved in that group |
| 04:24 | <nattokirai> | so, the problem is this |
| 04:24 | <nattokirai> | ePub has a very specific set of requirements |
| 04:24 | <MikeSmithX> | nattokirai: Murata-san tells me there is a related meeting going on in August in Sapparo |
| 04:24 | <nattokirai> | that don't quite match HTML in the large |
| 04:24 | MikeSmithX | nods |
| 04:24 | <nattokirai> | for example |
| 04:25 | <nattokirai> | wtf is to be done with form controls? |
| 04:25 | <MikeSmithX> | nattokirai: I believe that part of what they are doing with the ePub 2.1 is some course correction to address that problem |
| 04:25 | <nattokirai> | vertical versions? |
| 04:25 | <MikeSmithX> | nattokirai: yeah, understood |
| 04:25 | nattokirai | shudders |
| 04:25 | <nattokirai> | and the dark corners of css3 are all impacted |
| 04:26 | <MikeSmithX> | that's why we should get some people in there to help them understand |
| 04:26 | <annevk> | ah, /whois nattokirai clears things up, hey John :) |
| 04:26 | <nattokirai> | howdy |
| 04:26 | <nattokirai> | i could be wrong but i think vertical text is really going to mean a full rewrite |
| 04:26 | <MikeSmith> | nattokirai seems to have a magic way of showing up any time we start to talk about stuff related to layout |
| 04:26 | <nattokirai> | of a lot of layout engines |
| 04:26 | <MikeSmith> | wow |
| 04:27 | <MikeSmith> | well, that'd suck |
| 04:27 | <MikeSmith> | or actually, it would not happen |
| 04:27 | <MikeSmith> | not for a long time at least |
| 04:27 | <roc> | right, that won't happen |
| 04:27 | <nattokirai> | well, i think the right time to address it is as part of some form of grid layout |
| 04:27 | <boblet> | ouch |
| 04:27 | <nattokirai> | in whatever form that takes |
| 04:28 | <roc> | where do things come unstuck if we define vertical layout as a rotation transformation plus setting some kind of 'glyph-orientation' property? (That can also affect certain replaced elements such as images) |
| 04:28 | <MikeSmith> | which means that people in Japan and Taiwan who want to read e-books that more closely match the user experience of real books will instead have to read PDFs or something else not based on HTML+CSS |
| 04:28 | <nattokirai> | roc: so you need to flow across columns |
| 04:28 | <annevk> | or Internet Explorer starts dominating their market :p |
| 04:29 | <nattokirai> | so transformations aren't really right |
| 04:29 | <roc> | I'm not sure what you mean |
| 04:29 | <roc> | some Chinese newspapers have horizontal columns, but that would work OK |
| 04:29 | <MikeSmith> | annevk: yeah, no joke -- seriously market opportunity for IE9 in the eBook market .. let's try to keep it a secret |
| 04:30 | <nattokirai> | well, like mirroring in bidi you have different vertical punctuation forms |
| 04:30 | <boblet> | heh |
| 04:30 | <roc> | well, except "IE9" and "mobile" can't really be used in the same sentence |
| 04:30 | <nattokirai> | heh |
| 04:30 | <nattokirai> | MikeSmith: i actually think xsl 1.1 is closer to what ePub wants |
| 04:31 | <MikeSmith> | roc: btw, another note of pragmatism from the minutes: "Markus: rational for supporting XML with DAISY was that web was evolving to XML vocabularies as first-class, but in practice this hasn't happened" (Markus is CTO of DAISY and chair of the WG) |
| 04:31 | <boblet> | ruby on vertical text would no doubt be an extra layer of fun to implement too |
| 04:31 | <annevk> | given how complex CSS layout is nowadays it sort of dazzles me when I try to think of vertical |
| 04:31 | <nattokirai> | well, ruby is easy compared to things like warichu |
| 04:31 | <MikeSmith> | nattokirai: xsl 1.1 as opposed to what? CSS? |
| 04:31 | <annevk> | especially how certain complicated parts of CSS layout nowadays are not defined (e.g. tables) |
| 04:31 | <nattokirai> | which is two columns of text displayed within a larger column |
| 04:31 | <roc> | nattokirai: selecting correct character forms could be handled without much hassle |
| 04:31 | <nattokirai> | yup |
| 04:32 | <nattokirai> | roc: i think it's completely doable but there are still lots of dependencies that need to be worked out |
| 04:32 | <roc> | seems like the way to go then |
| 04:33 | <roc> | since it can be done incrementally |
| 04:33 | <nattokirai> | so you define vertical versions of pop-up menus? |
| 04:33 | <roc> | popups already have interesting interactions with CSS transforms |
| 04:33 | <roc> | this would be no different |
| 04:33 | <nattokirai> | i can imagine |
| 04:34 | <roc> | making popups transform correctly isn't actually all that hard |
| 04:34 | <boblet> | damn, can’t afford to make it to Tokyo this week. will be sorry to miss your talk nattokirai |
| 04:34 | <roc> | make the widget the right size, make it transparent, carry in the transform when rendering, and Bob's your uncle |
| 04:34 | <nattokirai> | boblet: i'll post slides... |
| 04:34 | <roc> | if you actually want to do that. I think it would freak people out. |
| 04:35 | <nattokirai> | heh |
| 04:35 | <roc> | I think having an untransformed popup appear in roughly the right place would be satisfactory, wouldn't it? |
| 04:35 | <nattokirai> | dunno, might work |
| 04:36 | <nattokirai> | but it relates back to the whole top is right debate |
| 04:36 | <roc> | I mean, it's not as if we're striving to faithfully render Qin dynasty popups |
| 04:36 | <nattokirai> | well, it's not totally unreasonable |
| 04:36 | <nattokirai> | tests in japan are given in vertical form |
| 04:37 | <nattokirai> | so having radio buttons flow vertically should be natural |
| 04:37 | <nattokirai> | and fairly simple |
| 04:38 | <nattokirai> | i think this really requires a vertical layout module |
| 04:38 | <nattokirai> | that tries to cover the minimal set needed to make things work |
| 04:38 | <nattokirai> | otherwise you'll be playing spec whack-a-mole |
| 04:39 | <nattokirai> | MikeSmith: yeah, so i think xsl 1.1 instead of css makes sense for the ePub requirements |
| 04:42 | <nattokirai> | roc: btw, did you follow the whole physical vs. logical dimensions debate? |
| 04:42 | <roc> | I have in the past |
| 04:42 | <roc> | in fact, I instigated the latest round of it |
| 04:42 | <roc> | I may have not kept up recently |
| 04:42 | <nattokirai> | so you think it makes sense to add margin-before/after/start/end? |
| 04:43 | <roc> | ohhhh |
| 04:43 | <roc> | sorry |
| 04:43 | <roc> | I was thinking about units |
| 04:43 | <roc> | nattokirai: vertical-flowing radio buttons would work fine with a transforms-based approach |
| 04:44 | <MikeSmith> | nattokirai: where are you going to be presenting? |
| 04:44 | <roc> | the question you raised was whether we need to be able to have a single stylesheet that can intelligently style content without knowing what the orientation is |
| 04:44 | <roc> | right? |
| 04:44 | <nattokirai> | yes |
| 04:44 | <nattokirai> | MikeSmith: WDE ex, Apple Store Ginza, wed eve |
| 04:45 | <MikeSmith> | ah good |
| 04:45 | <nattokirai> | roc: not sure about transforms |
| 04:46 | <nattokirai> | roc: you need to use vertical metrics, use vertical glyphs, and some layout features will be vertical specific |
| 04:46 | <roc> | right so some layout features need to use vertical forms |
| 04:47 | <nattokirai> | so the natural thing is to key off writing-mode |
| 04:47 | <nattokirai> | plus you have to deal with full-width/half-width issues to do it right |
| 04:48 | <nattokirai> | i.e. in horizontal mode use proportional glyphs but in vertical use full-width |
| 04:48 | <roc> | but at least you start from a position where everything is well-defined, and then you add features or specialize behaviour in some places to get better results |
| 04:49 | <nattokirai> | you can force that down into the content but it's really more styling |
| 04:50 | <nattokirai> | yeah, i think the best way forward is to use writing-mode |
| 04:50 | <nattokirai> | and add some property *values* like start, end to text-align |
| 04:50 | <nattokirai> | but stay away from "logical" properties like margin-before/after/start/end |
| 04:50 | <roc> | yeah |
| 04:51 | <roc> | did anyone come up with good use-cases for being able to style content independent of the orientation? |
| 04:51 | <nattokirai> | it's an ePub thing |
| 04:51 | <nattokirai> | ePub readers allow a user to flip orientation |
| 04:52 | <nattokirai> | horizontal vs. vertical |
| 04:52 | <roc> | they could have two stylesheets? |
| 04:52 | <nattokirai> | yes but the claim is that's too much of a burden |
| 04:53 | <roc> | how about a pseudo-class on the root element for the "master" writing-mode? |
| 04:53 | <nattokirai> | yes, i think that's what murata-san is thinking about now |
| 04:53 | <nattokirai> | a 'principal-writing-mode' or something like that |
| 04:53 | <roc> | really need some examples |
| 04:54 | <annevk> | then you have a selector directly depending on a property |
| 04:54 | <roc> | of content that can be viewed in either mode and that's burdensome to style with multiple rules or stylesheets |
| 04:54 | <roc> | annevk: not if you have the UA set that psuedo-class externally |
| 04:54 | <roc> | so the same thing that sets the initial writing-mode also sets the selector state |
| 04:55 | <annevk> | so if you then overwrite it it's okay? |
| 04:55 | <annevk> | seems kind of odd, but I guess you only need it for such a flip scenario |
| 04:56 | <nattokirai> | roc: http://lists.w3.org/Archives/Public/www-style/2010Jun/0133.html |
| 04:56 | <nattokirai> | roc: examples of Latin text and numerals in Japanese text layout |
| 04:57 | <roc> | yeah |
| 04:57 | <roc> | I've seen similar stuff in some Chinese papers |
| 04:57 | <roc> | note though |
| 04:57 | <roc> | some of what they do is probably "we don't know what we're doing" rather than "it really needs to be done this way" |
| 04:57 | <nattokirai> | heh |
| 04:58 | <roc> | especially where they're being inconsistent! |
| 04:58 | <nattokirai> | well, there are absolute rules and fuzzy rules, as with anything |
| 04:58 | <nattokirai> | distinguishing between the two is a subtle art i think |
| 05:03 | <nattokirai> | MikeSmith: so what's the event in Sapporo? |
| 05:09 | <MikeSmith> | nattokirai: gimme a few minutes, I'll get you the details |
| 06:25 | <hsivonen> | interesting change of attitude at epub/DAISY |
| 06:54 | <MikeSmith> | hsivonen: yeah |
| 06:54 | <MikeSmith> | and encouraging |
| 07:16 | <hsivonen> | MikeSmith: whether it's encouraging depends on whether it results in requirements that are off-focus for the Web being brought into the HTML WG |
| 07:17 | <hsivonen> | but how can a group be concerned that CSS 2.1 might not be stable enough and at the same time be wanting extensibility |
| 07:17 | <hsivonen> | ? |
| 07:17 | <hsivonen> | isn't extensibility a gaping loophole of instability? |
| 07:23 | <MikeSmith> | I'm not even sure what they mean by "extensibility" |
| 07:24 | <MikeSmith> | or what anybody does |
| 07:25 | <othermaciej> | who thinks CSS 2.1 is not stable enough? |
| 07:25 | <MikeSmith> | Murata-san did mention something to me about a particular vocabulary from another vocab that there is some use case for including in ePub files |
| 07:26 | <MikeSmith> | to which I said I'd like to know the particular use case |
| 07:26 | <MikeSmith> | and that it may well be that addressing that use case does not require namespace support in order to include some existing vocab |
| 07:26 | <MikeSmith> | and may not even require that particular vocab at all |
| 07:29 | <MikeSmith> | hsivonen: and yeah, one would think that for a format like this especially, where you have particularly constrained devices that it's meant to be deployed on, a mechanism for arbitrary extensibility would not be a great way to ensure interoperability and stability |
| 07:29 | <MikeSmith> | but as always, it'd help for everybody to keep an open mind |
| 07:30 | <MikeSmith> | othermaciej: I am told there are some Apple folk who are in the ePub 2.1 WG, but in looking through the names of the people who attended the f2f, I don't see names of anybody familiar from Webkit team |
| 07:31 | <othermaciej> | I can try to find out who if anyone is involved from Apple |
| 07:31 | <MikeSmith> | othermaciej: there's a long list of attendees here: |
| 07:31 | <MikeSmith> | http://code.google.com/p/epub-revision/wiki/F2F201006Agenda |
| 07:32 | <MikeSmith> | damn, that really is a long list, too |
| 07:32 | <MikeSmith> | 60 people |
| 07:32 | <othermaciej> | I didn't recognize any of the names |
| 07:32 | <othermaciej> | that is indeed a long list |
| 07:33 | <hsivonen> | othermaciej: Gregory's comment seemed to imply instability of CSS 2.1, but maybe I was reading too much into it |
| 07:34 | <hsivonen> | then in the other end of the spectrum there's the participant who'd just go with what WebKit does |
| 07:35 | <hsivonen> | MikeSmith: is the Michael Smith on the participant list someone else who doesn't have (tm)? |
| 07:35 | <MikeSmith> | hsivonen: it's someone who's not me :) |
| 07:36 | <hsivonen> | ok |
| 07:36 | <MikeSmith> | and also someone who's probably not the same Michael Smith who is a Google Chrome product manager |
| 07:36 | <MikeSmith> | hsivonen: about the Webkit mentions, roc commented on that earlier |
| 07:36 | MikeSmith | notices rolandsteiner |
| 07:37 | <MikeSmith> | rolandsteiner: we been having some discussion here today about the ePub 2.1 work |
| 07:37 | <MikeSmith> | which includes some work to try to address "global language" needs, and vertical text in particular |
| 07:37 | <othermaciej> | someone seemed to think MathML was a reason for extensibility, because WebKit doesn't support it yet (at least not complete or on by default) |
| 07:38 | <MikeSmith> | rolandsteiner: if you're interested, see scrollback and/or http://krijnhoetmer.nl/irc-logs/whatwg/20100628 |
| 07:38 | <MikeSmith> | hamaji: ↑ also |
| 07:39 | <othermaciej> | it is quite surprising how many times webkit is mentioned by name in the minutes there |
| 07:39 | <MikeSmith> | othermaciej: hmm, OK.. well that just seems like confusion about what extensibility is about |
| 07:39 | <MikeSmith> | othermaciej: one guy who mentions it a few time seems to be at Adobe |
| 07:39 | <MikeSmith> | "Ric" in the minutes |
| 07:40 | <hsivonen> | is Bill McCoy the same Bill McCoy as the one who participated briefly on the WHATWG list in 2005? http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-January/002784.html |
| 07:40 | <MikeSmith> | Ric = Ric Wright, Adobe |
| 07:41 | <othermaciej> | someone in those minutes indirectly says the HTML5 standards process is "highly politicized" |
| 07:41 | <othermaciej> | "CSS3 != HTML5. The specification process for CSS3 modules is not highly-politicized and many modules have seen renewed interest in recent weeks." |
| 07:41 | <MikeSmith> | hsivonen: I would guess so, yes - http://blogs.adobe.com/billmccoy/ |
| 07:42 | <MikeSmith> | http://billmccoybooks2.blogspot.com/ |
| 07:42 | <othermaciej> | someone else says: "to all intents and purposes HTML5 is whatever is in Webkit nightlies, you are deluding yourself if you are waiting for W3C" |
| 07:42 | <othermaciej> | (that's Ric W I guess?) |
| 07:42 | <MikeSmith> | othermaciej: is the HTML5 standards process not highly politicized? |
| 07:42 | hsivonen | notes that the WHATWG email was before the Macromedia merger when Adobe has the Adobe Intelligent Document Platform thing going on with PDF and Reader |
| 07:43 | <hsivonen> | s/has/had/ |
| 07:43 | <MikeSmith> | and anybody who thinks that there's not some politics in the CSS WG as well obviously doesn't know much about that group |
| 07:43 | <othermaciej> | MikeSmith: I decline to comment on the merits of that statement one way or the other, for obvious political reasons |
| 07:43 | <MikeSmith> | heh |
| 07:43 | <othermaciej> | standards are politics |
| 07:43 | <MikeSmith> | amen |
| 07:44 | <MikeSmith> | anybody who believe otherwise is fooling themselves |
| 07:44 | <othermaciej> | the moment independent parties need to agree on something, you are fundamentally engaged in a political exercise |
| 07:44 | <MikeSmith> | yep |
| 07:45 | <MikeSmith> | and if you just instead sit around agreeing with each other, that's a possible sign that you are not talking about anything that anybody else cares about |
| 07:45 | <othermaciej> | or as wikipedia would put it, "Politics is a process by which groups of people make collective decisions." |
| 07:45 | <MikeSmith> | othermaciej: I disagree with you about that |
| 07:45 | <MikeSmith> | (sorry, I just figured I needed to throw in some token disagreement to support my point) |
| 07:45 | <othermaciej> | MikeSmith: no, you! |
| 07:46 | <MikeSmith> | OK, clearly I will only be victimized and ridiculed here -- I will now go off to start a different channel |
| 07:46 | <MikeSmith> | or actually, I think I will instead just do all my commenting on twitter |
| 07:47 | <MikeSmith> | or as comments on other people's blogs |
| 07:49 | <MikeSmith> | for some reason that seems like a better way than the strategy that has so for resulted in seeing actual features getting implemented all over the place in shipping browsers |
| 07:49 | <MikeSmith> | but hey, who cares about stuff being implemented |
| 07:49 | <MikeSmith> | anyway, I digress |
| 07:51 | <MikeSmith> | meanwhile, abarth|InBody wakes up, parachutes in, and hits the ground running |
| 07:52 | <MikeSmith> | if I don't have a conformant HTML5 tree builder in Webkit by the end of this week, I'm going to withdraw my ambassador |
| 07:53 | <othermaciej> | heh |
| 07:53 | <nessy> | lol |
| 07:53 | <MikeSmith> | or file a formal diplomatic protest with Ban Ki Moon |
| 07:59 | <MikeSmith> | hsivonen: http://www.webpaper.net/blog seems to be Bill McCoy's current venture |
| 08:01 | <MikeSmith> | "And that Adobe would be passing around back-slaps for an Apple-forced port from ActionScript to Objective C, calling that "innnovation" is, well, kind of sad." |
| 08:01 | <MikeSmith> | he has a way with words, that's for sure |
| 08:10 | <abarth|InBody> | MikeSmith: we only recently where able to parse the document "<html>" |
| 08:11 | <abarth|InBody> | MikeSmith: having a fully conformant tree builder by the end of the week is a bit ... optimistic :) |
| 08:15 | <hsivonen> | MikeSmith: it's kinda sad that so many people want to put paper-like stuff on the Web instead of putting Web-like stuff on the Web |
| 08:19 | <hsivonen> | wow. if Adobe's Reader Mobile SDK doesn't support the "enterprise" features of PDF, it seems like an admission that PDF peaked at 1.4 |
| 08:20 | <hsivonen> | PDF 1.4 seems to be what everyone outside Adobe was targeting anyway |
| 08:24 | <Dashiva^2> | What are the enterprise features? |
| 08:25 | <othermaciej> | what version of PDF has those? |
| 08:25 | <hsivonen> | Dashiva^2: "interactive forms, security of the Livecycle PolicyServer variety, JavaScript, and digital signatures" |
| 08:25 | <hsivonen> | quoting from http://billmccoybooks2.blogspot.com/2010/01/q-what-pdf-version-for-ebooks.html |
| 08:25 | <MikeSmithX> | abarth|InBody: well, I'm an optimist.. if I weren't, I guess I'd be doing something else for a living |
| 08:26 | <hsivonen> | also, the later versions of PDF have *totally* off-focus CAD features |
| 08:26 | <MikeSmith> | abarth|InBody: anyway, I'm just trying to giving you some grief.. I realize it'll take a while |
| 08:26 | <MikeSmith> | e.g., maybe two weeks instead of one |
| 08:27 | <hsivonen> | too bad Adobe's PDF went bad after 1.4 |
| 08:28 | <hsivonen> | now if you want some good post-1.4 features, there's no easy shorthand for talking about 1.4 + the good parts of later PDF versions |
| 08:29 | <hsivonen> | (I count the ability to apply the deflate algorithm to everything a good part albeit a marginal one) |
| 08:32 | <Dashiva^2> | Javascript seems more like a bug than a feature in PDF... |
| 08:32 | <hsivonen> | Dashiva^2: indeed |
| 08:33 | <hsivonen> | btw, what's for Windows what Preview is for Mac and Evince is for Gnome? |
| 08:34 | <Dashiva^2> | Foxit? Not sure what Preview and Evince "are" |
| 08:34 | <hsivonen> | Dashiva^2: Preview and Evince are faster than Adobe Reader and (I believe) have fewer serious exploitable security holes or are at least less actively being exploited |
| 08:35 | <abarth|InBody> | hsivonen: notepad? |
| 08:35 | <Dashiva^2> | Then probably Foxit |
| 08:36 | <hsivonen> | abarth|InBody: I meant for users who aren't comfortable with only viewing source in the PDF case |
| 08:36 | <MikeSmith> | hsivonen: about the wanting paper-like stuff on the Web problem -- yeah, it seems like some people maybe "can't see the forest for the trees" (or whatever metaphor) -- that is, they seem overly focused on trying to replicate the print-reading experience on the Web, and not nearly enough focused on trying to see how to best exploit the richer features of the Web to deliver and even better reading experience |
| 08:36 | <hsivonen> | Dashiva^2: thanks |
| 08:36 | <othermaciej> | MikeSmith: making good flexible layouts is hard |
| 08:37 | <hsivonen> | is the business model of Foxit Reader to be a gateway drug for their PDF creation stuff? |
| 08:37 | <MikeSmith> | well, there are some features that we currently have only in print that are very important |
| 08:37 | <othermaciej> | it's also hard to get truly top quality typography about of browser-grade text layout engines |
| 08:37 | <hsivonen> | othermaciej: that's partly because raw speed is overrated |
| 08:38 | hsivonen | gestures at the direction of WebKit on Mac not doing ligatures for Latin text where Cocoa text views and Gecko do |
| 08:38 | <MikeSmith> | othermaciej, hsivonen - e.g., vertical text is very important part of the user experience for reading in Japan .. lack of it for normal reading of e-books is a pretty big deal |
| 08:38 | <othermaciej> | raw speed of text layout? |
| 08:38 | <MikeSmith> | othermaciej: top-grade typography is not a high priority.. but being able to read vertical text is |
| 08:39 | <hsivonen> | othermaciej: why else would you not have the usual Mac ligature experience in WebKit? |
| 08:39 | <othermaciej> | I'm not even thinking specifically of ligatures, necessarily, I'm thinking of things like good quality justification (for which hyphenation is one prerequisite) |
| 08:39 | hsivonen | wants hyphenation in Web engines |
| 08:40 | <othermaciej> | actually we just landed some hyphenation support in webkit |
| 08:40 | <othermaciej> | not sure which ports support it right now though |
| 08:40 | <othermaciej> | (it's opt-in with a CSS property) |
| 08:40 | <hsivonen> | othermaciej: sure, but isn't the lack of ligatures an indication that typography is sacrificed for speed benchmarks? |
| 08:40 | <othermaciej> | I can imagine supporting contextual forms and kerning pairs in latin scripts eventually, either through an opt-in CSS property or because we find a way to make the common case very fast |
| 08:41 | <othermaciej> | it's true that we care more about page load speed than ligatures in latin scripts (or at least have historically) |
| 08:41 | <hsivonen> | I think at least at some point there was a hidden pref in Safari for turning on better typography |
| 08:41 | <othermaciej> | WebKit's text rendering (in the fast-path case) is much much much much faster than any of the native APIs on Mac OS X |
| 08:42 | <othermaciej> | you can force everything to go through the slow path |
| 08:42 | <hsivonen> | othermaciej: but also uglier |
| 08:42 | <othermaciej> | I think our eventual strategy has to be to extend the fast-path code to handle things like kerning and ligatures |
| 08:42 | <hsivonen> | "Qu" on my site looks worse in WebKit than it does in Gecko on Mac |
| 08:43 | <othermaciej> | a lot of very visually picky people use Safari every day |
| 08:43 | <othermaciej> | I am inclined to say our choice of tradeoffs is reasonable |
| 08:43 | <hsivonen> | in Gecko, the 'Q' extends nicely under the 'u' |
| 08:44 | <hsivonen> | othermaciej: too bad there aren't many ligatures in Helvetica, so we don't got Gruber to call you on this :-( |
| 08:44 | <othermaciej> | Qu is of course a kerning pair not a ligature |
| 08:45 | <othermaciej> | (as far as I can tell anyway, and in the default font |
| 08:45 | <hsivonen> | I thought the Q was a contextual alternative glyph |
| 08:45 | <hsivonen> | it's not just kerning |
| 08:45 | <hsivonen> | (I'm not suggesting it were a ligature) |
| 08:46 | <othermaciej> | I'm looking in Times 16 point and I don't see indications of an alternate glyph |
| 08:46 | <othermaciej> | but then, I'm not the most visually acute person in the world |
| 08:46 | <hsivonen> | othermaciej: the text is supposed to be in @font-face Linux Libertine |
| 08:46 | hsivonen | wonders why WebKit isn't applying the font |
| 08:46 | <othermaciej> | oh, on your site in particular |
| 08:47 | <othermaciej> | I thought you were referring to Qu in general |
| 08:47 | <othermaciej> | mea culpa |
| 08:47 | <hsivonen> | othermaciej: I meant "Qu" on my site in particular |
| 08:48 | <othermaciej> | it does however look like Safari is not applying the font (at least for me) on your site |
| 08:48 | <hsivonen> | othermaciej: I guess that's a bug in WebKit/Safari, then |
| 08:48 | <hsivonen> | othermaciej: I've had people point out to me that the font isn't getting applied |
| 08:49 | <hsivonen> | othermaciej: but debugging it is hard, because Apple doesn't allow me to virtualize a vanilla copy of OS X |
| 08:49 | <hsivonen> | and if the font exists on any mounted volume, Safari finds it |
| 08:49 | <hsivonen> | which is kinda creepy |
| 08:50 | <hsivonen> | and makes it hard to investigate the problem on a system I actually use |
| 08:50 | <othermaciej> | I believe the font server is going to get less aggressive with hunting for fonts |
| 08:51 | <othermaciej> | anyway, I can see the alternate glyph looking at your page in Firefox (that might actually be a ligature) |
| 08:51 | <hsivonen> | othermaciej: does WebKit require a particular MIME type for fonts? |
| 08:51 | <othermaciej> | it's also true that Firefox kerns Qu tighter than Safari does in Times |
| 08:51 | <othermaciej> | probably, but I don't know for sure |
| 08:51 | <zcorpan_> | hmm, the Q doesn't extend under the u in opera |
| 08:52 | <othermaciej> | I notice all your fonts have a .gz extension which makes me wonder if you end up serving gzip files rather than truetype files with gzip transfer-encoding |
| 08:52 | <hsivonen> | othermaciej: IIRC, they are served as text/plain with gzip encoding |
| 08:52 | <othermaciej> | if I download one of the fonts, FontBook opens it, so something in the system is sniffing it |
| 08:52 | <othermaciej> | but that might not happen in the font loading path |
| 08:52 | <hsivonen> | maybe I should try font/ttf or application/octet-stream |
| 08:53 | <othermaciej> | I can definitely see that Safari loads all the font files |
| 08:53 | <hsivonen> | othermaciej: surely safari should ungzip those resources before the font subsystem gets to sniff? |
| 08:53 | <othermaciej> | if it's a transfer-encoding then it will |
| 08:54 | <othermaciej> | if it's just gzipped, then Safari will still decompress while downloading and sniff when done and/or based on extension |
| 08:54 | <Dashiva^2> | I find myself wanting a native hash function in JS |
| 08:54 | <Dashiva^2> | Wasn't that supposed to be in es5? |
| 08:54 | <othermaciej> | I believe the ES committee has been persuaded to add such a thing |
| 08:54 | <othermaciej> | but I fear the next ES version may take forever |
| 08:54 | <hsivonen> | Content-Encoding: gzip |
| 08:57 | <othermaciej> | I guess I will debug it sometime, but not tonight |
| 08:57 | <othermaciej> | from reading the code it seems like it should ignore the MIME type |
| 08:58 | <abarth|InBody> | othermaciej: ignoring mime type = sadness in the future |
| 08:59 | <othermaciej> | abarth|InBody: probably! - might be too late for this one though |
| 09:00 | <othermaciej> | I'm not sure there even is a correct mime type for opentype fonts |
| 09:00 | <hsivonen> | I'm pretty sure there isn't |
| 09:00 | <hsivonen> | all hooray for IANA |
| 09:00 | <zcorpan_> | iirc annevk tried to get font/ttf but failed |
| 09:00 | <hsivonen> | it's possible that WebKit has been ignoring those fonts since at least February 2009 |
| 09:01 | <hsivonen> | but I haven't gotten around to investigating and filing a bug, because I was unable to investigate on the instances of Mac OS X I actually use myself |
| 09:01 | <othermaciej> | I don't think I have ever seen your site in the correct font before |
| 09:01 | <othermaciej> | zcorpan_: why did he fail? |
| 09:02 | <zcorpan_> | othermaciej: not sure. i think he was the only one who cared, or something |
| 09:02 | <othermaciej> | I'm surprised there is not even a "font" top-level content type |
| 09:38 | <roc> | hsivonen: raw performance is not overrated |
| 09:38 | <roc> | raw performance is everything |
| 09:39 | <roc> | the CAD stuff in Acroread is actually licensed from a New Zealand company |
| 09:40 | <roc> | I think we could get completely adequate book-reading typography in browsers with a combination of optimizations and CSS opt-in |
| 09:42 | <hsivonen> | roc: if raw perf is everything, why does Gecko do nice things for Latin text? |
| 09:42 | <roc> | on Windows and Linux, we actually don't |
| 09:43 | <hsivonen> | oh. :-( |
| 09:43 | <roc> | we have fast paths that bypass the shaper |
| 09:43 | <roc> | on Mac, well, we never got around to implementing the fast paths |
| 09:43 | <roc> | also the performance difference was never measured to be stunningly huge on Windows and Linux |
| 09:44 | <hsivonen> | roc: will the feature be available for opt-in once harfbuzz is used on all platforms? |
| 09:44 | <roc> | it's available for opt-in right now |
| 09:44 | <roc> | users can opt in via about:config, authors can opt in via text-rendering:optimizeLegibility |
| 09:44 | <roc> | (the latter also works on some Webkit ports, as I understand it) |
| 09:45 | <hsivonen> | nice. |
| 09:45 | <roc> | with Harfbuzz we're going to carefully measure the performance difference. Right now, Harfbuzz has no fast path |
| 09:45 | <hsivonen> | it sucks, though, that the default is optimizeBenchmarks |
| 09:45 | <roc> | it's not just benchmarks |
| 09:45 | <hsivonen> | what's the deal with camelCase in CSS? |
| 09:46 | <roc> | SVG screwed up |
| 09:46 | <hsivonen> | :-( |
| 09:46 | <roc> | Harfbuzz is considerably more optimizable of course, so I'm quite hopeful we can get away without any fast paths |
| 09:47 | <roc> | and we cache shaped text at the word level quite aggressively |
| 09:48 | <kling> | roc: harfbuzz performance is on the ToDo whiteboard behind me :] |
| 09:48 | <roc> | also, with Harfbuzz we can move most text shaping off the main thread if it's still showing up in profiles |
| 09:48 | <roc> | kling: get it off the whiteboard and check it in :-) |
| 09:48 | <annevk> | othermaciej, nobody seemed to care enough and then browsers shipped and all was lost |
| 09:49 | <kling> | roc: getting there eventually. memory usage is the larger problem ATM |
| 09:49 | <othermaciej> | annevk: still sorta seems worth doing but it seems like the MIME registry operates too slowly for Web reality |
| 09:50 | <roc> | interesting. if there are any regressions there we'll see them when Jonathan flips the switch |
| 09:52 | hsivonen | wonders what happens when a benchmark starst using optimizeLegibility... |
| 09:52 | <roc> | then we optimize it! |
| 09:53 | <hsivonen> | there should be an acid test measuring legibility and giving browsers points for typographic nice things |
| 09:55 | <hsivonen> | wow. Gecko has special UTF-8 decoder code for arm |
| 09:55 | <roc> | yes |
| 09:55 | <roc> | shaping text runs across element boundaries should be worth five million points |
| 09:56 | <roc> | but since that's not a "CSS feature", I don't expect to see it |
| 10:00 | <zcorpan_> | MikeSmith: hmm. i'm not sure it's a good idea to make <annotation-xml encoding=...> affect the tree building |
| 10:01 | <annevk> | http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-January/002852.html is somewhat interesting (via that link from hsivonen earlier) on an attempted definition of the platform |
| 10:02 | hsivonen | notes that Hixie had xml:id on the list. boo |
| 10:03 | <hsivonen> | whoa. XML Events is on Hixie's list too |
| 10:03 | <hsivonen> | why? |
| 10:07 | <annevk> | maybe because of SVG and Opera |
| 10:07 | <annevk> | I was kind of surprised by those too |
| 10:10 | <MikeSmith> | zcorpan_: why would it not be a good idea to make <annotation-xml encoding=...> affect the tree building? |
| 10:10 | <zcorpan_> | MikeSmith: seems complicated and i still don't know the use case :) |
| 10:10 | <zcorpan_> | MikeSmith: how do you parse the encoding="" attribute? parsing mime types is not defined |
| 10:11 | <hsivonen> | I hope we aren't going to parse attribute values beyond comparing with a constant |
| 10:11 | <MikeSmith> | zcorpan_: what hsivonen said |
| 10:12 | <MikeSmith> | we have existing HTML attributes that are defined in HTML5 as taking an MIME type |
| 10:12 | <annevk> | why is <annotation-xml> back in the picture? |
| 10:12 | <MikeSmith> | or at least one such attribute |
| 10:12 | <zcorpan_> | MikeSmith: they don't affect parsing |
| 10:12 | <MikeSmith> | annevk: because there is existing content that has HTML in annotation-xml |
| 10:13 | <MikeSmith> | and the parsing algorithm currently barfs on HTML in annotation-xml |
| 10:13 | <MikeSmith> | in a particularly ungraceful way |
| 10:13 | <zcorpan_> | where's the existing content? |
| 10:15 | <MikeSmith> | zcorpan_: some examples at Mozilla MDC, at least |
| 10:15 | <MikeSmith> | and I suspect that there are a few people who have created content base on those |
| 10:16 | <zcorpan_> | mozilla mdc is a wiki, it's easier to fix than changing the spec :) |
| 10:16 | <MikeSmith> | heh |
| 10:16 | <MikeSmith> | anyway, the reason those were created to begin with is that apparently people believe that is the way to include foreign content in MathML |
| 10:16 | <MikeSmith> | they have come to believe that for whatever reason |
| 10:17 | <MikeSmith> | perhaps based on a misreading of the MathML spec |
| 10:18 | <zcorpan_> | http://www.google.se/search?q=%22annotation-xml%22+site%3Adeveloper.mozilla.org |
| 10:19 | <zcorpan_> | http://www.google.com/codesearch?q=%3Cannotation-xml+encoding%5Cs%2A%3D%5Cs%2A%28%22%7C%27%29text%2Fhtml&hl=en&btnG=Search+Code |
| 10:20 | <MikeSmith> | zcorpan_: point taken |
| 10:21 | <MikeSmith> | I will personally not be very unhappy if the spec were changed to just drop annotation-xml content on the floor |
| 10:22 | <MikeSmith> | but if we keep the current SVG-in-annotation-xml support, I can understand that users might find it frustrating that the can include SVG but not HTML |
| 10:23 | <MikeSmith> | hey, there is even an example in the MathML3 spec of HTML in annotation-xml |
| 10:23 | <zcorpan_> | google code searching for just "<annotation-xml" i see mostly mathml in there, but also openmath and "<tt><code>" but that's without any encoding attribute |
| 10:23 | MikeSmith | goes to find it |
| 10:23 | <MikeSmith> | at this point, the case of HTML without the encoding attribute is not one I'd suggest trying to support |
| 10:25 | <Lachy> | Philip`, do you have any data analysing the use of <meta http-equiv="Content-Language"> compared with HTTP Content-Language? |
| 10:25 | <zcorpan_> | http://www.w3.org/TR/MathML3/chapter5.html#mixing.elements.annotation.xml |
| 10:25 | <hsivonen> | oh right. there are polls that need objecting to :-( |
| 10:26 | <MikeSmith> | zcorpan_: http://www.w3.org/TR/MathML3/chapter5.html#id.5.2.3.2 |
| 10:26 | <Lachy> | Specifically, I'm interested in data that shows whether or not sites that use the <meta> element for this also use Content-Language in HTTP. (My assumption is that they don't, and thus the meta is indeed not widely used for server side processing, as Roy claimed) |
| 10:27 | <hsivonen> | zcorpan_: I'm not fond of the idea of supporting <html>, <head> or <body> there... |
| 10:27 | <zcorpan_> | hsivonen: i agree |
| 10:28 | <MikeSmith> | zcorpan_: that is admittedly not a great example. but because it's in the MathML spec, I think it could also lead users to assume it should be supported in UAs |
| 10:28 | <MikeSmith> | anyway, I will send a message today to the public MathML list asking for use cases |
| 10:28 | <annevk> | removing annotation-xml entirely wfm |
| 10:29 | <MikeSmith> | wfm too personally |
| 10:29 | <MikeSmith> | not sure it will be a popular choice among end users, though |
| 10:30 | <Philip`> | Lachy: All I can see is http://philip.html5.org/data/meta-http-equiv-content-language-values.txt |
| 10:31 | <Philip`> | Lachy: (and http://philip.html5.org/data/http-headers.txt for header counts) |
| 10:31 | <hsivonen> | Dashiva^2: I can now see what the business model for the free Foxit reader is |
| 10:32 | <hsivonen> | Dashiva^2: seems to be installware |
| 10:32 | <Philip`> | Lachy: (Those are from different sets of pages, I think) |
| 10:32 | <hsivonen> | Dashiva^2: it defaults to changing the default browser search engine to Ask.com, installing a toolbar of somekind somewhere and adding an eBay shortcut to somewhere |
| 10:33 | <hsivonen> | Dashiva^2: not to suggest that Adobe Reader were any better |
| 10:35 | <Lachy> | Philip`, ok. No worries then. I probably don't need it, but would might have been a nice addition to my argument for ISSUE-88 |
| 10:37 | <Philip`> | Lachy: I could extract the raw content-language header/meta data from the latest page set pretty easily, and you could find some way to analyse it (count the number of pages in one set or the other or both) |
| 10:40 | <Lachy> | Philip`, could you extract it in a way that associates the <meta> elements used on the page with the value of the Content-Language used, if any? |
| 10:42 | <Lachy> | so, e.g. I can see if example.com uses "Content-Language: en, fr" in the HTTP, but decalares <meta http-equiv="Content-Language" content="en"> in the page. |
| 10:44 | <Lachy> | my assumption is that if, as I suspect, servers aren't using server side processing to extract the meta Content-Language to and set the HTTP headers, then we'll see a significant portion of pages using the the meta element, either without the HTTP header or with different values. |
| 10:47 | <Philip`> | Lachy: I think I could do that later today, if I don't forget |
| 10:49 | <Lachy> | thanks. |
| 11:00 | <Dashiva^2> | hsivonen: Yeah, it's become a lot worse recently |
| 11:00 | <Dashiva^2> | Like three different screens you have to disable stuff on |
| 11:09 | <boblet> | anyone have thoughts about RDFa’s @datatype? I’m trying to think of a situation where it’d be applicable to have more than one kind of data type for an @itemprop that wouldn’t be specced in advance (similar to datetime’s conformance rules) |
| 11:10 | <boblet> | yoshiaki: hello :) |
| 11:10 | <yoshiaki> | boblet, hello!! |
| 11:16 | <MikeSmith> | yoshiaki: hey! |
| 11:16 | <yoshiaki> | Hey! MikeSmith!! |
| 11:17 | <MikeSmith> | yoshiaki is an intern at W3C Japan and a doctoral student at Keio U. here |
| 11:17 | <MikeSmith> | and a great guy |
| 11:17 | <MikeSmith> | so be nice to him! |
| 11:18 | <MikeSmith> | or he will kill you |
| 11:18 | <yoshiaki> | Nice to meet you, all. I am Yoshiaki Fukami. |
| 11:18 | <kennyluck> | Yoshiaki's famous quote, "you need different protocol to talk to different people" (ref. old-style Japanese companies) |
| 11:22 | <jgraham> | MikeSmith: Is on-on-one combat a requirement for W3C internships these days? |
| 11:25 | <MikeSmith> | jgraham: yeah, the test is that all interns have to be able to beat me up |
| 11:25 | <yoshiaki> | I will never kill person who loves world wide web :) I am very happy to join this community. |
| 11:25 | <hsivonen> | boblet: as I understand it, @datatype isn't there to support a use case but it's there for RDF completeness |
| 11:26 | <jgraham> | MikeSmith: Yeah, but I was asking about combat |
| 11:26 | <hsivonen> | boblet: RDFa puts the ability to encode arbitrary RDF above use cases |
| 11:26 | <jgraham> | boblet: I thought the usecase was something like being able to have a distance and specify a unit of miles or a unit of picometres |
| 11:27 | <jgraham> | But that might have been something else |
| 11:27 | <MikeSmith> | jgraham: you probably don't really want me to go into details about the combat.. it's not pretty |
| 11:28 | <MikeSmith> | hsivonen: I recall that Manu recently said the HTML+RDFa spec is a strict superset of the Microdata spec |
| 11:28 | <hsivonen> | MikeSmith: yeah, he said so on twitter. I haven't verified the claim. |
| 11:29 | <jgraham> | boblet: (if that is the use case it is a bad idea; mixing units like that is a really bad idea) |
| 11:29 | <Dashiva^2> | Yeah, data types should be handled by the ontology, IMO |
| 11:29 | hsivonen | wonders how datatypes ended up on the RDF level in the first place |
| 11:30 | <jgraham> | hsivonen: Did you look at the API? I let my eyes slide across it for a few fractions of a second and it looked somewhat complex, but I didn't look hard enough to form a proper opinion |
| 11:30 | <hsivonen> | jgraham: I haven't reviewed the latest API draft properly |
| 11:30 | <MikeSmith> | well, it sounds like it is an intentional design goal, at least. given that, it would seem like it might be useful for the HTML+RDFa spec to include a section explaining to implementors and users which features to drop in order can to create Microdata-friendly processors and documents |
| 11:30 | <hsivonen> | jgraham: I searched it for the string "Microdata" and concluded that the document doesn't spell it out to the reader that the API is supposed to support Microdata |
| 11:31 | <jgraham> | Yeah, iirc it just said something like "this could also be used for microdata" |
| 11:31 | <MikeSmith> | perhaps that HTML+RDFa spec could define a Microdata-compatible processor as one of its conformance classes |
| 11:32 | <MikeSmith> | and then the spec could specify that Microdata-compatible processors are not required to implement support for particular features |
| 11:34 | <hsivonen> | MikeSmith: if done properly, wouldn't the result be a restatement of the Microdata spec? |
| 11:35 | <hsivonen> | is Object a magic type in WebIDL? |
| 11:35 | <jgraham> | hsivonen: What do you mean "magic type"? |
| 11:35 | <hsivonen> | jgraham: I mean something special |
| 11:36 | hsivonen | sees http://dev.w3.org/2006/webapi/WebIDL/#idl-object |
| 11:36 | <hsivonen> | but that's lower case |
| 11:36 | <hsivonen> | but the last sentence of that section says Object |
| 11:36 | <hsivonen> | hmm |
| 11:37 | <jgraham> | hsivonen: What is the context? |
| 11:38 | <hsivonen> | jgraham: the RDFa API spec has WebIDL stuff where type is Object |
| 11:41 | <hsivonen> | the RDFa API spec has some non-normative advertising content |
| 11:41 | <hsivonen> | "RDFa 1.0 [RDFA-SYNTAX] has seen substantial growth since it became an official W3C Recommendation in October 2008. It has seen wide adoption among search companies, e-commerce sites, governments, and content management systems. There are numerous interoperable implementations and growth is expected to continue to rise with the latest releases of RDFa 1.1 [RDFA-CORE], XHTML+RDFa 1.1 [XHTML-RDFA], and HTML+RDFa 1.1 [HTML-RDFA]." |
| 11:42 | hsivonen | wonders if those who oppose to Hixie's political editorialization have already filed bugs about the advertising in the RDFa API spec |
| 11:44 | <othermaciej> | I think self-puffery is a different matter than deprecation of others |
| 11:44 | <othermaciej> | (though in this case it seems a little over the top for a technical specification) |
| 11:45 | <othermaciej> | MikeSmith: is it claimed to be a feature-wise superset, or does it literally include all the exact markup constructs of Microdata? |
| 11:48 | <othermaciej> | I cannot find evidence of "itemprop" or "itemscope" in any of RDFa 1.1 Core, XHTML+RDFa 1.1 or HTML+RDFa 1.1 |
| 11:51 | <MikeSmith> | othermaciej: feature-wise, I assume. I don't think the intention it to use the exact markup constructs |
| 11:53 | <kennyluck> | I had the same impression as othermaciej got, and was very surprised that "itemprop" or "itemsope" is in RDFa. :) |
| 11:53 | <kennyluck> | s/is/was/ |
| 11:54 | <MikeSmith> | hsivonen: yeah, I suppose it could be seen as being a restatement, if it does in fact end up being that.. I guess the difference would be that it defines additional features for those implementations that choose to support them, and those authors who choose to use them |
| 11:54 | <othermaciej> | if there's a subset of RDFa 1.1 that has a trivial one-to-one mapping to Microdata, that might be interesting to identify |
| 11:55 | <othermaciej> | it might be complicated to do that if you want to make the microdata generate the same RDF triples when converted to RDF that RDFa does |
| 11:56 | <kennyluck> | ''' |
| 12:24 | <Lachy> | Does anyone know if there is any reason to avoid the WIndows 7 64bit edition in favour of 32bit? Does Windows 7 x64 still suffer from the same compatibility problems that XP x64 did? |
| 12:25 | <Lachy> | I suppose, I should check driver compatibility for my hardware and availability of 64bit anti-virus software, etc. |
| 12:26 | <Philip`> | Are you going to run any applications that need >4GB memory each? |
| 12:27 | <gsnedders> | Lachy: Yes, there's still no support for Win16. |
| 12:27 | <gsnedders> | Oh, wait, you don't care about that? |
| 12:27 | <hsivonen> | Philip`: I gather perf benefits from more general purpose registers are a more significant consideration than RAM |
| 12:27 | <jgraham> | Philip`: Used any modern web browsers recently? :p |
| 12:27 | <gsnedders> | Then Vista and Win7 have been fine in 64-bit mode |
| 12:29 | <Lachy> | are there any real benefits, given that my current hardware doesn't support more than 4GB of RAM anyway? |
| 12:30 | <gsnedders> | More general purpose registers |
| 12:30 | <Philip`> | hsivonen: There's also perf loss from using up more cache storing pointers, so I'm not sure there's a clear benefit except in a few specific applications (ones that do lots of computation but don't do it all with SSE) |
| 12:30 | <Lachy> | does that help much with widely deployed, older software that I have? |
| 12:30 | <hsivonen> | Philip`: I have been lead to believe the difference is significant on SunSpider |
| 12:31 | <hsivonen> | Philip`: and perf on SunSpider matter more for perception than real-world perf :-/ |
| 12:32 | <Philip`> | Lachy: It makes no difference unless the software is recompiled as a 64-bit binary |
| 12:32 | hsivonen | notes "HyBI (BiDirectional or Server-Initiated HTTP)" in the IETF 78 announcement/invitation |
| 12:33 | <Lachy> | Philip`, that's what I thought |
| 12:34 | <Lachy> | although, I suppose, since my main use case is running it on my Macs, in a virtual machine, and if and when I upgrade my Mac, I'll likely get 8GB of RAM. That might be a good excuse to go for 64 bit now. |
| 12:35 | <Lachy> | my other use case, will be for running it on the HTPC that I'm considering building soon, but I don't know the exact hardware for that yet. |
| 12:35 | <Philip`> | Lachy: With 32-bit Windows and 4GB RAM and suitable kernel options, each application can only use 3GB but the whole system can use all 4GB |
| 12:36 | <Philip`> | Actually that works for any value of "4GB" that is <= 64GB |
| 12:36 | <hsivonen> | Philip`: why 3 GB? |
| 12:36 | <Philip`> | hsivonen: http://blogs.msdn.com/b/oldnewthing/archive/2004/08/05/208908.aspx |
| 12:38 | <Dashiva^2> | Not all 4 GB, surely, since some of the address space is also lost to device mapping (graphics card) |
| 12:39 | <hsivonen> | Philip`: interesting that they implemented 3 GB instead of doing the simpler 2 GB user / 2 GB kernel thing only |
| 12:39 | <Lachy> | hmm, is Windows available with a multiple-machine licence, like OS X's family pack, or will I have to buy a new full copy for every machine I have? |
| 12:41 | <jgraham> | So is it deliberate that html breakout elements in foreign lands only break out of one level of foreignness? |
| 12:42 | <Philip`> | Dashiva^2: I think what happens is that if you don't have PAE then Windows can only see 3.5GB physical address space (the rest is BIOS stuff), but if you do have PAE then it can see 64GB physical address space and can then access all 4GB of RAM plus the BIOS stuff |
| 12:43 | <hsivonen> | Lachy: Microsoft doesn't even allow you to install 32-bit and 64-bit in dual boot without purchasing 2 licenses |
| 12:43 | <Philip`> | (You probably can't have 64GB RAM then, but at that point you ought to get a 64-bit CPU) |
| 12:43 | <MikeSmith> | for those who've not gotten their quota of drama for the day - |
| 12:43 | <MikeSmith> | http://news.cnet.com/8301-30685_3-20008935-264.html |
| 12:43 | <hsivonen> | jgraham: I don't know |
| 12:43 | <Dashiva^2> | I didn't know there was a quota |
| 12:44 | <Philip`> | hsivonen: Why wouldn't they implement the 3GB switch, since it's presumably not terribly complex and it lets customers easily use 50% more RAM? |
| 12:44 | <MikeSmith> | though that article's less dramatic than some might have hoped for I suppose |
| 12:44 | <MikeSmith> | "oversight of the future Web isn't collapsing, it's just rebalancing" |
| 12:45 | <hsivonen> | Philip`: I admit that I don't know how the 3 GB switch is implemented on the CPU memory protection level, so I'll shut up now |
| 12:50 | Dashiva^2 | notes that MikeSmith's article includes mention of the awesome HTML5 feature geolocation |
| 12:53 | <MikeSmith> | all good new features that have gone into the Web platform recently are by definition HTML5 features |
| 12:54 | <MikeSmith> | and any bad features that may have also gone in are by definition not HTML5 features |
| 13:01 | <hsivonen> | speaking of drama: http://lists.w3.org/Archives/Public/public-html-comments/2010Jun/0035.html |
| 13:08 | <boblet> | hsivonen, jgraham thanks for your input |
| 13:08 | <boblet> | MikeSmith: “it might be useful for the HTML+RDFa spec to include a section explaining to implementors and users which features to drop in order can to create Microdata-friendly processors and documents” I’d like that too |
| 13:09 | <annevk> | hsivonen, will be interesting to see how that goes |
| 13:11 | <boblet> | and an HTML5 version of the RDFa primer http://www.w3.org/TR/xhtml-rdfa-primer/ would be nice too |
| 13:38 | <roc> | now I don't feel so bad about duking it out with other Mozilla people in public |
| 14:27 | <MikeSmith> | "Needs more vuvuzela." |
| 14:30 | <annevk> | argh |
| 14:30 | <annevk> | security considerations for XMLHttpRequest are a pain |
| 14:31 | <annevk> | basically, I don't think it needs any, but trl wants some weasel wording in there that repeats what's been said and adds some fluff that's really a way more generic problem than XMLHttpRequest |
| 14:31 | <annevk> | like DNS rebinding |
| 14:32 | <zcorpan_> | fluff should be easy |
| 14:32 | <annevk> | it's all easy in a way, but it doesn't make any sense to me |
| 14:33 | <zcorpan_> | just copy stuff from abarth|InBody's cookie spec, it has lots of stuff on security that surely applies to xhr also |
| 14:33 | <annevk> | I believe I can certainly write something that will make the "problem" go away, but I don't believe it will actually improve anything |
| 14:40 | <boblet> | the phenny bot in #swik is pretty cool |
| 14:40 | <boblet> | s/swik/swig/ |
| 14:42 | boblet | is resisting the urge to be all “thanks for the interwebs” fanboi-ish to timbl who’s there |
| 14:44 | mhausenblas | thinks we owe timbl a lot, boblet ... for example an open and free WWW ;) |
| 14:45 | <boblet> | mhausenblas: oh noes! you’ve discovered I’m part of the cabal ;-) |
| 14:45 | <hsivonen> | how long should it take for a response to show up on http://www.w3.org/2002/09/wbs/40318/issue-88-objection-poll/results ? |
| 14:45 | <annevk> | yours shows for me |
| 14:45 | <boblet> | mhausenblas: and yeah I definitely feel so, but I bet timbl has heard it enough times. don’t wanna be annoying |
| 14:46 | <hsivonen> | annevk: odd. it shows to me in a browser I didn't use for responding |
| 14:46 | <mhausenblas> | sure thing, boblet ;) |
| 14:46 | <hsivonen> | but it doesn't show in the browser I used after reloading several times |
| 14:46 | <annevk> | maybe some wrong caching directives |
| 14:46 | <annevk> | HTTP isn't easy |
| 15:03 | <jgraham> | Sigh. I just found out one of our developers had been unwittingly reading the /TR/ version of the spec |
| 15:04 | <annevk> | nothing new there :/ |
| 15:04 | <Dashiva^2> | Oh dear |
| 15:04 | <MikeSmith> | jgraham, annevk - time for you guys to add some stuff to browser.js |
| 15:05 | <MikeSmith> | have it redirect all TR requests to dev.w3.org |
| 15:05 | <MikeSmith> | that's assuming this Opera developer is actually using Opera as her/his browser of course |
| 15:05 | <Dashiva^2> | Or have it redirect HTML5 to whatwg.org :) |
| 15:05 | <annevk> | jgraham, http://lists.w3.org/Archives/Public/public-html/2010Jun/0451.html |
| 15:07 | <Philip`> | jgraham: Someone from Mozilla (I forget who) was unwittingly reading the author version of the spec some time ago, and got confused about there not being any behaviour specified |
| 15:07 | <Dashiva^2> | Philip`: Sounds like HTML4, eh |
| 15:08 | <jgraham> | Philip`: That is sad |
| 15:08 | <jgraham> | Hmm |
| 15:08 | <jgraham> | Sad isn't quite what I mean |
| 15:08 | <jgraham> | Anyway... I at least believe that the author view has real utility |
| 15:09 | <jgraham> | I think the group of people that want stable but wrong snapshots is purely hypothetical |
| 15:09 | <annevk> | I've yet to hear something coherent in favor of that, indeed |
| 15:09 | <jgraham> | So... what was the last publication date of the HTML5 spec before the one that just happened? |
| 15:10 | <annevk> | March 4 |
| 15:10 | <jgraham> | Thanks |
| 15:11 | <jgraham> | annevk: It would be nice if the html5 tracker let you specify a date in the UI :) |
| 15:13 | <annevk> | I should prolly sync up the latest version of that so you can patch it :) |
| 15:13 | <jgraham> | Is the version in svn out of date? If you put the latest version there I might as well make a patch |
| 15:13 | <annevk> | html5-diff has SVN revision dates in the source of the HTML5 changelogs section by the way |
| 15:14 | <annevk> | working on it now |
| 15:20 | <annevk> | argh, password troubles |
| 15:21 | <annevk> | ok, should be good now |
| 15:21 | <annevk> | r175 |
| 15:33 | <MikeSmith> | kennyluck: you read http://www.w3.org/DesignIssues/RDF-Future.html already? |
| 15:33 | <kennyluck> | Yeah. This shows that timbl is a logician. :) |
| 15:34 | <Philip`> | "RDF/MXL" - that sounds intriguing |
| 15:34 | <kennyluck> | hahhah |
| 15:42 | <MikeSmith> | Philip`: that's one of the many little-known features of RDF |
| 15:43 | <MikeSmith> | which is, there's a rule that when the string "RDF" precedes another three-letter string, the first two letters of the second string must then be transposed |
| 15:43 | <MikeSmith> | a lot of people think RDF is complicated, but I think that's a good example of a case where the rule is pretty simple |
| 15:44 | <MikeSmith> | I'm pretty kennyluck agrees with me about that |
| 15:44 | <annevk> | sounds like you're in a bar :p |
| 15:44 | <MikeSmith> | RDF TFW! |
| 15:47 | <MikeSmith> | kennyluck: anyway, about what we were discussing earlier, I guess N3 still remains relevant |
| 15:47 | <MikeSmith> | judging from that at least |
| 15:49 | <kennyluck> | I would encourage you guys to write your personal profile in N3, namely FOAF. |
| 15:50 | <kennyluck> | RDF/XML is a very complicated serialization of RDF that semantic web folks complain about for years. |
| 15:51 | <kennyluck> | I know RDF/XML might is the origin of XML namespace. I guess it's very unfortune. |
| 15:51 | <Philip`> | Hopefully they've now learned the lesson that using XML for human-readable file formats is often not a good idea |
| 15:52 | <MikeSmith> | kennyluck: I guess I would make my personal profile more usable, if I wanted more people to contact me |
| 15:52 | <MikeSmith> | but I have too many people contacting me already |
| 15:52 | <MikeSmith> | so for me, maybe RDF/XML is a good choice |
| 15:53 | <kennyluck> | Why not RDF/N3? I have actually only written RDF in RDF/XML for only once or twice. |
| 15:53 | <kennyluck> | Almost all RDF library parses RDF/N3 or a subset of it, called Turtle. |
| 15:55 | <kennyluck> | I totally agree with you Philip`. |
| 15:56 | <MikeSmith> | I think the future of RDF should maybe involve renaming it to something else |
| 15:56 | <kennyluck> | One of the topic of the RDF Next step workshop is to think about a way to standardize RDF/JSON, IIRC. |
| 15:56 | <MikeSmith> | a funner name would help |
| 15:56 | <MikeSmith> | like ARF |
| 15:57 | <MikeSmith> | or like the subtitle format called "ASS" |
| 15:57 | <Philip`> | kennyluck: I don't think a format without e.g. comments would be a good basis for human-readable file formats either |
| 15:57 | <Philip`> | (where by "human-readable" I mean more "human-editable") |
| 15:58 | <kennyluck> | JSON does not allow /* this is a comment */ ? |
| 15:58 | <Philip`> | People shouldn't be scared of custom formats |
| 15:58 | <Philip`> | kennyluck: No |
| 15:59 | <kennyluck> | Hmm... sorry, this is new to me. |
| 15:59 | <Philip`> | The JSON grammar is just what http://json.org/ shows |
| 16:14 | <MikeSmith> | btw, that MXL typo corrected itself |
| 16:14 | <MikeSmith> | that's another little-known feature of RDF: self-correcting typos |
| 16:55 | boblet | is trying not to hyperventilate from laughing at a 27bslash6 link via MikeSmith |
| 17:15 | <MikeSmith> | boblet: blame John Allsopp for that one |
| 17:16 | <boblet> | yeah I saw |
| 17:16 | <boblet> | classic |
| 17:55 | <MikeSmith> | http://blogs.gnome.org/rbultje/2010/06/27/googles-vp8-video-codec/ |
| 17:56 | <MikeSmith> | "we wrote a video decoder that heavily reuses existing components in FFmpeg, leading to a vp8.c file that is a mere 1400 lines of code (including whitespace, comments and headers) and another 450 for the DSP functions" |
| 17:57 | <MikeSmith> | "Google’s VP8 specs are not always equally useful. They only describe the baseline profile (0). Other profiles (including those part of the vector testsuite, i.e. 1-3) use features not described in the specifications" |
| 18:01 | <Philip`> | "in the end, it’s much quicker to just read libvpx source code rather than depend on the spec" - that's not really the "independent implementations" that help make a good standard |
| 18:07 | <MikeSmith> | Philip`: silly you |
| 18:08 | <MikeSmith> | in this case, by "independent implementations", they mean "independent of any specification" |
| 18:08 | <MikeSmith> | and dependent on one another |
| 18:08 | <MikeSmith> | so is more of an "independent community of implementations" |
| 18:08 | <MikeSmith> | kind of like a hippy commune |
| 18:09 | <MikeSmith> | with free love |
| 18:09 | <MikeSmith> | and LSD |
| 18:10 | <gsnedders> | MikeSmith: What have you been doing _now_!? |
| 18:10 | <TabAtkins> | gsnedders: Free love and LSD. |
| 18:10 | <annevk> | MikeSmith, and a test suite, apparently |
| 18:11 | <MikeSmith> | morninglory seeds |
| 18:11 | <gsnedders> | Free love, LSD, and a test suite? Okay… |
| 18:11 | <annevk> | you're not seeing the pattern? |
| 18:12 | <gsnedders> | Not quite. |
| 18:12 | <krijnh> | -_- |
| 18:38 | <variable> | does anyone know of any bugs or offical responses from Hixie about the "advert" tag / |
| 18:38 | <variable> | *about an advert tag |
| 18:38 | <TabAtkins> | That we'd never do it, because it would immediately defeat itself? |
| 18:39 | <variable> | TabAtkins, agreed - I'm looking for an offical response from hixie |
| 18:40 | <variable> | or some W3C bug or something like that says exactly what you are saying |
| 18:40 | <TabAtkins> | Hmm, I'll check. |
| 18:40 | <Dashiva^2> | Was there ever a formal suggestion to add it? |
| 18:40 | <variable> | Dashiva^2, I don't know. |
| 18:42 | <variable> | TabAtkins, failing that a mailing list post from some influential WHATWG contributer |
| 18:42 | <variable> | I'm searching my archives but I can't find one |
| 18:44 | <TabAtkins> | variable: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html |
| 18:47 | <TabAtkins> | variable: And, two messages down that reply chain, Hixie points back to jgraham's response. |
| 21:35 | <annevk> | gsnedders, postMessage is also on window so no |
| 21:36 | <annevk> | gsnedders, hack: (self != window) |
| 21:37 | <annevk> | gsnedders, shared workers do not have postMessage on the global object by the way, it seems |
| 21:46 | <jgraham> | annevk: You mean this !== window I guess |
| 21:47 | <annevk> | jgraham, self exists |
| 21:48 | <jgraham> | Ah |
| 21:48 | <jgraham> | Indeed it does |
| 21:48 | <jgraham> | That's confusing |
| 21:49 | <jgraham> | It should have been named workerGlobal or something |
| 21:49 | <jgraham> | Anyway to late to paint that bikeshed |
| 21:49 | <jgraham> | *too |
| 21:49 | <annevk> | self is much nicer |
| 21:49 | <annevk> | there |
| 21:49 | <jgraham> | Not if you have a python background |
| 21:50 | <annevk> | kids of the future will have an ECMAScript background |
| 21:50 | <jgraham> | boy will they be screwed up |
| 21:50 | <annevk> | ECMAScript is prolly one of the lesser problems of the future :) |
| 21:51 | <jgraham> | Well I meant DOM really |
| 21:51 | <jgraham> | Or "the union of all web apis" |
| 21:52 | <jgraham> | Since I guess there will not be that many people with a pure es background |
| 21:52 | <jgraham> | unless it breaks out of the browser in a really big way |
| 21:52 | <jgraham> | much bigger than node.js |