| 02:44 | gsnedders | recalculates uncertainties and has them almost double |
| 02:44 | gsnedders | sighs |
| 04:40 | <john_fallows> | Hixie: the EventSource attribute called "URL" looks like it has the wrong case (compare StorageEvent.url) |
| 06:25 | <Hixie> | john_fallows: StorageEvent is the one with the wrong case |
| 06:26 | <john_fallows> | isn't the attribute name "URL" (all upper case) inconsistent with other attribute names? |
| 06:26 | <Hixie> | yeah but document.URL has existed for years |
| 06:27 | <john_fallows> | so then propagate that to EventSource, WebSocket, StorageEvent, ... ? |
| 06:35 | <john_fallows> | i suppose the attributes on EventSource, WebSocket, StorageEvent would not need to be consistent with the case of "URL" if they were named something completely different :-) |
| 06:39 | <Hixie> | WebSocket and EventSource both already use .URL |
| 06:39 | <Hixie> | might be too late to change StorageEvent though |
| 06:39 | <Hixie> | since i imagine that's about to ship in IE8 |
| 06:49 | jwalden | remembers MessageEvent.uri almost a year ago, in ancient times |
| 06:52 | <john_fallows> | if that's the state of things, then why not keep the legacy "URL" on document as a special case and make everything else self-consistent case? |
| 06:52 | <Hixie> | it is self-consistent now :-) |
| 06:52 | <Hixie> | what's wrong with upper case? |
| 06:53 | <Hixie> | have one uppercase and three lowercase or three uppercase and one lowercase, they're still inconsistent |
| 06:53 | <john_fallows> | you just pointed out that it's not self-consistent now, (StorageEvent.url ) |
| 06:53 | <Hixie> | right but why does it matter whether we're consistent with uppercase or lowercase? |
| 06:54 | <john_fallows> | you are right, so the argument of consistency with uppercase "URL" is already moot |
| 06:54 | <john_fallows> | but the argument of consistency with the case of all the other attributes still holds, no? |
| 06:54 | <Hixie> | *shrug* |
| 06:55 | <Hixie> | consistency in the html apis is so far beyond a lost cause at this point that i'd rather just be consistent with the existing attribute names (like document.URL) |
| 06:55 | <john_fallows> | it just looked a bit confusing to me because "URL" in upper case instantly looks like a type, not an attribute |
| 06:57 | <Hixie> | oh i'm not saying it makes any sense, indeed |
| 06:59 | Hixie | stares at his inbox |
| 06:59 | <Hixie> | holy crap what a lot of e-mail |
| 06:59 | <john_fallows> | you'll be glad when 2022 rolls around ;-) |
| 07:01 | <Hixie> | i'll be glad when sam manages to get people to stop repeating themselves |
| 07:01 | <Hixie> | 34 messages on summary="" alone in 24 hours |
| 07:02 | <Hixie> | is smylers on irc? |
| 07:04 | <MikeSmith> | I think to bypass the rules that Sam outlined in his message today, people can switch to using "thou" instead of "you", and the royal "we" instead of "I" |
| 07:11 | <Dashiva> | Semantics on public-html? Unheard of |
| 07:13 | <MikeSmith> | Hixie: if you were to put the spellcheck attribute into a particular class, would "interactive" be appropriate? the WHATTF schema has contenteditable, draggable, hidden, and contextmenu in that class (named pattern in the schema) |
| 07:14 | <Hixie> | yes |
| 07:14 | <MikeSmith> | OK |
| 07:14 | <Hixie> | tabindex would likely be in the same class |
| 07:16 | <MikeSmith> | schema has that in common.attrs.present (presentational), along with style attribute |
| 07:17 | <Hixie> | what an odd distinction |
| 07:17 | <Hixie> | are they handled differently? |
| 07:17 | <MikeSmith> | comment there says, "REVISIT move style to a module and bundle tabindex with ARIA" |
| 07:17 | <Hixie> | o_O |
| 07:28 | <Hixie> | i wonder if i can get out of watching the video sam wants us to watch, on the grounds that i was there at the filming of the video... |
| 07:30 | <sayrer> | Hixie, you weren't required, as you were under the limit |
| 07:30 | <Hixie> | aah, that's lucky |
| 07:36 | Hixie | watches the video again anyway |
| 08:13 | <hsivonen> | sigh. that's a lot of email on public-html for one Sunday |
| 08:14 | <hsivonen> | I think I'm going to limit my posting rate voluntarily to max one message per day per thread |
| 08:17 | <Hixie> | hsivonen: i hope that means you start e-mailing whatwg instead :-) |
| 08:17 | <Hixie> | i wouldn't want to lose your input just because some people are crazy :-) |
| 08:36 | <jgraham> | Oh good lord. |
| 08:36 | jgraham | sees like 100 new messages for 1.5 days |
| 08:41 | <jgraham> | hsivonen: Is there any good reason to believe that people would use summary="" reliably enough to use it a presentation-indicator (or, at least, a lone presentation indicator) |
| 09:19 | <hsivonen> | jgraham: I don't expect all layout tables to be flagged with summary="" or role=presentation |
| 09:19 | <hsivonen> | jgraham: I do assume (with no data) that people wouldn't put role=presentation on data tables |
| 09:28 | <jgraham> | hsivonen: I can imagine copy-and-paste authouring making it less than 100% accurate |
| 09:50 | <Hixie> | what's the opposite of "lexical space"? |
| 09:50 | <Hixie> | i'm having a mind blank |
| 09:52 | <Philip`> | I don't know what you mean by "opposite", but maybe it's what XML Schema calls "value space"? |
| 09:55 | <virtuelv> | Hixie: would you support splitting the storage spec from HTML5? |
| 09:55 | <virtuelv> | (local/sessionStorage that is) |
| 09:56 | <Hixie> | value space is where i was going, thanks |
| 09:56 | <virtuelv> | we have some use for the same interfaces in Widgets APIs and Events, and have some extra requirements, such as read-only storage, and the ability to reset storage to default values |
| 10:03 | <jgraham> | virtuelv: I was under the impression that splitting out the storage spec is a done deal it's just that it hasn't happened yet. But I could be wrong of course |
| 10:03 | <virtuelv> | ah, I was unsure of that |
| 10:04 | <virtuelv> | the issue here being that we're on a different timeline than html5 |
| 10:04 | <virtuelv> | and with slightly different needs |
| 10:04 | <Hixie> | yeah it'll be taken out, uh, *consults calendar* |
| 10:05 | <Hixie> | erm |
| 10:05 | Hixie | adds to the calendar |
| 10:05 | <Hixie> | this month! |
| 10:05 | <virtuelv> | Hixie: in other words, we need an editor for a storage spec? and asap? :) |
| 10:05 | <Hixie> | nah, i can do it |
| 10:05 | <Hixie> | it's stable enough |
| 10:07 | <virtuelv> | Hixie: when you do, will you account for the extra requirements raised? (read-only storage items, reset to default (in Widgets, you can declare prefs in the manifest), and also making sure that it's agnostic towards where something is stored)? |
| 10:08 | <Hixie> | i would recommend inheriting from the Storage interface and defining those extensions in the widgets spec |
| 10:09 | <virtuelv> | for now, we've tried to avoid dependencies on HTML5 |
| 10:09 | <jgraham> | Hixie: Does that work better than making storage deal with both sets of requirements and making HTML5 say "all values are Read Write, All values default to undefined" |
| 10:09 | <Hixie> | virtuelv: the Storage interface will be in another doc within the month, hopefully |
| 10:10 | <Hixie> | jgraham: i'll have to look closer at the two needs to know which is better |
| 10:10 | <virtuelv> | Hixie: given its relative maturity, are you foreseeing any fast-track to LC? |
| 10:10 | <jgraham> | Hixie: Fair enough :) |
| 10:25 | <Lachy> | Hixie, are you splitting out localStorage/sessionStorage and the Database storage APIs together? |
| 10:25 | <Hixie> | yes |
| 10:25 | <Hixie> | virtuelv: html5 itself is intended for lc in october, i doubt i'll be attempting for anything faster |
| 10:26 | <Lachy> | ok, so basically the whole of section 5.11 "Structured client-side storage" will be removed |
| 10:26 | <Hixie> | virtuelv: i expect it'll take longer than that for the w3c to manage to get us a charter allowing us to get to fpwd! |
| 10:26 | <Hixie> | Lachy: right |
| 10:26 | Philip` | fails to understand what Kristof means about "bounding box" and "flattening" |
| 10:27 | <Lachy> | ok. that's good cause it will reduce the size of HTML5, but that's bad cause it's another spec I will need to look at separately. I hate having conflicting needs. |
| 10:29 | jgraham | imagines Lachy's head exploding like some poorly designed film robot that can't cope with contradictions |
| 10:30 | <Hixie> | Lachy: i'm tempted to leave them in the whatwg version (they'll still be in the whatwg source file...) |
| 10:30 | <Lachy> | but that will make the W3C and WHATWG copies differ. |
| 10:31 | <Hixie> | that is the main downside, yes |
| 10:31 | Lachy | 's head explodes! *BOOM* |
| 10:31 | <Hixie> | oh dear oh dear |
| 10:31 | Hixie | cleans up the mess |
| 10:31 | <Hixie> | someone order a new lachy! |
| 10:34 | <hsivonen> | Hixie: how did workers being in a separate source file work out? |
| 10:36 | <Hixie> | Not. Well. |
| 10:39 | <Hixie> | ok i'm going to sleep |
| 10:39 | <Hixie> | nn |
| 10:39 | <Lachy> | nn |
| 10:59 | <Philip`> | Is it appropriate to use dl/dt/dd for marking up FAQs? |
| 11:05 | <jgraham> | Philip`: I don't see any reason why not |
| 11:07 | <Philip`> | jgraham: I suppose I don't quite see a FAQ question as being a "name" |
| 11:07 | <Philip`> | but it's still associating a sort-of-not-quite-name thing with some other text |
| 11:08 | <Philip`> | and, most importantly, the default presentation is kind of appropriate |
| 11:08 | <jgraham> | Philip`: Yeah, I just read the spec text and it doesn't quite support it. |
| 11:08 | <jgraham> | But since my opinion is roughly "if you have to ask about semantics they have already failed" I don't think it matters much |
| 11:09 | <Philip`> | Hmm, maybe the questions should be <hN> so an outline-based ToC generator would include them |
| 11:09 | <virtuelv> | Hixie: I'd imagine that a storage API already falls in under the webapps charter - you could ask chaals |
| 11:10 | <jgraham> | Philip`: That is certianly a good practical reason for taking that approach. |
| 11:10 | <Lachy> | I think <dl> is suitable for an FAQ. But I think the problem is trying to find an appropriate way to express the semantics in the spec, without making the definition too vague and also without making it too specific that it accidentally eliminates otherwise valid uses |
| 11:10 | <jgraham> | Although I bet accessibuility people have a rule like "you shouldn't have more than three words in a heading" or something silly |
| 11:11 | <Lachy> | the other problem is that some people tend to be overly strict in their interpretation of the semantics in the spec |
| 11:11 | <Philip`> | jgraham: Such a rule should not be acceptable to i18n people, because it would allow German sites to put whole paragraphs of meaning in a single compound word in a heading |
| 11:12 | <jgraham> | Uh, maybe they should syllables instead |
| 11:13 | <jgraham> | (I often see characters used as a measure, but that is silly for obvious reasons) |
| 11:13 | <Dashiva> | Syllables still lets languages like Japanese run wild |
| 11:13 | <Philip`> | Lachy: You can't really blame people for reading overly strictly when the spec itself says you rfc2119:MUST follow the intended semantics |
| 11:14 | <jgraham> | Dashiva: Really? Japanese has syllables just like every other language that has a spoken form |
| 11:14 | <Philip`> | If it wasn't meant to be interpreted strictly, it should be phrased more as suggestions rather than as absolute requirements |
| 11:15 | <Lachy> | Philip`, there's a difference between being strict and being overly strict. |
| 11:17 | <Philip`> | jgraham: Now you're discriminating against sign language users |
| 11:18 | <jgraham> | Lachy: But if the point of semantics is to let people build general-purpose consuming software then you either have to be really narrow and strict or... well actually even if you are really narrow and strict you have to deal with the fact that people get things wrong. So you have to either solve a different problem or do something more clever |
| 11:18 | <Philip`> | ((I'm assuming they find it harder to understand the concept of syllables than people who regularly use verbal communication, and so they'd find it hard to count the syllables of their written text)) |
| 11:18 | <jgraham> | Like only use the markup as one input amongst many |
| 11:18 | <Lachy> | Philip`, the important part of the element's definition is that it says it's an association list. It just uses to terms "name" and "value" to refer to the parts within a group. It doesn't strictly mean that the first has to be a name, and that is an example of being overly strict |
| 11:20 | <jgraham> | Philip`: However you have to consider that the visually-impaired community has much better advocacy than the deaf community. So as long as things work in screenreaders people tend to assume it meets the definition of "accessible" |
| 11:21 | <Philip`> | Lachy: But the spec says the list MUST be name-value pairs, so it seems fairly clear that its intention is that <dt>s represent names, and it's stated elsewhere that you MUST NOT use elements except for how they were intended to be used |
| 11:21 | <Philip`> | jgraham: If that was true, nobody would care about <video> captioning, but clearly some people do care about that |
| 11:22 | <jgraham> | Philip`: Hmm. Good point. |
| 11:22 | jgraham | should maybe stop being contrary |
| 11:23 | <Philip`> | It's fine to be contrary as long as you're correct ;-) |
| 11:23 | <virtuelv> | <jgraham> Although I bet accessibuility people have a rule like "you shouldn't have more than three words in a heading" or something silly |
| 11:23 | <virtuelv> | that would rather be UX people |
| 11:24 | <jgraham> | virtuelv: Not sure what UX has to do with it, really. Long heaings are more-or-less OK for people who are reading the document. I guess they would be annoying if you were scanning through it in a screenreader |
| 11:25 | <jgraham> | Philip`: I think I am right in general that the visually disabled have the best advocacy for their needs |
| 11:26 | <Philip`> | I wouldn't like to read http://www.whatwg.org/specs/web-apps/current-work/multipage/index.html#contents if all the headings were limited to three words |
| 11:26 | <Lachy> | Philip`, there's an example in the spec that uses the dl to give a set of instructions. The statements marked up as DTs don't really fit the definition of a "name". But if you understand that the term "name" is merely being used as an identifer of the component, rather than a strict definition of what it can contain, then it makes sense |
| 11:27 | <jgraham> | Lachy: Arguably the spec is wrong then. But I bet it is wrong in this way for almost every element |
| 11:29 | <Philip`> | jgraham: Perhaps that's largely because they have the most drastically different needs of all the common disability groups, in terms of how HTML is designed and authored? |
| 11:29 | <Lachy> | jgraham, can you think of a better way to define it that doesn't suffer from the same problem of misinterpretation? |
| 11:29 | <Philip`> | jgraham: HTML is primarily a visual markup language, so visual disabilities are going to have to fight hardest to make it acceptable to them |
| 11:30 | <jgraham> | Philip`: Maybe. But nevertheless consider the difference in the public-html traffic between @alt and the equivalent for <audio> |
| 11:30 | <Lachy> | jgraham, besides, the spec clearly states that "Name-value groups may be terms and definitions, metadata topics and values, or any other groups of name-value data.", so it's clear that "names" isn't strictly limited to names. |
| 11:31 | <jgraham> | Lachy: Well if "name" doesn't fit the semantic of the english word "name" it is clearly confusing |
| 11:31 | <jgraham> | "identifier" might be better for example |
| 11:32 | <Philip`> | jgraham: Hmm, perhaps it's also relevant that there's been a decade for groups focused on visual accessibility to grow, whereas audio accessibility is a very new concern on the web and so very few people have got organised enough to participate in discussions on it |
| 11:32 | <Lachy> | possibly, but you have to balance strictness with readability, and more people would be familiar with the concept of name-value groups than "identifier-value" groups. |
| 11:34 | <jgraham> | Philip`: That could be true too. I am only making an empirical observation that almost all the people involved in a10y threads come from a visual-impairment background. I hope I didn't claim to know why that was :) |
| 11:34 | <Philip`> | Maybe the spec shouldn't try to say that using <dl> for FAQs is (depending on its intended semantics, which I can only vaguely discern from the text) the same kind of conformance error as using <blink> |
| 11:35 | <jgraham> | Lachy: That familiarity seems unhelpful if the semantics of <dd>/<dt> pairs are different from those usually associated with name-value groups |
| 11:35 | <Philip`> | jgraham: I don't mean to disagree with you; I'm just idly wondering :-) |
| 11:37 | Philip` | idly wanders off |
| 11:38 | <jgraham> | Anyway on a not-entirely-unrelated subject, is there any easier way to produce a UI for categorising layout/data tables whilst simultaneously collecting information about the table inclusing its computed style, than developing something like a firefox extension? |
| 11:38 | <Philip`> | Is computed style important to capture? |
| 11:39 | <jgraham> | Philip`: No idea. That's the point really. It seems like it could be |
| 11:40 | <jgraham> | Although if you can convince me that it is trivial to do everything apart from computed style it would maybe be worth doing that first and then seeing how well it works |
| 11:41 | <Philip`> | If you want to get a human to categorise thousands of tables, it seems like it'd be quite a pain if they had to download the entire page (along with styles and images and adverts etc) just so they could see the table and decide if it was data or layout |
| 11:41 | <jgraham> | Basically I want the user to see the table, probably out of its original context, to have three buttons marked "Layout", "Data", "Unknown" and some script that computes properties of the tble in its original context |
| 11:41 | <Philip`> | because that would be slow |
| 11:41 | <jgraham> | It would be possible to have the categorisation happen at an entirely different time to the property computation if that would help |
| 11:42 | <Philip`> | It'd be pretty trivial to e.g. extract all the <table> elements from 130K pages from dmoz, ignoring all the external styles and everything, which would be one way to get a list of tables you could show to a user and have them press a key to categorise each one |
| 11:43 | <jgraham> | Philip`: Right. Could you then find the _same_ tables again and compute the properties of them somehow |
| 11:44 | <jgraham> | In their original context. e.g. by constructing an xpath that matched the table and then discarding any cases where the same xpath didn't return a table |
| 11:44 | <jgraham> | (it would just be something like /html/body/div[3]/table or whatever Xpath syntax is |
| 11:44 | <Philip`> | XPath sounds complex - just remember that it was table n on http://... |
| 11:45 | <Philip`> | (and keep a static copy of the page's markup so it won't change) |
| 11:45 | <Philip`> | (though you might have to worry about external stylesheets changing, but I guess that's pretty rare) |
| 11:46 | <jgraham> | I guess that might work |
| 11:46 | <Philip`> | Maybe you could do something like using the embedding API of a browser engine to write an application that loads the pages and dumps the computed style information |
| 11:46 | <jgraham> | Philip`: That was roughly what I had in mind |
| 11:46 | Philip` | doesn't know if that'd be easier or harder than writing a Firefox extension |
| 11:47 | <Philip`> | I can't think of any other sane way to get computed style information |
| 11:48 | <Philip`> | (Ooh, the bug that made @font-face crash Firefox appears to have been fixed upstream now) |
| 11:48 | <Philip`> | (Hmm, why did someone make Bugzilla's background pink?) |
| 11:49 | <Dashiva> | jgraham: Re:japanese, use of ideograms lets you overload syllables massively. |
| 11:50 | <Philip`> | Oops, I forgot I was going to wander off |
| 11:50 | Philip` | does so |
| 12:35 | <Philip`> | jgraham: In terms of UI for table categorisation, I kind of like the thing like in http://philip.html5.org/tests/canvas/suite/tests/reportgen.html?100,0 where there's a button for each case, and also you can use the keyboard (y/n), and it automatically scrolls down to the next case, and you can manually scroll up and change your answers if you did it wrong |
| 12:51 | <jgraham> | Philip`: Interesting |
| 12:52 | <Philip`> | ...though that particular example page is rubbish unless you're using IE or Safari 3.0 or something, because otherwise it automatically determines almost all the results |
| 13:12 | <hsivonen> | I wonder if adding classes to text/plain elements is interop-sensitive. see https://bugzilla.mozilla.org/show_bug.cgi?id=369301 |
| 13:15 | <zcorpan> | hsivonen: seems more appropriate to extend css with vendor-specific @rules or something |
| 13:16 | <zcorpan> | @-moz-text-document { pre { color:green } } @-moz-web-document { pre { color:red } } |
| 13:17 | zcorpan | notes that HTTP Link: headers can apply css to text/plain documents |
| 13:17 | <hsivonen> | @-moz-content-type("text/plain") { ... } maybe? |
| 13:17 | <zcorpan> | yeah |
| 13:17 | <gavin> | the use case in that bug was to avoid styling the <pre>s |
| 13:17 | <gavin> | can you do that with an @ rule? |
| 13:18 | <zcorpan> | gavin: @-moz-web-document { pre { color:red } } |
| 13:18 | <hsivonen> | gavin: as much as with classes in the text/plain DOM, I think |
| 13:19 | <gavin> | oh, I misunderstood what you meant by -moz-web-document |
| 14:02 | <annevk3> | sshfs + komodo is no fun over a slow connection |
| 14:02 | <annevk3> | geez |
| 14:02 | <annevk3> | every i/o operation takes >10s or so |
| 14:04 | hsivonen | reads http://lists.w3.org/Archives/Public/www-html/2006Feb/0095 |
| 14:05 | annevk3 | joins |
| 14:08 | <hsivonen> | "Firefox can't establish a connection to the server at hades.mn.aptest.com." |
| 14:08 | <hsivonen> | Yay for issue tracking systems maintained by spec editors without the W3C systeam |
| 14:14 | <annevk3> | you realize we're doing the same, right? |
| 14:15 | <annevk3> | though admittedly an index of e-mails without replies is a bit different from an issue database in a lot of people's minds |
| 14:15 | <Philip`> | At least there's an externally-hosted mirror of whatwg.org/issues |
| 14:15 | <hsivonen> | annevk3: I fully realize we are doing the same thing |
| 14:16 | <annevk3> | Philip`, you're not supposed to defend us :p |
| 14:17 | <Philip`> | More concerning than any technical infrastructure is that Hixie's head is not maintained by the W3C systeam, despite being critical to the development of HTML 5 |
| 14:48 | Philip` | finds it really strange to be reading papers from research conferences that include fragments of XML and RDF and talk about OWL and stuff |
| 14:48 | <Philip`> | I suppose it's good that people are using the technologies, but it seems very far removed from the web |
| 14:59 | <virtuelv> | Philip`: is http://www.rijksmuseum.nl/ far removed from the web? |
| 15:04 | <virtuelv> | I listened in on a presentation about this during last year's xtech, and it's almost all built on semweb stuff |
| 15:05 | <Philip`> | virtuelv: No, but that's independent of the issue of me hearing about RDF/OWL/etc in contexts that have very little to do with the web (e.g. policy services frameworks for distributed computing platforms in industrial, military and space applications, in one particular example) |
| 15:06 | <virtuelv> | ah |
| 15:07 | <virtuelv> | I guess it's a decent enough means of data exchange for those industries |
| 15:11 | <Philip`> | There's a strange mixture of lines like (M, π) ⊨ p ⇔ p ∊ L(π₀) and lines like <Resource name="XI_J2EE_LOP_achalm47_AS" class="IBM.Application" node="achalm47"> in one paper |
| 15:12 | <Philip`> | (and I can understand the former much better than the latter) |
| 15:28 | <hsivonen> | virtuelv: but does rijksmuseum expose its RDF data to the public? |
| 15:29 | <Philip`> | Or does it import RDF data from the public? |
| 15:35 | <jgraham> | And if it does either of those things, does anyone make use of those facilities? |
| 15:45 | <hsivonen> | http://www.w3.org/2001/tag/2009/sum02.html |
| 15:46 | Philip` | tries to work out whether that's from 2001 or 2009 or 2002 |
| 15:49 | <Philip`> | "The TAG [...] reopened its ISSUE-20: What should specifications say about error handling?, an issue that the TAG originally raised in 1992." / "The Technical Architecture Group (TAG) was created in February 2001." - how does that work, in the absence of time travel? |
| 16:04 | <virtuelv> | hsivonen: I can't recall |
| 16:05 | <virtuelv> | weren't you at ms. Stash's lightning talk in Dublin? |
| 16:05 | <virtuelv> | I believe you, at the very least, joined us for Irish food and beer later |
| 16:06 | <virtuelv> | and, I think they imported data from elsewehre |
| 16:07 | virtuelv | has to run |
| 20:00 | <virtuelv> | .innerHTML history lesson: http://www.ericvasilik.com/2006/07/code-karma.html |
| 21:53 | <Hixie> | with the whole splitting of html5 into multiple specs, i think we're going to need a name for the group of next gen specs, for PR purposes |
| 21:54 | <Hixie> | it was bad enough people calling all this stuff "HTML5" when it was 90% in HTML5 |
| 21:54 | <Hixie> | but when more than half of the features are their own specs, that's just not going tofly |
| 21:54 | <Hixie> | maybe the WHATWG should release a spec called simply "Web" |
| 21:55 | <Hixie> | we could start it at version 3.0 |
| 21:55 | <gsnedders> | Hixie: But 5 > *! |
| 21:56 | <Hixie> | no 5 > 2 |
| 21:56 | <Hixie> | 3 > 5! |
| 21:56 | <gsnedders> | WHAT logic: 3 > 5 > 2 |
| 21:56 | <Hixie> | it goes 1 2 5 3 4, apparently |
| 21:56 | <gsnedders> | Hixie: What is 4 + 1? |
| 21:56 | <Hixie> | i don't think you can add version numbers |
| 21:57 | <roc> | Radiance |
| 21:57 | <gsnedders> | Hixie: What version number comes after 4, then? |
| 21:57 | <Hixie> | gsnedders: i don't know that it's come up |
| 21:58 | <Hixie> | actually come to think of it, it goes 1 4 2 5 3 |
| 21:58 | <svl> | HTML 2011? |
| 21:58 | <Hixie> | since HTML4 comes before HTML5 and XHTML2 |
| 21:58 | gsnedders | still wants the revision of HTML after 5 to be 2π |
| 21:59 | <jcranmer> | be exotic |
| 21:59 | <Philip`> | The next should be HTML VI |
| 21:59 | <jcranmer> | name it after some random dieties |
| 21:59 | <Philip`> | (obviously followed by HTML EMACS) |
| 21:59 | <jcranmer> | Philip`: HTML NANO? |
| 21:59 | <jcranmer> | then HTML PICO |
| 21:59 | <gsnedders> | jcranmer: only after PCIO |
| 21:59 | <gsnedders> | *PICO |
| 22:00 | <gsnedders> | jcranmer: No, NANO must come after PICO |
| 22:00 | <jcranmer> | HTML FEMTO |
| 22:00 | <Philip`> | HTML Tiny |
| 22:00 | <gsnedders> | What about HTML MOO? |
| 22:00 | <jcranmer> | HTML "It's just HTML, why do I need a version number?" |
| 22:00 | <jcranmer> | HTML Buddha |
| 22:01 | <jcranmer> | followed by HTML Zeus |
| 22:01 | <svl> | Why do we need the H, T and M anymore, really? Just call it L and be done with it. |
| 22:02 | <jcranmer> | ₤ |
| 22:02 | <gsnedders> | HTML ∞ |
| 22:02 | <jcranmer> | make it stylized letters! |
| 22:02 | <jcranmer> | HTML א₀ |
| 22:03 | <gsnedders> | ןɯʇɥ |
| 22:04 | <Lachy> | Hixie, how many specs are being split out from HTML5? |
| 22:04 | <Hixie> | half a dozen at least |
| 22:05 | <Hixie> | search for "marked for extraction" in the spec |
| 22:08 | <Lachy> | OK, so it's URLs, Content Sniffing, Storage APIs, Server-sent Events, Web Sockets, and Timers. There's also Web Workers, although it was never in the same spec. |
| 22:08 | <Lachy> | have I missed anything? |
| 22:09 | <Hixie> | i think that's it for now |
| 22:09 | <Hixie> | there's also webidl, geolocation, selectors api, xhr2, cors |
| 22:09 | <Lachy> | let's just call it something like The Web Platform, without a version number. |
| 22:09 | <Hixie> | the problem is you can't market "the web platform" without a number, because every browser supports "the web platform" |
| 22:09 | <Lachy> | or Web Core |
| 22:10 | <Hixie> | web dom core is a whole other thing, and should be on the list too :-) |
| 22:10 | <Lachy> | oh, that would clash with Web DOM Core. |
| 22:10 | <roc> | And Webcore |
| 22:10 | <Hixie> | the idea is to have something that you can point people to with "does your browser implement this?" |
| 22:10 | <Hixie> | to kind of establish a baseline term for web technologies that people generally agree should be implemented in the next gen web platform |
| 22:11 | <Hixie> | where "people" means us, primarily. :-) |
| 22:11 | <roc> | the most logical term would be Web5 |
| 22:11 | <Lachy> | The Cabal's Collection of Baseline Web Specs |
| 22:11 | <Hixie> | roc: can we get away with skipping 3.0 and 4.0 in the public eye? |
| 22:12 | <roc> | of course |
| 22:12 | <Hixie> | Lachy: you are off the naming committee. :-P |
| 22:12 | <jcranmer> | Stupendous Hypertext Index of Technology? |
| 22:13 | <Lachy> | damn, today isn't a good day. First my head explodes, and now I'm kicked of the committee. :-) |
| 22:13 | <Hixie> | jcranmer: also off the committee :-P |
| 22:13 | <Hixie> | i could buy Web 5.0 |
| 22:13 | <Lachy> | why does this need a version number? |
| 22:13 | <Hixie> | i'm just worried that people will focus on the skipping of 3.0 and 4.0 |
| 22:13 | <jcranmer> | sounds too... buzzword-y |
| 22:14 | <Hixie> | Lachy: because it'll change over time and it's easier to just have one name you keep revving than have multiple names |
| 22:14 | <Hixie> | jcranmer: it _is_ a buzzword. :-P |
| 22:14 | <jcranmer> | Specifications for Interoperable Platform-Independent Technology |
| 22:15 | <jcranmer> | Specifications for Interoperable Platform-Independent Mostly Backwards-Compatible Technology |
| 22:16 | <jcranmer> | Hixie's Specifications? |
| 22:16 | <Lachy> | but given that it will change gradually over time, and given the way browsers implement specs, the point at which we set the feature freeze for each version will be completely arbitrary. |
| 22:16 | <Hixie> | yes |
| 22:17 | <Hixie> | just like people referring to HTML5 now is arbitrary :-) |
| 22:17 | <Philip`> | HTML 2009.0 |
| 22:17 | <Philip`> | Just use dates instead of version numbers |
| 22:19 | <Lachy> | Philip`, not a good idea because if we say Web 2009 includes the 10 or so specs mentioned above, by the time they all get fully implemented and browsers start claiming support for this collection of specs, it will already be about 2019. |
| 22:20 | <Lachy> | I mean, if we want a way for browser marketing to make themselves sound out of date, it's a brilliant idea. |
| 22:21 | <Lachy> | I think calling it Web 5.0 would be a mistake because of it's similarity to Web 2.0, but with which it has absolutely no relation |
| 22:23 | <Lachy> | How about Core Web Specs |
| 22:23 | <Hixie> | i think the great thing about Web 3.0 or 5.0 is that it co-opts the Web 2.0 term to actually mean something |
| 22:23 | <Hixie> | embrace and extend |
| 22:24 | <Lachy> | But Web 2.0 does have a meaning in relation to the design and functionality of modern web sites. It's just not very specific about what design features qualify. |
| 22:25 | <Philip`> | Call it Acid 4 |
| 22:25 | <Philip`> | because that's already got the right brand association in people's minds |
| 22:25 | <Hixie> | roc: we could call the specs we are working on today 5.0, with the specs that are mostly done 4.0, and the specs of a few years ago 3.0, so that the Acid test numbers line up with the Web numbers :-) |
| 22:25 | <Hixie> | heh, Philip` thought of it at the same time |
| 22:26 | <Lachy> | so if we start with a version greater than 1.0, then we should retroactively describe roughly which specs correspond to the earlier versions. |
| 22:26 | <Philip`> | It's A Collection of Internet D... uh, Drafts? |
| 22:27 | <Hixie> | Lachy: agreed |
| 22:27 | <Hixie> | Philip`: hah |
| 22:28 | <jcranmer> | published by the Web Technology Foundation? |
| 22:28 | <jcranmer> | Web Task Force, sorry |
| 22:29 | <Lachy> | jcranmer, we already have the WHATTF. Introducing the WTF too might be a little confusing |
| 22:30 | jcranmer | intended it as a parody to IETF + the Internet Drafts |
| 22:33 | <Philip`> | People complain that the Acid tests are only testing a tiny part of necessary functionality for the web, and passing the test has little correlation to being able to render real web sites properly, so it makes sense to redefine Acid to be the entire collection of specs that ought to be supported, and the Acid tests can be the entire conformance test suites for those specs |
| 22:34 | <gsnedders> | We just need bigger Acid tests in general. |
| 22:37 | <Lachy> | gsnedders, I thought one of the complaints about acid 3 was that it was too large |
| 22:37 | <gsnedders> | Lachy: I don't care what other people think. In en-gb-x-sneddy where wrong is defined as disagreeing with me, they are wrong. |
| 22:38 | heycam | finds it interesting that the "Continue" button in the firefox unresponsive script window is the one that has the red X icon |
| 22:39 | <gsnedders> | It should be pink! |
| 22:39 | <heycam> | :) |
| 22:39 | <heycam> | and when did the green element definition sections get the funky border and identation |
| 22:40 | <gsnedders> | http://twitter.com/gsnedders/status/1260379505 |
| 22:40 | <heycam> | (the unresponsive script window is for status.js in html5 btw...) |
| 22:41 | <Hixie> | funky border and indentation? |
| 22:41 | <Hixie> | what version of firefox? |
| 22:41 | <Philip`> | (Everyone loves status.js!) |
| 22:41 | <heycam> | nightly from january |
| 22:42 | <Hixie> | hm |
| 22:42 | <Hixie> | try updating |
| 22:42 | <Hixie> | there were some problems around the beta1 timeframe |
| 22:43 | <heycam> | http://mcc.id.au/temp/funky-border.png |
| 22:43 | <heycam> | i like it |
| 22:44 | <jcranmer> | that does look nice |
| 22:44 | <Hixie> | oh, cool, glad you like it :-) |
| 22:44 | <heycam> | but is it accidental? |
| 22:44 | <Hixie> | it was to avoid the status boxes overlapping the element boxes |
| 22:44 | <Hixie> | no, it was intentional |
| 22:44 | <heycam> | ah ok good |
| 22:44 | <Philip`> | That border looks ugly in Opera (9.63) |
| 22:44 | <heycam> | damn unresponsive status.js keeps popping up every so often |
| 22:44 | <Philip`> | The horizontal bit extends one pixel too far to the right |
| 22:44 | <heycam> | does it run some script whenever i press a key or something? |
| 22:45 | <Lachy> | heycam, the design change was at my request to stop the status boxes overlapping. The weird indentation is a result of the way the spec is marked up and the limitations of CSS having no :matches() selector |
| 22:46 | <Hixie> | heycam: 500ms or so after you stop scrolling |
| 22:46 | <heycam> | ah. can you make status.js faster, for people with 5 year old computers like me? :) |
| 22:48 | <Hixie> | heycam: i don't really understand why it is slow |
| 22:48 | <gsnedders> | Hixie: Because you're running it on a kinda big document? |
| 22:49 | <Hixie> | well clearly |
| 22:59 | <Hixie> | but beyond that |
| 22:59 | <gsnedders> | Hixie: Because you can't write good optimized code? |
| 22:59 | gsnedders | ducks |
| 22:59 | <Hixie> | well i know that too |
| 22:59 | <Philip`> | Because the web platform is actually a pretty rubbish development environment? |
| 22:59 | <Hixie> | i mean, what exactly is the slow part |
| 22:59 | <Hixie> | Philip`: clearly |
| 22:59 | <heycam> | how come updateOffsetTops is passed an argument at one point, but the function doesn't use it? |
| 22:59 | <Philip`> | Hixie: Have you tried running it in a profiler? |
| 22:59 | <Philip`> | (Does Venkman still work and have a profiler?) |
| 22:59 | <gsnedders> | That'd be logical, so I'd assume not. |
| 22:59 | <Philip`> | (I vaguely remember it giving some kind of timing output when I last used it) |
| 22:59 | <gsnedders> | WebKit has one! :P |
| 22:59 | <jcranmer> | gsnedders: use dtrace! |
| 22:59 | <Hixie> | Philip`: i haven't successfully been able to get any of the dev tools to work with my firefox builds |
| 22:59 | <Hixie> | it appears part of the problem is that offsetTop is really slow in firefox |
| 22:59 | <gsnedders> | Then don't use it? |
| 22:59 | gavin | doubts that offsetTop itself is slow |
| 22:59 | <gavin> | but the layout flushes it triggers are another story |
| 22:59 | <Hixie> | i wait til after the page has painted to get the offsetTops |
| 22:59 | <Hixie> | and it takes upwards of a second to get all the offsetTop data of all the annotation boxes |
| 23:24 | <roc> | Firebug has a profiler |
| 23:26 | gsnedders | wants Coldbug |
| 23:28 | <Hixie> | gah why won't my browsers load my js files |
| 23:28 | gsnedders | informs Hixie of this <script> element |
| 23:28 | <Hixie> | it's a caching problem actually |
| 23:56 | <olliej> | roc: webkit has a profiler as well, i ahven't yet worked out how it decides how long is spent in functions though |
| 23:56 | <olliej> | roc: i'm not convinced it's restricting itself to the same rules of mathematics that we might usually expect |
| 23:57 | <roc> | I think everyone has a profiler now. Even IE8 has one |
| 23:58 | <olliej> | roc: .. lynx? ;D |
| 23:58 | olliej | hides |
| 23:58 | <roc> | ok ok ok you win |
| 23:58 | <olliej> | hehehe |
| 23:58 | <olliej> | victory! |
| 23:58 | olliej | does a dance |
| 23:58 | olliej | trips and falls |
| 23:59 | <roc> | I think our profiler turns off the JIT so it's probably less useful than it was |
| 23:59 | <olliej> | roc: ours doesn't |
| 23:59 | <roc> | need sample-based profiling of JITted code |
| 23:59 | <olliej> | roc: but omg |
| 23:59 | <olliej> | roc: completely nails performance |
| 23:59 | <olliej> | roc: yeah |
