| 09:14 | <zcorpan> | TabAtkins: each side of the equation had a multiplier, you can't just compare the numbers and call the equation untrue |
| 09:16 | <zcorpan> | TabAtkins: e.g. html = 1.1 and rdfa = 4.01 would solve the equation |
| 11:55 | <annevk> | colleague had this idea similar I guess to the JSON idea going around |
| 11:56 | <annevk> | representing a Node as an array so you can build templates and then create a whole structure using Element.create(templ) |
| 11:56 | <annevk> | something like: |
| 11:57 | <annevk> | TMPL = [NAME, optional ATTRS, optional HANDLERS, optional TEXT|TMPL...] |
| 11:57 | <annevk> | kind of neat |
| 11:59 | <Lachy> | Are the attrs, handlers, etc. represented as nested arrays or other structure? |
| 11:59 | <jgraham> | annevk: That's kind of how the templating system in testharness.js works |
| 11:59 | <annevk> | they would be objects |
| 11:59 | <jgraham> | I'm not sure if it's the idea that sucks or just the implementation |
| 11:59 | <annevk> | jgraham, apparently Dragonfly uses it as well |
| 12:00 | <annevk> | it seems everyone sort of invents this on their own |
| 12:01 | <Lachy> | ok, so like ["div", {"class": "foo"}] would represent <div class="foo"> |
| 12:02 | <jgraham> | http://dvcs.w3.org/hg/html/file/1d201654fce1/tests/resources/testharness.js#l1390 is my version of that idea |
| 12:02 | <jgraham> | Like I said that particular implementation kind of sucks though |
| 12:03 | <annevk> | Lachy, yeah |
| 12:04 | <annevk> | jgraham why did you have the special text node thing? |
| 12:05 | <jgraham> | annevk: If you want to create a text node but also use the simple format string functionality I added. I think it might have been just to make the implementation easier. |
| 12:06 | <jgraham> | Well I guess the point is that you can't just pass in ["text"]. And there might be some reason that you can't pass in "text" that I forget |
| 12:06 | <annevk> | k |
| 12:06 | <annevk> | once heycam is back I guess I'll take a stab at this |
| 12:16 | <yaffle> | hello! |
| 12:18 | <yaffle> | @Hixie what about this http://www.w3.org/Bugs/Public/show_bug.cgi?id=14331 ? |
| 12:19 | <yaffle> | @Hixie i create test case: currently Opera and Chrome fires "message" events even after "close()" |
| 12:19 | <annevk> | Hixie is in California so unlikely to be awake at the moment |
| 12:19 | <yaffle> | @Hixie and Firefox 7 doesn't fires any "message" after close() |
| 12:21 | <zcorpan> | annevk: for template you probably want to return a document fragment |
| 12:21 | <zcorpan> | annevk: maybe new DocumentFragment(template) |
| 12:22 | <annevk> | rather just an element |
| 12:22 | <annevk> | I think |
| 12:22 | <zcorpan> | what if the template has just a text node? |
| 12:22 | <jgraham> | Being able to create a list of elements to insert into an existing element is rather convenient |
| 12:23 | <zcorpan> | or several elements |
| 12:23 | <zcorpan> | or mixed |
| 12:23 | <annevk> | a template is by definition an element |
| 12:23 | <jgraham> | Huh? |
| 12:24 | <annevk> | see above |
| 12:24 | <zcorpan> | ? |
| 12:24 | <jgraham> | Well sure, you can write a system that only allows generating a single element |
| 12:24 | <annevk> | http://krijnhoetmer.nl/irc-logs/whatwg/20111003#l-289 |
| 12:25 | <jgraham> | But that's not the definition of template |
| 12:25 | <annevk> | it's the definition I gave |
| 12:25 | <annevk> | if we are discussing a different proposal, please say so :) |
| 12:26 | <jgraham> | We are discussing the proposal to generalise your system to allow more than just a single element :) |
| 12:26 | <jgraham> | Or single subtree |
| 12:26 | <zcorpan> | annevk: if one wants a list of elements or list of elements mixed with text nodes, the root element of your template proposal would just be in the way |
| 12:28 | <jgraham> | zcorpan: So I think this could be where things start to get hairy. My system supports this because it is clearly useful |
| 12:29 | <jgraham> | But you need to be clear on what is a list of elements and what is supposed to be a single element |
| 12:29 | <jgraham> | I guess using multiple arguments would work |
| 12:30 | <jgraham> | documentfragment.create(elm1, elm2, etc.) |
| 12:31 | <annevk> | if the DocumentFragment is just for later insertion shouldn't it be directly supported on appendChild and co somehow? |
| 12:32 | <zcorpan> | appendChild(elm1, elm2, 'foobar') ? |
| 12:32 | <annevk> | not sure that syntax works well given insertBefore |
| 12:32 | <zcorpan> | or appendChild([elm1, elm2, 'foobar']) |
| 12:33 | <annevk> | that you cannot disambiguate |
| 12:33 | <annevk> | unless inserting a single element would require it to be wrapped |
| 12:33 | <zcorpan> | right |
| 12:33 | <annevk> | eww |
| 12:35 | <jgraham> | I think using lists there was one of the major mistakes I made |
| 12:35 | <jgraham> | rather than variable number of arguments |
| 13:06 | <annevk> | anyone here with opinions on event handlers? |
| 13:06 | <annevk> | should they move to Element? |
| 13:06 | <annevk> | should content attributes? |
| 13:07 | <Ms2ger> | I think people wanted the IDL attributes to move to Element, at least |
| 13:07 | <annevk> | bz argued for that, indeed |
| 13:08 | <annevk> | I think we can import most of what HTML says about them |
| 13:08 | <annevk> | we might need to define BeforeUnloadEvent |
| 13:09 | <annevk> | hsivonen, are you going to reply to http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1787.html ? |
| 13:53 | <hsivonen> | annevk: today. I can prioritize it |
| 13:54 | <hsivonen> | today is one of those days when every press of the return key is an opportunity to crash xorg |
| 13:54 | <annevk> | no need to prioritize |
| 13:54 | <annevk> | I'm in no rush |
| 14:07 | <annevk> | zcorpan, about your bug: http://dev.w3.org/cvsweb/csswg/cssom/Overview.src.html.diff?r1=1.83;r2=1.84 |
| 14:07 | <annevk> | zcorpan, I'm not quite sure what the rationale was though :( |
| 14:13 | <zcorpan> | annevk: maybe it's needed for .backgroundColor etc but not for setProperty? |
| 14:13 | <annevk> | I guess the rationale was that backgroundColor = null should be the same as backgroundColor = "" |
| 14:14 | <annevk> | TreatNullAs=... would prolly be a better directive to use then |
| 14:20 | <hsivonen> | annevk: I replied |
| 14:22 | <annevk> | "the chairs have reached consensus" |
| 14:22 | <annevk> | is that the goal these days? |
| 14:27 | <annevk> | thanks hsivonen |
| 14:30 | <annevk> | zcorpan, should I just remove it for now? |
| 14:30 | <annevk> | zcorpan, nobody mentioned this as compatibility concern, but maybe Microsoft did not test thoroughly |
| 14:33 | <zcorpan> | annevk: i'd like it removed from setProperty at least |
| 14:33 | <annevk> | removed it from both |
| 14:34 | <annevk> | if we need TreatNullAs=Empty annotations someone should let me know |
| 15:00 | <djr> | Hey guys, am looking at the validator.nu project with the idea of improving the build system for deployments |
| 15:01 | <Ms2ger> | hsivonen, ^ |
| 15:02 | <djr> | by improving I mean managing all the java dependencies under maven. The current python build script is good for getting things up and running |
| 15:04 | <djr> | just, makes it a bit awkward to deploy on any of these platforms that support java ootb |
| 15:34 | <djr> | okay I've gotten so far in making each of the separate components under validator.nu have their own pom file |
| 15:36 | <djr> | just discovered there is a circular dependency between the 'syntax' and 'utils' repos |
| 15:37 | <djr> | hsivonen: MikeSmith: any thoughts? |
| 15:40 | <MikeSmith> | djr: there are probably other circular dependencies in there as well |
| 15:41 | <MikeSmith> | anyway, I don't reckon hsivonen would be too keen on switching the build system to use maven |
| 15:41 | <MikeSmith> | me neither, really |
| 15:41 | <MikeSmith> | if we were to switch it something else, I'd vote for just using make |
| 15:42 | <djr> | MikeSmith: well I read the reasoning behind the python build script as being, so you don't need maven :) |
| 15:44 | <MikeSmith> | djr: I've always thought that using a python script to do the actual build is a little odd |
| 15:44 | <MikeSmith> | but it does seem to work well enough for most people |
| 15:44 | <karlcow> | first mention of "What problem are you trying to solve?"— Roy T. Fielding http://lists.w3.org/Archives/Public/ietf-http-wg-old/1996MayAug/0019.html |
| 15:44 | <djr> | MikeSmith: using maven and having all the libraries treated as separate components... not having circular dependencies... that would be awesome |
| 15:45 | <djr> | mainly cause I think it doesn't have to be, use one or the other |
| 15:45 | <MikeSmith> | true |
| 15:45 | <djr> | was surprised to find, http://mvnrepository.com/artifact/nu.validator.htmlparser |
| 15:46 | <djr> | which works great, am just hacking around trying to get the whole project built like that |
| 15:46 | <MikeSmith> | djr: but using a real dependency-aware build system would mostly be beneficial to developers working on the sources |
| 15:46 | <MikeSmith> | who need to make changes to the source and rebuild while they are doing development |
| 15:46 | <MikeSmith> | so it would save time if they didn't have to rebuild targets whose dependencies have not changed |
| 15:47 | <djr> | well the python stuff would work well for dev |
| 15:47 | <MikeSmith> | but the fact is that the full build only takes a minute or so to run |
| 15:47 | <djr> | I'm suggesting maven for a production friendly build |
| 15:47 | <MikeSmith> | ok |
| 15:48 | <MikeSmith> | djr: if you have ideas on how to resolve the circular dependencies, I would be happy to help test them |
| 15:48 | <MikeSmith> | the biggest current problem with the build is that it always fails the very first time you run it from a fresh checkout |
| 15:48 | <djr> | yeah |
| 15:49 | <MikeSmith> | and it also has no "clean" target |
| 15:49 | <djr> | I'm no java expert :) am just hacking around at present |
| 15:50 | <djr> | am thinking a way might be to create a complete clone of everything and have a complicated pom that just builds the whole thing and not care about the dependencies |
| 15:50 | <djr> | well, can use the httpclient, but that's about it. |
| 15:51 | <djr> | The only way I would see if resolving the circular dependencies would be to split some of the stuff out of the util library |
| 15:52 | <djr> | and put it in a thing which depends on org.whattf |
| 15:55 | <kling> | is there a downloadable version of the single-page html spec somewhere? |
| 15:55 | <Ms2ger> | ctrl-s? |
| 15:55 | <kling> | (that would open in the browser without needing external resources from whatwg.org etc) |
| 15:55 | <Ms2ger> | Or you could checkout from svn |
| 15:55 | <Ms2ger> | Oh, hmm |
| 15:55 | <Ms2ger> | I don't think sp |
| 15:55 | <Ms2ger> | so* |
| 15:56 | <Ms2ger> | Unless the epub stuff actually happened in the end |
| 15:56 | <kling> | mm, okay |
| 16:06 | <djr> | MikeSmith: do you know who actually maintains the production install of validator.nu ? |
| 16:07 | <MikeSmith> | djr: you mean the http://validator.nu/ site? |
| 16:07 | <djr> | aye |
| 16:08 | <djr> | maybe am jumping the gun with all this maven shite :) all I really want to do is improve our deployment of the validator |
| 16:09 | <hsivonen> | indeed I'm not keen on moving to Maven |
| 16:09 | <djr> | currently running a massive command to java, under screen |
| 16:09 | <djr> | maven would be amazing as it would be a simple, git push heroku |
| 16:10 | <djr> | that's the only real reason |
| 16:12 | <timeless> | hello hsivonen |
| 16:18 | <hsivonen> | timeless: hello |
| 16:18 | <timeless> | how's finland? |
| 16:18 | <hsivonen> | timeless: rainy. |
| 16:18 | <hsivonen> | timeless: well, Helsinki at least |
| 16:19 | <hsivonen> | djr: the parser component used to be in Maven |
| 16:19 | <hsivonen> | djr: it's not anymore, because the current packaging steps do stuff that I don't know how to do in Maven |
| 16:21 | <djr> | hsivonen: oh, right. Dang |
| 16:22 | <djr> | hsivonen: I'm abandoning my approach of making each of your repos a 'library' to be managed under maven... instead trying to do something with the whole project itself |
| 16:24 | <hsivonen> | note that "I don't know how to do with Maven" doesn't equal "can't be done in Maven" |
| 16:24 | <hsivonen> | I know very little about Maven except that it makes things more complicated for me |
| 16:24 | <djr> | :) |
| 16:26 | <Yaffle> | hi |
| 16:26 | <djr> | yeah, I think it would be possible but because of the circular dependency it would probably need some changes to the utils / syntax repos |
| 16:27 | <djr> | am happy to try hack with that in the future, but I think for now I can do something that won't need any changes on your end |
| 16:28 | <djr> | will let you know how it goes. |
| 16:28 | <djr> | Thanks hsivonen / MikeSmith |
| 16:29 | <timeless> | more complicated hardly sounds like progress :) |
| 16:29 | <MikeSmith> | djr: cheers |
| 16:29 | <timeless> | hi MikeSmith |
| 16:29 | <djr> | happy to help with any of these things we've been talking about! |
| 16:43 | <annevk> | anyone else read this? |
| 16:43 | <annevk> | http://infrequently.org/2011/10/real-constructors-webidl-last-call/ |
| 16:44 | <annevk> | bit of a rant on magical constructors |
| 16:48 | <Ms2ger> | Oh, is that the guy who keeps arguing about changing the default? |
| 16:49 | <annevk> | yeah |
| 16:50 | <annevk> | he works on Chrome Frame for Google, but as far as standards go... |
| 16:51 | <jgraham> | Alex Russel is kind of lame. He tries to rant but doesn't have any style. |
| 16:51 | <Ms2ger> | Did he ever explain what new HTMLHeadingElement() should return? |
| 16:51 | <jgraham> | He should have described lack of constructors as "cancer for the web" or something equally silly |
| 16:52 | <jgraham> | *Russell |
| 16:55 | <annevk> | that he keeps pushing a proposal which hasn't been thought through in detail is annoying and a big waste of everyone's time |
| 16:55 | <Ms2ger> | Welcome to web standards |
| 16:55 | <jgraham> | Ah, so he is good at standards then |
| 16:56 | <jgraham> | Do people really want to do new HTMLDivElement? |
| 16:56 | <jgraham> | I mean jQuery doesn't work like that |
| 16:56 | <Ms2ger> | I've heard that claim |
| 16:56 | <jgraham> | Is there some framework that works with lots of new Foo() type syntax? |
| 16:57 | <jgraham> | Closure? |
| 16:57 | <Ms2ger> | Never from an actual webdev, though |
| 16:57 | <jgraham> | var newHeader = goog.dom.createDom('h1', {'style': 'background-color:#EEE'}, |
| 16:57 | <jgraham> | 'Hello world!'); |
| 16:58 | <jgraham> | Doesn't look much like new Foo() |
| 16:59 | <jgraham> | (complaining that things don't look like javascript when you work for *Google*is pretty much the definition of irony. All their javascript libraries look like java) |
| 16:59 | <Ms2ger> | Maybe that's why he wants it in the DOM? Then he doesn't have to use their javaey stuff |
| 16:59 | <zewt> | heh |
| 17:00 | <zewt> | that'd be a pretty gigantic hammer to work around your company having annoying libraries: "get what you want built into every browser" |
| 17:01 | <jgraham> | zewt: But it's just flipping a default in the WebIDL spec! |
| 17:02 | <annevk> | flip the default already |
| 17:02 | <annevk> | magical ponies for everyone |
| 17:02 | <annevk> | also make work |
| 17:02 | <annevk> | but look, ponies! |
| 17:02 | <zewt> | unicorns? |
| 17:03 | <jgraham> | With the magic ponies obsession, it's no wonder people think annevk is a girl |
| 17:04 | <Ms2ger> | Well done, doctor |
| 17:05 | <annevk> | he's no psychologist though |
| 17:39 | <annevk> | "FOR something so central to the modern world, the internet is shambolically governed. It is run by a hotch-potch of organisations with three- to five-letter acronyms." |
| 17:39 | <annevk> | now it's even more clear how secretive the WHATWG is |
| 17:39 | <annevk> | not recognized by The Economist! |
| 17:40 | <hsivonen> | I thought the governance issues were with ICANN |
| 17:40 | <annevk> | http://www.economist.com/node/21531011 btw |
| 17:40 | <zewt> | a ... hotch-potch? |
| 17:40 | <zewt> | (and that's skimming right over "shambolically") |
| 17:40 | <annevk> | hsivonen, ah governance in that sense, fair enough |
| 17:41 | <annevk> | zewt, what's wrong? |
| 17:42 | <zewt> | pretty absurd writing, heh |
| 17:43 | <annevk> | pretty accurate though |
| 18:03 | <jcranmer> | annevk: to be fair, the WHATWG isn't exactly a governing body of the internet |
| 18:03 | <jcranmer> | ICANN and IANA are the primary "governing" bodies |
| 18:05 | <jcranmer> | "Most the IETF standards mirror ITU standards (e.g. email - smtp - X.400)." ... bwahahaha |
| 18:05 | <jcranmer> | I much prefer foo⊙bc over CN=foo,OU=bar,OU=com :-) |
| 18:06 | <annevk> | yeah |
| 18:07 | <annevk> | what is the three-letter acronym then though? |
| 18:07 | <annevk> | I initially thought W3C, but that is not governing either |
| 18:08 | <annevk> | ooh bitbucket has Git now |
| 18:09 | <karlcow> | ISO? |
| 18:09 | <annevk> | doh |
| 18:10 | <annevk> | well actually |
| 18:10 | <annevk> | oh well |
| 18:10 | <Hixie> | IANA isn't a governing body, it's a registration body |
| 18:30 | <AryehGregor> | Gmail's rich-text editor seems to be completely broken. Professionally, I am unsurprised. |
| 18:31 | <zewt> | i wish the entire html-pasting "feature" would die |
| 18:31 | <zewt> | the only effect it's had on my life is that every single time I paste from a webpage into gmail, I have to paste mail into a text editor and re-copy it so it doesn't paste in some random font |
| 18:32 | <djr> | hsivonen: MikeSmith: I believe I'm quite close here > https://raw.github.com/gist/10e1e61ee4bb32639367/20e6937b5350221487272210f14680a186bd1861/validator-nu-maven-build-failure.sh |
| 18:32 | <zewt> | (at least presumably the undo work will fix gmail and every other web editor's undo, which seems to essentially put the cursor in a random place after each undo) |
| 18:33 | <AryehGregor> | zewt, you can use the "remove formatting" feature. |
| 18:35 | <zewt> | don't know where that is, but I'd sooner it just stop doing that, it's nothing but an annoyance |
| 18:36 | <zewt> | sometimes I've just converted to plain text and back to get rid of everything |
| 18:36 | <AryehGregor> | It's a little T with a red X next to it. |
| 18:37 | <zewt> | Meaningless Icon Syndrome |
| 18:49 | <timeless> | zewt: hey, i do that for Outlook calendar items! |
| 18:49 | <timeless> | (i can't find a way to tell outlook i don't want calendar items to be rich text) |
| 18:50 | <AryehGregor> | Yay, sane HTTPS URLs for Wikipedia: https://en.wikipedia.org/wiki/Main_Page |
| 18:52 | <tomasf> | aaah. no more secure.wikimedia.org |
| 18:52 | <AryehGregor> | With extensive use of protocol-relative URLs, incidentally. |
| 18:52 | <timeless> | AryehGregor: is there a news article for this? |
| 18:53 | <AryehGregor> | timeless, http://www.google.com/search?q=wikipedia+protocol-relative+urls has some relevant things. |
| 18:53 | <AryehGregor> | timeless, http://blog.wikimedia.org/2011/10/03/native-https-support-enabled-for-all-wikimedia-foundation-wikis/ |
| 18:53 | <AryehGregor> | There you go. |
| 18:53 | <timeless> | thanks, that's what i wanted :) |
| 18:55 | <AryehGregor> | There are techy details here: http://wikitech.wikimedia.org/view/Https |
| 18:55 | <AryehGregor> | They work around lack of SNI support by having one IP address for each second-level domain. |
| 18:55 | <AryehGregor> | And wildcard certs. |
| 18:57 | <timeless> | > SNI is only supported in fairly modern browsers (IE7, FX2, Opera8). |
| 18:57 | <timeless> | yeah, Fx2 is fairly modern... :) |
| 18:57 | <timeless> | (the problem of course is IE6..) |
| 18:57 | <AryehGregor> | Yeah. |
| 18:57 | <AryehGregor> | There was a surprising amount of work needed to get it to work properly. You'd think it would be relatively simple. |
| 18:57 | <timeless> | is it ok for me to change that page? |
| 18:57 | <timeless> | oh, i can't |
| 18:58 | <timeless> | can you? |
| 18:58 | <timeless> | > In our current CNAME approach we use three service names: |
| 18:58 | <timeless> | s/our current/our previous/; s/use/used/ |
| 18:59 | <AryehGregor> | I don't have a wikitech.wikimedia.org account. It's for sysadmins only, I think. |
| 19:00 | <AryehGregor> | I mean, I could get one if I was interested. |
| 19:00 | <timeless> | can you pass along a note? |
| 19:00 | <AryehGregor> | You can, in #wikimedia-tech. |
| 19:00 | <AryehGregor> | But the entire page was evidently written before deployment. |
| 19:00 | <AryehGregor> | Thus "current CNAME approach". |
| 19:00 | <timeless> | it seems rude for someone w/ no wikipedia affiliation to do it |
| 19:00 | <timeless> | it's mixed actually |
| 19:00 | <timeless> | > To support IP based virtual hosts, we created service CNAMEs on a per project basis. The -lb suffix means "load balancing". |
| 19:06 | <timeless> | AryehGregor: ok, i think that was a waste of breath |
| 19:07 | <timeless> | but thanks for the pointer, it's a reminder of why i don't go anywhere near that stuff |
| 19:07 | <AryehGregor> | timeless, well, they probably have better things to do than make the tense of a documentation page consistent. |
| 19:09 | <AryehGregor> | They're probably more interested in, e.g., reports of actual service problems. |
| 19:10 | <AryehGregor> | People who write standards might appreciate editorial feedback, but people who write transient project documentation pages, not so much. |
| 19:11 | timeless | sighs |
| 19:12 | <timeless> | wikimedia documentation exists partially so that others can use it as a guideline |
| 19:12 | <timeless> | if it's confusing, it hurts people who might try to do that |
| 20:42 | <ojan> | TabAtkins: i didn't realize collapse was != display:none. What's the use-case for only collapsing the block-progression direction? |
| 20:44 | <sicking> | annevk: for what it's worth, it *might* be tricky to make .responseText/.responseXML throw for .responseType != "" given that webkit has been shipping an unprefixed implementation for a while |
| 20:50 | <TabAtkins> | ojan: Ignore what that dude says. collapse is nothing of the sort. |
| 20:51 | <Hixie> | visibility:collapse has nothing to do with display:none, if that's what we're talking about. it's equivalent to visibility:hidden except in some cases involving table cells. |
| 20:51 | <TabAtkins> | Collapsing a table cell is just like display:none'ing it, except that it maintains the "hole" in the table. That's basic sensical stuff, though. There's no real analog to that for Flexbox. |
| 20:52 | <ojan> | TabAtkins: what's the use-cases for maintaining the "hole"? |
| 20:52 | <TabAtkins> | ojan: Not fucking up your columns? |
| 20:52 | <Hixie> | if a whole row or column is visibility:collapse, the whole row or column is removed |
| 20:53 | <Hixie> | otherwise, visibility:collapse is just like visibility:hidden (which is basically like opacity:0) |
| 20:53 | <ojan> | Hixie: i see |
| 20:53 | <ojan> | interesting |
| 20:53 | <ojan> | now that i understand all this...i need to rethink how visibility:collapse should interact w flexbox |
| 20:54 | <Hixie> | it's highly unlikely that you want it to do anything at all if display:none already handles your case |
| 20:55 | <ojan> | Hixie: the question is whether visiblity:collapse should be the new display:none for new display types |
| 20:55 | <Hixie> | yikes why would we do that |
| 20:55 | <ojan> | Hixie: that would let you use visiblity state to collapse things instad of toggling display |
| 20:55 | <Hixie> | why would you toggle display even |
| 20:55 | <ojan> | Hixie: it's kind of sucktastic that you need to toggle display to get something to collapse |
| 20:55 | <Hixie> | just use .hidden |
| 20:55 | <TabAtkins> | Hixie: display:none is a legacy mistake. |
| 20:56 | <ojan> | Hixie: .hidden? |
| 20:56 | <Hixie> | div.hidden = true; div.hidden = false; |
| 20:56 | <Hixie> | and in css, [hidden] { display: none; } /* or opacity:0 or whatever you want to hide the thing with */ |
| 20:56 | <ojan> | wait...wth. how have i never heard of this before. |
| 20:57 | <TabAtkins> | ojan: it's the global "hidden" attribute. |
| 20:57 | <ojan> | mind blown |
| 20:57 | <TabAtkins> | Heh. |
| 20:57 | <ojan> | Hixie: the case that doesn't work is if you're working from a pure JS library |
| 20:57 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/complete/editing.html#the-hidden-attribute |
| 20:58 | <Hixie> | "pure JS library"? |
| 20:58 | <Hixie> | [hidden] { display: none; } is in the UA stylesheet |
| 20:58 | <ojan> | Hixie: sorry...that was imprecise |
| 20:58 | <ojan> | Hixie: i mean things like jquery |
| 20:58 | <Hixie> | so it'll even work in a JS library that doesn't dare touch the DOM to add a stylesheet (but does to add inline style?) |
| 20:58 | <annevk> | sicking, we're locked down these days by one implementation? |
| 20:58 | <ojan> | Hixie: that don't have an associated stylesheet in the page |
| 20:58 | <annevk> | sicking, your argument was sort of compelling though |
| 20:58 | <ojan> | Hixie: yeah...i don't know why we don't use the hidden attribute |
| 20:59 | <ojan> | Hixie: I think js library authors might just not know about it? |
| 20:59 | <Hixie> | it's relatively new |
| 20:59 | <ojan> | ah |
| 20:59 | <sicking> | annevk: well.. if they refuse to change then it'll be hard to write the spec otherwise |
| 20:59 | <ojan> | TabAtkins: given the hidden attribute, does it make sense to propagate visiblity:collapse to other elements? |
| 20:59 | <sicking> | annevk: but if my argument convinced you then it's not a problem anyway :-) |
| 21:00 | <TabAtkins> | ojan: Maybe not. |
| 21:00 | <ojan> | TabAtkins: i'll think about this more and comment on thread |
| 21:00 | <TabAtkins> | ojan: cool. |
| 21:01 | <annevk> | sicking, might be hard to change encoding stuff too then |
| 21:02 | <sicking> | annevk: yeah, i was worrying about that |
| 21:02 | <zcorpan> | something being shipped doesn't mean there are compat constraints necessarily |
| 21:02 | <sicking> | annevk: i am curious what they were going to do once they do .responseType in worker-xhr though |
| 21:02 | <sicking> | annevk: unless they're going to spin up a DOM-less HTML parser |
| 21:02 | <Hixie> | ojan: it was introduced as "placeholder" in April 2007, quickly changed to "irrelevant" a few hours later, and became "hidden" in August 2008. |
| 21:03 | <Hixie> | ojan: been pretty stable since, and is now implemented in a few browsers. |
| 21:04 | <sicking> | Hixie: by the way, did you consider my proposal to allow pointing internal references to stuff inside @hidden elements? |
| 21:04 | <annevk> | sicking, I wonder if XHR should account for Workers in the specification |
| 21:04 | <annevk> | hmm |
| 21:04 | <annevk> | also, you already have that problem with XML |
| 21:05 | <sicking> | annevk: you mean for .responseType="" |
| 21:05 | <sicking> | ? |
| 21:05 | <sicking> | annevk: .responseXML always returns null or throws in workers. Don't recall which |
| 21:06 | <timeless> | abarth|gardener: hello |
| 21:06 | <zcorpan> | but responseText looks for an xml decl still? |
| 21:06 | <abarth|gardener> | timeless: hi |
| 21:06 | <timeless> | so... perhaps a small iteration round |
| 21:06 | <timeless> | >> If RDF-flag is 1 and RSS-flag is 1, then let the sniffed-type be "application/rss+xml" and abort these steps. |
| 21:06 | <nlogax> | i just noticed that chromium lets me nest anchors, and it works beautifully. bug or feature? |
| 21:06 | <abarth|gardener> | yessir |
| 21:06 | <sicking> | zcorpan: i think in our implementation it currently does, yeah. But that will change once we fix some architectural stuff |
| 21:07 | <timeless> | could you change that to: If both RDF-flag and RSS-flag are 1, then ...? |
| 21:07 | <abarth|gardener> | sure |
| 21:07 | <sicking> | zcorpan: right now worker-xhr runs on the main thread in gecko. Which severely affects performance |
| 21:07 | <sicking> | zcorpan: and implementation complexity |
| 21:07 | <timeless> | abarth|gardener: note that i have a tendency to read specs in text/plain |
| 21:07 | <timeless> | which can be why i might miss 'green' text :) |
| 21:07 | <AryehGregor> | nlogax, "nest anchors" how? |
| 21:08 | <AryehGregor> | nlogax, Chromium most likely follows the spec here. |
| 21:08 | <abarth|gardener> | timeless: done |
| 21:08 | <nlogax> | AryehGregor: var a = document.createElement("a"); var b = same...; a.appendChild(b); |
| 21:08 | <AryehGregor> | nlogax, yes, that will work in all browsers. |
| 21:08 | <nlogax> | AryehGregor: awesome :) |
| 21:08 | <AryehGregor> | Or should. |
| 21:08 | <AryehGregor> | .innerHTML will break, though. |
| 21:08 | <annevk> | sicking, responseText |
| 21:08 | <sicking> | annevk: ? |
| 21:08 | <timeless> | > >> Comparisons between media types, as defined by MIME specifications, are done in an ASCII case-insensitive manner. [RFC2046] |
| 21:09 | <AryehGregor> | It will serialize it to <a href=x><a href=y>foo</a></a>, which will become <a href=x></a><a href=y>foo</a><a></a> if you use it in actual markup. |
| 21:09 | <timeless> | so, the problem is that your `note` here is ambiguous |
| 21:09 | <annevk> | sicking, responseText uses XML |
| 21:09 | <AryehGregor> | The text/html syntax doesn't support nested anchors, but the DOM does. |
| 21:09 | <AryehGregor> | So beware. |
| 21:09 | <AryehGregor> | nlogax, ^^ |
| 21:09 | <timeless> | it's hard to understand that you're just saying `mime rfc says that mime comparisons are insensitive` |
| 21:09 | <timeless> | v. `this specification wants mime comparisons to be insensitive` |
| 21:09 | <sicking> | annevk: you mean when .responseType == ""? |
| 21:09 | <timeless> | you want the former |
| 21:09 | <timeless> | but `note:` doesn't cause that result |
| 21:09 | <annevk> | sicking, currently either "" or "text" |
| 21:10 | <timeless> | nor does the `[rfc....]` at the end |
| 21:10 | <timeless> | does that kinda make sense? |
| 21:10 | <sicking> | annevk: right, only when "" in my proposal |
| 21:10 | <sicking> | annevk: but yes, it's a problem |
| 21:10 | <timeless> | > I'm tempted to just rename them to be less semantic. They're just symbols that don't mean anything, really. |
| 21:10 | <timeless> | please do :) |
| 21:10 | <sicking> | annevk: i was actually thinking that we should make .responseType default to "text" for worker-xhr. But i'm not terribly excited by that idea |
| 21:10 | <timeless> | > That's a lot of editing! I'm not sure that buys us much. |
| 21:11 | <timeless> | i ask, because it actually was useful when i was dealing w/ someone else's spec |
| 21:11 | <nlogax> | AryehGregor: thanks, yeah i saw that behavior when just opening a regular ol' html document. it's very useful, wish it worked there as well.. :) |
| 21:11 | <timeless> | they had hex digits and some of them were wrong |
| 21:11 | <annevk> | sicking, in workers we could make "" and "text" the same |
| 21:11 | <timeless> | it was much easier to read when the hex digits were in <tt> |
| 21:11 | <sicking> | annevk: yeah, that'd work too |
| 21:11 | <AryehGregor> | nlogax, it can't, because of legacy pages that rely on current browser behavior. |
| 21:11 | <timeless> | > That is intentional. Sniffing SWF is bad times. |
| 21:11 | <annevk> | still not sure how much of the HTML parser we want to use |
| 21:12 | <nlogax> | AryehGregor: i see. oh well, can at least use it in this all-js thing. :) |
| 21:12 | <sicking> | annevk: when actually parsing into a DOM? |
| 21:12 | <annevk> | I guess what hsivonen suggested sounded okay |
| 21:12 | <AryehGregor> | nlogax, as long as you don't expect .innerHTML to work properly. |
| 21:12 | <timeless> | i think it might be worth an actual NOTE in the spec explaining that SWF is intentionally not sniffed, and what that means for untyped SWF files (actually explaining how it flows and to which resulting sniff type) |
| 21:12 | <AryehGregor> | nlogax, it's somewhat risky that way. You might be better off making sure they don't overlap. |
| 21:12 | <AryehGregor> | Otherwise you risk hitting confusing bugs far down the line when something tries using .innerHTML or similar features somewhere. |
| 21:13 | <zcorpan> | AryehGregor: iirc the html parser can end up with nested <a>s |
| 21:13 | <zcorpan> | AryehGregor: with foster parenting |
| 21:13 | <timeless> | > Thanks to Alfred HÎnes Boris Zbarsky David Singer Mark Pilgrim, and Russ Cox. |
| 21:14 | <AryehGregor> | zcorpan, or maybe if there's an intervening <button> or something. But not from plain <a><a>. |
| 21:14 | <nlogax> | AryehGregor: hmm yeah, i can't imagine why anyone would do that in this case, but you are right, less possible weirdness is good. but it's like it was made for this.. http://dl.dropbox.com/u/28029058/Screen%20Recording.mov |
| 21:14 | <timeless> | you need some punctuation before `Boris`, `David`, and `Mark` :) |
| 21:14 | <nlogax> | was going to add a big anchor somewhere and just position it on top of the other stuff and so on.. but tried thatand was surprised to see it work |
| 21:15 | <sicking> | annevk: i really don't know how much encoding stuff will be a problem in some locales |
| 21:15 | <sicking> | locals |
| 21:15 | <timeless> | abarth|gardener: ok, i think that's all the comments for today |
| 21:15 | <timeless> | i'll try to serialize that into an email for the record |
| 21:16 | <annevk> | it's a new feature |
| 21:16 | <abarth|gardener> | thanks. I appreciate all the comments |
| 21:16 | <annevk> | they'll adapt |
| 21:16 | <AryehGregor> | zcorpan, what's a case where it will work with foster parenting? |
| 21:16 | <sicking> | annevk: errr.. |
| 21:17 | <zcorpan> | AryehGregor: <a><table><a> |
| 21:17 | <annevk> | also, more than 50% of the web or so already is UTF-8 |
| 21:17 | <sicking> | annevk: do you have any idea how much they'll have to rewrite? |
| 21:17 | <zcorpan> | AryehGregor: button doesn't give nested a |
| 21:17 | <AryehGregor> | zcorpan, awesome. |
| 21:17 | <sicking> | annevk: 50% of the web is a lot of pages |
| 21:18 | <AryehGregor> | Are we talking about not supporting non-UTF-8 pages for new features? |
| 21:18 | <annevk> | I hope you don't believe the remaining 50% is untagged |
| 21:18 | <AryehGregor> | If so, I'm heartily in favor. |
| 21:18 | <AryehGregor> | Well, kind of. |
| 21:18 | <AryehGregor> | At least if it's a pain to support other encodings. |
| 21:18 | <timeless> | abarth|gardener: oh, i should be added to the list ;-) |
| 21:18 | <AryehGregor> | Maybe we can make UTF-8 the new XHTML: don't support any new features on sites using legacy encodings! |
| 21:19 | <AryehGregor> | It might work better than with XHTML, since UTF-8 actually is technically superior in every respect to the competitors for practically all sites . . . |
| 21:19 | <zcorpan> | hey, IE could add a new rendering mode that just accepts utf-8 |
| 21:20 | <reggna> | Been playing #BF3 Beta with my laptop mouse during the weekend; bought a G400 today though, so everything is back to normal. |
| 21:20 | <Hixie> | jgraham: 503 |
| 21:20 | <jamesr_> | yo standards monkeys and kibitzers |
| 21:20 | <AryehGregor> | zcorpan, I love how <a href=x><table><a href=y>foo</table> puts foo in a double link while leaving the actual table empty and invisible. |
| 21:20 | <jamesr_> | i want to read adobe's latest CSS proposal: https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html |
| 21:20 | <jamesr_> | but it throws mixed http/https warnings |
| 21:20 | <AryehGregor> | You could use that for parser hacks. |
| 21:20 | <AryehGregor> | jamesr_, use http://dvcs.w3.org instead? :) |
| 21:20 | <sicking> | annevk: I would be very sad if we did something that so deeply affects other locals without even checking with them what that'll mean |
| 21:20 | <jamesr_> | because dvcs.w3.org serves resources over https, but they only server css/js resources over http |
| 21:20 | <timeless> | s/server/serve/ |
| 21:20 | <annevk> | jamesr_, read http://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html instead? |
| 21:21 | <jamesr_> | AryehGregor, that works but why does it serve the https:// version at all? |
| 21:21 | <sicking> | annevk: It might mean that asian websites can't transition to use ajax as easily for example |
| 21:21 | <zcorpan> | AryehGregor: foster parenting is great for reordering content |
| 21:21 | <timeless> | jamesr_: it isn't wrong to support https |
| 21:21 | <jamesr_> | and all of the internal links are https:// |
| 21:21 | <AryehGregor> | jamesr_, all of w3.org seems to be set up to serve either http or https interchangeably. |
| 21:21 | <timeless> | the adobe content could be changed to use protocol relative paths... |
| 21:21 | <jamesr_> | right, but parts seem to be intentionally http only |
| 21:21 | <jamesr_> | it could |
| 21:21 | <AryehGregor> | jamesr_, you should tell the draft authors to use protocol-relative URLs for the mixed-content resources. |
| 21:21 | <annevk> | sicking, what? |
| 21:21 | <sicking> | annevk: saying "it's a new feature, they'll adapt" might mean that they have a serious disadvantage for the next 5-10 years |
| 21:22 | <jamesr_> | does everyone support protocol-relative URLs? |
| 21:22 | <annevk> | sicking, euhm... |
| 21:22 | <annevk> | sicking, XHR is pretty much UTF-8 only at the moment |
| 21:22 | <timeless> | jamesr_: wikipedia is using them |
| 21:22 | <jamesr_> | timeless, kk |
| 21:22 | <timeless> | so presumably anyone who matters does :) |
| 21:22 | <annevk> | if they haven't adapted by now, they've had a disadvantage for a decade now |
| 21:22 | <AryehGregor> | jamesr_, Wikipedia just started using them on all sites, so I hope so. |
| 21:22 | <annevk> | would be kind of odd |
| 21:22 | <AryehGregor> | https://en.wikipedia.org/ <-- look at source |
| 21:22 | <sicking> | annevk: but we haven't been reading HTML contents until now |
| 21:22 | <ojan> | Hixie: oh right. i remember irrelevant. lol. |
| 21:22 | <sicking> | annevk: there's a lot of HTML contents in non-UTF8 out there |
| 21:22 | <sicking> | annevk: 50% of a few trillion pages |
| 21:23 | <sicking> | iirc |
| 21:23 | <AryehGregor> | AFAIK, Wikipedia's testing found no clients at all that didn't support them. The only issues were things like "we don't want to output protocol-relative URLs to e-mail/print/feeds/..." |
| 21:23 | <annevk> | sure |
| 21:23 | <annevk> | but it's not all untagged |
| 21:23 | <AryehGregor> | So it required a bunch of work to get MW to work well with them. |
| 21:23 | <sicking> | annevk: gotta run |
| 21:23 | <AryehGregor> | jamesr_, alternatively, they could just unconditionally load the resources over HTTPS. It looks like just a stylesheet and an icon. |
| 21:23 | <zcorpan> | don't we have data on how much unlabeled non-utf-8 html content there is? |
| 21:24 | <annevk> | but if they are just going to read some HTML content... I'm not even sure how that stuff would work |
| 21:24 | <jamesr_> | AryehGregor, W3C doesn't serve these over https |
| 21:24 | <AryehGregor> | jamesr_, https://www.w3.org/StyleSheets/TR/W3C-ED.css https://www.w3.org/Icons/w3c_home |
| 21:24 | <AryehGregor> | WFM |
| 21:24 | <zcorpan> | we could make xhr inherit the page's encoding for text/html |
| 21:24 | <jamesr_> | ooh |
| 21:24 | <zcorpan> | if there's no decl |
| 21:24 | <jamesr_> | i ran into some resource on the rAF spec that the w3 wasn't serving over https |
| 21:25 | <zcorpan> | and in workers it'd use utf-8 since workers are utf-8 |
| 21:25 | <AryehGregor> | whatwg.org doesn't serve its stylesheets and things over HTTPS, so I can't make my spec work right now without mixed content. :( |
| 21:25 | <AryehGregor> | Otherwise I'd use HTTPS URLs too. |
| 21:25 | <zcorpan> | or maybe that'd be annoying when moving from <script> to worker |
| 21:26 | <zcorpan> | AryehGregor: just write a script that copies the stuff over to your server every once in a while |
| 21:27 | <annevk> | inheriting the encoding sounds like a terrible idea |
| 21:28 | <annevk> | that stuff is already annoying with <script>, especially when it comes to caching and such |
| 21:28 | <AryehGregor> | Hixie, can we have whatwg.org stuff on HTTPS too? I want https://www.whatwg.org/style/specification and https://www.whatwg.org/specs/web-apps/current-work/dfn.js so that https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html works without mixed content. Also, a pony. |
| 21:30 | AryehGregor | votes for using DNSSEC stapling instead of buying a cert |
| 21:33 | <zcorpan> | annevk: yeah |
| 21:37 | <timeless> | AryehGregor: the pony might be cheaper than dnssec |
| 21:37 | <timeless> | AryehGregor: can you offer the poney room and board? |
| 21:37 | <timeless> | i could probably help you w/ the getting part |
| 21:38 | <AryehGregor> | timeless, are registrars charging for DNSSEC on supported TLDs? You'd think it wouldn't really cost them anything extra. |
| 21:38 | <AryehGregor> | .org is signed. |
| 21:38 | <AryehGregor> | (.name is not :( ) |
| 21:38 | <timeless> | AryehGregor: how many browsers support dnssec? |
| 21:38 | <AryehGregor> | (nor is .il :( ) |
| 21:39 | <AryehGregor> | timeless, DNSSEC stapling in certs is supported by Chrome. Firefox is looking at it last I heard. The client doesn't need to actually support DNSSEC. |
| 21:39 | <timeless> | http://www.pir.org/get/registrars?order=field_dnssec_value&sort=desc |
| 21:39 | <AryehGregor> | It's clever: all it does is stick the signed DNS record where the cert should be. |
| 21:39 | <AryehGregor> | After all, with DNSSEC you know the record is correct no matter where it comes from, so there's no need for the client to actually query a DNSSEC server. |
| 21:41 | timeless | hasn't looked to see how many ways clients can screw up dnssec |
| 21:41 | timeless | is currently thinking about certain other technologies |
| 21:41 | <AryehGregor> | Answer: lots. |
| 21:41 | <AryehGregor> | Which is why it's great that the stapling solution doesn't require client DNSSEC support. |
| 21:41 | <timeless> | atm i'm more interested in how banks and credit card vendors can screw up deployments of things |
| 21:42 | <AryehGregor> | Answer: also lots of ways. |
| 21:43 | <timeless> | hrm |
| 21:43 | <timeless> | my office phone tells me someone rang my doorbell erev rosh hashanah |
| 21:43 | timeless | wonders why |
| 21:58 | <annevk> | AryehGregor, what's wrong with http? |
| 21:58 | <AryehGregor> | annevk, it's insecure. Someone might MITM our precious specs! |
| 21:59 | <jamesr_> | chrome's getting more aggressive about warning about mixed http/https content, since when it's not just a precious spec MITM attacks do matter |
| 22:00 | <annevk> | TR/ is pretty successful at man-in-the-middle'ing them and will do so even when they are served over TLS :p |
| 22:00 | <annevk> | alright, really nap time now |
| 22:06 | <TabAtkins> | Macroeconomic theory, as explained via the medium of rap: http://www.youtube.com/watch?v=GTQnarzmTOc |
| 22:09 | <hober> | TabAtkins: classic, though the first one was better |
| 22:21 | <danbeam> | add 0 stevet⊙gc |
| 22:21 | <danbeam> | d'oh, sorry guys |
| 22:43 | <Hixie> | sicking: i do not recall (re the hidden thing), probably still an open bug. i think the spec says no currently. |
| 22:48 | <sicking> | Hixie: ok, I don't think i ever filed a bug on the spec, Want me to open one? |
| 22:49 | <Hixie> | didn't you send mail about it or something? i seem to recall seeing it discussed but i don't think i've gotten to it yet |
| 23:01 | <Hixie> | jgraham: dude pms isn't working for me at all anymore |
| 23:02 | <TabAtkins> | Hixie: I'm surprised pms every worked for you, given your gender. |