From mail at robbiegee.com Tue Aug 1 01:56:08 2006 From: mail at robbiegee.com (=?iso-8859-15?Q?Robert_Gr=E6sdal?=) Date: Tue, 01 Aug 2006 10:56:08 +0200 Subject: [whatwg] Events for added nodes while page is loading Message-ID: It'd be nice to have an event that'd tell my script when a new dom node have been added to the DOM tree /while it is loading/. Some documents just take quite a while to load, so it'd be nice to be able to modify nodes as they were added to the DOM tree. I figure we'd need events that fired when the node had been added and closed (meaning that all child nodes have been added and we are about to start on the sibling). For instance, if you had the code: Test

This is a paragraph

You'd have the events fired as such (+ means an add event, / means a "close" event. Ignoring whitespace-only text nodes): +html +head +title +#Test /title /head +body +p +#This is a paragraph /p /body /html If one relied on events not being retroactive (in that they only fire after the event has been registered, and you're not told about those already added), I am realizing one would probably never get to register the root node's creation, and for html, neither would the head's opening event. I don't think that'd be a problem, but... comments? - Robert Gr?sdal From alexey at feldgendler.ru Tue Aug 1 02:13:27 2006 From: alexey at feldgendler.ru (Alexey Feldgendler) Date: Tue, 01 Aug 2006 16:13:27 +0700 Subject: [whatwg] Events for added nodes while page is loading In-Reply-To: References: Message-ID: On Tue, 01 Aug 2006 15:56:08 +0700, Robert Gr?sdal wrote: > It'd be nice to have an event that'd tell my script when a new dom node > have been added to the DOM tree /while it is loading/. Some documents just > take quite a while to load, so it'd be nice to be able to modify nodes as > they were added to the DOM tree. Yes, this would help a lot when writing client-side scripts which modify pages as they are loaded, removing unwanted content such as Flash. Some browsers (Opera) have a mechanism like "User JS" to register a script which runs before every page starts loading. It can register event listeners, but currently there is no way for such script to e.g. prevent loading of Flash. It can only remove all Flash objects in document.onload handler, but by that time some Flash objects might have already started playing. > If one relied on events not being retroactive (in that they only fire > after the event has been registered, and you're not told about those > already added), I am realizing one would probably never get to register > the root node's creation, and for html, neither would the head's opening > event. I don't think that'd be a problem, but... comments? With mechanisms such as "User JS", a script can register so early as to get the event for creation of the root node. -- Alexey Feldgendler [ICQ: 115226275] http://feldgendler.livejournal.com From alexey at feldgendler.ru Tue Aug 1 02:31:13 2006 From: alexey at feldgendler.ru (Alexey Feldgendler) Date: Tue, 01 Aug 2006 16:31:13 +0700 Subject: [whatwg] What should document.write() do when called from setTimeout or event handlers? In-Reply-To: <000501c6b512$bda90f90$3401a8c0@TERRA> References: <000501c6b512$bda90f90$3401a8c0@TERRA> Message-ID: On Tue, 01 Aug 2006 09:32:31 +0700, Andrew Fedoniouk wrote: > (That is what I never understand : why script is allowed to do anything > during load time. Script should start executing when DOM is complete, > when, e.g. getElementById makes real sense.) Document loading can take a lot of time, especially when external images and objects are used on the page. The user can start interacting with the partially rendered page before it has completely loaded. -- Alexey Feldgendler [ICQ: 115226275] http://feldgendler.livejournal.com From alexey at feldgendler.ru Tue Aug 1 02:32:07 2006 From: alexey at feldgendler.ru (Alexey Feldgendler) Date: Tue, 01 Aug 2006 16:32:07 +0700 Subject: [whatwg] What should document.write() do when called from setTimeout or event handlers? In-Reply-To: References: Message-ID: On Tue, 01 Aug 2006 05:34:55 +0700, Ian Hickson wrote: > IE seems to make those calls to document.write() simply blow away the > document, as if the document was closed. Opera seems to do the same. I think this is the best thing to do. Easy to implement and well-defined. -- Alexey Feldgendler [ICQ: 115226275] http://feldgendler.livejournal.com From stewart.brodie at antplc.com Tue Aug 1 03:15:25 2006 From: stewart.brodie at antplc.com (Stewart Brodie) Date: Tue, 1 Aug 2006 11:15:25 +0100 Subject: [whatwg] Events for added nodes while page is loading In-Reply-To: References: Message-ID: Robert Gr?sdal wrote: > It'd be nice to have an event that'd tell my script when a new dom node > have been added to the DOM tree /while it is loading/. Some documents just > take quite a while to load, so it'd be nice to be able to modify nodes as > they were added to the DOM tree. > > I figure we'd need events that fired when the node had been added and > closed (meaning that all child nodes have been added and we are about to > start on the sibling). Well DOMNodeInserted(IntoDocument) almost (see below) fits the bill for the first one. The latter one is much trickier. Like you, I also discovered I needed to know about close tags marking that the parser had finished dealing with the child nodes in order to handle things that cannot start until their content is fully parsed, like launching plugins for OBJECT tags (you can't actually start it up until you've seen all the PARAM elements). My tree builder issues a custom event for this when it considers a node's content complete. Obviously, I'm looking at this from the browser implementation point of view, rather than the page author's script's point of view, but both want the same information. However, there is still an additional complication of how to handle somebody using the DOM Node interface to attach entire subtrees - in this case, you just need to know that the object's content is already complete (because the child nodes will already be there, you just won't have seen the events yet). My solution for this was to have an additional property on the DOMNodeInserted(IntoDocument) events indicating that the tree builder was responsible for attaching the node. In effect, this was a signal to the default event handler that it should wait for one of my custom events to arrive for that node before dealing with any OBJECT or TEXTAREA element. I believe that the standard DOM events should always be raised whenever the DOM tree is modified, whether it be by the parser or by direct modification of the tree through the Node interface. This is one area where I disagree with the WA1 document. I don't accept the efficiency argument against this: it is not terribly difficult to optimise away event dispatch if there are no listeners registered for the event anywhere on that document. Without such filtering then, yes, it degrades performance noticeably (on 300MHz devices), but with it, it's barely measurable. -- Stewart Brodie Software Engineer ANT Software Limited From stewart.brodie at antplc.com Tue Aug 1 06:37:17 2006 From: stewart.brodie at antplc.com (Stewart Brodie) Date: Tue, 1 Aug 2006 14:37:17 +0100 Subject: [whatwg] What should document.write() do when called from setTimeout or event handlers? In-Reply-To: References: Message-ID: Ian Hickson wrote: > > I'm trying to spec document.write() and I've run into a difficult edge > case. > > Imagine the server sees this: > > > > > function test() { > document.write('TEST'); > } > setTimeout(test, 1000); > > >

> > ...and then time passes. The image loads, the timeout fires. > > Then once the image has loaded and the timer has fired: > > > > > ...and the connection is closed. > > What should happen? > > IE seems to make those calls to document.write() simply blow away the > document, as if the document was closed. Opera seems to do the same. In other words, they treat it like being in an event handler context where document.write is for replacing the entire document. That seems entirely reasonable to me. Calling document.write() directly whilst in an event handler context must blow the document away too, well, once you do document.close() that is. > Mozilla seems to make the document.write() calls insert text into the > parser, as if they'd been called inline, with the result that the inserted > text could appear pretty much anywhere. (It's actually a bit more complex > than that -- it avoids inserting into tokens -- but that's a detail.) I think we can do without Heisenberg-like effects from Mozilla :-) > I couldn't work out what Safari and MacIE do; they seem to delay the > timeout somehow and then print to the end of the page. Possibly they are preventing setTimeout/setInterval timeouts from firing until the document is loaded? It's the same sort of problem faced by constructs like (is it CONTENT? whatever). Finding a suitable definition for "until the document is loaded" remains problematic. I have yet to find any satisfactory documentation for events like "load", for example. The key sticking point for me is whether or not a browser should wait until it's formatted the page before issuing the event. Script authors seem to believe that computed style will be available as soon as the load event has been fired, which would imply that not only do you have to wait until all the resources are downloaded, but processed too - and what about images whose size is unknown and thus cause the document to be reflowed. The data is available (so technically the conditions for a "load" event are fulfilled), but it hasn't been decoded yet - should the "load" event be deferred until after it is? > Any preferences? I'm particularly interested in feedback from browser > developers here as to whether there is anything I should know about how > easy/hard it is to do one thing or the other. Easiest to disallow it like Safari/MacIE or behave like IE/Opera. I prefer the Safari way (it's what I've implemented, anyway :-) Of course, if you implement the Safari way, the Opera/IE behaviour is moot because the situation never arises. -- Stewart Brodie Software Engineer ANT Software Limited From alexey at feldgendler.ru Tue Aug 1 07:32:49 2006 From: alexey at feldgendler.ru (Alexey Feldgendler) Date: Tue, 01 Aug 2006 21:32:49 +0700 Subject: [whatwg] What should document.write() do when called from setTimeout or event handlers? In-Reply-To: References: Message-ID: On Tue, 01 Aug 2006 20:37:17 +0700, Stewart Brodie wrote: >> Mozilla seems to make the document.write() calls insert text into the >> parser, as if they'd been called inline, with the result that the >> inserted text could appear pretty much anywhere. (It's actually a bit >> more >> complex than that -- it avoids inserting into tokens -- but that's a >> detail.) Mozilla tokenizes text in blocks as it arrives from the network socket. document.write() in the described situation seems to insert the text after the already tokenized portion. This means that the observed behavior will depend on the network conditions. > I think we can do without Heisenberg-like effects from Mozilla :-) Indeed. :-) -- Alexey Feldgendler [ICQ: 115226275] http://feldgendler.livejournal.com From sd at sven-drieling.de Wed Aug 2 06:25:42 2006 From: sd at sven-drieling.de (Sven Drieling) Date: Wed, 2 Aug 2006 15:25:42 +0200 Subject: [whatwg] [canvas] Multiple closePath() after beginPath()? Message-ID: <200608021518.11667.sd@sven-drieling.de> Hello, is it allowed to use multiple closePath() calls after beginPath()? This works with Opera 9.00 to draw two triangles but the paired method names beginPath() and closePath() makes the impression that only one closePath() could follow one beginPath() call. Maybe a closeSubpath() method? ctx.beginPath(); ctx.moveTo( 60, 50); ctx.lineTo(110, 110); ctx.lineTo( 10, 110); ctx.closePath(); ctx.moveTo(180, 50); ctx.lineTo(230, 110); ctx.lineTo(130, 110); ctx.closePath(); ctx.stroke(); tschuess [|8:) From jworent at yahoo.com Thu Aug 3 12:04:11 2006 From: jworent at yahoo.com (Jonathan Worent) Date: Thu, 3 Aug 2006 12:04:11 -0700 (PDT) Subject: [whatwg] level attribute Message-ID: <20060803190411.31803.qmail@web32212.mail.mud.yahoo.com> I have just recently become interested in the work WHATWG is doing. I apologize if something like this has already been suggested. I'd like to suggest adding a level attribute to both em and strong tags. This attribute would be used to set the level of emphasis/importance, rather than by nesting. The level attribute would take a negative integer, to indicate, de-emphasis/less importance, a positive integer, to indicate increasing emphasis/importance, or a "0", to indicate the default. If the default is desired the level attribute could be left off, unless it is nested within an element that has changed the level (though I can't think of any examples where this would be good practice). There would need to be a reasonable limit for the number of levels, both positively and negatively Examples: I am getting very angry. I don't spend every waking moment on the computer, although my wife thinks otherwise. This is a bad example of where the default level has to be explicit stated. I think a level attribute is better than nesting because it allows for reducing the emphasis/importance below normal. Nesting can only increase this. A use-case where de-emphasis would be needed is in marking up a transcript. (WCAG requires this for accessibility) De-emphasis could be used to indicate that the speaker whispered. A use-case where indicating less importance would be needed would be digression. This is different than aside IMHO. I understand that this is not backwards compatible. But, IMHO, neither is nesting elements. Future browsers already will have to change to understand that nesting em or strong increases emphasis/importance. They could also be changed to understand the level attribute. If this cannot be done then I would suggest as an alternative: Add 2 new elements. One for indicating de-emphasis, One of indicating less importance. I leave the naming of them to you. Thank you, Jonathan --------------------------------- Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juanrgonzaleza at canonicalscience.com Fri Aug 4 00:30:23 2006 From: juanrgonzaleza at canonicalscience.com (juanrgonzaleza at canonicalscience.com) Date: Fri, 4 Aug 2006 00:30:23 -0700 (PDT) Subject: [whatwg] level attribute In-Reply-To: References: Message-ID: <3247.217.124.88.218.1154676623.squirrel@webmail.canonicalscience.com> Jonathan Worent said: > > I have just recently become interested in the work WHATWG is doing. I > apologize if something like this has already been suggested. > > I'd like to suggest adding a level attribute to both em and strong tags. > This attribute would be used to set the level of emphasis/importance, > rather than by nesting. The level attribute would take a negative > integer, to indicate, de-emphasis/less importance, a positive integer, > to indicate increasing emphasis/importance, or a "0", to indicate the > default. If the default is desired the level attribute could be left > off, unless it is nested within an element that has changed the level > (though I can't think of any examples where this would be good > practice). There would need to be a reasonable limit for the number of > levels, both positively and negatively > > Examples: > I am getting very angry. This remember me the highlight tag of some markup language. > I don't spend every waking moment on the computer, level="-1">although my wife thinks otherwise. > > This is a bad example of where the level="0">default level has to be explicit > stated. > > I think a level attribute is better than nesting because it allows for > reducing the emphasis/importance below normal. Nesting can only > increase this. Not necesarily. level-1level-2 level-2level-1 define proper CSS rules for but more natural appears to be changing the markup for deemphasizing. level-2level-1 > A use-case where de-emphasis would be needed is in marking up a > transcript. (WCAG requires this for accessibility) De-emphasis could be > used to indicate that the speaker whispered. > > A use-case where indicating less importance would be needed would be > digression. This is different than aside IMHO. > > I understand that this is not backwards compatible. But, IMHO, neither > is nesting elements. Future browsers already will have to change to > understand that nesting em or strong increases emphasis/importance. They > could also be changed to understand the level attribute. > > If this cannot be done then I would suggest as an alternative: Add 2 new > elements. One for indicating de-emphasis, One of indicating less > importance. I leave the naming of them to you. The advantage of nesting and reason for the new heading model of XHTML2 is in that you do not need be aware of structure at each instant. Absolute levels h1, h2, h3... are to be avoided in next XHTML2. Why would we reintroduce it in and now? I also find problems with CSS and definition of levels. Is level="2" absolute, i.e. independent of position of , or relative, i.e. level="2" over level="0" defined by container? > Thank you, > Jonathan > Juan R. Center for CANONICAL |SCIENCE) From ian at hixie.ch Sat Aug 5 16:38:58 2006 From: ian at hixie.ch (Ian Hickson) Date: Sat, 5 Aug 2006 23:38:58 +0000 (UTC) Subject: [whatwg] What should document.write() do when called from setTimeout or event handlers? In-Reply-To: References: Message-ID: On Tue, 1 Aug 2006, Alexey Feldgendler wrote: > > On Tue, 01 Aug 2006 05:34:55 +0700, Ian Hickson wrote: > > > IE seems to make those calls to document.write() simply blow away the > > document, as if the document was closed. Opera seems to do the same. > > I think this is the best thing to do. Easy to implement and well-defined. It's not particularly well-defined, since you have to now make a distinction between scripts that are executing "inline", and scripts that were started by scripts executing inline but are actually executing in a different context. It basically means that the behaviour of document.write() depends on more than the current state of the browser, it depends on the call stack of the script executing. That's quite weird. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Sat Aug 5 16:43:32 2006 From: ian at hixie.ch (Ian Hickson) Date: Sat, 5 Aug 2006 23:43:32 +0000 (UTC) Subject: [whatwg] What should document.write() do when called from setTimeout or event handlers? In-Reply-To: References: Message-ID: On Tue, 1 Aug 2006, Stewart Brodie wrote: > > > > IE seems to make those calls to document.write() simply blow away the > > document, as if the document was closed. Opera seems to do the same. > > In other words, they treat it like being in an event handler context > where document.write is for replacing the entire document. That seems > entirely reasonable to me. > > Calling document.write() directly whilst in an event handler context > must blow the document away too, well, once you do document.close() that > is. Well, once the document is closed (completed parsing), then sure, document.write() should blow away the document. But here we're talking about scripts that are executing while the document is being parsed. > > Mozilla seems to make the document.write() calls insert text into the > > parser, as if they'd been called inline, with the result that the > > inserted text could appear pretty much anywhere. (It's actually a bit > > more complex than that -- it avoids inserting into tokens -- but > > that's a detail.) > > I think we can do without Heisenberg-like effects from Mozilla :-) I agree that this kind of race-condition effect is bad, but we can mitigate that by defining clear places where the tokeniser looks at pending document.write()n text, so this doesn't have to be quite as crazy as Mozilla's implementation. > > I couldn't work out what Safari and MacIE do; they seem to delay the > > timeout somehow and then print to the end of the page. > > Possibly they are preventing setTimeout/setInterval timeouts from firing > until the document is loaded? I don't think so. They seem to only delay the document.write() calls. > Finding a suitable definition for "until the document is loaded" remains > problematic. Well, that's "when the load event fires". We'll have to document that in detail in due course. > Easiest to disallow it like Safari/MacIE or behave like IE/Opera. I > prefer the Safari way (it's what I've implemented, anyway :-) Of > course, if you implement the Safari way, the Opera/IE behaviour is moot > because the situation never arises. The Safari way has the problem that it means you can end up blocking once script while another script executes, which is a very bad situation to be in (theoretically, JS is not re-entrant except in well-defined cases). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jworent at yahoo.com Sun Aug 6 16:13:30 2006 From: jworent at yahoo.com (Jonathan Worent) Date: Sun, 6 Aug 2006 16:13:30 -0700 (PDT) Subject: [whatwg] level attribute Message-ID: <20060806231330.82699.qmail@web32211.mail.mud.yahoo.com> --- juanrgonzaleza at canonicalscience.com wrote: > Jonathan Worent said: > > > > I have just recently become interested in the work WHATWG is doing. I > > apologize if something like this has already been suggested. > > > > I'd like to suggest adding a level attribute to both em and strong tags. > > This attribute would be used to set the level of emphasis/importance, > > rather than by nesting. The level attribute would take a negative > > integer, to indicate, de-emphasis/less importance, a positive integer, > > to indicate increasing emphasis/importance, or a "0", to indicate the > > default. If the default is desired the level attribute could be left > > off, unless it is nested within an element that has changed the level > > (though I can't think of any examples where this would be good > > practice). There would need to be a reasonable limit for the number of > > levels, both positively and negatively > > > > Examples: > > I am getting very angry. > > This remember me the highlight tag of some markup language. > > > I don't spend every waking moment on the computer, > level="-1">although my wife thinks otherwise. > > > > This is a bad example of where the > level="0">default level has to be explicit > > stated. > > > > I think a level attribute is better than nesting because it allows for > > reducing the emphasis/importance below normal. Nesting can only > > increase this. > > Not necesarily. > > level-1level-2 > > level-2level-1 > > define proper CSS rules for And what if the css is ignored? The text gets emphesized instead of de-emphesized, which totally changes the meaning of the text. Using a level attribute make the meaning of the text explicit to the markup. Let me explain that. The fact that some text is given more or less emphesis/importance than other text changes its meaning. That should therefore be conveyed in the html. You can use css to modigy the way is it interpreted, but if the css is ignored the meaning is not changed. > > but more natural appears to be changing the markup for deemphasizing. > > level-2level-1 Can you give an example using proper sentince structure. I think there would be some instances where rearranging the sentince would be better but not in most cases. > > > A use-case where de-emphasis would be needed is in marking up a > > transcript. (WCAG requires this for accessibility) De-emphasis could be > > used to indicate that the speaker whispered. > > > > A use-case where indicating less importance would be needed would be > > digression. This is different than aside IMHO. > > > > I understand that this is not backwards compatible. But, IMHO, neither > > is nesting elements. Future browsers already will have to change to > > understand that nesting em or strong increases emphasis/importance. They > > could also be changed to understand the level attribute. > > > > If this cannot be done then I would suggest as an alternative: Add 2 new > > elements. One for indicating de-emphasis, One of indicating less > > importance. I leave the naming of them to you. > > The advantage of nesting and reason for the new heading model of XHTML2 is > in that you do not need be aware of structure at each instant. Absolute > levels h1, h2, h3... are to be avoided in next XHTML2. Why would we > reintroduce it in and now? > > I also find problems with CSS and definition of levels. Is level="2" > absolute, i.e. independent of position of , or relative, i.e. > level="2" over level="0" defined by container? I'm not totally sure what you mean. should have more importance than no matter the nesting. Of course, it would be bad practice to skip levels. > > > Thank you, > > Jonathan > > > > > > > Juan R. > > > > Center for CANONICAL |SCIENCE) > > > > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From alexey at feldgendler.ru Sun Aug 6 23:04:23 2006 From: alexey at feldgendler.ru (Alexey Feldgendler) Date: Mon, 07 Aug 2006 13:04:23 +0700 Subject: [whatwg] What should document.write() do when called from setTimeout or event handlers? In-Reply-To: References: Message-ID: On Sun, 06 Aug 2006 06:38:58 +0700, Ian Hickson wrote: >>> IE seems to make those calls to document.write() simply blow away the >>> document, as if the document was closed. Opera seems to do the same. >> I think this is the best thing to do. Easy to implement and well-defined. > It's not particularly well-defined, since you have to now make a > distinction between scripts that are executing "inline", and scripts that > were started by scripts executing inline but are actually executing in a > different context. It basically means that the behaviour of > document.write() depends on more than the current state of the browser, it > depends on the call stack of the script executing. That's quite weird. It's not that bad. It only depends on the open/closed state of the document, which is kept somewhere anyway. A call to document.close() or an end-of-stream closes a document. -- Alexey Feldgendler [ICQ: 115226275] http://feldgendler.livejournal.com From alexey at feldgendler.ru Sun Aug 6 23:08:17 2006 From: alexey at feldgendler.ru (Alexey Feldgendler) Date: Mon, 07 Aug 2006 13:08:17 +0700 Subject: [whatwg] What should document.write() do when called from setTimeout or event handlers? In-Reply-To: References: Message-ID: On Mon, 07 Aug 2006 13:04:23 +0700, Alexey Feldgendler wrote: >>>> IE seems to make those calls to document.write() simply blow away the >>>> document, as if the document was closed. Opera seems to do the same. >>> I think this is the best thing to do. Easy to implement and well-defined. >> It's not particularly well-defined, since you have to now make a >> distinction between scripts that are executing "inline", and scripts that >> were started by scripts executing inline but are actually executing in a >> different context. It basically means that the behaviour of >> document.write() depends on more than the current state of the browser, it >> depends on the call stack of the script executing. That's quite weird. > It's not that bad. It only depends on the open/closed state of the document, > which is kept somewhere anyway. A call to document.close() or an > end-of-stream closes a document. Please disregard my last message. But, anyway, I'm strongly against prohibiting event handling while the document is loading. Doing that would be removing functionality on which existing documents rely. -- Alexey Feldgendler [ICQ: 115226275] http://feldgendler.livejournal.com From juanrgonzaleza at canonicalscience.com Mon Aug 7 03:22:12 2006 From: juanrgonzaleza at canonicalscience.com (juanrgonzaleza at canonicalscience.com) Date: Mon, 7 Aug 2006 03:22:12 -0700 (PDT) Subject: [whatwg] level attribute In-Reply-To: <20060806231330.82699.qmail@web32211.mail.mud.yahoo.com> References: <20060806231330.82699.qmail@web32211.mail.mud.yahoo.com> Message-ID: <3137.217.124.88.188.1154946132.squirrel@webmail.canonicalscience.com> Jonathan Worent said: > --- juanrgonzaleza at canonicalscience.com wrote: > >> Jonathan Worent said: >> > >> > I think a level attribute is better than nesting because it allows >> for reducing the emphasis/importance below normal. Nesting can only >> increase this. >> >> Not necesarily. >> >> level-1level-2 >> >> level-2level-1 >> >> define proper CSS rules for > > And what if the css is ignored? The text gets emphesized instead of > de-emphesized, which totally changes the meaning of the text. Using a > level attribute make the meaning of the text explicit to > the markup. Let me explain that. The fact that some text is given more > or less emphesis/importance > than other text changes its meaning. That should therefore be conveyed > in the html. You can use css to modigy the way is it interpreted, but if > the css is ignored the meaning is not changed. Well, sure but why would the css be ignored? Moreover, how would the level attribute degrade to old UAs. HTML 4 compatible systems would understand incorrectly the em structure, changing the meaning also. >> >> but more natural appears to be changing the markup for deemphasizing. >> >> level-2level-1 > > Can you give an example using proper sentince structure. I think there > would be some instances where rearranging the sentince would be better > but not in most cases. I cannot see any case where a level-n attribute cannot be represented as n nested s. >> > I understand that this is not backwards compatible. But, IMHO, >> neither is nesting elements. Future browsers already will have to >> change to understand that nesting em or strong increases >> emphasis/importance. They could also be changed to understand the >> level attribute. Take your example: I don't spend every waking moment on the computer, although my wife thinks otherwise. A _current_ browser (asuming that can ignore the level attribute) would understand: I don't spend every waking moment on the computer, although my wife thinks otherwise. changing the meaning. >> > If this cannot be done then I would suggest as an alternative: Add 2 >> new elements. One for indicating de-emphasis, One of indicating less >> importance. I leave the naming of them to you. I do not understand this. We begin from a level-0 in HTML and next we add levels of emphasis with . Then

normal level, emphasis simple, emphasis double emphasis simple again

If i want eliminate a level of emphasis simply close the and i recover an inferior level. There is not need for a de-emphasis

normal level, emphasis simple, emphasis double emphasis simple again

>> The advantage of nesting and reason for the new heading model of >> XHTML2 is in that you do not need be aware of structure at each >> instant. Absolute levels h1, h2, h3... are to be avoided in next >> XHTML2. Why would we reintroduce it in and now? >> >> I also find problems with CSS and definition of levels. Is level="2" >> absolute, i.e. independent of position of , or relative, i.e. >> level="2" over level="0" defined by container? > > I'm not totally sure what you mean. should have more > importance than no matter the nesting. Of course, it > would be bad practice to skip levels. In current HTML, heading levels are absolute. This mean that when you modify the structure of any doc, e.g. simply copying and pasting a fragment into other doc the heading structure usually change obligating to you to retype the whole document. This is very odd whith dinamic docs and multi-authoring and editing of docs. Absolute levels were eliminated from next XHTML2 (in fact other approaches were using relative levels for headings). Instead

XHTML2 (and other approaches) works
now i copy and paste into other doc

The XHTML structure is automatically updated, the HTML structure is not and may be admended now to

Similar thoughts apply to absolute levels of emphasis. >> > Thank you, >> > Jonathan I personally hate absolute levels of anything in a dynamic world as the web is but can understand that some people prefer the contrary. Juan R. Center for CANONICAL |SCIENCE) From ian at hixie.ch Mon Aug 7 04:09:42 2006 From: ian at hixie.ch (Ian Hickson) Date: Mon, 7 Aug 2006 11:09:42 +0000 (UTC) Subject: [whatwg] What should document.write() do when called from setTimeout or event handlers? In-Reply-To: References: Message-ID: On Mon, 7 Aug 2006, Alexey Feldgendler wrote: > > But, anyway, I'm strongly against prohibiting event handling while the > document is loading. Doing that would be removing functionality on which > existing documents rely. Agreed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From fora at annevankesteren.nl Thu Aug 10 02:46:15 2006 From: fora at annevankesteren.nl (Anne van Kesteren) Date: Thu, 10 Aug 2006 11:46:15 +0200 Subject: [whatwg] XMLHttpRequest: getAllResponseHeaders In-Reply-To: References: <42B93C48.19515.3CF9DA5@localhost> <42B94117.32300.3E2667A@localhost> <43D7E581.22134.1AE875F9@hallvord.hallvord.com> Message-ID: On Mon, 30 Jan 2006 13:47:34 +0100, Hallvord R M Steen wrote: > By the way, about "getResponseHeader" the sentence: > >> If no headers of that name were received, then returns the >> empty string > > should be fixed to say "returns null". Fixed. Please raise new issues on public-webapi at w3.org. -- Anne van Kesteren From aaronlev at moonset.net Thu Aug 10 15:04:34 2006 From: aaronlev at moonset.net (Aaron Leventhal) Date: Thu, 10 Aug 2006 18:04:34 -0400 Subject: [whatwg] Dynamic content accessibility in HTML today In-Reply-To: <3247.217.124.88.218.1154676623.squirrel@webmail.canonicalscience.com> References: <3247.217.124.88.218.1154676623.squirrel@webmail.canonicalscience.com> Message-ID: <44DBAD72.2040207@moonset.net> Firefox has support for making dynamic web applications with custom JS widgets accessible, via support for xhtml:role and aaa: properties. If anyone would be interested in taking a look, I would welcome feedback. In Firefox 1.5 the role attribute had to use the xhtml2 namespace. However, Firefox 2 will allow the role attribute in XHTML 1.x. See "XHTML Role Attribute Module": http://www.w3.org/TR/2006/WD-xhtml-role-20060725/ I have a specific question: what about adding the role attribute to whatwg specs? I know Hixie mentioned that he would prefer the element tag itself always specify the role, rather than using a role attribute which can conflict and override that. XBL was going to be the solution for creating custom widgets, which I prefer myself. In an ideal world, I think we'd be able to just create new custom widgets via XBL and define that accessibility there. However, I thought I'd ask anyway because the role attribute does fill some niches: 1) a11y in SVG 2) roles that no specs today have, which provide important accessibility functions, such as liveregion for AJAX accessibility (perhaps we should try to synchronize the 2 sometime) 3) ability to fix a11y in JS apps that exist today 4) ability to create new custom roles -- this is still under development (at the moment it uses RDF, but I believe the group will consider XBL moving forward) 5) The role attribute allows us to specify additional semantics without conflicting with older browsers For more info -- Here are some docs for those interested in comparing what we have with whatwg: Developer docs & intro: http://developer.mozilla.org/en/docs/Accessible_DHTML For those who have w3c member access (apologies for that): Roles: http://www.w3.org/WAI/PF/Group/GUI/roleTaxonomy-20060809/ States: http://www.w3.org/WAI/PF/Group/adaptable/StatesAndProperties-20060809/ - Aaron From mattraymond at earthlink.net Sat Aug 12 03:15:13 2006 From: mattraymond at earthlink.net (Matthew Raymond) Date: Sat, 12 Aug 2006 06:15:13 -0400 Subject: [whatwg] Dynamic content accessibility in HTML today In-Reply-To: <44DBAD72.2040207@moonset.net> References: <3247.217.124.88.218.1154676623.squirrel@webmail.canonicalscience.com> <44DBAD72.2040207@moonset.net> Message-ID: <44DDAA31.5090706@earthlink.net> Aaron Leventhal wrote: > Firefox has support for making dynamic web applications with custom JS > widgets accessible, via support for xhtml:role and aaa: properties. If > anyone would be interested in taking a look, I would welcome feedback. What Firefox is doing for DHTML accessibility has a very narrow use case. It applies to DHTML widgets, that are not bound to fallback markup using XBL, where a proper CSS presentation for the users primary media is not available, and where the CSS3-UI "appearance" property doesn't provide a proper value. I suspect that many DHTML widgets, however, won't necessarily have a corresponding predefined |role| value, which means |role| essentially becomes just another vector for microformats. I don't see a significant difference between |role| and predefined values for |class|. For instance, I believe Dublin Core specifies predefined |class| values, so it's not like there's no precedence for it. The only difference is that |class| doesn't explicitly state that it can be used for such purposes. > I have a specific question: what about adding the role attribute to > whatwg specs? I don't see any sufficient benefit from it. I'd rather see a clarification of how |class| can be used. > However, I thought I'd ask anyway because the role attribute does fill > some niches: > > 1) [accessibility] in SVG I don't understand. Could you provide a use case? BTW, how would this even apply for HTML, which has no namespaces? > 2) roles that no specs today have, which provide important accessibility > functions, such as liveregion for AJAX accessibility (perhaps we should > try to synchronize the 2 sometime) I'm not following you here. This sounds a lot like microformats. > 3) ability to fix [accessibility] in JS apps that exist today There are only a small number of supported values for the |role| attribute. Most of those are covered by tags in HTML5:
<--> "main"
<--> "secondary"???