[whatwg] typo in the spec of the selectionDirection attribute
I've read the the spec of the selectionDirection attribute, and I've found a typo. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#dom-textarea/input-selectiondirection The spec says in the second paragraph as below. --- On setting, it must act as if the setSelectionRange() method had been called, with the current value of the selectionStart attribute as the first argument, the current value of the selectionEnd attribute as the first argument, and the new value as the third argument. --- The current value of the selectionEnd attribute is not as the first argument, but as the second argument, is it? -- Futomi Hatano i...@html5.jp http://www.html5.jp/ http://www.futomi.com/ http://twitter.com/futomi
[whatwg] a typo in 8.6.1 APIs for the browsing context selection
I've found a typo in 8.6.1 APIs for the browsing context selection. http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#documentSelection In the green box, we can find a definition as below. collapsed = selection . isCollapsed() As far as I've read the section 8.6.1, I understand that isCollapsed isn't a method, but an IDL attribute. So, I think it should be as below. collapsed = selection . isCollapsed -- Futomi Hatano http://www.html5.jp/ http://www.futomi.com/ http://twitter.com/futomi
Re: [whatwg] Paragraphs in blockquotes
On Tue, 11 May 2010 09:06:11 +0100 Richard Clark he...@richclarkdesign.com wrote: In HTML5 that requirement seems to have been relaxed, as the following element validates successfully: blockquoteThis is a blockquote./blockquote The HTML5 spec uses the p element in the usage examples, but does not mention whether it is required. Can you please confirm if this requirement has now been deprecated? The content model for blockquote is Flow content. Flow content includes text. So, the text as a child of blockquote is valid. The spec says that a run of phrasing content (in this case, it is the text.) is a paragraph. http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#paragraph So, the examples below have same semantics. blockquoteThis is a blockquote./blockquote blockquotepThis is a blockquote./p/blockquote The former is valid, but, of course, authers are encouraged the latter much more. Regards Futomi -- Futomi Hatano http://www.html5.jp/ http://www.futomi.com/ http://twitter.com/futomi
Re: [whatwg] Why are form fields without a name barred from constraint validation?
Hi Bruce, On Fri, 02 Apr 2010 09:57:04 - Bruce Lawson bru...@opera.com wrote: Constraint validation: If an element does not have a name attribute specified, or its name attribute's value is the empty string, then it is barred from constraint validation. http://dev.w3.org/html5/spec/forms.html#naming-form-controls As a matter of interest, why? Because such controls are ignored when the form is submitted. http://dev.w3.org/html5/spec/forms.html#form-submission-algorithm Nameless controls are meaningless in form submission. So, those controls do not need to be validated, I think. -- Futomi Hatano http://www.html5.jp/ http://www.futomi.com/ http://twitter.com/futomi
[whatwg] The examples of the list attribute of the input element is incorrect
Hi all, I have checked the examples of the list attribute of the input element, which have added today. http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-list-attribute There is a example which shows how to mark up fallback contents of the datalist element. p label Enter a breed: input type=text name=breed list=breeds /label datalist id=breeds label or select one from the list: select name=breed option value= (none selected) optionAbyssinian optionAlpaca !-- ... -- /select /label /datalist /p I think that this example is incorrect. It works in legacy UAs as expected (i.e. the fallback contens are shown.). But it does not work in UAs which support the datalist element as expected (i.e. the suggests are not shown.), because the option elements do not have a value attribute. The spec says that a value attribute is required in the option element for a suggestion. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-datalist-element The example works in Opera 10.1, because it is based on the old spec. In fact, the example does not work in Opera 10.5 pre-alpha. I think that Opera 10.5 pre-alpha is correct. I think that the example must be as follow. p label Enter a breed: input type=text name=breed list=breeds /label datalist id=breeds label or select one from the list: select name=breed option value= (none selected) option value=AbyssinianAbyssinian option value=AlpacaAlpaca !-- ... -- /select /label /datalist /p This example works in Opera(10.1, 10.5) and other UAs which does not support the datalist element as expected, except Chrome 4. Thank you. -- Futomi Hatano http://www.html5.jp/ http://www.futomi.com/ http://twitter.com/futomi
[whatwg] typo in the vCard spec
Hi all, I wonder if there is a typo in the example of Microdata Vocabularies: vCard. http://www.whatwg.org/specs/vocabs/current-work/#examples There are three examples. Could you see the second example? strong title=fnAlfred Person/strong I wonder if the title attribute is incorrect. The itemprop attribute is correct, isn't it? strong itemprop=fnAlfred Person/strong Thank you. -- Futomi Hatano www.html5.jp
Re: [whatwg] value content attribute of input
On Thu, 3 Dec 2009 09:31:18 -0500 Mike Taylor michaelaarontay...@gmail.com wrote: It's not clear to me that every possible attribute is intended to be in that table. Autofocus, for example, is missing as well. Exactly. The table seems to list attributes defined for only input. Attributes common to form controls(autofocus, disabled, form, name, value) seem to be excluded. I understand the purpose of the table. Thanks for your insight. -- Futomi Hatano www.html5.jp
[whatwg] value content attribute of input
Hi all Could you please see the section in the spec? http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element There is a table which includes summarizes which of content attributes, IDL attributes, methods, and events apply to each state. Is the value content attribute needed to include to the table, isn't it? -- Futomi Hatano www.html5.jp
Re: [whatwg] rp is a styling tag and has no semantic function
On Sat, 31 Oct 2009 11:27:26 +0100 Nikita Popov pri...@ni-po.com wrote: The text without a ruby annotation should not be in ruby. It should be marked up like this: ruby char rtpron 1/rt another char rtpron 2 pron 3/rt /ruby and some other text without a ruby annotation. Yes, that's right. But there are always people not as strict. I think some ninety-nine percent of websites aren't valid an even less semantic. HTML5 mustn't be planed only for the exemplary developers but for the standard-user, too. Do you think that HTML5 should support bad markups? I don't think so. Screen-readers are yet another problem: I'm not sure, what's better: ka-n-ka-n-ji-ji or ka-n-bracketopen-ka-n-bracketclose-ji-bracketopen-ji-bracketclose. I think the first one is even better, because the text is only duplicated and the reader mustn't read the brackets, too. (This is for screen-readers not supporting ruby. The ones that support it can then handle it by only reading out the rt, as you proposed. [Though you need to consider the problem above.]) This is not a problem. Of course, the first one is better. But, the second one is based on markup which is not good. The markup blow is better, as I mentioned previously. ruby 漢字rp(/rprtかんじ/rtrp)/rp /ruby It will be read ka-n-ji-bracketopen-ka-n-ji-bracketclose by screen-readers which don't support ruby. It is not best, but still is understandable. My solution is progressive enhancement. Screen-readers which support ruby will be able to read ka-n-ji. I don't want to say that you should use rp. I think that your solution is also good. I simply want rp not to dropped from HTML5. It's better that we have alternative markup ways for a ruby. Thank you. -- Futomi Hatano www.html5.jp
Re: [whatwg] rp is a styling tag and has no semantic function
On Fri, 30 Oct 2009 11:10:59 +0100 Nikita Popov pri...@ni-po.com wrote: Futomi Hatano schrieb: If ATs(e.g. screen reader) know the rp element, it can remove the content of the rp element. So, we can get only true annotations from ATs, without parentheses. I don't want hear parentheses from a screen reader. I hope that all browsers (including ATs) support the ruby element. If so, I think the rp element is not necessary. Thank you. -- Futomi Hatano www.html5.jp I think this element is necessary in the HTML5 spec. Talking about screen-readers: How should a screen-reader actually handle ruby annotations? In this case ruby 漢 rt かん /rt 字 rt じ /rt /ruby it would be quite strange if a screen-reader read the annotations, because they have the same content as the ruby base text. (I hope this is correct. I don't know the Japanese language, but I understood it as 漢 beeing same as かん only in a different way of writing.) So the reader must not read the annotation. More correctly, screen-readers should read only the contents of rt rather than the base text. That is, screen-readers are expected to read it as ka-n-ji from rts. Of course, screen-readers which don't support ruby repeat 2 times such like ka-n-ka-n-ji-ji as you know. We also have to get ruby easy to read for visual browser users. But, the markup above is rendered by non-IE browsers as below. 漢かん字じ We feel it is odd. So, I want to mark it up like this. ruby漢字rp(/rprtかんじ/rtrp)/rp/ruby This markup is rendered by non-IE browsers as below. 漢字(かんじ) It's natural and easy to understand. Screen-readers which supports ruby of HTML5 are expected to ignore rp, and read only the contents of rt. Users who use such a screen-reader will hear ka-n-ji only once. I think that both of screen reeder users and visual browser users would be happy. If rp is dropped from the spec, screen-readers could't ignore parentheses without fail. So, I think that rp is necessary. In an example i got from an older W3C spec, it's different: Are you talking about Ruby Annotation module for XHTML 1.1? http://www.w3.org/TR/ruby/ ruby rbc rb10/rb rb31/rb rb2002/rb /rbc rtc rtMonth/rt rtDay/rt rtYear/rt /rtc rtc rt rbspan=3Expiration Date/rt /rtc /ruby As this markup isn't used anymore with HTML5, here's how it would be (dropping the expiration date): ruby 10 rtMonth/rt 31 rtDay/rt 2002 rtYear/rt /ruby This one now should be read out by the screen-reader. Otherwise the meaning of the numbers may be not as clear. (Or is the date-example out-of-date and ruby shouldn't be used there?) I think that ruby of HTML5 is not appropriate for the case. According to the HTML5 spec, ruby is primarily used in East Asian typography as a guide for pronunciation or to include other annotations. I think that this element was not designed for the case you mentioned. Ruby Annotation module for XHTML 1.1 can be used for a broad range of objectives. But ruby of HTML5 is limited, I think. Thank you for your time. -- Futomi Hatano www.html5.jp
[whatwg] an odd example of the meter element
Hi, all I found an odd example in the meter element section of the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-meter-element metermax: 100; current: 75/meter According to steps for finding one or two numbers of a ratio in a string, does it means that the actual value is 100 and the max value is 75? http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#steps-for-finding-one-or-two-numbers-of-a-ratio-in-a-string If so, the gauges would end up looking maxed out. Should it be as below? metercurrent: 75; max: 100;/meter Thank you. -- Futomi Hatano www.html5.jp
Re: [whatwg] an odd example of the meter element
On Thu, 29 Oct 2009 10:58:17 +0100 Magnus Kristiansen magnusrk+wha...@pvv.org wrote: No, the larger number is always used as the max, and the smaller as current. In the meter section: (...) if there were two numbers parsed out of the textContent, then the maximum is the higher of those two numbers. and (...) if the result of processing the textContent of the element was two numbers, then the actual value is the lower of the two numbers found. Oh!, I'm sorry. I overlooked what you pointed out. Thank you for letting me know. -- Futomi Hatano www.html5.jp
Re: [whatwg] rp is a styling tag and has no semantic function
On Wed, 28 Oct 2009 17:27:21 +0100 Nikita Popov pri...@ni-po.com wrote: In the spec the use of the rp-tag is shown like this: ruby 漢 rp(/rprtかん/rtrp)/rp 字 rp(/rprtじ/rtrp)/rp /ruby What semantic function has the rp-tag? No. It is only styling for browsers not supporting ruby-text. I don't think that the rp element is only for styling. It has important semantics which represents *parentheses* for ruby anotations. I know that the element is for legacy browsers. But, if we would like to use ruby annotations, we have to use parentheses to separate the main text and the ruby annotations for legacy browsers. So I think this element musn't be in the HTML5 spec. You can add the brackets before and after the ruby text using CSS pseudoclasses (:after, :before). I think this element is necessary in the HTML5 spec. If ATs(e.g. screen reader) know the rp element, it can remove the content of the rp element. So, we can get only true annotations from ATs, without parentheses. I don't want hear parentheses from a screen reader. I hope that all browsers (including ATs) support the ruby element. If so, I think the rp element is not necessary. Thank you. -- Futomi Hatano www.html5.jp
[whatwg] Author requirements of the progress element
Hi, all I'd like to talk about the author requirements of the progress element. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-progress-element There are some cases in the requirements. But one case is dropped. The value attribute is specified but the max attribute is not specified Is this case intended to be dropped? If so, why? I think that this case is necessary specially in Japanese language. Word order of Japanese language is different from English language. In addition, Japanese people often use kanji characters or two-byte characters to represent the completion progress of a task. So, the case of no value, no max, 2 numbers in progress is not easy to use in Japanese document. Neither, the case of no value, max specified, 1 number in progress. But the case of value specified, no max is easy to use in Japanese language. For example, progress value=0.2kanji characters which represent 20%/progress In this case, the max value should be 1. So, UAs can determine the rate of the progress. I think that this case has no problem as one of the requirements. I know that I can use the case of value specified, max specified. progress value=0.2 max=1kanji characters which represent 20%/progress But, I think that there is no reason why the case of value specified, no max is dropped. Thank you. -- Futomi Hatano www.html5.jp
