Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Mon, Sep 26, 2011 at 2:36 AM, Glenn Maynard gl...@zewt.org wrote: On Sun, Sep 25, 2011 at 1:02 PM, Ryosuke Niwa rn...@webkit.org wrote: The current Trident/WebKit behavior has a nice side-effect to (without scripts) require a visible submit button to enable implicit form submission. I don't find that nice. As a user, it's very annoying when implicit form submission doesn't work for some obscure reason (like not having a submit control), forcing me to use the mouse instead of it behaving like any other form. It makes the UI inconsistent and unpredictable. Also, the single-text-input-with-no-submit-button case doesn't follow the above. The without scripts is also a fatal caveat. Users can't be expected to understand things like you can press enter to submit the form if you see a browser-native submit button, but not if the button is actually scripted markup. In principle, *all* forms should allow implicit submit, unless the site explicitly doesn't want it (scripted autosave dialogs) or the UA doesn't support it. That ship sailed years ago, but the visibility of the submit button shouldn't enter into it. Reopening discussion - In case of single Input box and disabled (but visible button) forms still gets submitted on implicit submission. This is again something weird and happens in IE Webkit but not in FF opera. IMHO, the implicit submission should have straight away algorithm - 1) If submit button is there but not disabled implicit submission should happen on enter key press 2) If submit button is there and disabled implicit submission should not happen on enter key press Both logic should be irrespective of number of input button OR visibility of submit button. - Kaustubh
Re: [whatwg] Three concerns regarding HTML5 form validation
On 29 sep 2011, at 02:25, Jonas Sicking wrote: OK, I understand... so is there a reason not to have a method for triggering the display of validation errors in addition to triggering a click on a submitControl? (I can understand not wanting duplication of functionality, but it would be great for clarity) I agree that this sounds like a good idea. One simple solution would be to make checkValidity take a optional boolean argument which defaults to false. If the function is called on a form and passed true, this instructs the UA to display the same UI as would be displayed if the form was submitted. If the function is called on a individual control and passed true, this instructs the UA to display any UI it would for that control. / Jonas Exactly! http://twitter.com/#!/matiaslarsson/status/116887142516531201 :) /Matias
Re: [whatwg] track / WebVTT issues
On Thu, Sep 22, 2011 at 2:53 AM, Ralph Giles gi...@mozilla.com wrote: On 21/09/11 04:04 AM, Anne van Kesteren wrote: I have an additional point. Can we maybe consider naming it just VTT? At least as far as file signatures, media types, and other developer-facing identifiers are concerned. Three ASCII characters is a little sparse for a file signature. Otherwise, I don't object. The mime type is already text/vtt, so nothing to worry about there. Whether you want to call it VTT or WebVTT is up to you. The file signature should indeed stay longer and I do quite like WEBVTT for that. Cheers, Silvia.
Re: [whatwg] track / WebVTT issues
On Wed, Sep 21, 2011 at 7:15 PM, Philip Jägenstedt phil...@opera.com wrote: == Scrolling captions == The WebVTT layout algorithm tries to not move cues around once they've been displayed and to never obscure other cues. This means that for cues that overlap in time, the rendering will often be out of order, with the earliest cue at the bottom. This is quite contrary to the (mainly US?) style of (live) scrolling captions, where cues are always in order and scroll to bring new captions into view. (I am not suggesting any specific change.) I have a particular issue with this since text grows from the top down and not from the bottom up. If you have ever seen live captions (even in their recorded state), you will notice the scrolling feature (also called roll-up captions), e.g. http://www.youtube.com/watch?v=F_q-RRXw-vY . This example also shows how captions may move location if they try to avoid other text on screen. Also note that YouTube is experimenting with richer captions, see http://www.youtube.com/watch?v=0xTURXWoJ6A (check the different caption tracks) . These are representing some of the features that the US TV standard CEA608/708 captions support, so we need to make sure they are also supported by browsers, otherwise we get a lower quality result with captions on the Web that we get with captions on TV. == Scaling up and down == Scaling the font size with the video will not be optimal for either small screens (text will be too small) or very large screens (text will be too big). Do we change the default rendering in some way, or do we let users override the font size? If users can override it, do we care that this may break the intended layout of the author? We definitely need to give users the possibility to scale up the text size. YouTube does that already (just press + or - on the video player as you are watching with captions on). YouTube also allows users to change the font color and the background color on captions (see the caption settings menu) because some people may have different types of color blindness to deal with. YouTube deals with the increased front size by wrapping lines that go outside the determined rendering box width. This also happens when we get long caption texts, so isn't really anything new that we have to deal with. What happens with the new lines that are created by wrapping should, however, be defined better than what we have right now. In other existing caption formats, there is the concept of an anchor. The box into which the caption text is rendered is anchored to the video by choosing a point inside the one-line caption cue box and a point on the video viewport and anchoring that point. The box then grows around that point in equal parts. For example, if the box is anchored at its top middle point and assuming horizontally rendered text, the box will grow down from that point. If it's anchored at the bottom middle point, the box will grow up (even if the text is wrapped down and grows down - i.e. the first line will be moved up before the second line is rendered). Cheers, Silvia.
[whatwg] Question: rel=help
Hi there everyone, Question, would an element with rel=help and a title=Help text make sense and be valid as a JavaScript hook for tooltips? Does not match the usage as described by the WHAT-WG (http://developers.whatwg.org/links.html#link-type-help) exactly, but close enough? -- Kind Regards, Schalk Neethling Mozilla Corporation
Re: [whatwg] Question: rel=help
On Thu, 29 Sep 2011 16:35:33 +0200, Schalk Neethling sneethl...@mozilla.com wrote: Question, would an element with rel=help and a title=Help text make sense and be valid as a JavaScript hook for tooltips? Does not match the usage as described by the WHAT-WG (http://developers.whatwg.org/links.html#link-type-help) exactly, but close enough? If there is no actual hyperlink, using a link relation does not make sense. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Three concerns regarding HTML5 form validation
On Thu, Sep 29, 2011 at 12:32 AM, Matias matia...@gmail.com wrote: On 29 sep 2011, at 02:25, Jonas Sicking wrote: OK, I understand... so is there a reason not to have a method for triggering the display of validation errors in addition to triggering a click on a submitControl? (I can understand not wanting duplication of functionality, but it would be great for clarity) I agree that this sounds like a good idea. One simple solution would be to make checkValidity take a optional boolean argument which defaults to false. If the function is called on a form and passed true, this instructs the UA to display the same UI as would be displayed if the form was submitted. If the function is called on a individual control and passed true, this instructs the UA to display any UI it would for that control. / Jonas Exactly! http://twitter.com/#!/matiaslarsson/status/116887142516531201 :) I'd take a experimental gecko-patch if you write one :) / Jonas
Re: [whatwg] Question: rel=help
Hi Anna, I heard some mention of using the data-* attributes so, something like: a href= data-tooltip=Some help text/a or input type=text data-tooltip=Some help text / Would you agree that this is the better option? On 29/09/2011 16:50, Anne van Kesteren wrote: On Thu, 29 Sep 2011 16:35:33 +0200, Schalk Neethling sneethl...@mozilla.com wrote: Question, would an element with rel=help and a title=Help text make sense and be valid as a JavaScript hook for tooltips? Does not match the usage as described by the WHAT-WG (http://developers.whatwg.org/links.html#link-type-help) exactly, but close enough? If there is no actual hyperlink, using a link relation does not make sense. -- Kind Regards, Schalk Neethling Mozilla Corporation
Re: [whatwg] Question: rel=help
29.9.2011 20:34, Schalk Neethling wrote: I heard some mention of using the data-* attributes so, something like: a href= data-tooltip=Some help text/a The data-* attributes are supposed to be strictly private, so they are the last resort. This all depends on what is going on, which was not disclosed in the original question. The use of rel=help is for most practical purposes just an idle attribute (few user agents pay any attention to it). But the title attribute is used, so the questions are: What would you like to happen when JavaScript is disabled? Is it OK to search engines to treat the title=... attribute value as actually relating to the link? -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] Question: rel=help
Schalk, Javascript-only help text (tooltip or otherwise) or any other content intended for human consumption is a really bad idea for all the usual reasons (#a11y, mobile, search etc.) Consider adjusting your content design to incorporate the help text instead (perhaps with either the respective element's title attribute or with a nearby/adjacent element) so that it is available without JS, and then if you wish to do fancy tooltip effects feel free to provide them with JS (progressive enhancement) which re-uses that content from the page. Thanks, Tantek -Original Message- From: Schalk Neethling sneethl...@mozilla.com Sender: whatwg-boun...@lists.whatwg.org Date: Thu, 29 Sep 2011 19:34:40 To: Anne van Kesterenann...@opera.com Reply-To: sneethl...@mozilla.com Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Question: rel=help Hi Anna, I heard some mention of using the data-* attributes so, something like: a href= data-tooltip=Some help text/a or input type=text data-tooltip=Some help text / Would you agree that this is the better option? On 29/09/2011 16:50, Anne van Kesteren wrote: On Thu, 29 Sep 2011 16:35:33 +0200, Schalk Neethling sneethl...@mozilla.com wrote: Question, would an element with rel=help and a title=Help text make sense and be valid as a JavaScript hook for tooltips? Does not match the usage as described by the WHAT-WG (http://developers.whatwg.org/links.html#link-type-help) exactly, but close enough? If there is no actual hyperlink, using a link relation does not make sense. -- Kind Regards, Schalk Neethling Mozilla Corporation
Re: [whatwg] Question: rel=help
29.9.2011 20:50, Tantek Çelik wrote: Javascript-only help text (tooltip or otherwise) or any other content intended for human consumption is a really bad idea for all the usual reasons (#a11y, mobile, search etc.) Except in cases where the information is relevant only when JavaScript is enabled. But the original question did not imply, as far as I can see, any JavaScript-only idea. On the contrary, using the title=... attribute implies that the text will be available to many people graphic browsers (though perhaps just by accident) and to many people using speech-based browsing. Consider adjusting your content design to incorporate the help text instead (perhaps with either the respective element's title attribute or with a nearby/adjacent element) I think that idea was implied in the question: Question, would an element with rel=help and a title=Help text make sense and be valid as a JavaScript hook for tooltips? I stll think it's best, for all users, to give instructions in normal text before the fields to be filled out. But there are situations where you expect 80% of people do well without any instructions. I'm not sure of what we are expected to do, as authors, in order to give instructions that might be needed by 20% of users but would mostly be a distraction for the majority. -- Yucca, http://www.cs.tut.fi/~jkorpela/
[whatwg] Drag and drop: bugged implementation of setting drag feedback with setDragImage?
I've a question regarding setDragImage. I've implemented dragstart event handler in the following way: event.setDragImage(this, 0, 0); this.style.background = 'yellow'; What do I expect: 1) Origin element to have yellow background 2) Drag feedback element (the one under cursor) to have original background Are my expectations correct? Because Webkit and Gecko implementation doesn't match it. In their cases both elements have modified background. It seems that both engines delay setting drag image until the end of event handler. I'll provide testcase in a moment. http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html -- Rafał
Re: [whatwg] Question: rel=help
On Thu, Sep 29, 2011 at 11:12, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 29.9.2011 20:50, Tantek Çelik wrote: Javascript-only help text (tooltip or otherwise) or any other content intended for human consumption is a really bad idea for all the usual reasons (#a11y, mobile, search etc.) Except in cases where the information is relevant only when JavaScript is enabled. That's a reasonable theory. Do you have URLs to any real world examples? But the original question did not imply, as far as I can see, any JavaScript-only idea. On the contrary, using the title=... attribute implies that the text will be available to many people graphic browsers (though perhaps just by accident) and to many people using speech-based browsing. Agreed. Consider adjusting your content design to incorporate the help text instead (perhaps with either the respective element's title attribute or with a nearby/adjacent element) I think that idea was implied in the question: Question, would an element with rel=help and a title=Help text make sense and be valid as a JavaScript hook for tooltips? Realizing that this example markup was ambiguous - that is: Does the string Help text represent a hypothetical placeholder on a span or div etc.? Or is that markup part of a hyperlink that links to a separate help document? E.g. a rel=help title=Help text href=help.html(?)/a I stll think it's best, for all users, to give instructions in normal text before the fields to be filled out. Agreed. But there are situations where you expect 80% of people do well without any instructions. Again, seems like a reasonable theory. Do you have URLs to real world examples thereof? I'm not sure of what we are expected to do, as authors, in order to give instructions that might be needed by 20% of users but would mostly be a distraction for the majority. Theoretical problems are harder to provide specific answers for, but this might work: Try the details and summary elements. http://html5doctor.com/the-details-and-summary-elements/ Thanks, Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Re: [whatwg] Drag and drop: bugged implementation of setting drag feedback with setDragImage?
W dniu 29 września 2011 20:46 użytkownik Rafał Miłecki zaj...@gmail.com napisał: I've a question regarding setDragImage. I've implemented dragstart event handler in the following way: event.setDragImage(this, 0, 0); this.style.background = 'yellow'; What do I expect: 1) Origin element to have yellow background 2) Drag feedback element (the one under cursor) to have original background Are my expectations correct? Because Webkit and Gecko implementation doesn't match it. In their cases both elements have modified background. It seems that both engines delay setting drag image until the end of event handler. I'll provide testcase in a moment. See the attachment. One more bug: under Linux in webkit (Chrome) there is not drag feedback image at all. Not sure about Mac. -- Rafał
[whatwg] createContextualFragment in detached contexts
Currently there is no easy way to create a tbody (and others from
markup). To do this correctly people have to go through ugly hacks
like what jQuery does [1] where they wrap the HTML string with the
right context elements and then grab the nodes inside that.
I would like to propose a change to createContextualFragment [2].
If the context object is in a detached state, then relax the parsing
rules so that all elements are allowed at that level. The hand wavy
explanation is that for every tag at the top level create a new
element in the same way that ownerDocument.createElement would do it.
This would allow the following to work.
var df =
document.createRange().createContextualFragment('tbodytrtdHi/tbody
text option/option');
assertEquals(3, df.childNodes.length);
assertEquals('TBODY', df.childNodes[0].tagName);
assertEquals(' text ', df.childNodes[1].textContent);
assertEquals('OPTION', df.childNodes[2].tagName);
[1] https://github.com/jquery/jquery/blob/master/src/manipulation.js#L643
https://github.com/jquery/jquery/blob/master/src/manipulation.js#L32
[2] http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment
erik
Re: [whatwg] createContextualFragment in detached contexts
Can't authors use createElement? Or are you specifically concerne the case
where authors want to use createContextualFragment?
- Ryosuke
On Sep 29, 2011 3:37 PM, Erik Arvidsson a...@chromium.org wrote:
Currently there is no easy way to create a tbody (and others from
markup). To do this correctly people have to go through ugly hacks
like what jQuery does [1] where they wrap the HTML string with the
right context elements and then grab the nodes inside that.
I would like to propose a change to createContextualFragment [2].
If the context object is in a detached state, then relax the parsing
rules so that all elements are allowed at that level. The hand wavy
explanation is that for every tag at the top level create a new
element in the same way that ownerDocument.createElement would do it.
This would allow the following to work.
var df =
document.createRange().createContextualFragment('tbodytrtdHi/tbody
text option/option');
assertEquals(3, df.childNodes.length);
assertEquals('TBODY', df.childNodes[0].tagName);
assertEquals(' text ', df.childNodes[1].textContent);
assertEquals('OPTION', df.childNodes[2].tagName);
[1] https://github.com/jquery/jquery/blob/master/src/manipulation.js#L643
https://github.com/jquery/jquery/blob/master/src/manipulation.js#L32
[2]
http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment
erik
[whatwg] getImageData(), the canvas backing store, and device pixels != CSS pixels
Hi, Re: http://krijnhoetmer.nl/irc-logs/whatwg/20110930#l-81 An example in §4.8.11.1.11 Pixel Manipulation[1] states that the data returned by getImageData() is at the resolution of the canvas backing store, which is likely to not be one device pixel to each CSS pixel if the display used is a high resolution display. This should probably be moved out of the example and into the main prose of the spec. It's easy for implementors to overlook normative statements made in examples. Thanks, Ted 1. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#pixel-manipulation
