- From: Mike Schinkel <mikeschinkel@gmail.com>
- Date: Thu, 7 Dec 2006 13:31:29 -0500
Ian Hickson wrote: >> > Ability to insert XML-based solutions into HTML and have then processed >> > as XML. >> That's not a problem. That's a solution, looking for a problem. 1.) Inserting Sam Ruby's SVG logo into HTML, for one example. 2.) To incorporate an RSS feed in the HTML document and have it transformed by XSLT. This would allow me to display headlines on my HTML pages but not how to duplicate my RSS feed nor do the transform on the server. 3.) To embed RDF into HTML and be able to transform it visually. 4.) Ability to embed Word XML into a document and transform it. This would allow services to accept uploaded Word docs, export their XML, and display them online. 5.) Allowing me to insert non-visible metadata about my document so it can be parsed by an XML parser (to explain my use case would require that I explain my entire project. I don't have time for that at the moment.) This is something I proposed to the Microformat community and they told me that Microformat were not for that purpose. >> > This would allow almost ultimate flexibility moving forward and not >> > require an HTML6 for many things. >> Why would requiring HTML6 be a bad thing? You say HTML5 won't have broad browser support until 2008. When will HTML6 have broad browser support? 2012? 2015? No, it would be nice to accomplish get something valuable done "today" rather than pin hopes on some arbitrary point in the future. >> > What's more, it would help to see what the world at large has created >> > for extensions to understand what interests people. >> We already have such a mechanism, namely, plugins. Two extension mechanisms are not possible? >> > And because it would be required to be valid (or at least well formed) >> > XML you'd give HTML publishers a chance to learn the rules of XML. >> Why is that a good thing? Because XML is the other important technology. >> > It would also allow embedding of what I'll call "Microdirectives", i.e. >> > basically metadata, but that visible like Microformats. It would let >> > someone publish both a human readable document and a machine readable >> > document. >> HTML already lets you do this. Microformats are an example of this. I suggested this one the Microformat list and they told me under no uncertain terms that Microformats needed to be visible. >> > > What are the parsing requirements? >> > >> > Again, not exactly sure what you are asking. Have I >> answered already? I mean, what exactly would the >> browser have to do to parse the content you are >> proposing? Something like the parsing rules in the spec >> today, but specifically for your proposed feature. Pass it to the XML parser and follow the rules of XML parsing. That node would contain an XML tree. > > Note that any feature that, when misused, will "work better" in > > browsers that _don't_ support the feature than in browsers that _do_ > > support the feature, are doomed to failure, because browsers will be > > forced to emulate the browsers that don't support the feature instead. > > This basically implies that any syntax checking in a text/html > > document that results in fatal error (even for a subpart) but that > > renders ok in legacy browsers is a non-starter. > > I don't follow this. Did you state it correctly? Yes. >> > Does it apply to what I'm talking about? And if so, why? >> Here's an example. If this: Okay, thanks, I understand. Then if the XML doesn't parse, insert an error comment, nothing more. People won't see the error, but it will be described in view source for debugging. >> > but I know from participating on the Microformat list that >> > one of the biggest problems if lack of available attributes. That certainly isn't what I've heard from the Microformats community. >> 14 characters is not enough to warrant 14 characters times every instance. There can be hundreds to thousands of instances on the page. It makes creating the markup correctly very difficult, and adds needlessly to page size (often exceeding Google recommendations for parsable documents.) >> an entirely new attribute with its own processing model, >> conformance requirements, semantics, etc. Every element >> and attribute is very expensive to add. We have to keep >> it to a bare minimum. They are not new. They have already been added to other elements. >> What's wrong with: >> $54.97 (USD) Uh, no metadata? We debated the currency syntax for weeks on the Microformat list, and it's still not finalized. >> ...? It doesn't seem like you actually need _any_ markup here. >> If you really want it: >> >> <span class="amount"><abbr title="USD">$</abbr>54.97</span> >> >> I don't see why this is a problem. Then you obviously were not involved in those hundreds of messages on the Microformat list were people did see a problem with it. Let me go to the Microformat community and see if I can get it more clarified. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/
Received on Thursday, 7 December 2006 10:31:29 UTC