Re: Making all elements and attributes that contain hyphens valid

On 3.10.2013 9:05, Michael[tm] Smith wrote:
> The HTML spec defines the known element and attribute names recognized as
> being standard names in the HTML language and that are "portable" in the
> sense that among other things we know that UAs and other tools recognize
> them as such. And additional specifications such as the existing ITS2 and
> ARIA specs define other standard names for other specific purposes.

OTOH, Web Components can attach behaviour to such elements and then
elements become portable even if there is no additional specification
like ARIA/ITS2 which defines behaviour of such elements. Definition is
in code only. I understand your concerns, but I think that web platform
needs more open extensibility story, something pioneered by XBL1/2 and
now proposed by Web Components.

> Conformance checkers should report non-standard names so a person checking
> a document can actually be aware it contains non-standard names. Then that
> person can decide what they choose to do about it (e.g., choose to ignore
> the reports because they're the ones who created the document and are already
> aware it contains custom names). To be clear, the person checking a document
> with a validator is not always the same person who created the document.

We can solve this by having several conformance levels. Strict level
will allow only HTML (+ other well recognized vocabularies like
MathML/SVG/...) elements and extended level could allow
these-dash-based-extensions.

> It seems like you're scope-creeping your own proposal... Maybe I'm missing
> something but at least as far as I know, Custom Elements in particular and Web
> Components more broadly don't have any special need for attributes with hyphens.

Such attributes are already used in wild, for example see AngularJS
(http://angularjs.org/) and its ng-* attributes.

It would be nice if editing AngularJS injected HTML template wouldn't
put red underling to every second attribute inside code editor.

> So if we allow any attribute containing a hyphen, we're going to make it a
> lot harder for authors to catch mistakes like ist-allowed-characters,
> aira-describedby, aria-describesby, aria-described-by, its-annotaters-ref,
> etc. Because it'll be a lot more difficult for tools to distinguish those
> typoed names from arbitrary custom hypen-containing attribute names.

This could be at least partially solved by having several conformance
checking levels or by requirement do declare somehow which extensions
page tries to use -- for example having <link> or <meta> element which
say that page wants to use particular prefix. (Welcome back, namespace
prefix declarations :-)

> If for example the epub WG wants to have attributes that use the prefix
> epub-*, then they could produce a spec that defines the specific name for
> each new attribute, in the same way the ITS2 spec defines specific its-*
> attributes or the ARIA spec defines specific aria-* attributes. Then we can
> add a schema to the validator to check for those specific attribute names.

My impression is that with Web Components many libraries similar to
AngularJS will emerge, each with its own set of element/attributes.
Given potential number of such libraries and their development cycle it
would be quite heroic effort to keep validator schemas updated.

> There's a third alternative, which is that they just be treated as unknown
> names that are not part of the HTML language and not part of any other
> known specification. Which is exactly what they are. Then the validator
> will keep reporting them as unknown the same way it does now.

I have one concern. Look back to 2000. XHTML was promoted as an
*eXtensible* version of HTML. New elements could be used (in their own
namespace) and that should lead to controlled innovation which has some
bounds preventing clashes with existing and future standard HTML element
names. Unfortunately XHTML spec was actually disallowing such usage, DTD
validation prevented using such extensions. The outcome is well known --
XHTML provided more strict syntax, no new features, just problems in
legacy browsers.

I think that we should try to seek balance between strict approach (only
elements baked with W3C spec are recognized) and lenient approach
(any-dashed-markup-is-allowed).

> So if you were to have the spec say that any element name containing a
> hyphen is valid, you would be introducing a condition that's not
> expressible in current schema languages, and so not checkable with most
> current off-the-shelf validation tools.

In a long term I can imagine that RELAX NG 2.0 can support this if there
is strong enough use-case. There are already plans to lift existing
restriction on name classes to be full patterns in RELAX NG
(https://lists.oasis-open.org/archives/relax-ng/200611/msg00025.html).
Such change would actually simplify adding new extensions like ITS2/ARIA
into existing HTML schemas a lot.

But as there is no big demand for such new features
(https://wiki.oasis-open.org/relax-ng/FutureRequirements) development of
RELAX NG 2.0 is stalled now.

> But there are many other contexts other than the validator in which it
> would be useful to have some level of HTML conformance checking. For
> example, you might want to have HTML conformance checking in an interactive
> editing application -- anything from a text editor like Emacs to some
> WYSWIG Web-authoring application. And it's unreasonable to expect that
> all those tools will implement custom attribute-name-filtering mechanisms
> like the one I described above that we're using for data-* attributes.

Although currently this is not supported by tools, I have no doubts that
wide usage of such extension elements/attributes in HTML5 will lead to
change in tools. It will take some time of course.

    Jirka

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
------------------------------------------------------------------
    Bringing you XML Prague conference    http://xmlprague.cz
------------------------------------------------------------------