W3C home > Mailing lists > Public > public-html@w3.org > April 2009

Re: SVG <title> (was: SVG Feedback on HTML5 SVG Proposal)

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 2 Apr 2009 11:43:14 -0700
Message-ID: <63df84f0904021143m660fdc2an6e7c4393bc5e470a@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: Robin Berjon <robin@berjon.com>, Ian Hickson <ian@hixie.ch>, Doug Schepers <schepers@w3.org>, public-html@w3.org, www-svg <www-svg@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
On Thu, Apr 2, 2009 at 8:42 AM, Simon Pieters <simonp@opera.com> wrote:
> On Wed, 11 Mar 2009 13:38:51 +0100, Robin Berjon <robin@berjon.com> wrote:
>> On Mar 11, 2009, at 02:04 , Ian Hickson wrote:
>>> On Tue, 10 Mar 2009, Doug Schepers wrote:
>>>> The SVG equivalent of <span lang=""> is <tspan xml:lang="">.  We
>>>> considered making the content model of the <title> and <desc> elements
>>>> match that of the <svg:text> element, but also wish to allow X/HTML
>>>> content for document semantics like lists and such.  Up until this
>>>> point, the SVG+X/HTML story was unclear, but with browsers natively
>>>> implementing SVG, we now have an opportunity to sort this out.  (Do note
>>>> that there are SVG-only UAs, so any solution there would have to only
>>>> optionally use HTML.)  Any thoughts or comments along those lines?
>>> One option would be to have SVG say what it does now, and to have the
>>> HTML5 spec explicitly say that the content model of <title> in SVG in
>>> text/html is limited to what HTML5 calls "phrasing content". This
>>> basically excludes what HTML4 calls "block-level elements", and includes
>>> things like <span> and <ruby>.
>>> I don't really have an opinion on exactly what the right solution here
>>> is.
>> I think that's the right approach. Basically, the limitations that Tiny
>> 1.2 has in making it text only are (as you point out) bad for I18N and in
>> effect entail that there's no need to use an element as an attribute would
>> suffice. Since a) there is no specified SVG rendering for this element, and
>> b) the cases in which it can be involved with the rest of the (notably with
>> <tref>) are well defined, using phrasing content seems sensible.
> But...
> SVG to date only allows text in title.
> XHTML 1.x and XHTML5 only allow text in title.
> text/html HTML does not and cannot allow elements in title.
> If SVG <title> in text/html does not use RCDATA parsing then it's pointless
> to make SVG <script> and <style> use CDATA parsing.

I don't see how you come to this conclusion? I think the benefits of
parsing <script> and <style> as CDATA is at least as much for authors
as it is for implementations. And authors would benefit just as much
no matter how <title> is handled.

> Performance with speculative parsing (which needs more research) and
> consistency in syntax and content models should be given consideration here,
> too, IMHO.

This I agree with though. It's also unclear to me that UAs are going
to be able to do anything sensible with rich markup inside <title>
given that the title is usually forwarded to the OS windowing system,
and I've never heard of a windowing system that supports rich markup.

Native apps have presumably had the exact same use cases and
requirements on titles for many years, and so far this does not seem
to have resulted in windowing systems supporting rich content in
application titles. So I'm not sure if there's a reason to think that
the web would affect anything here.

/ Jonas
Received on Thursday, 2 April 2009 18:44:07 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:44 UTC