- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 24 Jul 2009 07:41:43 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: "public-html@w3.org WG" <public-html@w3.org>
Ian Hickson wrote: > ... >> The main point of ISSUE-73 is that I don't want the HTML WG to spend >> cycles on this. > > Ironically, the only reason we are spending any cycles on this at all in > the HTML WG is that you filed this issue. I'd be happy to stop discussing > it, if your only concern is that we not discuss it. > ... How about removing the part instead? >>> I've shown a number of examples (just with vCard, even) of real-world >>> scenarios that have led me to hold this position; is your disagreement >>> on idealogical grounds, or do you have any counter-examples? >> The fact that some extension mechanisms have failed doesn't prove they >> are a bad idea in general. There are many that have worked perfectly >> well. > > Could you name some? I'm aware of some that have worked adequately, such > as the class="" attribute in HTML, but I think it would be a stretch to > say that any Web technology has had non-spec-based extension mechanisms > that have worked "perfectly". Why does it need to be a "Web" technology? Does Atom matter? XHTML? XSLT? WebDAV? > ... >>>> So *will* you fix it once draft-ietf-vcarddav-vcardrev is approved >>>> for publication? >>> Yes, of course (assuming that the revised draft represents what >>> implementations are interested in supporting, anyway -- I guess there >>> is the chance that the revised draft is ends up being DOA, though I >>> have no reason to believe that will happen in this case). >> And whether this is the case will be decided by whom? > > Implementors, presumably. Who else can decide whether a spec is adopted? > ... Who is going to measure that support and then make a decision for the HTML5 spec? > ... > Again, I am not editing HTML5 to be what I want it to be, I'm editing it > to be the best technical solution that I can find for the problems that > people have raised. Despite my personal opinions on the topic, many people > do in fact seem to care about these use cases, and so it would be remiss > of me to ignore them. > ... Right now, you're ignoring those who disagree with the inclusion. How is that different? >>>> The proposal is *not* to make it part of the language. (And, btw, >>>> I've seen several other people agreeing with that, favoring a more >>>> generic approach instead). >>> I don't understand how the predefined vocabularies could not be part >>> of the language. What do you mean by "part of the language"? >> Defined by HTML5, or by something it normatively refers to. > > By "part of the language" I mean a feature that HTML authors can use as a > first-class feature. We could take the HTML parsing section out of the > HTML5 spec, define it in another document, and not explicitly or > normatively reference it, but that wouldn't make the syntax stop being > part of the HTML language. > > So again, the predefined vocabularies are part of the language. Whether > there's an explicit normative reference or an implicit import through a > back-reference doesn't seem to matter, except that the former is far > clearer to readers. > ... It doesn't matter to you, but it does matter to me, because we have a different opinion about what defines the language. So if it doesn't matter to you, why do you insist on that approach? >>>> BTW, I notice that you didn't reply to: >>>> >>>>> But then, it would be a reason to add lots of other things as >>>>> well. Some of which being more important, and related to >>>>> *existing* interop problems of UAs, btw. >>> I didn't realise there was anything to respond to. Which other things >>> did you have in mind? >> I was wondering whether anything that is browser related and affects >> *existing* implementations, and does have *current* interop problems >> merits being addressed by HTML5. In which case I'd like to restart the >> discussion of making requirements on the treatment of >> Content-Disposition (which currently has little interop with respect to >> I18N). > > I'm sure the HTTP working group specs get plenty of review without having > to piggy back on the HTML5 spec. That isn't an HTTP WG spec. BR, Julian
Received on Friday, 24 July 2009 05:42:27 UTC