See also: IRC log
<trackbot> Date: 17 February 2009
trackbot, start telcon
<trackbot> Meeting: SVG Working Group Teleconference
<trackbot> Date: 17 February 2009
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
CL: so from reading your mail cameron, it seems there's a whitelist of element/attribute names?
CM: correct, non-recognised element names will still become SVG elements
CL: so if we introduce new elements with mixed case names you'd need to modify HTML 5?
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
... e.g. the <link> element
... especially since SVG fragments in HTML won't have a way of referencing stylesheets except for <style>@import ... </style>
... of course you could put <link> outside the SVG fragment, but it'd make more sense to put it in the SVG
<ed__> JW: why would you drop out of svgmode if the previous html element sibling was html rather than the parent element?
<ed__> CM: there's a normal mode and a foreign mode in html5
<ed__> ...the stack of elements doesn't record which mode it's in I think
<ed__> ...so it would switch the mode on encountering an html element, and then not switch back to foreign mode
<ed__> ...perhaps I'm wrong
<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
CM: and all other open tags will be placed in the SVG namespace
<jwatt> ED: so only elements in the hardcoded list, and link is not one of those
<ed__> DS: it seems less desctructive to add the string as its typed, rather than casefolding it to lowercase (or some defined case)
<ed__> CM: in html it makes sense, but the casefolding happens in the tokenizer not in the parser
<ed__> ...so you'd need to store the input strings in the case it's in, regardless of which parsemode it's in
<ed__> ...there might be some speculative things you could do, but you might not know for sure until in the parser
<ed__> DS: you're going through a step, so html is trying to optimize for tokenizing
<ed__> ...but you could have a whitelist of elements that you could compare to
<ed__> ...the list of tokens that need to have the correct casing, it shouldn't come from the html specification
<ed__> ...it should come from the implementations
<ed__> CM: what about having the SVG WG defining the casefolding tables for attributes/elements?
<ed__> CL: but it owuld be nicer if the casefolding happened only on html elements, not for svg/mathml fragments
<ed__> DS: though that happens at an earlier phase (tokenization)
<ed__> CM: there's a mail from hsivonen about speculative tokenization discussing this I think
<ed__> DS: how much more expensive would it be to be casepreserving?
<ed__> CM: probably depends on how many case-insensitive comparisons you'd need to do
<ed__> ...we could ask if it's feasible to remember the casing when in foreign content parsing mode
<ed__> CM: this thread is slightly different
<ed__> ...he's saying tokenization is slightly different in foregin content mode
<ed__> ...while you're blocking for script you might want to continue tokenizing
<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
<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
<ed__> ...so if the tokenizer doesn't know which mode you're in then it would have had to made a guess
<ed__> DS: almost all svg content uses the cdata section for scripts
<ed__> JW: well, only when you're using a less than or greater than sign
<ed__> CM: so we'd prefer if the case was kept like it was in the content
<ed__> ...that would also work for new elements that we add that the spec hasn't "blessed"
<ed__> ...we should however ask them, to see if there are problems with that approach
<ed__> CL: what about character encoding?
<ed__> CM: probably the xml declaration would be parsed as a "weird element"
<ChrisL> well, thats no bloody use
<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
<ed__> CM: but it would be useful to guess the encoding based on the xml declaration, in that algorithm
<ed__> ...but there mght be evidence that those are commonly incorrect
<ed__> ...but the meta charset might be wrong as well
<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
<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
<ed__> ED: this seems like something we should ask them for, unless it happens already
CM: we could check that the html
encoding guessing algorithm doesn't already take into account
an XML declaration, and if it doesn't,
... suggest to them that it does, as that would help both XHTML served as text/html and whole SVG documents served as text/html
<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
CM: could we suggest the use of document.rootElement rather than document.documentElement in SVG scripts?
JW: the SVG would be sized to
... the height of the <body> is auto by default
... and the intrinsic height of the SVG is 100%
... so since 100% cannot be resolved against auto, it defaults to 150px
DS: that's the current CSS rules, we could change it for this case
JW: there have been countless
people upset about the defualt of <body> being auto
... so i wouldn't be sure that we'd make good headway on that
CM: so is there any reasonable
solution to this?
... 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>?
... what's the height of the initial containing block?
JW: it's the height of the viewport
CM: so that would solve the
... 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
ED: what about SVG doctype?
... we want to change the "before html" mode
... do we want to change the initial insertion mode to recognise SVG doctypes and do something special?
... if you put an SVG DOCTYPE and serve it as text/html, you would get a parse error currently
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
ED: so currently, an SVG doctype at the top would force the document to be in quirks mode
CM: i think it would be better to
be standards mode
... should that be dependent on whether the first tag is <svg>?
... e.g. <!DOCTYPE svg><html> being in standards mode doesn't seem right
[we discuss these issues and write down what we agree on]
we agree on standards mode
there's no legacy content that requires different css handling or whatever
ED: ok next point, magic
... so that's allowed in their proposal?
CM: yes, <svg> with no xmlns will become an <svg:svg> element but be a conformance error
JW: so that wouldn't allow copy/pasting that content out of the HTML into an image/svg+xml document
CM: it is a conformance error, so
if you fix that (=> add the xmlns attribute), you can
copy/paste it out
... (assuming no text/html content is in foreignObject)
JW: that's a good compromise then
ED: it would still be generating the correct DOM, so if you serialize it, you would still get exportable image/svg+xml content
JW: and copy/pasting into the HTML document wouldn't be a problem
ED: next is magic xlink:href
... so you don't need to declare the xlink prefix
... but you can if you do it correctly
CM: so all xlink:* attributes are whitelisted for magic namespaces
ED: if we allow xmlns:xlink to be magic, why require the prefix at all?
CM: then some more conformant content cannot be copied out into image/svg+xml
JW: i prefer that if you do xmlns:xlink="garbage" then xlink:href would break
CM: i don't think they'd want to track scope to do that for subtrees
JW: ideally it would
CM: next is <SVG XMLNS=...> being conforming
JW: i'd like to it be nonconforming
ED: me too
CM: but nonconforming but working?
JW: it does prevent you from
copy/pasting out to image/svg+xml
... it would cause more problems for authors; you might save the occasional author who mistypes the case
ED: how many authors would do that?
JW: you probably will cause more problems with copy/pasting between text/html and image/svg+xml
ED: in most cases, tools will
generate SVG, and i've never seen incorrect casing of
... if you convert HTML to XHTML, you still have to do case fixups
CM: next point is unrecognised
element names in foreign content
... contrary to my mail, they get created in the SVG namespace
CM: the last choice in that state
"Insert a foreign element for the token, in the same namespace as the current node."
ED: but the case is still lowercase there
http://paste.lisp.org/display/75642 -- bookmarklet to make visible any comments
<jwatt> CM: does it matter if prefixed SVG elements are not supported?
<ed__> ED: i'm ok with not allowing prefixes on svg elements in html, most tools generate non-prefixed svg elements anyway
<jwatt> JW: do you know any that do?
<ed__> ED: not one that I can think of atm
<jwatt> JW: I think I've only seen it used in XML SVG, where SVG in inline in XHTML
<ed__> ED: yes, i've seen it in XHTML+SVG content, handcoded only though
<jwatt> JW: right
DS: i don't think we should discard the ability to have prefixed SVG elements lightly
CM: would that be a fixed prefix
... then it would be similar to what we'll propose for xlink attributes
<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
<ed__> JW: i've never seen a prefix other than 'svg' for svg content that used prefixes
<jwatt> JW: except for demonstration purposes
<ed__> data:text/html,<!DOCTYPE html><body><a:b><script>alert(document.body.firstChild.localName)</script>
<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
<jwatt> JW: so the draft doesn't support prefixed SVG tags
<jwatt> ED: the question is when/if it is useful to support
<jwatt> CM: if you have a lot of mixing back and forward between namespaces
<jwatt> ED: you don't really get that now
<jwatt> JW: CDATA parsing: if the HTML5 parser does not create CDATASection nodes, node.nodeType will return a different value
<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
<jwatt> ED: edge case
<jwatt> JW: would it take much to have HTML5 cleate CDATA_SECTION_NODE nodes?
<jwatt> JW: might as well minimize differences if it's easy
<jwatt> CM: when you do:
<jwatt> CM: <script>
<jwatt> CM: <![CDATA[
<jwatt> CM: ]]>
<jwatt> CM: </script>
<jwatt> CM: you'd end up with three nodes under the script element if parsed as XML, but only one if parsed as HTML5
<jwatt> CM: so script depending on getting the second child node, for example, would get null
<ed__> ED: so clashing html5 / svgt12 elements are: video, audio and textArea
<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 [recorded in http://www.w3.org/2009/02/17-svg-minutes.html#action01]
<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].
<jwatt> JW: we should make tests to enable us to check whether an HTML5 parser behaves the way we'd prefer or not
[discussions about <foreignObject>, <desc> and <title> switching to the secondary insertion mode]
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/no/a/ Succeeded: s/encountering an html mode/encountering an html element/ Succeeded: s/content other/a prefix other/ Succeeded: s/three nodes/three nodes under the script element/ Found Scribe: Cameron Found ScribeNick: heycam WARNING: No "Present: ... " found! Possibly Present: CL CM ChrisL DS ED JW ScribeNick anthony data ed__ ed_work heycam joined jwatt shepazu svg trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 17 Feb 2009 Guessing minutes URL: http://www.w3.org/2009/02/17-svg-minutes.html People with action items: jwatt WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]