- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 18 Feb 2009 18:04:20 +1100
- To: public-svg-wg@w3.org
http://www.w3.org/2009/02/17-svg-minutes.html
(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]W3C
[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
Attendees
Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Cameron
Contents
* [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
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
[6]http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-
construction.html#parsing-main-inforeign
[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
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
[7]http://lists.w3.org/Archives/Public/public-html/2008Dec/0128.html
[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
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__>
[8]http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0151
.html
[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
element"
<ChrisL> well, thats no bloody use
[9]http://livedom.validator.nu/
[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
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__>
[11]http://dev.opera.com/articles/view/mama-document-encodings/
[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
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
[12]http://www.whatwg.org/specs/web-apps/current-work/multipage/tree
-construction.html#adjust-foreign-attributes
[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
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
[13]http://www.whatwg.org/specs/web-apps/current-work/multipage/tree
-construction.html#parsing-main-inforeign
[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
[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
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)</s
cript>
<ed__> data:text/html,<!DOCTYPE
html><body><a:b><script>alert(document.body.firstChild.localName)</s
cript>
<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
[16]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>
[17]http://groups.google.com/group/openweb-group/browse_thread/threa
d/b1e4fc8f0ec43160/6fef98a601f892fe?lnk=raot#6fef98a601f892fe
[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/name
d-character-references.html
[18] http://www.whatwg.org/specs/web-apps/current-work/multipage/named-character-references.html
data: text/html,&%20c
[19]http://livedom.validator.nu/
[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
[20]http://www.w3.org/2009/02/17-svg-minutes.html#action01]
[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
/scribe/
[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