| 06:05 | <hsivonen> | Hixie: OK if I consolidate the "Registered Extensions" and "Proposals" sections on the MetaExtensions page considering the Proposals section has a status column? |
| 06:05 | <hsivonen> | it seems to me that no-email-collection fails the requirements for registration due to being URL-valued |
| 06:24 | <Hixie> | hsivonen: yeah, do with that page whatever you think is most helpful for you and the web in general |
| 06:24 | <hsivonen> | Hixie: ok |
| 06:28 | <hsivonen> | Hixie: why does HTML(5) allow rel=tag on <link> when the microformats.org spec for rel=tag says implementations SHOULD NOT support it on <link>? |
| 06:29 | <Hixie> | probably just my sucking |
| 06:29 | <hsivonen> | also, what word is being tagged in the <link> case? the one in the title attribute? |
| 06:29 | <Hixie> | file a bug, i can fix that np |
| 06:29 | <hsivonen> | Hixie: ok |
| 06:29 | <hsivonen> | Hixie: btw, all the HTML 4 link types got registered |
| 06:30 | <Hixie> | interesting |
| 06:30 | <Hixie> | even the ones the wg rejected? |
| 06:30 | <hsivonen> | which WG? |
| 06:30 | <Hixie> | and did anyone include a link to a spec that actually defines them? (i.e. a spec more detailed than html4) |
| 06:30 | <Hixie> | w3c html wg |
| 06:30 | <hsivonen> | Hixie: the link is to HTML 4 |
| 06:30 | <Hixie> | fail |
| 06:31 | <Hixie> | we're definitely going to have to move to a model where there's a review step after regstration, i guess |
| 06:31 | <Hixie> | i mean, the idea here was to stop people wasting their time |
| 06:31 | <Hixie> | if the types that people commonly waste their time with get registered, ... :-( |
| 06:34 | <hsivonen> | Hixie: well, Tantek registered them and he is in charge of review. :-) |
| 06:35 | <Hixie> | ah |
| 06:35 | <Hixie> | well then we'll need to speak to tantek :_) |
| 06:36 | <hsivonen> | btw, which relations did the W3C HTML WG reject? |
| 06:38 | <Hixie> | i forget. index? up? something like that? |
| 06:39 | <hsivonen> | "up" might be it |
| 06:39 | <hsivonen> | "up" wasn't registered |
| 06:39 | <hsivonen> | hmm. nofollow got registered for <link> but HTML(5) bans it on <link> |
| 06:47 | <othermaciej> | to be specific W3C HTML WG rejected them from the core spec |
| 06:47 | <othermaciej> | it didn't say "never register these as extensions" |
| 06:48 | <othermaciej> | though I personally tend to think the navigation-type relations are not very useful and are basically a failed experiment |
| 06:49 | <hsivonen> | hmm. XFN is an interesting case of use of the global namespace |
| 06:50 | <hsivonen> | XFN was grandfathered in to microformats |
| 06:50 | <hsivonen> | I wonder if stuff like rel=date would make it through the Process now |
| 06:51 | <hsivonen> | (rel=date being a person being dated--not any kind of calendar thing) |
| 06:51 | <othermaciej> | probably not with that name |
| 06:51 | <othermaciej> | well I hope not |
| 06:52 | <hsivonen> | also, rel=parent |
| 06:52 | <hsivonen> | means parent as in a person |
| 06:52 | <hsivonen> | not a parent of the document in a hierarchy |
| 06:52 | <Hixie> | othermaciej: well presumably if the wg couldn't find a good reason to have the relations, then (short of a new reason coming along) there's not a good enough reason to have it in the registry either |
| 06:52 | <othermaciej> | hsivonen: you're starting to convince me of the merits of namespace prefixes |
| 06:53 | <hsivonen> | othermaciej: scary |
| 06:53 | <othermaciej> | Hixie: well, if there is a distinction between "registered |
| 06:53 | <othermaciej> | " and "approved" |
| 06:53 | <othermaciej> | then there are probably good reasons for such relations to be in the former state even if not the latter |
| 06:53 | <othermaciej> | since they do get used in a fair amount of places, and there is no need to hide that |
| 06:53 | <hsivonen> | othermaciej: what practical differenc would the distinction make? |
| 06:54 | <hsivonen> | other than pedants feeling a bit better about something not being Approved |
| 06:54 | <othermaciej> | less pressure for implementors to waste time implementing arguably silly UI features? |
| 06:54 | <hsivonen> | othermaciej: good point |
| 06:54 | <Hixie> | othermaciej: oh certainly if a new relation comes along we definitely need a way to be able to reserve the name |
| 06:54 | <Hixie> | othermaciej: but i'm talking about an existing but presumably useless relation |
| 06:55 | <othermaciej> | less encouragement for broader use of relations that the community doesn't widely consider useful |
| 06:55 | othermaciej | is listing reasons a distinction between "registered" and "approved" might be useful |
| 06:57 | <danbri> | that distinction would be useful |
| 06:57 | <Hixie> | i think we should move towards a world where we have trivial registration, less trivial (but still non-bureaucratic) approval, and things that don't get approved lose their registration status |
| 06:57 | <danbri> | 'registered' could cover cases like 'yeah, we know about that one, ... it was tried but kinda failed' |
| 06:57 | <Hixie> | validators would ok anything in either category, and may give more specific advice about things that were once registered but were then rejected |
| 06:58 | <hsivonen> | danbri: btw, do you happen to know if GRDDL really meant to register rel=transformation for <a> in addition to <link>? |
| 06:58 | <danbri> | i've no idea |
| 06:58 | <danbri> | it sounds like a doc-level construction |
| 06:58 | <hsivonen> | danbri: ok. |
| 06:58 | <othermaciej> | I could imagine having a "rejected" category for cases where it's important to tombstone the name |
| 06:58 | danbri | nods |
| 06:58 | <othermaciej> | as opposed to making that identical to "never registered" |
| 06:59 | <danbri> | we've been using 'archaic' in some other contexts (foaf, rdfwg); it seems to capture some intuitions |
| 06:59 | <danbri> | i.e. this is old-fashioned usage; but not as harsh as deprecated/rejected |
| 06:59 | <othermaciej> | HTML5 says "obsolete" |
| 06:59 | <othermaciej> | opinions on the harshness of that vary |
| 07:00 | <Hixie> | othermaciej: i don't mind what we call them. categories a, b, and c, for the sake of argument. |
| 07:00 | <danbri> | can i get a bookmark to this discussion from a logger bot somewhere? useful stuff |
| 07:00 | <Hixie> | see /topic |
| 07:01 | <othermaciej> | the topic has links to full logs |
| 07:01 | danbri | curses limechat's display of /topic, clicks around |
| 07:02 | <danbri> | got it |
| 07:04 | <hsivonen> | what's the wiki syntax for linking to an anchor on the same wiki page? |
| 07:05 | <Hixie> | wiki link syntax drives me batty |
| 07:05 | <Hixie> | mediawiki, anyway |
| 07:05 | <MikeSmith_> | [[foo]] |
| 07:05 | <hsivonen> | [[#See also|different text]] |
| 07:05 | <danbri> | should the schema.org folk put their relationship types thru this registration process? |
| 07:05 | <MikeSmith_> | I think |
| 07:05 | <Hixie> | it has like three different ways of doing links |
| 07:06 | <Hixie> | danbri: do they have rel types? i thought they only used microdata |
| 07:06 | <danbri> | they are types of relationship; but expressed as microdata yeah |
| 07:06 | <danbri> | 'cos it's a full uri, no need to register? |
| 07:06 | danbri | RTFMs, finds " Note that URL-valued properties must not be registered as meta names but should be registered as rel keywords instead." |
| 07:06 | <Hixie> | microdata doesn't use the rel="" attribute at all |
| 07:07 | <hsivonen> | danbri: Microdata uses full URIs, so it's Distributed Extensibility with no registration |
| 07:07 | <Hixie> | and "URL-valued properties" are an entirely separate thing again :-) |
| 07:07 | <danbri> | (they're types of real-world relationship) |
| 07:07 | <danbri> | pardon my confusion :) |
| 07:08 | <nessy> | if my email is stuck in moderation for being too long, should I wait till somebody authorizes it or remove it and resend multiple? |
| 07:08 | <MikeSmith_> | nessy: which list? |
| 07:09 | <nessy> | whatwg |
| 07:09 | <Hixie> | i approved it |
| 07:09 | <Hixie> | i don't get notified when things get caught |
| 07:09 | <nessy> | oh! thanks! |
| 07:09 | <Hixie> | so if you get something caught, let me know :-) |
| 07:09 | <Hixie> | mine got caught too |
| 07:09 | <Hixie> | that's why it didn't go into the archives at first |
| 07:10 | <Hixie> | (i let mine through when i saw your www-archive mail) |
| 07:10 | <nessy> | yeah, strangely though it came to the list |
| 07:10 | <Hixie> | nah it went to you directly |
| 07:10 | <Hixie> | i bcc everyone who i reply to |
| 07:10 | <Hixie> | whom |
| 07:10 | <nessy> | ah! that explains it |
| 07:10 | <nessy> | thanks heaps |
| 07:10 | <Hixie> | np |
| 07:14 | <nessy> | you'll really like this page that Ronny from leanbackplayer has developed: http://leanbackplayer.com/other/webvtt.html |
| 07:14 | <hsivonen> | grr. bitbucket pulls hang |
| 07:16 | <Hixie> | nessy: let him know he misspelt A:start and A:end :-) |
| 07:16 | <nessy> | oh!? |
| 07:16 | <Hixie> | (he wrote A:left and A:right in an example) |
| 07:17 | <Hixie> | the diagram for L:50% is wrong |
| 07:17 | <Hixie> | L:50% means vertically centered |
| 07:17 | <Hixie> | same idea as T:50% |
| 07:18 | <Hixie> | (with A:middle) |
| 07:18 | <Hixie> | actually ignore what i said about T:50%/A:middle |
| 07:18 | <Hixie> | L:50% means vertically centered |
| 07:18 | <Hixie> | 50% point of box should be 50% of the way down |
| 07:19 | <Hixie> | i was going to say that there's no <u>, but i guess i did add that after all, when we added <u> to html proper |
| 07:20 | <nessy> | yeah, we were discussion how L:50% works - right no he has the bottom of the subtitle box vertically centered, not the middle |
| 07:20 | <Hixie> | L:x% means to line up the point x% of the way along the box x% of the way along the viewport |
| 07:20 | <Hixie> | so L:50% centers vertically, L:0% goes to the top, L:100% goes to the bottom |
| 07:21 | <nessy> | are we anchoring top left corner then and not bottom? |
| 07:21 | <Hixie> | you're not anchoring either |
| 07:21 | <Hixie> | you're anchoring the point x% of the way along the box |
| 07:22 | <nessy> | what I meant is: where does 0% start |
| 07:23 | <nessy> | I thought T:0% and L:0% would be bottom left corner |
| 07:23 | <Hixie> | i don't understand the question |
| 07:23 | <nessy> | will get Ronny to fix it |
| 07:23 | <nessy> | (A:left and A:right are already fixed :-) |
| 07:23 | <Hixie> | nice |
| 07:24 | <nessy> | so, the T: and A: examples are correct? |
| 07:25 | <nessy> | ah, probably not |
| 07:25 | <Hixie> | the examples don't give me enough information to determine their accuracy |
| 07:26 | <nessy> | do you want 50% markers etc? |
| 07:26 | <Hixie> | i'd like to see the whole cue |
| 07:27 | <nessy> | ah, ok - those are meant to have nothing but the one or two cue settings that are given there |
| 07:27 | <nessy> | the arabic example is rtl text, the English one ltr |
| 07:29 | <Hixie> | so why is the first one not as wide as the box? |
| 07:30 | <nessy> | the A:start example with the "Hello everybody" example? |
| 07:30 | <Hixie> | yeah |
| 07:30 | <nessy> | the green and red boxes are the video viewport |
| 07:30 | <Hixie> | the grey box is like 40% |
| 07:30 | <Hixie> | it should be 100% |
| 07:30 | <Hixie> | no? |
| 07:30 | <Hixie> | width wise |
| 07:31 | <nessy> | oh! no, I think that's overkill |
| 07:31 | <nessy> | it should only be as wide as the max string of the subtitle string |
| 07:31 | <Hixie> | ? |
| 07:31 | <Hixie> | the spec says it's 100% wide |
| 07:31 | <nessy> | oh! |
| 07:31 | <nessy> | I don't like that because the subtitle box then obscures more than it needs to |
| 07:32 | <Hixie> | i'm not saying i like it, i'm saying it's what the spec says |
| 07:32 | <nessy> | why can't we have it just the bounding box around the text |
| 07:32 | <Hixie> | *shrug* dunno, send mail |
| 07:32 | <nessy> | can we change that? do you want on on-list discussion about that? |
| 07:32 | <Hixie> | i'm just trying to review this document with respect to the spec here :-) |
| 07:32 | <nessy> | ok, will send email |
| 07:32 | <Hixie> | i don't have the editor open or anything |
| 07:32 | <nessy> | very much appreciated! |
| 07:33 | <nessy> | we'll make some fixes and I'll send another email |
| 07:33 | <nessy> | we could even use some of the images that Ronny makes in the spec eventually |
| 07:33 | <LBP> | hi there. |
| 07:33 | <nessy> | hi Ronny :-) |
| 07:34 | <Hixie> | hi |
| 07:34 | <LBP> | you are discussing my thoughts? ;-) |
| 07:34 | <Hixie> | nice doc :-) |
| 07:35 | <LBP> | the specs is great, webvtt is great but some times I need some more visual informations like a screenshot, so there is ;-) |
| 07:35 | <Hixie> | yeah, the spec is sorely lacking in examples and stuff |
| 07:35 | <LBP> | mainly to make it easier for me to write the parsers. |
| 07:35 | <Hixie> | i tend to avoid making informative text until after we have implementations because before we do the spec keeps changing and i end up spending twice as much time working on the examples as fixing the spec |
| 07:36 | <nessy> | I think we're getting there :-) |
| 07:36 | <nessy> | I've had the request for examples from others, too, and Ronny's doc will certainly help |
| 07:37 | <LBP> | Hixie.you wrote about the subtitle box should be 100%? |
| 07:38 | <Hixie> | yeah the default "text track cue size" is 100% according to step 27 of the parser |
| 07:39 | <LBP> | I have no TV so most times I only use subs at the web/pc and most players going to make the box only the width of the text within! |
| 07:39 | <Hixie> | the spec might be wrong, i'm just saying what the spec says :-) |
| 07:39 | <LBP> | ;-) |
| 07:39 | <Hixie> | if teh spec is wrong, mail the list |
| 07:39 | <Hixie> | or file a bug |
| 07:40 | <nessy> | is that what the "S:" setting refers to, too? |
| 07:40 | <nessy> | the size of the subtitle box? |
| 07:41 | <LBP> | that is not a problem, I have also a subtitle area of 100% and the box containing the subtitle text within there has a fixed width (and perhaps a background). but it should be clear which of the areas/boxes are the part that should be aligned and positioned through settings. |
| 07:41 | nessy | is confused |
| 07:41 | <Hixie> | what do you mean by "subtitle box" exactly? |
| 07:41 | <nessy> | the box within which the subtitles are rendered on top of the video viewport |
| 07:41 | <LBP> | let me show you the player (if Silvia not yet has done). |
| 07:42 | <LBP> | http://leanbackplayer.com/test/webvtt.html |
| 07:42 | <Hixie> | nessy: the subtitles are rendered within at least 5 nested boxes in the simplest case, so "the box" is insufficiently precise for these purposes |
| 07:43 | <LBP> | there is a box at the bottom containing a box with subs. last one is colored and I think last one is also the box that should be aligned/positioned?! |
| 07:43 | <nessy> | the visual effect is a dark grey box on top of the video viewport - that's the box that I referred to |
| 07:44 | <LBP> | that is way (for me) it is important to have some examples/images to resolve. |
| 07:44 | <Hixie> | the dark gray box could come from a variety of places |
| 07:45 | <Hixie> | one of which might be the one whose size you're setting with S: |
| 07:45 | <Hixie> | depends on how you style it |
| 07:45 | <nessy> | in a normal horizontal box with S:20%, for example, would that size the width of that box? |
| 07:45 | <LBP> | yes,thats the point. let me update the css of the player showing the areas/boxes. |
| 07:46 | <Hixie> | nessy: depends how you style it |
| 07:46 | <nessy> | given no additional CSS |
| 07:46 | <nessy> | just using the cue settings |
| 07:46 | <Hixie> | given no additional css, there is no single box with a grey background |
| 07:46 | <LBP> | now there is a background 0.2 black and the subtitle is 0.4 black so you can see, the 0.2 box is 100% |
| 07:47 | <Hixie> | there is one inline box per line box, each with a grey background; these boxes have the width of the text |
| 07:47 | <Hixie> | these boxes might differ in width from each other for a single cue |
| 07:48 | <LBP> | one inline box per line box,ok. |
| 07:48 | <nessy> | background of the cue is by default set to rgba(0,0,0,0.8) , which will create the grey background for all the line boxes inside, no? |
| 07:48 | <Hixie> | no |
| 07:48 | <Hixie> | well yes, but it's not one box |
| 07:48 | <Hixie> | it's the background boxes, which are inline, not block |
| 07:48 | <Hixie> | the way it's currently specced, actually, there's no way to set a background on the box whose size is set by S: |
| 07:49 | <Hixie> | (though you can see its size by setting the 'outline' property) |
| 07:50 | <nessy> | but S: does indeed size the width of the cue box and not the font size? |
| 07:50 | <nessy> | sorry, but that spec keeps confusing me :-) |
| 07:51 | <nessy> | must be because I never wrote a CSS spec ;-) |
| 07:51 | <nessy> | or I am trying to read stuff into it that doesn't exist |
| 07:51 | <LBP> | the width of the box grows with font-size I would have thought (without any other setting). |
| 07:52 | <Hixie> | font size? why would S: affect the font size? |
| 07:52 | <Hixie> | before reading the webvtt rendering spec you really need to understand css :-) |
| 07:52 | <nessy> | the other way around: the font size affects the cue's size |
| 07:52 | <Hixie> | and before implementing the webvtt rendering rules you _definitely_ need to know css |
| 07:53 | <Hixie> | what do you mean by "size"? |
| 07:53 | <nessy> | I have an understanding of CSS, but no-where near the in-depth that you have |
| 07:53 | <nessy> | width when horizontal, height when vertical |
| 07:53 | <Hixie> | this stuff depends on an understanding of the css box model generation, and css selector matching |
| 07:54 | <Hixie> | font-size has no effect on the width when horizontal. But since the width is 100% by default, and cannot go bigger than 100%, it's unclear to me what it would mean for it to have an effect. |
| 07:54 | <nessy> | yeah, I understand those sufficiently (FAIK) |
| 07:55 | <nessy> | what if you do S:20% but your text is wider than 20%? |
| 07:56 | <nessy> | actually, I think we can live without "S:" if we just do a bounding box around the text - I'll raise that on list |
| 07:57 | <Hixie> | assuming you mean, if the shrink-wrap width of the inline boxes is greater than the maximum width of the box generated for the /list of WebVTT Node Objects/, then the answer is the shrink-wrap width isn't used, so it doesn't matter. |
| 07:57 | <Hixie> | text is force-wrapped at the S: width |
| 07:57 | <Hixie> | do bounding box around the text for what? |
| 07:57 | <Hixie> | the background is on a per-line basis behind the text only |
| 07:57 | <Hixie> | unless you use 'outline' on the root of the cues, you can't see the S: size at all |
| 07:58 | <Hixie> | except for its indirect effect on wrapping |
| 08:01 | <nessy> | I see - so S: is used where we want to wrap text in a restricted area, which could be placed anywhere on the screen |
| 08:01 | <Hixie> | typically, yes |
| 08:02 | <nessy> | fair enough - we do need it then |
| 08:02 | <nessy> | LBP: we need some more examples |
| 08:06 | <nessy> | thanks Hixie for clarifying! |
| 08:07 | <Hixie> | np |
| 08:18 | <zewt> | heh, replying to these 20-page mails on whatwg in gmail is stalling ff for seconds at a time |
| 08:20 | <nessy> | zewt: my gmail refuses to display Hixie's video feedback email and instead tells me to go to this special text link for reading it ;-) |
| 08:22 | <zewt> | my onboard sound adds free invisible progress bars to gmail |
| 08:22 | <zewt> | there's so much bus noise, when I deleted a big block of text (and it froze up for a few seconds), I hear a progressively higher-pitched noise out my headphones |
| 10:39 | <karlcow> | http://blog.geoiq.com/2011/05/31/geocommons-2-0/ |
| 10:39 | <karlcow> | Cross-browser platform Support – view your maps anywhere from IE to your iPad. We’ve added support for HTML5 and Flash. |
| 11:09 | <espressive> | Hi there everyone |
| 11:09 | <hsivonen> | hi |
| 11:09 | <espressive> | Very curious to know what some people in here think of schema.org |
| 11:10 | <hsivonen> | I have a blog post about it coming up |
| 11:10 | <hsivonen> | not quite done yet |
| 11:11 | <espressive> | I am very torn, understand the concept but, the amount od extra markup that needs to be added for this just seems to go against the idea of creating lighter web pages that make for a faster web |
| 11:11 | <hsivonen> | espressive: if you don't need the SEO, don't use it |
| 11:12 | <espressive> | hsivonen, jip, I get that but, even if you do, this is not something that is going to be simple for content creators to add. |
| 11:12 | <espressive> | I wrote something up here : http://goo.gl/42SVK would love to read yours once published |
| 11:12 | <espressive> | I am thinking marketers working via a CMS with a simple web editor |
| 11:19 | <espressive> | Do you know if there is any current work regarding tools or integration with current web wysiwyg editors? |
| 11:21 | <espressive> | Also, comments on Tantek's tweets? |
| 11:21 | <espressive> | http://tantek.com/2011/155/t5/schemaorg-html5-fork-smoke-openinghours-time-duration |
| 11:21 | <espressive> | http://tantek.com/2011/155/t4/schemaorg-google-ms-duopoly-forking-html5 |
| 11:28 | <hsivonen> | espressive: it's not cool that they just dumped invalid stuff into <time> element attributes without (as far as I've noticed) sending feedback to the WHATWG or the HTML WG ahead of time |
| 11:29 | <espressive> | agreed |
| 11:31 | <espressive> | Also, is the scema completely open to, for example, the WHAT-WG getting involved and enhancing/improving this or, is this governed by Google, Yahoo and Bing? |
| 11:33 | <espressive> | I believe the following line has some people wondering about the openness of this: "We strongly encourage schema developers to develop and evangelize their schemas. As these gain traction, we will incorporate them into schema.org." |
| 11:39 | <eightfold> | could pubdate be used with the <time> element in a <li> of articles? the <li>'s has no <article> element? should there always be an element with an <article> parent when using pubdate? |
| 11:41 | <karlcow> | espressive: I have the feeling schema.org has for a goal to align everyone on one type of description which is good for them (G+M+Y) but not necessary good for small distributed communities. |
| 11:42 | <karlcow> | Then I guess the issue is not necessary that it matters that these small independent communities exist in SEO land, but more that the schema.org will likely drive the creation of tools or reduce the surface of other tools. |
| 11:42 | <karlcow> | That will be interesting to see how it will evolve. |
| 11:43 | <karlcow> | schema.org is just a Britney Spears ontology. |
| 11:43 | <espressive> | I would just have hoped that it would evolve in a open space where everyone can contribute from experience of using the schema |
| 11:43 | <espressive> | karlcow ;) |
| 11:44 | <karlcow> | or schema.org is just a Justin Bieber ontology. (for other fans) |
| 12:12 | <mikekelly> | is the 'offline web applications' bit still alive or has it been removed? |
| 12:13 | <MikeSmith> | mikekelly: alive |
| 12:13 | <mikekelly> | ok thanks, fwiw I've proposed an alternative here: http://blog.stateless.co/post/6246070973/how-offline-web-apps-should-work |
| 12:14 | <mikekelly> | MikeSmith: who came up with the current propsal, do you know? |
| 12:16 | <MikeSmith> | what current proposal? you mean what's already been implemented? |
| 12:16 | <mikekelly> | yeah |
| 12:19 | <mikekelly> | MikeSmith: any ideas? I'd like to find out some of the background on it if possible |
| 12:28 | <MikeSmith> | that's something more than a proposal at this point. support for it has shipped in multiple browser engines, and production sites rely on it, |
| 12:28 | <MikeSmith> | and it's simple |
| 12:30 | <MikeSmith> | so it would seem like the genesis of it would be just mostly be of historical interest only at this point |
| 12:31 | <MikeSmith> | anyway, Hixie wrote the spec for it |
| 12:31 | <MikeSmith> | like most everything else in the html5 spec |
| 12:32 | <MikeSmith> | there may have been somebody else who wrote the original proposal for it |
| 12:33 | <MikeSmith> | if so I don't personally remember |
| 13:06 | <karlcow> | mikekelly: being a big lover of HTTP, I like the proposal of Cache-Storage. The issue is a question of authority for authors. |
| 13:06 | <karlcow> | The Web servers are not in the control of authors. Let's say the hierarchy goes to something very similar to System Engineers > Back End Developers > Front-End Developers > Webmasters > Authors |
| 13:06 | <karlcow> | It is difficult for people right now to have controls on HTTP headers if they are not close to the actual server management. |
| 13:06 | <karlcow> | Unfortunately. |
| 13:07 | <karlcow> | I have the feeling it is one of the reasons why so many things have been pushed to the client side. |
| 13:12 | <mikekelly> | karlcow: I actually considered proposing it as part of an html doc rather than an http header |
| 13:13 | <mikekelly> | i.e. metadata in <head> of the application entry point |
| 13:14 | <mikekelly> | but again, I guess that doesn't really alleviate the concerns re: cache control headers |
| 13:16 | <mikekelly> | creating an /offline_assets folder in apache and creating necessary settings in .htaccess is pretty simple though |
| 13:21 | <checkers> | oh, pyhtml5lib is part of the *real* whatwg? nice! |
| 13:21 | <hsivonen> | karlcow: judging from Twitter, Justin Bieber seems to have quite a following. Will schema.org? |
| 13:24 | <karlcow> | hsivonen: yes. |
| 13:24 | <karlcow> | SEO porn |
| 13:25 | <gsnedders> | checkers: Well, it's written by people who've been around here for ages (and nowadays maintained mostly by random Opera people, coincidently, though both of us worked on it before working for Opera), and there tends to be people around here who know about it, thus the pointing of people here for it. |
| 13:28 | <smaug____> | is anne back from holiday? |
| 13:29 | <gsnedders> | smaug____: No. |
| 13:30 | <gsnedders> | smaug____: Back in two weeks, I believe. |
| 13:30 | <smaug____> | gsnedders: I assume he has written http://tc.labs.opera.com/apis/EventSource/ ? |
| 13:30 | <smaug____> | apparently there are some bugs in the tests |
| 13:30 | <smaug____> | but I'll go through them once anne is back |
| 13:34 | <gsnedders> | smaug____: Yeah, annevk wrote them. But, well, it depends how urgent it is. If you have any real need for it to be done sooner, I (or someone else) can deal with them. |
| 13:35 | <smaug____> | I don't think it is urgent |
| 13:37 | <jquerier> | can i ask a adsense question here? |
| 13:42 | <karlcow> | jquerier: not sure it is the right channel for this. |
| 13:43 | <karlcow> | or more exactly the right crowd, but you can still try. |
| 13:46 | <checkers> | gsnedders: i see python3 in the repository but no mention of it in the docs.. is python 3 supported? |
| 13:47 | <gsnedders> | checkers: Not really. It's an old 2to3 based port, and quite out of sync. |
| 13:47 | <checkers> | ok |
| 21:21 | <zcorpan> | hsivonen: "Note that updates of the wiki data in the validator are manual and do not happen in real time." doesn't seem particularly relevant |
| 21:22 | <zcorpan> | hsivonen: the message could be clearer about the possibility to register rel values |
| 21:22 | <zcorpan> | hsivonen: (updates to the spec are manual too but isn't mentioned anywhere) |
| 21:24 | zcorpan | tries to edit the microsyntaxdescriptions page |
| 21:32 | <zcorpan> | edited |
| 21:38 | <zcorpan> | hsivonen: i moved the real time note to the microformats wiki page |
| 22:02 | <zcorpan> | hsivonen: does v.nu implement "A document must not contain any items for which crawling the properties of the element, with an empty list as the value of memory, either fails or returns an error count other than zero." for microdata? |
| 22:57 | <sicking> | Hixie: ping |
| 22:57 | <Hixie> | yo |
| 22:58 | <sicking> | Hixie: why does the websockets API spec say this: "Act as if the user agent had received a set-cookie-string for the document's address, consisting of the cookies set during the server's opening handshake"? |
| 22:58 | <Hixie> | sicking: you mean, why is it phrased that way, why is that requirement there, or something else? |
| 22:58 | <sicking> | Hixie: doesn't that mean that if site A opens a websocket to site B, then site B can set cookies for A's domain |
| 22:59 | <Hixie> | ah, you mean "why is it bogus" |
| 22:59 | <Hixie> | uh yeah i suck |
| 22:59 | <Hixie> | let me fix that |
| 23:14 | <Hixie> | sicking: fixed (should be up in a few seconds) |
| 23:14 | <sicking> | Hixie: thanks! |
| 23:15 | <Hixie> | np |
| 23:44 | <heycam> | Hixie, can you tell me what I need to build the Web Applications spec? |
| 23:44 | <Hixie> | "build"? |
| 23:44 | <heycam> | convert source to index |
| 23:44 | <Hixie> | my password to log in to my machine, probably |
| 23:44 | <heycam> | and complete.html I guess |
| 23:44 | <heycam> | oh :( |
| 23:44 | <Hixie> | it's a huge rube goldberg machine |
| 23:45 | <Hixie> | invokes multiple other hosts, scripts, all kinds of things |
| 23:45 | <Hixie> | i can probably generate you a version if you need something though |
| 23:45 | <Hixie> | what's up |
| 23:45 | <heycam> | oh I was just going to work on the patch for the nullable web idl thing |
| 23:45 | <Hixie> | aah |
| 23:46 | <heycam> | it's probably not vital to be able to build it |
| 23:46 | <heycam> | since I probably won't be editing anything magical, just plain content |
| 23:46 | <Hixie> | if you need to review the output i can regen the spec, just mail me the diffs or whatever |
| 23:46 | <heycam> | and the idl fragments |
| 23:46 | <heycam> | ok, sure |
| 23:46 | <Hixie> | the file is html though, you can open it as is if you stick an HTML header on the top of it |
| 23:46 | <Hixie> | should work fine |
| 23:46 | <heycam> | ok |
| 23:46 | <heycam> | cool |
| 23:47 | <Hixie> | copy http://www.whatwg.org/specs/web-apps/current-work/header-whatwg-html onto its head |
| 23:47 | <Hixie> | should give you something to work with |
| 23:47 | <heycam> | k |
| 23:47 | <Hixie> | don't hesitate to ask if i can help in any way |
| 23:48 | <Hixie> | i'm eager to make this easy for you :-) |
| 23:48 | <heycam> | sure :) |