| 08:49 | <jgraham> | Conclusion from the last two days of HTML related email: there is nothing interesting happening. |
| 10:35 | gsnedders | finally gets around to looking at what heycam changed in WebIDL because of him :P |
| 10:36 | <gsnedders> | Though trying to load the spec on train wifi isn't working brilliantly |
| 10:37 | <gsnedders> | (I guess dev.w3.org being on a sewing machine doesn't help) |
| 10:42 | smaug____ | imagines a server getting electricity from an old singer http://upload.wikimedia.org/wikipedia/commons/0/00/Singer_sewing_machine.jpg |
| 10:43 | <tomasf> | maybe they let the sewing machine "render" the page on actual fabric and automatically take a photo of it and deliver that as the web page |
| 10:46 | <jgraham> | Lack of a CSS media type for fabric suggests that isn't the case |
| 11:24 | <smaug____> | Does anyone have tests for canvas objects in "data" documents |
| 11:25 | <smaug____> | something like |
| 11:25 | <smaug____> | document.implementation.createHTMLDocument("").createElement("canvas").getContext("2d"); |
| 11:25 | <smaug____> | and then using that context somehow |
| 11:36 | <woef> | If they say html5 should be "backwards compatible" ... how far back in time are they talking about? |
| 11:37 | <jgraham> | If who says what? |
| 11:38 | <jgraham> | For developing HTML5 the tenets were more like "support existing content" and "no mode switching" |
| 11:38 | <woef> | I remember a discussion about why a <dl> only has "assumed" list items (no unique container) |
| 11:39 | <woef> | It was said that adding one was not backwardds compatible with what existed today. |
| 11:39 | <jgraham> | So you can't make changes that break (large enoguh numbers of) existing sites (that browser makers would be reluctant to make the changes). Since some sites are as old as the web, that gives a timescale |
| 11:40 | <woef> | Wouldn't it be interesting to make a "intermediate" tracks. Support two modes, until the old way of working gets fazed out? |
| 11:40 | <jgraham> | No |
| 11:40 | <jgraham> | It's a lot of effort |
| 11:40 | <jgraham> | and there is no good idea of what the timescale for the old way fading out is |
| 11:40 | <woef> | Yeah ... |
| 11:40 | <gsnedders> | woef: How many things have ever been fazed out? |
| 11:41 | <woef> | image maps? |
| 11:41 | <woef> | flash slowly is going away. |
| 11:41 | <jgraham> | (pretty sure phased is spelt wityh a ph and an s) |
| 11:41 | <woef> | fazed is the "i'm a cool geek" way of spelling ;) |
| 11:42 | <jgraham> | Ah. I never get those memos for some reaswon |
| 11:42 | <woef> | I'm afraid we don't really do the whole ph-thing in Belgium :) |
| 11:42 | <woef> | I get that wrong a lot. |
| 11:42 | <gsnedders> | woef: image maps are still supported by all browsers. |
| 11:42 | <jgraham> | woef: Yeah, but gsnedders is scottish. That's almost english, so he doesn't have an excuse |
| 11:43 | <woef> | Hah! |
| 11:43 | <gsnedders> | woef: An extreme example is the plaintext element, noted as being deprecated in the first ever HTML spec, still special-cased in the parser in HTML 5. |
| 11:44 | <woef> | I once tried to read some Irvine Welsh books, my English lessons didn't really help. |
| 11:44 | <gsnedders> | jgraham: I just copied what woef said! |
| 11:44 | <gsnedders> | jgraham: You know I can't spell. :P |
| 11:44 | <gsnedders> | Copying others is normally better than guessing myself :P |
| 11:44 | Philip` | is unphased by homonyms |
| 11:44 | <gsnedders> | (It also provides a convenient way to mitigate blame for my inability to spell.) |
| 11:45 | <jgraham> | Is someone who is phased by homonyms a homophobe? |
| 11:46 | <gsnedders> | woef: Speaking of Welsh, the only book I found hard to read was one with phonetic transcription of dialect from where I grew up. :) |
| 11:46 | <gsnedders> | (I can cope with it fine when spoken.) |
| 11:51 | <woef> | I think I tried Trainspotting once. |
| 11:51 | <woef> | But if I get it right, we'll never have a <dl> list with proper list items? |
| 11:51 | <woef> | Or nested <a>-tags? |
| 11:53 | <gsnedders> | woef: nested a-elements will break existing sites, so there's no way you'll get browsers to change behaviour. Equally, what does a link within a link *do*? |
| 11:53 | <gsnedders> | woef: What's the use-case for changing dl though? What's unclear about dt/dd? |
| 11:53 | <woef> | link to it's href? |
| 11:53 | <gsnedders> | woef: which href? |
| 11:53 | <jgraham> | gsnedders: (pretty obvious what it does, really) |
| 11:53 | <woef> | The one with the deepest nesting. |
| 11:53 | <jgraham> | Still won't happen ofc |
| 11:54 | <Philip`> | (Presumably it does the same as it does if you nest <a> in XHTML) |
| 11:54 | <woef> | Like "i block-level-link my blog intro but the contained link to the comment section goes there immediately" |
| 11:54 | <gsnedders> | jgraham: (that would require half a second of thought which I'm not doing while on vacation, even if I am responding to spec changes I requested) |
| 11:54 | <jgraham> | Or in HTML with script |
| 11:54 | <gsnedders> | woef: Still, changing the parser would break existing sites. |
| 11:54 | <woef> | gsnedders: how so? |
| 11:55 | <woef> | I hope nobody is nesting links now, if you see the dom-crap that ensues :) |
| 11:56 | <jgraham> | hahaha |
| 11:56 | <jgraham> | :) |
| 11:56 | <gsnedders> | woef: Plenty of people are. The vast majority of the web doesn't follow the spec. |
| 11:56 | <gsnedders> | Like, approximately 100% of the webhas invalid HTML. |
| 11:56 | <woef> | But these sites break by default :p |
| 11:57 | <jgraham> | I wonder what the half life of this conversation is |
| 11:57 | <gsnedders> | Breaking the web would cause people to not use a browser, so good luck getting any browser to change :P |
| 11:57 | <jgraham> | We've had the same discussion with different people since 2004 |
| 11:57 | <jgraham> | Hopefully it will eventually stop |
| 11:57 | <woef> | As for the <dl>, I just don't like that there is no <li> equivalent. |
| 11:58 | <jgraham> | That one at least might be changable |
| 11:58 | <jgraham> | There was a long thread on WHATWG a while back |
| 11:58 | <jgraham> | I don't remembert the conclusions |
| 11:59 | <woef> | You just say that to increase the suspense. |
| 12:00 | <jgraham> | Yep, it's practically Resident Evil in here |
| 12:01 | <gsnedders> | At least it's not the merky darkness of Doom 3. |
| 12:08 | <Philip`> | Does it count as suspense when you're 100% certain a monster is going to spring into existence behind you when you enter a room? |
| 12:09 | <gsnedders> | Okay, true, once you get beyond the first few levels it is like that. |
| 12:09 | <woef> | It killed AvsP2 |
| 12:10 | <woef> | The first one was creepy as hell though. |
| 12:10 | <woef> | Damn motion detector. |
| 13:20 | <hsivonen> | looks like ISSUEs are as important as ever http://www.w3.org/html/wg/tracker/issues/170 |
| 13:30 | <hsivonen> | looking at the number of duplicates on https://bugzilla.mozilla.org/show_bug.cgi?id=162653 I wonder if mattur will be able to find an XML design thread from 1997 or 1998 containing an assertion that HTML authors won't be confused by XML doing <foo/> |
| 13:41 | <gsnedders> | Is (char)(int)1 a plausible way to check endianness of integers |
| 13:41 | <gsnedders> | ? |
| 13:44 | <jgraham> | gsnedders: Won't the compiler get upset by that? |
| 13:44 | <jgraham> | See also http://stackoverflow.com/questions/1001307/detecting-endianness-programmatically-in-a-c-program |
| 13:44 | <gsnedders> | (Yay for writing code that depends on endianness) |
| 13:48 | <Philip`> | int i = 1; char c[sizeof(int)]; memcpy(c, &i, sizeof(int)); bool is_littleendian = c[0]; |
| 13:49 | <Philip`> | I'm not sure the union trick is actually legal C (though I'm not sure it's illegal either) |
| 13:49 | <Philip`> | but memcpy is always safe |
| 13:50 | <gsnedders> | Philip`: It's illegal, I'm pretty certain. At least people have managed to cite quite obvious bits of the spec about it. |
| 13:50 | <gsnedders> | (Well, it's not illgal, it's just undefined.) |
| 13:50 | <Philip`> | (char)(int)1 will always just give you 1, and *(char*)&i will give you bogus results depending on what compiler version and optimisation settings you use |
| 13:52 | <Philip`> | (The union thing works in all compilers in practice, though) |
| 13:52 | <gsnedders> | Philip`: Casting to char always take the low-bits? |
| 13:53 | <gsnedders> | Philip`: bool is C99? |
| 13:54 | jgraham | would imageine without knowing that casting to char does an actual type conversion rather than just reading some subset of the bits |
| 13:54 | <gsnedders> | jgraham: What else can it do? |
| 13:55 | <gsnedders> | jgraham: a char is just a numberic type |
| 13:55 | <gsnedders> | *numeric |
| 13:55 | <jgraham> | Well yes, I know that |
| 13:55 | <jgraham> | It could overflow differently, for example. And be endianness independent. |
| 13:56 | <Philip`> | If char is unsigned, then (char)i adds or subtracts 256 to/from i until it's in the range [0, 255] and then returns that |
| 13:56 | <Philip`> | If char is signed, and i is in [0, 255] then it returns that, else it's implementation-defined behaviour |
| 13:56 | <gsnedders> | Philip`: I could remember there was some magic about char, but I couldn't remember what. |
| 13:57 | <Philip`> | The magic thing is that you don't know whether it's signed or unsigned |
| 13:57 | <gsnedders> | And about casting as well? Which I guess is the adding/subtracting… |
| 13:58 | <Philip`> | (bool isn't in C99; use a BOOL or int or whatever, or use C++) |
| 13:59 | <Philip`> | In C99, casting is the same process for any integer types (except _Bool) |
| 13:59 | <Philip`> | ...except replace "256" by appropriate values etc |
| 14:00 | <tomasf> | according to http://en.wikipedia.org/wiki/Stdbool.h , bool expands to _Bool in C99 |
| 14:00 | <gsnedders> | Philip`: (Yeah, I know what to do) |
| 14:01 | <Philip`> | Basically it always does the mathematically obvious thing, except it's unwilling to assume two's-complement representation so any cases of signed overflow are implementation-defined behaviour |
| 14:02 | <Philip`> | and it's all endian-independent until you try to read the char representation of a larger value |
| 14:03 | <Philip`> | But in any case, it's usually more useful to know endianness at compile-time and not run-time |
| 14:04 | <gsnedders> | so reading an int into a short is endian dependent, assuming they're different sizes? |
| 14:04 | <Philip`> | since then you can have byte-swap macros that get replaced with noops |
| 14:04 | <Philip`> | so you should have a configure script or something to detect it and set a macro |
| 14:04 | <Philip`> | What do you mean by "reading into"? |
| 14:05 | <gsnedders> | *read the short representation of an int |
| 14:08 | <Philip`> | What do you mean by that? |
| 14:08 | <gsnedders> | Philip`: (But yes, it makes sense to do this in a saner way once I have all the setup to do that, which is pretty much going to be when I stop playing around with this code as a standalone application |
| 14:08 | <Philip`> | (Values have byte repesentations, not short representations) |
| 14:09 | gsnedders | wants to give up on IRC as this internet connection isn't working well |
| 14:09 | gsnedders | is on the WCML being all fancy and stuff in first-class, because Bank Holiday Monday => cheap upgrades. |
| 14:16 | <Philip`> | In practice, the solution that works 99.99% of the time is "#define IS_LITTLE_ENDIAN 1" |
| 14:18 | <gsnedders> | That's effectively what this code already is. :) |
| 14:32 | <karlcow> | http://glandium.org/blog/?p=2180 |
| 14:33 | <woef> | About the article tag ... why is it the author's responsability to decide what content is syndicable? |
| 14:37 | <woef> | Or is the "syndication" part just a way of helping you decide whether to use an article tag? |
| 16:08 | <zcorpan> | hey, a spambug reported from http://html5.clearboth.org/spec ! |
| 16:11 | <timeless> | anyone here have some time to consider some Web IDL? |
| 16:12 | <timeless> | X implements Y; |
| 16:12 | <timeless> | interface Y: Z; |
| 16:12 | <timeless> | Z implements P; |
| 16:12 | <timeless> | the contents of the interfaces are omited for brevity and the names have been changed to protect the guilty |
| 16:13 | <zcorpan> | the question is? |
| 16:14 | <timeless> | err lemme make sure i got that last line right |
| 16:14 | <timeless> | yeah, i did |
| 16:14 | <timeless> | well, first of all, is one really supposed to be using `implements` on interfaces which are inherited by other interfaces? |
| 16:14 | timeless | thought that `implements` was generally for objects and not interfaces |
| 16:16 | <timeless> | note to self: send feedback to list requesting a line "Generally you should use `dictionary Foo` instead of `[NoInterfaceObject] interface Foo`." |
| 16:17 | <zcorpan> | yeah implements might be a bad word |
| 16:18 | <zcorpan> | though i don't see what's wrong with using it on interfaces that are inherited |
| 16:21 | <timeless> | well |
| 16:21 | <timeless> | the problem is this: |
| 16:21 | <timeless> | ConcreteObject A; |
| 16:21 | <timeless> | A implements IFoo; |
| 16:21 | <timeless> | A implements IBar; |
| 16:21 | <timeless> | A implements IBaz; |
| 16:21 | <timeless> | ConcreteObject B; |
| 16:21 | <timeless> | B implements IFoo; |
| 16:22 | <timeless> | if someone decides that they have a `B` and want to make B's IFoo interface do more |
| 16:22 | <timeless> | they might say: |
| 16:22 | <timeless> | IFoo implements IMyFooMore; |
| 16:22 | <timeless> | expecting it to make B more powerful |
| 16:22 | <timeless> | but at the same time, it causes random effects on A |
| 16:22 | <timeless> | note that we had this experience in mozilla land |
| 16:22 | <timeless> | the rule which we try to enforce is this: |
| 16:23 | <timeless> | Only the owner of IFoo is allowed to extend IFoo until IFoo is frozen, at which point, IFoo /may/ but probably /should not/ be extended by others |
| 16:24 | <timeless> | roughly that translates into `You, owner of ConcreteObject X are free to use 'X implements IWhatever;' |
| 16:24 | <timeless> | but you are not free to use 'IStandardsBodyThing implements IWhatever;'.` |
| 16:57 | <dglazkov> | good morning, Whatwg! |
| 18:07 | Philip` | sees HTML5 supports ∡, which he will make good use of next time he wants to do some dangle measuring |
| 18:07 | <timeless> | heh |
| 18:07 | <timeless> | i need to send some feedback to some app vendors |
| 18:07 | <timeless> | they aren't unescaping entities :( |
| 18:07 | <timeless> | (it makes names of people and places really hard to read) |
| 18:11 | <ojan> | TabAtkins: ping |
| 18:25 | <zewt> | death to entities |
| 19:58 | <AryehGregor> | jgraham, this seems to not produce any output anymore. http://dvcs.w3.org/hg/html/raw-file/tip/tests/submission/AryehGregor/reflection/reflection-onepage.html |
| 20:04 | AryehGregor | can't see why |
| 20:05 | <AryehGregor> | It's not just the number of tests, I don't think. |
| 20:05 | timeless | sighs |
| 20:05 | <timeless> | maybe i was reading the wrong spec? |
| 21:39 | <jgraham> | AryehGregor: So it doesn't. I will look tomorrow |
| 21:39 | <AryehGregor> | jgraham, thanks. |
| 21:47 | <dglazkov> | Accio Hixie! |
| 21:47 | <dglazkov> | Hixie: are you working on the dialog plumbing? |
| 21:52 | <ojan> | TabAtkins: in your flex rewriting this week...are you touching flex-flow? |
| 21:52 | <ojan> | TabAtkins: what's there now seems...complicated |
| 21:57 | <dglazkov> | hey fsamuel! |
| 21:58 | <dglazkov> | fsamuel: this is Hixie's natural habitat. You can see a glimpse of him eating a banana here. Be very, very still. |
| 21:59 | <fsamuel> | dglazkov, Hixie: Hi dglazkov, hi hixie! :) |
| 22:00 | <dglazkov> | Hixie: meet fsamuel. He's been very interested in building user-stylable select menu drop-downs. I wondered if there's an overlap with your thinking on <dialog> |
| 22:23 | <smaug____> | AryehGregor: ping |
| 22:23 | <AryehGregor> | smaug____, pong. |
| 22:23 | <smaug____> | AryehGregor: about http://html5.org/specs/dom-range.html#range-behavior-under-document-mutation and splitText |
| 22:24 | <smaug____> | what if textnode's parent is null |
| 22:24 | <AryehGregor> | Don't I handle that explicitly? |
| 22:24 | <AryehGregor> | "If old node's parent is not null, . . ." |
| 22:24 | <smaug____> | AryehGregor: you handle not-null case |
| 22:24 | <smaug____> | but where is the is null |
| 22:25 | <AryehGregor> | That's a corner case, so nothing special happens. Regular range mutation rules apply. |
| 22:25 | <AryehGregor> | IIRC I used to handle it, but decided it was pointless to worry about it. |
| 22:25 | <smaug____> | hmm |
| 22:25 | <AryehGregor> | Often you can't do better than the default behavior anyway. |
| 22:25 | <AryehGregor> | Since the range can't span the two text nodes. |
| 22:25 | <smaug____> | AryehGregor: so what if you split text between the boundary points |
| 22:26 | <AryehGregor> | If the parent is null? Exactly what Gecko does now: any boundary point after the offset you're splitting at is clamped to the end of the node. |
| 22:26 | <AryehGregor> | There's no special case then. |
| 22:27 | <smaug____> | ah |
| 22:27 | <smaug____> | ok |
| 22:27 | <smaug____> | a bit hard to read but ok |
| 22:27 | <smaug____> | I mean the draft |
| 22:28 | <AryehGregor> | What wording would you suggest? |
| 22:29 | <smaug____> | well, I was assuming that since there is the "If old node's parent is not null" case, there would be also the "is null" case |
| 22:30 | <AryehGregor> | Would you assume that when reading code? If it doesn't give the case, it's not there. |
| 22:30 | <AryehGregor> | This is really just pseudocode. |
| 22:30 | <smaug____> | well, there is the other case defined |
| 22:30 | <smaug____> | "User agents must run the following steps whenever they execute splitText()" |
| 22:31 | <AryehGregor> | Right, just sometimes they do nothing. Of course, the horrible way this is written is a hack to work around the fact that we haven't merged it into DOM Core yet. |
| 22:31 | <smaug____> | well, they need to update the boundary points when parent is null |
| 22:31 | <smaug____> | that is not "do nothing" |
| 22:32 | <AryehGregor> | It's "do nothing extra". |
| 22:32 | <smaug____> | the draft doesn't say that do something, but when splitText() is called, do something extra |
| 22:33 | <AryehGregor> | It says UAs have to run the steps as though they were written at the end of splitText(). |
| 22:33 | <AryehGregor> | Earlier than that, splitText() replaced data and probably inserted a node. |
| 22:33 | <AryehGregor> | That already triggered different mutation rules. |
| 22:33 | <AryehGregor> | I have a note there that points this out explicitly: "Thus they must be executed after following the range mutation rules for any changes to data or insertions that the method caused." |
| 22:34 | <AryehGregor> | Also, one of the steps is "Let original offset equal what the boundary point's offset was before this splitText invocation replaced the data of node." That doesn't make any sense if you didn't already have range mutation rules running beforehand. |
| 22:34 | <AryehGregor> | I'd ask for suggestions to make this clearer, but it will be moot once it's merged into DOM Core. |
| 22:35 | <smaug____> | a lot clearer would be to add just the case for null parent |
| 22:35 | <smaug____> | or at least a link |
| 22:36 | <AryehGregor> | A link to what? |
| 22:36 | <smaug____> | to the part of the spec which says what to do when parent is null |
| 22:36 | <AryehGregor> | You do nothing extra when the parent is null. |
| 22:37 | <smaug____> | this is about readability of the spec |
| 22:37 | <smaug____> | not correctness |
| 22:37 | <AryehGregor> | Readability is a mess because it's trying to hack extra steps onto DOM Core when DOM Core doesn't provide hooks for it. |
| 22:37 | <AryehGregor> | This will be solved when DOM Range is merged into DOM Core, so this will just be an extra step or two in the splitText() algorithm itself. |
