Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
Asbjørn Ulsberg wrote: Improving on the legacy, proprietary DOM just isn't feasible, imo. Are there particular parts that overlap between IE's DOM and the standard DOM where IE's implementation is non-compliant? If not, why can't IE simply support both sets of methods at the same time? (In other words, add the standard DOM classes, methods and events while leaving in all of the proprietary stuff that people depend on.)
Re: [whatwg] base versus xml:base
On Tue, 13 Mar 2007 19:15:12 +0100, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: They don't conflict. They are both applied. base is the document's base URI, and xml:base is the base URI of the element it is applied on. What about: base href=http://www.example.org/; xml:base=/bar / I suppose xml:base= should affect href=. That would make it consistent with img src=... xml:base=.../ at least. Interesting sample. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] base versus xml:base
2007/3/14, Anne van Kesteren: On Tue, 13 Mar 2007 19:15:12 +0100, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: They don't conflict. They are both applied. base is the document's base URI, and xml:base is the base URI of the element it is applied on. What about: base href=http://www.example.org/; xml:base=/bar / I suppose xml:base= should affect href=. That would make it consistent with img src=... xml:base=.../ at least. Interesting sample. How about this variation: head xml:base=bar/ base href=foo/ / /head Is the [EMAIL PROTECTED] resolved to absolute using [EMAIL PROTECTED]:base or not? If it is, then when looking at links inside head, relative URIs are resolved using a base of bar/foo/bar/ (taking [EMAIL PROTECTED]:base into account twice: once to resolve [EMAIL PROTECTED], which sets the document's base URI, and then relative to that base URI to resolve [EMAIL PROTECTED]'s). If it is not, then base is in violation of the xml:base spec AFAICT. I'd personally only allow absolute URI references in [EMAIL PROTECTED] We still have to cope with legacy content which uses a relative URI, but then they're likely not XHTML, so xml:base is simply ignored. This could be solved by saying that if there is an xml:base in scope, then base is ignored for the whole document. A quick test with Firefox shows that xml:base is applied but base seems to be ignored in application/xhtml+xml documents. Just some thoughts… -- Thomas Broyer
Re: [whatwg] base versus xml:base
On Wed, 14 Mar 2007 10:17:48 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: They don't conflict. They are both applied. base is the document's base URI, and xml:base is the base URI of the element it is applied on. What about: base href=http://www.example.org/; xml:base=/bar / I suppose xml:base= should affect href=. That would make it consistent with img src=... xml:base=.../ at least. Interesting sample. Please ignore the comment above. It would lead to silly loops. base href=, if relative, should be resolved against the document location and not against (any) xml:base. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Embedding Elements Should be Structured Inline-Level
Le 2007-03-14 à 1:23, Lachlan Hunt a écrit : Hi, The spec currently defines most embedding elements (img, iframe, embed, object, video and canvas) as strictly inline level and thus only allows them to be used in contexts where strictly inline level content may be used. I think these elements should be defined as structured inline-level elements. When used in block level contexts, they should represent paragraphs. You're right that it's often a little silly to have an image alone in its own paragraph. But maybe we could use figure for these cases: figure img /figure Ok, this is not conformant with the current spec since it's missing a legend, but in my opinion it should be allowed. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
[whatwg] List of links idea (href= stuff)
The most common use case for href= on every element seems to be about removing lots of characters when creating a navigation menu or a blog roll or similar list. So instead of typing ul lia href=test/a ... you would type ul li href=test ... Maybe we can change the content model of ul (and perhaps ol) to allow a series of a elements: ul a href=test/a ... For backwards compatibility text content would be allowed inside ul but must be ignored for the purposes of determining the semantics of the content (in a conforming HTML5 UA). This would allow: ul a href=test/a | a href=test/a | ... Alternatively nav could be redefined to have this type of semantics when its content model is just a elements and text content. (Also thanks to Sjoerd Visscher.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] IRIs vs. URIs
L. David Baron on 2007-03-13: I tend to think it would be good that new uses of URIs/IRIs document that they are really IRIs and therefore this reverse-encoding behavior should not be used, but instead encoding should be done as UTF-8. You cannot have UTF-8 encoding just for the URIs/IRIs, and another encoding for the rest of the source text. To properly parse a URI/IRI in the source document, you must first convert the bytes in the resource into a stream of Unicode characters. (In Mozilla's codebase such distinctions are easy to implement since we have to pass along the encoding of the document every time we create a URI in order to get this backwards-compatible behavior. Of course, you will need to take special care to handle query data that is stored as plain non-ASCII bytes in the source document, so you would still need to pass around that document encoding. It would probably be good if the spec documented how the encoding issues in URIs are actually handled. Indeed. Considering the number of partly contradicting bug reports we have here at Opera on the issue, it would be nice to have it clearly spelled out, so that everyone is doing the same thing, and that we are doing what the user expects. -- \\// Peter, software engineer, Opera Software The opinions expressed are my own, and not those of my employer. Please reply only by follow-ups on the mailing list.
Re: [whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)
On Mon, 12 Mar 2007 01:01:38 +0100, Matthew Ratzloff [EMAIL PROTECTED] wrote: The Web has done great so far without it? When strict mode was introduced, all existing websites didn't suddenly start rendering under it. It was opt-in. Versioning is just a formalized way of opting into a certain rendering method. On 14/03/07, Anne van Kesteren [EMAIL PROTECTED] wrote: FWIW: Introducing strict mode has been quite painful and still is. Every time you encounter a rendering bug on some web page you have to check on what rendering mode the page relies (quirks, almost standards or standards) and then figure out what the behavior should be for quirks and almost standards by reverse engineering other popular browsers. Next time such a thing comes up we should just fix the specifications instead in my opinion to keep things predictable for authors and easy for implementors. Well, the original question wasn't about versioning in particular as much as it was Microsoft asking developers (not spec writers) for something, anything, that they can use to tell whether the author has written the document for HTML5 and more important the standard DOM, so they can avoid breaking pages on the web that assume the old iew tagsoup parser and quirky not-quite-standard DOM. One thing in particular - I don't think iew can at all change the events model to follow standard DOM in their compatibility-with-the-web mode. Other browsers evidently can work with standard DOM, so the spec isn't broken. It's just that Microsoft have painted themselves into a corner and need a way for authors to tell iew that their documents don't rely on their old proprietary DOM-tagsoup-CSS handling. The HTML5 spec doesn't even need to deal with that. If the spec provides a way for authors to sing their documents as not relying on old iew behaviour, all Microsoft needs is a hint from the developers, or the spec writers, that they can use that to switch. Other browsers can calmly carry on doing whatever they were doing before. I don't think Microsoft are asking for a versioning scheme, they don't intend to make a new locked down mode that needs replacing in the future. They already have a CSS switch, now they need a DOM switch to accompany that. With ie7 they proved they weren't afraid of breaking sites using the standards rendering mode in the name of improving their standards support on the CSS side, so in all likelyhood the DOM switch will similarly not require versioning. Microsoft absolutely REQUIRE this switch however. Without it there is no way for them to correct their behaviour even if all other browsers are doing just fine with complying to the standard DOM. This is a switch out of backwards-compatibility-hell for a single specific browser they are asking for, not something any other browser vendor should have to worry about. And I don't see any reason why !DOCTYPE html shouldn't be the switch seeing as developers are already used to DOCTYPEs as mode switches. -- David liorean Andersson
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
Asbjørn Ulsberg wrote: Improving on the legacy, proprietary DOM just isn't feasible, imo. On 14/03/07, Martin Atkins [EMAIL PROTECTED] wrote: Are there particular parts that overlap between IE's DOM and the standard DOM where IE's implementation is non-compliant? Several, yeah. Most important is the events model. If not, why can't IE simply support both sets of methods at the same time? (In other words, add the standard DOM classes, methods and events while leaving in all of the proprietary stuff that people depend on.) Oh, without overlap everything would be fine and dandy. However, consider how many scripts would break with just the simple change of including all newline/whitespace text nodes in the DOM... Sure, any sensibly coded script won't break because of this sense because it's already coded so that a single piece of code handles both cases. But everything that does a browser check and forks will suddenly fail. And I think we all know that the vast majority of scripts out there aren't sensibly coded. -- David liorean Andersson
Re: [whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)
On Wed, 14 Mar 2007 16:16:49 +0100, liorean [EMAIL PROTECTED] wrote: Well, the original question wasn't about versioning in particular as much as it was Microsoft asking developers (not spec writers) for something, anything, that they can use to tell whether the author has written the document for HTML5 and more important the standard DOM, so they can avoid breaking pages on the web that assume the old iew tagsoup parser and quirky not-quite-standard DOM. [...] Oh, yeah, I think !doctype html would be a good switch for Internet Explorer to use if they indeed need such a thing in text/html (besides doing the sane thing in XML). I've suggested that to them in the past. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Versioning
liorean wrote: Well, the original question wasn't about versioning in particular as much as it was Microsoft asking developers (not spec writers) for something, anything, that they can use to tell whether the author has written the document for HTML5 I could well have missed this, but has Microsoft actually asked for this? I didn't hear them ask for it, but I haven't read every message in the thread. I'd hate to add something for this purpose if Microsoft hasn't made a firm commitment to actually use it. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
Re: [whatwg] Versioning
On Wed, 14 Mar 2007 16:47:01 +0100, Elliotte Harold [EMAIL PROTECTED] wrote: Well, the original question wasn't about versioning in particular as much as it was Microsoft asking developers (not spec writers) for something, anything, that they can use to tell whether the author has written the document for HTML5 I could well have missed this, but has Microsoft actually asked for this? I didn't hear them ask for it, but I haven't read every message in the thread. I'd hate to add something for this purpose if Microsoft hasn't made a firm commitment to actually use it. Nobody is talking about adding. It was suggested that Microsoft, if desired, could utilize !doctype html as a trigger for real standards mode. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Embedding Elements Should be Structured Inline-Level
For the given use case: header h1img src=/images/logo alt=Company Name/h1 object data=flash/object /header I think figure is in appropriate. The spec says: 'The |figure http://www.whatwg.org/specs/web-apps/current-work/#figure0| element represents a paragraph http://www.whatwg.org/specs/web-apps/current-work/#paragraph consisting of embedded content and a caption.' and from a semantic point of view, figure seems to connote an illustration or explanatory image. In the use case - a company logo - h1 is IMO important markup: the company logo is the document heading. I have no problems with images remaining inline only. Colin Lieberman Michel Fortin wrote: Le 2007-03-14 à 1:23, Lachlan Hunt a écrit : Hi, The spec currently defines most embedding elements (img, iframe, embed, object, video and canvas) as strictly inline level and thus only allows them to be used in contexts where strictly inline level content may be used. I think these elements should be defined as structured inline-level elements. When used in block level contexts, they should represent paragraphs. You're right that it's often a little silly to have an image alone in its own paragraph. But maybe we could use figure for these cases: figure img /figure Ok, this is not conformant with the current spec since it's missing a legend, but in my opinion it should be allowed. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)
Anne van Kesteren Wrote IE doesn't have a broken box model in standards mode. I was under the impression you wanted to throw out different rendering modes because they are difficult for implementors. If so, at least for IE (and presumably quirksmode in other browsers, since they tend to mimmic IE's quirks), there would be two box models that aren't reconcilable. Authors code against implementations, not specifications. Yeah, authors eventually end up doing browser testing, and, in that way, code against an implementation. However, I have to look at the specification to determine what is valid markup. It seems, according to implementations, that HTML, HTML-XHTML, and real XHTML all allow user invented tags. While they don't validate (validating is coding against a spec), the browsers I test on all rendered the content and applied CSS markup. Except for Safari in real XHTML, the element was added to the DOM and accessible with JavaScript. This seems roughly congruent with HTML specs[2], though I don't know if it is congruent with CSS specs and DOM specs. However, if I code against the implementation, not bothering to code against the specification (e.g. by validation or by looking at the specification), I can make up my own elements and have them render on the page. Since validation is a part of the web standards movement, I would say that authors worth their salt will code against both implementations and specifications. [1] http://whatwg.robertdot.org/files/20070314-invented-tags/ [2] http://www.w3.org/TR/html4/appendix/notes.html#notes-invalid-docs -- Robert http://robertdot.org
Re: [whatwg] Versioning
Elliotte Rusty Harold wrote: I could well have missed this, but has Microsoft actually asked for this? I didn't hear them ask for it, but I haven't read every message in the thread. I posted a link to at least one instance where Chris Wilson of the IE Team asked for an additional standards mode opt-in that would provide better standards rendering.[1] I forgot the exact time he asked for it (it was around 18:00), but his talk leading up to it starts at 15:00. [1] http://yuiblog.com/blog/2007/03/05/browserwars/ -- Robert http://robertdot.org
Re: [whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)
On 14 Mar 2007, at 15:16, liorean wrote: This is a switch out of backwards-compatibility-hell for a single specific browser they are asking for, not something any other browser vendor should have to worry about. Other browsers introduced quirks mode to match buggy behaviour of others – what's to say that won't happen here, so that other browsers have an IE/Win DOM mode, which would therefore require a switch? - Geoffrey Sneddon
Re: [whatwg] Versioning
On Wed, 14 Mar 2007 18:20:43 +0100, Robert Brodrecht [EMAIL PROTECTED] wrote: Anne van Kesteren Wrote IE doesn't have a broken box model in standards mode. I was under the impression you wanted to throw out different rendering modes because they are difficult for implementors. If so, at least for IE and presumably quirksmode in other browsers, since they tend to mimmic IE's quirks), there would be two box models that aren't reconcilable. No, I don't want to introduce more rendering modes. I explained that having standards mode is already a pain. If for Internet Explorer having a real standards mode is unavoidable for some reason I'd suggest (and have) that they use !doctype html in text/html and XML in general to trigger it. Authors code against implementations, not specifications. Yeah, authors eventually end up doing browser testing, and, in that way, code against an implementation. However, I have to look at the specification to determine what is valid markup. You're not a normal author then. 97% of the web or so contains syntax errors. It seems, according to implementations, that HTML, HTML-XHTML, and real XHTML all allow user invented tags. While they don't validate (validating is coding against a spec), the browsers I test on all rendered the content and applied CSS markup. Except for Safari in real XHTML, the element was added to the DOM and accessible with JavaScript. This seems roughly congruent with HTML specs[2], though I don't know if it is congruent with CSS specs and DOM specs. However, if I code against the implementation, not bothering to code against the specification (e.g. by validation or by looking at the specification), I can make up my own elements and have them render on the page. Since validation is a part of the web standards movement, I would say that authors worth their salt will code against both implementations and specifications. I'm not sure what this has to do with the other points made in this thread. [1] http://whatwg.robertdot.org/files/20070314-invented-tags/ [2] http://www.w3.org/TR/html4/appendix/notes.html#notes-invalid-docs -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Versioning
On Wed, 14 Mar 2007 18:13:14 +0100, Geoffrey Sneddon [EMAIL PROTECTED] wrote: This is a switch out of backwards-compatibility-hell for a single specific browser they are asking for, not something any other browser vendor should have to worry about. Other browsers introduced quirks mode to match buggy behaviour of others – what's to say that won't happen here, so that other browsers have an IE/Win DOM mode, which would therefore require a switch? I don't think you can compare the current quirks mode with something for which non-IE browsers would have to essentially rethink how to implement the DOM (allowing incest relations) and rendering (hasLayout comes to mind). Some of the things there fundamentally break with both the DOM and CSS specifications. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On Tue, 13 Mar 2007 22:33:54 +0100, Simon Pieters [EMAIL PROTECTED] wrote: The only way to not break 50% of the web is to invent a new mode that gives the IE developers a blank sheet they can begin to draw on. FWIW, I think the 50% figure is incorrect. According to [1], 90% of the web use quirks mode. Although it's great to get the right numbers on the table, it isn't really relevant for this discussion. If the IE team feels an obligation to maintain backwards compatibility with CSS1Compat and thus has a need to introduce another rendering switch, then that's what matters. The discussion is then how this should be enabled, and my proposal is with !DOCTYPE html. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: [whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)
liorean wrote: Well, the original question wasn't about versioning in particular as much as it was Microsoft asking developers (not spec writers) for something, anything, that they can use to tell whether the author has written the document for HTML5 and more important the standard DOM, so they can avoid breaking pages on the web that assume the old iew tagsoup parser and quirky not-quite-standard DOM. I think that is why they changed the subject of the thread. That thread is still available for discussion. I mentioned some versioning stuff that happened to strike a vein. The HTML5 spec doesn't even need to deal with that. I wholeheartedly agree. That is why I proposed an HTTP header that would be completely proprietary and controlled by Microsoft. It could be either a real header or a meta http-equiv tag. The only advantage to having some item in the HTML 5 spec is that it would be something authors already use, thus saving a few extra seconds to create the HTTP header. The disadvantage is that I think the IE team would want something they could apply to HTML 4 and XHTML documents as well. So, it'd have to be something backward compatible. I don't think Microsoft are asking for a versioning scheme, they don't intend to make a new locked down mode that needs replacing in the future. I don't think they are either. I was initially hoping to solve two problems at once (lack of versioning and the IE switch). After thinking on it, I came to the same conclusion as you: a IE-only switch shouldn't be part of any spec. A quick way to offer the deliverable is with an http header. It can be easily added to existing sites with .htaccess files, as well. This is a switch out of backwards-compatibility-hell for a single specific browser they are asking for, not something any other browser vendor should have to worry about. And I don't see any reason why !DOCTYPE html shouldn't be the switch seeing as developers are already used to DOCTYPEs as mode switches. It won't work as a switch if you want Super-Standards Mode in HTML 4 and XHTML documents. I know I want that option. -- Robert http://robertdot.org
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
Asbjørn Ulsberg wrote: On Tue, 13 Mar 2007 22:33:54 +0100, Simon Pieters [EMAIL PROTECTED] wrote: The only way to not break 50% of the web is to invent a new mode that gives the IE developers a blank sheet they can begin to draw on. FWIW, I think the 50% figure is incorrect. According to [1], 90% of the web use quirks mode. Although it's great to get the right numbers on the table, it isn't really relevant for this discussion. If the IE team feels an obligation to maintain backwards compatibility with CSS1Compat and thus has a need to introduce another rendering switch, then that's what matters. The discussion is then how this should be enabled, and my proposal is with !DOCTYPE html. Sorry I must be missing something here. As far as I can tell, there is no specification related issue here. If the IE team want to introduce a new rendering mode they could indeed switch on the doctype. However there is nothing we can do to make this happen so there seems little point in discussing it. I suppose one could argue over whether HTML5 should include the possibility of language version information in the document. However, exisiting implementators have reported that trying to switch rendering based on such information is highly undesirable because of the additional difficulty of development and testing. Therefore the spec instead takes the point of view that all future development of the HTML language must be backward compatible so that such switches are not needed. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
On Wed, 14 Mar 2007 16:25:08 +0100, liorean [EMAIL PROTECTED] wrote: Are there particular parts that overlap between IE's DOM and the standard DOM where IE's implementation is non-compliant? Several, yeah. Most important is the events model. Thanks for pointing it out. The handling of whitespace is also quite different. Oh, without overlap everything would be fine and dandy. However, consider how many scripts would break with just the simple change of including all newline/whitespace text nodes in the DOM... Sure, any sensibly coded script won't break because of this sense because it's already coded so that a single piece of code handles both cases. But everything that does a browser check and forks will suddenly fail. And I think we all know that the vast majority of scripts out there aren't sensibly coded. Exactly. IE needs a new DOM. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: [whatwg] Versioning
Anne van Kesteren Wrote If for Internet Explorer having a real standards mode is unavoidable for some reason I'd suggest (and have) that they use !doctype html in text/html and XML in general to trigger it. I'd love to use their super-standards mode in HTML4 and / or XHTML. Or maybe use it some time in the next few years, if it were available before HTML 5 was completed. Using the HTML 5 doctype will not allow me to do that. I'm not sure what this has to do with the other points made in this thread. I was replying to your assertion that authors code against implementations, not specifications by: 1) Giving a good reason why not to code against implementation only (because the author can make up arbitrary elements and use them in practice, hence the examples). Creating proprietary markup does not ensure the longevity of the document, breaking with the ideals of standards. Coding against implementations allows me to create proprietary markup. 2) Say that validation is a big part of the web standards movement. Validation is coding against specifications. Therefore, at least in the standards movement, people code against implementations AND specifications, and at least attempt to create valid markup, even if they don't always succeed. Not just implementations as you asserted. 3) Because, ultimately, a policy of letting implementors dictate standards as-they-go doesn't seem like a good idea. (However, you've cleared that up some, and I hope you mean something more along the lines of: if the innerHTML functionality in JavaScript implementations is added to the DOM specification; in that case, the implementation is providing much needed functionality that the specification should have had in the first place. That is different than, say, Microsoft changing the specs for the W3C box model because IE's bad implementation had a large user base.) That said, this has ended up completely off topic. -- Robert http://robertdot.org
Re: [whatwg] base versus xml:base
On Wed, 14 Mar 2007 10:17:48 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: base href=http://www.example.org/; xml:base=/bar / I suppose xml:base= should affect href=. The XML Base[1] specification says: The base URI for a URI reference appearing in any other attribute value, including default attribute values, is the base URI of the element bearing the attribute. Let's say the document from my example was located on 'http://users.example.org/bob/'. According to the XML Base specification, the initial base URI of the document (in this example) is «the URI used to retrieve the entity». Since 'xml:base' affects base, and not the other way around (I would presume), the base URI of the document, after processing the base element, should be: http://users.example.org/bar That is, if 'xml:base' is processed before the base element. And according to the XML Base specification, I'd say that is the case. If not, base is a special case element where 'xml:base' doesn't apply or is applied after the 'href' value has been resolved. That would make it consistent with img src=... xml:base=.../ at least. Interesting sample. Yep. [1] http://www.w3.org/TR/xmlbase/ -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: [whatwg] base versus xml:base
On Wed, 14 Mar 2007 11:40:04 +0100, Thomas Broyer [EMAIL PROTECTED] wrote: How about this variation: head xml:base=bar/ base href=foo/ / /head Is the [EMAIL PROTECTED] resolved to absolute using [EMAIL PROTECTED]:base or not? I'd say it is. At least according to XML Base. The HTML specification can of course state otherwise, but the smartest thing to do would be to not break 'xml:base' processing rules in HTML, even if base is a special case element. If it is, then when looking at links inside head, relative URIs are resolved using a base of bar/foo/bar/ (taking [EMAIL PROTECTED]:base into account twice: once to resolve [EMAIL PROTECTED], which sets the document's base URI, and then relative to that base URI to resolve [EMAIL PROTECTED]'s). Hm, that sounds weird. I'd say once [EMAIL PROTECTED] is resolved (taking into account the parent xml:base URI), then that's final. Any xml:base's after base's presence will override the base, but I don't see a reason for applying xml:base twice. Since base is a special case element that magically affects all URI's in the document, I'd say it works like that even when combined with 'xml:base'. If it is not, then base is in violation of the xml:base spec AFAICT. It's even worse if 'xml:base' doesn't apply to base at all, but I'd say apply the parent base URI, then apply that URI to all elements in the document (until another 'xml:base' is encountered). I'd personally only allow absolute URI references in [EMAIL PROTECTED] +1. We still have to cope with legacy content which uses a relative URI, but then they're likely not XHTML, so xml:base is simply ignored. I'd actually vote for the exclusion of base from XHTML entirely. We have xml:base, so use that instead. This could be solved by saying that if there is an xml:base in scope, then base is ignored for the whole document. That's also a solution, yea. A quick test with Firefox shows that xml:base is applied but base seems to be ignored in application/xhtml+xml documents. Sounds like good behaviour. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: [whatwg] base versus xml:base
On Wed, 14 Mar 2007 11:40:04 +0100, Thomas Broyer [EMAIL PROTECTED] wrote: How about this variation: head xml:base=bar/ base href=foo/ / /head Is the [EMAIL PROTECTED] resolved to absolute using [EMAIL PROTECTED]:base or not? I'd say it is. At least according to XML Base. The HTML specification can of course state otherwise, but the smartest thing to do would be to not break 'xml:base' processing rules in HTML, even if base is a special case element. If it is, then when looking at links inside head, relative URIs are resolved using a base of bar/foo/bar/ (taking [EMAIL PROTECTED]:base into account twice: once to resolve [EMAIL PROTECTED], which sets the document's base URI, and then relative to that base URI to resolve [EMAIL PROTECTED]'s). Hm, that sounds weird. I'd say once [EMAIL PROTECTED] is resolved (taking into account the parent xml:base URI), then that's final. Any xml:base's after base's presence will override the base, but I don't see a reason for applying xml:base twice. Since base is a special case element that magically affects all URI's in the document, I'd say it works like that even when combined with 'xml:base'. If it is not, then base is in violation of the xml:base spec AFAICT. It's even worse if 'xml:base' doesn't apply to base at all, but I'd say apply the parent base URI, then apply that URI to all elements in the document (until another 'xml:base' is encountered). I'd personally only allow absolute URI references in [EMAIL PROTECTED] +1. We still have to cope with legacy content which uses a relative URI, but then they're likely not XHTML, so xml:base is simply ignored. I'd actually vote for the exclusion of base from XHTML entirely. We have xml:base, so use that instead. This could be solved by saying that if there is an xml:base in scope, then base is ignored for the whole document. That's also a solution, yea. A quick test with Firefox shows that xml:base is applied but base seems to be ignored in application/xhtml+xml documents. Sounds like good behaviour. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: [whatwg] base versus xml:base
* Asbjørn Ulsberg wrote: Let's say the document from my example was located on 'http://users.example.org/bob/'. According to the XML Base specification, the initial base URI of the document (in this example) is «the URI used to retrieve the entity». Since 'xml:base' affects base, and not the other way around (I would presume), the base URI of the document, after processing the base element, should be: http://users.example.org/bar That is, if 'xml:base' is processed before the base element. And according to the XML Base specification, I'd say that is the case. If not, base is a special case element where 'xml:base' doesn't apply or is applied after the 'href' value has been resolved. It is not very useful to make these assumptions. The problem here is that you have a cycle in the lookup algorithm. If you have a relative reference you do this under both xml:base and base processing: rel ref - base of element - base of parent - ... base or else ... document base If the relative reference is in the base href attribute, the algo- rithm would not terminate. The XML Base specification does not address this problem in any way. The minimal approach to break the cycle would be to define what happens if resolving base href depends on resolving base href. A simple solution would be to ignore the base element for the purposes of determining the base of any element. Note that some of the suggestions made in this thread would give quite surprising results e.g. when using XInclude. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
[whatwg] Scripting and WF2 repetition model?
I am trying to put together a demo for Web Forms 2.0 where each row
has a product name, quantity and unit price, and there is a summary
field at the end of the form showing the total price.
I have been able to get the repetition to work fine, once I realized
that the thead and tbody elements are needed, without them the
column headers mysteriously appear at the bottom of the table, but
perhaps that's just a bug in Opera 9.
What I haven't yet worked out is how to address the fields in each
row from the onforminput event handler set on the form element.
In the following, I get an alert that the form object is missing the
row, and then an error. Any ideas on how to address the fields in
a script that iterates across the rows and fields?
script type=text/javascript
function update()
{
var form = document.forms[0];
if (!form) alert(missing form);
if (!form.row) alert(form is missing row);
alert(rows = + form.row[0].item.value);
}
/script
form name=form1 onsubmit=false onforminput=update()
fieldset name=lineItem
legendRepeating groups of fields/legend
table
tr
tdProduct Name/td
tdQuantity/td
tdPrice Per Unit/td
/tr
tr id=lineitem repeat=template repeat-start=4
tdinput name=row[lineitem].item type=text title=product
name/td
tdinput name=row[lineitem]quantity type=number title=number
purchased/td
tdinput name=row[lineitem]unitprice type=number title=price
per unit/td
/tr
/table
/fieldset
plabel for=totalTotal price/label
input name=total readonly=readonly
button type=submitSubmit/button
button type=resetReset/button/p
/form
Dave Raggett [EMAIL PROTECTED] http://www.w3.org/People/Raggett
Re: [whatwg] IRIs vs. URIs
On Wednesday 2007-03-14 15:20 +0100, Peter Karlsson wrote: L. David Baron on 2007-03-13: I tend to think it would be good that new uses of URIs/IRIs document that they are really IRIs and therefore this reverse-encoding behavior should not be used, but instead encoding should be done as UTF-8. You cannot have UTF-8 encoding just for the URIs/IRIs, and another encoding for the rest of the source text. To properly parse a URI/IRI in the source document, you must first convert the bytes in the resource into a stream of Unicode characters. No, it's the *encoding* (conversion from characters to bytes) that should be done as UTF-8, not the *decoding* (conversion from bytes to characters). The URIs within the document are decoded along with the rest of the document. But to send them back to the server they need to be encoded (converted from characters back to bytes) and then percent-escaped. If we say they're IRIs then the encoding step is always encoding to UTF-8. But the traditional behavior for URIs has been to encode based on the encoding of the document, which requires tracking, for every URI, what the encoding of the document, style sheet, or script that contained it was. (I don't think Mozilla does this for scripts, but we do for style sheets and documents.) -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgp1U2Bf9RrDe.pgp Description: PGP signature
Re: [whatwg] Scripting and WF2 repetition model?
On Wed, 14 Mar 2007, Dave Raggett wrote:
What I haven't yet worked out is how to address the fields in each row
from the onforminput event handler set on the form element.
[...]
alert(rows = + form.row[0].item.value);
That should be form[row0.item].value.
The [foo] bit in the name= attributes get expanded, so that the names
are row0.item, row1.item, etc; the actual repetition blocks don't have
the square brackets. Look at the post-repetition DOM to see what I mean.
(The square-bracket dereference notation is required because there's a .
in the name of the field.)
Anyway, you just want:
pTotal price: output onforminput=value = total()0/output?p
...with:
script
function total() {
var rows = document.getElementsByTagName('tbody')[0].rows;
var result = 0;
for (var i = 0; i rows.length; ++i) {
var prefix = 'row' + rows[i].repetitionIndex;
result += rows[i].getElementsByName(prefix + 'quantity')[0].value *
rows[i].getElementsByName(prefix + 'unitprice')[0].value;
}
return result;
}
/script
By the way, the [EMAIL PROTECTED] mailing list is probably more appropriate
for this thread. (That's our authoring help mailing list.)
HTH,
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] IRIs vs. URIs
* L. David Baron wrote: If we say they're IRIs then the encoding step is always encoding to UTF-8. But the traditional behavior for URIs has been to encode based on the encoding of the document, which requires tracking, for every URI, what the encoding of the document, style sheet, or script that contained it was. (I don't think Mozilla does this for scripts, but we do for style sheets and documents.) The traditional behavior of Internet Explorer on Western versions of Windows for western web sites using western encodings has been, since the release of IE5b2 I think, to encode the path using UTF-8 and the query string using the document encoding, depending on the send-urls- as-utf-8 setting. For example, a href='Björn.html'.../a in an ISO-8859-1 encoded document would result in a request for ... Bj%C3%B6rn.html ... Opera, at least for a considerable amount of time, used UTF-8 for the whole reference, I think independently of encodings, domains, and other environment variables. Mozilla was incompatible with that for a long time, always using the document encoding even for the path. I understand this is no longer the case for trunk builds. So the above is a major oversimplification of the issue. (I included the many Western qualifications because the default settings for send-urls-as-utf-8 is regionally different and because I encountered some strange edge cases that result in odd behavior, like sending raw non-ascii octets in the request; details are in Mozilla Bugzilla comment from me, and various list archives). -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)
liorean wrote: Well, the original question wasn't about versioning in particular as much as it was Microsoft asking developers (not spec writers) for something, anything, that they can use to tell whether the author has written the document for HTML5 On 14/03/07, Elliotte Harold [EMAIL PROTECTED] wrote: I could well have missed this, but has Microsoft actually asked for this? I didn't hear them ask for it, but I haven't read every message in the thread. Well, first note something Cris Wilson said on his blog. http://blogs.msdn.com/cwilso/archive/2007/01/10/you-me-and-the-w3c-aka-reinventing-html.aspx On error correction standardization – I disagree with this goal of the WHAT WG because I don't believe it is responsible for Microsoft to cause any unnecessary compatibility problems (e.g. the problems that would be caused if we changed error-handling behavior). If the WHAT-WG wants to standardize on EXACTLY what IE6 does for any given error case, no matter how funky it may be, great, but I don't think that's what they would consider doing. While not asking for it, that is a strong indication they cannot change the default handling, that this new handling has to be opt-in. Second, yeah, they've asked for it. See Chris Wilson's opening statement here: http://video.yahoo.com/video/play?vid=287660 I'd hate to add something for this purpose if Microsoft hasn't made a firm commitment to actually use it. Well, it's not a commitment, just asking for developers giving them the option. I do think it'd be most sensible to give them a hint that if they are to do it some way, [x] is the preferred way, even if the spec doesn't explicitly spell it out. But then we need to come to an agreement about what [x] should be. On 14 Mar 2007, at 15:16, liorean wrote: This is a switch out of backwards-compatibility-hell for a single specific browser they are asking for, not something any other browser vendor should have to worry about. On 14/03/07, Geoffrey Sneddon [EMAIL PROTECTED] wrote: Other browsers introduced quirks mode to match buggy behaviour of others – what's to say that won't happen here, so that other browsers have an IE/Win DOM mode, which would therefore require a switch? It won't happen because the situation is actually better on this point - DOM code either uses only interoperable things, or it already forks for iew on one side and standards DOM on the other. The competing browsers have already proven that they don't need that iew compatibility on the DOM side. The only browser that needs this new switch is iew, because it's the only browser that has to support both this proprietary DOM and the standards DOM. liorean wrote: I don't think Microsoft are asking for a versioning scheme, they don't intend to make a new locked down mode that needs replacing in the future. On 14/03/07, Robert Brodrecht [EMAIL PROTECTED] wrote: I don't think they are either. I was initially hoping to solve two problems at once (lack of versioning and the IE switch). After thinking on it, I came to the same conclusion as you: a IE-only switch shouldn't be part of any spec. A quick way to offer the deliverable is with an http header. It can be easily added to existing sites with .htaccess files, as well. Well, I have several issues with that: - First of all, that developers have low awareness of the HTTP side of the web. Most web developers are happily ignorant about HTTP headers, and even if they know about them, it's mostly limited to some specific problem, such as cache control headers. - Second, that we already have MIME type switching (tagsoup/XML modes), Content-Type: ...;charset=xyz switching (and corresponding meta element), various cache behaviour switching, and DOCTYPE switching. Please don't add yet another type of switch, just reuse the most practical one of those already present. - Third, it has to work when there's no HTTP headers, e.g. from network shares or the file system. liorean wrote: This is a switch out of backwards-compatibility-hell for a single specific browser they are asking for, not something any other browser vendor should have to worry about. And I don't see any reason why !DOCTYPE html shouldn't be the switch seeing as developers are already used to DOCTYPEs as mode switches. On 14/03/07, Robert Brodrecht [EMAIL PROTECTED] wrote: It won't work as a switch if you want Super-Standards Mode in HTML 4 and XHTML documents. I know I want that option. Something I'm very grateful for here, is that XHTML documents don't have this problem. There is no quirks mode in XML in any XHTML aware browser. And iew is not an XHTML aware browser. The super-standards mode will be the only mode available in XHTML douments. As for HTML 4.01 or XHTML1.0 as text/html, that's an area I disagree. The text/html media type is tagsoup for all browsers. A certain set of doctypes act as standards mode switches, but only as token strings, not by actually meaning the document conforms to
Re: [whatwg] IRIs vs. URIs
On Wednesday 2007-03-14 20:16 +0100, Bjoern Hoehrmann wrote: Opera, at least for a considerable amount of time, used UTF-8 for the whole reference, I think independently of encodings, domains, and other environment variables. Mozilla was incompatible with that for a long time, always using the document encoding even for the path. I understand this is no longer the case for trunk builds. So the above is a major oversimplification of the issue. (I included the many Western qualifications because the default settings for send-urls-as-utf-8 is regionally different and because I encountered some strange edge cases that result in odd behavior, like sending raw non-ascii octets in the request; details are in Mozilla Bugzilla comment from me, and various list archives). I believe Mozilla's behavior is the way it is in order to be compatible enough with IE's behavior to be usable when browsing East Asian Web sites. We avoid changing our interpretation of Web standards based on localization; that's just too much complexity to test and maintain. -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpoLsCBR9wwi.pgp Description: PGP signature
Re: [whatwg] Embedding Elements Should be Structured Inline-Level
Colin Lieberman wrote: For the given use case: header h1img src=/images/logo alt=Company Name/h1 object data=flash/object /header I think figure is in appropriate. The spec says: 'The |figure| element represents a paragraph consisting of embedded content and a caption.' and from a semantic point of view, figure seems to connote an illustration or explanatory image. I thought of using figure, but it currently requires legend to provide a caption, but in this case there is no caption. Even if figure were allowed to be used without legend, what would be the point? That would be no better than just adding an extraneous wrapper div around the object just to work around the content model restrictions. I have no problems with images remaining inline only. I think all embedding elements, including img, should be allowed to be used in the same places. I consider it a mistake that HTML4 allows object to be used almost anywhere, but img only inline. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] base versus xml:base
Asbjørn Ulsberg wrote: If it is, then when looking at links inside head, relative URIs are resolved using a base of bar/foo/bar/ (taking [EMAIL PROTECTED]:base into account twice: once to resolve [EMAIL PROTECTED], which sets the document's base URI, and then relative to that base URI to resolve [EMAIL PROTECTED]'s). Hm, that sounds weird. I'd say once [EMAIL PROTECTED] is resolved (taking into account the parent xml:base URI), then that's final. Any xml:base's after base's presence will override the base, but I don't see a reason for applying xml:base twice. Since base is a special case element that magically affects all URI's in the document, I'd say it works like that even when combined with 'xml:base'. This kinda-cyclic definition is caused by the fact that the base element is defined as actually setting a property of the document as a whole. So let's imagine that there's in illusionary element enclosing the whole document, so that we can write this in terms of xml:base... So if we imagine that we've retrieved a document from http://example.com/: (document) xml:base=http://example.com/; html head xml:base=foo/ link href=bar.html / /head ... /html /(document) So here, that link ends up being http://example.com/foo/bar.html, because the xml:base on head is relative to the xml:base on the document. Now if we throw in an HTML base element: (document) xml:base=??? html head xml:base=foo/ base href=wibble/ / link href=bar.html / /head ... /html /(document) What is the document's xml:base set to now? the base element overrides the original document URL, making it http://example.com/foo/wibble/, but since the xml:base on the document is now http://example.com/foo/wibble/, the base href is now http://example.com/foo/wibble/foo/wibble/ and so on ad infinitum. So it seems to me that base href has to be a special case of some sort. I'm not sure what the special case should be. I think in this case I'd expect the notional xml:base on the document to be http://www.example.com/wibble/ and the URL in my link element to end up as http://www.example.com/wibble/foo/bar.html ... in other words, the base href has ignored xml:base entirely... the base href attribute is in effect acting as if it were the xml:base attribute on my imaginary (document) element, regardless of its actual position in the DOM.
Re: [whatwg] Figure without caption
Great example. (http://www.radio-canada.ca/arts-spectacles/PlusArts/2007/03/13/003-viacom_youtube.asp) My reading is that one would use figure as the block-level parent of the second image, where the first image could happily be inline. Michel Fortin wrote: Le 2007-03-14 à 16:24, Lachlan Hunt a écrit : Even if figure were allowed to be used without legend, what would be the point? That would be no better than just adding an extraneous wrapper div around the object just to work around the content model restrictions. If figure denotes illustrative content, your image then becomes an illustration of the subject in the surrounding text. Otherwise, you have no way to distinguish images which are meant to be read as part of the text -- mathematic formulas embedded as images for instance -- and those which are more detached from the prose -- a photo illustrating the text's subject. - - - I'd like to submit this example of a news article having two pictures; both are styled the same, they both have the same purpose (illustration), yet one has no caption while the other has one. http://www.radio-canada.ca/arts-spectacles/PlusArts/2007/03/13/003-viacom_youtube.asp If we say the second picture is a figure, how can we reasonably say the first one is not? A table does not need a caption to be a table, and I don't think a figure needs a caption to be a figure: it just needs to be an illustration of the surrounding subject. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)
liorean wrote: Well, I have several issues with that: - First of all, that developers have low awareness of the HTTP side of the web. Most web developers are happily ignorant about HTTP headers, and even if they know about them, it's mostly limited to some specific problem, such as cache control headers. To deliver real XHTML, developers are supposed to know about content-type headers. I don't think it's asking too much of the upper-eschalon of web developers to add a header for IE. Of the ~50% of people (according to Chris Wilson) that have DOCTYPE, I'm sure there is a good portion that have it because the WYSIWYG editor put it there. Since those ship with the ability to create compatible designs, it's not an issue for them. For those that work in quirksmode or just copy/pasted in a doctype from a tutorial, it is certainly not an issue. Having the extra standards support is an issue for those of us who hand-code our sites. If someone is purposefully triggering standards mode, I would hope they had a clue about HTTP headers. - Second, that we already have MIME type switching (tagsoup/XML modes), Content-Type: ...;charset=xyz switching (and corresponding meta element), various cache behaviour switching, and DOCTYPE switching. Please don't add yet another type of switch, just reuse the most practical one of those already present. The problem is that there isn't a practical one to reuse. I would hope the IE Team would have been smart enough to think of looking for a complete DOCTYPE first. They asked for another opt-in (presumably other than the doctype opt-in). - Third, it has to work when there's no HTTP headers, e.g. from network shares or the file system. Real XHTML turns to tag soup when there is no header. This can have quite a few unexpected consequences when a real XHTML document is downloaded and viewed not-over-the-network. At least with an IE-only header, it would only affect viewing the page locally in IE (unless the meta http-equiv tag was present, then it should display properly). Something I'm very grateful for here, is that XHTML documents don't have this problem. There is no quirks mode in XML in any XHTML aware browser. And iew is not an XHTML aware browser. The super-standards mode will be the only mode available in XHTML douments. The fact that IE doesn't support real XHTML is why real XHTML* never gained critical mass. I don't think we'd be working on HTML 5 if IE would have had support for real XHTML, even if it was buggy / semi-quirky support. As for HTML 4.01 or XHTML1.0 as text/html, that's an area I disagree. The text/html media type is tagsoup for all browsers. A certain set of doctypes act as standards mode switches, but only as token strings, not by actually meaning the document conforms to any particular HTML specification. With HTML and fake XHTML, it is the job of the developer to make sure that code conforms to a particular specification. There are quite a few people out there who care about delivering well-formed, quality code, even if their page will still render when there are syntax errors. There are quite a few of us who aren't lazy (even if we make mistakes now and again). There is no meaning in those strings to any of the browsers, except for their triggering different rendering modes. HTML2.0, HTML4.01 of XHTML1.0 are all the same HTML if you ask the browser. This mode is just another one added to the set of modes provided by one particular browser. There is (and ought to be) meaning to the authors. The spec we are working on now will have a text/html serialization. When I start writing for HTML 5, I will do my best to conform to the spec by writing valid code, and will write well-formed code because I take pride in the work I do. I do the same thing with HTML 4.0 (and would do the same with fake XHTML if I didn't believe it was ideologically broken... instead I don't use it at all). Just because it renders with a tag soup parser doesn't mean I shouldn't be able to reap the benefits of better standards-based rendering in IE. So, it'd be super great if whatever switch the IE Team decides to use is backwards compatible. * When I say real XHTML, I mean XHTML served with application/xhtml+xml Content-type headers. -- Robert http://robertdot.org
[whatwg] input elements and css styles
Hi,
I have tried simple styling of WF2 elements in Opera 9.10 implementation
Only colour and background-color.
And found some heterogenity.
Try {color:red; background-color:green} on input type=datetime-local and
on input type=week, gives you different results - week accepts
background color, datetime-local ignores. So I looked in WF2 spec. for any
mention about forms styling. Didn't found any.
My direction is - webdesigners are used to style forms in any (hi-tech)
color of theirs websites. And would expect the same from WF2 probably. This
(Opera) behaviour should be correct according to the WF2 spec or not? Do not
mentioning I was not able to style calendar window so on page with black
background it was still shining white.
Shouldn't be there some specification or at least recommendation about
possibility of form styling included? Or is this area completely free to
implementors and do not fall in the WF2 specification anyway?
--
Met - Martin Hassman
http://www.met.cz/
Re: [whatwg] input elements and css styles
On Wed, 14 Mar 2007, Martin Hassman wrote:
Try {color:red; background-color:green} on input type=datetime-local
and on input type=week, gives you different results - week accepts
background color, datetime-local ignores. So I looked in WF2 spec. for
any mention about forms styling. Didn't found any.
My direction is - webdesigners are used to style forms in any (hi-tech)
color of theirs websites. And would expect the same from WF2 probably.
This (Opera) behaviour should be correct according to the WF2 spec or
not? Do not mentioning I was not able to style calendar window so on
page with black background it was still shining white.
Shouldn't be there some specification or at least recommendation about
possibility of form styling included? Or is this area completely free to
implementors and do not fall in the WF2 specification anyway?
This is what the (not yet begun) Web Controls 1.0 specification is
intended to cover. However, there is no estimated time for work on this
specification to begin. In the meantime, I recommend contacting your
browser vendor directly.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Figure without caption (was: Embedding Elements Should be Structured Inline-Level)
Michel Fortin wrote: Le 2007-03-14 ? 16:24, Lachlan Hunt a ?crit : Even if figure were allowed to be used without legend, what would be the point? That would be no better than just adding an extraneous wrapper div around the object just to work around the content model restrictions. As a newcomer still working through the specification, it is not clear to me that figure requires a legend. The content model calls for exactly one legend element. But then several paragraphs later the text reads The first legend element child of the element, if any I think this part of the specification needs to more clearly state if one legend element is required, or if zero is acceptable. -- Bill Mason Accessible Internet [EMAIL PROTECTED] http://accessibleinter.net/
Re: [whatwg] video element proposal
* Håkon Wium Lie wrote: I think we want to make video a first class citizen of the web. That means, IMHO, that there must be a simple way to add video to HTML pages. I don't think one shoulr rely on other languages for this, although I'm perfectly happy supporting those other languages as well. Part of the reason why we could to this so quickly is the work we have done on SVG. Absolutely, and http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera Basic Web application features should be implementable using behaviors, scripting, and style sheets in IE6 today so that authors have a clear migration path. In case of video, there is no need to implement anything using style sheets, behaviors, or scripting, you can use it directly, right now, it's easy as pie, html xmlns:t=urn:schemas-microsoft-com:time ?import namespace=t implementation=#default#time2 body t:video src='example.video'/t:video /body and based on an open W3C standard. No need for separate languages at all. It's not perfect, but the terrible design of XMLHttpRequest, canvas, and other features also did not prevent their inclusion in Web Applications 1.0. Don't you think the differences between the video features in IE5+, SMIL, SVG, and HTML should be minimized, and using them in IE be made as easy as technically feasible? -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
[whatwg] Adding mouseenter and mouseleave events
Mouseover/out events will trigger when elements contained inside the EventTarget are hovered, and then bubble up. This is contrary to the most obvious interpretation, as you are still inside (over) the targeted element. IE supports two events, mouseenter[1] and mouseleave[2], which solve this problem by not bubbling. It is possible to work around the problem by using target/relatedTarget and walking up the DOM tree. However, this requires extra code for every event handler. Besides, these events were often not meant to be generated in the first place, by the intent of the author. I have no statistics for how often mouseover/out are used with and without intent of bubbling, but the anecdotal evidence from my own experience has never found me wanting it. I suggest these two events be added to the web applications spec. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmouseenter.asp [2] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmouseleave.asp -- Magnus Kristiansen Don't worry; the Universe IS out to get you.
Re: [whatwg] Figure without caption (was: Embedding Elements Should be Structured Inline-Level)
On Thu, 15 Mar 2007 01:19:40 +0100, Bill Mason [EMAIL PROTECTED] wrote: Michel Fortin wrote: Le 2007-03-14 ? 16:24, Lachlan Hunt a ?crit : Even if figure were allowed to be used without legend, what would be the point? That would be no better than just adding an extraneous wrapper div around the object just to work around the content model restrictions. As a newcomer still working through the specification, it is not clear to me that figure requires a legend. The content model calls for exactly one legend element. But then several paragraphs later the text reads The first legend element child of the element, if any You're confusing document conformance requirements and UA conformance requirements. The content model applies to documents. The later text you referred to applies to UAs. (UAs need to handle non-compliant content.) The Conformance requirements section has the following note: | Note: There is no implied relationship between document conformance | requirements and implementation conformance requirements. User agents are | not free to handle non-conformant documents as they please; the | processing model described in this specification applies to | implementations regardless of the conformity of the input documents. -- Simon Pieters
Re: [whatwg] Adding mouseenter and mouseleave events
Can't you just return false from an event handler to prevent further bubbling? On 15 Mar 2007, at 00:30, Magnus Kristiansen wrote: Mouseover/out events will trigger when elements contained inside the EventTarget are hovered, and then bubble up. This is contrary to the most obvious interpretation, as you are still inside (over) the targeted element. IE supports two events, mouseenter[1] and mouseleave[2], which solve this problem by not bubbling. It is possible to work around the problem by using target/ relatedTarget and walking up the DOM tree. However, this requires extra code for every event handler. Besides, these events were often not meant to be generated in the first place, by the intent of the author. I have no statistics for how often mouseover/out are used with and without intent of bubbling, but the anecdotal evidence from my own experience has never found me wanting it. I suggest these two events be added to the web applications spec. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/ events/onmouseenter.asp [2] http://msdn.microsoft.com/workshop/author/dhtml/reference/ events/onmouseleave.asp -- Magnus Kristiansen Don't worry; the Universe IS out to get you.
[whatwg] Web Forms 2.0 and the W3C Patent Policy
The following individuals may or may not have agreed to the W3C Patent Policy regarding the Web Forms 2.0 specification: Andreas dolphinling fantasai Grey Josh Aas Christopher Aillon Jonny Axelsson Stuart Ballard David Baron Ian Bicking Christian Biesinger Mark Birbeck Susan Borgrink Bert Bos Anthony Boyd Daniel Bratell Daniel Brooks Tantek Çelik David E. Cleary Allan Clements Andrew Clover Craig Cockburn Michael Daskalov Rich Doughty Micah Dubinko Dean Edwards Brendan Eich Michael Enright Jon Ferraiolo Michel Fortin Brad Fults Csaba Gabor Joe Gregorio Andy Heydon Dave Hodder Sean Hogen Björn Höhrmann Martin Honnen Gytis Jakutonis John Keiser Jason Kersey Olav Junker Kjær Peter-Paul Koch Jukka K. Korpela Brian Korver Martin Kutschker Edmund Lai Will Levine Jim Ley Jens Lindström Jason Lustig Matthew Mastracci David Matja Bill McCoy Ted Mielczarek Eira Monstad Simon Montagu Chris Morris Michael A. Nachbaur Jorunn Danielsen Newth Paul Norman Mark Nottingham Wladimir Palant Subramanian Peruvemba Olli Pettay Alan Plum Mikko Rantalainen Shanti Rao Neil Rashbrook Eric Rescorla Max Romantschuk Doron Rosenberg Malcolm Rowe Brian Ryner Mark Schenk Christian Schmidt Sebastian Schnitzenbaumer Mike Shaver Jonas Sicking Justin Sinclair Henri Sivonen Andrew Smith Rene Stach Maciej Stachowiak Peter Stark Hallvord Reiar Michaelsen Steen Johnny Stenback Matthew Thomas Sander van Lambalgen Menno van Slooten Sigbjørn Vik Alexander J. Vincent Mattias Waldau Martijn Wargers Edward Welbourne Rigo Wenning C. Williams Brian Wilson Mark Wilton-Jones Matt Wright Ave Wrigley If your name is on the list above, please agree to the license so we can circumvent the patent policy issue in the HTML WG. Let me know if you've already agreed to the policy so I can take you off the list. Ian, are you able to contact any of these individuals?
Re: [whatwg] Web Forms 2.0 and the W3C Patent Policy
On Mar 14, 2007, at 6:59 PM, Matthew Raymond wrote: If your name is on the list above, please agree to the license so we can circumvent the patent policy issue in the HTML WG. Let me know if you've already agreed to the policy so I can take you off the list. I can't find an easy way to simply agree to the patent policy. However, I know I had to do it in the process of becoming an invited expert to the HTML WG. I assume that each person can complete that process via Ian's instructions: http://blog.whatwg.org/w3c-restarts- html-effort If anyone knows a way to do this with less overhead for the W3C folks (e.g. Dan Connolly and Karl Dubost), it would probably also be easier for the specified individuals to get through the process. Links to forms or e-mail addresses of people to contact would be nice if you have them. -- Robert http://robertdot.org
Re: [whatwg] Embedding Elements Should be Structured Inline-Level
- Original Message - From: Lachlan Hunt [EMAIL PROTECTED] To: Colin Lieberman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Michel Fortin [EMAIL PROTECTED] Sent: Wednesday, March 14, 2007 12:24 PM Subject: Re: [whatwg] Embedding Elements Should be Structured Inline-Level I have no problems with images remaining inline only. I think all embedding elements, including img, should be allowed to be used in the same places. I consider it a mistake that HTML4 allows object to be used almost anywhere, but img only inline. Strictly speaking HTML4 does not dictate inline nature of the image. The only place I've found is this: The IMG element has no content; it is *usually* replaced inline by the image designated by the src attribute. [1] This phrase use word usually that imply exceptions other than float cases. This is how I read this but I am not sure about it. BTW. Does it make sense for me to create a map of all HTML5 elements that will define them in terms of display-model and display-role [2]? Andrew Fedoniouk. http://terrainformatica.com [1] http://www.w3.org/TR/html401/struct/objects.html#edef-IMG [2] http://www.w3.org/TR/css3-box/#L706
Re: [whatwg] Embedding Elements Should be Structured Inline-Level
Andrew Fedoniouk wrote: Strictly speaking HTML4 does not dictate inline nature of the image. The only place I've found is this: The IMG element has no content; it is *usually* replaced inline by the image designated by the src attribute. [1] This phrase use word usually that imply exceptions other than float cases. This is how I read this but I am not sure about it. No, I believe the full quote makes it clear that float cases *are* the exception to inline presentation: The IMG element has no content; it is usually replaced inline by the image designated by the src attribute, the exception being for left or right-aligned images that are floated out of line. IMG elements do not meet the distinctions for block-level as described in http://www.w3.org/TR/html401/struct/global.html#didx-inline -- Bill Mason Accessible Internet [EMAIL PROTECTED] http://accessibleinter.net/
Re: [whatwg] Web Forms 2.0 and the W3C Patent Policy
On Wednesday 2007-03-14 21:59 -0400, Matthew Raymond wrote: The following individuals may or may not have agreed to the W3C Patent Policy regarding the Web Forms 2.0 specification: [...] If your name is on the list above, please agree to the license so we can circumvent the patent policy issue in the HTML WG. Let me know if you've already agreed to the policy so I can take you off the list. Sorry, what patent policy issue? I've seen a lot of comments about patent policy flying around, but I haven't seen any concrete statement of an issue that exists. (And the W3C patent policy is not a license.) -David -- L. David BaronURL: http://dbaron.org/ Technical Lead, Layout CSS, Mozilla Corporation pgpIdPblKaQPz.pgp Description: PGP signature
Re: [whatwg] Web Forms 2.0 and the W3C Patent Policy
On Wed, 14 Mar 2007 21:28:12 -0700, L. David Baron [EMAIL PROTECTED] wrote: On Wednesday 2007-03-14 21:59 -0400, Matthew Raymond wrote: The following individuals may or may not have agreed to the W3C Patent Policy regarding the Web Forms 2.0 specification: [...] If your name is on the list above, please agree to the license so we can circumvent the patent policy issue in the HTML WG. Let me know if you've already agreed to the policy so I can take you off the list. Sorry, what patent policy issue? I've seen a lot of comments about patent policy flying around, but I haven't seen any concrete statement of an issue that exists. I guess there is an issue that it is difficult for W3C to simply accept a specification without having any clear idea of the patent licensing agreement made by those who developed it (as a minimal exercise in protection from some unpleasant uses of patents). As David says, it isn't a license. But it has been helpful to have the policy active in the past. Anyway, Opera in W3C abides by the W3C patent policy, and has already made the relevant commitment to the WAF group, which has already been working on WF2. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
Re: [whatwg] Embedding Elements Should be Structured Inline-Level
- Original Message - From: Bill Mason [EMAIL PROTECTED] To: Andrew Fedoniouk [EMAIL PROTECTED] Cc: Lachlan Hunt [EMAIL PROTECTED]; Colin Lieberman [EMAIL PROTECTED]; [EMAIL PROTECTED]; Michel Fortin [EMAIL PROTECTED] Sent: Wednesday, March 14, 2007 8:15 PM Subject: Re: [whatwg] Embedding Elements Should be Structured Inline-Level Andrew Fedoniouk wrote: Strictly speaking HTML4 does not dictate inline nature of the image. The only place I've found is this: The IMG element has no content; it is *usually* replaced inline by the image designated by the src attribute. [1] This phrase use word usually that imply exceptions other than float cases. This is how I read this but I am not sure about it. No, I believe the full quote makes it clear that float cases *are* the exception to inline presentation: The IMG element has no content; it is usually replaced inline by the image designated by the src attribute, the exception being for left or right-aligned images that are floated out of line. IMG elements do not meet the distinctions for block-level as described in http://www.w3.org/TR/html401/struct/global.html#didx-inline Thanks, Bill, for the clarification. I think that word 'usually' is redundant there then. At least it is not a common wording: usually A but sometimes B makes sense but usually A except of B from view of formal logic or fuzzy set math do not cover the full set (with 1.0 possibility). This is why I found it a bit confusing. Andrew Fedoniouk. http://terrainformatica.com -- Bill Mason Accessible Internet [EMAIL PROTECTED] http://accessibleinter.net/
Re: [whatwg] Web Forms 2.0 and the W3C Patent Policy
On Wed, 2007-03-14 at 22:12 -0700, Charles McCathieNevile wrote: [...] Anyway, Opera in W3C abides by the W3C patent policy, and has already made the relevant commitment to the WAF group, which has already been working on WF2. FYI, W3C keeps public record of patent policy status for each WG, such as the one for WAF that shows what Opera and others have agreed to. Web Application Formats Working Group Patent Policy Status http://www.w3.org/2004/01/pp-impl/38483/status -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
