Re: Last Call comments for css3-ui

> > 3.1.2 :valid and :invalid
>
> I think these pseudo-class names are unfortunate, as they suggest
> alternative meanings to their specific use with form controls.

I understand your point and see what you're trying to avoid, however would
like to express my view on this because I don't see a problem, and disagree
with changing the syntax to something like :form(valid), arguing in favor
of keeping it as-is, and I'll try to explain why I think so...

> For example, *:valid seems to suggest "all valid elements", but in fact it
> means elements that represent form controls whose contents are currently
> valid. It might be prudent in the long run to avoid such name collisions
> by using :form(valid) or some other mechanism.

... there is no distinction between those two things. You argue that
elements being valid against a DTD or Schema and form controls whose
contents are currently valid / invalid are two distinct things that need
seperation. This is not true. You can think of a form control being
invalid to be exactly the same paradigm as a element being invalid
against its Schema or DTD, whereas the only difference is that in
a form control there is probably one or more levels of indirection
to the actual invalid element - the invalid element is defined
somewhere else and bound to a form control, via XPath in XForms for
instance.

In XForms, you bind UI controls to any arbitrary XML instance data,
and the validation rules set forth in the Schema of the XML instance
are the validation rules of the XForms, in other words, validation
in a form is validation of data against a schema, presented thru a
defined UI (e.g. "the form").

Whether the invalid element is invalid because it does not conform
to its schema, or whether it is invalid because it does not conform
to its schema and is also bound to a form control, are both
semantically exactly the same definition of :valid or :invalid.

> This seems more relevant given the CSS3 Selectors candidate recommendation
> which introduces so many structural pseudo-classes that truly do apply to
> the *element* itself, such as :root, :nth-child, :empty, etc.
>
> If a new pseudo-class was introduced to match empty form controls, such as
> text boxes with no content, calling it :empty would clash, while calling
> it :form(empty) would not, as well as being more descriptive.

A UI control in XForms that is empty is empty because it is bound
to an instance node that is empty.

Getting away from XForms, looking at JavaScript forms, I'm arguing
that essentially each JavaScript form is an attempting to define
a schema and a tree data structure on a per form basis in a
procedural way. A processor or user agent will have a hard time
figuring out whether a UI control is ":valid" or ":invalid" since
there are no clear semantics.

All other semantic forms languages gravitate towards the exact same
concepts: Data is defined in one place, logic and constraints are
defined in another place, and then there is a View and something that
binds / negotiates between all of them.

Now validation of XML instance elements against a DTD or schema
can actually be seen as an xForm with a specific, fixed UI and logic.
The W3C validation service validates your XML against its DTD or
Schema and shows you the results as XHTML. Control over the
XHTML presented is specific to this validation service, just as
validation is specific to each JavaScript form today.

Whether we talk about extremely "local" validation (e.g. in JavaScript),
or very generic language (e.g. XML validition) is orthogonal to the
semantics of :valid and :invalid, and just as CSS is e.g designed to
make no distinction between "local" (X)HTML markup and
generic XML markup, CSS shouldn't make a distiction between
:valid / :invalid coming from a DTD, a schema, an xForm or any other
validation technique.

Regards,

- Sebastian

Received on Thursday, 24 July 2003 12:20:51 UTC