| 01:57 | <takkaria> | I never knew people could bikeshed over implemented features |
| 02:19 | <Philip`> | Hmm, looks like I can't tunnel Web Socket connections through a Squid reverse proxy :-( |
| 02:20 | <Philip`> | (It messes up all the response headers, and then closes the connection immediately) |
| 02:40 | <famicom> | yo |
| 02:40 | <famicom> | takkaria what do you mean with bikeshed |
| 02:44 | <famicom> | blegh |
| 02:44 | <famicom> | html 5 is a Bad-Idea (tm) |
| 02:46 | <famicom> | as far as the new tags go that is. |
| 02:58 | <takkaria> | famicom: http://www.unixguide.net/freebsd/faq/16.19.shtml |
| 02:59 | <takkaria> | famicom: why do you think html5 is a bad idea? |
| 03:00 | <famicom> | if anything, it should feature LESS tags instead of more |
| 03:02 | <takkaria> | what tags do you have problems with in particular? |
| 03:06 | <famicom> | <article> <audio> <command> <footer> <progress> <time> <video> |
| 03:06 | <famicom> | <figure> etc etc |
| 03:08 | <famicom> | <aside> is horrible too |
| 03:09 | <famicom> | why on EARTH would you add a new element, when you can just use a css float |
| 03:19 | <olliej> | famicom: audio and video actually provide completely new functionality |
| 03:19 | <olliej> | famicom: the others mostly represent semantic information rather than style information |
| 03:20 | <olliej> | famicom: then there are a few others that all the browser already implement, so defining behaviour == compatibility win |
| 03:21 | <othermaciej> | famicom: elements are about semantics and behavior, not presentation |
| 03:21 | <famicom> | yeah, but what if i add 2 footer tags inside a document |
| 03:22 | <othermaciej> | HTML5 tries to add semantic elements for structures very commonly seen on the Web, to avoid the need to do everything with <div> soup |
| 03:22 | <othermaciej> | then that would be invalid, unless each is in a different sectioning element |
| 03:22 | <famicom> | what is wrong with div soup |
| 03:24 | <famicom> | adding new elements is going to create an even bigger mess |
| 03:25 | <famicom> | and audio + video add NOTHING that hasnt been possible with embed |
| 03:26 | <olliej> | famicom: um? you're entirely right, it's perfectly possible to use a variety of proprietary technologies in an embed tag |
| 03:26 | <olliej> | famicom: non of which are styleable with css |
| 03:26 | <olliej> | ignoring the fact you should be using an object tag ;D |
| 03:26 | <famicom> | gehehehehe |
| 03:29 | <famicom> | but here's something, what about for instance flash video. |
| 03:29 | <olliej> | famicom: what about it? |
| 03:29 | <famicom> | which is proprietary, but is a media container for video |
| 03:29 | <famicom> | well |
| 03:29 | <famicom> | which tag should be used for that |
| 03:29 | <olliej> | famicom: an object tag |
| 03:30 | <famicom> | but it displays video |
| 03:30 | <olliej> | famicom: video == browser embedded video |
| 03:30 | <olliej> | famicom: eg. the browser knows what is happening |
| 03:30 | <famicom> | it is embedded in my browser isnt it |
| 03:30 | <olliej> | famicom: and an do correct compositing |
| 03:30 | <othermaciej> | with flash video, you're embedding a flash program that happens to play video |
| 03:31 | <olliej> | famicom: plugins do not integrate with the page well -- you can't style them from css, they have all sorts of exciting compositing issues, they tend to be the most crash prone things on the web |
| 03:32 | <famicom> | agreed |
| 03:32 | <famicom> | but thats a whole other issue |
| 03:33 | <olliej> | um -- you've just effectively said "every reason that plugins are bad doesn't matter, what's wrong with plugins?" |
| 03:35 | <famicom> | no, im seperating markup from media-objects |
| 03:38 | <famicom> | because i sure as hell know that a lot of vendors won't be implementing it in the way the specification discribes |
| 03:38 | <olliej> | famicom: ? |
| 03:38 | <olliej> | famicom: <video> and <audio> need to be actual elements |
| 03:38 | <olliej> | famicom: they're not style information, they're semantic behaviour |
| 03:38 | <famicom> | explain the "need" for them |
| 03:39 | <olliej> | famicom: they are also not generic content vehicles -- they don't allow you to use an arbitrary plugin -- they exist specifically for media, that the browser controls |
| 03:39 | <olliej> | famicom: people want audio and video on the web, there is no standard way for them to do so without video and audio elements |
| 03:40 | <olliej> | famicom: currently your only option is to use a proprietary plugin which does not interact with the webpage in any sane way, does not composite properly in the webpage, and cannot be styled with css |
| 03:40 | <famicom> | first of all, you cannot style audio:P |
| 03:41 | <olliej> | famicom: well yes, but you can interact with it through a standard dom interface |
| 03:41 | <famicom> | secondly, whereas i understand the need for a standard for multimedia |
| 03:42 | <famicom> | i don't see why it should be so "specific" |
| 03:43 | <famicom> | or why it should be handled by the browser to begin with |
| 03:43 | <olliej> | famicom: dammit, are you ignoring what i say deliberately? |
| 03:43 | <olliej> | famicom: plugins *cannot* compositie correctly with the page |
| 03:43 | <olliej> | famicom: they are entirely distinct |
| 03:43 | <famicom> | nor does multimedia |
| 03:44 | <famicom> | do you think lynx or elinks will ever be able to support it? |
| 03:44 | <olliej> | famicom: nor does multiemedia what? |
| 03:44 | <famicom> | "qcompositie correctly with the page" |
| 03:44 | <olliej> | famicom: um? i take it you haven't actually played with the video tag at all then? |
| 03:45 | <olliej> | famicom: because at least in webkit the video tag does composite correctly |
| 03:45 | <famicom> | your point being |
| 03:45 | <famicom> | just because it works in 1 single implementation, doesn't make it a good idea |
| 03:46 | <olliej> | famicom: the whole point is it is specced to composite correctly |
| 03:46 | <famicom> | webkit also was the first implementation to pass the acid2 test |
| 03:46 | <olliej> | famicom: if it doesn't composite correctly in another implemetnation that is a bug in that implementation |
| 03:46 | <olliej> | famicom: and they will fix that |
| 03:46 | <othermaciej> | I believe that the Mozilla implementation of <video> also composites properly |
| 03:46 | <olliej> | famicom: however it is not actually possible to correctly composite plugins |
| 03:47 | <olliej> | famicom: nor is it possible to colour correct them |
| 03:47 | <olliej> | famicom: nor do they respect arbitrary transforms you can get with css transofrms, or through embedding in svg |
| 03:48 | <roc> | of course it composites properly |
| 03:48 | <roc> | it even plays nice in an SVG foreignObject with transforms, filters and the whole shebang |
| 03:49 | <olliej> | heya roc |
| 03:49 | <olliej> | i kind of assumed it would composite correctly, but didn't actually know for sure :D |
| 03:49 | <famicom> | well what about mobile browsers |
| 03:50 | roc | notes that olliej's complains about plugins apply only to *windowed* plugins, although for the sake of this argument, he's entirely on olliej's side |
| 03:50 | <olliej> | famicom: video tag is preferable for a mobile browser as well |
| 03:50 | <olliej> | famicom: as it means less untrusted code running |
| 03:50 | <famicom> | ok |
| 03:51 | <olliej> | famicom: note that all content from the web (JS, ActionScript, etc) == untrusted |
| 03:51 | <famicom> | so according to you, html is no longer about text, but about audio and video as well |
| 03:51 | <olliej> | ActionScript == untrusted code running in a closed off and proprietary vm |
| 03:51 | <famicom> | yeah, i hate flash as far as that goes |
| 03:51 | <olliej> | famicom: um, i haven't see you utter one complaint about the <img> tag |
| 03:52 | <famicom> | ollie, yup |
| 03:52 | <famicom> | because it exists, and that's it |
| 03:52 | <takkaria> | as soon as plugins were allowed, html was no longer about text, but about being an application platform |
| 03:52 | <olliej> | famicom: but i suspect you have basically gotten confused about semantics and style -- markup == semantic information, css = style information |
| 03:53 | <famicom> | not entirely |
| 03:53 | <olliej> | um yes |
| 03:53 | <olliej> | entirely |
| 03:53 | <othermaciej> | roc: however windowless plugins can be quite a bit slower than the browser providing the same functionality natively, in some cases |
| 03:53 | <roc> | yes |
| 03:53 | <famicom> | my problem, is that the video and audio tags are too specific |
| 03:54 | <olliej> | famicom: there are old tags that still exist that predate css for presentation, that's it |
| 03:54 | <olliej> | famicom: how so? |
| 03:54 | <famicom> | you are basicly introducing a new set of font tags |
| 03:54 | <olliej> | no |
| 03:54 | <olliej> | goddammit |
| 03:54 | <olliej> | why do you not get this? |
| 03:54 | <olliej> | famicom: font == style |
| 03:54 | <olliej> | famicom: video == content |
| 03:54 | <olliej> | famicom: audio = content |
| 03:54 | <famicom> | because in 10 years time, i know that we will be able to embed 3d animations in webpages |
| 03:55 | <roc> | yeah, and then we'll create a new element |
| 03:55 | <olliej> | famicom: animation is presentation |
| 03:55 | <roc> | sometimes |
| 03:55 | <olliej> | famicom: webkit already supports transitions in css |
| 03:55 | <famicom> | so a 3d game is presentation |
| 03:55 | <famicom> | my ass it is |
| 03:55 | <famicom> | its a media object |
| 03:55 | <olliej> | famicom: canvas is technically able to provide a 3d context |
| 03:56 | <famicom> | so why add so many new tags |
| 03:56 | <olliej> | *sigh* |
| 03:56 | olliej | gives up |
| 03:56 | <takkaria> | give me a 't', give me an 'r', give me an 'o' 'l' 'l' |
| 03:56 | <roc> | good plan |
| 03:56 | <famicom> | adding more tags isnt going to solve it |
| 03:56 | <famicom> | just create one single tag, then give it meaning via attributes |
| 03:56 | <famicom> | <meta> allready does that |
| 03:57 | <roc> | yeah baby |
| 03:58 | <roc> | <tag type="h1"><tag type="p"><tag type="video"> |
| 03:58 | <othermaciej> | olliej: don't feed the trolls |
| 03:59 | <roc> | the big practical reason to introduce new tags is when new kinds of content need a specific API |
| 03:59 | <othermaciej> | roc: you probably shouldn't feed the trolls either |
| 04:01 | <roc> | This is important. Someone is *WRONG* on the Internet. |
| 04:02 | <famicom> | actually, im listening to roc |
| 04:02 | <olliej> | hehehe |
| 04:02 | <MikeSmith> | othermaciej, olliej - so did I read correctly that the "Add to Home Screen" feature on the iPhone is implemented using ApplicationCache from HTML5? |
| 04:02 | <famicom> | plus, im listening to your arguments, because they all contain good points and some substance |
| 04:02 | <olliej> | i have no idea |
| 04:03 | <famicom> | but was far as <tag type="h1"> goes |
| 04:03 | <othermaciej> | MikeSmith: when you "add to home screen", then if there is an HTML5 application cache manifest it takes effect |
| 04:03 | <MikeSmith> | OK |
| 04:03 | <othermaciej> | MikeSmith: we don't invent an application cache when none is specified |
| 04:03 | <MikeSmith> | sure, I understand that part |
| 04:03 | <famicom> | the <tag type="" would be redudant, because the < allready defines a tag |
| 04:04 | <othermaciej> | roc: all right, tell him how wrong he is |
| 04:05 | <famicom> | othermaciej please me more respectfull of other people's opinions |
| 04:05 | <othermaciej> | famicom: roc is the one who said you were wrong! |
| 04:07 | <famicom> | othermaciej you once again confirmed it and reinforced it by adding the word "how" |
| 04:07 | <famicom> | it's all about semantics baby! |
| 04:07 | <othermaciej> | famicom: I was being respectful of roc's opinion |
| 04:08 | <famicom> | hah, this is fun |
| 04:10 | <othermaciej> | famicom: here is the short version of "why add new tags" |
| 04:10 | <othermaciej> | there are basically two reasons: |
| 04:10 | <othermaciej> | 1) To better express the semantics of Web documents and Web applications; the face of the Web has changed since 1998 when HTML 4.01 was published, and it is valuable to express the constructs of 2008-style Web sites, and not just what we had in 1998 |
| 04:11 | <othermaciej> | 2) To add functionality and behavior that many agree should be a basic part of the open Web platform (such as multimedia support) |
| 04:11 | <othermaciej> | given those goals, new tags are often a cleaner choice than new attributes on existing tags |
| 04:11 | <othermaciej> | and as you say yourself, it's the same amount of additions either way |
| 04:12 | <othermaciej> | so you may as well do it the cleaner way, with new tags |
| 04:12 | <famicom> | allright |
| 04:12 | <othermaciej> | HTML5 does also allow for extending semantics, using the class="" attribute and data- attributes |
| 04:12 | <famicom> | 1 |
| 04:13 | <othermaciej> | it's unlikely that the main designers of HTML5 will be convinced that either of these goals is wrong, or that minimum number of tags is a more important goal |
| 04:13 | <othermaciej> | most people working on HTML5 try to follow these Design Principles: http://www.w3.org/TR/html-design-principles/ |
| 04:15 | <othermaciej> | I suggest reading it to get a feel for where HTML5 people are coming from |
| 04:15 | <famicom> | yup |
| 04:16 | <famicom> | right now im just checking the water for the generall attitude + where its coming from |
| 04:16 | <famicom> | people wise that is |
| 04:17 | <othermaciej> | it comes from acceptance of shared design goals |
| 04:17 | <othermaciej> | not so much from specific people |
| 04:29 | <famicom> | sure |
| 04:29 | <famicom> | in a perfect world perhaps |
| 04:29 | <famicom> | same as all wikipedia articles are written without a bias |
| 08:52 | <hsivonen> | any recommendations of a mercurial tutorial for cvs/svn dummies? |
| 08:57 | <roc> | have you read the hgbook? |
| 08:57 | <roc> | it's very good |
| 08:57 | <hsivonen> | roc: I haven't. thanks |
| 09:38 | <annevk2> | Hixie, so currently the sync stuff and the async stuff happily uses the same path, I guess if I used event loops that would all have to if/elsed :/ |
| 09:42 | <olliej> | sigh |
| 09:42 | <olliej> | the number of people who think gears is a good thing saddens me |
| 09:42 | <Hixie> | annevk2: so it's not sync, it's just that you don't define when the events fire :-) |
| 09:43 | <Hixie> | olliej: what is it they think is good? |
| 09:43 | <olliej> | Hixie: things that html5 supports |
| 09:43 | <olliej> | Hixie: especially the offline storage stuff |
| 09:43 | <Hixie> | so what's the problem with people thinking html is good? |
| 09:44 | <olliej> | Hixie: it will be good when we have safari and firefox release versions that simultaneously support all the offline storage stuff |
| 09:44 | <olliej> | Hixie: it's people promoting gears |
| 09:44 | <olliej> | Hixie: rather saying ooh look here's this standard and non-proprietary equivalent |
| 09:45 | <roc> | the funny thing is that as far as I can tell, Firefox and Safari have greater market penetration than Gears |
| 09:45 | <Hixie> | i'm confused by what you consider to be "gears", but that's maybe because the project has changed direction so many times that i don't know what it means anymore :-) |
| 09:45 | <olliej> | roc: yeah i know |
| 09:45 | <Hixie> | last i heard, gears was just supporting html5 |
| 09:45 | <olliej> | roc: i suspect safari 3.1 alone has more market share |
| 09:46 | <olliej> | and it supports at least the database stuff |
| 09:46 | <olliej> | Hixie: it provides a different api |
| 09:46 | <olliej> | Hixie: people code to that api |
| 09:46 | <olliej> | and suddenly your site is dependent on an extension |
| 09:46 | <annevk2> | Hixie, it's not entirely clear to me how to do that, for instance, the UA needs to schedule a set of events during a sync request that are handled directly after the request, just before the method returns |
| 09:46 | olliej | is still depressed that chrome has actively marketed gears rather than the standards that they turned off |
| 09:47 | <Hixie> | annevk2: if it's handled before the method returns, it's handled during the method call, and you can just define it as part of the algorithm |
| 09:47 | <annevk2> | Hixie, but you're saying i need to add if/else for the async case then? |
| 09:48 | <annevk2> | because the method call returns earlier for that, but the rest is the same... |
| 09:48 | <Hixie> | olliej: there is certainly inertia behind existing APIs that Gears supports (and has to continue supporting), just like there is inertia behind safari's extensions |
| 09:48 | <Hixie> | olliej: but so long as we all converge on the long term, i don't see a problem |
| 09:48 | <olliej> | Hixie: yes, but to actively turn off standards support seems somewhat hokey to me |
| 09:49 | <olliej> | oh well |
| 09:49 | <olliej> | the past is the past |
| 09:49 | <Hixie> | olliej: i'm not aware of anything that was turned off (though there were things that won't ported) |
| 09:49 | <Hixie> | weren't, even |
| 09:49 | <annevk2> | I thought maciej said turning those things on required additional effort |
| 09:49 | <Hixie> | though that's just a scheduling issue |
| 09:49 | <olliej> | Hixie: client side databases are supported in the webkit revision chrome is based off |
| 09:49 | <othermaciej> | olliej: they chose to do work to integrate Gears and did not choose to do work to make WebKit's existing HTML5 Database support work |
| 09:49 | <olliej> | which is the wrong way round |
| 09:49 | <Hixie> | olliej: not multiprocess, they're not |
| 09:50 | <olliej> | othermaciej: they claim to be trying to deprecate gears yet it was a major advertising point |
| 09:50 | <annevk2> | seems a bit too early to tell whether Chrome is evil with respect to standards |
| 09:50 | <Hixie> | othermaciej: sure, because google had properties that used that API. that's just sensible. |
| 09:50 | <othermaciej> | olliej: I am not sure all of Google is of one mind about this |
| 09:50 | Hixie | shrugs |
| 09:50 | <othermaciej> | debating it here also does not seem fruitful |
| 09:51 | Hixie | wasn't really aware of _any_ advertising for chrome, let alone advertising in favour of gears over standards |
| 09:51 | <Hixie> | like i said, last i heard, gears was just working on html5 stuff |
| 09:51 | <othermaciej> | I think more than bundling Gears, the prominent mention of Gears in the marketing campaign was what seemed weird |
| 09:52 | <hsivonen> | Hixie: doesn't using the HTML5 stuff in Chrome require access via a gears-specific object? |
| 09:52 | <hsivonen> | Hixie: so to migrate sites, the sites need to change |
| 09:52 | <othermaciej> | Chrome doesn't have any HTML5 stuff |
| 09:52 | <othermaciej> | or at least |
| 09:52 | <othermaciej> | not the Gears-equivalent HTML5 things |
| 09:52 | <othermaciej> | (not <video> or <audio> either which were in the version of WebKit their are based on) |
| 09:52 | <hsivonen> | I meant HTML5 stuff as implemented by gears |
| 09:53 | <roc> | the interesting question is really when, if ever, Google properties will use HTML5 APIs instead of Gears APIs where they overlap |
| 09:53 | <Hixie> | hsivonen: it's not html5 stuff if it's not as per the spec. but i don't think anything has shipped since they said they were giving up on their own apis and making html5 stuff only |
| 09:53 | <othermaciej> | they have legacy Gears APIs provided by a bundled Gears extension that you access through a Gears-specific object with Gears-specific APIs |
| 09:53 | <hsivonen> | ok. I though they had the HTML5 API with a non-standard entry point |
| 09:54 | <Hixie> | hsivonen: it's not html5 if it has a non-standard entry point |
| 09:54 | <othermaciej> | their APIs fail to match in ways other than the entry point |
| 09:54 | <Hixie> | hsivonen: it's like saying fruit juice is "water" :-) |
| 09:54 | hsivonen | thought some Google presentation video suggested a copy of the HTML5 api might appear under a non-standard entry point |
| 09:54 | <othermaciej> | (so porting Google properties from Gears APIs to standard APIs might be nontrivial) |
| 09:55 | <Hixie> | hsivonen: oh, that's possible |
| 09:55 | <hsivonen> | Hixie: well, it's not standard if you need a non-standard entry point, but there's still a practical difference between obtaining a standard interface in a non-standard way and obtaining a non-standard interface in a non-standard way |
| 09:55 | <annevk2> | othermaciej, btw, I saw somewhere a comment to the effect that Chrome was pre-Safari 3.1 |
| 09:56 | <Hixie> | anyway |
| 09:56 | Hixie | goes back to trying to work out what <select> is |
| 09:56 | <hsivonen> | is there some kind of chart of all WebKit forks/branches relative to Safari? |
| 09:56 | <othermaciej> | I believe they have a version of WebKit based on the same as the one that is in Safari 3.1 |
| 09:56 | <othermaciej> | *had |
| 09:56 | <othermaciej> | for their initial release |
| 09:56 | <othermaciej> | with some selected changes from newer WebKit revisions backported |
| 09:57 | <othermaciej> | and some advanced features left disabled, since they had not implemented the back end |
| 09:57 | <annevk2> | Hixie, from what other Google employees told me Gears will always need the non-standard entry point, but hopefully you're right |
| 09:57 | <othermaciej> | the ones I am aware of are Web Fonts, <audio>/<video>, HTML5 database, and text-shadow |
| 09:58 | <Hixie> | annevk2: when did you hear that? |
| 09:58 | <annevk2> | othermaciej, http://code.google.com/p/chromium/issues/detail?id=1533#c1 says pre-Safari 3.1 (via http://googlechromereleases.blogspot.com/ ) |
| 09:58 | <annevk2> | Hixie, last week at The Ajax Experience; I believe from Brad Neuberg |
| 09:59 | <Hixie> | ah, i should speak to brad. that's not what i had understood. |
| 10:00 | <othermaciej> | annevk2: engineers from the Chrome team have told me it was essentially the same as what was in 3.1 (though 3.1 has had security updates) |
| 10:00 | <othermaciej> | annevk2: their current trunk is now only a month behind WebKit trunk though |
| 10:00 | <othermaciej> | I believe the general plan is to get completely in sync and do WebKit work out of webkit.org |
| 10:01 | <annevk2> | nice |
| 10:04 | <othermaciej> | anyway what Google does with their Web properties once at least one release browser supports the HTML5 versions of all three of the original core Gears features will show what they really think of standards more so than what they chose to do with Chrome or Gears |
| 10:04 | <othermaciej> | IMO |
| 10:05 | <Hixie> | http://google.com/privacy/ already uses html5, as do a number of other google sites |
| 10:06 | <Hixie> | the bigger properties will take proportionally longer |
| 10:06 | hsivonen | wonders if the Nokia Widget platform version of WebKit is the same as in their S60 Browser |
| 10:06 | <othermaciej> | does that use any HTML5 features other than the doctype? |
| 10:07 | <Hixie> | i don't think it uses anything that wasn't valid in html4 other than the doctype and the charset declaration |
| 10:07 | <Hixie> | but that's not really the point |
| 10:07 | <Hixie> | there's very little that wasn't in html4 that works reliably in IE yet |
| 10:08 | <Hixie> | and that's the target, along with the other major browsers |
| 10:08 | <roc> | there isn't much enthusiasm for implementing the HTML5 SQL stuff in Gecko so I don't think we'll be able to test Google's goodness anytime soon |
| 10:09 | <othermaciej> | well, we'll see what happens once workers and appcache are in a shipping Safari then |
| 10:09 | <othermaciej> | since it seems most likely to hit the trifecta first |
| 10:09 | <othermaciej> | we should convert webkit.org to html5 |
| 10:09 | <othermaciej> | but that will require wrestling with wordpress for some of it |
| 10:09 | <othermaciej> | I gotta go to bed |
| 10:10 | <Hixie> | nn |
| 10:10 | <roc> | Hixie: the thing is, arguments about the importance of supporting IE+gears are a little flat when IE+Gears has much lower market penetration than Firefox+Safari |
| 10:10 | <hsivonen> | roc: change from http://intertwingly.net/blog/2008/03/07/Design-By-Attrition#c1205011800 ? |
| 10:11 | <roc> | Perhaps. I have no idea who Hixie was referring to. |
| 10:12 | <Hixie> | roc: the argument is about supporting IE alone |
| 10:13 | <roc> | hsivonen: note that below, sayrer says "I don’t think my employer supported it. Can you point to evidence of this, ..." ... and none is forthcoming |
| 10:14 | <om_sleep> | Apple representatives (including me) supported the idea of all Gears features being part of Web standards so they could be implemented by browsers |
| 10:14 | roc | himself does not object to SQL in HTML5 |
| 10:14 | <om_sleep> | I don't believe we were specific as to which standard they should be in |
| 10:14 | <om_sleep> | this was in response to being asked to bundle Gears with various Apple products |
| 10:15 | <om_sleep> | to which we said no |
| 10:15 | <Hixie> | i don't recall who it was who was pushing for sql from the mozilla side of things |
| 10:16 | <om_sleep> | I do not really see the problem with a SQL API being available to Web content, or why anyone who wants a strong and competitive Web platform would be against it |
| 10:16 | <om_sleep> | I believe it is easier to implement than either the appcache or Workers |
| 10:16 | <roc> | the problem is the lack of definition of exactly what SQL it is |
| 10:17 | <roc> | saying it's whatever SQLite does is problematic |
| 10:17 | <roc> | well, that's one problem |
| 10:17 | <othermaciej> | that is true, but it's hard to define exactly what SQL is, and unwise (it seems to me) to withhold the feature until someone does that work |
| 10:18 | <Hixie> | my plan is to spec the common subset of the first two implementations |
| 10:18 | <Hixie> | so the first two implementations, whatever they are, get to decide what the language is |
| 10:18 | <hsivonen> | at least saying that one must bundle SQLite would be better than not saying so but bundling SQLite being de facto required anyway |
| 10:18 | <roc> | I'm not the right person to have this conversation since I'm not actually objecting to it |
| 10:20 | <othermaciej> | you did bring it up though |
| 10:21 | <othermaciej> | prior to that, Gecko plans vis-a-vis the HTML5 SQL API were not a topic of conversation |
| 10:22 | <roc> | I thought the information might be relevant, even though I can't fully explain it. Sorry. |
| 10:23 | <othermaciej> | it would be valuable if whoever at Mozilla has concerns were to communicate them, as it would help improve HTML5 |
| 10:23 | <virtuelv> | othermaciej: any particular reason why additional arguments to the TimerHandler are unspecified? |
| 10:24 | <othermaciej> | virtuelv: the handleTimer method doesn't get any arguments besides the TImer |
| 10:24 | <othermaciej> | roc: btw you may be interested in this proposal I made for a high resolution (and otherwise improved) timer API: http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0009.html |
| 10:24 | <virtuelv> | othermaciej: I realised that, my question is more one of "shouldn't it"? |
| 10:25 | <othermaciej> | virtuelv: I know setTimeout (at least in Gecko and WebKit, but not in IE) will pass extra arguments that were given to setTimeout to the callback function |
| 10:25 | <virtuelv> | startTimer(1,true,fade,$('myElement')) |
| 10:25 | <othermaciej> | virtuelv: I don't think that's a particularly great feature |
| 10:25 | <virtuelv> | othermaciej: so does opera, btw |
| 10:26 | <othermaciej> | startTimer(1,true, function() { fade($('myElement')); }); |
| 10:26 | <othermaciej> | or if your JS library has support for making a thunk out of a function bound to arguments, then use that |
| 10:27 | <virtuelv> | I'm not sure I enjoy that syntax very much, though |
| 10:27 | <othermaciej> | I'm not deeply philosophically against it or anything, it just seems a little odd and makes the API hard to extend |
| 10:27 | <othermaciej> | well that's the sort of thing you normally have to do for DOM API callbacks |
| 10:28 | <othermaciej> | like events |
| 10:28 | <virtuelv> | othermaciej: how about: Timer startTimer(in double delay, in Boolean repeat, in TimerHandler handler, in Array argumentlist) |
| 10:29 | <othermaciej> | virtuelv: that doesn't seem better than just passing along the extra arguments |
| 10:29 | <othermaciej> | from the people who do lots of web development who have reviewed this API I have not really gotten requests to support the extra-args thing |
| 10:30 | <Hixie> | i'm with maciej, the argument passing form of setTimeout is poor API design |
| 10:30 | <Hixie> | (as is the string form) |
| 10:31 | <othermaciej> | the string form is lame too, yes |
| 10:31 | <Philip`> | But you'll get memory leaks in IE if you use closures :-( |
| 10:31 | <othermaciej> | saves you a few characters in exchange for losing syntax checking and lexical scope, and effectively invoking eval |
| 10:31 | <Hixie> | Philip`: you won't be able to use this API in IE anyway |
| 10:32 | <roc> | othermaciej: proposal sounds OK with the revisions suggested in the thread. But I don't think this is the ultimate solution for JS animations |
| 10:32 | <othermaciej> | roc: animations are not the primary use case for this |
| 10:32 | <othermaciej> | (IMO) |
| 10:33 | <othermaciej> | true zero-delay timers are the most important use case |
| 10:33 | <Hixie> | are we sure we can't repurpose setTimeout() for those? maybe with some backoff logic in setTimeout() to prevent cpu hogging? |
| 10:34 | <roc> | that use case would be served by a single API equivalent to setTimeout(0) |
| 10:34 | <Hixie> | it seems like whatever caused setTimeout() to end up with a clamp will end up happening to this API too |
| 10:34 | <Hixie> | (i.e. I don't see anything that shows lessons having been learnt from setTimeout's clamp) |
| 10:35 | <virtuelv> | Hixie: setTimeout/setInterval is, as othermaciej already noted in the proposal an ugly api |
| 10:35 | <othermaciej> | Hixie: WebKit already has setTimeout(0) as initially 0 with backoff logic |
| 10:36 | <Hixie> | othermaciej: so what's the problem? |
| 10:36 | <othermaciej> | Hixie: the webkit.org version of WebKit |
| 10:36 | <othermaciej> | well apparently the Chrome folks found use cases where lowering the clamp was very helpful despite that |
| 10:36 | <othermaciej> | (though I have yet to hear citations of real sites) |
| 10:36 | <Hixie> | virtuelv: an existing ugly API is better than a redundant clean API with an ugly API as well |
| 10:36 | <othermaciej> | roc: I did propose the even-more-minimal callSoon() |
| 10:37 | <roc> | so it's a tricky situation ... the API seems OK, but it's not ideal for any of its use cases, except I think use case #3 where you clearly have to have a new interface and a Timer object |
| 10:37 | <Hixie> | othermaciej: well we would presumably need more information on exactly what those cases are to determine if we have satisfied the use cases |
| 10:37 | <othermaciej> | Hixie: the Chrome folks seem more interested in changing the clamp to different values than doing a clear study of the benefits and costs of changing setTimeout in various ways |
| 10:37 | <annevk2> | if it's just for having a real 0 initially, I believe Opera has that too |
| 10:38 | <othermaciej> | a new API is the one thing I personally am sure will not break compatibility |
| 10:38 | <othermaciej> | (I'm also pretty sure starting with real 0 and ramping up for nested setTimeout calls is safe, but it doesn't help the case of significantly long-running work that wants to drop back to the event loop often) |
| 10:39 | <Hixie> | well without data we definitely shouldn't write a spec |
| 10:40 | <othermaciej> | the API I proposed has other improvements besides zero-delay |
| 10:40 | <othermaciej> | namely telling you true time elapsed and making it easy to reset a timer's time |
| 10:40 | Philip` | just wants a "draw the next frame to this canvas as fast as possible, but don't bother going faster than the monitor refresh rate" function, and setTimeout doesn't work in practice since it's too slow and you can't tell precisely how much time has elapsed between frames |
| 10:40 | <othermaciej> | which I am told are common use cases in real Web apps |
| 10:41 | <roc> | can't you tell how much time has elapsed using "new Date()"? |
| 10:42 | <virtuelv> | I can agree with the string form being ugly |
| 10:42 | <virtuelv> | roc: new Date() is actually quite slow |
| 10:43 | <Philip`> | roc: If I remember correctly, that was limited to 16ms precision in some(/most/all?) browsers on Windows |
| 10:43 | <othermaciej> | roc: sure, if you saved the date at the time you started the timer or that it last fired |
| 10:43 | <othermaciej> | Philip`: some |
| 10:43 | <virtuelv> | roc: certain windows mobile implementations limit you to 1000ms |
| 10:43 | <roc> | virtuelv, Philip`: those are fixable bugs that don't require new API |
| 10:43 | <virtuelv> | (yes, really) |
| 10:44 | <Philip`> | roc: If they do get fixed without a new API, I'd be happy :-) |
| 10:44 | <roc> | but thanks, that answers my question |
| 10:44 | <virtuelv> | Philip`: perhaps we could have a vsync callback :) |
| 10:44 | <roc> | onpaint |
| 10:45 | <othermaciej> | virtuelv: this function is a handy way to bind arguments in a way that works for any callback API |
| 10:45 | <othermaciej> | function bindArgs(f) |
| 10:45 | <othermaciej> | { |
| 10:45 | <othermaciej> | var args = Array.prototype.slice.call(arguments, 1); |
| 10:45 | <othermaciej> | return function() { f.apply(null, args); } |
| 10:45 | <othermaciej> | } |
| 10:45 | <othermaciej> | (though I guess you can't get any real args passed to the callback that way) |
| 10:46 | <Philip`> | virtuelv: That's probably bad, because if it takes 1/59s to render the frame and the vsync rate is 60Hz, it'd only render at 30fps if each frame is locked to the vsync, which is uglier than rendering at 59fps and skipping one frame a second |
| 10:46 | virtuelv | points at the smiley |
| 10:46 | <Philip`> | vsync only works if you're pretty certain you're always going to be rendering faster than that |
| 10:47 | <virtuelv> | the high-resolution timer stuff is moot for the next couple of years anyway |
| 10:47 | <othermaciej> | virtuelv: this version is better: |
| 10:47 | <othermaciej> | function bindArgs(f) |
| 10:47 | <othermaciej> | { |
| 10:47 | <othermaciej> | var savedArgs = Array.prototype.slice.call(arguments, 1); |
| 10:47 | <othermaciej> | return function() { f.apply(null, Array.prototype.concat.call(arguments, savedArgs)); } |
| 10:47 | <othermaciej> | } |
| 10:47 | <othermaciej> | (completely untested though) |
| 10:48 | <virtuelv> | othermaciej: I can live with the closure |
| 10:48 | <Hixie> | what kind of black magic is Array.prototype.concat.call |
| 10:48 | <Hixie> | oh is this because arguments isn't an Array? |
| 10:48 | <othermaciej> | yeah |
| 10:48 | <Hixie> | but it's "generic" enough to work with Array methods? |
| 10:49 | <othermaciej> | you can write that a lot more simply if you prototype-hack arguments to have slice and concat on its prototype |
| 10:49 | Hixie | mumbles something about multimethods and interfaces and superior languages |
| 10:49 | <othermaciej> | I believe ES3.1 proposes to make arguments support the Array prototype methods |
| 10:49 | <othermaciej> | which would make that a lot simpler to write |
| 10:49 | <virtuelv> | Philip`: my perception is that browsers struggle getting anything over 30-40 fps anyhow for anything reasonably complex |
| 10:50 | <othermaciej> | making bindArgs take an array of extra arguments would make it a bit simpler too |
| 10:52 | <Philip`> | virtuelv: Chrome gets >100fps on Canvex, which is reasonably complex |
| 10:52 | <Philip`> | but that's only possible because they stopped clamping setTimeout (or setInterval or whatever it is) |
| 10:53 | <othermaciej> | they reduced the clamp on both of those to 1ms |
| 10:53 | <othermaciej> | they will be trying 4ms next |
| 10:53 | <virtuelv> | they also got "yelled" at by Intel for the 1ms timeout, no? |
| 10:54 | <othermaciej> | well, it's more the technique they use to achieve timer precision at all |
| 10:54 | <othermaciej> | on Windows, to get accurate timers, you have to make a system call that increases the whole system's power consumption |
| 10:54 | <othermaciej> | at least on XP |
| 10:54 | <othermaciej> | because Microsoft can't code their way out of a wet paper bag |
| 10:54 | <othermaciej> | the webkit.org version of WebKit also does the timer accuracy thing, but we only leave it on while short delay timers are pending |
| 10:55 | <othermaciej> | (and for a little after, for hysteresis) |
| 10:55 | <othermaciej> | and no one has complained |
| 10:55 | <othermaciej> | (on Windows that is; on Mac and Linux there's no need for such nonsense to get accurate timers) |
| 10:56 | <Philip`> | Sounds like a complex optimisation problem, with performance on one axis and getting-yelled-at-by-other-developers on the other |
| 10:56 | <othermaciej> | it's not that hard |
| 10:56 | <othermaciej> | most sites do not have short-delay timers on all the time, at least not on purpose |
| 10:57 | <othermaciej> | it's really the way of working around the suckiness of Windows that needs finesse |
| 10:57 | <othermaciej> | and SafariWin does not drain battery like Chrome does in that regard |
| 10:58 | <virtuelv> | Philip`: canvas is one thing, DOM manipulation is another |
| 10:58 | <Philip`> | virtuelv: DOM is boring, so canvas is the only thing I'm interested in :-) |
| 11:16 | <virtuelv> | speaking of canvas, will anything come of Sjoerd's proposal? |
| 11:19 | <olliej> | virtuelv: given there has been absolutely no form of consensus it's hard to say |
| 11:19 | <virtuelv> | context.fillStyle = imageData.slice(0,3) seems handy |
| 11:20 | <olliej> | virtuelv: imageData.data.slice isn't valid -- CanvasPixelArray is not an Array (although i suppose it could be) |
| 11:20 | <olliej> | virtuelv: but that's not actually a real use case |
| 11:20 | <Philip`> | virtuelv: Handiness seems irrelevant, since you can just write a function to convert whatever data structure you have into a rgb(...) string |
| 11:20 | <othermaciej> | olliej: though you could rebind slice to apply |
| 11:20 | <olliej> | virtuelv: the specific issue that we're looking at is the need to convert a numberic colour representation in to an rgb() string |
| 11:20 | <virtuelv> | Philip`: and it'd be slower than neccesary |
| 11:20 | <othermaciej> | Array.prototype.slice.call(imageData.data, 0, 3) |
| 11:21 | <othermaciej> | wouldn't be very fast |
| 11:21 | <othermaciej> | making and parsing the string is a waste |
| 11:21 | <Philip`> | and fillStyle = rgb(1, 0, 0) (where 'rgb' converts to string) is no harder to write than fillStyle = [1, 0, 0] and also is more flexible since you can do HSL and everything |
| 11:21 | <othermaciej> | I think being able to pass 4 rgba values separately would be useful, but I can't say for sure how common it is to have an rgb triple or rgba quad that's not already in an array |
| 11:21 | <Philip`> | so it seems performance is the only real concern |
| 11:24 | <Hixie> | before we start adding APIs to canvas to do microsecond optimisations, lets see about getting the rest of the spec implemented |
| 11:51 | <Philip`> | What's the shortest string that can be appended to any prefix of a well-formed XML document, to make it ill-formed? |
| 11:53 | <Philip`> | (e.g. if I'm serialising to XML and then at some arbitrary point decide that I want to stop (e.g. because of an error) and make sure the output is not well-formed, and just have an opportunity to print some string onto the end to make sure it won't be accidentally parseable) |
| 11:53 | <Dashiva> | Random guess, ]]>\0 |
| 11:54 | <Philip`> | Oh |
| 11:54 | <Philip`> | Even just \0 should do it |
| 11:54 | <Philip`> | because that doesn't seem to be allowed even in CDATA blocks |
| 11:55 | <Philip`> | That's simpler than I expected - thanks :-) |
| 12:01 | <Philip`> | Actually, I don't know why I was thinking it was a problem - I could just add some plain text (like "Error") onto the end, and it'll never be well-formed |
| 13:03 | <Philip`> | Urgh... How can I make a web service that accepts HTML and returns equivalent XHTML, without making the site vulnerable to XSS attacks when external sites make users post forms to the service? |
| 13:05 | <Philip`> | Would it be safe to require the request content-type to be text/html, and hope that nobody implements the bit of HTML4 that says <form enctype=text/html> should send content-type: text/html? |
| 13:05 | <annevk2> | what is the vulnerability? |
| 13:06 | <Philip`> | (Oh, actually, HTML4 doesn't really say it should send with text/html - it's explicitly unspecified behaviour) |
| 13:08 | <Philip`> | annevk2: The problem is <form method=post action=http://mysite/html-to-xhtml/ enctype=multipart/form-data><input name=x value="<script>alert(document.cookie)</script>"><input type=submit></form> which would execute the script in my domain, since the service returns application/xhtml+xml content |
| 13:09 | <annevk2> | oh, you should run uch a service on its own domain I think |
| 13:09 | <Philip`> | That's ugly, so I don't want to do that |
| 13:09 | <Philip`> | And I can't even think of one domain name yet, so I'm just using the IP address :-p |
| 13:11 | <annevk2> | well, it's also necessary as far as I can tell to protect yourself |
| 13:11 | <annevk2> | I might be able to give you some subdomain of html5.org, iirc I set DNS for subdomains in some way |
| 13:16 | <Philip`> | I'd be happier to just require the request to be text/html, since that seems to work in practice as far as I can tell |
| 13:17 | <annevk2> | oh, you require POST? |
| 13:17 | <Philip`> | Yes |
| 13:17 | <annevk2> | that helps, yes |
| 13:18 | <Philip`> | (GET requests don't even get sent to the same server process) |
| 13:18 | <Philip`> | (I'm making this slightly awkward on purpose, because that's more educational) |
| 13:19 | <hsivonen> | Philip`: XSS concern was the reason why I haven't offered the service as part of parsetree.validator.nu |
| 13:20 | <hsivonen> | actually, livedom.validator.nu has the same XSS exposure |
| 13:20 | <hsivonen> | so the actual concern is that running an open proxy might attract the wrong kind of attention |
| 13:21 | <Philip`> | I require the content to be sent in the request, rather than sending a URL that the service downloads, which should prevent that proxy behaviour |
| 13:23 | <Philip`> | (and also prevents many DOS attacks, since it avoids multiplying the attacker's effort) |
| 14:17 | annevk2 | grmbls at "event loop" |
| 14:18 | annevk2 | wonders if he should copy "fetch" from HTML5 too |
| 14:19 | <annevk2> | I like HTML5 defining all this stuff, but architecturally it's a bit of a mess, but maybe that's ok |
| 14:23 | <virtuelv> | annevk2: I still want the ByteArray |
| 14:24 | <annevk2> | virtuelv, me too! :) |
| 14:40 | <annevk2> | oops, fetch assumes async |
| 16:31 | <annevk2> | sicking, yo? |
| 16:32 | <annevk2> | sicking, I'm wondering whether "remove cache entries" should remove everything regardless of "credentials flag" or not |
| 16:32 | <annevk2> | weinig, ^^ |
| 17:31 | <sicking> | annevk2, hm |
| 17:31 | <sicking> | annevk2, i don't implement the remove stuff yet, so haven't thought about it |
| 17:31 | <sicking> | annevk2, seems like the safest is to remove more rather than less |
| 17:31 | <sicking> | annevk2, should be a rare case anyway that something is removed, right? |
| 17:43 | <hsivonen> | hmm. it seems that HTML fragments in Gecko get an ancestor chain of context instead of just a parent |
| 17:43 | <hsivonen> | I wonder if it makes any difference in practice |
| 18:06 | <sicking> | hsivonen, IMHO we should do neither |
| 18:06 | <sicking> | hsivonen, but yes, we build the whole chain |
| 18:06 | <sicking> | hsivonen, partially because the parser is built to parse whole documents |
| 18:10 | <sicking> | hsivonen, actually, this is something that we should chat about, seeing that you are quite experienced with parsing HTML5 at this point :) |
| 18:11 | <sicking> | hsivonen, in which cases does it actually make a difference to use the parent as a context, vs. using no context? |
| 18:58 | <Philip`> | hsivonen: It's a bit annoying that the tokeniser has a finally{} block that calls endDocument on the contentHandler which might be an XmlSerializer which calls writer.close(), because that closes the output stream and prevents me writing some error notification after an exception was thrown from the parser |
| 19:33 | <annevk2> | sicking, yeah, it's a rare case |
| 19:33 | <annevk2> | sicking, basically, when things don't go as expected |
| 19:33 | <sicking> | annevk2, right, so nuke it all IMHO |
| 19:33 | <sicking> | annevk2, btw, is 'with credentials' part of the primary key now? |
| 19:34 | <annevk2> | ok, I'll leave it as is then, although I might inline "remove cache entries" at some point |
| 19:34 | <sicking> | annevk2, (or intended to be) |
| 19:34 | <annevk2> | sicking, I haven't checked that change in |
| 19:34 | <annevk2> | sicking, I was waiting for you to see what to do with "remove cache entries" before making that change |
| 19:34 | <sicking> | ok |
| 19:34 | <sicking> | so what is the intent after you have checked in? |
| 19:35 | <annevk2> | that it's part of the primary key |
| 19:35 | <sicking> | sweet |
| 19:36 | <annevk2> | the optimization for non credentialed requests doesn't seem worth the effort |
| 19:36 | <sicking> | agreed |
| 19:36 | <sicking> | the alternative is to specify the semantic meaning of the various headers |
| 19:36 | <sicking> | and then let the spec cache as it pleases |
| 19:36 | <sicking> | err |
| 19:37 | <sicking> | and then let the spec implementation as it pleases |
| 19:39 | <annevk2> | I rather have it like this it's crystal clear what is to be done |
| 19:39 | <sicking> | ok |
| 20:17 | <annevk2> | sicking, I checked in the change for allowing HEAD and made the credentials flag part of the primary key |
| 20:20 | <annevk2> | http://econym.org.uk/gmap/chrome.htm#winding correct criticism? |
| 20:22 | <annevk2> | came from this thread: http://groups.google.com/group/Google-Maps-API/browse_thread/thread/562c3614e8ba034c |
| 20:23 | <Hixie> | annevk2: i'd love for this stuff to be in its own spec |
| 20:23 | <Hixie> | Philip`: easiest way to avoid xss problems is to avoid having anything on the domain that is valuable |
| 20:26 | <Philip`> | Hixie: But I always complain about other people's XSS holes even when they're revealing no data of any value whatsoever, so I mustn't have the same problem on my own site |
| 20:32 | <Hixie> | Content-Disposition might be a solution then |
| 20:32 | <Hixie> | or returning the data as the wrong mime type |
| 20:35 | <Philip`> | Is there a practical problem if I require the request to be text/html? (I can't see any way to send that via a <form>) |
| 20:36 | <Philip`> | (and if someone changes HTML or browsers in the future so they can send text/html, that's their fault for introducing security vulnerabilities in perfectly adequate web sites) |
| 20:36 | <annevk2> | if that happens it would require Access Control opt in for cross-site requests |
| 20:37 | <Hixie> | what's zcorpan's e-mail address again? |
| 20:37 | <annevk2> | simonp⊙oc |
| 20:38 | <Hixie> | Philip`: wf2 has a mechanism to upload arbitary files, but i've removed that feature in html5 |
| 20:38 | <Hixie> | annevk2: thx |
| 20:39 | <csarven> | http://www.w3.org/html/wg/html5/#the-address-element "Typically, the address element would be included with other information in a footer element." -- How was this determined? |
| 20:40 | <Hixie> | how do you mean? |
| 20:41 | <csarven> | The "typical" bit. |
| 20:41 | <csarven> | Is that based on verifiable data or just a conjecture? |
| 20:43 | <Hixie> | conjecture |
| 20:43 | <csarven> | I would venture to say that a good chunk of <address> data is used in the header along with the site logo. |
| 20:44 | <Hixie> | i imagine that happens too |
| 20:44 | <csarven> | I'm actually trying to reverify this: http://www.csarven.ca/logo-identity-in-address-and-document-heading#address_for_documents_contact_information |
| 20:46 | <csarven> | Hixie Got an opinion on that (or the whole article)? Agree/disagree? |
| 20:46 | <Hixie> | logos don't really seem to belong there |
| 20:46 | <csarven> | In any case, I would suggest to rewrite the part that suggests where <address> may "typically" occur. |
| 20:46 | <Hixie> | but otherwise sure |
| 20:47 | <Hixie> | by the time the spec is done, that sentence will hopefully be true :-) |
| 20:48 | <csarven> | I tend to agree that <img> is a bit misplaced there |
| 20:48 | <Philip`> | Hixie: Hmm, I suppose the ability to upload arbitrary files could be a useful feature, so I might as well support it and not make it be an XSS hole, since Content-Disposition seems like an adequately non-evil way of preventing browsers executing scripts from the response, so that sounds good :-) |
| 20:49 | <csarven> | Which is not so good as microformats are concerned since doing <address class="vcard"> and <img class="logo"> goes along pretty well as far as hCard is concerned. |
| 20:49 | <erlehmann> | WHAT |
| 20:50 | <csarven> | erlehmann Directed at me? |
| 20:51 | <Hixie> | Philip`: :-) |
| 20:51 | <erlehmann> | csarven: so, only for fun ;) |
| 21:17 | <Philip`> | Hmph, Firefox (3) doesn't accept xhr.open('POST', '') |
| 21:17 | <Philip`> | (NS_ERROR_ILLEGAL_VALUE, it says) |
| 21:29 | <Philip`> | http://92.243.11.39/html-to-xhtml/ - hooray, it's a thing |
| 21:29 | <Philip`> | It would be a pretty pointless thing, except the point was to encourage me to set up the server and it has mostly succeeded at that |
| 21:30 | <Philip`> | But I still need a witty domain name |
| 21:30 | <csarven> | Philip` <link> gets translated to <link></link> |
| 21:31 | <Philip`> | csarven: That's intentional |
| 21:31 | <Philip`> | (hsivonen's intent, in particular) |
| 21:31 | <csarven> | Oh alright, I suppose true for all empty/null elements? Appears to be for <img> as well. |
| 21:32 | <Philip`> | Yes - the serialiser always simply emits a start tag, then the (possibly empty) content, then the end tag |
| 21:33 | <Philip`> | which is a perfectly valid way to serialise XML, even if it's a bit weird :-) |
| 21:36 | <Philip`> | The inability to return a 500/etc error code after you've started sending the response seems like an unfortunate missing feature in HTTP :-( |
| 21:36 | <Philip`> | (unless it's a feature that exists but I've failed to notice) |
| 21:40 | <csarven> | Hixie Perhaps it can be argued that <img> *is* contextually valid inside <address>, since it provides contact information for the document. That is, the image (photo/logo) outlines what the entity looks like - which is a form of identifying an entity in order to communicate. |
| 21:41 | <Hixie> | csarven: i suppose it could also be argued that the whole document belongs in <address> since it provides a way to recognise the document, which is a form of identity...? |
| 21:42 | <csarven> | iff the information in the rest of the document is 'about' the identity. |
| 21:43 | <Hixie> | the idea of <address> is to put contact information in there... the less information ends up there the better, since that way it's very clear. |
| 21:44 | <csarven> | microformats touched on this with 'representative hCard's as it distinguishes an identity that is outlined in <address> from the author or contact information of the page. |
| 21:47 | <csarven> | I understand the argument about keeping it clear and focusing on common contact information like email, phone, physical address (iff need to contact by snail mail), however, the argument also works for existing practises in the wild where an entity stamps itself not just with that information but also with its logo/photo. In a way, logo/photo is not easily separated. |
| 21:48 | <csarven> | As I've mentioned earlier, the typical placement of <address> information can be found anywhere (e.g., header) |
| 21:51 | Hixie | shrugs |
| 21:51 | <Hixie> | i wish we could just drop <address> altogether |
| 21:52 | <Hixie> | typically though i have most often seen that element in the footer of pages |
| 21:52 | <Hixie> | and i think that makes sense |
| 21:53 | <csarven> | I agree to some extent, however, it is very common to find a site put up its logo and contact information at the top of the page. If this is treated as <address> then they don't have to repeat this information at the bottom of the page. |
| 21:53 | Hixie | grumbles about IE having select.options === select |
| 21:54 | <Hixie> | csarven: they don't have to repeat that information even if they don't use address |
| 21:54 | <Hixie> | csarven: they don't have to use address |
| 21:55 | <csarven> | Ok, let's put this aside for a sec and look into two things and perhaps they can reveal some insight. |
| 21:55 | <csarven> | 1. Do we agre that logos should use <img> ? |
| 21:55 | <Hixie> | as opposed to what? |
| 21:55 | <csarven> | CSS |
| 21:55 | <Hixie> | either is fine |
| 21:56 | <csarven> | Well, placing a logo in CSS doesn't help much when you try to print the document. |
| 21:56 | <Hixie> | why? |
| 21:56 | <csarven> | Plus it is not for decoration and rather content oriented. |
| 21:56 | <Hixie> | *shrug* |
| 21:56 | <Hixie> | depends on how it is used |
| 21:56 | <Hixie> | the logo on damowmow.com is decorative |
| 21:57 | <Hixie> | as is the logo on damowmow.com/portal |
| 21:57 | <csarven> | How so? You have it in <img> as opposed to CSS. |
| 21:58 | <Hixie> | there's fundamentally very little difference between having <img alt="..." src=x> and having <span>...</span> with span { content: url(x); } |
| 21:58 | <Hixie> | it's an <img> on damowmow.com/ and in CSS on damowmow.com/portal/ |
| 21:59 | <csarven> | I disagree because if an image is for decoration (as opposed to having contextual meaning in the document) then it should be in CSS, no? |
| 22:00 | <Hixie> | doesn't really matter |
| 22:00 | <Hixie> | if it's page-specific, it's easier to have it in the markup |
| 22:00 | <Hixie> | if it's site-wide, the css |
| 22:00 | <csarven> | If you identify yourself with the cat, then that is your logo. That is your branding. It is not just for illustration for the page because the cat has a meaning. |
| 22:01 | <Hixie> | coca cola identifies itself with the colour red, that is its branding. does that mean we should put the red into the markup? |
| 22:02 | <Hixie> | you are attempting to layer black-and-white requirements on a fuzzy and judgement-call-laden area. |
| 22:02 | <csarven> | Of course not. The colour red is part of their brand guidelines. The 'logo' is the whole (the name 'coca-cola' and the red and white..). Coca-cola doesn't brand itself out only with the colour red. |
| 22:03 | <Hixie> | google brands itself using a specific sequence of colours on the letters of words using a specific font |
| 22:04 | <Hixie> | to the point where a random word, without the word "google" anywhere, using the right font and colours, can be immediately identified as google-related |
| 22:04 | <Hixie> | should we use <font color face> for such words? |
| 22:05 | <Dashiva> | <googleword>Apple</googleword> |
| 22:05 | <csarven> | No we should not because as part of their guidelines, the logo (image, typography, sizes, objects...) is unique. |
| 22:06 | <csarven> | In order to be consistent and maintain that on all platforms, they need to use an image. |
| 22:06 | <Hixie> | there are many cases where we don't care if it doesn't turn out quite right |
| 22:06 | <Hixie> | especially on our intranet site |
| 22:06 | <Hixie> | in such cases there is no image |
| 22:07 | <csarven> | That's fine, but that is part Google's branding guidelines, that is, they are not that strict. |
| 22:07 | <Hixie> | ian.hixie.ch's header shows something similar |
| 22:07 | <csarven> | Which is not the case for many orgs. |
| 22:07 | <Hixie> | my point is that this is not clear cut |
| 22:07 | <Hixie> | and people should use their judgement when deciding what to put in css and what to put in html |
| 22:08 | <csarven> | I think logos need to preserved and be consistent and match the guidelines of the org as far as what is allowed and not allowed. |
| 22:08 | <csarven> | If consistency is not an issue for an org, sure, CSS will do. |
| 22:09 | <csarven> | In all other cases, <img> is more appropriate IMHO. |
| 22:10 | <Hixie> | you're not going to get much more consistency from img than from css |
| 22:11 | <csarven> | 2. (Let's say we are using <img> for logos for the sake of this discussion) Can we agree that <h1><img></h1> is inappropriate since the document is not 'about' the contents of the image. (e.g., If I'm writing an article about cats, it should say something like <h1>I love cats</h1> instead of having <h1><img></h1>) |
| 22:13 | <csarven> | Here, I'm talking about the proper use of <h1>. |
| 22:14 | <Hixie> | depends what the img src is |
| 22:15 | <Hixie> | <h1><img src="googlelogo.png" alt="Google"></h1> is quite appropriate |
| 22:15 | <csarven> | Agreed, for that case. |
| 22:16 | <csarven> | http://damowmow.com is okay too in that case. |
| 22:17 | <csarven> | I'm referring to an ordinary document... say a blog post, a wiki page. |
| 22:17 | <Hixie> | <h1><img src="wikipedia.png" alt="Wikipedia"></h1> seems fine too |
| 22:17 | <Hixie> | also <h1><img src="blogheader.png" alt="Hixie's Natural Log"></h1> |
| 22:18 | <Hixie> | in all these caes, it would be fine to just replace the text with an image using CSS, too |
| 22:18 | <Hixie> | where are you going with this? |
| 22:18 | <csarven> | Is the rest of the document *about* "Wikipedia"? |
| 22:18 | <Hixie> | no, the <h1> here is the site header |
| 22:18 | <Hixie> | the <h2> would be the page header |
| 22:19 | <csarven> | Site header? |
| 22:19 | <csarven> | Why would <h1> speak for the rest of the site as opposed to the current document? |
| 22:19 | <Hixie> | how else do you give a site header? |
| 22:19 | <csarven> | Can you give me an example of a 'side header' content? |
| 22:19 | <Hixie> | imagine the site as one big page, which was then chopped into multiple smaller pages |
| 22:19 | <Hixie> | sure |
| 22:20 | <gsnedders> | csarven: It's the highest level header. The fact that it applies to more than just that page is irrelevant |
| 22:20 | <Hixie> | the html5 spec's multipage version |
| 22:21 | <gsnedders> | On an unrelated note, I'm amazed people haven't bitched about all the @id in HTML 5 changing |
| 22:21 | <gsnedders> | (or at least, not that I've heard) |
| 22:21 | <csarven> | Hixie "<h1>HTML 5</h1>" ? |
| 22:21 | <Hixie> | gsnedders: one person bitched to me privately because it totally broke the multipage links |
| 22:21 | <Hixie> | csarven: right |
| 22:22 | <gsnedders> | Hixie: But only one person? |
| 22:22 | <csarven> | IMO, that should have been marked as: <h1>HTML 5 <span>Draft Recommendation � 6 October 2008</span></h1> |
| 22:23 | <Hixie> | gsnedders: so far |
| 22:23 | <Hixie> | csarven: well, the <div class="head"> should be a <header>, but that's another problem |
| 22:23 | <csarven> | The reason is simply because when I'm about to read a document, <h1> should indicate what I'm about to read. |
| 22:23 | <Philip`> | Hasn't it broken single-page links just as much as multipage links? |
| 22:23 | <Hixie> | Philip`: yes |
| 22:23 | <Philip`> | since in both cases it'll just go to the top of the page, not the desired target |
| 22:23 | <Hixie> | Philip`: but the guy got a 404 and complained |
| 22:24 | <Hixie> | because the page filenames changed too |
| 22:24 | <csarven> | Hixie Just to be sure, you were referring to http://www.whatwg.org/specs/web-apps/current-work/multipage/ correct? |
| 22:24 | <Hixie> | csarven: yes |
| 22:24 | <csarven> | Is that document used in <object> elsewhere? |
| 22:24 | <Philip`> | Hixie: Oh, I thought it was set up so 404 pages would redirect you |
| 22:24 | <csarven> | Either way, I don't understand what 'site header' means. |
| 22:25 | <Hixie> | Philip`: only if the fragment identifier is recognised |
| 22:25 | <Philip`> | Hixie: Argh, fragment-links.js is broken |
| 22:25 | <csarven> | Hixie Perhaps 'Site header' should be handled by <title>? |
| 22:25 | <Hixie> | csarven: a header that applies to multiple pages |
| 22:26 | <Hixie> | csarven: this is all already discussed in the spec, i don't see anything wrong with what's there currently |
| 22:26 | <Hixie> | csarven: what problem are you trying to solve? |
| 22:26 | <csarven> | Do we have other elements that applies to multiple pages? |
| 22:26 | <Hixie> | i don't understand what you mean by "applies to multiple pages" |
| 22:27 | <csarven> | Hixie http://www.csarven.ca/logo-identity-in-address-and-document-heading |
| 22:27 | <csarven> | [17:29:13] <Hixie> i don't understand what you mean by "applies to multiple pages" -- I was trying to understand [17:28:15] <Hixie> csarven: a header that applies to multiple pages |
| 22:27 | <Hixie> | the header is on multiple pages |
| 22:27 | <Hixie> | just like the "HTML5" header is present on multiple pages |
| 22:27 | <Hixie> | the element itself doesn't apply to multiple pages |
| 22:28 | <Hixie> | it's the header that is present on all those pages |
| 22:28 | <Philip`> | gsnedders: You should have told me that you'd make IDs with "'"s in them :-( |
| 22:28 | <gsnedders> | Philip`: I make IDs with anything allowed in ifragment |
| 22:28 | <gsnedders> | Philip`: It's in the docs! |
| 22:28 | <Hixie> | jesus fricking christ IE's handling of <option> elements is screwed up |
| 22:28 | <Hixie> | it crashes at the slightest problem |
| 22:29 | <csarven> | Hixie What good is it to indicate that a heading is repeated in other documents on the site? Is there an accurate way to determine this? I don't think <h1> indicates this (or should) in any way. <h1> is just suggesting what the current document is about. Am I going slightly insane? :) |
| 22:29 | <Hixie> | and does really weird things otherwise |
| 22:29 | <Hixie> | csarven: have you read the spec? |
| 22:29 | <Philip`> | gsnedders: You can't expect me to read the docs :-p |
| 22:30 | <gsnedders> | Philip`: I wasn't expecting you to :P |
| 22:30 | <gsnedders> | Philip`: I was being sarcastic :P |
| 22:30 | <Hixie> | csarven: specifically http://www.whatwg.org/specs/web-apps/current-work/#distinguishing-site-wide-headings-from-page-headings |
| 22:30 | <csarven> | Hixie What I'm trying to solve is a consistent way to represent logos, contact information and the main document heading. |
| 22:31 | <csarven> | Hixie You got me there. I have not read that bit (nor came across it) |
| 22:31 | <Hixie> | csarven: that's not a problem, that's a solution. what's the problem? |
| 22:31 | <Hixie> | (well, it's a requirement for a solution, not an actual solution) |
| 22:31 | <csarven> | The problem is simply people are incorrectly marking up their documents and there is a great variance in how people use those components |
| 22:31 | <Hixie> | why is that a problem? |
| 22:32 | <csarven> | Not consistent |
| 22:32 | <Hixie> | so? |
| 22:32 | <Hixie> | welcome to humanity. |
| 22:32 | <Hixie> | we're inconsistent. |
| 22:32 | <csarven> | Can we strive for some consistency? |
| 22:32 | <Hixie> | deal with it. :-) |
| 22:32 | <gsnedders> | I'm not! |
| 22:32 | <Hixie> | why? |
| 22:32 | <gsnedders> | I'm completely consistent! |
| 22:32 | <Hixie> | what is the benefit of being consistent? what problem would it solve? |
| 22:32 | <gsnedders> | Hixie: We get to be predictable! |
| 22:33 | <csarven> | Well, having an agreed upon vocab (and its implementation) leads to good things. Can we not agree there? :) |
| 22:33 | <gsnedders> | I mean, it's completely predictable I'll never ask my <3 out, because I'm a hopeless romantic! I'm consistent! |
| 22:33 | <Philip`> | http://www.whatwg.org/specs/web-apps/current-work/multipage/404#introduction - fixed now |
| 22:33 | <Hixie> | csarven: i agree that we should have some level of consistency, so that, for example, users of accessibility tools can read pages as well. |
| 22:33 | <Philip`> | (I'll continue blaming gsnedders for that bug) |
| 22:34 | <Hixie> | csarven: what good things? i'm not going to worry about hypothetical good things here. we have enough real problems to deal with. |
| 22:34 | <Hixie> | Philip`: the problem was bigger than that -- the IDs had changed, so there was nowhere to redirect |
| 22:34 | <Hixie> | Philip`: effectively http://www.whatwg.org/specs/web-apps/current-work/multipage/404#404 |
| 22:35 | <csarven> | Well a simple example would be that if we have a common way of marking a logo (and being able to identify it in a document) will allow us to extract that information from the document with tools. |
| 22:35 | <Hixie> | wtf am i going to do with select.add() and select.remove() and select.options.add() and select.options.remove() |
| 22:35 | <csarven> | <img class="logo"> |
| 22:35 | <gsnedders> | Philip`: What was the bug? |
| 22:35 | <Hixie> | csarven: who on earth is trying to extract logos with tools? |
| 22:35 | <csarven> | Oh, I don't know... microformats? |
| 22:36 | <Hixie> | csarven: if we really wanted to make logos easily extractable, we'd just do something like <link rel=icon src=...> |
| 22:36 | <Hixie> | csarven: "microformats" is not a person |
| 22:36 | <csarven> | :) |
| 22:36 | <Philip`> | gsnedders: http://www.whatwg.org/specs/web-apps/current-work/multipage/fragment-links.js was saying "var fragment_links = { ...,'the-'icon'-property':'rendering',... }" |
| 22:36 | <csarven> | Hixie I'm going towards the use of hCards here. |
| 22:36 | <gsnedders> | Hixie: There was an RSS reader that used RSS's image element to give a logo with the feed |
| 22:37 | <Philip`> | Hixie: You're going to spec what IE does |
| 22:37 | <Hixie> | Philip`: no, i'm not, IE makes select.options === select and crashes for most arguments i tried to pass to select.add() |
| 22:38 | <gsnedders> | Philip`: Why did you assume that there couldn't be '? |
| 22:38 | <Philip`> | gsnedders: Because there wasn't ' |
| 22:38 | gsnedders | blames bert |
| 22:41 | <Philip`> | If browsers popped a big ugly modal error dialog when there was a script error, I would have noticed this bug instead of letting it exist unknown for weeks |
| 22:41 | <Philip`> | s//up / |
| 22:44 | <gsnedders> | Philip`: Like XML errors? |
| 22:44 | <Philip`> | gsnedders: Exactly |
| 22:44 | <gsnedders> | Philip`: Once browsers implement that, can we write ECMAScript 5 that specs how to deal with syntax errors non-fatally |
| 22:48 | <Hixie> | OH MY GOD. <select> and select.options are SO FRICKING MESSED UP. |
| 22:48 | <Hixie> | i even blogged about this before: http://ln.hixie.ch/?start=1161042744&count=1 |
| 22:48 | <Dashiva> | Welcome to our world |
| 22:52 | <Hixie> | oh i've been here for some time |
| 22:56 | <Dashiva> | Yeah, it just felt like you had gone somewhere else since you were surprised by browsers being messed up :) |
| 22:57 | <Hixie> | Dashiva: i'm not used to this level of lack of interop and this amount of crashyness on one small feature |
| 22:57 | <Hixie> | even for html, this takes the biscuit |
| 23:01 | <Hixie> | bbl. |