| 00:42 | <MikeSmith> | I see that the locus of EME debate seems to have now shifted away from W3C forums and on to blink-dev |
| 00:43 | <MikeSmith> | that's progress |
| 00:47 | <MikeSmith> | in other news, now that the HTML spec requires the title element to have non-whitespace content, we'll need to choose some stock value for the title attribute to use in the minimal boilerplate HTML document in the text-field input feature of the validator |
| 00:47 | <MikeSmith> | anybody have suggestions? |
| 00:49 | <jamesr__> | anyone here familiar with the charset attribute on Document? |
| 00:49 | <jamesr__> | it's in blink with a comment "// IE extensions" as an attribute DOMString |
| 00:49 | <jamesr__> | notable, not readonly |
| 00:50 | <jamesr__> | we appear to "support" (for some definition of that word) writing a value to the attribute |
| 00:50 | <jamesr__> | i don't know what it actually does |
| 00:51 | <jamesr__> | i can't find references on MDN, but maybe i just suck at it |
| 00:52 | <jamesr__> | mozilla doesn't appear to have it (according to http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/core/nsIDOMDocument.idl) |
| 00:59 | <jamesr__> | in blink they date back from when the property was defined in a file called khtml/ecma/kjs_dom.cpp |
| 01:08 | <esprehn> | Hixie_: it's not clear, it puts it in the DOM Manipulation Task Source, but the onload is just handled by the "delays the load event" logic |
| 01:08 | <esprehn> | Hixie_: Do things in the DOM Manipulation Task Source delays the load event ? |
| 01:12 | <esprehn> | I see, they are the same task source |
| 01:12 | <esprehn> | it'd be nice if the spec made this more clear, there's just a sentence in each section that mentions the task source |
| 01:14 | <esprehn> | Hixie_: it's unfortunate that autofocus is speced like this, it means there has to be a recalculate style before the onload event can fire, since we need to know the style to decide if something is focusable. |
| 01:18 | <esprehn> | I suppose developers should listen for DOMContentLoaded instead since onload is doomed to slowness |
| 03:36 | <MikeSmith> | damn can you devs at google please quit using the term "drive-by web" already |
| 03:36 | <MikeSmith> | I don't see any signs that anybody else is buying into that term |
| 04:29 | <matjas> | MikeSmith: how about <title>Test</title>? |
| 04:30 | <MikeSmith> | matjas: sounds good |
| 04:30 | <MikeSmith> | I will make it so |
| 04:39 | <MikeSmith> | matjas: pushed https://bitbucket.org/validator/validator/commits/4f4c6243d2da0b596304c830d9c642802c4d15cb |
| 04:39 | <MikeSmith> | thanks |
| 04:40 | <matjas> | MikeSmith: yay! good point about the other bugzilla tracker btw, i had forgotten about it |
| 04:42 | <MikeSmith> | matjas: yeah, until hsivonen has time to deal with load issues for the bugzilla.validator.nu server, that's probably the best place |
| 04:43 | <MikeSmith> | matjas: btw, about table@sortable, nobody implements that yet right? |
| 04:43 | <MikeSmith> | are there any polyfills for it yet? |
| 04:44 | <MikeSmith> | and about <data> it's implemented in the validator sources but not yet pushed to http://html5.validator.nu/ or http://validator.nu/ yet |
| 04:53 | <matjas> | MikeSmith: i don't think so, no. But note that it also errors on <data> in that context |
| 04:56 | <MikeSmith> | matjas: the <data> part should work at least at http://validator.w3.org/nu/ (which is running the current sources from the repo) |
| 05:00 | <Hixie_> | MikeSmith: <title>Page Title Here — Site Title Here</title> maybe? |
| 05:00 | <Hixie_> | esprehn: hm, it wasn't my intent to make that bad, but let me look... |
| 05:01 | <MikeSmith> | Hixie_: that'd work too I guess |
| 05:02 | <Hixie_> | esprehn: hm, i guess if you're so quick to finish loading the doc that you can fire 'load' almost immediately, you could end up with it sitting behind the many tasks that want to resolve style to figure out what can be focused |
| 05:02 | <Hixie_> | esprehn: note that DOMContentLoaded is on the same task source, so it would also be delayed |
| 05:03 | <Hixie_> | esprehn: also, technically, you are already required to resolve style before firing 'load' since you (per spec, anyway) are supposed to render between each task |
| 05:03 | <Hixie_> | esprehn: so you'd resolve style and layout and render between the parser task that stopped parsing, and the DOMContentLoaded/load tasks |
| 05:05 | <esprehn> | Hixie_: that's definitely not how browsers work, we're not going to resolve style or layout between tasks |
| 05:06 | <Hixie_> | esprehn: yeah, well, so long as it _looks_ like you do :-) |
| 05:07 | <Hixie_> | esprehn: for the autofocus thing, i can use another task source |
| 05:07 | <Hixie_> | not sure which exactly |
| 05:07 | <Hixie_> | user interaction task source maybe |
| 05:07 | <esprehn> | Hixie_: The sad thing is if you had <input autofocus> and then onload = function() { doSomethingThatInvalidatesStyle(); } the current spec means we calculate the style twice |
| 05:08 | <Hixie_> | oh i'm convinced of the badness here, don't worry |
| 05:08 | <esprehn> | :) |
| 05:09 | <Hixie_> | interesting, there is _some_ precedence for using the user interaction task source for non-user interaction tasks |
| 05:09 | <Hixie_> | calling input.select() does it |
| 05:09 | <Hixie_> | i guess that makes sense |
| 05:09 | <esprehn> | webkit and (old) opera both do autofocus inside "layout" |
| 05:10 | <esprehn> | ex. appendChild(input with autofocus); input.offsetTop; // focus happened inside this |
| 05:10 | <Hixie_> | woah |
| 05:10 | <Hixie_> | that's... special |
| 05:10 | <esprehn> | Firefox appears buggy, it frequently seems to not do autofocus at all |
| 05:11 | <Hixie_> | well, you're allowed to not focus |
| 05:11 | <Hixie_> | so you can get a synchronous 'focus' event during the call to offsetTop? |
| 05:11 | <esprehn> | yes |
| 05:11 | <Hixie_> | that's definitely pretty special |
| 05:11 | <esprehn> | webkit/blink and old opera all do it |
| 05:12 | <esprehn> | autofocus is handled at the time when the render tree is constructed |
| 05:12 | <Hixie_> | what happens if the dom is manipulated as this happens? |
| 05:12 | <esprehn> | same thing as mutation events |
| 05:12 | <Hixie_> | _mutation events_ happen during layout?! |
| 05:13 | <esprehn> | oh no :) |
| 05:15 | <Hixie_> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2470 |
| 05:15 | <Hixie_> | i don't understand why chrome can't find the node |
| 05:15 | <Hixie_> | does it calculate layout before running inline <script>? |
| 05:15 | <Hixie_> | does querySelector() calculate layout? |
| 05:16 | <Hixie_> | (change autofocus to autofocusx and it works) |
| 05:16 | <esprehn> | offsetTop calculates style (1) and then does layout (2), in between those two steps we fire the focus event handler |
| 05:16 | <Hixie_> | so if the focus handler moves the node in the DOM, the layout is what? using the old cascade? |
| 05:16 | <Hixie_> | but the new location? |
| 05:17 | <esprehn> | using the new location |
| 05:17 | <Hixie_> | but what style? |
| 05:17 | <esprehn> | focus causes another recalc style, so you end up with recalc style (1) -> focus event -> recalc style (2) -> layout -> return offset value |
| 05:18 | <Hixie_> | oh you check if the event changed things, and start over if it did? |
| 05:18 | <esprehn> | yup |
| 05:18 | <Hixie_> | what if the focus event added a new element with an autofocus attribute? |
| 05:18 | <esprehn> | that's why I was talking about mutation events |
| 05:19 | <esprehn> | I think we'll do it all over again, if you continued adding autofocus things we'll hang |
| 05:19 | <Hixie_> | i can't get chrome to operate as you describe. it seems to evaluate style earlier than when i call offsetTop. |
| 05:20 | <esprehn> | yeah, right now we do it inside the parser... |
| 05:20 | <esprehn> | I'm working on fixing that |
| 05:20 | <esprehn> | autofocus happens the second the parser inserts the child right now, there's no "posting a task" |
| 05:20 | <Hixie_> | wow, autofocus right now does a synchronous during-parse style recalc and layout? :-) |
| 05:20 | <esprehn> | no layout :) |
| 05:21 | <Hixie_> | well, still |
| 05:21 | <Hixie_> | wow |
| 05:21 | <Hixie_> | ok |
| 05:21 | <Hixie_> | well anyway |
| 05:21 | <esprehn> | blink and webkit right now calculate the style of every element as the parser inserts them |
| 05:21 | <Hixie_> | i suggest just doing it on a task |
| 05:21 | <Hixie_> | a task that's on the same task source as click events, etc |
| 05:21 | <Hixie_> | since you can't process those without a layout either |
| 05:23 | <esprehn> | yeah, I'll look into if we can do that |
| 05:23 | <Hixie_> | k, i'll update the spec accordingly. keep me posted. |
| 05:27 | <esprehn> | Hixie_: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2471 |
| 05:28 | <Hixie_> | ah, i see |
| 05:31 | <hsivonen> | whoa. Mark Pilgrim spotted on blink-dev |
| 06:15 | <MikeSmith> | hsivonen: EME discussions bring out the best |
| 07:33 | <MikeSmith> | hsivonen: about validation of role values with multiple tokens, I went ahead and pushed the code to the repo |
| 07:34 | <MikeSmith> | I'll send you the patches by e-mail for sanity checking when you ahve time |
| 07:34 | <MikeSmith> | for now, http://validator.w3.org/nu/?doc=http://w3c-test.org/vnu/syntax/relaxng/tests/html/attributes/role/001.notvalid.html |
| 08:45 | <Ms2ger> | Seagull umlaut? |
| 08:49 | <MikeSmith> | wha? |
| 08:50 | <Ms2ger> | https://twitter.com/hsivonen/status/370241051182637056 |
| 08:53 | <MikeSmith> | {: |
| 08:55 | <MikeSmith> | I like the mustachioed umlaut }: |
| 09:01 | <annevk> | I wonder if there's other bad features we should block inside a sandboxed <iframe> |
| 09:22 | <annevk> | GPHemsley: yt? |
| 09:27 | <annevk> | Updated my zip fragments gist: https://gist.github.com/annevk/6295844 |
| 09:28 | <annevk> | jamesr__: yo, .charset should be removed |
| 09:28 | <annevk> | jamesr__: we considered it for DOM and decided the web could most likely do without it |
| 09:28 | <annevk> | jamesr__: if that's not true... let us know |
| 09:44 | <zcorpan> | matjas: what license do you have on your contribution to v.nu, "<title>Test</title>" ? |
| 09:45 | <matjas> | zcorpan: hah, WTFPL |
| 09:46 | <matjas> | MikeSmith: while you’re at it, maybe you could review my pull request? https://bitbucket.org/validator/validator/pull-request/4/use-a-monospaced-font-for-some-form-fields |
| 09:46 | <zcorpan> | matjas: k :-) |
| 09:55 | <zcorpan> | MikeSmith: the role="" checking looks nice. (haven't QAed it though, just looked at your link) |
| 09:56 | <matjas> | MikeSmith: \o/ thanks |
| 09:56 | <MikeSmith> | matjas: yup (sorry I had forgot about & thinks for reminding me) |
| 09:57 | <MikeSmith> | zcorpan: cool |
| 09:58 | <zcorpan> | MikeSmith: can you point to the diff that implements the role filter? |
| 09:59 | <MikeSmith> | zcorpan: sure gimme a minute |
| 10:00 | <MikeSmith> | it's mostly new code |
| 10:00 | <MikeSmith> | new files |
| 10:00 | <MikeSmith> | https://bitbucket.org/validator/util/commits/859eabdaa10ad477ff55666b22ce1bb0ce9bcafe |
| 10:00 | <MikeSmith> | that's the first part |
| 10:01 | <MikeSmith> | zcorpan: main part of interest is https://bitbucket.org/validator/util/commits/859eabdaa10ad477ff55666b22ce1bb0ce9bcafe#Lsrc/nu/validator/xml/roleattributes/RoleAttributeFilteringContentHandlerWrapper.javaT178 |
| 10:03 | <MikeSmith> | zcorpan: code for integration into the servlet is simple https://bitbucket.org/validator/validator/commits/edb7fe0890f24ee764481e90db771d6f98af2e07 |
| 10:03 | <zcorpan> | MikeSmith: thx |
| 10:19 | <zcorpan> | MikeSmith: LGTM. didn't find any bugs from testing a few things ad hoc :-) |
| 10:19 | <MikeSmith> | super |
| 10:19 | <MikeSmith> | zcorpan: thanks for taking time to check it |
| 12:20 | <annevk> | idna-update keeps blocking my emails... |
| 12:20 | <annevk> | oh well, they'll get to www-tag |
| 12:22 | <SimonSapin> | annevk: did they black-list you? ;) |
| 12:23 | <annevk> | too many email addresses or some such |
| 12:23 | <annevk> | I think someone actually white-listed me because I couldn't post to the list at all before and wasn't interested in subscribing |
| 12:24 | <annevk> | SimonSapin: what does Servo do for IDNA? |
| 12:25 | <SimonSapin> | haha |
| 12:25 | <SimonSapin> | is this a real question? |
| 12:27 | <jgraham> | Sero priorities: a) Implement getElementById, b) Implement a whole web browser c) Implement IDNA |
| 12:27 | <jgraham> | *Servo |
| 12:27 | <annevk> | SimonSapin: well, since it has URL processing... |
| 12:28 | <SimonSapin> | I would be surprised if it’s supported at all |
| 12:28 | <SimonSapin> | right now HTTP is disabled because of recent changes in Rust’s IO |
| 13:05 | <gsnedders> | Servo: the web browser without HTTP support. |
| 13:06 | <SimonSapin> | who needs HTTP anyway |
| 13:06 | <gsnedders> | I hear SPDY is the future. |
| 13:07 | <Ms2ger> | HTTPbis |
| 13:07 | <jgraham> | Have to start with HTTP/0.9 only |
| 13:09 | <gsnedders> | jgraham: But then you also need to start off with content-type sniffing. |
| 13:10 | <jgraham> | gsnedders: Of course! But everyone knows that you implement specs one at a time in order and get full conformance to older specs before starting on newer ones. |
| 13:10 | <jgraham> | I particularly look forward to the HTML+ support |
| 13:12 | <gsnedders> | Personally I'm just waiting for HTML 3.0, so I can then file bugs to remove it. Because that's my hobby. |
| 13:21 | <GPHemsley> | annevk: Here now |
| 14:52 | <annevk> | GPHemsley: so the situation is this... |
| 14:52 | <annevk> | GPHemsley: we're gonna have to do some sniffing at the Fetch level |
| 14:52 | <annevk> | GPHemsley: to determine if the response is a ZIP thingie |
| 14:52 | <annevk> | GPHemsley: https://gist.github.com/annevk/6295844 has a high-level sketch of this feature |
| 14:53 | <annevk> | Hmm, HTTP... gotta spec that too someday |
| 15:04 | <GPHemsley> | annevk: Alright; one of the problems I ran into with ZIP was that a lot of various office suite file formats use it as a basis. |
| 15:04 | <GPHemsley> | annevk: What do you need me to do? |
| 15:04 | <GPHemsley> | Ms2ger: Did you ever implement the attribute sorting in anolis? |
| 15:05 | <annevk> | GPHemsley: I'd like you to think about how that makes sense architecturally or if we just need to accept sniffing at various layers... |
| 15:08 | <GPHemsley> | annevk: Is the old zip: proposal still in the running, or are you committed to media fragments? |
| 15:12 | <GPHemsley> | annevk: Also, doesn't fragment evaluation occur after the resource is loaded? |
| 15:12 | <Ms2ger> | GPHemsley, no, don't think so |
| 15:12 | <annevk> | I'm pretty sure nested URL schemes is not going to be a thing. |
| 15:13 | <GPHemsley> | annevk: Thus, load resource -> sniff type -> evaluate fragment -> navigate to fragment location |
| 15:13 | <annevk> | GPHemsley: at which point you might "load" a subresource and sniff type again |
| 15:14 | <GPHemsley> | annevk: Sgtm; is that a problem? |
| 15:14 | <annevk> | Normally fetch returns a resource which is sniffed. Now fetch retrieves a resource, sniffs it, and returns a subresource. |
| 15:15 | <GPHemsley> | That's the reality of the situation. I'm not sure you can get around it. |
| 15:15 | <annevk> | This changes where sniffing happens. It also changes where certain fragments are handled. |
| 15:15 | <GPHemsley> | You are indeed loading two different resources. |
| 15:15 | <annevk> | Yeah, that was my conclusion too. Was wondering whether there was another way. |
| 15:16 | <GPHemsley> | There may be, but I'm not seeing any problem with the obvious way. |
| 15:17 | <GPHemsley> | Other than the one raised by sicking about the nested fragments |
| 15:17 | <GPHemsley> | but that's not necessarily part of the network stack |
| 15:17 | <GPHemsley> | more a URL syntax issue |
| 15:18 | <GPHemsley> | what if you had #path=#anchor ? |
| 15:19 | <GPHemsley> | as in <a href="#path=subdir/file.html#subheader"> |
| 15:20 | <GPHemsley> | or perhaps use a different symbol or percent-encoding for the embedded fragment ID |
| 15:20 | <GPHemsley> | -ID |
| 15:20 | <GPHemsley> | hmm |
| 15:20 | <GPHemsley> | that part needs more thought |
| 15:20 | <GPHemsley> | but I think the sniffing issue is fine |
| 15:20 | <annevk> | #path=x&id=test exists. However, it's not entirely clear to me we want to support it in browsing contexts just yet. There's more complication there. |
| 15:21 | <GPHemsley> | one step at a time, I suppose |
| 15:21 | <annevk> | Just resource loads should be sufficient for the use cases that have come up thus far. |
| 15:21 | <GPHemsley> | but is there a reason you can't do file.zip/subdir/file.html ? |
| 15:21 | <GPHemsley> | or will that not work on the server side? |
| 15:22 | <annevk> | GPHemsley: The request to the server will be for /file.zip/subdir/file.html ... |
| 15:22 | <GPHemsley> | right |
| 15:22 | <GPHemsley> | hmm |
| 15:23 | <GPHemsley> | oh well |
| 15:25 | <GPHemsley> | but yeah, load resource -> sniff type -> evaluate fragment -> load subresource from path -> sniff type -> display |
| 15:25 | <GPHemsley> | it's probably OK to treat resources inside ZIPs as sandboxed in such a way that there is decreased functionality |
| 15:25 | <SimonSapin> | GPHemsley: is this recursive? :] |
| 15:25 | <SimonSapin> | a zip in zip |
| 15:26 | <GPHemsley> | SimonSapin: That's a good question |
| 15:26 | <SimonSapin> | http://en.wikipedia.org/wiki/Zip_bomb |
| 15:26 | <GPHemsley> | and it probably falls into the same boat as the regular (HTML) page fragments |
| 15:27 | <annevk> | SimonSapin: I don't think we'll support recursion |
| 15:28 | <GPHemsley> | What about file.zip?path= |
| 15:28 | <SimonSapin> | annevk: yeah, it sounds not very useful and potentially dangerous |
| 15:30 | <GPHemsley> | Another way is to treat the zip file as if it's an embedded domain |
| 15:30 | <GPHemsley> | as in, relative links inside the ZIP can't get out of the ZIP |
| 15:31 | <GPHemsley> | such that <a href="#anchor"> gets turned into file.zip?path=subdir/file.html&id=anchor |
| 15:31 | <GPHemsley> | or something |
| 15:31 | GPHemsley | shrugs |
| 15:32 | <GPHemsley> | oh, s/?/#/ |
| 15:32 | <GPHemsley> | force of habit |
| 15:32 | <GPHemsley> | but then if you have an embedded fragment for image dimensions, you'd need to deal with that |
| 15:33 | <GPHemsley> | so <a href="#xywh=160,120,320,240"> inside /package.zip#path=image.jpg would get navigated to /package.zip#path=image.jpg&xywh=160,120,320,240 |
| 15:34 | <GPHemsley> | given that media fragments seems to allow multiple name-value pairs with the same name, you might be able to get away with #path=image.zip&path=embedded.html |
| 15:35 | <GPHemsley> | but this is me trying to solve problems you didn't really ask me about :) |
| 15:37 | <GPHemsley> | annevk: Would this proposal be a generic one that could possibly be extended to all archive types? |
| 15:58 | <annevk> | GPHemsley: it's not clear to me we want to support all archive types |
| 16:42 | <Domenic_> | is someone working on making svg support css gradients? (is that already specced?) because dropping back to markup to declare these gradients is just feeling silly. |
| 16:43 | <annevk> | Domenic_: TabAtkins would know, can also check public-fx for that I think |
| 16:43 | <annevk> | Domenic_: it's the CSS/SVG coordination group; given that such coordination is happening, I suspect they're on it |
| 16:45 | <Domenic_> | annevk: neat, thanks. |
| 16:57 | <Ms2ger> | "Three RDFa Recommendations Published" |
| 16:57 | <Ms2ger> | (Offered without comment) |
| 17:12 | <weinig> | annevk: hello |
| 17:12 | <JonathanNeal> | I am writing an article on schemes and how to use them, common and proprietary, and I would love feedback, even if it's extremely critical. https://gist.github.com/jonathantneal/6301455 |
| 17:12 | <annevk> | weinig: hey hey |
| 17:12 | <annevk> | weinig: how are things? keeping hober in check on this b-day? |
| 17:13 | <weinig> | annevk: he's left me to "celebrate" |
| 17:13 | <annevk> | aah |
| 17:14 | <weinig> | annevk: I have a question about the dom spec promises, |
| 17:15 | <annevk> | weinig: k |
| 17:15 | <weinig> | annevk: there are quite a few places that state to run the resolver's resolve, and I am curious if one should ever set the resolved flag out side of the 3 real js functions exposed on the resolver itself |
| 17:15 | <annevk> | weinig: the long and short of it is that Domenic_ is working on something that matches better what TC39 wants |
| 17:16 | <weinig> | annevk: heh, ok |
| 17:16 | <annevk> | weinig: https://github.com/domenic/promises-unwrapping |
| 17:16 | <weinig> | annevk: 404 :( |
| 17:16 | <annevk> | weinig: yeah, the resolved flag is kinda broken |
| 17:16 | <annevk> | weinig: oh, didn't know Domenic_ made it private |
| 17:16 | <weinig> | maybe if I log in it will work |
| 17:17 | <Domenic_> | i can make it public i guess |
| 17:17 | <Ms2ger> | Yay, more design-in-back-rooms |
| 17:17 | <weinig> | Domenic_: thanks |
| 17:18 | <weinig> | annevk: I have most of it implemented already (just missing Promise.some and Promise.every) |
| 17:18 | <annevk> | weinig: gotta go, Domenic_ should be able to help out with further questions, we're pretty much in sync I think |
| 17:18 | <weinig> | annevk: I hope it doesn't change too muh |
| 17:18 | <weinig> | annevk: excellend |
| 17:18 | <weinig> | annevk: excellent |
| 17:18 | <weinig> | annevk: have a good night |
| 17:18 | <annevk> | weinig: so I think we might subset and remove fulfill() for now; details around scheduling might change |
| 17:19 | <Domenic_> | weinig: Ms2ger: annevk: public. |
| 17:19 | <annevk> | weinig: and the unwrapping might move entirely to the then() method; but by and large... |
| 17:19 | <weinig> | fair enough |
| 17:19 | <annevk> | thanks Domenic_ |
| 17:30 | <TabAtkins> | Domenic_: Yes, the idea is that fill/stroke will support the CSS <image> type as well. |
| 17:30 | <TabAtkins> | (And vice versa.) |
| 17:31 | <TabAtkins> | That is, SVG paint servers will work as <image> type in CSS. |
| 17:31 | <Domenic_> | TabAtkins: thank goodness. How's progress on that front? Distant-future, or living-spec-as-soon-as-someone-implements-it? |
| 17:32 | <TabAtkins> | The SVG-in-CSS part is roughly living spec, in Images 4 (check out element()). The CSS-in-SVG part is expected, but hasn't been written yet. |
| 17:33 | <Domenic_> | awww |
| 17:33 | <Domenic_> | (but yes, element() is great stuff.) |
| 18:21 | <zcorpan> | anyone want to finish reviewing https://critic.hoppipolla.co.uk/r/32 ? |
| 18:23 | <jamesr__> | annevk: i would tend to agree. i'm adding instrumentation to Blink for document.charset and document.defaultCharset to confirm |
| 18:23 | <jamesr__> | annevk: if it turns out those things do appear to be needed, i'll let whatwg know. if it turns out they aren't (which is hopefully the case) i'll let WebKit know they can probably remove them too |
| 19:18 | <zcorpan> | something that would be fun to do: subscribe to annevk's blog but with the posts from 10 years ago |
| 19:19 | <zcorpan> | so today is http://annevankesteren.nl/2003/08/object |
| 19:44 | <Domenic_> | oh woah i never noticed that "SVG sucks" changed to "URLs suck", haha |
| 19:55 | <TabAtkins> | Whatever he's currently play with sucks. |
| 20:04 | <Domenic_> | i feel like it was SVG for years. |
| 20:07 | <zcorpan> | it was svg since jan 2009 |
| 20:07 | <zcorpan> | dunno when it changed to urls |
| 20:08 | <zcorpan> | or what it was before svg |
| 20:08 | <nimbu> | annevk: ^^ |
| 20:08 | <nimbu> | inquiring minds want to know |
| 20:10 | <jarek> | I haven't seen anybody notable to say that SVG sucks |
| 20:10 | <jarek> | maybe except Alex Russel |
| 20:10 | zcorpan | just knows the svg date because he made the svg version and still has it at http://simon.html5.org/dump/ |
| 20:10 | <jarek> | CSS3 definitely sucks more with the prefix hell |
| 20:12 | <Hixie_> | saying svg "sucks" is an oversimplification |
| 20:12 | <Hixie_> | but it certainly has some serious issues |
| 20:13 | <Hixie_> | (the wg has done some work to mitigate those over time) |
| 20:58 | <aklein> | Hixie_: hi there. http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#dynamic-changes-to-base-urls seems to suggest that moving an <img> between document's shouldn't cause it to re-fetch any resources (and to simply keep displaying whatever it was displaying before), but quick tests suggests this isn't the case in either Blink or Gecko |
| 20:58 | <aklein> | (both re-resolve). Am I misreading the spec, or is there a bug somewhere? |
| 21:00 | <aklein> | (trying to figure out how URL resolution plays with <link rel=import> |
| 21:42 | <Hixie_> | aklein: probably a bug in the spec, the cross-document stuff isn't well documented |
| 22:28 | <Yuhong> | http://www.reddit.com/r/web_design/comments/1kw8yw/firefox_is_automatically_fixing_bad_html_making/ |
| 22:28 | <Yuhong> | "Firefox is automatically fixing bad html making it impossible for me to debug. Can I disable it? |
| 22:28 | <Yuhong> | "Firefox is automatically fixing bad html making it impossible for me to debug. Can I disable it?" |
| 22:51 | <MikeSmith> | for blink is there an OWP bug yet for NavigationController? |
| 22:52 | <MikeSmith> | hmm not even listed on http://www.chromestatus.com/features yet |
| 22:53 | <MikeSmith> | https://bugzilla.mozilla.org/show_bug.cgi?id=navigationcontroller for gecko |