| 09:59 | <annevk2> | maybe that's why the IETF folks don't like to reuse URL as term :) |
| 12:05 | <krijnh> | I know |
| 14:39 | <annevk42> | whoa, logs fail? :) |
| 14:43 | <krijnh> | Yeyeah |
| 14:43 | <krijnh> | Seems to be working now again |
| 14:44 | <annevk2> | all the conspiracy once again lost o_O |
| 16:39 | masinter | wonders what happened to the whatwg irc log from yesterday |
| 16:40 | <Dashiva> | Quits: krijnh (n=krijnhoe⊙kxn) (Read error: 110 (Connection timed out)) |
| 16:41 | <Dashiva> | That happened, over and over |
| 16:44 | <annevk42> | prolly someone with backups can help krijnh fix it if he wants to |
| 16:48 | <Dashiva> | All he has to do is ask :) |
| 17:08 | <krijn> | *asks* |
| 17:08 | <krijn> | In fact, all you have to do is ask :) |
| 17:08 | <krijn> | I don't really read the logs |
| 17:30 | <Steve^> | The feedback from MS seems to be largely, "are you sure these are the right tags?" |
| 17:31 | <Steve^> | Which after years of discussion, whatwg could only ever answer yes without looking like idiots |
| 17:40 | <annevk42> | good that we're not a single entity then :) |
| 17:50 | <masinter> | you know, you'd do better if you took "are you sure these are the right tags?" to mean "these tags look wrong, why do you think they are right?" |
| 17:50 | <masinter> | sometimes people are, amazingly, trying to be polite |
| 17:51 | <JoePeck> | Any thoughts on why there is document.body but no document.head? Lots of developers append styles, etc to the head of a page and they waste time with getElementsByTagName('head'). Was this ever discussed before? |
| 17:57 | <JoePeck> | although it looks like "document.head" shows up in the WHATWG mailing list a few times |
| 17:59 | <JoePeck> | it doesn't show up in the IDL for document in the spec |
| 18:14 | <masinter> | Steve: not everything in the spec is the result of years of discussion, is it? |
| 18:14 | <Steve^> | I couldn't say the age of anything |
| 18:17 | <masinter> | but you did, "Which after years of discussion, whatwg could only ever answer yes" |
| 18:18 | <Steve^> | I do know that some elements are of significant age, given mailing list posts I've seen |
| 18:19 | <masinter> | the elements Microsoft asked about? |
| 18:20 | <Steve^> | the section, article, nav, header, footer have been set for some time? |
| 18:20 | <Steve^> | The content models are the area of HTML5 I am most familiar with |
| 18:21 | <Steve^> | as I see the greatest value coming from them |
| 18:23 | <hsivonen> | masinter: section, article, nav and footer have been around for a relatively long time |
| 18:29 | <masinter> | if new elements from HTML4 are puzzling to MS, then some justification or pointers to the discussions about them seem like they would be useful. Just saying "these have been here for years" isn't very helpful. |
| 18:30 | <Steve^> | I disagree somewhat. If the wg has no problem with them for a substantial amount of time, what gives MS the right to come along towards the end of the drafting stage and use its commercial power to try and change things? |
| 18:33 | <Steve^> | I can't find a proper reference to @cite in the spec. It is mentioned and exampled, but only within the q element. It is not clear it can be used on section and other elements |
| 18:37 | <Steve^> | Infact, the spec says it cannot be. Only MS's example suggests otherwise |
| 18:39 | <erlehmann> | masinter, ms hasn't really tried to get involved in the process, not even in blocking terms like apple :i |
| 18:40 | <masinter> | if you throw away all the organizational politics, the question is: are these good, justified additions to HTML |
| 18:40 | <masinter> | every new feature has an amazing implementation cost for all kinds of HTML interpreters |
| 18:40 | <masinter> | i mean, if you care about all of the HTML implementations in the world and not just the WhatWG browsers or the "Major browsers" |
| 18:41 | <Steve^> | of course, but they don't have to implement it, just as many developers won't use the new features |
| 18:41 | <masinter> | so additions or changes to the language have a big cost -- even if Apple and WebKit and Mozilla and Opera and a few others have implemented |
| 18:41 | <masinter> | no, not if you want to be a conforming implementation |
| 18:41 | <Steve^> | But by having an official specification with the options available, developers and UAs can use these features when possible |
| 18:42 | <Steve^> | I'm thinking of screenreaders interpreting nav. They might not, but from seeing things at standards.next, they need to |
| 18:42 | <Steve^> | It hits a user requirement right on the head |
| 18:42 | <masinter> | well, look at http://en.wikipedia.org/wiki/List_of_HTML_editors |
| 18:42 | <masinter> | so here are a bunch of editors of HTML |
| 18:43 | <masinter> | every element you add is something that every editor needs to add if it's going to be a good HTML editor |
| 18:43 | <Steve^> | if a text editor finds that task difficult, they're doing something wrong |
| 18:44 | <masinter> | you think so? |
| 18:45 | <Steve^> | considering good text editors are designed to allow user-submitted language highlighting, then yes |
| 18:45 | <masinter> | these aren't all "text editors", some people actually try to build editors that know about the markup language they're editing |
| 18:45 | <masinter> | perhaps you're only familiar with text editing HTML? |
| 18:45 | <masinter> | but there's a long list of WYSIWYG editors there too |
| 18:45 | <Steve^> | are there any elements in particular you see being a problem? |
| 18:46 | <masinter> | i'm just commenting on why it would be good to take MS comments seriously, and not just dismiss them as "we've talked about these for years" |
| 18:47 | <Steve^> | At the same time, you need to make steps forwards |
| 18:48 | <masinter> | of course, it's just that there's a balance |
| 19:12 | <Philip`> | Steve^: "If the wg has no problem with them for a substantial amount of time, ..." - that doesn't seem a very good argument - if somebody pointed out a serious problem or provided some new data, that should be taken fully into consideration even if nobody else noticed the issues for years |
| 19:12 | <Steve^> | sure, that's fine |
| 19:13 | <Steve^> | as long as they do that, rather than sound unsure |
| 19:15 | <Philip`> | Indeed, if they just say "I don't think this sounds like a good idea" then it's not actionable feedback, given that decisions supposedly aren't made on the basis of popularity at all |
| 19:24 | <erlehmann> | masinter, what new exements are bothering you at all? |
| 21:21 | <annevk42> | masinter, fwiw, I agree with you |
| 21:23 | <annevk42> | masinter, I haven't followed that discussion closely enough as most discussions about semantics seem to turn into some bikeshed discussion that eats my time, but I thought I did see some replies that tried to justify why the elements where there |
| 21:23 | <annevk42> | s/where/were/ |
| 21:24 | <Steve^> | annevk2, they tried to? did they succeed? |
| 21:26 | <annevk42> | I don't think the thread concluded |
| 21:27 | <annevk42> | for the one I did follow Adrian said he'd follow up next week (regarding <keygen>) |
| 21:27 | <annevk42> | I believe he said they supported <video> and <audio> |
| 21:28 | <annevk42> | <dialog> actually got dropped in response to feedback and has been there for a long time too |
| 21:28 | <annevk42> | taking a fresh look at elements every couple of years is not a bad thing at all imo |
| 21:28 | <annevk42> | we did exactly the same thing with HTML4 elements and attributes |
| 21:29 | <annevk42> | it'd be a bit weird if we didn't allow the same scrutiny for additions |
| 21:31 | <masinter> | well, it's some work, but the "differences from HTML4" document might be a good place to put whatever people have |
| 21:32 | <masinter> | i haven't looked closely at tool implementation impact |
| 21:41 | <annevk42> | masinter, yeah, one day I should put a bit more effort into that doc than simply updating it along the same old tune the initial draft was based on |
| 21:45 | <Steve^> | what HTML5 elements can the cite attribute be used on? |
| 21:46 | <Hixie> | same as html4, q, blockquote, ins, and del |
| 21:46 | <Steve^> | fair enough |
| 21:47 | <Steve^> | the guy from MS is crazy then |
| 21:47 | <Hixie> | it changed after they sent their feedback |
| 21:47 | <Hixie> | partiall in response to their feedback |
| 21:47 | <Steve^> | ahh |
| 21:48 | <Steve^> | nevermind then |
| 21:48 | <gsnedders> | bq! bq! don't forget bq! |
| 21:49 | <gsnedders> | (Opera uses some interface with the cite attribute in the DOM for bq) |
| 21:49 | <Steve^> | I feel there should be an alias for q called quote |
| 21:50 | <gsnedders> | (bq was in HTML 3, Opera is the only browser that does anything with it) |
| 21:50 | <gsnedders> | (Also, Opera's implementation is broken.) |
| 21:51 | <Steve^> | of all the elements in 4.5 of the spec, blockquote is the only one with a long name |
| 21:52 | <Steve^> | so that should be aliased to bq |
| 21:52 | <da3d> | I want a <bbq> tag :) |
| 21:52 | <Steve^> | :D |
| 21:52 | <gsnedders> | Steve^: Parsing differences in legacy UAs, and different styling. |
| 21:53 | <Steve^> | Is <summary> coming back? |
| 21:53 | <Steve^> | gsnedders, hmm? |
| 21:53 | <Steve^> | oh, bq is an actual element too? |
| 21:57 | <Steve^> | So HTML2 had blockquote, HTML3 has bq and now HTML5 has blockquote |
| 22:02 | <Hixie> | HTML3 was never more than a draft |
| 22:03 | <Philip`> | HTML5 has never been more than a draft |
| 22:03 | <Hixie> | indeed |
| 22:05 | <masinter> | the status of a document in some standards group is interesting, but a lot of people are confused about the names like 'a draft' or 'a standard' or 'a draft standard' |
| 22:06 | <masinter> | while the IETF and W3C names are confusing, the WhatWG names aren't better |
| 22:06 | <Hixie> | yeah |
| 22:06 | <Hixie> | we really should just move to an always-on mechanism |
| 22:06 | <Hixie> | instead of the snapshot mechanism |
| 22:06 | <masinter> | as far as differences go, there are 'differences with spec X' and then 'differences with implementations A, B, C' |
| 22:07 | <masinter> | i don't think always-on makes sense |
| 22:07 | <masinter> | very few organizations are willing to provide funding for always-on |
| 22:07 | <Hixie> | for a platform evolving like the web's, i think it's the practical reality anyway |
| 22:07 | <masinter> | because it means a continual support not just for products, but for specifications |
| 22:07 | <Hixie> | i'm happy to pay for the whatwg site out of pocket as i have so far |
| 22:07 | <masinter> | it's not the dollar cost, it's the personnel cost |
| 22:08 | <Hixie> | oh well we're paying that cost anyway in practice |
| 22:08 | <masinter> | it's better if products compete on their technology and not on control of the interfaces |
| 22:08 | <Hixie> | and whenever we've stopped paying that cost -- DOM3, HTML4 -- it's been a disaster that's cost us far more on the long run |
| 22:08 | <Hixie> | i should say, as after DOM3 and after HTML4 |
| 22:09 | <masinter> | i think there are hundreds, thousands of industries which have a practice of infrequent upgrade of standards |
| 22:09 | <Hixie> | not DOM3 and HTML4 themselves |
| 22:09 | <Hixie> | sure, i'm just talking about HTML, the DOM, and CSS |
| 22:09 | <Hixie> | for most industries it obviously makes no sense to keep evolving the specs |
| 22:09 | <Hixie> | imagine what mess that would be for power sockets, e.g. :-) |
| 22:09 | <masinter> | there's no intrinsic reason why web standards should be completely different from almost every other distributed set of interfaces |
| 22:10 | <Hixie> | the difference is platforms vs individual features |
| 22:10 | <masinter> | or that keeping web standards up to date should require every organizaiton that wants to participate to dedicate multiple full-time resources ot tracking the interfaces |
| 22:10 | <Hixie> | the practical reality is that they have to already |
| 22:10 | <masinter> | the idea of a "platform" is an architectural vision |
| 22:11 | <masinter> | I understand you have that opinion |
| 22:11 | <masinter> | but just saying that your opinion is the "practical reality" doesn't really help, especially when that view doesn't match most other industries and standards practices |
| 22:11 | <Hixie> | i'm only talking about this industry, not others |
| 22:11 | <Hixie> | i agree that it's not the case in other industries |
| 22:12 | <Hixie> | and that it should not be in most |
| 22:12 | <masinter> | so what industry is Apple in? |
| 22:12 | <Steve^> | I dislike always-on, I think vendors want to say they fully support HTML5 and compete in that fashion |
| 22:12 | <Hixie> | but it _is_ the case for software platforms, like windows, or mac, or the web |
| 22:12 | <masinter> | what industry is Google in? |
| 22:12 | <Hixie> | Steve^: they haven't historically |
| 22:12 | <Steve^> | By continually updating the spec, they may miss out features for longer periods |
| 22:12 | <Hixie> | masinter: both are in many industries |
| 22:12 | <masinter> | is Google in the Web industry, or is Google in the Internet service industry? |
| 22:12 | <Hixie> | Steve^: why? |
| 22:12 | <Hixie> | masinter: both, and many more |
| 22:13 | <masinter> | so if you make, say, a cell phone operating system |
| 22:13 | <masinter> | and as a product it implements some interfaces |
| 22:13 | <Steve^> | If I get lots of bits of homework, I don't do them in the order they arrive. Whereas you would need to do HTML 5 then 5.1 then 5.2, etc |
| 22:13 | <masinter> | some web, some voice over IP, some instant messaging, some calendaring, some geolocation, etc. |
| 22:13 | <masinter> | are you saying that all of those need "always on" standards activities to maintain compatibility between Nokia, Apple and Google? |
| 22:14 | <masinter> | or just the web ones? |
| 22:14 | <Steve^> | I suppose CSS shows that isn't how it works |
| 22:14 | <masinter> | i suppose I should add Opera |
| 22:14 | <masinter> | it's not clear what CSS "shows" |
| 22:15 | <masinter> | standards activities don't work well when the players don't agree to play |
| 22:15 | <Hixie> | Steve^: right now, browser vendors are continually adding new features from whatever the latest specs are that they want to support, ignoring the version numbers, and ignoring features they don't want to support |
| 22:16 | <Hixie> | masinter: just the web and other platforms. e.g. the iPhone platform, if it was a standard, would be one that i would not bother giving a version number to |
| 22:16 | <Hixie> | masinter: but the USB connector is a standard that makes sense to version |
| 22:17 | <Hixie> | masinter: because you don't want any variety on that connector for a period of many years |
| 22:17 | <masinter> | the word 'platform' is used with such variability that it's useful to be more precise about what you mean |
| 22:17 | <Hixie> | a set of APIs and other features on which applications and content can be based |
| 22:17 | <masinter> | that's not how i use the word |
| 22:18 | <Hixie> | some things, like connectors, provide value when they are ubiquitous and unchanging over time |
| 22:18 | <masinter> | http://en.wikipedia.org/wiki/Platform_%28computing%29 |
| 22:18 | <masinter> | i dont like that too much either |
| 22:19 | <masinter> | the usage that makes sense to me is one i read a long time ago: there are implementations, interfaces, and platforms |
| 22:19 | <Hixie> | others, like sets of APIs, derive value from offering the features their content and application providers need, and there is no need for the feature sets from different interpreters being in lock-step, so long as the common subset is interoperable |
| 22:19 | <masinter> | a language, protocol, API are all interfaces |
| 22:19 | <masinter> | HTML, URI, HTTP are all interfaces that are essential to the web "platform" |
| 22:19 | <Hixie> | so for the former, i think versioning is important, and for the latter, i think just continous improvement would be better |
| 22:20 | <masinter> | what distinguishes a platform from an interface is that a platform has multiple interfaces, any one of which can evolve independently of the other |
| 22:20 | <masinter> | you want interoperability across different implementations of individual interfaces |
| 22:21 | <masinter> | so that you can replace your HTTP server or your HTTP protocol stack on the client, without having to make sure it matches the other side of the client/server interface |
| 22:21 | <Hixie> | gotta go now, we're going to play TI3 |
| 22:21 | <masinter> | it's easier to talk about versioning if we get straight about terminology |
| 22:21 | <Hixie> | bbl |
| 22:23 | <masinter> | whether interface versions have version 'numbers' is a separate issue, but upgrading the interface is more costly and requires coordination, while upgrading the implementations without upgrading the interfaces doesn't |
| 23:59 | masinter | wonders, "is this thing on?" |
| 23:59 | gsnedders | notes there is a certain randomness to how busy this channel is, but seems to be busiest when both Europe and America is awake |