Ben Adida wrote: > Bonner, Matt wrote: >>> Not that you have to take the time, of course, I'm sure you're busy. >>> But if you're going to spend time arguing with us, then please argue >>> with us about what we actually need, not about what you think we >>> need. >> >> Is that the only point of discussion? > > No, it definitely isn't if we're talking about how RDFa fits into > HTML5. But I think you're the one who brought that up, I was just > explaining where CC is coming from :)
All I did was point out to the WHATWG that CC/W3C had published a Submission that appeared to call for changes to HTML. I continue to believe you should clarify the ccREL Submission to clarify that as it stands, it applies only to XHTML, and that you propose changes to HTML5 to support ccREL. >> Well, if you used <link> instead of <a>, > > <link> doesn't support DRY (the user doesn't see the link to the > license), and it's only in the head, so we can't pass out a small > chunk of HTML that folks can embed in their page. > > That's explained in the ccREL paper, under the principles of DRY and > self-containment. The linkage is arguably present, but I think would be improved with clearer explanation of how the principles drive the design choices. >> Perhaps it would be better to start over and engage the HTML5 >> community on your requirements, what makes sense and proceed from >> there? > > Sure, although again I got roped into a conversation that *you* > started :) I'm not trying to force anyone into anything here. I noticed the Submission, inferred a proposal for changes to HTML5, and informed the WHATWG. Sorry if I stole anyone's thunder. But this conversation would need to happen eventually if you want HTML5 support. > If HTML5 can tell browsers to ignore data-* attributes, I think it can > probably choose to ignore a few more attributes, right? Obviously not my decision, by any means. I'm new to the HTMLWG myself. I can say from what I've observed, that the process steps have been pretty consistent: 1. show web author/reader demand 2. distill the scenarios into a few key use cases 3. offer a proposal 4. respond to feedback & adjust proposal accordingly 5. if successful, become part of the spec. Matt -- Matt Bonner Hewlett-Packard Company
smime.p7s
Description: S/MIME cryptographic signature
