Re: [whatwg] More YouTube response

[Kornel Lesinski]

On 6 Jul 2010, at 15:24, Marques Johansson wrote:

> A 200 response or partial 206 responses that returns less than the full 
> requested range is not handled by browsers in a consistent or usable way (for 
> this purpose).  Only Chrome will continue to fetch where the previous short 
> 206 response left off (request 1-10, server replies 1-5, request 6-10, server 
> replies 6-10).  The HTTP spec isn't clear about whether UAs should take this 
> behavior - and so they don't.

It might be easier to get that fixed in browsers, than to get 
spec+implementation of a completely new feature.

> Some UAs request video without sending "Range: bytes 0-".  The server has no 
> way to negotiate that the UA (a) must use ranges to complete the request or 
> that (b) the range requested is too large, retry will a smaller range.

You could respond with HTTP/1.0 and close connection. You could split movie 
into separate video files and hide that fact in the player's UI (sort-of like 
Apple's HTTP live streaming).

-- 
regards, Kornel

Re: [whatwg] HTML 5 : The Youtube response

[Kornel Lesinski]

> 
> I believe we can allow arbitrary content to go fullscreen, along the lines of 
> what Robert O'Callahan has proposed on this list, if we impose sufficient 
> restrictions to mitigate the above risks. In my opinion, the following 
> measures would likely be sufficient:
> 
> A) Have a distinctive animated sequence when an element goes into full-screen 
> mode. This helps the user understand what happened.
> B) Limit the ability to go fullscreen to user gestures, much as many browsers 
> limit pop-ups. This prevents shenanigans from happening while the user is 
> away from the keyboard, and greatly limits the potential annoyance factor.
> C) On systems with keyboard/mouse input, limit the keys that may be processed 
> by fullscreen content to a small set, such as the set that Flash limits to in 
> full-screen mode: 
> .
> D) On multitouch devices with an onscreen keyboard as the normal means of 
> input, things are trickier, because it's possible for a dedicated attacker to 
> simulate the keyboard. My best idea is make sure that a visually distinctive 
> status indicator appears at the top of the screen even in full-screen mode, 
> since that is the norm on such platforms.
> E) Reserve one or more obvious key combinations to exiting fullscreen no 
> matter what (Escape, perhaps Cmd+W/Ctrl+W).
> F) Even on keyboard/mouse type systems, have some distinctive visual 
> affordance which is either always present or appears on mouse moves, and 
> which allows the user to exit full-screen mode.
> 
> I think these measures greatly mitigate risks (1) and (2) above, and open up 
> highly valued functionality (full screen video) with a UI that users will 
> enjoy, and customizability that video hosting sites will appreciate.

Another option (for low-res videos on desktop) might be to use lower screen 
resolution when in full screen — text and UI elements displayed by attacker 
will look noticeably different.

-- 
regards, Kornel

Re: [whatwg] Allowing ">" in attribute values

[Kornel Lesinski]

> A agree disallowing ">" chars in attributes greatly simplifies parsing. Not
> only with regular expressions, but any parsing.
> If ">" are allowed, it means that in order to found the end of the element
> you do have to read all attributes before. This is very costy.

You just need two extra states in the parser (toggled on " or '). I wouldn't 
call that "very costly".

> Just an
> example but they are many others:  let's image you'd like to convert an HTML
> document into flat text. To simplify you're algorithm you've chosen  to
> retrieve the content of the  element and then to delete all elements
> in it. This is very fast if ">" are not allowed in attributes because you're
> able found elements bounds just by searching "<" and then ">".  But if ">"
> are allowed, the operation gets much more complicated, and you spend much
> more time to scan all elements.

Conversion of HTML to text is more complicated than that - e.g. you shouldn't 
turn foobar into foobar, but you have to keep foobar as foobar. Implied 
 is allowed, you should extract , you have to decode entities, 
etc. I think check for a single character is just a drop in the ocean in such 
code.

And if you're not concerned about accuracy of conversion, you can ignore the 
fact that ">" is allowed too. It's just going to be yet another tradeoff among 
many other, much bigger ones.

>> Also take into consideration that even if ">" was forbidden in the spec,
> it wouldn't mean it doesn't happen in
>> the wild. Since it works in browsers, you'd still have to support it if
> you wanted to parse markup from the web. 
> 
> Allowing it in the spec and how the browser should  behave if it is anyway
> are two different things.

If you're parsing markup from the web, you have to support invalid markup that 
browsers accept, not merely pure markup that spec allows.

There are reasons to disallow ">", but I'm not convinced that parsing 
performance is one of them.

-- 
regards, Kornel

Re: [whatwg] Allowing ">" in attribute values

[Kornel Lesinski]

On 24 Jun 2010, at 14:11, Benjamin M. Schwartz wrote:

>> Why would it simplify parsing?
> 
> It greatly simplifies parsing when you just want to extract entire tags,
> without immediately parsing the attributes.

If you mean "parsing" with regular expressions, then I think that's a bad 
practice and shouldn't be encouraged. 

Also take into consideration that even if ">" was forbidden in the spec, it 
wouldn't mean it doesn't happen in the wild. Since it works in browsers, you'd 
still have to support it if you wanted to parse markup from the web. OTOH if 
you want to parse only markup that is under your control, you can self-impose 
that restriction.

However, I see other argument against allowing ">" in attributes: it helps to 
catch unclosed attributes early:

Re: [whatwg] Form validation against invisible controls

[Kornel Lesinski]

On Mon, 14 Jun 2010 08:44:09 +0100, Jonas Sicking  wrote:


Agreed on both accounts. Both these suggestions add a lot of
complexity to the platform and we should avoid it if at all possible.
To the extent that if there is lots of broken sites out there because
they happen to use attribute names that collide with HTML5, but only
partially match the HTML5 behavior, then we should consider renaming
those attributes in HTML5.


I don't agree that there are "lots" of broken sites. My main browser is  
Opera and I haven't noticed that problem yet.


The fact that there are some sites using 'required' attribute proves that  
it's a good, intuitive name.


HTML5 is likely to outlive those broken sites. I think it would be shame  
to change to worse name for HTML's lifetime just to avoid temporary  
problem with some sites.


--
regards, Kornel Lesiński

Re: [whatwg] Is there a way to stop scrolling when pressing directional arrows?

[Kornel Lesinski]

On Mon, 14 Jun 2010 20:38:07 +0100, Carlos Andrés Solís  
 wrote:


Hello! I've been noticing a problem in many HTML5 test apps, very  
especially games. When the directional arrow buttons are pressed, the  
screen scrolls.
This is a problem that, as far as I know, Flash had solved by changing  
the focus of the application to the app. Is this doable in HTML5?


Yes. It's possible already — page just has to return false from keypress  
handler:


window.onkeypress = function(){return false}

That's just one line that, unfortunately, many web-based games forget to  
include.


--
regards, Kornel Lesiński

Re: [whatwg] WebSockets: UDP

[Kornel Lesinski]

On 1 Jun 2010, at 11:12, Erik Möller wrote:

> The use case I'd like to address in this post is Real-time client/server 
> games.
> 
> The majority of the on-line games of today use a client/server model over UDP 
> and we should try to give game developers the tools they require to create 
> browser based games. For many simpler games a TCP based protocol is exactly 
> what's needed but for most real-time games a UDP based protocol is a 
> requirement. Games typically send small updates to its server at 20-30Hz over 
> UDP and can with the help of entity interpolation and if required entity 
> extrapolation cope well with intermittent packet loss. When a packet loss 
> occur in a TCP based protocol the entire stream of data is held up until the 
> packet is resent meaning a game would have to revert to entity extrapolation 
> possibly over several seconds, leading to an unacceptable gameplay experience.
> 
> It seems to me the WebSocket interface can be easily modified to cope with 
> UDP sockets (a wsd: scheme perhaps?) and it sounds like a good idea to 
> leverage the work already done for WebSockets in terms of interface and 
> framing.
> 
> The most important distinction between ws: and wsd: is that messages sent by 
> send() in wsd: need not be acknowledged by the peer nor be resent. To keep 
> the interface the same to the largest possible extent I'd suggest 
> implementing a simple reliable 3-way handshake over UDP, keep-alive messages 
> (and timeouts) and reliable close frames. If these are implemented right the 
> interface in it's entirety could be kept. Only one new readonly attribute 
> long maxMessageSize could be introduced to describe the min path MTU (perhaps 
> only valid once in connected mode, or perhaps set to 0 or 576 initially and 
> updated once in connected mode). This attribute could also be useful to 
> expose in ws: and wss: but in that case be set to the internal limit of the 
> browser / server.

SCTP would be ideal for this. It's connection-oriented, but supports 
multistreaming (can deliver messages out of order, without head of line 
blocking).

http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol

-- 
regards, Kornel

Re: [whatwg] Image resize API proposal

[Kornel Lesinski]

On 24 May 2010, at 22:09, David Levin wrote:

> > that even if it was implemented everywhere, this solution involves readback
> > from the GPU which, as Chris mentioned, is generally evil and should be
> > avoided at all costs.
> 
> This I'm not qualified to comment on, though.  To the best of my
> knowledge, GPUs are magical boxes that make things go faster via pixie
> dust.  ;)
> 
> Thanks for your opinion. :)
> 
> Chris is qualified so are other people whom I've spoken to who have said the 
> same thing, so using the gpu is not pixie dust in this particular scenario 
> even though folks would like to be believe it so.

I think GPU readback is a red herring. It's an operation that takes 
milliseconds. It's "slow" for realtime graphics, but it's not something that 
user is going to notice when uploading images — users are not uploading 
hundreds of images per second.

If UA can parallelize decoding, scaling, encoding and sending, the operation 
can be very fast and memory-efficient, even if scaling is done very slowly (it 
won't have noticeable impact as long as it's not slower than uploading).

JPEG can be efficiently decoded at fraction of its size — without full decode 
and scale process. This process also needs only fraction of memory required for 
full scaling, which might matter on low-end mobile devices. Letting UA utilize 
this feature may give huge performance gains.

Scaling isn't the only operation desirable — in some cases users might also 
want to crop the image (e.g., to upload only their face as an avatar), and 
cropping interface needs to be platform-specific — on touchscreen devices I'd 
rather use gestures than select-by-click'n'drag interface typical for desktop. 

I think scaling of images before upload might be left completely up to UA. From 
site's perspective it could look like user simply selected scaled-down file. It 
could even be done declaratively — site could define desired size and whether 
user should be asked to crop the image:



Actually, I wish UAs offered scaling even for plain , because 
I don't expect every site with image upload to add extra code for resizing.

-- 
regards, Kornel

Re: [whatwg] RFC:

[Kornel Lesinski]

On 4 May 2010, at 09:07, timeless wrote:

> On Tue, May 4, 2010 at 10:08 AM, Eitan Adler  wrote:
>> 3) Currently autofill for usernames looks for something like
>> id="username" or name="username". However on certain websites this
>> fails.
> 
> Why would a site which doesn't cooperate with today's autofill
> features choose to cooperate with your proposal?

Sites may not work correctly with autofill because their login forms are too 
complex or confusing the auto-fill feature (and sometimes login forms are 
complex/unusual – users may have option to log in to different sections of the 
site, with different security options).

I don't think type=username is good solution, but I agree that autofill needs 
help. Sites often use e-mail address as login. There would be conflict between 
type=email and type=username.

I have wiki that has password field on edit page (you don't log in before 
starting an edit, you simply type password before submitting the change). It 
completely confuses Opera's autofill which tries to save page title field as 
login name.

Perhaps new values for autocomplete attribute would do the trick? 
autocomplete=login, autocomplete=not-login? (latter meaning you can 
autocomplete, but don't autofill when logging in).

It would be nice to have autodiscovery for OpenID logins: ? autocomplete=openid?

Another problem is the same login form appearing in multiple places on the site 
(usually slighly different form is part of site's layout, and different one is 
presented when user is forced to log in). Sometimes autofill sees such forms as 
same, and sometimes it doesn't. Auto-fill information is often lost when sites 
are redesigned.

It would be nice if autofill could remember values from registration form and 
automatically use them for logging in. Users usually aren't asked to log in 
after registering, so there's no opportunity for the browser to save login 
details immediately.

For this something like "Realm" value in HTTP auth would be helpful (perhaps as 
an attribute on  or ). Same realm across different forms would 
allow browser to save same details for all of them.

-- 
regards, Kornel

Re: [whatwg] Form-based HTTP Authentication Proof of Concept

[Kornel Lesinski]

On Thu, 25 Feb 2010 16:00:37 -, Timothy D. Morgan  
 wrote:



As a follow up to my paper advocating HTTP authentication over
cookies [1], I've built a simple sample application which demonstrates
how a combination of XMLHttpRequest and response code tricks can be
used to achieve form-based login, logout, and authenticated password
changes in the four most popular browsers:
  http://www.vsecurity.com/download/tools/fbha-poc_0.1.zip

Note that this is achieved without using any checks to determine what
browser is being used.

While this is promising, I still think we should have an HTTP-based
log out mechanism.  In addition, the proposed W3C change to
XMLHttpRequest authentication behavior will make this code much
simpler.


FIY a while ago I've implemented proof-of-concept as well, but by using  
URLs with login/password:


http://geekhood.net/auth/

Those two approaches combined could offer solution with good user  
experience and working non-JS fallback.


--
regards, Kornel Lesiński

Re: [whatwg] Suddenly, ~40% of IE users get HTML5 Theora with no effort

[Kornel Lesinski]

On Fri, 05 Feb 2010 20:47:35 -, David Gerard  wrote:


http://www.atoker.com/blog/2010/02/04/html5-theora-video-codec-for-silverlight/
http://arstechnica.com/open-source/news/2010/02/nuanti-brings-html5-and-ogg-theora-video-to-silverlight.ars

The 40% is from the blog post at the top.


There's also Cortado Theora player which can work for those who don't have  
Silverlight, but have Java.


I've tested it - it's good enough for small videos (too slow for HD  
unfortunately) and can be used to implement basic  interface.


--
regards, Kornel Lesiński

Re: [whatwg] some thoughts on sandboxed IFRAMEs

[Kornel Lesinski]

On 5 Feb 2010, at 14:19, Lachlan Hunt wrote:

>> where $token is the random part. This avoids oddity of attributes in
>> closing tag, and is compatible with XML. In XML you could also use:
>> 
>> <$token:sandbox xmlns:$token="…">
> 
> No, you couldn't use a namespace like that, because then the sandbox element 
> would not be in the HTML namespace, and thus would not have any known 
> semantics.


Eh, I've left out namespace URI, because I don't like to type it. Here's 
complete example that applies HTML semantics:

http://www.w3.org/1999/xhtml";>
  http://www.w3.org/1999/xhtml";>
  HTML
 


-- 
regards, Kornel

Re: [whatwg] some thoughts on sandboxed IFRAMEs

[Kornel Lesinski]

On 4 Feb 2010, at 17:44, Michal Zalewski wrote:
>> 
>> If there's no HTML, there's no need for a sandbox, so the simplest
>> solution is just to escape the  
> Which people fail at, big time. There are 50,000+ entries on
> xssed.com, many of them against big sites presumably developed by
> skilled developers with the help of sophisticated frameworks -
> microsoft.com, google.com, amazon.com, ebay.com, etc. It is a really
> low-effort tweak to accommodate it here, and it may offer a very
> significant security benefit, so...?

The problem comes from lack of escaping of any kind, so change in escaping 
method will not fix the problem, i.e.,

Hello $unescaped_name

is as vulnerable as:

Hello 

> I think the difference is huge; in a typical web framework, you need
> to explicitly escape every single piece of potentially dangerous
> attacker-controlled input to stay safe - and because people tend to do
> some validation at input stage, it's very difficult to audit for it.
> Escaping also needs to be very different depending on the context
> (URLs need to be encoded differently than HTML parameters, and
> differently than standalone text).
> 
> So even though your framework may provide several escape() functions,
> it's very easy to get it wrong, and people constantly do. OTOH, if
> your framework provides a get_token() function, there's really not
> that much to using it properly.

That's problem with the frameworks (a big one, admittedly). However, there are 
templating engines that escape all variables, everywhere, by default, and this 
solves the problem very well.

Addition of token-based sandbox won't improve anything in cases where authors 
forget to escape or wrongly assume that input is already filtered/escaped or 
harmless. If someone forgets to add escape(), why would they remember to add 
? Additionally  will cause new security problem in all 
current UAs, so for plain text I don't see any benefit at all.

However, if we're going to introduce token-based sandbox anyway, I suggest 
putting token in tag name:

...

where $token is the random part. This avoids oddity of attributes in closing 
tag, and is compatible with XML. In XML you could also use:

<$token:sandbox xmlns:$token="…">

-- 
regards, Kornel Lesiński

Re: [whatwg] window.print() when printing is not supported

[Kornel Lesinski]

On Mon, 28 Dec 2009 11:54:00 -, Olli Pettay   
wrote:


So I think it *might* make sense to throw some error if printing isn't  
supported. Or should browsers which don't support window.print() just
not have print() method in the window object? (problem is that I'd guess  
everyone just expects .print() to be there)



Why would page need to know if printing works? What (useful) thing could  
it do if it detects failed print?


If all you want is to display error when printing fails, that's a UA  
issue. Why burden all sites with handling of error they can't fix? UA can  
signal the error, and can do it better, e.g. offer option to configure a  
printer.



I'm afraid that even letting pages know whether printing is available  
might have negative consequences.


I can't print anything from computer I'm using at the moment, BUT if I  
need to print something, I can save page/document and print it from  
another computer. If pages could detect that my computer can't print, they  
could wrongly assume I can't print anything at all, and hide print-related  
options from me. I'd hate if ticket sites automatically decided to  
snail-mail me tickets without offering option to print them myself.


--
regards, Kornel Lesinski

Re: [whatwg] functionality absorbed into ?

[Kornel Lesinski]

On Sun, 18 Oct 2009 08:54:59 +0100, Ian Hickson  wrote:


Your version with split  seems to use it only for visual effect.


Not just visual, but presentational, yes, pretty much. It also makes it
clear how to generate the outline.


I don't understand how presentational s make outline clear. I thought  
they're an exception that didn't work simple outline algorithm:


http://validator.w3.org/check?uri=http%3A%2F%2Fwww.w3.org%2FTR%2Fhtml5%2F&outline=1#outlineresult

and  exists to resolve ambiguity caused by presentational use of  
headers.



I still think that  (subheader, tagline) would be just as
effective, less confusing and less likely to break outline when used
improperly...


How is  confusing?


 alone isn't.  is the source of confusion.

* Difference between  and  is not obvious. It wasn't to me  
when I first saw them, and this isn't first thread about them.
* Makes meaning of  overloaded (sometimes it's a header that affects  
outline and level or other headers, sometimes it's a subheader that  
doesn't do anything that header would).


Have you seen this post? http://www.onderhond.com/blog/work/the-hgroup-tag  
I think it sums up problems quite well.


I think something like  is just as likely to be misused as  
, to be honest.


Sure, but it's much more fail-safe. If you use  instead of  
 or fail to use , you may significantly change structure  
of the document.


You can't make much damage with . Sections will remain correct  
and at worst you'll add wrong subtitles to headers.



My proposal for processing of :

* look for first  preceeding  in tree order (depth-first  
starting with last child) [makes any  after  work]
* abort and ignore subheader when search crosses section boundaries  
[prevents misplaced  from being associated with wrong section].


Optionally:
* if  is an ancestor of , associate subheader with that  
header


The last rule allows:

The magnificent HTML 5 specification

which addresses one of use cases you've mentioned a while ago when  
 was discussed.



Also, it has a much poorer legacy (backwards compatibility) story.


Both solutions have problems. I don't think ones are much worse than the  
others.  breaks the outline,  is ignored. Without CSS  
s will be too large and have too big margins.  will not get  
special rendering, but at least will look like block element ( and   
typically surrounding it will cause this). One might use   
if non-CSS display is a concern.


With CSS  will work fine and doesn't limit styling  
possibilities. 's content model doesn't allow any non-header  
elements, so one can't add any extra hooks for styling:



  
  


  



Another thing - can you write XPath query that extracts all headers from  
the document? Without  it's simple. With  I'm not sure if  
I could manage to write correct query.


--
regards, Kornel Lesinski

Re: [whatwg] Make quoted attributes a conformance criteria

[Kornel Lesinski]

On Thu, 23 Jul 2009 19:32:28 +0100, Eduard Pascual 
wrote:


I don't think there's any value in having the spec take a stance like
this.  It's a matter of taste, IMO.


While I don't consider a hard requirement would be appropriate, there
is an audience sector this discussion seems to be ignoring: Authoring
Tools' developers. IMO, it would be highly desirable to have some
guidelines for these tools to determine when they *should* quote
attribute values.


I think this requirement is even less relevant for authoring tools:

   * It's not a problem for tools to use unquoted attributes in a  
perfectly safe manner.
   * Not all code generated by tools is intended to be edited by humans,  
and in such cases shorter code is likely to be preferred over  
human-readable code.
   * Tools that offer editing of HTML source code may (and often do) have  
syntax highlighting and validation.


--
regards, Kornel Lesinski

Re: [whatwg] input type="url" allow URLs without http:// prefix

[Kornel Lesinski]

On Sun, 12 Jul 2009 09:46:19 +0100, Bruce Lawson  wrote:

As it's very common for people to drop the http:// prefix on  
advertising, business cards etc (and who amongst us reads out the prefix  
when reading a URL on the phone?) I'd like to suggest that input  
type="url" allows the http:// prefix to be optional on input and, if  
ommitted, be assumed when parsing.


The spec explicitly allows that actual value seen and edited by the user  
in the interface is different from DOM value of the input, so browsers are  
free to prepend http:// automatically (and IMHO should – DSK-253195).


--
regards, Kornel Lesinski

Re: [whatwg] consideration

[Kornel Lesinski]

On Tue, 16 Jun 2009 11:51:05 +0100, Aryeh Gregor  
 wrote:


 is a very poor solution, and  would be too. You  
should use graceful degradation/progressive enhancement instead (in  
both cases).


Graceful degradation is not necessarily possible with JavaScript.  For
instance, consider a real-time game written in JavaScript.


True, but  doesn't allow implementation of games either.

What matters is cases where fallback is possible, and where   
would improve it.



Sometimes  can be used for graceful fallback, too.  For
instance, if a script normally generates an element dynamically when
needed, the element might be placed statically inside  so
that it always appears if script is disabled.  (For instance, a
"Nationality" form in a field that only appears if a radio control is
changed from the default of "U.S. Citizen".)  Without , the
only way I know of to allow graceful fallback is to do something like
hide the element onload, which will make it briefly visible.


It doesn't have to be briefly visible. Don't use onload, but an inline  
script:



document.getElementById('hideme').hidden = true
(in)visible content…



If your page uses DHTML a lot, and has fallback in many places, there's  
nice trick for it:



document.documentElement.className += " script-supported"
.script-supported .dhtml-fallback {display:none}

--
regards, Kornel Lesinski

Re: [whatwg] consideration

[Kornel Lesinski]

On Mon, 15 Jun 2009 21:26:21 +0100, Thomas Powell   
wrote:



1) Head Usage


 



2) Body Usage


 Warning: Styles required for correct rendering



Purpose of this element seems to make lack of CSS "not my problem" instead  
of providing meaningful alternative.


This is not helpful for users without CSS. It only helps authors to  
discriminate against them, and I'm strongly against it.



Comments?


 is a very poor solution, and  would be too. You should  
use graceful degradation/progressive enhancement instead (in both cases).


--
regards, Kornel Lesinski

Re: [whatwg] Question on (new) header and hgroup

[Kornel Lesinski]

On Sat, 06 Jun 2009 04:00:28 +0100, Ian Hickson  wrote:


I don't think  will be used often enough to justify calling it
just .


Ok, but what about ? (, ?)

The purpose of  is to imply that  is a subtitle. That's quite  
an indirection. An explicit element would be easier to understand:


Dr. Strangelove
Or: How I Learned to Stop Worrying and Love the Bomb

Also it could accept only phrasing content, so it would be easier for  
validators to catch when authors confuse it with .


It doesn't require changes to styling of , and can be given  
appropriate size with "h1 + subheader" CSS selector.


--
regards, Kornel Lesinski

Re: [whatwg] page refresh and resubmitting POST state

[Kornel Lesinski]

On Sun, 24 May 2009 17:40:21 +0100, Mike Wilson  wrote:

> Aryeh Gregor wrote:
>> You should spell out the existing problem carefully  and in
>> great detail, including existing solutions or workarounds, to
>> get the best response.
>
> I certainly intend to do this once I get feedback on whether
> this subject is relevant for HTML5, or any other whatwg spec
> (preferrably from people involved in authoring these). Time
> is limited and I would like to only spend this effort if
> applicable to spec work.

It depends what solution is chosen - browser behaviors and HTML 
elements/attributes are in scope of HTML 5, but HTTP methods and headers not so 
much.

>> I don't think refresh is a big deal.
>
> I've been using refresh/resubmit as an easy example so that
> everybody knows what I am talking about. 

Hm, now I don't :) 

Can you re-state the problem you want to be solved? I thought you wanted to 
avoid browsers asking question whether they should re-submit POST.

> When/if this subject seems to relate to the HTML5 effort, I would like to 
> contribute to a larger discussion on these kinds of topics.

If the problem affects web applications and browsers, then that's probably good 
place to discuss it.

-- 
regards, Kornel Lesinski

Re: [whatwg] page refresh and resubmitting POST state

[Kornel Lesinski]

On Sun, 24 May 2009 16:50:38 +0100, Aryeh Gregor  
wrote:

>> Is it possible for HTML 5 spec to say that browsers may re-send PUT  
>> without asking? (and that authors should use PUT only when resending is  
>> not going to cause this problems).
>
> When would that be?

When application is protected against it, e.g. includes version or timestamp as 
part of request and is able to reject or merge conflicting requests.

However I've re-read definition of PUT, and I'm not sure anymore if that's a 
good solution:

> the user agent knows what URI is intended and the server MUST NOT attempt to 
> apply the request to some other resource. 

This makes it inappropriate for role of "idempotent POST" (e.g. it would be 
wrong to use PUT for login form, although login is idempotent action), 
therefore I'm leaning towards opinion that another solution may be needed.

-- 
regards, Kornel Lesinski

Re: [whatwg] page refresh and resubmitting POST state

[Kornel Lesinski]

On Sun, 24 May 2009 15:41:12 +0100, Aryeh Gregor  
 wrote:

>> This problem can be elegantly solved within existing standards: Opera  
>> simply goes back in history without resubmitting forms, and resubmits  
>> only when user clicks standard Reload button (or F5, etc.)
>
> Firefox does that too, at least in 3.5b4pre.  But this solution only
> works if the page is still in the browser's history cache.  Browsers
> can't keep pages in their cache forever -- it fills up and needs to be
> emptied.

It only needs to keep it as long as Back history is kept, and could get  
rid of it as soon as this entry is removed from Back/Forward history.

>> * If it's not safe to resubmit, use status 303. I know it's not very  
>> convenient, but can be implemented reasonably well and works with  
>> existing browsers.
>
> The problem is that since HTTP is stateless, you don't have the data
> available to show a confirmation page.

You store the data on server side, and redirect to URL that contains  
unique ID for this data.

It's just a few lines in PHP (and similar solutions shuold be possible in all 
web frameworks):

$id = uniqid();
$_SESSION[$id] = $_POST;
header("Location: […]/result.php?id=$id",false,303);

and later:

$_POST = $_SESSION[$_GET['id']];

This works even for multiple submissions done in parallel and it's pretty  
secure and tamper-proof.

>> * If it's safe to resubmit, use PUT method (allowed in HTML 5), which  
>> is idempotent by definition.
>
> Theoretically, but not really in practice.  Someone else might have
> PUT something new at the URL since your last PUT, or DELETEd it, or
> otherwise done something to it.  In that case, you'd overwrite their
> modifications.  PUT is only practically idempotent if only one user is
> modifying the resource, as far as I can tell.

That's a good point.

Is it possible for HTML 5 spec to say that browsers may re-send PUT without 
asking? (and that authors should use PUT only when resending is not going to 
cause this problems).

-- 
regards, Kornel Lesinski

Re: [whatwg] page refresh and resubmitting POST state

[Kornel Lesinski]

On Sat, 23 May 2009 15:38:02 +0100, Mike Wilson  wrote:

>> Do you think that solution suggested by RFC 2616 13.13 is not
>> appropriate?
>
> It does not define what to do at page refresh, only history
> traversal, as far as I can see.

Sorry, I've assumed you were talking about Back button only.

In case of Refresh it depends whether user realizes implications of 
re-submitting. If browser designers don't believe that pressing Refresh button 
states intent clearly enough, then I think asking the question might be 
justified.

As creator of application you can solve this dylemma:

* If it's not safe to resubmit, use status 303. I know it's not very 
convenient, but can be implemented reasonably well and works with existing 
browsers.
* If it's safe to resubmit, use PUT method (allowed in HTML 5), which is 
idempotent by definition.

-- 
regards, Kornel Lesinski

Re: [whatwg] page refresh and resubmitting POST state

[Kornel Lesinski]

On Sat, 23 May 2009 12:29:56 +0100, Mike Wilson   
wrote:

> I was thinking about the resubmit problem in a general
> context, specifically how browsers could make it possible
> for web authors to create POSTing pages that avoids giving
> the dreaded "do you want to resubmit" question at all,
> independent of operation.

Browsers could make it possible by implementing history mechanism exactly like 
HTTP/1.1 specification suggests in section 13.13, i.e. going back in history 
should never cause resubmits, so there shouldn't be anything to ask about. 
Users should simply see previous state of the page, just like in case of GET.

Do you think that solution suggested by RFC 2616 13.13 is not appropriate?

Is Opera's solution of this problem not good enough?

-- 
regards, Kornel Lesinski

Re: [whatwg] Removing the need for separate feeds

[Kornel Lesinski]

On Fri, 22 May 2009 07:01:51 +0100, Ian Hickson  wrote:

> It doesn't collect the blogroll or the blog post tags yet, mostly because
> I'm not sure how to do that. Any suggestions of improvements are  
> naturally welcome.

There's hAtom that solves this problem already, and appears to have been 
proliferated by popular blogging software:
http://search.yahoo.com/search?p=searchmonkeyid%3Acom.yahoo.page.uf.hatom

but I doubt that many users take advantage of it. Almost all of these pages 
have standard feeds as well (and all of them can provide them via hAtom2Atom 
proxy).

Maybe a better approach would be to extend hAtom or define extraction in terms 
of hAtom? (e.g. make  and  interchangeable?)


> For each article element article that does not have an ancestor article 
> element

That excludes possibility of syndicating article's comments from markup like 
this:



post
comment
comment



Feed with only single entry "post" or "post comment comment" would not be 
useful.

OTOH it may be useful to include all nested comments in a single feed:

comment
comment reply



Another problem is that algorithm cannot create . Perhaps  
could be assumed if there's alternate link and article doesn't contain more 
than one header? Or has entire contents wrapped in ?


I haven't noticed any way to exclude articles from the feed (except hack 
...). I may have news that's not 
important enough to justify notification of all subscribers. Are trackbacks and 
tweets appropriate for ? I might want to show them on my page, but 
wouldn't want to repost them in my feeds.

-- 
regards, Kornel Lesinski

Re: [whatwg] Removing the need for separate feeds

[Kornel Lesinski]

On Fri, 22 May 2009 09:41:43 +0100, Eduard Pascual  wrote:

> For manually authored pages and feeds things would be different; but
> are there really a significant ammount of such cases out there? I
> can't say I have seen the entire web (who can?), but among what I have
> seen, I have never encountered any hand authored feed, except for code
> examples and similar "experimental" stuff.

I maintain hand-authored Atom feeds on few websites. It's not a problem if 
feeds are updated rarely. On websites without CMS copying&pasting few tags once 
a month feels like less work than moving website to a CMS or writing XSLT :)

Despite that I'm not excited about Ian's proposal. In these scenarios I often 
want content of the feed to be different than content of the page, e.g. feed 
says "I've added article about Foo.", but page has "Newest articles: Foo, Bar, 
Baz."

-- 
regards, Kornel Lesinski

Re: [whatwg] page refresh and resubmitting POST state

[Kornel Lesinski]

On Fri, 22 May 2009 21:48:28 +0100, Mike Wilson  wrote:

> Thanks for expanding on my previous mail, Jonas, but I was assuming
> that everyone on this list was aware of the PRG pattern and its
> existing support in browsers.
>
> With current technology there are limitations to the usefulness of
> PRG (f ex in multi-window/tab scenarios), so I am asking if it is
> within HTML5's scope to explore improved or alternative solutions
> to the "resubmit" problem.

As far as I understand the "resubmit problem" is just sign of poor 
implementation that violates SHOULD NOT in the HTTP RFC:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13

This problem can be elegantly solved within existing standards: Opera simply 
goes back in history without resubmitting forms, and resubmits only when user 
clicks standard Reload button (or F5, etc.)

-- 
regards, Kornel Lesinski

Re: [whatwg] Question on (new) header and hgroup

[Kornel Lesinski]

These new elements weren't clear to me initially either.

Maybe instead of:

HTML 5
a new era of loveliness

We should introduce  or  elements?

HTML 5
a new era of loveliness

or perhaps stepping a little on XHTML2's toes isn't that bad and  can 
be renamed to :


HTML 5
a new era of loveliness


-- 
regards, Kornel Lesinski

Re: [whatwg] /RemoteEventSource wierdness

[Kornel Lesinski]

On 18 Feb 2009, at 06:53, Jonas Sicking wrote:


This could also replace the IMHO awkward  element. I
don't understand the value of having this element at all. It seems to
me that if the only way you can use an API is through script, then
making the API into an element is adding extra complexity to the HTML
language for little to no gain.


I agree with that one. I don't see any reason why sources need to be  
declared in HTML (sources are site-specific and useful only with JS  
enabled, so non-JS clients, bots, etc. don't need to know about them).



Finally, I do question the need for this API at all.



I like the concept and find it useful. I think existence of Comet[1]  
is a proof that such feature is desired, even without support for SMS.


Implementation of Comet via XHR is tricky, especially robust error  
handling is difficult. JS libraries can't have best implementation of  
event streams, because JS doesn't have enough control over network  
connections (e.g. can't bypass proxy if it doesn't handle long-lived  
connections well). Native browser implementations can excel here.


One key feature that IMHO is needed in this area is sharing of events  
between pages/windows - e.g. page with stock ticker doesn't need  
separate stream for every page in every window. One permanent  
connection shared between windows and kept alive between page reloads  
would be sufficient, and would save both client and server resources  
and wouldn't have problems with HTTP/1.1 connections limit.


1. I think that such feature is needed and event source should be kept  
in some form.
2. I wouldn't mind if event source API was redesigned, made JS-only  
(without DOM), moved to separate specification or merged with XHR/web  
sockets.

3. Connection sharing is needed to make it a killer feature.

--
regards, Kornel

[1] http://en.wikipedia.org/wiki/Comet_(programming)

Re: [whatwg] Solving the login/logout problem in HTML

[Kornel Lesinski]

I've prepared proof-of-concept of an alternate solution that reuses  
existing HTTP authentication:


http://geekhood.net/auth/

In essence this works by translating HTML form into URL in format  
http://user:[EMAIL PROTECTED] (it can be done using JS or HTTP redirect.  
Ideally, this would be done by the browser based on  attribute or  
such).


--
regards, Kornel Lesinski

Re: [whatwg] Solving the login/logout problem in HTML

[Kornel Lesinski]

On Tue, 25 Nov 2008 05:26:47 -, Ian Hickson <[EMAIL PROTECTED]> wrote:


http://www.w3.org/TR/1999/NOTE-authentform-19990203

[...]

I don't really understand what problem the above solves that isn't solved
better by SSL.


I agree that if real security is desired, SSL is the only way to go.
However given that most login forms on the web send passwords in the
clear, other problems were more important than security.

Form + Digest avoids these SSL problems:

* Does not negatively impact performance. In TLS handshake lots of  
messages are going back and forth, so this can't be fixed by beefing up  
servers' CPUs.
* Does not need access to server's configuration, and generation,  
installation and renewal of certificates. Redistributable software can  
support it out of the box, on almost any server, without manual  
installation steps.


Additionally, it's better than new "WWW-Authenticate: HTML" authentication  
mechanism:


* It's compatible with existing non-HTML HTTP clients.
* Although its security is weak compared to SSL, it's a step up from forms  
+ cookies.
* It's easier to sell: "It will allow bots to log in" doesn't sound very  
desirable. "It will protect your users' passwords against passive  
eavesdropping" sounds better.


I don't think "WWW-Authenticate: HTML" is a significant improvement. It  
doesn't offer anything to existing websites/browsers. It's primarily  
targetted for non-browser UAs, but it's not compatible with them.
If UAs are required to parse HTML, they could as well look for form with a  
single password field.


--
regards, Kornel Lesinski

Re: [whatwg] Absent rev?

[Kornel Lesinski]

On Wed, 19 Nov 2008 17:26:17 -, Tab Atkins Jr. <[EMAIL PROTECTED]>  
wrote:


Finally we come to the ones that I can't otherwise categorize.  I'll  
just go ahead and list them directly:

  3 


Apropos vote-for, even specification of this Microformat confused rel with  
rev (and so did I when I first tried to use vote links, even though I'd  
read corrected version of the spec):

http://microformats.org/wiki/vote-links

There's also relevant entry on Microformat blog:
It seems that everytime I present microformats, I need to explain the  
difference bettween the rel and rev attributes.

http://microformats.org/blog/2005/12/01/rel-vs-rev/

and finally use of rev has been deprecated in Microformats:
http://microformats.org/wiki/rel-faq#Should_rev_even_be_used

--
regards, Kornel Lesinski

Re: [whatwg] fixing the authentication problem

[Kornel Lesinski]

You're re-inventing Digest authentication (RFC 2617).

Digest has two-way authentication with hashed challenge-response, nonces,  
can use passwords stored as hashes (though not as secure as storage for  
plaintext auth), avoids insecurity of cookies and even has simple data  
integrity verification.


...and it's all futile if attacker can modify a single byte sent over the  
network.


Anyway, it doesn't make sense to duplicate all that functionality in forms  
just because typical interface for HTTP authentication is ugly and  
unusable. You can fix the interface, and there's proposal for it already  
(from 1999!):

http://www.w3.org/TR/NOTE-authentform

I think that proposal is generally a good idea, but the details could be  
improved (i.e. should reuse existing forms and input types rather than  
creating new ones that can't offer seamless fallback).


--
regards, Kornel Lesinski

Re: [whatwg] a and button

[Kornel Lesinski]

On Sun, 19 Oct 2008 16:09:11 +0100, Håkon Wium Lie <[EMAIL PROTECTED]>  
wrote:



 > W3C

It's not a link. I'd like for buttons to work as links so that they
take me to a page when I click on them.


http://www.w3.org/TR/css3-ui/#appearance

a {appearance: button} should do that.

In current browsers:



is very close to a link.

--
regards, Kornel Lesinski

Re: [whatwg] Placeholder option for text input boxes

[Kornel Lesinski]

On Sun, 05 Oct 2008 19:16:14 +0100, Kristof Zelechovski  
<[EMAIL PROTECTED]> wrote:



I think it is rather uncommon that the value entered into a search field
needs a hint about what format it should be in.  The search engine  
should be smart enough to figure out what the user was looking for.


What I had in mind was use of placeholder instead of , rather as a  
additional hint.




--
regards, Kornel Lesinski

Re: [whatwg] Placeholder option for text input boxes

[Kornel Lesinski]

On Sun, 05 Oct 2008 17:08:29 +0100, Keryx Web <[EMAIL PROTECTED]> wrote:

E.g.  is present on the page, but no other  
explanatory text. The user accidentally types in "". How will the  
user get the hint back? Deleting what has been typed and blurring the  
field. Good usability? I think not!


Therefore I suggest limiting placeholder to type=search.

I rarely see placeholders used in other context than search. Distinctive  
look of search input should prevent abuse of it for other kinds of inputs.


--
regards, Kornel Lesinski

Re: [whatwg] Safari-compatible

[Kornel Lesinski]

On Tue, 30 Sep 2008 12:40:23 +0100, Andy Lyttle <[EMAIL PROTECTED]> wrote:

I would like Apple's  adopted as an official  
standard, maintaining Safari compatibility.



Comments?


I like type=search.

Special search box style is used throughout Mac OS X and Mac-centric sites  
try to fake it with borderless inputs that often end up looking broken.


Windows has now a standard search box look too, so type=search would be  
good for intuitively looking search boxes across platforms.


I'm in favor of placeholder on . It may be a bad UI,  
but it is used very often regardless. Standarizing it at least gives more  
control to UAs and frees authors from writing potentially buggy scripts (I  
haven't figured out yet how to write one that's not annoying on Opera  
Mini).



I suggest ignoring onsearch and incremental attributes. They can be  
replaced with combination of oninput and onchange.


I also don't like results and autosave. They're a bit confusing (if  
autosave=yes became popular, it would cause a mess). It can be abused  
(autosave=google's + script that puts site's own keywords just before user  
submits search). Such things are best controlled by browsers/users. To  
disable autosave authors could use autocomplete=off.


--
regards, Kornel Lesinski

Re: [whatwg] The sizes="" attribute for rel=icon

[Kornel Lesinski]

On Wed, 28 May 2008 13:07:50 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:


I'm afraid that this could cause trouble (every visitor downloading icon
that's 20–300 times larger than typical favicon). Why not use
rel=application-icon or rel=appicon?


I don't understand the question.


 is currently used for favicons. Favicons are expected to  
be small (in byte size). Current browsers always download favicons on  
every website.


If page author adds high-quality image using rel=icon (like Vista's 100KB  
icon or Leopard's 300KB monstrosity), it may significantly increase site's  
traffic (these icons will be downloaded by every visitor rather than only  
those who create a shortcut).


e.g.:



In current browsers this will not work as expected - browsers will  
download the big application icon, which is going to be order of magnitude  
larger (in byte size) than a favicon.


Using rel=application-icon instead of rel=icon would avoid this problem.  
Another solution would be to suggest that authors specify favicon as last  
in the tree order (example it the spec lists favicon first).


--
regards, Kornel Lesiński

Re: [whatwg] Script, style and backwards compatibility

[Kornel Lesinski]

On Fri, 09 May 2008 00:50:20 +0100, Samuel Santos <[EMAIL PROTECTED]>  
wrote:



In order to validate a page as valid HTML/XHTML you need to escape inline

Re: [whatwg]

[Kornel Lesinski]

On Thu, 08 May 2008 03:17:38 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:


I've added a "sizes" attribute to  for the "icon" keyword.


The spec now contains:

If multiple icons are provided, the user agent must select the most  
appropriate icon according to the media and sizes attributes. If there  
are multiple equally appropriate icons, user agents must use the first  
one declared in tree order.


Does this disallow composing .ico files from multiple separate files? UAs  
like Fluid or Prism can't know which sizes OS is going to use, so all  
valid ico sizes are 'equally appropriate'.


Also this algorithm doesn't match current browser behaviour, is this  
intentional?

I did a quick test with a bunch of random favicons:
* Opera 9.5b2 loads all icons (that's pretty bad if one decides to provide  
Leopard's monsterous 300KB icons) and displays last icon loaded,
* Firefox 3b5 picks last icon regardless of attributes. It loads all icons  
when I reload page after restoring session.
* WebKit nightly and Fluid pick last icon that has type attribute (even if  
type is bogus), or just last if none have type.


I'm afraid that this could cause trouble (every visitor downloading icon  
that's 20–300 times larger than typical favicon). Why not use  
rel=application-icon or rel=appicon?


I don't like the "any" keyword. SVG icons are scallable, but it's not the  
same as being usable at any size. For example Tango icons project provides  
PNG for 16, 22 and 32px icons in addition to SVG, because lines and finer  
details in SVG become illegible at small sizes.


Does the specified size imply that UA is required to display icon at given  
size only? (i.e. is "any" obligatory to have icon scaled at all?) What if  
sizes attribute is absent?


--
regards, Kornel Lesiński

Re: [whatwg]

[Kornel Lesinski]

On Mon, 05 May 2008 23:36:51 +0100, Aaron Boodman <[EMAIL PROTECTED]> wrote:


There isn't much bandwidth to be saved. These icons are going to be
downloaded only once. 128x128 PNG icons take only 20-30kb.


Without hints as to which file contains which size, the user agent
must download up to four separate images before using them.


It doesn't have to download four images. For purpose of instant preview,  
UA can display first file it downloads.


And you don't have to use many files, because larger files can (usually)  
be scaled to smaller sizes.



Large PNG file + favicon for smallest sizes may be good enough in most
cases. In cases when icon design doesn't scale well, authors could  
provide additional .ico/.icns files.


Why should web developers have to settle for "good enough", while
desktop application developers get to create many differently sized
icons optimized for use in different contexts?


I didn't say authors have to settle for good enough. When one file isn't  
good enough, authors could provide additional ico/icns which can have best  
quality OS can handle, e.g:


 
 
 


UA could assume that ico/icns offers better quality on platform that  
supports this file format and also that this file is going to be larger  
(because it contains set of images as opposed to single image).



When website provides application icons (not favicon) in .icns or .ico
files, I think it can be reasonably assumed that these files contain all
sizes that are needed for desktop icons, and it doesn't matter which
exactly.


I don't think that ico or icns format is going to be the common case.
These formats require specialized software to create correctly,
whereas any image editor can create pngs.


There are free, open-source tools to convert between .ico and set of PNG  
images. OS X comes with Icon Composer and there's 3rd party IconBuilder  
that works on MS Windows.


Favicons in .ico format are popular and supported by all major browsers  
today.


--
regards, Kornel Lesiński

Re: [whatwg]

[Kornel Lesinski]

I don't think it's that important to specify exact icon sizes. Authors  
won't bother to accurately provide such detailed information, and  
applications don't need it anyway.


iPhone shouldn't be a concern here. It isn't limited to 59x60  
icons—Apple's own website uses 129x129  
(http://www.apple.com/apple-touch-icon.png) and current EDGE network  
iPhones won't use anything else than rel=apple-touch-icon.



My suggestion is to simply define rel=application-icon without extra  
attributes.


There isn't much bandwidth to be saved. These icons are going to be  
downloaded only once. 128x128 PNG icons take only 20-30kb.


Large PNG file + favicon for smallest sizes may be good enough in most  
cases. In cases when icon design doesn't scale well, authors could provide  
additional .ico/.icns files.


When website provides application icons (not favicon) in .icns or .ico  
files, I think it can be reasonably assumed that these files contain all  
sizes that are needed for desktop icons, and it doesn't matter which  
exactly.


--
regards, Kornel Lesiński

Re: [whatwg] Referer header sent with ?

[Kornel Lesinski]

On Tue, 12 Feb 2008 21:54:25 -, Philip Taylor <[EMAIL PROTECTED]> wrote:

It's quite a different situation when the Referer is used as a security  
measure in deciding to trust a user's request, where false negatives can  
have significant consequences (like editing data via cross-site request  
forgery). That is the situation where  mustn't introduce new  
risks.


I looked for some examples of code that checks the Referer for security,  
and found:

[...]

That's interesting. In that case attack outlined on Mozilla's list is even  
less likely to succeed than I thought. So maybe a "less abusive" approach  
would suffice:


* if ping is cross-domain, always send Referer
* if ping originates from the same domain, don't send any Referer at all

--
regards, Kornel Lesiński

Re: [whatwg] createImageData -> new ImageData() ?

[Kornel Lesinski]

On Sun, 10 Feb 2008 23:25:51 -, Ian Hickson <[EMAIL PROTECTED]> wrote:


That would mean that passing ImageData around between two 
elements doesn't always work as expected. I think that's highly
undesirable. Is there any implementation where we know this will the
case?


Not today, but why preclude it? Implementations could get higher quality
renderings on canvases that get resized dynamically, by using a bigger
backing store. What's wrong with what we have now?


It's very easy to write code which assumes that size of imageData is the  
same as size given in  (I know, because I did it :)


Since the ratio is system/browser-dependent and 200dpi screens aren't  
popular yet, such bug may be easily overlooked/ignored and get widely  
deployed.


The difference in sizes isn't intuitive. For example if browser doubled  
number of pixels in ImageData only when user used zoom, I think authors  
would rather think that browser's zoom is buggy.


I think that by default getImageData should return data with same size as  
specified in width/height attributes of . There might be another  
method (getImageScreenData?) or method argument that returns all pixels of  
.


ImageData can be made portable between canvases by adding aspect ratio  
field or additional width/height fields given in CSS pixels.


--
regards, Kornel Lesiński

Re: [whatwg] Referer header sent with ?

[Kornel Lesinski]

On Wed, 23 Jan 2008 07:27:16 -, Ian Hickson <[EMAIL PROTECTED]> wrote:


HTML5 doesn't say anything about whether a referer should be sent with
the POST generated by . There is a new attack vector 
opens (as currently being discussed on mozilla.dev.platform) that would
be blocked if the referer were not sent.


Fixed. I also said to not include Cookies or HTTP auth headers.  
Legitimate uses can always include whatever information they want in the  
ping=""

attribute's value itself.


Doesn't that kill use of ping for tracking ad clicks? I think ad providers  
want to have cookies to track individual users across domains, and site  
that serves  is unable to provide that. Maybe ping could allow only  
cookies with a certain name/naming scheme?



I don't think that attack vector discussed on mozilla.dev.platform should  
be taken so seriously. In my opinion case when  enables attack  
(instead of being just one of countless possible attack vectors) is very  
very unlikely:


- If site accepts data from GET as well as POST (e.g. is using PHP's  
register_globals), then  is not needed at all -- a better attack  
can be performed with simple  or .
- If site allows HTML from untrusted source and allows ping to slip  
through, it is very likely that the site can be tricked to allow other  
potentially dangerous attributes or scripts.
- Because not all browsers/proxies/firewalls send Referer header,  
public-facing websites have to accept POSTs without Referer, so forbidding  
Referer for  may not increase security and even make it harder to  
protect against CSRF.


OTOH Referer can help save bandwidth. Without it page may need to include  
its own URL in every  attribute. On pages with lots of links  
(portals, directories) this can noticeably increases size of HTML.


Maybe these problems could be solved with an additional HTTP header in the  
ping request? e.g.:


X-Ping: from="http://example.com/here";, to="http://example.com/there";

This would make it easy to protect against unwanted ping-originated  
requests (one could configure server or set up application firewall to  
filter pings), and URL in  wouldn't have to contain copies of  
page's URL and href.


--
regards, Kornel Lesiński

Re: [whatwg] Revised Plan for Server-sent DOM events

[Kornel Lesinski]

On Mon, 07 Jan 2008 10:30:29 -, Anne van Kesteren <[EMAIL PROTECTED]>  
wrote:


- Continued problems of the 2 connection limit on HTTP server  
scalability


Is there any realistic solution to this other than to use separate  
domains and have cross-domain working?


Sharing of event-source connection between many pages/windows would help  
tremendously.


Currently each  on every page gets its own connection. This  
makes use of it as standard element of page's design (e.g. live stock  
ticker in a sidebar on financial portal) impractical - for every page in  
every window browser would open separate connection, easily reaching the  
limit.


This could be improved, if connection to event source was handled outside  
of page's context, in a global pool of stream connections. Browser would  
never use more than one connection to the same source and would use one  
connection to trigger events on all pages that subscribe to the given  
source. As a bonus, browser could also keep connection open while user  
navigates between pages instead of closing and re-opening stream  
connections each time.


The downside is that applications couldn't rely on seeing every event in  
the source, so they couldn't rely on incremental updates. To remedy this,  
an additional feature, like checkpoints in the stream and replaying of  
past events would be neccessary.


--
regards, Kornel Lesiński

Re: [whatwg] Revised Plan for Server-sent DOM events

[Kornel Lesinski]

On Sat, 05 Jan 2008 06:51:29 -, Henry Mason <[EMAIL PROTECTED]> wrote:


- Unnecessary dependency on DOM Events


This feature is inherently event-based. I think it does make sense to  
re-use existing framework for event handling.


However, I haven't found use-case for remote triggering of standard  
events, like mouse and keyboard events. I always use my custom events,  
because I don't want to couple server-side code with details of particular  
user interface.



- Redundancy with already existing techniques, especially XMLHttpRequest


It's much simpler to use and allows browser to manage the connection.

I propose that we remove support for non-message events; that is, allow  
only events with MessageEvent interface.


+1

Scripts that need that functionality can create wrapper on client-side  
that will dispatch other types of events.


The critically cool part, however, is that since MessageEvents store  
their domain and URI origin, it will be safe to allow for cross-domain  
messaging through this server-sent events.


I don't see how it makes cross-domain messaging safe. Without  
Access-Control mechanism, what would prevent malicious site from reading  
event-source of e.g. users' gmail chat? (variant of CSRF attack)


--
regards, Kornel Lesiński

Re: [whatwg] several messages regarding Ogg in HTML5

[Kornel Lesinski]

On Thu, 13 Dec 2007 00:02:10 -, Krzysztof Żelechowski  
<[EMAIL PROTECTED]> wrote:



You're exaggerating, you are.  If Web developers read the specification
(or any specification, for that matter), the Web would not look like it
does.  But they do not; the prefer Dreamweaver, and whatever you have
got.


Hopefully the specification will be used as basis for many tutorials,  
books, and tools, so this suggestion may indirectly have very wide  
influence.


--
regards, Kornel Lesiński

Re: [whatwg] webforms2: new hash attribute for input ?

[Kornel Lesinski]

On Thu, 16 Aug 2007 19:49:27 +0100, Julien TOUCHE  
<[EMAIL PROTECTED]> wrote:



Unfortunately this will not secure browsing session, because once user
is authenticated, server will have to use cookies which could be stolen
and used to impersonate the user.


cookies are another part of the problem which needs to be secured too
(httpOnly, secure, limited to one IP, and so on ... but could be
overcome too)


Limiting cookies to one IP is problematic with proxies (may block users  
behind proxy farms, protection is weakened for users of ISP's proxies).



Still need to standardize other algorithm than in rfc2617 which
specifies only md5 (better to add sha1/sha256/sha512)


Fortunately RFC 2617 allows addition of new algorithms (I haven't checked  
if that doesn't break popular clients though).



rfc2617 also defines a salt-like with nonce, which is a very good point,
 but it seems to give the same problem said in first mail: it need
server to have passwd in clear to be able to compare against a changing
hash (if nonce is used) ...


Maybe I'm missing something, but AFAIK server only needs to store H(A1),  
which may be generated without nonce if 'MD5' (rather than 'MD5-sess')  
algorithm is used, and this does not eliminate nonce from the algorithm,  
because it's used in computation of 'request-digest'.



another problem is you can't block brute attacks. banks account are, in
general, blocked if you miss them 3 times and after you need to call the
bank.


Digest makes it difficult to count exact number of invalid login attemts  
(as legitimate requests may get rejected because of stale nonce or nonce  
count), but generally it is possible to implement and when client exceeds  
allowed number of attempts, server may start responding with 401 or 403 to  
every request from that user/IP.


--
regards, Kornel Lesiński

Re: [whatwg] webforms2: new hash attribute for input ?

[Kornel Lesinski]

On Wed, 15 Aug 2007 16:08:51 +0100, Julien TOUCHE  
<[EMAIL PROTECTED]> wrote:




so the browser transmits only the corresponding hash of the
given value.


Unfortunately this will not secure browsing session, because once user is  
authenticated, server will have to use cookies which could be stolen and  
used to impersonate the user.



My suggestion is to kill two birds with one stone by marrying forms with  
Digest authentication (RFC 2617).


Digest is already implemented in browsers, doesn't require storage of  
unhashed passwords, protects entire browsing session (with integrity  
checking of payload and stopping replay attacks) and can provide mutual  
authentication - it would be wasteful to re-invent and re-implement all  
that for forms.


The dealbreaker in current Digest implementations is the user interface -  
looks unfriendly, can't be customized, website can't offer account  
registration until user cancels login and there's no logout mechanism.


This can be solved by providing form controls that would log user in using  
Digest authentication:








or


username=myusernameid>


UI for logging out could be as simple as , however  
implementation details are probably outside scope of HTML 5.


--
regards, Kornel Lesiński

Re: [Whatwg] Request for HTML-only print link

[Kornel Lesinski]

On Sat, 28 Jul 2007 19:02:46 +0100, Sander <[EMAIL PROTECTED]> wrote:


I don't see how that is good usability. Quite the contrary, because this
approach means things work different on each website. That's confusing;
incosistency makes things harder to use. A print method that works the  
same across web sites is much more usable.


I don't think it's confusing as the browser's own print button is still  
there.


If page provides it's own print button, user won't be sure if there was a  
real technical reason for doing this (and browser's print button won't  
work properly) or if just author felt it's nice having more buttons on his  
page.


"A man with a watch knows what time it is. A man with two watches is never  
sure."


--
regards, Kornel Lesiński

Re: [whatwg] Entity parsing

[Kornel Lesinski]

On Fri, 15 Jun 2007 19:37:46 +0100, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:


I've defined the parsing and conformance requirements in a way that
matches IE. As a side-effect, this has made things like "naïve"
actually conforming. I don't know if we want this.


Rather not. This would break unencoded URLs:

?foo=bar®ion=baz → ?foo=bar®ion=baz


You mean that Internet Explorer breaks them already? That doesn't make  
much sense to me.


No, IE doesn't break them, and that's the point.

Section 8.2.3.1. states "This definition is used when parsing entities in  
text and in attributes." - if I understand this correctly, this makes  
semicolon optional for entities in both attributes and text and "®ion"  
in attribute would be interpreted as "®ion".
If that's the case, it is not compatible with IE, because it parses  
entities differently in attributes and text. Semicolon (or any  
non-alphanumeric character actually) is required in attributes, but in  
text it is not.


In IE6 ®ion is equivalent to
®ion

--
regards, Kornel Lesiński

Re: [whatwg] Entity parsing

[Kornel Lesinski]

On Fri, 15 Jun 2007 02:05:05 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:


I've defined the parsing and conformance requirements in a way that
matches IE. As a side-effect, this has made things like "naïve"
actually conforming. I don't know if we want this.


Rather not. This would break unencoded URLs:

?foo=bar®ion=baz → ?foo=bar®ion=baz

--
regards, Kornel Lesiński

[whatwg] Drag'n'drop uploads propsal

[Kornel Lesinski]

I've added proposal for drag'n'drop uploads to WHATWG Wiki.

http://wiki.whatwg.org/wiki/Drag'n'Drop_Uploads

(discussion started on public-html:  
http://lists.w3.org/Archives/Public/public-html/2007Apr/1277.html)


--
regards, Kornel Lesiński

Re: [whatwg] element

[Kornel Lesinski]

On Mon, 23 Apr 2007 23:19:49 +0100, Jonas Sicking <[EMAIL PROTECTED]> wrote:


This is an idea I have had floating around in my head for a while and
a recent couple of threads reminded me I really need to post it here.

Basic idea:
The idea is basically an element like  but that renders the  
linked page


Something similar has been proposed recently:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010801.html

IMHO such includes don't solve the biggest problem of frames - that  
there's only a single usable URL and all actual content is in orphaned  
scraps of documents.


Your use-case is a bit different, but I think such  will be  
commonly abused as a drop-in replacement for .


I suggest investigating further concept of "ID overlays" instead:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010805.html

--
regards, Kornel Lesiński

Re: [whatwg] Alt text authoring Re: Conformance for Mail clients

[Kornel Lesinski]

On Sun, 22 Apr 2007 18:58:13 +0100, Kristof Zelechovski  
<[EMAIL PROTECTED]> wrote:



For (2): alt="(Your browser does not display graphic images)".


What's the point? Users who rely on alt attribute know that already, and  
unless exactly that phrase is required by the specification (= bad for  
i18n), it won't be any use for bots either.


I think presence of the title attribute (which might be empty) could be  
required if alt is omitted:


or maybe:


and role of  should be left undefined, allowing UAs  
to use heuristics to guess it.


--
regards, Kornel Lesiński

Re: [whatwg] Alt text authoring Re: Conformance for Mail clients

[Kornel Lesinski]

On Sun, 22 Apr 2007 01:26:55 +0100, Jon Barnett <[EMAIL PROTECTED]>  
wrote:


By "entirely omitted alt", do you still only mean WYSIWYG editors?  If  
not, I agree.  The distinction would be as follows:

(1)  - This image represents text,
particularly the word "obvious".  Lynx should replace it with the word
"obvious" and do nothing else.
(2)   The image is part of the content and  
doesn't represent text.  Lynx should indicate that the image is missing  
and offer a way to download it


I'm a bit worried about this one - authors too often forget (or don't  
care) to add alt attribute, and this case gives it a different meaning.


I think that for (2) there should be either magic alt value or some way of  
specyfing that alt was intentionally omitted, and not forgotten (special  
classname? presence of title attribute?).


--
regards, Kornel Lesiński

Re: [whatwg] Alt text authoring Re: Conformance for Mail clients

[Kornel Lesinski]

On Thu, 19 Apr 2007 21:07:09 +0100, timeless <[EMAIL PROTECTED]> wrote:


As such, encouraging people to include alt tags means the difference
between me knowing that there's an image I care to look at and not.


If e-mail client automatically inserted [image was here] in the text part  
of e-mail, you would know that there were images, even without user  
providing better alternative text.



I support opinion that it doesn't make sense to _require_ e-mail clients  
to bug users about alternative text. On the web rationale for alt text is  
that you can never know who will read your page. In case of personal  
e-mail you do know.
Pictures sent in personal e-mails almost never have function other than  
the picture itself - alt text for vacation photos, to be really an  
alternative, would have to be an essay.


--
regards, Kornel Lesiński

Re: [whatwg] [WF2] without value="" should perhaps use .innerText as value

[Kornel Lesinski]

On Sat, 14 Apr 2007 02:10:07 +0100, Simon Pieters <[EMAIL PROTECTED]>  
wrote:


We currently don't have interop with IE and other browsers with regards  
to what to send to the server as the value of .


IE always sends .innerText as value.


IIRC it's innerHTML, but I can't verify it at the moment.

Is there really a noticable number of sites that rely on IE's broken  
behaviour? I doubt, because:
* By sending contents of button instead of value, it doesn't provide much  
more functionality than .
* Styling of  is not an easy task, so it's unlikely to be used for  
its HTML contents - authors rather use  or href="javascript:sendform()">
* And worst of all - IE always sends all undisabled . This makes  
value irrelevant, because you can't check which button was clicked anyway.


--
regards, Kornel Lesiński

Re: [whatwg] IE/Win treats backslashes in path as forward slashes

[Kornel Lesinski]

On Wed, 11 Apr 2007 14:02:39 +0100, Geoffrey Sneddon  
<[EMAIL PROTECTED]> wrote:


Looking through the spec again, there is nothing about backslashes in  
URI's path being treated as a forward slash, behaviour needed for  
compatibility for quite a few websites.


I think it can be added.

RFC 1738 calls backslash "unsafe" (RFC 2396 "unwise") character and says  
it must be encoded, so this change won't affect any valid URLs/URIs.


I've tested how browsers handle path in  tag:
IE6, Opera 9.2, Safari 2 translate "\" to "/". Camino (Gecko 1.8) and iCab  
3 translate it to "%5C".
All browsers leave "%5C" alone, meaning that this change won't stop anyone  
from accessing resources that really contain backslash in the path (tested  
Apache2 on OS X 10.4).


--
regards, Kornel Lesiński

Re: [whatwg] IE/Win treats backslashes in path as forward slashes

[Kornel Lesinski]

On Wed, 11 Apr 2007 15:13:09 +0100, Gervase Markham <[EMAIL PROTECTED]>  
wrote:


Looking through the spec again, there is nothing about backslashes in  
URI's path being treated as a forward slash, behaviour needed for  
compatibility for quite a few websites.


I would be rather surprised if that were true, given that Firefox  
doesn't do it and I've never come across a website which broke for that  
reason. But maybe I live a sheltered life.


Working for osiolki.net (site that blacklists IE-only websites), I've come  
across a few.


http://www.google.com/search?q=site:osiolki.net+backslash&filter=0  
(+ there are 4 more non-public cases).


--
regards, Kornel Lesiński

Re: [whatwg] Anchor target-attribute extension to enable dom targeting

[Kornel Lesinski]

On Sun, 08 Apr 2007 22:22:20 +0100, Georges MARZIN  
<[EMAIL PROTECTED]> wrote:



IMHO it isn't much better than:




It's still as evil as frames - subpages can't be used as standalone
documents (thus bookmarked, returned by search engines, etc), because

they lack proper navigation menus and in your example they're not even
proper documents.



When the response will arrive, css rules will apply to the new content,
and the result will be smart.


Yes, in this regard it's much better than iframe. However it doesn't solve  
the worst problem of frames - that subpages become separated from  
essential parts of the document.



I am interested with your solution of xul-like id overlay for merging
documents. But I know this for xul, but not for html. How can it work ?


I was just referring to the concept. Something similar could be made for  
HTML.


I think there should be an additional requirement that every subpage  
specifies its parent page. This would allow user agents to reconstruct  
full document from any subpage.


How about that?

index.html:

My page
open subpage
hello world

I've used rel=overlay since you don't need to specify where should supage  
be included (elements with same IDs will be replaced).


subpage.html:

my parent
subpage

This page has reV=overlay, which specifies the "parent" document. This has  
two roles:
- a fallback that allows users and bots to find parent page that contains  
navigation and rest of the content
- allows UAs that support overlays to rebuild complete page using this  
reference


resulting DOM would be:

My page
open subpage
subpage


It should be enforced that subpages contain rev=overlay link and that  
parent pages and subpages are mutually connected:


If there's no rev=overlay link in the subpage or it has rev=overlay link  
that points to URL other than that of current page, browser should  
normally open subpage instead of overlaying it.

For example if index.html contains:

and orphaned.html does not contain ,  
browser should not overlay it (ignore the rel=overlay).



When opening a page that has rev=overlay link, browser should load  
referenced page and overlay the current one on top of it.


For example if user opens subpage.html as a standalone document (types the  
address, opens a bookmark) and the document contains:


browser should load index.html and overlay subpage.html on it.


And of course since DOM of pages gets shared, overlay should be subject to  
the same origin policy.


--
regards, Kornel Lesiński

Re: [whatwg] Anchor target-attribute extension to enable dom targeting

[Kornel Lesinski]

On Sun, 08 Apr 2007 19:17:55 +0100, Georges MARZIN  
<[EMAIL PROTECTED]> wrote:



 
 Click here to dynamicaly load a text/html piece of code into
the "main_area" identified dom node
 

 
 

The content of inc/foo.frg in not a complete html page but only a well
formed xhtml piece of code like :


   this content is dynamically loaded into a dom node, like ajax,
   but with a html extended syntax of the target property.



IMHO it isn't much better than:




It's still as evil as frames - subpages can't be used as standalone  
documents (thus bookmarked, returned by search engines, etc), because they  
lack proper navigation menus and in your example they're not even proper  
documents.


I think that much better and more powerful solution are ID overlays. The  
idea is to merge documents instead of completly including one into  
another. XUL has something like that:

http://developer.mozilla.org/en/docs/XUL_Tutorial:Overlays

--
regards, Kornel Lesiński

Re: [whatwg] Parsing: comment tokenization

[Kornel Lesinski]

On Sat, 07 Apr 2007 13:27:14 +0100, Nicholas Shanks  
<[EMAIL PROTECTED]> wrote:



2) A double HYPHEN-MINUS delimits comments within tags, this provides
compatibility with XML and SGML and changing this needlessly in HTML5
will just complicate conversion.


HTML5 is not an application of SGML and I think it has been proven by now  
that it doesn't make sense to keep pretending it is (see story about SGML  
comment in Acid2).


--
regards, Kornel Lesiński

Re: [whatwg] element feedback

[Kornel Lesinski]

On Sun, 25 Mar 2007 20:28:38 -, Elliotte Harold  
<[EMAIL PROTECTED]> wrote:


there can always be browser defaults that take over, but by allowing  
authors the ability to override the browsers controls

will allow for the flexibility of
a) allowing for disabled controls (perhaps disabling fast-forward for  
training videos)


Seems to me the user shoudl be in control here, not the author. If they  
want to fast forward, the browser lets them. I have no interest in  
enabling or even suggesting the use of the silly DVD type controls where  
you can't fast forward through the ads or the FBI notice.


I find these annoyng myself as well, but I don't think specification could  
stop anyone from doing that. Authors use unskippable ads in Flash videos  
already. If  won't let them do the same, most likely they simply  
won't use .


--
regards, Kornel Lesiński

Re: [whatwg] element feedback

[Kornel Lesinski]

On Fri, 23 Mar 2007 20:57:24 -, Silvia Pfeiffer  
<[EMAIL PROTECTED]> wrote:




  to provide the video segment between offset 12:35 and 20:40


  to provide the video from named offset "section4"

These provide the Web page author with the power to do offsets.


How would that be used? Do you expect UA to change query string arguments  
when video.seek() is invoked?
If src="video.ogg?t=0:12:35" is specified, how would user see the  
beginning of the video?



http://example.com/example.html#myvideo_1?t=0:12:35/0:20:40
  to provide the Web page with the first video playing section  
12:35-20:40,


It's fine although ofcourse I'm biased towards simpler and more compact  
syntax I've suggested :)



These two URIs with fragment offsets would currently not work in a Web
browser. However the set of URIs that I provided inside the 
tag above already work through the Annodex framework for ogg files.


What if server does not support it or site uses another video format?

--
regards, Kornel Lesiński

Re: [whatwg] element feedback

[Kornel Lesinski]

On Fri, 23 Mar 2007 10:24:30 -, Silvia Pfeiffer  
<[EMAIL PROTECTED]> wrote:



Let's say there's http://example.com/example.html page which contains
embedded video:
..

I'd like to be able to construct URL like:
http://example.com/[EMAIL PROTECTED]:35
that would cause UA to start playing the embedded video.ogg from 12:35.


That would be hard, because how would you identify which embedded
video or audio file on the example.html page this temporal offset is
referring to?


I think it might work like this: when play() is called on a   
element, and it hasn't been called on any other video element in this  
document yet, read time from location.hash and call seek().


This would work with dynamically created  elements and would  
probably be the best choice even if there are multiple  elements in  
the document.


If such altered behavior of play() is not unacceptable, then that might  
work:


http://example.com/[EMAIL PROTECTED]:35

Where "myvideo" part is interpreted as ID of element in the document (and  
if there's no such element - assume document.body).

If the element is a , then seek() that video.
If it isn't, then seek first  descendant of that element (something  
like: (document.getElementById("myvideo") ||  
document.body).getElementsByTagName('video')[0].seek(12*6+35000))).




My rationale:
* it doesn't require any changes to the document, so user can control  
starting position in any document, even if author didn't think of such  
possibility
* It's part of document's URL, not URL of the video file, so user doesn't  
have to extract video file URL from the document and can still use the  
page (which provides controls for the video).
* it can be implemented in JavaScript with current  API (also in  
User JavaScript, but I think for interoperability it's important to be  
part of the spec).

* it's orthogonal to server-side support for seeking


Also, it could be interpreted by the UA only, since
everything after "#" will not be transferred to the server.


Yes, that's intentional. It allows user to modify *any* URL without risk  
of breaking it (some servers/applications may not like extra query  
string). I think use of hash for this is appropriate - just like UA  
scrolls HTML to given element, UA would "scroll" the video - it's just a  
change of axis from Y to time :)


--
regards, Kornel Lesiński

Re: [whatwg] element feedback

[Kornel Lesinski]

On Thu, 22 Mar 2007 20:53:48 -, Silvia Pfeiffer  
<[EMAIL PROTECTED]> wrote:



About 8 years ago, we had the idea of using fragment offsets to start
playing from offsets of media files. However, in discussions with the
URI standardisation team at W3C it turned out that fragment offsets
are only being seen by the UA that sends them, so they will never
reach the web server.


I think we had in mind (at least I did) URL of the page that contains the  
video, not the URL of the video file itself. Because of this indirection  
it's completly up to UA to read fragment identifier and translate it into  
appropriate HTTP request for the video file (which could use Range header  
that's more proxy-friendly than query string).


Let's say there's http://example.com/example.html page which contains  
embedded video:

..

I'd like to be able to construct URL like:
http://example.com/[EMAIL PROTECTED]:35
that would cause UA to start playing the embedded video.ogg from 12:35.

--
regards, Kornel Lesiński

[whatwg] Bookmarking videos

[Kornel Lesinski]

On Wed, 21 Mar 2007 20:19:24 -, Nicholas Shanks
<[EMAIL PROTECTED]> wrote:


On the other hand it depends on authors providing metadata. Most
likely very few will do that, and even then provided chapters may
not cover all interesting fragments in the video/audio.


That situation isn't any different from ordinary HTML nowadays, most
people don't even give all header-level elements unique ids, let
alone individual paragraphs. But that doesn't mean the facility
shouldn't be made available to those who want/need it.


It is possible to implement it using JavaScript - you can read
location.hash and seek() video appropriately.

This however is a little help to users who want to bookmark videos or
share links to certain parts of them - without a standard way of doing it
UA's won't be able to provide UI for it. Even if you implement that for
yourself using UserJS, you won't be able to share those links, etc.

--
regards, Kornel Lesiński

Re: [whatwg] Full screen for the element

[Kornel Lesinski]

On Wed, 21 Mar 2007 19:30:13 -, Simon Pieters <[EMAIL PROTECTED]>  
wrote:



Shouldn't the video API include a way to toggle full screen on/off?


Browsers are allowed to provide full screen, however there's no API for  
it. Entering fullscreen should only be under the control of the user,  
otherwise the author could hijack the user's screen and no way to get  
out of it (e.g. as soon as the user tries to exit fullscreen, the script  
goes back to fullscreen).


Couldn't this be protected in a similar way pop-up blocking works? If not,  
browsers could simply display confirmation dialog box before entering  
fullscreen (some sort of protection is neccessary to protect against  
phishing and annoyance).


I think Mihai has a valid point here -- if there's no API for fullscreen,  
custom players won't be able to provide UI for it or will try to fake it.


I suggest adding fullscreen() (toggleFullscreen? enterFullscreen?) method  
that returns false if UA refused to enter fullscreen:


if (!video.fullscreen())
{
openVideoInLargePopupInstead();
}

--
regards, Kornel Lesiński

Re: [whatwg] element feedback

[Kornel Lesinski]

On Wed, 21 Mar 2007 18:31:29 -, Nicholas Shanks  
<[EMAIL PROTECTED]> wrote:



Well besides the fact that fragment ids cannot start with a number
nor contain a colon


I've checked syntax for fragment identifiers in URIs (RFC 2396) and  
haven't found such limitation. If such fragments cannot match any current  
HTML IDs, that's even better.



you have to consider the problem of multiple
unequal representations. In this example equivalent content is not at
the same time offset. Clicking the link should take you to the
relevant place whether the UA is rendering the video, the audio or
the transcript:


On the other hand it depends on authors providing metadata. Most likely  
very few will do that, and even then provided chapters may not cover all  
interesting fragments in the video/audio.


--
regards, Kornel Lesiński

Re: [whatwg] Attribute proposal:

[Kornel Lesinski]

On Mon, 19 Mar 2007 08:15:43 -, Alexey Feldgendler  
<[EMAIL PROTECTED]> wrote:


Automatic behavior in HTML has been traditionally expressed through  
scripting. It's not hard to write a one-line script which automatically  
starts playback, but solutions based on scripting are easier to  
circumvent on the user side (and it's good).


If you intend to use user scripts, you can as well call stop() on  
automatically started  elements.



-1 for |autoplay|.


I think it depends on whether  will be usable without scripting or  
not. If current specification does not intend to require default UI, then  
some JavaScript would be neccessary anway, so autoplay attribute doesn't  
make any difference.


If  gets default UI and one could simply use ,  
then addition of something like  
document.getElementById('myvideo').play(); would diminish  
elegance and simplicity of  element.


--
regards, Kornel Lesinski

Re: [whatwg] Comments on the element

[Kornel Lesinski]

On Sun, 18 Mar 2007 21:07:20 -, Mihai Sucan <[EMAIL PROTECTED]>  
wrote:


If  elements would have native UIs, bloggers would be more  
attracted of it, and developers of video sites as well. In the above  
case, you'd only have:


http://www.youtube.com/v/id";>


I doubt YouTube would allow that. Such video (even with UI provided by  
browser) lacks features that YouTube probably would require: branding and  
link to their website.


I think support for XSPF might be helpful in solving that problem. XSPF  
has  element which could be used as stand-in or overlay image and  
 elements for link to YouTube and video's page.


--
regards, Kornel Lesiński

Re: [whatwg] Video playback UI

[Kornel Lesinski]

On Sun, 18 Mar 2007 18:52:35 -, Alexey Feldgendler  
<[EMAIL PROTECTED]> wrote:


How about controls overlaid on top of video, which are visible only when  
mouse hovers it? Something like fullscreen controls in QuickTime Pro or  
iTunes 7.


To ensure that video is always usable:
* UI would be on by default (but visible on hover)
* Author could disable it using attribute of  element
* User could re-enable controls using context-menu or some other method  
(in case author disabled default UI and failed to provide usable  
alternative)


--
regards, Kornel Lesiński

Re: [whatwg] element proposal

[Kornel Lesinski]

On Fri, 16 Mar 2007 23:49:04 -, Bjoern Hoehrmann <[EMAIL PROTECTED]>  
wrote:



  ++-+-+---+
  | SMIL   | SVG | IE  | "WHATWG"  |
  ++-+-+---+
beginElement() | beginElement()  | beginElement()  | play()
endElement()   | endElement()| endElement()| stop()
-  | pauseElement()  | pauseElement()  | pause()
-  | resumeElement() | resumeElement() | togglePause()
-  | isPaused| isPaused| state == PAUSED
   ...


I think that nomenclature in WHATWG's API is much simpler and  
straightforward and that outweights benefit of appealing to authors  
experienced with SMIL/SVG.


beginElement() may sound strange and confusing to authors, especially ones  
familiar only with W3C DOM (where names like getElementById or  
createElement are often used). OTOH anyone can guess what play() and  
stop() do.



  +--+-+
  | Flash/ActionScript   | "WHATWG"|
  +--+-+
pause()  | togglePause()
pause(true)  | pause()
pause(false) | togglePause()
seek(s)  | seek(1000 * s)
time | position / 1000


This however is a good point - since Flash became de-facto standard for  
publishing video on the web, authors are likely to know Flash's API  
already. Having similar, but not exactly the same API may be source of  
mistakes.


--
regards, Kornel Lesiński

Re: [whatwg] Video proposals

[Kornel Lesinski]

I think it would be useful if fragment identifiers in URL could specify  
starting position of video. This would let anyone to bookmark position in  
the video without having to worry about (lack of) site-specific navigation  
and UI for seeking.


[EMAIL PROTECTED]:mm:ss

(I'm not sure how should it be handled if  doesn't have an ID -  
maybe ID of any ancestor element could be used instead or fragment would  
affect any/first video on the page)


The use case however is quite simple and common:
If I'm watching long video and want to show interesting part of it to my  
friends (or bookmark it), I could right-click the video, choose "Copy link  
to this video" option and have URL with current playing position copied.


--
regards, Kornel Lesiński

Re: [whatwg] Make be a header cell for its row even for the first row

[Kornel Lesinski]

On Tue, 13 Mar 2007 20:29:09 -, Asbjørn Ulsberg  
<[EMAIL PROTECTED]> wrote:


Many pages use tables where only the first column are header cells,  
e.g.:



 Foo Bar
 Foo Bar
 Foo Bar


With the current algorithm for assigning header cells to data cells,  
the first  won't be a header cell for any data cells.


Can't 'scope="row"' be used?


It can, but in this case scope of row is so obvious, that it would be  
counter-intuitive if specification said otherwise.


--
regards, Kornel Lesiński

Re: [whatwg] Configure Apache to send the right MIME type for XHTML

[Kornel Lesinski]

On Wed, 07 Mar 2007 23:52:08 -, Alexey Feldgendler  
<[EMAIL PROTECTED]> wrote:


Even your regular expressions for User-Agent aren't doing exactly what  
you intended, because mod_rewrite does not anchor patterns.


While I totally agree that browser sniffing isn't a way to go, I must  
say that Accept headers cannot be used to resolve this because MSIE  
claims to support */* in the Accept header that it sends.


And Googlebot claims to accept "application/*".

Despite that Accept header can resolve this issue. XHTML browsers include  
full "application/xhtml+xml" MIME type, so you can avoid false positives  
if you ignore wildcard matches in negotiation. While it's not perfect, I  
think it's still better than using User-Agent for the same purpose.


--
regards, Kornel Lesiński

Re: [whatwg] Configure Apache to send the right MIME type for XHTML

[Kornel Lesinski]

On Wed, 07 Mar 2007 17:46:43 -, Elliotte Harold  
<[EMAIL PROTECTED]> wrote:



How so?
 Well, your article advocates sniffing specific user agents where the  
one written by Mark Pilgrim uses the Accept: header which was actually  
designed for this... Google, for one, is known for not supporting XHTML  
really well.


I'm not doing content negotiation here.


From HTTP point of view you are.

There's one representation available. It is XHTML. We can send that to  
most browsers and they'll deal reasonably. Two I know of have problems  
(IE and Lynx) so we lie to them and tell them it's text/html.


Use of Accept does not require you to return completly different  
representations, you can use it just like you used User-Agent.


However Accept contains exactly the information you're trying to (and  
failing to) derive from User-Agent header.



I am curious what problems Google has with XHTML. Then they deal.


Last time I checked they were marking XHTML documents as "Unknown format".

Since Google certainly has engineers aware and capable of fixing this  
problem, Google must be ignoring XHTML deliberately. I suspect they  
support only what works for their customers and XHTML in XML mode doesn't  
work for vast majority of them.



User-agent sniffing is a bad practice - it's inaccurate, hurts minority  
browsers and is not forward-compatible. Please change your method to use  
Accept header, so it won't be affecting any HTML-only user-agents (web is  
more than a handful of desktop browsers).  Accept method will even work  
for MSIE and Lynx when/if they start supporting XHTML.


Even your regular expressions for User-Agent aren't doing exactly what you  
intended, because mod_rewrite does not anchor patterns.


--
regards, Kornel Lesiński

Re: [whatwg] element proposal

[Kornel Lesinski]

On Tue, 06 Mar 2007 10:11:01 -, Gervase Markham <[EMAIL PROTECTED]>  
wrote:


A good point. I know nothing about extending IE; would it be possible to  
have an IE addon which implemented support for a  tag, or would  
it need to be a plugin and therefore use -style markup?


A script could easily fake  element using dynamically created  
. That's almost what SWFObject/QTObject scripts do now (and that's  
probably de-facto standard for embedding interactive content since Eolas  
patent).


I think in that case  is safest solution, because this gives acces  
to alternative content (which is broken in IE6's ) and allows  
script-controlled plugin detection and workarounds for bugs in  
plugins/browser.


--
regards, Kornel Lesiński

Re: [whatwg] element proposal

[Kornel Lesinski]

I think it's a good idea to provide API for controlling and monitoring  
video playback and specyfing that it should be possible to overlay HTML  
elements on top of a movie. Probably one of the reasons for adoption of  
Flash as a movie container is ability to create custom players, which are  
consistent with websites' UI/branding, can add advertisements and other  
features.


New  element may also clean up problematic properties of ,  
like use of obscure classids, plug-in dependent ways of specyfing movie  
source and lack of standard values for .


I'm in favor of requiring browsers to support OGG Vorbis for audio. It's a  
very good codec and bandwidth achievable on the Internet is already much  
greater than required for audio, so there will be little pressure to  
replace it with another codec in future.


However I'm not quite sure if specifying baseline video codec will be much  
help - I'm afraid that any baseline codec specified today will be  
obsoleted in a few years by newer versions of Flash or plugins bundled  
with OS or popular software.


--
regards, Kornel Lesiński

Re: [whatwg] Geolocation in the browser

[Kornel Lesinski]

On Fri, 23 Feb 2007 15:15:13 -, Gervase Markham <[EMAIL PROTECTED]>  
wrote:


Postcode would be easiest way to integrate location API with existing  
services (especially via userjs/greasemonkey, where using  
location->postcode database may be difficult).


The problem with suggestions like this is that they require geocoding on  
the server side. Geocoding services are not always readily available;  
there's no free, unencumbered implementation I know of. And you need a  
different database for every country.


API I've suggested allows browsers to provide various representations of  
the location, so there can be best effort on both sides.


I guess I don't object to the browser returning this information  
additionally if it knows it - but lat/long should be the baseline,  
always-present info.


But what about browsers that don't have access to GPS device nor geocoding  
service? These browsers could still return city and postcode information  
provided by the user and that could be enough for many applications  
(nearest branch locators, etc.).


navigator.getGeolocation() would return location with best precision  
allowed by default (without asking user every time). If user set in  
preferences that every page can get location with 10km precision, that  
would be returned.


I think it's better to ask every time and remember the precision  
allowed. I would certainly much prefer to know who knows where I am.


Ofcourse there should be option to ask every time, but it can't be the  
only option. Some users may prefer not to be bothered and have  
location-based services just working. Also there are IP<>geo databases, so  
some users may want to allow giving away information that has  
approximately same accuracy.


--
regards, Kornel Lesiński

Re: [whatwg] Geolocation in the browser

[Kornel Lesinski]

On Wed, 21 Feb 2007 20:31:11 -, Ryan Sarver  
<[EMAIL PROTECTED]> wrote:



var location = window.getLocation();


For some applications location given in format other than lat/long may be  
more useful and less privacy-sensitive.


For example name of the city might be good enough if you order a cab from  
a nationwide company.
Postcode would be easiest way to integrate location API with existing  
services (especially via userjs/greasemonkey, where using  
location->postcode database may be difficult).
Additionally city/postcode information may be provided to desktop browsers  
by the user (for example Opera collects that information already).


Also different applications may be satisfied with different precision of  
location (searching for nearest airport vs nearest starbucks :)


There's also privacy problem with giving too precise location and  
usability problem with asking for user's permission every time.


My proposal is:

use navigator.getGeolocation instead of window.getLocation to avoid  
conflicts with existing functions (window object is a global namespace in  
JS) and to avoid confusion with window.location object.


navigator.getGeolocation() would return location with best precision  
allowed by default (without asking user every time). If user set in  
preferences that every page can get location with 10km precision, that  
would be returned.


navigator.getGeolocation(100) would request location that has precision of  
100m or better. If user's default allowed precision is lower than the  
specified one, browser would ask for permission. Browser would be allowed  
to return location with lower precision than requested (if it doesn't have  
information precise enough or because user decided so).


The function would return an object, which could be queried about various  
aspects of the location - name of the city, postcode, but also precision  
of location given (so applications would know if user is really exactly in  
the middle of the city or if browser only knows the city name).


--
regards, Kornel Lesiński

Re: [whatwg] WF2: Non-validating submit buttons

[Kornel Lesinski]

On Wed, 24 Jan 2007 21:55:16 -, Simon Pieters <[EMAIL PROTECTED]>  
wrote:


However, this doesn't solve the use case of saving an unfinished  form  
server-side.


Are there any real-world examples where you can save an unfinished form  
on the server and continue filling it afterwards, that also has required  
fields (when the form is finished)? I have never seen such a form.


Saving incomplete forms is a recommendation in ;) >Devensive Design for the Web which provides www.bankone.com as  
an example site that saves incomplete applicatios (I don't know however if  
that's via save button or just up to the last completed step).


IMHO non-validating button makes sense for saving drafts of various kinds  
(webmail, blog post, wiki page).



Another use-case is a preview button.

Example: comment submission on a blog. You may require users to fill-in  
their name and e-mail address, but these fields aren't neccessary to  
display a preview of text formatting.


--
regards, Kornel Lesiński

Re: [whatwg] E4X and attribute values

[Kornel Lesinski]

On Tue, 16 Jan 2007 12:59:56 -, Henri Sivonen <[EMAIL PROTECTED]> wrote:

Is E4X allowed in event handler attribute values and in javascript:  
URIs? If yes, how can a UA know whether the E4X parse mode should be  
used?


This can be explictly stated using Content-Script-Type HTTP header/meta  
and Mozilla's MIME type parameter:



http://developer.mozilla.org/en/docs/New_in_JavaScript_1.6
http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.2.1

However since the e4x type parameter seems to be only affecting parsing of  
comments and CDATA inside 

Re: [whatwg] Hyphenation

[Kornel Lesinski]

On Tue, 09 Jan 2007 23:47:46 -, James Graham <[EMAIL PROTECTED]> wrote:

FWIW this all makes just as much sense with "dictionary" replaced by  
"stylesheet" (stylesheets need to be kept in sync as new elements,  
classes and ids are used rather than new words).


Not entirely. The layout and structure of the documents is not as variable  
as their content.


And the solution that works for stylesheets (external file) has a problem:  
delays initial display or causes FOUC. With external dictionary there  
could be another FOUC - Flash of Unhyphenated Content.


--
regards, Kornel Lesiński

Re: [whatwg] Hyphenation

[Kornel Lesinski]

On Tue, 09 Jan 2007 13:03:04 -, Leons Petrazickis  
<[EMAIL PROTECTED]> wrote:



I would suggest that the first priority is getting a naive hyphenator
into browsers. Since you only ever need hyphenation when
full-justifying


I disagree. It's also needed in narrow columns, even if they're  
left-justified and may be useful for very long words in general.



Once that is in place, we can start thinking about special cases. I
would suggest a hyphenation dictionary in the  of the document.


Hyphenation dictionary supplied by the page seems like a good idea, but  
having it in  might cause some headaches in dynamic systems:

* in some template systems adding anything to  is difficult
* author may want to compose page from several independent fragments,  
possibly each having its own dictionary. Merging these dictionaries would  
either require some extra logic or cause duplicate entires (and authors  
won't like that waste).
* One would have to keep in sync dictionaries and text (in practice there  
will be cases when dictionary lacks some words or contains words which  
aren't present in text any more)
* syntax proposed is verbose and with entire dictionary repeated on every  
page that adds up to a substantial traffic


And this problem can't be solved by using external file for dictionary, as  
it will either delay initial display of the page until dictionary is  
loaded or will require reflow of entire page.



Therefore I suggest something possibly a bit more difficult to UAs - learn  
from the text in document.


Having document with:
The zoë-ven hypertext must ab-stain from grooming monkeys in an
indefatigably questionable fashion. The zoëven hypertext must abstain
from grooming monkeys in an indefatigably questionable fashion.

UA would make note of words with soft hyphens and replace further  
non-hyphenated occurances with hyphenated ones:

The zoë-ven hypertext must ab-stain from grooming monkeys in an
indefatigably questionable fashion. The zoë-ven hypertext must ab-stain
from grooming monkeys in an indefatigably questionable fashion.

(decision whether this is visible in DOM or not is probably best left to  
implementation).


As for the exceptions in hyphenation, I'm in favor of  element.


--
pozdrawiam, Kornel Lesiński

Re: [whatwg] as a wrapper for inline content

[Kornel Lesinski]

On Thu, 04 Jan 2007 00:58:34 -, Ian Hickson <[EMAIL PROTECTED]> wrote:


What's the use case for  elements containing inlines?


From microformats.org:


 http://tantek.com/";>Tantek Çelik
 Technorati



It can be generalized to "when  is used in place of elements with  
inline content model and which are not in HTML." The simplest example  
could be .


--
regards, Kornel Lesiński

Re: [whatwg] Progressive rendering

[Kornel Lesinski]

On Thu, 02 Nov 2006 12:43:37 -, Michel Fortin  
<[EMAIL PROTECTED]> wrote:


Just an update on my previous footnote markup proposal. Håkon Wium Lie  
told me in a private email that it wouldn't work alongside progressive  
rendering in CSS. From what I understand, it only applies to paged media  
however.


The problem is that you can't lay out a page until all the footnotes for  
that page have been found; if footnotes are all at the end of the  
document -- as in my backward compatible proposal -- then no page with a  
footnote can be rendered until the footnote content, at the end of the  
document, has been parsed.


I don't think it breaks progressive rendering, even on paged media.

On each footnote encountered, browser can check:

if (height_of_static_content + height_of_footnote_area > height_of_page)  
break_page();


I'm thinking that footnotes would be flowed independently of normal  
content. Browser would flow normal content from the top of the page, and  
flow footnotes from the bottom of the page at the same time. Break when  
both meet.


The only limitation here is that HTML of footnotes section has to be known  
in advance to compute styles for footnotes, however  
printing-while-downloading seems a bit extreme to me.


--
regards, Kornel Lesiński

Re: [whatwg] Detecting Web Forms for future proof scripts?

[Kornel Lesinski]

On Mon, 02 Oct 2006 17:37:28 +0100, Shawn Wilsher <[EMAIL PROTECTED]>  
wrote:



This project appears to be dead for over a year now. It seems to have at
least intention to support Gecko, but I couldn't get it to work properly
in Firefox.


Just because the project appears to be dead doesn't mean you should
just disregard all the work that has been done with it before.  It's
original aim is only for IE (as stated in the description).  However,
it has a large amount of work already done - why reinvent the wheel?


If I need just a feature or two, it's easier for me to write and maintain  
my own bit of code rather than rip it out of an unfinished, unstable code  
that I'm not familiar with.


I'd love to use that script once it's production-ready.

--
regards, Kornel Lesiński

Re: [whatwg] Detecting Web Forms for future proof scripts?

[Kornel Lesinski]

On Mon, 02 Oct 2006 17:00:02 +0100, Shawn Wilsher <[EMAIL PROTECTED]>  
wrote:



Hopefully, you aren't duplicating work that has already been done here:
https://sourceforge.net/projects/wf2/

Granted, this is only for IE, but nearly half of your work is already  
done then.


This project appears to be dead for over a year now. It seems to have at  
least intention to support Gecko, but I couldn't get it to work properly  
in Firefox.



I've ran into similar problem as the original poster. For inputs, buttons  
and repetition there's an easy solution:


input.setAttribute('type','uri');
if (input.type != 'uri') alert('no native WF2!');

but it's a stretch to assume that support of certain input type means  
support for all of WF2, so I'm curious how can one detect support for  
other functionality.


--
pozdrawiam, Kornel Lesiński

Re: [whatwg] href on any element

[Kornel Lesinski]

On Tue, 29 Aug 2006 22:55:01 +0100, Matthew Raymond  
<[EMAIL PROTECTED]> wrote:


Having data table representing list of items where large clickable area  
is useful - i.e. inbox in a webmail, list of contacts, forum threads  
listing, etc.


I've ran into this problem many times and seen many questions about this
on forums/usenet.

My current solution is:



   This can be accomplished by having  elements in each individual
cell...


Ofcourse it can, but it bloats code a lot. You have to add several  
redundant links, add tabindex=-1 to avoid breaking keyboard navigation,  
move all table and cell styles to anchors, and if cells contain block  
elements you have to bloat your code even more.



Another situation where I wanted href on any element was advertisement:


My product is:

Cool
Great
And soo semantic




   People don't typically don't initiate a purchase in a user interface
by clicking on the product description.


Make it href="/info" then. Sometimes it doesn't make sense to have  
separate page for each listed detail.



Ofcourse you can live without href on every element if you apply a bit of  
scripting and CSS tricks, but the same thing can be said about almost  
every thing in WHATWG specifications.



It can have some backwards-compatibility. AFAIK XHTML/2 allows nested  
anchors, so I'd use it like this:


anchorno anchorno  
anchorno anchor


With some scripting (see first code in this post) this could work in  
current browsers and had fallback for bots and non-JS agents.


--
regards, Kornel Lesiński

Re: [whatwg] href on any element

[Kornel Lesinski]

On Tue, 29 Aug 2006 17:02:22 +0100, Francisco Monteiro  
<[EMAIL PROTECTED]> wrote:



What practical use has this for Mr Joe Public?

Give me a really useful example in very simple wording!


Having data table representing list of items where large clickable area is  
useful - i.e. inbox in a webmail, list of contacts, forum threads listing,  
etc.


I've ran into this problem many times and seen many questions about this  
on forums/usenet.


My current solution is:


Another situation where I wanted href on any element was advertisement:


My product is:

Cool
Great
And soo semantic



--
regards, Kornel Lesiński

Re: [whatwg] [WA1] is semantic

[Kornel Lesinski]

On Wed, 12 Oct 2005 22:31:23 +0100, James Graham <[EMAIL PROTECTED]> wrote:

Maybe not, but there's a large class of problems for which this would  
provide a neat solution e.g. a  scientific document ("fig. 15 shows the  
results  of the numerical calculations described in section 3").


That's another interesting use-case.

Maybe  should be implemented as CSS property? Then you could use it  
like that:


img {counter: fig; counter-increment: fig;}
ref {content: counter-of( attr(to), fig );}

--
regards, Kornel Lesinski

Re: [whatwg] [WA1] is semantic

[Kornel Lesinski]

On Wed, 12 Oct 2005 17:11:40 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote:


BTW I'd be tempted to suggest that the attribute on  be for="" and
that it take an IDREF rather than a URI, to avoid any chance that people
might try to refer to things in other documents and expect it to work,  
and also for consistency with  and  -- what  
do

you think?


I like the idea, but I see some minor problems:

- user agents may need to stop progressive rendering if there is forward  
reference (  before referenced list item).


- what if CSS markers/list-style are dynamically chaged (on hover or using  
js)? Should references be changed realtime as well? As far as I know there  
isn't any similar element in CSS, so engines may not be prepared to  
support something like that.


- what should be done with references to non-existant ID? I think that if  
fallback content is displayed in such case, it will lead to hard-to-spot  
errors:



See 1.

In testing it will seem OK to author, but will break when list is changed.

--
regards, Kornel Lesinski