[whatwg] A few spec typos
section 1.3 under Authoring tools and markup generators: However, since an authoring tools is likely unable to determine the difference, an authoring tool is exempt from that requirement. Since an authoring tools is - since an authoring tool is or since authoring tools are Section 1.3.1: Unless other specified, if a DOM attribute that is a signed numberic type is assigned a negative value, a NOT_SUPPORTED_ERR exception must be raised. 1. Unless other specified sounds funny to me. I get what it's saying, but maybe it could be worded differently. Was otherwise intended in that case? 2. Instead of signed numberic, should that be unsigned numeric? 1.4 terminology In The term root element... part: or the node itself is there is none - or the node itself if there is none -- Michael
Re: [whatwg] Still more comments and questions on Web Apps 1.0
On Sat, 09 Jun 2007 04:49:56 +0200, Michel Fortin [EMAIL PROTECTED] wrote: I'd agree they're mostly useless in a browser context, but when reading HTML with the intent of reserializing it later, preserving the whitespace around the document type declaration, the comments and the root element can be beneficial for the readability of the final output. I'd keep them there, just like XML does. I don't think XML does that, actually. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Still more comments and questions on Web Apps 1.0
At least, MSXML does not preserve white space even where mixed content is allowed. I get span a/span span b/span when I XSLT span a/span span b/span . I have to type #32; for all standalone spaces. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anne van Kesteren Sent: Saturday, June 09, 2007 11:26 AM To: Michel Fortin; Ian Hickson Cc: Henri Sivonen; whatwg List Subject: Re: [whatwg] Still more comments and questions on Web Apps 1.0 On Sat, 09 Jun 2007 04:49:56 +0200, Michel Fortin [EMAIL PROTECTED] wrote: I'd agree they're mostly useless in a browser context, but when reading HTML with the intent of reserializing it later, preserving the whitespace around the document type declaration, the comments and the root element can be beneficial for the readability of the final output. I'd keep them there, just like XML does. I don't think XML does that, actually. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] accessibility management for timed media elements, proposal
Dave Singer wrote: we promised to get back to the whatwg with a proposal for a way to handle accessibility for timed media, and here it is. sorry it took a while... Three cheers for Apple for trying to tackle some of the accessibility issues around video content! :) Without trying to assess whether CSS media queries are the best approach generally, here's three particular issues I wanted to raise: 1. Property values I honestly don't think the property values are well-named. either is confusing and vague; dont-want is a misspelled colloquialism. How about one of the following possibilities: captions: wanted captions: unwanted captions: no-preference (This seems more natural to me than the original proposal.) /or/ captions: prefer captions: prefer-not captions: no-preference (Has the consistency of using the same word as the basis for each value. OTOH prefer-not and no-preference may be confusing if your English isn't that good.) /or/ captions: desired captions: undesired captions: no-preference (desire has the minor advantages of being in Ogden's basic English word list and being common to Romance languages thanks to a Latin root. OTOH it's slightly longer.) 2. Conflict resolution The proposal does not describe how conflicts such as the following would be resolved: User specifies: captions: want high-contrast-video: want Author codes: video ... source media=all and (captions: want;high-contrast-video: dont-want) ... / source media=all and (captions: dont-want;high-contrast-video: want) ... / /video Because style rules cascade, this sort of conflict doesn't matter when media queries are applied to styles. But you can only view one video source. 3. (Even more) special requirements The suggested list of media features is (self-confessedly) not exhaustive. Here's some things that seem to be missing: a) I should think sign-language interpretation needs to be in there. sign-interpretation: want | dont-want | either (default: want) Unless we want to treat sign interpretation as a special form of subtitling. How is subtitling in various languages to be handled? b) Would full descriptive transcriptions (e.g. for the deafblind) fit into this media feature-based scheme or not? transcription: want | dont-want | either (default: either) c) How about screening out visual content dangerous to those with photosensitive epilepsy, an problem that has just made headlines in the UK: http://news.bbc.co.uk/2/hi/uk_news/england/london/6724245.stm Perhaps: max-flashes-per-second: integer | any (default: 3) Where the UA must not show visual content if the user is selecting for a lower number of flashes per second. By default UAs should be configured not to display content which breaches safety levels; the default value should be 3 /not/ any. Compare: http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#G19 d) Facilitating people with cognitive disabilities within a media query framework is trickier. Some might prefer content which has been stripped down to simple essentials. Some might prefer content which has extra explanations. Some might benefit from a media query based on reading level. Compare the discussion of assessing readability levels at: http://juicystudio.com/services/readability.php reading-level: integer | basic | average | complex | any (default: any) Where the integer would be how many years of schooling it would take an average person to understand the content: basic could be (say) 9, average could be 12, and complex could be 17 (post-graduate). This wouldn't be easily testable, but it might be useful nevertheless. Postscript: This isn't an accessibility issue but /if/ media queries are adopted as a mechanism for serving up the best content for a person's abilities, I wonder if they could also be used to enhance parental control systems using queries based on PICS: http://www.w3.org/PICS/ So for example, one source might have a music video featuring uncensored swearing, and another source might have the same video with the swearing beeped out. -- Benjamin Hawkes-Lewis
Re: [whatwg] Still more comments and questions on Web Apps 1.0
Le 2007-06-09 à 5:26, Anne van Kesteren a écrit : On Sat, 09 Jun 2007 04:49:56 +0200, Michel Fortin [EMAIL PROTECTED] wrote: I'd agree they're mostly useless in a browser context, but when reading HTML with the intent of reserializing it later, preserving the whitespace around the document type declaration, the comments and the root element can be beneficial for the readability of the final output. I'd keep them there, just like XML does. I don't think XML does that, actually. I've tested by dumping a tree made with PHP 5's XML parser (libxml2) before adding XML to my argument. Now, if I look at the XML spec under [2.10 Whitespace Handling][1]: An XML processor MUST always pass all characters in a document that are not markup through to the application. A validating XML processor MUST also inform the application which of these characters constitute white space appearing in element content. To me, all characters in a document also includes direct children of the document node. But perhaps I'm missing something. [1]: http://www.w3.org/TR/REC-xml/#sec-white-space Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] accessibility management for timed media elements, proposal
At 16:35 +0100 9/06/07, Benjamin Hawkes-Lewis wrote: Dave Singer wrote: we promised to get back to the whatwg with a proposal for a way to handle accessibility for timed media, and here it is. sorry it took a while... Three cheers for Apple for trying to tackle some of the accessibility issues around video content! :) Many thanks for all your helpful comments! Without trying to assess whether CSS media queries are the best approach generally, here's three particular issues I wanted to raise: 1. Property values I honestly don't think the property values are well-named. either is confusing and vague; dont-want is a misspelled colloquialism. We struggled with this also; suggestions are welcome. How about one of the following possibilities: captions: wanted captions: unwanted captions: no-preference (This seems more natural to me than the original proposal.) /or/ captions: prefer captions: prefer-not captions: no-preference (Has the consistency of using the same word as the basis for each value. OTOH prefer-not and no-preference may be confusing if your English isn't that good.) /or/ captions: desired captions: undesired captions: no-preference (desire has the minor advantages of being in Ogden's basic English word list and being common to Romance languages thanks to a Latin root. OTOH it's slightly longer.) nice (in my personal opinion). 2. Conflict resolution The proposal does not describe how conflicts such as the following would be resolved: User specifies: captions: want high-contrast-video: want Author codes: video ... source media=all and (captions: want;high-contrast-video: dont-want) ... / source media=all and (captions: dont-want;high-contrast-video: want) ... / /video There is no suitable source here; it's best to have something (late) in the list which is less restrictive. Because style rules cascade, this sort of conflict doesn't matter when media queries are applied to styles. But you can only view one video source. 3. (Even more) special requirements The suggested list of media features is (self-confessedly) not exhaustive. Here's some things that seem to be missing: a) I should think sign-language interpretation needs to be in there. sign-interpretation: want | dont-want | either (default: want) Unless we want to treat sign interpretation as a special form of subtitling. How is subtitling in various languages to be handled? I think we assume that a language attribute can also be specified, as today. I have to confess I saw the BBC story about sign-language soon after sending this round internally. But I need to do some study on the naming of sign languages and whether they have ISO codes. Is it true that if I say that the human language is ISO 639-2 code XXX, and that it's signed, there is only one choice for what the sign language is (I don't think so -- isn't american sign language different from british)? Alternatively, are there ISO or IETF codes for sign languages themselves? b) Would full descriptive transcriptions (e.g. for the deafblind) fit into this media feature-based scheme or not? transcription: want | dont-want | either (default: either) how are these presented to a deafblind user? c) How about screening out visual content dangerous to those with photosensitive epilepsy, an problem that has just made headlines in the UK: http://news.bbc.co.uk/2/hi/uk_news/england/london/6724245.stm Perhaps: max-flashes-per-second: integer | any (default: 3) Where the UA must not show visual content if the user is selecting for a lower number of flashes per second. By default UAs should be configured not to display content which breaches safety levels; the default value should be 3 /not/ any. I think we'd prefer not to get into quantitative measures here, but a boolean this program is unsuitable for those prone to epilepsy induced by flashing lights might make sense. epilepsy: dont-want -:) Compare: http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#G19 d) Facilitating people with cognitive disabilities within a media query framework is trickier. Some might prefer content which has been stripped down to simple essentials. Some might prefer content which has extra explanations. Some might benefit from a media query based on reading level. Compare the discussion of assessing readability levels at: http://juicystudio.com/services/readability.php reading-level: integer | basic | average | complex | any (default: any) Where the integer would be how many years of schooling it would take an average person to understand the content: basic could be (say) 9, average could be 12, and complex could be 17 (post-graduate). This wouldn't be easily testable, but it might be useful nevertheless. Yes, this isn't testable, and is quantitative. Postscript: This isn't an accessibility issue but /if/ media queries are adopted as a mechanism for serving up the best
Re: [whatwg] accessibility management for timed media elements, proposal
On Jun 9, 2007, at 5:26 PM, Dave Singer wrote: I have to confess I saw the BBC story about sign-language soon after sending this round internally. But I need to do some study on the naming of sign languages and whether they have ISO codes. Is it true that if I say that the human language is ISO 639-2 code XXX, and that it's signed, there is only one choice for what the sign language is (I don't think so -- isn't american sign language different from british)? Alternatively, are there ISO or IETF codes for sign languages themselves? Almost no sign languages are related to the spoken language in the same region any more than any two spoken languages are related to each other. Sign languages are full-fledged languages in their own right, not signed transliterations of spoken language (though they do frequently have an alphabet system for signing words and names from spoken languages). So, American Sign Language is not actually related to English any more than other languages spoken in America are (like Cherokee or Spanish). The situation with the ISO 639-2 codes is unfortunate, because there is only a single code for all sign languages, sgn. It appears that the solution is to add extensions specifying the actual language, such as sgn-US or sgn-UK. There's more information available here: http://www.evertype.com/standards/iso639/sgn.html
