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