Re: Improving SVG DOM: Modification request

On Fri, Nov 22, 2013 at 11:04 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> On Nov 20, 2013, at 5:47 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Wed, Nov 20, 2013 at 7:56 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>>> * Remove SVG namespace. Elements or attributes explicitly created with SVG namespace will still end up with no namespace. Keep current object names (SVGNameElement)
>>
>> Why not swap them into the HTML namespace like normal HTML elements?
>> This also makes things more compatible with simply reusing <style> and
>> <script>, which would be in the HTML namespace.
>
> Are you mixing up object names and namespace here? Using the HTML namespace is exactly what Cameron and I suggested. We just shouldn’t change the object names IMO. First, it doesn’t buy anyone anything to do a s/HTML/SVG/g. Second, if we would do it, we have the problems of SVGImageElement which suddenly already exists with HTML prefix. Third, it doesn’t buy anyone anything :) The same namespace is the important part.

No, I meant exactly what I said.  Your words that I was responding to
were "[elements] will still end up with no namespace".  However, you
also said that we should just use HTML's <script> and <style>
elements.  These are in the *HTML namespace*, rather than having no
namespace.

I was wondering if you meant that SVG elements should generate into
the HTML namespace, rather than the null.


>>> * Continue to differ between elements in an SVG context and in an HTML context with <svg> being the switch (as specified by HTML5 and done by browsers today). This still allows us easily to reduce the restriction later when we have a much more detailed proposal to mix them.
>>
>> I don't understand this line.
>
> You can still mix up elements as you wish and as you can do today. They just don’t get rendered, also as done today. The HTML parser doesn’t need to change just for SVG2. It could though if we have a sane model how to render SVG elements as child of arbitrary HTML elements and the other way around: <div><g></g></div> - <g><div></div></g>. That is something we can do for the next level or even independent of SVG. (Parser changes must be done by the HTML WG. I am sure they have other things to do ATM.)

Okay, that's kinda what I thought.  <svg> provides the rendering
context that SVG elements understand; without it, they're *allowed* to
be mixed in, but don't render.

I agree that we can deal with fully mixed content at the HTML parser
and CSS level.  (This, of course, is separate from our attempt to have
<html> just work inside of SVG.)

>>> * Deprecate most of the SVG DOM interfaces
>>>     * Incrementally remove / replace interfaces as possible / as reasonable
>>>     * use unions to give some attributes a new meaning for an potentially new SVG DOM
>>
>> We need to track usage of all the SVG DOM interfaces ASAP, so we can
>> kill off everything that's not necessary.
>
> Yes, that would be extremely helpful. I talked with Philip Rogers on Blink, but it seems more difficult to get accurate data then I initially thought it would. It needs more investigation.

Interesting.  I'll talk with pdr too.

>>> * Transform x, y, width, height, rx, ry, r, cx, cy, viewbox into presentation attributes, as already done for transform, patternTransform, gradientTransform
>>>     * All attributes are SINGLE value properties defaulting to auto. It is less likely that <length-list>s will be accepted by authors or implementations… the biggest flaw of the proposal in the past.
>>>     * Reuse CSSOM instead of creating yet another way to access variable definitions
>>>     * Deprecate (but still make mandatory) x, y, rx, ry attributes on <text> in favor for multiple <tspan>'s and CSS transforms, or introduce :nth-letter [2] to address each single glyph individually. The attributes on <text> would NOT be presentation attributes.
>>
>> No, you need x/y on <text>, as it works with text-anchor.  They should
>> be presentation attributes along with x/y on everything else.  I'm
>> fine with killing (but requiring support for) dx/dy in favor of
>> <tspan>s.
>
> x, y as positioning without lists is fine for me and would still work. x, y as attributes would mean something different. That is what I am saying with not turning them to presentation attributes. Like for <canvas> where width and height attributes mean something different then the properties.

Ah, I see what you mean.  We avoid promoting the x/y attributes on
<text> *because* they're multi-valued.  <text> elements still respond
to x/y *properties*, though.

> Greetings,
> Dirk

I'm still confused why you say "Greetings" at the *end* of a message. ^_^

~TJ

Received on Friday, 22 November 2013 19:22:31 UTC