This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 2.2.3 Extensibility says: "When vendor-neutral extensions to this specification are needed, either this specification can be updated accordingly, or an extension specification can be written that overrides the requirements in this specification. When someone applying this specification to their activities decides that they will recognize the requirements of such an extension specification, it becomes an applicable specification." This doesn't provide flexible mechanism which can incorporate vendor-neutral extension attributes in required speed given overhead connected with spec update. Lightweight registry which will allow registration of vendor-neutral attribute prefixes should be created and maintained. I propose the following spec change. After above paragraph the following prose will be added: For vendor-neutral extension attributes their attribute prefix may be registered in the Wiki Vendor-neutral extension attribute prefixes (yet to be created if this proposal is accepted by WG). Anyone is free to edit the Wiki Vendor-neutral extension attribute prefixes page at any time to add a new prefix. These new prefixes must be specified with the following information: Prefix The actual prefix being defined. The name should not be confusingly similar to any other defined prefix (e.g. differing only in case). Brief description A short non-normative description of what attributes with the prefix do. Specification A link to a more detailed description of all attributes using the prefix. It could be another page on the Wiki, or a link to an external page. Status One of the following: Proposed The prefixed set of attributes has not received wide peer review and approval. Someone has proposed it and is, or soon will be, using it. Ratified The prefixed set of attributes has received wide peer review and approval. It has a specification that unambiguously defines how to handle pages that use the prefixed set of attributes, including when they use it in incorrect ways. If a prefixed set of attributes is registered in the "proposed" state for a period of a month or more without being used or specified, then it may be removed from the registry. Anyone can change the status at any time, but should only do so in accordance with the definitions above. Conformance checkers may use the information given on the Wiki Vendor-neutral extension attribute prefixes page to establish if a prefixed attribute is allowed or not: attributes with prefixes marked as "proposed" or "ratified" should be accepted, whereas prefixes marked as "discontinued" or not listed in the aforementioned page may be rejected as invalid. Conformance checkers may cache this information (e.g. for performance reasons or to avoid the use of unreliable network connectivity).
I believe this is covered under the WG decision on ISSUE-41. http://www.w3.org/html/wg/tracker/issues/41
(In reply to comment #1) > I believe this is covered under the WG decision on ISSUE-41. > > http://www.w3.org/html/wg/tracker/issues/41 I don't think so. This proposal just lifts conformance criteria for attributes in form prefix-* and proposes registry for them (similar registries are already used in HTML5, for example for additional meta properties). It's far from being (and doesn't try to be) proposal solving distributed extensibility. There is use-case behind this. As a part of charter of http://www.w3.org/International/multilingualweb/lt/ we are developing set of attributes for conveying data related to localization process (extension of former ITS). In HTML5 we are going to use its-* attributes for this (similarly to aria-*) and we need a way to make such content valid. I'm reopening this bug as I think that it's just spec change with small impact on validators. There is no need to change user agents, as they are processing "unknown" attributes with no problems. Jirka P.S. What means "WORKSFORME" status?
Do you really think anybody else will mint its-*="" attributes? This hasn't been a problem in practice. RESOLVED WORKSFORME, in this context, meant that the existing extensibility mechanisms are good enough for your stated use case.
(In reply to comment #3) > Do you really think anybody else will mint its-*="" attributes? This hasn't > been a problem in practice. A lot of parties are interested in using ITS in HTML5. If there is way how to make localization and translation process more automated, then it will be used to $$$. And a lot of content is now stored and processed primarly as HTML. Technically its-* attributes can be used without any problem. The trouble is that such attributes will be marked as non-conforming. And for many government and Fortune 500 customers it is unacceptable to use HTML which isn't formally valid. As it seems that there is no consensus on getting generic distributed extensibility in HTML5 there should be at least simple and non-distributed mechanism how to put such data in HTML and keep validaty of document. It is just conservative extension of mechanism that is already in spec -- data-* attributes. But data-* attributes are targeted for private application use, while its-* is used by different tools and different stages of document workflow. > RESOLVED WORKSFORME, in this context, meant that the existing extensibility > mechanisms are good enough for your stated use case. In MultilingualWeb WG we made extensive research and have long discussion about another possibilities including data-* attributes, RDFa and Microdata. However using its-* is technically the best approach. What we are asking here is just to lift conformance criteria little bit, so larger communities can register prefix and use their custom attributes to convey additional metadata in HTML files without getting red flags from validators. Impact on implementations will be almost zere. No single line of web browser has to be changed. Validators will just add simple rule similar to one already bypassing data-* attributes from validation. That is.
I don't think this is a spec bug, but instead an issue for conformance checkers such as validator.w3.org. You should file a bug on the conformance checkers which you would like to treat ITS as an "other applicable specification" as per http://dev.w3.org/html5/spec/infrastructure.html#other-applicable-specifications
(In reply to comment #5) > I don't think this is a spec bug, but instead an issue for conformance checkers > such as validator.w3.org. Sorry, conformance checker is bound by rules defined in HTML5 spec. Currently prefixed attributes (except aria-* and data-*) are non-conforming in HTML5. Currently HTML5 conformance checker must report its-* as non-conforming. If not, then please point me at place in the spec which allows for this. > You should file a bug on the conformance checkers which you would like to treat > ITS as an "other applicable specification" as per > http://dev.w3.org/html5/spec/infrastructure.html#other-applicable-specifications I want prefix-* attributes to be conforming even without applicable specification if they are registered at Wiki page (yet to be created), similarly to another few places in HTML5 which are relying on such lightweight registries. As prefixed attributes are not harmful to anything it is excessive burden to request applicable specification for them, because then conforming documents with such attributes will not be HTML5 documents but HTML5+some extension documents. You can't explain why such document is not conforming HTML5 document to average human being.
New attributes (prefixed or not) are harmful as they increase the vocabulary authors are exposed to and therefore definitely a) require a specification (ideally defined in HTML itself) and b) require community recognition for validator support.
(In reply to comment #7) > New attributes (prefixed or not) are harmful as they increase the vocabulary > authors are exposed to and therefore definitely a) require a specification > (ideally defined in HTML itself) and b) require community recognition for > validator support. Hi Anne, exactly for these reasons I proposed change that introduces new lightweight registry where for each such vocabulary addition new entry including link to specification will be created. Only those recognized vocabularies are going to be added into registry. Wasn't this clear enough from my proposal? Anyway there seems to be sort of egg & chicken problem. Should we first create our own spec relying on its-* attributes, create implementations and then eventually try to change HTML5 spec to allow such attributes as valid? Or should we first change HTML5 spec to provide infrastructure for defining such vocabulary additions?
(In reply to comment #6) > I want prefix-* attributes to be conforming even without applicable > specification if they are registered at Wiki page (yet to be created), > similarly to another few places in HTML5 which are relying on such lightweight > registries. What makes you think that validator developers would write code for your registry idea but wouldn't write code for ITS? I encourage you to create an applicable specification with its-* attributes instead of trying to come up with a generic registry mechanism.
(In reply to comment #9) > (In reply to comment #6) > > I want prefix-* attributes to be conforming even without applicable > > specification if they are registered at Wiki page (yet to be created), > > similarly to another few places in HTML5 which are relying on such lightweight > > registries. > > What makes you think that validator developers would write code for your > registry idea but wouldn't write code for ITS? I encourage you to create an > applicable specification with its-* attributes instead of trying to come up > with a generic registry mechanism. The whole idea is that registry will gave more "special" status to selected applicable specifications -- their attributes will be recognized as conforming in HTML5 and there will be one place where such extensions to core HTML5 attributes could be found. If you think that it makes sense and life of validator developers easier, then we can require that registry will contain RELAX NG schema for additional attributes. But that would be little bit strange given that there is no official schema for core HTML5.
I agree with Henri. We could create a wiki page somewhere, either on whatwg.org or w3.org, that documents what the validator accepts/rejects.
Acceptance by one (or more) validators is NOT the same as complying with a standard...
(In reply to comment #12) > Acceptance by one (or more) validators is NOT the same as complying with a > standard... The ITS spec can say that there is such a thing as HTML5+ITS and documents can then comply to that standard. The HTML5 standard already has an extension point for writing standards that say such things.
This bug was cloned to create bug 17997 as part of operation convergence.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: No change. Rationale: The "other applicable specifications" clause already in the spec covers this.