| 06:16 | <nesta_> | good morning! |
| 06:55 | <jgraham> | TabAtkins: Assuming othermaciej was talking about http://lists.w3.org/Archives/Public/www-style/2012May/0215.html, my response is haha, yeah right |
| 06:56 | <jgraham> | Tying unprefixing to the release of a testsuite just seems like a way to prevent it happening |
| 06:58 | <jgraham> | It also creates bad incentives for writing tests since the goal of the tests will be to make the Process transition happen as fast as possible, not to make implemntations that are basically about the same interoperate on edge cases |
| 06:59 | jgraham | hasn't read the whole thread yet though |
| 07:03 | <jgraham> | and re: the followup on the thread, authors currently assume rough interop anyway when they blindly add -*-whatever properties. And they also assume rough interop between the - often mostly seperate-code - -webkit- implementations |
| 07:03 | <jgraham> | So you are suggesting a bar that is utterly at odds with reality |
| 07:07 | <jgraham> | AryehGregor: If you are there, this might be faster than email. I didn't understand your email to public-html-testsuite |
| 07:07 | <AryehGregor> | jgraham, which e-mail to public-html-testsuite? |
| 07:07 | <AryehGregor> | Did I make one recently? |
| 07:07 | <AryehGregor> | I don't recall. |
| 07:07 | <AryehGregor> | Oh, that one. |
| 07:08 | <AryehGregor> | jgraham, http://dvcs.w3.org/hg/editing/raw-file/583bf580775b/selecttest/collapseToStartEnd.html <-- Works. |
| 07:09 | <AryehGregor> | Because I have: <script src=http://w3c-test.org/resources/testharness.js></script>; |
| 07:09 | <AryehGregor> | If I had: <script src=/resources/testharness.js></script> |
| 07:09 | <AryehGregor> | Then it wouldn't work. |
| 07:09 | <AryehGregor> | Because that doesn't exist on dvcs.w3.org. |
| 07:09 | <jgraham> | Oh I see |
| 07:09 | <jgraham> | It's specific revisions of the *tests* that you want to link to |
| 07:09 | <jgraham> | Or open |
| 07:09 | <AryehGregor> | (By sheer coincidence, I was pointing out on Mozilla's Bugzilla that my use of w3c-test.org here makes my tests not importable into Gecko without a separate manual step.) |
| 07:10 | <AryehGregor> | Well, perhaps ideally the test suite should include whatever testharness.js was current at the time it was written. |
| 07:10 | <jgraham> | Yeah, it doesn't work for us either, for the same reason |
| 07:10 | <AryehGregor> | But at least it should work. |
| 07:10 | <AryehGregor> | find -type f -exec sed 's!http://w3c-test.org!!'; {} + |
| 07:10 | <AryehGregor> | That works fine. |
| 07:10 | <jgraham> | It works fine, but makes updating things a pain |
| 07:11 | <AryehGregor> | Do you auto-update? In Gecko it's manual, in principle. |
| 07:11 | <jgraham> | No, but basically it's such an effort that we often just don't do it |
| 07:11 | <jgraham> | Which is bad and I want to change |
| 07:11 | <AryehGregor> | Gecko updating of imported test suites is totally scripted. |
| 07:12 | <AryehGregor> | We have Ms2ger to thank for that. |
| 07:12 | <AryehGregor> | (as well as the fact that we support testharness tests at all) |
| 07:12 | <AryehGregor> | Although, updating the list of expected fails is still somewhat tedious. |
| 07:12 | <AryehGregor> | I'll probably want to work on that. |
| 07:13 | <jgraham> | The problem for us, in general, is that we might have local patches to a testsuite (not so much testharness.js testsuites, since they were designed to avoid some of the problems we have encountered) |
| 07:13 | <AryehGregor> | Version them in a DVCS and rebase. :) |
| 07:13 | <AryehGregor> | (we don't have local patches to any testsuites yet, but we haven't imported many either) |
| 07:13 | <jgraham> | Yes, that's the ideal world |
| 07:14 | <jgraham> | For legacy reasons, however, all our tests are on svn |
| 07:14 | <jgraham> | sometimes people have tried horrendous things like putting git repos inside svn |
| 07:14 | <AryehGregor> | Well, there's your problem . . . |
| 07:15 | <jgraham> | Yeah, I know |
| 07:15 | <jgraham> | I know how to fix the problem in an abstract way, I just need to make it work in a concrete way |
| 07:52 | <tabatkins_> | European morning! |
| 07:53 | <jgraham> | Is that another way of saying "bad morning"? |
| 07:53 | <jgraham> | or "Commie socialist bastards morning", perhaps? |
| 07:54 | <tabatkins_> | I'm in Europe, so clearly I need to differentiate this from normal morning. |
| 07:54 | <tabatkins_> | And by "normal", I of course mean "west-coast american". |
| 07:54 | <jgraham> | Pretty sure that nothing about the west coast of america is normal |
| 07:54 | <charlvn> | tabatkins_: how is west-coast american normal? |
| 07:55 | <tabatkins_> | charlvn: That should be self-evident. |
| 07:55 | <charlvn> | yeah exactly jgraham |
| 07:55 | <charlvn> | tabatkins_: i must be missing it ;) |
| 07:55 | <tabatkins_> | charlvn: Clearly you're not a citizen of Imperial America. |
| 07:55 | <charlvn> | tabatkins_: nope! lol |
| 07:55 | <charlvn> | The Backstroke of the West |
| 07:56 | <othermaciej> | tabatkins_: good euro-morning |
| 08:22 | <zcorpan> | arun++ for fixing fileapi :-) |
| 08:44 | <Velmont> | I'm back |
| 08:45 | <Velmont> | Oh, lost internet. Was going to write; I'm back on the mother-continent. So good euro-morning to all. |
| 08:48 | <jgraham> | Help, Velmont has been invaded by the Glazkov-mind-worms |
| 08:49 | <zcorpan> | woah. https://www.w3.org/Bugs/Public/show_bug.cgi?id=16945 |
| 08:50 | <Velmont> | jgraham: WAT? |
| 08:57 | <jgraham> | zcorpan: So, is he wrong or is the spec wrong? And are browsers following the spec? |
| 08:57 | <zcorpan> | jgraham: just commented in the bug |
| 08:58 | <zcorpan> | spec is wrong, but nobody follows the spec, it seems :-) |
| 08:58 | <jgraham> | Oh, I wonder if the tests are right, somehow? |
| 08:59 | <jgraham> | Otherwise how did everyone miss this? |
| 08:59 | <zcorpan> | is there a test for this case? |
| 08:59 | <jgraham> | I don't know |
| 08:59 | <jgraham> | If it was just that the spec was so obviously wrong that everyone did something different, I think someone at least would have reported the issue |
| 09:00 | <zcorpan> | yeah that's a bit weird |
| 09:03 | <zcorpan> | i don't see a test for that particular state transition |
| 09:15 | <annevk> | anyone know why Steam does not let you play games in offline mode? |
| 09:15 | <annevk> | kind of sucked on the flight back |
| 10:10 | <Dashiva> | annevk: There's supposed to be an offline mode for steam, but you have to enable it while online or something |
| 10:11 | <zcorpan> | LOL. Please go online to go offline. |
| 10:27 | <Philip`> | I assume the idea is that "go offline" means "lock my account so no other machine can log in as me while I'm offline, then go offline" |
| 10:28 | <Philip`> | to prevent many individuals sharing a Steam account and all playing at once |
| 10:28 | <Philip`> | (which is normally prevented by having the online service check you're only logged in once) |
| 10:34 | <jgraham> | AryehGregor: Thinking about it, W3C probably don't want you running tests directly on the DVCS server, so you could see that as a feature |
| 10:35 | <jgraham> | Hence w3c-test.org being an entirely seperate domain |
| 10:55 | <Philip`> | Maybe there should be a rev583bf580775b.w3c-test.org for every Hg revision |
| 14:54 | <jgraham> | OK, reading comprehension fail |
| 14:54 | <jgraham> | Why can't I get the script-inserted-external-script opt out to work? |
| 14:54 | <jgraham> | +raciness |
| 14:56 | <jgraham> | "In addition, whenever a script element whose "force-async" flag is set has a async content attribute added, the element's "force-async" flag must be unset." |
| 14:57 | <jgraham> | So if I create a script, set the async content attribute, then remove it again, I should be left with a script that has neither async nor force-async set, right? |
| 15:11 | <jgraham> | Oooh |
| 15:12 | <jgraham> | I see where I am wrong |
| 15:12 | <jgraham> | Nevermind me |
| 19:43 | <jgraham> | With the unload thing, is it a good assumption that XHR is the only use case? |
| 19:43 | <jgraham> | Won't peoplw want to do potentially-laggy IO to the local system on site exit? |
| 20:43 | <Ms2ger> | A copy of WordPerfect? What's that? |
| 20:45 | <Hixie> | well i usually say Microsoft Word, but i wanted to vary it a bit |
| 20:45 | <Hixie> | and i couldn't think of any other word processors :-P |
| 20:59 | <jgraham> | Wordstar! |
| 21:00 | <Ms2ger> | It's even in the spec! |
| 21:00 | <Philip`> | OpenOffice.org Writer? |
| 21:01 | <Philip`> | Maybe not the catchiest name |
| 21:01 | <Ms2ger> | LibreOffice? |
| 21:07 | <jgraham> | AbiWord? |
| 21:10 | <jgraham> | Oh look Wikipedia has a list http://en.wikipedia.org/wiki/List_of_word_processors |
| 21:11 | <Ms2ger> | Of course |
| 21:16 | <Hixie> | jgraham: i thought of lots of them after writing "WordPerfect" :-P |
| 22:23 | <Hixie> | anyone understand https://www.w3.org/Bugs/Public/show_bug.cgi?id=15645 ? |
| 22:26 | <Hixie> | lordy, https://www.w3.org/Bugs/Public/show_bug.cgi?id=15704 is going to be fun |
| 22:29 | <tabatkins_> | Hixie: Actually, "o.value = +a.value + +b.value;" is even shorter. ^_^ |
| 22:31 | <Hixie> | yeah but that acts weird if the value is e.g. '0xa' |
| 22:31 | <tabatkins_> | Okay, true. |
| 22:34 | <tabatkins_> | So, throwing an idea out before I post it to the list. |
| 22:35 | <tabatkins_> | We discussed in the SVGWG today about pulling SVG further into HTML. Specifically, allowing SVG elements to also work when in the HTML namespace. (Or, equivalently, adding all the SVG elements to HTML with the same meaning and rendering.) |
| 22:35 | <tabatkins_> | SVG is totally down with this. Will it work? |
| 22:36 | <Hixie> | what would it mean? |
| 22:36 | <Hixie> | e.g. what coordinate space would one use? |
| 22:37 | <Hixie> | what's the use case? |
| 22:37 | <tabatkins_> | Baby steps. First, imagine we're still in the current situation where you need an <svg> ancestor to establish your rendering mode. |
| 22:38 | <tabatkins_> | The benefit here is just that you can use createElement() rather than createElementNS. |
| 22:38 | <Hixie> | oh, just moving <Svg> to the html namespaces |
| 22:38 | <Hixie> | sorry, i misunderstood |
| 22:38 | <tabatkins_> | And that three of the four element collisions become meaningless. |
| 22:38 | <tantek> | so we can add xpath to the scrap pile? |
| 22:39 | <tantek> | XPath: because <a href> was too simple. |
| 22:39 | <Hixie> | tabatkins_: sounds like a painful transition, and it would require very close coordination between the groups, which is likely to be hard given that html hasn't really proven to be able to coordinate even within its own groups |
| 22:39 | <Hixie> | tabatkins_: but in principle it seems like what we should have done long ago |
| 22:40 | <tabatkins_> | Okay, so no killer problems besides, you know, actually writing things correctly? |
| 22:40 | <jamesr> | are there any element name collisions? |
| 22:40 | <tantek> | Tabatkins, perhaps you should propose SVG assimilation for the next HTML WG charter. |
| 22:40 | <tabatkins_> | jamesr: style, script, a, font. |
| 22:40 | <jamesr> | some of those may be in use |
| 22:40 | <tabatkins_> | jamesr: style, script, and a are *almost* identical in the two. Merging wouldn't be too painful. |
| 22:41 | <tabatkins_> | font is vastly different. Not sure how best to handle it. |
| 22:41 | <Hixie> | tabatkins_: well i wouldn't expect it to be a smooth transition, certainly |
| 22:41 | <tabatkins_> | Simple way is that createElement('font') just always makes an HTMLFontElement. |
| 22:41 | <Hixie> | tabatkins_: solving the problem of createElementNS() might be done more easily in other ways than this though |
| 22:41 | <Hixie> | tabatkins_: if that's the main problem |
| 22:41 | <tabatkins_> | Nah, it's just one (annoying) problem. |
| 22:42 | <tabatkins_> | Agree that createElementNS itself could just be fixed by letting it take "svg" as a string or something. |
| 22:42 | <tabatkins_> | But it means that <template> and DocumentFragment.innerHTML no longer need to worry about parsing SVG specially. |
| 22:43 | <Hixie> | why do they need to parse SVG specially anyway? |
| 22:43 | <Hixie> | oh right it's this whole parse mode stuff that's being discussed in webapps |
| 22:43 | <tabatkins_> | So that "frag.innerHTML = '<g><rect /></g>';" works the right way. |
| 22:43 | <Hixie> | how do you know what context node to use, etc |
| 22:43 | <Hixie> | well |
| 22:43 | <Hixie> | you'd still have that problem |
| 22:44 | <tabatkins_> | Why? |
| 22:44 | <Hixie> | because you'd still need to go into foreign mode |
| 22:44 | <tabatkins_> | Why? |
| 22:44 | <Hixie> | to handle the /? |
| 22:44 | <Hixie> | the /> i mean |
| 22:44 | <Hixie> | not /? |
| 22:44 | <tabatkins_> | Ah. That's not quite true. Instead just special-case the SVG elements to make /> meaningful. |
| 22:45 | <Hixie> | yikes |
| 22:45 | <tabatkins_> | Meh. |
| 22:45 | <Hixie> | i'm still not sure we've 100% dealt with the fallout of foreign mode |
| 22:45 | <tabatkins_> | The HTML parser contains worse. ^_^ |
| 22:45 | <Hixie> | i'm certainly not up for trying to rewrite all that |
| 22:45 | <tabatkins_> | I'm definitely up for trying. |
| 22:45 | <Hixie> | not without a really REALLY big payoff |
| 22:46 | <Hixie> | i guess my feeling here is that overall the cost is likely to be way higher than the benefit, but that might just be because i don't see what the benefits are |
| 22:46 | <Hixie> | but i see very high costs |
| 22:46 | <tabatkins_> | So, the payoff is that this makes it easier to *then* do seamless mixing without the <svg>/<foreignObject> barrier. |
| 22:46 | <Hixie> | i don't really follow why that's a win though |
| 22:46 | <tabatkins_> | The rendering issue is then pretty easy from a CSS angle. |
| 22:46 | <Hixie> | or what it would even really mean |
| 22:47 | <Hixie> | why would you want a <rect> in the middle of a <p>? |
| 22:47 | <Hixie> | or whatever? |
| 22:47 | <tabatkins_> | Why do you want an <svg><rect /></svg> in the middle of a <p>? |
| 22:47 | <Hixie> | same reason you'd want an <img> there |
| 22:47 | <tabatkins_> | Exactly. |
| 22:47 | <Hixie> | because you have an image |
| 22:47 | <Hixie> | that's not the same |
| 22:47 | <Hixie> | an <Svg> introduces a replaced element |
| 22:48 | <Hixie> | <rect> introduces... not sure what exactly |
| 22:48 | <tabatkins_> | As would a <rect>, once I define the rendering model. |
| 22:48 | <othermaciej> | tabatkins_: might be nice if it had always worked that way, but now it would create a chameleon namespace issue |
| 22:48 | <Hixie> | when would you want _just_ a rect? |
| 22:48 | <Hixie> | that seems very odd |
| 22:48 | <othermaciej> | sucks to have an element that can be in two different namespaces |
| 22:48 | <othermaciej> | see dbaron's well-known comment on the topic |
| 22:48 | <tabatkins_> | Hixie: If you, say, had some <pattern>s defined earlier in the doc, and are painting it with them? |
| 22:48 | <tantek> | like <a> ? |
| 22:49 | <tabatkins_> | othermaciej: I don't recall dbaron's comment. |
| 22:49 | <othermaciej> | <a> is annoying for a different reason (namespace collision if you ignore the namespace) |
| 22:49 | <Hixie> | mixing at that level seems like it would be a huge departure from svg's semantics while simultanesouly being kinda counter to the whole content/presentation split |
| 22:49 | <Hixie> | svg is media-specific, html is not |
| 22:49 | <Hixie> | it's fine to have well-defined places to integrate them |
| 22:49 | <Hixie> | but i don't really see what it means to have a <path> in the middle of a <label> |
| 22:49 | <tabatkins_> | SVG is exactly as media-specific as <img>. I don't understand why you believe <img> is okay but <rect> isn't. |
| 22:50 | <Hixie> | <img> or fine, so is <svg>, the point is that <rect> is like having five of the pixels of a PNG without the rest of it |
| 22:50 | <othermaciej> | tabatkins_: http://lists.w3.org/Archives/Public/www-archive/2009Feb/0065.html |
| 22:50 | <tabatkins_> | More important, though, is being able to mix HTML into SVG so you can get better handling of text and stuff, without <foreignObject> pain. |
| 22:50 | <Hixie> | why is <foreignObject> painful? |
| 22:53 | <tabatkins_> | Because it's an extra element that doesn't *do* anything. |
| 22:53 | <Hixie> | it introduces a viewport |
| 22:53 | <Hixie> | that's pretty important :-) |
| 22:54 | <tabatkins_> | Nah, that's already done by nesting <svg> if you need a new viewport, or by the root <svg> if you don't. |
| 22:57 | <Hixie> | it introduces a viewport with the dimensions and position where you want the nested HTML. We could say you could use <svg> instead, sure, but my point is that it does something, not nothing. |
| 22:57 | <tabatkins_> | Looking over dbaron's comment, it looks like his concerns are mostly only a problem if you (a) actually care about namespaces, and (b) don't fully integrate the DOMs of the two languages. |
| 22:57 | <Hixie> | it also does the important job of keeping the visual markup segragated from the media-independent markup, allowing us to have sane conformance criteria |
| 22:58 | <tabatkins_> | I'm still not understanding that objection. A <rect> is visual in the same way an <img> is, so the same conformance criteria apply. A <text> is media-independent in the same way a <p> is, so ditto. |
| 22:58 | <Hixie> | (we could certainly define what happens if we allowed mixing svg and html together, e.g. we could say shapes aren't in flow and so margins collapse between the <p>s in <p><circle/></p>, but that seems like it'd be hugely confusing for no benefit) |
| 22:59 | <Hixie> | <rect> isn't the same as <img> |
| 22:59 | <Hixie> | <rect is the same as the pixels in the PNG in the <img> that happens to form a rectangle |
| 22:59 | <Hixie> | > ^ |
| 22:59 | <shepazu> | Hixie: that's a pretty sexist conclusion |
| 22:59 | <tabatkins_> | Not if the <rect> is hosting a <pattern>, for example. |
| 23:00 | <Hixie> | it'd be like putting the 2D canvas on all HTML elements |
| 23:00 | <tabatkins_> | Are you under the impression that <rect> is just for drawing solid-color rectangles? |
| 23:00 | <shepazu> | where by "sexist", I mean "something I don't agree with" |
| 23:00 | <Hixie> | tabatkins_: i am familiar with <rect> |
| 23:01 | <tabatkins_> | Hixie: Then I don't understand why you keep implying that a <rect> (or generally, an SVG drawing element) can't be an "image" by itself. |
| 23:01 | <shepazu> | I wouldn't rather we not have to use <foreignObject> |
| 23:01 | <shepazu> | er… s/wouldn't/would/ |
| 23:02 | <Hixie> | tabatkins_: you can certainly form an image from a single <rect>, or a single <rect> with lots of supporting patterns and gradients and colour stops, or indeed a single path, or indeed many other things |
| 23:02 | <Hixie> | tabatkins_: just like you can form a bitmap from a collection of pixels |
| 23:02 | <Hixie> | tabatkins_: but so what? |
| 23:02 | <Hixie> | tabatkins_: just because you can have a <select> with a single <optgroup> doesn't mean we should allow <optgroup> anywhere in the DOM |
| 23:03 | <shepazu> | (you can also make an image using CSS) |
| 23:03 | <Hixie> | tabatkins_: there are many things about SVG that I would change if we were starting over, but getting rid of the clear boundaries of where the image starts and ends isn't one of them |
| 23:03 | <tabatkins_> | Interestingly, we *do* allow display:table-row anywhere in the document. |
| 23:03 | <Hixie> | if we were talking about putting SVG into CSS 'content' or some such, i would be totally fine with it |
| 23:03 | <tabatkins_> | Because it has a clear meaning, and you can infer the context. |
| 23:04 | <Hixie> | because CSS is not media-independent |
| 23:04 | <Hixie> | it's the presentation layer, like SVG |
| 23:04 | <Hixie> | it makes perfect sense in the CSS layer to talk about having an arrow or a pattern or a line here or there or whatever |
| 23:04 | <tabatkins_> | Dude, quit pulling out that argument. It's *wrong*. HTML has several presentational elements. |
| 23:05 | <Hixie> | i think while you consider that argument to be wrong we are unlikely to make progress in this discussion, since it is the core premise of much of my work :-) |
| 23:05 | <tabatkins_> | So trying to argue that adding variants of them is somehow anti-semantic is simply nonsensical. |
| 23:06 | <tabatkins_> | If it's ok to refer to SVG in an <img>, it's equally okay to embed SVG in an <svg>, and it's equally okay to embed a <rect> directly (from a semantic perspective). |
| 23:06 | <Hixie> | i've attempted to explain why i disagree |
| 23:06 | <tabatkins_> | Yes, but that particular reason is nonsense, as it's inconsistent with the current (reasonable) state of HTML. |
| 23:07 | <Hixie> | telling me that it's nonsense is not going to convince me |
| 23:08 | <Hixie> | but i respect that that is your opinion |
| 23:08 | <tabatkins_> | othermaciej: As far as I can tell, dbaron's comment hinges on you (a) caring about namespaces in general (rather than importing them for the purpose of *eliminating* them for practical purposes), and (b) not fully integrating the two languages. |
| 23:08 | <othermaciej> | tabatkins_: would support for svg elements in the svg namespace be removed? |
| 23:08 | <tabatkins_> | Hixie: You are asserting that <p>foo <rect/></p> is somehow wrong, but <p>foo <svg><rect /></svg></p> is okay. You can't justify that. |
| 23:09 | <tabatkins_> | othermaciej: That would be cool, but would greatly magnify the transition pain. |
| 23:09 | <othermaciej> | tabatkins_: if not, then I believe dbaron's criticisms apply |
| 23:09 | <othermaciej> | tabatkins_: if yes, it's probably a nonstarter from a compat perspective |
| 23:09 | <tabatkins_> | othermaciej: I agree they apply. I don't think they're as important as when dbaron raised them. |
| 23:10 | <tabatkins_> | (They may not even have actually been important when they were raised. I don't know what dbaron thought about namespaces in general in 2006.) |
| 23:10 | <Hixie> | tabatkins_: i am asserting that <p>foo</p> <line .../><line .../> <p>bar</p> should not be conforming because it is almost certainly going to occur only when authors are intentionally making their HTML files media-specific and that that is counter to the purpose of a semantic markup language. |
| 23:11 | <othermaciej> | I think all of dbaron's criticisms still fully apply to the svg-in-html-namespace proposal |
| 23:11 | <othermaciej> | (unless support for the svg namespace is dropped) |
| 23:11 | <tabatkins_> | Hixie: But that *precise* markup is okay if you wrap the <line>s in an <svg> element? |
| 23:11 | <othermaciej> | implementations will have to support the same element in both namespaces |
| 23:11 | <othermaciej> | svg even has the additional issue of namespace collisions, where svg:a != html:a and svg:font != html:font |
| 23:12 | <Hixie> | tabatkins_: i think it's fine to have a well-defined short list of ways to embed media-specific material, ideally in a manner that allows for fallback in other media, as that makes it clear where the media-specific content's boundaries lie. |
| 23:12 | <Hixie> | tabatkins_: (i'm not 100% happy that <svg> in HTML doesn't have well-defined fallback) |
| 23:12 | <tabatkins_> | SVG doesn't allow for fallback. (Ninja'd!) |
| 23:14 | <tabatkins_> | othermaciej: Well, dbaron didn't object along any of those lines when we discussed it over dinner. ^_^ |
| 23:14 | <tabatkins_> | He may have forgotten his previous position, of course. |
| 23:14 | <othermaciej> | could be |
| 23:14 | <Hixie> | i think there is a huge qualitative difference between <svg><line .../><line .../></svg> and <div><line .../><line .../></div>. The former clearly indicates to authors where the boundaries of their image lies. The latter makes it way harder to distinguish. |
| 23:15 | <Hixie> | i just don't see the problem with requiring <svg>, frankly |
| 23:16 | <tabatkins_> | Hixie: It's a meaningless wrapper element, morally equivalent to a wrapper <div>. ^_^ |
| 23:17 | <Hixie> | well, no, it introduces the coordinate space, defines a viewport, and various other things, but even if it were technically identical, it isn't _morally_ identical, and that's my whole argument |
| 23:17 | <othermaciej> | implementing svg without the <svg> wrapper would be slightly annoying, because of the issues pixie mentions |
| 23:18 | <othermaciej> | <svg> defines a coordinate space and a viewbox, without which other svg elements are meaningless |
| 23:18 | <tabatkins_> | That's just a CSS issue, actually. Not difficult. |
| 23:18 | <othermaciej> | you'd essentially have to add an "anonymous box" for the svg element |
| 23:18 | <tabatkins_> | You can default to a coordinate space of the containing block. |
| 23:18 | <othermaciej> | like anonymous table rows or the like |
| 23:20 | <Hixie> | i just don't see the advantage |
| 23:20 | <Hixie> | you'd almost always want the wrapper anyway to give the coordiante space and viewbox and various other things |
| 23:21 | <othermaciej> | anything is technically possible with enough effort |
| 23:21 | <othermaciej> | but I wonder also what the advantage is, beyond saving a few characters for svg start and end tags |
| 23:24 | <tabatkins_> | Avoiding namespace annoyances for the common case, and mixing HTML into SVG without the decently larger cost of <foreignObject> start and end tags. |
| 23:24 | <Hixie> | just rename <foreignObject> to <html> |
| 23:24 | <tabatkins_> | (Particularly since, in proper SVG, you need to provide the html and body tags.) |
| 23:24 | <Hixie> | and define it as taking "flow content" |
| 23:25 | <Hixie> | (or rename it <body>) |
| 23:25 | <Hixie> | (or <doc>) |
| 23:30 | <tabatkins_> | Hm. That doesn't fix the annoyance of the *NS functions, or simplify <template> parsing, though. |
| 23:34 | <Hixie> | we should fix the *NS thing using the new API we figured out but that never went anywhere |
| 23:34 | <Hixie> | <template> parsing is a separate issue that we need to resolve in general |
| 23:36 | <tabatkins_> | <template> parsing is either "manually provide a context element" or "infer a context element, almost certainly in the way that Raf is suggesting". |
| 23:38 | <roc> | eliding <foreignObject> would be much easier than eliding <svg> |
| 23:40 | <tabatkins_> | roc: I think it requires adding x/y/width/height presentational attributes to every HTML element. Kosher? |
| 23:41 | <Hixie> | and every MathML element |
| 23:41 | <roc> | not necessarily. Use their intrinsic widths and heights only, and use transforms to position them |
| 23:41 | <tabatkins_> | (Well, technically we could do it within @style, once we properly merge all the SVG attributes into CSS properties.) |
| 23:41 | <Hixie> | (and every unknown XML element if anyone wants to embed non-HTML non-MathML CSS-styled XML) |
| 23:41 | <tabatkins_> | Hixie: I'm not sure if it's reasonable to have MathML outside of a <math>. |
| 23:41 | <roc> | you could say it only works for HTML elements. |
| 23:42 | <tabatkins_> | Given that MathML's rendering model is much different than the existing CSS ones. |
| 23:42 | <tabatkins_> | (While SVG's layout model is just a slight variant on abspos.) |
| 23:43 | <Hixie> | tabatkins_: i think solving the "<foreignObject> problem" is as easy as just renaming it <doc> or introducing a new element <doc> that works like <fO> |
| 23:44 | <Hixie> | no reason to define new CSS stuff |
| 23:44 | <Hixie> | frankly though, who is hand-authoring SVG-embedding-HTML other than me? |
| 23:44 | <Hixie> | i.e. is it really that big a problem? |
| 23:45 | <tabatkins_> | Well, I certainly am. |
| 23:45 | <tabatkins_> | And for a lot of things, it's definitely easy to hand-author. |
| 23:53 | <Hixie> | if it's just you and me, i think we can punt the issue :-) |
| 23:54 | <Hixie> | if it's not, it may be worth creating a shorter name for that element |
| 23:55 | <tabatkins_> | It's not just us. ^_^ SVG is gradually actually being used by webdevs, as support finally reaches useful levels and people realize what it can do. |
| 23:56 | <tabatkins_> | CSS is also gradually integrating more into SVG, with properties that let you "plug in" SVG elements for advanced functionality (generally not the sort of thing you'll probably make in an SVG image editor). |
| 23:59 | <tabatkins_> | And a substantial fraction (maybe even a majority? I'd have to count) of the new features accepted for SVG2 are about increasing human-authorability. |
| 23:59 | <tabatkins_> | Adding features that are easy to handle if you're a computer and don't mind repeating yourself, but are difficult to write (and impossible to read) if you're a human. |