Re: Text Selection

On Mon, 1 Nov 2004, Doug Schepers wrote:
> 
> | This section doesn't define what should happen if the 
> | selection crosses out of the <svg> element into other 
> | content. For example, why is the |selection| attribute on the 
> | SVGSVGElement interface instead of the document?
> 
> Why would we need to worry about that? Surely, the SVG Spec need only 
> define what happens within the scope of an SVG document, and a Compound 
> Documents Spec should fill in the gaps on interaction between other 
> Specs.

No. SVG will be implemented by user agents that support other namespaces 
natively, and SVG needs to describe how its features will work in all 
contexts, otherwise it can't be implemented.

It is definitely not in the CDF charter to come behind other working 
groups and clean up their mess if their specs are under-defined.


> Otherwise, HTML would have to define, as part of its Spec, how every 
> HTML element or attribute interacts with every SVG element; in that 
> case, no Spec would ever be able to leave Last Call.

SVG and HTML together _do_ define how every HTML element and attribute 
interacts with every SVG element and attribute, at least to the same 
extent as HTML attributes are defined in pure-HTML environments.

For example, there is nothing ambiguous about this:

   <test xmlns:html="http://www.w3.org/1999/xhtml"
         xmlns:svg="http://www.w3.org/2000/svg">
    <html:form>
     <svg:svg height="100" width="300">
      <svg:foreignObject height="100" width="300">
       <html:input name="q" type="text"/> <!-- this is rendered and gets submitted -->
      </svg:foreignObject>
      <html:p> bla </p> <!-- this is not painted -->
      <html:input name="c" value="x" type="hidden"/> <!-- this gets submitted -->
     </svg:svg>
    </html:form>
   </test>

CSS defines how you render the non-SVG bits, SVG defines how you render 
the bits from <svg:svg> to <svg:foreignObject>. DOM3 Events defines how 
events flow through the whole thing.

(Most of the ambiguities in HTML4/XHTML1 in the example above are 
ambiguities that can just as easily be shown using just HTML, and those 
that I am aware of have been clarified by WHATWG's work on Web Forms 2:

   http://whatwg.org/specs/web-forms/current-work/

Let me know if I missed anything, though.)


> | It would seem better for selection to be defined independent 
> | of SVG (outside the SVG specification, since it applies to 
> | more than SVG) and have SVG re-use such a definition.
> 
> I think the case is special for SVG and text selection, as you have 
> noted yourself. SVG has a special relationship with text. Unlike the 
> other shapes that SVG presents, text has deep semantic content. A circle 
> can mean any number of things; an "A" glyph has a specific meaning. No 
> other SVG element requires child nodes in order to render; in fact, no 
> other SVG element can have

I'm not sure what you mean here. There's nothing particularly special 
about the way SVG's selection interface is defined, the same definition 
could, with very little change, be applied to any other language whose 
text can be selected (such as anything styled with CSS, or even natively- 
rendered HTML).


> In no HTML browser that I'm aware of (not even Amaya) can you reference 
> an SVG Font in HTML; CSS doesn't seem to provide any way to do this, 
> even in the abstract.

SVG fonts aren't particularly special, they can be referenced the same way 
as any other font in CSS (i.e. by name, once they are installed; if they 
are not installed, then using CSS2's @font-face rule to indicate the name 
and download location).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 4 November 2004 01:10:14 UTC