| 00:51 | <Hixie> | aboodman2: yt? |
| 00:52 | <Hixie> | aboodman2: cross-domain importScripts(), opinion? |
| 04:59 | <aboodman> | Hixie: ping? |
| 05:32 | <Hixie> | hey |
| 05:32 | <Hixie> | i was wondering if you knew why we'd made importScripts() block cross-domain imports |
| 07:03 | <heycam> | Hixie, you can now use [IndexGetter=NoFunction] (and similarly for [IndexSetter], [NameGetter] and [NameSetter]) to cause the function not to exist in ES |
| 07:19 | <Hixie> | heycam: did you come up with a solution to the issue of the objects in question actually having the properties or whatever the issue was? |
| 07:57 | <othermaciej> | Hixie: the distinction of "really existing" is meaningless |
| 07:57 | <othermaciej> | but |
| 07:57 | <othermaciej> | it's worth specifying in what cases magic getter properties are enumerable |
| 07:57 | <othermaciej> | I don't think that can be specified in terms of delegating to a function in the IDL |
| 07:57 | <othermaciej> | nor is it really sound to specify behavior of the "in" operator that way |
| 08:00 | <Hixie> | right, the enumerability is what i meant |
| 09:58 | <heycam> | Hixie, not yet |
| 09:58 | <heycam> | othermaciej, is it really meaningless? it would change what Object.prototype.hasOwnProperty would return. |
| 09:59 | heycam | checks how enumeration of properties is defined in es3 |
| 09:59 | <othermaciej> | heycam: I mean, there's no spec-level concept of "real" and "not real" properties |
| 10:00 | <heycam> | othermaciej, in which spec? |
| 10:00 | <othermaciej> | ECMA-262 |
| 10:00 | <heycam> | no it only talks about properties |
| 10:00 | <heycam> | but magic [[Get]] will look like there are properties |
| 10:00 | <othermaciej> | I'm not sure it allows [[Get]] to be out of sync with [[HasProperty]] or hasOwnProperty |
| 10:01 | <heycam> | i think you can have whatever host object [[Get]] behaviour that you want, even if it is inconsistent with [[HasProperty]] etc. |
| 10:01 | <jwalden> | I think it must, because [[Get]] can be a getter function |
| 10:02 | <othermaciej> | I guess host objects can do anything |
| 10:02 | <othermaciej> | anyway |
| 10:02 | <heycam> | i think garrett showed that the properties were "real" though (for collections), so i'll be changing it to that |
| 10:02 | <othermaciej> | please don't use the term "real" or "actual" |
| 10:02 | <othermaciej> | it makes my skin crawl |
| 10:02 | <heycam> | ok :) |
| 10:02 | <othermaciej> | it doesn't mean anything |
| 10:02 | <heycam> | he showed that the objects had properties, rather than magic [[get]] |
| 10:02 | <othermaciej> | that doesn't mean anything either |
| 10:02 | <heycam> | ? |
| 10:03 | <othermaciej> | he showed that the dynamic properties are reflected by [[HasProperty]] (and hasOwnProperty) as well as by [[Get]] |
| 10:04 | <othermaciej> | another interesting question is whether they are enumerable (or conversely whether they are DontEnum or not); I don't know if he tested that |
| 10:05 | <othermaciej> | I don't think the IndexGetter IDL syntax is sufficient to capture these issues |
| 10:05 | <heycam> | no there'll likely need to be something additional to say whether the properties are enumerable |
| 10:05 | <othermaciej> | even the [[HasProperty]] part can't properly be captured |
| 10:06 | <othermaciej> | (as far as I know) |
| 10:07 | <heycam> | if html5 needs some objects to have non-standard [[HasProperty]] behaviour, then no that can't be captured yet either |
| 10:07 | <othermaciej> | because any value that an IDL method could return is in theory a possible valid value of a function |
| 10:07 | <heycam> | what do you mean by that? |
| 10:09 | <heycam> | anyway i'll do some testing tomorrow and see if i come up with something sensible |
| 10:09 | heycam | tv |
| 10:10 | <zcorpan> | Hixie: appendChild() prevents elements from being appended to text nodes in http://simon.html5.org/specs/web-dom-core#legal-hierarchy |
| 10:12 | <heycam> | btw zcorpan i like how you can click on the <dfn>s in that document and get an index of what refers to it |
| 10:12 | <zcorpan> | heycam: you can do the same in the html5 spec |
| 10:13 | <hsivonen> | zcorpan: looks like this is a case of sequential readability vs. random access readability :-( |
| 10:13 | <heycam> | zcorpan, i can't get it to do that in html5 for me |
| 10:14 | <zcorpan> | heycam: the whatwg single-page version? |
| 10:15 | <heycam> | no i was looking at the multipage version |
| 10:15 | <zcorpan> | hsivonen: i guess in due course i might spec it in the algorithms in a way that matches how you'd sanely implement it |
| 10:16 | <hsivonen> | zcorpan: "The Node is a Document node and has zero or one child Element node. " could be clearer if it somehow made it unambiguous that the sentence doesn't restrict other types of children |
| 10:16 | heycam | cries as the single page version makes his opera unusable |
| 10:17 | heycam | goes to watch True Blood instead |
| 10:19 | <hsivonen> | heycam: two years ago when the spec was smaller, it worked fine in Opera 7 on Nokia 770 with 64 MB of RAM. |
| 10:19 | hsivonen | doesn't understand the perf complaints about the spec. It loads faster than many MXR pages. |
| 10:19 | <zcorpan> | hsivonen: true. is s/zero or one/no more than one/ clearer? |
| 10:20 | <hsivonen> | zcorpan: yeah |
| 10:23 | <zcorpan> | hsivonen: fixed |
| 10:24 | <Philip`> | The spec still works very badly for me in Opera (freezing for tens of seconds after loading); Firefox is much better |
| 10:26 | <hsivonen> | yeah. the situation with current spec and current opera isn't quite smooth |
| 10:33 | <Philip`> | Some Opera developer should look into it and work out how to fix the spec / Opera so that they cooperate nicely and smoothly, because it's bad PR if their browser can't render specifications :-) |
| 10:34 | wilhelm | looks. |
| 10:38 | <MikeSmith> | I heard that Opera is preconfigured now to do secret user-data collection about any user who accesses the HTML5 spec |
| 10:39 | <Philip`> | I don't mind it collecting user data |
| 10:39 | <Philip`> | (The only problem is if it starts sending that collection to someone) |
| 10:39 | <MikeSmith> | I was kidding of course |
| 10:40 | <MikeSmith> | the truth is that Firefox is configured to optimize the user experience for any user accessing the HTML5 spec |
| 10:40 | <Philip`> | Anyway they could just look at their web server access logs for the Opera icon that's used in the stability annotations |
| 10:41 | <MikeSmith> | I was kidding about Firefox too |
| 10:42 | <MikeSmith> | the truth is that the HTML5 spec is going secret user-agent sniffing and varying its user experience depending on UA |
| 10:45 | <Philip`> | Maybe Opera has some high-tech AI algorithm that detects you're reading the latest version of the spec, parses it for changes since the browser was initially programmed, and then automatically patches the browser so it's consistently up-to-date |
| 10:45 | <Philip`> | and that's what makes it freeze for a bit while loading the spec |
| 10:45 | <krijnh> | MikeSmith: you're full of kidding today :) |
| 10:53 | Philip` | resists the temptation to make a joke about what else MikeSmith might be full of, because that would be entirely unfair |
| 11:06 | <MikeSmith> | Philip`: I'm full of good will for humanity |
| 12:03 | <MikeSmith> | can any opera folk tell me if Arve is around somewheres today? |
| 12:07 | <wilhelm> | MikeSmith: He's not in his office. |
| 12:07 | <MikeSmith> | wilhelm: ok, thanks |
| 12:25 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cvideo%20src%3Dimage%3E |
| 12:25 | <zcorpan> | safari shows the image |
| 12:30 | <zcorpan> | hsivonen: http://livedom.validator.nu/?%3C!DOCTYPE%20html%3E%0D%0A%3Cp%3E%3Csvg%3E%3Cforeignobject%3E%3C%2Fp%3E is weird |
| 12:34 | <zcorpan> | in fact just <svg><foreignobject></p> is weird |
| 13:17 | <hsivonen> | zcorpan: isn't that per spec, though? |
| 16:00 | <mookid> | Is there any chance of having content-type negotiation in hyperlinks in html5? |
| 16:01 | <mookid> | i.e. a way of indicating what the Accept header should be for a link.. |
| 16:01 | <mookid> | that might encourage browsers to be better HTTP clients :) |
| 16:02 | <mookid> | being able to indicate PUT and DELETE methods in html would be great too.. |
| 16:03 | <mookid> | I guess you've already discussed this - what is your approach to this right now? |
| 16:13 | <Philip`> | Why not link to a URL that is specific to the desired content-type, instead of trying to modify Accept? |
| 16:14 | <Philip`> | (e.g. link to foo.txt or foo.html, instead of to foo with Accept:text/html) |
| 16:15 | <Philip`> | HTML5 allows <form method="PUT"> and <form method="DELETE"> |
| 16:51 | <mookid> | Philip`: why? becuase that's how HTTP was designed :) |
| 16:52 | <mookid> | URL = resource locator, a resource has nothing to do with content-type |
| 16:53 | <mookid> | one resource can have multiple content-types, which one is returned should be evaluated according to the Accept header.. |
| 16:54 | <mookid> | by specifying .html or .txt you are adding content-type to a URL, which was never the intention for HTTP |
| 16:54 | <Dashiva> | Yet it works |
| 16:55 | <mookid> | HTTP has been misused because of the failures of HTML and brwosers to conform to HTTP |
| 16:55 | <mookid> | HTML less so |
| 16:55 | <mookid> | but browsers use HTML as an excuse for not being proper HTTP clients |
| 16:56 | <Dashiva> | What would the benefit be? |
| 16:56 | <mookid> | benefit of conforming to HTTP? Oh I don't know.. consistency? |
| 16:56 | <takkaria> | sadly, whilst HTTP might be geared up for content negotiation and this entire "one resource, multiple representation" thing, the rest of the world just isn't |
| 16:56 | <mookid> | because HTML is crap |
| 16:57 | <mookid> | as are the browsers |
| 16:57 | <mookid> | you can change this with HTML5 |
| 16:57 | <Dashiva> | Heh |
| 16:57 | <takkaria> | I meant more the operating systems, and the servers |
| 16:57 | <mookid> | rubbish lol |
| 16:57 | <mookid> | that's nonsense |
| 16:57 | <mookid> | no offence |
| 16:57 | <Dashiva> | They're violating HTTP left and right |
| 16:57 | <takkaria> | and the way most people use file extensions, and think of URLs as mapping to a directory tree on a server |
| 16:57 | <Philip`> | I like it when people tell me how to access all their data via URLs, rather than requiring me to wildly guess content-types until it happens to send me the right one :-) |
| 16:58 | <mookid> | so you're giong to leave out trivial.. potentially game changing improvements to HTML5 on teh basis that no one has been doing it properly? |
| 16:58 | <mookid> | superb. |
| 16:58 | <Dashiva> | Like what? |
| 16:58 | <mookid> | like an Accept tag in hyperlinks |
| 16:58 | <Dashiva> | What are these game changing improvements? |
| 16:58 | <Philip`> | Why is it game-changing? It's trivial for your server to map a single resource with multiple content-types onto multiple distinct URLs |
| 16:59 | <takkaria> | well, I'd sugget you're better trying to convince authors to see the world your way before you try and add features to a language which currently no-one wants to use |
| 16:59 | <mookid> | it's completely fundamental to enabling browsers to be good HTTP clients |
| 16:59 | <mookid> | what are you talking about HTTP is already established? |
| 16:59 | <mookid> | it's you guys and the brwoser guys not playing the game |
| 16:59 | <Dashiva> | http://www.example.com/resource with Accept:X can be mapped to http://www.example.com/resource?accept=X so I'm not seeing the big loss |
| 17:00 | <mookid> | there's a HUGE loss |
| 17:00 | <mookid> | If I tell you there's a resource |
| 17:00 | <mookid> | at say |
| 17:00 | <mookid> | example.com/something |
| 17:00 | <Dashiva> | There's a huge win: You don't have to specify anything for the huge majority of cases with only one type |
| 17:00 | <mookid> | you can put that into a browser.. you get HTML |
| 17:00 | <mookid> | you put that into iTunes you get the mp3 |
| 17:00 | <mookid> | you put it into a feed reader you get the RSS |
| 17:00 | <mookid> | that's amazing.. |
| 17:00 | <mookid> | if you do it your way the URL only serves one content-type |
| 17:01 | <mookid> | that's poop |
| 17:01 | <Dashiva> | Meanwhile the rest of the world has hyperlinks |
| 17:01 | <mookid> | what? |
| 17:01 | <Philip`> | How would I know that I should put that URL into iTunes or a feed reader? |
| 17:01 | <mookid> | you could do all or any |
| 17:01 | <mookid> | that's the point. |
| 17:01 | <mookid> | it's jsut a RESOURCE |
| 17:01 | <mookid> | URL.. |
| 17:01 | <mookid> | a resource can have many representations |
| 17:01 | <mookid> | depending on what UA you use to access it |
| 17:01 | <Dashiva> | That wasn't one resource, that was two resources |
| 17:02 | <Philip`> | If I tried putting random URLs into iTunes in the hope that they were music, I'd be continually disappointed and would give up; so I'd only try it once you explicitly told me that this URL could be accessed as an MP3, in which case you might as well tell me an MP3-specific URL |
| 17:02 | <mookid> | a resource is not a specific thing it's an abstract concept |
| 17:02 | <takkaria> | argh, I hate discussions about ontologies and the Web, it never ends well |
| 17:02 | <mookid> | but this is nonsense |
| 17:02 | <mookid> | why are you rejecting this? |
| 17:02 | <mookid> | you could include an accept tag in a hyperlink |
| 17:02 | <Dashiva> | Because we can already do everything you have suggested |
| 17:03 | <takkaria> | and do it easier |
| 17:03 | <mookid> | oh that's just onsense |
| 17:03 | <mookid> | no you dont |
| 17:03 | <Dashiva> | Why bolt on extra complexity for no gain other than some abstract concept's purity? |
| 17:03 | <mookid> | it's not EXTRA complexity |
| 17:03 | <mookid> | EXTRA complexty is using a URL for somethign it wans't designed for |
| 17:03 | <Dashiva> | No, that's existing functionality |
| 17:03 | <mookid> | why don't you ask Roy Fielding he knows a thing or 2 abuot HTTP.. |
| 17:03 | <Philip`> | The default stance towards features has to be rejection, because otherwise HTML would be more horrendously bloated than it is, and so convincing arguments are required before a feature will be accepted |
| 17:03 | <mookid> | no it's NOT |
| 17:04 | <mookid> | that's not functionality at all that's a dirty hack that's becoma standard |
| 17:04 | <Dashiva> | Also known as functionality |
| 17:04 | <takkaria> | that's what most functionality in the world is, oddly enough :) |
| 17:04 | <Philip`> | That's what HTML is :-) |
| 17:04 | <mookid> | when you type in example.com/flibblwe.html - there is no gurantee whatsoever that html is returned.. |
| 17:04 | <takkaria> | I think most states are built on dirty hacks, too |
| 17:04 | <mookid> | when you type in example.com/flibblwe.html - there is no gurantee whatsoever that html is returned.. |
| 17:04 | <Dashiva> | There's no guarantee the world will exist tomorrow either |
| 17:04 | <takkaria> | but it's a reasonable guess |
| 17:04 | <mookid> | oh good argument. |
| 17:04 | <takkaria> | but if you type in example.com/flibblew then you really have no idea what it could be |
| 17:05 | <mookid> | yeah so is putting example.com/bla into ituens.. |
| 17:05 | <mookid> | yes exatly |
| 17:05 | <mookid> | so you put it into whatever UA you have.. |
| 17:05 | <Dashiva> | Why would I put bla into a music player? There's nothing telling me it's a song |
| 17:05 | <mookid> | and it tries to get the appropriate content type for you |
| 17:05 | <mookid> | in the case of a browser this is quite important because you're supposed to be able to GET lots of different content types |
| 17:05 | <Dashiva> | Now you're mixing two completely separate issues |
| 17:06 | <mookid> | no I'm not |
| 17:06 | <Dashiva> | User agents use accept all the time to get the right content |
| 17:06 | <Dashiva> | But putting accept into HTML elements is a different beast altogether |
| 17:06 | <Dashiva> | Besides, such accept info wouldn't travel with the URL when you enter it into iTunes |
| 17:07 | <mookid> | so you can't download a pdf.. or rss.. or xhtml.. or json with a brwoser? |
| 17:07 | <Dashiva> | (Oh look, invisible metadata) |
| 17:07 | <mookid> | header? |
| 17:07 | <mookid> | Accept is a header |
| 17:07 | <mookid> | it's a standard component of an HTTP transaction |
| 17:07 | <Dashiva> | As an attribute on a link, it is metadata |
| 17:07 | <mookid> | to tell the browser how to compose the request.. |
| 17:08 | <mookid> | it's fundamental |
| 17:08 | <takkaria> | there are advantages to having the pdf and html versions at different urls |
| 17:08 | <takkaria> | because humans use urls |
| 17:08 | <Dashiva> | And humans usually use two different files |
| 17:08 | <takkaria> | and if you want to pass soeone the url to the PDF version, you paste "http://blah/file.pdf"; at them |
| 17:08 | <takkaria> | without .pdf you'd be hard pushed to do that |
| 17:09 | <mookid> | I'm not saying that you souldn't be able to specify - I'm implementing an API that negotiates with either the Accept header, or if it's specified a ?type=application/pdf |
| 17:09 | <Dashiva> | So what's the problem then? |
| 17:09 | <mookid> | but browsers wont be able to be good HTTP clients until you provide markup that allows them to do this properly |
| 17:10 | <Dashiva> | Use type=whatnot in HTML, you support it |
| 17:10 | <mookid> | that doesn't change the accept header |
| 17:10 | <takkaria> | HTTP is broken in that regard, then, since the accept header is invisible to users when really it should be visible to then |
| 17:10 | <takkaria> | so HTML is just working around a broken transport layer |
| 17:10 | <mookid> | HTTP ISNT BROKEN |
| 17:10 | <mookid> | HTTP and browsers are broken |
| 17:10 | <mookid> | HTML^ |
| 17:10 | <takkaria> | it's certainly no platonic form |
| 17:11 | <Philip`> | (HTTP servers are broken too) |
| 17:11 | <Dashiva> | Don't take it personally, it's just a protocol :) |
| 17:11 | <mookid> | HTTP servers arent broken? |
| 17:11 | <mookid> | it's an important protocol |
| 17:11 | <Philip`> | (I particularly like the one that returns four random bytes for Content-Type when you send a HEAD request) |
| 17:11 | <Dashiva> | Philip`: How about the one that returns text/plain on unknown content-types :) |
| 17:11 | <mookid> | and it's completely miss-represented and miss-understood because people get all political and dont want to admit that stuff like HTML and browsers are crap at speaking HTTP |
| 17:12 | <mookid> | so you've got an opporunity to bridge the gap.. |
| 17:12 | <mookid> | and instead of taking stuff like this onboard |
| 17:12 | <mookid> | you get defensive |
| 17:12 | <Philip`> | Dashiva: That's just boring brokenness, not fun brokenness |
| 17:12 | <mookid> | and nothign gets fixed |
| 17:12 | <Dashiva> | Who is defensive again? |
| 17:12 | <mookid> | but you get to feel good about yourself because there's a new version of HTML |
| 17:12 | <mookid> | I'm trying to make the web work better |
| 17:12 | <Dashiva> | No you're not |
| 17:12 | <mookid> | you're trying to be on a document for HTTP5 |
| 17:13 | <Dashiva> | You're trying to make HTTP look better |
| 17:13 | <mookid> | what? |
| 17:13 | <mookid> | I have no affiliation with HTTP whatsoever |
| 17:13 | <Dashiva> | You haven't mentioned a single thing that would benefit the web |
| 17:13 | <mookid> | of HTTP? |
| 17:13 | <mookid> | are you insnae? |
| 17:13 | <mookid> | isnane^ |
| 17:13 | <Dashiva> | Just pragmatic |
| 17:13 | <mookid> | no you're misguided |
| 17:14 | <mookid> | are there project leads here because this is pretty important and from what I can gather not one of you appreciates any of these points |
| 17:14 | <mookid> | I'm in the real world developing real world solutions and HTTP works perfectly.. brwosers and HTML are attrocious |
| 17:15 | <Dashiva> | You could send an email to the mailing list |
| 17:15 | <Dashiva> | Hixie will be sure to read it |
| 17:15 | <Philip`> | I think most people here would agree that browsers and HTML have significant problems; the disagreement is usually about how to best move forwards from where we are |
| 17:16 | <mookid> | well I would say that looking into HTTP - respecting it and according to it |
| 17:16 | <mookid> | would be a good start |
| 17:16 | <mookid> | and "oh well HTTP can still work and we dont need to provide a mechanism for setting an Accept header" is frankly not good enough |
| 17:16 | <mookid> | considering how important HTML is |
| 17:17 | <mookid> | I really hope your approach is not reflective of this project |
| 17:18 | <mookid> | Hixie: what are your thoughts on this? |
| 17:19 | <Dashiva> | He's probably still asleep |
| 17:20 | <mookid> | Do you not think an optional tags for appropriate HTTP requests is even a possibility? |
| 17:20 | <mookid> | -an |
| 17:20 | <Dashiva> | I predict Hixie will say something along the lines of "What are the use cases?" |
| 17:21 | <mookid> | great..l so he can nerd me into position |
| 17:21 | <Philip`> | The HTML5 approach is (in theory) to start by considering use cases, like "person X wants to send a link to a music file to a friend who can listen to it" or whatever, and then considering various solutions (e.g. send a multi-type URL and make UAs use Accept correctly, or send a URL specific to the MP3, or whatever) and choosing the 'best' (usually simplest, given the cost of adding features to browsers) that satisfies the use cases |
| 17:21 | <mookid> | but what if the benefits are mostly external to HTML itself |
| 17:21 | <mookid> | then it's not considered |
| 17:22 | <mookid> | my argument is that it's better for HTTP and ultimately better for the web |
| 17:22 | <mookid> | how do I make that a use case for HTML itself? |
| 17:22 | <mookid> | your argument will alwasy be 'well you can put the content type in the URL' |
| 17:22 | <mookid> | if you look at the definition of URL though.. it's pretty clear that shouldn't be the approach |
| 17:23 | <mookid> | the fact that you can doesnt make it right |
| 17:23 | <mookid> | e.g. I can spam aload of ranting jibberish at you - that doesnt mean I'm right |
| 17:23 | <Philip`> | Whenever a feature is added to the spec, the browser developers will have to be convinced that it's worth implementing, and they're unlikely to do that if the only justification is some abstract "it's better for the web" and it doesn't directly make their users happier |
| 17:23 | <Dashiva> | Say, mookid |
| 17:23 | <Dashiva> | Did you read the discussion about HTML URLs? |
| 17:23 | <mookid> | it's not HTML urls |
| 17:23 | <mookid> | it's just URLs |
| 17:23 | <Dashiva> | Oh boy |
| 17:23 | <mookid> | what? it's not.. |
| 17:24 | <Dashiva> | Philip`: Can I point him there in good conscience? |
| 17:24 | <mookid> | is that not allowed because it makes you feel less important? |
| 17:24 | <takkaria> | HTML has its own concept of how to map and URI expressed in HTML to a real URI |
| 17:25 | <Philip`> | Dashiva: You mean the discussion about whether HTML5 should call its URL-ish syntax "URLs" instead of something ugly like "HURLs"? |
| 17:25 | <mookid> | why? |
| 17:25 | Philip` | isn't quite sure why that's at all relevant |
| 17:25 | <mookid> | why not just follow what the HTTP protocol tells you |
| 17:25 | <mookid> | it's pretty specific |
| 17:25 | <mookid> | R = Resource |
| 17:25 | <Dashiva> | Philip`: It's another violation of the HTTP/URL purity :) |
| 17:25 | <mookid> | R != Resource + content-type |
| 17:26 | <mookid> | even if that is the way things are done now |
| 17:26 | <mookid> | and I'm not even saying 'stop people from doing it' |
| 17:26 | <mookid> | I'm just saying give them the ability to do it right |
| 17:26 | <mookid> | and let them choose |
| 17:26 | <Philip`> | Dashiva: Not really - it's just a syntactic issue about how you translate a stream of bytes in an HTML document into a requestable URI |
| 17:26 | <mookid> | a few optional tags isn't exactly rocket science |
| 17:27 | <mookid> | I guess I'm not the first person to bring this up right? |
| 17:28 | <takkaria> | AFAICR, you are |
| 17:28 | <jmb> | mookid: why does html have to add an attribute to link elements? user agents know what content types they support, so they send an accept header. it's then up to the server to serve something up that's appropriate. the exact same thing happens right now with language negotiation |
| 17:28 | <mookid> | jmb that's not true for browsers actually |
| 17:28 | <mookid> | brwosers handle lots of different content types |
| 17:28 | <mookid> | not just HTML |
| 17:28 | <mookid> | *chock horror* ! |
| 17:28 | <mookid> | shockl^ |
| 17:28 | <mookid> | chock^ |
| 17:28 | <mookid> | shock^ |
| 17:28 | <takkaria> | that's exactly what he said... |
| 17:28 | <jmb> | mookid: yes, and they send an appropriate Accept header |
| 17:28 | <mookid> | no they don't |
| 17:29 | <Philip`> | My browser says it accepts */* |
| 17:29 | <mookid> | they send a generic header |
| 17:29 | <mookid> | that's what I'm saying |
| 17:29 | <mookid> | that's not how HTTP was intended |
| 17:29 | <mookid> | that's how it's been implemented |
| 17:29 | <Philip`> | (Specifically: "text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1") |
| 17:29 | <mookid> | because HTML and browsers are crap |
| 17:29 | <mookid> | .. |
| 17:29 | <mookid> | that's exaclty my point. |
| 17:29 | <mookid> | ! |
| 17:29 | <jmb> | what has html to do with this? |
| 17:29 | <mookid> | oh deasr lord. |
| 17:30 | <mookid> | <a> = GET request to a URL - it shoudl indicate exactly how to construct that request |
| 17:30 | <mookid> | but at the moment it doesnt |
| 17:30 | <jmb> | no |
| 17:30 | <mookid> | and apparently the new version wont either |
| 17:30 | <mookid> | which is sad |
| 17:30 | <mookid> | because you have an oppotunity |
| 17:30 | <jmb> | the page author has utterly no way of knowing what the user agent supports |
| 17:30 | <mookid> | and a protocol to guide you |
| 17:31 | <mookid> | the Accept HEADER |
| 17:31 | <mookid> | that's the point |
| 17:31 | <jmb> | therefore, they have no reason whatsoever to be given a way to change the user agent's accept header |
| 17:31 | <mookid> | yes there is |
| 17:31 | <mookid> | if I request from my browser example.com/report |
| 17:31 | <mookid> | and I want that page to link to the pdfversion |
| 17:31 | <mookid> | and not the html |
| 17:32 | <mookid> | how am I supopsed to tell the brwoser to ask for pdf ? |
| 17:32 | <mookid> | your sugegstion is to us ethe URL |
| 17:32 | <mookid> | URL's arent for that |
| 17:32 | <mookid> | YES you can do it |
| 17:32 | <jmb> | if the browser can't handle PDF, then why should it ask for it? |
| 17:32 | <Philip`> | mookid: Just to be clear: Are you suggesting that browsers should support something like <a href="..." accept="audio/mp3, audio/wav;q=0.9">? and do you just want Accept, or all the other HTTP request headers that you currently can't access? |
| 17:32 | <mookid> | yes exactly |
| 17:32 | <mookid> | exactly Philip` |
| 17:32 | <mookid> | so generic if not specified |
| 17:33 | <mookid> | for that browser/OS |
| 17:33 | <Philip`> | mookid: Just for Accept, not anything else? |
| 17:33 | <mookid> | if specified it tells brwoser to specify header |
| 17:33 | <mookid> | well Accept is the only one I can think of that has practical use to the user |
| 17:33 | <mookid> | there may be others |
| 17:34 | <mookid> | are you talking to the HTTP community abuot this? |
| 17:34 | <mookid> | it's quite important actually |
| 17:34 | <mookid> | Philip`: are you seeign where I am coming from? |
| 17:34 | <mookid> | or not? |
| 17:34 | <Philip`> | mookid: Should it only apply to <a href>, and not to <img src> or <script src> or <link href> etc? |
| 17:35 | <mookid> | right.. any hyperlink |
| 17:35 | <mookid> | that's not a hyperlink is it |
| 17:35 | <mookid> | I dont know the word |
| 17:35 | <mookid> | anythign containg an URL refrence |
| 17:36 | <mookid> | <a> would be the most comomon though obviously |
| 17:36 | <mookid> | and if developers didn't use it - it would make no difference to them anyway |
| 17:37 | <mookid> | + it's not a binding contact for the server, the protocol doesn't require the server to actually respect the Accept header - in the same way that I can make my server respond to index.html with a jpeg |
| 17:39 | <takkaria> | the main point here, is that it provides no tangible benefit to allow people to do that over other methods that are already widely used, and so it would be a very low priority in specification development |
| 17:39 | <mookid> | *shakes head* |
| 17:39 | <mookid> | lordy lordy lordy |
| 17:40 | <mookid> | it provides massive benefits |
| 17:40 | <Philip`> | mookid: I do see what you're proposing, but I don't currently see that the cost of implementing it would be worth the value (particularly since it seems it only has any value once it's implemented in nearly every deployed web browser, because otherwise people won't be able to safely use it) |
| 17:40 | <mookid> | do you know who Roy Fielding is? |
| 17:40 | <takkaria> | yes |
| 17:40 | <takkaria> | do you know who Tony Blair is? |
| 17:40 | <mookid> | he agrees with me. |
| 17:41 | <mookid> | Roy Fielding is pretty authorative guy when it comes to the web |
| 17:41 | <takkaria> | appeals to authority never work in the WHAT WG, I'm afraid |
| 17:41 | <Dashiva> | Argument from authority? |
| 17:41 | <mookid> | er |
| 17:41 | <mookid> | I'm sorry but |
| 17:41 | <mookid> | how can you make sweeping statements like "this isnt high enough priority" |
| 17:41 | <mookid> | you must assume some kind of authority within the realm of HTML to make that assertion |
| 17:42 | <mookid> | oops? did you just make an internet boo boo ? |
| 17:42 | <Dashiva> | The design principles? |
| 17:42 | <mookid> | There is just so much potential with a new version of HTML |
| 17:42 | <mookid> | yuor gonna ruin it if you ignore this |
| 17:43 | <mookid> | why don't you start a dialogue with the HTTP guys and see what the feedback is? |
| 17:43 | <Philip`> | The HTTP guys' feedback has mostly been objecting to aspects of HTML5 that can't be changed because of compatibility requirements on the web, if I remember correctly |
| 17:44 | <mookid> | well this isn't a compatablity requirements |
| 17:44 | <mookid> | issue |
| 17:44 | <mookid> | wahtever coming back later this is insane |
| 17:44 | <mookid> | :D |
| 17:45 | <Dashiva> | Philip`: Also refusing to change things that clash with the web |
| 17:52 | <Philip`> | (From #html-wg: http://www.w3.org/html/wg/markup-spec/ ) |
| 17:53 | <Dashiva> | obsolete... |
| 17:55 | <aboodman> | Hixie: not sure if you got last message... I would lean toward doing what the web already does, but that is not based on any sort of analysis |
| 18:04 | <Philip`> | Dashiva: Oh, didn't see it on the list |
| 18:07 | <Hixie> | aboodman: k |
| 18:08 | <Hixie> | aboodman: (i remember that we added the cross-site limitations for a reason, i just don't remember if the reason was "to do the right thing" or "because it prevents attack X") |
| 19:32 | <Lachy> | my presentation at pubcon is over |
| 19:33 | <MikeSmith> | ぁ |
| 19:33 | <MikeSmith> | Lachy: お疲れさま |
| 19:34 | <Lachy> | surprisingly I stuttered a lot more than usual this time |
| 19:34 | <Lachy> | MikeSmith, wtf? |
| 19:34 | <MikeSmith> | Lachy: how did it go? how many people in the audience? |
| 19:34 | <MikeSmith> | otsukare-sama |
| 19:34 | <Lachy> | I'd guess around 50 to 60 |
| 19:34 | <Lachy> | though I'm not sure. Could have been more |
| 19:34 | <MikeSmith> | this was an HTML5 presentation? |
| 19:35 | <Lachy> | it was a panel on HTML and CSS. 3 of us gave 15 min presentations each |
| 19:36 | <Lachy> | I should have spoken more about forms instead of things like <section>, since forms would have been more relevant to this business and marketing oriented crowd |
| 19:36 | <Lachy> | but I didn't have any decent slides about forms to reuse |
| 19:36 | <Lachy> | I will have to make them |
| 19:37 | <Lachy> | anyway, I went and saw Steve Wyrick, a magician, last night. |
| 19:38 | <Lachy> | he was good. I really have no idea how he managed to get from the stage to a seat in the middle of the audience |
| 19:39 | <Lachy> | but the person he was sitting next to got a huge surprise :-) |
| 19:41 | <Philip`> | Maybe it was his identical twin |
| 19:41 | <Philip`> | or an illegal cloning experiment |
| 19:44 | <Lachy> | I also found a cool magic shop, and learned how to make a levitating playing card |
| 19:47 | <MikeSmith> | Lachy: Pubcon is the same organizers as Webmaster World? |
| 19:47 | <Lachy> | yes |
| 19:48 | <MikeSmith> | anybody else from Opera was speaking there? or around for the event? |
| 19:49 | <Lachy> | Gier from the web apps dept is here somewhere, but not presenting |
| 19:52 | <MikeSmith> | Lachy: please tell him I said hi. I've not seem him since Xtech a couple years ago |
| 20:51 | <jgraham> | Being able to set HTTP headers used in hyperlinks from HTML seems to have a very poor backward compaibility story |
| 20:59 | <Dashiva> | jgraham: No, no. HTTP has supported headers for many years ;) |
| 21:05 | <jgraham> | :-p |
| 21:14 | <gsnedders> | It opens up all kinds of attack vectors |
| 21:18 | <jcranmer> | is scheme:path?query;param#anchor the correct format, or is it scheme:path;param?query#anchor ? |
| 21:19 | <Dashiva> | I believe it's the latter |
| 21:37 | <hsivonen> | gsnedders: I think Macrovision on VHS isn't *DRM*, because it lacks the D |
| 21:37 | <gsnedders> | hsivonen: Pedant :) |
| 21:38 | <hsivonen> | gsnedders: it seems to me that the argument is: |
| 21:39 | <hsivonen> | 1) Font foundries want to make infringing people aware that they are infringing |
| 21:40 | <hsivonen> | 2) People grab a font using view source / Web Inspector / Firebug don't realize they are infringing |
| 21:41 | <hsivonen> | so the argument doesn't hinge on any technical prevention |
| 21:41 | <hsivonen> | but on what hoops make people aware that they are infringing when they infringe |
| 21:41 | <gsnedders> | Then any obstruction or DRM is overkill |
| 21:42 | <hsivonen> | s/grab/who grab/ |
| 21:43 | <gsnedders> | Would it not be simpler for browsers to include a small note in all save boxes, along the lines of, "This file may be subject to copyright/licence restrictions." |
| 21:44 | <jgraham> | I don't see why that is needed |
| 21:45 | <jgraham> | or how it would help, really |
| 21:45 | <gsnedders> | Nor do I really, but it seems to address the needs of the foundries |
| 21:46 | <hsivonen> | jgraham: the whole discussion is basically about what rituals would make one group of believe that another group of people is lead to think in a certain way |
| 21:47 | <jgraham> | hsivonen: Yeah, but putting randon pseudo-legalese in browsers is really not nice |
| 21:49 | <jgraham> | I still don't understand why fonts deserve more protection than photographs |
| 21:49 | <hsivonen> | jgraham: I agree. Particularly when the pseudo-legalese is a truism that should be assumed to be known by default. |
| 21:49 | <Hixie> | "<gsnedders> Nor do I really, but it seems to address the needs of the foundries" assumes that we need to address those needs |
| 21:49 | <Hixie> | which i'm pretty sure we don't |
| 21:50 | <gsnedders> | Hixie: Just ignore the font foundries? |
| 21:50 | <gsnedders> | Hixie: Surely that's no different to ignoring implementers? |
| 21:50 | <jgraham> | gsnedders: That seems like an option. |
| 21:50 | <gsnedders> | (in terms of getting stuff used) |
| 21:52 | <Hixie> | implementors can veto stuff because if they don't implement, the spec is fiction |
| 21:52 | <Hixie> | font foundries have no veto ability here, and their needs directly conflict with the users' |
| 21:52 | <Hixie> | users win |
| 21:52 | <hsivonen> | Hixie: what happened with Google's EOT patch for WebKit? |
| 21:53 | <Hixie> | we decided we couldn't justify introducing DRM given our "do no evil" principles |
| 21:53 | <gsnedders> | Hixie: No, users don't win. They can't use the majority of fonts. |
| 21:53 | <Hixie> | sure they can |
| 21:54 | <gsnedders> | (and if you just send OTF/TTF anyway, who's betting the foundries will just change their licences to disallow that) |
| 21:54 | <Hixie> | of the fonts available to a random author, the vast majority are free |
| 21:54 | <hsivonen> | Hixie: it seems to me that the "need" of foundries is to believe that users know what they are infringing. I'm not convinced that in would be against the users' needs to know what behaviors are infringing. However, I'd prefer a way to establish the belief and awareness without using technology as a intermediate. |
| 21:55 | <Hixie> | users are fully aware that copying a font from another site is a violation of copyright |
| 21:55 | <Hixie> | so that need is already met |
| 21:55 | <jgraham> | hsivonen: That is hardly a unique need. Why do fonts get special consideration over all other media |
| 21:58 | <hsivonen> | Hixie: yeah, according to a recent study conducted in Finland, 95% of school kids believe that distributing movies and music without authorization is illegal. |
| 21:59 | <Hixie> | people know it's illegal, they just don't care |
| 22:04 | <Dashiva> | hsivonen: You say "believe", makes it sound like it isn't :) |
| 22:06 | <hsivonen> | Dashiva: well, I'm pretty sure it's illegal here, but these studies also include BS about using the word that approximates "felony" for things that are illegal but not punishable |
| 22:06 | <hsivonen> | (compare with riding a bike without a helmet) |
| 22:07 | <Dashiva> | The jail/no jail distinction? |
| 22:08 | <hsivonen> | Dashiva: for example, I'm pretty sure that downloading movies / music without authorization is in the illegal but not punishable category here. |
| 22:08 | <hsivonen> | Dashiva: but the people who get prosecuted also shared the content |
| 22:08 | <Philip`> | If it's not punishable, what would stop anyone from doing it? |
| 22:09 | <hsivonen> | Philip`: knowing that it illegal. And for all things not copyright-related, Finns will generally obey the law on the law's sayso |
| 22:10 | <hsivonen> | Also, over here the police can do pretty much what it pleases and can use equipment confiscation as a de facto punishment on a presumed guilty-basis. |
| 22:13 | <Philip`> | Given how many people infringe copyright even when they know it's illegal, I can't imagine many are put off by it being considered legally naughty but not punishable |
| 22:13 | <hsivonen> | I would guess that for people who are very familiar with the law and practice, the risk of equipment confiscation without judicial oversight is a stronger deterrent than the law |
| 22:19 | <hsivonen> | (oh. there's another thing that's illegal but not punishable and that people do: lying about campaign finance to the ministry of justice) |
| 22:20 | <hsivonen> | (the politicians had the good sense to make their own illegalities non-punishable) |
| 22:22 | <Dashiva> | I don't get that |
| 22:22 | <Dashiva> | I learned in class that illegal was defined as there being a law against it |
| 22:24 | <hsivonen> | Dashiva: right. But the law doesn't have to set punishments for all things that are illegal. |
| 22:25 | <hsivonen> | Dashiva: and over here if an illegal thing doesn't have an entry in the Criminal Code, it's a different type of illegality than a "crime" |
| 22:27 | <Dashiva> | So what happens if the police find you committing one of those crimes? They take your computer to gather evidence, and then throw the evidence away? |
| 22:29 | <Hixie> | copyright violation is punishable |
| 22:29 | <Hixie> | it's just a civil offense rather than a criminal one |
| 22:29 | <Hixie> | which means financial damages and reparations, generally |
| 22:30 | <hsivonen> | Hixie: Finland doesn't have punitive damages, so in theory, if it's a civil case, it's not a punisment but just damages |
| 22:30 | <hsivonen> | *punishment |
| 22:30 | <Hixie> | and what's the nominal "damage" of violating copyright? |
| 22:32 | <hsivonen> | Dashiva: they can take the computers and all inessential related equipment away for investigation, be slow with the investigation, and turn over the evidence to support a trial brought by a RIAA/MPAA/IFPI-connected civil association |
| 22:32 | <hsivonen> | Hixie: the retail price of the same piece of content on CD/DVD |
| 22:33 | <hsivonen> | Hixie: assuming a theory that every copy is a lost sale, which is of course bogus |
| 22:33 | <Hixie> | wow, that's low |
| 22:33 | <jcranmer> | hsivonen: better than the RIAA's theory |
| 22:33 | <Hixie> | the us has insanely high numbers |
| 22:33 | <Hixie> | like, ever violation is 5 digits usd |
| 22:33 | <hsivonen> | Hixie: plus legal fees! |
| 22:33 | <jcranmer> | i.e., every copy represents thousands of lost sales |
| 22:33 | <Hixie> | every, even |
| 22:34 | <hsivonen> | so if you lose a case to the enforcement association, the court orders you to pay their legal fees |
| 22:34 | <hsivonen> | so for the downloader case, the main risk is equipment confiscation and legal fees |
| 22:35 | <hsivonen> | for the uploader case, there's also a potentially high supposed damage |
| 22:35 | <hsivonen> | none of these are "punishments" in the legal sense although de facto, they are |
| 22:38 | <hsivonen> | not having punitive damages is good. If something requires more punishment, a fine to the state leads to much more healthy behavior than awarding more than the actual damages to the supposedly injured party |
| 22:39 | <hsivonen> | (the reason why we don't have punitive damages is a principle that the injured party shouldn't end up better off than where they started by suffering a damage) |
| 22:41 | <Hixie> | you'll note i didn't mention punitive damages :-) |
| 22:41 | <Hixie> | i don't think the us has them for copyright violations either |
| 22:41 | <Hixie> | but what do i know |
| 22:41 | <hsivonen> | Hixie: well, the U.S. has crazy statutory damages |
| 22:41 | <Dashiva> | It's not like the actual law matters to the RIAA :P |
| 22:41 | <hsivonen> | I'm not sure if those are considered "punitive" legally in this case |
| 22:44 | <jruderman> | how about cruel and unusual? |
| 22:44 | <hsivonen> | anyway, damages in excess of the actual damages whether statutory or made up be a judge on the spot suck, and it's better to put the excess into the state treasure than to award it to another litigant, IMO |
| 22:45 | <Hixie> | statutory damages kinda makes sense in that for non-financial stuff there has to be some sort of going rate for pain |
| 22:45 | <Hixie> | i mean, it's not like you can easily measure the pain cause by slander in USD, for example |
| 22:46 | jruderman | slanders Hixie's cat |
| 22:46 | <Hixie> | poor mowmow |
| 22:46 | <Hixie> | they were at the vet this morning |
| 22:46 | jcranmer | has a cat who likes to sit and sleep |
| 22:46 | <jcranmer> | very good paperweight |
| 22:46 | <hsivonen> | jruderman: it seems to me that in RIAA cases damages are cruel but unfortunately not unusual |
| 22:48 | <hsivonen> | s/treasure/treasury/ |