Re: [whatwg] Section 4.10.4.1.4 and Section 9.1.2.6

[Ian Hickson]

On Fri, 14 Aug 2009, Kevin Benson wrote:
>
> In section "4.10.4.1.4 URL state", the text reads:
> 
> "The input element represents a control for editing a single absolute
> URL given in the element's value.
> 
> If the is mutable, the user agent should allow the user to change the
> URL represented by its value."
> 
> 
> I believe that last line should read:
> 
> "If the input element is mutable, ..."

Oops. Thanks. Fixed.


> ALSO, in section "9.1.2.6 Restrictions on the contents of raw text and
> RCDATA elements" there is text that reads:
> 
> "An escaping text span end is a part of text that consists of the
> three character sequence "-->" (U+002D HYPHEN-MINUS, U+002D
> HYPHEN-MINUS, U+003E GREATER-THAN SIGN) whose U+003E GREATER-THAN SIGN
> (>)."
> 
> The part that reads "... whose U+003E GREATER-THAN SIGN (>)" seems
> incomplete, out of place or unclear.

Fixed, thanks.

I've no idea how the first error came to be or what I originally was going 
to say in the dangling clause in the second. :-)

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

Re: [whatwg] Possible typo in application cache section

[Ian Hickson]

On Thu, 6 Aug 2009, Darin Adler wrote:
>
> 6.9.4, paragraph 7 says, �applications caches never include fragment
> identifiers� and I think this should just be �application caches�.

Fixed, thanks.

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

[whatwg] Section 4.10.4.1.4 and Section 9.1.2.6

[Kevin Benson]

In section "4.10.4.1.4 URL state", the text reads:

"The input element represents a control for editing a single absolute
URL given in the element's value.

If the is mutable, the user agent should allow the user to change the
URL represented by its value."


I believe that last line should read:

"If the input element is mutable, ..."

--

ALSO, in section "9.1.2.6 Restrictions on the contents of raw text and
RCDATA elements" there is text that reads:

"An escaping text span end is a part of text that consists of the
three character sequence "-->" (U+002D HYPHEN-MINUS, U+002D
HYPHEN-MINUS, U+003E GREATER-THAN SIGN) whose U+003E GREATER-THAN SIGN
(>)."

The part that reads "... whose U+003E GREATER-THAN SIGN (>)" seems
incomplete, out of place or unclear.

-- 
-- 
   --
   --
   ô¿ô¬
K e V i N
   /¯\

Re: [whatwg] 2.2 Performant

[Ian Hickson]

On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote:
>
> "In particular, the algorithms defined in this specification are 
> intended to be easy to follow, and not intended to be performant."
> 
> Yech. The recently coined word "performant" just grates on my ears; and 
> I'm not the only one as a Google search will show: 
> http://www.google.com/search?ie=UTF-8&oe=UTF-8&q=performant

It's language evolution at work:

   http://en.wiktionary.org/wiki/performant


> Perhaps we could replace it with "efficient" or some other word or 
> phrase?

"Efficient" is more about efficient use of resources rather than about the 
performance of the solution. A solution might be very efficient but very 
slow. I guess we could use "fast", but it seems rather pessimistic to call 
even the most naive implementation of the algorithms in the spec "slow", 
given that we're talking about performing millions of operations per 
second here.

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

Re: [whatwg] 2.2 editorial

[Ian Hickson]

On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote:
>
> Applications and tools that process HTML and XHTML documents for reasons 
> other than to either render the documents or check them for conformance 
> should act in accordance to the semantics of the documents that they 
> process.
>
> 2.2 editorial
> 
> "in accordance to" --> "in accordance with"

Fixed.

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

Re: [whatwg] HTML 5 Script Tag

[Ian Hickson]

On Thu, 6 Aug 2009, Cready, James wrote:
>
> Is there any good reason why a 

Re: [whatwg] 2.1.6 Editorial actually

[Ian Hickson]

On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote:
>
> "the image actually also contained animation data."
> 
> delete "actually". It adds nothing to the sentence.

I think it reads better with it, but ok. Removed.

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

Re: [whatwg] 2.1.1 (they are in the per-element partition)

[Ian Hickson]

On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote:
>
> I suggest deleting the parenthetical remark "(they are in the 
> per-element partition)". I'm not sure what this term means. I've never 
> encountered either "partition" or "per-element partition" in an XML 
> namespace context before.

It was a term from the first XMLNS spec:

   http://www.w3.org/TR/1999/REC-xml-names-19990114/#ns-breakdown

It's been removed, though, so I removed the parenthetical.

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

Re: [whatwg] Editorial: 1.9 DOCTYPE HTML

[Ian Hickson]

On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote:
>
> Section 1.9 uses this DOCTYPE twice:
> 
> 
> 
> Unless the intention is to demonstrate case-insensisitivity, which 
> doesn't seem to be the case since that's not otherwise mentioned in this 
> section, I think this should be:
> 
> 
> 
> as section 4.2 of the FAQ recommends.

On Thu, 6 Aug 2009, Tab Atkins Jr. wrote:
> 
> Ian has said before that he purposely writes examples in multiple styles 
> just to ensure that the spec isn't construed as defining a single 
> 'correct' style through them.

Tab is correct, but to encourage the lowercase variant I've changed some 
of the examples to have the earlier section use lowercase text.

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

Re: [whatwg] Section 1.7 editorial

[Ian Hickson]

On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote:
>
> The first such concrete syntax is "HTML5". This is the format 
> recommended for most authors. It is compatible with all legacy Web 
> browsers. If a document is transmitted with the MIME type text/html, 
> then it will be processed as an "HTML5" document by Web browsers.
> 
> The second concrete syntax uses XML, and is known as "XHTML5". When a 
> document is transmitted with an XML MIME type, such as 
> application/xhtml+xml, then it is processed by an XML processor by Web 
> browsers, and treated as an "XHTML5" document.
> 
> The last sentence is awkward. I think making it more parallel with the 
> previous paragraph would help. I.e.
> 
> If a document is transmitted with an XML MIME type, such as 
> application/xhtml+xml, then it will be processed as an "XHTML5" document 
> by Web browsers.

I've tried improving the paragraph. Thanks.

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

Re: [whatwg] Section 1.7 "abstract language"

[Kevin Benson]

On Thu, Aug 13, 2009 at 10:10 PM, Ian Hickson wrote:
> On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote:
>>
>> "This specification defines an abstract language for describing
>> documents and applications, and some APIs for interacting with in-memory
>> representations of resources that use this language."
>>
>> The phrase "abstract language" concerns me. It's not clear to me that a
>> language can be abstract, nor is it clear to me what this phrase refers
>> to, especially since it seems to be distinguished from the "concrete
>> syntaxes that can be used to transmit resources that use this abstract
>> language, two of which are defined in this specification."
>>
>> Perhaps there's some sort of abstract data model or information model
>> here; but I don't believe that the word "language" is appropriate to
>> describe this. Language as normally understood is a collection of actual
>> words or symbols, written or spoken. It is not a collection of abstract
>> concepts, at least not in any definition of the term I was able to find.
>>
>> http://www.google.com/search?hl=en&safe=off&q=define%3Alanguage&aq=f&oq=&aqi=g10
>
> What term would you recommend rather than "language" that is more
> understandable than "data model" or "information model"?
>
> Would "vocabulary" be ok?
>
> --
> Ian Hickson
>
Pardon me for interjecting myself into your exchange.

Rather than changing the word "language", how about changing the the
word "abstract" instead...
...to an adjective such as "prescriptive" or "normative"...
in order to describe the usage of the word "language" more purposefully ?

Just a thought.

-- 
-- 
   --
   --
   ô¿ô¬
K e V i N
   /¯\

Re: [whatwg] HTML5: compatible with all legacy Web browsers

[Ian Hickson]

On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote:
>
> Section 1.7:
> 
> "The first such concrete syntax is "HTML5". This is the format 
> recommended for most authors. It is compatible with all legacy Web 
> browsers."
> 
> I challenge the claim that HTML5 is compatible with *all* legacy Web 
> browsers. I can produce valid HTML 4 documents today that are not 
> compatible with *all* legacy Web browsers. I suggest this be weakened to 
> something like "is compatible with most Web browsers still in active use 
> today".

Changed "all" to "most".


On Fri, 7 Aug 2009, Simon Pieters wrote:
> 
> I guess the following is an example of a valid HTML5 document that is 
> incompatible with legacy Web browsers:
> 
>
>
>
>Hello world

It's certainly possible to use the language in a way that is incompatible 
with legacy UAs. 


On Fri, 7 Aug 2009, Aryeh Gregor wrote:
>
> I think the meaning of "compatible with all existing browsers" here is
> that HTML 5 does not *require* authors to break compatibility with any
> existing browser.

Exactly.


> Clearer wording might be like, "HTML5 pages can be written to be 
> compatible with all legacy Web browsers."  Of course, "all legacy Web 
> browsers" does need to be construed to exclude Netscape Navigator 3 and 
> such.  If you really want to be picky, it could be "all legacy Web 
> browsers that still see significant use."

I think just saying the language is compatible is probably clear enough.


On Fri, 7 Aug 2009, Erik Vorhes wrote:
> 
> I agree completely with your interpretation of the phrase. HTML5 is 
> intended to enhance the web without breaking it, so noting (or even 
> emphasizing) how it's backwards-compatible is important and useful.
> 
> But the phrase should be clarified along similar lines to what you've 
> articulated. Maybe: "HTML5 can be written in such a way that it is 
> compatible with all browsers made after X date"?

I don't think most people reading this are really going to be confused 
either way on this.

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

Re: [whatwg] Section 1.7 "abstract language"

[Ian Hickson]

On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote:
>
> "This specification defines an abstract language for describing 
> documents and applications, and some APIs for interacting with in-memory 
> representations of resources that use this language."
> 
> The phrase "abstract language" concerns me. It's not clear to me that a 
> language can be abstract, nor is it clear to me what this phrase refers 
> to, especially since it seems to be distinguished from the "concrete 
> syntaxes that can be used to transmit resources that use this abstract 
> language, two of which are defined in this specification."
> 
> Perhaps there's some sort of abstract data model or information model 
> here; but I don't believe that the word "language" is appropriate to 
> describe this. Language as normally understood is a collection of actual 
> words or symbols, written or spoken. It is not a collection of abstract 
> concepts, at least not in any definition of the term I was able to find.
> 
> http://www.google.com/search?hl=en&safe=off&q=define%3Alanguage&aq=f&oq=&aqi=g10

What term would you recommend rather than "language" that is more 
understandable than "data model" or "information model"?

Would "vocabulary" be ok?

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

Re: [whatwg] behavior

[Ian Hickson]

On Thu, 6 Aug 2009, Andrew Oakley wrote:
>
> The rules in the HTML5 spec for which plugin to load for an  do 
> not seem to be followed by any browser, and in some cases are different 
> to behavior that is common to Opera, Webkit and Gecko (I haven't tested 
> with IE due to its lack of nsplugin support).
> 
> Most notably HTML5 says that the Content-Type header is used in 
> preference to the type attribute, whereas the browsers seem to honour 
> the attribute in preference to the header.  (If the spec is changed to 
> match the browsers behaviour then the conditions on when to load a new 
> plugin also need to be changed.)  HTML5 also seems to prefer the type 
> attribute on 

Re: [whatwg] Editorial section 1.5.1 serialising

[Ian Hickson]

On Wed, 5 Aug 2009, Elliotte Rusty Harold wrote:
>
> "completely serialising the execution of all scripts".
> 
> -->
> 
> serializing (i.e. use the American spelling used throughout the rest of 
> the document.)

Thanks. Fixed.

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

Re: [whatwg] Editorial, section 1.5

[Ian Hickson]

On Wed, 5 Aug 2009, Elliotte Rusty Harold wrote:
>
> I suggest simply deleting "It must be admitted that many aspects of HTML 
> appear at first glance to be nonsensical and inconsistent." I would 
> disagree with nonsensical, and in any case this sentence adds nothing to 
> the text.
> 
> However if this sentence is retained, at least deleted "It must be 
> admitted that" in favor of simply "Many aspects of HTML appear at first 
> glance to be nonsensical and inconsistent" or better yet "Many aspects 
> of HTML appear at first glance to be inconsistent" or even "Many aspects 
> of HTML are inconsistent."
> 
> If any part of this sentence is retained, it should be combined with the 
> following paragraph. In fact, the first 3 paragraphs could likely be 
> combined.

Could you elaborate on your reasoning? At first blush, the current text 
seems better than what you are suggesting, but maybe I am missing something.

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

Re: [whatwg] Section 1.4: Editorial: Avoid passive voice

[Ian Hickson]

On Wed, 5 Aug 2009, Elliotte Rusty Harold wrote:
>
> Section 1.4 currently states:
> 
> Work on HTML 5 originally started in late 2003, as a proof of concept to 
> show that it was possible to extend HTML 4's forms to provide many of 
> the features that XForms 1.0 introduced, without requiring browsers to 
> implement rendering engines that were incompatible with existing HTML 
> Web pages. At this early stage, while the draft was already publicly 
> available, and input was already being solicited from all sources, the 
> specification was only under Opera Software's copyright.
> 
> In early 2004, some of the principles that underlie this effort, as well 
> as an early draft proposal covering just forms-related features, were 
> presented to the W3C jointly by Mozilla and Opera at a workshop 
> discussing the future of Web Applications on the Web. The proposal was 
> rejected on the grounds that the proposal conflicted with the previously 
> chosen direction for the Web's evolution.
> 
> Active voice would be more forceful and possibly more accurate here.

The choice of the passive voice was intentional here, to avoid making this 
paragraph about who was involved, but instead keeping it about the work.

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

Re: [whatwg] Remove addCueRange/removeCueRanges

[Silvia Pfeiffer]

Hi Markus,

2009/8/13 Dr. Markus Walther :
> please note that with cue ranges removed, the last HTML 5 method to
> perform audio subinterval selection is gone.

Not quite. You can always use the video.currentTime property in a
javascript to directly jump to a time offset in a video. And in your
javascript you can check this property until it arrives at your
determined end time. So, there is a way to do this even now.

I agree that this is rather crude and not integrated, which is why I
am working on a callback addition to the itext specification. However,
the situation is not as bad as you may think.

Also, I don't think keeping the cueRange specification in the spec
will change the current situation with browser vendors not
implementing it. So, your needs won't be satisfied no matter whether
it says or not.

We could decide to keep the cueRange proposal in the spec as a
reminder that there is still a problem to be solved. However, since we
have removed such "reminders" elsewhere in the spec (e.g. the need for
a baseline codec), it doesn't seem to make much sense to me to keep it
as a reminder.

Just my 2c. :-)

Cheers,
Silvia.

Re: [whatwg] AppCache online whitelist wildcard bypasses restriction on scheme

[Ian Hickson]

On Wed, 5 Aug 2009, Jenn Braithwaite (�~C��~E��~K~R) wrote:
> 
> In the AppCache section of the HTML5 spec, the new wildcard value '*' 
> for the online whitelist section allows one to 'whitelist all' 
> regardless of scheme. However, the spec requires a URL in the online 
> whitelist section to have the same scheme as the manifest URL.  Seems 
> like the new wildcard feature has created a mismatch in whether the 
> scheme should be restricted.
> 
> Should the scheme restriction be consistent regardless of wildcard value 
> vs explicitly listed URL?

I've changed the model to so that any resourcs that aren't in the same 
scheme are automatically in the online whitelist, whether "*" is specified 
or not.

I think the scheme restrictions were always intended to work this way 
(i.e. always intended as a way to make it impossible to cache mailto: 
URIs, and things like that, and always intended to not block cross-scheme 
networking), but it seems it was only half-baked before.

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

Re: [whatwg] Remove addCueRange/removeCueRanges

[Silvia Pfeiffer]

On Fri, Aug 14, 2009 at 3:31 AM, David Singer wrote:
> At 10:31  +0200 13/08/09, Philip Jägenstedt wrote:
>>
>> Hi,
>>
>> We would like to request that addCueRange/removeCueRanges be dropped from
>> the spec before going into Last Call. We are not satisfied with it and want
>> to see it replaced with a solution that includes (scriptless) timed text
>> (a.k.a captions/subtitles). I don't think that this will be finished in time
>> for Last Call however, because we need implementor experience to write a
>> good spec. However, we have no intention of implementing both cue ranges and
>> its replacement, so it is better if the spec doesn't provide any solution
>> for now.
>>
>> I have been briefly in contact with other browser vendors and while I
>> cannot speak for them here, I hope those that agree will chime in if
>> necessary.
>
> We reluctantly agree.  We suggested a re-think a year ago, and though that
> got some support, it didn't get the editor's support.  We do not have an
> implementation of the current spec., and don't expect to.
>
> 
>
> We do think the functionality is important, and are saddened to agree with
> this proposal, however.

I am actually hoping that we could attach callbacks to time-aligned
text segments which makes the whole approach to cue ranges more
generic. Hopefully I will have a demo of this within the next few
weeks, so we can discuss further.

Regards,
Silvia.

Re: [whatwg] Editorial section 4.8.7

[Ian Hickson]

On Wed, 5 Aug 2009, Elliotte Rusty Harold wrote:
>
> "so that legacy video plugins can be tried, or to show text to the users 
> of these older browser informing them of how to access the video 
> contents."
> 
> these older browser --> these older browsers

Fixed, thanks.

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

Re: [whatwg] Spec comments, sections 1-2

[Ian Hickson]

On Wed, 5 Aug 2009, Anne van Kesteren wrote:
> On Wed, 05 Aug 2009 02:01:59 +0200, Ian Hickson  wrote:
> > I'm pretty sure that character encoding support in browsers is more of 
> > a "collect them all" kind of thing than really based on content that 
> > requires it, to be honest.
> 
> Really? I think a lot of them are actually used.

I'm pretty sure not all of them are common.


> If you know anything I'd love to trim the amount of encodings the Web 
> needs to a smaller list than what we currently ship with. Ideally this 
> becomes a fixed list across all Web languages.

That would be nice.


> > If someone can provide a firm list of encodings that they are 
> > confident are required for a certain substantial percentage of the 
> > Web, I'm happy to add the list to the spec.
> 
> Can you not do a survey on your large dataset of data to find this out? 
> I read somewhere also that Adam Barth was able to add code to Google 
> Chrome to figure out a better algorithm for Content-Type sniffing. Maybe 
> something similar could be done here?

For various reasons, my usual techniques for obtaining data aren't 
suitable for encoding-related work. Could MAMA or Opera be instrumented 
instead?


> We've encountered problems by the way with using the Unicode encoding 
> matching algorithm. Particularly on some Asian sites. I think we need to 
> switch HTML5 back to something more akin to WebKit/Gecko/Trident. I 
> realize this means more magic lists, but the current algorithm does not 
> seem to cut it. E.g. sites rely on the fact that EUC_JP is not a 
> recognized encoding but EUC-JP is.

If you let me know what the algorithm should be, I can do that. Is it just 
underscores that must not be ignored? Maybe we can just do a delta spec on 
the Unicode algorithm? (i.e. say "do what Unicode says except...").

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

Re: [whatwg] HTML5 History Management

[Ian Hickson]

On Wed, 5 Aug 2009, Nathan Hammond wrote:
> 
> With regards to pushState not triggering a hashchange event, I like it, 
> but I do want to be absolutely sure that all implementers get this 
> right. So, could we clarify this in the spec? Right now I think that the 
> spec could be read where since it adjusts the document's current address 
> it might should cause a hashchange event. Providing this specific 
> example would do the trick.

Done.


> Related, is window.location.hash = "newhash"; supposed to trigger a hashchange
> event? (Is this specified? I couldn't find it.) I do believe it does in IE8,
> but I don't have IE8 available to me at this moment to check.

Yes, and yes, it is specified. It triggers a navigation, which eventually 
gets around to the part that fires hashchange.


> > > 2. Specify a method to allow access to the history stack. (At least 
> > > readable within the context of same-origin, possibly mutable.)
> > > 
> > > This would allow for understanding on the client side of a user's 
> > > path through the site, even after navigating away from the page. If 
> > > this is not implemented the absolute first thing I will be 
> > > implementing is a method to track this information, a rather large 
> > > duplication of effort for something that could easily be made 
> > > available. This would involve a something like currentstate = { 
> > > _previous: currentstate, title: window.title, newval: true }; plus a 
> > > form-based storage mechanism to repopulate state in case the user 
> > > exits on a page which they manually changed the hash to get to 
> > > (which would not have access to the data object upon revisiting 
> > > later since there wouldn't be one stored with that history state).
> > > 
> > > I'm aware of the privacy ramifications, but at the same time, I'm 
> > > going to be exposing those exact same concerns with the above 
> > > method.
> > 
> > It turns out to be quite complex to expose this in the API currently, 
> > because the History object exposes a mix of all the various frames at 
> > once, and you can get to the History object of cross-origin frames, 
> > and there's some other legacy baggage here also (e.g. history.length).
> > 
> > Since it's not entirely clear what the use case is, and since you can 
> > do it to some extent already using onload, onhashchange, and 
> > onpopstate, I'd rather just let authors reimplement this themselves at 
> > this point, and maybe revisit this in a future version.
> 
> Complexity. Bah! (Then again, you don't have to tell me.) The use case I 
> find is pretty simple: in the event that there are two separate ways to 
> get to a specific page in the app I need to know how the person got 
> there. Or this could be used to provide content tailored specifically to 
> that user based upon their history (whether suggestions, ads, or help 
> text). Really though, this point is far less critical (as it is easy 
> enough to handle in client code) and does greatly increase the 
> complexity for getting all implementers on board. If this *isn't* 
> implemented however, the point below becomes more critical for being 
> able to successfully track state in client code...

I don't really understand the scenario under which those use cases would 
be relevant. Can you show an example of someone doing something like this 
now?


> > > 3. Specify a method to modify the current history state without adding a
> > > new history point.
> > 
> > Assuming you don't mind causing the page to reload, you can use
> > history.replace(). I'm not sure what it would mean to replace the history
> > state without changing the Document or anything, though.
> > 
> > > This would alleviate the need for the (incredibly brittle) form-based
> > > storage mechanism I describe above.
> > 
> > Can you use sessionStorage for this?
> 
> I should have stated this one with a goal: the ability to ensure that 
> the popstate event always fires with a full understanding of the 
> (app/page) state when navigating through history. This would be lost 
> when a user manually changes the hash. With that as my goal, 
> history.replace does not achieve what I am trying to accomplish. Neither 
> does pushState without a URL as that still registers a new history 
> point.

All the information about the state really should be in the URL, such that 
the state of the app after the user manually changes the hash, and the 
state of the app after the user returns to a point in the history where he 
had manually changed the hash, really should be the same. I don't think we 
should encourage cases where the same URL can correspond to multiple 
states, which this would encourage.


> > > 4. Specify additional properties on the hashchange event.
> > > 
> > > Lots of possible useful information with the number one most 
> > > important being the new hash that triggered the event to prevent 
> > > race conditions reading window.location.hash. Other fun things that 
> > > are a bit more pie in the 

Re: [whatwg] Spec comments, sections 3.1-4.7

[Aryeh Gregor]

On Thu, Aug 13, 2009 at 5:00 PM, Aryeh Gregor wrote:
> Yes, I guess I got sort of sidetracked.  I assume the idea is that it
> will be styleable eventually, but I don't see how it would work with
> existing CSS properties, so I'd assume it would take significant
> implementation effort and not happen very soon.  I don't think it will
> be used very widely or usefully until it becomes styleable.
>
> Beyond that, the use-cases just seem very narrow compared to other
> elements invented in HTML 5.  The number of progress bars needed on
> the web is pretty modest, and the gains from marking them up
> semantically don't seem to be large.  For some particular types of
> progress bars,  gives better accessibility than any
> straightforward existing possibility I can think of, but a) authors
> concerned about accessibility could usually add some kind of text
> without any trouble, and b) the progress of some activity is rarely
> critical information in web apps, so if you're missing it you usually
> won't be missing much anyway.

It sort of looks like I'm harping on this, doesn't it?  I don't really
care, actually, FWIW.  I'm an author, not an implementer, so extra
features aren't a burden to me.  I just thought it was incongruous
when reading the spec.  If other people think / would
be useful enough to justify implementation, then no problem.  I
personally don't see the need to debate it further.

Re: [whatwg] Spec comments, sections 3.1-4.7

[Tab Atkins Jr.]

On Thu, Aug 13, 2009 at 4:00 PM, Aryeh Gregor wrote:
> On Thu, Aug 13, 2009 at 2:11 PM, Anne van Kesteren wrote:
>> You seem to base most of your argument on that  will not be 
>> stylable. I think the idea is that it will be stylable though.
>
> Yes, I guess I got sort of sidetracked.  I assume the idea is that it
> will be styleable eventually, but I don't see how it would work with
> existing CSS properties, so I'd assume it would take significant
> implementation effort and not happen very soon.  I don't think it will
> be used very widely or usefully until it becomes styleable.
>
> Beyond that, the use-cases just seem very narrow compared to other
> elements invented in HTML 5.  The number of progress bars needed on
> the web is pretty modest, and the gains from marking them up
> semantically don't seem to be large.  For some particular types of
> progress bars,  gives better accessibility than any
> straightforward existing possibility I can think of, but a) authors
> concerned about accessibility could usually add some kind of text
> without any trouble, and b) the progress of some activity is rarely
> critical information in web apps, so if you're missing it you usually
> won't be missing much anyway.

Well, it's a default widget in jQuery UI.  I think that makes a good
case for it being common enough that it'll see use.

(For reference, the other default widgets are a datepicker and slider,
which are new  types, a styleable dialog box, and then
accordion and tab displays (which were hit by some proposals between
Brad Kemper and I on the CSS list a while back).)

~TJ

Re: [whatwg] Spec comments, sections 3.1-4.7

[Aryeh Gregor]

On Thu, Aug 13, 2009 at 2:11 PM, Anne van Kesteren wrote:
> You seem to base most of your argument on that  will not be 
> stylable. I think the idea is that it will be stylable though.

Yes, I guess I got sort of sidetracked.  I assume the idea is that it
will be styleable eventually, but I don't see how it would work with
existing CSS properties, so I'd assume it would take significant
implementation effort and not happen very soon.  I don't think it will
be used very widely or usefully until it becomes styleable.

Beyond that, the use-cases just seem very narrow compared to other
elements invented in HTML 5.  The number of progress bars needed on
the web is pretty modest, and the gains from marking them up
semantically don't seem to be large.  For some particular types of
progress bars,  gives better accessibility than any
straightforward existing possibility I can think of, but a) authors
concerned about accessibility could usually add some kind of text
without any trouble, and b) the progress of some activity is rarely
critical information in web apps, so if you're missing it you usually
won't be missing much anyway.

Re: [whatwg] Installed Apps

[Drew Wilson]

On Thu, Aug 13, 2009 at 5:13 AM, Mike Wilson  wrote:

>
> Maybe I'm mistaken, but I think Drew wanted handling of
> "live" objects, where each window gets access to the same
> concrete objects (possibly protected by private proxy
> objects) so the graph can be walked without cloning.


To be honest, I'm not really a good spokesperson for this issue, as most of
my thinking has been around shared workers which have all the same drawbacks
for data sharing that WebStorage has.

I was just saying that I understand the problem that the shared context is
trying to address. I personally think that part of the problem can be
overcome using the existing tools, although with more effort on the app side
than a simple shared context solution.


>
> Drew: are you thinking that the same object graph also
> makes up the data cache between sessions? If not, then
> persistence is not a must-have for this use case so the
> area of ideas could well expand outside webstorage.


I think ideally serialization would happen only when data needs to be
persisted. If I have a data structure that I want to share with other open
windows, I shouldn't have to persist it to accomplish this, and I certainly
shouldn't have to re-serialize it every time I want to make a minor change.

But, again, I'm just speaking in the abstract - the folks proposing shared
context (Dmitry) should probably chime in here as they've thought about this
problem much more than I have.

-atw

Re: [whatwg] Installed Apps

[Drew Wilson]

On Thu, Aug 13, 2009 at 4:07 AM, Ian Hickson  wrote:

>
> > Sure, although I'd say that "persistent storage is addressed by the Web
> > Storage and Web Database features". Shared state is also addressed, but
> > that's not the primary goal. If I have a tree of objects that I'd like
> > to share between two pages, telling me to serialize it into name/value
> > string pairs, write it into Web Storage, and then have the remote side
> > read it out is not a satisfying (or performant) solution.
>
> Web Storage supports structured data now.
>

Yeah, the fact that the UA will automatically jsonify my (cycle-free) data
structures does not really make this a great solution, for many of the
reasons Mike Wilson mentioned. That said, once you've architected your
application around having only asynchronous access to your data structures,
there are lots of tools available in HTML5 to do sharing (use WebStorage as
you describe, push all data access through a SharedWorker, keep duplicate
copies of data structures in each page and update them via DB or
SharedWorker messages, etc).


> A system that displays rich/scripted content on server demand rather than
> on user demand is a massive security nightmare. It turns a scripting
> security bug and an XSS bug into an instant malware deployment vector.


Another name for "a system that displays rich/scripted content on server
demand" is "an open web page" :) The only difference is the user has UI to
close a web page when he's done interacting with it, while the UI to
enable/disable notifications from a domain is probably less obvious.

Scriptable notifications are a use case that none of these proposals
currently satisfy. I understand the security concerns. I just don't (yet :)
share the general belief that they are insurmountable which is why I want to
continue experimenting in this area.



>
> > Additionally, any server-side-feed-based solution has the implication
> > that it won't work for offline apps. If I am using a web calendar, I
> > want my event notifications regardless of whether I'm online or offline
> > (the event may have been added while I'm offline and never synced to the
> > server at all).
>
> I think on the long term we may wish to consider adding a feature to queue
> up POSTs for when the UA finds it is back online. That would address a
> number of problems, including this one.
>

I'll just note that to get a narrow subset of the behavior that simple
background scripting would provide (static notifications and static data
synchronization without client-side reconciliation), we're having to have:

1) A server-controlled push notification stream, as well as infrastructure
for applications to insert/remove notifications into the stream for offline
use.
2) Some kind of server database push-sync protocol.
3) Some kind of "queued up posts" feature (with assumedly yet more
infrastructure to deal with errors/return values from these delayed POSTs).

What you really want for #2/#3 is a general-purpose sync protocol, but I
don't see how you do it without some form of client-side conflict
resolution.

I hope that people understand why application scripting seems like a more
attractive, general-purpose solution. I'm unable to muster much enthusiasm
for a set of convoluted server-and-client-side mechanisms that cover such a
narrow set of use cases without any way for client applications to customize
this behavior through scripting.


> I really don't feel right allowing script to run like that.
>
> Why can't the server send the data to the client in a near-final form and
> let the script figure it out when the user finally opens the app?
>

What if there are things the application wants to do to act upon this data
immediately (add items to the notification stream, for example)? What you're
saying is we need to push all of this functionality up to the server, then
provide a very narrow set of APIs (essentially, static notifications) that
the server can use to act on that functionality.


>
> What other use cases are there? Those were the ones given. We're very much
> use-case-driven here.
>

I won't claim to understand all of the potential use cases yet, but I have a
preference for general-purpose solutions rather than solutions that narrowly
target a set of specific use cases, although I recognize that more
general-purpose solutions have commensurate security implications.

I'd like to just experiment with background scripting/scriptable
notifications in a way that people find acceptable (either without
persistence, or using extensions for persistence), see how applications
actually use them, then continue this conversation. People are certainly
welcome to do parallel experimentation with other approaches such as the
ones you've outlined above.


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

Re: [whatwg] Spec comments, sections 3.1-4.7

[Anne van Kesteren]

On Thu, 13 Aug 2009 19:34:47 +0200, Aryeh Gregor  
wrote:
> I'd think that the author in this use-case is not likely to be happy using
> an unstyle-able  element and getting some kind of unknown
> appearance that might clash with their color scheme or such.

You seem to base most of your argument on that  will not be stylable. 
I think the idea is that it will be stylable though.


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

Re: [whatwg] Installed Apps

[Jeremy Orlow]

On Thu, Aug 13, 2009 at 4:07 AM, Ian Hickson  wrote:

>
> > Additionally, any server-side-feed-based solution has the implication
> > that it won't work for offline apps. If I am using a web calendar, I
> > want my event notifications regardless of whether I'm online or offline
> > (the event may have been added while I'm offline and never synced to the
> > server at all).
>
> I think on the long term we may wish to consider adding a feature to queue
> up POSTs for when the UA finds it is back online. That would address a
> number of problems, including this one.


It seems like conflict resolution will be more difficult when it can only
happen at the server side.  In addition, it seems like there'd be more
efficient means of syncing rather than many small messages.  We don't have
to talk about this now since there isn't even a proposal yet, but I'm
doubtful this will be a good solution to the problem.

> On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson  wrote:
>  > >
> > > I'm not sure XMPP is the protocol I would jump to, but it's certainly
> > > an option, yes.
> >
> > What don't you like about XMPP?
>
> It's far too complex for people to write and deploy an XMPP server on a
> whim. Like HTTP, it requires people to use off-the-shelf software instead
> of allowing them to experiment with their own code. This leads to software
> monocultures, and prevents easy experimentation.


I guess we'll see how the WebSocket protocol works out.  I definitely see
both pros and cons to this approach.

Re: [whatwg] Spec comments, sections 3.1-4.7

[Aryeh Gregor]

On Thu, Aug 13, 2009 at 9:24 AM, Tab Atkins Jr. wrote:
> I suspect, though, that there are a lot of places you currently don't
> see a progress bar solely because it's a bit of a pain to do.  Any
> place where progress is being made and displayed is a potential
> candidate.  In one of the many intranet applications I write and
> maintain for my company, I'm using  right now to indicate
> how far someone is in providing translations for our program.  I'm
> waiting for browsers to catch up and actually display the element, but
> in the meantime the fallback content is fine.

I guess I don't understand why  is more useful than just
displaying the fallback content to begin with.  Text like "74% done"
doesn't really need , does it?  There should be no
accessibility problem with that, at least that I can see.  Likewise,
if your progress indicator is made up of one or more s, then you
should be able to use alt text with no accessibility problems.

The only case I can see where progress bars would be an accessibility
problem is if there's a graphical progress bar that doesn't use .
 For instance, something like this to indicate 63% progress:





This should give you a nice blue bar on a white background that fills
up 63% of the width, showing the user how much progress has occurred
without forcing the client to download an image.  (Assuming I didn't
mess up my CSS.)  In this case, a user who can't perceive the width or
color for some reason would get no information, and there's no easy
way for the author to provide alternative content.  This is the only
use-case I can think of where  would increase accessibility.
 Are there others?

But the case only occurs when the author is concerned enough with
appearances to go out of their way to make a pretty progress bar.  If
they didn't really mind how it rendered on the client, they'd probably
be okay with just using text to avoid accessibility problems.  I'd
think that the author in this use-case is not likely to be happy using
an unstyle-able  element and getting some kind of unknown
appearance that might clash with their color scheme or such.

Is it even anticipated that authors will be able to control the *size*
of  using CSS width or height properties?  Even if that
worked as expected, it would probably interfere with display of
fallback content, so it would be hard to use in practice (you'd need
to serve the CSS only if the UA supports ).  If you can't
even control the size, you'd really have no idea whether it would
stand a chance of working with your layout.  It might cause content to
overflow unpredictably, it couldn't be used in any context where you
need precise positioning, etc.

Are there use-cases for  that I'm missing?  (E.g., are
textual progress indicators not accessible for some reason?)  And am I
being too pessimistic about how important style is for what use-cases
there are?

> Eh, it's not all that bad.  I'll be happy when I get XBL2, but until
> then I'm fine with platform-native displays.

You're also apparently okay with just having a textual progress
display, so what advantage does  give you?  Do you feel you
have reason to believe that if UAs implement it, it will look better
than the text, even though it might clash with your color scheme or be
a strange size?

> People hack around it
> any case, by providing js libraries that transform your good markup
> into more easily styleable markup (while maintaining accessibility).

That sounds like a maintainability nightmare.  I'm also not sure how
you're supposed to maintain accessibility.  If you transform
 into a  using JS, then screen readers that run
JavaScript won't ever see the , and all benefit will be
lost.  And I assume screen readers need to run JS by default just as
much as normal browsers.

On Thu, Aug 13, 2009 at 10:20 AM, Smylers wrote:
> Many shopping sites have indicators of how far you are through the
> buying process ("Step 2 of 4"), and online surveys often have progress
> bars indicating the position in the survey.
>
> Typically these are static to the page (as in, making progress and
> seeing the indicator move involves submitting a form and displaying the
> next page in the sequence), but so far as I can see from the spec
>  can be used in these situations; it isn't restricted to use
> on a single page where it is updated dynamically.

Yes, those are good points.  Including those does mean there are quite
a few progress bars on the web.  Still, the approach of HTML 5 is that
new features should have concrete use-cases, rather than adding
semantics for the sake of semantics with no specific purpose.  I don't
see how the use-cases given for  are enough to justify its
existence.

Re: [whatwg] Remove addCueRange/removeCueRanges

[David Singer]

At 10:31  +0200 13/08/09, Philip Jägenstedt wrote:

Hi,

We would like to request that 
addCueRange/removeCueRanges be dropped from the 
spec before going into Last Call. We are not 
satisfied with it and want to see it replaced 
with a solution that includes (scriptless) timed 
text (a.k.a captions/subtitles). I don't think 
that this will be finished in time for Last Call 
however, because we need implementor experience 
to write a good spec. However, we have no 
intention of implementing both cue ranges and 
its replacement, so it is better if the spec 
doesn't provide any solution for now.


I have been briefly in contact with other 
browser vendors and while I cannot speak for 
them here, I hope those that agree will chime in 
if necessary.


We reluctantly agree.  We suggested a re-think a 
year ago, and though that got some support, it 
didn't get the editor's support.  We do not have 
an implementation of the current spec., and don't 
expect to.




We do think the functionality is important, and 
are saddened to agree with this proposal, however.

--
David Singer
Multimedia Standards, Apple Inc.

[whatwg] size limits on web databases

[Rob Kroeger]

>From http://dev.w3.org/html5/webdatabase/:

"The openDatabase() method on the Window and WorkerUtils interfaces
must return a newly constructed Database object that represents the
database requested."

The spec does not make it clear what the UA on an extremely
resource-constrained device (e.g. a mobile phone) should do if the
requested size database size cannot be satisfied. Some implementations
return a null Database object if something has gone wrong in the
openDatabase() call but (at least to me) the spec does not seem to
permit this and simply returning null does not particularly help an
application adapt gracefully to the availability of only a small
database.

Consequently, I would hope that this could be improved in some
fashion. Three possible modifications to the spec occur to me. From
the viewpoint of webdatabase developer, I prefer (1), could work with
(2) and would greatly dislike (3). Is this reasonable?

1. Retain the existing def'n of openDatabase but add a property on
interface Database:
  unsigned long minimumCapacity;
which returns the amount of storage that the UA guarantees to be
present in the database at the time of opening. The UA should try to
set minimumCapacity so that QUOTA_ERR will be extremely unlikely if
the database client code never writes more than minimumCapacity bytes
to the database.

2. A language change:

"The user agent may raise a SECURITY_ERR exception instead of
returning a Database object if the request violates a policy decision
(e.g. if the user agent is configured to not allow the page to open
databases)."

to something like this:

"The user agent must raise a SECURITY_ERR exception instead of
returning a Database object if the request violates a policy decision
(e.g. if the user agent is configured to not allow the page to open
databases) or the estimatedSize of the database cannot currently be
satisfied (e.g. the UA is running from a read-only volume or the
estimatedSize exceeds the free space on the volume.)"

3. An alternative language change:

"The openDatabase() method on the Window and WorkerUtils interfaces
must return a newly constructed Database object that represents the
database requested."

to

"The openDatabase() method on the Window and WorkerUtils interfaces
must return a newly constructed Database object that represents the
database requested or null if openDatabase call has failed."


Rob.

-- 
Rob Kroeger
rjkro...@liqui.org
http://www.liqui.org

Re: [whatwg] the cite element

[Smylers]

Erik Vorhes writes:

> On Thu, Aug 13, 2009 at 4:59 AM, Smylers wrote:
> 
> > For words that you wish to have no distinct presentation from the
> > surrounding text -- words that readers don't need calling out to
> > them as being in any way 'special' -- simply don't mark them up.
> 
> Interesting point. Should the HTML5 specification explicitly admonish
> against using microformats, microdata, RDFa, and the like?

Possibly I stated the above too strongly.

In general invisible metadata doesn't have a great history; the most
successful systems involving machine-parsed web pages seem to involve
machines parsing the human visible parts of pages rather than things
like .

But I didn't actually mean to go so far as to say these should never be
used.  If somebody can do something useful with names marked up as
metadata then that's a reason for marking it up in some way.  But HTML 5
doesn't need a specific element for that; there's the generic microdata
syntax.

If marking up people's names when citing them becomes really common then
a future version of the spec could mint an element for that (like
happened with , a common metadata pattern).

But there still wouldn't be a call for an element which sometimes
indicates its contents should be displayed to the reader in a way which
indicates they are the title of a work and sometimes indicates its a
person's name.

Smylers

Re: [whatwg] Issues with Web Sockets API

[Alexey Proskuryakov]

13.08.2009, в 4:42, Ian Hickson написал(а):


A note explaining that the close event will be dispatched at server's
discretion (or on subsequent connection timeout), potentially long  
time

after close() is called, would likely make the intention clearer.


It won't be long after the close().



Why not? My understanding is that it can take arbitrary amount of time  
- the server can choose not to close its side of connection for years,  
and to send data over it.


- WBR, Alexey Proskuryakov

Re: [whatwg] Spec comments, sections 3.1-4.7

[Smylers]

Tab Atkins Jr. writes:

> On Wed, Aug 12, 2009 at 7:43 PM, Aryeh
> Gregor wrote:
> 
> > I haven't noticed many progress bars on the web
> 
> You see them a lot more in the indeterminate form, as a 'spinner'
> image or the like. ...  I suspect, though, that there are a lot of
> places you currently don't see a progress bar solely because it's a
> bit of a pain to do.

Many shopping sites have indicators of how far you are through the
buying process ("Step 2 of 4"), and online surveys often have progress
bars indicating the position in the survey.

Typically these are static to the page (as in, making progress and
seeing the indicator move involves submitting a form and displaying the
next page in the sequence), but so far as I can see from the spec
 can be used in these situations; it isn't restricted to use
on a single page where it is updated dynamically.

Smylers

Re: [whatwg] the cite element

[Smylers]

Erik Vorhes writes:

> On Thu, Aug 13, 2009 at 4:59 AM, Smylers wrote:
> 
> > As Ian has pointed out, the above is technically non-conforming with
> > what the HTML 4 spec claims.  But it's how I've been using  for
> > years, since it makes sense and has a use.
> 
> I defy you to show me in the HTML 4.01 specification where something
> like the following is nonconforming:

By "the above" I was refering to my previous paragraphs -- in which I'd
just described my use of .  I am admitting that _my_ definition
isn't permitted by HTML 4.

I am _not_ claiming that your definition isn't allowed in HTML 4; I'm
claiming that the HTML 4 definition, including things like marking up
names, isn't particularly useful.

For this example:

> I like to read nonfiction, such as John Adams, but I
> had more time for that when I was a professional academic.

How do you want that to be rendered?  The conventional presentation
would be for "John Adams" simply to be rendered in exactly the same way
as the surrounding text, with the reader being given no information at
all that those words are in some way special.

Smylers

Re: [whatwg] the cite element

[Erik Vorhes]

On Thu, Aug 13, 2009 at 4:59 AM, Smylers wrote:
>
> For words that you wish to have no distinct presentation from the
> surrounding text -- words that readers don't need calling out to them as
> being in any way 'special' -- simply don't mark them up.
>

Interesting point. Should the HTML5 specification explicitly admonish
against using microformats, microdata, RDFa, and the like?

Re: [whatwg] the cite element

[Erik Vorhes]

On Wed, Aug 12, 2009 at 6:21 PM, Ian Hickson wrote:
>
> Currently,  in HTML5 isn't for collecting anything, it's purely to
> provide a hook for styling.

Please explain how , if it is only a hook for styling titles of
works, is any different from  in the HTML5 specification, since an
italicized title of a work qualifies as "prose whose typical
typographic presentation is italicized."

Erik

Re: [whatwg] the cite element

[Erik Vorhes]

On Thu, Aug 13, 2009 at 8:50 AM, Remco wrote:
>> I defy you to show me in the HTML 4.01 specification where something
>> like the following is nonconforming:
>>
>> I like to read nonfiction, such as John Adams, but I
>> had more time for that when I was a professional academic.
>>
>
> I don't think John Adams is a name of a person in this context. It is
> a group of works.
>

Sorry, I shouldn't have been so obscure. I was referring to _John
Adams_, by David McCullough, not John Adams the person or the
collected works of John Adams.

The point I'm trying to make by referencing the above HTML fragment is
that using  to surround the title of a work is perfectly
acceptable in HTML 4.01, which Ian claims not to be the case.

Erik

Re: [whatwg] the cite element

[Remco]

On Thu, Aug 13, 2009 at 2:26 PM, Erik Vorhes wrote:
> On Thu, Aug 13, 2009 at 4:59 AM, Smylers wrote:
>>
>> As Ian has pointed out, the above is technically non-conforming with
>> what the HTML 4 spec claims.  But it's how I've been using  for
>> years, since it makes sense and has a use.
>
>
> I defy you to show me in the HTML 4.01 specification where something
> like the following is nonconforming:
>
> I like to read nonfiction, such as John Adams, but I
> had more time for that when I was a professional academic.
>
> Erik
>

I don't think John Adams is a name of a person in this context. It is
a group of works.

Remco

Re: [whatwg] Spec comments, sections 3.1-4.7

[Tab Atkins Jr.]

On Wed, Aug 12, 2009 at 7:43 PM, Aryeh Gregor wrote:
>> The point of  is to add progress bars. Right now people hack
>> them in highly non-accessible ways using images and all kinds of crazy
>> things. This lets them avoid that while also getting a platform-native
>> look and feel.
>>
>> The point of  is to make sure people don't abuse  for
>> showing meters.
>
> I see.  I guess if you're using a screen reader or have images
> disabled, loading bars in some web apps would be completely absent.  I
> haven't noticed many progress bars on the web, but I guess if I used
> web apps other than Gmail more then maybe I'd see the need for this
> better.

You see them a lot more in the indeterminate form, as a 'spinner'
image or the like.  Of course, in that form an intelligent person can
just slap a "Loading..." @alt on the image.

I suspect, though, that there are a lot of places you currently don't
see a progress bar solely because it's a bit of a pain to do.  Any
place where progress is being made and displayed is a potential
candidate.  In one of the many intranet applications I write and
maintain for my company, I'm using  right now to indicate
how far someone is in providing translations for our program.  I'm
waiting for browsers to catch up and actually display the element, but
in the meantime the fallback content is fine.

>> Yeah, styling of complex widgets like progress bars and other widgets is
>> somewhat dependent on us deploying a technology like XBL2. This is
>> something that we need to resolve in general. Once we have more
>> implementation experience, I expect we'll add some pseudo-elements and
>> define how the CSS model applies.
>
> Hmm, okay.  I don't think pretty much anyone will be using these
> elements until something like this is in place, though.  And possibly
> not after that if it's not easy enough to use.

Eh, it's not all that bad.  I'll be happy when I get XBL2, but until
then I'm fine with platform-native displays.  People hack around it
any case, by providing js libraries that transform your good markup
into more easily styleable markup (while maintaining accessibility).

> (I notice Gmail doesn't appear to even use form buttons.  Inspecting
> the Send button on this page shows a stack of several nested divs with
> various obscure classes and styles applied.  And, indeed, it seems
> like that's so they could change the appearance.)

That's because of GWT, actually, Google's homebrew Java library that
allows them to produce web content in Java.  I'm guessing it goes with
that approach because, even though it's basically impossible for a
human to understand, it's easier to machine-create with a stable
cross-platform appearance.

~TJ

Re: [whatwg] Remove addCueRange/removeCueRanges

[Philip Jägenstedt]

On Thu, 13 Aug 2009 14:34:55 +0200, Dr. Markus Walther   
wrote:



Hi,

please note that with cue ranges removed, the last HTML 5 method to
perform audio subinterval selection is gone.

AFAIK, when dropping support for 'start' and 'end' attributes it was
noted on this list that cue ranges would provide a replacement to
dynamically select, say, a 3-second range from a 1-hour audio source.

So, if cue ranges will indeed be dropped, could browser vendors and
standards people consider putting 'start' and 'end' back in, just like
Safari had it for a while (albeit buggy)?


The .start/.end properties were dropped in favor of media fragments, which  
the Media Fragments Working Group is producing a spec for. It will be  
something like http://www.example.com/movie.mov#t=12.33,21.16


See http://www.w3.org/2008/01/media-fragments-wg.html and  
http://www.w3.org/2008/WebVideo/Fragments/wiki/Syntax#Examples



Actually, out of curiousity: could gapless concatenation of several
audio objects be added as well, e.g.

audioObject1.append(audioObject2)

or even

audioObject.join([audioObject1,audioObject2,...,audioObjectN)


There has been much discussion about audio "canvas" API:s and I trust this  
could fit into that scope. View source at  
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video  
and search for "v2" and you'll find some of these ideas.


--
Philip Jägenstedt
Opera Software

Re: [whatwg] Remove addCueRange/removeCueRanges

[Dr. Markus Walther]

Hi,

please note that with cue ranges removed, the last HTML 5 method to
perform audio subinterval selection is gone.

AFAIK, when dropping support for 'start' and 'end' attributes it was
noted on this list that cue ranges would provide a replacement to
dynamically select, say, a 3-second range from a 1-hour audio source.

So, if cue ranges will indeed be dropped, could browser vendors and
standards people consider putting 'start' and 'end' back in, just like
Safari had it for a while (albeit buggy)?

Actually, out of curiousity: could gapless concatenation of several
audio objects be added as well, e.g.

audioObject1.append(audioObject2)

or even

audioObject.join([audioObject1,audioObject2,...,audioObjectN)

Just my 2c.

--Markus

Philip Jägenstedt wrote:
> Hi,
> 
> We would like to request that addCueRange/removeCueRanges be dropped
> from the spec before going into Last Call. We are not satisfied with it
> and want to see it replaced with a solution that includes (scriptless)
> timed text (a.k.a captions/subtitles). I don't think that this will be
> finished in time for Last Call however, because we need implementor
> experience to write a good spec. However, we have no intention of
> implementing both cue ranges and its replacement, so it is better if the
> spec doesn't provide any solution for now.
> 
> I have been briefly in contact with other browser vendors and while I
> cannot speak for them here, I hope those that agree will chime in if
> necessary.
> 

Re: [whatwg] the cite element

[Erik Vorhes]

On Thu, Aug 13, 2009 at 4:59 AM, Smylers wrote:
>
> As Ian has pointed out, the above is technically non-conforming with
> what the HTML 4 spec claims.  But it's how I've been using  for
> years, since it makes sense and has a use.


I defy you to show me in the HTML 4.01 specification where something
like the following is nonconforming:

I like to read nonfiction, such as John Adams, but I
had more time for that when I was a professional academic.

Erik

Re: [whatwg] Installed Apps

[Mike Wilson]

Ian Hickson wrote:
> 
> On Tue, 4 Aug 2009, Drew Wilson wrote:
> > Sure, although I'd say that "persistent storage is 
> > addressed by the Web Storage and Web Database 
> > features". Shared state is also addressed, but that's 
> > not the primary goal. If I have a tree of objects 
> > that I'd like to share between two pages, telling me 
> > to serialize it into name/value string pairs, write 
> > it into Web Storage, and then have the remote side 
> > read it out is not a satisfying (or performant) 
> > solution.
> 
> Web Storage supports structured data now.

I'm assuming that you refer to the concept of "structured
clone" now added to http://dev.w3.org/html5/webstorage/.

This certainly makes life easier for certain scenarios,
but I don't think it fully addresses Drew's use case.
The problem is that to change the tiniest thing in the
object graph, you will have to get a complete copy of
the data out from the storage provider, apply the change,
and then let it be copied (cloned) back into storage
again.
With Drew's large mailbox + categories example I think
this will be too inefficient. Also, it cannot be divided
into chunks stored under individual keys as that breaks 
object pointers.

Maybe I'm mistaken, but I think Drew wanted handling of
"live" objects, where each window gets access to the same
concrete objects (possibly protected by private proxy
objects) so the graph can be walked without cloning.

Drew: are you thinking that the same object graph also
makes up the data cache between sessions? If not, then
persistence is not a must-have for this use case so the 
area of ideas could well expand outside webstorage.

(Minor note: the Introduction still says that structured
data needs to be handled manually: "To store structured 
data in a storage area, you must first convert it to a 
string.")

Best regards
Mike Wilson

Re: [whatwg] Issues with Web Sockets API

[Ian Hickson]

On Tue, 4 Aug 2009, Alexey Proskuryakov wrote:
> 04.08.2009, в 16:47, Ian Hickson написал(а):
> > 
> > The text "Closing the connection causes a close event to be fired and 
> > the readyState attribute's value to change, as described below" is not 
> > normative (it has no "must"s in it). It's just letting you know that 
> > subsequent requirements as described lower in the spec do result in 
> > that.
> > 
> > Is there some way I can make that clearer?
> 
> A note explaining that the close event will be dispatched at server's 
> discretion (or on subsequent connection timeout), potentially long time 
> after close() is called, would likely make the intention clearer.

It won't be long after the close(). If the UA closes the connection, then 
the conditions under which "the Web Socket connection is closed" occurs 
will quickly come to be.

I've tried to make this a little clearer.

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

Re: [whatwg] "Fullscreenable" and "Mouselockable" attributes

[Ian Hickson]

On Tue, 4 Aug 2009, Henry Bridge wrote:
>
> With the video tag and web games gaining traction, it seems like there 
> should be a way for apps to provide fullscreen and better control 
> schemes to users.  Of course, spoofing and clickjacking are major 
> concerns, but I liked Alpha Omega's suggestion a few weeks ago [1] to 
> specify a "fullscreenable" attribute to certain elements that hint to 
> the UA that the object would be appropriate to consider for fullscreen.  
> Similarly, for content that uses relative mouse motion or requires great 
> precision (like a first-person view), it would be useful to have a 
> "mouselockable" attribute; upon a UA defined interaction, the mouse 
> would be locked within the particular element and report relative mouse 
> events until the user disengages the lock.
> 
> I can imagine a variety of ways browsers could expose these features: 
> overloading F11 to gray out all portions of page except those are 
> fullscreenable; pressing F11 repeatedly to cycle through elements; 
> having a right click option on fullscreenable elements, automatic hover 
> borders etc.

I think this would be an interesting idea. I think experimentation with a 
UI for this would be a good way to find out if it is feasible.

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

Re: [whatwg] Installed Apps

[Ian Hickson]

On Tue, 4 Aug 2009, Drew Wilson wrote:
> On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson  wrote:
> >
> > It seems like a direct solution to these would be to have a way for 
> > Web pages to expose a service that clients could subscribe to, which 
> > could send up database updates and notifications. That way, no script 
> > runs on the client, but the server can still update the client 
> > whenever needed.
> 
> Yeah, this is an interesting idea, although I'm envisioning apps that 
> support offline use requiring what amounts to a sync process with 
> app-specific conflict resolution, etc - I think this would be difficult 
> to support with this kind of general platform. But, agreed, this is 
> better than nothing - at the very least, an application could use it to 
> sync down changes to a "staging area" for later resolution once the app 
> itself starts up.

Ok. I think this is the direction we should look in to address this use 
case then. I haven't specced anything yet, but I've noted it as a feature 
we should look at. If anyone wants to experiment in this space, that would 
be great.


> Sure, although I'd say that "persistent storage is addressed by the Web 
> Storage and Web Database features". Shared state is also addressed, but 
> that's not the primary goal. If I have a tree of objects that I'd like 
> to share between two pages, telling me to serialize it into name/value 
> string pairs, write it into Web Storage, and then have the remote side 
> read it out is not a satisfying (or performant) solution.

Web Storage supports structured data now.


> Yeah, I'm somewhat leery of the "canned RSS-feed"-style solution to 
> notifications (our vision for notifications is that they are scriptable 
> and more interactive than just a dumb text + icon).

A system that displays rich/scripted content on server demand rather than 
on user demand is a massive security nightmare. It turns a scripting 
security bug and an XSS bug into an instant malware deployment vector.


> Additionally, any server-side-feed-based solution has the implication 
> that it won't work for offline apps. If I am using a web calendar, I 
> want my event notifications regardless of whether I'm online or offline 
> (the event may have been added while I'm offline and never synced to the 
> server at all).

I think on the long term we may wish to consider adding a feature to queue 
up POSTs for when the UA finds it is back online. That would address a 
number of problems, including this one.


On Tue, 4 Aug 2009, Jeremy Orlow wrote:
> 
> The idea of tying the notification spec to a particular brand of storage
> seems like a bad idea...especially at this point in time.

We can make this work with all of the mechanisms pretty easily.


> On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson  wrote:
> >
> > I'm not sure XMPP is the protocol I would jump to, but it's certainly 
> > an option, yes.
> 
> What don't you like about XMPP?

It's far too complex for people to write and deploy an XMPP server on a 
whim. Like HTTP, it requires people to use off-the-shelf software instead 
of allowing them to experiment with their own code. This leads to software 
monocultures, and prevents easy experimentation.


On Tue, 4 Aug 2009, Dmitry Titov wrote:
>
> What about the "shared context with DOM access" idea which, even w/o 
> persistency, seems to resolve some issues for apps like GMail? Like a 
> shared worker, but with access to DOM.

I don't think that such a mechanism will work well given multicore 
processors, multiprocess UAs, and the way that gadgets end up connecting 
domains all over the place.


> 2. It does rely on 'cooperative' pages to be opened in the same process 
> but this is easy to implement. I mean, you can't 'guarantee' it (a page 
> from another domain may have iframe pointing to the app and it will be 
> in a diff. process) but any reasonable app can be easily structured in a 
> way to get its views (pages) into a single process.

I think this is understating the disadvantages of this model, and 
overestimating the ease with which one can make it work.


> 3. It would help to provide fast (meaning sub-100ms, interactively fast) 
> UI responses necessary for the seamless operations. Persistent data 
> storage and parsing/generating HTML (including loading all the code 
> necessary to do that from the 'pure data') will always present challenge 
> for sub-100ms UI actions - even in native apps it is a challenge today.
> 
> Here is a typical use case: You compose a message in GMial window. 
> Halfway through you decide to peek into another mail thread for more 
> information. You click 'tear-off' button to "disconnect" the compose 
> window so you can see other mail threads. Today, this opens a new window 
> and starts loading XXX Kb of script into it. You see the progress 
> indicator for a few seconds. This script is needed to be able to go to 
> server and generate a proper UI from the response, as well as have all 
> the 'controller' lo

Re: [whatwg] Make quoted attributes a conformance criteria

[Ian Hickson]

On Tue, 4 Aug 2009, Henri Sivonen wrote:
> On Aug 3, 2009, at 05:45, Ian Hickson wrote:
> > 
> > Instead of preventing anyone from not using quote marks, I would 
> > instead recommend asking your validator vendor to offer you an option 
> > to require quote marks and warn you when you have forgotten them.
> 
> There's a usability cost and a QA cost to adding optional features to a 
> validator, which is why I try to resist requests to add more 
> configuration and optional features to Validator.nu.

We need more validators, so that authors can pick the one they want. I'm 
not saying validator.nu should be the one to support this.

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

Re: [whatwg] the cite element

[Smylers]

Erik Vorhes writes:

> So the definition of  in HTML5 should currently be "title of
> work or something that could be construed as a title where one doesn't
> exist in the explicit sense of 'title.' But not people's names, even
> if they're the citation, because using  for citations is silly."

Hi Erik.  Rather than start with the  element and think how  you
can use it, I find it easier to understand t'other way round:

When writing text you sometimes want some words to be presented
differently (typically in italics), to convey some information to
readers.  If the semantic you wish the italicized text to convey is that
it's the title of a published work, then  is the appropriate HTML
element to use for this.

(When word processing many folks simply use italics, meaning titles are
marked up the same as, say, emphasis.  This precludes later changing the
house style in a way which distinguishes them, and from having voice
output use different voice variants for each.)

If you wish the graphical presentation of such titles to be something
other than italic (underlined perhaps, or in a different colour, or in
normal text but surrounded by quote marks) then you can achieve that
with CSS.  But the semantic is still there in the document, so can still
be conveyed to all readers and listeners, regardless of their
environment and user-agents.

For words that you wish to have no distinct presentation from the
surrounding text -- words that readers don't need calling out to them as
being in any way 'special' -- simply don't mark them up.

As Ian has pointed out, the above is technically non-conforming with
what the HTML 4 spec claims.  But it's how I've been using  for
years, since it makes sense and has a use.

Other proposed definitions of  may more closely correspond to the
English word "cite", but the set of phrases they would denote do not
seem to be a useful set of things to lump together; they do not match
any set of things which are typically conveyed to readers in a
particular way (for example by typographical conventions).

While HTML 5's definition of  is a useful thing to have an element
for, the name 'cite' is not a great choice to label that.  However the
element already exists; its previous definition has overlap with the
useful definition; and its default display in existing browsers is the
common typographic style for the useful definition (which gives weight
to the idea that the HTML 5 definition is actually what at least some
people intended in the first place, or have already been using it as).

So tweaking the definition to be more useful seems better than inventing
a new element with a better name.

Smylers

Re: [whatwg] Remove addCueRange/removeCueRanges

[Silvia Pfeiffer]

I agree with this assessment.
Please note that at this stage this is my personal opinion, since I
haven't discussed it with other Mozilla developers yet.

Regards,
Silvia.

On Thu, Aug 13, 2009 at 6:31 PM, Philip Jägenstedt wrote:
> Hi,
>
> We would like to request that addCueRange/removeCueRanges be dropped from
> the spec before going into Last Call. We are not satisfied with it and want
> to see it replaced with a solution that includes (scriptless) timed text
> (a.k.a captions/subtitles). I don't think that this will be finished in time
> for Last Call however, because we need implementor experience to write a
> good spec. However, we have no intention of implementing both cue ranges and
> its replacement, so it is better if the spec doesn't provide any solution
> for now.
>
> I have been briefly in contact with other browser vendors and while I cannot
> speak for them here, I hope those that agree will chime in if necessary.
>
> --
> Philip Jägenstedt
> Opera Software
>

[whatwg] Remove addCueRange/removeCueRanges

[Philip Jägenstedt]

Hi,

We would like to request that addCueRange/removeCueRanges be dropped from  
the spec before going into Last Call. We are not satisfied with it and  
want to see it replaced with a solution that includes (scriptless) timed  
text (a.k.a captions/subtitles). I don't think that this will be finished  
in time for Last Call however, because we need implementor experience to  
write a good spec. However, we have no intention of implementing both cue  
ranges and its replacement, so it is better if the spec doesn't provide  
any solution for now.


I have been briefly in contact with other browser vendors and while I  
cannot speak for them here, I hope those that agree will chime in if  
necessary.


--
Philip Jägenstedt
Opera Software