W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

Minutes Sydney 2009 F2F day 3

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 18 Feb 2009 18:04:20 +1100
To: public-svg-wg@w3.org
Message-ID: <20090218070420.GA19784@arc.mcc.id.au>

(Some of the minutes got a bit terse in the second half of the day, but
we’ve been taking some handwritten notes of important points.)


      [1] http://www.w3.org/

                               - DRAFT -

                   SVG Working Group Teleconference

17 Feb 2009

   See also: [2]IRC log

      [2] http://www.w3.org/2009/02/17-svg-irc





     * [3]Topics
         1. [4]SVG in text/html
     * [5]Summary of Action Items

   <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

   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

   <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


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

   <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


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

   <ed__> CM: so we'd prefer if the case was kept like it was in the

   <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


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

   <ChrisL> well, thats no bloody use


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

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

   <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


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

   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

   [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

   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


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

   CM: then some more conformant content cannot be copied out into

   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


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

   [14]http://paste.lisp.org/display/75642 -- bookmarklet to make
   visible any comments

     [14] http://paste.lisp.org/display/75642


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

   <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

   <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

   <ed__> ED: i think that if we allow prefixes then there isn't much
   value unless custom namespaces are supported as well in svg

   <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

   <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

   <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

   <jwatt> ED: edge case

   <jwatt> JW: would it take much to have HTML5 cleate

   <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

   <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

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


     [17] http://groups.google.com/group/openweb-group/browse_thread/thread/b1e4fc8f0ec43160/6fef98a601f892fe?lnk=raot#6fef98a601f892fe


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

   data: text/html,&amp%20c


     [19] http://livedom.validator.nu/

Summary of Action Items

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

   [End of minutes]

    Minutes formatted by David Booth's [21]scribe.perl version 1.133
    ([22]CVS log)
    $Date: 2009/02/18 07:03:23 $

     [21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [22] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51
Check for newer version at [23]http://dev.w3.org/cvsweb/~checkout~/2002

     [23] 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: [24]http://www.w3.org/2009/02/17-svg-minutes.html
People with action items: jwatt

     [24] http://www.w3.org/2009/02/17-svg-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

   End of [25]scribe.perl diagnostic output]

     [25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Cameron McCormack ≝ http://mcc.id.au/
Received on Wednesday, 18 February 2009 07:05:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:10 UTC