IRC log of svg on 2009-02-17

Timestamps are in UTC.

22:09:19 [RRSAgent]
RRSAgent has joined #svg
22:09:19 [RRSAgent]
logging to http://www.w3.org/2009/02/17-svg-irc
22:09:21 [trackbot]
RRSAgent, make logs public
22:09:21 [Zakim]
Zakim has joined #svg
22:09:23 [trackbot]
Zakim, this will be GA_SVGWG
22:09:23 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
22:09:24 [trackbot]
Meeting: SVG Working Group Teleconference
22:09:24 [trackbot]
Date: 17 February 2009
22:09:33 [ChrisL]
zakim, remind us in 9 hours to go home
22:09:33 [Zakim]
ok, ChrisL
22:09:46 [ChrisL]
rrsagent, this telcon spans midnight
22:09:46 [RRSAgent]
I'm logging. I don't understand 'this telcon spans midnight', ChrisL. Try /msg RRSAgent help
22:09:53 [ChrisL]
rrsagent, this call spans midnight
22:09:53 [RRSAgent]
I'm logging. I don't understand 'this call spans midnight', ChrisL. Try /msg RRSAgent help
22:10:04 [ChrisL]
rrsagent, this meeting spans midnight
22:10:36 [heycam]
heycam has joined #svg
22:19:27 [ChrisL]
zakim, who is here?
22:19:27 [Zakim]
sorry, ChrisL, I don't know what conference this is
22:19:28 [Zakim]
On IRC I see heycam, Zakim, RRSAgent, ChrisL, shepazu, anthony, ed_work, trackbot
22:20:13 [ed__]
ed__ has joined #svg
22:20:23 [heycam]
trackbot, start telcon
22:20:26 [trackbot]
RRSAgent, make logs public
22:20:28 [trackbot]
Zakim, this will be GA_SVGWG
22:20:28 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
22:20:29 [trackbot]
Meeting: SVG Working Group Teleconference
22:20:29 [trackbot]
Date: 17 February 2009
22:20:39 [heycam]
RRSAgent, this meeting spans midnight
22:38:01 [heycam]
Scribe: Cameron
22:38:03 [heycam]
ScribeNick: heycam
22:38:06 [heycam]
Topic: SVG in text/html
22:38:17 [heycam]
CL: so from reading your mail cameron, it seems there's no whitelist of element/attribute names?
22:39:14 [ChrisL]
s/no/a/
22:40:01 [heycam]
CM: correct, non-recognised element names will still become SVG elements
22:40:31 [heycam]
CL: so if we introduce new elements with mixed case names you'd need to modify HTML 5?
22:40:32 [heycam]
CM: yes
22:41:47 [heycam]
ED: if you find an HTML open tag as a child of an SVG tag, i'm wondering if it's useful for some HTML elements to be HTML elements as a child there
22:41:55 [heycam]
ED: e.g. the <link> element
22:42:10 [heycam]
ED: especially since SVG fragments in HTML won't have a way of referencing stylesheets except for <style>@import ... </style>
22:42:24 [heycam]
ED: of course you could put <link> outside the SVG fragment, but it'd make more sense to put it in the SVG
22:44:23 [ed__]
JW: why would you drop out of svgmode if the previous html element sibling was html rather than the parent element?
22:44:42 [ed__]
CM: there's a normal mode and a foreign mode in html5
22:44:55 [ed__]
...the stack of elements doesn't record which mode it's in I think
22:45:20 [ed__]
...so it would switch the mode on encountering an html mode, and then not switch back to foreign mode
22:45:37 [ed__]
s/encountering an html mode/encountering an html element/
22:45:45 [ed__]
...perhaps I'm wrong
22:46:06 [heycam]
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inforeign
22:47:26 [jwatt]
jwatt has joined #svg
22:49:33 [jwatt]
CM: what I think the HTML text actually says, is there are a hardcoded list of elements that will take us out of SVG mode by closing all the SVG parents
22:49:50 [heycam]
CM: and all other open tags will be placed in the SVG namespace
22:50:09 [jwatt]
ED: so only elements in the hardcoded list, and link is not one of those
22:52:53 [ed__]
DS: it seems less desctructive to add the string as its typed, rather than casefolding it to lowercase (or some defined case)
22:53:26 [ed__]
CM: in html it makes sense, but the casefolding happens in the tokenizer not in the parser
22:53:51 [ed__]
...so you'd need to store the input strings in the case it's in, regardless of which parsemode it's in
22:54:16 [ed__]
...there might be some speculative things you could do, but you might not know for sure until in the parser
22:54:50 [ed__]
DS: you're going through a step, so html is trying to optimize for tokenizing
22:55:20 [ed__]
...but you could have a whitelist of elements that you could compare to
22:56:16 [ed__]
...the list of tokens that need to have the correct casing, it shouldn't come from the html specification
22:56:28 [ed__]
...it should come from the implementations
23:01:59 [ed__]
CM: what about having the SVG WG defining the casefolding tables for attributes/elements?
23:02:21 [ed__]
CL: but it owuld be nicer if the casefolding happened only on html elements, not for svg/mathml fragments
23:02:36 [ed__]
DS: though that happens at an earlier phase (tokenization)
23:03:10 [ed__]
CM: there's a mail from hsivonen about speculative tokenization discussing this I think
23:04:17 [ed__]
DS: how much more expensive would it be to be casepreserving?
23:04:39 [ed__]
CM: probably depends on how many case-insensitive comparisons you'd need to do
23:05:14 [ed__]
...we could ask if it's feasible to remember the casing when in foreign content parsing mode
23:06:12 [heycam]
http://lists.w3.org/Archives/Public/public-html/2008Dec/0128.html
23:06:51 [ed__]
CM: this thread is slightly different
23:07:03 [ed__]
...he's saying tokenization is slightly different in foregin content mode
23:07:21 [ed__]
...while you're blocking for script you might want to continue tokenizing
23:07:56 [ed__]
...because it's different in foreign content mode, and script might change which mode youä're in some of that work might be wasted
23:08:56 [ed__]
...specifically he's saying that in foregin content the script tag is parsed differently in html and in svg...you can have cdata sections for example
23:09:25 [ed__]
...so if the tokenizer doesn't know which mode you're in then it would have had to made a guess
23:09:45 [ed__]
DS: almost all svg content uses the cdata section for scripts
23:10:23 [ed__]
JW: well, only when you're using a less than or greater than sign
23:11:19 [ed__]
CM: so we'd prefer if the case was kept like it was in the content
23:11:38 [ed__]
...that would also work for new elements that we add that the spec hasn't "blessed"
23:11:56 [ed__]
...we should however ask them, to see if there are problems with that approach
23:16:53 [ed__]
http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0151.html
23:17:10 [ed__]
CL: what about character encoding?
23:17:33 [ed__]
CM: probably the xml declaration would be parsed as a "weird element"
23:17:53 [ChrisL]
well, thats no bloody use
23:18:54 [heycam]
http://livedom.validator.nu/
23:18:56 [ChrisL]
so if I have an svg file, its in shift-jis say so it needs an xml declaration to state the encoding. then it gets wrapped in html, there is an xml encoding declaration in the middle and it breaks? thats bogus
23:20:07 [ed__]
http://dev.w3.org/html5/spec/#the-input-stream
23:21:38 [ed__]
CM: but it would be useful to guess the encoding based on the xml declaration, in that algorithm
23:21:53 [ed__]
...but there mght be evidence that those are commonly incorrect
23:22:02 [ed__]
...but the meta charset might be wrong as well
23:23:54 [ed__]
...utf8 is the default encoding for svg, so that would be the most useful to have as the default even if served as text/html
23:25:30 [ed__]
...if the xml declaration is omitted, that is utf8, and that is served as text/html, and the document have some characters that might cause the algorithm to try to guess the encoding, I'd like to make sure that it's utf8
23:26:59 [ed__]
ED: this seems like something we should ask them for, unless it happens already
23:27:43 [heycam]
CM: we could check that the html encoding guessing algorithm doesn't already take into account an XML declaration, and if it doesn't,
23:28:00 [heycam]
CM: suggest to them that it does, as that would help both XHTML served as text/html and whole SVG documents served as text/html
23:34:10 [ed__]
http://dev.opera.com/articles/view/mama-document-encodings/
23:44:53 [ed__]
JW: scripts might break if they do document.documentElement.currentScale and expecting the SVGSVGElement as root, because when served as text/html there'll be an <html> element as the root
23:45:46 [heycam]
CM: could we suggest the use of document.rootElement rather than document.documentElement in SVG scripts?
23:47:49 [heycam]
JW: the SVG would be sized to 150px high
23:47:55 [heycam]
JW: the height of the <body> is auto by default
23:48:00 [heycam]
JW: and the intrinsic height of the SVG is 100%
23:48:08 [heycam]
JW: so since 100% cannot be resolved against auto, it defaults to 150px
23:48:56 [heycam]
DS: that's the current CSS rules, we could change it for this case
23:49:09 [heycam]
JW: there have been countless people upset about the defualt of <body> being auto
23:49:41 [heycam]
JW: so i wouldn't be sure that we'd make good headway on that
23:50:27 [heycam]
CM: so is there any reasonable solution to this?
23:51:26 [heycam]
CM: what about just saying in the "initial mode" (or "before head" or whatever it's called) if you get an <svg> open tag you don't imply the <html> and <head>?
23:52:25 [heycam]
CM: what's the height of the initial containing block?
23:52:31 [heycam]
JW: it's the height of the viewport
23:52:35 [heycam]
CM: so that would solve the problem
23:56:06 [heycam]
CM: although if you had a <blockquote> under the <svg>, that might be a problem since you can't pop off elements until an HTML element
23:56:12 [heycam]
ED: what about SVG doctype?
23:56:22 [heycam]
ED: we want to change the "before html" mode
23:56:48 [heycam]
ED: do we want to change the initial insertion mode to recognise SVG doctypes and do something special?
23:57:51 [heycam]
ED: if you put an SVG DOCTYPE and serve it as text/html, you would get a parse error currently
23:58:18 [heycam]
CM: i don't think it's a goal for us to have any wellformed SVG documents served as text/html be conformant HTML documents
00:04:32 [heycam]
ED: so currently, an SVG doctype at the top would force the document to be in quirks mode
00:04:48 [heycam]
CM: i think it would be better to be standards mode
00:05:22 [heycam]
CM: should that be dependent on whether the first tag is <svg>?
00:05:40 [heycam]
CM: e.g. <!DOCTYPE svg><html> being in standards mode doesn't seem right
00:27:05 [heycam]
[we discuss these issues and write down what we agree on]
00:31:05 [heycam]
we agree on standards mode
00:31:19 [heycam]
there's no legacy content that requires different css handling or whatever
00:36:01 [heycam]
ED: ok next point, magic namespaces
00:37:07 [heycam]
ED: so that's allowed in their proposal?
00:37:18 [heycam]
CM: yes, <svg> with no xmlns will become an <svg:svg> element but be a conformance error
00:37:37 [heycam]
JW: so that wouldn't allow copy/pasting that content out of the HTML into an image/svg+xml document
00:38:14 [heycam]
CM: it is a conformance error, so if you fix that (=> add the xmlns attribute), you can copy/paste it out
00:38:54 [heycam]
CM: (assuming no text/html content is in foreignObject)
00:38:59 [heycam]
JW: that's a good compromise then
00:39:45 [heycam]
ED: it would still be generating the correct DOM, so if you serialize it, you would still get exportable image/svg+xml content
00:39:57 [heycam]
JW: and copy/pasting into the HTML document wouldn't be a problem
00:40:31 [heycam]
ED: next is magic xlink:href namespace
00:40:36 [heycam]
ED: so you don't need to declare the xlink prefix
00:40:42 [heycam]
ED: but you can if you do it correctly
00:42:39 [heycam]
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#adjust-foreign-attributes
00:42:55 [heycam]
CM: so all xlink:* attributes are whitelisted for magic namespaces
00:43:05 [heycam]
ED: if we allow xmlns:xlink to be magic, why require the prefix at all?
00:44:01 [heycam]
CM: then some more conformant content cannot be copied out into image/svg+xml
00:54:46 [heycam]
JW: i prefer that if you do xmlns:xlink="garbage" then xlink:href would break
00:55:04 [heycam]
CM: i don't think they'd want to track scope to do that for subtrees
00:55:07 [heycam]
JW: ideally it would
01:16:05 [heycam]
CM: next is <SVG XMLNS=...> being conforming
01:16:11 [heycam]
JW: i'd like to it be nonconforming
01:16:12 [heycam]
ED: me too
01:16:22 [heycam]
CM: but nonconforming but working?
01:16:23 [heycam]
ED: yes
01:17:11 [heycam]
JW: it does prevent you from copy/pasting out to image/svg+xml
01:17:25 [heycam]
JW: it would cause more problems for authors; you might save the occasional author who mistypes the case
01:17:29 [heycam]
ED: how many authors would do that?
01:17:43 [heycam]
JW: you probably will cause more problems with copy/pasting between text/html and image/svg+xml
01:17:57 [heycam]
ED: in most cases, tools will generate SVG, and i've never seen incorrect casing of attribute/element names
01:31:56 [heycam]
ED: if you convert HTML to XHTML, you still have to do case fixups
03:05:15 [heycam]
CM: next point is unrecognised element names in foreign content
03:05:23 [heycam]
CM: contrary to my mail, they get created in the SVG namespace
03:06:11 [heycam]
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inforeign
03:06:32 [heycam]
CM: the last choice in that state
03:06:54 [heycam]
"Insert a foreign element for the token, in the same namespace as the current node."
03:07:28 [heycam]
ED: but the case is still lowercase there
03:08:04 [heycam]
http://paste.lisp.org/display/75642 -- bookmarklet to make visible any comments
03:29:53 [heycam]
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#coercing-an-html-dom-into-an-infoset
03:34:06 [jwatt]
CM: does it matter if prefixed SVG elements are not supported?
03:34:09 [ed__]
ED: i'm ok with not allowing prefixes on svg elements in html, most tools generate non-prefixed svg elements anyway
03:34:27 [jwatt]
JW: do you know any that do?
03:34:49 [ed__]
ED: not one that I can think of atm
03:35:35 [jwatt]
JW: I think I've only seen it used in XML SVG, where SVG in inline in XHTML
03:36:07 [ed__]
ED: yes, i've seen it in XHTML+SVG content, handcoded only though
03:36:23 [jwatt]
JW: right
03:37:19 [heycam]
DS: i don't think we should discard the ability to have prefixed SVG elements lightly
03:37:27 [heycam]
CM: would that be a fixed prefix ("svg:")?
03:37:37 [heycam]
CM: then it would be similar to what we'll propose for xlink attributes
03:37:47 [ed__]
ED: i think that if we allow prefixes then there isn't much value unless custom namespaces are supported as well in svg fragments
03:38:59 [ed__]
JW: i've never seen content other than 'svg' for svg content that used prefixes
03:39:39 [ed__]
s/content other/a prefix other/
03:40:12 [jwatt]
JW: except for demonstration purposes
03:40:58 [heycam]
<!DOCTYPE html><body><a:b><script>alert(document.body.firstChild.localName)</script>
03:41:53 [ed__]
data:text/html,<!DOCTYPE html><body><a:b><script>alert(document.body.firstChild.localName)</script>
03:43:06 [jwatt]
JW: so if the comments in the current HTML5 draft mean that we would get a colon in the localName, CSS rules matching on tag in the SVG would break
03:43:46 [jwatt]
JW: so the draft doesn't support prefixed SVG tags
03:44:21 [jwatt]
ED: the question is when/if it is useful to support
03:44:50 [jwatt]
CM: if you have a lot of mixing back and forward between namespaces
03:44:58 [jwatt]
ED: you don't really get that now
04:29:09 [jwatt]
JW: CDATA parsing: if the HTML5 parser does not create CDATASection nodes, node.nodeType will return a different value
04:30:34 [jwatt]
CM: so e.g. scripts looking for nodes of type TEXT_NODE might get unwanted CDATA, or script looking for CDATA would not find anything
04:30:48 [jwatt]
ED: edge case
04:31:20 [jwatt]
JW: would it take much to have HTML5 cleate CDATA_SECTION_NODE nodes?
04:31:34 [jwatt]
JW: might as well minimize differences if it's easy
04:35:46 [jwatt]
CM: when you do:
04:35:48 [jwatt]
CM: <script>
04:35:49 [jwatt]
CM: <![CDATA[
04:35:51 [jwatt]
CM:
04:35:52 [jwatt]
CM: ]]>
04:35:54 [jwatt]
CM: </script>
04:35:55 [jwatt]
CM: you'd end up with three nodes if parsed as XML, but only one if parsed as HTML5
04:36:12 [jwatt]
CM: so script depending on getting the second child node, for example, would get null
04:36:52 [jwatt]
s/three nodes/three nodes under the script element/
04:58:10 [ed__]
ED: so clashing html5 / svgt12 elements are: video, audio and textArea
05:16:36 [jwatt]
action: jwatt to Create a an errata item on the Error Processing Rules section to mention what SVG Tiny 1.2 does, and that a future version of Full will go the same route
05:16:36 [trackbot]
Created ACTION-2473 - Create a an errata item on the Error Processing Rules section to mention what SVG Tiny 1.2 does, and that a future version of Full will go the same route [on Jonathan Watt - due 2009-02-25].
05:19:56 [jwatt]
JW: we should make tests to enable us to check whether an HTML5 parser behaves the way we'd prefer or not
05:31:54 [heycam]
[discussions about <foreignObject>, <desc> and <title> switching to the secondary insertion mode]
05:52:02 [shepazu]
http://groups.google.com/group/openweb-group/browse_thread/thread/b1e4fc8f0ec43160/6fef98a601f892fe?lnk=raot#6fef98a601f892fe
06:30:56 [heycam]
heycam has joined #svg
06:33:45 [heycam]
http://www.whatwg.org/specs/web-apps/current-work/multipage/named-character-references.html
06:37:27 [heycam]
data:text/html,&amp%20c
06:51:55 [heycam]
http://livedom.validator.nu/
07:03:17 [heycam]
RRSAgent, make minutes
07:03:17 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/02/17-svg-minutes.html heycam
07:04:47 [heycam]
RRSAgent, bye
07:04:47 [RRSAgent]
I see 1 open action item saved in http://www.w3.org/2009/02/18-svg-actions.rdf :
07:04:47 [RRSAgent]
ACTION: jwatt to Create a an errata item on the Error Processing Rules section to mention what SVG Tiny 1.2 does, and that a future version of Full will go the same route [1]
07:04:47 [RRSAgent]
recorded in http://www.w3.org/2009/02/17-svg-irc#T05-16-36
07:04:49 [heycam]
Zakim, bye
07:04:49 [Zakim]
Zakim has left #svg