| 06:33 | <TabAtkins> | zewt: You should see the spec for FFTactics, particularly the interactions of Quick and reaction abilities with the turn order. |
| 07:29 | <asmodai> | Does Firefox' "show windows and tabs from last time" funtion the same as Chrome's "Continue where I left off", i.e. session cookies are kept after a browser restart? |
| 07:31 | <zcorpan_> | data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg"; viewBox="-1 -1 2 2"><style>svg { background:url("") } </style><circle r="1"/></svg> |
| 07:32 | <heycam> | zcorpan_, that's fun |
| 07:32 | <zcorpan_> | looks like presto and gecko don't use the background |
| 07:32 | <heycam> | zcorpan_, doesn't seem to work in Firefox, but I wonder if the <svg> were inline whether we paint backgrounds there? |
| 07:32 | <heycam> | zcorpan_, oh but then url("") wouldn't be an SVG document anyway |
| 07:35 | <asmodai> | Mmm, so if we cannot use the mark session cookie to be deleted on browser restart, I wonder how we need to deal with this for our certificate/token functionality. |
| 07:42 | <zcorpan_> | does ie10 still not support data urls from the address bar? |
| 07:42 | <zcorpan_> | or is that on purpose? |
| 08:07 | <MikeSmith> | hsivonen: fyi all the w3c vnu backends are now running under Java7 |
| 08:08 | <MikeSmith> | for the last day or so |
| 08:08 | <MikeSmith> | with no apparent problems so far |
| 08:22 | <MikeSmith> | zcorpan_: about http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/0174.html you're already working on a spec that relates to? |
| 08:22 | <MikeSmith> | (ViewportObserver API proposal) |
| 08:22 | <MikeSmith> | oh CSSOM View? |
| 08:22 | <zcorpan_> | MikeSmith: right |
| 08:23 | <MikeSmith> | ok |
| 08:24 | <MikeSmith> | is there some overlap with the thing in the Web Performance WG? |
| 08:24 | <MikeSmith> | https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html |
| 08:25 | <zcorpan_> | maybe that's a different solution to the same use case |
| 08:25 | <MikeSmith> | ok |
| 08:26 | <zcorpan_> | i haven't looked into it yet |
| 08:26 | <zcorpan_> | i wonder what <svg lazyload> is supposed to do |
| 08:26 | <zcorpan_> | <script lazyload>? please no |
| 08:26 | <MikeSmith> | man the name "Resource Priorities" for that spec seems like not such a great choice |
| 08:26 | <MikeSmith> | oh I though it was just for images |
| 08:27 | <MikeSmith> | have they scope-creeped it out to everything else already? |
| 08:27 | <zcorpan_> | seems so |
| 08:27 | <MikeSmith> | geez |
| 08:28 | <zcorpan_> | or just applied it to all the tags that load something, and some others too |
| 08:28 | <MikeSmith> | oh man |
| 08:28 | <MikeSmith> | just now seeing the actual <script src="Analytics.js" lazyload ></script> in there |
| 08:29 | <MikeSmith> | 974 ftw |
| 08:31 | <MikeSmith> | I don't remember anybody actually ever describing a problem around this for anything other than images |
| 08:37 | <zcorpan_> | what's the current thinking on naming of methods with both singular and plural forms? |
| 08:38 | <zcorpan_> | e.g. elementFromPoint (already exists) and elementsFromPoint |
| 09:18 | <annevk> | GPHemsley: I think the problem http://wiki.whatwg.org/wiki/Contexts has now is that <object> is always object-src per CSP. So either HTML has something special for it sniffing-wise, or the table is simply wrong. |
| 09:41 | <annevk> | Ms2ger: https://bugzilla.mozilla.org/show_bug.cgi?id=444380 |
| 09:44 | <zcorpan_> | annevk: you should have said that you have authority because you're on the TAG :-) |
| 09:45 | <zcorpan_> | why is memory an issue for svg but not for html? |
| 09:48 | <annevk> | SVG files have a tendency to have most of their information in an attribute value... |
| 09:48 | <annevk> | I don't buy it would be twice the memory though. You'd just to design a better storage solution. |
| 09:49 | <annevk> | I would buy that it sucks and maybe is not worth it... |
| 10:04 | <annevk> | http://lists.w3.org/Archives/Public/public-media-annotation/2013Jun/0008.html may have been a bit much, but geez... |
| 11:17 | <MikeSmith> | "Unfortunately, your comment about callback syntax is out of scope of this 3rd Last Call." |
| 11:22 | <Ms2ger> | Don't worry, it'll be in scope for the fourth |
| 11:40 | <annevk> | It seems we're implementing something much simpler anyway so maybe most of that work needs to ignored in the end anyway? |
| 11:42 | <zcorpan_> | MikeSmith: how could you forget about <!DOCTYPE &> & <!--&--> & <?&> & <!&> & <p &="foo"> & <foo&> & <svg><![CDATA[&]]></svg> & ..... ??? |
| 11:43 | <MikeSmith> | heh |
| 11:43 | <MikeSmith> | I knew I shouldn't have responded to that message |
| 12:17 | <zcorpan_> | hmmm. looks like Glenn made MediaList a constructor, but i see no discussion about that |
| 12:20 | <zcorpan_> | and a MediaList object created with the constructor can't be used for anything |
| 12:33 | <zcorpan_> | Ms2ger: poke https://bitbucket.org/ms2ger/anolis/pull-request/10/use-for-the-toc-in-w3c_compat-since-csswgs/diff |
| 12:56 | <annevk> | I'm flying to the Netherlands... "You are required to enter Advance Passenger Information (API) for your trip" I wonder what the Netherlands thinks they do not know about me... |
| 12:59 | <annevk> | Following the link reveals nothing. klm.com is such a great website. |
| 13:06 | <Ms2ger> | zcorpan_, gah. |
| 13:06 | <Ms2ger> | Later this week, I think |
| 13:08 | <zcorpan_> | Ms2ger: great :-) i'm not in a rush, i was just looking through my open tabs |
| 13:21 | <zcorpan_> | hmm, i tried to implement a new option for xref.py, but i get this error: anolis: error: unrecognized arguments: --xref-use-a |
| 13:21 | <Ms2ger> | Did you add it to ./anolis? |
| 13:23 | <zcorpan_> | aha. i didn't |
| 13:44 | <GPHemsley> | annevk: <object> is complex, because it basically has to be sniffed twice. |
| 13:45 | <GPHemsley> | annevk: http://www.whatwg.org/specs/web-apps/current-work/#object-type-detection |
| 13:46 | <Ms2ger> | Yay, single-page |
| 13:47 | <GPHemsley> | Ms2ger: Yeah, sorry |
| 13:47 | Ms2ger | didn't click :) |
| 13:48 | <GPHemsley> | annevk: object-src really seems to be more suited towards the plugin type of <object> |
| 13:48 | <GPHemsley> | annevk: (And <applet> doesn't really need to be sniffed, because it's always Java.) |
| 13:53 | <zcorpan_> | hmm, looks like i did a mistake. https://bitbucket.org/zcorpan/anolis/commits/featurebranches - how do i make the xref_use_a branch include only the last commit (compared to the default branch)? |
| 13:56 | <zcorpan_> | Ms2ger: ^ |
| 13:57 | Ms2ger | looks |
| 13:58 | <Ms2ger> | zcorpan_, so you want it on top of 5ce506b ? |
| 14:00 | <zcorpan_> | Ms2ger: yeah, i guess. unless it's better if i sync with upstream first |
| 14:00 | <Ms2ger> | No, that's fine |
| 14:01 | <Ms2ger> | hg up 5ce506b5da30d429083217fce4695013bf012a39 |
| 14:02 | <Ms2ger> | hg branch <foo> |
| 14:02 | <Ms2ger> | hg di -r 0c807914e393f0bcd87da4f3779c20f6955e70bc:7890a059a0a30f4887cc4044587c5216f2120b1a | patch -p1 |
| 14:02 | <Ms2ger> | hg comm -m "bar" |
| 14:02 | <Ms2ger> | I think |
| 14:03 | <Ms2ger> | And then strip the original |
| 14:03 | <zcorpan_> | <foo> should be something like xref_use_a_2 ? |
| 14:03 | <Ms2ger> | I suppose so, yes |
| 14:04 | <zcorpan_> | ok, i'll try |
| 14:06 | <matjas> | looks like pretty much all existing npm modules dealing with HTML entities are broken |
| 14:07 | <annevk> | GPHemsley: I guess what I'm saying is that the sniffing cannot be reconciled with CSP contexts and is sort of a separate thing later on |
| 14:07 | <matjas> | only 1 lib has the complete list of HTML5 entities as per http://www.whatwg.org/specs/web-apps/current-work/multipage/entities.json, and none of them support astral symbols at all |
| 14:07 | <matjas> | may need to write my own |
| 14:07 | <zcorpan_> | Ms2ger: looks like it did the trick. thanks! |
| 14:07 | <Ms2ger> | Np |
| 14:07 | <matjas> | </rant> |
| 14:08 | <GPHemsley> | annevk: For <object> or for everything? I think we could make it work, if we allow context switching. |
| 14:08 | <GPHemsley> | annevk: We'll likely need it for the browsing context anyway. |
| 14:10 | <annevk> | GPHemsley: I guess the alternative is that you say <object> uses the "<object> context" which implies object-src for CSP purposes and complicated rules for sniffing purposes |
| 14:10 | <annevk> | GPHemsley: however, it's not entirely clear to me whether Fetch and sniffing ought to be merged in this way |
| 14:11 | <annevk> | GPHemsley: sniffing might actually be okay as a local per API endpoint affair |
| 14:11 | <annevk> | Hmm, although for images you always want to sniff... Ugh. |
| 14:11 | <GPHemsley> | right |
| 14:13 | <annevk> | Maybe some contexts should leave it up to the caller and others do it automatically? |
| 14:13 | <annevk> | E.g. for connect-src you want to leave it up to the caller... For object-src prolly too given the complexity. |
| 14:14 | <annevk> | And also, we could leave it always up to the caller and define something like "image fetch" that does the right for images. |
| 14:17 | <GPHemsley> | I'm not clear on what the issue/potential conflict is here. The contexts are just a tunnel with which to travel when fetching a resource. It's OK if sniffing branches, because it's downstream from fetch. |
| 14:19 | <GPHemsley> | annevk: Oh, I see the issue. The "trigger" part. Hmm... |
| 14:19 | <annevk> | API, does a, Fetch (potentially blocked due to CSP), then potentially Sniff (depending on API), ... |
| 14:20 | <GPHemsley> | annevk: What are some of the possible APIs we're discussing here? |
| 14:20 | <annevk> | So CSP and Fetch need to become integrated, sniffing seems like a convenience |
| 14:20 | <annevk> | GPHemsley: everything on the platform that does a Fetch, simple example is <img> |
| 14:21 | <GPHemsley> | annevk: Right, but what is the "API"? HTML? |
| 14:22 | <annevk> | GPHemsley: <img> is an API, background-image is another |
| 14:22 | <GPHemsley> | hmm |
| 14:22 | <GPHemsley> | And when would the Sniff part differ by API? |
| 14:23 | <GPHemsley> | Presumably all APIs of a given context are dealing with the same realities on the Web |
| 14:23 | <annevk> | <img> does sniffing for images. XMLHttpRequest only sometimes ignores Content-Type, but does no real sniffing. |
| 14:23 | <GPHemsley> | Well, the connection context is one that requires a little more thought |
| 14:24 | <GPHemsley> | But I think the rest are fairly established |
| 14:25 | <annevk> | No, e.g. <script> and Worker both mostly ignore Content-Type, but Worker also ignores encoding |
| 14:25 | <annevk> | Both are script-src though. |
| 14:25 | <GPHemsley> | (The connection context was added to provide a home in the table for connect-src.) |
| 14:25 | <annevk> | And object-src covers <applet>/<object>/<embed>, which have vastly different sniffing rules |
| 14:26 | <GPHemsley> | <applet> doesn't really need sniffing, AFAICT. It's always Java. |
| 14:26 | <annevk> | Whereas in your table <object> is sometimes tied with image which is just wrong |
| 14:26 | <annevk> | GPHemsley: it's also always object-src |
| 14:26 | <GPHemsley> | And the sniffing for <object> is a superset of the sniffing for <embed> |
| 14:26 | <annevk> | As I said, the sniffing is distinct |
| 14:27 | <annevk> | And it's not clear that if we introduce a new similar context we want the same sniffing. |
| 14:27 | <annevk> | E.g. for <script> we added Worker but wanted different rules. |
| 14:28 | <GPHemsley> | So what do you propose? |
| 14:30 | <annevk> | I think we should marry CSP contexts and Fetch. Then for sniffing we should find the right level of abstraction. |
| 14:31 | <annevk> | I think for most cases handling the sniffing where the fetching for the API is defined is fine, as it's e.g. done for <object> today. We might want to introduce something like "image fetch" as there are many APIs that fetch images. |
| 14:32 | <GPHemsley> | annevk: So where does that leave http://mimesniff.spec.whatwg.org/#context-specific-sniffing ? |
| 14:33 | <GPHemsley> | (which was the whole reason I compiled the contexts list) |
| 14:34 | <annevk> | Those look like useful shorthands for the various APIs we have today, no? Although maybe some just want to inline that so the badness doesn't leak further... |
| 14:35 | <annevk> | And in some cases they might not be okay, e.g. the example of <script> vs Worker |
| 14:35 | <annevk> | Basically script does not do sniffing. It simply does not look at content-type at all. |
| 14:35 | <annevk> | Well, except to determine the encoding, in case of <script> (not Worker). |
| 14:36 | <GPHemsley> | So what determines the script type? The type hint? |
| 14:37 | <annevk> | The API. |
| 14:37 | <GPHemsley> | (Keep in mind that I'm totally fine with defining a sniffing algorithm to not actually do any sniffing.) |
| 14:37 | <GPHemsley> | Is Worker always JavaScript? |
| 14:37 | <GPHemsley> | (How do you call Worker, anyway?) |
| 14:38 | <annevk> | new Worker("url") |
| 14:38 | <annevk> | GPHemsley: yes |
| 14:38 | <GPHemsley> | So isn't that a connection context, not a script context? |
| 14:40 | <annevk> | GPHemsley: For Sniff, maybe. Not for CSP. |
| 14:40 | <GPHemsley> | Ah, I see |
| 14:41 | <GPHemsley> | hmm |
| 14:43 | <GPHemsley> | Well, I suppose CSP doesn't have to map cleanly onto the contexts... The CSP directives kinda form their own contexts anyway |
| 14:43 | <GPHemsley> | They apply at different levels anyway |
| 14:44 | <GPHemsley> | annevk: Are you OK with the "How to use a context" steps? |
| 14:44 | <annevk> | It seems you'd sniff before handling, no? |
| 14:44 | <annevk> | Potentially as one-step (e.g. as many image libraries do) |
| 14:45 | <annevk> | Also, it seems you can only set the no-sniff flag after you actually fetched it |
| 14:46 | <GPHemsley> | annevk: "Handle" refers to http://mimesniff.spec.whatwg.org/#handling-a-resource |
| 14:46 | <GPHemsley> | annevk: And Sniff allows the UA to decide that they don't want to sniff based on the URL before the type is determined. |
| 14:47 | <GPHemsley> | (Like a nosniff whitelist) |
| 14:47 | <annevk> | Again, if you don't fetch it, you don't have a resource |
| 14:50 | <GPHemsley> | Not sure I understand what you're getting at |
| 14:50 | <GPHemsley> | If you don't have a resource, you can abort the steps |
| 14:50 | <GPHemsley> | s/can // |
| 14:51 | <GPHemsley> | Step 2 |
| 14:55 | <annevk> | 2. "Set no-sniff flag on resource" 3. "Fetch resource" |
| 14:55 | <annevk> | You cannot do 2 without 3 |
| 14:55 | <GPHemsley> | ah |
| 14:55 | <GPHemsley> | well |
| 14:57 | <GPHemsley> | ok, so you're prefer steps 3 and 4 to be switched? |
| 14:57 | <jgraham> | annevk: FWIW I got the API thing from KLM too. Couldn't tell if I had filled it in right since it didn't really day what was required. Katie assumed that the mail was a scam. |
| 14:58 | <annevk> | jgraham: a scam that points to your actual booking? |
| 14:58 | <jgraham> | Well, yeah it quickly became clear it wasn't |
| 14:58 | <annevk> | GPHemsley: I think I'm a bit at a loss as to what the benefit of the sniffing contexts is |
| 14:59 | <jgraham> | But she has been trained to assume that unexpected mails asking for personal information aren't to be trusted |
| 14:59 | <annevk> | GPHemsley: there's a clear outcome of the CSP object-src context and why <object> needs to mention it |
| 14:59 | <annevk> | GPHemsley: it's not obvious that refactoring <object> with these sniffing contexts would be a win for the <object> spec |
| 15:00 | <annevk> | jgraham: fair enough |
| 15:00 | <GPHemsley> | annevk: I'm not sure I'm following. I compiled this list based on the existing concepts in HTML and CSS, in order to facilitate having different sniffing algorithms for each. The addition of CSP was per your request. |
| 15:01 | <annevk> | GPHemsley: "existing concepts"? |
| 15:02 | <GPHemsley> | annevk: Yes, these concepts are implicitly defined by the various parts of the HTML spec which detail sniffing. I just put a name on them. |
| 15:02 | <annevk> | And invented some more? |
| 15:03 | <GPHemsley> | Which ones do you consider "invented"? |
| 15:04 | <annevk> | script |
| 15:04 | <annevk> | plugin? |
| 15:06 | <GPHemsley> | Well, OK, the contexts weren't all based on explicit sniffing instructions in HTML. They were compiled based on every possible fetch point. |
| 15:06 | <annevk> | So, I'm behind the goal of getting CSS and HTML to agree on how to fetch an image and sniff the hell out of it. |
| 15:06 | <annevk> | But most of the other stuff defined in HTML is really HTML-specific and does not warrant abstraction I think. |
| 15:07 | <GPHemsley> | Well, the mimesniff spec has been created much to abstract sniffing out of the HTML spec. |
| 15:09 | <GPHemsley> | But all the sniffing algorithms need to be explicitly referenced by a calling spec. |
| 15:11 | <annevk> | "Abstract sniffing out" by itself is not enough of a goal. Having someone else maintain most of the details might be one. Having more specs use it might be another. |
| 15:11 | <annevk> | But too much abstraction comes at a cost. |
| 15:11 | <GPHemsley> | What is the cost here? |
| 15:12 | <annevk> | Shifting text around for no benefit is costly as people who once understood what's going on have to relearn. |
| 15:13 | <annevk> | And if it does not need to be referenced by other specs moving it away further from where the text is required can make the algorithm harder to follow (though sometimes easier) |
| 15:14 | <GPHemsley> | You seem to be speaking in hypotheticals. |
| 15:17 | <annevk> | GPHemsley: I have some experience shifting bits around and I'm questioning some of what you're doing here |
| 15:17 | <annevk> | GPHemsley: I don't think you've clearly illustrated the benefit other than "the goal of Sniff is to further abstract HTML" which I don't think is a worthy goal |
| 15:23 | <GPHemsley> | annevk: Yet you described two other possible goals that you do think are worthy, and would be fulfilled by the same outcome. |
| 15:25 | <annevk> | The only benefit is the image stuff, but I thought we already had that particular invocation point long ago... |
| 15:29 | <annevk> | I think it may have been partly my fault for encouraging you in this direction though. My apologies. That was mostly due to CSP/Fetch convergence which is necessary. (CSP necessitates changes to the Fetch algorithm.) |
| 15:33 | <Ms2ger> | Peanut gallery: |
| 15:33 | <Ms2ger> | Is matches() safe to unprefix? |
| 15:34 | <annevk> | Ms2ger: implementation of http://dev.w3.org/2006/webapi/selectors-api2/ ? |
| 15:34 | <Ms2ger> | Yep |
| 15:34 | <annevk> | Ms2ger: with relative selectors and all? |
| 15:35 | <annevk> | that's pretty interesting; I would have expected find/findAll to happen first |
| 15:35 | <annevk> | That IDL should use different variable names for querySelector and find... |
| 15:35 | <Ms2ger> | We've had mozMatchesSelector since forever |
| 15:35 | <Ms2ger> | Not sure how close it is to the spec |
| 15:35 | <annevk> | Ms2ger: that's way different |
| 15:37 | <Ms2ger> | Want to comment in bug 886308? |
| 15:37 | <annevk> | sure |
| 15:37 | <Ms2ger> | Ta |
| 15:38 | <annevk> | GPHemsley: so in general what you want is to make the minimal number of changes, until there's sort of sufficient build up of reasons for why the organisation of things should change; and to me it's not the case we're there for sniffing |
| 17:02 | <annevk> | I guess bz meant requiring type for XSLT, as data:text/xml,<?xml-stylesheet href="data:text/css,:root{background:lime}"?><test/> works fine. |
| 17:25 | <reyre> | is there a default display for WebVTT voice objects? |
| 17:25 | <reyre> | tooltips don't work in a video element currently |
| 18:04 | <TabAtkins> | reyre: What do you mean by "default display"? |
| 18:05 | <reyre> | TabAtkins: how should voice cues be displayed by default? should they be displayed? i.e. currently a voice tag is translated to a span with a title attribute that is the voice of the speaker |
| 18:05 | <reyre> | which would usually mean you could mouse over and see a tooltip |
| 18:05 | <reyre> | is that what we want? |
| 18:06 | <TabAtkins> | Ah, I dunno. |
| 18:06 | <reyre> | or would it make more sense to have something like "Title: Text" |
| 18:07 | <reyre> | TabAtkins: okay, i'll send an email to the mailing list, maybe we need some discussion about it or something |
| 18:07 | <TabAtkins> | That should be easy enough to do, btw, though I'm not sure that the ::cue() syntax allows it right now. Something like ::cue(voice::before) { content: attr(title) ": "; } |
| 18:08 | <reyre> | yeah an author could do that, but do we want a default display or something ? |
| 18:08 | <TabAtkins> | Dunno! |
| 18:08 | <reyre> | okay :) |
| 20:04 | <haelwenn> | hello |
| 20:05 | <haelwenn> | i want to add the twitter:domain thing on the wiki can someone do it or can someone create an account for me (username: lanodan) |
| 20:06 | <haelwenn> | are you all AFK/away ? |
| 20:06 | <haelwenn> | i give you a minute |
| 20:08 | <haelwenn> | ok the minute is pass i'll send an email |
| 20:08 | <jorgepedret> | I guess there's a bunch of us just reading, I'm new here and don't have access to anything :-) |
| 20:09 | <TabAtkins> | I believe we're moving to just allowing anything in <meta> anyway, so the wiki will become obsolete. |
| 22:51 | <Hixie> | rafaelw: ping (at your leisure) |
| 23:22 | <rafaelw> | hixie: poing. |
| 23:22 | <Hixie> | hey |
| 23:22 | <Hixie> | so i'm trying to integrate the template parser thing |
| 23:23 | <Hixie> | and i've got some questions :-) |
| 23:23 | <rafaelw> | sure. |
| 23:23 | <Hixie> | one is, if you have <table><template>text</template</table>, am i missing something, or do the suggested changes not handle the text right? |
| 23:24 | <Hixie> | seems like you'll end up in table text mode |
| 23:24 | <Hixie> | which will then trigger the foster parenting |
| 23:24 | <Hixie> | rather than the template parenting |
| 23:25 | <Hixie> | (i think we should probably just define an "insert" algorithm that handles the foster and template parenting hacks rather than doing it as now with "comefrom"-style programming, fwiw. but that's an editorial thing.) |
| 23:27 | <rafaelw> | when do you end up in table text mode? |
| 23:27 | <Hixie> | <table>text |
| 23:27 | <rafaelw> | but which token put you in table text mode? |
| 23:27 | <Hixie> | the "t" |
| 23:27 | <Hixie> | oh, i see, <template> will be the current node in the template case |
| 23:27 | <Hixie> | hmm, interesting |
| 23:28 | <Hixie> | oh that _is_ interesting |
| 23:28 | <rafaelw> | nope. the <template> put you in "template contents" mode. |
| 23:28 | <Hixie> | that means we never get to foster parent text _or_ comment nodes |
| 23:28 | <Hixie> | rafaelw: yeah, got it |
| 23:29 | <Hixie> | rafaelw: so, next question; is the lack of foreign content support intentional? |
| 23:29 | <Hixie> | or is it magically supported some way i can't tell :-) |
| 23:29 | <rafaelw> | what looks like isn't supported? |
| 23:29 | <Hixie> | like, <html><svg><template> |
| 23:30 | <rafaelw> | Well, in that case, it's a <template> in the svg namespace. |
| 23:30 | <rafaelw> | Which doesn't do much interesting. |
| 23:30 | <Hixie> | right |
| 23:30 | <Hixie> | that's intentional? |
| 23:30 | <rafaelw> | We can still make the call that <template> is even more magical and behaves the same in svg & mathml. |
| 23:30 | <rafaelw> | I'd say: not addressed yet. |
| 23:30 | <Hixie> | ok, cool |
| 23:30 | <Hixie> | thanks |
| 23:31 | <rafaelw> | We discussed this with Tab and kind of concluded that that could be left to the svg/mathml to champion. |
| 23:31 | <Hixie> | sgtm |
| 23:31 | <rafaelw> | svg/mathml *folks* |
| 23:31 | <rafaelw> | Anything else? |
| 23:31 | <rafaelw> | I'll review Robin's changes right now. |
| 23:31 | <Hixie> | not right now, but i'm still looking :-) |
| 23:32 | <rafaelw> | let me know =-) |
| 23:32 | <Hixie> | i think i might end up doing a separate merge from darobin's, i'm finding too many things i disagree with at an editorial level |
| 23:32 | <Hixie> | e.g. having the template parenting use comefrom-style prose as well as foster parenting doing that makes the whole insertion thing really hard to follow now |
| 23:32 | <Hixie> | so i think i should merge it all into one clear algorithm |
| 23:33 | <Hixie> | still just going through trying to understand it, right now, though |
| 23:35 | <Hixie> | rafaelw: oh, another question; is there some reason for section 7.2 in https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#creating-an-element-for-a-token ? |
| 23:35 | <Hixie> | the bit that talks about ownerDocument? |
| 23:35 | <Hixie> | it seems like every node will be inserted into another node, which forces the ownerDocument anyway, no? |
| 23:35 | <Hixie> | or is there some way you can end up with orphan nodes? |
| 23:36 | <rafaelw> | the issue is that the node needs to be constructed into the correct document. |
| 23:36 | <rafaelw> | If it's constructed in a "live" document, even transiently, it can have side effects. |
| 23:36 | <Hixie> | ah, interesting |
| 23:36 | <rafaelw> | The goal of template content is that it's inner. |
| 23:36 | <rafaelw> | inert. |
| 23:36 | <Hixie> | yeah |
| 23:43 | <TabAtkins> | rafaelw: Given that I'm an SVG folk, I think I should champion it. ^_^ |
| 23:44 | <TabAtkins> | I definitely know I'd like to be able to use <template> in SVG. |
| 23:44 | <Hixie> | should be simpler for svg than html, no crazy parsing rules to deal with |
| 23:44 | <Hixie> | well, except for shunting into a separate doc |
| 23:44 | <rafaelw> | Ah, those salt-of-the-earth SVG folk. Good people. |
| 23:44 | <shepazu> | I've always assumed that <template> would work in SVG, happy if you'll hande the details, TabAtkins |
| 23:45 | <Hixie> | btw did we ever come to a decision on how this works i xml? |
| 23:45 | <Hixie> | in |
| 23:49 | <TabAtkins> | Don't think so? |
| 23:50 | <rafaelw> | Well, the spec has some to say about XHTML, but not XML in general. |
| 23:50 | <rafaelw> | (also XSLT & XPath) |
| 23:53 | <Hixie> | xhtml and xml are basically the same thing for these purposes |
| 23:54 | <rafaelw> | so the spec doesn't answer this question for you? |
| 23:56 | <Hixie> | looks like the answer is, yes, we concluded that we were changing the xml parser :-) |
| 23:56 | <Hixie> | to have special rules specefically for nodes in[4~ the HTML namespace |
| 23:56 | <Hixie> | which isn't really new, it's just pushing what we had already a little further |
| 23:57 | <rafaelw> | yep. this was basically henri's requirement for supporting the whole plan. |
| 23:57 | <rafaelw> | (which i also happen to agree with(. |
| 23:57 | <rafaelw> | ). |
| 23:59 | <Hixie> | given that i am the last one to this party, it having been specced in both webapps and the htmlwg before i'd even begun, i wonder if i'm still the one who's gonna get the blunt end of the criticsm from the xml community... |
| 23:59 | <TabAtkins> | Hixie: How can you even ask that question? Of course you will. |