<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

SVG in text/html

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?

CM: yes

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

http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inforeign

<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

http://lists.w3.org/Archives/Public/public-html/2008Dec/0128.html

<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__> http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0151.html

<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

http://livedom.validator.nu/

<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__> http://dev.w3.org/html5/spec/#the-input-stream

<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__> http://dev.opera.com/articles/view/mama-document-encodings/

<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 150px high
... 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 problem
... 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 namespaces
... 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 namespace
... so you don't need to declare the xlink prefix
... but you can if you do it correctly

http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#adjust-foreign-attributes

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?

ED: yes

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 attribute/element names
... 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

http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inforeign

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

http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#coercing-an-html-dom-into-an-infoset

<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 ("svg:")?
... 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

<!DOCTYPE html><body><a:b><script>alert(document.body.firstChild.localName)</script>

<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: ]]>

<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]

<shepazu> http://groups.google.com/group/openweb-group/browse_thread/thread/b1e4fc8f0ec43160/6fef98a601f892fe?lnk=raot#6fef98a601f892fe

http://www.whatwg.org/specs/web-apps/current-work/multipage/named-character-references.html

data: text/html,&amp%20c

http://livedom.validator.nu/

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.