| 00:31 | <zewt> | bikeshedding contest: a word for "parameters" that isn't a plural (and is preferably less verbose than "configuration") |
| 00:32 | <zewt> | (bugs me that webgl says "has *context creation parameters*"; defined abstractions like that are usually singular, which seems more concrete) |
| 00:33 | <zewt> | "setup" doesn't really sound right |
| 00:35 | <tantek> | zewt, argv :P |
| 00:54 | <zewt> | wow. someone trying to use "doesn't spec java bindings" as an argument? that's a pretty big alarm bell that someone's reaching for arguments. heh |
| 01:18 | <Hixie> | heycam|away: re http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0192.html : |
| 01:18 | <Hixie> | heycam|away: addHitRegion() only makes sense in an immediate-mode bitmap world, you don't need it or anything like it in the retained-mode svg vector world |
| 01:19 | <Hixie> | heycam|away: as far as matrix objects go i'm happy to use whatever |
| 01:19 | <Hixie> | heycam|away: (i used SVGMatrix because that's what mozilla people suggested) |
| 06:06 | <smaug____> | rafaelw_: ping |
| 06:06 | <smaug____> | (probably a bit late for you ) |
| 06:09 | <zcorpan> | margins won't collapse at the top or bottom of seamless iframes |
| 06:10 | <zcorpan> | but maybe that's not a problem |
| 06:11 | <smaug____> | (all the special casing for seamless feels horrible, but I don't complain, yet :) ) |
| 06:12 | <smaug____> | aklein: ping |
| 06:12 | <zcorpan> | i agree with display:block default style (since inline gives the annoying line height spacing thing everyone hates) and margin:0 |
| 06:17 | <hsivonen> | MikeSmith: I suppose org.whattf.syntax.Driver could be extended with full validator functionality. Now it's jus a minimal Jing harness |
| 06:19 | <smaug____> | does DOM4 say anything about garbage collection or similar? |
| 06:20 | smaug____ | can't find anything |
| 06:26 | <zcorpan> | smaug____: what do you expect it to say? |
| 06:30 | <zcorpan> | i wonder who to cc from webkit and microsoft about changes to shared workers |
| 06:33 | <smaug____> | zcorpan: it should say something about ownership of MutationObserver |
| 06:33 | <smaug____> | I filed a bug |
| 06:49 | <zcorpan> | hmm. <annotation-xml> complicates innerHTML if we want to support foreign content with innerHTML |
| 06:49 | <zcorpan> | well, you need to check an attribute on the context element |
| 06:49 | <zcorpan> | i guess that's simple enough |
| 06:51 | <zcorpan> | also, the escape foreign lands thing doesn't make much sense in the fragment case, but i don't know what to do about that |
| 06:51 | <smaug____> | innerHTML reminds me... hsivonen, how hard would it support innerHTML in svg elements? |
| 06:52 | <zcorpan> | at least it needs to have a check not to pop the root element in the fragment case |
| 06:52 | <zcorpan> | smaug____: that's what i'm investigating :-) |
| 06:52 | <smaug____> | hsivonen: I mean in gecko |
| 06:52 | <zcorpan> | oh |
| 06:52 | <smaug____> | ah, there can be some spec issues too :) |
| 06:52 | <zcorpan> | well the spec is totally broken for innerHTML on non-html elements currently |
| 06:53 | <zcorpan> | the insertion mode is "in body" |
| 06:53 | <zcorpan> | so you get HTML elements |
| 06:54 | <zcorpan> | but the fix is more complicated than just changing the insertion mode to foreign content... |
| 06:54 | <zcorpan> | see https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 |
| 06:58 | <hsivonen> | smaug____: not at all hard |
| 06:58 | <hsivonen> | smaug____: the code is pretty much there. we're just annoying by putting the IDL on HTML elements instead of all elements |
| 06:59 | <hsivonen> | IIRC, I've fixed the parser code ahead of spec |
| 06:59 | hsivonen | checks |
| 07:03 | <zcorpan> | hsivonen: what changes are needed to make innerHTML do the right thing on svg and mathml elements, including elements that are MathML text integration points and HTML integration points? |
| 07:03 | <hsivonen> | smaug____: oops. there seems to be a bug in the case where the namespace is not HTML but the local name matches "script", "plaintext", "xmp", "textarea", "title", "style", et. |
| 07:05 | <hsivonen> | zcorpan: "reset the insertion mode" needs to be able to handle non-HTML at the start of the algorithm... |
| 07:06 | <zcorpan> | hsivonen: right, but i think more changes are needed |
| 07:06 | <zcorpan> | hsivonen: consider setting innerHTML to "<b>x" |
| 07:06 | <zcorpan> | hsivonen: that will pop the root element per spec |
| 07:06 | <zcorpan> | oops |
| 07:07 | <hsivonen> | zcorpan: looking at this stuff more carefully, it might be that the code I have here is very buggy... |
| 07:07 | <hsivonen> | anyway, it shouldn't be too hard |
| 07:08 | <hsivonen> | we should definitely add innerHTML for SVG and MathML elements |
| 07:11 | <zcorpan> | commented on the bug |
| 07:11 | <zcorpan> | i agree we should |
| 07:12 | <zcorpan> | i started to write down proposed spec changes, but then i stopped when it came to <annotation-xml>, <annotation-xml encoding=text/html>, <mglyph>, etc |
| 07:12 | <zcorpan> | because i wasn't confident that i'd get it right |
| 07:18 | <Ms2ger> | MikeSmith, ping? |
| 07:21 | <annevk> | better get ourselves some Java bindings! |
| 07:27 | <annevk> | <input type=range> is called a Range Element by Microsoft |
| 07:27 | <annevk> | that's so confusing |
| 07:29 | <Ms2ger> | Well, we have Java bindings |
| 07:29 | <zcorpan> | http://www.amazon.com/Range-Kleen-Replacement-Plug-Element/dp/B000FNJ5RG%3FSubscriptionId%3DAKIAILSHYYTFIVPWUY6Q%26tag%3Dduckduckgo-z-20%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3DB000FNJ5RG |
| 08:04 | <annevk> | Ms2ger: I know, not sure whether to reply or not |
| 08:36 | <annevk> | smaug____: so it's very easy to spec takeRecords() as return copy of X and then empty X |
| 08:36 | <smaug____> | yup |
| 08:37 | <annevk> | smaug____: the alternative is something like remove all Y from X and then return Y in the same order but that does not account for the empty list |
| 08:37 | <annevk> | are you happy if the spec just says copy? |
| 08:37 | <annevk> | you can implement whatever of course |
| 08:37 | <smaug____> | yeah |
| 08:37 | <annevk> | k |
| 08:38 | <smaug____> | just make it clear that if there are no records, empty array is returned |
| 08:44 | <annevk> | I'll make it clear record queue is always a list, sure |
| 08:47 | <annevk> | slow dvcs.w3.org is slow |
| 08:47 | <annevk> | Ms2ger: not sure making the redirect of mozilla.org to en-US permanent in the draft was sensible btw |
| 08:49 | <annevk> | specced |
| 08:50 | <charlvn> | have any of you guys/girls tried out jsoup? it's a bit hacky but it's a powerful library |
| 08:52 | <smaug____> | w3.org is slow... |
| 08:53 | <RobbertAtWork> | smaug____: w3 is slow, yes |
| 08:53 | <RobbertAtWork> | smaug____: w3.org loads snappy for me though |
| 08:54 | <MikeSmith> | Ms2ger: here now |
| 08:54 | <charlvn> | time curl www.w3.org gives me 0m0.543s |
| 08:54 | Ms2ger | tries to remember |
| 08:55 | <smaug____> | I'm trying to load DOM4, so it is dvcs.w3.org |
| 08:55 | <Ms2ger> | annevk, it's a 301, apparently |
| 08:55 | <annevk> | Ms2ger: seems that even Mozilla makes mistakes |
| 08:55 | <Ms2ger> | annevk, :) |
| 08:55 | <Ms2ger> | MikeSmith, it would be nice if http://dev.w3.org/html5/tests/ had a pointer to the hg repo |
| 08:56 | <MikeSmith> | Ms2ger: you mean an index page? |
| 08:56 | <Ms2ger> | Or in the readme file, at least |
| 08:57 | <MikeSmith> | or maybe I should just have it redirect? |
| 08:57 | <Ms2ger> | wfm |
| 08:58 | <MikeSmith> | OK |
| 08:58 | <smaug____> | no, I can't get dvcs.w3.org to load |
| 08:58 | <MikeSmith> | oh |
| 08:58 | <MikeSmith> | that's a different problem |
| 08:58 | <Ms2ger> | smaug____, clone https://bitbucket.org/ms2ger/dom-core :) |
| 08:58 | <MikeSmith> | wow |
| 08:59 | <MikeSmith> | I can't get it load either |
| 08:59 | <Ms2ger> | 'How do you scare off a flock of web developers? �Java! Java!�' |
| 08:59 | <niloy> | lolz |
| 09:00 | <annevk> | smaug____: updated http://dom.spec.whatwg.org/ for the occasion |
| 09:00 | <smaug____> | thanks |
| 09:01 | <Ms2ger> | annevk, hmm, when did I get a Mozilla link? |
| 09:01 | <MikeSmith> | smaug____: please try now |
| 09:01 | <annevk> | Ms2ger: also, you only updated one mozilla.org link, the one from Aryeh |
| 09:01 | <Ms2ger> | Yeah |
| 09:02 | <MikeSmith> | still responding slowly |
| 09:02 | <Ms2ger> | I didn't think I had one |
| 09:02 | <smaug____> | MikeSmith: works now |
| 09:02 | <MikeSmith> | I just restarted the web server |
| 09:02 | <Ms2ger> | annevk, want to revert me? :) |
| 09:03 | <MikeSmith> | load on that machine is still pretty high |
| 09:03 | <annevk> | Ms2ger: I'll just fix it instead and it'll go with the next commit |
| 09:03 | <annevk> | whenever that is |
| 09:03 | <Ms2ger> | Alright |
| 09:04 | <MikeSmith> | Mem: 524504k total, 518140k used, 6364k free, 1548k buffers |
| 09:04 | <MikeSmith> | Swap: 524280k total, 275388k used, 248892k free, 10408k cached |
| 09:04 | <Ms2ger> | Ddos? |
| 09:04 | <MikeSmith> | using a lot of swap space |
| 09:05 | <smaug____> | that is not much memory |
| 09:05 | <MikeSmith> | Ms2ger: some spider probably yeah |
| 09:05 | <smaug____> | total |
| 09:05 | <annevk> | is someone making sure the CSS specs that define OM stuff are doing the right thing? |
| 09:05 | <MikeSmith> | smaug____: yeah, it's not a big machine |
| 09:05 | <Ms2ger> | Nah |
| 09:05 | <MikeSmith> | annevk: heh |
| 09:05 | <annevk> | because as much as the CSS WG likes to bitch at other groups for not informing them, they're certainly not informing us |
| 09:06 | <MikeSmith> | annevk: I think asking "is someone making sure the CSS specs do ..." with respect to each other, you get the same answer |
| 09:06 | <annevk> | sort of curious with respect to events and such |
| 09:06 | <annevk> | MikeSmith: mwaha |
| 09:07 | <annevk> | anyone know what's been happening with WebVTT? |
| 09:07 | <annevk> | I haven't had any requests with respect to my validator |
| 09:08 | <MikeSmith> | now dvcs.w3.org is unresponsive again |
| 09:09 | <MikeSmith> | tailing the apache access.log I don't see any problems |
| 09:09 | <MikeSmith> | hmm |
| 09:10 | <MikeSmith> | I do see a lot of this in the error logs: |
| 09:10 | <MikeSmith> | [Thu Apr 05 09:10:44 2012] [error] [client 49.128.35.6] Script timed out before returning headers: hgweb.wsgi, referer: http://dvcs.w3.org/hg/csswg/log/tip/css3-animations/Overview.src.html |
| 09:11 | <MikeSmith> | every 2 seconds |
| 09:13 | <Ms2ger> | Same IP? |
| 09:15 | <MikeSmith> | hmm |
| 09:15 | <MikeSmith> | [Thu Apr 05 09:08:31 2012] [error] server is within MinSpareThreads of MaxClients, consider raising the MaxClients setting |
| 09:15 | <MikeSmith> | [Thu Apr 05 09:09:28 2012] [error] server reached MaxClients setting, consider raising the MaxClients setting |
| 09:15 | <MikeSmith> | Ms2ger: no, different clients |
| 09:16 | <MikeSmith> | I think the above was the problem |
| 09:16 | <MikeSmith> | it seems to have re-stabiized |
| 09:16 | <MikeSmith> | stabilized now |
| 09:17 | <MikeSmith> | if we keep having problems I guess I can try raising the maxclients value |
| 09:20 | <MikeSmith> | load is back down to normal now |
| 09:21 | <MikeSmith> | ok, next time if anybody has problems with dvcs.w3.org please ping me so I can get on there and look |
| 09:23 | <zcorpan> | hsivonen: your input for https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 would be appreciated, when you have time :-) |
| 09:24 | <MikeSmith> | Ms2ger: I redirected to http://w3c-test.org/html/tests/ instead |
| 09:24 | <MikeSmith> | if you think we should redirect it to dvcs.w3.org, I will change it to that |
| 09:25 | <Ms2ger> | Fine with me |
| 09:25 | <MikeSmith> | OK |
| 09:26 | <zcorpan> | TabAtkins: http://www.w3.org/TR/css3-hyperlinks/ is a spec that should get the "don't look at this" treatment, right? |
| 09:27 | <Ms2ger> | Wow, http://dev.w3.org/csswg/css3-cascade/ has got a nice header |
| 09:28 | <Ms2ger> | zcorpan, that treatment still hasn't made it to TR/... |
| 09:29 | <Ms2ger> | Also, I didn't want to see http://www.youtube.com/watch?v=qmJKhois7E8 |
| 09:32 | <MikeSmith> | Ms2ger: then you probably wouldn't like the alternate one where he's naked |
| 09:32 | <Ms2ger> | No. I would not. |
| 09:37 | <annevk> | http://www.nature.com/press_releases/linkeddata.html as long as they're not releasing the articles, I'm kind of missing why this is a big deal |
| 09:39 | <jgraham> | I guess citation data can be mildly interesting. But yeah, not too big a deal. Unless you are an RDF-head I guess in which case ever time someone publishes a triple it's a big deal |
| 09:45 | <annevk> | hmm |
| 09:45 | <annevk> | http://www.w3.org/TR/CSS21/zindex.html contradicts other parts of CSS 2.1 |
| 09:45 | <annevk> | where it is said that the root element and body element set the background of the canvas |
| 09:45 | <zcorpan> | hey it's almost a decade ago first version of xhtml2 was published |
| 09:46 | <MikeSmith> | " The platform uses standard vocabularies such as Dublin Core, FOAF, PRISM, BIBO and OWL" .. OWL is a vocabulary? |
| 09:46 | <zcorpan> | http://www.w3.org/TR/2002/WD-xhtml2-20020805/ |
| 09:46 | MikeSmith | goes to read OWL spec for first time |
| 09:46 | <MikeSmith> | zcorpan: party time |
| 09:46 | <annevk> | champagne! |
| 09:47 | <annevk> | omg that text is terrible |
| 09:47 | <annevk> | talks about elements, forgets about pseudo-elements |
| 09:47 | <annevk> | oh no |
| 09:47 | <MikeSmith> | one thing is, I looked back at mail archives and such, and it seems like the XHTML WG really stopped working on XHTML2 in 2006 or so |
| 09:47 | <annevk> | that's scoped by some box at the top |
| 09:48 | <annevk> | so it's just a confusing mix of terminology, but I guess that makes sense given the patchwork that CSS 2.1 is |
| 09:48 | <MikeSmith> | I think instead they were pretty much just working on RDFa, along with the whole XHTML 1 modularization thing |
| 09:48 | <MikeSmith> | annevk: I wonder who actually wrote that |
| 09:49 | <annevk> | Appendix E is pretty much Hixie I think |
| 09:49 | <MikeSmith> | oh |
| 09:50 | <annevk> | it has a list, for starters, and in general defines things more clearly than most of CSS |
| 09:50 | <MikeSmith> | "Elaborate description of Stacking Contexts" sounds like a heading that Hixie would mint |
| 09:50 | <annevk> | I think that is mostly because it has to start with an E |
| 09:51 | <MikeSmith> | ah |
| 09:51 | <MikeSmith> | yeah |
| 09:51 | <MikeSmith> | I seem to remember this now |
| 09:51 | <annevk> | CSS 2.1 has a nice joke with the appendices |
| 09:51 | <MikeSmith> | or maybe another case |
| 09:51 | <MikeSmith> | yeah |
| 09:51 | <jgraham> | "Extended" would have been more utilitarian |
| 09:52 | <MikeSmith> | Evil |
| 09:54 | <annevk> | well CSS 2.1 is cute, but if we're talking about how it should be done better than it should probably not look like this at all |
| 09:54 | <annevk> | defining a core piece of layout in an appendix is insane |
| 09:54 | <MikeSmith> | hey guys I got instagram on my Android handset so feel free to unfollow my twitter now |
| 09:55 | <MikeSmith> | https://twitter.com/#!/sideshowbarker/status/187419744058613760 |
| 09:56 | <annevk> | oh yes, burgers without buns |
| 09:56 | <annevk> | I remember that place |
| 09:56 | <MikeSmith> | annevk: about CSS 2.1, it's like Star Trek original vs Star Trek the Next Generation |
| 09:56 | <MikeSmith> | you have to love both for what they are |
| 09:57 | <annevk> | yeah, that's prolly why some people secretly (and not so secretly) think HTML4 is better than HTML |
| 09:57 | <MikeSmith> | yeah |
| 09:58 | <MikeSmith> | and some people shop at Walmart |
| 10:02 | <hsivonen> | hmm. is it expected that the Windows installer of LibreOffice is unsigned? |
| 10:03 | MikeSmith | wonders why hsivonen is installing anything on Windows |
| 10:04 | <zcorpan> | hsivonen: the normal procedure on windows is to click through any security warnings |
| 10:10 | <hsivonen> | awesome. they sign using GPG but don't use the kind of signing Windows can verify |
| 10:27 | <MikeSmith> | it will be really interesting to see how the Encrypted Media Extensions work for WebKit progresses |
| 10:27 | <MikeSmith> | re https://lists.webkit.org/pipermail/webkit-dev/2012-April/020182.html |
| 10:33 | <Tuju> | hi, is there an irc channel for xml-related discussion? |
| 10:34 | <zcorpan> | Hixie: http://www.whatwg.org/specs/web-apps/current-work/multipage/images/parsing-model-overview.svg should have fill="none" instead of fill="transparent" (transparent is invalid svg, apparently) |
| 10:34 | <annevk> | Tuju: dunno, but you can try here |
| 10:34 | <annevk> | Tuju: as far as browsers and XML go, this channel knows a fair bit |
| 10:35 | <Tuju> | annevk: ack. I'm wonder how i could do enumeration with xml-schema, so that instead of enumerating string choices, i would enumerate tag choices. |
| 10:36 | <annevk> | RobbertAtWork: ^^ |
| 10:36 | <Tuju> | annevk: http://modweb.org/apache.scd see the customLog entry. |
| 10:36 | <MikeSmith> | Tuju: Ankh on #w3c might have a clue |
| 10:36 | <MikeSmith> | or he should at least |
| 10:36 | <MikeSmith> | since he's responsible for all the XML work at W3C |
| 10:37 | <Tuju> | MikeSmith: ack, sounds good. :) |
| 10:37 | <MikeSmith> | he's asleep now though |
| 10:37 | <MikeSmith> | or should be |
| 10:37 | <MikeSmith> | he lives in Toronto |
| 10:37 | <Tuju> | irc should run over xml and include localization metainfo.... |
| 10:37 | <RobbertAtWork> | Tuju: Do you mean <xs:choice>? http://www.w3.org/TR/xmlschema11-1/#element-choice |
| 10:37 | <Ms2ger> | zcorpan, looks like that's my fault :) |
| 10:38 | <Tuju> | RobbertAtWork: hmm..... |
| 10:39 | <RobbertAtWork> | Tuju: Like this: <xs:choice><xs:element ref="p"/><xs:element ref="table"/><xs:element ref="ol"/></xs:choice> |
| 10:40 | <zcorpan> | Ms2ger: (╯°□°)╯︵ ┻━┻ |
| 10:41 | <Tuju> | RobbertAtWork: http://www.w3schools.com/Schema/el_choice.asp actually that looks very good. |
| 10:42 | <annevk> | Tuju: http://w3fools.com/ |
| 10:42 | <RobbertAtWork> | annevk: come on, have you ever tried reading the XSD spec? it's… it's… special. |
| 10:43 | <Tuju> | RobbertAtWork: i agree. it should have more examples to illustrate the very condensated content. just like xhtml and html specs have. |
| 10:44 | <annevk> | RobbertAtWork: everyone sane knows XSD is best avoided :) |
| 10:45 | <Tuju> | annevk: anyway, funny site name and i guess they've a point in that statement. |
| 10:45 | <Tuju> | thou best way to fight against it would be by providing better content that would push that schools.com domain out of search engine results. |
| 10:46 | <annevk> | yeah |
| 10:47 | <Tuju> | and i don't mind if they're wrong in something, eventually xmllint will complain anyway. |
| 10:54 | <Ms2ger> | zcorpan, hmm? |
| 10:55 | <zcorpan> | Ms2ger: "Y U RITE INVALID SVG" |
| 10:55 | <Ms2ger> | "It works" |
| 10:56 | <Ms2ger> | What did you expect me to do, read the SVG spec? |
| 10:56 | <zcorpan> | no, test in opera :-) |
| 10:56 | <zcorpan> | anyway, i guess the svg spec will be fixed to support transparent eventually |
| 10:59 | <Tuju> | RobbertAtWork: it works and even scarier thing is that i changed it quite a bit and got syntax correct without typos and everything at first try. |
| 10:59 | <annevk> | I disagree with it being invalid SVG btw |
| 10:59 | <annevk> | SVG says it takes a CSS color, CSS colors evolved since CSS 2.0, deal with it |
| 10:59 | <Tuju> | RobbertAtWork: thanks, you saved my morning. |
| 10:59 | <Ms2ger> | zcorpan, heh, I guess I indeed didn't test in Opera |
| 11:01 | <foolip> | annevk, about http://lists.w3.org/Archives/Public/www-archive/2012Apr/0020.html |
| 11:01 | <foolip> | do you have a table of both alternatives in their original context? |
| 11:02 | <shepazu> | I think I agree with annevk… SVG1.1 didn't know about "transparent", but I don't see why a browser that knows SVG and CSS colors shouldn't allow it (in fact, it probably should allow it) |
| 11:02 | <annevk> | big5.json has about 7 different ways to decode the byte sequences foolip |
| 11:03 | <annevk> | foolip: or has 7 mapping tables, anyway |
| 11:03 | <zcorpan> | annevk: ah, then we should just fix opera |
| 11:04 | <foolip> | annevk, oh, that many |
| 11:04 | <annevk> | foolip: the interesting ones are "firefox", "internetexplorer" and one that ends in "-hk" I think |
| 11:05 | <annevk> | foolip: the rest is more or less the same |
| 11:08 | <zcorpan> | make an html page with a table with iframes with the first column being decoded as big5-firefox and encoded to utf-8, etc, and maybe with <mark>s around the interesting words, for easy comparison :-) |
| 11:11 | <foolip> | annevk, I'm looking at the pages manually, the first was actually UTF-8 thrown in at random |
| 11:12 | <annevk> | foolip: ah interesting, I expect that might have happened more often |
| 11:12 | <annevk> | foolip: these pages are weird |
| 11:13 | <foolip> | annevk, should I send a reply to www-archive, or how? |
| 11:13 | <annevk> | foolip: either that or on the WHATWG list |
| 11:13 | <foolip> | ok, I'll see how many I have time to check |
| 11:13 | <annevk> | foolip: I'll write up a summary at some point I guess on my blog or somewhere and then update the spec |
| 11:13 | <annevk> | currently working on forking Appendix E of CSS |
| 11:20 | <Tuju> | RobbertAtWork: any idea is it possible to embed metainformation, like explanation of those tags into schema, strings that could be used when creating a xml file based on that schema? |
| 11:20 | <Tuju> | or should it be in own file? |
| 11:21 | <RobbertAtWork> | Tuju: http://www.w3schools.com/schema/el_annotation.asp |
| 11:22 | <Tuju> | RobbertAtWork: aaaah, exactly something like that. :) |
| 11:38 | <annevk> | how are |
| 11:38 | <annevk> | "An element in this layer is rendered in the CSS model as an atomic unit |
| 11:38 | <annevk> | that is a sibling to the root element;" |
| 11:38 | <annevk> | and |
| 11:38 | <annevk> | "The containing block for such an element is the initial containing |
| 11:38 | <annevk> | block" |
| 11:38 | <annevk> | different? |
| 11:39 | annevk | reads more of CSS 2.1 than he wants |
| 11:40 | <zcorpan> | annevk: that happened to me as well when trying to define quirks :-) |
| 11:40 | <annevk> | nope it's different |
| 11:41 | <annevk> | I was pretty close to defining some parts of CSS in a better way at some point, but there just seemed to be too much negative inertia in the CSS group |
| 11:41 | <annevk> | so I worked on other problems instead, e.g. Encoding |
| 12:00 | <hsivonen> | I wonder how velocity changes would work under negative inertia |
| 12:00 | <annevk> | oops :) |
| 12:02 | <annevk> | what I meant is that the focus always is on how to publish and organize things; rather than on how to solve the big problems |
| 12:03 | <jgraham> | hsivonen: Well the simple newton's law effect would be like inverting the direction of the force |
| 12:03 | <zcorpan> | annevk wants big bangs |
| 12:03 | <jgraham> | i.e. F = m (dv/dt) uner m->(-m) is equivalent to F->(-F) |
| 12:04 | <jgraham> | Needless to say this would cause complications :) |
| 12:38 | <annevk> | hmm, so I guess I should have some algorithms for updating the fullscreen element stack |
| 12:38 | <annevk> | and have those invoke the top layer stack algo |
| 12:38 | <annevk> | not such a bad sick day |
| 12:50 | <annevk> | matjas: eum, css3-hyperlink is obsolete |
| 12:53 | <zcorpan> | argh, how did i manage to double post? |
| 12:53 | <zcorpan> | and why did i get the indentation wrong |
| 12:54 | <annevk> | aliens |
| 12:55 | <Ms2ger> | Predator |
| 12:55 | <annevk> | now fight |
| 12:56 | <charlvn> | don't fight, be kawaii like VA http://www.youtube.com/user/VenusAngelic |
| 12:58 | <zcorpan> | bugzilla goes to great lengths to prevent accidental double-post of a bug, but doesn't mind double-post of comments |
| 12:59 | <AryehGregor> | . . . It's got to have been like ten years since I've heard anyone say "kawaii". |
| 12:59 | <Ms2ger> | ^ |
| 13:01 | <charlvn> | AryehGregor: you definitely don't hang out with japanophiles then |
| 13:01 | <AryehGregor> | charlvn, well, I used to, around the time that Pokémon was trendy. |
| 13:02 | <charlvn> | AryehGregor: eh, yes that has definitely been a while then :P |
| 13:03 | <charlvn> | actually kawaii isn't so bad, wait until they start about moe moe and maid cafes, then the conversation is turning full-out otaku |
| 13:05 | <charlvn> | on an unrelated note, i have been toying with using jsoup from python using jython and combining that with pygments |
| 13:06 | <charlvn> | the end result is extremely hacky but minimalist code (sounds a bit like perl) |
| 13:06 | <charlvn> | https://gist.github.com/2310803 |
| 13:06 | <matjas> | annevk: obsoleted by …? |
| 13:06 | <Ms2ger> | HTML |
| 13:07 | <annevk> | matjas: sanity and also HTML |
| 13:07 | <matjas> | hah |
| 13:07 | <annevk> | unfortunately TR/ documents are hard to correct |
| 13:07 | <annevk> | even if they're only drafts |
| 13:07 | <annevk> | so they will confuse people for years |
| 13:08 | <annevk> | in this case eight years now |
| 13:22 | <hsivonen> | No new IE6 countdown champions this year yet. :-( |
| 13:26 | <zcorpan> | hsivonen: any firefox 3.6 countdowns? |
| 13:36 | <annevk> | Hixie: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html has your top layer thing now |
| 13:36 | <annevk> | zcorpan: will look at your Fullscreen bugs in a minute |
| 13:39 | <zcorpan> | annevk: s/remove/pop/ ? |
| 13:40 | <zcorpan> | or isn't it pop? :-) |
| 13:41 | <annevk> | not if I define empty in terms of remove |
| 13:41 | <annevk> | well could still be |
| 13:41 | <annevk> | remove just seemed safer |
| 13:41 | <zcorpan> | k |
| 13:41 | <annevk> | but maybe I should call it add instead of push then |
| 13:41 | <annevk> | and have add perform a push operation |
| 13:42 | <annevk> | meh |
| 13:46 | <zcorpan> | ok now a quiz i don't know the full answer to :-) |
| 13:48 | <annevk> | App H |
| 13:48 | <Ms2ger> | ^ |
| 13:48 | <annevk> | the appendices themselve |
| 13:48 | annevk | goes back to fixing bugs |
| 13:49 | <Ms2ger> | \o/ |
| 13:49 | <zcorpan> | annevk: i know those too, but i suspect there are more |
| 13:52 | <annevk> | zcorpan: I think orange might be an easter egg |
| 13:53 | <annevk> | zcorpan: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16449 nitpicking much? :p |
| 13:53 | <zcorpan> | can't help it! :-) |
| 13:53 | <zcorpan> | what's with orange? |
| 13:54 | <annevk> | it was added for fun |
| 13:54 | <annevk> | or for the glory of the Dutch |
| 13:54 | <annevk> | prolly the latter |
| 14:15 | <charlvn> | if you put the orange and the green together it looks more like the flag of ireland |
| 14:16 | <zcorpan> | annevk: pretty responsive spec work with fullscreen |
| 14:17 | <annevk> | I like <dialog> |
| 14:19 | <zcorpan> | annevk: some Its should be It's |
| 14:20 | <zcorpan> | "rendered as an atomic unit as it were a sibling of the root element." missing an "if" |
| 14:21 | <annevk> | yup |
| 14:25 | <zcorpan> | annevk: aren't width/height unnecessary to set when all of top/right/bottom/left are set? |
| 14:25 | <zcorpan> | they get ignored anyway, i think |
| 14:25 | <annevk> | these are from roc's styles |
| 14:25 | <annevk> | I haven't really thought hard about that |
| 14:26 | <annevk> | I wonder more why there's no newline after the namespace declaration |
| 14:26 | <annevk> | bug in Opera |
| 14:26 | <annevk> | baaah |
| 14:26 | <annevk> | zcorpan: are you sure that is the case even for replaced elements? |
| 14:27 | <annevk> | zcorpan: I think they might get intrinsic sizing |
| 14:27 | <annevk> | zcorpan: which is not what we want for e.g. <iframe> |
| 14:27 | <annevk> | zcorpan: you're making me read CSS 2.1 again |
| 14:27 | <annevk> | this is a sad day |
| 14:28 | <annevk> | zcorpan: see http://www.w3.org/TR/CSS21/visudet.html#abs-replaced-width for why we likely need height/width |
| 14:28 | <zcorpan> | oh. that may well be true |
| 14:29 | <zcorpan> | ok |
| 14:30 | <zcorpan> | didn't know about that |
| 14:31 | <zcorpan> | also, i was wrong about what gets ignored |
| 14:31 | <zcorpan> | in case of over-constraining for non-replaced |
| 14:33 | <zcorpan> | annevk: to make it easier to put the fullscreen styles in the same style sheet as the rest of the ua styles, maybe you should make html the default namespace and use *|*:fullscreen |
| 14:35 | <annevk> | not unreasonable |
| 14:36 | <annevk> | done |
| 15:17 | <annevk> | foolip: did you get anywhere? I might take another look then |
| 15:17 | <foolip> | annevk, I'm about half way through |
| 15:17 | <annevk> | wow cool |
| 15:17 | <foolip> | annevk, it would help a lot if you could help me distill big5.json to the different options that there are for each weird sequence |
| 15:18 | <foolip> | now I'm just testing with the browsers that I have, and in some cases none of them do the right thing |
| 15:18 | <annevk> | I have these two functions |
| 15:18 | <annevk> | def get_index(lead, trail): |
| 15:18 | <annevk> | row = 0xFE-0xA1 + RANGE + 1 |
| 15:18 | <annevk> | cell = (trail-0xA1 + RANGE) if trail > (0x7E+1) else trail - 0x40 |
| 15:18 | <annevk> | return (lead-0x81) * row + cell |
| 15:18 | <annevk> | and |
| 15:19 | <annevk> | def get_bytes(index): |
| 15:19 | <annevk> | row = 0xFE-0xA1 + RANGE + 1 |
| 15:19 | <annevk> | lead = (index / row) + 0x81 |
| 15:19 | <annevk> | cell = index % row |
| 15:19 | <annevk> | trail = (cell + 0xA1 - RANGE) if cell > RANGE else cell + 0x40 |
| 15:19 | <annevk> | return (lead, trail) |
| 15:19 | <annevk> | by using get_index you can use the position in any of the browsers' arrays |
| 15:20 | <annevk> | if you have some code point, by first finding it in the index and then using get_bytes on its position, you can do the reverse |
| 15:21 | <foolip> | annevk, ok, let me try that with some of the results I have |
| 15:21 | <annevk> | oh sorry |
| 15:21 | <annevk> | you also need |
| 15:21 | <annevk> | RANGE = 0x7E-0x40+1 |
| 15:21 | <annevk> | (with apologies to hsivonen) |
| 15:22 | <foolip> | http://html5.org/temp/big5.json is up to date? |
| 15:22 | <annevk> | yes, I doubt the mapping has changed the last week :) |
| 15:22 | <foolip> | :P |
| 15:27 | <annevk> | so TR/dom we published today lacks takeRecords()? |
| 15:27 | <annevk> | haha |
| 15:29 | <Ms2ger> | Well, yes |
| 15:31 | <dglazkov> | good morning, Wha?...wg! |
| 15:32 | <foolip> | annevk, judging from the results so far, just using the -hk tables will fix these pages |
| 15:34 | <annevk> | wb dglazkov |
| 15:34 | <annevk> | foolip: sweet |
| 16:56 | <annevk> | jsbell: btw, apparently ES6 will get some kind of byte representation, might want to check with them just in case they have encoding API plans too |
| 16:57 | <annevk> | jsbell: https://mail.mozilla.org/listinfo/es-discuss |
| 16:57 | annevk | is not subscribed |
| 16:57 | <jsbell> | annevk: I follow es-discuss |
| 16:57 | <jsbell> | binary types for es6 haven't come up in ages |
| 16:58 | <jsbell> | annevk: latest thinking *should* be summarized in the "binary data" section of http://wiki.ecmascript.org/doku.php?id=harmony:proposals |
| 16:59 | <jsbell> | Last active discussion I heard was that reality would be accepted and everything would be built on top of Typed Array ArrayBuffers, but again there hasn't been active discussion recently. |
| 17:01 | <jsbell> | but thanks for the heads-up. I should ping dherman |
| 17:08 | <foolip> | annevk, I hope you're not in a hurry, I'll have to wait until next week to finish up the email |
| 17:09 | <Ms2ger> | foolip, noooooooo ;) |
| 17:14 | <TabAtkins> | zcorpan: Yes, it absolutely should get the "dont' look at me" treatment. I don't think it's in the repo, though. |
| 17:17 | <Ms2ger> | I guess it's in the MO folder |
| 17:24 | <TabAtkins> | Hixie: The "Canonical Order" line is just to define the serialization order. The serialization of the individual bits is defined by the datatype of the bit. |
| 17:47 | <annevk> | foolip: k, I might dig into gbk then |
| 17:47 | <annevk> | jsbell: cool |
| 17:56 | <danbri> | Hixie, how/where would you prefer to receive a proposal for multiple types in Microdata? |
| 17:56 | <Hixie> | abarth: Michal raises an interesting point regarding not leaking to advertisers the origin of the top-level page, since that would be a privacy leak if they can in any way (e.g. IP address, broader fingerprint) identify the user |
| 17:56 | <Hixie> | danbri: nowhere. :-) i would like to hear about concrete use cases for multiple types in the whatwg list, though. |
| 17:57 | <TabAtkins> | Hixie: Maybe sandboxes can't read up past the barrier? |
| 17:57 | <danbri> | if you get concrete use cases, is there some prayer you'll change the spec, or that ship has sailed? |
| 17:57 | <Hixie> | danbri: if there are convincing concrete use cases and implementors wishing to implement, it's never too late |
| 17:57 | <Hixie> | danbri: (the point being that syntax proposals should come after we've established that there's a problem -- so far all the discussions proposing multiple unrelated types have been theoretical use cases at best) |
| 17:58 | <Hixie> | TabAtkins: that might work |
| 17:58 | <danbri> | ok, i'll pull things together in w3c wiki and make a whatwg email of it |
| 17:59 | <Hixie> | danbri: the shorter the better, fwiw. i tend to find that the longer the description of the use case, the more vague and hand-wavy it is. |
| 17:59 | <Hixie> | danbri: the ideal use case is something like Foo Corp (a real company) is trying to do X and Y and cannot. |
| 17:59 | <danbri> | ok. |
| 18:00 | <Hixie> | danbri: as opposed to "maybe one day there will be two companies and they will support different vocabularies covering similar topics and it would be nice if we could in theory support both" |
| 18:00 | <Hixie> | danbri: or "today there are three vocabs for topic X, none of them actually implemented, but on the off-chance that one of them eventually is, and to hedge our bets, we'd like to use all three today" |
| 18:00 | <zcorpan> | "and to solve this I've developed RDF, now suck it up" |
| 18:00 | <Hixie> | danbri: both of which are rather uncompelling use cases (if nobody is consuming the data, why bother producing it, let alone producing it in two different vocabs) |
| 18:01 | <danbri> | schema.org (a group of engineers from several big companies) are trying to avoid going insane by having everything in their schema. And so they want 3rd parties to be able to declare subclasses directly. But they can't commit to maintaining a giant mush of all the 3rd party stuff out there, so will write consumer code only for known classes. Multiple types would all partial understanding, with 3rd parties adding detai |
| 18:01 | <danbri> | l while central schema has a useful core. |
| 18:01 | <Hixie> | danbri: schema.org's multiple type use case is already supported, since they just have a single vocabulary. |
| 18:01 | <Hixie> | common to all types |
| 18:02 | <Hixie> | (albeit with some properties only valid on some types) |
| 18:02 | <danbri> | no, because we want 3rd parties to be able to extend that vocab without having to agree everything with us. |
| 18:02 | <Hixie> | they can do that too, by just using URLs for their extension points (who is consuming their extension properties anyway?) |
| 18:03 | <Hixie> | ("extension" isn't a concrete use case, btw) |
| 18:03 | <TabAtkins> | So the use-case is "I want to publish data using a schema.org vocab so it'll get picked up by the googlebot, but I want to add additional details that aren't in the official vocab.". |
| 18:03 | <TabAtkins> | What are you doing with the additional details? |
| 18:04 | <TabAtkins> | I guess that's Hixie's "Who's consuming it?" question. |
| 18:04 | <Hixie> | yeah, as tab says, "I want to add additional details" isn't a concrete use case |
| 18:04 | <danbri> | so a single item description can have a type of e.g. http://schema.org/Person and http://historical-data.org/HistoricalPerson ? |
| 18:04 | <Hixie> | so long as both those types use the same vocabulary |
| 18:04 | <danbri> | Google are consuming it, amongst others |
| 18:04 | <Hixie> | google aren't consuming the non-schema.org extensions |
| 18:04 | <TabAtkins> | danbri: Google are consuming the schema.org properties, yes. Who's consuming the extra ones you want to add? |
| 18:05 | <danbri> | but they want the non-schema.org extensions to be there |
| 18:05 | <danbri> | ... so that if they are successful they can be consumed |
| 18:05 | <Hixie> | so just put them in the schema.org "namespace" and use a wiki to do first-come-first-served name registration |
| 18:05 | <Hixie> | same as rel="" |
| 18:05 | <Hixie> | so it's still all the same vocab |
| 18:06 | <Hixie> | bbiab |
| 18:48 | <manu-db> | hsivonen: We discussed your responses to ISSUE-130 and ISSUE-132 (@rel, @rev, @href and @src in HTML5+RDFa) today: http://www.w3.org/2010/02/rdfa/meetings/2012-04-05#Responses_to_Henri_Sivonen |
| 18:49 | <manu-db> | I'll do a formal response in the next few days, just giving you a heads-up. |
| 18:49 | <annevk> | Hixie: "just tied to sandbox" and then advertisers will demand not be sandboxed... |
| 18:50 | <annevk> | Hixie: that can happen already, but more so if fingerprinting features become available |
| 18:50 | <Hixie> | annevk: well, whatever solution we provide will be optional, so that argument applies to everything |
| 18:51 | <Hixie> | annevk: what do you mean by "fingerprinting features become available"? |
| 18:52 | <annevk> | disabling sandbox, you get ancestorOrigins |
| 18:54 | <Hixie> | we could fake it, i guess |
| 18:54 | <Hixie> | make ancestorOrigins act as if it only contained the parent |
| 18:55 | <Hixie> | so then you can't tell |
| 18:55 | <annevk> | Google can tell because of indexing |
| 18:55 | <annevk> | and others could do likewise |
| 18:56 | <annevk> | note to self for tomorrow: maybe instead of partial Element for Fullscreen put it on HTMLElement/SVGSvgElement |
| 18:56 | <annevk> | doesn't make much sense for <rect> and such |
| 18:56 | <Hixie> | well anyway my point is that the argument applies to any solution |
| 18:57 | <Hixie> | it's not special for sandboxing |
| 19:00 | <annevk> | ah yeah, so maybe we shouldn't do it |
| 19:00 | <annevk> | if the parent cooperates it can already be exposed of course, but this makes it a lot easier |
| 19:28 | <Hixie> | annevk: so how do you address the security issue in the non-advertising case? |
| 21:24 | <annevk> | Hixie: touche |
| 21:24 | <annevk> | touché, rather |
| 21:25 | <annevk> | I named Fullscreen a Living Standard btw now that you guys solved the final problem and I specced it |
| 21:32 | <rniwa> | AryehGregor: yt? |
| 21:33 | <annevk> | and yay, Notifications got an update finally |
| 21:33 | <annevk> | though it needs more work |
| 21:33 | <annevk> | maybe I should help out... |
| 21:33 | annevk | -> sleeep |
| 21:44 | <sedovsek> | annevk: I see you're going to fronteers. |
| 21:45 | <sedovsek> | Just spoted you among attendees on lanyrd, http://lanyrd.com/2012/fronteers/ |
| 22:06 | <Hixie> | i wonder what the default value of anchor-point should be |
| 22:06 | <Hixie> | it could be 'auto' |
| 22:06 | <Hixie> | but then i wonder what algorithm to use to determine the anchor point |
| 22:06 | <Hixie> | it could be something really clever... |
| 22:06 | <TabAtkins> | Where's spec/proposal for dialogs that explains anchor-point? |
| 22:06 | <Hixie> | http://wiki.whatwg.org/wiki/Dialogs#Proposal |
| 22:07 | <Hixie> | "explains" may be a bit strong though |
| 22:07 | <TabAtkins> | "Proposes in a handwavey fashion" is sufficient. |
| 22:08 | <TabAtkins> | Urgh, this *really* needs the "position from an arbitrary box" proposal. |
| 22:08 | <TabAtkins> | Maybe not the full one on my blog, but a simplified one. |
| 22:08 | <Hixie> | ignore the point where it says "the anchor point is the center of the given element's first box", i want it to be "the anchor point is the anchor point of the given element's first box" |
| 22:09 | <Hixie> | i'm fine with using something else if there's a spec i can point to or if i can spec something better than what i'm doing |
| 22:09 | <TabAtkins> | Ok, so your intention is that the dialog and the passed element just align their anchor points? |
| 22:10 | <Hixie> | yeah |
| 22:10 | <Hixie> | the idea being that you'd put the dialog's image border's "<" bit at the anchor point of the dialog |
| 22:11 | <TabAtkins> | Okay, hm. I don't think you actually want to specify the two anchor points separately. The positioning element should specify both of them. |
| 22:12 | <Hixie> | happy to entertain proposals if you have any :-) |
| 22:15 | <TabAtkins> | Simplest method is to define "position-root: auto | <element-reference>;", which changes the positioning container for the element. 'auto' is the standard behavior, based on the 'position' value. |
| 22:15 | <TabAtkins> | Then just use t/r/b/l as normal. |
| 22:15 | <TabAtkins> | You need some cycle detection, unfortunately. |
| 22:16 | <Hixie> | how do i align a dialog so that the point 10px down its left edge is 1em down the target's right edge, with that? |
| 22:16 | <TabAtkins> | Ah, if you want to get that fancy, you want the fuller model that I present in http://www.xanthir.com/blog/b48H0 |
| 22:17 | <TabAtkins> | Or, you may be able to get away with "position-root: auto | [ <element-reference> <position>? ];" |
| 22:17 | <Hixie> | (with my proposal, you just say "anchor-point: right at 1em from top" on the target, "anchor-point: left at 10px from top" on the dialog, and you call dialog.show(target) ) |
| 22:17 | <TabAtkins> | Hixie: How do you hang multiple dialogs off a single element? |
| 22:18 | <TabAtkins> | That want different anchor-points on the target? |
| 22:18 | <Hixie> | you don't |
| 22:18 | <Hixie> | (nobody showed an example of that in the list of use cases i'm using to design this) |
| 22:18 | <TabAtkins> | What's with all your "at" and "from" keywords? What do those do? |
| 22:18 | <TabAtkins> | You're just specifying a point. |
| 22:19 | <TabAtkins> | "right 1em top" works. |
| 22:19 | <Hixie> | the syntax is <edge> at [ <length> from ] <edge-on-other-axis> |
| 22:19 | <TabAtkins> | That's handled by the <position> type defined in V&U. |
| 22:19 | <TabAtkins> | That seems like a silly way to define a point on a box. |
| 22:20 | <Hixie> | how so? |
| 22:20 | <Hixie> | (it's a point on an edge, not a point on a box) |
| 22:20 | <TabAtkins> | Why are you restricting it to points on edge? |
| 22:20 | <Hixie> | because all the use cases are for aligning edges |
| 22:21 | <TabAtkins> | It doesn't make things any simpler, and actually complicates things by not just using the <position> syntax. |
| 22:21 | <TabAtkins> | Using <position> handles edge-aligning exactly as easily, with slightly less typing, and also handles more general cases. |
| 22:24 | <Hixie> | how do you do the equivalent of "right at 1em from bottom" with <position>? |
| 22:24 | <TabAtkins> | "right 1em bottom" |
| 22:24 | <TabAtkins> | Oh, sorry. |
| 22:24 | <TabAtkins> | "right bottom 1em" |
| 22:24 | <TabAtkins> | Misread your syntax because I'm so used to the ordering that <position> uses. ^_^ |
| 22:26 | Hixie | finally manages to follow links to the right spec and mumbles (a) something about living standards and (b) something about spec quality |
| 22:27 | <Hixie> | yeah, i guess <position> would work |
| 22:27 | <Hixie> | kinda ugly, but not fatally so |
| 22:27 | <TabAtkins> | Um. It's *exactly* your syntax, just without the useless extra keywords. |
| 22:28 | <Hixie> | the "useless extra keywords" are what makes it usable :-) |
| 22:29 | <TabAtkins> | Disagree, but whatever. ^_^ More importantly, <position> is used in several places, and having a new syntax for it, particularly one that orders the values differently, would be excessively confusing. |
| 22:30 | <Hixie> | i am already convinced :-) |
| 22:30 | <TabAtkins> | NO YOU MUST SUBMIT |
| 22:30 | <Hixie> | man, the chain of specs to get to <position> is a poor story though |
| 22:30 | <Hixie> | css3 values and units points to two different definitions, and the css3 background module's definition is just completely devoid of conformance criteria |
| 22:30 | <TabAtkins> | Hm? You go V&U to B&B. I'd prefer defining it directly in V&U, but whatever. |
| 22:31 | <Hixie> | V&U points to CSS2.1 first, then B&B in a second sentence. |
| 22:31 | <TabAtkins> | Yeah, that's to avoid gating our Rec on B&B's status. |
| 22:31 | <Hixie> | and in fact the only normative chain is to 2.1, strictly speaking |
| 22:32 | <Hixie> | so i guess i'd have to reference b&b if i wanted to do a strictly correct job here |
| 22:32 | <TabAtkins> | No, you should reference V&U. |
| 22:32 | <Hixie> | then i don't get the b&b definition :-) |
| 22:32 | <Hixie> | since i'm hoping this won't remain my problem for long, i don't much care though |
| 22:33 | <TabAtkins> | Um, I don't understand. In V&U it clearly says that the syntax for <position> is updated in B&B, and UAs that support B&B must interpret <position> as defined there. |
| 22:34 | <Hixie> | right |
| 22:34 | <Hixie> | but what if my ua doesn't support b&b? |
| 22:35 | <Hixie> | also, it's kinda special to define something as X and then say that it must be interpreted as X'. :-) |
| 22:35 | <TabAtkins> | That's how you do modules! |
| 22:35 | <Hixie> | modules are dumb |
| 22:35 | <Hixie> | especially on the web |
| 22:35 | <TabAtkins> | Shrug. |
| 22:35 | <TabAtkins> | It's an alternate formulation of the living standard. |
| 22:36 | <Hixie> | it's clearly nothing like the living standard since there's not one canonical url which is updated over time, but that's not the issue |
| 22:36 | <Hixie> | modularisation is orthogonal to living vs snapshot |
| 22:37 | <TabAtkins> | Not quite. I challenge you to produce a snapshot document that's not modularized without being drastically out-of-date. |
| 22:37 | <TabAtkins> | Your choices are either "one document, living", or "modules, living or snapshot" if you want accurate specs. |
| 22:38 | <Hixie> | snapshot documents are always out of date |
| 22:38 | <Hixie> | that's the problem with snapshots :-) |
| 22:38 | <TabAtkins> | Sure, but you require modules if you want the out-of-date-ness to be minimized. |
| 22:39 | <Hixie> | nah, you can have rarely-updated living modules just like you can have frequently-updated monolithic RECs |
| 22:40 | <Hixie> | the rate of update is also orthogonal to living vs REC and module vs monolithic |
| 22:40 | <TabAtkins> | Frequently-updated monolithic RECs are a theoretical beast that's never been observed in reality. |
| 22:40 | <Hixie> | CSS 2.1 was a frequently-updated monolithic REC from about 2000 to 2006 |
| 22:40 | <Hixie> | well |
| 22:40 | <Hixie> | frequently-updated monolithic CR |
| 22:41 | <Hixie> | not as frequent as you or i may wish these days, i'll grant you |
| 23:20 | <Hixie> | i wonder if we need an attribute a bit like "disabled" but that globally prevents a subtree from being focused or having anything within it activated, without actually making the descendants appear disabled |
| 23:20 | <Hixie> | so that semi-modal dialogs (dialogs that are locally modal but not across the entire web app) can be implemented |
| 23:20 | <TabAtkins> | Like "pointer-events:none"? |
| 23:20 | <Hixie> | but for tabbing and everything |
| 23:20 | <TabAtkins> | With more magic to prevent tabbing. |
| 23:20 | <TabAtkins> | "inert" |
| 23:20 | <Hixie> | and accesskey="", and ATs, and so on |
| 23:21 | <Hixie> | or maybe we should just have showModal() take an element relative to whom subtree the dialog should be modal |
| 23:21 | <Hixie> | to whose, rather |
| 23:26 | <Hixie> | nah, i think a global attribute is probably better |
| 23:27 | <Hixie> | there could be multiple subtrees to disable |
| 23:28 | <TabAtkins> | So the code that shows the dialog sprinkles some @inert aroudn the DOM, and the code that closes the dialog removes them? |
| 23:29 | <Hixie> | TabAtkins: i guess, yeah |
| 23:30 | <TabAtkins> | Do we expect UAs to offer their own ways to close non-modal dialogs? |
| 23:30 | <Hixie> | TabAtkins: might be useful for other scenarios too, e.g. i have an app with several mutually exclusive <section>s, but because I leave the inactive ones slightly visible in the background (when they have hidden=""), instead of making them display:none, I still need a way to make them inert |
| 23:30 | <Hixie> | i don't think i'd want to use <Dialog> for those really |
| 23:30 | <Hixie> | TabAtkins: no |
| 23:31 | <Hixie> | TabAtkins: non-modal dialogs are basically just <div>s |
| 23:33 | <TabAtkins> | Okay, then I'm okay with that. |
| 23:34 | <TabAtkins> | Since the only way to close a non-modal dialog would be through an author-provided function. |
| 23:35 | <Hixie> | i wonder if there's some overlap between this inert=""ness and the inertness we need in templates |
| 23:35 | <TabAtkins> | No. |
| 23:35 | <Hixie> | i'm guessing not (and that templates need much more) |
| 23:35 | <TabAtkins> | That "inertness" is more "no parsing implications to the surrounding content". |
| 23:35 | <TabAtkins> | Plus "no network activity". |
| 23:35 | <TabAtkins> | In addition to the inertness you want for this. |
| 23:43 | <Hixie> | yeah |
| 23:44 | <zewt> | grr |
| 23:44 | <zewt> | nothing is quite as frustrating as "if we change this we'll break some tests, so let's not do it" |
| 23:44 | <TabAtkins> | wtf |
| 23:44 | <TabAtkins> | Where? |
| 23:45 | <zewt> | tests being used as an excuse not to improve something is pretty much the exact opposite to why tests exist |
| 23:45 | <zewt> | Also, if the behavior is changed, the 1.0.1 conformance suite will no longer run on future WebGL implementations, because it tests passing null for WebGLObjects and expects that no exceptions are thrown. |
| 23:45 | <zewt> | not a hard "we can't do this because tests", but it shouldn't even be a consideration |
| 23:47 | <zewt> | also, surprise, webgl returning null on error causes lots of bugs in user code |
| 23:47 | <zewt> | also frustrating since the entire industry learned that C-style error handling is badly error prone a couple decades ago |
