This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There are currently several dozen instances of requirements stated in the spec prose in the form "The foo DOM attribute must reflect the foo content attribute." For their internal IDLs, the WebKit development team is adding a "[Reflect]" annotation (more precisely, what WebIDL calls an "extended attribute") to each instance of declaration of a DOM attribute for which the HTML spec requires reflection of a content attribute. For details, see this message: https://lists.webkit.org/pipermail/webkit-dev/2009-June/008457.html It might be worthwhile to consider using such an extended attribute in those corresponding IDLs within the HTML5 spec itself. The WebIDL spec makes it clear that use of such not-in-the-WebIDL-spec-itself extended attributes is OK: http://dev.w3.org/2006/webapi/WebIDL/#extensibility [[ Extensions to language binding requirements can be specified using extended attributes that do not conflict with those defined in this document. ]] So the HTML5 spec could internally define (e.g., somewhere in the "Reflecting content attributes in DOM attributes" section) what it means by its use of the [Reflect] extended attribute (or whatever other name might be used instead). If it's added, we can just try to let other groups (e.g., SVG WG) know about it, so that if they end up finding similar utility for such an attribute, we can have consistent naming across different specs -- or I suppose if we really wanted to, we could publish a short Note for it. If we did that, I guess it would probably be most appropriate to have the WebApps WG publish that.
Maybe this should be in Web DOM Core instead?
If it's just HTML5 that's using this, then what we have is fine. If there are multiple DOM specs that want to use this (say HTML5 and SVG 2.0), then I think it makes sense to put this in Web DOM Core. I've added a note about this in my draft. I don't think it's appropriate to put this in a Note since Notes are non-normative.
I've considered this kind of thing in the past, but the main reason I haven't done it is that I don't want to have features that are defined exclusively by the IDL blocks, because it makes the spec harder to read (IMHO). How strongly do you feel about this?
(In reply to comment #3) > I've considered this kind of thing in the past, but the main reason I haven't > done it is that I don't want to have features that are defined exclusively by > the IDL blocks, because it makes the spec harder to read (IMHO). > > How strongly do you feel about this? I think that for the intended audience in this particular case, it actually makes the spec easier to read, not harder. But I don't feel strongly about it. I just put it forward as something to consider. If you reckon the spec text around this is fine as is and would not benefit significantly from the proposed change, it's fine by me for this bug to just changed to resolution=wontfix.
Ok. I'm going to WONTFIX this for now, since it would be a lot of (likely quite error-prone) work to make this change at this point anyway. I'll consider something like this in the future, though. Thanks!
This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, 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 This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.