| 02:37 | <roc> | in what way? |
| 02:42 | <jamesr> | roc, was that to me? |
| 02:43 | <roc> | yes |
| 02:44 | <jamesr> | it's supposing that microsoft wants to introduce their own shading language. i suspect they simply want to avoid the IPR obligations that requiring glsl would imply |
| 02:44 | <jamesr> | i really doubt they want anything at all |
| 02:46 | <roc> | IIRC the IPR argument was not raised the first time they objected to specifying GLSL |
| 02:46 | <roc> | I could be wrong. |
| 02:47 | <jamesr> | just because they didn't say it doesn't mean they weren't thinking it |
| 02:48 | <roc> | I suppose you could strike "They prefer their own shading language they call IESL.", but that doesn't affect the thrust of the rant, which is that it's absurd to standardize "CSS Shaders" without a standard common shading language |
| 02:48 | <jamesr> | i don't think they even want to standardize css shaders |
| 02:49 | <roc> | if not, they're not saying it for some reason |
| 02:49 | <jamesr> | it doesn't really impact them at all if someone goes off and creates a standard unless it triggers IPR for them |
| 02:50 | <roc> | sure it does, because they'll be expected to support it sooner or later. |
| 02:51 | <roc> | it's kinda hard to avoid the conclusion that they don't like GLSL for the same reason they don't like WebGL. The reason for *that* is a bit more speculative, but maybe not much more :-) |
| 02:52 | <jamesr> | it doesn't really matter if they object on IPR grounds, which they definitely do |
| 02:52 | <jamesr> | so making further conspiracy theories just seems like a waste of time |
| 02:54 | <othermaciej> | Microsoft seems to be asking for GLSL to be a MAY-level rather than SHOULD-level requirement |
| 02:54 | <othermaciej> | at least in that original email |
| 02:55 | <othermaciej> | I think anything less than a MUST does not trigger w3c IPR commitments |
| 03:14 | <othermaciej> | hmm, Sylvain seems to think SHOULD and RECOMMENDED mean different things in RFC2119 language |
| 03:18 | <othermaciej> | but I guess it does not matter since both appear to trigger the patent policy - optional features are covered as long as they are normative |
| 03:19 | <othermaciej> | however, the patent policy excludes "technology developed elsewhere and merely incorporated by reference in the body of the Recommendation" |
| 03:19 | <roc> | I would have expected GLSL to be excluded by that |
| 03:20 | <othermaciej> | so I think the IPR claim is doubtful |
| 03:21 | <othermaciej> | it is hard to assess the non-IPR objections, the thread has a poor signal-to-noise ratio |
| 03:21 | <jamesr> | yeah the thread is crap |
| 03:21 | <jamesr> | othermaciej, do you think he's not assessing it in terms of IPR and he's wrong, or that's not his concern? |
| 03:21 | <jamesr> | sorry too many negatives. do you think his assessment of the RFC2119 triggers is wrong, or that's not what he is bothered by? |
| 03:22 | <othermaciej> | his claims about IPR are: |
| 03:22 | <othermaciej> | (1) RECOMMENDED is an RFC2119 keyword that "is not just an optional should" |
| 03:22 | <othermaciej> | (2) therefore the W3C patent policy likely applies to IPR on GLSL |
| 03:23 | <othermaciej> | these statements are false or misleading for the following reasons: |
| 03:23 | <othermaciej> | (A) RECOMMENDED and SHOULD are synonyms in RFC2119, so they have no difference in normative effect (I am puzzled how he could miss this while quoting the RFC_ |
| 03:24 | <othermaciej> | (B) The W3C patent policy covers optional features so long as they are normatively specified, so the fact that recommended is in fact optional does not matter |
| 03:25 | <othermaciej> | C) however the w3c patent policy excludes technologies developed elsewhere and incorporated by reference, so it likely would not apply to GLSL in any case |
| 03:25 | <crocket> | What do I use instead of <frame> with HTML5 web pages? |
| 03:25 | <crocket> | <frame> is obsolete. |
| 03:25 | <jamesr> | <iframe> typically |
| 03:26 | <othermaciej> | that depends on what you are trying to do |
| 03:26 | <othermaciej> | if you want an independently browsable area that really needs to hold separate pages, <iframe> |
| 03:26 | <crocket> | hmm.... |
| 03:26 | <othermaciej> | if you just want your page to have separate areas that scroll independently, CSS overflow: scroll |
| 03:26 | <crocket> | I know what <iframe> is. |
| 03:27 | <othermaciej> | (that is, make it all one page and use overflow: scroll on the scroll containers) |
| 03:27 | <crocket> | othermaciej, Can you show me an example of how CSS overflow property works? |
| 03:27 | <othermaciej> | crocket: not offhand but if you google or bing it I am sure you will find some good tutorials |
| 03:28 | <crocket> | othermaciej, ok |
| 03:28 | <crocket> | kennyluck_, Who killed you? |
| 03:33 | <jamesr> | othermaciej, is that something you can ask the w3c people to convince the microsoft lawyers of? your logic sounds reasonable, but IANAL and if they don't feel comfy here they are quite capable of blocking this for a long time |
| 03:33 | <jamesr> | i doubt replying on that thread could do much good, especially at this point |
| 03:34 | <othermaciej> | I am hesitant to wade into the topic since it is a flame-splosion right now |
| 06:18 | <MikeSmith> | oh cool an interface index |
| 06:20 | <MikeSmith> | non-element interfaces |
| 06:20 | <MikeSmith> | http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html#all-interfaces |
| 06:44 | <MikeSmith> | http://lists.webkit.org/pipermail/webkit-dev/2012-August/022049.html is interesting |
| 06:44 | <MikeSmith> | Apple going all out on CSS Regions it seems |
| 07:59 | <odinho> | Aiai, I think I think pipermail should always force linebreaks if there is none. Always have to monkeypatch it in Dragonfly to be able to read pipermail archives :P |
| 08:01 | Philip` | just does ctrl+F11 (fit to width) in Opera |
| 08:04 | <odinho> | Philip`: That should teach me to learn all of my browsers hidden features. :S Thanks! :D That's a super cool feature. |
| 08:07 | deane | is disappointed that opera has discontinued it's irc chat feature. |
| 08:13 | <jgraham> | Bug annotations now have titles |
| 08:40 | <Ms2ger> | jgraham++ |
| 08:51 | <zcorpan> | nice! |
| 08:52 | <zcorpan> | Hixie: it's a bit annoying that the bug links move when you hover. can the section link be moved to the bottom of the box, or so? |
| 09:01 | <jgraham> | Argh, there was a WHATWG email and a gecko bug and maybe a spec bug about the interaction between loading and session history, and now I can't find any of them |
| 09:03 | <zcorpan> | Hixie: http://whatwg.org/specs/ doesn't list these specs: http://www.w3.org/community/whatwg/ |
| 09:11 | <zcorpan> | Hixie: http://wiki.whatwg.org/wiki/Test_cases might be better if we point people to http://www.w3.org/html/wg/wiki/Testing |
| 09:14 | <zcorpan> | Hixie: "and in five to ten years you'll finally be able to do it!" - it doesn't necessarily have to take 5+ years |
| 09:15 | <jgraham> | zcorpan: You could just edit some of these pages you know :) |
| 11:11 | <sedovsek> | Just read this tweet: |
| 11:11 | <sedovsek> | https://twitter.com/w3c/status/238652019089485824 |
| 11:11 | <sedovsek> | Twitter, Inc. (@TwitterEng) joined W3C http://dlvr.it/22l89w |
| 11:12 | <sedovsek> | Are there any Twitter employees that already contribute to W3C? |
| 11:12 | <kennyluck> | Not I know of. |
| 11:12 | <sedovsek> | If so, on which standards/drafts? |
| 11:12 | <kennyluck> | Tracking related stuff maybe? |
| 11:13 | <sedovsek> | I don't know, but I'm very curious. |
| 11:14 | <sedovsek> | Perhaps @TabAtkins has more insights? |
| 11:15 | <kennyluck> | sedovsek, if you know their corporate email domain, you can do a search here: http://www.w3.org/Search/Mail/Public/search?keywords= |
| 11:15 | <sedovsek> | Thanks. |
| 11:46 | <carli2> | hi |
| 11:46 | <carli2> | I tried to ask a question in #html, but that was forbidden |
| 11:47 | <carli2> | does this channel has to do with that? |
| 11:47 | <jgraham> | Have to do with HTML? |
| 11:47 | <carli2> | I wanted to ask if/how I can load a static JSON document into a html page |
| 11:47 | <jgraham> | Yes; this is mostly people involved with in the development of specs around the web platform |
| 11:48 | <carli2> | ah |
| 11:49 | <jgraham> | carli2: If you are generating the while thing server-side you can probably do <script type="text/json">/*json data*/</script> |
| 11:49 | <jgraham> | If you want to pull in an enternal file, use XHR |
| 11:50 | <carli2> | jgraham: but how can I access the JSON object then? the script is executed in the global scope |
| 11:51 | <jgraham> | carli2: You can read the content of the script element and use JSON.parse |
| 11:51 | <jgraham> | Or whatever the method is called |
| 11:51 | <carli2> | ah |
| 11:58 | <carli2> | jgraham: I cannot read the content from the <script> element |
| 11:59 | <jgraham> | Internal or external script? |
| 11:59 | <sedovsek> | There's also a #html5 chann, which might be slightly more appropriate. |
| 12:00 | <jgraham> | An internal script should be readable with .textContent |
| 12:00 | <sedovsek> | an* |
| 12:00 | <carli2> | jgraham: should work for both, SO and non-SO |
| 12:00 | <jgraham> | Oh, well if you are trying to read data cross-origin things are harder |
| 12:00 | <jgraham> | Then you probably want to use CORS + XHR |
| 15:14 | <jgraham> | So, is there an event I can get in the top level browsing context when I navigate the joint session history of a browsing context with nested browsing contexts in such a way that it is one of the child browsing contexts that chnages its document |
| 15:14 | <jgraham> | ? |
| 15:15 | <jgraham> | i.e. I have a parent document A with an iframe in itially containing B. I navigate the iframe to C and then do history.go(-1) |
| 15:15 | <jgraham> | I want an event that will fire when I am back at B in the iframe |
| 15:37 | <Hixie> | jgraham: i got method not allowed? |
| 15:42 | <jgraham> | Hixie: I forgot to restart the server. Try again? |
| 15:48 | <Hixie> | jgraham: awesome |
| 15:48 | <Hixie> | ok i put it at the bottom of file-bug.cgi |
| 15:48 | <Hixie> | hopefully it doesn't break anything :-) |
| 15:48 | <Hixie> | this is awesome stuff |
| 15:48 | <Hixie> | really glad we did this |
| 15:48 | <jgraham> | Me too :) |
| 15:49 | <Hixie> | i also like my new styling for the boxes :-) |
| 15:50 | <jgraham> | Indeed, but see zcorpan's comment; having the bug link move on hover is annoying |
| 15:50 | <Hixie> | moved it already |
| 15:50 | <jgraham> | Oh, I didn't reload |
| 15:50 | <jgraham> | It takes a while ;) |
| 15:51 | <Hixie> | ok, afk for a bit |
| 15:56 | <jgraham> | Hixie: New style is much better, thanks |
| 16:52 | <TabAtkins> | All right, time to lose a few hours of productivity and get this new workstation set up. |
| 17:36 | <dglazkov> | good morning, Whatwg! |
| 17:36 | <dglazkov> | TabAtkins: vroom, vroom |
| 19:10 | <Hixie> | is there anywhere i can make a note of some tests that should be added to the html test suite? |
| 19:10 | <Hixie> | (i want to note that we need to test that legacycaller isn't supported for all interfaces that have a getter) |
| 19:13 | <Ms2ger> | Hixie, you can file a bug in the HTMLWG/testsuite product |
| 19:13 | <Ms2ger> | I might even see it there |
| 19:13 | <Hixie> | ah, cool, that's for actual bugs, not just infrastructure? |
| 19:13 | <Ms2ger> | Yep |
| 19:15 | <Hixie> | cool |
| 19:15 | <Hixie> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=18681 |
| 19:15 | <Hixie> | that clear enough? |
| 19:15 | <Ms2ger> | Clear enough for me |
| 19:15 | <Hixie> | oooooh, would it help if i added something to the live dom viewer that automatically filed a bug in that component with the current contents? |
| 19:16 | <Ms2ger> | Hmm, would be nice |
| 19:16 | <Ms2ger> | Now all we need is a script to automatically translate it to an automated test :) |
| 19:22 | <Hixie> | Ms2ger: default assignee, or should i assign to someone in particular? |
| 19:22 | <Ms2ger> | Default is fine |
| 19:23 | <Hixie> | anyone i should put in default cc? |
| 19:26 | <Ms2ger> | Feel free to put me, but I don't think it's going to make me do anything sooner :) |
| 19:26 | <Hixie> | entirely up to you |
| 19:27 | <Ms2ger> | Don't, then, I get heaps of bugmail already :) |
| 19:27 | <Hixie> | i'd put myself in to monitor for abuse, but i send all w3c bugmail to trash :-) |
| 19:30 | <jamesr> | s/bugmail // |
| 19:31 | <Hixie> | i still monitor public-html in case anyone raises a bug i have to fix |
| 19:31 | <Hixie> | hasn't happened in recent years, but we never know... |
| 19:57 | <TabAtkins_> | Yesssssss. Now to banish my old self. |
| 20:07 | <rubys> | hixie: re: "hober: is there any documentation anywhere that tracks which revisions the w3c spec has adopted and which it hasn't? " |
| 20:07 | <rubys> | this is a small part of that (which bugs are still open that have clones): |
| 20:07 | <rubys> | http://intertwingly.net/tmp/clones.html |
| 20:08 | <rubys> | if I can build reports that are helpful, let me know |
| 20:52 | <hober> | Hixie: you can follow along at https://github.com/w3c/html/commits/master/ |
| 20:53 | <hober> | (with regard to which revisions from the whatwg spec have been applied to the w3c spec) |
| 21:22 | <Hixie> | hober: that tells me which have been applied, but not which have not :-) |
| 21:24 | <hober> | true |
| 21:27 | <GPHemsley> | Hixie: Any idea why the JSURL development stalled? |
| 21:27 | <Hixie> | what is JSURL? |
| 21:27 | <GPHemsley> | The JavaScript URL standard |
| 21:31 | <GPHemsley> | (mentioned in the recent r7265) |
| 21:33 | <Hixie> | oh the javascript: spec? |
| 21:33 | <Hixie> | no iea |
| 21:33 | <Hixie> | idea |