Re: Input on the agenda

I'm sorry that I'm not familiar enough with how self-closing elements
are treated in HTMLish syntax.  Can someone please tell me how the
current SVG-in-HTML algorithm would treat the following SVG code
fragments?

The intention of this code is that both the circle and rectangle
animate from green to red over 2 seconds:

  <g fill="green">
    <rect width="200" height="100" x="50" y="50" />
    <circle r="50" cx="100" cy="100" >
    <animateColor from="green" to="red" begin="0s" end="2s" />
  </g>

(i.e. the <animateColor> element is a direct child of the <g>)

The intention of this code is that only the circle animates from green
to red over 2 seconds:

  <g fill="green">
    <rect width="200" height="100" x="50" y="50" />
    <circle r="50" cx="100" cy="100">
      <animateColor from="green" to="red" begin="0s" end="2s" />
    </circle>
  </g>

Thanks,
Jeff

On Wed, Mar 25, 2009 at 12:51 AM, Sam Ruby <rubys@intertwingly.net> wrote:
> Jonas Sicking wrote:
>>
>> On Wed, Mar 18, 2009 at 1:24 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>
>>> On Mon, Mar 9, 2009 at 5:15 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>>>>
>>>> Jonas Sicking wrote:
>>>>>
>>>>> Personally I would like to see something that is even more HTMLy than
>>>>> Hixies current proposal. I don't like at all that we have to use a
>>>>> different tokenizer in "HTML mode" and in "foreign content mode". This
>>>>> is both confusing to web developers and painful for end users (as
>>>>> performance and code complexity suffers).
>>>>
>>>> Do you (or Henri) have a concrete proposal to offer?
>>>
>>> The cases where I can see that the parser state is affecting the
>>> tokenizer state is the following:
>>>
>>> CDATA handling. <![CDATA[]]> is currently only allowed in foreign
>>> content. It would be great if we could allow <![CDATA[]]> consistently
>>> throughout the markup. It sounds like Opera has done some
>>> experimentation in this area.
>>>
>>> In HTML mode, there are a set of elements that change the tokenizers
>>> 'content model flag':
>>> The following elements switch the tokenizer to CDATA state: noscript,
>>> noframes, style, xmp, iframe, script
>>> The following elements switch the tokenizer to RCDATA state: title,
>>> textarea
>>> The following elements switch the tokenizer to PLAINTEXT state: plaintext
>>>
>>> It would be great if we could allow the same set of tags to affect the
>>> parser the same way in both HTML mode and in foreign content mode. The
>>> only two tags that seem troublesome here is <script> and <style>. It
>>> sounds like it might possibly might be agreement that it would be
>>> possible to parse <script> as CDATA, which would leave <style> as the
>>> only remaining controversial tag.
>>>
>>> If we made these changes I think there would be some optimizations
>>> that we could do on the implementation side. However more importantly,
>>> I think the consistency would be much appreciated by authors.
>>
>> Just realized there was one more thing that I forgot about.
>>
>> This isn't a case where the tokenizer is directly dependent on the
>> parser, however it's nonetheless a case that I think will be confusing
>> for authors.
>>
>> Currently in foregin content mode, the 'empty XML element' syntax is
>> supported. So you can write
>>
>> <circle x="42" y="4711" />
>>
>> This is IMHO a good thing. However this syntax does not work in HTML
>> mode. So for example
>>
>> <div id="output" />
>>
>> does not create an empty div, but is rather treated as a start tag.
>>
>> This would be an easy problem to solve if it wasn't for web
>> compatibility concerns. However I'd still like to explore what could
>> be done in this area. For example of there is a short list of tags for
>> which we wouldn't support the empty element syntax, or if we could
>> make empty-element syntax only work in standards mode (I'm not exited
>> about either option).
>
> I'm actually OK with this being the list of always empty tags, as is
> reflected in the current spec.  <br></br> is an extreme case of one you
> couldn't fix if you wanted to, and <script src=""/> is an example of one
> that would be really nice if it could be fixed, but alas it can't either.
>
>> / Jonas
>
> - Sam Ruby
>
>
>
>

Received on Wednesday, 25 March 2009 12:51:57 UTC