| 01:03 | <Hixie> | sweet mother of kittens |
| 01:03 | <Hixie> | i sure hope zcorpan and hsivonen are sure about this |
| 02:22 | <meoblast001> | HTML5 here? |
| 02:25 | <Hixie> | yep |
| 02:25 | <Hixie> | right here on the mantelpiece |
| 02:25 | <Hixie> | above our roaring fire |
| 02:25 | <Hixie> | do you like the frame? |
| 02:26 | Hixie | goes off to dinner |
| 02:28 | <meoblast001> | how do you loop audio |
| 02:28 | <meoblast001> | playcount won't do it |
| 02:28 | <meoblast001> | i have Firefox |
| 02:28 | <meoblast001> | for GNU/Linux |
| 02:32 | <MikeSmith> | meoblast001: loop attribute? |
| 02:32 | <meoblast001> | there's one of those? |
| 02:32 | <meoblast001> | i only saw playcount |
| 02:33 | <MikeSmith> | meoblast001: I think playcount was removed from the spec long ago |
| 02:33 | <meoblast001> | loop is not doing anything |
| 02:34 | <kinetik> | the loop attribute isn't implemented in firefox yet (bug 449157) |
| 02:34 | <meoblast001> | wtf :/ |
| 02:34 | <kinetik> | you can get roughly the same behaviour by calling play() when the ended event fires |
| 02:35 | <kinetik> | in script |
| 03:04 | <AryehGregor> | Hixie, you didn't think it was reasonable for a standard to permit something like X-UA-Compatible where there wouldn't be multiple interoperable implementations in practice. But isn't <object> a lot like that? An HTML page including Flash via <object> is valid HTML, right? |
| 03:31 | <meoblast001> | kinetik: how do you "play()"? |
| 03:32 | <meoblast001> | javascript? |
| 03:32 | <kinetik> | yes, call play() on the element in script |
| 03:33 | <meoblast001> | kinetik: document.getElementById('object').play();? |
| 03:33 | <meoblast001> | and the event is onabort? |
| 03:34 | <kinetik> | the event is 'ended' |
| 03:35 | <meoblast001> | kinetik: onended? |
| 03:35 | <roc> | you can just write <video ... onended="event.target.play()"> |
| 06:12 | <zcorpan_> | "script data double escaped dash dash state" |
| 06:14 | <zcorpan_> | could we rename it to script data double escaped double dash state? :) |
| 06:29 | <zcorpan_> | script data states outnumber the doctype states |
| 06:35 | <zcorpan_> | does the abnf allow things like <!--<!--<script><script></script>-->? |
| 06:36 | <Hixie> | i hope so |
| 06:36 | <Hixie> | shouldn't it? |
| 06:36 | <Hixie> | jgraham: dude, pms is being really slow |
| 06:36 | <zcorpan_> | yeah it should |
| 06:37 | <zcorpan_> | on a first pass reading, the spec looks good |
| 06:37 | <Hixie> | cool |
| 06:38 | <zcorpan_> | maybe there should be some more cases that should trigger a parse error, though i didn't think about that while reading |
| 06:39 | <Hixie> | i think we don't need any parse errors, given the script abnf nonsense |
| 06:39 | <zcorpan_> | ah, the abnf applies to conformance checkers? |
| 06:40 | <Hixie> | it's intended to |
| 06:40 | <Hixie> | if i missed the "must", let me know |
| 06:41 | <zcorpan_> | i thought it was in the syntax section at first. just read the diff with not enough context :) |
| 06:47 | <MikeSmith> | tyoshino: you around? |
| 06:48 | <zcorpan_> | sicking: i've filed a bug on removing tags() in opera |
| 06:48 | <MikeSmith> | ukai: ping |
| 06:48 | <sicking> | zcorpan_: yay, sweet! |
| 06:52 | <tyoshino> | hi |
| 06:52 | <tyoshino> | MIkeSmith: hi |
| 06:56 | <ukai> | MikeSmith: hi |
| 07:12 | <sirdarckcat> | hey! one question |
| 07:12 | <sirdarckcat> | <script src="something.js"></script><link href="something.css" rel="stylesheet" type="text/css"> |
| 07:13 | <sirdarckcat> | should the browser start the request to something.css before executing the JS of something.js? |
| 07:13 | <sirdarckcat> | since something.js may have document.write("<plaintext>") or whatever |
| 07:14 | <hsivonen> | annevk: no, I didn't get around to filing a bug about <base>. I'll file one now. |
| 07:15 | <hsivonen> | annevk: I see you filed one already. Thanks |
| 07:16 | <hsivonen> | sirdarckcat: Gecko will start requesting the style sheet but may not end up applying it |
| 07:16 | <sirdarckcat> | :( |
| 07:16 | <sirdarckcat> | also IE |
| 07:17 | <sirdarckcat> | and chrome |
| 07:17 | <sirdarckcat> | opera and safari wont |
| 07:17 | <hsivonen> | sirdarckcat: however, you should not rely on script-set cookies to take effect for requesting later resources on the same page |
| 07:17 | <hsivonen> | sirdarckcat: why :-( ? It's an awesome optimization. |
| 07:18 | <hsivonen> | I'm surprised if Safari doesn't prefetch, too, in that case |
| 07:19 | <sirdarckcat> | because I was relying that was not going to happen |
| 07:19 | <sirdarckcat> | there are several reasons but |
| 07:19 | <hsivonen> | it would also be odd if Opera didn't start prefetching in order to be competitive perf-wise |
| 07:20 | <sirdarckcat> | but how the browser knows? |
| 07:20 | <sirdarckcat> | what if the script makes a |
| 07:20 | <sirdarckcat> | document.write(base) |
| 07:20 | <sirdarckcat> | well |
| 07:20 | <sirdarckcat> | <base href=""> |
| 07:20 | <sirdarckcat> | they dont know the real location |
| 07:20 | <sirdarckcat> | "yet" |
| 07:21 | <sirdarckcat> | I'll try to make some tests, maybe I can disable it with a <plaintext> or something like that |
| 07:22 | <zcorpan_> | how did you rely on it not going to happen? |
| 07:23 | <sirdarckcat> | since I dont want the referrer to be leaked |
| 07:23 | <sirdarckcat> | anyway, I think I can fix it with a <plaintext> after the <script> |
| 07:27 | <zcorpan_> | do you have document.write('<plaintext>') now? |
| 07:28 | <sirdarckcat> | yes |
| 07:28 | <sirdarckcat> | <script src="..."></script><script>document.write("<plaintext>")</script> |
| 07:29 | <sirdarckcat> | anyway, is this standarized or is just a defacto optimisation? |
| 07:29 | <zcorpan_> | defacto |
| 07:29 | <sirdarckcat> | hmm I see |
| 07:29 | <sirdarckcat> | well.. I see why browsers would like to do it |
| 07:29 | <sirdarckcat> | :) thanks zcorpan |
| 07:29 | <sirdarckcat> | and hsivoben |
| 07:29 | <sirdarckcat> | hsivonen |
| 07:29 | <hsivonen> | sirdarckcat: if you have <base> at all, Gecko just makes bogus speculative GETs |
| 07:30 | <hsivonen> | sirdarckcat: GET is idempotent and safe, so it only wastes bits |
| 07:30 | <hsivonen> | if you want your site to be fast, don't use <base> |
| 07:30 | <sirdarckcat> | oh, I dont want to use base |
| 07:30 | <hsivonen> | (I might fix that some day, but it's not a priority.) |
| 07:30 | <sirdarckcat> | but I should support sites that use it |
| 07:31 | <sirdarckcat> | there are a lot of things that shouldnt exist, multiple <base> tags being one of them |
| 07:31 | <hsivonen> | Support for multiple <base> tags is on its way out, IIRC. |
| 07:31 | <sirdarckcat> | haha its gonna be standard? |
| 07:31 | <sirdarckcat> | no way! |
| 07:32 | <sirdarckcat> | xDDD |
| 07:32 | <sirdarckcat> | that sucks |
| 07:32 | <sirdarckcat> | well |
| 07:32 | <sirdarckcat> | what problem does that solve? |
| 07:32 | <sirdarckcat> | I can only think on xss |
| 07:32 | <zcorpan_> | ie only uses the first <base> |
| 07:32 | <sirdarckcat> | yeah |
| 07:32 | <zcorpan_> | html5 matches ie |
| 07:32 | <sirdarckcat> | I think that's the way to go |
| 07:32 | <sirdarckcat> | yeah I agree |
| 07:32 | <sirdarckcat> | but then, what do u mean with |
| 07:33 | <sirdarckcat> | oh |
| 07:33 | <sirdarckcat> | wait |
| 07:33 | <sirdarckcat> | wait |
| 07:33 | <sirdarckcat> | you said |
| 07:33 | <hsivonen> | zcorpan_: I think HTML5 is silent ATM |
| 07:33 | <sirdarckcat> | "on its way out" |
| 07:33 | <sirdarckcat> | ohhh sorry |
| 07:33 | <sirdarckcat> | haha, I misunderstood u |
| 07:33 | <zcorpan_> | hsivonen: no it isn't :) |
| 07:33 | <sirdarckcat> | :) |
| 07:33 | <hsivonen> | zcorpan_: where's the normative text? |
| 07:33 | <hsivonen> | zcorpan_: I only saw an informative note |
| 07:34 | <sirdarckcat> | I filled a bug on the multiple base tags on webkit&mozilla 2 days ago |
| 07:34 | <sirdarckcat> | https://bugzilla.mozilla.org/show_bug.cgi?id=522658 |
| 07:34 | <zcorpan_> | oh maybe it was removed as part of URLs |
| 07:35 | <sirdarckcat> | informative note means its optional? |
| 07:35 | <hsivonen> | sirdarckcat: yeah, the spec bug exists because I was unable to determine the spec-compliance status of the Gecko bug you filed |
| 07:35 | <hsivonen> | sirdarckcat: informative note means the editor goofed |
| 07:36 | <zcorpan_> | hsivonen: "The document base URL of a Document object is the document base Web address as defined by the Web addresses specification. [WEBADDRESSES]" |
| 07:37 | <sirdarckcat> | hmm mmm |
| 07:37 | <sirdarckcat> | Contexts in which this element may be used: |
| 07:37 | <sirdarckcat> | In a head element containing no other base elements. |
| 07:37 | <sirdarckcat> | whats the informative note? |
| 07:37 | <sirdarckcat> | http://www.whatwg.org/specs/web-apps/current-work/#the-base-element |
| 07:37 | <zcorpan_> | the note is "Note: If there are multiple base elements with href attributes, all but the first are ignored." |
| 07:38 | <hsivonen> | zcorpan_: does [WEBADDRESSES] deal with multiple <base>s and script-inserted bases? |
| 07:38 | <sirdarckcat> | AH RIGHT |
| 07:39 | <zcorpan_> | hsivonen: yes. "Otherwise, let w be the value of the href attribute of the first such element." |
| 07:39 | <hsivonen> | zcorpan_: oh ok. thanks |
| 07:40 | <hsivonen> | ok so Hixie didn't good. sorry. but it would sure be clearer to have the <base> processing model in HTML5 |
| 07:40 | <sirdarckcat> | mmm well webkit says they wont fix it unless gecko does it.. =/ |
| 07:40 | <sirdarckcat> | https://bugs.webkit.org/show_bug.cgi?id=30432#c3 |
| 07:40 | <sirdarckcat> | anyway |
| 07:40 | <sirdarckcat> | maybe |
| 07:40 | <zcorpan_> | webaddress doesn't define what "the head element" is |
| 07:46 | <hsivonen> | duped the bug against https://bugzilla.mozilla.org/show_bug.cgi?id=515401 ; see sicking's comment #13 there. |
| 08:03 | <sirdarckcat> | @hsivone thnx |
| 08:03 | <sirdarckcat> | what's the meaning of Whiteboard: [good first bug] ? |
| 08:17 | <sirdarckcat> | oh nvm, http://www-archive.mozilla.org/contribute/hacking/first-bugs/ |
| 08:28 | <erlehmann> | more HTML5 on your console browser, coming soon: http://img3.imageshack.us/img3/1247/bildschirmfoto2eb.png |
| 08:30 | <zcorpan_> | erlehmann: cool |
| 08:30 | <zcorpan_> | erlehmann: does it use an html5 parser? |
| 08:31 | <erlehmann> | zcorpan_, haha, no. the source is a mess, as far as i can tell. |
| 08:31 | <jgraham> | Hixie: Is pms being more reliable? I made a small change that may improve reliability at the expense of a little speed, but it may not have helped |
| 08:31 | <jgraham> | erlehmann: Those things are not mutually exclusive... |
| 08:31 | <zcorpan_> | erlehmann: do you support <video><source src>? |
| 08:32 | <erlehmann> | zcorpan_, no. there are three bugs i will probably fix in the next days. |
| 08:32 | <Hixie> | jgraham: it was significantly slower earlier, but yes, it was eventually completing. However, the slowness was for everything, not just the W3C copy. |
| 08:32 | <erlehmann> | first, no <source> element parsing |
| 08:32 | <Hixie> | jgraham: haven't tried in the last few hours. |
| 08:32 | <erlehmann> | second, element contents are still displayed |
| 08:32 | <jgraham> | Hixie: Might just have been a server problem then |
| 08:33 | <erlehmann> | third, the poster attribute. inserting a fake image before the video link will do it. |
| 08:33 | <Hixie> | jgraham: yeah |
| 08:33 | <hsivonen> | years ago, when I still thought XHTML was the Right Thing for the Web, I wanted to add expat to Lynx as a weekend hack |
| 08:33 | <erlehmann> | zcorpan_, if you want to add the javascript interface for media elements in elinks, good luck with that :D |
| 08:34 | <zcorpan_> | erlehmann: heh |
| 08:34 | <hsivonen> | I looked at the source and it was a bunch of undocumented pointer magic |
| 08:34 | <hsivonen> | then I turned to links |
| 08:34 | <hsivonen> | and it looked similar |
| 08:34 | <hsivonen> | so I gave up |
| 08:34 | <hsivonen> | maybe elinks is better now |
| 08:35 | <Hixie> | hsivonen: i was hoping one day to make an aalib GFX for Gecko |
| 08:35 | <zcorpan_> | would be cool to asciify the rendered output of a modern rendering engine |
| 08:35 | <erlehmann> | Hixie, better make embedded aalib rendering for elinks ;) |
| 08:36 | <zcorpan_> | with <video> playing as ascii art |
| 08:36 | <hsivonen> | Hixie: these days, I think TTY browsers should put a TTY presentation layer on a mainstead browser engine impl |
| 08:36 | <erlehmann> | i think that too btw |
| 08:36 | <Hixie> | yeah, i don't think using elinks would be worth it |
| 08:36 | <Hixie> | you want all the CSS support, etc |
| 08:38 | <erlehmann> | i thought elinks does some CSS |
| 08:40 | <zcorpan_> | the html5 doctors are a bit slow at fixing their templates |
| 08:40 | <zcorpan_> | wonder if someone can help |
| 09:16 | <jgraham> | So one reason that clashing html/non-html tag names in foreign content is bad is the need for the breaking out of foreign content mode stuff. Were the other reasons mostly increased implementation complexity? |
| 09:17 | <zcorpan_> | v=document.createElement('video'); v.src='foo'; v.load(); |
| 09:17 | <zcorpan_> | will fire an emptied event, right? |
| 09:17 | <erlehmann> | zcorpan_, elinks uses spidermonkey, so if you can get that to work, i't would be cool |
| 09:18 | <zcorpan_> | because setting src invokes the load algorithm, which invokes resource selection, which sets networkState to NETWORK_NO_SOURCE |
| 09:19 | <zcorpan_> | then calling load() will run the load algorithm again, see that networkState is not NETWORK_EMPTY, and thus fire 'emptied' |
| 09:21 | <zcorpan_> | seems a bit annoying |
| 09:27 | <mikekelly> | hi fans |
| 09:28 | <zcorpan_> | foolip: ping |
| 09:28 | <mikekelly> | are there any javascript/browser geniuses around? |
| 09:28 | <mikekelly> | :P |
| 09:30 | <mikekelly> | I need to figure out if it is possible to shift browser location to a new URL and add custom headers to the request |
| 09:30 | <Philip`> | mikekelly: Use XHR and then document.write the responseText, maybe? |
| 09:30 | Philip` | doesn't know what else could work |
| 09:31 | <mikekelly> | hmm |
| 09:31 | <mikekelly> | presumably that doesn't work for docs like pdf, or images |
| 09:31 | <Philip`> | Use XHR and then convert the responseText into a data: URI and load that, maybe |
| 09:32 | <Philip`> | That might not work at all |
| 09:36 | <zcorpan_> | so should we limit document.all to quirks mode? |
| 09:49 | <jgraham> | zcorpan_: It seems like it might be OK |
| 09:50 | <jgraham> | I mean it is already such a disaster that no one should be using it. And Mozilla seem to get away with it |
| 09:50 | <jgraham> | s/using it/using it in new code/ |
| 09:51 | <jgraham> | The main arguments against are: it is added complexity which is bad, and there is a possibility that other browsers will have more compat problems than Mozilla (e.g. because they get a differnt codpath due to a different level of IE emulation) |
| 09:53 | <zcorpan_> | yeah, we probably need to investigate the compat situation |
| 09:54 | <zcorpan_> | opera more often gets to the ie code path than mozilla |
| 09:54 | <zcorpan_> | so if we remove document.all from standards mode, sites might break in opera but continue to work in ie and moz |
| 09:56 | <jgraham> | I guess the other fix is to emulate less of IE in Opera :) |
| 09:56 | <zcorpan_> | sure |
| 09:57 | <Hixie> | p4200 |
| 09:57 | <Hixie> | er |
| 09:57 | <Hixie> | r4200 |
| 09:58 | <jgraham> | But yes it would be good to get an idea of compat |
| 09:58 | <jgraham> | Hixie: just for the nice number? |
| 09:59 | <zcorpan_> | we should rename the spec to HTML4200 |
| 10:00 | <zcorpan_> | and change it every revision |
| 10:00 | <Philip`> | That would be a good way to demonstrate the meaninglessness of version numbers |
| 10:01 | <erlehmann> | <DOCTYPE html4321> :D |
| 10:01 | <Hixie> | jgraham: yeah |
| 10:01 | <jgraham> | Ah, how I pine for the days of HTML4198 |
| 10:02 | <Hixie> | i'm amused that the ietf people keep being shocked that websocket is at r48 |
| 10:02 | <Hixie> | 48! shocking! such a high number of revisions! |
| 10:03 | zcorpan_ | hears Hixie go lalala complete.html gets like 48 revisions a day |
| 10:05 | <erlehmann> | i guess charces stross was wrong about the IETF being capable of coping with the coming singularity |
| 10:05 | jgraham | feels zcorpan might be immortalised in the html5lib code for the Script data double escaped dash dash state |
| 10:05 | <foolip|work> | zcorpan_: you rang? |
| 10:06 | <zcorpan_> | foolip|work: what do you think about the load algorithm being invoked twice in v=document.createElement('video'); v.src='foo'; v.load(); ? |
| 10:06 | <zcorpan_> | foolip|work: and thus firing 'emptied' afaict |
| 10:07 | <erlehmann> | "Rachel grinned humorlessly as she held up a warrant card. Her head, surrounded by the UN three-W logo on a background of stars." |
| 10:07 | <foolip|work> | zcorpan_: don't call load() ? |
| 10:07 | <erlehmann> | in the next revision of iron sunrise it will be a green question mark, i bet ;) |
| 10:07 | <webben> | erlehmann: It does (do some CSS). |
| 10:08 | <zcorpan_> | foolip|work: sure but then it wouldn't load in older browsers |
| 10:09 | <annevk> | seems like a short term problem not worth fixing |
| 10:10 | <zcorpan_> | v=document.createElement('video'); v.src='foo'; v.load(); doesn't look wrong, so people will probably do it even though load() isn't necessary, and would maybe be surprised when it fires an 'emptied' event |
| 10:11 | <foolip|work> | zcorpan_: I'm not sure this is a problem, why would anyone listen to the emptied event to begin with? |
| 10:12 | <zcorpan_> | i don't know. what's the use case for the event? |
| 10:13 | <foolip|work> | beats me :) |
| 10:15 | zcorpan_ | files a spec bug |
| 10:19 | <foolip|work> | Hixie: re: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7843 no other event on media elements can be trusted to be in sync with the state of the element, why would it be important for abort or emptied? |
| 10:21 | <hsivonen> | hmm. type="x-shader/x-fragment" |
| 10:21 | <hsivonen> | on <script> |
| 10:22 | <foolip|work> | especially since the state of the element in 'abort' or emptied' is reset, there's nothing interesting for the script to check on the element anyway |
| 10:22 | <hsivonen> | maybe in the future I should special-case those not to create speculative futures |
| 10:22 | <zcorpan_> | hsivonen: we probably need an official type that authors can use for their script data blocks |
| 10:22 | <Hixie> | foolip|work: i dunno, maybe. i'm scared of race conditions. feel free to reopen the bug. |
| 10:23 | <foolip|work> | Hixie: ok, will do :) |
| 10:31 | <Hixie> | foolip|work: while you're here, http://www.w3.org/Bugs/Public/show_bug.cgi?id=7844 |
| 10:32 | <zcorpan_> | Hixie: i filed that bug |
| 10:33 | <Hixie> | zcorpan_: cool, you can answer my question too then :-) |
| 10:33 | <Hixie> | anyway, my question is: do we want media elements to be live after being created? |
| 10:33 | <Hixie> | it seems weird that one wouldn't be able to construct an <audio> while it's dead, and invoke the loading later |
| 10:34 | <Philip`> | hsivonen: Shouldn't you special case text/javascript and similar things that will get executed, rather than special-casing a few of the infinitely many types that won't get executed? |
| 10:35 | <hsivonen> | Philip`: Gecko has this extensibility thing going... |
| 10:36 | <hsivonen> | Philip`: so the parser would have to know that it's doing exactly the same comparisons as the script loader when Python etc. is loaded |
| 10:36 | <hsivonen> | and IIRC, Python is chrome-only, etc. |
| 10:36 | <hsivonen> | and the parser doesn't know if it is parsing a chrome doc, etc. |
| 10:37 | <Philip`> | hsivonen: I thought speculative parsing was only particularly useful for high-latency web documents, so you can pre-fetch resources, and would have minimal effect in chrome |
| 10:37 | <zcorpan_> | Hixie: hmm, not sure when one would want to have a dead <audio> |
| 10:38 | <Hixie> | zcorpan_: precreating a number of videos, say, so they can be inserted when desired? dunno |
| 10:38 | <zcorpan_> | maybe |
| 10:39 | <zcorpan_> | but you'd have to use <source> as the spec is now |
| 10:40 | <zcorpan_> | it's not the most obvious thing that it loads automatically when you set src and when you insert a <source> when it's in a document but not when you insert a <source> when it's not in a document |
| 10:40 | <Hixie> | yeah i agree we should make that consistent |
| 10:41 | <zcorpan_> | if there's a need for dead media elements, maybe a new attribute or something? |
| 10:42 | <zcorpan_> | <video loadondemand>? |
| 10:42 | <Hixie> | it's not important enough to have its own feature, imho |
| 10:43 | <zcorpan_> | yeah |
| 10:58 | <Hixie> | what should location.search do in data: pages...? |
| 11:04 | <Lachy> | are data URLs not allowed to have query components? |
| 11:04 | <Hixie> | no |
| 11:04 | <Hixie> | nor pathname |
| 11:04 | <Hixie> | looks like i just overlooked this |
| 11:04 | <Hixie> | i'll make them just ignore .pathname and .search |
| 11:04 | <Lachy> | then do what Mozilla does and return an empty string |
| 11:05 | <Hixie> | yeah |
| 11:07 | <Lachy> | data:text/html,<!DOCTYPE html><script>if(location.search===""){document.write("PASS");}else{document.write(location.search)}</script><!--?FAIL |
| 11:08 | <Lachy> | Opera outputs "?FAIL" |
| 11:08 | <Lachy> | woah, Safari outputs "?FAIL?FAIL" |
| 11:08 | <Hixie> | yeah i tested the browsers before asking :-) |
| 11:09 | <Lachy> | ok |
| 11:09 | <Lachy> | oh, Safari does that cause it reparses the comment |
| 11:10 | <Hixie> | reparses? |
| 11:11 | <Lachy> | yeah, when it sees <!--XXX with no closing -->, doesn't it do reparsing to handle the error? |
| 11:11 | <Hixie> | why would that make it say ?FAIL?FAIL ? |
| 11:11 | <Hixie> | it doesn't affect the URL |
| 11:12 | <Lachy> | because the first one is the result of the document.write(), the latter is a result of it actually being part of the page content. |
| 11:12 | <Lachy> | the result is the same as doing this: <script>document.write("?FAIL");</script>?FAIL |
| 11:13 | <Hixie> | oh, right |
| 11:20 | <Hixie> | is "decentralized extension" newspeak for non-standard extension? http://www.w3.org/Bugs/Public/show_bug.cgi?id=7855 |
| 11:32 | <zcorpan_> | a standard is centralized, so it probably follows that non-standard is decentralized |
| 11:49 | <zcorpan_> | hmm |
| 11:49 | <zcorpan_> | if a browser supports video formats A and B |
| 11:49 | <zcorpan_> | and a video using format A is labeled as content-type: B |
| 11:50 | <zcorpan_> | should the video be played? |
| 11:53 | <zcorpan_> | i think the spec says yes, because the algorithm only fails if the mime type is unsupported or the video can't be decoded |
| 11:53 | <annevk> | that depends on whether you want to enforce some additional pedantic check |
| 11:55 | <Hixie> | yes, the spec says that the MIME type has to be supported, but it doesn't say the MIME type has to match the content |
| 11:56 | <zcorpan_> | yep |
| 11:56 | <Hixie> | wasn't really what i meant to spec, but i don't propose changing it :-) |
| 11:57 | <zcorpan_> | i think it's fine |
| 11:57 | <zcorpan_> | makes it easier to test, too |
| 11:58 | <zcorpan_> | also matches how <img> works |
| 11:58 | <zcorpan_> | except for SVG vs PNG i guess |
| 11:59 | <zcorpan_> | haven't tested though |
| 12:00 | <Philip`> | zcorpan_: Why are standards centralized? |
| 12:00 | <Philip`> | It seems quite common for independent groups to spring up and make standards, without being part of the existing centralized standards organisations |
| 12:01 | <zcorpan_> | maybe |
| 12:06 | <jgraham> | Why are existing organisations making standards centralized but new organisations doing the same thing decentralised? |
| 12:06 | <jgraham> | e.g. I wouldn't describe what the WHATWG did as "decentralised extensibility" |
| 12:09 | <Philip`> | They become centres of standardisation after existing for a while and being successful |
| 12:09 | <Philip`> | jgraham: That's because HTML didn't support distributed extensibility, and the realistic option was to start from scratch instead of extending it |
| 12:10 | <jgraham> | Philip`: I doubt we would have had {http://whatwg.org/ns/webapps}video even if it had been possible |
| 12:11 | <Philip`> | In the magical world of distributed extensibility, I suppose the idea is some random group of people could form a WHYWG and define a video element without needing to get approval from existing standard organisations (though still needing cooperation from browser vendors) |
| 12:12 | <Philip`> | but presumably that'd only work if features using the extension mechanism were as good as 'native' non-extension features |
| 12:13 | <Philip`> | (and it wouldn't work if extension features had to use complex namespaces while native feature didn't) |
| 12:15 | <jgraham> | Maybe fans of namespaces in html should set up the Web Hypertext Extensibility Namespaces Working Group |
| 12:21 | <zcorpan_> | foolip: reopened the bug and gave you permissions to edit bugs and give other people permissions |
| 12:26 | <gsnedders|work> | jgraham: You aware that html5lib.parse("foo", "etree") will never work? |
| 12:30 | <zcorpan_> | application/octet-stream; codecs=foobar |
| 12:30 | <zcorpan_> | is that a type that the ua knows it cannot render? |
| 12:37 | <zcorpan_> | Hixie: does the term "MIME type" include parameters or not? |
| 12:40 | <zcorpan_> | "valid MIME type" seems to include parameters, so i guess "MIME type" does too |
| 12:45 | <hsivonen> | how does WebKit deal with https://bugzilla.mozilla.org/show_bug.cgi?id=510063 ? |
| 12:46 | <zcorpan_> | hsivonen: by not foster parenting forms |
| 12:49 | <hsivonen> | zcorpan_: does that lead to bad craziness? |
| 12:49 | <hsivonen> | zcorpan_: if not, why doesn't HTML5 copy WebKit here? |
| 12:49 | <zcorpan_> | i guess Hixie didn't think it was needed for compat and didn't want to add unneeded complexity |
| 12:49 | <zcorpan_> | but clearly it's a bug in html5 |
| 12:50 | <zcorpan_> | old gecko also doesn't foster parent forms |
| 12:58 | <zcorpan_> | maybe the quirks mode form margin could be zapped, but presumably it's there for compat with content and not just a leftover from netscape? |
| 12:59 | <hsivonen> | I have no idea |
| 13:00 | <zcorpan_> | hmm opera has the margin in standards mode too |
| 13:01 | <zcorpan_> | does ie have the margin in standards mode? |
| 13:19 | hsivonen | wonders if Opera does the reloading charset switch in mid-parse |
| 13:25 | <annevk> | should createHTMLDocument talk about quirks mode? |
| 13:26 | <annevk> | or is that implied from createDocument() somehow? |
| 13:26 | <gsnedders|work> | I thought the spec said that all documents were by default in no-quirks |
| 13:26 | <gsnedders|work> | So unless it is explicitly set to quirks/limited-quirks, it's in no-quirks |
| 13:26 | <hsivonen> | gsnedders|work is right |
| 13:27 | <hsivonen> | an informative note wouldn't hurt, though |
| 13:39 | <annevk> | fair enough |
| 13:41 | <zcorpan_> | hsivonen: http://simon.html5.org/test/html/parsing/encoding/charset-reload-2k.htm http://simon.html5.org/test/html/parsing/encoding/charset-reload-200k.htm |
| 13:41 | <zcorpan_> | apparently we don't reload, we just give up trying to find the encoding at some point |
| 13:42 | <zcorpan_> | possibly based on a timer, because i needed more bytes when testing locally |
| 13:42 | <zcorpan_> | that or my test is bogus |
| 13:43 | <annevk> | Hixie, onload can also be specified for a lot of elements besides body |
| 13:43 | <hsivonen> | ok. so Opera doesn't reparse, WebKit doesn't reparse |
| 13:43 | <hsivonen> | does IE reparse? |
| 13:43 | <annevk> | (same for other such restricted elements) |
| 13:43 | <zcorpan_> | ie reparses |
| 13:44 | <hsivonen> | I've spent way too much time tweaking reparsing |
| 13:47 | <zcorpan_> | but webkit doesn't give up trying to find the encoding, or does it? |
| 13:47 | <hsivonen> | IIRC, WebKit prescans 1KB and that's it |
| 13:48 | <zcorpan_> | i get an Ђ in chrome with a meta after 2MB |
| 13:49 | <hsivonen> | oh |
| 13:49 | <hsivonen> | I wonder if they write the charset to the cache entry like Gecko does |
| 14:29 | <TabAtkins> | Can anyone give an estimate of how much time is required, on a modern website, to download + parse the page, versus downloading all linked resources, execute scripts, apply css, and render? |
| 14:29 | <TabAtkins> | Intuitively I'd expect it to be a very small part of the overall time. |
| 14:29 | gsnedders|work | points out that some resources block parsing |
| 14:29 | <Philip`> | What's a modern website? |
| 14:29 | <Philip`> | You can't parse the page without executing scripts anyway, since modern websites use document.write |
| 14:29 | <gsnedders|work> | (if you ignore the parser being blocked by other resources, then it's almost no cost at all) |
| 14:29 | <TabAtkins> | gsnedders|work: Assume no scripts are run at all, so parsing can proceed without dealing with that (as happens when an XHR is parsed into responseXML). |
| 14:31 | <TabAtkins> | Would it be realistic to assume that, when XHR2 is implemented and HTML pages are allowed to be fetched and parsed into responseXML, scripts still won't run? |
| 14:31 | <jgraham> | Well downloading can be pretty slow of course |
| 14:31 | <Philip`> | You should be able to measure download times easily using any kind of web profiler |
| 14:31 | <jgraham> | Basically parsing is fast compared to layout |
| 14:31 | <gsnedders|work> | TabAtkins: HTML 5 takes a while to download and parse |
| 14:31 | <Philip`> | (and compare time for initial page download vs total download time) |
| 14:31 | <TabAtkins> | I think html5 is an edge case. ^_^ |
| 14:32 | <Philip`> | HTML5 only takes fractions of a second to parse, if I remember correctly |
| 14:32 | <jgraham> | (in most cases) |
| 14:32 | <jgraham> | (although you can probably create pathological testcases with mesnested formatting elements and so on) |
| 14:33 | <gsnedders|work> | Philip`: The download time is more than that, though |
| 14:33 | <Philip`> | gsnedders|work: That's why I said "parse", not "download" :-p |
| 14:33 | <jgraham> | gsnedders|work: Not if you load it from file:// pointing to a ram disk |
| 14:33 | <jgraham> | ;p |
| 14:33 | <TabAtkins> | "Average" website being 30k-40k of page, at most. |
| 14:34 | <gsnedders|work> | jgraham: I don't normally keep HTML 5 on a RAM-disk backed place accessible by file:// ;P |
| 14:34 | <Philip`> | Load the HTML5 spec from a data: URL and then there's no IO at all |
| 14:34 | <jgraham> | gsnedders|work: Your problem, not mine ;) |
| 14:36 | <TabAtkins> | Hmm, I could have sworn YSlow gav a nice litte graph showing a visual timeline of the resource requests. I can't find anything like it now. |
| 14:37 | <jgraham> | TabAtkins: Firebug and Web Inspector both do that don't they> |
| 14:37 | <jgraham> | s/>/?/ |
| 14:37 | <TabAtkins> | Firebug doesn't do it by itself, but the YSlow extension used to. I don't use Web Inspector. |
| 14:38 | <TabAtkins> | Oh, nm. It was the Net panel. My current system colors make it *really* hard to see disabled tabs. |
| 14:39 | Philip` | is fairly sure Firebug does it by itself |
| 14:45 | <TabAtkins> | Philip`: Yeah, you're right. Okay, so it takes about 200ms to completely receive the request for my company's home page. |
| 14:47 | <TabAtkins> | Scripts *aren't* parsed currently when building responseXML's DOM in an XHR, right? |
| 14:48 | <TabAtkins> | (Can document.write() even be used in XML?) |
| 14:48 | <jgraham> | No |
| 14:49 | <TabAtkins> | Do you think scripts *will* be parsed once XHR2 is implemented and responseXML can contain HTML documents? |
| 14:53 | <gsnedders|work> | TabAtkins: Only in the case that they are HTML documents |
| 14:53 | <gsnedders|work> | (and not XML ones, of any sort, inc. XHTML ones) |
| 14:54 | <TabAtkins> | Yeah, assumed that much. Hrm. |
| 14:54 | <TabAtkins> | I'm trying to gauge how much time it will take for an average document to be checked for the relevant #ids in my <a onlyreplace> proposal. |
| 14:55 | <gsnedders|work> | document.getElementsById is cheap. |
| 14:55 | <gsnedders|work> | Like, really cheap. |
| 14:55 | <TabAtkins> | Yeah, but you have to build the document first. |
| 14:55 | <gsnedders|work> | Yeah, so? |
| 14:55 | <TabAtkins> | I know it's nearly free, since you keep a hash of elements by id. |
| 14:55 | <TabAtkins> | So if there are slow scripts involved, it can still be slow to build the DOM and decide that you need to fail and render the whole page. |
| 14:56 | <TabAtkins> | From my data here, it doesn't look *that* slow, though. The only slow scripts are the external customer tracking ones. Everything else completes downloading in another 200ms. |
| 14:57 | <annevk> | my plan was to parse assuming scripts were disabled |
| 14:57 | <annevk> | i guess we could execute them but it seems weird |
| 14:58 | <TabAtkins> | Yay! That was my hope. |
| 14:58 | <annevk> | we also don't want to load external resources and all |
| 14:58 | <TabAtkins> | k, so worst case there are some document.write() embedded directly in the page. That shouldn't be at all significant. |
| 15:23 | <annevk> | argh, how do you write that :nth-child(4n+0) serializes to :nth-child(4n) |
| 15:24 | <TabAtkins> | Can you just outright state that +0 is dropped when there's a non-zero n term? |
| 15:25 | <annevk> | maybe, now I wonder what happens for 0n |
| 15:25 | <TabAtkins> | Preferably it would serialize to :nth-child(0). |
| 15:26 | <annevk> | Firefox does that |
| 15:26 | <annevk> | WebKit gives 0n |
| 15:26 | <annevk> | I guess Firefox wins |
| 15:26 | <TabAtkins> | What about 0n+2? |
| 15:26 | <annevk> | any idea why I can't have a space after n? |
| 15:26 | <annevk> | after ( I mean, e.g. in :not( [foo] ) |
| 15:27 | <TabAtkins> | Huh? You can't? That's bizarre. Sounds like a spec bug. |
| 15:27 | <annevk> | it fails to parse in WebKit/Opera |
| 15:27 | <annevk> | not in Gecko though |
| 15:27 | <TabAtkins> | How strange. |
| 15:27 | <TabAtkins> | I doubt that it's correct to fail there. |
| 15:27 | <annevk> | 0n +2 gives 2 in Gecko |
| 15:28 | <annevk> | also gives 2 in Opera |
| 15:28 | <annevk> | Opera drops 0n on the floor |
| 15:28 | <annevk> | which might make sense because it never matches |
| 15:28 | <TabAtkins> | Yeah. |
| 15:28 | <TabAtkins> | I like that behavior. |
| 15:29 | <annevk> | WebKit also fails to parse for 0n+ 2 (note the space) |
| 15:29 | <annevk> | 0n+2 gives 0n+2 |
| 15:30 | <annevk> | leading and trailing whitespace is allowed per CSS |
| 15:31 | <TabAtkins> | Yeah, just an under-permissive parser there then. Those need bugs. |
| 15:32 | <annevk> | odd becomes 2n+1 |
| 15:32 | <annevk> | except in WebKit |
| 15:33 | <TabAtkins> | I forget - does n start at 0? |
| 15:33 | <annevk> | you found a spec bug |
| 15:33 | <TabAtkins> | Heh, ok. |
| 15:34 | <annevk> | the spec says 1, but the definition of odd/even assume 0 |
| 15:34 | <annevk> | i think authors also assume 0 |
| 15:34 | <TabAtkins> | I think everyone assumes 0, yeah. |
| 15:34 | <Lachy> | annevk, TabAtkins, you can't have spaces in :not( [foo] ) because a simple selector can't contain leading or trailing whitespace |
| 15:34 | <annevk> | TabAtkins, will you file a comment? |
| 15:34 | <TabAtkins> | annevk: Where do I do so? Just the mailing list? |
| 15:34 | <annevk> | www-style |
| 15:35 | <annevk> | [css3-selectors] as subject |
| 15:35 | <Lachy> | oh, actually. The space says S* is allowed |
| 15:35 | <TabAtkins> | Yeah, I'll do so. One moment. |
| 15:35 | <Lachy> | The *spec* says... |
| 15:35 | <annevk> | also for :not? |
| 15:35 | <annevk> | hmm |
| 15:36 | <Lachy> | yeah, it says: |
| 15:36 | <Lachy> | negation |
| 15:36 | <Lachy> | : NOT S* negation_arg S* ')' |
| 15:36 | <annevk> | ah ok |
| 15:37 | <annevk> | I guess I should file a bug on 0 -> ignored/error |
| 15:37 | <TabAtkins> | Hmm, you sure that it's a spec bug, annevk? It says that the index of the first element is 1, but that doesn't bear on the values used for n. |
| 15:38 | <annevk> | oh no, it's not |
| 15:38 | <annevk> | my bad |
| 15:38 | <TabAtkins> | Ah, but it *does* say that an+b matches the bth element in each group of a elements. That's assuming 0-numbering. |
| 15:38 | <annevk> | though if you're writing an email now maybe you can bring up the :nth-child(0) issue |
| 15:38 | <TabAtkins> | Which then contradicts the "first element is 1" bit. |
| 15:38 | <annevk> | it also says "for a given positive integer or zero value of n" |
| 15:39 | <annevk> | I guess it should say that a/b cannot be both zero at the same time |
| 15:39 | <TabAtkins> | Hmm, I think it's fine if they are, as long as it's clear that it means "0", which doesn't match anything. |
| 15:40 | <annevk> | since it indicates an authoring error I think what Opera does (dropping the rule) makes more sense |
| 15:40 | <TabAtkins> | ... :nth-child(0) *doesn't* match anything, right? It shouldn't, per spec. |
| 15:42 | <TabAtkins> | Is there a difference between dropping it and just leaving it around as a non-matching rule? |
| 15:42 | <annevk> | yes |
| 15:43 | <annevk> | I thought you said CSS was easy? :p |
| 15:43 | <TabAtkins> | Arcana is never easy. ^_^ |
| 15:44 | <TabAtkins> | I guess the difference is in, say, :not(:nth-child(0))? |
| 15:44 | <annevk> | difference is in the CSSOM, it is in whether :nth-child(0), p {} will match p elements, etc. |
| 15:45 | <TabAtkins> | Oh, I assumed that a dropped rule didn't invalidate the whole block. |
| 15:46 | <MikeSmith> | it will be interesting to see how CSSOM progresses |
| 15:46 | <MikeSmith> | annevk: you planning specific CSSOM discussion for CSS WG f2f at TPAC? |
| 15:46 | <annevk> | yeah, so far the chapters on Media Queries and Style Sheets in http://dev.w3.org/csswg/cssom/ are somewhat adequate |
| 15:46 | <annevk> | the rest needs work |
| 15:47 | <annevk> | MikeSmith, I can't attend the CSS WG meeting |
| 15:47 | <Philip`> | '":{N}{O}{T}(" return NOT;' - surely that should be ":"{N}{O}{T}"(" ? |
| 15:47 | <MikeSmith> | hmm |
| 15:47 | <annevk> | Philip`, prolly, email www-style |
| 15:47 | <MikeSmith> | sometimes I think CSS WG just has too much on its plate |
| 15:47 | Philip` | is too lazy |
| 15:48 | <annevk> | CSS grammar is a gigantic pain |
| 15:48 | <annevk> | MikeSmith, it's not exactly clear to me how you'd split it up |
| 15:48 | <MikeSmith> | I guess we have too much too (as far as a API side) |
| 15:49 | <annevk> | I guess you could have syntax / object model vs layout vs text or some such |
| 15:49 | <annevk> | but they are something intertwined |
| 15:49 | <annevk> | s/something/somewhat/ |
| 15:50 | <annevk> | and there's only a limited people with sufficient knowledge on all those topics anyway |
| 15:50 | <annevk> | number of people* |
| 15:50 | <TabAtkins> | Yeah, finding good editors is always the problem. |
| 15:50 | <annevk> | so whether they meet in three different groups or one really doesn't matter, you'll end up with the same 10 persons :) |
| 15:53 | <TabAtkins> | So it's like saying that HTML5 is too big, so we should split it up? |
| 15:53 | <Philip`> | Maybe it's like saying the web is too big, so we should split it up into markup and styling and scripting etc in different groups |
| 15:54 | <TabAtkins> | But that's clearly a silly idea, Philip`. |
| 15:54 | <annevk> | Philip`, emailed the grammar issue to www-style |
| 15:55 | <TabAtkins> | d'oh, Anne, I already sent a message about a=b=0, since you asked me too. |
| 15:56 | <annevk> | the orthogonality works to some extent except you do need to remember to build the bridges (e.g. the rendering section in HTML5) |
| 15:56 | <annevk> | TabAtkins, oh, I thought you didn't want to, sorry |
| 15:56 | <TabAtkins> | It's cool. It just means fantasai has to read both of our messages. |
| 15:57 | <Philip`> | annevk: Thanks |
| 15:57 | <annevk> | not a huge burden |
| 17:29 | <TabAtkins> | Man, why does jQuery still use eval for JSON, when IE and FF (and maybe others?) have native JSON parsing now? |
| 19:55 | <jgraham> | Did we already have a discussion about the confusion that will arise when authors try to do document.createElement("svg") and expect it to work? |
| 19:57 | <annevk42> | yes, we decided it was not worth the complexity of making it work |
| 19:58 | <zcorpan_> | the right solution for now is probably to have js libraries to paper over the confusingness |
| 20:01 | <jgraham> | Right I don't really see how you woulf make it work in general |
| 20:01 | <jgraham> | All I can imagine is having createSVGElement and so on |
| 20:01 | <jgraham> | Which would mean that you didn't have to remember the namespace at least |
| 20:01 | <zcorpan_> | doug had an idea of Element.createElement |
| 20:01 | <annevk42> | the SVG WG has some plan on adding a bunch of constructors I believe |
| 20:02 | <zcorpan_> | which would use the same namespace as the element you're calling it on |
| 20:02 | <jgraham> | Interesting |
| 20:02 | <jgraham> | I guess that might help |
| 20:03 | <zcorpan_> | doesn't help if you want to create a new <svg> root in an html document |
| 20:03 | <jgraham> | Indeed |
| 20:04 | <jgraham> | I guess javascript libraries can just have tagname->namspace mappings |
| 20:04 | <jgraham> | which will almost-always work |
| 20:05 | <zcorpan_> | i think we should wait and see how js libraries solve this before extending dom core |
| 20:05 | <annevk42> | I sort of doubt they'll solve this on the element-level |
| 20:06 | <annevk42> | JS libraries that create SVG today have more high-level functionality |
| 20:07 | <zcorpan_> | if authors don't feel the need to solve it on the element level, we shouldn't extend dom core to solve it |
| 20:27 | <annevk42> | jgraham, you really think the way the HTML parser works is a bug? |
| 20:27 | annevk42 | kind of likes it |
| 20:47 | <deltab> | TabAtkins: JSON.parse not in jQuery? it's release lag — the development version has it: http://code.jquery.com/jquery-nightly.js |
| 20:50 | <jgraham> | annevk42: I think the way the DOM layer works is unfortunate |
| 20:53 | <annevk42> | how should it work instead? |
| 20:55 | <jgraham> | In a way that doesn't require authors o understand XML namespaces |
| 20:55 | <jgraham> | (I don 't know if we could have done better in the circumstances though) |
| 20:56 | <annevk42> | ah ok |
| 20:56 | <annevk42> | yeah it would've been nicer if markup had been a bit more coordinated |
| 20:58 | Philip` | notes that nobody has shipped SVG in text/html and so it wouldn't be too late to change that |
| 20:58 | <annevk42> | it would require changing how MathML and SVG work in XML and all |
| 20:58 | <annevk42> | at least, if I understand what jgraham is saying |
| 20:58 | <Philip`> | That part might be more of a problem |
| 20:59 | <jgraham> | I'm not really saying anything concrete |
| 20:59 | <jgraham> | I'm just saying that what we have is bad |
| 21:00 | <jgraham> | (and that we shouldn't use use this badness as an excuse for introducing more pervasive forms of the same badness) |
| 21:00 | <annevk42> | seems that Julian took it the wrong way |
| 21:01 | <jgraham> | Oh I should check my email then |
| 21:09 | <TabAtkins> | deltab: Ah, k. It's been around for a while, so I would have thought it'd be in 1.3.2. Shrug. |
| 21:10 | <deltab> | TabAtkins: 1.3.2 is ten months old! JSON.parse was added five months ago |
| 21:11 | <TabAtkins> | !_! really? Never mind, then. |
| 21:12 | <deltab> | there's no newer release, mind — you have to use the svn version for something more up-to-date |
| 21:13 | <TabAtkins> | Yeah, I just wait for releases. |
| 23:12 | <roc> | TabAtkins: sorry, my question was about the use of <angle> with radial gradients |
| 23:12 | <TabAtkins> | roc: I'm sorry, I'm too dumb to answer questions today. |
| 23:12 | <roc> | ok, I'll ask again tomorrow :-) |
| 23:12 | TabAtkins | pulls the email back up to answer it properly. |
| 23:13 | <roc> | I've got linear gradients pretty much implemented, working on radial now |
| 23:13 | <TabAtkins> | Okay, yes. I somehow skipped putting in the default value. It's 0. |
| 23:14 | <roc> | ok, thanks |
| 23:14 | <TabAtkins> | roc: If you want to be my hero, also do square/rectangle and diamond/rhombus radial gradients. |
| 23:14 | <TabAtkins> | They're really really simple once you've got everything else done. |
| 23:14 | <roc> | they're hard to implement actually |
| 23:14 | <roc> | common graphics libraries don't support them directly |
| 23:14 | <TabAtkins> | Really? It took me like 5 minutes to do them once I got circle and oval working. |
| 23:15 | <TabAtkins> | Most of it was just trying to figure out the filledRectangle syntax. |
| 23:15 | <roc> | we don't draw gradients with a lot of rectangles |
| 23:15 | <roc> | we pass them down |
| 23:16 | <roc> | to various native libraries |
| 23:16 | <TabAtkins> | Ah, I see. |
| 23:16 | <TabAtkins> | Damns. |
| 23:16 | TabAtkins | just started from the bottom. |
| 23:16 | <roc> | I suppose we could approximate squares etc with linear gradients and clipping |
| 23:16 | <TabAtkins> | Hmm, maybe that'll work. |
| 23:17 | <roc> | you really want them implemented as close to the graphics hardware as possible, for performance |
| 23:17 | <roc> | (gradients in general, I mean) |
| 23:17 | <TabAtkins> | That won't help us solve the 7th gradient-shape I wanted, though - box (shape of the box, taking into account border-radius). |
| 23:17 | <TabAtkins> | ;_; |
| 23:18 | <TabAtkins> | Though, to be honest, that's not as useful now that I don't skew the gradient. |
| 23:18 | <roc> | we should define a new SVG Filter for that |
| 23:18 | <TabAtkins> | I really just have no idea what can be done with SVG. I need to learn up on it. |
| 23:19 | <roc> | actually |
| 23:19 | <roc> | with feMorphology erode/dilate you can kind of approximate the effect |
| 23:22 | <roc> | the only bit of heroism I'm considering is adding -moz-repeating-linear-gradient and -moz-repeating-radial-gradient, since they'd be really easy |
| 23:22 | <Philip`> | Hixie: Gavin > Garrett |
| 23:22 | <TabAtkins> | That's a long name, but sure. I still don't like the idea of other background properties leaking into image generation. Making it explicit is better. |
| 23:23 | <gavin> | Philip`: ? |
| 23:23 | <Philip`> | (alphabetically) |
| 23:23 | <Hixie> | ooh |
| 23:23 | <Philip`> | gavin: I think they're wrongly ordered in the credits section |
| 23:23 | <Hixie> | alphabets are hard |
| 23:24 | <TabAtkins> | roc: But I do like the idea behind repeating gradients, so I'd be happy to see them in there. |
| 23:25 | <TabAtkins> | What would be the effect, though, of -moz-repeating-linear-gradient(red, blue)? |
| 23:25 | <TabAtkins> | (Since, for a normal linear gradient, that defines a single sweep from red to blue across the entire height of the gradient.) |
| 23:26 | <TabAtkins> | s/height of the gradient/height of the box/ |
| 23:26 | <gavin> | I'm in the credits? |
| 23:26 | <gavin> | what for, I wonder |
| 23:27 | <gavin> | oh, it's not me! |
| 23:27 | <Philip`> | gavin: You're not the only person in the world called Gavin ;-) |
| 23:27 | <gavin> | it's Gavin Carothers |
| 23:27 | <gavin> | hate that guy |
| 23:27 | <Philip`> | Because he stole your name? |
| 23:28 | <gavin> | yeah |
| 23:29 | <Philip`> | Good a reason as any to hate somebody |
| 23:31 | <TabAtkins> | roc: Also, I assume that -moz-repeating-linear-gradient(red -10px, blue 50px) repeats with a 60px period? |
| 23:31 | <roc> | yeah |
| 23:32 | <TabAtkins> | Hmm. Is that equivalent to linear-gradient(red -10px, blue 50px, red 110px, blue 170px, ...)? |
| 23:32 | <roc> | no |
| 23:32 | <TabAtkins> | red -10px, blue 50px, red 50px, blue 110px? |
| 23:32 | <roc> | it's equivalent to linear-gradient(red -10px, blue 50px, red 50px, blue 110px, ...) |
| 23:32 | <TabAtkins> | k, yeah. |
| 23:32 | <TabAtkins> | That makes better sense. |
| 23:33 | <roc> | so you get an abrupt transition when the starting and ending colors are not the same |
| 23:33 | <TabAtkins> | Yeah. |
| 23:33 | <roc> | but I think that's OK, it's pretty obvious what to do to get a smooth transition there |
| 23:33 | <TabAtkins> | Yeah, and I can put an example in the spec for it too. |
| 23:33 | <roc> | and you might want the abrupt transition |
| 23:35 | <TabAtkins> | I guess sure. Possibly more in radial - I dont' think I'd ever want it to be abrupt in linear. But there's no reason to prevent it. |
| 23:54 | <roc> | TabAtkins: a couple more questions, if I may trouble you... |
| 23:54 | <TabAtkins> | Go for it. |
| 23:54 | <roc> | "In certain circumstances it is impossible to determine an appropriate ending-shape from the given parameters; in these instances the gradient image is just a solid color, defined by the last color-stop in the list. The following combinations of values will trigger this: closest-side if the starting-point is on a box edge, closest-corner if the starting-point is on a box corner, ellipse and closest-corner if the starting-point is on a box-edge," |
| 23:55 | <roc> | in those situations, the shape is simply a circle/ellipse with radius 0, isn't it? |
| 23:55 | <TabAtkins> | Yes. |
| 23:55 | <TabAtkins> | Which is also "a solid color, defined by the last color-stop in the list". |
| 23:55 | <roc> | ok, I suggest you rephrase "it is impossible to determine an appropriate ending-shape" then |
| 23:55 | <TabAtkins> | Hmm, okay. |
| 23:55 | <roc> | there' nothing really inappropriate about an empty circle or ellipse |
| 23:56 | <TabAtkins> | Well, it's sort of a degenerate circle. |
| 23:56 | <TabAtkins> | Equivalent to a point. |
| 23:56 | <roc> | yeah |
| 23:56 | <TabAtkins> | Depending on who you're talking to, degenerate shapes aren't valid. ^_^ I'll rephrase it, though. |
| 23:56 | <roc> | "and finally ellipse and either closest-corner or closest-side if the starting-point is outside of the box." |
| 23:57 | <roc> | I don't think we need to call out degenerate shapes in the spec, unless the spec demands behavior for the degenerate shape that is different from what you would get applying the normal rules |
| 23:58 | <TabAtkins> | That last one really is an error, though. There's no way to determine the dimensions of the ellipse in that case. |
| 23:59 | <roc> | there is |
| 23:59 | <roc> | suppose I'm using closest-side |
| 23:59 | <TabAtkins> | Unless you extend the lines defined by the sides outside of the box, I guess. |
| 23:59 | <roc> | right |
| 23:59 | <TabAtkins> | You can attempt to infer that, but I don't say anything that would make that required. |
| 23:59 | <roc> | I dunno if it's useful |
| 23:59 | <roc> | but it's what my code does |
