Web Components Suggestion
Markup could be much cleaner if custom elements use the element name, rather than the is attribute. fancyButton/ instead of button is=fancyButton/
Re: Web Components Suggestion
It's my understanding that if you want to define a strict parser using a DTD that describes the markup, it's impossible to introduce arbitrary tage names (as in there are not tag wildcards in a DTD). A document that used arbitrary tags could not be validated. On Sun, Aug 12, 2012 at 8:05 AM, Dave Geddes davidcged...@gmail.com wrote: Markup could be much cleaner if custom elements use the element name, rather than the is attribute. fancyButton/ instead of button is=fancyButton/
Re: [FileAPI] blob: protocol need a content-length header
On Sun, Aug 12, 2012 at 2:56 AM, Benjamin BERNARD benjamin.bern...@benvii.com wrote: Hi, I was developing an offline music web App when I discover that is no Content-length header specified here : http://www.w3.org/TR/FileAPI/#ProtocolExamples So when you play an audio/video file stored as a blob (under a blob URI) it's considered by the player as streaming content which means you can't get the duration of a song for instance (it has an infinite duration). I think it might be the consequence of not providing a content-length header. I experienced it using Firefox I heard Internet Explorer already provide this header. Moreover, I don't understand why there is no content-length header recommended in the spec because when you use URL.createObjectURL(blob), blob has a finished size (correct me if I'm wrong). So a content-length header should also be provided and recommended in the spec. Yes, I agree, we should have a content-length header similar to the content-type header. In Gecko things are a bit complicated because we don't have headers on anything but http channels. But we do have the concept of a length of a response for all channels so that should take care of it. Not sure off the top of my head why it doesn't. Filing a bug with an example would be great. / Jonas
Re: Web Components Suggestion
On Sun, Aug 12, 2012 at 3:36 AM, Florian Bösch pya...@gmail.com wrote: It's my understanding that if you want to define a strict parser using a DTD that describes the markup, it's impossible to introduce arbitrary tage names (as in there are not tag wildcards in a DTD). A document that used arbitrary tags could not be validated. What Dimitri said, but to address your comment directly, DTD-based validation is long-dead, at least when applied to HTML. A DTD can't capture the validity requirements that the HTML spec already imposes, so it's irrelevant if it also can't validate a document containing custom elements. The current validator used by the W3C is a combination of (iirc) constrains expressed in Schematron and custom Java code. ~TJ
Re: Web Components Suggestion
Tab Atkins Jr. jackalm...@gmail.com, 2012-08-12 15:43 -0700: What Dimitri said, but to address your comment directly, DTD-based validation is long-dead, at least when applied to HTML. A DTD can't capture the validity requirements that the HTML spec already imposes, so it's irrelevant if it also can't validate a document containing custom elements. The current validator used by the W3C is a combination of (iirc) constrains expressed in Schematron and custom Java code. The core of the backend for the W3C Nu Markup Validator (http://validator.w3.org/nu/) and validator.nu is James Clark's Jing, a Relax NG implementation. The backend doesn't actually use Schematron, for performance reasons. Instead it has some Java code to perform the equivalent the of assertions-based checking that Schematron provides but that can't be done with grammar-based checking alone (whether with Relax NG or anything else). No grammar-based schema language is capable of expressing all the constraints in HTML spec. Things like checking the data types (microsyntaxes) of attribute values requires custom code -- especially if you want to report useful messages for errors (something regexp-based checking it totally useless for). Also, more to the point here, things like the fact that arbitrary attribute names prefixed with data- are valid -- grammar-based checkers can't handle that at all. So the validator.nu backend has some custom code that Henri wrote that drops those data-* attributes -- basically, filters them out -- before the Jing part of the toolchain even sees them. --Mike -- Michael[tm] Smith http://people.w3.org/mike
Re: Web Components Suggestion
Florian Bösch pya...@gmail.com, 2012-08-12 12:36 +0200: It's my understanding that if you want to define a strict parser using a DTD that describes the markup, it's impossible to introduce arbitrary tage names (as in there are not tag wildcards in a DTD). A document that used arbitrary tags could not be validated. There is no conceivable conformance checker that's going to allow the use of completely arbitrary tag names. It doesn't matter what formalism it uses. To allow custom tag names and still be able to check the conformance of normal tag names, the only possibility is to limit the custom tag names to some recognized prefix -- e.g., x-fancyButton or whatever. --Mike -- Michael[tm] Smith http://people.w3.org/mike
