| 00:01 | <takkaria> | Philip`: ah, thankyou |
| 00:01 | <takkaria> | Philip`: did you do that with an html5 parser? |
| 00:06 | <Philip`> | takkaria: It was with a (very old) HTML5 tokeniser |
| 00:06 | <Philip`> | though I might have hacked in something to make it respond to <script> etc correctly |
| 00:07 | <takkaria> | hmm |
| 00:08 | <takkaria> | it fits in with what I thought |
| 00:08 | <takkaria> | well, wildly guessed |
| 00:09 | <takkaria> | which was that attributes can be allocated in blocks of five |
| 00:09 | <Philip`> | I measured stuff like tag name lengths so I could preallocate enough space to make the common cases fast, but I can't find any of the results from that :-( |
| 00:10 | <takkaria> | I'd be very interested in seeing the longest attribute values found in real world content |
| 00:12 | <Philip`> | I saw tens of kilobytes in some <img alt> attributes |
| 00:13 | <takkaria> | I wonder what implementation limits there are in current Web browsers |
| 00:19 | <roc> | we have a 2GB string limit, other than that I think we're OK |
| 00:20 | <takkaria> | roc: I've been wanting to isolate mozilla's htmlparser to do speed tests with it, you don't know of anyone who's done something similar in the past do you? |
| 00:20 | <Philip`> | Hmph, there goes my plans for a microformat that embeds base-64 DVD rips in title attributes :-( |
| 00:21 | takkaria | chuckles |
| 00:21 | <roc> | I know people have tried to do that, but I don't have any details worry |
| 00:21 | <roc> | sorry |
| 00:21 | <takkaria> | ah, it was worth trying. thanks :) |
| 00:21 | <roc> | mrbkap might know |
| 00:22 | <roc> | my guess is our parser is not all that fast, other than bugfixes it has not received enthusiastic maintenance for several years. |
| 00:22 | <takkaria> | hmm |
| 00:23 | <takkaria> | I was going to have a play with it at some point and see if I could coax some more html5-style handling into it |
| 00:23 | <takkaria> | probably in the autumn, though, if at all |
| 00:23 | <roc> | I would dearly love someone to come up with a super-fast from-scratch HTML5 parser that we could integrate :-) |
| 00:23 | <roc> | but mrbkap is the person to talk to about such things |
| 00:26 | <takkaria> | ok, I might have to do that later |
| 00:26 | <takkaria> | he's working on html5 comment parsing in mozilla IIRC, right? |
| 00:27 | <takkaria> | yeah, he is: https://bugzilla.mozilla.org/show_bug.cgi?id=214476 |
| 02:18 | <Lachy> | JohnResig_, another selectos api feature request. http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864 If you know of or think of any other feature requests, particularly those that are already implemented in JS libraries, let me know |
| 02:35 | <JohnResig_> | Lachy: cool, thanks - I'll be sure to let you know |
| 08:13 | <Lachy> | Geez, why won't some people listen when I say no and explain why :root cannot be redefined?! http://lists.w3.org/Archives/Public/www-style/2008Jul/0298.html |
| 09:12 | <MikeSmith> | Philip`: you around? |
| 09:55 | <Philip`> | MikeSmith: Yes, but you aren't |
| 13:18 | takkaria | reads the SVG WG's proposal |
| 13:20 | <annevk> | Hmm, Mozilla is not going re-use XMLHttpRequest for Workers? -- https://bugzilla.mozilla.org/show_bug.cgi?id=437152 |
| 13:33 | <takkaria> | well, they want a case-preserving tokeniser |
| 13:33 | <takkaria> | though I can't see why, since as soon as they hit an <svg xmlns="..."> tag they hand it off to an XML processor anyway |
| 13:34 | <takkaria> | they also have a paragraph about using SVG in <img> which is mostly entirely irrelevant |
| 13:35 | <annevk> | case-preserving the toeknizer helps with <svg viewBox=... xmlns=...> |
| 13:35 | <annevk> | tokenizer, even |
| 13:36 | <roc> | yeah that whole section about SVG integration with HTML is irrelevant |
| 13:36 | <takkaria> | it doesn't, since they want everything from "<svg" to be passed |
| 13:37 | <roc> | I think the issue is that they don't want <SVG xMLns="..."> to do something |
| 13:38 | <takkaria> | it won't do the right thing anyway, because when it gets passed to the XML parser, the resulting tree will have no namespace or whatever |
| 13:42 | <takkaria> | what they have is implementable, but I really object to having to deal with *:math and *:svg |
| 13:43 | <annevk> | I guess I'm glad I'm going away for a few weeks while everyone else can have that discussion :) |
| 13:43 | <takkaria> | heh |
| 14:00 | <Lachy> | JohnResig_, yt? |
| 14:00 | <JohnResig_> | Lachy: yeah |
| 14:00 | <Lachy> | just a quick question about http://docs.jquery.com/Traversing/filter#expr |
| 14:01 | <Lachy> | I don't understand the use cases for that. How is the example given: $("p").filter(".selected"); any different from $("p.selected"); ? |
| 14:02 | <JohnResig_> | Lachy: it's not any different - but it allows for 1) queries to $("p") to be cached for later and 2) it allows you to manipulate $("p") before performing a later filter, weening down the number of elements. |
| 14:02 | <Lachy> | ok |
| 14:03 | <annevk> | document.forms.querySelector("#test") |
| 14:03 | <JohnResig_> | it's the same reason we have .find(), .not() and others |
| 14:03 | <Lachy> | I'll keep that in mind for the .matchesSelector() feature for selectors api 2 |
| 15:37 | <takkaria> | well, I'm sure I'll live to regret that |
| 15:41 | <howardr> | where is a good html5 validator? |
| 15:41 | <takkaria> | http://validator.nu/ |
| 15:42 | <howardr> | thanks |
| 15:42 | <annevk> | http://html5.validator.nu/ has the simple UI for that, fwiw |
| 15:44 | <jmb> | takkaria: works for me :) |
| 18:20 | <Lachy> | aargh! I really don't know how to respond to this? http://lists.w3.org/Archives/Public/www-style/2008Jul/0302.html |
| 18:21 | <Lachy> | How can I possibly make it any clearer that the answer is no and that's final, without being rude about it? |
| 18:24 | <annevk> | just say :root has a different purpose |
| 18:24 | <annevk> | there's :root so you can do :not(html):root > body > :context > a |
| 18:26 | <Lachy> | I already that :root has a different purpose. |
| 18:27 | <annevk> | might be worth repeating then, giving an example |
| 18:30 | <Lachy> | but I don't know when :root is ever useful, other than as a CSS hack to filter out browsers that don't support it. |
| 18:31 | <annevk> | if it's not useful, why not reuse it then? |
| 18:33 | <Lachy> | because it would require redefining it in Selectors, getting implementers to change their existing implementations of and and make sure that all implementers have changed it before they ship support for seletors api. |
| 18:34 | <Lachy> | and given the slow process, I'm not sure we could even get :context through before they ship selectors api |
| 18:34 | <annevk> | it seems it would be a pretty trivial change to Selectors |
| 18:35 | <annevk> | :root either matches the "context element" or in case that is not defined the "root element" |
| 18:35 | <Lachy> | plus, getting the CSS WG to agree to change an existing selector seems like it would be harder than introducing a new one. Plus, the name :root doesn't really make much sense when it doesn't have to be the root of the tree |
| 18:35 | <annevk> | it's the root of the tree you're interested in... |
| 18:35 | <Lachy> | e.g. "body :root div" would work, but that's clearly not the root of any tree. |
| 18:36 | <annevk> | it's the root of the context tree |
| 18:36 | <annevk> | having the CSS WG make changes to a single paragraph seems easier than the effort required to put out a new draft |
| 18:36 | <annevk> | a new spec, I mean |
| 18:37 | <Lachy> | that depends. The context element may be at the bottom of the tree, depending what it's used for. e.g. for the possible matchesSelector() method, foo.matchesSelector("div>:context") isn't at the root of a tree. |
| 18:44 | <annevk> | I don't know how matchesSelector is supposed to work |
| 18:46 | <annevk> | for the proposals currently on the table :root can work and I think it might be easier to introduce than :context |
| 18:50 | <Lachy> | I don't think it will work. matchesSelector() returns true or false depending on whether the element matches or not. |
| 18:51 | <annevk> | for that case you don't want :context |
| 18:51 | <annevk> | and :root can just match the root element |
| 18:53 | <Lachy> | what? why wouldn't that case want :context? |
| 18:53 | <annevk> | why would it? |
| 18:54 | <annevk> | how is :context different from *? |
| 18:54 | <Lachy> | in that particular case, it probably makes no difference |
| 18:55 | <Dashiva> | What if it's div > :context > span? |
| 18:55 | <Lachy> | but I still don't get how the name :root fits the purpose of this selector anyway. |
| 18:55 | <annevk> | Dashiva, that would never match the :context element itself |
| 18:56 | <Dashiva> | But it could match something or nothing |
| 18:56 | <annevk> | Lachy, are you bikeshedding over a name? |
| 18:57 | <Lachy> | annevk, I'm just trying to stop others from arguing with me over the name I chose. |
| 18:57 | <annevk> | Dashiva, sure, but that's besides the point of matchesSelector |
| 18:57 | <Lachy> | becuase :root doesn't work or make sense |
| 18:57 | <annevk> | Lachy, I don't think you've shown that :root doesn't work |
| 18:57 | <Lachy> | I clearly did. |
| 18:58 | <annevk> | you did? |
| 18:58 | <Dashiva> | I figured it was a "Is the hassle and incompatability from redefining :root worse than the hassle from defining :context" thing |
| 18:59 | <Lachy> | yes. and neither you nor Brad or Andrew on www-style have put forth convincing arguments for why :root should be reused. |
| 18:59 | <annevk> | I'd appreciate a pointer to evidence |
| 18:59 | <Lachy> | see www-style |
| 18:59 | <annevk> | I read www-style |
| 19:00 | <annevk> | :root seems easier to fit to this new purpose and doesn't really have a use without it anyway |
| 19:00 | <Lachy> | http://lists.w3.org/Archives/Public/www-style/2008Jul/0299.html |
| 19:00 | <annevk> | and the name works good enough |
| 19:00 | <annevk> | (that e-mail is marked as visited) |
| 19:00 | <Lachy> | so re-read it. |
| 19:01 | <Lachy> | it's confusing because if it's redefined, then in scoped stylesheets it will allow things like <style scoped>body.foo :root>div { ... }</style>, and that doesn't make sense cause it's not the root element. |
| 19:01 | <annevk> | I just did, I don't think your arguments are compelling |
| 19:02 | <Lachy> | sure they are, you're being silly. |
| 19:02 | <annevk> | that doesn't really seem productive |
| 19:03 | <Philip`> | If people are not compelled by the arguments, clearly the arguments are not compelling |
| 19:03 | <Lachy> | I'm not being compelled by their arguments either |
| 19:03 | <Dashiva> | Sounds like a job for... consensus-man |
| 19:04 | <Philip`> | I suggest dice |
| 19:04 | <Lachy> | so far, the only reason put forth has been ":root is mostly useless, so let's just redefine it to something that doesn't make sense" |
| 19:04 | <Lachy> | --> not a compelling argument! |
| 19:05 | <annevk> | I said that it was easier to redefine :root than to introduce a new pseudo-class as a separate specification |
| 19:06 | <annevk> | Also, the way you phrase the "only reason" is clearly way to biased to your own opinion for third parties to draw conclusions from |
| 19:06 | <bradee-oh> | Hixie: Acid3 doesn't think Mac IE 5.1 has javascript :( |
| 19:06 | <Lachy> | annevk, of course. We don't want third parties mistakenly beleiving your arguments are in any way compelling. :-) |
| 19:07 | <annevk> | I also think reusing :root makes sense and I actually believe that re-using :root for scoped style sheets was part of the original goals having talked to glazou |
| 19:07 | <annevk> | though I may recall incorrectly |
| 19:25 | annevk | tries to make a more compelling case for :context |
| 19:40 | Lachy | wonders how many times annevk is going to keep apologising for adding NSResolver to selectors api |
| 19:42 | <Lachy> | ok, so what should I make this feature string be? hasFeature("Selectors-API", "1.0");? Do I need to distinguish between implementations that choose to support NSResolver and those that don't? |
| 19:42 | <Lachy> | (I don't want to, I want to keep it as simple as possible) |
| 19:43 | <annevk> | Lachy, as long as it takes for someone to kill it |
| 19:43 | <annevk> | and the whole concept of it, that is |
| 19:44 | <othermaciej> | I think you should make either NSResolver or the replacement namespace resolution feature non-optional |
| 19:44 | <othermaciej> | optional features suck |
| 19:45 | <othermaciej> | but in general I agree on only one feature string |
| 19:46 | <annevk> | I agree that the namespace feature should never have been made optional |
| 19:46 | <annevk> | it should just have been removed |
| 19:46 | <Lachy> | othermaciej, the only reason I made it optional was because IE8 refuses to ship with support for the NSResolver, and I wanted to at least define sensible behaviour for them. |
| 19:47 | <Lachy> | so could I make it required, and still say that if implementations still don't support it, that they should show a NOT_SUPPORTED_ERR anyway? |
| 19:47 | <Lachy> | annevk, I would have removed it, but Mozilla wants it. |
| 19:47 | <annevk> | that's optional |
| 19:48 | <othermaciej> | removing would have been ok too |
| 19:48 | <annevk> | Mozilla is not the only player and so far they haven't really put forward any compelling cases |
| 19:48 | <othermaciej> | saying what to do if you violate a requirement of the spec seems pointless |
| 19:48 | <Lachy> | if I remove it and they still ship, then we're stuck with having to define whatever they ship with. |
| 19:49 | <annevk> | again, Mozilla is not the only player |
| 19:49 | <othermaciej> | if content starts depending on the resolver part of the feature, then it's not really optional |
| 19:49 | <annevk> | you're not saying we're stuck with defining what Microsoft ships with |
| 19:49 | <Lachy> | hmm, good point. |
| 19:49 | <othermaciej> | if content does not depend on it, then it doesn't matter what Mozilla ships with |
| 19:51 | <Lachy> | ok. Please raise these arguments on the mailing list and I'll deal with it tomorrow. |
| 19:51 | <Lachy> | othermaciej, you made a reasonably good case to use :scope. |
| 19:53 | <Lachy> | should I still refer to it in the spec as the "context element" (or contextual reference element that I have in my local draft), or find a more appriate name that aligns with :scope? |
| 19:53 | <othermaciej> | "scope element" |
| 19:53 | <Lachy> | ok |
| 19:53 | <Lachy> | I'll update it now and send in a new copy. |
| 19:53 | <othermaciej> | surprisingly, my naming debate entry seems to be more productive than most of the other content on the thread |
| 19:54 | <Lachy> | LOL :-D |
| 19:54 | <Lachy> | Bjoern and Hixie's comments were also productive |
| 19:55 | <Lachy> | I'm still waiting for a clarification from Bert, cause I didn't understand where he was coming from. |
| 22:16 | <gsnedders> | Hixie: FWIW, I agree with Julian (sp?) about the requirement for an opaque HTTP-like string for WebSockets |
| 22:18 | <jruderman> | Hixie: annevk says https://bugzilla.mozilla.org/show_bug.cgi?id=445166 is invalid per html5. is that intentional on your part? |
| 22:19 | <annevk> | someone should fix XML instead |
| 22:19 | <gsnedders> | jruderman: to answer on behalf of Hixie, it's because you can't rely upon external DOCTYPEs being read by XML processors, thereby meaning there's no point in allowing any entities as they can't be relied upon |
| 22:19 | <annevk> | fixing all the APIs around it doesn't scale long term |
| 22:19 | <gsnedders> | jruderman: (beyond those that are defined in XML itself) |
| 22:19 | <jruderman> | how about just including the same entities that HTML includes? |
| 22:20 | <gsnedders> | jruderman: See above. That needs a DOCTYPE. |
| 22:20 | <annevk> | in all of XML or just for innerHTML? |
| 22:20 | <annevk> | (note that HTML now has over 2000 entities) |
| 22:20 | <gsnedders> | for innerHTML it'd be silly to make it different to normal XML |
| 22:21 | <annevk> | well, that's one POV |
| 22:21 | <jruderman> | increasing compatibility between text/html and application/xhtml+xml isn't silly |
| 22:22 | <gsnedders> | They'll always have to be incompatible though. There's no point in pretending the two are. |
| 22:23 | <annevk> | it seems better to change XML to get more predefined entities, but that may be a hard battle |
| 22:23 | <Hixie> | gsnedders: which requirement? (re websocket) |
| 22:24 | <Hixie> | jruderman: yes, it is intended to work the same way as any xml content (that doesn't declare a dtd) |
| 22:25 | <gsnedders> | Hixie: "Read the first 85 bytes from the server. If the connection closes before 85 bytes are received, or if the first 85 bytes aren't exactly equal to the following bytes, then fail the Web Socket connection and abort these steps." for one |
| 22:25 | <gsnedders> | annevk: Yeah, in some ways we need that for RSS (people just blindingly using HTML content without escaping it, often just causing errors purely because of entities) |
| 22:26 | <annevk> | it's called XML5, but only has blog traction |
| 22:26 | <Hixie> | gsnedders: what's wrong with that? |
| 22:26 | <gsnedders> | That was on the list of things to help with over the summer, annevk, but too far down to be reached, I suspect |
| 22:26 | <gsnedders> | Hixie: I'll send a long email once I get home, but I mostly agree with Julian until then :) |
| 22:27 | <Hixie> | ok, but bear in mind that the main requirement from me is that the handshake be resilient |
| 22:27 | <gsnedders> | Yeah, sure |
| 22:27 | <Hixie> | leaving holes in the handshake through which you can pass inconvenient material wouldn't work |
| 22:27 | <Hixie> | i am in fact disappointed as to how much flexibility we already have |
| 22:30 | <Hixie> | jesus, the svgwg's proposal is longer than the entire checkin i made to support svg |
| 22:31 | <annevk> | apparently it addresses more than just the syntax issue |
| 22:32 | <othermaciej> | link? |
| 22:33 | <Hixie> | public-html |
| 22:33 | <annevk> | http://lists.w3.org/Archives/Public/public-html/2008Jul/att-0179/svg-html-proposal.html |
| 22:33 | <Hixie> | feedback from apple would be very interesting and would inform my response |
| 22:35 | <roc> | the entire section "Use of SVG Resources in HTML and CSS" is irrelevant and should be dropped |
| 22:36 | <othermaciej> | yeah it has nothing to do with this topic |
| 22:36 | <othermaciej> | I do not uinderstand the effect of the tokenizer changes |
| 22:36 | <othermaciej> | *understand |
| 22:36 | <annevk> | takkaria commented on that already |
| 22:36 | <Hixie> | well one big effect is killing performance |
| 22:37 | <Hixie> | hsivonen_ told me before going on vacation that he strongly objected to anything that involved making the tokeniser case-preserving because it would just kill his performance by order(s) of magnitude |
| 22:37 | <othermaciej> | I'm not sure what they are meant to do |
| 22:37 | <othermaciej> | are they trying to implement XML parsing in the HTML tokenizer formalism? |
| 22:38 | <gsnedders> | Why would that kill perf. though? Surely it's just a question of where you do the case-normalisation? |
| 22:38 | <roc> | I actually doubt that it would kill performance |
| 22:39 | <roc> | anyone who wants to round-trip HTML source (we do) will have to preserve case somewhere anyway |
| 22:39 | <annevk> | gsnedders, if you create an integer for the element during tokenization to match on during tree building it would be quite different if tokenization required preserving case |
| 22:40 | <Hixie> | his problem is that he normalises all strings to IDs, and having to do his normalisation in different ways for different tokens is crazy, as i understand it |
| 22:40 | <gsnedders> | ah |
| 22:40 | <Hixie> | he does case-preserving for roundtripping by remembering indexes into the original source |
| 22:40 | <Hixie> | which bypasses the entire problem |
| 22:40 | <roc> | then he can use that info to do the case-sensitive comparisons the SVG people want |
| 22:41 | <Hixie> | you have to do this for every single token |
| 22:42 | <othermaciej> | WebKit makes no effort to preserve case when parsing text/html |
| 22:43 | <othermaciej> | so it's certainly not the case that everyone has to preserve case someday |
| 22:43 | <othermaciej> | the html and xml parsers both intern atoms for tag names, either converting to lowercase or preserving case |
| 22:43 | <othermaciej> | would probably be a hassle to change that decision to be made late |
| 22:44 | <othermaciej> | instead of determined by whether it is the html or xml tokenizer |
| 22:44 | <othermaciej> | if that is indeed required |
| 22:44 | <Hixie> | that appears to be what is required |
| 22:44 | <Hixie> | but i haven |
| 22:44 | <Hixie> | 't studied it in detail yet |
| 22:44 | <Hixie> | and do not have an opinion of my own at this time |
| 22:45 | <annevk> | since they require parsing using an XML parser for the bits where it matters it seems to be a performance optimization at "best" |
| 22:45 | <othermaciej> | their ideas for fallback mechanisms both don't work |
| 22:45 | <roc> | seems to me the only place where case-sensitivity *matters* is the case-sensitive check for math/svg tag names and "xmlns" attribute |
| 22:45 | <othermaciej> | (at least as proposals for fallback in the current generation of UAs) |
| 22:46 | <Hixie> | wait where does the xml parser fall into this |
| 22:47 | <annevk> | the bit that says "Create a new XML parser"? |
| 22:47 | <Hixie> | woah |
| 22:47 | <Hixie> | well that's not going to fly |
| 22:47 | <Hixie> | we have a requirement that you be able to implemnt html5 without an xml parser |
| 22:47 | <roc> | why? |
| 22:48 | <Hixie> | because having to have two parsers just to poke at some microformats is a little excessive |
| 22:48 | <roc> | eh |
| 22:49 | <roc> | all browsers are going to have XML parsers in them |
| 22:49 | <roc> | most platforms have one |
| 22:49 | <Hixie> | browsers aren't the only implementations of html5 |
| 22:49 | <Hixie> | in fact right now they're in the minority :-) |
| 22:49 | <roc> | like I said, most platforms have one |
| 22:49 | <jcranmer> | roc: and drop support for DOS? |
| 22:49 | <Philip`> | It doesn't seem like it'd be that infeasible to implement an XML-fragment (minus doctype etc) parser as an extra HTML5 tree constructor mode |
| 22:50 | <Hixie> | that's probably how i would spec it if we did this |
| 22:50 | <Hixie> | but that seems like a lot of excess work for no good benefit |
| 22:51 | <Hixie> | how do they handle xml parse errors? |
| 22:51 | <Hixie> | i guess i should read this thing |
| 22:51 | <roc> | I don't see why they actually need to make tokenization case-sensitive |
| 22:52 | <Dashiva> | Someone suggested it was because they didn't want <SVG XMLNS in their lap |
| 22:52 | <othermaciej> | their proposal for XML parse errors seems to be, when you hit one you close all open XML element and resume parsing as HTML at the same character position |
| 22:52 | <othermaciej> | which seems like a weird compromise between draconian and tolerant |
| 22:52 | <roc> | Dashiva: they wouldn't get it that, because that wouldn't render anything |
| 22:53 | <roc> | The XML parser would create an <SVG> element with no namespace, and the author tries again |
| 22:53 | <Hixie> | they require <a> in svg to be written <svg:a> |
| 22:53 | <Hixie> | as i understand it |
| 22:54 | <Hixie> | this proposal seems to somewhat fail to achieve the goal maciej put forward |
| 22:54 | <Hixie> | of providing for svg the same level of author-friendliness as html has |
| 22:55 | <roc> | that goal is 100% incompatible with the SVG WG's goal of strict XML parsing |
| 22:55 | <Hixie> | yes |
| 22:55 | <gsnedders> | yay! simple consensus! |
| 22:56 | <Hixie> | wait, this proposal requires html in svg to be marked up as xhtml, too |
| 22:58 | <gsnedders> | oh yuk. |
| 22:59 | <annevk> | last thing I read about that was to embed text/html HTML through CDATA or something, similar to Atom |
| 22:59 | <annevk> | I didn't like it too much |
| 23:00 | <roc> | I don't think that's really a big deal |
| 23:00 | <jgraham> | CDATA? For real? |
| 23:00 | <Hixie> | this proposal would also totally break this page http://www.laroseweb.com/calcs/fans.php |
| 23:00 | <gsnedders> | It works, sure, and it would be compat. with SVG/XML, but it seems illogical within HTML |
| 23:01 | <Hixie> | it would knock out the stylesheet and the script |
| 23:01 | <roc> | many things make HTML in <foreignObject> less than ideal |
| 23:02 | <annevk> | Hixie, it would fail on &mathml; |
| 23:02 | <Hixie> | oh, true |
| 23:03 | <jgraham> | roc: I guess HTML in <foreignObject> will be one of the most useful features if the syntax doesn't suck so much that no one can get it right |
| 23:03 | <roc> | it really only works for fixed-size objects |
| 23:03 | <annevk> | aren't most of the HTML in <foreignObject> cases addressed by SVG effects through CSS? |
| 23:04 | <roc> | yes |
| 23:04 | <roc> | one of the main goals of SVG effects through CSS is to get around the fact that <foreignObject> prevents reasonable layout |
| 23:04 | <annevk> | I would expect SVG in HTML to be mostly used for iconic images and logos |
| 23:04 | <roc> | diagrams |
| 23:04 | <roc> | if you want to send a diagram in email it's going to be the only way |
| 23:06 | <Hixie> | bbiab |
| 23:09 | <takkaria> | I don't really have an opinion either way on how to do svg-in-html; even implenting an xml fragment parser in the html parsing algorithm wouldn't be that much of a code burden |
| 23:10 | <takkaria> | it wouldn't be great, but it's doable |
| 23:10 | <annevk> | would it be more work than what you have so far? |
| 23:10 | <takkaria> | I very much doubt it, really |
| 23:11 | <takkaria> | it just multiplies the number of testcases needlessly, I guess |
| 23:14 | <howardr> | does anyone know any good irc channels on js? |
| 23:14 | <takkaria> | I would much prefer just making sure implementations can export the SVG tree as well-formed XML, really, because that seems like by far the least effort on anyone's part |
| 23:14 | <roc> | irc.mozilla.org has #js, not sure if it's good :-) |
| 23:15 | <takkaria> | (though I'm just repeating what I said in my reply now, so I'll go back to fixing my parser...) |
| 23:15 | <Dashiva> | howardr: #javascript on efnet |
| 23:17 | <howardr> | thanks |
| 23:30 | <gsnedders> | Any feelings on handling of <!--begin-toc--><em>foo<!--end-toc-->bar? |
| 23:30 | <jcranmer> | a comment in the middle of a word? :-P |
| 23:30 | <gsnedders> | (with regards to the spec-gen, that is) |
| 23:31 | <gsnedders> | I feel like throwing a fatal error if the start and end comments don't have the same parent |
| 23:34 | <annevk> | gsnedders, just do whatever is easiest for weird stuff |
| 23:34 | <annevk> | (until we complain :) ) |
| 23:48 | <gsnedders> | Well, either I just let the behaviour be weird (everything after until the em tag closes vanishes), or I just throw a fatal error |
| 23:49 | <gsnedders> | I think the latter behaviour is more desirable |
| 23:49 | <gsnedders> | anyhow, g'nite |