- From: Mark Baker <distobj@acm.org>
- Date: Thu, 20 Nov 2008 10:18:17 -0500
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: public-html@w3.org
On Tue, Nov 18, 2008 at 4:10 PM, Ian Hickson <ian@hixie.ch> wrote: >> You've made the claim that it's difficult to separate the concerns of >> declarative and imperative programming within browsers, and if that is >> in fact the case then this would provide evidence for your belief that >> HTML 5 needs all the features it has. But you haven't made that case >> yet, so I'm not ready to accept your re-definition of the word >> "language", not even for HTML. > > The declarative vocabulary and the dynamic API are not orthogonal -- they > have direct impact on each other. For example, should <video> have a > start="" and end="" attribute, or should we use a currentTime DOM > attribute for seeking and the addCueRange() API for pausing? > > These decisisons aren't orthogonal. Depends what you mean by "orthogonal" here. I agree that there are complex interactions between the various components in play. I just don't agree that this means that they can't be specified independently. I *do* agree that it would be more work than specifying them together though, because simplification always takes effort. > Another example of how the vocabulary and DOM parts aren't orthogonal: > > We have to define how <script> executes in script-aware UAs when the > document is parsed, but the execution is also triggered by DOM > manipulation creating the element and inserting it into the DOM. This then > can trigger document.write(), which means that the vocabulary needs to > define how it interacts with the .write() API. The .write() API can then > trigger the parser, which can restart the whole loop. Or it can trigger > document.open(), which can cause a navigation of the browsing context, > thus requiring <script> and the browsing context to be carefully defined. I agree that's complex, but I don't see why script needs to be any more carefully defined than "This element encapsulates a script of the type defined by its type/language attribute". Inside the DOM spec, and/or browsing context spec, or wherever, the complexities of that state machine you describe can be laid out in excruciating detail. >> > Just look at the definition of the form controls for instance. There's >> > a tighter relationship between the declarative features and the >> > dynamic features than between the declarative features and the syntax. >> >> I'm not sure what you're referring to. Can you point to an example? > > Sure. The value="" attribute on the <input type="text"> element represents > the initial value. When you click a <button type="reset">, the UA has to > reset the <input> element to its original value="". That's all very well, > but what events are to be fired when that happens? What if a script > changes the value="" attribute? Does that change the displayed value or > just the default value? What happens if a script dynamically changes the > type="" attribute of the <input>? or the <button>? Again, I agree that is a complex interaction that needs to be specified carefully. But as with the previous example, I don't understand why that necessitates defining the meaning of those attributes in terms of the DOM. Mark.
Received on Thursday, 20 November 2008 15:18:54 UTC