Copyright © 2001-2010 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This note contains remaining, unresolved issues about XHTML 2. The XHTML2 Working Group wanted to capture these in a document before terminating its development of XHTML 2.
During the development of XHTML 2, many public drafts of the document have been made available, and many public comments received. This document summarizes the information about 32 open issues in the issue tracking system at http://htmlwg.mn.aptest.com/xhtml2-issues.
Note that the majority of this document is automatically generated from the Working Group's database of comments. As such, it may contain typographical or stylistic errors. If so, these are contained in the original submissions, and the XHTML 2 Working Group elected to not change these submissions.
This document is a Note of the W3C's XHTML 2 Working Group. This Note may be updated, replaced or rendered obsolete by other W3C documents at any time. It is inappropriate to use W3C Notes as reference material or to cite them as other than "work in progress". This document is work in progress and does not imply endorsement by the W3C membership.
This document has been produced by the W3C XHTML 2 Working Group as part of the HTML Activity. The goals of the XHTML 2 Working Group are discussed in the XHTML 2 Working Group charter.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Please send detailed comments on this document to www-html-editor@w3.org. We cannot guarantee a personal response, but we will try when it is appropriate. Public discussion on HTML features takes place on the mailing list www-html@w3.org.
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.
Issue | Working Group Action | Commentor Position | Change Type | Notes |
---|---|---|---|---|
7844: Fwd: XHTML 2 Draft Recommendation: the @key attribute | None | None | N/A | |
7661: [XHTML2] Constraining attribute relationship | Defer | None | N/A | We think this is a good thing for M12N 2.0, but is not necessary for XHTML 2 right now. |
7783: [XHTML 2] 15 Bi-directional text collection and embedded attributes? | Modify and Accept | None | N/A | The dir attribute does not apply to embedded content. The src attribute is not equivalent to an xml "include" - it is a reference to a (potentially) external resource that is rendered in the way appropriate to that resources type. But that rendering is done in the context of a separate renderer; ala the object element. Similary, the styling from stylesheets that apply to the parent document does not apply to any embedded content. The fact that your example is "text" does not really matter - text is no more special than any other embedded content. It is handled by however the user agent processes text content, but in a different context than the parent element. We will add text to the src attribute description to clarify this. |
7799: Fw: [XHTML 2] Section 5.5 quality values. | None | None | N/A | Discussed this a bit. What we mean is that it is an intersection of media types, and that quality values in the document should take precedence. Will continue to work on this and craft wording. Upon further review, Steven Pemberton has agreed to think about the right solution. |
7800: Fw: [XHTML 2] Section 5.5 intersection of mime-types | None | None | N/A | This is related to issue 7799 - the answer may be that asterisks are not relevant. We will clarify this once Steven's action item is complete. |
7336: Identifying XHTML version in ansence of DTDs | Defer | None | N/A | BAE F2F: for the present DTD's are required for entity resolution. This is a tricky issue, and the working group needs to resolve it quickly. We are asking for input from the Hypertext Coordination Group and others in our quest to sort it out. |
670: Entity management: do we still need it? | Accept | Agree | N/A | We will support both XML Catalogs and SGML Open Catalogs for XHTML 2. |
671: Character entities: do we still need them? | Accept | None | N/A | The WG believes that there's still a need for character entities. We need to find a solution. On 9 September 2003, the WG agrees to retain character entities; DTDs therefore still necessary; it might be possible to supply a DTD that only provides the entities. |
7724: Re: Formal Response to My issue on styling embedding attributes. | None | None | N/A | Original message at: http://lists.w3.org/Archives/Public/www-html-editor/2005AprJun/0064 This is a reply to issue 7655, where SP also replied |
7670: XHTML2 issue request: no defined mapping from imagemaps to SVG | Defer | None | N/A | We concerned about how to marry the coordinate systems between SVG and HTML. We need a concrete proposal from the SVG group, because we can't figure out how to implement it. Working group feels that the imagemap stuff should remain the same as it has been historically. SVG has its own stuff, and if an author wants to use that, they can by creating hybrid documents that use XHTML 2 + SVG markup. However, creating fallback imagemaps (using SVG if supported, native XHTML 2 if not) would be challenging. Authoring tool developers may find this even more challenging. Submitter indicated that he would accept adding a note to the spec indicating that there is another way to do imagemaps using SVG, with a pointer to SVG. W3C is working on Profiles of XHTML that include SVG-Tiny / SVG. In the future we feel that imagemaps will be better handled by such an environment. Include a reference to SVG / SVG-Tiny. |
7887: [XHTML2] (Image) titles | None | None | N/A | XHTML 2 incorporates XForms, which has some elements to assist with this general problem. The working group will investigate this further and see if the solution can be applied here. |
7759: [XHTML2] Spirit of "1.1.3. XHTML 2 and Presentation" | None | None | N/A | Suspended until last call |
7663: [XHTML2] 11.3. The ol , and ul elements | None | None | N/A | The working group is not in favor or the definition of a "continueFrom" attribute that would allow continuation of list numbering, simply because there is no way to describe the behavior in current styling languages. However, there is a usecase for being able to define groups of list items and label them.... The working group is continuing to discuss this issue. To be *really* fair to the required structure in his use case ... you really want something like this: <ol> <group> <li>.. <li>... <li>... </group> <group> <label>... <li>... <li>... </group> </ol> The use case has two different structures imposed on top of each other A bit like <label for=""> in HTML4 |
7869: rebuild link element: chapter, section / subsection | None | None | N/A | |
7873: XHTML 2: metaAttributes examples | None | None | N/A | Looking into the dc:created item. Fixed the dc:date item. |
7868: New rel value: enclosure | None | None | N/A | |
7864: remove copyright value from rel attribute | None | None | N/A | |
8001: [XHTML-role] How to define roles still needs clarification | Accept | None | None | There are two issues in here. As to machine discovery of vocabulary, the working group has resolved to tighten up the conformance requirement about discovery. This will be in the next working draft. As to priority of role values, the working group agrees that this is important, but is not part of the Role spec necessarily. The Role spec does not have normative behavioral requirements in it, and therefore does not have any requriement as to how a user agent might interpret the value(s) of the role attribute. This is a vocabulary issue, and the working group expects this will be resolved as part of future vocabulary work either by the XHTML 2 Working Group or by related activities such as ARIA. |
7830: [XHTML2] How are UAs to interpret <h> and <hx> elements? | None | None | N/A | |
7874: block@kind vs elt@structure | None | None | N/A | |
7820: [XHTML2] How are UAs to interpret <h> and <hx> elements? | None | None | N/A | |
7878: What is the scope of a header? | Accept | None | N/A | Group agrees that the scope needs a better explanation. |
7870: RE: [BULK] - Re: [XHTML2] Spirit of "1.1.3. XHTML 2 and Presentation" | Accept | None | N/A | The working group resolved at the f2f meeting in June 08 to remove this attribute and to permit the style element throughout the content model. |
7871: Re: [BULK] - Re: [XHTML2] Spirit of "1.1.3. XHTML 2 and Presentation" | Reject | None | N/A | We are removing the style attribute, but we are ensuring that it is possible to embed style definitions via the style element or the link element anywhere in your document. |
7881: nesting colgroup and rowgroups | None | None | N/A | While there are notional "rowgroups" there are no explicit arbitrary rowgroups in HTML nor in XHTML because rows are explicit in tables. colgroups, on the other hand, exist because HTML / XHTML needs a way of referring to columns. Asked the submitter for more information and an example including a description of what the advantages would be. |
7828: Why no nested colgroup or rowgroup? | None | None | N/A | We have reviewed this request, but don't understand how the additional markup supports the use case. What problem are you trying to solve exactly? |
674: Can we use 'application/xhtml+xml' for XHTML 2.0? | Defer | None | N/A | BAE F2F: accepted the idea, but have not crafted a resolution. Decided to use a parameter on the media type. HCG is going to discuss and make a recommendation as to what parameter to use. |
7729: MediaDesc with CSS3 | Defer | None | N/A | Defered because CSS3 is not in the right state. |
7659: [XHTML2] Some comments | None | None | N/A | This issue needs to be broken into individual issues. |
8050: [XML Events 2] Problem with image | None | None | N/A | |
8056: LC Comment: Common event info from event() | Accept | None | Editorial | The group notes that you can access anything that is in the event object. We will add some text to make this clear and tie it to the DOM 3 specification. |
8059: [Fwd: Errata for XML Events: An Events Syntax for XML] | None | None | N/A |
PROBLEM ID: 7844
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
ORIGINAL MESSAGE:
Date: Mon, 21 Nov 2005 17:42:33 +0900 (JST) From: Anne van Kesteren <fora@annevankesteren.nl> From: Anne van Kesteren <fora@annevankesteren.nl> To: www-html-editor@w3.org Subject: Fwd: XHTML 2 Draft Recommendation: the @key attribute Date: Fri, 18 Nov 2005 11:51:58 +0100 Message-ID: <20051118115158.ytjesdzi2xogkogc@webmail.annevankesteren.nl> X-Archived-At: http://www.w3.org/mid/20051118115158.ytjesdzi2xogkogc@webmail.annevankesteren.nl This seems more like a comment to me... ----- Forwarded message from mel.pedley@gawds.org ----- Date: Fri, 18 Nov 2005 04:06:27 +0000 From: Mel Pedley <mel.pedley@gawds.org> Reply-To: mel.pedley@gawds.org Subject: XHTML 2 Draft Recommendation: the @key attribute To: www-html@w3.org I would like to add my support to the arguments John Foliot has raised on: http://www.wats.ca/articles/xhtmlroleaccessmodulestillflawed /80 In the notes accompanying http://hades.mn.aptest.com/cgi-bin/xhtml2- issues/Role?id=7809 it has been suggested that: "Author-defined key bindings are a requirement of many members of our user community." I can only conclude that the author's 'user community' differs greatly from the user community that I have worked with. I have personally *never* encountered a single user who was in favour of such author-defined key bindings - let alone felt that they were a user requirement. Most feel that these bindings are forced upon users (whether they want them or not) in a manner that often completely disregards the serious conflicts they can cause. I should like to take this opportunity to point out that, for some years, I actually favoured such an approach under the mistaken assumption that key bindings (accesskeys) offered significant navigational assistance for some users. However, after listening to the arguments against accesskeys, I finally got around to *asking* the users for their opinions. "I don't use them..." "They vary from site to site, and I'd have to a) learn whether a site has them, b) what they are on that site." "...they would need to offer *additional* functions to standard keyboard shortcuts or be an additional way to access keyboard functions, not be a replacement for them." "The site should be designed in such a way as to not break standard keyboard shortcuts." All of the above arguments against author defined accesskeys can be equally applied to the proposed @key attribute. Nice idea, in theory but, in reality, at best, a complete waste of time and, at worst, a positive and significant hinderance to effective web usage. The notes on http://hades.mn.aptest.com/cgi-bin/xhtml2- issues/Role?id=7809 also mention: "The working group agrees that the end users should be able to override key bindings, but authors must be able to define them." Does the working group really believe that the average user has the technical ability to over-ride key bindings? Must users of assistive software now have to increase their learning curve yet further by learning how to dismantle the barriers created by authors? And since when did the words "author" and "must" belong together in a discussion about possibly over-riding the default behaviour of *users'* software? Until web authors understand that they must fit in with users and not vice versa, large sections of the potential user community will remain disenfranchised by a medium that has tremendous potential to empower them. The implementation of @key will simply continue this rather shabby tradition. I would earnestly request that the working group seriously reconsider. Mel Pedley -- Administrator Guild of Accessible Web Designers mel.pedley@gawds.org http://www.gawds.org ----- End forwarded message ----- -- Anne van Kesteren <http://annevankesteren.nl/>
PROBLEM ID: 7661
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: None
NOTES:
We think this is a good thing for M12N 2.0, but is not necessary for XHTML 2 right now.
ORIGINAL MESSAGE:
Date: Mon, 02 Aug 2004 14:46:39 +0900 (JST) From: Masayasu Ishikawa <mimasa@w3.org> While DTD and XML Schema provide no way to describe relationship between attributes, there are several cases in XHTML 2.0 where presense of an attribute depends on other attribute, or only one of two attributes is allowed, and so on. RELAX NG (and Schematron) can express this kind of constraints, so if we want, we could formalize these constraints in prose and implement them in some schema languages. To list a few: - @hreftype and @hreflang would only make sense when @href is used - @target may depend on the presence of @href - maybe @datetime should be used with @edit - @type depends on the presence of @src - @coords needs to be used with @shape - maybe @rel and @rev should not be used together - @restype depends on the presence of @resource - @value and @valuetype on "param" are related (but we should rework on this) If we want to do these, perhaps we should work out how to express these constraints in abstract definition. Regards, -- Masayasu Ishikawa / mimasa@w3.org W3C - World Wide Web Consortium
FOLLOWUP 1:
Date: Mon, 02 Aug 2004 10:31:48 -0500 From: Shane McCarron <shane@aptest.com> This is a cryptographically signed message in MIME format. --------------ms060604070004030200010108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I agree that it is a good idea to express these relationships in the prose AND in the abstract syntax. In the abstract syntax, something simple like: attrName=attrType ( dependentAttrs...), nextAttr... would be enough. mimasa@w3.org wrote: >While DTD and XML Schema provide no way to describe relationship >between attributes, there are several cases in XHTML 2.0 where >presense of an attribute depends on other attribute, or only one of >two attributes is allowed, and so on. RELAX NG (and Schematron) can >express this kind of constraints, so if we want, we could formalize >these constraints in prose and implement them in some schema languages. >To list a few: > >- @hreftype and @hreflang would only make sense when @href is used >- @target may depend on the presence of @href >- maybe @datetime should be used with @edit >- @type depends on the presence of @src >- @coords needs to be used with @shape >- maybe @rel and @rev should not be used together >- @restype depends on the presence of @resource >- @value and @valuetype on "param" are related (but we should rework > on this) > >If we want to do these, perhaps we should work out how to express >these constraints in abstract definition. > >Regards, > > -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com --------------ms060604070004030200010108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFJjCCBI+gAwIBAgIQLarnEdgQVg4IVLWJhZSYYTANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzA5MTAw MDAwMDBaFw0wNDA5MDkyMzU5NTlaMIIBFDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRowGAYDVQQDFBFTaGFuZSBQLiBNY0NhcnJvbjEf MB0GCSqGSIb3DQEJARYQc2hhbmVAYXB0ZXN0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALesDaUrx5jSFWRNS5lq7TlDGSudYKA0oplmmUgkgwbbDA/4HXnBYYwbgDuU 5rMpqZT88My7GiY/4goovNGuyc9nmcyiK7n3oJGqiVSvk1kFJe04kQoXpx7/9S9oYeVFKrFW FUOo5oifnwG4K+6AoTEd8ISNauXfwmlBT/YGuoQWyU+76zltr+rxmVSP/Z54y5cuxrlvcy8F zmwZbXp91aKxJl39kOXODVo099MJHzxoXT9CtH9+BRoEOHeOwoKr1uVbbrWqhpy1vOMwog7B VSfbK+2j7z2EUcGJQ7DAW35kgNzd5lKSMW7EDhoXeq8MRB0lzrg8vysarwaNrSiK7UMCAwEA AaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4w KAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIw VjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJl ZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAw BgpghkgBhvhFAQYHBCIWIDJiMTllZGNlNmE5NDFkYWVmYzI3ZmI0NGUyNzc2NTZlMDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZI hvcNAQEEBQADgYEApEqCokzlv+Ryhjssst2nHAP86vX5ckhTfhXpVONK62DvyVnIGxT259x6 yD893yJixYnX16ScG5U796c1uC/4EXmPG695oAaga+jtwiNw4x/TFRhN7MYPS6vaOnc92T9k +ZbS4LMEBDDhclg/zilWIjdXKcCgNAfcwXyDfnrrRNAwggUmMIIEj6ADAgECAhAtqucR2BBW DghUtYmFlJhhMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYG A1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u YSBOb3QgVmFsaWRhdGVkMB4XDTAzMDkxMDAwMDAwMFoXDTA0MDkwOTIzNTk1OVowggEUMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5 IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMw MQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxGjAY BgNVBAMUEVNoYW5lIFAuIE1jQ2Fycm9uMR8wHQYJKoZIhvcNAQkBFhBzaGFuZUBhcHRlc3Qu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt6wNpSvHmNIVZE1LmWrtOUMZ K51goDSimWaZSCSDBtsMD/gdecFhjBuAO5TmsymplPzwzLsaJj/iCii80a7Jz2eZzKIrufeg kaqJVK+TWQUl7TiRChenHv/1L2hh5UUqsVYVQ6jmiJ+fAbgr7oChMR3whI1q5d/CaUFP9ga6 hBbJT7vrOW2v6vGZVI/9nnjLly7GuW9zLwXObBlten3VorEmXf2Q5c4NWjT30wkfPGhdP0K0 f34FGgQ4d47CgqvW5VtutaqGnLW84zCiDsFVJ9sr7aPvPYRRwYlDsMBbfmSA3N3mUpIxbsQO Ghd6rwxEHSXOuDy/KxqvBo2tKIrtQwIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0g BIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZl cmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVy aVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMmIxOWVkY2U2YTk0 MWRhZWZjMjdmYjQ0ZTI3NzY1NmUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJp c2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCkSoKiTOW/5HKGOyyy3acc A/zq9flySFN+FelU40rrYO/JWcgbFPbn3HrIPz3fImLFidfXpJwblTv3pzW4L/gReY8br3mg BqBr6O3CI3DjH9MVGE3sxg9Lq9o6dz3ZP2T5ltLgswQEMOFyWD/OKVYiN1cpwKA0B9zBfIN+ eutE0DGCBKowggSmAgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/ VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3Qg VmFsaWRhdGVkAhAtqucR2BBWDghUtYmFlJhhMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDgwMjE1MzE0OFowIwYJKoZIhvcN AQkEMRYEFMh7tQAKdtXdhaOCaGGK3N3oFhe8MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25h IE5vdCBWYWxpZGF0ZWQCEC2q5xHYEFYOCFS1iYWUmGEwgfQGCyqGSIb3DQEJEAILMYHkoIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAtqucR2BBW DghUtYmFlJhhMA0GCSqGSIb3DQEBAQUABIIBAHu1rI4290FFytB9hYu5gC+oMm/VBnczO/J7 hnzyykfa+IEDqiIwGE8i9h+VM1oCjHf69iGHBNYCPDyfpDsNJAYS9PkknFoJa9YdIP9EXjNa eAbmwFOmYMF0em1Azs/wWpbn3YRujeL2fp0+u69SUUpbf7thP8JkcbLVxXdladj25AP/Q8t8 SyZbGxKRKbep6l2IjqEhc0IycHTiCp4/fUpn2RkuhH/64dXRroZSMXqIp+eGc7USdMzEV94W 2paPZpeFUyjobXFacUKaNn/TgELGkcsFlzbK05dotkvMez1sHPa7gS4XlVjFeAIWzsvj4yCz aDR6ZvAg3vm+O/+iFRgAAAAAAAA= --------------ms060604070004030200010108--
PROBLEM ID: 7783
STATE: Approved
EDIT: N/A
RESOLUTION: Modify and Accept
USER POSITION: None
NOTES:
The dir attribute does not apply to embedded content. The src attribute is not equivalent to an xml "include" - it is a reference to a (potentially) external resource that is rendered in the way appropriate to that resources type. But that rendering is done in the context of a separate renderer; ala the object element. Similary, the styling from stylesheets that apply to the parent document does not apply to any embedded content. The fact that your example is "text" does not really matter - text is no more special than any other embedded content. It is handled by however the user agent processes text content, but in a different context than the parent element. We will add text to the src attribute description to clarify this.
ORIGINAL MESSAGE:
From: "Jim Ley" <jim@jibbering.com> Date: Sun, 29 May 2005 22:05:10 +0100 Dear HTML Working Group, http://www.w3.org/TR/xhtml2/mod-bidi.html#col_Bi-directional says that the dir attribute specifies the direction of the elements text content, what is the elements text content in the case of embedded attributes? ie how is <p dir="ltr" src="data:text/plain;chickens"/> rendered? Regards, Jim Ley
FOLLOWUP 1:
Date: Wed, 11 Oct 2006 09:50:21 -0500 From: Mail Delivery Subsystem <MAILER-DAEMON@aptest.com> This is a MIME-encapsulated message --k9BEoLHm005613.1160578221/htmlwg.mn.aptest.com The original message was received at Wed, 11 Oct 2006 09:50:21 -0500 from hades.mn.aptest.com [208.42.66.14] ----- The following addresses had permanent fatal errors ----- "|exec /usr/bin/procmail -f- || exit 75 #user" (reason: Can't create output) (expanded from: <xhtml2iss@htmlwg.mn.aptest.com>) ----- Transcript of session follows ----- procmail: Couldn't create "/var/mail/xhtml2iss" 550 5.0.0 "|exec /usr/bin/procmail -f- || exit 75 #user"... Can't create output --k9BEoLHm005613.1160578221/htmlwg.mn.aptest.com Content-Type: message/delivery-status Reporting-MTA: dns; htmlwg.mn.aptest.com Received-From-MTA: DNS; hades.mn.aptest.com Arrival-Date: Wed, 11 Oct 2006 09:50:21 -0500 Final-Recipient: RFC822; xhtml2iss@htmlwg.mn.aptest.com X-Actual-Recipient: X-Unix; |exec /usr/bin/procmail -f- || exit 75 #user Action: failed Status: 5.3.0 Diagnostic-Code: X-Unix; 73 Last-Attempt-Date: Wed, 11 Oct 2006 09:50:21 -0500 --k9BEoLHm005613.1160578221/htmlwg.mn.aptest.com Content-Type: message/rfc822 Return-Path: <xhtml2-issues@mn.aptest.com> Received: from hades.mn.aptest.com (hades.mn.aptest.com [208.42.66.14]) by htmlwg.mn.aptest.com (8.13.1/8.13.1) with ESMTP id k9BEoLHm005612 for <xhtml2iss@htmlwg.mn.aptest.com>; Wed, 11 Oct 2006 09:50:21 -0500 Received: by hades.mn.aptest.com (Postfix) id 6588D7B6EA; Wed, 11 Oct 2006 09:50:55 -0500 (CDT) Delivered-To: xhtml2-issues@hades.mn.aptest.com Received: from localhost (localhost [127.0.0.1]) by hades.mn.aptest.com (Postfix) with ESMTP id 2C2547B6D0 for <xhtml2-issues@hades.mn.aptest.com>; Wed, 11 Oct 2006 09:50:55 -0500 (CDT) Received: from hades.mn.aptest.com ([127.0.0.1]) by localhost (hades.mn.aptest.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21390-08 for <xhtml2-issues@hades.mn.aptest.com>; Wed, 11 Oct 2006 09:50:52 -0500 (CDT) Received: by hades.mn.aptest.com (Postfix, from userid 589) id CD8C27B736; Wed, 11 Oct 2006 09:50:52 -0500 (CDT) Received: from htmlwg.mn.aptest.com (htmlwg.mn.aptest.com [208.42.66.11]) by hades.mn.aptest.com (Postfix) with ESMTP id A88AC7B6D0 for <xhtml2-issues@hades.mn.aptest.com>; Wed, 11 Oct 2006 09:50:52 -0500 (CDT) Received: from htmlwg.mn.aptest.com (htmlwg.mn.aptest.com [127.0.0.1]) by htmlwg.mn.aptest.com (8.13.1/8.13.1) with ESMTP id k9BEoIpY005609; Wed, 11 Oct 2006 09:50:18 -0500 Date: Wed, 11 Oct 2006 09:50:18 -0500 Message-Id: <200610111450.k9BEoIpY005609@htmlwg.mn.aptest.com> From: Shane McCarron <xhtml2-issues@mn.aptest.com> To: jim@jibbering.com Subject: Re: [XHTML 2] 15 Bi-directional text collection and embedded attributes? (PR#7783) Cc: xhtml2-issues@hades.mn.aptest.com X-Loop: xhtml2-issues@mn.aptest.com X-Virus-Scanned: by amavisd-new at mn.aptest.com Sorry for the long delay in responding to this issue. It was lost in the issues list. The dir attribute does not apply to embedded content. The src attribute is not equivalent to an xml "include" - it is a reference to a (potentially) external resource that is rendered in the way appropriate to that resources type. But that rendering is done in the context of a separate renderer; ala the object element. Similary, the styling from stylesheets that apply to the parent document does not apply to any embedded content. The fact that your example is "text" does not really matter - text is no more special than any other embedded content. It is handled by however the user agent processes text content, but in a different context than the parent element. We will add text to the src attribute description to clarify this. We hope this will address your concern. --k9BEoLHm005613.1160578221/htmlwg.mn.aptest.com--
PROBLEM ID: 7799
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
Discussed this a bit. What we mean is that it is an intersection of media types, and that quality values in the document should take precedence. Will continue to work on this and craft wording. Upon further review, Steven Pemberton has agreed to think about the right solution.
ORIGINAL MESSAGE:
From: "Jim Ley" <jim@jibbering.com> Date: Tue, 31 May 2005 18:38:01 +0100 "Jim Ley" <jim@jibbering.com> > Dear HTML Working Group, > > In Section 5.5 ContentTypes, it is not clear what the user agent should do > in this situation > > <p src="logo" type="image/png; q=0.5, image/jpeg;q=0.1"> > > with a user agent values of > > image/png;q=0.1, image/jpeg;q=0.9; > > Please clarify the section to explain how document quality values, and > user agent quality values combine. > > Regards, > > Jim Ley.
PROBLEM ID: 7800
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
This is related to issue 7799 - the answer may be that asterisks are not relevant. We will clarify this once Steven's action item is complete.
ORIGINAL MESSAGE:
From: "Jim Ley" <jim@jibbering.com> Date: Tue, 31 May 2005 18:38:12 +0100 "Jim Ley" <jim@jibbering.com> > Dear HTML Working Group > > Section 5.5 says that "The user agent must combine this list with its own > list of acceptable media types by taking the intersection" > > Please clarify this to say that asterisks are expanded when considering > the intersection, this is not clear currently, if I have assumed wrongly > and it is a simple intersection of the unexpanded values, please change > this to be an intersection of the expanded values. > > Regards, > > Jim Ley.
PROBLEM ID: 7336
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: None
NOTES:
BAE F2F: for the present DTD's are required for entity resolution. This is a tricky issue, and the working group needs to resolve it quickly. We are asking for input from the Hypertext Coordination Group and others in our quest to sort it out.
ORIGINAL MESSAGE:
Date: Thu, 8 May 2003 10:34:27 -0500 From: steven.pemberton@cwi.nl Full_Name: Steven Pemberton Submission from: (NULL) (192.16.196.157) Submitted by: spemberton If we move to a world of schema-based validation, the DOCTYPE disappears. But that is the principle method of idetifying the XHTML variant. What method should we use to identify the variant in the absence of DTDs?
FOLLOWUP 1:
Date: Thu, 8 May 2003 17:11:18 -0400 From: "Glenn A. Adams" <glenn@xfsi.com> I was reacting to Steven's statement that "If we move to a world of schema-based validation, the DOCTYPE disappears." I was pointing out that this is not necessarily the case, since the use of (non XML DTD) schema based validation has no necessary impact on the presence or absence of a DOCTYPE declaration. In the case of W3C XML Schema, the typical way of associating an instance document with a W3C XML Schema is to use the xsi:schemaLocation attribute. RELAX NG does not define a way to associate an instance document with a RNG pattern (schema). It is perfectly acceptable for an instance document to have a DOCTYPE declaration, an xsi:schemaLocation attribute, and even other to be specified ways to associate with an RNG pattern. Indeed, perhaps a good reason to do this would be to define XML entities in the DOCTYPE internal declaration subset for use in the instance document, since neither W3C XML Schema nor RNG support XML general entities. So, moving beyond the above, there seems to be a couple of potentially orthogonal issues here: (1) how to associate an instance document with one or more schema with which the document may be validated; (2) how to identify a profile (by which I take to mean subset) of some standard schema. In the case of (1), then I believe one could reasonably have multiple associations specified in the instance document as I have described. In the case that multiple schemas were associated, then some rules could be established for determining an ordering for their application, e.g., use xsi:schemaLocation first if user agent performs W3C Schema Validity Assessment, then use DTD specified by DOCTYPE, if schema is not available or if user agent supports only XML DTD validation, etc. In the case of (2), such a profile could be indicated in a variety of ways, such as: * according to referenced schema/dtd * according to value of profile attribute on <head> * according to applicable namespace * ... I don't have any preference in particular. G. > -----Original Message----- > From: Shane McCarron [mailto:shane@aptest.com] > Sent: Thursday, May 08, 2003 2:39 PM > To: Glenn A. Adams > Cc: w3c-html-wg@w3.org; xhtml2-issues@mn.aptest.com > Subject: Re: Identifying XHTML version in ansence of DTDs (PR#7336) > > > Let me just try to clarify this suggestion. > > What you are saying is that the DOCTYPE can still be present, > and we can use that to determine the "type" of the document. > Then a validating parser could, at its option, look for an > xsi:schemaLocation attribute on the root element. If that > were there, it could use the referenced schema for > validating. If it were NOT there, it could use the > referenced DTD from the DOCTYPE for validating. > > Is that right? > > "Glenn A. Adams" wrote: > > > > The DOCTYPE need not disappear. One can specify both DOCTYPE > > referencing a DTD as well as provide an xsi:schemaLocation > attribute > > on the document element referencing a schema. > > > > I agree with PV that the profile attribute is a good candidate. > > > > Forget about <!SCHEMA ...> as that is not XML compliant (and > > doubtfully would ever be considered as an extension). > > > > G. > > > > > Date: Thu, 8 May 2003 10:34:27 -0500 > > > Message-Id: <200305081534.h48FYRf13996@hades.mn.aptest.com> > > > From: steven.pemberton@cwi.nl > > > To: w3c-html-wg@w3.org > > > CC: xhtml2-issues@mn.aptest.com > > > Subject: Identifying XHTML version in ansence of DTDs (PR#7336) > > > > > If we move to a world of schema-based validation, the DOCTYPE > > > disappears. But that is the principle method of > idetifying the XHTML > > > variant. What method should we use to identify the variant in the > > > absence of DTDs? > > -- > Shane P. McCarron Phone: +1 763 786-8160 x120 > Managing Director Fax: +1 763 786-8180 > ApTest Minnesota Inet: shane@aptest.com >
FOLLOWUP 2:
Date: Thu, 08 May 2003 11:18:16 -0500 From: Shane McCarron <shane@aptest.com> Talking with Beth and Ann a little, how about something like: <!DOCTYPE html PUBLIC "whatever" SYSTEM "foo.xsd" TYPE "application/xml-schema" SYSTEM "foo.dtd" TYPE "application/xml-dtd" ... > This is an extension, and would need to be in an update to XML, so we would need to REQUIRE a new version of XML to support this: <?xml version="1.1" ?> steven.pemberton@cwi.nl wrote: > > Full_Name: Steven Pemberton > Submission from: (NULL) (192.16.196.157) > Submitted by: spemberton > > If we move to a world of schema-based validation, the DOCTYPE disappears. > > But that is the principle method of idetifying the XHTML variant. > > What method should we use to identify the variant in the absence of DTDs? -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
FOLLOWUP 3:
Date: Thu, 8 May 2003 08:54:56 -0700 From: rubydoo123@aol.com (Beth Epperson) I would suggest the following: I would suggest something like this: <?xml version="1.0" encoding="utf-8"?> <!SCHEMA xhtml PUBLIC "-//W3C//SCHEMA XHTML 2.0//EN" "http://www.w3.org/TR/xhtml2/SCHEMA/xhtml2.sch"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US"> We would need to get approval for the <!SCHEMA This would allow us to: 1. allow authros to point to different versions, like in html doctype 2. allow parser/validation services to easily recognize different versions 3. remain consistant with the current methodology //beth steven.pemberton@cwi.nl wrote: > > Full_Name: Steven Pemberton > Submission from: (NULL) (192.16.196.157) > Submitted by: spemberton > > > If we move to a world of schema-based validation, the DOCTYPE disappears. > > But that is the principle method of idetifying the XHTML variant. > > What method should we use to identify the variant in the absence of DTDs? >
FOLLOWUP 4:
Date: Thu, 08 May 2003 13:38:32 -0500 From: Shane McCarron <shane@aptest.com> Let me just try to clarify this suggestion. What you are saying is that the DOCTYPE can still be present, and we can use that to determine the "type" of the document. Then a validating parser could, at its option, look for an xsi:schemaLocation attribute on the root element. If that were there, it could use the referenced schema for validating. If it were NOT there, it could use the referenced DTD from the DOCTYPE for validating. Is that right? "Glenn A. Adams" wrote: > > The DOCTYPE need not disappear. One can specify both DOCTYPE > referencing a DTD as well as provide an xsi:schemaLocation > attribute on the document element referencing a schema. > > I agree with PV that the profile attribute is a good candidate. > > Forget about <!SCHEMA ...> as that is not XML compliant (and > doubtfully would ever be considered as an extension). > > G. > > > Date: Thu, 8 May 2003 10:34:27 -0500 > > Message-Id: <200305081534.h48FYRf13996@hades.mn.aptest.com> > > From: steven.pemberton@cwi.nl > > To: w3c-html-wg@w3.org > > CC: xhtml2-issues@mn.aptest.com > > Subject: Identifying XHTML version in ansence of DTDs (PR#7336) > > > If we move to a world of schema-based validation, the DOCTYPE disappears. > > But that is the principle method of idetifying the XHTML variant. > > What method should we use to identify the variant in the absence of DTDs? -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
PROBLEM ID: 670
STATE: Approved
EDIT: N/A
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
We will support both XML Catalogs and SGML Open Catalogs for XHTML 2.
ORIGINAL MESSAGE:
Date: Wed, 06 Mar 2002 02:12:36 +0900 (JST) From: Masayasu Ishikawa <mimasa@w3.org> This is primarily a question for XHTML 2.0, but also affects the second edition of XHTML 1.0 (and 1.1, Basic and M12N as well, when we publish them). So far, we included SGML Open catalogs [1] in our XHTML specifications, but as its name says, it's primarily for SGML and not for XML. Support for (even a subset of) SGML Open catalog in XML 1.0 was rejected by the former XML WG [2], so we were using a feature with no official standing in XML. We didn't have an alternative when we published XHTML 1.0, Basic, M12N and 1.1, but the XML Catalogs specification [3] was published as an OASIS Committee Specification in August 2001. So now that we have an XML way of entity management. My questions are: 1. Do we still want to support catalogs in XHTML 2.0 (assuming that we will provide informative DTD modules)? 2. If the answer is yes, which entity management we would use, XML catalogs or SGML Open catalogs? 3. If we choose XML catalogs, do we want to use it for the second edition of XHTML 1.0 and other specs? [1] http://www.oasis-open.org/specs/tr9401.html [2] http://www.w3.org/XML/9712-reports#ID41 [3] http://www.oasis-open.org/committees/entity/spec.html Regards, -- Masayasu Ishikawa / mimasa@w3.org W3C - World Wide Web Consortium
PROBLEM ID: 671
STATE: Approved
EDIT: N/A
RESOLUTION: Accept
USER POSITION: None
NOTES:
The WG believes that there's still a need for character entities. We need to find a solution. On 9 September 2003, the WG agrees to retain character entities; DTDs therefore still necessary; it might be possible to supply a DTD that only provides the entities.
ORIGINAL MESSAGE:
Date: Thu, 07 Mar 2002 17:55:44 +0900 (JST) From: Masayasu Ishikawa <mimasa@w3.org> I'm really sorry to resurrect this old issue, but for XHTML 2.0, we have to reconsider this issue again, unfortunately. If I understand correctly, the decision at the Cannnes FtF w.r.t. the conformance section of XHTML 2.0 [1] is to require xsi:schemaLocation and make DOCTYPE optional. However, as we all know painfully well, XML Schema doesn't support entities and if we want to continue to support character entity references in XHTML 2.0, we have to stick to DTD mechanism. I'm not sure if we discussed this issue particularly for XHTML 2.0, and in Boston FtF, we discussed (I believe with XHTML 1.x in mind) and decided as follows [2]: Conclusion: We will continue to require DTD parsers along with XML Schemas Well, strictly speaking, it's somewhat bogus, as non-validating XML processors may not read external DTD subset, so if we really want to use character entity references reliably, those entity declarations have to be declared in the internal DTD subset. So, what's our position for XHTML 2.0? Possible options include: 1. Continue to support character entities, require DOCTYPE (at least for character entities) in addition to xsi:schemaLocation 2. Abandon support for character entities 3. Replace character entities with an ugly schema "alternative" (see an example in XML Schema Part 0 [3]) 4. Use other arcane mechanism, such as PI (ugh). 5. Declare defeat, explain the current mess, tell authors not to rely on character entities (e.g. authors MAY use them but they have to explicitly include all the necessary entity declarations in the internal subset for reliable processing). None of these options is ideal, but we have to face this reality and make a decision. [1] http://www.w3.org/MarkUp/Group/2002/WD-xhtml2-20020209/conformance.html#strict [2] http://www.w3.org/MarkUp/Group/2001/03/f2f/minutes#Entities [3] http://www.w3.org/TR/xmlschema-0/#usingEntities Regards, -- Masayasu Ishikawa / mimasa@w3.org W3C - World Wide Web Consortium
FOLLOWUP 1:
Date: Fri, 22 Mar 2002 18:56:14 +0900 (JST) From: Masayasu Ishikawa <mimasa@w3.org> Masayasu Ishikawa <mimasa@w3.org> wrote: > I found Henry Thompson's proposal and relevant discussion at xml-dev. > See the following threads: > > A heavier-weight proposal for character entity definition > http://lists.xml.org/archives/xml-dev/200202/threads.html#00234 > http://lists.xml.org/archives/xml-dev/200202/threads.html#00278 Another relevant proposal from OASIS is at: http://www.oasis-open.org/docbook/xmlcharent/0.2/entities-2002-03-19.html See in particular "2. XML Character Elements". Regards, -- Masayasu Ishikawa / mimasa@w3.org W3C - World Wide Web Consortium
FOLLOWUP 2:
Date: Sat, 16 Mar 2002 09:43:04 +0900 (JST) From: Masayasu Ishikawa <mimasa@w3.org> mimasa@w3.org wrote: > So, what's our position for XHTML 2.0? Possible options include: > > 1. Continue to support character entities, require DOCTYPE (at least > for character entities) in addition to xsi:schemaLocation > 2. Abandon support for character entities > 3. Replace character entities with an ugly schema "alternative" (see > an example in XML Schema Part 0 [3]) > 4. Use other arcane mechanism, such as PI (ugh). > 5. Declare defeat, explain the current mess, tell authors not to > rely on character entities (e.g. authors MAY use them but they > have to explicitly include all the necessary entity declarations > in the internal subset for reliable processing). I found Henry Thompson's proposal and relevant discussion at xml-dev. See the following threads: A heavier-weight proposal for character entity definition http://lists.xml.org/archives/xml-dev/200202/threads.html#00234 http://lists.xml.org/archives/xml-dev/200202/threads.html#00278 > [1] http://www.w3.org/MarkUp/Group/2002/WD-xhtml2-20020209/conformance.html#strict > [2] http://www.w3.org/MarkUp/Group/2001/03/f2f/minutes#Entities > [3] http://www.w3.org/TR/xmlschema-0/#usingEntities Regards, -- Masayasu Ishikawa / mimasa@w3.org W3C - World Wide Web Consortium
PROBLEM ID: 7724
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
Original message at: http://lists.w3.org/Archives/Public/www-html-editor/2005AprJun/0064 This is a reply to issue 7655, where SP also replied
ORIGINAL MESSAGE:
Date: Fri, 27 May 2005 20:32:48 -0500 From: Shane McCarron <shane@aptest.com> Jim Ley wrote: >On 5/27/05, Shane McCarron <shane@aptest.com> wrote: > > >It is disappointing that just a few days after being last reminded of >your obligations under the W3 Process document, you again fail to >adhere to those obligations. > > Thanks again for reminding me. >I do not regard this as an appropriate attempt to respond to or >satisfy my issue, there is no techincal content in why the issue was >rejected, and at no time have you attempted to explain either the >decision or attempted to satisfy me. Please formally address the >issue in accordance with the process document. > > Our primary obligation is to produce a document that achieves consensus. This particular feature has achieved a sufficient level of consensus in the working group. That's why it is in the draft. I have not had an opportunity to discuss this issue further with the working group, or to ask the group to consider revising its response. However, here are some PERSONAL THOUGHTS on this feature of XHTML 2: The working group has chosen to extend the fallback model that was present in HTML 4 with the object element. There is no requirement that document authors use this mechanism, just as there was no requirement anyone use the mechanism that was available with the object element. There are a myriad of pathological cases where this mechanism, while technically sound, would be aesthetically disappointing. This is true of lots of features in HTML, XHTML and indeed in other markup languages and technologies. Tables, for example, are used in inappropriate ways all over the place. However, we would never consider getting rid of tables, because there are situations where tables are the perfect tool for the job. Your original request, b.t.w., asked a question. It did not request a change or propose a solution, even a vague one. Regardless, the working group took the request as a serious submission and reviewed it. We interpreted your comment as having two related components - 1) that fallback items might be different sizes, and 2) that the fallback content might need to be styled differently. We responded to 1) with "We understand that fallbacks might have different sizes. This is really an issue for the author. The flexibility far outweighs the risk that things will render in unpredictable ways." You have indicated that this is an unacceptable response, and we have recorded your objection. We did not respond to the second component explicitly. I can extrapolate from my notes that the group felt the issue with different styles could be addressed by, for example, assigning different @id values to each level, or using different @style attributes at each level, or using different @class values at each level that you wanted to style differently. This permits very finely grained control of the formatting of fallback blocks. You could also, of course, choose to NOT style the different levels explicitly too. This provides for maximum flexibility. You are correct that using the fallback in the example you cite would be challenging to style using the mechanisms above. However, it could be written as: <div src="temperature-graph.png" srctype="image/png" id="weatherimg"> <table id="weathertable"> <caption>Average monthly temperature over the last 20 years</caption> <tr><th>Jan</th><th>Feb</th><th>Mar</th><th>Apr</th><th>May</th><th>Jun</th> <th>Jul</th><th>Aug</th><th>Sep</th><th>Oct</th><th>Nov</th><th>Dec</th> </tr> <tr><td> 4</td><td> 2</td><td> 7</td><td> 9</td><td>13</td><td>16</td> <td>17</td><td>17</td><td>14</td><td>11</td><td> 7</td><td> 4</td> </tr> <!-- 19 more rows for the other 19 years> </table> </div> And then styled appropriately. If you have a proposal that would address your concern in some other way, please let us know. -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
PROBLEM ID: 7670
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: None
NOTES:
We concerned about how to marry the coordinate systems between SVG and HTML. We need a concrete proposal from the SVG group, because we can't figure out how to implement it. Working group feels that the imagemap stuff should remain the same as it has been historically. SVG has its own stuff, and if an author wants to use that, they can by creating hybrid documents that use XHTML 2 + SVG markup. However, creating fallback imagemaps (using SVG if supported, native XHTML 2 if not) would be challenging. Authoring tool developers may find this even more challenging. Submitter indicated that he would accept adding a note to the spec indicating that there is another way to do imagemaps using SVG, with a pointer to SVG. W3C is working on Profiles of XHTML that include SVG-Tiny / SVG. In the future we feel that imagemaps will be better handled by such an environment. Include a reference to SVG / SVG-Tiny.
ORIGINAL MESSAGE:
Date: Thu, 09 Sep 2004 18:01:30 +0900 (JST) From: Dan Brickley <danbri@w3.org> From: Dan Brickley <danbri@w3.org> To: www-html-editor@w3.org Cc: dean@w3.org Subject: XHTML2 issue request: no defined mapping from imagemaps to SVG Date: Thu, 9 Sep 2004 04:08:14 -0400 Message-ID: <20040909080813.GC7011@homer.w3.org> X-Archived-At: http://www.w3.org/mid/20040909080813.GC7011@homer.w3.org Hi I'd like to raise an issue with the XHTML2 spec - the imagemap section would be improved if it mentioned a mapping into SVG. I'm reading the 22 July 2004 Working Draft, specifically the section on Imagemaps, http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-csImgMap.html#s_csImgMapmodule While I realise HTML imagemaps pre-date SVG, XHTML2 is generally taking a more daring line regarding backwards compatibility than previous HTMLs. At W3C we have a lot of specs that overlap in little ways in their scope, and this is a pretty typical example of that. 'd like the XHTML2 spec to at least acknowledge the existence of SVG. Ideally, you would also define a mapping into SVG constructs (perhaps SVGTiny or SVGBasic). I'd also like to see consideration of the arguments for/against use of SVG, or at least a more SVG-centric markup notation. In http://www.w3.org/TR/2004/WD-xhtml2-20040722/introduction.html#s_intro "As generic XML as possible: if a facility exists in XML, try to use that rather than duplicating it" suggests that the HTML WG might be friendly to the possibility of re-use rather than duplication here. One argument in favour of SVG support within HTML imagemaps, is that imagemap authoring tools should be perfectly capable of generating both HTML-imagemap markup and/or normal SVG (+RDF metadata) based on the same authoring session. Image overlays are a form of metadata, and can be useful for accessibility, search, clipart etc., so anything we can do that encourages tool builders to offer HTML and SVG saveAs facilities would be valuable. In its current form, the new XHTML2 work doesn't give any hint to imagemap implementors that there might be other W3C-blessed ways of representing rectangles, circles, polygons etc overlaid on images. So, to summarise: 1. please cite the SVG specs from http://www.w3.org/TR/xhtml2/mod-csImgMap.html and make at least a brief prose account of the different representational conventions (XSLT code would be better) 2. please consider (or point me at the discussion if I missed it) allowing SVG (or a profile) to be directly used instead of olde-style HTML imagemaps. 3. if you choose/chose not to go with SVG, consider revising the notation in http://www.w3.org/TR/xhtml2/mod-csImgMap.html#s_csImgMapmodule to be closer to the SVG way, to make things easier on Web developer's brains. I should stress that I'm not suggesting that the HTML WG need to make a full SVG implementation a normative requirement on XHTML2 implimentors, just that the notations could be more closely alligned. cheers, Dan ps. if things stay as-is, might be worth reminding SVG authoring tool folk that their code probably works as an imagemap authoring thingie with relatively little effort...
PROBLEM ID: 7887
STATE: Suspended
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
XHTML 2 incorporates XForms, which has some elements to assist with this general problem. The working group will investigate this further and see if the solution can be applied here.
ORIGINAL MESSAGE:
Date: Sat, 25 Mar 2006 14:18:45 +0100 From: Laurens Holst <lholst@students.cs.uu.nl> This is a cryptographically signed message in MIME format. --------------ms030006010108030703050602 Content-Type: multipart/mixed; boundary="------------010100070104000508020703" This is a multi-part message in MIME format. --------------010100070104000508020703 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Giving titles to images is something that is done extremely frequently=20 in pretty much all applications of XHTML. (Of course, this wouldn=E2=80=99= t=20 apply to images alone but also to code blocks, mathematical formulas and=20 inline svg.) There are currently the following two mechanisms: <img src=3D"binarytree.png" title=3D"Representation of a binary tree">= =E2=80=A6</img> and in XHTML 2.0 also: <img src=3D"binarytree.png" id=3D"binarytree">=E2=80=A6</img> <meta about=3D"#binarytree" property=3D"title">Representation of a bin= ary=20 tree</meta> Currently, the first is hardly used on the web because it requires=20 generated content to be made visible (unless you are satisfied with a=20 tooltip), and also doesn=E2=80=99t allow element content. On most web sit= es, you=20 will probably see that authors simply wrap the image in a <div>, and=20 create a separate <div class=3D"title"> with the title below the image. The second is better, but it still needs a property=3D"title" attribute,=20 and it isn=E2=80=99t immediately clear from the name =E2=80=98meta=E2=80=99= that it can be used=20 for titles on images as well, so I wonder whether this will be=20 discoverable enough to authors. So, isn=E2=80=99t a title something common enough to warrant an element o= f its=20 own? This could simply be a shortcut for <meta property=3D"title">, or=20 provide more capabilities such as a container element to link the title=20 to its image by means of XML structure. In any case, given that this is such a frequent use case, I propose to=20 add these two as examples to the specification, for clarification to=20 authors. Either at the =E2=80=98title=E2=80=99 attribute or the =E2=80=98= img=E2=80=99 element. ~Grauw --=20 Ushiko-san! Kimi wa doushite, Ushiko-san!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Laurens Holst, student, university of Utrecht, the Netherlands. Website: www.grauw.nl. Backbase employee; www.backbase.com. --------------010100070104000508020703 Content-Type: text/x-vcard; charset=utf-8; name="lholst.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lholst.vcf" YmVnaW46dmNhcmQNCmZuOkxhdXJlbnMgSG9sc3QNCm46SG9sc3Q7TGF1cmVucw0KZW1haWw7 aW50ZXJuZXQ6bGhvbHN0QHN0dWRlbnRzLmNzLnV1Lm5sDQp0ZWw7Y2VsbDooKzMxKSAwNi00 MTc2NTA0OA0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnZlcnNpb246Mi4xDQplbmQ6dmNhcmQN Cg0K --------------010100070104000508020703-- --------------ms030006010108030703050602 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJHzCC AuowggJToAMCAQICEDWFwmQavETUVHd8CnEtJLMwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDMyMDE0MjcxNFoX DTA3MDMyMDE0MjcxNFowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUG CSqGSIb3DQEJARYYbGhvbHN0QHN0dWRlbnRzLmNzLnV1Lm5sMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAyfKi1lJ9Xcim04z6ufnR8DhnNbImjqxC+EugM7ueHH3teg2hjxVc fIJfKltRkSd9epX0RbciLoColN8wGCL9Tipreau8vgKOJ8fm2Py/cSNQ5x8K8L1WTTZcs63y O1fiizrrhd2A7olWY35dRoEtzoMvBpjiMwszOdWm/UWVYtrhrRMJE+3RfcHMx4y0MEwnDL1/ eI58jXL8d7f+jLiSDz9E1OLLXp/1Lbv86SnWOXWru/t9pNgrBKH6/jqbeHUFTzcyNYtkwpFy hgneKbI3NjSdVnE0jJxK8jG7GHrT69pZ/F0vMlKTRykOfyJ+uLAG90DIGVQfB2u/uVKWR8Lr 0wIDAQABozUwMzAjBgNVHREEHDAagRhsaG9sc3RAc3R1ZGVudHMuY3MudXUubmwwDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCEAy9JQpJ+9JBsHpCncLLEuLGBmY01qlyt+iF/ 5l6VqT+iJHZVIJDEP3l9bwC6a90Q8UJvLVVluINFvii4U6FxxGYqWVwy9Xma0IYfEyoW8J8R +PEic2dRrFK/DBDOFbil0kSB2ZNPPpuu7x4gYLD1tNxRuXWNbiGwHgZytvbl0TCCAuowggJT oAMCAQICEDWFwmQavETUVHd8CnEtJLMwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDMyMDE0MjcxNFoXDTA3MDMy MDE0MjcxNFowSjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEnMCUGCSqGSIb3 DQEJARYYbGhvbHN0QHN0dWRlbnRzLmNzLnV1Lm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAyfKi1lJ9Xcim04z6ufnR8DhnNbImjqxC+EugM7ueHH3teg2hjxVcfIJfKltR kSd9epX0RbciLoColN8wGCL9Tipreau8vgKOJ8fm2Py/cSNQ5x8K8L1WTTZcs63yO1fiizrr hd2A7olWY35dRoEtzoMvBpjiMwszOdWm/UWVYtrhrRMJE+3RfcHMx4y0MEwnDL1/eI58jXL8 d7f+jLiSDz9E1OLLXp/1Lbv86SnWOXWru/t9pNgrBKH6/jqbeHUFTzcyNYtkwpFyhgneKbI3 NjSdVnE0jJxK8jG7GHrT69pZ/F0vMlKTRykOfyJ+uLAG90DIGVQfB2u/uVKWR8Lr0wIDAQAB ozUwMzAjBgNVHREEHDAagRhsaG9sc3RAc3R1ZGVudHMuY3MudXUubmwwDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQQFAAOBgQCEAy9JQpJ+9JBsHpCncLLEuLGBmY01qlyt+iF/5l6VqT+i JHZVIJDEP3l9bwC6a90Q8UJvLVVluINFvii4U6FxxGYqWVwy9Xma0IYfEyoW8J8R+PEic2dR rFK/DBDOFbil0kSB2ZNPPpuu7x4gYLD1tNxRuXWNbiGwHgZytvbl0TCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNkMIIDYAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQNYXCZBq8RNRUd3wKcS0kszAJBgUrDgMCGgUAoIIBwzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMjUxMzE4NDVaMCMG CSqGSIb3DQEJBDEWBBRk6UvH7T72LXD9i5s0KlkX+GVX2zBSBgkqhkiG9w0BCQ8xRTBDMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEDWFwmQavETUVHd8CnEtJLMwgYcGCyqGSIb3DQEJEAIL MXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDWF wmQavETUVHd8CnEtJLMwDQYJKoZIhvcNAQEBBQAEggEAVvBHILwhqPLMIWWMvTOoUVLHC9h0 yOJBFK7V/7oKWhghNTTabF3rxh+fSHIIEFfZXXTPrA3fGW/laH6RhHzcpwPgCAdg6/qbhi2W Vd5hBphEndo3EXhszic3n4r1bBuQwyB7GWlhAk0XpaehoSXOeF0hRuZJ1ushG/tR/mmZZRqZ OHvzr8ZpSqtKWdvO53Eyxvqqp4sOzp4jw/uZSHXWB3BfKuhv5vL/4rTb0+VLJoGK4nqYV9hP 1bm7r9hOQZy4oEJJxVDcYVW2hEf0ibvFCTcjeX/UcHhNi9RJ4Imvcd56STGllUv0Itll4AsD csg2dax9W/j82BJzHgC22jXGwAAAAAAAAA== --------------ms030006010108030703050602--
PROBLEM ID: 7759
STATE: Suspended
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
Suspended until last call
ORIGINAL MESSAGE:
Date: Sat, 28 May 2005 23:06:44 +0000 (UTC) From: Ian Hickson <ian@hixie.ch> XHTML2's "1.1.3. XHTML 2 and Presentation" section says: # XHTML 2 takes HTML back to these roots, by removing all presentation # elements, and subordinating all presentation to style sheets. This, while technically true, does not seem completely consistent with the inclusion of the style="" attribute (in section 27 XHTML Style Attribute Module). I feel that the intent of removing all presentational aspects from the language is to be applauded and would like to ask for the purely presentational style="" attribute to be removed. If it is to remain in XHTML2, however, a clear indication of its purpose should be given, so as to explain the conflict between its presence and the sentiment of section 1.1.3. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
FOLLOWUP 1:
Date: Wed, 8 Feb 2006 20:52:11 -0800 From: "Epperson, Beth" <bepperson@websense.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C62D35.0D2AD3CA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would suggest that this be a response from the CSS WG. As a member of = the WG - Ian, I would suggest you bring this to the F2F where the CSS WG = come to an internal agreement as to whether the desire is to have the = attribute removed or retained. Once the CSS WG has a decision, then = request a joint meeting where both WG's can discuss and finally agree = and be done with this discussion. But wait - we already did that 2 or 3 = years ago - hence it is in the spec. //beth -----Original Message----- From: w3c-html-wg-request@w3.org on behalf of ian@hixie.ch Sent: Wed 2/8/2006 9:55 AM To: w3c-html-wg@w3.org Cc: xhtml2-issues@hades.mn.aptest.com Subject: [BULK] - Re: [XHTML2] Spirit of "1.1.3. XHTML 2 and = Presentation" (PR#7759) =20 On Wed, 8 Feb 2006, Steven Pemberton wrote: > Ian Hickson wrote: > > On Fri, 13 Jan 2006, Steven Pemberton wrote: > > > > XHTML2's "1.1.3. XHTML 2 and Presentation" section says: > > > >=20 > > > > # XHTML 2 takes HTML back to these roots, by removing all = presentation # > > > > elements, and subordinating all presentation to style sheets. > > > >=20 > > > > This, while technically true, does not seem completely = consistent with > > > > the inclusion of the style=3D"" attribute (in section 27 XHTML = Style > > > > Attribute Module). I feel that the intent of removing all = presentational > > > > aspects from the language is to be applauded and would like to = ask for > > > > the purely presentational style=3D"" attribute to be removed. > > > >=20 > > > > If it is to remain in XHTML2, however, a clear indication of its = purpose > > > > should be given, so as to explain the conflict between its = presence and > > > > the sentiment of section 1.1.3. > > > > > > The WG has decided to suspend this issue (ie decide whether to=20 > > > include the style attribute or not) until after last call. > >=20 > > Um, it would seem that this issue would have to be resolved _before_ = > > last call, otherwise we could not make a complete review of the=20 > > document during last call. Therefore this does not satisfy my = request. >=20 > Unfortunately, this is an issue where consensus hasn't been reached In that case, per W3C process, you will be unable to progress beyond = last=20 call. > Since we can't please both groups at once, since no new information = has=20 > come in, and since can't keep ping ponging the attribute from draft to = > draft, we resolved to leave it as is, bring attention to the issue at=20 > last call, and revisit it then. As you are no doubt aware, however, W3C process section 7.4.3, paragraph = 7=20 sentence 2, and all of section 7.4.6, require you to go back to last = call=20 if you make any substantive changes. As you have pointed out, this is a=20 big change. Therefore attempting to duck the issue until after last call = seems like a false economy -- it will only force you to have _another_=20 last call. > I'm sorry you are not satisfied, but it is either you or Daniel = Glazman. My request was not only to remove the style attribute. It was to either=20 remove the style attribute, _or_, to make it clear that XHTML2 is not a=20 purely non-presentational language, with prose explaining why. --=20 Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ------_=_NextPart_001_01C62D35.0D2AD3CA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7638.1"> <TITLE>RE: [BULK] - Re: [XHTML2] Spirit of "1.1.3. XHTML 2 and = Presentation" (PR#7759)</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <BR> <P><FONT SIZE=3D2>I would suggest that this be a response from the CSS = WG. As a member of the WG - Ian, I would suggest you bring this to the = F2F where the CSS WG come to an internal agreement as to whether the = desire is to have the attribute removed or retained. Once the CSS WG has = a decision, then request a joint meeting where both WG's can discuss and = finally agree and be done with this discussion. But wait - we already = did that 2 or 3 years ago - hence it is in the spec.<BR> <BR> //beth<BR> <BR> -----Original Message-----<BR> From: w3c-html-wg-request@w3.org on behalf of ian@hixie.ch<BR> Sent: Wed 2/8/2006 9:55 AM<BR> To: w3c-html-wg@w3.org<BR> Cc: xhtml2-issues@hades.mn.aptest.com<BR> Subject: [BULK] - Re: [XHTML2] Spirit of "1.1.3. XHTML 2 and = Presentation" (PR#7759)<BR> <BR> <BR> On Wed, 8 Feb 2006, Steven Pemberton wrote:<BR> > Ian Hickson wrote:<BR> > > On Fri, 13 Jan 2006, Steven Pemberton wrote:<BR> > > > > XHTML2's "1.1.3. XHTML 2 and Presentation" = section says:<BR> > > > ><BR> > > > > # XHTML 2 takes HTML back to these roots, by = removing all presentation #<BR> > > > > elements, and subordinating all presentation to = style sheets.<BR> > > > ><BR> > > > > This, while technically true, does not seem = completely consistent with<BR> > > > > the inclusion of the style=3D"" attribute = (in section 27 XHTML Style<BR> > > > > Attribute Module). I feel that the intent of = removing all presentational<BR> > > > > aspects from the language is to be applauded and = would like to ask for<BR> > > > > the purely presentational style=3D"" = attribute to be removed.<BR> > > > ><BR> > > > > If it is to remain in XHTML2, however, a clear = indication of its purpose<BR> > > > > should be given, so as to explain the conflict = between its presence and<BR> > > > > the sentiment of section 1.1.3.<BR> > > ><BR> > > > The WG has decided to suspend this issue (ie decide = whether to<BR> > > > include the style attribute or not) until after last = call.<BR> > ><BR> > > Um, it would seem that this issue would have to be resolved = _before_<BR> > > last call, otherwise we could not make a complete review of = the<BR> > > document during last call. Therefore this does not satisfy my = request.<BR> ><BR> > Unfortunately, this is an issue where consensus hasn't been = reached<BR> <BR> In that case, per W3C process, you will be unable to progress beyond = last<BR> call.<BR> <BR> <BR> > Since we can't please both groups at once, since no new information = has<BR> > come in, and since can't keep ping ponging the attribute from draft = to<BR> > draft, we resolved to leave it as is, bring attention to the issue = at<BR> > last call, and revisit it then.<BR> <BR> As you are no doubt aware, however, W3C process section 7.4.3, paragraph = 7<BR> sentence 2, and all of section 7.4.6, require you to go back to last = call<BR> if you make any substantive changes. As you have pointed out, this is = a<BR> big change. Therefore attempting to duck the issue until after last = call<BR> seems like a false economy -- it will only force you to have = _another_<BR> last call.<BR> <BR> <BR> > I'm sorry you are not satisfied, but it is either you or Daniel = Glazman.<BR> <BR> My request was not only to remove the style attribute. It was to = either<BR> remove the style attribute, _or_, to make it clear that XHTML2 is not = a<BR> purely non-presentational language, with prose explaining why.<BR> <BR> --<BR> Ian = Hickson = = U+1047E = )\._.,--....,'``. fL<BR> <A = HREF=3D"http://ln.hixie.ch/">http://ln.hixie.ch/</A> &nb= sp; = U+263A &= nbsp; /, _.. \ _\ ;`._ = ,.<BR> Things that are impossible just take longer. = `._.-(,_..'--(,_..'`-.;.'<BR> <BR> <BR> <BR> <BR> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C62D35.0D2AD3CA--
FOLLOWUP 2:
Date: Wed, 08 Feb 2006 15:14:21 +0100 From: Steven Pemberton <steven.pemberton@cwi.nl> Ian Hickson wrote: > On Fri, 13 Jan 2006, Steven Pemberton wrote: >>> XHTML2's "1.1.3. XHTML 2 and Presentation" section says: >>> >>> # XHTML 2 takes HTML back to these roots, by removing all presentation >>> # elements, and subordinating all presentation to style sheets. >>> >>> This, while technically true, does not seem completely consistent with the >>> inclusion of the style="" attribute (in section 27 XHTML Style Attribute >>> Module). I feel that the intent of removing all presentational aspects >>> from the language is to be applauded and would like to ask for the purely >>> presentational style="" attribute to be removed. >>> >>> If it is to remain in XHTML2, however, a clear indication of its purpose >>> should be given, so as to explain the conflict between its presence and >>> the sentiment of section 1.1.3. >> The WG has decided to suspend this issue (ie decide whether to include >> the style attribute or not) until after last call. > > Um, it would seem that this issue would have to be resolved _before_ last > call, otherwise we could not make a complete review of the document during > last call. Therefore this does not satisfy my request. Unfortunately, this is an issue where consensus hasn't been reached, There are people with very strong views on both sides. Originally we had no style attribute, and this brought strong complaints (principally from the CSS WG I should say). The style attribute got added then, and that brought with it equally strong complaints from others. Since we can't please both groups at once, since no new information has come in, and since can't keep ping ponging the attribute from draft to draft, we resolved to leave it as is, bring attention to the issue at last call, and revisit it then. I'm sorry you are not satisfied, but it is either you or Daniel Glazman. Best wishes, Steven Pemberton
FOLLOWUP 3:
Date: Wed, 8 Feb 2006 17:55:11 +0000 (UTC) From: Ian Hickson <ian@hixie.ch> On Wed, 8 Feb 2006, Steven Pemberton wrote: > Ian Hickson wrote: > > On Fri, 13 Jan 2006, Steven Pemberton wrote: > > > > XHTML2's "1.1.3. XHTML 2 and Presentation" section says: > > > > > > > > # XHTML 2 takes HTML back to these roots, by removing all presentation # > > > > elements, and subordinating all presentation to style sheets. > > > > > > > > This, while technically true, does not seem completely consistent with > > > > the inclusion of the style="" attribute (in section 27 XHTML Style > > > > Attribute Module). I feel that the intent of removing all presentational > > > > aspects from the language is to be applauded and would like to ask for > > > > the purely presentational style="" attribute to be removed. > > > > > > > > If it is to remain in XHTML2, however, a clear indication of its purpose > > > > should be given, so as to explain the conflict between its presence and > > > > the sentiment of section 1.1.3. > > > > > > The WG has decided to suspend this issue (ie decide whether to > > > include the style attribute or not) until after last call. > > > > Um, it would seem that this issue would have to be resolved _before_ > > last call, otherwise we could not make a complete review of the > > document during last call. Therefore this does not satisfy my request. > > Unfortunately, this is an issue where consensus hasn't been reached In that case, per W3C process, you will be unable to progress beyond last call. > Since we can't please both groups at once, since no new information has > come in, and since can't keep ping ponging the attribute from draft to > draft, we resolved to leave it as is, bring attention to the issue at > last call, and revisit it then. As you are no doubt aware, however, W3C process section 7.4.3, paragraph 7 sentence 2, and all of section 7.4.6, require you to go back to last call if you make any substantive changes. As you have pointed out, this is a big change. Therefore attempting to duck the issue until after last call seems like a false economy -- it will only force you to have _another_ last call. > I'm sorry you are not satisfied, but it is either you or Daniel Glazman. My request was not only to remove the style attribute. It was to either remove the style attribute, _or_, to make it clear that XHTML2 is not a purely non-presentational language, with prose explaining why. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
FOLLOWUP 4:
Date: Sat, 4 Feb 2006 02:22:14 +0000 (UTC) From: Ian Hickson <ian@hixie.ch> On Fri, 13 Jan 2006, Steven Pemberton wrote: > > > XHTML2's "1.1.3. XHTML 2 and Presentation" section says: > > > > # XHTML 2 takes HTML back to these roots, by removing all presentation > > # elements, and subordinating all presentation to style sheets. > > > > This, while technically true, does not seem completely consistent with the > > inclusion of the style="" attribute (in section 27 XHTML Style Attribute > > Module). I feel that the intent of removing all presentational aspects > > from the language is to be applauded and would like to ask for the purely > > presentational style="" attribute to be removed. > > > > If it is to remain in XHTML2, however, a clear indication of its purpose > > should be given, so as to explain the conflict between its presence and > > the sentiment of section 1.1.3. > > The WG has decided to suspend this issue (ie decide whether to include > the style attribute or not) until after last call. Um, it would seem that this issue would have to be resolved _before_ last call, otherwise we could not make a complete review of the document during last call. Therefore this does not satisfy my request. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
PROBLEM ID: 7663
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
The working group is not in favor or the definition of a "continueFrom" attribute that would allow continuation of list numbering, simply because there is no way to describe the behavior in current styling languages. However, there is a usecase for being able to define groups of list items and label them.... The working group is continuing to discuss this issue. To be *really* fair to the required structure in his use case ... you really want something like this: <ol> <group> <li>.. <li>... <li>... </group> <group> <label>... <li>... <li>... </group> </ol> The use case has two different structures imposed on top of each other A bit like <label for=""> in HTML4
ORIGINAL MESSAGE:
Date: Thu, 05 Aug 2004 15:46:25 +0900 (JST) From: Anne van Kesteren <fora@annevankesteren.nl> From: Anne van Kesteren <fora@annevankesteren.nl> To: www-html-editor@w3.org Subject: [XHTML2] 11.3. The ol , and ul elements Date: Wed, 04 Aug 2004 18:39:40 +0200 Message-ID: <4111114C.4040101@annevankesteren.nl> X-Archived-At: http://www.w3.org/mid/4111114C.4040101@annevankesteren.nl Can we get the START attribute back (I saw VALUE was added already)? Use case: <http://mpt.net.nz/archive/2004/02/16/os-x> -- Anne van Kesteren <http://annevankesteren.nl/>
FOLLOWUP 1:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> Date: Wed, 18 Aug 2004 14:59:12 +0200 > From: Anne van Kesteren <fora@annevankesteren.nl> > Can we get the START attribute back (I saw VALUE was added already)? Use > case: > > <http://mpt.net.nz/archive/2004/02/16/os-x> Hi, <ol start="21"> <li> can be written <ol> <li value="21"> Why do you need both? Best wishes, Steven Pemberton
FOLLOWUP 2:
Date: Wed, 18 Aug 2004 15:40:02 +0200 From: Anne van Kesteren <fora@annevankesteren.nl> >> Can we get the START attribute back (I saw VALUE was added already)? Use >> case: >> >> <http://mpt.net.nz/archive/2004/02/16/os-x> > > Hi, > > <ol start="21"> > <li> > > can be written > > <ol> > <li value="21"> > > Why do you need both? I thought about that later. Now I don't like either solution. Being able to define a relation between two lists would be much be better for structure. Something like: <h>...</h> <ol id="foo"> <li>...</li> <li>...</li> </ol> <h>...</h> <ol start="foo"> <li>...</li> </ol> Where the START attribute would be an IDREF. That way you can also update the first list without having to modify the VALUE attribute of the first LI element of the follow-up list. The VALUE attribute should still be kept of course for other purposes. Like skipping a number when an item was deleted (a comment on a weblog, for example). -- Anne van Kesteren <http://annevankesteren.nl/>
PROBLEM ID: 7869
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
ORIGINAL MESSAGE:
From: ddooss@wp.pl Date: Tue, 31 Jan 2006 16:00:36 -0600 (CST) Full_Name: Dominik "Domel" Tomaszuk Submission from: (NULL) (83.26.15.196) I think we should develop the link element. Example 1: <link rel="chapter" href="http://www.example.com/1"> <link rel="chapter" href="http://www.example.com/1.1" /> <link rel="chapter" href="http://www.example.com/1.2" /> <link rel="chapter" href="http://www.example.com/1.3"> <link rel="chapter" href="http://www.example.com/1.3.1"> </link> </link> It define "3-level" chapters. * 1 ** 1.1 ** 1.2 ** 1.3 *** 1.3.1 Now we can define only flat chapters. Example 2: <link rel="section" href="http://www.example.com/1"> <link rel="section" href="http://www.example.com/1.1" /> <link rel="section" href="http://www.example.com/1.2" /> <link rel="section" href="http://www.example.com/1.3"> <link rel="section" href="http://www.example.com/1.3.1"> </link> </link> Now we can define "2-level" sections - section and subsection. So we can remove subsection value. This solution is more structural (the same as h1,h2... vs. h, section. Best wishes, Dominik Tomaszuk
PROBLEM ID: 7873
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
Looking into the dc:created item. Fixed the dc:date item.
ORIGINAL MESSAGE:
Date: Wed, 22 Feb 2006 20:04:48 +0900 (JST) From: Freek Dijkstra <public@macfreek.nl> From: Freek Dijkstra <public@macfreek.nl> To: www-html-editor@w3.org Subject: XHTML 2: metaAttributes examples Date: Tue, 31 Jan 2006 18:06:36 +0100 Message-ID: <43DF991C.1060009@macfreek.nl> X-Archived-At: http://www.w3.org/mid/43DF991C.1060009@macfreek.nl To whom it may concern: On http://www.w3.org/TR/xhtml2/mod-metaAttributes.html there are a few examples that were confusing to me. 23.1. Metadata Attribute Collection A few examples in this section use the "dc:created" property. For example: <meta about="http://www.example.com/" property="dc:created">2004-03-20</meta> It seems implied that this is a valid property of the Dublic Core namespace, given the reference later to this namespace: <html .... xmlns:dc="http://purl.org/dc/elements/1.1/"> However, "created" is not defined in version 1.1 of the Dublin Core (as far as I can tell). It is mentioned at http://dublincore.org/documents/dcmi-terms/ though. A casual reader may be inclined to incorrectly assume he/she can use the dc:created property, while in fact it is undefined. I suggest to simply change the example. 23.3. Metadata as Content The example in this section lists (among other lines): <meta property="dc:date">March 23, 2004</meta> Though the dc:date spec does not formally specify the formatting of the content, it does recommend to follow the style as set forth in http://www.w3.org/TR/NOTE-datetime Again, a casual reader may be inclined to think that this is the recommended way of specifying dates. I recommend to change it to 2004-03-23. Kind regards, Freek Dijkstra
PROBLEM ID: 7868
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
ORIGINAL MESSAGE:
From: ddooss@wp.pl Date: Tue, 31 Jan 2006 15:24:05 -0600 (CST) Full_Name: Dominik "Domel" Tomaszuk Submission from: (NULL) (83.26.15.196) I think we should add to rel attribute new value enclosure. It would be refer to a resource serving as a potentially large in size (for example audio, video) and might require special handling.
PROBLEM ID: 7864
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
ORIGINAL MESSAGE:
From: Dominik@mn.aptest.com, Domel@mn.aptest.com, Date: Tue, 24 Jan 2006 10:51:15 -0600 (CST) Full_Name: Dominik "Domel" Tomaszuk Submission from: (NULL) (83.26.7.96) I think we should remove copyright value from rel attribute and replace it dc:rights [1]. The same as replace author to dc:creator. [1] http://dublincore.org/2003/03/24/dces#rights Best wishes, Dominik Tomaszuk
FOLLOWUP 1:
Date: Tue, 24 Jan 2006 10:51:50 -0600 (CST) From: MAILER-DAEMON@mn.aptest.com (Mail Delivery System) This is a MIME-encapsulated message. --06B407B6C6.1138121510/hades.mn.aptest.com Content-Description: Notification Content-Type: text/plain This is the Postfix program at host hades.mn.aptest.com. I'm sorry to have to inform you that your message could not be be delivered to one or more recipients. It's attached below. For further assistance, please send mail to <postmaster> If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program <Dominik@mn.aptest.com>: host atlas.mn.aptest.com[208.42.66.13] said: 550 5.1.1 <Dominik@mn.aptest.com>... User unknown (in reply to RCPT TO command) --06B407B6C6.1138121510/hades.mn.aptest.com Content-Description: Delivery report Content-Type: message/delivery-status Reporting-MTA: dns; hades.mn.aptest.com X-Postfix-Queue-ID: 06B407B6C6 X-Postfix-Sender: rfc822; xhtml2-issues@hades.mn.aptest.com Arrival-Date: Tue, 24 Jan 2006 10:51:50 -0600 (CST) Final-Recipient: rfc822; Dominik@mn.aptest.com Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host atlas.mn.aptest.com[208.42.66.13] said: 550 5.1.1 <Dominik@mn.aptest.com>... User unknown (in reply to RCPT TO command) --06B407B6C6.1138121510/hades.mn.aptest.com Content-Description: Undelivered Message Content-Type: message/rfc822 Received: from localhost (localhost [127.0.0.1]) by hades.mn.aptest.com (Postfix) with ESMTP id 06B407B6C6 for <Dominik@mn.aptest.com>; Tue, 24 Jan 2006 10:51:50 -0600 (CST) Received: from hades.mn.aptest.com ([127.0.0.1]) by localhost (hades.mn.aptest.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11101-04 for <Dominik@mn.aptest.com>; Tue, 24 Jan 2006 10:51:23 -0600 (CST) Received: by hades.mn.aptest.com (Postfix, from userid 589) id 3E0B57B6BB; Tue, 24 Jan 2006 10:51:22 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by hades.mn.aptest.com (Postfix) with ESMTP id 91B517B6CC for <Dominik@mn.aptest.com>; Tue, 24 Jan 2006 10:51:21 -0600 (CST) From: xhtml2-issues@hades.mn.aptest.com To: Dominik@mn.aptest.com, Subject: Re: remove copyright value from rel attribute (PR#7864) X-Loop: xhtml2-issues@hades.mn.aptest.com Message-Id: <20060124165121.91B517B6CC@hades.mn.aptest.com> Date: Tue, 24 Jan 2006 10:51:21 -0600 (CST) X-Virus-Scanned: by amavisd-new at mn.aptest.com Your issue has been added to the W3C's HTML Working Group Issue Tracking System. Please note that there is currently a backlog of issues being processed; your issue will be responded to as quickly as possible. If you have further information about this issue to report, please reply to this message so that the additional data can be automatically attached to the original query. If you would like to check on the status of this issue, select the following link: http://hades.mn.aptest.com/cgi-bin/xhtml2-issues?selectid=7864 This link will take you to a page that shows all the categories of problems tracked in the system. The category in which your problem report is held (initially called Incoming) will have the number "1" next to it, and all others will have the number "0". Select the link to the category to see your problem report, its status, any follow-up messqages, etc. If you would like to check on the other issues in the system, you can do so via the web at http://hades.mn.aptest.com/xhtml2-issues --06B407B6C6.1138121510/hades.mn.aptest.com--
PROBLEM ID: 8001
STATE: Suspended
EDIT: None
RESOLUTION: Accept
USER POSITION: None
NOTES:
There are two issues in here. As to machine discovery of vocabulary, the working group has resolved to tighten up the conformance requirement about discovery. This will be in the next working draft. As to priority of role values, the working group agrees that this is important, but is not part of the Role spec necessarily. The Role spec does not have normative behavioral requirements in it, and therefore does not have any requriement as to how a user agent might interpret the value(s) of the role attribute. This is a vocabulary issue, and the working group expects this will be resolved as part of future vocabulary work either by the XHTML 2 Working Group or by related activities such as ARIA.
ORIGINAL MESSAGE:
From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> Date: Fri, 17 Nov 2006 15:42:54 +0000 Hi This is a comment for "XHTML Role Attribute Module" http://www.w3.org/TR/2006/WD-xhtml-role-20061113 2006-11-13 Working Draft Re: > Note that current best practice is that the URI associated with that > namespace resolve to a resource that allows for the discovery of the > definition of the roles in the namespace. As I suggested back in September, http://lists.w3.org/Archives/Public/www-html/2006Sep/0030.html Surely it should be an *absolute and fundamental requirement* (not merely "best practice") for "the URI associated with" a role's namespace to "resolve to a resource that allows for the discovery of the definition of the roles in the namespace" so that user agents can always learn new roles? Re: > User agents, search engines, etc. may interpret these relationships in > a variety of ways If browsers are to learn new roles, should it not be an absolute requirement for role definitions to include machine-understandable suggestions on how to interpret and render such relationships, aurally and visually? Should it not also be an absolute requirement for role definitions to include a machine-understandable specification of whether the defined relationships are: 1. Of primary importance and must be obviously exposed to end-users (like ordinary hyperlinks). 2. Only of secondary importance, with access dependent on end-users requesting more information (like the TITLE attribute in HTML4). 3. Unimportant to end-users (like the CLASS attribute in HTML4). Should such styling and behaviours be entirely dependent on (potentially disabled) stylesheets and scripting, and does that conflict with accessibility requirements? This must be clarified. Bear in mind, when considering this question, the example of the radical difference in treatment by current browsers between the HREF attribute of LINK, the HREF attribute of A, and the under-appreciated CITE attribute of INS, DEL, Q, and BLOCKQUOTE in HTML 4.01. No rendering was suggested and no importance was specified for CITE, and it has been mostly ignored, undermining its potential to extend hypertext in interesting ways. (I'm cross-posting to the www-html list for discussion.) -- Benjamin Hawkes-Lewis
PROBLEM ID: 7830
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
ORIGINAL MESSAGE:
Date: Wed, 29 Jun 2005 09:49:16 -0400 From: Jim Jewett <jimjjewett@gmail.com> I just noticed Ian Hixie's XHTML2 issue at http://hades.mn.aptest.com/cgi-bin/xhtml2-issues/incoming?id=3D7820;user=3D= guest and realized that a very similar issue had been dismissed on the www-html list because outlines are only one use, and should be left up to the user agent. So I wanted to bring this back up, and point out that the real question is not presentational; it is how headers are linked to blocks. I've marked up parts of his example with more explicit questions. To summarize: Should <h> elements have a for attribute that says which section/block they describe? Should they instead always describe the nearest enclosing section/block? Should they instead always describe the nearest following section/block? Are the rules the same for <h> and <h#> elements? Detailed questions: <body> <h> AAA </h> # Does this header describe the body, or the next secti= on? # Or maybe even the implicit section of blocks before the # next section? <p> aaa </p> <h3> BBB </h3> # What about this one? Does it matter than this is an # h<number> instead of just an <h>?=20 Does it matter # that it is an h3 instead of an h1?=20 Even if skipping # levels is discouraged, I don't know whether it should # be h1 (first numbered header) or h2 (counting the h) <p> bbb </p> <h2> CCC </h2> # This header is right before a section. Previous=20 # examples have suggested that an <h> here would # apply to the following section.=20 Is that also true for # h<number> headers? <section> <h6> DDD </h6> # The other sensible choice is to always describe the # nearest enclosing section. But is an <h6> strong # enough for that, given than there is also an <h1> # in the same section? <p> ddd </p> <h1> EEE </h1> <ol> <li> eee </li> <li> <h> FFF </h> </li> # What does it mean if there are intervenin= g # elements between the section and the h? <li> fff </li> </ol> <blockquote> <p> fff </p> <h> GGG </h> # Is this header part of/describing the qu= ote,=20 # or the enclosing document? <p> ggg </p> </blockquote> <p> ggg </p> </section> <p> ccc </p> </body> -jJ
PROBLEM ID: 7874
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
ORIGINAL MESSAGE:
Date: Wed, 22 Feb 2006 20:53:38 +0900 (JST) From: Jim Jewett <jimjjewett@gmail.com> From: Jim Jewett <jimjjewett@gmail.com> To: www-html-editor@w3.org Cc: www-html@w3.org Subject: block@kind vs elt@structure Date: Thu, 2 Feb 2006 11:44:58 -0500 Message-ID: <fb6fbf560602020844n63ef6821w83ec24e5192027cb@mail.gmail.com> X-Archived-At: http://www.w3.org/mid/fb6fbf560602020844n63ef6821w83ec24e5192027cb@mail.gmail.com http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.10. lists block@kind as an open issue. I'm not sure anyone is entirely comfortable with the kind attribute representing the actual semantic value. How about adding a structure attribute, perhaps even to the core attributes? (What we really want is "conceptual size", but size *will* be used for styling.) Then, instead of <block kind=samp>... Users would write <samp structure=block>... If there are too many concerns about letting the content model depend on an attribute, then I would suggest adding a block element to the Text content set, so that people could write <samp><block><p>now you can use more than inline -- because it isn't a direct descendent of samp. </p></block></samp> -jJ
PROBLEM ID: 7820
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
ORIGINAL MESSAGE:
Date: Fri, 10 Jun 2005 00:16:15 +0000 (UTC) From: Ian Hickson <ian@hixie.ch> Hi, XHTML2 does not seem to define the semantics of the <h> and <hX> elements in enough detail to implement a user agent that intelligently displays sections. For example, I can't work out what the correct document outline should be for the following fragment: <body> <h> AAA </h> <p> aaa </p> <h3> BBB </h3> <p> bbb </p> <h2> CCC </h2> <section> <h6> DDD </h6> <p> ddd </p> <h1> EEE </h1> <ol> <li> eee </li> <li> <h> FFF </h> </li> <li> fff </li> </ol> <blockquote> <p> fff </p> <h> GGG </h> <p> ggg </p> </blockquote> <p> ggg </p> </section> <p> ccc </p> </body> I request that the XHTML2 specification include an algorithm that exactly defines how to obtain a document outline from a given XHTML2 document, so that user agents can interoperabily represent document outlines. Cheers, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
PROBLEM ID: 7878
STATE: Approved
EDIT: N/A
RESOLUTION: Accept
USER POSITION: None
NOTES:
Group agrees that the scope needs a better explanation.
ORIGINAL MESSAGE:
Date: Wed, 22 Feb 2006 20:59:34 +0900 (JST) From: Jim Jewett <jimjjewett@gmail.com> From: Jim Jewett <jimjjewett@gmail.com> To: www-html-editor@w3.org Cc: www-html@w3.org Subject: What is the scope of a header? Date: Thu, 2 Feb 2006 14:03:37 -0500 Message-ID: <fb6fbf560602021103x61525008la7e240f08f90b509@mail.gmail.com> X-Archived-At: http://www.w3.org/mid/fb6fbf560602021103x61525008la7e240f08f90b509@mail.gmail.com The example in http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.5. shows headers matched 1:1 with a following block element. Are the semantics defined if this pattern is not followed? For instance, does the following header cover all three paragraphs, or only the first one? <body> <h>This is a top level heading</h> <p>....</p> <p>...</p> <p>...</p> </body> If this is intentionally undefined, then please say so. If it covers only the first, that will surprise people. If it covers all three, then it effectively creates an anonymous div around the three paragraphs -- and I think that the header should really be a *child* of that div, rather than a sibling. We only want it as a sibling because the default presentation of "float it out ahead" is so strong. In other words, the semantics really should be written <body> <section><h>This is the sole heading for this section</h> <p>....</p> <p>...</p> <p>...</p> </section> </body> I assume the implicit div would end at the first of (1) the end of the container or (2) the next header of at least equal strength (and separators are too weak to end it), but ... maybe it would be better to just require the sectioning explicitly. -jJ
PROBLEM ID: 7870
STATE: Approved
EDIT: N/A
RESOLUTION: Accept
USER POSITION: None
NOTES:
The working group resolved at the f2f meeting in June 08 to remove this attribute and to permit the style element throughout the content model.
ORIGINAL MESSAGE:
Date: Thu, 9 Feb 2006 22:35:47 +0000 (UTC) From: Ian Hickson <ian@hixie.ch> On Wed, 8 Feb 2006, Epperson, Beth wrote: > > I would suggest that this be a response from the CSS WG. As a member of > the WG - Ian, I would suggest you bring this to the F2F where the CSS WG > come to an internal agreement as to whether the desire is to have the > attribute removed or retained. Once the CSS WG has a decision, then > request a joint meeting where both WG's can discuss and finally agree > and be done with this discussion. But wait - we already did that 2 or 3 > years ago - hence it is in the spec. In that case, as I said in my original request: > > > > > XHTML2's "1.1.3. XHTML 2 and Presentation" section says: > > > > > > > > > > # XHTML 2 takes HTML back to these roots, by removing all presentation > > > > > # elements, and subordinating all presentation to style sheets. > > > > > > > > > > This, while technically true, does not seem completely > > > > > consistent with the inclusion of the style="" attribute (in > > > > > section 27 XHTML Style Attribute Module). I feel that the intent > > > > > of removing all presentational aspects from the language is to > > > > > be applauded and would like to ask for the purely presentational > > > > > style="" attribute to be removed. > > > > > > > > > > If it is to remain in XHTML2, however, a clear indication of its > > > > > purpose should be given, so as to explain the conflict between > > > > > its presence and the sentiment of section 1.1.3. What I am asking for is for EITHER: A. The "style" attribute to be removed, to be consistent with the sentiment in section 1.1.3, OR: B. The text in section 1.1.3 to explain why it is considered ok to have presentational attributes but not presentational elements. That's all I'm asking for. It should not be difficult to do option B, if there really is a good reason not to do option A. Just say what the reason is in section 1.1.3. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
PROBLEM ID: 7871
STATE: Approved
EDIT: N/A
RESOLUTION: Reject
USER POSITION: None
NOTES:
We are removing the style attribute, but we are ensuring that it is possible to embed style definitions via the style element or the link element anywhere in your document.
ORIGINAL MESSAGE:
Date: Thu, 09 Feb 2006 15:01:46 -0800 From: Garret Wilson <garret@globalmentor.com> At first, Ian's request seems perfectly reasonable, and succinctly put. Upon closer examination, there is not such a tension between the text of 1.1.3 and the presence of the style attribute, any more than there is a tension between the text of 1.1.3 and the <style> element. Although section 1.1.3. does indicate that XHTML 2 is "removing all presentation elements", the style attribute is not a presentation element. It's not even a presentation attribute, in the sense that "fontSize" or "lineSpacing" would be presentation attributes. In other words, the style attribute's *value* contains stylesheet information bound to a single element, much in the same way that the <style> element's textual content contains stylesheet information mapped to individual elements within the document. Presentation attributes, in my opinion, would be those in which the attribute name represented a style predicate, with the attribute value representing the value of that style predicate. The style attribute, on the other hand, contains a value that consists of many presentation predicates and their values. The style attribute is no more than locally-bound information transferred from the <style> element; hence it is consistent with the stated goal of 1.1.3 of "subordinating all presentation to style sheets", as the style attribute content is really a mini-stylesheet. Ian does not seem to be making the same request regarding the <style> element, and as such his request would seem more inconsistent than the tension between 1.1.3 and the presence of the style attribute. On the other hand, this question is likely to come up more in the future, and the working group ignores it now at their peril---putting text in the recommendation would be preemptive against answer the question again and again after the document is finalized. Lastly, I'd like to personally express my desire to retain the style attribute. With newer AJAX applications, it is many times extremely useful, if not necessary, to send style information to a browser for small updated within a document. The lack of a style attribute would mean that dynamically updating the style of a single element within a document would require somehow modifying an external stylesheet or the internal stylesheet in the document's <head>. Garret Ian Hickson wrote: > On Wed, 8 Feb 2006, Epperson, Beth wrote: > >> I would suggest that this be a response from the CSS WG. As a member of >> the WG - Ian, I would suggest you bring this to the F2F where the CSS WG >> come to an internal agreement as to whether the desire is to have the >> attribute removed or retained. Once the CSS WG has a decision, then >> request a joint meeting where both WG's can discuss and finally agree >> and be done with this discussion. But wait - we already did that 2 or 3 >> years ago - hence it is in the spec. >> > > In that case, as I said in my original request: > > >>>>>> XHTML2's "1.1.3. XHTML 2 and Presentation" section says: >>>>>> >>>>>> # XHTML 2 takes HTML back to these roots, by removing all presentation >>>>>> # elements, and subordinating all presentation to style sheets. >>>>>> >>>>>> This, while technically true, does not seem completely >>>>>> consistent with the inclusion of the style="" attribute (in >>>>>> section 27 XHTML Style Attribute Module). I feel that the intent >>>>>> of removing all presentational aspects from the language is to >>>>>> be applauded and would like to ask for the purely presentational >>>>>> style="" attribute to be removed. >>>>>> >>>>>> If it is to remain in XHTML2, however, a clear indication of its >>>>>> purpose should be given, so as to explain the conflict between >>>>>> its presence and the sentiment of section 1.1.3. >>>>>> > > What I am asking for is for EITHER: > > A. The "style" attribute to be removed, to be consistent with the > sentiment in section 1.1.3, > > OR: > > B. The text in section 1.1.3 to explain why it is considered ok to have > presentational attributes but not presentational elements. > > That's all I'm asking for. It should not be difficult to do option B, if > there really is a good reason not to do option A. Just say what the reason > is in section 1.1.3. > >
PROBLEM ID: 7881
STATE: Feedback
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
While there are notional "rowgroups" there are no explicit arbitrary rowgroups in HTML nor in XHTML because rows are explicit in tables. colgroups, on the other hand, exist because HTML / XHTML needs a way of referring to columns. Asked the submitter for more information and an example including a description of what the advantages would be.
ORIGINAL MESSAGE:
Date: Wed, 22 Feb 2006 20:51:29 +0900 (JST) From: Jim Jewett <jimjjewett@gmail.com> From: Jim Jewett <jimjjewett@gmail.com> To: www-html-editor@w3.org Subject: nesting colgroup and rowgroups Date: Thu, 2 Feb 2006 11:32:49 -0500 Message-ID: <fb6fbf560602020832j6542395eo2e45aa905556538e@mail.gmail.com> X-Archived-At: http://www.w3.org/mid/fb6fbf560602020832j6542395eo2e45aa905556538e@mail.gmail.com The colgroup example discusses grouping permanent and local contact information separately. Even within these groupings, there may be subgroupings, such as physical address vs phone number. I would prefer that a colgroup could contain other colgroups (and a rowgroup other rowgroups). If this has been rejected, I would like to see at least a brief summary of the reasoning behind the limit in that section of the spec.
FOLLOWUP 1:
Date: Wed, 05 Apr 2006 13:31:16 -0500 From: Shane McCarron <shane@aptest.com> Yes - tbody, thead, and tfoot are implicit row groups - and are discussed as such in HTML 4. However, there is no way to explicitly create arbitrary rowgroup collections other than these, which have fairly hard-coded semantics. At least, I think they do. Anne van Kesteren wrote: > > On Wed, 05 Apr 2006 16:52:13 +0200, Shane McCarron > <xhtml2-issues@mn.aptest.com> wrote: >> While there are notional "rowgroups" there are no explicit arbitrary >> rowgroups in HTML nor in XHTML because rows are explicit in tables. > > Euh, isn't <tbody> used for grouping rows? > > > --Anne van Kesteren > <http://annevankesteren.nl/> > <http://www.opera.com/> > -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
FOLLOWUP 2:
Date: Thu, 06 Apr 2006 00:08:12 +0200 From: "Anne van Kesteren" <annevk@opera.com> On Wed, 05 Apr 2006 20:31:16 +0200, Shane McCarron <shane@aptest.com> wrote: > Yes - tbody, thead, and tfoot are implicit row groups - and are > discussed as such in HTML 4. However, there is no way to explicitly > create arbitrary rowgroup collections other than these, which have > fairly hard-coded semantics. At least, I think they do. Given that you can have multiple <tbody> elements I think that's a pretty arbitrary way to group rows. When such a group of rows happens to be a footer or header you use <tfoot> and <thead> instead... -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
FOLLOWUP 3:
Date: Wed, 05 Apr 2006 17:14:41 +0200 From: "Anne van Kesteren" <annevk@opera.com> On Wed, 05 Apr 2006 16:52:13 +0200, Shane McCarron <xhtml2-issues@mn.aptest.com> wrote: > While there are notional "rowgroups" there are no explicit arbitrary > rowgroups in HTML nor in XHTML because rows are explicit in tables. Euh, isn't <tbody> used for grouping rows? -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
FOLLOWUP 4:
Date: Wed, 5 Apr 2006 16:41:22 -0400 From: "Jim Jewett" <jimjjewett@gmail.com> On 4/5/06, Shane McCarron <xhtml2-issues@mn.aptest.com> wrote: > While there are notional "rowgroups" there are no explicit arbitrary rowgroups > in HTML nor in XHTML because rows are explicit in tables. colgroups, on the > other hand, exist because HTML / XHTML needs a way of referring to columns. > > Could you please provide a concrete example of what you are looking for, along > with a description of what the advantages would be? rowgroup: Some of the tables I generate now have a multidimensional key, like SystemA PartA LocationA data .... SystemA PartA LocationB data ... SystemA PartB LocationX data ... SystemB PartC LocationY data At the moment, I can (ignoring browser bugs) treat SystemA and System B as separate rowgroups by placing multiple tbody elements in a single table. Alternatively, I could group SystemA-PartA. I would like to group System A, and also group PartA within that group. Users often want to focus on (or exclude) certain sections. Workarounds I have seen include (1) mangling the key name into a CSS class and toggling visibility with javascript (redundant and ugly) (2) requiring users to pick columns and rows in advance and submit again if they change their minds (slow and inefficient). colgroup: Often, the data groups naturally into subobjects, and I would like to group them. The example already suggests an Address grouping, which may be repeated for Permanent Address and Temporary Address. I would like to extend this to additional levels. With the address, I would like the sub-colgroup "mailing address" to include street address, city, state, and zip, but not to include phone number. The workarounds I usually see are to either concatenate columns that are logically distinct (possibly with font tags to redistinguish them), or to spread them out so they take a disproportionate share of the visual display. -jJ > > From: Jim Jewett <jimjjewett@gmail.com> > > To: www-html-editor@w3.org > > Subject: nesting colgroup and rowgroups > > Date: Thu, 2 Feb 2006 11:32:49 -0500 > > Message-ID: <fb6fbf560602020832j6542395eo2e45aa905556538e@mail.gmail.com> > > X-Archived-At: http://www.w3.org/mid/fb6fbf560602020832j6542395eo2e45aa905556538e@mail.gmail.com > > > > The colgroup example discusses grouping permanent and local contact > > information separately. Even within these groupings, there may be > > subgroupings, such as physical address vs phone number. > > > > I would prefer that a colgroup could contain other colgroups (and a > > rowgroup other rowgroups). If this has been rejected, I would like to > > see at least a brief summary of the reasoning behind the limit in that > > section of the spec. > > > > >
PROBLEM ID: 7828
STATE: Feedback
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
We have reviewed this request, but don't understand how the additional markup supports the use case. What problem are you trying to solve exactly?
ORIGINAL MESSAGE:
Date: Wed, 29 Jun 2005 16:47:17 +0900 (JST) From: Jim Jewett <jimjjewett@gmail.com> From: Jim Jewett <jimjjewett@gmail.com> To: www-html-editor@w3.org Subject: Why no nested colgroup or rowgroup? Date: Fri, 17 Jun 2005 15:32:21 -0400 Message-ID: <fb6fbf5605061712321df45f58@mail.gmail.com> X-Archived-At: http://www.w3.org/mid/fb6fbf5605061712321df45f58@mail.gmail.com It is fairly common to sort tabular data by multiple columns -- implicitly creating nested rowgroups. Neither colgroup nor any of the rowgroup instantiations (tbody, thead, tfoot) can nest. In the past, this was needed for backwards compatibility -- colgroup elements were implicitly closed by the next colgroup. In XHTML 2.0, all elements will have closing tags, so it is possible to distinguish a nested colgroup from an adjacent one. Given this, I believe nested colgroups and (rowgroups) should be permitted. -jJ
PROBLEM ID: 674
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: None
NOTES:
BAE F2F: accepted the idea, but have not crafted a resolution. Decided to use a parameter on the media type. HCG is going to discuss and make a recommendation as to what parameter to use.
ORIGINAL MESSAGE:
Date: Wed, 20 Mar 2002 17:53:18 +0900 (JST) From: Masayasu Ishikawa <mimasa@w3.org> As we have decided to use a different namespace for XHTML 2.0, an issue comes up whether we could use 'application/xhtml+xml' for XHTML 2.0 or not. At the moment I'm not quite sure whether RFC 3236 allows to serve a document whose namespace is not XHTML (1.x) as 'application/xhtml+xml'. "Interoperability considerations:" in "2. Registration of MIME media type application/xhtml+xml" of RFC 3236 says as follows: XHTML 1.0 [XHTML10] specifies user agent conformance rules that dictate behaviour that must be followed when dealing with, among other things, unrecognized elements. With respect to XHTML Modularization [XHTMLMOD] and the existence of XHTML based languages (referred to as XHTML family members) that are not XHTML 1.0 conformant languages, it is possible that 'application/xhtml+xml' may be used to describe some of these documents. However, it should suffice for now for the purposes of interoperability that user agents accepting 'application/xhtml+xml' content use the user agent conformance rules in [XHTML1]. Although conformant 'application/xhtml+xml' interpreters can expect that content received is well-formed XML (as defined in [XML]), it cannot be guaranteed that the content is valid XHTML (as defined in [XHTML1]). This is in large part due to the reasons in the preceding paragraph. This part doesn't explicitly mention namespaces, but the second paragraph seems to imply that some XHTML Family members that do include elements and attributes from other namespaces could still use 'application/xhtml+xml', though, it is clear that following (at least some part of) the user agent conformance rules in XHTML 1.0 is not a desirable behavior for XHTML 2.0 user agents or generic XML user agents. On the other hand, "5. Recognizing XHTML files" notes as follows: All XHTML documents will have the string "<html" near the beginning of the document. Some will also begin with an XML declaration which begins with "<?xml", though that alone does not indicate an XHTML document. All conforming XHTML 1.0 documents will include an XML document type declaration with the root element type 'html'. XHTML Modularization provides a naming convention by which a public identifier for an external subset in the document type declaration of a conforming document will contain the string "//DTD XHTML". And while some XHTML based languages require the doctype declaration to occur within documents of that type, such as XHTML 1.0, or XHTML Basic (http://www.w3.org/TR/xhtml-basic), it is not the case that all XHTML based languages will include it. All XHTML files should also include a declaration of the XHTML namespace. This should appear shortly after the string "<html", and should read 'xmlns="http://www.w3.org/1999/xhtml"'. In the last paragraph, the "XHTML namespace" (URI) is mentioned as "http://www.w3.org/1999/xhtml". Does that mean XHTML 2.0 documents SHOULD not be recognized as "XHTML" documents when it is served as 'application/xhtml+xml'? Well, the answer would differ what do you think is "XHTML" here. Is XHTML 2.0 an "XHTML"? Anyway, my impression is that RFC 3236 is intentionally or unintentionally vague to what extent 'application/xhtml+xml' could be used. Some possible approach would include: 1. Just use 'application/xhtml+xml' 2. Use 'application/xhtml+xml', and a profile parameter to identify XHTML 2.0 3. Just use 'application/xml' 4. Use 'application/xml', and hope that the 'xmlns' media feature tag I-D would become an RFC 5. Update RFC 3236 so that XHTML 2.0 can also use 'application/xhtml+xml' 6. Register a yet another media type?? Your opinion is much appreciated. Regards, -- Masayasu Ishikawa / mimasa@w3.org W3C - World Wide Web Consortium
FOLLOWUP 1:
Date: Fri, 22 Mar 2002 15:51:34 +0100 From: "Stark, Peter N" <Peter.N.Stark@sonyericsson.com> I would like to clarify my previous post and also add some more comment. In order of preference, I think we have the following options for XHTML 2.0 MIME type: 1. 'application/xhtml+xml', with optional profile parameter. I consider this to be the 'text/html' for XHTML. In the HTTP request it is useful to advertise support for XHTML. In the HTTP response it is useful to dispatch the document to the XHTML UA instead of the HTML UA (different parsers). 2. New MIME type for XHTML 2.0. Takes time but would remove the need for the 'profile' parameter. It is an explicit way to indicate XHTML 2.0 support, good for content negotiation. 3. 'application/xml' The BIG problem with is that it is too general, it does not say anything. With 'application/xhtml+xml' at least you know it is an XHTML document. IF the xmlns feature tag [1] becomes accepted by the industry, used by Web servers, then the 'application/xml' media type may be useful - in the future. In the above, I avoid the issue of what MIME types mean for mixed documents such as XHTML+SVG, a problem I don't think the HTML WG should not try to solve, it is for TAG. [1] http://search.ietf.org/internet-drafts/draft-stlaurent-feature-xmlns-02.txt -- Peter.N.Stark @SonyEricsson.com > -----Original Message----- > From: Stark, Peter N > Sent: den 20 mars 2002 13:11 > To: mimasa@w3.org; w3c-html-wg@w3.org > Cc: voyager-issues@mn.aptest.com > Subject: RE: Can we use 'application/xhtml+xml' for XHTML > 2.0? (PR#674) > > > I think "application/xhtml+xml" should be used also for XHTML 2.0, > with a recommendation to also use the profile parameter. > > I also think that we should NOT use another namespace name > for XHTML 2.0 than the one we use for XHTML 1.x, > "http://www.w3.org/1999/xhtml". New XHTML 2.0 elements can be > added to the existing namespace. There is not a need for a > new namespace. > > > -- > Peter.N.Stark > @SonyEricsson.com > > > > -----Original Message----- > > From: mimasa@w3.org [mailto:mimasa@w3.org] > > Sent: den 20 mars 2002 09:53 > > To: w3c-html-wg@w3.org > > Cc: voyager-issues@mn.aptest.com > > Subject: Can we use 'application/xhtml+xml' for XHTML 2.0? (PR#674) > > > > > > As we have decided to use a different namespace for XHTML 2.0, > > an issue comes up whether we could use 'application/xhtml+xml' > > for XHTML 2.0 or not. At the moment I'm not quite sure whether > > RFC 3236 allows to serve a document whose namespace is not > > XHTML (1.x) as 'application/xhtml+xml'. > > > > "Interoperability considerations:" in "2. Registration of MIME > > media type application/xhtml+xml" of RFC 3236 says as follows: > > > > XHTML 1.0 [XHTML10] specifies user agent conformance > rules that > > dictate behaviour that must be followed when dealing > with, among > > other things, unrecognized elements. > > > > With respect to XHTML Modularization [XHTMLMOD] and the > > existence > > of XHTML based languages (referred to as XHTML family members) > > that are not XHTML 1.0 conformant languages, it is > possible that > > 'application/xhtml+xml' may be used to describe some of these > > documents. However, it should suffice for now for the > > purposes of > > interoperability that user agents accepting > > 'application/xhtml+xml' content use the user agent conformance > > rules in [XHTML1]. > > > > Although conformant 'application/xhtml+xml' interpreters can > > expect that content received is well-formed XML (as defined in > > [XML]), it cannot be guaranteed that the content is > valid XHTML > > (as defined in [XHTML1]). This is in large part due to the > > reasons in the preceding paragraph. > > > > This part doesn't explicitly mention namespaces, but the second > > paragraph seems to imply that some XHTML Family members that do > > include elements and attributes from other namespaces could still > > use 'application/xhtml+xml', though, it is clear that following > > (at least some part of) the user agent conformance rules in > XHTML 1.0 > > is not a desirable behavior for XHTML 2.0 user agents or generic > > XML user agents. > > > > On the other hand, "5. Recognizing XHTML files" notes as follows: > > > > All XHTML documents will have the string "<html" near > the beginning > > of the document. Some will also begin with an XML > > declaration which > > begins with "<?xml", though that alone does not indicate an XHTML > > document. All conforming XHTML 1.0 documents will include an XML > > document type declaration with the root element type 'html'. > > > > XHTML Modularization provides a naming convention by > which a public > > identifier for an external subset in the document type > > declaration of > > a conforming document will contain the string "//DTD XHTML". And > > while some XHTML based languages require the doctype > declaration to > > occur within documents of that type, such as XHTML 1.0, or XHTML > > Basic (http://www.w3.org/TR/xhtml-basic), it is not the > > case that all > > XHTML based languages will include it. > > > > All XHTML files should also include a declaration of the XHTML > > namespace. This should appear shortly after the string > > "<html", and > > should read 'xmlns="http://www.w3.org/1999/xhtml"'. > > > > In the last paragraph, the "XHTML namespace" (URI) is mentioned as > > "http://www.w3.org/1999/xhtml". Does that mean XHTML 2.0 documents > > SHOULD not be recognized as "XHTML" documents when it is served as > > 'application/xhtml+xml'? Well, the answer would differ what do you > > think is "XHTML" here. Is XHTML 2.0 an "XHTML"? > > > > Anyway, my impression is that RFC 3236 is intentionally or > > unintentionally vague to what extent 'application/xhtml+xml' > > could be used. Some possible approach would include: > > > > 1. Just use 'application/xhtml+xml' > > 2. Use 'application/xhtml+xml', and a profile parameter > to identify > > XHTML 2.0 > > 3. Just use 'application/xml' > > 4. Use 'application/xml', and hope that the 'xmlns' media > > feature tag > > I-D would become an RFC > > 5. Update RFC 3236 so that XHTML 2.0 can also use > > 'application/xhtml+xml' > > 6. Register a yet another media type?? > > > > Your opinion is much appreciated. > > > > Regards, > > -- > > Masayasu Ishikawa / mimasa@w3.org > > W3C - World Wide Web Consortium > > > > > >
FOLLOWUP 2:
Date: Wed, 20 Mar 2002 13:11:17 +0100 From: "Stark, Peter N" <Peter.N.Stark@sonyericsson.com> I think "application/xhtml+xml" should be used also for XHTML 2.0, with a recommendation to also use the profile parameter. I also think that we should NOT use another namespace name for XHTML 2.0 than the one we use for XHTML 1.x, "http://www.w3.org/1999/xhtml". New XHTML 2.0 elements can be added to the existing namespace. There is not a need for a new namespace. -- Peter.N.Stark @SonyEricsson.com > -----Original Message----- > From: mimasa@w3.org [mailto:mimasa@w3.org] > Sent: den 20 mars 2002 09:53 > To: w3c-html-wg@w3.org > Cc: voyager-issues@mn.aptest.com > Subject: Can we use 'application/xhtml+xml' for XHTML 2.0? (PR#674) > > > As we have decided to use a different namespace for XHTML 2.0, > an issue comes up whether we could use 'application/xhtml+xml' > for XHTML 2.0 or not. At the moment I'm not quite sure whether > RFC 3236 allows to serve a document whose namespace is not > XHTML (1.x) as 'application/xhtml+xml'. > > "Interoperability considerations:" in "2. Registration of MIME > media type application/xhtml+xml" of RFC 3236 says as follows: > > XHTML 1.0 [XHTML10] specifies user agent conformance rules that > dictate behaviour that must be followed when dealing with, among > other things, unrecognized elements. > > With respect to XHTML Modularization [XHTMLMOD] and the > existence > of XHTML based languages (referred to as XHTML family members) > that are not XHTML 1.0 conformant languages, it is possible that > 'application/xhtml+xml' may be used to describe some of these > documents. However, it should suffice for now for the > purposes of > interoperability that user agents accepting > 'application/xhtml+xml' content use the user agent conformance > rules in [XHTML1]. > > Although conformant 'application/xhtml+xml' interpreters can > expect that content received is well-formed XML (as defined in > [XML]), it cannot be guaranteed that the content is valid XHTML > (as defined in [XHTML1]). This is in large part due to the > reasons in the preceding paragraph. > > This part doesn't explicitly mention namespaces, but the second > paragraph seems to imply that some XHTML Family members that do > include elements and attributes from other namespaces could still > use 'application/xhtml+xml', though, it is clear that following > (at least some part of) the user agent conformance rules in XHTML 1.0 > is not a desirable behavior for XHTML 2.0 user agents or generic > XML user agents. > > On the other hand, "5. Recognizing XHTML files" notes as follows: > > All XHTML documents will have the string "<html" near the beginning > of the document. Some will also begin with an XML > declaration which > begins with "<?xml", though that alone does not indicate an XHTML > document. All conforming XHTML 1.0 documents will include an XML > document type declaration with the root element type 'html'. > > XHTML Modularization provides a naming convention by which a public > identifier for an external subset in the document type > declaration of > a conforming document will contain the string "//DTD XHTML". And > while some XHTML based languages require the doctype declaration to > occur within documents of that type, such as XHTML 1.0, or XHTML > Basic (http://www.w3.org/TR/xhtml-basic), it is not the > case that all > XHTML based languages will include it. > > All XHTML files should also include a declaration of the XHTML > namespace. This should appear shortly after the string > "<html", and > should read 'xmlns="http://www.w3.org/1999/xhtml"'. > > In the last paragraph, the "XHTML namespace" (URI) is mentioned as > "http://www.w3.org/1999/xhtml". Does that mean XHTML 2.0 documents > SHOULD not be recognized as "XHTML" documents when it is served as > 'application/xhtml+xml'? Well, the answer would differ what do you > think is "XHTML" here. Is XHTML 2.0 an "XHTML"? > > Anyway, my impression is that RFC 3236 is intentionally or > unintentionally vague to what extent 'application/xhtml+xml' > could be used. Some possible approach would include: > > 1. Just use 'application/xhtml+xml' > 2. Use 'application/xhtml+xml', and a profile parameter to identify > XHTML 2.0 > 3. Just use 'application/xml' > 4. Use 'application/xml', and hope that the 'xmlns' media > feature tag > I-D would become an RFC > 5. Update RFC 3236 so that XHTML 2.0 can also use > 'application/xhtml+xml' > 6. Register a yet another media type?? > > Your opinion is much appreciated. > > Regards, > -- > Masayasu Ishikawa / mimasa@w3.org > W3C - World Wide Web Consortium > >
FOLLOWUP 3:
Date: Thu, 21 Mar 2002 18:13:51 -0800 (GMT-08:00) From: "SUBRAMANIAN.PERUVEMBA (PV)" <SUBRAMANIAN.PERUVEMBA@oracle.com> If "application/xhtml+xml" is re-used then the CGI programs will have no clue about the version of XHTML the browser supports, esp. XHTML 2.0 is not intended to be backward compatible. PV > > As we have decided to use a different namespace for XHTML 2.0, > an issue comes up whether we could use 'application/xhtml+xml' > for XHTML 2.0 or not. At the moment I'm not quite sure whether > RFC 3236 allows to serve a document whose namespace is not > XHTML (1.x) as 'application/xhtml+xml'. > > "Interoperability considerations:" in "2. Registration of MIME > media type application/xhtml+xml" of RFC 3236 says as follows: > > XHTML 1.0 [XHTML10] specifies user agent conformance rules that > dictate behaviour that must be followed when dealing with, > among other things, unrecognized elements. > > With respect to XHTML Modularization [XHTMLMOD] and the > existence of XHTML based languages (referred to as XHTML family > members) that are not XHTML 1.0 conformant languages, it is > possible that 'application/xhtml+xml' may be used to describe > some of these documents. However, it should suffice for now > for the purposes of interoperability that user agents accepting > 'application/xhtml+xml' content use the user agent conformance > rules in [XHTML1]. > > Although conformant 'application/xhtml+xml' interpreters can > expect that content received is well-formed XML (as defined in > [XML]), it cannot be guaranteed that the content is valid XHTML > (as defined in [XHTML1]). This is in large part due to the > reasons in the preceding paragraph. > > This part doesn't explicitly mention namespaces, but the second > paragraph seems to imply that some XHTML Family members that do > include elements and attributes from other namespaces could still > use 'application/xhtml+xml', though, it is clear that following > (at least some part of) the user agent conformance rules in XHTML > 1.0 is not a desirable behavior for XHTML 2.0 user agents or generic > XML user agents. > > On the other hand, "5. Recognizing XHTML files" notes as follows: > > All XHTML documents will have the string "<Masayasu Ishikawa / > mimasa@w3.org>
FOLLOWUP 4:
Date: Wed, 20 Mar 2002 22:02:23 +0900 (JST) From: Masayasu Ishikawa <mimasa@w3.org> mimasa@w3.org wrote: > Anyway, my impression is that RFC 3236 is intentionally or > unintentionally vague to what extent 'application/xhtml+xml' > could be used. Some possible approach would include: > > 1. Just use 'application/xhtml+xml' > 2. Use 'application/xhtml+xml', and a profile parameter to identify > XHTML 2.0 > 3. Just use 'application/xml' > 4. Use 'application/xml', and hope that the 'xmlns' media feature tag > I-D would become an RFC > 5. Update RFC 3236 so that XHTML 2.0 can also use 'application/xhtml+xml' > 6. Register a yet another media type?? Some test results, for your information. I prepared an XHTML+MathML+SVG document and an old XHTML 2.0 prototype (which doesn't declare any namespace for test purpose), both served as 'application/xhtml+xml' and 'text/xml'. XHTML+MathML+SVG document: application/xhtml+xml http://www.w3.org/People/mimasa/test/schemas/xhtml-math-svg-sample.xhtml text/xml http://www.w3.org/People/mimasa/test/schemas/xhtml-math-svg-sample.xml Old XHTML 2.0 prototype: application/xhtml+xml http://www.w3.org/People/mimasa/test/schemas/DTD/dev/xhtml2-xlink.xhtml text/xml http://www.w3.org/People/mimasa/test/schemas/DTD/dev/xhtml2-xlink.xml For browsers that support 'application/xhtml+xml', it seems 'application/xhtml+xml' or 'text/xml' (and I presume that's the case for 'application/xhtml+xml' as well) doesn't matter. Both SVG-enabled Mozilla and Amaya worked fine with an XHTML+ MathML+SVG document, served as 'application/xhtml+xml' and 'text/xml'. Mozilla worked fine with an old XHTML 2.0 prototype, both 'application/xhtml+xml' and 'text/xml'. Opera behave the same way for both documents (Opera doesn't understand XLink, but rendered the document nicely). I don't know how these browsers treat 'application/xhtml+xml' internally, but looks like it's just an alias of 'application/xml'. In which case, we could use 'application/xhtml+xml' just like 'application/xml'. So long as we make XHTML 2.0 as generic as possible, I suspect it won't cause much problem. Regards, -- Masayasu Ishikawa / mimasa@w3.org W3C - World Wide Web Consortium
FOLLOWUP 5:
Date: Fri, 22 Mar 2002 13:39:04 +0900 (JST) From: Masayasu Ishikawa <mimasa@w3.org> "SUBRAMANIAN.PERUVEMBA (PV)" <SUBRAMANIAN.PERUVEMBA@oracle.com> wrote: > If "application/xhtml+xml" is re-used then the CGI programs will have no clue about the version of XHTML the browser supports, esp. XHTML 2.0 is not intended to be backward compatible. Note that RFC 3236 doesn't mention at all that a resource served as 'application/xhtml+xml' will be backward compatible (with what?). The 'profile' parameter is there to provide some clue about the version of XHTML. Regards, -- Masayasu Ishikawa / mimasa@w3.org W3C - World Wide Web Consortium
PROBLEM ID: 7729
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: None
NOTES:
Defered because CSS3 is not in the right state.
ORIGINAL MESSAGE:
From: ddooss@wp.pl Date: Sat, 28 May 2005 09:29:12 -0500 (CDT) Full_Name: Dominik "Domel" Tomaszuk Submission from: (NULL) (81.15.254.50) I think that we should change possible value of media attribute and hrefmedia attribute to MediaDesc support CSS3 (not CSS2) http://www.w3.org/TR/2002/CR-css3-mediaqueries-20020708 (now in CR). Also add Media Queries to References.
PROBLEM ID: 7659
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
NOTES:
This issue needs to be broken into individual issues.
ORIGINAL MESSAGE:
Date: Thu, 29 Jul 2004 21:43:54 +0900 (JST) From: Anne van Kesteren <fora@annevankesteren.nl> From: Anne van Kesteren <fora@annevankesteren.nl> To: www-html-editor@w3.org Subject: [XHTML2] Some comments Date: Thu, 29 Jul 2004 14:12:16 +0200 Message-ID: <4108E9A0.80704@annevankesteren.nl> X-Archived-At: http://www.w3.org/mid/4108E9A0.80704@annevankesteren.nl Comments on the Working Draft of 22 July 2004[1] 1.1.1. Design Aims # As generic XML as possible: if a facility exists in XML, try to use # that rather than duplicating it. If that is true, why are several elements imported from XHTML 1.1? For example: CODE, VAR, BLOCKQUOTE et cetera. 1.1.2. Backwards compatibility # Much of XHTML 2 works already in existing browsers; This is not true. Even in Mozilla I would have to include the default style sheet in order to make it work as described. And if XHTML 2.0 will get a new mime type, like 'application/xhtml-2+xml' user agents would ask to download it instead. 1.2. Major Differences with XHTML 1 I think that BR can still serve a useful purpose, when you don't want to split text in lines, but just use a line-break. Example: <p>John,<br/> ...</p> "John" is not a separate "line of text". I actually think L is presentational, although in some rare cases I never encountered it can probably add some semantics. 8.1. The address element There are a lot of use cases where it would be nice if this could be an inline element as well. As in having both BLOCKADDRESS and ADDRESS. Having more elements allowed within (BLOCK)ADDRESS, such as headings and paragraph is a good thing for more detailed contact information imo. 8.4. The div element It looks like DIV elements were used for presentation in the example. Aren't they just marking up sections of the document? (So remove that example, since there is SECTION element already.) Also, in the same example a P element is used: # <p>By Huntington B. Snark</p> Should I call tag abuse? ;-) 8.5. The heading elements It is confusing that there are two types of headings. Is there an example were there is need for both? Also, is the following considered bad practice: <section> <h>...</h> <section> <h1>...</h1> </section> </section> Could the draft clarify that? And how they should interact with each other? 8.6. The p element In the example here, both PCDATA and block level elements are mixed. This looks really bad and just asks for markup abuse once released to the public. 8.7. The pre element The example is a quote, why is PRE used? And not BLOCKQUOTE with the style rule mentioned in the description? 8.8. The section element The example given here is almost exactly the same as in 8.5. 8.9. The separator element There isn't mentioned a single use case. Only some presentational issues that should be kept in CSS as mentioned in 1.1.1. Right? 9.1. The abbr element Should this element get it's own attribute, instead of abusing the TITLE attribute for it's purpose? 9.2. The cite element The examples make it look "Gandalf the White" and "[XML]" are citations. (There is also an error in the first example.) Shouldn't the HREF instead of the CITE attribute be used? 9.6. The kbd element How should keys be marked up, or is this not the right attribute for that? Use case: To go to the homepage, click ALT+1 How should "ALT+1" be marked up? I don't want someone to type in "A+L+T+1". 9.7. The l element Didn't BLOCKCODE preserve whitespace by default? What do we need the L element for here? And as mentioned before, BR is still needed. I also think that a better use case for L should be presented, this one is bad. 9.8. The quote element # either directly in the text, or via a stylesheet Why directly in the text, what is the use case? 10.1. The a element Why do we need this element when there is SPAN? Everything can be an explicit link in XHTML 2.0. 11. XHTML List Module Why can't LABEL be used halfway in a list? Example: <nl> <label>...</label> <li>...</li> <li>...</li> <label>...</label> <li>...</li> </nl> I also don't really like how nested lists work. I have read something[2] in the past that seems a whole lot better. Maybe someone can look into it? 12.1. Core Attribute Collection Will ID be replaced with it's XML equivalent, once that specification[3] becomes a recommendation? I think something should be done with TITLE. On www-html there is a permathread[4] going on with some suggestions. Suggestions include to replace it with an element, create more attributes to be able to distinguish between titles, practical hints and descriptions. 13.1. Hypertext Attribute Collection Why are HREFLANG and HREFTYPE needed at all? It currently looks like they define what kind of content you are going to see when you follow a link. Let's see that resource http://example.org/x is written in 5 languages and 3 different types. A friend of my creates a link to it: <a href="http://example.org/x" hreflang="nl" hreftype="text/html" >...</a> Now I follow that link and obviously, since I'm browsing a conforming browser I get the Dutch HTML version of that page. Now I'm passing that link along (copying it from my address bar) through IRC and tell him it's a great Dutch site (what do I know?). A minute later he tells me he can't read Russian and why I think giving him that link is funny. If a document consists of multiple versions it should have a permanent link (cool URIs don't change) for each document. That would mean 3*5=15 different documents for the above given example each with their own URI possibly looking like: http://example.org/x.nl.html Also, isn't TARGET a CSS issue[5]? 15.1. Bi-directional Text Collection The second example here does define a DOCTYPE, but doesn't define a namespace. 16.1. Edit Collection Why does |edit="deleted"| has default presentation where QUOTE does not? 17. XHTML Embedding Attributes Module I can't see why modern user agents need TYPE. Most of them don't need it with HTML anyway. 18. XHTML Image Map Attributes Module Why aren't the attributes directly applied to the NL element? Using a P element there looks like a major hack. And how do I describe sections that are not links and are not part of the navigation, but are part of the same image? I guess not with LI, since that would be a hack, although it is suggested in the specification. 21.1. The object element Why do we need this? 23. XHTML Scripting Module Since this is getting dropped, is the W3C working on something along the lines of the following: <?xml-script href="script" type="application/x-javascript" alternate="yes" ?> ...? 24. XHTML Style Attribute Module Can this be dropped as well? Having a STYLE element is bad enough. 27. XForms Module Can this be replaced by understandable for everyone forms? This was it (besides the previous mails sent). I probably missed things. [1]<http://www.w3.org/TR/2004/WD-xhtml2-20040722/> [2]<http://webperso.easyconnect.fr/danielglazman/weblog/newarchive/2002_11_24_glazblogarc.html#s85072264> [3]<http://www.w3.org/TR/2004/WD-xml-id-20040407/> [4]<http://lists.w3.org/Archives/Public/www-html/2004Jul/thread.html#16> [5]<http://www.w3.org/TR/2004/WD-css3-hyperlinks-20040224/> -- Anne van Kesteren <http://annevankesteren.nl/>
PROBLEM ID: 8050
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
ORIGINAL MESSAGE:
Date: Wed, 27 Aug 2008 17:46:52 +0200 From: "Steven Pemberton" <steven.pemberton@cwi.nl> There has been a complaint that the image at the beginning of the XML Events 2 spec has the capture phase going right down to the target element. This has confused people, and so should be fixed. Steven
PROBLEM ID: 8056
STATE: Approved
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: None
NOTES:
The group notes that you can access anything that is in the event object. We will add some text to make this clear and tie it to the DOM 3 specification.
ORIGINAL MESSAGE:
From: John Boyer <boyerj@ca.ibm.com> Date: Wed, 8 Oct 2008 13:55:43 -0700 This is a multipart message in MIME format. --=_alternative 0072F6AE882574DC_= Content-Type: text/plain; charset="US-ASCII" On the Forms WG telecon today, Steven recommended it would be OK to submit the following as a last call comment (despite the late date). XML Events 2 has an event() function, and it depends on the consuming language profile to provide specific context information properties that can be returned by the function. However, there are at least five properties that XML Events 2 could offer to all consuming languages: event('name') - the name of the event, e.g. xforms-insert (this is more for completeness, since often you will know this based on ev:event) event('targetid') - returns ID of the event target event('phase') - returns capture or bubble, depending on the phase the event is in when the event() function is invoked. event('bubbles') - returns true or false depending on whether or not the event bubbles event('cancelable') - returns true or false depending on whether the event propagation can be stopped. I can't recall offhand whether the ability to stop the default action is also part of cancelable, but it should be accounted for as well. The most important ones, in my view, seem to be targetid and phase. I have hit a few cases at least where I want to do something *if* the event is going to a particular element or *if* it is in the capture phase. Best regards, John M. Boyer, Ph.D. STSM, Interactive Documents and Web 2.0 Applications Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw --=_alternative 0072F6AE882574DC_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">On the Forms WG telecon today, Steven recommended it would be OK to submit the following as a last call comment (despite the late date).</font> <br> <br><font size=2 face="sans-serif">XML Events 2 has an event() function, and it depends on the consuming language profile to provide specific context information properties that can be returned by the function.</font> <br> <br><font size=2 face="sans-serif">However, there are at least five properties that XML Events 2 could offer to all consuming languages:</font> <br> <br><font size=2 face="sans-serif">event('name') - the name of the event, e.g. xforms-insert (this is more for completeness, since often you will know this based on ev:event)</font> <br> <br><font size=2 face="sans-serif">event('targetid') - returns ID of the event target</font> <br> <br><font size=2 face="sans-serif">event('phase') - returns capture or bubble, depending on the phase the event is in when the event() function is invoked.</font> <br> <br><font size=2 face="sans-serif">event('bubbles') - returns true or false depending on whether or not the event bubbles</font> <br> <br><font size=2 face="sans-serif">event('cancelable') - returns true or false depending on whether the event propagation can be stopped. </font> <br> <br><font size=2 face="sans-serif">I can't recall offhand whether the ability to stop the default action is also part of cancelable, but it should be accounted for as well.</font> <br> <br><font size=2 face="sans-serif">The most important ones, in my view, seem to be targetid and phase. I have hit a few cases at least where I want to do something *if* the event is going to a particular element or *if* it is in the capture phase.</font> <br> <br><font size=2 face="sans-serif">Best regards,</font> <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br> STSM, Interactive Documents and Web 2.0 Applications<br> Chair, W3C Forms Working Group<br> Workplace, Portal and Collaboration Software<br> IBM Victoria Software Lab<br> E-Mail: boyerj@ca.ibm.com <br> <br> Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/page/JohnBoyer</font></a><font size=2 face="sans-serif"><br> Blog RSS feed: </font><a href="http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw"><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw</font></a><font size=2 face="sans-serif"><br> <br> </font> --=_alternative 0072F6AE882574DC_=--
PROBLEM ID: 8059
STATE: Open
EDIT: N/A
RESOLUTION: None
USER POSITION: None
ORIGINAL MESSAGE:
From: "Ian B. Jacobs" <ij@w3.org> Date: Sun, 30 Mar 2008 19:26:00 +0000 Hello, I received this email and thought I would forward it to the proper list. _ Ian -------- Forwarded Message -------- > Subject: Errata for XML Events: An Events Syntax for XML > Date: Fri, 28 Mar 2008 16:18:05 -0500 > > On your page http://www.w3.org/TR/2003/REC-xml-events-20031014/ in > "3.3.1. Examples of Using Attributes Attached to a Handler Element", > Example 3 reads: "The <script> element is the handler for event > click; the <img> element is the observer." This should read: "The > <script> element is the handler for event activate; the <img> element > is the observer." > > In "B. Schema Implementation" the third sentence reads: "It is > divided into an attributes module and an element module for the XML > Events module defined in this Proposed Recommendation." This should > read: "It is divided into an attributes module and an element module > for the XML Events module defined in this Recommendation." -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260-9447