| 00:00 | <nessy> | Hixie: do you mind if I upload some more examples to the wiki? |
| 00:00 | <nessy> | I have one with a pretty substantial background from a mobile phone app |
| 00:00 | <tiglionabbit> | do any browsers implement the non-breaking content in columns css yet? |
| 00:00 | <Hixie> | nessy: go for it |
| 00:01 | <TabAtkins> | tiglionabbit: I don't think so, though check latest Opera. |
| 00:01 | <tiglionabbit> | that's a shame. multi column is kind of gimped without it, as far as i'm concerned |
| 00:01 | <tiglionabbit> | I guess I'll have to use inline blocks instead? |
| 00:03 | <TabAtkins> | I agree, it kind of is. Inline-blocks sort of go in the opposite direction, though, don't they? What display are you trying to achieve? |
| 00:03 | <TabAtkins> | (I've done some things where multicol or inline-block were both usable, and settled on inline-block.) |
| 00:04 | <tiglionabbit> | well, I I'm trying to do a fluid grid layout |
| 00:04 | <tiglionabbit> | of a bunch of boxes |
| 00:04 | <tiglionabbit> | I'd like them to be ordered the way that multi column does, but I suppose inline block ordering is decent |
| 00:04 | <TabAtkins> | Are the columns equal-width? If so, then yeah, just do inline-block. |
| 00:04 | <tiglionabbit> | the problem with multi-column is that my blocks keep getting chopped in half |
| 00:05 | <TabAtkins> | Alternately, use Flexbox. As long as you don't do anything too fancy, it'll work in FF, Safari, and Chrome. |
| 00:05 | <tiglionabbit> | multi-column can use different column widths? |
| 00:05 | <tiglionabbit> | what's flexbox? |
| 00:05 | <TabAtkins> | tiglionabbit: Actually, no, not yet, but it's planned to make it possible later. |
| 00:05 | <TabAtkins> | google for "css flexbox" |
| 00:06 | <TabAtkins> | Also, there's a relatively recent article on mozhacks about flexbox. |
| 00:08 | <tiglionabbit> | thanks =] |
| 00:12 | <nessy> | Hixie: check out http://wiki.whatwg.org/wiki/Use_cases_for_timed_tracks_rendered_over_video_by_the_UA - I've also added a new section - hope that fits your requirements |
| 00:13 | <Hixie> | i don't understand what's special about the background emphasis one |
| 00:13 | <Hixie> | how is it different from the other plain text ones? |
| 00:14 | <nessy> | ah just that on the Web you wouldn't be doing such a big black background thingy under the text, but on mobile it's important for readability |
| 00:14 | <nessy> | I don't mind adding them to the other plain text ones - just wanted to make sure that background requirement is considered |
| 00:14 | <nessy> | I don't really know how you arrived at your categories |
| 00:14 | <TabAtkins> | Because simply doing a stroked border on the text isn't enough on mobiles? |
| 00:15 | <nessy> | yeah - not readable |
| 00:15 | <TabAtkins> | Kk. |
| 00:16 | <nessy> | :) |
| 00:16 | <TabAtkins> | nessy, what's your name on the lists? |
| 00:16 | <nessy> | email? I'm Silvia Pfeiffer |
| 00:16 | <TabAtkins> | I thought so. Just making sure. It's helpful to connect my people-concepts together. ^_^ |
| 00:17 | <nessy> | surprised my whois doesn't tell - Adium is so much worse in comparison to xchat! |
| 00:17 | <TabAtkins> | Yeah, no useful info. |
| 00:18 | <nessy> | but I've given it to Adium - strange |
| 00:18 | <TabAtkins> | Your ircname is "Adium User". |
| 00:18 | <nessy> | yeah, not very useful |
| 00:23 | <Hixie> | nessy: ah, i see |
| 00:23 | <nessy> | hey, do you want this one, too? http://joeclark.org/access/crtc/CRTC-2008/reply/images/CCfoto-CBC-CC-ST-ManWithoutaFace.jpg |
| 00:23 | <Hixie> | i think that's more of an example of things going terribly wrong, but sure :-) |
| 00:23 | <nessy> | kinda shows the problem with open & closed captions, plus music notes |
| 00:23 | <nessy> | yeah, indeed! |
| 00:23 | <Hixie> | shows an example of what we should avoid :-) |
| 00:24 | <Hixie> | the musical notes thing is a non-issue, turns out Unicode has notes in it |
| 00:24 | <nessy> | ah, cool |
| 00:24 | <TabAtkins> | Unicode has everything in it. |
| 00:24 | <nessy> | I put it into positioning for now |
| 00:25 | <nessy> | joe clark seems to have a fair few, here's another one http://joeclark.org/access/crtc/CRTC-2008/reply/images/BCCS_unbelievably_wordy_speaker_ID_1.jpg |
| 00:26 | <TabAtkins> | That seems reasonable. We can't auto-solve it, since there's no way to detect when baked-in captioning is present. |
| 00:26 | <nessy> | shows providing of speaker names |
| 00:26 | <Hixie> | TabAtkins: except klingon |
| 00:26 | <nessy> | lol |
| 00:26 | <TabAtkins> | Hixie: Well, someone's put that in one of the private use ranges. You just need the right font. ^_^ |
| 00:26 | <AryehGregor> | Why did they reject Klingon? :( |
| 00:26 | <Hixie> | (it has several fictional languages, but they apparently drew the line at klingon and rejected it) |
| 00:28 | <AryehGregor> | Does it have Tolkien's Elvish? |
| 00:29 | <TabAtkins> | Hixie: I don't think it includes any fictional languages. Cirth and Tengwar are "proposed for inclusion", but not actually in the SMP. |
| 00:30 | <Philip`> | AryehGregor: Which of his Elvishes? |
| 00:30 | <AryehGregor> | Any. |
| 00:31 | <Philip`> | If somebody made up a new language in a style that emulated Tolkien, would it be an Elvish impersonator? |
| 00:33 | <TabAtkins> | The only language in Unicode which could be said to be "fictional" is the Shavian alphabet, but it wasn't invented for a story - it's just a semi-phonetic alphabet for English. |
| 00:33 | <AryehGregor> | http://www.magicdeckbuilder.com/public/cards/1-Illegal/1-Creatures/Elvish%20Impersonators.jpg |
| 00:33 | <Hixie> | i thought at least one fictional alphabet had made it in... i may be mistaken |
| 00:34 | <AryehGregor> | If only they didn't have to worry about UTF-16, they could have kept 2^32 possible characters and accepted all the writing systems out there. |
| 00:34 | <TabAtkins> | The Phaistos Disc script might be fictional. Nobody's sure if it's a hoax or not yet. |
| 00:34 | <AryehGregor> | Of course, you'd think they'd have enough room even now for as many alphabets as they like. |
| 00:34 | <AryehGregor> | As long as they're not logographies. |
| 00:34 | <AryehGregor> | (I like the words "logography" and "syllabary". They're just cool words.) |
| 00:34 | <TabAtkins> | They do. We're only using Planes 0, 1, and 2. We *might* use Plane 3. |
| 00:36 | <Hixie> | oh dear lord they accepted the emoticons block |
| 00:36 | <TabAtkins> | What's the range? |
| 00:36 | <Hixie> | 1F600..1F64F |
| 00:36 | <Hixie> | that's a lot of emoticons |
| 00:37 | <AryehGregor> | You could add non-writing-system stuff like emoticons and icons without limit. |
| 00:37 | <TabAtkins> | Wikipedia is out of date! |
| 00:37 | <TabAtkins> | It only lists through Domino Tiles (1f09f) in plane 1. |
| 00:37 | <AryehGregor> | (I recently looked for icons of a lion or tablets to replace the star of David at aryeh.name, but didn't find any. Will have to think of something else, I don't really like it much.) |
| 00:37 | <AryehGregor> | TabAtkins, {{sofixit}} |
| 00:38 | <TabAtkins> | I will, as soon as I find what's missing between 1f0a0 and 1f600. |
| 00:40 | <Hixie> | the emoticons aren't in yet |
| 00:40 | <Hixie> | they're approved for addition, but have yet to go through the ISO part of the proess |
| 00:40 | <Hixie> | see the pipeline table |
| 00:40 | <Hixie> | http://www.unicode.org/alloc/Pipeline.html |
| 00:42 | <TabAtkins> | Ah, yup. |
| 00:42 | <TabAtkins> | Ok, then I won't edit the wiki page yet. Nothing beyond 1f0a0 is approved *yet*. |
| 00:43 | Hixie | finds http://unicode.org/~scherer/emoji4unicode/snapshot/NamesList.txt and starts drooling |
| 00:43 | <Hixie> | U+1F36F HONEY POT mmmmm |
| 00:44 | <Hixie> | there's a Facial parts symbols section |
| 00:44 | <Hixie> | lol |
| 00:45 | <Hixie> | U+1F47D EXTRATERRESTRIAL ALIEN!!! |
| 00:45 | <AryehGregor> | Are there drawings of what these will look like? |
| 00:45 | <AryehGregor> | 1F307 SUNSET OVER BUILDINGS |
| 00:45 | <Hixie> | U+1F47E ALIEN MONSTER!!! |
| 00:45 | <Hixie> | i like that 1F479 and 1F47A are specifically japanese |
| 00:45 | <Hixie> | wouldn't want any EUROPEAN ogres |
| 00:46 | <AryehGregor> | 1F3E8 HOTEL |
| 00:46 | <AryehGregor> | 1F3E9 LOVE HOTEL |
| 00:46 | <AryehGregor> | 1F3EA CONVENIENCE STORE |
| 00:46 | <AryehGregor> | 1F3EC DEPARTMENT STORE |
| 00:46 | <Hixie> | um, 1F499 to 1F49C are identical except for colour |
| 00:46 | <Hixie> | that ought to be interesting |
| 00:46 | <Hixie> | up to now unicode has been black and white |
| 00:47 | <AryehGregor> | I have no idea what some of these will look like. |
| 00:47 | <AryehGregor> | 1F452 WOMANS HAT |
| 00:47 | <AryehGregor> | Ooh, handy! 1F464 BUST IN SILHOUETTE |
| 00:47 | <AryehGregor> | = guest account |
| 00:47 | <AryehGregor> | 1F471 WESTERN PERSON |
| 00:47 | <AryehGregor> | . . . |
| 00:47 | <AryehGregor> | Is it supposed to emphasize the round eyes or something? |
| 00:47 | <TabAtkins> | 8-| |
| 00:48 | <Hixie> | 1F5FB to 1F5FE is going to be a terrible precedent |
| 00:48 | <Hixie> | prepare for planes 2-14 being full of landmark icons |
| 00:48 | <AryehGregor> | Seriously, though, are there reference pictures for these, or it's like every Unicode font will have a totally different-looking 1F47D EXTRATERRESTRIAL ALIEN? |
| 00:48 | <Hixie> | no idea |
| 00:48 | <TabAtkins> | I'm going with the latter. |
| 00:49 | <AryehGregor> | Some of these things will only be remotely legible at huge font sizes. |
| 00:49 | <AryehGregor> | What's up with how many of these are Japanese, anyway? |
| 00:50 | <AryehGregor> | Four out of five of "Cultural symbols" are Japanese, for instance. |
| 00:50 | <Hixie> | emojicons are all japanese |
| 00:50 | <Hixie> | nobody else seems to have gone quite as crazy as they have with this stuff |
| 00:50 | <AryehGregor> | 1F5FE SILHOUETTE OF JAPAN? So I guess we need a silhouette of all other countries too, and we should add new ones every time there's a successful war? |
| 00:51 | <Hixie> | like i said above :-) |
| 00:51 | <AryehGregor> | "SILHOUETTE OF FICTITIOUSTAN BETWEEN APRIL AND DECEMBER 2008" |
| 00:51 | <AryehGregor> | :/ |
| 00:53 | <Hixie> | http://www.unicode.org/~scherer/emoji4unicode/snapshot/emojidata.pdf |
| 00:55 | <Hixie> | the ones in red are the new ones |
| 00:57 | <AryehGregor> | I'm torn between seeing this as insane and seeing it as awesome. |
| 00:57 | <Hixie> | yes! |
| 00:57 | <Hixie> | some of these are going to be really hard to explain in 1000 years to our children on another planet |
| 00:57 | <Hixie> | my sig is so changing once this goes through |
| 00:59 | <TabAtkins> | Aw man, so good. |
| 00:59 | <TabAtkins> | I like how U+1F473 ALIEN MONSTER looks completely different between the suggested symbol and the actual characters as implemented in two mobile phones. |
| 01:00 | <Hixie> | i love the separate "HOTEL" and "LOVE HOTEL" entries |
| 01:00 | <TabAtkins> | That's how you know it's Japanese. |
| 01:00 | <Hixie> | it really is hilarious to see what they include in emoji |
| 01:01 | <Hixie> | theres a dozen or two animals and another dozen insects, out of the millions of known animals, which itself represents like 2% of all animals |
| 01:01 | <TabAtkins> | U+1F4A9 PILE OF POO |
| 01:03 | <Hixie> | ah, i can finally have a single character as my away message when I sleep: U+1F4A4 |
| 01:04 | <Hixie> | lol U+1F4B8 MONEY WITH WINGS |
| 01:04 | <Hixie> | man i almost feel bad about saying "no" to people who ask for crazy things in HTML now |
| 01:06 | <TabAtkins> | The difference is that nobody expects everyone to implement all of unicode. |
| 01:06 | <Hixie> | ok seriously this is quite insane. Now if aliens come, instead of sending them wikipedia, we can just ship them the Unicode table and they can pretty much learn everything they want about our culture from that. |
| 01:06 | <Paul_Irish> | http://paulirish.com/i/f6b0.png money with wings |
| 01:07 | <AryehGregor> | On a totally different off-topic note, is this true or what? http://jeff-vogel.blogspot.com/2010/04/how-i-saved-gaming-industry-overnight.html |
| 01:07 | <AryehGregor> | The gaming industry is completely insane in how it throws away everything it creates. |
| 01:08 | <TabAtkins> | I agree. |
| 01:08 | <TabAtkins> | But I also agree with the commenter who says that if you stick with roughly the same technology, you actually have to offer a compelling story to get people to like your product. |
| 01:09 | <AryehGregor> | You don't need story, mechanics is fine. |
| 01:09 | <AryehGregor> | But you only redo the stuff you need to. |
| 01:09 | <Hixie> | lol, they didn't include FACE WITH ROLLING EYES. I guess the irony would have been too great? |
| 01:09 | <AryehGregor> | Valve is a great example. |
| 01:09 | <TabAtkins> | Sure, for some things. Still more difficult than just paying people to make something completely new and shiny. |
| 01:10 | <TabAtkins> | That requires no creativity, just technical acumen. |
| 01:12 | <nessy> | at least this would be a simple way to get icons into captions |
| 01:12 | <nessy> | apart, of course, for company logos ;) |
| 01:12 | <TabAtkins> | That's what Plane 6 is for. |
| 01:16 | <othermaciej> | nessy: if you're on the Mac, I recommend Colloquy for IRC |
| 01:16 | <nessy> | ok, will try it out |
| 01:17 | <nessy> | does it hook into irc, jabber, gtalk, and twitter? |
| 01:17 | <nessy> | I like to have all that stuff in one app |
| 01:19 | <Hixie> | for jabber/gtalk to irc, i recommend bitlbee |
| 01:19 | <Hixie> | for twitter to irc, i recommend tircd |
| 01:19 | <Hixie> | both are compatible with any irc client |
| 01:20 | <Hixie> | since they're gateway servers |
| 01:20 | <othermaciej> | nessy: it only does IRC, but it's way better for IRC than Adium is |
| 01:21 | <nessy> | I used to use tircd, but am finding the integration of twitter directly in Adium really nice |
| 01:21 | <nessy> | then I don't have to run another program - it just does it |
| 01:26 | <TabAtkins> | Summary of RDFa 1.1: A ridiculously verbose way of expressing identical metadata relationships as Microdata. With datatypes. |
| 01:28 | <Hixie> | TabAtkins: that's not really fair, rdfa does way more than microdata. For example it does per-field typing, and supports XML literals. |
| 01:28 | <TabAtkins> | I said per-field typing. ^_^ XML literals is indeed something it has over Microdata. |
| 01:29 | <Hixie> | and it has full CURIE support |
| 01:29 | <TabAtkins> | That's not a benefit. |
| 01:29 | <Hixie> | oh |
| 01:29 | <Hixie> | well i'm sure it can be sold as a benefit |
| 01:29 | <Hixie> | does microdata do CURIES? I think not! |
| 01:29 | <Hixie> | clearly microdata is inferior |
| 01:29 | <TabAtkins> | Microdata does CURIES via an implicit @vocab mechanism. |
| 01:30 | <Hixie> | i have no idea what that means but it sounds good, i like it |
| 01:31 | <TabAtkins> | @vocab is just RDFa1.1's way of making you not need to use prefixes. Any property nested in the @vocab element that doesn't have a prefix uses the @vocab value as its prefix. |
| 01:31 | <TabAtkins> | Alternately: the mechanism isn't implicit, but it's covered by @itemtype. |
| 01:31 | <TabAtkins> | Which I think is actually more accurate. |
| 01:33 | <TabAtkins> | The RDFa 1.1 spec doesn't do a great job of explaining what all the attributes do. It took some hunting to discover that @typeof and @datatype are the same thing, with the former for the triple-subject and the latter for the triple-object. |
| 01:33 | <TabAtkins> | Also: chaining is a bad, confusing idea and I hate it. |
| 01:37 | <TabAtkins> | Additionally: very confused about why/how @src is always a subject, never an object, but @href is always an object, never a subject. |
| 01:38 | <TabAtkins> | That's not true. @src can be an object too, at the same time as it's functioning as a subject and a scoping indicator. |
| 01:39 | <roc> | Colloquy is rubbish, it crashes, won't reconnect when I get back on the network, and gets into weird rendering states |
| 01:39 | <TabAtkins> | Just run irssi. |
| 01:39 | <roc> | of course I still use it, so I suppose it's not that bad or else I'm just a masochist |
| 01:41 | <Hixie> | nessy: thanks (re your mail) |
| 01:41 | <nessy> | thought you might like it :) |
| 01:41 | <nessy> | many ppl working behind the scenes to make this happen |
| 01:41 | Hixie | is wondering what to do about positioning captions |
| 01:41 | <Hixie> | considering just the horizontal dimension for now |
| 01:42 | <Hixie> | there are three variables for a cue: |
| 01:42 | <Hixie> | horizontal position, size of the box, and the alignment of the text within the box |
| 01:42 | <Hixie> | http://docs.google.com/drawings/edit?id=1LXroDh1tSee1YM79toEMo6OEdlI2Du5EfoWt7mSmc8U&hl=en |
| 01:43 | <Hixie> | there's two ways i can think of doing this: either aligning the alignment edge to the given horizontal position, or |
| 01:43 | <Hixie> | aligning the point along the box in the horizontal dimension that is the given distance along the box as a fraction of the box width to the equivalent position on the video as a fraction of the video width |
| 01:43 | <Hixie> | the latter works really well if the width is known ahead of time and is not 100% |
| 01:44 | <Hixie> | the former works really well if the horizontal position is less than 75% or so |
| 01:44 | <Hixie> | the latter makes the position irrelevant if the width is 100% though |
| 01:44 | nessy | is just going through email and reached the public-html thread ;) |
| 01:45 | <TabAtkins> | I'm confused about how the last box in the second example works. |
| 01:45 | <Hixie> | and the former fails dramatically for the case of the position being 100% |
| 01:45 | <TabAtkins> | Omitted size implies 100%, and thus ignores H? |
| 01:45 | <Hixie> | TabAtkins: the point 50% along the way of the box is aligned to the point 50% along the video |
| 01:45 | <TabAtkins> | Oh, duh, got it. |
| 01:45 | <Hixie> | TabAtkins: it's just that since the dimension is 100% (presumably, by default), that is indistinguishable to any other position |
| 01:46 | <TabAtkins> | I like that usage. It's very natural in CSS backgrounds. |
| 01:46 | <Hixie> | yeah but it totally makes the position useless if the width is not known |
| 01:46 | <Hixie> | it's as bad as the last case in the first box |
| 01:46 | <TabAtkins> | Unless you introduce some concept of "shrinkwrap" for width. |
| 01:46 | <nessy> | for the positioning and styling stuff, can't we use CSS directly? |
| 01:46 | <Hixie> | TabAtkins: if we do that, then each cue would align differently |
| 01:47 | <Hixie> | nessy: CSS doesn't have the magic avoidance we need to add for titles to avoid the overlapping titles issue |
| 01:47 | <TabAtkins> | Yes? So either you do a definite size, or just deal with it. |
| 01:47 | <Hixie> | TabAtkins: i'd rather the default was pretty :-) |
| 01:47 | <nessy> | hmmm… |
| 01:47 | <TabAtkins> | I don't really have an opinion on whether it's better to shrinkwrap or just expand to full width. |
| 01:47 | <TabAtkins> | The latter seems like it would be fine, personally. |
| 01:48 | <Hixie> | maybe the default should be to do absolute positions, except if you set a width, then it does the second case... |
| 01:48 | <Hixie> | though then you still have the other problem... |
| 01:48 | <Hixie> | i guess the question is |
| 01:48 | <Hixie> | what should happen if you say a left-aligned box is at position 100% horizontally? |
| 01:49 | <Hixie> | does that even make sense? |
| 01:49 | <TabAtkins> | That's why always doing the latter is best. |
| 01:49 | <TabAtkins> | So that situation actually produces something good - a right-aligned box. |
| 01:49 | <Hixie> | always doing the latter works fine except when width is automatic, then it's counterintuitive or ugly depending on how we do it |
| 01:50 | <Hixie> | no, it produces a left-aligned box that is the full width of the screen :-) |
| 01:50 | <TabAtkins> | If the width is auto positioning it doesn't make sense, given our requirement that it shouldn't go out of the screen. |
| 01:50 | <TabAtkins> | At least, horiz positioning it doesn't. |
| 01:50 | <Hixie> | if the size of the box is 100%, and we use the case-2 alignment mechanism, then the position has no effect |
| 01:50 | <TabAtkins> | Yes. |
| 01:50 | <Hixie> | yeah maybe that's the answer... if it has no width, then ignore the horizontal positioning |
| 01:51 | <erlehmann> | Hixie, overlapping title avoidance ? couldn't you just create pseudo-boxes that become more if there are more subtitles ? styling like video::subtitle:first-of-type() etc ? |
| 01:51 | <Hixie> | (and say so explictly) |
| 01:51 | <TabAtkins> | Phew. Just got through Chapter 8 of RDFa 1.1. There aren't words to describe how stupid the complexity of the processing here is. |
| 01:51 | <Hixie> | erlehmann: watch the titles at http://www.youtube.com/watch?v=xG9KluukpJI#t=2m40 |
| 01:51 | <Hixie> | erlehmann: i'd like us to get that effect without the author having to say anything about the positioning |
| 01:52 | <nessy> | I am confused about this whole positioning thing |
| 01:52 | <TabAtkins> | Unfortuantely there's no way to "fix" it without just dropping the whole concept and saying "Use raw RDF, or Microdata." |
| 01:52 | <erlehmann> | words fail me to describe the awesome that animu has in defining this part of the spec |
| 01:53 | <Hixie> | erlehmann: the same thing occurs in lots of other contexts too, it's just that anime is the main way most of us geeks get exposed to fancy subtitle effects :-) |
| 01:54 | <nessy> | Hixie: do I understand correctly that you are trying to put the avoidance straight into the caption file format? |
| 01:54 | <Hixie> | nessy: straight into the processing model for the format, yeah |
| 01:54 | <Hixie> | not into the format itself |
| 01:54 | <Hixie> | i.e. there should be no syntax for this |
| 01:54 | <Hixie> | it should just happen |
| 01:54 | <nessy> | but wouldn't you only know of overlapping conflicts if you have all the different caption tracks analysed? |
| 01:55 | <nessy> | typicallly, the ones that conflict would come from different caption files |
| 01:55 | <Hixie> | if all the tracks are using the same format, then no, you just do it on the fly |
| 01:55 | <Hixie> | for rendering, doesn't matter which track the files come from |
| 01:55 | <nessy> | who would do it? at which level? |
| 01:55 | <Hixie> | the UA |
| 01:55 | <Hixie> | when rendering |
| 01:56 | <Hixie> | (or the media subsystem, or whatever is responsible for this) |
| 01:56 | <nessy> | ok, follow |
| 01:56 | <nessy> | so, what do you need to put into the files then to make that happen? |
| 01:56 | <othermaciej> | ideally, you want a caption format that would be reasonable for either a web engine or a media engine to render |
| 01:56 | <Hixie> | nessy: hopefully nothing |
| 01:56 | <othermaciej> | since implementation strategies may differ |
| 01:56 | <Hixie> | othermaciej: yeah, 100% agree |
| 01:57 | <nessy> | ok, I follow :) |
| 01:57 | <nessy> | so, why would CSS styling then not work per caption file? |
| 01:58 | <Hixie> | not sure what you mean |
| 01:58 | <Hixie> | why would CSS styling not work? |
| 01:58 | <Hixie> | work for what? |
| 01:58 | <nessy> | and positioning, I mean |
| 01:59 | <Hixie> | i don't understand how you'd use CSS to do the positioning. |
| 01:59 | <nessy> | the part of CSS that does positioning |
| 01:59 | <nessy> | CSS has alignment properties and stuff, right? |
| 02:00 | <nessy> | I'm trying to understand why there is a need for the horizontal positioning (H) and alignment (A) stuff to be different from CSS |
| 02:00 | <Hixie> | CSS has like a dozen different layout mechanisms, i don't see how any of them would work here though |
| 02:01 | <TabAtkins> | Actually... Flexbox + abspos would probably work great. |
| 02:01 | <Hixie> | i mean, i intend to define things in term of the block/inline/vertical layout mechanisms, but you still have to position those somehow |
| 02:01 | <Hixie> | TabAtkins: including for http://www.youtube.com/watch?v=xG9KluukpJI#t=2m40 ? |
| 02:01 | <nessy> | ok, just go ahead - maybe things get clearer when I see it all specified |
| 02:01 | <nessy> | I'm just struggling to follow the logic |
| 02:02 | <TabAtkins> | Hixie: That'd be absposing the translations of the writing on the picture. |
| 02:02 | <Hixie> | TabAtkins: no i mean the way the second title doesn't move when the first goes away |
| 02:02 | <Hixie> | TabAtkins: and the way the second one appears above the first automatically (without being given explicit instructions of where to appear) |
| 02:02 | <Hixie> | nessy: i might be missing something obvious... if you have a proposal for how to make it work with CSS, i'm all ears |
| 02:03 | <TabAtkins> | The former - no, unless you have a mechanism for setting things to visibility:hidden when they overlap, then visibility:collapse when they stop overlapping. |
| 02:03 | <nessy> | I'll see if I can work it out with CSS - maybe then I can see what the issue is :) |
| 02:03 | <TabAtkins> | The latter, yes. |
| 02:04 | <Hixie> | TabAtkins: i'd like a system where you can position things all over the place then have another title in "defualt" position and have that one just slide to the first "line" where it fits |
| 02:04 | <TabAtkins> | (In current draft, have a flexbox with box-orient:vertical and box-direction:alternate. In my current rewritten syntax, just have display:flex-up on the caption container. |
| 02:04 | <Hixie> | TabAtkins: i think either way you end up having to have dedicated code |
| 02:04 | <nessy> | just one more question: with the S parameter (size) are you trying to do automatic line breaks? |
| 02:05 | <Hixie> | nessy: possibly. The main reason was to have a way to say where the edge was for purposes of avoiding overlaps. |
| 02:05 | <Hixie> | nessy: is there a need for automatic wrapping? |
| 02:05 | <TabAtkins> | Hixie: In the case that you have something manually positioned in the middle of the screen, and then overlapping text fills the entire bottom fo the screen to just below the positioned text, would a third overlapping segment then go above the manually positioned text? |
| 02:06 | <nessy> | I don't think so - though I wonder what happens when you change video size, e.g. to to full-screen |
| 02:06 | <Hixie> | TabAtkins: i'd hope so, don't see where else we'd want it to go |
| 02:06 | <nessy> | if you don't blow up the captions at the same ratio, they look really tiny |
| 02:06 | <Hixie> | nessy: i assume captions will be sized relative to the video |
| 02:06 | <Hixie> | nessy: but i'm more worried about different fonts having different needs for where to wrap |
| 02:06 | <TabAtkins> | Hixie: In that case we do need a new layout mode. |
| 02:07 | <nessy> | so, rather than having a S parameter size given in the spec, I would say that S should be calculated by the rendering engine, right? |
| 02:07 | <Hixie> | TabAtkins: right, that's what i'm doing :-) |
| 02:07 | <TabAtkins> | Something with a notion of intruding abspos, and stability of positioning. |
| 02:07 | <Hixie> | nessy: how do you mean? |
| 02:08 | <nessy> | are the three parameters in your image H, S, A specified in the caption file or just something that your layout mode deals with? |
| 02:08 | <nessy> | maybe this is where my whole confusion comes from! |
| 02:09 | <nessy> | I would think H, A are in the caption file, but S is only in the layout mode |
| 02:10 | <Hixie> | that's one of the things i want to try to work out. I think it's possible that we'd have all three in the track file (though all three optional for each cue of course) |
| 02:10 | <Hixie> | but maybe we can get away with fewer |
| 02:10 | <Hixie> | Extended SRT has H and S |
| 02:10 | <Hixie> | (though expressed as X1 and X2) |
| 02:11 | <Hixie> | if we want to be able to set a background colour whose edge doesn't move around with each cue, we'd need an S |
| 02:11 | <nessy> | only in the layout mode though, I think |
| 02:11 | <TabAtkins> | I wonder if just doing a left and right would be better instead. |
| 02:12 | <Hixie> | so e.g. the question is, in the video from which http://junkyard.damowmow.com/425 comes, is the box the same size in each cue? |
| 02:12 | <nessy> | as an author, I wouldn't really want to have to calculate for every text cue how long it is |
| 02:12 | <Hixie> | if yes, we need an explicit S |
| 02:12 | <TabAtkins> | Benefit is that it shares well with the "abspos" positioning scheme. |
| 02:12 | <Hixie> | TabAtkins: H+S and X1+X2 are equivalent |
| 02:12 | <TabAtkins> | Hixie: Yes, but one or the other may be more natural to use. |
| 02:12 | <Hixie> | TabAtkins: how it is written in the file is a separate issue :-) |
| 02:13 | <Hixie> | i'm just trying to work out the processing model for now |
| 02:13 | <nessy> | it's either a box defined for all text cues in size or it is dynamically adjusted around the size of the current text cue |
| 02:13 | <nessy> | I think specifying it separately per text cue is a nightmare |
| 02:13 | <nessy> | to authore |
| 02:14 | <Hixie> | yes i'd expect most authors to let it be implied |
| 02:14 | <Hixie> | i'd expect most authors to not set any of this |
| 02:14 | <nessy> | that X1 X2 Y1 Y2 of extended SRT is not implemented anywhere is a good sign that it's not useful per text cue |
| 02:14 | <Hixie> | it's only really relevant for cases like http://philip.html5.org/misc/eva-captions.jpg |
| 02:14 | <Hixie> | or http://img3.imageshack.us/img3/6743/vlcsnap090208083027134xq5.png |
| 02:16 | <nessy> | to me as an author I would think there is top, right, bottom, left, center placement of caption cue box; then there is left, right, center, justify alignment on the text around the center of the caption cue box |
| 02:17 | <Hixie> | it's more complicated than that because of having to deal with which direction the box grows in when it's multiple lines long |
| 02:18 | <nessy> | then I might define a background formatting for the caption cue box for all captions and either make that adjust to the size of the caption or give it a fixed size into which all my caption cues will fit |
| 02:20 | <nessy> | the direction in which the box grows is dependent on the charset (is it charset that I use, e.g. for Chinese characters?) and the way in which that charset works - e.g. top-to-bottom or left-to-right |
| 02:20 | <nessy> | I would think |
| 02:21 | <Hixie> | i don't mean the block-progression-direction, i mean where the box is anchored. Consider http://philip.html5.org/misc/eva-captions.jpg -- if the top caption were one line long, it would be at the top, but if the bottom caption were one line long, it would be at the bottom. |
| 02:21 | <Hixie> | they grow in different directions |
| 02:21 | <Hixie> | http://dashiva.net/misc/1271498287684.jpg shows that oo |
| 02:21 | <Hixie> | too |
| 02:22 | <Hixie> | except there i'd expect the bottom one to grow down, or maybe even be centered, rather than grow up |
| 02:23 | <Hixie> | you wouldn't want the author to have to worry about this for each cue, so you really want good defaults so that just throwing the caption to the top or the bottom gets the right effect |
| 02:23 | <Hixie> | without having to give a dozen coordinates and alignment instructions for each cue |
| 02:25 | <nessy> | I think we want the same thing |
| 02:25 | <nessy> | I might just not express it very well |
| 02:26 | <nessy> | on http://dashiva.net/misc/1271498287684.jpg I would think there are two boxes |
| 02:27 | <nessy> | a second line in both boxes would always be rendered underneath the first line, but the box center position would move down on the top box and up on the bottom box |
| 02:27 | <Hixie> | yeah |
| 02:28 | <nessy> | and the author would only say that for the first box it is top position and left aligned, and on the second box that it is bottom positioned and center aligned |
| 02:28 | <Hixie> | ideally though the author would only have to give two instructions, maybe three: for the top box: align left, position at the top; for the bottom box: position at the bottom |
| 02:28 | <Hixie> | or maybe not even anything for the bottom box |
| 02:28 | <Hixie> | gotta go to dinner |
| 02:29 | <Hixie> | later |
| 02:29 | <nessy> | will be out for lunch |
| 02:29 | <nessy> | ttyl |
| 03:29 | <Bolkonskij> | hi |
| 05:29 | <Hixie> | a lot of the discussion in public-html-a11y about timed tracks has assumed that subtitles are mutually exclusive... why is that? |
| 05:29 | <Hixie> | wouldn't that just be a UI decision? |
| 05:30 | <Hixie> | foolip: you were in that discussion a lot... any idea? |
| 05:31 | <micheil> | Hixie: I've been thinking about some websockets stuff, and have a bit of an idea.. wanted to run it past you if you had a moment? |
| 05:31 | <Hixie> | sure |
| 05:32 | <micheil> | okay, currently with websockets, they are a two way channel, however, what happens in the case where a websocket server is only interested in streaming data down to a client? |
| 05:32 | <micheil> | would it make sense to add an extra (optional) headers which allowed you to specific (from the server) whether the connection was to be a ReadOnly connection? |
| 05:33 | <micheil> | (alternatively, you may also wish to implement a writeOnly, but I can't see a use case for that) |
| 05:33 | <Hixie> | you define the protocol that runs over websocket, so you could just define your protocol such that there is nothing the client is allowed to say, and the server can just ignore everything the client sends |
| 05:33 | <micheil> | by default, websockets would assume that they are both Read and Write, unless this is set |
| 05:34 | <micheil> | true, although, would it not be a good idea to give the client some indication of this? |
| 05:34 | <micheil> | I'm thinking in a more generic sense, rather then at the subprotocol level |
| 05:35 | <micheil> | this flag would have no effect on the readyState of the connection. |
| 05:35 | <Hixie> | well it's not like the client is a random client, the client is you |
| 05:36 | <Hixie> | i mean, you're not going to be talking to random pages, you're only talking to people who know what your protocol is |
| 05:36 | <Hixie> | so they know your protocol is "read only", because that's why they're connecting to you |
| 05:37 | <micheil> | not so |
| 05:37 | <micheil> | the client may be a random client, in the case of a websocket server as an API server |
| 05:40 | <Hixie> | then you're going to have to tell the client a heck of a lot more than just that the server doesn't want anything |
| 05:40 | <Hixie> | you're going to have to tell the client the entire protocol |
| 05:41 | <micheil> | hmm.. okay, fair enough |
| 05:41 | <micheil> | it was just a quick idea I had |
| 05:42 | <Hixie> | micheil: the way to think of Web Sockets is that it is the same as TCP |
| 05:42 | <Hixie> | except for the web |
| 05:42 | <micheil> | okay |
| 05:42 | <micheil> | I'm thinking in a more service oriented thing |
| 05:43 | <micheil> | Hixie: have you seen pusherapp.com? |
| 05:44 | <Hixie> | looks like what eventsource was made for :-) |
| 05:45 | <micheil> | eventsource? |
| 05:45 | <Hixie> | http://dev.w3.org/html5/eventsource/ |
| 05:47 | <micheil> | Hixie: there's a difference there, these are read/write |
| 05:47 | <Hixie> | ah ok |
| 05:47 | <micheil> | the stuff about readonly was in relation to another piece of work I'm doing |
| 05:48 | <othermaciej> | good evening |
| 05:48 | <micheil> | evening' |
| 05:54 | <abarth> | anyone know what WG at the IETF is working on URL stuff? |
| 06:17 | <hsivonen> | Hixie: do you recall if you intended to stop processing if the insertion point becomes non-foreign in the case mentioned in the bug report http://www.w3.org/Bugs/Public/show_bug.cgi?id=9582 ? |
| 06:18 | <Hixie> | i don't recall off hand |
| 06:18 | <Hixie> | do you have some markup examples in mind? |
| 06:19 | <hsivonen> | IIRC <a><svg><foreignObject><a><svg></a> |
| 06:20 | <othermaciej> | abarth: IRIbis |
| 06:20 | <abarth> | is that http://tools.ietf.org/wg/iri/ ?> |
| 06:20 | <othermaciej> | http://tools.ietf.org/wg/iri/ |
| 06:20 | <othermaciej> | yeah |
| 06:21 | <othermaciej> | abarth: "work" may be a stronger word than is merited so far |
| 06:21 | <abarth> | ic |
| 06:21 | <othermaciej> | abarth: but they are indeed planning to publish an updated document that's supposed to handle real-world URL parsing |
| 06:22 | <abarth> | i'm crunching all this data for the GURL/KURL thing |
| 06:22 | <abarth> | maybe I'll write up a doc and send it to their mailing list |
| 06:22 | <abarth> | that's probably a better forum than public-html |
| 06:22 | <abarth> | it's looking pretty messy at the moment |
| 06:22 | <abarth> | but maybe it will become clearer as I get further in |
| 06:23 | <othermaciej> | abarth: messy in what way? |
| 06:23 | <othermaciej> | abarth: quirky required behavior? lots of browser differences? |
| 06:23 | <abarth> | lots of browser differences |
| 06:24 | <abarth> | i'm not sure what's required |
| 06:24 | <abarth> | if there's a lot of variety, that might mean there's room to remove quirks |
| 06:24 | <aboodman> | abarth: you around? |
| 06:25 | <abarth> | aboodman: yes |
| 06:26 | <aboodman> | abarth: hey, i was wondering something about cors |
| 06:26 | <aboodman> | doesn't it have the issue where it might leak access to intranet resources? |
| 06:27 | <othermaciej> | aboodman: no (unless intranet resources are in the habit of adding Access-Control-Allow-Origin headers randomly) |
| 06:27 | <abarth> | aboodman: that's one of the threats CORS tries to address |
| 06:27 | <abarth> | aboodman: do you have something speific you're worried about? |
| 06:27 | <othermaciej> | aboodman: in theory it *can* violate integrity (as opposed to confidentiality) of intranet resources, but only in the same ways forms already can |
| 06:27 | <aboodman> | right cors, requires that existing servers respond with a special header. |
| 06:27 | <aboodman> | even for GET. |
| 06:27 | <abarth> | yes |
| 06:27 | <aboodman> | sorry, forgot that bit. |
| 06:29 | <aboodman> | ooc, if the intranet issue didn't exist, would servers still need to respond with the special header? |
| 06:29 | <abarth> | depends what you mean by intranet |
| 06:29 | <aboodman> | that is, would not sending credentials be sufficient. |
| 06:29 | <abarth> | there's always IP-based authentication |
| 06:29 | <othermaciej> | for requests without credentials, maybe not |
| 06:29 | <abarth> | you can't avoid sending credentials |
| 06:29 | <abarth> | for example, proxy-auth credentials |
| 06:29 | <abarth> | or IP addresses |
| 06:29 | <othermaciej> | "intranet" is a shorthand for a broad category |
| 06:30 | <abarth> | what about the loopback interface? |
| 06:30 | <abarth> | does that count as an intranet? |
| 06:30 | <othermaciej> | it basically means any resource you have access to by virtue of network position |
| 06:30 | <aboodman> | othermaciej: ok, that shorthand is fine. |
| 06:30 | <othermaciej> | abarth: the loopback interface is not behind a firewall, is it? |
| 06:30 | <aboodman> | intranet => any resource you have access to by virtue of network position |
| 06:30 | <abarth> | it might or might not be. there are lots of services that bind only to 127.0.0.1 |
| 06:31 | <othermaciej> | abarth: well, I guess for most home users it is since they are behind a NAT firewall |
| 06:31 | <abarth> | those aren't "firewalled" per-se |
| 06:31 | <abarth> | but they're only accessible from the box itself |
| 06:31 | <othermaciej> | aboodman: many home routers are reconfigurable via http from the local network segment |
| 06:31 | <othermaciej> | aboodman: in many cases this is encoded in firmware that can't readily be upgraded |
| 06:31 | <aboodman> | i guess i'm asking: are there other forms of ambient authority that the browser does not control, other than client IP address. |
| 06:31 | <othermaciej> | so "if the intranet issue didn't exist" is a rather huge counter-factual |
| 06:32 | <aboodman> | yeah, it was "out of curiosity" |
| 06:32 | <aboodman> | not related to current debate |
| 06:32 | <othermaciej> | the IP address and the routes |
| 06:32 | <othermaciej> | for example, I have access to systems on net 17 right now |
| 06:32 | <othermaciej> | but my IP address is not on net 17 |
| 06:32 | <othermaciej> | because I have a VPN tunnel |
| 06:33 | <othermaciej> | random attackers cannot send packets to machines behind Apple's firewall even if they can send packets to me |
| 06:33 | <othermaciej> | it's a matter of network topology, not just IP address |
| 06:33 | <aboodman> | i see. |
| 06:34 | <aboodman> | ok, thanks. |
| 06:34 | <abarth> | aboodman: proxy-authentication is another example |
| 06:34 | <abarth> | also, just having a fresh IP address can be valuable |
| 06:34 | <abarth> | e.g., for sending spam |
| 06:34 | <abarth> | or click fraud |
| 06:34 | <abarth> | there was a recent attack on IRC using browsers |
| 06:35 | <abarth> | that used that property |
| 06:35 | <othermaciej> | yum, cross-protocol attacks |
| 06:35 | <othermaciej> | aboodman: the CORS vs UMP debate is really about whether it is ever ok to send user and originating site credentials in a cross-site request |
| 06:36 | <othermaciej> | the ObjCap people say no, because ambient authority is bad, end of story |
| 06:36 | <othermaciej> | others (e.g. me) would say, but the Web security model is already based on origins, so we may as well go with the flow in the soundest way we can instead of trying to fight it |
| 06:36 | <othermaciej> | and CORS makes it easier to code many common access patterns securely, notwithstanding theory |
| 06:37 | <Hixie> | imho UMP might make sense but only if you revamp the way the web works first |
| 06:37 | <aboodman> | yeah, my question came up because i remembered the "intranet case" from earlier discussions abarth and i had had regarding chrome extensions. |
| 06:37 | <aboodman> | and i suddenly wondered how cors could work at all. |
| 06:37 | <othermaciej> | if we were designing the Web security model from scratch, then an object-capability model might be a reasonable choice |
| 06:37 | <aboodman> | i had forgotten the requirement to respod with a header. |
| 06:37 | <aboodman> | apologies for the dumb question. |
| 06:37 | <othermaciej> | aboodman: the "intranet case" is a bane of existence for cool stuff |
| 06:37 | <abarth> | there are no dumb questions on this topic |
| 06:37 | <abarth> | this stuff is all very archane |
| 06:38 | <othermaciej> | there are many dumb answers, though :-) |
| 06:39 | <othermaciej> | security is hard |
| 06:39 | <othermaciej> | the Web is hard |
| 06:39 | <wirepair> | which is why i have a job ;> |
| 06:39 | <othermaciej> | hardness combines nonlinearly |
| 06:39 | <aboodman> | fwiw i think othermaciej's argument that keeping secrets secure is compelling too. |
| 06:40 | <aboodman> | in favor of sop. |
| 06:40 | <othermaciej> | which argument was that? |
| 06:41 | <aboodman> | it ws from awhile ago, but you recently referred to it |
| 06:41 | aboodman | looks |
| 06:41 | <abarth> | yeah, integrity primitive are better for integrity properties |
| 06:41 | Hixie | doesn't understand why the a11y tf came up with <trackgroup> |
| 06:44 | <aboodman> | "the risk of programming errors with CORS-only |
| 06:44 | <aboodman> | solutions has to be weighed against the risk of programming errors in |
| 06:44 | <aboodman> | shared-secret solution" |
| 06:44 | <aboodman> | http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0481.html |
| 06:44 | <aboodman> | it was ojan who referred to it, not you. |
| 06:44 | <othermaciej> | aboodman: oh |
| 06:45 | <othermaciej> | yeah, I remember that |
| 06:45 | <Hixie> | TabAtkins: yt? |
| 06:45 | <othermaciej> | that's something that is often glossed over, the challenge of managing shared secrets |
| 06:45 | <othermaciej> | especially if those shared secrets go in URLs |
| 06:45 | <Hixie> | anyone know what the csswg's current state of thinking wrt multiple pseudo-elements per selector is? |
| 06:45 | <othermaciej> | it's very hard to keep URLs confidential - they like to leak out into the world |
| 06:47 | <othermaciej> | aboodman, abarth: a while back I made a series of slides explaining how you could combine Origin-based defenses and shared secrets to make a protocol that was more robust than either alone |
| 06:48 | <othermaciej> | but I never finished it, because it seemed pointless to continue the debate about security qualities of the protocol |
| 06:48 | <othermaciej> | but maybe I could dig it out and send it somewhere |
| 06:48 | <abarth> | did you take the anticipated rhetorical context into account? |
| 06:48 | <abarth> | <--- i'll stop being mean now |
| 06:49 | <othermaciej> | abarth: I did - that's why I never finished it :-) |
| 06:49 | <abarth> | IP address canonicalization seems to break down as Safari+Firefox versus Chrome+IE |
| 06:49 | <abarth> | IE likes to canonicalize whereas FF doesn't |
| 06:50 | <abarth> | canonicalize('http://000030052000001/';) is 'http://192.168.0.1/'; IE |
| 06:50 | <abarth> | canonicalize('http://000030052000001/';) is 'http://192.168.0.1/'; KR |
| 06:50 | <abarth> | canonicalize('http://000030052000001/';) should be http://192.168.0.1/. Was http://000030052000001/. FF |
| 06:50 | <abarth> | canonicalize('http://000030052000001/';) should be http://192.168.0.1/. Was http://000030052000001/. SA |
| 06:50 | <abarth> | as a random example |
| 06:50 | <othermaciej> | are there any reasons besides matching one browser or the other to caniicalize or not? |
| 06:50 | <Hixie> | abarth: iirc it is considered a security-wise dubious thing to support non-dotted-quad ipv4 addresses |
| 06:50 | <Hixie> | abarth: and it is certainly not kosher per the rfc iirc |
| 06:51 | <abarth> | what does "support" mean? |
| 06:51 | <Hixie> | convert to anything or resolve as an IP address |
| 06:51 | <othermaciej> | so you think URLs like that should not be canonicalized, and the network layer should refuse to load from such UR:s? |
| 06:51 | <abarth> | i should check whether firefox actually lets you follow those URLs |
| 06:51 | <othermaciej> | er |
| 06:51 | <othermaciej> | URLs |
| 06:52 | <Hixie> | othermaciej: unless there's a pressing compat need or the spec says i'm wrong, yes |
| 06:52 | <Hixie> | to start with, pure-numeric labels are valid dns labels |
| 06:52 | <Hixie> | so you could have a local machine in dns with the name "000030052000001" if i'm not mistaken |
| 06:53 | <Hixie> | (e.g. www.000.com. resolves) |
| 06:53 | <othermaciej> | I thought that officially DNS labels were not supposed to start with a number |
| 06:53 | <othermaciej> | but I know that is often violated |
| 06:53 | <Hixie> | 000.com and 123.com are both registered |
| 06:53 | <Hixie> | so... |
| 06:57 | <othermaciej> | aboodman: hey, that was a good email you cited - I didn't remember writing that :-) |
| 06:57 | <aboodman> | heh. happy to help. |
| 06:57 | <aboodman> | this debate has been going on quite awhile. |
| 06:57 | <Hixie> | the debate is pointless since no UA is implement it |
| 06:58 | <Hixie> | implementing |
| 06:58 | <Hixie> | it's like Web SQL DB -- except with even fewer vendors on board |
| 06:58 | <othermaciej> | Hixie: except that Caja is apparently the most important UA of all |
| 06:58 | <Hixie> | i don't understand why it's still even on the table |
| 06:58 | <aboodman> | web sql db :( |
| 06:58 | <aboodman> | rip |
| 06:59 | <Hixie> | othermaciej: Why would this need specifying separately from the rest of Caja's APIs? |
| 06:59 | <othermaciej> | Hixie: don't ask me, ask Mark Miller |
| 06:59 | <Hixie> | i haven't seen him argue that it needs speccing because of caja |
| 07:00 | <othermaciej> | he cited Caja as a UA that plans to implement UMP and not CORS |
| 07:01 | <Hixie> | yeah that's all i've seen |
| 07:02 | <othermaciej> | I would say the APIs of script libraries do not require the Web standards process to define |
| 07:02 | <Hixie> | depends if they're going to be implemented once or more than once, i'd say |
| 07:03 | <Hixie> | but in this case i don't mind if it has a spec or not, i just think it should be done in a manner consistent with the rest of caja's apis |
| 07:03 | <Hixie> | if it's just for caja |
| 07:07 | <zcorpan> | http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/0009.html |
| 07:08 | <zcorpan> | since my previous speculation about microsoft implementing xhtml when they sent feedback on document.write was correct, i'll speculate again that they're now implementing canvas |
| 07:08 | <abarth> | Hixie: what about this kind of canonicalization: |
| 07:08 | <abarth> | canonicalize('http://[0:0::0:0:8]/') is 'http://[::8]/' |
| 07:10 | <zcorpan> | should (new WebSocket('ws://foo:80/')).URL return ws://foo/ or ws://foo:80/ ? |
| 07:11 | <abarth> | i have that case |
| 07:11 | <abarth> | one sec |
| 07:11 | <abarth> | KR canonicalize('ws://foo:80/') is 'ws://foo/' |
| 07:11 | <abarth> | FF canonicalize('ws://foo:80/') should be ws://foo/. Was ws://foo:80/. |
| 07:11 | <abarth> | IE canonicalize('ws://foo:80/') should be ws://foo/. Was ws://foo:80/. |
| 07:11 | <abarth> | SA canonicalize('ws://foo:80/') should be ws://foo/. Was ws://foo:80/. |
| 07:12 | <abarth> | short answer is "probably" |
| 07:12 | <abarth> | FF/IE/SA don't support web sockets |
| 07:12 | <abarth> | but for the protocols that they do support |
| 07:12 | <abarth> | KR/FF/IE remove default port numbers |
| 07:12 | <abarth> | but SA doesn't |
| 07:13 | <zcorpan> | so for say http://foo:80/, everyone would give http://foo/ ? |
| 07:13 | <zcorpan> | except SA? |
| 07:13 | <othermaciej> | aboodman: so hrome is the only browser to canonicalize away the default port? |
| 07:14 | <othermaciej> | oh, ws: |
| 07:14 | <abarth> | yeah |
| 07:14 | <aboodman> | othermaciej: no idea. |
| 07:14 | <abarth> | i'll show the http case |
| 07:14 | <abarth> | which is simpler |
| 07:14 | <abarth> | FF canonicalize('http://www.example.com:80/';) is 'http://www.example.com/'; |
| 07:14 | <abarth> | KR canonicalize('http://www.example.com:80/';) is 'http://www.example.com/'; |
| 07:14 | <abarth> | SA canonicalize('http://www.example.com:80/';) should be http://www.example.com/. Was http://www.example.com:80/. |
| 07:14 | <abarth> | IE canonicalize('http://www.example.com:80/';) is 'http://www.example.com/'; |
| 07:14 | <zcorpan> | thanks! |
| 07:14 | <othermaciej> | abarth: yeah, the default port thing really needs to be a whitelist of specific protocols - making it based on the protocols the browser knows seems bad for interop |
| 07:15 | <abarth> | othermaciej: possibly, i'm trying to reserve judgement until i see the whole picture, which I don't yet |
| 07:16 | <abarth> | ok, the absolute URL dataset is done |
| 07:16 | <abarth> | i'm going to relative URLs later |
| 07:16 | <zcorpan> | othermaciej: if a browser doesn't know the protocol, does it matter whether it removes the port or not? |
| 07:16 | <abarth> | they seem even more complicated |
| 07:16 | <abarth> | (ok, i don't have file URLs done either) |
| 07:16 | <othermaciej> | zcorpan: for purposes of the API on <a> elements, yes, though maybe that is minor enough to not care |
| 07:17 | <Hixie> | abarth: yeah ipv6 canon seems legit |
| 07:18 | <Hixie> | once you're supporting different protocols, you've already lost interop anyway |
| 07:19 | <abarth> | FF canonicalize('http://GoOgLe.CoM/';) is 'http://google.com/'; |
| 07:19 | <abarth> | IE canonicalize('http://GoOgLe.CoM/';) is 'http://google.com/'; |
| 07:19 | <abarth> | KR canonicalize('http://GoOgLe.CoM/';) is 'http://google.com/'; |
| 07:19 | <abarth> | SA canonicalize('http://GoOgLe.CoM/';) should be http://google.com/. Was http://GoOgLe.CoM/. |
| 07:20 | <Hixie> | ok time to go play bc2 |
| 07:20 | <othermaciej> | abarth: FYI I'm planning to make a variant of the file URL test I made that has an http base URL |
| 07:20 | <Hixie> | bbl |
| 07:20 | <othermaciej> | in fact, I think I will do that now |
| 07:20 | <abarth> | great :) |
| 07:20 | <abarth> | i'm putting off the file URL stuff until i understand the other cases |
| 07:20 | <othermaciej> | hmmm |
| 07:21 | <abarth> | it looks like Brett preferred the IE way in a lot of cases |
| 07:21 | <zcorpan> | abarth: would it be possible to test opera also? :) |
| 07:21 | <othermaciej> | I need to not make it a script test though to avoid getting the <base> that I put in the template pulled in |
| 07:21 | <abarth> | i removed the base URL from the template |
| 07:21 | <abarth> | it didn't work properly |
| 07:21 | <abarth> | as in, it broke the tests on windows |
| 07:22 | <abarth> | there's a utility method to set the base URL to whatever you like |
| 07:22 | <abarth> | trival.js has an example |
| 07:22 | <othermaciej> | abarth: that will probably mess up the file: test |
| 07:22 | <abarth> | zcorpan: sure |
| 07:22 | <othermaciej> | abarth: which other tests did it break on windows? |
| 07:22 | <othermaciej> | does windows not have the /tmp link? was pretty sure it did, cause other tests use it |
| 07:22 | <abarth> | zcorpan: i was trying to keep the data set managable to start with |
| 07:23 | <abarth> | i don;t think the URL you used is a valid file URL on windows |
| 07:23 | <abarth> | it didn't have a drive-spec |
| 07:23 | <abarth> | why would it mess up the file test to set it using the API? |
| 07:23 | <abarth> | it just adds a base tag like you did |
| 07:24 | <abarth> | the difference is it does it after loading the various script tests scripts |
| 07:24 | <othermaciej> | setting it using the API could work |
| 07:24 | <othermaciej> | but if it breaks on Windows with a <base> tag, it will break with an API |
| 07:24 | <othermaciej> | what I meant is that not setting the base URI at all will likely break |
| 07:25 | <abarth> | its an ordering thing |
| 07:25 | <othermaciej> | or not so much break as make the test results dependent on the user's system |
| 07:25 | <abarth> | you need to set the base tag after loadingin the scripts |
| 07:25 | <abarth> | because the scripts are loaded using relative URLs |
| 07:26 | <othermaciej> | I see |
| 07:26 | <othermaciej> | good point |
| 07:26 | <othermaciej> | though it may still throw off the results in browsers that consider a file URI invalid if it has no drive letter |
| 07:26 | <othermaciej> | or maybe they just consider it undereferancable, not syntactically invalid |
| 07:26 | <othermaciej> | that would be ok |
| 07:30 | <othermaciej> | abarth: ok, I made file-http-base.html but I am not sure the expected results I have will match google-url's behavior |
| 07:30 | <abarth> | this is another interesting case |
| 07:31 | <abarth> | (that's fine. the shouldBe results don't matter. we'll figure out what they should be later) |
| 07:31 | <abarth> | IE canonicalize('http://example.com/foo%41%7a';) is 'http://example.com/fooAz'; |
| 07:31 | <abarth> | KR canonicalize('http://example.com/foo%41%7a';) is 'http://example.com/fooAz'; |
| 07:31 | <abarth> | FF canonicalize('http://example.com/foo%41%7a';) should be http://example.com/fooAz. Was http://example.com/foo%41%7a. |
| 07:31 | <abarth> | SA canonicalize('http://example.com/foo%41%7a';) should be http://example.com/fooAz. Was http://example.com/foo%41%7a. |
| 07:31 | <abarth> | the question here is whether you URL decode things that don't need to be encoded |
| 07:31 | <othermaciej> | yeah |
| 07:31 | <othermaciej> | Brett really likes IE's URL parsing I guess :-) |
| 07:32 | <abarth> | IE likes to keep non-ASCII characters in URLs |
| 07:33 | <abarth> | brett seems to follow firefox + safari in making things more ascii more of the time |
| 07:33 | <abarth> | FF canonicalize('http://example.com/ä½ å¥½ä½ å¥½';) is 'http://example.com/%E4%BD%A0%E5%A5%BD%E4%BD%A0%E5%A5%BD'; |
| 07:33 | <abarth> | KR canonicalize('http://example.com/ä½ å¥½ä½ å¥½';) is 'http://example.com/%E4%BD%A0%E5%A5%BD%E4%BD%A0%E5%A5%BD'; |
| 07:33 | <abarth> | SA canonicalize('http://example.com/ä½ å¥½ä½ å¥½';) is 'http://example.com/%E4%BD%A0%E5%A5%BD%E4%BD%A0%E5%A5%BD'; |
| 07:33 | <abarth> | IE canonicalize('http://example.com/ä½ å¥½ä½ å¥½';) should be http://example.com/%E4%BD%A0%E5%A5%BD%E4%BD%A0%E5%A5%BD. Was http://example.com/ä½ å¥½ä½ å¥½. |
| 07:33 | <othermaciej> | I guess IE doesn't like things to be escaped |
| 07:34 | <abarth> | woah, firefox doesn't turn \ into / in paths |
| 07:34 | <abarth> | crazy |
| 07:34 | <abarth> | i'm surprised that works |
| 07:34 | <wirepair> | like http://example.com/blah\something.jsp ? |
| 07:35 | <abarth> | yeah |
| 07:35 | <abarth> | non-FF makes that |
| 07:35 | <abarth> | http://example.com/blah/something.jsp |
| 07:35 | <abarth> | life is different in the query string |
| 07:35 | <wirepair> | yeah it converts it to %5c |
| 07:36 | <abarth> | in the query string apparently non-IE likes to keep more things encoded |
| 07:36 | <abarth> | but IE is aggressive at not encoding things |
| 07:36 | <wirepair> | yeah which is why it's a hotbed for xss |
| 07:36 | <wirepair> | ;> |
| 07:36 | <othermaciej> | abarth: did you port over the component parsing tests (other than user/pass) in addition to the canonicalization ones? |
| 07:36 | <abarth> | even to the point of keeping invalid unicode characters around |
| 07:37 | <wirepair> | invalid unicode == overlong utf-8 and such? |
| 07:37 | <abarth> | othermaciej: i'm not 100% clear what you're asking, but i think the answer is yet |
| 07:37 | <abarth> | sorry |
| 07:37 | <abarth> | yes |
| 07:37 | <abarth> | i'm using a.href for all of them |
| 07:37 | <othermaciej> | the ones that test what you get for scheme or path when given a particular URL |
| 07:38 | <abarth> | i haven't tried using the other APIs |
| 07:38 | <abarth> | oh |
| 07:38 | <abarth> | there are tests that give you a whole URL at then |
| 07:38 | <abarth> | see what the components are? |
| 07:38 | <abarth> | no, i haven't done those |
| 07:38 | <othermaciej> | well, I assume there are |
| 07:40 | <abarth> | http://code.google.com/p/google-url/source/browse/trunk/src/url_parse_unittest.cc |
| 07:40 | <abarth> | no, i haven't done the ones from that file yet |
| 07:41 | <abarth> | they look worthwhile too |
| 07:41 | <othermaciej> | ok maybe I will do those if I have time |
| 07:41 | <othermaciej> | gonna see if I can pick off a more important bug first |
| 07:42 | <abarth> | 'http://www.example.com/#\ud800\u597d'; |
| 07:42 | <abarth> | that URL gets a different result in every browser |
| 07:42 | <abarth> | i think the problem is that its invalid unicode |
| 07:43 | <abarth> | 'http://www.example.com/#a\uFDD0'; |
| 07:43 | <abarth> | that looks like a more reduced test for that case |
| 07:43 | <othermaciej> | abarth: reading that chromium-dev thread, I fear I will have to do my slideshow about CORS and Confused Deputy vulnerabilities for google folk at some point |
| 07:44 | <othermaciej> | I wouldn't want Chromium to be deciding on security features based on "Maciej said so" |
| 07:44 | <abarth> | to some extent, they rely on my for that kind of stuff, but i'm kind of pulling the rug out from under them by try to not be involved |
| 07:44 | <othermaciej> | at the very least it should be based on "Adam said so" |
| 07:45 | <abarth> | well, ifette is also a good person to be involved in the decision process |
| 07:45 | <aboodman> | we really only make decisions because aboodman said so, but since that list is public, we try to put on a nice show. |
| 07:45 | <abarth> | hahaha :) |
| 07:46 | <aboodman> | g'nite troops |
| 07:46 | <othermaciej> | abarth: you should give your advice, even if you don't want to be the decider, IMO |
| 07:48 | <abarth> | it seems like a no-win situation |
| 07:48 | <abarth> | i'm not even really sure what that thread is about |
| 07:48 | <othermaciej> | you're the one who started it! |
| 07:49 | <abarth> | oh, on chromium-dev? |
| 07:49 | <othermaciej> | yeah |
| 07:49 | <abarth> | yeah, ok |
| 07:50 | <abarth> | that sounds like a good email for tomorrow morning :) |
| 07:52 | <abarth> | Safari encodes the second # in the fragment, which doesn't match IE/FF/KR |
| 07:52 | <abarth> | that sounds like an easy fix |
| 07:53 | <abarth> | also, Safari doesn't lower-case schemes, unlike IE/FF/KR |
| 07:56 | <othermaciej> | abarth: I am glad you are working on this and doing it to your usual ridiculously thorough standards |
| 07:56 | <abarth> | its actually not nearly as complicated as I thought it would be, at least for non-file, non-relative URLs |
| 07:56 | <abarth> | there seems to be <6 decisiosn |
| 07:57 | <abarth> | i need to look it over again when I'm less tired |
| 07:57 | <abarth> | but i'll write it up and ask brett and others why they chose what they did |
| 07:57 | <abarth> | i'm happy to do this stuff |
| 07:57 | <abarth> | i think its more important than anding random feature XYZ |
| 07:58 | <abarth> | but i understand that it doesn't generated good press articles :) |
| 07:59 | <abarth> | anyway, me => bed |
| 07:59 | <abarth> | thanks for your help writing the tests |
| 08:43 | <foolip> | Hixie: mutually exclusive subtitles: this is the way virtually all software and hardware media players work. it seems useful to be able to mark up that certain tracks are mutually exclusive (<tracktrack>) so that the UI can create a sane menu. |
| 08:44 | <hsivonen> | having multiple subtitle tracks present at one time seems to be on the wrong side of 80/20 |
| 08:44 | <foolip> | the other options are to make all tracks mutually exlcusive or all tracks "parallel", both of which are broken |
| 08:44 | <hsivonen> | if you want to make English subtitles plus Japanese subtitles for language learners for anime, you can package them into one track |
| 08:45 | <foolip> | hsivonen: I agree, but others (nessy) insisted, and I think the current solution is fairly non-intrusive |
| 08:45 | <hsivonen> | FWIW, in movie theaters in Finland, there are subtitles in Finnish and in Swedish, but they aren't independent tracks |
| 08:45 | <hsivonen> | specifically, the Swedish subtitles aren't bought from Sweden |
| 08:45 | asmodai | wonders what it is that keeps leaking memory in FF. |
| 08:45 | <nessy> | hsivonen: you will not want to package two different languages in one file if you can avoid it |
| 08:45 | <foolip> | the most compelling argument (to me) is that if <track> is also used for e.g. extra audio tracks, clearly subtitles and the extra audio track aren't mutually exclusive |
| 08:46 | <hsivonen> | nessy: I think you do |
| 08:46 | <nessy> | then you cannot turn one off |
| 08:46 | <foolip> | hi nessy |
| 08:46 | <hsivonen> | nessy: for the same reason Swedish subtitles in Finnish movie theaters aren't independent of the Finnish subtitles |
| 08:46 | <hsivonen> | nessy: the traslator to Finnish chooses the timing |
| 08:46 | <nessy> | hi foolip :) |
| 08:47 | <hsivonen> | and then the translator to Swedish uses that timing |
| 08:47 | <hsivonen> | so the Finnish and Swedish subtitles always change at the same time |
| 08:47 | <hsivonen> | because having them change at different times would be annoying |
| 08:47 | <nessy> | so you cannot reuse the subtitles in Finnish or Swedish separately? |
| 08:48 | <hsivonen> | nessy: but the Web is different from movie theaters in the sense that the Web experience is personal |
| 08:48 | <nessy> | I think you can very well create them in different files but synchronised |
| 08:48 | <nessy> | do you know whether in the production process they are actually in the same file and not just rendered on together? |
| 08:48 | <foolip> | I'd say that if parallel tracks don't impose too much complexity (in API, markup, code or UI) then it's a good feature |
| 08:48 | <hsivonen> | nessy: what's the use case on the Web except language learning? |
| 08:48 | <hsivonen> | IMO, language learning is way on the wrong side of 80/20 |
| 08:48 | <hsivonen> | esp. since there's a workaround |
| 08:49 | <foolip> | current downside: it makes <trackgroup> mandatory boilerplate in most cases |
| 08:49 | <hsivonen> | multiple tracks means you need to stack them in layout... |
| 08:49 | <zcorpan> | hsivonen: use case: watching a movie with a friend who doesn't know swedish |
| 08:49 | <nessy> | chapter markers and subtitles and textual audio descriptions on together would be one need for multiple tracks active at the same time |
| 08:50 | <nessy> | plus you saw the examples that Hixie cumulated together with multiple subtitles on at the same time |
| 08:50 | <hsivonen> | zcorpan: I suppose the Web experience can become unpersonal once movie rentals and TV move to the browser |
| 08:51 | <hsivonen> | nessy: the examples I saw suggested they were for learning Japanese |
| 08:51 | <nessy> | I am not a big fan of having tracks of the same type on at the same time, but we definitely need it for different types |
| 08:51 | <hsivonen> | are there new examples? |
| 08:51 | <zcorpan> | hsivonen: yeah, i'd expect Voddler-like apps to appear as web apps |
| 08:51 | <othermaciej> | if <track> was used for audio descriptions as well as subtitles, then you would want those to come from a separate mutually exclusive list |
| 08:51 | <foolip> | indeed |
| 08:51 | hsivonen | notes that Finnish TV broadcasts don't support Finnish and Swedish subtitles simultaneously |
| 08:51 | <nessy> | that was my original design |
| 08:52 | zcorpan | doesn't know if Voddler supports multiple subtitles or indeed subtitles at all |
| 08:52 | <nessy> | shot down by reality I was told :) |
| 08:53 | nessy | goes checking out voddler |
| 08:53 | <hsivonen> | zcorpan: it would be an interesting market enabler if the Swedish audience had so good English listening comprehension that they could optimize subtitles away |
| 08:53 | <nessy> | bah, not available in my country |
| 08:54 | <foolip> | lol, region coded internets suck |
| 08:54 | <zcorpan> | hsivonen: personally i prefer english captions but most other people i know prefer swedish subtitles |
| 08:55 | <hsivonen> | zcorpan: why English captions? |
| 08:55 | <foolip> | I have the same preference as zcorpan, especially if the spoken language is English |
| 08:55 | <hsivonen> | interesting |
| 08:55 | <foolip> | and usually otherwise too, because the translation tends to be better |
| 08:56 | <hsivonen> | If the spoken language is English and I'm watching a movie alone, I turn subtitles off |
| 08:56 | <zcorpan> | hsivonen: it's easier to follow what they say compared to no captions, and it's easier to mentally listen and read in english compared to listen in english and read in swedish |
| 08:56 | <hsivonen> | if I'm watching with other people, they want the Finnish subtitles anyway |
| 08:57 | <hsivonen> | or the other people opt to have no subtitles, too |
| 08:58 | hsivonen | wonders what's the current situation with the Voddler GPL violation story is |
| 08:59 | <hsivonen> | http://en.wikipedia.org/wiki/Voddler#Source_Code_Copyright_Violation_by_Voddler wikipedia to rescue |
| 09:07 | <asmodai> | Any suggestions for testing memory leaks in FF? Or should I just use binary search on the addons/plugins? |
| 09:13 | <hsivonen> | asmodai: have you already verified that the leak isn't present when all addons and plug-ins are disabled? |
| 09:26 | <Hixie> | foolip: why wouldn't the UI just let you pick one subtitle or caption track, and leave it at that? |
| 09:26 | <Hixie> | foolip: while still letting the JS enable/disable whatever it wants? |
| 09:27 | <Hixie> | hsivonen: supporting multiple tracks visible at once is basically free once you support multiple cues not overlapping |
| 09:27 | <hsivonen> | Hixie: even in terms of layout stacking? |
| 09:29 | <Dashiva> | One thing I didn't see in the timed tracks examples was vertical text |
| 09:30 | <Hixie> | hsivonen: that's what i mean, once you have cues not stacking each other, making subtitles not stack each other is basically free |
| 09:30 | <Hixie> | hsivonen: is there anything else that would be non-trivial? |
| 09:30 | <Hixie> | Dashiva: one of the first examples has some vertical text |
| 09:31 | <Dashiva> | Oh, must've missed it |
| 09:31 | <Dashiva> | Wait, that isn't vertical text |
| 09:31 | <Dashiva> | That's rotated text |
| 09:31 | <Dashiva> | It's flipped 90 degrees |
| 09:31 | <Hixie> | oh, so it is |
| 09:32 | <Hixie> | i hadn't even noticed |
| 09:32 | <Hixie> | anyway i'm treating it as vertical |
| 09:32 | <Hixie> | for the purposes of this exercise |
| 09:32 | <Hixie> | :-) |
| 09:32 | <Dashiva> | kk |
| 09:32 | <Hixie> | and not supporting rotated text :-P |
| 09:32 | <Dashiva> | I think we can live without rotated text |
| 09:32 | <Hixie> | which isn't really a particularly good use of the evidence :-P |
| 09:32 | <Hixie> | if you have any other examples, please do put them up |
| 09:32 | <Hixie> | vertical ones in particular |
| 09:33 | <Hixie> | otherwise i will basically just have to go on my rather faulty knowledge of vertical text layout |
| 09:34 | <Hixie> | i gotta say, the thing that most surprises me in all my standards work is how hard it is to get people to provide use case examples |
| 09:34 | <Dashiva> | Here's one where the subtitles bounce in tune with the music... let's ignore that |
| 09:35 | <Hixie> | from people not understanding what that means, to not understanding why we would want to even look at real-world examples rather than just base it on theory, to not believing that use case examples actually affect design... |
| 09:36 | <Hixie> | many people have expressed the belief that when i ask them for use cases i'm just trying to dismiss them and that they are the only people from whom i ask for use cases |
| 09:36 | <Hixie> | it's so crazy |
| 09:36 | <hsivonen> | Hixie: I think I'm not sure if I understood what it means to support multiple cues not overlapping |
| 09:36 | <foolip> | Hixie: I don't think a content manu UI for enabling multiple tracks would be very nice, so from a laziness point of view I could live with letting the native UI only enable one track, implicitly disabling all other. |
| 09:37 | <foolip> | context menu |
| 09:37 | <Hixie> | hsivonen: http://www.youtube.com/watch?v=xG9KluukpJI#t=2m40 |
| 09:37 | <Hixie> | foolip: yeah i wouldn't want the native menu to enable multiple tracks |
| 09:37 | <foolip> | if <track> is only for text I could accept this |
| 09:38 | <hsivonen> | Hixie: looks like a totally gratuitous "just because we can" effect that in *waaayy* on the wrong side of 80/20 |
| 09:38 | <foolip> | if we take <track> for e.g. commentators tracks seriously, then it's not so good |
| 09:38 | <foolip> | I don't feel strongly about this issue either way |
| 09:38 | <hsivonen> | Hixie: are you assuming the reuse of the line layout code of the CSS formatter? |
| 09:38 | <Hixie> | hsivonen: multiple cues with overlapping times are not that rare |
| 09:38 | <foolip> | nessy: thoughts? |
| 09:39 | nessy | is reading email - have wasted a day in town today :( |
| 09:39 | <Hixie> | foolip: i think if we ever do multiple media resources in sync, the way to do it is to reuse <video>/<audio> and have them linked at that level |
| 09:39 | <Hixie> | foolip: i don't think we'd use <track> for that |
| 09:39 | <foolip> | Hixie: I would agree that that's cleaner |
| 09:39 | <Dashiva> | http://dashiva.net/misc/vertical_karaoke.jpg |
| 09:40 | hsivonen | didn't know YouTube supported times in the fragment id |
| 09:40 | <Hixie> | hsivonen: if you mean inline box and line box layout, then yes, at least in UAs that want to do CSS-based styling of cues |
| 09:40 | <foolip> | <track> is still not a great name for an element though (the only upside is that I first suggested it) |
| 09:40 | <Hixie> | foolip: what's a better name? |
| 09:40 | <Hixie> | Dashiva: sweet lord man |
| 09:40 | <foolip> | I have no better name, I suggested the best I could think of :) |
| 09:41 | <Creap> | probably the wrong channel to ask in.. but you know how to read specs :P ARIA spec says default value of aria-haspopup is false, does that mean that <li aria-haspopup> is the same as <li aria-haspopup="false">? |
| 09:41 | <Hixie> | <track> it is :-P |
| 09:41 | <foolip> | others have been <itext> and something else |
| 09:41 | <Dashiva> | This is the full madness karaoke form, with animated fade in and fade out of characters |
| 09:41 | <Hixie> | Dashiva: addressing the actual "current" span is something i haven't worked out how to do |
| 09:42 | <Hixie> | Dashiva: and positioning the subtitles that precisiely is non-trivial |
| 09:42 | <Hixie> | well it's very trivial if we do it pixel-based, but that's not an especially good idea for various reasons |
| 09:42 | <Hixie> | Dashiva: other than that i think we can do that |
| 09:42 | <Dashiva> | Well, most of this probably falls on the wrong side of 80/20, so it's no big crisis |
| 09:43 | <Hixie> | Dashiva: assuming we go down the kind of route i'm thinking of |
| 09:43 | <Hixie> | Dashiva: yeah |
| 09:43 | <Dashiva> | http://dashiva.net/misc/bouncing_karaoke.jpg |
| 09:43 | <foolip> | it would be quite acceptible to leve the most crazy styling/animations to JavaScript |
| 09:43 | <Hixie> | i really need to figure out positioning, that's the main thing i'm spinning on |
| 09:45 | <nessy> | re: multiple cues with overlapping times - that is actually really common on captions that position the spoken text close to the speaker - they leave the old text at the other speaker around for a bit so ppl can catch up on it |
| 09:45 | <nessy> | it's a really useful feature and doesn't cost us much, I think |
| 09:45 | <Hixie> | would be good to find some examples of that on youtube or something so i could study them "in action" as it were |
| 09:45 | <Dashiva> | Not to mention when multiple people speaking simultaneously |
| 09:46 | <Hixie> | right now i just have that one example |
| 09:46 | <Hixie> | right, i'm off |
| 09:46 | <Hixie> | later |
| 09:47 | <Dashiva> | http://dashiva.net/misc/multiple_speakers.jpg |
| 09:47 | hsivonen | wonders if the people tagging http://labs.opera.com/news/2010/04/22/ as "iphone" on Delicious know the difference between Opera Mini and Opera Mobile |
| 09:48 | <Dashiva> | Um, already examples for that, so no need I guess |
| 09:50 | <foolip> | SRT files often have overlapping times by mistake, because most (all?) player fix it during parsing |
| 09:50 | <nessy> | also about having multiple media resources in sync: I think you need both - (1) the dependent ones like audio descriptions whose timeline is totally dependent on the main timeline - they would go into <track> - (2) the compositions of multiple media resources that may build a multimedia experience of sorts - they would be linked on the full <audio>/<video> level |
| 09:51 | <nessy> | foolip: players don't "fix" it - they just remove the old element when the new one appears |
| 09:51 | <foolip> | nessy: internally syncing them is the same think regardless of the syntax, so I think it's mostly a question of picking a syntax which makes sense |
| 09:51 | <nessy> | with srt that's the only thing you can do because they would be rendered in the same place |
| 09:52 | <asmodai> | hsivonen: Was going to try that now. |
| 09:52 | <foolip> | nessy: in any event the overlapping is concealed, so SRT files have overlap which wasn't intended as such by the author |
| 09:53 | <nessy> | the internal mechanism is only the same for some of it - e.g. if a dependent media resource is longer its overlength will never be played - if a synchronised media resource is longer, it will continue playing |
| 10:00 | <asmodai> | hsivonen: seems to grow with all addons and plugins disabled as well. But lets see, 336 MB now. Will see what it uses after a few minutes of not touching. |
| 10:01 | <foolip> | nessy: true |
| 10:17 | <asmodai> | hsivonen: doing nothing, now 466 MB and growing |
| 10:18 | <hsivonen> | asmodai: I suggest filing a bug |
| 10:23 | <asmodai> | hsivonen: Yeah, just have my developer instincts taking over trying to nail it down. Managed to with the XHTML Ruby addon. :) |
| 11:40 | <Dashiva> | And people still misunderstand the problem with hidden metadata... |
| 11:48 | <Lachy> | Dashiva, it just seems that some people are incapable of understanding when it's appropriate for specific metadata to be hidden, and when it's more optimal for the metadata to be based on visible content. |
| 11:52 | <Dashiva> | And the discussion about <p /> vs <p></p> seems to ignore the fact that empty <p> is non-conforming... |
| 12:01 | <remysharp> | Re: canvas 2d api - toDataURL and the second optional argument, compression level - between 0.0 and 1. Is 1 highest compression or 1 being biggest sized file? |
| 12:03 | <gsnedders> | It's only supported for image/jpeg |
| 12:03 | <gsnedders> | And 1 is the highest quality, and hence biggest file |
| 12:03 | <Philip`> | "The second argument, if it is a number in the range 0.0 to 1.0 inclusive, must be treated as the desired quality level." |
| 12:03 | <Philip`> | I interpret 'quality level' as being exactly opposite to 'compression level' |
| 12:04 | <Philip`> | and that's how it's implemented - see http://philip.html5.org/tests/canvas/suite/tests/toDataURL.jpeg.quality.basic.html |
| 12:04 | <Philip`> | Uh, s/that's/what gsnedders said is/ |
| 12:05 | <Dashiva> | It's a somewhat silly parameter, most users will have no idea what to put there |
| 12:05 | <Philip`> | Most users won't put anything there |
| 12:05 | <Philip`> | Surely most web developers have used a paint program that exports JPEG and has a quality slider, though? |
| 12:06 | <Dashiva> | Sure, but those programs don't explain the slider any better |
| 12:06 | <Philip`> | so they'll know that e.g. 70% (0.7) is typically okay |
| 12:06 | <Philip`> | Those programs dynamically display the result of the chosen compression quality |
| 12:07 | <Dashiva> | That sounds like a small subset of paint programs |
| 12:07 | <jgraham> | I guess photoshop does |
| 12:07 | <Philip`> | It's all the one I've used |
| 12:07 | <Philip`> | *ones |
| 12:07 | <jgraham> | The GIMP does |
| 12:07 | <jgraham> | s/guess/am pretty sure that/ |
| 12:08 | <Philip`> | Paint Shop Pro does, since many years ago when I last used it |
| 12:08 | <jgraham> | I think lightroom doesn't but I haven't looked that hard because I know the defaults are fine |
| 12:09 | Philip` | wonders why Opera thinks quality 0.0 should give a larger file than quality 0.1 |
| 12:09 | <jgraham> | Philip`: Does it give the same as quality 1.0? |
| 12:10 | <jgraham> | or no quality parameter, I guess |
| 12:10 | <remysharp> | out of interest, does the quality actually affect the size of the base64 data. I'm assuming it does, but I don't know much about the encoding techniques |
| 12:12 | <Philip`> | jgraham: No |
| 12:12 | <Philip`> | See e.g. http://philip.html5.org/tests/canvas/suite/tests/toDataURL.jpeg.quality.outsiderange.html and modify the last test |
| 12:13 | <Philip`> | (assuming the behaviour hasn't changed since the Opera I'm using) |
| 12:13 | <Philip`> | (which looks like 10.10) |
| 12:14 | <Philip`> | remysharp: Yes - base64 just does 4 bytes of output for each 3 bytes of input |
| 12:14 | <Philip`> | so if the input changes by 3 or more bytes then the output will definitely change length |
| 12:14 | <remysharp> | okay, cheers. |
| 12:15 | <remysharp> | ta for that all :) |
| 13:34 | Dashiva | wonders what kind of nut they had to use to fit perl in a nutshell. Coconuts? |
| 13:47 | <remysharp> | in need of canvas sanity check if someone is willing? |
| 13:48 | <remysharp> | I've got this simple example - and logging to the console (firebug, whatever) the length of pixel data - but I'm getting undefined: http://introducinghtml5.com/examples/ch05/getimagedata.html |
| 13:48 | <remysharp> | :-\ |
| 13:48 | <Philip`> | remysharp: You want pixels.data.length |
| 13:48 | <remysharp> | I've been looking at this too much and now just confused myself, because I had this kind of simple example working before - any help would be greatly appreciated! |
| 13:48 | <Philip`> | not pixels.length |
| 13:48 | <remysharp> | Philip` thank you! |
| 13:48 | <remysharp> | see - me => going mad |
| 13:49 | <remysharp> | out of interest, when I run this offline - i.e. using file:/// I get a security error in firefox and chrome - should that be happening? |
| 13:50 | <asmodai> | So has this EU cookie issue been discussed in the whatwg yet? |
| 13:50 | <remysharp> | I know if I'm going across origins then it'll throw a security error, but I thought whilst offline the security model was different |
| 13:50 | <remysharp> | i.e. loose |
| 13:53 | <Philip`> | remysharp: With file:/// the security model is tighter in lots of ways |
| 13:53 | <Philip`> | so that you can't trick a user into downloading an HTML file to their desktop when then steals all their private data |
| 13:53 | <remysharp> | that makes sense |
| 13:54 | <Philip`> | s/when/which/ |
| 13:54 | <remysharp> | I'm sure I had an example that was drawing images in to a canvas from a live domain (where my file was offline) but it was still able to call getImageData |
| 13:54 | <remysharp> | so I could do image manipulation offline |
| 13:54 | <remysharp> | in fact I've got a screencast of the demo - but it doesn't seem to work now - not sure if it's me, or if browsers have been updated in the last 4 monts |
| 13:54 | <remysharp> | *months |
| 13:55 | <remysharp> | perhaps they fixed it flagging as a security bug as you've suggested. |
| 13:58 | <Philip`> | remysharp: Accessing files from an http: location that's not the same origin as your script, and accessing ones from file: while you script is also on file:, sound like quite different security risks |
| 13:58 | <Philip`> | but they both sound like things that shouldn't be permitted |
| 13:59 | Philip` | has no idea what browsers' file: security models are like |
| 13:59 | <remysharp> | indeed - you're right, they don't sound like they're possible. Good chance I just caught it whilst they were figuring out the model. |
| 13:59 | <remysharp> | cheers for letting me bounce ideas. |
| 14:02 | <akahn> | Philip`: there was just a webkit issue about this recently |
| 14:02 | <akahn> | let me see if i can find it |
| 14:03 | <akahn> | my mistake, a chromium issue: http://code.google.com/p/chromium/issues/detail?id=37586 |
| 14:41 | <zcorpan> | hmm, http://www.boingboing.net/2010/04/22/evil-witch-from-snow.html results in a page with nothing but an ad in opera and firefox with html5.enable, and nothing but the ad twice without html5.enable |
| 14:42 | <zcorpan> | with html5.enable it never stops loading |
| 14:42 | <zcorpan> | chrome loads as was intended |
| 14:46 | <doublec> | loads fine in firefox trunk |
| 14:50 | <hsivonen> | zcorpan: how up-to-date is your build? |
| 14:50 | <hsivonen> | zcorpan: wfm regardless of the pref in a build I made this week with some local patches |
| 14:52 | <hsivonen> | zcorpan: also wfm regardless of whether I have "Firefox" or "Minefield" in the UA string |
| 14:53 | <hsivonen> | zcorpan: broken in Opera for me, too |
| 14:53 | <zcorpan> | hsivonen: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a5pre) Gecko/20100417 Minefield/3.7a5pre |
| 14:54 | <hsivonen> | zcorpan: wfm with that UA string, too |
| 14:55 | <Dashiva> | View source doesn't work, DOM only has a single ifram element |
| 14:55 | <Dashiva> | *iframe |
| 14:55 | <zcorpan> | hsivonen: with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a5pre) Gecko/20100423 Minefield/3.7a5pre i get two ads with html5.enable also |
| 14:55 | <Lachy> | zcorpan, works in Opera 10.10 for me. Fails in 10.50. |
| 14:56 | <Lachy> | zcorpan, check it in core, see where it regressed. I hope it's not a carakan bug |
| 14:58 | <gsnedders> | Lachy: Just because you were Carakan QA? :P |
| 14:58 | <gsnedders> | It's empty in 10.10 for me, having got zero bytes from the server |
| 15:00 | <hsivonen> | WFM in an actual Mac build, too |
| 15:02 | <hsivonen> | this polyglot spec isn't starting well |
| 15:03 | <jgraham> | hsivonen: In what way? |
| 15:03 | jgraham | isn't really following |
| 15:03 | <Lachy> | I don't get the point of the polyglot spec. It seems like it's just an authoring guide, and mine already covers much of that info |
| 15:03 | <hsivonen> | jgraham: in the way that it seems to repeat at least one superstition and in the way that bug reports about it have themselves been buggy |
| 15:03 | <Lachy> | anyway, I hope to find some time to get back to working on the authoring guide soon. It's been kind of left stagnant for far too long |
| 15:04 | <hsivonen> | s/bug reports/feedback on teh list/ |
| 15:05 | <jgraham> | Polyglotness is so hard that even experts get it wrong? Who knew? |
| 15:05 | <hsivonen> | also, I can find terminology errors in Leif's and Lachy's emails in that thread |
| 15:06 | <Lachy> | my e-mails in which thread? |
| 15:06 | <hsivonen> | Lachy: "then you should include the BOM indicating UTF-16LE" |
| 15:07 | <hsivonen> | UTF-16LE is BOMless |
| 15:07 | <hsivonen> | the BOM indicates little-endian UTF-16 |
| 15:07 | <gsnedders> | A leading U+FEFF is a ZWNBSP |
| 15:07 | <gsnedders> | (in UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE, etc.) |
| 15:07 | <hsivonen> | right |
| 15:08 | <gsnedders> | (it only isn't in UTF-8 because the spec specifically allows it, but assigns no meaning to it) |
| 15:08 | <Lachy> | I was using that as shorthand for indicating little-endian or big-endian, as indiciated by the BOM |
| 15:08 | <jgraham> | On the other hand Sam had just claimed that serving HTML as UTF-16 was non-conformant |
| 15:08 | <hsivonen> | Lachy: I know. I'm nitpicking |
| 15:08 | <jgraham> | And he's chair of the freaking working group |
| 15:08 | <gsnedders> | I didn't think he did that |
| 15:09 | <gsnedders> | I took it to mean that HTML processors aren't required to support UTF-16, unlike XML |
| 15:09 | <Dashiva> | I wouldn't mind if UTF-16 was non-conforming :) |
| 15:09 | <jgraham> | "UTF-16 is not valid for HTML5" |
| 15:09 | <jgraham> | I don't really know how to interpret that other than "not valid" |
| 15:10 | <jgraham> | If he meant "not required to be supported" then he should have said so |
| 15:10 | <gsnedders> | Try not literally interpreting anything. It might help with communication. |
| 15:10 | <Lachy> | Dashiva, there's nothing inherently wrong with UTF-16. But it's more useful if your document contains a significant proportion of characters that would be represented as 3 or 4 octets in UTF-8, compared with just 2 in UTF-16 |
| 15:11 | <jgraham> | Although the fact that UTF-16 is not required is basically a cop-out by the spec |
| 15:11 | <jgraham> | Lachy: That's much less common than you would think |
| 15:11 | <Philip`> | gsnedders: Communication works better when you ignore what somebody actually said and pretend they said something totally different? |
| 15:11 | <Dashiva> | Lachy: Is it really? Even after applying gzip compression and such? And how many documents are affected? |
| 15:12 | <gsnedders> | Philip`: Totally. |
| 15:12 | <Philip`> | gsnedders: I'm glad you agree it's a bad idea |
| 15:12 | <zcorpan> | jgraham: maybe sam meant that UTF-16 isn't valid in <meta charset> |
| 15:12 | jgraham | remembers some study that looked at Japanese wikipedia and concluded that UTF-8 vs UTF-16 didn't make much difference |
| 15:12 | <Dashiva> | It comes with downsides too, such as not being ascii-compatible, having both BE and LE variants + BOM variants of each, and trouble with surrogates (if it's not actually UCS2 in disguise, that is) |
| 15:13 | <Philip`> | Lachy: HTML documents are largely markup and URLs, which is all ASCII, so you need an extremely high density of raw text to make up for it |
| 15:13 | <Philip`> | (Also they're a lot of whitespace indentation and word-spacing, which is also ASCII) |
| 15:14 | <jgraham> | zcorpan: Possibly. Who knows? It wasn't what he said though. |
| 15:15 | <Lachy> | jgraham, I expect it would be more common with asian language documents that contain a large amount of text, with comparitively little markup. |
| 15:15 | <Lachy> | I know that may not be common overall |
| 15:16 | <jgraham> | Lachy: It might make sense for the Japanese equivalent of Moby Dick on project Gutenberg |
| 15:16 | <jgraham> | It is something of an edge case on the web though |
| 15:17 | <Philip`> | I thought Project Gutenberg was text/plain |
| 15:17 | <jgraham> | http://www.gutenberg.org/files/2701/2701-h/2701-h.htm |
| 15:17 | <jgraham> | Not necessarily |
| 15:18 | <Dashiva> | Well, plain text would be even better fodder for compression, wouldn't it? |
| 15:19 | <Philip`> | Yes, but that's irrelevant to what is allowed in HTML |
| 15:21 | <Lachy> | has anyone seen any stats on how common UTF-16 usage is on the web? |
| 15:22 | <Lachy> | http://trends.builtwith.com/encoding/UTF-16-UCS-2 |
| 15:23 | <Lachy> | not sure how representative that is of the web in general. I suspect it was biased by a significant number of western lanagues, which are predominately the latin alphabet. |
| 15:24 | <Lachy> | would probably be more interesting to limit the sample to langauges where using UTF-16 is potentially useful |
| 15:28 | <Philip`> | Lachy: http://philip.html5.org/data/charsets.html#charset-utf-16 are the only ones I saw in a sample that's largely Western but still has thousands of .jp/.cn/etc pages |
| 15:31 | <Lachy> | ok, so it's usage is negligable. |
| 15:33 | <jgraham> | Hmm. I just tried comparing the UTF-8 and UTF-16 encoded size of some japanese wikipedia articles and it seemed that utf-8 was smaller overall, but I suspect I did something wrong |
| 15:34 | <Dashiva> | Wikipedia has massive amounts of hidden markup, to be fair |
| 15:34 | <jgraham> | Is that atypical? |
| 15:35 | <Dashiva> | I would think so |
| 15:35 | <Dashiva> | Huge amounts of links, all of which are percent-encoded. Quite large head with inline <script> and such. |
| 15:39 | <jgraham> | http://event.rakuten.co.jp/borderless/index.html seems similar |
| 15:39 | <Lachy> | I got the same result with the jp Main_Page equivalent, and some other random article |
| 15:39 | <Lachy> | I then gzipped the results, and the UTF-8 still ended up smaller |
| 15:39 | <jgraham> | (in that case utf8 seems close to euc-jp which is the encoding the site uses) |
| 15:40 | <Lachy> | oh, I assumed the file I got from wikipedia was UTF-8. |
| 15:41 | <Dashiva> | Isn't it? |
| 15:41 | <Dashiva> | That's what I get, at least |
| 15:41 | <Lachy> | indeed, it is UTF-8. I don't know where you found a page using euc-jp |
| 15:42 | <Dashiva> | jgraham's link is euc-jp |
| 15:42 | <Lachy> | ah, I see. jgraham wasn't talking about wikipedia being euc-jp |
| 15:53 | <hsivonen> | the claim that UTF-16 is more compact for Japanese Web pages is a myth |
| 15:54 | <hsivonen> | real Web pages have markup, inline scripts, whitespace, inline style, etc. |
| 15:55 | <hsivonen> | jgraham: a couple of years ago, I measured wikipedia pages re-encoded in various ways |
| 15:55 | <hsivonen> | summary: gzipped UTF-8 is so good that everything else is pointless |
| 15:57 | <jgraham> | hsivonen: That would agree with my 5-minute "study" |
| 15:58 | <jgraham> | Did you compare with euc-js and similar? |
| 15:58 | <jgraham> | Did you write it up? |
| 16:06 | <hsivonen> | jgraham: http://lists.w3.org/Archives/Public/public-html-comments/2008Jan/0048.html and http://lists.w3.org/Archives/Public/public-html-comments/2008Jan/0076.html |
| 16:10 | <jgraham> | hsivonen: I think it would be great to blog any numbers that you have left over from that study |
| 16:15 | <Dashiva> | Perhaps if we talk about it enough, Philip` will make a service that takes a URL and outputs how big the page would be with different encodings and transfer options |
| 16:16 | <Philip`> | Surely you can do that with a single line of shell code |
| 16:16 | <Philip`> | using curl and iconv and gzip and wc and some loops |
| 16:22 | <Dashiva> | Philip`: Pretend this line is reverse psychology tricking you into making it to prove it's really possible in one line |
| 16:31 | <Philip`> | wget http://www.gutenberg.org/files/31757/31757-h/31757-h.htm; perl -e'for$c(qw(utf-8 utf-16be utf-16le utf-32 euc-jp shift-jis)){for$g(" ","|gzip -c"){print "$c$g ".`iconv -c 31757-h.htm -f utf-8 -t $c$g|wc -c`}}' |
| 16:33 | <Dashiva> | Accepted |
| 16:35 | <Philip`> | Interestingly the results are far tighter (and better) if you use bzip2 |
| 16:35 | <Dashiva> | Is the default gzip compression level a reasonable assumption? |
| 16:38 | <Philip`> | Yes |
| 16:38 | <Philip`> | Don't know if it's a correct assumption, though |
| 16:38 | <Philip`> | Strangely, xz (LZMA) is slightly worse than bzip2 here |
| 16:42 | <Dashiva> | Not much difference with maximum compression on gzip anyhow |
| 16:44 | <Philip`> | You can save ~7% over gzip -9 by using 7z's gzip implementation |
| 16:46 | <Philip`> | (...though you wouldn't do that dynamically on a web server because it's way too slow) |
| 16:47 | <Philip`> | (but it's good whenever you're precomputing compressed files) |
| 16:55 | <JonathanNeal> | Heyo! |
| 16:57 | <Dashiva> | Philip`: But it doesn't seem to change the relative ranking of the methods |
| 16:57 | <Dashiva> | That's the most important thing, I think |
| 17:06 | <Philip`> | Dashiva: The most important thing is the size of the output, since the author's goal is to minimise that |
| 17:06 | <Philip`> | and if using a better compression implementation gives you a larger percentage gain than changing the charset, it's probably better for people to focus on the former before worrying too much about the latter |
| 17:08 | <Dashiva> | Compression is a different trade-off, though, since it also requires resources to (de)compress |
| 17:08 | <Philip`> | I guess so |
| 17:08 | <Philip`> | It's more complex to changing the compression code and to make it cached so it goes fast etc |
| 17:09 | <Philip`> | so maybe it's better to do dumb stuff like recompress static files on every single request, and make easy changes like reencoding the static file |
| 17:10 | <Dashiva> | But of course, in the end it's the size in actual bytes that matters |
| 17:11 | <Philip`> | Most compression algorithms seem to be designed to maximise resource usage on compression and minimise on decompression |
| 17:12 | <Philip`> | (e.g. LZMA can happily use 1GB RAM to compress, and a tenth of that for decompression) |
| 17:13 | <Philip`> | which seems precisely the wrong way around when you're doing compression on a single centralised server, and decompression on a thousand fast unutilised desktop PCs simultaneously |
| 17:25 | <AryehGregor> | Philip`, the server can cache the compressed files. |
| 17:25 | <AryehGregor> | Assuming they're more or less static. |
| 22:21 | <Hixie> | Dashiva: http://dashiva.net/misc/multiple_speakers.jpg - did those cues appear simultaneously? |
| 22:21 | <Hixie> | Dashiva: or do they appear staggered? |
| 22:21 | <Dashiva> | They interleave |
| 22:21 | <Dashiva> | Each image has one conversation going at its own pace |
| 22:21 | <Hixie> | interesting |
| 22:22 | <Hixie> | i'd love to study that in more detail |
| 22:22 | <Hixie> | is it online anywhere? |
| 22:22 | <Dashiva> | http://www.youtube.com/watch?v=bw5JBWdaUHI |
| 22:24 | <Hixie> | awesome |
| 22:25 | <Hixie> | sweet lord |
| 22:26 | Hixie | gets to t=0m40s |
| 22:26 | <Hixie> | shoot me now |
| 22:26 | <Dashiva> | Yeah, I don't think we need to copy those effects |
| 22:27 | <Hixie> | interesting, http://www.youtube.com/watch?v=bw5JBWdaUHI#t=0m12s shows that the red subs are fixed to line -2, while the blue subs are fixed to line -1 |
| 22:28 | <Hixie> | they're not just stacking at the bottom first-come-first-served |
| 22:28 | <Hixie> | and percentage or pixel positioning isn't going to cut it for that |
| 22:28 | <Hixie> | we need line-based positioning |
| 22:29 | <Hixie> | excellent find, thanks Dashiva |
| 22:33 | <Dashiva> | (Another effect I'm not sure is needed is having subtitles resize and move to follow the original text being animated) |
| 22:33 | <AryehGregor> | Hixie, I believe the correct generalization here is "ignore the Japanese, they're insane". |
| 22:33 | <Hixie> | with perspective transforms to boot? :-) |
| 22:34 | <AryehGregor> | (see also: recent Unicode emoticon discussion) |
| 22:34 | <Hixie> | AryehGregor: hha |
| 22:34 | <Hixie> | hah even |
| 22:34 | <Dashiva> | Hmm, perhaps |
| 22:34 | <Hixie> | AryehGregor: we don't want to ignore them, we just want to take the needs of the anime subbing community with a pinch of salt :-) |
| 22:35 | <Dashiva> | Even within the community there's plenty of pushback against the more advanced stuff |
| 22:35 | <Hixie> | for the more advanced effects, i expect we'll just have people overlaying a canvas |
| 22:35 | <Hixie> | or svg |
| 22:36 | <Dashiva> | AryehGregor: But the bad news is you have similar things being produced in France and even USA now :P |
| 22:36 | <AryehGregor> | Dashiva, we can ignore more countries on an as-needed basis. |
| 22:42 | <Dashiva> | Maybe just ignore karaoke as a valid use case, you can do a lot with the tools needed for just regular text |
| 22:42 | <Philip`> | Hixie: Perspective transforms would be great - then we could have subtitles which replace the Star Wars opening crawls with equivalently rendered text in other languages |
| 22:42 | Dashiva | groans |
| 22:43 | <Hixie> | indeed |
| 22:57 | <AryehGregor> | "From the current state of the discussion, it seems like removing Atom conversion would draw the weakest objections." |
| 22:57 | <AryehGregor> | It seems like removing things always draws the weakest objections. Let's just put everything controversial in the WHATWG spec only so that W3C change proposals can't affect it. Is that what people want? |
| 22:57 | <Dashiva> | Yes, a few of them |
| 22:58 | <AryehGregor> | Proposing that something be removed doesn't make it go away. |
| 22:58 | <AryehGregor> | Well, a few people might want that, but not the people who try to get these things removed. |
| 22:58 | <TabAtkins> | Actually, no, that's what anyone wants. Some people want things removed from the WHATWG spec too. They just can't get that. |
| 22:58 | <AryehGregor> | Maybe they figure that even if they can't get it removed from the WHATWG spec, at least they can remove it from the W3C spec, and that will make people less likely to see it? |
| 22:59 | <AryehGregor> | Of course, the more this happens, the less useful the W3C spec becomes, and the more people will use the WHATWG spec. |
| 22:59 | <Dashiva> | You can also see it as a PR battle, creating division between W3C and WHATWG |
| 23:01 | <AryehGregor> | The W3C has a more positive reputation than the WHATWG, certainly. Much better known, too. |
| 23:02 | <Dashiva> | It's also likely that since the WHATWG copy exists, people have less incentive to fight to preserve the W3C copy |
| 23:02 | <AryehGregor> | That's true too. |
| 23:02 | <AryehGregor> | Fragmentation is often the easiest option, although rarely the best. |
| 23:03 | <AryehGregor> | See also microdata vs. RDFa. If we knew in advance that only one could exist, whichever one we had would probably be better than either of the two contenders now. |
| 23:03 | <AryehGregor> | But instead, everyone who likes one of them just ignores the other rather than trying to fix its deficiencies. |
| 23:05 | <Dashiva> | To be fair, RDFa seems to be absorbing some of the good ideas of microdata. It just doesn't seem as willing to part with the bad ideas. |
| 23:05 | <TabAtkins> | AryehGregor: Fwiw, I've done a relatively thorough and open review of RDFa 1.1. I think it's unfixable at this point, though. They just made some initial architectural mistakes and have dug themselves down far enough in an attempt to reduce their impact that you can't "fix" it without substantially rewriting it. |
| 23:06 | <TabAtkins> | The basic failure is not paying enough attention to the tree-based structure of XML, and relying on a notion of implicit subjects, rather than declaring subjects more explicitly. |
| 23:07 | <TabAtkins> | Then they made it worse by trying to be clever with the chaining concept. |
| 23:07 | <AryehGregor> | Bah, someone complained about this wording! http://www.w3.org/Bugs/Public/show_bug.cgi?id=7277 |
| 23:08 | <AryehGregor> | I appreciated that wording when I started reading the spec. |
| 23:08 | <TabAtkins> | The whole prefix/curie thing is pretty much a non-issue at this point. 1.1's @vocab and @profile attributes successfully hide the complexity in common cases. |
| 23:10 | <TabAtkins> | Basically, chapter 8 of RDFa1.1 speaks for itself about why the basic RDFa architecture is a mistake. |
| 23:11 | <TabAtkins> | It has like 60 examples, possibly more, walking through several things step-by-step because otherwise it's impossible to decipher. |
| 23:12 | <Hixie> | TabAtkins: complexity can't be hidden unless it's gone from the syntax altogether, because people have to maintain other people's code, and the other person might use the feature that's complicated |
| 23:13 | <TabAtkins> | True. It's at least lessened. Using @vocab *looks* like Microdata with @itemtype on simple cases. |
| 23:13 | <AryehGregor> | . . . of course, you could say the same about HTML. But I guess you'd say that there are few enough RDFa agents that we care about that we can break compatibility anyway. |
| 23:14 | <TabAtkins> | AryehGregor: Exactly. |
| 23:14 | <AryehGregor> | Or, more importantly, few enough RDFa pages. |
| 23:14 | <AryehGregor> | Since a few implementations can be changed pretty easily. |
| 23:15 | <TabAtkins> | Once I finish setting up my workflow, I might spend a few hours hacking our Rich Snippets support to ensure that it works with Microdata properly. |
| 23:15 | <Dashiva> | It seems to be some of the same people saying we can ignore deployed HTML5 content because it's not a standard yet who proclaim existing RDFa-in-HTML content must be supported |
| 23:15 | <TabAtkins> | Those people don't have a point, they're just inconsistent due to their agenda. |
| 23:16 | AryehGregor | tried to rewrite that to reverse the roles, but it didn't work |
| 23:16 | <TabAtkins> | AryehGregor: Yay! That's how you know it's true. |
| 23:16 | <Dashiva> | I'm sure you can reverse it |
| 23:16 | <Dashiva> | You just need to apply a secondary measure |
| 23:16 | <Dashiva> | E.g. we can't ignore [massively] deployed HTML5 content, but we can ignore [small amounts of] RDFa-in-HTML |
| 23:17 | <AryehGregor> | Well, we ignore deployed RDFa+HTML content because there's not a lot of it, but there's a lot of HTML content, so it seems consistent. I'd need to be more creative. |
| 23:17 | <TabAtkins> | Indeed, but if you apply that measure with the original statement, it becomes obviously ridiculous. |
| 23:17 | <Dashiva> | It seems obvious, but I'm not sure it's necessarily so |
| 23:17 | <Dashiva> | e.g. if you take the claims that blog software ships with it enabled by default, and doing something useful by default |
| 23:18 | <AryehGregor> | Most blog software also outputs HTML. |
| 23:18 | <Dashiva> | I personally don't think anyone would notice even if it was deployed by default, but I don't have the data to back it up |
| 23:19 | <AryehGregor> | I think WHATWG people tend to only really care about browsers (and maybe search engines and feed readers and such), while the specific technology is usually more or less of secondary interest. The RDFa people seem to be more invested in a particular technology than in a particular high-level goal. |
| 23:19 | <AryehGregor> | The same is true for lots of people who disagree with WHATWG people, actually. |
| 23:19 | <TabAtkins> | That technology is "namespaces", for RDFa. |
| 23:20 | <Dashiva> | And RDF ;) |
| 23:21 | <TabAtkins> | RDF's not necessarily a problem. You could parse RDFa data into JSON with roughly the same ease as you parse Microdata into RDF. |
| 23:21 | <AryehGregor> | Is there anything wrong with RDF, or just RDFa? |
| 23:21 | <othermaciej> | RDF as a data model |
| 23:21 | <TabAtkins> | RDF is just a rolled-out version of tree-based data. |
| 23:21 | <othermaciej> | ? |
| 23:21 | <TabAtkins> | With a focus on URIs. |
| 23:21 | <othermaciej> | RDF is not tree-based data, it is graph-based |
| 23:22 | <Dashiva> | Not necessarily wrong, but coming from a graph structure and designing for a tree is tricky |
| 23:22 | <Dashiva> | Graphs should be the exception, trees the norm |
| 23:23 | <Dashiva> | But if you come from a world where everything is graphs, it can be hard to adapt |
| 23:23 | <TabAtkins> | All trees are graphs, and they're more common in real data, so I still think my gloss is mostly accurate. |
| 23:23 | <erlehmann> | I like graphs. |
| 23:23 | <Dashiva> | TabAtkins: It's a graph in total, but each page usually only contains a tree-like subgraph |
| 23:23 | <TabAtkins> | Dashiva: Right, that's what I tried to say, but failed to do so clearly. |
| 23:24 | <TabAtkins> | Thanks for the clarification. ^_^ |
| 23:25 | <TabAtkins> | So anyway, that's why RDFa's essential architecture is wrong. It didn't take full advantage of the parallel between most data's tree-nature and HT/XML's tree-like nature. |
| 23:26 | <othermaciej> | TabAtkins: all trees are directed graphs, but not vice versa |
| 23:26 | <TabAtkins> | othermaciej: That's what I said, isn't it? |
| 23:26 | <othermaciej> | earlier you said "RDF is just a rolled-out version of tree-based data." |
| 23:26 | <othermaciej> | maybe I misinterpreted that statement |
| 23:27 | <TabAtkins> | Right, I left out some details that Dashiva corrected me on. |
| 23:27 | <TabAtkins> | In a hand-wavey way, I mean that the RDF structure of data embedded in pages is typically a tree, or at least very tree-like. |
| 23:27 | <othermaciej> | I agree that a lot of interesting data can be expressed well enough with a tree, rather than a general directed graph |
| 23:28 | <othermaciej> | I suspect a lot of RDFa at least points to common objects and so is likely at least a DAG |
| 23:28 | <Dashiva> | Yeah, I should have said DAG instead of tree. Even microdata is like that. |
| 23:29 | <TabAtkins> | Yeah. |
| 23:29 | <othermaciej> | Microdata is a DAG? |
| 23:29 | <Dashiva> | With itemref |
| 23:29 | <TabAtkins> | And, in a larger sense, with itemid. |
| 23:29 | <othermaciej> | itemref just clones some properties though |
| 23:30 | <othermaciej> | does the actual Microdata model retain a DAG structure? |
| 23:30 | <othermaciej> | are you pointing to the same conceptual object, or do you just happen to have properties with the same values? |
| 23:30 | <TabAtkins> | No, it serializes as a tree. |
| 23:30 | <TabAtkins> | But, if you lean on urls as values, it retains exactly as much DAGness as RDF would. |
| 23:33 | <Hixie> | RDF isn't natively a graph at all, it's a list of triples |
| 23:33 | <Hixie> | actually even that's not accurate |
| 23:33 | <Hixie> | it's a list of quads |
| 23:34 | <Hixie> | with some annotations |
| 23:34 | <Hixie> | but you can form a graph from that list |
| 23:34 | <TabAtkins> | The graphness comes from defining a form of url-equality, yeah. |
| 23:34 | <Hixie> | microdata is natively a tree, that you can flatten to a list of triples, from which you can also create a graph |
| 23:34 | <TabAtkins> | What's the quad? The object type? |
| 23:34 | <Hixie> | value type |
| 23:35 | <TabAtkins> | Right, yeah. |
| 23:35 | <Hixie> | and annotations are language of the value if it's a literal, and source of the triple |
| 23:35 | <Hixie> | also the literal can itself be structured XML |
| 23:37 | <othermaciej> | RDF serializations are a list of triples/quads/whatever |
| 23:37 | <othermaciej> | but RDF the data model is a graph |
| 23:39 | <TabAtkins> | Under your wording, othermaciej, Microdata's data model can indeed be a DAG, if you lean on url-equality to associate nodes as being the same (the same thing you have to do to make RDF a graph). |
| 23:40 | <Hixie> | right |
| 23:40 | <othermaciej> | but no cycles? |
| 23:40 | <Hixie> | microdata itself isn't but when you convert it to RDF you can get the same kind of graph with cycles |
| 23:40 | <Hixie> | the only thing you can't do cycles through in microdata iirc is bnodes |
| 23:40 | <Hixie> | but since you can just give them unique IDs, that becomes a non-issue |
| 23:42 | <TabAtkins> | Yeah, bnodes in Microdata are only as blank as you allow them to be. |
| 23:42 | <othermaciej> | I don't really understand what a bnode is |
| 23:42 | <TabAtkins> | A node in the data graph without an associated url. |
| 23:42 | <Hixie> | it's a node without an identifier |
| 23:43 | <TabAtkins> | In Microdata's RDF serialization, a bnode is the subject of all the triples generated by an @itemscope without an @itemid. |
| 23:44 | <Hixie> | it's hard to say exactly what the RDF model is since there's no official API; the only reason I'd say microdata's model is a tree and not the RDF graph is that there's an explicit microdata API that does't follow the URL refs and thus makes it a tree |
| 23:45 | <othermaciej> | the API being proposed by RDFa doesn't expose a graph or tree at all |
| 23:45 | <othermaciej> | just a list of triples |
| 23:45 | <Hixie> | right, like i said, RDF's model is just a list :-) |
| 23:45 | <othermaciej> | which seems like a pretty lousy interface |
| 23:45 | <Hixie> | which by convention can be interpreted as a graph |
| 23:47 | <TabAtkins> | I believe you're just supposed to parse the triples out and then hand them to a triple-store which will make the node associations for you. |
| 23:47 | <Hixie> | yeah the usual way of working with RDF is through queries, not through an API |
| 23:47 | <othermaciej> | but if you are running as JS in the browser, you don't have a triple store available |
| 23:47 | <othermaciej> | I expected the RDFa API itself to be a "triple store" |
| 23:47 | <othermaciej> | maybe that was a bad assumption |
| 23:47 | <TabAtkins> | You'd be disappointed, then. ^_^ |
| 23:47 | <othermaciej> | er |
| 23:48 | <othermaciej> | assumption |
| 23:48 | <Hixie> | it's not clear to me that the people designing the API are doing it for any reason other than to say they have an API |
| 23:48 | <othermaciej> | it seems like this model makes it very hard to have a live triple store on a dynamically modified document |
| 23:48 | <Hixie> | (unlike the microdata API, which is designed to make the information available) |
| 23:48 | <Hixie> | but then browser vendors are even less likely to implement a real triple store with querying than to implement the flat API |
| 23:48 | <Hixie> | so... |
| 23:49 | <othermaciej> | a triple store API would be more complicated to implement, but on the other hand it might have a real use case |
