| 00:01 | <TabAtkins> | Augh, I need to move off of Aurora. twice-a-day restarts are killing me. |
| 02:37 | <jwalden> | TabAtkins: I thought we only updated once a day |
| 04:07 | <Hixie> | there's no shipped way to save a canvas across page loads and sessions, right? |
| 04:07 | <Hixie> | since nobody saves imagedata to web storage? |
| 04:10 | <beverloo> | could get an image from the canvas and store that, I suppose |
| 04:11 | <Hixie> | like the data: URL? |
| 04:11 | <Hixie> | i guess |
| 04:11 | <beverloo> | Yes |
| 04:11 | <Hixie> | that's pretty messed up |
| 04:11 | <Hixie> | but i guess it would work |
| 04:11 | <Hixie> | i wonder what the perf implications would be |
| 04:35 | <Hixie> | if i have two <div>s with similar but not identical content that overlap |
| 04:36 | <Hixie> | and i want to fade from one to the other |
| 04:36 | <Hixie> | is there a way to do it that doesn't involve the areas that are the same changing coloru at all? |
| 05:11 | <othermaciej> | Hixie: layer one over the other, transition opacity of the top one from 100% to 0% |
| 05:12 | <zewt> | only works for opaque images |
| 05:15 | <othermaciej> | zewt: I assume from Hixie's example that both divs in question have or can be given an opaque background |
| 05:16 | <zewt> | i assumed the more complex case since i figured he knew how to use opacity :) |
| 05:17 | <othermaciej> | hmm, maybe they overlap but not 100% |
| 05:17 | <othermaciej> | and he wants to change which is "on top" |
| 05:17 | <othermaciej> | that would be less obvious |
| 05:48 | <annevk> | oh yes |
| 05:48 | <annevk> | make works again |
| 05:49 | <annevk> | macports however is still broken |
| 05:56 | <Hixie> | man some of these lion changes are quite buggy |
| 05:57 | <Hixie> | e.g. the flickering when you switch from one terminal to another if you have different settings for blur for active vs inactive windows |
| 06:00 | <Hixie> | or this crazy sheering effect in the screen saver prefs "shuffle photos" sheet |
| 06:14 | <annevk> | http://trac.webkit.org/browser/trunk/Source/WebCore/dom/TreeWalker.cpp#L139 how does the "sibling = sibling->previousSibling();" line matter? |
| 06:15 | <annevk> | look like sibling will be set by the for loop right after |
| 07:00 | <annevk> | http://trac.webkit.org/browser/trunk/Source/WebCore/dom/TreeWalker.cpp#L139 how does the "sibling = sibling->previousSibling();" line matter? |
| 07:00 | <annevk> | look like sibling will be set by the for loop right after |
| 07:00 | <annevk> | othermaciej, ^^ |
| 07:01 | <othermaciej> | annevk: which "sibling = sibling->previousSibling()" line? |
| 07:02 | <annevk> | 163 |
| 07:02 | <othermaciej> | (I see at least two lines that say that) |
| 07:03 | <othermaciej> | that loop is a little mysterious to me |
| 07:03 | <annevk> | glad I am not the only one |
| 07:03 | <othermaciej> | in the "NodeFilter::FILTER_REJECT", nothing updates node |
| 07:04 | <othermaciej> | so it seems like that would cause an infinite loop |
| 07:05 | <othermaciej> | likewise for NodeFilter::FILTER_SKIP in the case where sibling has no children |
| 07:05 | <othermaciej> | maybe break actually breaks out of the loop instead of the switch statement |
| 07:05 | <othermaciej> | or is intended to |
| 07:05 | <othermaciej> | or something |
| 07:05 | <annevk> | in both of those cases you want the previousSibling |
| 07:06 | <othermaciej> | annevk: oh, nevermind |
| 07:06 | <othermaciej> | RefPtr<Node> sibling = node->previousSibling() is the initializer |
| 07:06 | <othermaciej> | the for loop has no increment step |
| 07:06 | <othermaciej> | and the loop condition is sibling not being null |
| 07:06 | <othermaciej> | so it totally makes sense |
| 07:06 | <annevk> | but how does line 163 make sense? |
| 07:07 | <annevk> | the for loop overwrites that, no? |
| 07:19 | <othermaciej> | annevk: no |
| 07:19 | <othermaciej> | annevk: the for loop's assignment to sibling is the initializer, not the increment |
| 07:19 | <othermaciej> | annevk: so it only sets sibling the first time before entering the loop |
| 07:20 | <annevk> | ah thanks |
| 09:34 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-treewalker-parentnode |
| 09:34 | <annevk> | Would be nice to auto feed concept-node-filter with whatToShow and filter somehow |
| 09:35 | <annevk> | Maybe besides "active flag" I should just define whatToShow and filter as concepts and then say that the attributes on the objects map to those concepts? |
| 09:36 | <annevk> | It has to be something like that; the current way is way verbose |
| 09:36 | <Ms2ger> | wfm |
| 09:46 | <annevk> | not sure when I'll get to it btw |
| 09:47 | <annevk> | got up a little too early and am now gonna relax for a while :) |
| 09:47 | <annevk> | but feedback welcome |
| 09:50 | <ivan`> | any ideas why Access-Control-Allow-Origin doesn't have subdomain wildcards? |
| 09:50 | <ivan`> | hmm, maybe I can just convince the server to send the right header for whichever subdomain |
| 10:35 | <hsivonen> | ivan`: the design of CORS assumes that it is applied to dynamic content, so it's OK to require the headers to vary, too. By not allowing wild-carding, the programmer is forced to think more and is assumed to be less likely to declare bad policies |
| 10:35 | <hsivonen> | ivan`: the result is, though, that CORS really sucks for static resources like images or fonts |
| 10:35 | <hsivonen> | if you want anything more granular than the blanket anything-goes wildcard * that is |
| 10:36 | <hsivonen> | this would become a lot less painful if Apache shipped with a mod_cors |
| 11:06 | <ivan`> | hsivonen: thank you |
| 11:07 | <ivan`> | I was worried about that header getting cached |
| 11:07 | <ivan`> | and then later I learned I could also just look at Origin |
| 11:10 | <ivan`> | anyway, now I see that it doesn't get cached, obviously |
| 15:38 | <dpy> | hi guys |
| 15:39 | <jgraham> | hej |
| 15:39 | <dpy> | Where would I post bug reports about this (i.e. which bugzilla component): http://validator.nu/?doc=http%3A%2F%2Fjsbin.com%2Fetabil%2F3 |
| 15:42 | <hsivonen> | dpy: do you mean the spelling bug "Namspaces"? |
| 15:42 | <dpy> | no, data-[ is a valid data-attribute name |
| 15:42 | <dpy> | and so are data-$, data-%, etc. |
| 15:43 | <jgraham> | Oh, I thought you meant that the line numbers were wrong :) |
| 15:43 | <dpy> | basically anything that is a non-space character in available unicode that is not a control character and not [\0"'/=] |
| 15:43 | <hsivonen> | dpy: that's not what the spec said last time I looked |
| 15:44 | hsivonen | looks again |
| 15:44 | <Philip`> | http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data-with-the-data-*-attributes |
| 15:44 | <dpy> | http://www.w3.org/TR/html5/syntax.html#attributes-0 <-- ? |
| 15:44 | <Philip`> | "▶ A custom data attribute is an attribute in no namespace whose name starts with the string "data-", has at least one character after the hyphen, is XML-compatible, and contains no characters in the range U+0041 to U+005A (LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z)." |
| 15:45 | <Philip`> | "Attribute names are said to be XML-compatible if they match the Name production defined in XML, they contain no U+003A COLON characters (:), and their first three characters are not an ASCII case-insensitive match for the string "xml"." |
| 15:45 | <hsivonen> | dpy: what Philip` said |
| 15:45 | <dpy> | What source are you quoting? |
| 15:45 | <dpy> | that link? |
| 15:45 | <hsivonen> | dpy: http://www.whatwg.org/specs/web-apps/current-work/#embedding-custom-non-visible-data-with-the-data-*-attributes |
| 15:45 | <hsivonen> | and http://www.whatwg.org/specs/web-apps/current-work/#xml-compatible |
| 15:46 | <dpy> | So the stuff on w3.org is outdated? |
| 15:46 | <jgraham> | Well yes, but more to the point it's the wrong part of the spec |
| 15:47 | <Philip`> | http://www.w3.org/TR/html5/elements.html#embedding-custom-non-visible-data-with-the-data-attributes is the relevant part |
| 15:47 | <jgraham> | In general anything on TR/ is outdated |
| 15:47 | <Philip`> | which hasn't changed since the obsolete TR/ |
| 15:47 | <jgraham> | And, increasingly, it seems that anything on the W3C site will be outdated |
| 15:47 | <dpy> | What does TR stand for if I may ask? |
| 15:47 | <hsivonen> | dpy: Technical Reports officially |
| 15:47 | <jgraham> | Temporally Retarded |
| 15:47 | <dpy> | lol |
| 15:48 | <Ms2ger> | TRash |
| 15:49 | <dpy> | Still, I think it is strange that two parts of the spec (at one point) seems to be ambiguous |
| 15:49 | <dpy> | but I probably misread |
| 15:50 | <dpy> | oh wait |
| 15:50 | <hsivonen> | dpy: you quoted a part about attributes in general. data-* attributes have more specific rules on top of the general stuff |
| 15:50 | <dpy> | yeah, the part I read was about the syntax |
| 15:50 | <Philip`> | The "Writing HTML documents" section says the form that attributes take, but you're only allowed to use attributes that are explicitly defined in the semantics |
| 15:50 | <dpy> | ok, I understand |
| 15:51 | <dpy> | too bad, would've been nice to be able to write things like: data-$foo= or data-foo[0]= |
| 15:51 | <Philip`> | which is a finite set of attributes plus a particular infinite subset of the ones start with "data-" |
| 15:52 | <Philip`> | so the attribute "data-$" is no different to the attribute "$$$" |
| 15:52 | <Philip`> | (in terms of conformance, at least) |
| 15:52 | <Philip`> | (unless I'm mistaken) |
| 15:55 | <hsivonen> | I fixed the typo in version control. Will deploy at some point but not now. |
| 16:09 | <dpy> | okay.. show set [:ANY:] on unicode.org was not a good idea |
| 16:22 | <TabAtkins> | dpy: Hah, indeed. |
| 16:22 | <TabAtkins> | "Please show me 10000 characters." |
| 16:26 | <dpy> | Why is data-a:0 not a valid attribute name? |
| 16:26 | <TabAtkins> | Because : makes the name not xml-compatible. |
| 16:27 | <TabAtkins> | (Philip` gave the description of "xml-compatiable" from the spec about 45min ago.) |
| 16:27 | <dpy> | Well, the html specs send me to the #NT-Name anchor of XML |
| 16:27 | <TabAtkins> | Just do data-a_0 |
| 16:27 | <dpy> | and a:0 is a valid name according to that production |
| 16:28 | <TabAtkins> | http://www.whatwg.org/specs/web-apps/current-work/#xml-compatible |
| 16:28 | <dpy> | it even explicitly states in text: "author should not use the colon in XML names except for namespace purposes, but XML processors must accept the colon as a name character" |
| 16:28 | <Philip`> | "... they contain no U+003A COLON characters (:)" |
| 16:28 | <Philip`> | (from #xml-compatible) |
| 16:29 | <dpy> | I stand corrected |
| 16:29 | <dpy> | I overlooked that by clicking through |
| 16:29 | <dpy> | seems that some people are trying very hard to not try to put indexed values in a data-attribute name |
| 16:30 | <dpy> | and that's exactly what I would like to be able to do |
| 16:30 | <TabAtkins> | No, it's an incidental consequence of making the attribute xml-compatible. |
| 16:30 | <Philip`> | What's the situation where you're trying to do that? |
| 16:30 | <TabAtkins> | Use an underscore. |
| 16:31 | <dpy> | the problem with the underscore is that it's typically also allowed in names where I don't expected indexed values |
| 16:31 | <dpy> | my software would not be able to distinguish between them |
| 16:31 | <Philip`> | I think the usual assumption for structured data is that you can do it with JSON, like data-whatever="[1,2,3]" instead of data-whatever[0]="1" ... |
| 16:31 | <TabAtkins> | Make those names use - instead. |
| 16:31 | <dpy> | Philip`: yes, but that get's hairy when we're not simply talking 1, 2 3 |
| 16:32 | jgraham | wonders what is not hairy munging text from an attibute name but is hairy parsing its value |
| 16:34 | <dpy> | I have three independent pieces of JSON, which are much easier to read when stored in three attributes than as a single JSON list crammed into a single attribute |
| 16:34 | <annevk> | * Microsoft will be submitting tests for SCA (Structured Cloning Algorithm, Forms, Async Script, Drag & Drop and Sandbox). |
| 16:34 | <annevk> | better set aside some reviewing time |
| 16:34 | <jgraham> | Really [[1,2,3], [2,,5,6], [7,8,9]] doesn't seem that hard to read |
| 16:35 | <jgraham> | And it is even easy to parse |
| 16:35 | <dpy> | jgraham: now replace each of the characters by a nested JSON structure |
| 16:35 | <jgraham> | dpy: If you have nested structures anyway, having an array of three of them doesn't seem at all bad compared to having three seperately |
| 16:36 | <dpy> | like: [{"foo":["X","Y","Z"],"bar":[...]"},{"foo":["X","Y","Z"],"bar":[...]"},{"foo":["X","Y","Z"],"bar":[...]"},{"foo":["X","Y","Z"],"bar":[...]"},{"foo":["X","Y","Z"],"bar":[...]"}] |
| 16:36 | <dpy> | and compare this with: |
| 16:36 | <dpy> | foo[0]={"foo":["X","Y","Z"],"bar":[...]"} |
| 16:36 | <dpy> | foo[1]={"foo":["X","Y","Z"],"bar":[...]"} |
| 16:36 | <dpy> | + ' ' |
| 16:37 | <dpy> | jgraham: well, it is if you keep in mind that it is likely for one of these to change and you need to resolve conflicts |
| 16:37 | <jgraham> | Well if you really care you can write {0:{"foo":["X","Y","Z"],"bar":[...]"},\n1:{"foo":["X","Y","Z"],"bar":[...]"}} |
| 16:38 | <dpy> | If your users aren't experiences programmers, I'd rather have them solve 2 attributes that are in conflict, than bore them with the details of JSON |
| 16:38 | <jgraham> | I am having great difficulty in seeing how having three attributes containing JSON is easier than having one attribute contaning JSON |
| 16:39 | <dpy> | I expect my users to understand html5, not JSON |
| 16:39 | <dpy> | now they are required to understand JSON |
| 16:39 | <dpy> | to solve a merge conflict |
| 16:40 | <jgraham> | I totally don't understand how they could not need to understand JSON if the data they are merging is in JSON |
| 16:40 | <dpy> | plus I liked the idea: one data-attribute = one property |
| 16:40 | <dpy> | not: some data attributes define multiple properties |
| 16:41 | <TabAtkins> | dpy: What happens if your data structure ends up nesting more deeply? |
| 16:41 | <jgraham> | Well you can do it your way if you like. But you have to use syntax that doesn't conflict with XML |
| 16:41 | <dpy> | jgraham: you don't need to understand the details of a syntax to point out which line you want to keep and which you don't |
| 16:41 | <dpy> | like: it's easier to read something, than it is to write it |
| 16:42 | <dpy> | TabAtkins: they are always singly lined, and should not get too complicated (otherwise something else is probably smelly) |
| 16:42 | jgraham | hopes you are not planning to use this for anything important |
| 16:42 | <jgraham> | Because expecting people to edit data in a format they don't understand |
| 16:42 | <jgraham> | That's not gonna work |
| 16:43 | <dpy> | jgraham: I'm obviously not able to do much about the status quo... I'm clearly not allowed to do it the way I like... |
| 16:43 | <TabAtkins> | So anyway, point is, you're free to embed things however you like if you use xml-compatible names (which happens to exclude some of the more natural ways to write what you want). It may be a better idea to just embed json, but whatever. |
| 16:43 | <dpy> | TabAtkins: I agree with you |
| 16:44 | <dpy> | Though I don't like it, it seems the only viable alternative, given the great lengths the specification has gone to prevent what I want to do |
| 16:45 | <TabAtkins> | dpy: You're making it sound like the spec went out of its way to prevent you from making it easy to solve your case. It didn't. It just said that custom attributes have to obey the same syntax rules as every other attribute in the language. |
| 16:45 | <dpy> | I would have rather seen a more liberal approach: You can use anything, except these... |
| 16:45 | <dpy> | Rather then: you can't use anything except these... |
| 16:45 | <dpy> | then=than |
| 16:46 | <TabAtkins> | If you get an identical set of allowed characters either way, it seems irrelevant whether the set is specified additively rather than subtractively. |
| 16:46 | <dpy> | TabAtkins: I don't take it personal. I'm feeling it as though it was a partical design choice. I may not agree with it, but it's fact now, so I might just as wel accept the situation |
| 16:47 | <dpy> | TabAtkins: " It just said that custom attributes have to obey the same syntax rules as every other attribute in the language." <-- this is not true. non-data HTML5 attributes are much less restricted |
| 16:48 | <TabAtkins> | Huh? How so? |
| 16:48 | <Philip`> | Non-data attributes are entirely restricted because you can't use any of them at all (except the finite set listed in the spec) |
| 16:48 | <dpy> | So any future attribute can still be written like: foo[2]= and current parsers need to accept it |
| 16:48 | <TabAtkins> | That's only possible in the case that the spec changes the rules and allows a non-XML-compatible attribute name. |
| 16:48 | <dpy> | Philip`: I'm talking about restrictions toward the future |
| 16:49 | <dpy> | TabAtkins: Where do you read that a non-data attribute must be xml compatible |
| 16:49 | <dpy> | ? |
| 16:49 | <TabAtkins> | It wouldn't make much sense for the spec to impose restrictions on itself, given that it's the spec and can just change those restrictions later. |
| 16:49 | <TabAtkins> | dpy: Every attribute is XML-compatible. |
| 16:50 | <TabAtkins> | dpy: Also, informally, keeping the language such that it generates the same DOM in HTML and XHTML as much as possible has been a strong goal. |
| 16:50 | <Philip`> | Parsers accept data-foo[2]="..." exactly the same way as foo[2]="...", and expose it as e.dataset["foo[2]"] etc - the only restrictions are for conformance (to discourage dangerous or XML-incompatible syntax)) |
| 16:50 | <Philip`> | s/)// |
| 16:52 | <dpy> | Philip`: I should I read that? That I can use it safely, or that I can't? |
| 16:52 | <TabAtkins> | You, as an author, are required to not do it. |
| 16:52 | <TabAtkins> | Browsers are required to accept to it. |
| 16:52 | <TabAtkins> | s/to it/it/ |
| 16:53 | <dpy> | I don't want to have a broken app, if something in the spec changes and the browsers no longer accept my data-attributes |
| 16:53 | <zewt-> | the usual contradiction. heh |
| 16:53 | <TabAtkins> | (Because every possible sequence of bits is an HTML document, though possibly an invalid one, and must have rules on how to process it.) |
| 16:54 | <dpy> | Okay, this is the old: be strict in what you produce, be unstrict in what you accept |
| 16:54 | <oal> | Is it possible to insert a link <a href="something">..</a> with css? When I do it with :after {content: 'somehtml'} it displays as text |
| 16:54 | <TabAtkins> | Basically, yeah. |
| 16:54 | <Ms2ger> | oal, only in Opera |
| 16:54 | <TabAtkins> | oal: No. Linking is an HTML behavior that can't be controlled with CSS. |
| 16:55 | <Ms2ger> | And Prince, I think |
| 16:55 | <oal> | Ok :/ |
| 16:57 | <Philip`> | If it was argued sufficiently convincingly that allowing non-XML-compatible characters in attribute names would be the best solution to some use cases, and if people were in a fed-up-with-XML mood and didn't mind abandoning the pretence of supporting it as an equal to text/html, then the conformance requirements could be relaxed and nothing else would change |
| 16:57 | <dpy> | Hurray! |
| 16:57 | <Philip`> | (since browsers will already parse it in the expected way) |
| 16:57 | <dpy> | Middle dot to the rescue: |
| 16:57 | <dpy> | data-foo·0="bar" |
| 16:57 | <dpy> | is allowed |
| 16:57 | <Philip`> | That's disgusting :-p |
| 16:57 | <zewt> | gross |
| 16:57 | <dpy> | now don't you guys dare take this away from me! |
| 16:57 | <dpy> | :P |
| 16:57 | <TabAtkins> | It seems bad to use non-ascii characters in an attribute, since you can't type them on your keyboard without an OS escape sequence, but whatever. ^_^ |
| 16:58 | <TabAtkins> | Also, retrieving the attribute will be more difficult. |
| 16:58 | <Ms2ger> | Mm, can you use entities in attribute names? |
| 16:58 | <dpy> | TabAtkins: they aren't really meant to be typed, so people can't accidentally type them.. which may even be a good thing |
| 16:58 | <TabAtkins> | Ms2ger: Don't think so. |
| 16:59 | <Philip`> | dpy: I thought you wanted inexperienced people to edit these things by hand |
| 16:59 | <dpy> | Philip: read: delete stuff |
| 16:59 | <dpy> | Philip`: but it may be a bad idea tomorrow morning |
| 17:00 | <Philip`> | Ms2ger: No but you could always write <script>document.write('<div data-foo\xb7')</script>="...data..."></div> if you want to avoid non-ASCII source |
| 17:01 | Ms2ger | glares at Philip` |
| 17:02 | <Philip`> | Oops, I forgot the 0 in there |
| 17:02 | <annevk> | jgraham, congrats on the labs release! |
| 17:08 | <annevk> | https://plus.google.com/112095156983892490612/posts/EMADdvHSRbH |
| 17:08 | <annevk> | gotta love the rhetoric in the comments |
| 17:10 | <TabAtkins> | I'm surprised. Julian's suggestion seems reasonable. |
| 17:10 | <dpy> | Okay, maybe it's just best to go with data-foo_0, foo.bar_0, foo.bar.xyz_0 and just prohibit my users to use the underscore _ (they'll just have to use the full stop as a delimiter) |
| 17:11 | <TabAtkins> | dpy: Or the dash. |
| 17:11 | <dpy> | TabAtkins: the dash is interpreted |
| 17:11 | <annevk> | His suggestion is basically what is being done, no? |
| 17:11 | <annevk> | Bunch of new features do not appear in the W3C draft |
| 17:11 | <dpy> | data-foo-0 becomes foo0, right? |
| 17:11 | <TabAtkins> | Only if you use the dataSet accessor. |
| 17:11 | <TabAtkins> | dataset.foo0 |
| 17:11 | <dpy> | just as data-foo-bar becomes fooBar |
| 17:12 | <TabAtkins> | But if you're using dataSet, you can't access anything with a period in it. |
| 17:12 | <dpy> | huh? |
| 17:12 | dpy | checks |
| 17:12 | <TabAtkins> | Or rather, you'd need to access it like an array. dataSet['foo.bar'] |
| 17:13 | <TabAtkins> | Though, actually... let me check the spec real quick about data-foo_0 |
| 17:13 | <Philip`> | (dataset, not dataSet) |
| 17:13 | <TabAtkins> | dpy: No, data-foo-0 is not changed. |
| 17:13 | <dglazkov> | good morning, Whatwg! |
| 17:13 | <TabAtkins> | it's still dataset['foo-0'] |
| 17:14 | Hixie | nods to dglazkov |
| 17:14 | <TabAtkins> | Or rather, data-foo_0 is still dataset['foo_0'] |
| 17:14 | <TabAtkins> | Well, both. |
| 17:15 | <TabAtkins> | ANYWAY, you only drop the dash if the following character is a lowercase letter (and then you uppercase that letter) |
| 17:15 | <dpy> | ok |
| 17:15 | <dpy> | I'll report that back to my team |
| 17:16 | <TabAtkins> | annevk: Not really. The HTMLWG hasn't branched properly, it's forced Hixie to branch and then keep the branch in line with trunk. |
| 17:16 | <dpy> | TabAtkins: tnx |
| 17:16 | <TabAtkins> | If we did a proper branch, a lot would be easier (and the HTMLWG branch would be immediately obsolete). |
| 17:17 | <annevk> | and keep maintaining it as Julian suggests? |
| 17:17 | <annevk> | sounds like a bad idea |
| 17:17 | <TabAtkins> | annevk: If the HTMLWG is maintaining a frozen branch, it's not really important. |
| 17:18 | <annevk> | I don't see how it would be better |
| 17:20 | <Ms2ger> | Less work for Hixie, more time to do something useful? |
| 17:20 | <TabAtkins> | I was just typing that. |
| 17:21 | Ms2ger | finally beat TabAtkins to something |
| 17:22 | <hsivonen> | annevk: regarding rhetoric, Leigh Klotz is an XForms guy, right? |
| 17:22 | <annevk> | think so, yes |
| 17:23 | <TabAtkins> | In other words, "someone who's bitter about the fact that browsers are the only relevant user of HTML". |
| 17:23 | Philip` | guesses one significant danger is more time being wasted by people who read and/or implement the W3C version of the spec without realising it's obsolete |
| 17:24 | <annevk> | yeah, it does not seem like a smart thing |
| 17:24 | <annevk> | to let that run wild |
| 17:24 | <TabAtkins> | The alternative is dealing with the HTMLWG continually trying to an LC. |
| 17:25 | <annevk> | if the W3C wants to move on they should focus more on tests and less on process |
| 17:25 | <annevk> | or change the process |
| 17:25 | <annevk> | tests and implementations are the bottleneck to move HTML5 forward there, nothing else |
| 17:25 | <annevk> | they are always the bottleneck |
| 17:26 | <Ms2ger> | Weren't they going to hire people to write tests from the HTML5 T-shirt sales? |
| 17:27 | <jgraham> | Well they said they would use them to fund testsuite development |
| 17:27 | <jgraham> | Not exactly how |
| 17:27 | <Philip`> | Maybe nobody has bought them since they're waiting for the Living Standard T-shirts |
| 17:27 | <jgraham> | So maybe they are saving it all for a big testsuite-development party |
| 17:27 | <jgraham> | With champagne and caviar |
| 17:28 | <annevk> | damnit |
| 17:28 | <annevk> | this stuff requires subsubsteps |
| 17:28 | <annevk> | jgraham is gonna kill me |
| 17:28 | <jgraham> | You should do it like ES |
| 17:28 | <jgraham> | It's really better :) |
| 17:29 | <annevk> | how do they do break? |
| 17:29 | <jgraham> | I don't recall. But usually you can avoid it if you structure the loop correctly |
| 17:29 | <Ms2ger> | jgraham, when we go to PR? |
| 17:30 | <annevk> | example: |
| 17:30 | <jgraham> | Ms2ger: Any earlier and we wouldn't be able to afford real champagne |
| 17:30 | <annevk> | while node is not null |
| 17:30 | <annevk> | sibling = node nextSibling/previousSibling |
| 17:30 | <annevk> | if sibling |
| 17:30 | <annevk> | node = sibling |
| 17:30 | <annevk> | break (back to outer loop) |
| 17:30 | <Philip`> | Split it into a separate function and do a 'return'? |
| 17:30 | <Ms2ger> | while node is not null and (random boolean) is true |
| 17:30 | <Ms2ger> | ... (random boolean) = false |
| 17:31 | <annevk> | eww |
| 17:31 | <Ms2ger> | :) |
| 17:31 | <jgraham> | Well anything is better than "and terminate these sub sub steps" |
| 17:31 | <Ms2ger> | goto |
| 17:31 | <hsivonen> | break; |
| 17:31 | <jgraham> | Well annevk uses goto as well |
| 17:31 | <hsivonen> | well, break with label |
| 17:32 | <hsivonen> | it's annoying that C++ lack break with label |
| 17:32 | <hsivonen> | but spec English doesn't have to lack break with label |
| 17:32 | Philip` | has occasionally done "for (i = 0; i < 100; ++i) { for (j = 0; j < 100; ++j) { ... if (whatever) i = 100; /* break out of outer loop */ } }" |
| 17:32 | <Philip`> | (but then felt unbearably dirty) |
| 17:32 | <Ms2ger> | And you should |
| 17:33 | <Philip`> | (and usually rewrote it as function with 'return' since that's the least nasty unstructured control flow statement) |
| 17:36 | <annevk> | separate algorithms work I guess, but it seems so pointless |
| 17:37 | <annevk> | or maybe I should go the Ms2ger route |
| 17:37 | <annevk> | with a silly variable |
| 17:37 | <Ms2ger> | Silly? That's me :) |
| 17:37 | <annevk> | oh wait, that does not work |
| 17:38 | <annevk> | well i would have to check it in several other places too, that would suck |
| 17:41 | <annevk> | man this sucks |
| 18:10 | <annevk> | because I can http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-treewalker-firstchild |
| 18:29 | <nmadzharov> | hi |
| 18:32 | <nmadzharov> | is handleEvent( Event evt) { if(evt.isMouseEvent()) MouseEvent me = (MouseEvent) evt; } a common way to implement the function? |
| 18:39 | <TabAtkins> | I presume you're talking about something other than JS. |
| 18:48 | <AryehGregor> | http://trevorparscal.com/stuff/msiejs/msiejs-diagram.png |
| 18:51 | <TabAtkins> | My favorite part is the "Murderer". |
| 18:51 | <nmadzharov> | lol |
| 19:07 | <versatiletech> | HTML5 job in close to Boston,MA? Relocation expenses paid. Very high pay. Opportunity to work on networking web app. PM me if you're interested. |
| 19:23 | <TabAtkins> | Ooh, got a coons patch working! |
| 19:23 | <TabAtkins> | http://www.xanthir.com/etc/scaling-algorithms.html |
| 19:27 | <smaug____> | annevk: seems like http://dev.w3.org/csswg/cssom-view/#dom-document-caretpositionfrompoint mentions still caretRange which is already removed from the interface |
| 19:31 | <annevk> | smaug____, http://lists.w3.org/Archives/Public/www-style/2011Jun/0604.html |
| 19:38 | <smaug____> | ah |
| 20:25 | <dglazkov> | TabAtkins: did I capture this right? http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Rendering_Form_Controls_with_SVG |
| 20:33 | <Hixie> | TabAtkins: you know the css in html is normative, right? :-) |
| 20:36 | <annevk> | dglazkov, looks good to me! |
| 20:37 | <dglazkov> | cool |
| 20:38 | <TabAtkins> | Hixie: If I did, I wouldn't've said the opposite. |
| 20:38 | <smaug____> | XForms extensions supports svg styled form controls :p |
| 20:39 | <othermaciej> | dglazkov: those use cases look much better than the old use cases document |
| 20:39 | <smaug____> | s/extensions/extension/ |
| 20:39 | <othermaciej> | though it is hard to see how the "Desirable Properties" follow from the use cases |
| 20:42 | <othermaciej> | dglazkov: it would be nice if the "Desirable Properties" section said which use case requires which property and why, or better yet, list under each use case what this specific use case implies about desirable properties for a solution |
| 21:34 | <TabAtkins> | Hmm. Is it possible to add a function to Number that operates on the value? |
| 21:34 | <TabAtkins> | Number.prototype.add(that) { return this+that; } doesn't work. |
| 21:35 | <gsnedders> | TabAtkins: this is a Number object in that situation |
| 21:36 | <gsnedders> | TabAtkins: this.valueOf() gives you the Number primitive |
| 21:38 | <TabAtkins> | Hmm, I'm getting a screwy result here that's probably unrelated... |
| 21:44 | <TabAtkins> | Oh jeez, I see what I did wrong. Never mind. |
| 21:45 | <metron> | hi |
| 21:47 | <metron> | Iam still reading webdev books but I can't any discussion about integration concepts of HTML5 standards, where I can find that stuff? thx |
| 21:47 | <metron> | +find |
| 21:47 | <TabAtkins> | What do you mean? |
| 21:48 | <metron> | Tab: information integration from old websites maybe |
| 21:50 | <TabAtkins> | I still don't understand what you mean. Could you rephrase in different words? |
| 21:51 | <annevk> | hmm |
| 21:51 | <annevk> | with Lion my connection is dropped way more often |
| 21:51 | <annevk> | bah |
| 21:51 | <annevk> | IRC connection at least |
| 21:52 | <metron> | Tab: I use to work with html5 but Iam not so experienced with it, still reading books, now friends ask me how those old html4 / xhtml sites will be integrated to the new html5 type of website. |
| 21:54 | <AryehGregor> | metron, you can just add features incrementally. HTML5 features work in HTML4 pages and vice versa. |
| 21:54 | <metron> | Tab: just by doing all changes manually? just renaming elements and stuff like that? |
| 21:54 | <AryehGregor> | It's all totally compatible. |
| 21:54 | <AryehGregor> | Use whatever features are useful to you, you don't have to rewrite your pages if you don't want to. |
| 21:55 | <metron> | Aryeh: ok, hmm |
| 21:55 | <D^mien> | see metron html5 aims to be backwards compatible with existing content |
| 21:56 | <D^mien> | html5 acknoledges previously existing elements even when those elements are no longer in html5 |
| 21:56 | <D^mien> | With HTML5, anything goes. Uppercase, lowercase, quoted, unquoted, self-closing or not; its entirely up to you. |
| 21:57 | <D^mien> | i'm just getting started with it, but so far it sure is a beauty to work with :D |
| 21:58 | <D^mien> | the easisest way to start switching to html5, change doctype to <!DOCTYPE HTML5> |
| 21:58 | <metron> | D^mien: k |
| 21:58 | <D^mien> | :) |
| 21:58 | <D^mien> | A good book that got me started was HTML5 for webdesigners by Jeremy Keith |
| 21:59 | <jamesr> | and find a good validator/linter |
| 22:00 | <metron> | I think I'll use netbeans, it was very useful for me with php5.3 |
| 22:01 | <annevk> | euh D^mien |
| 22:01 | <annevk> | doctype is <!DOCTYPE HTML> |
| 22:01 | <metron> | D^mien: good to know about, thx |
| 22:01 | <annevk> | no 5 |
| 22:01 | <D^mien> | haha ya |
| 22:01 | <D^mien> | duh |
| 22:01 | <D^mien> | sorry |
| 22:01 | <metron> | ^^ |
| 22:01 | <D^mien> | thanks for clearing that up, forgot no5 |
| 22:01 | <D^mien> | lol |
| 22:03 | <annevk> | Is it just me or is Daring Fireball reading like Fox News when it comes to Google? |
| 22:04 | <metron> | D^mien: Maybe I should read that book you suggested |
| 22:11 | <annevk> | shit |
| 22:11 | <annevk> | flamed on G+ |
| 22:11 | <annevk> | never did that on Facebook |
| 22:14 | <AryehGregor> | You can edit your posts, right? |
| 22:16 | <Hixie> | annevk: d'oh! |
| 22:16 | <Hixie> | annevk: url! |
| 22:16 | Hixie | grabs popcorn |
| 22:17 | <dglazkov> | othermaciej: sounds good! |
| 22:22 | <annevk> | not that bad |
| 22:22 | <annevk> | https://plus.google.com/112095156983892490612/posts/EMADdvHSRbH |
| 22:22 | <annevk> | Julian brought his splitting argument up again, I sneered about HTTP going so fast |
| 22:23 | <annevk> | (HTTP is now split into 7-10 drafts or so) |
| 22:23 | <annevk> | (a giant mess if you ask me, I can never find what I'm looking for) |
| 22:23 | <Hixie> | HTTP is a disaster |
| 22:25 | <annevk> | I like how that RDF thread goes on again about how the toolchain will save you |
| 22:26 | <Hixie> | RDF equally a disaster |
| 22:26 | <Hixie> | RDF might even be worse |
| 22:26 | <annevk> | Web developers hardly use tools |
| 22:26 | <annevk> | And pretty much requiring them to use tools will just mean less people develop, which seems bad |
| 22:26 | <Hixie> | what i like about the rdf tool thing is the way the dude was like "write a script? hello no, you'd write sparql instead!" |
| 22:26 | <Hixie> | how is that not a script! |
| 22:27 | <The_8472> | that's because the standards are so bad that you have to implement a whole browser before you can start making tools. |
| 22:27 | <AryehGregor> | Most web authors use tools of some kind, like CMSes. |
| 22:27 | <Hixie> | people totally use tools all the time |
| 22:27 | <The_8472> | it's like your server-side code IDE has to integrate the whole client side too |
| 22:27 | <Hixie> | but you cannot rely on a tool to save a technology that is too complicated to hang-author |
| 22:27 | <Hixie> | hand |
| 22:27 | <zewt> | web developers hardly use tools because largely the tools suck, heh |
| 22:27 | <The_8472> | works with xml |
| 22:28 | <zewt> | been getting better lately but at a snail's pace and still far from a mature environment |
| 22:28 | <The_8472> | nobody touches multi-megabyte XML files by hand |
| 22:28 | <Hixie> | and XML has been a failure on the web :-) |
| 22:28 | <zewt> | you could have stopped at "failure" |
| 22:28 | <The_8472> | but not a failure as technology in general |
| 22:28 | <gsnedders> | RDF is certainly successful, though, even if it's not successful on the public web. |
| 22:28 | <annevk> | zewt, there are perfectly fine XML parsers and yet people seem to do it with regexp every now and then |
| 22:28 | <The_8472> | crazy people |
| 22:28 | <zewt> | annevk: unfortunately, you can't spec away incompetence |
| 22:29 | <annevk> | no |
| 22:29 | <annevk> | you just have to take that into account |
| 22:29 | <The_8472> | you can. but that means your spec has to include fail-fast, fail-hard provisions. which may be good for quality, but usually not for adoption. |
| 22:30 | <Hixie> | no it doesn't |
| 22:30 | <Hixie> | CSS is a great example |
| 22:30 | <Hixie> | it handles typos fine, without hard-failure |
| 22:31 | <Hixie> | only local failure |
| 22:31 | <The_8472> | which leads/has lead to different browser behavior depending on how it dealt with your typo |
| 22:31 | <hober> | I've been trying to get people to call this 'argumentum ad adminiculum' |
| 22:32 | <hober> | because it's a fallacy that comes up over and over and over again |
| 22:32 | <hober> | "it's ok that it's crazy-complex, because people don't author things, tools do" |
| 22:32 | <TabAtkins> | The_8472: CSS's typo recovery is very well-defined. Differing behavior is bugs. |
| 22:32 | <The_8472> | TabAtkins, tell that to those years of browser hacks relying on inconsistent handling. |
| 22:33 | <annevk> | cool, Norm Walsh shows QR codes on printed pages |
| 22:33 | <Hixie> | hober: i usually reply "and who authors the tools?" |
| 22:33 | <hober> | Hixie: exactly. it's turtles all the way down |
| 22:33 | <zewt> | hober: of course, even for formats which are always output by tools (binary formats), you still have people writing tools that do it wrong, heh |
| 22:33 | <annevk> | not sure if QR codes are still cool, but it's definitely better than URLs users have to type over |
| 22:33 | <Hixie> | The_8472: that's the cause of a bad spec, not a necessary feature of error recovery |
| 22:33 | <Dashiva> | QR is totally last year |
| 22:33 | <hober> | annevk: were qr codes ever cool? |
| 22:33 | <TabAtkins> | The_8472: Um, they're still bugs. I don't see what point you're trying to make. |
| 22:33 | <zewt> | (parsing AVIs in the wild? good luck) |
| 22:33 | <hober> | zewt: true, true |
| 22:34 | <zewt> | of course, that was never really a well-specified format to begin with |
| 22:34 | <The_8472> | TabAtkins, the point? that browser hacks wouldn't have existed if browsers were fail-hard and we might have seen actual feature-detecting emerging much earlier. |
| 22:35 | <gsnedders> | The_8472: People would've just done browser hacks based upon other nbugs. |
| 22:35 | <gsnedders> | *bugs |
| 22:35 | <TabAtkins> | Dude, you kidding? Fail-hard CSS would have frozen the technology very early on. Local-fail is a necessary part of how CSS allows new tech. |
| 22:35 | <The_8472> | i think java is a good example for tools alleviating *some* complexity. you can write java without IDEs. but having one to back you up is a huge boon if you have to work with other people's code. it being very computer-friendly (static typing allowing lots of analysis) helps of course |
| 22:36 | <The_8472> | TabAtkins, i'm talking about syntax. not about permitted values. |
| 22:36 | <TabAtkins> | They're one and the same. An unknown property is the same as a syntax error. |
| 22:36 | <The_8472> | permitted values is just a matter of well-defined forwards-compatibility |
| 22:36 | <zewt> | writing java without an IDE is a fast path to migraines |
| 22:37 | <zewt> | (but only because java code tends to be split into 10x as many files as necessary, often in directory structures ten levels deep) |
| 22:37 | <Hixie> | well-defined forwards-compatibility is basically the same as fail-local |
| 22:38 | <Hixie> | you can have well-defined forwards-compatibility in syntax, in values, in semantics, etc |
| 22:38 | <The_8472> | xml has forwards-compatibility with namespaces and yet is fail-hard on its core syntax (preventing tag-soup) |
| 22:38 | <Hixie> | but in each case, it's a matter of handling a current failure in a graceful and predictable but non-fatal way |
| 22:38 | <Hixie> | The_8472: right, and that means it doesn't have well-defined forwards-compatibility for syntax changes |
| 22:39 | <The_8472> | have there been any major syntax changes in html? |
| 22:40 | <gsnedders> | The_8472: Adding more self-closing tags, adding foreign content… IE allowing ` as an attribute quote char, Opera allowing far more whitespace chars in tags. |
| 22:40 | <Hixie> | The_8472: yes |
| 22:40 | <Hixie> | The_8472: e.g. we added inline svg/mathml |
| 22:40 | <The_8472> | see, none of those things are essential features that really improve the language |
| 22:41 | <The_8472> | namespaces could have done that in the case of xml. in fact, they do exactly that |
| 22:41 | <AryehGregor> | Um, really? |
| 22:41 | <AryehGregor> | Never being allowed to add more self-closing tags is a good thing? |
| 22:41 | <The_8472> | yes |
| 22:41 | <AryehGregor> | Well, I'd have to disagree with that. |
| 22:41 | <The_8472> | if by selfclosing you mean things like <p> |
| 22:41 | <Hixie> | The_8472: the point is not that there are syntax changes that people want to add to xml but can't in a backwards-compatible way, the point is that if there were, it wouldn't matter, because it would be impossible to add them |
| 22:41 | <AryehGregor> | I mean things like <source>. |
| 22:42 | <AryehGregor> | Or <img>, for an older example. |
| 22:42 | <AryehGregor> | Where there's no closing tag. |
| 22:42 | <gsnedders> | The_8472: XML 1.0 Fifth Edition is a backwards incompatible change in XML, likewise XML 1.1 |
| 22:43 | <The_8472> | 1.1 -> goes into the header -> is an extension point |
| 22:43 | <Hixie> | not a backwards-compatible one |
| 22:43 | <The_8472> | obviously it would be nuts using a 1.0 parser on 1.1 code. |
| 22:43 | <Hixie> | so much so that 1.1 was basically killed in favour of 1.0 5th ed |
| 22:43 | <Hixie> | not "obviously" at all. |
| 22:43 | <gsnedders> | The_8472: And 5th ed? |
| 22:43 | <Hixie> | people use html4-era parsers on html5-era pages all the time |
| 22:44 | <Hixie> | that's what backwards-compatibility enables |
| 22:45 | <The_8472> | except that svg doesn't work. so it fails in unpredictable ways, depending on how complete the environment is in which you run it |
| 22:46 | <Hixie> | that's because html4 didn't define parsing |
| 22:46 | <Hixie> | when we add new syntax in a future revision, we'll be able to exactly predict the failure modes |
| 22:47 | <The_8472> | the thing is you can't assume anything will work at all. user might have javascript off. or it might be an old parser. or it might not support a random feature. so you have to test with all browser versions |
| 22:47 | <Hixie> | i'm just saying that fail-hard prevents having well-defined forwards-compatibility |
| 22:48 | <Hixie> | i'm not arguing that having well-defined forwards-compatibility makes everything bug-free |
| 22:48 | <Hixie> | or that web development is easy because of having well-defined forwards-compatibility |
| 22:49 | <The_8472> | well, ok. it does make moving forward easier. but it causes quite some headaches too. and imo in some places fail-hard is useful |
| 22:49 | <Hixie> | there are times fail-hard is useful, but they're rare on the web |
| 22:49 | <Hixie> | can't speak about headaches |
| 22:49 | <Hixie> | q.v. the /topic |
| 22:53 | <metron> | Hixie: what you ment with "fail-hard"? |
| 22:53 | <annevk> | almost done with DOM Traversal o_O |
| 22:53 | <Hixie> | metron: handling an error by entirely refusing to process the resource |
| 22:53 | <annevk> | well, except for like introductory text and stuff |
| 22:53 | <Hixie> | metron: JS and XML are examples of fail-hard languages at the syntax level |
| 22:54 | <annevk> | and a few more methods, and getting killed by jgraham for using hard-to-read-algorithms |
| 22:54 | <Hixie> | well here's a shocker |
| 22:54 | <Hixie> | the spec doesn't seem to require that browsers let users follow hyperlinks |
| 22:55 | <Hixie> | or even encourage it |
| 22:55 | <Hixie> | am i missing something i wrote somewhere? |
| 22:55 | <Hixie> | it has text for <area> and <link>... |
| 22:56 | <annevk> | implemented <a> with a table the other day |
| 23:01 | <The_8472> | mhh... replace capital punishment with the task to rewrite the spec to derive everything from tables. |
| 23:02 | <annevk> | it's actually a reference to an old joke; the claim was a table (an ordinary non-computer one) with quotation marks around it was a conforming HTML4 user agent |
| 23:02 | <Hixie> | not just any able, dbaron's desk at harvard ;-) |
| 23:03 | The_8472 | is confused |
| 23:03 | <annevk> | :) |
| 23:05 | <Hixie> | The_8472: HTML4 includes only one testable requirement on browsers |
| 23:05 | <Hixie> | The_8472: which is that <q> elements must be surrounded by quotation marks |
| 23:05 | <Hixie> | The_8472: so an ordinary desk with a pair of quotation marks engraved in it is a compliant HTML4 browser |
| 23:06 | <The_8472> | ah, semantic lawyering. |
| 23:06 | <Hixie> | not just semantic lawyering. it has also made it near impossible to write test suites for html4. |
| 23:06 | <Hixie> | (fixing this is one of the greatest achievments of the new html spec) |
| 23:24 | <dbaron> | Hixie, The_8472, the other testable requirement was that it treat SGML-equivalent streams the same... but doing nothing all the time is treating them the same |
| 23:25 | <Hixie> | ah yes |
| 23:25 | <Hixie> | a requirement which, incidentally, no browser ever implemented |
| 23:37 | <TabAtkins> | Except for dbaron's desk. |
| 23:38 | <dbaron> | not a browser |
| 23:38 | <TabAtkins> | Okay, granted. |
| 23:39 | <Dashiva> | Dunno, did html4 define what a browser is? |
| 23:41 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#traversal |
| 23:41 | <annevk> | still need TreeWalker previousNode/nextNode |
| 23:45 | <metron> | annevk: I thought XLink will do that for us?! |
| 23:46 | <annevk> | if XLink is not out already it is on its way |
| 23:46 | <annevk> | this is some legacy DOM API that ended up in Acid3 but was not really fully defined |
| 23:46 | <annevk> | now it is, presumably with new bugs |
| 23:47 | <Hixie> | hober: (fwiw, i filed a bug on that circle ordering thing. i have the same problem around the same number of circles.) |
| 23:55 | <metron> | annevk: k, so I'll change my mind with XLink |
| 23:56 | <annevk> | metron, rule of thumb: specs where the initial letter is an "X" are not really making it these days |
