| 07:31 | <MikeSmith> | hg clone http://hg.hoppipolla.co.uk/anolis/ |
| 07:31 | <MikeSmith> | "abort: error: nodename nor servname provided, or not known" |
| 07:31 | <MikeSmith> | jgraham: ↑ |
| 08:01 | <jgraham> | MikeSmith: Yeah, known problem. Incompetence on my part |
| 08:03 | jgraham | expects that ading the Array.prototype methods to HTMLCollection.prototype will break stuff |
| 08:04 | <MikeSmith> | jgraham: OK |
| 08:04 | <jgraham> | MikeSmith: (but ms2ger has a version on bitbucket) |
| 08:05 | <jgraham> | (which you could clone instead) |
| 08:05 | <MikeSmith> | jgraham: good to know |
| 08:05 | <MikeSmith> | I have my local workspace copy too |
| 08:05 | <MikeSmith> | so I'm fine for now |
| 08:05 | <jgraham> | All hail the power of DVCS |
| 08:05 | <paul_irish> | Very similar to resig's nodelist proposal, no? as it says htmlcollection inherits from nodelist which gets the extras. |
| 08:07 | <jgraham> | paul_irish: Sounds similar. My suspicion it will break stuff is informed in part by the attempt to do the same thing to the arguments object in ES5, since it is also *clearly* Array-like |
| 08:07 | <jgraham> | It was backed out when it broke sites |
| 08:07 | <paul_irish> | gotcha. |
| 08:32 | <Ms2ger`> | Btw, MikeSmith, my repository also contains your patch ;) |
| 08:37 | <JonathanNeal> | Anyone still check this out? file:///W:/iecss.com/whatwg.css |
| 08:37 | <JonathanNeal> | oooops |
| 08:37 | <JonathanNeal> | http://www.iecss.com/whatwg.css |
| 08:45 | <zcorpan> | hmm, what does this mean <style scoped>@font-face { ... |
| 08:45 | <zcorpan> | i assume that the font becomes available for the whole document |
| 08:53 | <annevk> | hmm @-rules are scoping |
| 08:53 | <annevk> | e.g. @namespace is |
| 08:53 | <annevk> | page-global would be quite bad I think |
| 08:53 | <zcorpan> | @font-face affects the whole document |
| 08:54 | <zcorpan> | in that the font becomes available for the whole document |
| 08:54 | <annevk> | hmm, shows what I know |
| 08:54 | <annevk> | I guess things with identifiers don't "fail" if the style sheet fails |
| 08:55 | <annevk> | whereas namespace identifiers would fail parsing |
| 08:56 | <zcorpan> | would @page work in <style scoped>? |
| 09:10 | <zcorpan> | hmm, seems tr:before{content:'x'} and tbody:before{content:'x'} don't work in webkit |
| 09:25 | <zcorpan> | filed https://bugs.webkit.org/show_bug.cgi?id=48404 |
| 09:45 | <annevk> | lolhttp://landoflisp.com/ |
| 09:45 | <annevk> | http://landoflisp.com/ |
| 09:45 | <annevk> | almost wanna start learning Lisp now |
| 09:48 | mhausenblas | finds himself not often in agreement with annevk, but +1 to Land of Lisp ;) |
| 09:50 | <annevk> | you should speak up when you don't then ;) |
| 09:54 | jgraham | wonders if there is any actual evidence that Lisp code is more bug free than other code that does the same stuff |
| 09:57 | <annevk> | jgraham, did you read the comic? they have space ships |
| 09:57 | <annevk> | jgraham, and some wicked guy with a nose which is also a hand in charge |
| 11:51 | <annevk> | euhm, oops http://www.w3.org/TR/html5/comms.html#dom-messageevent-source ? |
| 11:51 | <annevk> | that page should not be there |
| 12:20 | <hsivonen> | jgraham: have you upgraded to Maverick? Did it solve the event delivery / scheduling jumpiness when running an intensive process like building a browser? |
| 12:37 | <jgraham> | hsivonen: No, I haven't upgraded |
| 12:54 | <hsivonen> | jgraham: ok. |
| 12:54 | <hsivonen> | fwiw, right now, when building Firefox, Spotify sounds like an old-school needle-based broken record player |
| 12:57 | <annevk> | heh, Minefield about:home is XHTML with a bunch of entities |
| 12:57 | <annevk> | not the greatest view source example |
| 12:58 | <zcorpan> | most moz about: pages are like that |
| 12:58 | <hsivonen> | annevk: the Firefox approach to XML localization is a problem when it comes to killing DTDs :-( |
| 13:16 | <hsivonen> | jgraham: do you happen to have an SSD in your Ubuntu machine? |
| 13:18 | <jgraham> | hsivonen: No, sadly |
| 13:18 | <hsivonen> | jgraham: ok. |
| 13:18 | <jgraham> | (possibly my problems are not as bad as yours? But I do notice bad responsiveness under load) |
| 13:19 | <hsivonen> | I wonder why we're seeing a problem but there's no general outcry waking up Canonical |
| 13:19 | <hsivonen> | I guess I'll send some logs to Canonical's support in case they are able to make sense of them |
| 13:19 | <hsivonen> | I don't know how to infer anything actionable from the logs |
| 14:10 | <karlcow> | http://www.impressivewebs.com/cross-browser-css-properties/ |
| 14:10 | <karlcow> | "I decided to put together a comprehensive list of CSS properties that are supported in all browsers." |
| 14:11 | <annevk> | hmm |
| 14:11 | <annevk> | font-family is buggy in Opera |
| 14:11 | <annevk> | and list-style-position has a sheer of problems when combined with floats |
| 14:11 | <annevk> | iirc |
| 14:29 | <jgraham> | "No Bugs" as a claim says "I'm not a QA" |
| 14:29 | <jgraham> | At least for somthing as complex as this |
| 14:31 | <hsivonen> | jgraham: also "I'm not a browser developer" |
| 14:31 | <jgraham> | hsivonen: Yeah I think most browser developers aren't naive enough to claim that their code is bug free :) |
| 14:32 | <hsivonen> | jgraham: recently, when I've been fixing regressions I introduced when I made Gecko's script execution (mostly) HTML5-compliant, I've found even more legacy brokenness when I've looked at code relevent to my regressions |
| 14:33 | <hsivonen> | I *think* if you use XSLTProcessor to parse a fragment in the content of a document that's itself being parsed, the readyState of the document changes prematurely |
| 14:33 | <hsivonen> | that sort of thing |
| 14:33 | <hsivonen> | (by code inspection, I didn't test this particular thing) |
| 14:33 | <zcorpan> | in the Land of Lisp there are no bugs |
| 14:34 | <hsivonen> | s/content/context/ |
| 14:35 | <jgraham> | Yeah, obviously web browsers should have been written in Lisp so The Power Of Macros (TM) could save us all from wrong logic |
| 14:37 | Lachy | read that as "The Power of *Marcos*" and laughed. Then realised it said Macros. |
| 14:38 | <Philip`> | jgraham: That's why browser engines written in languages other than C/C++ have all been so successful |
| 14:38 | <hsivonen> | aside: the level of XSLT integration to the rest of the Open Web Platform is rather sad |
| 14:39 | <hsivonen> | non-Gecko browsers do it the ugly way |
| 14:39 | <jgraham> | hsivonen: In what way? |
| 14:39 | <hsivonen> | and Gecko does the nice thing in an approximate way |
| 14:40 | <jgraham> | Maybe no one was really feeling XSLT? |
| 14:40 | <hsivonen> | jgraham: in non-Gecko browsers <?xml-stylesheet?> produces a stream that gets reparsed |
| 14:40 | <hsivonen> | that's sad considering that it's a tree-to-tree tranformation system |
| 14:41 | <hsivonen> | jgraham: then Gecko does the tree-to-tree thing but has all sorts of approximate hacks for being compatible *enough* with the stream-based way |
| 14:41 | <jgraham> | I wonder if the stream-based way is much faster |
| 14:41 | <jgraham> | Anyway, the solution is probably not to use XSLT |
| 14:42 | <jgraham> | It would be nice if we cou nudge it off the edge of the open-web-platform |
| 14:42 | <jgraham> | *could |
| 14:43 | <hsivonen> | for example, compat requires scripts to execute in order, but Gecko can't suspend the XSLT engine in mid-transform, so you can't just use the parser-blocking script mechanism as is |
| 14:43 | <hsivonen> | instead, there's something else |
| 14:43 | <hsivonen> | and a hope that the script authors don't really rely on being able to see more future DOM than they should |
| 14:44 | <hsivonen> | part of the problem is that Hixie doesn't seem to be considering XSLT actively when writing the spec |
| 14:44 | <hsivonen> | so if I read the spec and write code, some time later someone tells me I broke XSLT again |
| 14:45 | <hsivonen> | which also means we don't have enough automated test coverage for XSLT integration with the rest of the platform |
| 14:45 | <hsivonen> | jgraham: shouldn't one expect the stream-based way to be *slower*? |
| 14:46 | <jgraham> | hsivonen: Well it isn't really clear. I suppose it depends what you can optimise in the two cases |
| 14:47 | <hsivonen> | by stream-based, I mean the XSLT engine serializes its output tree and the HTML parser parses the stream into a DOM |
| 14:47 | <hsivonen> | instead of the XSLT engine building an output DOM directly |
| 14:49 | <jgraham> | Right, but doing dom manipulations could be expensive compared to just parsing, whereas you could use something more lightweight than DOM within the XSLT engine itself. I'm not sure. |
| 14:54 | <hsivonen> | jgraham: well, the parser has to be able to build a DOM, too |
| 14:55 | <hsivonen> | though in Gecko, the parsers use notify layout in batches but the XSLT engine notifies on a per-node basis |
| 14:55 | <Philip`> | Perhap serialising+parsing is likely to be much more heavily optimised than XSLT-specific DOM construction code, since it's reusing code that the rest of the browser already wants to be fast, whereas nobody's going to spend much time optimising XSLT since it's so rarely used |
| 15:05 | Xano_ | leaves his shoes and sense of logic at the door, and calmly walks in |
| 15:05 | <Xano_> | adactio: Just read your book this morning. Nice writing style, but I only have more questions :P |
| 15:05 | <jgraham> | I would put your shoes back on if I were you |
| 15:06 | <Xano_> | jgraham: It's that dirty in here? |
| 15:06 | <Xano_> | oh my |
| 15:06 | <jgraham> | Some of the things on the carpet you don't want to step in |
| 15:06 | <adactio> | Xano_: Well, it's good that you have questions. The people here will be able to help you, shoes or no shoes. |
| 15:06 | <Xano_> | hehe |
| 15:07 | <Xano_> | I was wondering why there is still such a distinct separation in functionality between textareas and text inputs. |
| 15:07 | <AryehGregor> | No shoes, no shirt, no service! |
| 15:07 | <Xano_> | AryehGregor: Got a shirt and a tie! :D |
| 15:07 | <annevk> | majority of failed requests on my site are apparently /apple-touch-icon.png and /apple-touch-icon-precomposed.png -- way to go Apple |
| 15:07 | <AryehGregor> | Xano_, because that's how it was designed by whoever made up text inputs and textareas, and we can't change it now? |
| 15:08 | <AryehGregor> | Note: the above is the correct answer to most "why" questions about the web. |
| 15:08 | <Xano_> | hehe, I figured |
| 15:08 | <Xano_> | Well, textareas could've been removed, but recalling the dozens of "paving the cowpaths" quotes from a certain book about HTML5 doesn't make that option very appealing |
| 15:09 | <Xano_> | What *does* strike me as odd is that there (afaics) has been no effort to make the two elements behave more similarly, which could've been done without losing backwards compatibility |
| 15:09 | <annevk> | align them more in what way? |
| 15:09 | <annevk> | API-wise they are pretty similar actually |
| 15:10 | <annevk> | <textarea> even has .type |
| 15:10 | <Xano_> | As as I have been able to find there is no datalist for textareas, no maxlength and size for text inputs and cols for textareas behave similarly, yet are two different attributes |
| 15:11 | <adactio> | Actually, on the subject of textareas, I came across an interesting browser support issue today: it seems that Mobile Safari doesn't currently support the placeholder attribute on textarea (although the desktop version does). |
| 15:13 | <Xano_> | Wait, there is size for text inputs |
| 15:13 | <AryehGregor> | Xano_, maxlength works on text inputs and textareas. |
| 15:13 | <Xano_> | Why did I write that? |
| 15:13 | <AryehGregor> | And size also. |
| 15:13 | <AryehGregor> | Actually, maxlength on textareas is an HTML5 innovation, brings it closer to input. |
| 15:13 | <AryehGregor> | (I implemented it for Firefox, yay) |
| 15:13 | <AryehGregor> | (It was like five lines) |
| 15:13 | <Xano_> | There is? Nice! |
| 15:13 | <annevk> | adactio, <textarea placeholder> is a pretty recent addition |
| 17:25 | hsivonen | finds https://twitter.com/#!/HTML_longdesc |
| 17:28 | Philip` | curses his inability to double-click on such URLs to select them |
| 17:28 | <Philip`> | (The selection stops before the "!") |
| 17:34 | <jgraham> | You know, there is probably something more tragic than pretending to be an unused HTML attribute on twitter but I can't think of it now |
| 17:35 | <annevk> | using it |
| 17:36 | <annevk> | *zing* |
| 18:11 | <JonathanNeal> | Have any changes occured to the presentational requirements and recommendations in the last month or so? |
| 18:11 | <JonathanNeal> | I'm making sure http://www.iecss.com/whatwg.css is up to date. |
| 18:12 | <annevk> | misses <s>? |
| 18:23 | <JonathanNeal> | annevk, I think you're right, I did miss it. Is it missing from http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-css-user-agent-style-sheet-and-presentational-hints too ? |
| 18:25 | <JonathanNeal> | I've added it in, since <s> is in the cut @ http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-s-element |
| 18:27 | <JonathanNeal> | nope, it's there in presentational hints: del, s, strike |
| 18:27 | <JonathanNeal> | huh |
| 18:29 | <JonathanNeal> | annevk, was <s> cut at one point? http://en.wikipedia.org/wiki/HTML5#Differences_from_HTML_4.01_and_XHTML_1.x "Deprecated elements will be dropped altogether: acronym, applet, basefont, big, center, dir, font, frame, frameset, isindex, noframes, s, strike, tt, u" |
| 18:30 | <JonathanNeal> | And I think they got that from http://dev.w3.org/html5/html4-differences/#absent-elements |
| 18:37 | <AryehGregor> | JonathanNeal, yes, it was only just re-added. |
| 18:37 | <JonathanNeal> | Thanks AryehGregor, were any other elements added / removed? |
| 18:39 | <AryehGregor> | karlcow, someone ran a script on Wikipedia once that concluded // URLs work well in practice. It tried loading something via // URL and via normal URL and counted the differences in hit rate, it wasn't much. Wikimedia has been meaning to use it for its sites when it finally gets HTTPS working on the same domains as HTTP, since its server infrastructure caches page text very heavily and we don't want to cache separate copies for http and htt |
| 18:39 | <AryehGregor> | ps. |
| 18:39 | <AryehGregor> | Specifically, we would want to use src="//upload.wikimedia.org/..."; for files. For regular old links we already use relative URLs anyway. |
| 18:40 | <kennyluck> | Huh? <s> is out again? |
| 18:40 | <AryehGregor> | (of course, https://upload.wikimedia.org doesn't work at all and there are in fact no secure ways to get files, so even if you use https://secure.wikimedia.org/ anyone could still cross-check all your image requests against the articles containing those images and they'll know what you're viewing, unless you disable images, but they won't get your cookies, since no cookies are set on upload.wikimedia.org) |
| 18:41 | <AryehGregor> | (but this is something that ideally we should fix) |
| 18:41 | <AryehGregor> | kennyluck, no, it's recently back in. |
| 18:41 | <AryehGregor> | JonathanNeal, the HTML 4 differences spec should have an accurate list, possibly modulo very recent changes like <s> being re-added. |
| 18:41 | <JonathanNeal> | thanks |
| 18:42 | <kennyluck> | OK I found it. Yeah, I know it was back recently but since someone asks, I thought it is out again. |
| 18:42 | <annevk> | html5-diff on TR/ is actually more up to date for a change |
| 18:42 | <annevk> | because I haven't bothered committing a local fix |
| 18:48 | <karlcow> | AryehGregor: thanks. |
| 18:49 | <karlcow> | thing which bothers me with "//" is that I remember Tim telling me about it a few years ago, but I didn't remember last year when we had a performance issues for a client due to users having to switch http-https contexts |
| 19:22 | <Darxus> | Where does it say that an SVG object should, by default, be scaled up to the maximum size that fits in its container? Chrome seems to not be doing this. |
| 19:39 | <AryehGregor> | Darxus, it doesn't say that anywhere. |
| 19:39 | <AryehGregor> | If it has an intrinsic size, it should be displayed like that. If not, there's some default, like 300x150 px or something IIRC. |
| 19:40 | <AryehGregor> | Do you have a specific test case that different browsers display differently? |
| 19:51 | <Darxus> | AryehGregor: Yes, the graphs on this page: http://www.chaosreigns.com/dnswl/ |
| 19:52 | <Darxus> | Firefox displays them the full width of the page, as I want. Chrome displays them tiny. |
| 19:53 | <AryehGregor> | I'm not an expert on this, but it looks to me that Chrome is right. |
| 19:53 | <AryehGregor> | 300x150 since there's no size specified. |
| 19:53 | <AryehGregor> | I don't know what's wrong with Firefox. |
| 19:54 | <AryehGregor> | Setting width:100% doesn't seem to make Chrome actually do that, though. |
| 19:54 | <AryehGregor> | So it seems to be buggy too. |
| 19:54 | <AryehGregor> | Not totally sure here. |
| 19:55 | <AryehGregor> | Chrome only displays it right if you give explicit height and width, it looks like. |
| 19:55 | <AryehGregor> | Dunno why. Does it not have an intrinsic aspect ratio either? |
| 19:55 | <karlcow> | Darxus: what do you use to call the SVG? object element or something else. |
| 19:56 | <AryehGregor> | Chrome seems very buggy. |
| 19:56 | <AryehGregor> | karlcow, object in this case, see link. |
| 19:56 | <AryehGregor> | In fact, Chrome just gave me a sad tab. |
| 19:56 | <Darxus> | karlcow: Currently object. |
| 19:57 | <Adawerk```> | try giving the svg a fixed h/w |
| 19:57 | <karlcow> | I have not checked what html5 was saying about object. HTML4/XHTML 1.0 was not always clear http://www.w3.org/QA/2004/02/object/object-test-case |
| 19:58 | <AryehGregor> | This is handled by CSS. |
| 19:58 | <Darxus> | The .svg file starts with '<svg viewBox="0 0 1024 768"', so there is an aspect ratio defined. |
| 19:59 | <Darxus> | Oh that's interesting. I just specified 'width="800"' and then Chrome moved the location of the image, keeping it small, and then crashed. |
| 19:59 | <karlcow> | yoohoo |
| 19:59 | <Darxus> | I.. expected that to work. |
| 20:00 | <Darxus> | I think it centered the thumbnail in the 800 pixel width. |
| 20:00 | <AryehGregor> | Yeah, Chrome is crazy here. |
| 20:00 | <AryehGregor> | Dunno what it's smoking. |
| 20:00 | <Darxus> | Heh. |
| 20:00 | <Darxus> | So... I don't even know what the appropriate behavior is to report a bug... |
| 20:00 | <Darxus> | What way(s) should I be able to tell chrome to make the .svg the width of its container? |
| 20:01 | <Darxus> | I also tried specifying a width of 100% as a css property of object. |
| 20:02 | <Darxus> | It looks like nothing supports specifying an objects width as a percentage as an attribute of the entity? |
| 20:02 | <Adawerk```> | do you have firebug installed ? |
| 20:03 | <karlcow> | http://dev.w3.org/html5/spec/the-iframe-element.html#the-object-element |
| 20:03 | <Darxus> | Adawerk```: No. |
| 20:03 | <AryehGregor> | <object style="width: 100%"> should work correctly AFAIK, but seems not to in Chrome. |
| 20:04 | <Darxus> | Thanks. |
| 20:05 | <AryehGregor> | Have you tried using <img>? |
| 20:05 | <karlcow> | >The two attributes must be omitted if the resource in question does not have both an intrinsic width and an intrinsic height. -- http://dev.w3.org/html5/spec/the-map-element.html#attr-dim-width |
| 20:05 | <AryehGregor> | That won't work in Firefox < 4, though. |
| 20:05 | <Darxus> | AryehGregor: Yes, one of them (firefox?) won't load a .svg as an <img>. |
| 20:05 | <AryehGregor> | Only Firefox, and only < 4. |
| 20:05 | <AryehGregor> | (plus ancient versions of other browsers, I guess) |
| 20:05 | <karlcow> | it doesn't make sense. Or I'm not parsing the sentence correctly |
| 20:05 | <AryehGregor> | karlcow, what's wrong with it? |
| 20:06 | <Darxus> | Firefox < 4 is the version in the only release of Ubuntu that has been out more than a few weeks. Seems worth supporting. |
| 20:06 | <AryehGregor> | "If 'height' and 'width' both have computed values of 'auto' and the element has an intrinsic ratio but no intrinsic height or width and the containing block's width does not itself depend on the replaced element's width, then the used value of 'width' is calculated from the constraint equation used for block-level, non-replaced elements in normal flow." http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width |
| 20:06 | <AryehGregor> | Hmm, what does that mean? |
| 20:06 | <AryehGregor> | Maybe Firefox is right. |
| 20:06 | <AryehGregor> | Darxus, yeah, Firefox 4 is still beta. |
| 20:07 | <karlcow> | width and height must be omitted if the resource itself doesn't size values… then there is no value defined anywhere. I must be missing something |
| 20:07 | <AryehGregor> | karlcow, correct, then there's no value defined anywhere. |
| 20:07 | <karlcow> | s/size/have size/ |
| 20:07 | <AryehGregor> | width and height in HTML are only hints so that the UA knows the size before it loads the resource. |
| 20:07 | <Darxus> | Well, it's nice to know .svg will be supported as an <img> soon. |
| 20:07 | <AryehGregor> | http://www.w3.org/TR/CSS21/visudet.html#blockwidth |
| 20:07 | <AryehGregor> | Okay, it looks like Firefox is correct here. |
| 20:07 | <AryehGregor> | I should have guessed. :P |
| 20:07 | <AryehGregor> | I think. |
| 20:08 | <AryehGregor> | It looks like with an explicit ratio but no explicit height/width, it should just fill the width of the containing block. |
| 20:08 | <AryehGregor> | Hmm. |
| 20:08 | <AryehGregor> | Not sure about "the containing block's width does not itself depend on the replaced element's width". |
| 20:09 | <AryehGregor> | I guess it doesn't in this case. |
| 20:09 | <AryehGregor> | Anyway, Chrome is obviously braindead here, either way. |
| 20:09 | <karlcow> | AryehGregor: but in the case of SVG would not that be precisely helpful to rely on width and height in the markup if there is no intrinsic size (defined). |
| 20:09 | <Darxus> | Any of you more familiar with the details than me want to file the bug? |
| 20:09 | <AryehGregor> | karlcow, no, you should use CSS then. |
| 20:09 | <karlcow> | hmmm… |
| 20:10 | <AryehGregor> | Darxus, I think you can file bugs against Chrome pointing out their obviously crazy behavior for <object style="width:100%">, and pointing out the crash. |
| 20:10 | <AryehGregor> | Although probably both are actually WebKit bugs. |
| 20:10 | <Darxus> | AryehGregor: Sure, and I will if you guys don't, I'm just thinking one of you might manage a more useful report. |
| 20:11 | <karlcow> | I guess if people can tweak width and height then the CMS will not remove the style attribute. |
| 20:11 | <AryehGregor> | CMS? |
| 20:12 | <karlcow> | AryehGregor: I imagine a case where people use CMS to edit content and having sanitization filters in place. |
| 20:13 | <AryehGregor> | What does that have to do with what we were talking about? |
| 20:13 | <AryehGregor> | Oh, a CMS that allows width/height but not style? |
| 20:13 | <AryehGregor> | Possible, yeah. |
| 20:13 | <karlcow> | trying to find out if there would be case where people could only edit width and height attribute on the markup and no access to the style attribute. But that seems to be unlikely |
| 21:06 | <annevk> | http://blog.reddit.com/2010/10/everything-you-need-to-know-about.html fun |
| 22:01 | <hober> | http://lists.w3.org/Archives/Public/public-html-diffs/2010Oct/0158.html |
| 22:10 | <annevk> | euh edit wars? |
| 22:11 | <annevk> | what a circus |
| 22:12 | <Philip`> | "This is an out-of-date editor's draft. Please see [an outdated working draft]." |
| 22:13 | <annevk> | very meta |
| 22:14 | <Philip`> | (and that working draft is at least 4 months older than any editor's draft which that warning will appear in) |
| 22:16 | <annevk> | oh hahaha |
| 22:16 | <annevk> | he updated to point to the one before we just published |
| 22:17 | <Dashiva> | "This is a processed version of the source. It is most certainly out of date. Please learn to parse the source in your head and read that instead." |
| 22:17 | <annevk> | clearly it is time to make a SERIOUS PROTEST |
| 22:19 | <annevk> | OFFICIAL PROTEST, even |
| 22:19 | <Darxus> | width:100% should scale height proportionally, right? |
| 22:27 | <Darxus> | This is the bug I submitted about chrome's failure to handle <object style="width:100%">: https://bugs.webkit.org/show_bug.cgi?id=48466 |
| 22:32 | <jamesr_> | webkit doesn't handle percentage width/height on replaced elements in all cases currently |
| 22:35 | <Darxus> | Replaced elements? |
| 22:49 | <jamesr_> | http://www.w3.org/TR/CSS21/conform.html ctrl-f for 'replaced element' |
| 23:10 | <shepazu> | Darxus, karlcow, do you think it would be useful for SVG 2 to have an 'autoscaling' attribute on the root that will indicate that @width and @height determine the aspect ratio, but that the image will fill the available viewport (rather than using @viewBox)? |
| 23:17 | <heycam> | shepazu, would that be any different from <svg width="100%" height="100%" viewBox="0 0 w h">? |
| 23:20 | <shepazu> | heycam: effectively, it would be the same, but I've heard a lot of feedback that that is unintuitive to many people... they like @width and @height to be the intrinsic dimensions, rather than 100% |
| 23:21 | <heycam> | i see |
| 23:22 | <shepazu> | heycam: so, it would be <svg width="600" height="400" autoscale="scale"> or something |
| 23:22 | <shepazu> | @scale="auto | none", maybe |
| 23:22 | <shepazu> | I don't care much what the syntax would be |
| 23:24 | <shepazu> | I think that would make the dimension negotiation easier |
| 23:25 | <shepazu> | AryehGregor: what do you think of this idea ^^ ? |
| 23:27 | <heycam> | shepazu, easier for the author? might do. |
| 23:45 | <Philip`> | http://dev.w3.org/cvsweb/html5/spec/spec.html#rev1.1318 - ah, so now the process arguments expand into the CVS log |
| 23:47 | othermaciej | hates process arguments |
| 23:51 | <Philip`> | It becomes both hard to follow and hard to avoid when discussions get spread across public-html, Bugzilla, IRC, Twitter, and CVS |
| 23:51 | <Philip`> | Someone needs to find a way to make communication in the modern world much easier :-( |
| 23:51 | <shepazu> | othermaciej: you should write up a document that dictates how to manage process arguments |
| 23:51 | <othermaciej> | but then we'd need to get approval on that document |
| 23:52 | <shepazu> | then we could argue about that instead |
| 23:52 | <shepazu> | othermaciej: everything is solved by adding another level of abstraction :P |
| 23:52 | <othermaciej> | I think that might exceed my meta limit |
| 23:53 | <shepazu> | Philip`: wasn't that what Wave was about? |
| 23:53 | shepazu | still likes the idea of Wave |
| 23:53 | <Philip`> | Someone needs to find a way to make communication in the modern world much easier without having weirdo scrollbars |
| 23:54 | <shepazu> | Philip`: yeah, I think the fatal flaw was that it was too closely yoked to that single implementation |
| 23:54 | <shepazu> | but I really like distributed federated info streams |
| 23:54 | shepazu | isn't sure that he actually just said anything |
| 23:55 | <shepazu> | leverage the optimization of the ROI on Ajax and HTML5 |