Re: [whatwg] Forms dont submit when disabling submit button

[Kaustubh Atrawalkar]

Thanks Ian for the comment. There is already a bug filed in webkit -
https://bugs.webkit.org/show_bug.cgi?id=14443 which i was working on. I
will attach this thread for clarification there. I will try to fix the
issue asap.

Regards
--
Kaustubh

On Fri, Jan 27, 2012 at 4:23 AM, Ian Hickson  wrote:

> On Tue, 27 Sep 2011, Kaustubh Atrawalkar wrote:
> >
> > A simple use case -
> >
> > 
> > 
> > 
>
> (Note: This isn't a "use case", it's a sample. A use case is a description
> of the reason why an author or user wants to do something.)
>
>
> > This does not submit the form in IE, Opera or Webkit but in firefox it
> > does show alert. Considering generic behavior of HTML5 forms, until and
> > unless submit button is active submit action should also be followed by
> > onclick event on submit button. Just need to get what can be the exact
> > behavior here?
>
> The "this.disabled=true" bit should have no effect on the submission
> (since the click has already occurred), and the "return true" part of the
> event handler should have no effect at all.
>
> Thus, assuming the user only clicks once, the above should be equivalent
> to:
>
>  
>  
>  
>
> Thus, Firefox is correct here, and WebKit and Opera are wrong. (I didn't
> test IE.)
>
> I recommend filing bugs.
>
> HTH,
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] Focus remains on Hidden Element

[Kaustubh Atrawalkar]

Thanks Ian for the clarification. What I understand from the comment is
that, when focused element is made display:none in this case, the focus
should be moved to body element if its there else we should blur the
focused element. There is bug for the same issue
https://bugs.webkit.org/show_bug.cgi?id=47182. I will link this thread
there for fixing the same.

- Kaustubh


On Wed, Feb 22, 2012 at 10:57 AM, Ian Hickson  wrote:

> On Sat, 8 Oct 2011, Kaustubh Atrawalkar wrote:
> >
> > In a form element, If a form input element has a focus and its then made
> > hidden using style property display:none the focus still remains on the
> > hidden element. According to specs (
> >
> http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focus-management-
> > 4th point) hidden input elements can not be focused. But there is still
> > inconstancy in the browsers.
>
> The spec requires that focus be dropped in this case:
>
> "When an element that is focused stops being a focusable element, or stops
> being focused without another element being explicitly focused in its
> stead, the user agent should synchronously run the focusing steps for the
> body element, if there is one; if there is not, then the user agent should
> synchronously run the unfocusing steps for the affected element only."
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] Relation between "bordercolor" and "border" attributes

[Kang-Hao (Kenny) Lu]

(12/03/06 17:58), Kishore Bolisetty wrote:
> But it doesn't talks about the behaviour - what if border is not specified
> but bordercolor is specified? Looks like browsers have taken their own
> implementations on this, Opera and Mozilla displays bordercolor only if
> border is specified, where as Safari displays bordercolor assuming a
> default border.

I'll add one more testing result. IE9 and IE quirks mode match Opera and
Mozilla's behavior.

> Which one is correct behaviour? Is it not necessary to explicitly state
> this in the spec?

I don't know what is correct but Safari is certainly less interoperable
here, and the spec matches the interoperable behavior. That is, I think
the spec is pretty clear: bordercolor only changes the border color, not
whether the border shows up or not ('border-style') or border width
('border-width').

(12/03/07 0:35), Tab Atkins Jr. wrote:
> This behavior depends on the browser's default stylesheet, and whether
> they default borders to "border-style: solid; border-color:
> currentColor;" or "border-style: solid; border-width: 0px;".  Browsers
> are allowed to do either.

I don't understand your examples. I think you are probably suggesting
that browsers are allowed to put "table[bordercolor] { border-style:
solid}" in the default stylesheet, but I don't think that's the case
since it makes the browser that does this not "supporting the suggested
default rendering".



Cheers,
Kenny

Re: [whatwg] Specify href target with HTTP headers

[Bjartur Thorlacius]

On Wed, 07 Mar 2012 22:19:17 -, Christian Schmidt   
wrote:
I suggest that a server can specify a link target in an HTTP header,  
e.g. "Window-Target: _blank". The page would be equivalent to specifying  
the same value in the  or  tag leading to the page. It should  
probably be subject to some kind of restrictions, e.g. the header could  
be ignored if the link destination and the referring page had different  
origins, unless the referring page specified some special value in the  
target, e.g. _server (this value would indicate that the link  
destination is a somewhat trusted resource whose Window-Target header  
should be honoured). This ensures that the referring origin is always in  
control of the target.


We should describe the security implications of lifting said restrictions  
(if any) in the rationale document, for when someone is burdened by these  
restrictions and can't figure if they were added for erring on the side of  
security or to address some specific security problems.


It seems there was such a header (to some extent, at least) back in  
Netscape 4:

http://lists.w3.org/Archives/Public/www-html/1998Jan/0010.html
https://bugzilla.mozilla.org/show_bug.cgi?id=97459

The Content-Disposition: attachment/inline header does something related  
not entirely. Its was originally invented for use in MIME mails.


Content-Disposition seems like the "correct" header to use to me, but  
using the previously implemented header is fair enough. Window-Target and  
Content-Disposition must not appear in the same message, as the semantics  
of the former are a subset of the semantics of the latter AFAICT.




Use-case #1:
Sometimes the form target cannot be determined until after the form has  
been submitted. Assume you have a form of some kind. If the server-side  
validation fails, you want to load the same page again (this time with  
an error message) in the same window, but if the server-side validation  
succeeds, you want to open a new window, e.g. containting a PDF or some  
application-like window. This behaviour is sometimes done using  
window.open() on the target page, but many popup blockers prevent this.


Separating the network protocol from the user interface seems highly  
desirable. Window-Target sacrifices that. Would it not be more appropriate  
to return an error response clearly marked as such? That, however, would  
leave the issue of connecting error messages to specific form fields.



Use-case #2:
In Drupal 8 the administrative pages are opened in an overlay/lightbox  
on top of the frontend pages. For each URL it is specified (by means of  
wildcard patterns in hook_admin_paths()) whether it should open in the  
overlay or in the entire browser window, i.e. whether the URL is an  
administrative page or not. For each link on a page the target attribute  
should be specified accordingly (this is handled client-side using a  
click handler on  elements that matches the current href against the  
wildcard patterns and dynamically alters the target attribute - see  
Drupal.overlay.eventhandlerOverrideLink in [2]). Contrary to use-case #1  
it /is/ possible to preprocess all links, but it is a lot of work for  
all links on a page. It would be easier if the server could determine,  
whether the link that was actually clicked on should open in the overlay  
or not.


Note that you can also annotate the links with target hints server-side  
when you serve the frontend pages. While Window-Target may not be a great  
solution to this problem, I can't think of a better one ATM.


On  and  elements you can specify a target attribute, e.g.  
_blank. But sometimes you don't know whether to open in _self or _blank  
at the time the link is clicked/the form is submitted.


The questions are, what information is necessary to decide whether to  
reuse the browsing context or not, and what other decisions depend on the  
said information?


--
-,Bjartur

[whatwg] Specify href target with HTTP headers

[Christian Schmidt]

On  and  elements you can specify a target attribute, e.g. 
_blank. But sometimes you don't know whether to open in _self or _blank 
at the time the link is clicked/the form is submitted.


I suggest that a server can specify a link target in an HTTP header, 
e.g. "Window-Target: _blank". The page would be equivalent to specifying 
the same value in the  or  tag leading to the page. It should 
probably be subject to some kind of restrictions, e.g. the header could 
be ignored if the link destination and the referring page had different 
origins, unless the referring page specified some special value in the 
target, e.g. _server (this value would indicate that the link 
destination is a somewhat trusted resource whose Window-Target header 
should be honoured). This ensures that the referring origin is always in 
control of the target.


It seems there was such a header (to some extent, at least) back in 
Netscape 4:

http://lists.w3.org/Archives/Public/www-html/1998Jan/0010.html
https://bugzilla.mozilla.org/show_bug.cgi?id=97459

The Content-Disposition: attachment/inline header does something related 
not entirely. Its was originally invented for use in MIME mails.



Use-case #1:
Sometimes the form target cannot be determined until after the form has 
been submitted. Assume you have a form of some kind. If the server-side 
validation fails, you want to load the same page again (this time with 
an error message) in the same window, but if the server-side validation 
succeeds, you want to open a new window, e.g. containting a PDF or some 
application-like window. This behaviour is sometimes done using 
window.open() on the target page, but many popup blockers prevent this.


Use-case #2:
In Drupal 8 the administrative pages are opened in an overlay/lightbox 
on top of the frontend pages. For each URL it is specified (by means of 
wildcard patterns in hook_admin_paths()) whether it should open in the 
overlay or in the entire browser window, i.e. whether the URL is an 
administrative page or not. For each link on a page the target attribute 
should be specified accordingly (this is handled client-side using a 
click handler on  elements that matches the current href against the 
wildcard patterns and dynamically alters the target attribute - see 
Drupal.overlay.eventhandlerOverrideLink in [2]). Contrary to use-case #1 
it /is/ possible to preprocess all links, but it is a lot of work for 
all links on a page. It would be easier if the server could determine, 
whether the link that was actually clicked on should open in the overlay 
or not.



[1] 
http://api.drupal.org/api/drupal/modules!system!system.api.php/function/hook_admin_paths/7
[2] 
http://drupalcode.org/project/drupal.git/blob/HEAD:/core/modules/overlay/overlay-parent.js#l530


--
Christian Schmidt

Re: [whatwg] [media] startOffsetTime, also add startTime?

[Rick Waldron]

Thanks for putting this together Odin -- this has long been a point of
interest for all of us on the Popcorn.js dev team.

Rick

On Wed, Mar 7, 2012 at 5:56 AM, Odin Hørthe Omdal  wrote:

> startOffsetTime seem to leave people confused, I often have to explain it,
> and yesterday I read the spec[5] and old emails and got confused myself. It
> hasn't been implemented after almost 2 years.
>
>
> Having the UTC time of the clip you're getting would be very useful. But
> it'd be really nice to get the start of the non-normalized timestamp
> exposed to javascript for synchronizing out-of-band metadata with the live
> streamed media.
>
> Browsers are currently supposed to take the timestamp and normalize it to
> 0 for currentTime. Chromium currently does not do that; it starts at 3:15,
> if I join a streamed video that I started streaming 3 minutes, 15 seconds
> ago.
>
> I don't think using the UTC time as the sync point is very stable at the
> moment. It'd be a much quicker, stable, and easier win to get a startTime,
> timelineStartTime or timeSinceStart or similar that exposes the
> NON-normalized timestamp value at the start of the stream. So that, if you
> do
>
>   startTime + currentTime
>
> you're able to get the actual timestamp that the stream is at, at that
> point. And in contrast with startOffsetTime this one won't ever change, so
> startTime + currentTime will always be continuously increasing.
>
>
>
> The Date UTC which startOffsetTime would use, seems to be varying quite a
> bit. You need to know your streaming server and what it does in order to
> understand the result. Even different media from the same server might give
> different results if the streaming server implementation just reads the UTC
> time directly from the file. The information could be useful, but for more
> advanced uses.
>
>
> startOffsetTime and initialTime came out of this conversation in 2010:
>   2010-May/thread.html#26342
> >
>
> And introduced here:
>   2010-August/028004.html
> >
>
>
> Sean O'Halpin of BBC recently mentioned[2] some of the confusion:
>
>  There seems to be some confusion here in how the HTML5 media elements
>> specification is dealing with logical stream addressing versus physical
>> stream addressing. The excerpt above talks about a user agent being able to
>> "seek to an earlier point than the first frame originally provided by the
>> server" but does not explain how this could possibly happen without
>> communication back to the server, in which case we are effectively dealing
>> with a request for a different physical resource. At the very least, the
>> fact that the Firefox and Chrome teams came up with different
>> interpretations shows that this part of the specification would benefit
>> from clarification.
>>
>
>
> And an earlier blog post about startOffsetTime specifically[3]:
>
>  The reason for setting this out is that we'd like to see consistent
>> support for startOffsetTime across all commonly used codecs and for browser
>> vendors to bring their implementations into line with the published HTML5
>> media elements specification. There are ambiguities in the specification
>> itself, such as the interpretation of 'earliest seekable position', which
>> could be clarified, especially with respect to continuous live streaming
>> media. Browser vendors need to agree on a common interpretation of
>> attributes such as currentTime so others can experiment with the exciting
>> possibilities this new technology is opening up.
>>
>
>
>
> Sooo... It would be nice to get some real cleanups to the whole media +
> time thing. :D
>
>
>
> 1.  multipage/the-video-element.**html#offsets-into-the-media-**resource
> >
> 2.  02/what-does-currenttime-mean-**in.shtml
> >
> 3.  01/implementing-**startoffsettime-f.shtml
> >
> --
> Odin Hørthe Omdal · Core QA, Opera Software · http://opera.com /
>

[whatwg] [media] startOffsetTime, also add startTime?

[Odin Hørthe Omdal]

startOffsetTime seem to leave people confused, I often have to explain it,  
and yesterday I read the spec[5] and old emails and got confused myself.  
It hasn't been implemented after almost 2 years.



Having the UTC time of the clip you're getting would be very useful. But  
it'd be really nice to get the start of the non-normalized timestamp  
exposed to javascript for synchronizing out-of-band metadata with the live  
streamed media.


Browsers are currently supposed to take the timestamp and normalize it to  
0 for currentTime. Chromium currently does not do that; it starts at 3:15,  
if I join a streamed video that I started streaming 3 minutes, 15 seconds  
ago.


I don't think using the UTC time as the sync point is very stable at the  
moment. It'd be a much quicker, stable, and easier win to get a startTime,  
timelineStartTime or timeSinceStart or similar that exposes the  
NON-normalized timestamp value at the start of the stream. So that, if you  
do


   startTime + currentTime

you're able to get the actual timestamp that the stream is at, at that  
point. And in contrast with startOffsetTime this one won't ever change, so  
startTime + currentTime will always be continuously increasing.




The Date UTC which startOffsetTime would use, seems to be varying quite a  
bit. You need to know your streaming server and what it does in order to  
understand the result. Even different media from the same server might  
give different results if the streaming server implementation just reads  
the UTC time directly from the file. The information could be useful, but  
for more advanced uses.



startOffsetTime and initialTime came out of this conversation in 2010:
  


And introduced here:
  


Sean O'Halpin of BBC recently mentioned[2] some of the confusion:

There seems to be some confusion here in how the HTML5 media elements  
specification is dealing with logical stream addressing versus physical  
stream addressing. The excerpt above talks about a user agent being able  
to "seek to an earlier point than the first frame originally provided by  
the server" but does not explain how this could possibly happen without  
communication back to the server, in which case we are effectively  
dealing with a request for a different physical resource. At the very  
least, the fact that the Firefox and Chrome teams came up with different  
interpretations shows that this part of the specification would benefit  
from clarification.



And an earlier blog post about startOffsetTime specifically[3]:

The reason for setting this out is that we'd like to see consistent  
support for startOffsetTime across all commonly used codecs and for  
browser vendors to bring their implementations into line with the  
published HTML5 media elements specification. There are ambiguities in  
the specification itself, such as the interpretation of 'earliest  
seekable position', which could be clarified, especially with respect to  
continuous live streaming media. Browser vendors need to agree on a  
common interpretation of attributes such as currentTime so others can  
experiment with the exciting possibilities this new technology is  
opening up.




Sooo... It would be nice to get some real cleanups to the whole media +  
time thing. :D




1.  

2.  

3.  


--
Odin Hørthe Omdal · Core QA, Opera Software · http://opera.com /

[whatwg] window.close() and user-initiated

[Anne van Kesteren]

In http://www.whatwg.org/specs/web-apps/current-work/#dom-window-close it  
is forbidden to close browsing contexts using the close() method when they  
are opened by a user-initiated action. We think it would be better if that  
were allowed, with the restriction that WebKit has, namely that once the  
user navigates the newly opened browsing context (and gains a history), it  
can no longer be closed.



--
Anne van Kesteren
http://annevankesteren.nl/