[whatwg] style sheet blocking scripts

[tali garsiel]

Hi,

This is a quote from Section 4.2 of the spec:

"A style sheet in the context of the Document of an HTML parser or XML parser 
is said to be a style sheet blocking scripts if the element was created by that 
Document's parser, and the element is either a style element or a link element 
that was an external resource link that contributes to the styling processing 
model when the element was created by the parser, and the element's style sheet 
was enabled when the element was created by the parser, and the element's style 
sheet ready flag is not yet set, and, the last time the event loop reached step 
1, the element was in that Document"


And the section about parsing - the "

Re: [whatwg] HTML5 at Last Call (at the WHATWG)

[Shumpei Shiraishi]

Hi, all.

Congratulations on Last Call!

I'm administrator of HTML5 community in Japan
(http://translate.google.co.jp/translate?prev=hp&hl=ja&js=y&u=http://blog.livedoor.jp/kotesaki/archives/1290508.html&sl=ja&tl=en&history_state0=).

I would like to make known an act to celebrate the occasion.
Today, one of the community's member have created the "HTML5 clock"
iGoogle gadget which uses the logos created by Japanese designers.

http://translate.google.co.jp/translate?prev=hp&hl=ja&js=y&u=http://blog.livedoor.jp/kotesaki/archives/1290508.html&sl=ja&tl=en&history_state0=

If someone want to give feedback to him or designers, please tell me
or post to the community's mailing list directly!

I'm sorry for talking bollocks.
Kind regards.

--Shumpei


On Wed, Oct 28, 2009 at 7:12 AM, Ian Hickson  wrote:
>
> For a brief period today, there were no outstanding e-mails or bugs on the
> specs, and so I took that opportunity to transition us here at the WHATWG
> to the next stage of HTML5's development: Last Call! This affects three
> specs at the WHATWG:
>
>  * HTML5
>   http://www.whatwg.org/specs/web-apps/current-work/multipage/
>
>  * Web Workers
>   http://www.whatwg.org/specs/web-workers/current-work/
>
>  * Microdata vocabularies
>   http://www.whatwg.org/specs/vocabs/current-work/
>
> There's also a version of the spec called Web Applications 1.0 (for
> nostalgic reasons) that has all of the above as well as a number of other
> specs, namely Web Storage, Web Database, Server-sent Events, and the Web
> Sockets API and protocol, all together in one document. With the exception
> of the Web Database spec, they're all now in last call at the WHATWG:
>
>   http://www.whatwg.org/specs/web-apps/current-work/complete.html (5MB)
>
> So if you've been waiting to see if someone else would report the problem
> that you had seen, well, if it's not fixed, they didn't! So you should now
> send that feedback in yourself.
>
> If you sent an e-mail or filed a bug that I haven't replied to, then
> please send it again. A few weeks ago I noticed that I was losing about 1%
> of e-mail to a rogue and overeager spam filter, and I don't know how long
> that had been going on, so if I didn't reply that's probably why.
>
> (Note that this only applies to the WHATWG -- the W3C HTML WG is not yet
> at Last Call.)
>
> --
> Ian Hickson               U+1047E                )\._.,--,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] HTML5 video element - default to fallback in cases where UA can't play format

[Kit Grose]

Thanks for the really in-depth reply; you make some excellent points  
(particularly defining a video source file with the src attribute). I  
think it all boils down to the fact that canPlayType() can return  
"maybe"; and in those cases the expected behaviour I mention isn't  
easily definable.

In our particular case, relying on Javascript isn't a deal-breaker so  
we'll go forward that way until we can see some commercial benefit  
targeting Gecko users more actively.

I do think this will mean holding out on one of the most exciting new  
features of HTML5 for the foreseeable future for client work, though  
(at least until we see what the MSIE roadmap for support looks like;  
if they require yet another new format, we'll inevitably change from a  
/QT/Flash hierarchy to just QT/Flash (and lose practically  
nothing). Yet again, I think the defining factor will be the mobile  
web; if hardware decoders for OGG become cheap enough to be reasonably  
added to iPhones and Blackberries, etc. the incentive to quickly  
migrate away from Flash is more clear.

Thanks for your detailed response!

—Kit

Re: [whatwg] HTML5 video element - default to fallback in cases where UA can't play format

[Aryeh Gregor]

On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose  wrote:
> Can I get some sort of an understanding on why this behaviour (non-
> descript error in supported UAs rather than using the fallback content
> that can provide alternate access methods) would be preferred?

Suppose browsers fell back to the contents if they couldn't play any
of the sources.  Then what happens if the browser isn't sure whether
it can play a video until it's started loading it?  This would be
extremely common -- it would happen any time the source is given with
src="", or if  elements are given with no type="", or even if
there was a type="" but the browser wasn't sure it supported the exact
versions or didn't fully trust the author or whatnot.  Then does the
browser not load the contents until it figures out it can't play the
video, then load the contents at some undefined later time?  So
scripts execute out of order and so on?

Or should the browser be forced to block further rendering of the page
until it knows for sure whether it can play one of the videos?  This
might require it to fetch the metadata of several videos, probably
slowing down page load considerably.  This is a bad solution as well,
especially since in the long term, one would hope that some baseline
format would be supported by all major browsers and provided by all
pages, so the forced wait would usually be pointless.

If you suggest requiring type="", and forcing browsers to guess
whether they support the video based on that, what happens if the
browser guesses yes and it turns out not to be able to play the video
after all?  Then you're back to the same unpredictable injection of
content post-load.

This is not even mentioning what happens if the list of 
elements changes after page load.  That could probably be handled.
But the above problems are pretty hard to avoid, as far as I can tell.
 So for now, you have to either double-encode or rely on JavaScript.
If this is too much of a sacrifice for you, then you should probably
wait a few years before you start using , until support is
better -- for most authors it probably won't be pragmatically worth it
until  support is so good that fallback isn't necessary
anymore.

Re: [whatwg] HTML5 video element - default to fallback in cases where UA can't play format

[Kit Grose]

G'day Gregory,

Thanks for the explanation. While I understand the issue you present  
with precedence of JS and fallback content, I can't off the top of my  
head come up with any necessary uses for the canPlayType function  
(maybe as a nice-to-have, of course) had the behaviour worked more  
predictably—particularly if the tradeoff is a totally non-workable  
solution in modern browsers with NoScript turned on in situations like  
mine. What happens if/when IE comes to the party but requires WMV  
output? Will we all then encode *three* of the same video just to get  
broader support? I can't see the complexity of that operation every  
trumping the ease of use (from a content producer's end) of a single  
FLV with a Flash video player, which is surely the ultimate goal here.

As far as the standards compliance etc. goes; the site is not client  
work, and isn't going to be deployed/marketed as a standard website  
(hence my taking a risk on using the HTML5 doctype at all).

The trade-offs for us to implement OGG—in this particular case, at  
least—just for the sake of idealism aren't worth the maintenance cost  
penalty we'd pay by providing (encoding, hosting, etc., etc.) two  
video formats; the site will explicitly target users we know to use IE  
for the most part, but should also work on the iPhone (the customer is  
ourselves). That made V4E a good fit and I was keen to experiment with  
the video element myself anyway.

I just found the behaviour of the element highly contrary to what I  
had expected and wanted to raise it as a concern.

—Kit

On 28/10/2009, at 12:28 PM, Gregory Maxwell wrote:

> On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose   
> wrote:
> [snip]
>> I expected (incorrectly, in this case) that if I only produced one
>> source element (an MP4), Firefox would drop down to use the fallback
>> content, as it does if I include an object element for a format not
>> supported (for example, if I include a QuickTime object and QT is not
> [snip]
>
> Please see the list archives:
> http://www.mail-archive.com/whatwg@lists.whatwg.org/msg16092.html
>
> In short, there are corner cases which make this untenable. E.g. what
> happens when you have JS doing brilliant canplaytype magic, but also
> provide tag-interior fallbacks for clients which may not even have JS?
> They'll fire off and start before your JS has a chance to do its
> canplaytype magic.
>
>
> Of course, "standards-compliant HTML/XHTML using CSS and Javascript as
> required by the design", as your products are described, is pretty
> meaningless when its applied to sites no more compatible than the bad
> old "Works best in IE" days, only it's now Apple™ and Adobe™.  I urge
> you to consider the values of an open and interoperable web against
> the costs, and I hope you are informing your customer(s) about any
> long term licensing fees for the formats chosen for their site.

[whatwg] focus change inside keypress event handler

[Michael A. Puls II]

(CCing DOM list just in case anyone there has any comments)

With:



, if you type a character in the first field, should the character be  
entered in the second field or the first?


In Firefox and Safari, it's the first field. In IE and Opera, it's the  
second.


I'm pretty sure Opera's model is just old, willful compat with IE.

However, with  
,  
it has an IE code path and a FF code path. In Opera's case, it gets the FF  
code path. That's good, but Opera's not compatible with FF in this case.


Right now, Opera has a workaround in its browser.js to solve this.  
However, I believe Opera might eventually change to be like FF and Safari  
(in which case the workaround would be removed), but not totally sure.


I do think FF and Safari's way makes more sense and I think most will  
agree.  Could you make sure the spec is clear on this.


(I think I mentioned this before but cannot find the message or text in  
HTML5 that says what to do for sure.)


--
Michael

Re: [whatwg] HTML5 video element - default to fallback in cases where UA can't play format

[Gregory Maxwell]

On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose  wrote:
[snip]
> I expected (incorrectly, in this case) that if I only produced one
> source element (an MP4), Firefox would drop down to use the fallback
> content, as it does if I include an object element for a format not
> supported (for example, if I include a QuickTime object and QT is not
[snip]

Please see the list archives:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg16092.html

In short, there are corner cases which make this untenable. E.g. what
happens when you have JS doing brilliant canplaytype magic, but also
provide tag-interior fallbacks for clients which may not even have JS?
 They'll fire off and start before your JS has a chance to do its
canplaytype magic.


Of course, "standards-compliant HTML/XHTML using CSS and Javascript as
required by the design", as your products are described, is pretty
meaningless when its applied to sites no more compatible than the bad
old "Works best in IE" days, only it's now Apple™ and Adobe™.  I urge
you to consider the values of an open and interoperable web against
the costs, and I hope you are informing your customer(s) about any
long term licensing fees for the formats chosen for their site.

Re: [whatwg] the cite element

[Ian Hickson]

On Mon, 5 Oct 2009, tjeddo wrote:
> 
> I believe that the current HTML5 spec is heading in the right direction 
> by narrowing the meaning of the cite element compared to its ambiguous 
> use in HTML documents in the past. Overloading the meaning of the cite 
> element further by using it to distinguish speaker's names would not 
> only add ambiguity but would require developer's (who want to honor 
> typographical convention) to undo the default italics styling that would 
> be applied to the speaker's name when enclosed by  tags.

Indeed.


> I feel it is an improvement to HTML that the cite element is being 
> focused to specify the "title of a work." It is however unfortunate that 
> the element's name is 'cite' for legacy HTML reasons.

True. The name is pretty close -- it's in fact closer for most people than 
I realised it was, in fact, since people interpret HTML4's definition as a 
superset of HTML5's, and not a subset, as I do -- but as with many things 
in HTML5, it's certainly not ideal.


> I would much prefer the name of the cite element be reserved for a 
> purpose equivalent to the use of \cite{} in LaTeX.
> 
> However, given the ambiguity of the HTML4 specification as to the 
> correct usage of the 'cite' element, I'm wondering if we shouldn't align 
> the 'cite' element with a more intuitive use case matching that of 
> satisfied by \cite{} in LaTeX. And introduce a new inline element called 
> 'tow' (title of work) or 'tor' (title of reference), for example, to 
> explicitly specify the "title of a work."

\cite{} in LaTeX is basically a cross-referencing mechanism: you define a 
bibliographic entry, and then you can generate a cross-reference to it 
using \cite{} in the main text.

This use case is already handled by  -- for example, the HTML5 
spec has a bunch of bibliogaphic entries at the bottom, written as:

   [X690]
   http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf";>Recommendation
   X.690 — Information Technology — ASN.1 Encoding Rules —
   Specification of Basic Encoding Rules (BER), Canonical Encoding
   Rules (CER), and Distinguished Encoding Rules
   (DER). International Telecommunication Union, July
   2002.

...and then to reference them, I just write:

   [X690]

I think is adequate. It doesn't support more advanced use cases like 
automatic reference generation when copying and pasting, but that can be 
handled by microdata.

Now, if we do in fact conclude that the use case for \cite{} is already 
handled by , that leaves us with the choice of what to do for 
titles of works. We could make  obsolete and introduce a new 
element, with the same default styles, and with a better name, like  
or  or  or something. However, support for the element would 
take years to be deployed enough to be usable, and in the meantime 
browsers would still have the support of , so this would not be a 
cheap solution. On the other hand, if we just reuse , by slightly 
adjusting the definition in HTML4, we end up with a solution more or less 
for free.


> In fact, the two examples given in the HTML4 spec for using  are 
> both incorrect according to the current HTML5 definition:
> 
>  - "As Harry S. Truman said,"
>  - More information can be found in [ISO-]."

Sure, but then many of the examples in HTML4 aren't even conforming to 
HTML4, so that's not necessarily a big concern. :-)


> By the way, what is the reasoning in the HTML5 spec for stating that 
> ship names should not be marked up with  but should use  
> instead?
> 
> I guess I'm saying, why are ships not considered "works?"

I suppose one could indeed make a somewhat convincing argument that a ship 
is a work. I'm not sure I'd want to try to sell that though. I've removed 
the sentence that says a ship isn't a work, but I haven't added ships to 
the list works.


> Here are three references that indicate specifically that Ship names
> receive the same typographic treatment as other titles of works.

Oh I agree that they do; that's why  is suggested. So should emphasis.


On Tue, 6 Oct 2009, Erik Vorhes wrote:
> >
> > Is there as much semantic value in pointing to the primary source of a 
> > statement as there is in knowing that the word "earth" refers to the 
> > planet and not the dirt, for example? If so, what is that extra value?
> 
> Identifying speakers and other sources of attribution have multiple 
> use-cases, as identified previously to this list. Such uses are often 
> extra-contextual, unlike your example of "earth." I don't know how 
> otherwise to respond to such laughably obvious "reductio ad absurdum" 
> arguments.

I'm not aware of any use cases that have been put forward that  
addresses adequately and that are compelling enough to need solving. Could 
you list them explicitly?


> It may not need to be , per se, but that is the element that has 
> been used in examples of multiple kinds of quote + attribution markup 
> patterns. And since the WG has a general aversion to creatin

[whatwg] HTML5 video element - default to fallback in cases where UA can't play format

[Kit Grose]

G'day list,

I've been working on my first HTML5 frontend, which is using the video  
element, and I've run into a part of the spec that I disagree with  
(and would like to understand its justification):

> Content may be provided inside the video element. User agents should  
> not show this content to the user; it is intended for older Web  
> browsers which do not support video, so that legacy video plugins  
> can be tried, or to show text to the users of these older browsers  
> informing them of how to access the video contents.


(from 4.8.7: 
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html 
)

As a content producer, I have no desire to double-encode all our  
existing videos (from their current H.264 format into OGG), especially  
we really only see around 5–8% Firefox marketshare on this site. I'm  
using Kroc Camen's Video For Everybody 
(http://camendesign.com/code/video_for_everybody 
), so UAs which don't support the video element get a QuickTime object  
first, and a Flash 9+ player (capable of playing H.264 video) next,  
and lastly a video download link.

I expected (incorrectly, in this case) that if I only produced one  
source element (an MP4), Firefox would drop down to use the fallback  
content, as it does if I include an object element for a format not  
supported (for example, if I include a QuickTime object and QT is not  
installed, the user sees fallback content). As far as I can see, the  
only option in this situation is to rely on Javascript and the video  
element's canPlayType() function.

Can I get some sort of an understanding on why this behaviour (non- 
descript error in supported UAs rather than using the fallback content  
that can provide alternate access methods) would be preferred?

Cheers,


Kit Grose
User Experience + Tech Director
iQmultimedia

+61 (0)2 4260 7946
k...@iqmultimedia.com.au
iqmultimedia.com.au

[whatwg] HTML5 at Last Call (at the WHATWG)

[Ian Hickson]

For a brief period today, there were no outstanding e-mails or bugs on the 
specs, and so I took that opportunity to transition us here at the WHATWG 
to the next stage of HTML5's development: Last Call! This affects three 
specs at the WHATWG:

 * HTML5
   http://www.whatwg.org/specs/web-apps/current-work/multipage/

 * Web Workers
   http://www.whatwg.org/specs/web-workers/current-work/

 * Microdata vocabularies
   http://www.whatwg.org/specs/vocabs/current-work/

There's also a version of the spec called Web Applications 1.0 (for 
nostalgic reasons) that has all of the above as well as a number of other 
specs, namely Web Storage, Web Database, Server-sent Events, and the Web 
Sockets API and protocol, all together in one document. With the exception 
of the Web Database spec, they're all now in last call at the WHATWG:

   http://www.whatwg.org/specs/web-apps/current-work/complete.html (5MB)

So if you've been waiting to see if someone else would report the problem 
that you had seen, well, if it's not fixed, they didn't! So you should now 
send that feedback in yourself.

If you sent an e-mail or filed a bug that I haven't replied to, then 
please send it again. A few weeks ago I noticed that I was losing about 1% 
of e-mail to a rogue and overeager spam filter, and I don't know how long 
that had been going on, so if I didn't reply that's probably why.

(Note that this only applies to the WHATWG -- the W3C HTML WG is not yet 
at Last Call.)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] localStorage feedback

[Ian Hickson]

On Tue, 27 Oct 2009, timeless wrote:
> On Tue, Oct 13, 2009 at 4:07 AM, Ian Hickson  wrote:
> > I've edited the latter text to indicate that the expiration should 
> > only be done at user option.
> 
> On a device with limited storage, is the user option of having a device 
> that still boots and operates a sufficient "option"?
> 
> I'm looking at a device which tends to run out of space regularly but 
> which wants to support web standards.

I don't know that that's possible.


> If I visit 50 sites and collect junk for all of them, and i have a 
> screen which can barely show 5 site names + 1 line descriptions for 
> sites, then i'm not quite sure my user option of being able to 
> conveniently manage those sites will really exist.

On such a device you probably shouldn't be letting all sites store data 
without the user opting into it.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] localStorage feedback

[timeless]

On Tue, Oct 13, 2009 at 4:07 AM, Ian Hickson  wrote:
> I've edited the latter text to indicate that the expiration should only be
> done at user option.

On a device with limited storage, is the user option of having a
device that still boots and operates a sufficient "option"?

I'm looking at a device which tends to run out of space regularly but
which wants to support web standards.

If I visit 50 sites and collect junk for all of them, and i have a
screen which can barely show 5 site names + 1 line descriptions for
sites, then i'm not quite sure my user option of being able to
conveniently manage those sites will really exist.

User Agents always have the option of acting on the behalf of their user.

Web sites should be encouraged to design their content in a way which
warns the user about unsynchronized data and explains that they
probably should rely on syncing or backing up their data.

If I have a draft message in GMail, when I try to navigate away from
it, it helpfully warns me that my email could be lost. Web
applications shouldn't become less intelligent than that.

Re: [whatwg] A call for tighter validation standards

[Ian Hickson]

On Tue, 27 Oct 2009, Eduard Pascual wrote:
> On Fri, Oct 23, 2009 at 4:36 AM, Ian Hickson  wrote:
> > I think less rigid styles are good, and are what made the Web the success
> > that it is. Authors are welcome to use validators that complain about this
> > kind of markup, but we should enforce this style on everyone. Some people
> > (e.g. me) like being able to omit tags.
> 
> I hope you mean't "we shouldn't" rather than "we should".

Right, sorry!

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Author requirements of the progress element

[Ian Hickson]

On Tue, 27 Oct 2009, Futomi Hatano wrote:
> 
> I'd like to talk about the author requirements of the progress element.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-progress-element
> 
> There are some cases in the requirements.
> But one case is dropped.
> 
> "The value attribute is specified but the max attribute is not specified"
> 
> Is this case intended to be dropped?

Oops, that was an unintended omission. Fixed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Web Sockets API — send() with clos ed connections

[Avi Flax]

On Tue, Oct 27, 2009 at 01:17, Ian Hickson  wrote:


> The connection might get closed at any point, e.g. between the script
> checking if the connection might be closed and the script calling the
> send() method. Because of this, if we raised an exception when the
> connection was closed, we'd run the risk of the script randomly throwing
> an exception in a way that the author likely did not check for.
>
> This isn't a problem for the CONNECTING case, since there is an event that
> fires before the script can use the send() method, and thus the author is
> unlikely to accidentally run into that exception in a way that wouldn't
> be quickly caught in testing.


Makes sense. Thanks!

-- 
Avi Flax » Partner » Arc90 » http://arc90.com

Re: [whatwg] sessionStorage and the Storage event

[Honza Bambas]

Ian Hickson wrote:

On Tue, 27 Oct 2009, Honza Bambas wrote:
  

The spec says:

"When the |setItem()
|, |removeItem()
|, and |clear()
| methods are called on
a |Storage | object x that is
associated with a session storage area, if the methods did something, then in
every |HTMLDocument| object whose |Window| object's |sessionStorage
| attribute's |Storage
| object is associated with the
same storage area, other than x, a |storage
| event must be fired, as
described below ."

[http://dev.w3.org/html5/webstorage/#dom-sessionstorage]

The same applies to localStorage.

Maybe I read something wrong, but as a sessionStorage object is always 
unique to its document (it is cloned when a new document with the same 
origin is created and then independent from the original document's 
object) it, in my opinion, doesn't make sense to send the event to any 
other document then the one its storage has been changed. On the other 
hand, it makes sense to me to not fire the event in the same document 
where the storage has been changed (as for localStorage), then, I'd say 
there should be no event for sessionStorage at all. I simply don't a 
case when two or more documents would share a single sessionStorage 
object.


Thanks for clearing this.



You can have multiple (active) documents sharing the same sessionHistory 
using nested browsing contexts, for example in , , and 
/.


  

s/sessionHistory/sessionStorage/ ?

Ah, true. sessionStorage object is shared within the toplevel browsing 
context for all nested documents with the same origin. Then it makes 
sense to send the message to all those documents.


Thanks for clarifying.
-hb-

Re: [whatwg] sessionStorage and the Storage event

[Honza Bambas]

Jonas Sicking wrote:

On Mon, Oct 26, 2009 at 4:06 PM, Honza Bambas  wrote:
  

The spec says:

"When the setItem(), removeItem(), and clear() methods are called on a
Storage object x that is associated with a session storage area, if the
methods did something, then in every HTMLDocument object whose Window
object's sessionStorage attribute's Storage object is associated with the
same storage area, other than x, a storage event must be fired, as described
below."

[http://dev.w3.org/html5/webstorage/#dom-sessionstorage]

The same applies to localStorage.

Maybe I read something wrong, but as a sessionStorage object is always
unique to its document (it is cloned when a new document with the same
origin is created and then independent from the original document's object)
it, in my opinion, doesn't make sense to send the event to any other
document then the one its storage has been changed. On the other hand, it
makes sense to me to not fire the event in the same document where the
storage has been changed (as for localStorage), then, I'd say there should
be no event for sessionStorage at all. I simply don't a case when two or
more documents would share a single sessionStorage object.



Huh? Does documents from the same session not all share sessionStorage
data? I.e. in the following set of events:

1. User navigates to http://example.com/a.html
2. Page sets sessionStorage.foo = "hi";
3. User navigates, in same window, to http://example.com/b.html
4. Page sets sessionStorage.foo = "saxophone";
5. User clicks back-button, which puts him back at http://example.com/a.html
6. Page does x = sessionStorage.foo;

what is the value of 'x'? I would have expected it to be "saxophone",
is that not the case. This seems to be required in order to do for
example multi-page forms.

/ Jonas

  
Jonas, please read "unique to its document" as "unique to its browsing 
context". I was wrong. In step 6 you'll get saxophone ;)


-hb-

Re: [whatwg] A call for tighter validation standards

[Eduard Pascual]

On Fri, Oct 23, 2009 at 4:36 AM, Ian Hickson  wrote:
> I think less rigid styles are good, and are what made the Web the success
> that it is. Authors are welcome to use validators that complain about this
> kind of markup, but we should enforce this style on everyone. Some people
> (e.g. me) like being able to omit tags.

I hope you mean't "we shouldn't" rather than "we should".

Regards,
Eduard Pascual

[whatwg] Author requirements of the progress element

[Futomi Hatano]

Hi, all

I'd like to talk about the author requirements of the progress element.
http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-progress-element

There are some cases in the requirements.
But one case is dropped.

"The value attribute is specified but the max attribute is not specified"

Is this case intended to be dropped?
If so, why?

I think that this case is necessary specially in Japanese language.
Word order of Japanese language is different from English language.
In addition, Japanese people often use kanji characters or two-byte characters 
to represent the completion progress of a task.
So, the case of "no value, no max, 2 numbers in " is not easy to use 
in Japanese document.
Neither, the case of "no value, max specified, 1 number in ".
But the case of "value specified, no max" is easy to use in Japanese language.
For example, 

kanji characters which represent 20%

In this case, the max value should be 1.
So, UAs can determine the rate of the progress.
I think that this case has no problem as one of the requirements.

I know that I can use the case of "value specified, max specified".

kanji characters which represent 20%

But, I think that there is no reason why the case of "value specified, no max" 
is dropped.

Thank you.

--
Futomi Hatano
www.html5.jp

Re: [whatwg] sessionStorage and the Storage event

[Anne van Kesteren]

On Tue, 27 Oct 2009 00:06:41 +0100, Honza Bambas   
wrote:

Maybe I read something wrong, but as a sessionStorage object is always
unique to its document (it is cloned when a new document with the same
origin is created and then independent from the original document's
object) it, in my opinion, doesn't make sense to send the event to any
other document then the one its storage has been changed. On the other
hand, it makes sense to me to not fire the event in the same document
where the storage has been changed (as for localStorage), then, I'd say
there should be no event for sessionStorage at all. I simply don't a
case when two or more documents would share a single sessionStorage  
object.


sessionStorage is shared with e.g. same-origin child browsing contexts so  
it is not limited to a single Document.



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

Re: [whatwg] HTMLElement.onload

[Ian Hickson]

On Tue, 27 Oct 2009, Markus Ernst wrote:
> 
> Thank you. In this table
> http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html#events-0
> there is now the error event left with no indication where the event is fired,
> but only when it is fired.

Fixed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] sessionStorage and the Storage event

[Ian Hickson]

On Tue, 27 Oct 2009, Honza Bambas wrote:
>
> The spec says:
> 
> "When the |setItem()
> |, |removeItem()
> |, and |clear()
> | methods are called on
> a |Storage | object x that is
> associated with a session storage area, if the methods did something, then in
> every |HTMLDocument| object whose |Window| object's |sessionStorage
> | attribute's |Storage
> | object is associated with the
> same storage area, other than x, a |storage
> | event must be fired, as
> described below ."
> 
> [http://dev.w3.org/html5/webstorage/#dom-sessionstorage]
> 
> The same applies to localStorage.
> 
> Maybe I read something wrong, but as a sessionStorage object is always 
> unique to its document (it is cloned when a new document with the same 
> origin is created and then independent from the original document's 
> object) it, in my opinion, doesn't make sense to send the event to any 
> other document then the one its storage has been changed. On the other 
> hand, it makes sense to me to not fire the event in the same document 
> where the storage has been changed (as for localStorage), then, I'd say 
> there should be no event for sessionStorage at all. I simply don't a 
> case when two or more documents would share a single sessionStorage 
> object.
> 
> Thanks for clearing this.

You can have multiple (active) documents sharing the same sessionHistory 
using nested browsing contexts, for example in , , and 
/.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] HTMLElement.onload

[Markus Ernst]

Ian Hickson schrieb:

On Sun, 25 Oct 2009, Markus Ernst wrote:
The spec says in 3.2.3: "The following event handler content attributes 
may be specified on any HTML element" - with my quite trivial 
understanding, I would actually expect something to happen if I do this. 
The note "The attributes marked with an asterisk have a different 
meaning when specified on body elements as those elements expose event 
handlers of the Window object with the same names" does not correct this 
expectation, but rather implies, that onload on any element has an 
effect, as it is supposed to have another effect than when specified in 
the body element.


I've tried to clarify this by adding a note after the one you mention.


Also, in this events table, the description of the load event is very 
rudimentary: "Fired when a resource has finished loading". I suggest 
changing this to something like: "Fired at the Window object when the 
document has finished loading, or at an element containing a resource, 
when the resource has finished loading".


Ok.


Thank you. In this table
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html#events-0
there is now the error event left with no indication where the event is 
fired, but only when it is fired.

Re: [whatwg] Example wrong in web workers

[Ian Hickson]

On Mon, 26 Oct 2009, Simon Pieters wrote:
>
> Web Workers has the following in some example (twice):
> 
> // support being used as a shared worker as well as a dedicated worker
> if (this.onmessage) // dedicated worker
>   
> 
> This ought to be doing something like (typeof this.onmessage != 'undefined') ,
> as the event property is presumably 'null' by the time of the test.

Fixed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Issue on drag & drop example in specification?

[Ian Hickson]

On Mon, 26 Oct 2009, Shumpei Shiraishi wrote:
> 
> I'm sorry for delay of replying and thanks for your post very much.
> 
> > Here you want to put the preventDefault() after the for() loop, so 
> > that it cancels the event only if the type was not found.
> 
> Mmm, it seems my mistake about understanding the specification...

Actually no, my mistake, sorry!

Your example should work, with the call in question put in (not commented 
out). If it doesn't, then that's a bug in the relevant browsers. I just 
tried it in a recent WebKit nightly build and it seems to work with the 
line included.


> And what I wanted to say is, "dnd operation is performed in spite of
> omitting to call preventDefault() in dragenter event, so could I omit
> to handle the dragenter event?".

If you omit the preventDefault() call, the drag shouldn't be allowed on 
the element on which the event wasn't canceled.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'