Re: [svg2] lacuna value definition (was: Re: SVG 2 FPWD published)

Ah, sorry, I miss you're answer Erik, I ressend my concern about Lacuna
Value here to not split the discussion

2012/8/30 Erik Dahlstrom <ed@opera.com>

> On Thu, 30 Aug 2012 09:03:01 +0200, Chris Lilley <chris@w3.org> wrote:
>
>  On Wednesday, August 29, 2012, 3:11:12 PM, Jeremie wrote:
>>
>> JP> I know it's a very early WD but here are some small quick thought
>> about it:
>>
>> Thanks, appreciated.
>>
>> JP> Section 1.6
>> JP> I'm looking forward for the definition of "lacuna value" but I'm
>> JP> not sure it is quite différente than "default value" which seams a
>> JP> bit more easier to understand.
>>
>> Yes we probably do need to explain better; the terms are quite different.
>>
>> In XML, "default" values for attributes define "how an XML processor is
>> to react if a declared attribute is absent in a document".
>> http://www.w3.org/TR/xml/#sec-**attr-defaults<http://www.w3.org/TR/xml/#sec-attr-defaults>
>>
>> Note that attribute-value normalization may add such default values to
>> the infoset (I say may because it depends on whether external DTD subsets
>> are fetched or not). It turn, this affects what is in the DOM, whether CSS
>> attribute selectors match or not.
>>
>> In other words a default value is missing in the document and *may or may
>> not* show up in the DOM, etc. This is an undesirable cause of variability
>> in implementations. It can also result in DOM bloat.
>>
>> The term lacuna value was introduced in SVG Tiny 1.2 to deal with this.
>> http://www.w3.org/TR/**SVGTiny12/intro.html#**TermLacunaValue<http://www.w3.org/TR/SVGTiny12/intro.html#TermLacunaValue>
>>
>> A lacuna value is missing in the document, is *not* added to the infoset
>> or to the DOM and can *not* be matched by attribute selectors. The
>> specification tells the implementation what to do if tthe value is missing,
>> without needing to sort-of-maybe add the value to the document.
>>
>
In an author point of view, I'm a bit puzzled by this notion because it
sound a little bit like magic.

For exemple, if I forget an attribut or a property somewhere and if a
Lacuna Value is define for that case, something will happen but I have no
way to know what is the value applied (except by reading the SVG Spec which
is not a common practice among authors ;). So an author have no means to
know if this behavior is accurate or not (something happen... magically)
and it as now way to learn from it's code (the try and fail common way of
learning the web). It has to guess the value (and once again, to few
authors read the spec to learn this... they prefer spending hours of tests
to figure this out). My opinion is that if a lacuna value is used, it
should be a way for author to retrieve it from the browser directly
(through the DOM or any other means) without to dig into a spec.


>  I don't know if we have a need for it (yet), but perhaps we should
> consider splitting the lacuna value definition in two such that we get one
> term invalid-specified-value-**lacuna, and one term
> unspecified-attribute-lacuna for when an attribute is not specified?
>
> A construct like that might be nice if one wants to make the UA do one
> thing if the attribute was specified (but value invalid), and another if
> the attribute wasn't specified at all.


I like that idea, this is something that can be helpful for author without
the need to pollute the DOM. It allow implementors to add specific debug
features (such as consol log or UI change) which is always good for authors.

Best,
-- 
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>