Re: [whatwg] the cite element

[Erik Vorhes]

On Wed, Aug 12, 2009 at 6:21 PM, Ian Hickson wrote:
> On Mon, 3 Aug 2009, Erik Vorhes wrote:
>> On Mon, Aug 3, 2009 at 6:29 AM, Ian Hickson  wrote:
>> > Not all titles are citations, actually. For example, I've heard of the
>> > /Pirates of Penzance/, but I'm not citing it, just mentioning it in
>> > passing.
>>
>> No, that actually is a citation, whether you realize it or not. You are
>> making reference to a musical and are therefore citing it, even in
>> passing.
>
> Your definition of "citation" is far looser than my dictionary's ("a
> quotation from or reference to"). In fact your definition seems to be
> basically the same as HTML5's -- a title of a work. Unless you think that
> this should be valid use of :
>
>   I picked up my favourite book, and put it next to
>   the painting I got from my aunt.
>
> I don't think that those references to works should use . Doing so
> has zero benefit, as far as I can tell.
>


No, No, NO. That is not what I mean at all. You again deliberately
misrepresent what I am trying to convey, that  should be for
citations, not for a subset of citations.

I agree (and never suggested otherwise): those are in no way explicit
citations, as there is nothing specific about them that would justify
calling them citations. Pirates of Penzance, however is
an explicit reference to that work and therefore a citation, not
"just" a title of the work.


>
> Why not? An orchestral arrangement is a work, and has a title -- the spec
> explicitly lists "score", "song", and "opera" as possible works, for
> instance.
>
> I've added "legal case report" to the list, to clarify that you can use
>  to name such reports.
>


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."



>> Unless by "title of work" you mean "standard citation for an item,
>> usually its title"; but then  really means what it is defined as
>> in the HTML 4.01 specification.
>
> Unless you have a very loose definition of "citation", or unless you
> consider a person to be a possible "source",  in HTML5 is a strict
> superset of HTML4's definition.
>
> For example, the following is valid HTML5 but wouldn't be valid HTML4,
> since it's not a citation or reference to another source, but merely
> something mentioned in passing:
>
>   Today, as I was moving my copy of Dreamer's Void, I
>   hurt my back.
>


That's perfectly fine in HTML4. It's a citation, as I have explained
previously, and there's nothing in the HTML4 spec that prohibits that
use. Why are you misrepresenting the HTML4 spec?


>> Besides, there's already , which could be used to identify "title
>> text" or something like that.
>
> It has the wrong default styles.


So does , in many contexts even if we're relying on the
definition in HTML5 as it stands.


>  is also used to mark up titles that aren't citations, as shown by
> Philip's data.


Again. Those *are* citations.


>> There's no reason to limit it to a subset of citation (more below).
>
> I honestly don't understand how HTML5 is a subset of HTML4 here, unless
> you mean people's names, which as far as I can tell aren't commonly used
> with , and for which there is no benefit to using .


I believe they are more commonly used than you are willing to admit.



> Wikipedia's output is not an argument for consuming . In fact, what
> they're doing is an argument against keeping  for that purpose: they
> are explicitly overriding the only behaviour  gives them (italics)
> and then going out of their way to reintroduce that effect on a ! If
> that's not an argument for changing the meaning of  to something
> more convenient, I don't know what is.


Yes, Wikipedia's overall markup is problematic, but you seemed to be
needing some actual evidence that  is used for more than simply
"title of work" other than blog commenter names (which for some
inexplicable reason you have rejected out-of-hand as evidence that
 is used for people's names and other non-title citations).



>> Any reference to a title of a work is by definition a citation.
>> Therefore you are limiting  to a subset of citation.
>
> I disagree with your definition of "citation".


I'm sorry the New Oxford American Dictionary isn't good enough for you. I quote:

- a quotation from or reference to a book, paper, or author, esp. in a
scholarly work
- a mention of a praiseworthy act or achievement in an official
report, esp. that of a member of the armed forces in wartime
- a note accompanying an award, describing the reasons for it
- [in Law] a reference to a former tried case, used as guidance in the
trying of comparable cases or in support of an argument



>
> Unless you can demonstrate that there is a concrete benefit to doing what
> you describe, I do not think it is a good idea. There are concrete
> benefits to the definition currently i

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

[Aryeh Gregor]

On Wed, Aug 12, 2009 at 3:08 AM, Ian Hickson wrote:
>> In 4.2.4:
>>
>> "If the attribute is present, then the user agent must assume that the
>> resource is of the given type. If the attribute is omitted, but the
>> external resource link type has a default type defined, then the user
>> agent must assume that the resource is of that type."
>>
>> Why "must" and not "should"?  Perhaps the user agent has some good
>> reason to think the attribute is wrong.
>
> Because otherwise we don't get interoperable behaviour. That kind of
> reasoning is how we ended up with the crazy content sniffing behaviour we
> have now, with its assorted security issues.

Consider a search engine that can only index certain types of content.
 If a type attribute is provided on a link, and the type indicates a
non-supported type of content, the search engine would be required to
assume that the resource is not supported.  So say it does this, but a
major site emits incorrect type attributes for some links.  The
authors of the search engine spider become aware of this and are
unable to persuade the authors of the site to change their markup.
Should they have to still refrain from following the incorrectly
marked-up links?

Well, I guess I can answer my own question.  If authors produce markup
that's invalid, such that a user agent that followed the standard
would not be able to process the markup correctly, and those authors
are important enough that the implementers of the user agent can't
afford to process their markup incorrectly, then the implementers
would reasonably be expected to willfully violate the standard as much
as is strictly necessary to serve their purposes.  Like IE7
Compatibility Mode, say.  This is prohibited by the standard and does
make the user agent non-conformant in that respect, but it's not
useful to add a generic clause to the standard saying "you can ignore
everything if you really have to" to handle this case.  That's
implicit in the fact that the standard isn't mandated by law or
whatever.

So I withdraw the suggestion.

> 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.

> 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.

(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.)

>> In 4.6.16:
>>
>> "To make George eat an apple, select
>>     File|Eat 
>> Apple...
>> "
>>
>> That seems excessively baroque.  While it's a matter of taste, I guess,
>> I think it would be better if the spec didn't go out of its way to
>> encourage markup that's so excessively nested and unreadable for no
>> apparent purpose.
>
> This is again basically aimed at the pedants who like to argue about
> exactly how to mark up particular semantics. You'd be amazed how often I'm
> asked how to mark up that kind of thing.

I think that File | Eat Apple... or File | Eat
Apple... would be a better recommendation in this case.  It's
really unlikely that you'd need such excruciating precision in the
markup here.  It's pretty ugly, and violates the general principle
that if your markup isn't easily readable in a text editor, you're
using too much of it.

Actually, in real life I think the best recommendation would be to
just not use  or  at all, and use  or something
instead unless there's some special reason you want to distinguish
user input from other types of code, like style (in which case 
or  would be more convenient than using a class).  I'm guessing
that these elements are only present in the standard because they were
in previous versions of HTML and there's no good reason to actively
remove them?  They strike me as drastically less useful than many
other tags that would be rejected for having an insufficient use-case.

> Are F-sigma and G-delta variables?

Well, strictly speaking I guess they're constants, if you want to make
that distinction.  Is  inappropriate for 

Re: [whatwg] More input element feedback

[Ian Hickson]

On Mon, 3 Aug 2009, Kartikaya Gupta wrote:
> > >
> > > Also, editorial fix: in the same two paragraphs ("On getting" and 
> > > "On setting" for valueAsNumber), the link to valueAsDate is wrong; 
> > > it just links back to #dom-input-valueAsNumber instead of 
> > > #dom-input-valueAsDate.
> > 
> > It appears I already fixed that already.
> 
> It's still wrong for me. Search for the string "Otherwise, if the 
> valueAsDate" in the spec. There should be two occurrences; in both of 
> them the "valueAsDate" links to #dom-input-valueAsNumber.

Indeed! Thanks. Fixed.

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

Re: [whatwg] More input element feedback

[Ian Hickson]

On Mon, 3 Aug 2009, Garrett Smith wrote:
> 
> Why did you want valueAsNumber in the first place?
> 
> Why do you need valueAsDate?
> 
> Both of these seem unnecessary, out of place and overcomplicate INPUT.

Both are included as convenience methods to allow authors to get the data 
in a direct form without needing to parse it manually.

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

Re: [whatwg] question about Web Storage setItem()'s behavior

[Jeremy Orlow]

On Wed, Aug 12, 2009 at 4:26 PM, Cameron McCormack  wrote:

> Boris Zbarsky:
> > Given the actual example code (and not its description, which
> > doesn't match the code), the relevant section is
> > http://dev.w3.org/2006/webapi/WebIDL/#es-operations steps 1 through
> > 3 in the third bullet point.
> >
> > It looks to me like per the current spec text that will throw a
> > TypeError for the above call, unless the second argument to setItem
> > is marked [optional].
>
> Yeah I think that’s right.  I’ll just note though that behaviour when
> passing too many or too few arguments is still an open issue (although
> it’s more likely that the ‘too many’ case will change than the ‘too few’
> case).
>
> OTOH, passing in undefined explicitly as the second argument would have
> it converted to the string "undefined".


Thanks for the clarification.  I'll file a bug on WebKit.

Re: [whatwg] Web Workers and postMessage(): Questions

[Ian Hickson]

On Mon, 3 Aug 2009, Daniel Gredler wrote:
> On Sat, Aug 1, 2009 at 4:59 PM, Ian Hickson  wrote:
> > On Wed, 22 Jul 2009, Daniel Gredler wrote:
> > > Second, why not walk the prototype chain? Similar rules regarding 
> > > host objects and regular objects could apply to prototypes. You 
> > > would want to make sure that multiple references to the same 
> > > prototype instance result in references to a single prototype clone 
> > > in the cloned object graph. Again, though, it doesn't sound too hard 
> > > (though I might just be optimistic). Why not make web designers' 
> > > lives easier?
> >
> > We're definitely never going to copy function code over, so it's not 
> > clear that the prototype chain would be that useful. Could you 
> > elaborate on your use case?
> 
> I agree that once you've made the decision to not clone functions, 
> cloning the prototype chain becomes (nearly?) useless. However, I'd be 
> interested to know the rationale behind this decision, since Web Workers 
> appear to follow the same-origin policy (e.g. "If the origin of the 
> resulting absolute URL is not the same as the origin of the script that 
> invoked the constructor, then throw a security exception", etc). I 
> assume there's a security concern lurking somewhere?

Workers obey the same-origin policy for creation, but you can easily pass 
ports around so that non-same-origin code can talk to your worker.


> My specific use case spits out a tree, each node having a reference to 
> its children and its parent (hence the issue with circular references). 
> Each node also has a "name" attribute and a function (in the prototype) 
> used to retrieve the node's "path" (based on its name and its ancestors 
> names) -- I don't want to precalculate each node's path and keep it in 
> memory, given that there are tens of thousands of nodes (or more).

Serialise the tree and pass the serialised version, then reconstruct the 
objects on the other side.

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

Re: [whatwg] question about Web Storage setItem()'s behavior

[Cameron McCormack]

Boris Zbarsky:
> Given the actual example code (and not its description, which
> doesn't match the code), the relevant section is
> http://dev.w3.org/2006/webapi/WebIDL/#es-operations steps 1 through
> 3 in the third bullet point.
> 
> It looks to me like per the current spec text that will throw a
> TypeError for the above call, unless the second argument to setItem
> is marked [optional].

Yeah I think that’s right.  I’ll just note though that behaviour when
passing too many or too few arguments is still an open issue (although
it’s more likely that the ‘too many’ case will change than the ‘too few’
case).

OTOH, passing in undefined explicitly as the second argument would have
it converted to the string "undefined".

-- 
Cameron McCormack ≝ http://mcc.id.au/

Re: [whatwg] the cite element

[Ian Hickson]

On Mon, 3 Aug 2009, Erik Vorhes wrote:
> On Mon, Aug 3, 2009 at 6:29 AM, Ian Hickson  wrote:
> > Not all titles are citations, actually. For example, I've heard of the 
> > /Pirates of Penzance/, but I'm not citing it, just mentioning it in 
> > passing.
>
> No, that actually is a citation, whether you realize it or not. You are 
> making reference to a musical and are therefore citing it, even in 
> passing.

Your definition of "citation" is far looser than my dictionary's ("a 
quotation from or reference to"). In fact your definition seems to be 
basically the same as HTML5's -- a title of a work. Unless you think that 
this should be valid use of :

   I picked up my favourite book, and put it next to 
   the painting I got from my aunt.

I don't think that those references to works should use . Doing so 
has zero benefit, as far as I can tell.


> > > See ; note near the top of the source: 
> > > ...
> >
> > My statement stands, on the aggregate:
> >
> > On Mon, 27 Jul 2009, Philip Taylor wrote:
> > >
> > > See http://philip.html5.org/data/cite-attribute-values.txt for some 
> > > data. (Looks like non-URI values are quite rare.)
> 
> I agree that @cite is rarely used as anything other than a URI; I was 
> attempting to demonstrate that even very recent uses of HTML don't 
> necessarily "get" that it is for URIs (the site I referenced launched 
> last month, as I recall).

Mistakes are common with HTML, sure.


> > While we're at it, Philip had other data:
> >
> > > Also maybe relevant: see http://philip.html5.org/data/cite.txt for 
> > > some older data about . (Looks like non-title uses are very 
> > > common.)
> >
> > This seems to support my point that  is used for a whole variety 
> > of purposes, like , , , HTML4's , and HTML5's . 
> > Very few, actually much fewer than I had remembered from my last look 
> > at the data, are names of people, citations or otherwise.
> 
> I actually took this information the other way, that there are indeed 
> other uses for  out there beyond titles.

I don't think anyone has argued otherwise. I've only argued that of the 
uses that  is put to, the only ones that are common but have no 
other more appropriate elements (i.e. aren't flat out mistakes) are 
citations and titles, and not people's names.


> > On Mon, 27 Jul 2009, Erik Vorhes wrote:
> > >
> > > > A new element wouldn't work in legacy UAs, so it wouldn't be as 
> > > > compelling a solution. Also,  is already being used for this 
> > > > purpose.
> > >
> > > My preference would be for  to retain the flexibility it has 
> > > in pre-HTML5 specifications, which would include referencing titles.
> >
> > The flexibility doesn't seem as useful as limiting it to titles. What 
> > is the problem solved by allowing names to be marked up in the same 
> > manner as titles? The problem solved by allowing titles specifically 
> > to be marked up is that titles are usually typographically offset from 
> > the surrounding text in a distinctive fashion. This doesn't apply to 
> > names. Reusing the same element for both encourages authors to use 
> >  for both which makes it harder for them to get the right 
> > typographic effect, leading to a lower quality of typography overall. 
> > I think this is a bad thing.
> 
> This is not just about names. It allows other (non-title) text to be 
> identified as a citation. If  is identified as "title of work," 
> you can't cite many major orchestral arrangements at all, nor can you 
> cite legal decisions.

Why not? An orchestral arrangement is a work, and has a title -- the spec 
explicitly lists "score", "song", and "opera" as possible works, for 
instance.

I've added "legal case report" to the list, to clarify that you can use 
 to name such reports.


> Unless by "title of work" you mean "standard citation for an item, 
> usually its title"; but then  really means what it is defined as 
> in the HTML 4.01 specification.

Unless you have a very loose definition of "citation", or unless you 
consider a person to be a possible "source",  in HTML5 is a strict 
superset of HTML4's definition.

For example, the following is valid HTML5 but wouldn't be valid HTML4, 
since it's not a citation or reference to another source, but merely 
something mentioned in passing:

   Today, as I was moving my copy of Dreamer's Void, I
   hurt my back.


> > > If backwards compatibility is that big a concern, why does HTML5 use 
> > >  outside of  elements?
> >
> > There were no existing elements that could be reused for many of the 
> > new semantics. When there were, we used them (e.g. , , , 
> > , , ).
> 
> I agree that there aren't always existing elements for the new semantics 
> included in HTML5, but I don't believe that backwards compatibility is 
> as big a concern as you claim it is.

Ok.


> HTML5's re-use of , for example, is completely broken in every 
> extant browser.

Yeah,  is a complicated case where a number of factors have 
prevented an ideal soluti

Re: [whatwg] question about Web Storage setItem()'s behavior

[Boris Zbarsky]

Jeremy Orlow wrote:

 > and, when passed value is undefined (e.g. `setItem("key")`), which
 > behavior will be correct?

...

I believe this is the correct section of the spec to be looking 
at: http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString


If so, I think it's pretty clear that Safari's implementation is correct 
on this issue.


Given the actual example code (and not its description, which doesn't 
match the code), the relevant section is 
http://dev.w3.org/2006/webapi/WebIDL/#es-operations steps 1 through 3 in 
the third bullet point.


It looks to me like per the current spec text that will throw a 
TypeError for the above call, unless the second argument to setItem is 
marked [optional].


-Boris

Re: [whatwg] Begin discussions for pushing Last Call into 2010

[Sam Ruby]

Shelley Powers wrote:
 

Issue-74/Action-133 canvas-accessibility
This item is not due this week, but I'm choosing to flag it at this 
time as it as a target date of 2009-12-17 which would preclude us 
for going to Last Call this year.  I'd like to put out a call for 
volunteers: if there is anybody out there with an interest and 
ability to help pull this date in, I would like to ask that they 
step forward.


[snip]

Well, then, since the date on the action item for Canvas accessibility 
is past last call date, we should begin the discussion about pushing 
Last Call into 2010.


Per my original message: I would first like to see if there is any way 
we can pull the date in.  If we can not, I will agree that what you are 
describing is the obvious consequence.


Any notion that either the HTML WG or the WHATWG view this as "not our 
problem" is rather short-sighted.  I am specifically asking that anybody 
from either the WHATWG or HTML WG who has an interest in making last 
call be this year and may be able to contribute to discussions on making 
canvas be more accessible either attend tomorrow's call or at the very 
least be on the #html-wg IRC channel at that time.


And, yes, I am intentionally cross-posting this request.


Shelley


- Sam Ruby

Re: [whatwg] question about Web Storage setItem()'s behavior

[Jeremy Orlow]

On Wed, Aug 12, 2009 at 1:34 AM, Ian Hickson  wrote:

> On Wed, 12 Aug 2009, į~Y―į~_ģäŋ~Jåđģ wrote:
> >
> > and, when passed value is undefined (e.g. `setItem("key")`), which
> > behavior will be correct?
> > On current implementation of browsers, I looked as follows.
> > - IE and Firefox raise error, (arguments number is incorrect)
> > - Webkit family persist it as string ("undefined")
>
> I believe WebIDL says that a TypeError exception should be thrown, but it
> was not immediately obvious to me how to derive this from the spec.


I believe this is the correct section of the spec to be looking at:
http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString
If so, I think it's pretty clear that Safari's implementation is correct on
this issue.

Re: [whatwg] Alt attribute for and

[Remco]

On Wed, Aug 12, 2009 at 3:52 PM, Philip Jägenstedt wrote:
> The resource selection algorithm loops through the source elements and when
> it reaches the last one just waits for another source element to be
> inserted. It doesn't make any distinction between static markup and elements
> inserted via DOM, so even if you have  in your
> markup, it will still wait for another source element to be inserted via
> DOM. This is for spec simplicity basically, I'm not saying that it's a
> brilliant use case in itself.
>
> The spec says:
>
> In addition to the above, the user agent may provide messages to the user
> (such as "buffering", "no video loaded", "error", or more detailed
> information) by overlaying text or icons on the video or other areas of the
> element's playback area, or in another appropriate manner. [end quote]
>
> Trying to specify exactly when such extra overlays are appropriate is
> difficult, because it's really just a guess. Something like when parsing has
> finished, there are no more source elements and no scripts running that
> might insert more of them. But that would be wrong sometimes, you have no
> way of predicting what future scripts might do.

OK, so an alt entry in the spec should not mandate its display at a
specified situation, but could just suggest it as a possible "more
detailed information". So the spec would become:

In addition to the above, the user agent may provide messages to the
user (such as "buffering", "no video loaded", "error", the contents of
the alt attribute, or other more detailed information) by overlaying
text or icons on the video or other areas of the element's playback
area, or in another appropriate manner.[end quote]

>> If videos are desirable and available, but text is also desirable,
>> then the alt text could be displayed/spoken/etc when you tab onto it,
>> as Silvia Pfeiffer proposed in a previous email.
>
> I believe that was accomplished with some kind of ARIA attributes, correct
> me if I'm wrong.

I'm no expert on ARIA, but as far as I know it can be done with
aria-labelledby. This is pretty complicated though. You have to
provide an additional element, style or hide it, and reference it
through aria-labelledby. It's pretty DIY. This looks like another
longdesc fiasco to me. It has other more realistic uses such as making
existing elements (forms, etc) accessible, but I don't see it getting
used for arbitrary alternate content.

It would be a lot nicer if a web author could just provide an alt text
which would show up when the video doesn't load for whatever reason. I
don't think it's possible to create an easier tool for web authors to
make a video somewhat accessible.

Same stuff applies to , , , , .

Remco

Re: [whatwg] Alt attribute for and

[Philip Jägenstedt]

On Wed, 12 Aug 2009 14:45:36 +0200, Remco  wrote:

On Wed, Aug 12, 2009 at 1:26 PM, Philip Jägenstedt  
wrote:

On Wed, 12 Aug 2009 12:52:38 +0200, Remco  wrote:


On Wed, Aug 12, 2009 at 10:57 AM, Philip Jägenstedt
wrote:


Before suggesting any changes to the  element, make sure you  
have

read

http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm

Put simply, the handling of  is already quite complex,
overloading
it with completely different meanings is not a good idea.   
won't
handle "text/html" as a source, but if you want different media files  
for

different audiences I suggest experimenting with .


 doesn't do anything useful for my case. It can't load
textual data. Also, if the resources are unavailable, there will be
nothing to see, since all resources are off-page. It also doesn't work
for iframe, object, embed or img.

Is it really the idea that the only way you're going to have
alternative textual content, is to Build It Yourself? You have to
abuse  or a hidden  with some Javascript to build a
construction that has alternative content in case the
video/audio/iframe/object/embed is not available or desirable. If you
want it to be semantically accessible, you even have to build another
layer on top of that, in the form of ARIA attributes.


No, in the long term we want native captions/subtitle support in the
browsers. See
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/021658.html
and maybe  
http://lists.w3.org/Archives/Public/public-html/2009Aug/0439.html


OK, that's awesome. I mean, really! That is on par with DVD
functionality. But that's not exactly my case. It involves subtitling
the video. The format has to be learned, and time has to be spent on a
video. If a web author has no intention of doing so, but wants to give
a short textual alternative and be done with it, he is not able to do
that.


Nobody will do that. Even the  solution is harder, maybe too
hard, to use than the alt="" solution. It requires authors to create
additional elements or pages to house the alternative content. Since
accessibility is often an afterthought, about the most an author will
be willing to do, is filling in an alt attribute.


What do you suggest a browser do with the alt attribute? The resource
selection algorithm never ends until a suitable source is found, so when
should the alt text be displayed? By requiring anything at all, browsers
can't do things like display a box with a direct download link,  
suggestion

to install a specific codec, etc. If nothing at all is required of user
agents for the alt attribute, then I have no opinion (but then I expect  
no

one would use it either).


Well, I would suggest that the browser displays the text when no
desirable resource is available. In the case of network problems, no
resource at all is available. In the case of a textual browser (or a
"Disable Media" button), all videos are undesirable. You can still
show a download link or a codec suggestion, but you can display the
alt text below it, for the people who don't really care about a video,
or people who know the network connection won't be back for some time,
or people who can't or won't install the codec.

I must admit that I don't understand the media selection algorithm.
You say that it never ends. How does that work? The browser keeps
looping through the source elements until one becomes desirable and
available? How does that give browsers the opportunity to display a
download link or a codec suggestion? How should textual browsers
handle that?


The resource selection algorithm loops through the source elements and  
when it reaches the last one just waits for another source element to be  
inserted. It doesn't make any distinction between static markup and  
elements inserted via DOM, so even if you have  in  
your markup, it will still wait for another source element to be inserted  
via DOM. This is for spec simplicity basically, I'm not saying that it's a  
brilliant use case in itself.


The spec says:

In addition to the above, the user agent may provide messages to the user  
(such as "buffering", "no video loaded", "error", or more detailed  
information) by overlaying text or icons on the video or other areas of  
the element's playback area, or in another appropriate manner. [end quote]


Trying to specify exactly when such extra overlays are appropriate is  
difficult, because it's really just a guess. Something like when parsing  
has finished, there are no more source elements and no scripts running  
that might insert more of them. But that would be wrong sometimes, you  
have no way of predicting what future scripts might do.



If videos are desirable and available, but text is also desirable,
then the alt text could be displayed/spoken/etc when you tab onto it,
as Silvia Pfeiffer proposed in a previous email.


I believe that was accomplished with some kind of ARIA attributes, correct  
me if I'm wrong.


--
Philip Jä

Re: [whatwg] Alt attribute for and

[Remco]

On Wed, Aug 12, 2009 at 1:26 PM, Philip Jägenstedt wrote:
> On Wed, 12 Aug 2009 12:52:38 +0200, Remco  wrote:
>
>> On Wed, Aug 12, 2009 at 10:57 AM, Philip Jägenstedt
>> wrote:
>>>
>>> Before suggesting any changes to the  element, make sure you have
>>> read
>>>
>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm
>>>
>>> Put simply, the handling of  is already quite complex,
>>> overloading
>>> it with completely different meanings is not a good idea.  won't
>>> handle "text/html" as a source, but if you want different media files for
>>> different audiences I suggest experimenting with .
>>
>>  doesn't do anything useful for my case. It can't load
>> textual data. Also, if the resources are unavailable, there will be
>> nothing to see, since all resources are off-page. It also doesn't work
>> for iframe, object, embed or img.
>>
>> Is it really the idea that the only way you're going to have
>> alternative textual content, is to Build It Yourself? You have to
>> abuse  or a hidden  with some Javascript to build a
>> construction that has alternative content in case the
>> video/audio/iframe/object/embed is not available or desirable. If you
>> want it to be semantically accessible, you even have to build another
>> layer on top of that, in the form of ARIA attributes.
>
> No, in the long term we want native captions/subtitle support in the
> browsers. See
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/021658.html
> and maybe http://lists.w3.org/Archives/Public/public-html/2009Aug/0439.html

OK, that's awesome. I mean, really! That is on par with DVD
functionality. But that's not exactly my case. It involves subtitling
the video. The format has to be learned, and time has to be spent on a
video. If a web author has no intention of doing so, but wants to give
a short textual alternative and be done with it, he is not able to do
that.

>> Nobody will do that. Even the  solution is harder, maybe too
>> hard, to use than the alt="" solution. It requires authors to create
>> additional elements or pages to house the alternative content. Since
>> accessibility is often an afterthought, about the most an author will
>> be willing to do, is filling in an alt attribute.
>
> What do you suggest a browser do with the alt attribute? The resource
> selection algorithm never ends until a suitable source is found, so when
> should the alt text be displayed? By requiring anything at all, browsers
> can't do things like display a box with a direct download link, suggestion
> to install a specific codec, etc. If nothing at all is required of user
> agents for the alt attribute, then I have no opinion (but then I expect no
> one would use it either).

Well, I would suggest that the browser displays the text when no
desirable resource is available. In the case of network problems, no
resource at all is available. In the case of a textual browser (or a
"Disable Media" button), all videos are undesirable. You can still
show a download link or a codec suggestion, but you can display the
alt text below it, for the people who don't really care about a video,
or people who know the network connection won't be back for some time,
or people who can't or won't install the codec.

I must admit that I don't understand the media selection algorithm.
You say that it never ends. How does that work? The browser keeps
looping through the source elements until one becomes desirable and
available? How does that give browsers the opportunity to display a
download link or a codec suggestion? How should textual browsers
handle that?

If videos are desirable and available, but text is also desirable,
then the alt text could be displayed/spoken/etc when you tab onto it,
as Silvia Pfeiffer proposed in a previous email.

Remco

Re: [whatwg] DragEvent's inherited MouseEvent properties should be available to all drag events

[Sebastian Markbåge]

>
> > The spec should explicitly specify which MouseEvent properties are
> > available during the various drag events to avoid assumptions.
>
> The spec requires them to all be set on all drag events, currently.
>

I thought that this was clear too but apparently it's not clear that they
should be set to something useful:

https://bugzilla.mozilla.org/show_bug.cgi?id=505521


> > The specification is only partly input device agnostic. It can't be both
> > totally input device agnostic and inherit MouseEvent. If it's going to
> > inherit MouseEvent it needs to be specified what that means.
>
> I've added more text to clarify what it means in the case of the mouse not
> being used.
>
>
Apparently it also needs to be clear that the properties SHOULD be set, if a
pointing device IS being used. See above conversion on the Mozilla bug.

I'd suggest you add something like "If there is a relevant pointing device,
the attributes should be set to relevant position values for all events in
the sequence." - So that the intention is clear and don't have to rely on
implicit interpretation.

Re: [whatwg] Alt attribute for and

[Philip Jägenstedt]

On Wed, 12 Aug 2009 12:52:38 +0200, Remco  wrote:

On Wed, Aug 12, 2009 at 10:57 AM, Philip Jägenstedt  
wrote:
Before suggesting any changes to the  element, make sure you  
have

read
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm

Put simply, the handling of  is already quite complex,  
overloading

it with completely different meanings is not a good idea.  won't
handle "text/html" as a source, but if you want different media files  
for

different audiences I suggest experimenting with .


 doesn't do anything useful for my case. It can't load
textual data. Also, if the resources are unavailable, there will be
nothing to see, since all resources are off-page. It also doesn't work
for iframe, object, embed or img.

Is it really the idea that the only way you're going to have
alternative textual content, is to Build It Yourself? You have to
abuse  or a hidden  with some Javascript to build a
construction that has alternative content in case the
video/audio/iframe/object/embed is not available or desirable. If you
want it to be semantically accessible, you even have to build another
layer on top of that, in the form of ARIA attributes.


No, in the long term we want native captions/subtitle support in the  
browsers. See  
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/021658.html  
and maybe http://lists.w3.org/Archives/Public/public-html/2009Aug/0439.html



Nobody will do that. Even the  solution is harder, maybe too
hard, to use than the alt="" solution. It requires authors to create
additional elements or pages to house the alternative content. Since
accessibility is often an afterthought, about the most an author will
be willing to do, is filling in an alt attribute.


What do you suggest a browser do with the alt attribute? The resource  
selection algorithm never ends until a suitable source is found, so when  
should the alt text be displayed? By requiring anything at all, browsers  
can't do things like display a box with a direct download link, suggestion  
to install a specific codec, etc. If nothing at all is required of user  
agents for the alt attribute, then I have no opinion (but then I expect no  
one would use it either).


--
Philip Jägenstedt
Core Developer
Opera Software

Re: [whatwg] BWTP for WebSocket transfer protocol

[Greg Wilkins]

Jonas Sicking wrote:

> I'd rather not debate about which process should be used to get to a
> good protocol. I'd rather debate concrete proposals.

Sure.

So I think I'll keep this response short and see if I can
come up with a BWTP mkII  proposal that addresses
the feedback that I've received.



> So, can you describe an application which takes advantage of this
> added value. I.e. an application that transmits JSON, and that would
> not be put at some type of disadvantage (slower, harder to implement,
> impossible to implement etc) if it couldn't use the new 0x01 frame
> type.

An application that sends just a single content type like JSON is
not going to have any advantage from that proposal, because it
can assume that messages will be text/json;charset=utf8 and
be more efficient than anything that actually transmits that.

But any application that might send multiple types and/or charsets
will benefit.   Also any application that might want to conditionally
compress or encrypt a message would benefit.

Also browser that want to share a single connection between multiple
WebSocket API instances would benefit as they could use the metadata
to organize the virtual connections without the need to alter the
payload.


cheers

Re: [whatwg] Alt attribute for and

[Remco]

On Wed, Aug 12, 2009 at 10:57 AM, Philip Jägenstedt wrote:
> Before suggesting any changes to the  element, make sure you have
> read
> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm
>
> Put simply, the handling of  is already quite complex, overloading
> it with completely different meanings is not a good idea.  won't
> handle "text/html" as a source, but if you want different media files for
> different audiences I suggest experimenting with .

 doesn't do anything useful for my case. It can't load
textual data. Also, if the resources are unavailable, there will be
nothing to see, since all resources are off-page. It also doesn't work
for iframe, object, embed or img.

Is it really the idea that the only way you're going to have
alternative textual content, is to Build It Yourself? You have to
abuse  or a hidden  with some Javascript to build a
construction that has alternative content in case the
video/audio/iframe/object/embed is not available or desirable. If you
want it to be semantically accessible, you even have to build another
layer on top of that, in the form of ARIA attributes.

Nobody will do that. Even the  solution is harder, maybe too
hard, to use than the alt="" solution. It requires authors to create
additional elements or pages to house the alternative content. Since
accessibility is often an afterthought, about the most an author will
be willing to do, is filling in an alt attribute.

Remco

Re: [whatwg] Reading spec without boxes

[Smylers]

Ian Hickson writes:

> On Thu, 6 Aug 2009, Smylers wrote:
> 
> > Instead of setting the smaller font on the boxes, set it on all
> > their children (.box > * -- or whatever the class name is).  This
> > still makes the text smaller.  But that leaves the width of the box
> > being specified relative to the main content font -- the same as the
> > margin it needs to fit in.  As such it's trivial to pick a size that
> > always fits.
> 
> I applied the above suggestions.

Thanks -- and apologies for not having got round to suggesting this
before other people started complaining.

Smylers

Re: [whatwg] BWTP for WebSocket transfer protocol

[Jonas Sicking]

Missed a few parts to reply to:

On Wed, Aug 12, 2009 at 1:10 AM, Greg Wilkins wrote:
> Of course the 0x80 length framed binary data type could be
> used to send mime encoded messages, but then there would need
> to be other standards to work out what style of meta-data was
> used - if at all.

We'll need standards on top of BWTP/WS anyway, just getting a JSON
object doesn't really describe what to do with it. I.e. say that you
get

{ "message": "hello world", "from": "Eric" }

what do you do? Do you append "Eric: hello world" to your IM
conversation? Reject the message because it doesn't contain a
"channel" property which your irc application requires?

> But from a protocol point of view, I simply do not like the
> favoured-son status given to UTF-8 messages.  What good is
> knowing the character encoding if you don't know if the content
> is XML or JSON?  Are we going to have to write sniffers to
> look for XML, JSON, HTML content?
>
> Why is utf-8 given it's own framing type (sentinels), when
> the length framed binary framing is capable of carry the
> messages just as efficiently and the sentinel framing fails
> to support common transports such as gzipping etc.
>
> I really think that the ws protocol started from some
> assumptions that are just too special case for the javascript
> API usage and that it will be easier to come up with new
> clean protocols rather than push websocket protocol away
> from the assumptions that underlay is basic design.

While I agree that the protocol should be useful not just to be useful
for a single API, I do think we should keep APIs for using the
protocol in mind when designing it. From that point of view it makes
sense to me to separate text data from binary data. Not just for the
javascript API, but for other APIs as well.

/ Jonas

Re: [whatwg] BWTP for WebSocket transfer protocol

[timeless]

Jonas Sicking wrote:
> The only site where I can
> remember seeing content negotiation actually used is on w3.org

fwiw, MXR (and even LXR) uses some content negotiation, and it
generally "magically works". OTOH it's transparent, so you shouldn't
"see" it :).

But yes, I'd say that content negotiation is a failure. Another
failure in that area is Link: :).

The problem with content types i think stems more from:
1. images generally having random file extensions because users didn't
understand them
2. users who were publishing content in other formats not actually
having enough easy control over their hosting providers to specify the
content type, or knowing that it was necessary

Partially, both of these stem from the internet mantra: be strict in
what you send and graceful in what you receive.
However, only computers can be strict in what they send. So "be
ignorant of what you send" + "be graceful in what you receive" results
in "no one can trust what is sent".

Re: [whatwg] BWTP for WebSocket transfer protocol

[Jonas Sicking]

On Wed, Aug 12, 2009 at 1:10 AM, Greg Wilkins wrote:
> Jonas Sicking wrote:
>
>> I agree we should use the experiences from HTTP. However it seems like
>> we have different experiences.
>>
>> For example mime-types in HTTP have a very troubled record. Look at
>> Adam Barth's draft [1] for what browsers are forced to do to stay
>> compatible with the web.
>
> Indeed.  However I would argue that a lot of that problem is probably
> the result of the initial HTTP protocol not supporting content types,
> so that browsers started infering type from URL extensions etc.
> So when a proper mime-mechanism was finally provided, it was too
> late as bad practises were entrenched and remain so to this day.
>
> I would hate to see a new protocol repeat this mistake and
> start without support for content-types.

I don't think this was due to initial mistakes as the problem keeps
repeating. It's not just that many times there is no appropriate
mimetype to use (such as the fonts example). I think the judge is
still out on if we'll be successful in enforcing mimetypes on video.

>> So while I agree that we should look towards existing protocols, we do
>> need to be honest about what has been successful and what hasn't, and
>> not just assume that of existing protocols do something, it's a good
>> idea.
>
> I totally agree.
>
> I think we should start with existing protocols, slice away the
> capabilities that are not used and then build from there.

I'd rather not debate about which process should be used to get to a
good protocol. I'd rather debate concrete proposals.

>>> Example proposal to improve websocket protocol that
>>> was rejected:
>>>
>>> Greg Wilkins wrote:
> It would be great if the websocket proposal could include
> standard definitions for mime encoded datagrams.
>
> Current frame types are:
>
>   0x00  - sentinel framed UTF-8 message
>   0x80  - length framed binary data.
>
> I'd like to see two additional frame types supported
> by default:
>
>   0x01  - sentinel framed UTF-8 encoded MIME message
>   0x81  - length framed MIME message.
> 
>>
>> If we want mime-support this seems like a good proposal. Except I
>> don't understand the point of having the mime header optional? If
>> someone wants to send something without a mimetype it seems like the
>> other frame types cover that.
>
> The mime head was not optional, it was just proposed that an empty
> header (CRLFCRLF) would be legal.    You don't really want to have to
> be forced to change framing type just because you don't have any metadata

The proposal specifically said "The header is optional and terminated
by CR LF CR LF". Anyhow, I don't think it's an important issue. I'm
also wondering why terminate the mimetype with "CR LF CR LF" rather
than simply space or a null character?

>> I'm curious to hear what you consider the advantages of this over
>> simply transmitting for example JSON over a "sentinel framed UTF-8
>> message" frame? I.e. can you describe an application that would send
>> JSON using the above proposal.
>
> It would be difficult to transport some media types over
> JSON on a sentinel framed UTF-8 message.   For example image/jpeg
> would not be efficiently sent in JSON.

I think you are misunderstanding my question, so let me try over from
the beginning:

The proposal proposed that the API could use a separate notification
mechanism when JSON data was transmitted. So I take it that it is
imagined that someone will want to submit JSON data for *something*
using the wire protocol (in addition to other types, like text/xml and
image/png)

Additionally, it seems like the proposal claims to add some value when
transmitting JSON data using the new 0x01 frame type over transmitting
JSON data using the existing 0x00 frame type.

So, can you describe an application which takes advantage of this
added value. I.e. an application that transmits JSON, and that would
not be put at some type of disadvantage (slower, harder to implement,
impossible to implement etc) if it couldn't use the new 0x01 frame
type.

I hope that better explains my question?

/ Jonas

Re: [whatwg] Alt attribute for and

[Philip Jägenstedt]

On Wed, 12 Aug 2009 01:09:16 +0200, Remco  wrote:


As a small part of integrating the ideas of ARIA into existing HTML 5,
I just got an idea for a better solution for replacement content for
video and audio: .

The source element is used to provide media elements with multiple
sources. What if one of those sources could be an element on the page
itself? The text is just another source which could link off-page, or
on-page.







Alternative content in  which comes from an element on the
same page is an extension to what you already know, and it doesn't
require you to know about a special accessibility part of HTML.

In addition: currently,  is only used for  and ,
but why not extend it to any external element?











That last one may be problematic, since img-elements have
traditionally never had a closing tag. I don't know how browsers will
react to something like that. Maybe it would be better to have alt=
and longdesc= remain for the img-element, and give longdesc the
aria-describedby functionality (it could link to an element on the
same page) in addition to the original meaning.


Before suggesting any changes to the  element, make sure you have  
read

http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm

Put simply, the handling of  is already quite complex, overloading  
it with completely different meanings is not a good idea.  won't  
handle "text/html" as a source, but if you want different media files for  
different audiences I suggest experimenting with .


--
Philip Jägenstedt
Core Developer
Opera Software

Re: [whatwg] question about Web Storage setItem()'s behavior

[白石俊平]

> I believe WebIDL says that a TypeError exception should be thrown, but it
> was not immediately obvious to me how to derive this from the spec.

Ok, I understood what behavior is correct (and that current webkit's
behavior is a bit wrong).

very thanks.

On Wed, Aug 12, 2009 at 5:34 PM, Ian Hickson wrote:
> On Wed, 12 Aug 2009, į~Y―į~_ģäŋ~Jåđģ wrote:
>>
>> and, when passed value is undefined (e.g. `setItem("key")`), which
>> behavior will be correct?
>> On current implementation of browsers, I looked as follows.
>> - IE and Firefox raise error, (arguments number is incorrect)
>> - Webkit family persist it as string ("undefined")
>
> I believe WebIDL says that a TypeError exception should be thrown, but it
> was not immediately obvious to me how to derive this from the spec.
>
>   http://dev.w3.org/2006/webapi/WebIDL/
>
> --
> Ian Hickson               U+1047E                )\._.,--,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Accessibility for Drag and Drop

[Ian Hickson]

On Mon, 3 Aug 2009, Aron Spohr wrote:
>
> It's the same case here. Just like with "'a' elements that have an href 
> attribute" we should also add "elements that have a draggable attribute 
> set to true" to the list of elements that "should be made focusable by 
> the user agent" at the bottom of section 7.5.1 of the spec. 

Fair enough. Added.


> Btw. there is no information on what criteria the qualification is made 
> for the elements in that "should" list in the spec. Maybe that should be 
> added as well.

I don't know what the qualifications would be. That's why it's a "should" 
and not a "must" with explicit exceptions.


> > The user agent can actually find where drops can occur by just acting 
> > as if the user had tried to drop everywhere. I'm not really sure how 
> > we could make an attribute work for this, since the model allows any 
> > element to be a drop target already.
>
> Fair enough. I thought it might come in handy some day to identify both 
> draggable elements as well as elements that can "receive" drops without 
> the use of scripting. E.g. in a parser or for search spiders to creater 
> indexes for that faster...

I don't disagree in principle, I just don't see how it could work given 
the model we have.

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

Re: [whatwg] question about Web Storage setItem()'s behavior

[Ian Hickson]

On Wed, 12 Aug 2009, �~Y��~_���~J平 wrote:
> 
> and, when passed value is undefined (e.g. `setItem("key")`), which
> behavior will be correct?
> On current implementation of browsers, I looked as follows.
> - IE and Firefox raise error, (arguments number is incorrect)
> - Webkit family persist it as string ("undefined")

I believe WebIDL says that a TypeError exception should be thrown, but it 
was not immediately obvious to me how to derive this from the spec.

   http://dev.w3.org/2006/webapi/WebIDL/

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

Re: [whatwg] question about Web Storage setItem()'s behavior

[白石俊平]

Thanks, Ian.

>> > --when value is null, should `setItem("key", null)` behave as like as
>> > `removeItem("key")`? (localStorage.setItem("key", null);
>> > alert(localStorage.length); <-- what is value displayed?)
>>
>> No, it's not the same as removeItem.  It'll be set to 'null'.
>
> This changed recently; it'll now actually store the null value.

OK, I see.

and, when passed value is undefined (e.g. `setItem("key")`), which
behavior will be correct?
On current implementation of browsers, I looked as follows.
- IE and Firefox raise error, (arguments number is incorrect)
- Webkit family persist it as string ("undefined")


On Wed, Aug 12, 2009 at 4:10 PM, Ian Hickson wrote:
> On Sun, 2 Aug 2009, Jeremy Orlow wrote:
>> On Sun, Aug 2, 2009 at 7:17 PM, 白石俊平  wrote:
>> >
>> > I'm implementing the HTML5 Web Storage using Gears
>> > (http://code.google.com/p/gear5/), so I have several questions with
>> > the spec.
>> >
>> > -Storage.setItem(key, val)
>> > --is key allowed non-string type object?
>>
>> Yes, but...
>>
>> --and when pass non-string object to key/value, is it automatically
>> > converted to string?(I'm considering to convert to use String
>> > constructor - String(key) )
>>
>> Yes.
>
> Correct.
>
>
>> > --when value is null, should `setItem("key", null)` behave as like as
>> > `removeItem("key")`? (localStorage.setItem("key", null);
>> > alert(localStorage.length); <-- what is value displayed?)
>>
>> No, it's not the same as removeItem.  It'll be set to 'null'.
>
> This changed recently; it'll now actually store the null value.
>
> --
> Ian Hickson               U+1047E                )\._.,--,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] BWTP for WebSocket transfer protocol

[Greg Wilkins]

Jonas Sicking wrote:

> I agree we should use the experiences from HTTP. However it seems like
> we have different experiences.
> 
> For example mime-types in HTTP have a very troubled record. Look at
> Adam Barth's draft [1] for what browsers are forced to do to stay
> compatible with the web. 

Indeed.  However I would argue that a lot of that problem is probably
the result of the initial HTTP protocol not supporting content types,
so that browsers started infering type from URL extensions etc.
So when a proper mime-mechanism was finally provided, it was too
late as bad practises were entrenched and remain so to this day.

I would hate to see a new protocol repeat this mistake and
start without support for content-types.

> And the problem keeps persisting, for example
> the newly deployed downloadable fonts support in firefox completely
> ignores mimetypes for fonts since no mime type exists for fonts. And
> with video the mimetype situation is very complicated since there's
> both a type of container, as well as type of encoding for video and
> audio inside that needs to be described. And potentially all three
> types can be independent.

There are indeed problems with mime, but I don't think the solution
will be found in not attempting to communicate metadata and thus
forcing sniffing or an assumption based systems as the only
solution.


> Similarly content negotiation is something I would say is even more
> doubtful that it has provided any value. 

I think I'm +1 on it's value and I certainly would not want to
propose something that would enforce any negotiate overheads.
However, having a protocol that allows meta-data does allow
simple negotiation if client/server choose to participate.


> So while I agree that we should look towards existing protocols, we do
> need to be honest about what has been successful and what hasn't, and
> not just assume that of existing protocols do something, it's a good
> idea.

I totally agree.

I think we should start with existing protocols, slice away the
capabilities that are not used and then build from there.

>> Example proposal to improve websocket protocol that
>> was rejected:
>>
>> Greg Wilkins wrote:
 It would be great if the websocket proposal could include
 standard definitions for mime encoded datagrams.

 Current frame types are:

   0x00  - sentinel framed UTF-8 message
   0x80  - length framed binary data.

 I'd like to see two additional frame types supported
 by default:

   0x01  - sentinel framed UTF-8 encoded MIME message
   0x81  - length framed MIME message.
 
> 
> If we want mime-support this seems like a good proposal. Except I
> don't understand the point of having the mime header optional? If
> someone wants to send something without a mimetype it seems like the
> other frame types cover that.

The mime head was not optional, it was just proposed that an empty
header (CRLFCRLF) would be legal.You don't really want to have to
be forced to change framing type just because you don't have any metadata

> I'm curious to hear what you consider the advantages of this over
> simply transmitting for example JSON over a "sentinel framed UTF-8
> message" frame? I.e. can you describe an application that would send
> JSON using the above proposal.

It would be difficult to transport some media types over
JSON on a sentinel framed UTF-8 message.   For example image/jpeg
would not be efficiently sent in JSON.

The meta-data is called meta because it is not part of the payload,
but is about the payload and thus different encodings and framing
are applied to meta data and data by protocols like HTTP (iso8859
CRLFCRLF terminated meta data then arbitrary length/close/chunk
terminated data).

Of course the 0x80 length framed binary data type could be
used to send mime encoded messages, but then there would need
to be other standards to work out what style of meta-data was
used - if at all.

But from a protocol point of view, I simply do not like the
favoured-son status given to UTF-8 messages.  What good is
knowing the character encoding if you don't know if the content
is XML or JSON?  Are we going to have to write sniffers to
look for XML, JSON, HTML content?

Why is utf-8 given it's own framing type (sentinels), when
the length framed binary framing is capable of carry the
messages just as efficiently and the sentinel framing fails
to support common transports such as gzipping etc.

I really think that the ws protocol started from some
assumptions that are just too special case for the javascript
API usage and that it will be easier to come up with new
clean protocols rather than push websocket protocol away
from the assumptions that underlay is basic design.


cheers

Re: [whatwg] HTMLOptionElement::value compatibility

[Ian Hickson]

On Mon, 3 Aug 2009, TAMURA, Kent wrote:
>
> The `value' DOM attribute of HTMLOptionElement is incompatible with the
> current major browsers.
> The spec says:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-option-value
> 
>   The disabled, label, and value DOM attributes must
> reflect
> the
> respective content
>   attributes of the same name.
> 
> However .value in IE8, Firefox3.5, Chrome2, Safari4, and Opera10b2 doesn't
> work so.  It returns the value of `value' HTML attribute, or the value of
> .text DOM attribute if the element doesn't have the `value' HTML attribute
> or the value of `value' HTML attribute is empty.  If we substitute a string
> to .value DOM attribute, the `value' HTML attribute is updated.
> 
> The spec should follow this behavior.

Thanks, fixed.

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

Re: [whatwg] BWTP for WebSocket transfer protocol

[Jonas Sicking]

On Tue, Aug 11, 2009 at 7:46 PM, Greg Wilkins wrote:
> Jonas Sicking wrote:
>> Can you suggest changes to the WS protocol that would make it a better
>> general-purpose protocol?
>
> There were several threads on the IETF HYBI mailing list with some such
> proposals:
>
>  http://www.ietf.org/mail-archive/web/hybi/current/maillist.html
>
> An example of such a message is at the bottom of this email.
> However, the response to such proposals was pretty much that
> they were too complex and not needed for the ws API.

I did follow that list somewhat, however to be honest the noise to
signal ratio was too low. A lot of suggestions/complaints just didn't
feel practical.

> It was the result of those interactions that suggested to me
> that a bidirectional web protocol would be best developed
> at arms length to the websocket API, and thus the BWTP
> effort was born.

I'm glad to see that.

> So far the feedback I have received on BWTP is suggesting
> that it has perhaps gone a little too far the other way
> and that there are probably some significant simplifications
> that can be achieved without greatly restricting the feature
> set.

That is my impression too.

>> You've suggested multiplexing, segmentation,
>> per-frame mime-type and per-frame meta-data so far. Is there anything
>> else that is needed? It would also be good to know what use cases you
>> have in mind for all of these features in order to evaluate them.
>
> Predicting the future is always hard, but using the present
> as an indicator is good start.
>
> Currently the majority of the web traffic is carried over HTTP
> which is capable of multiplexing, segmentation, per-frame mime-type
> and per-frame meta-data.
>
> I don't see why adding bidirectional capability should result in any
> significant reduction in these capabilities of web transports.
>
> For example, HTTP can well transport a vast array of content types
> with meta data support to negotiate accepted languages, types and
> encodings.
>
> The ws API can only handle UTF-8 text datagrams, so as a result
> the ws protocol has special case handling for UTF-8 text datagrams.
>
> So I think that our starting point should be to develop a
> bidirectional protocol that can well support the current web
> transport capabilities.   I would say that anybody
> who wishes to advocate a less capable transport should
> be ask to make the case of why capabilities should be
> lost with bidirectional protocols.

I agree we should use the experiences from HTTP. However it seems like
we have different experiences.

For example mime-types in HTTP have a very troubled record. Look at
Adam Barth's draft [1] for what browsers are forced to do to stay
compatible with the web. And the problem keeps persisting, for example
the newly deployed downloadable fonts support in firefox completely
ignores mimetypes for fonts since no mime type exists for fonts. And
with video the mimetype situation is very complicated since there's
both a type of container, as well as type of encoding for video and
audio inside that needs to be described. And potentially all three
types can be independent.

Similarly content negotiation is something I would say is even more
doubtful that it has provided any value. The only site where I can
remember seeing content negotiation actually used is on w3.org, an
organization that is safe can be considered experts on web standards.
However even here things immediately failed. When firefox started
claiming that we supported application/xml, several urls stopped
working since the browser was sent the XML file used to generate the
specification, rather than something that actually usefully could be
rendered.

Similarly, how many URLs have you seen that look like
http://something.com/.../feed?format=atom or format=rss, something
that content negotiation was supposed to handle.

I'm sure there are many sites that use content negotiation, and that
do so successfully. However given the trillion or so pages on the web,
could it really be said that content negotiation is something that's
used often enough to considered as a successful feature? I.e. was the
time spent specifying and implementing it really worth it? And are the
63 bytes of data that Firefox adds to each request well spent?

So while I agree that we should look towards existing protocols, we do
need to be honest about what has been successful and what hasn't, and
not just assume that of existing protocols do something, it's a good
idea.

[1] http://www.ietf.org/id/draft-abarth-mime-sniff-01.txt

> Example proposal to improve websocket protocol that
> was rejected:
>
> Greg Wilkins wrote:
>>> It would be great if the websocket proposal could include
>>> standard definitions for mime encoded datagrams.
>>>
>>> Current frame types are:
>>>
>>>   0x00  - sentinel framed UTF-8 message
>>>   0x80  - length framed binary data.
>>>
>>> I'd like to see two additional frame types supported
>>> by default:
>>>
>>>   0x01  - sentinel framed UTF-8 enco

Re: [whatwg] question about Web Storage setItem()'s behavior

[Ian Hickson]

On Sun, 2 Aug 2009, Jeremy Orlow wrote:
> On Sun, Aug 2, 2009 at 7:17 PM, 白石俊平  wrote:
> >
> > I'm implementing the HTML5 Web Storage using Gears
> > (http://code.google.com/p/gear5/), so I have several questions with
> > the spec.
> >
> > -Storage.setItem(key, val)
> > --is key allowed non-string type object?
> 
> Yes, but...
> 
> --and when pass non-string object to key/value, is it automatically
> > converted to string?(I'm considering to convert to use String
> > constructor - String(key) )
> 
> Yes.

Correct.


> > --when value is null, should `setItem("key", null)` behave as like as
> > `removeItem("key")`? (localStorage.setItem("key", null);
> > alert(localStorage.length); <-- what is value displayed?)
> 
> No, it's not the same as removeItem.  It'll be set to 'null'.

This changed recently; it'll now actually store the null value.

-- 
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

[Ian Hickson]

On Sun, 2 Aug 2009, Aryeh Gregor wrote:
>
> First, a general remark: what's the difference supposed to be between 
> "PASS" and "BUG"?  Firefox and WebKit are listed as PASS and BUG in 
> these two cases respectively, for instance:
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#interactions-with-xpath-and-xslt
>  
> http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#controlling-the-input-stream
> 
> The descriptions just say "passes all the available test cases for this 
> feature", and "has nearly complete support for this feature, but does 
> not yet pass all the relevant test cases".  But in both cases, it says 
> "Tests: 0".  I guess this is an error in the XPath/XSLT section, since 
> all the other parts with no tests list browsers as BUG rather than PASS?

Currently they're all just judgement calls currently; there aren't any 
tests listed for most features. Feel free to change the annotations if you 
feel they are wrong (alt+double-click a section to edit it's marker).


> In 3.2.3:
> 
> "This specification does not define what makes an HTTP-only cookie, and 
> at the time of publication the editor is not aware of any reference for 
> HTTP-only cookies. They are a feature supported by some Web browsers 
> wherein an "httponly" parameter added to the cookie string causes the 
> cookie to be hidden from script."
> 
> Why doesn't the spec define them?

Cookies are out of scope of the HTML5 spec. This is being discussed in the 
http-state mailing list.


> In 3.4.1.7:
> 
> "When a pointing device is clicked, the user agent must run these steps:
> 
> "1. Let e be the nearest activatable element of the element designated 
> by the user, if any.
> 
> "2. If there is an element e, run pre-click activation steps on it.
> 
> "3. Dispatching the required click event. . . ."
> 
> The third item's grammar doesn't match the first two.  Probably it 
> should be "Dispatch" instead of "Dispatching".

Fixed.


> In 3.5:
> 
> I'm not certain what the point of 3.5 is.  What agents are supposed to 
> keep track of paragraph boundaries, and what are they supposed to do 
> with them?  They don't affect the DOM or rendering as far as I can tell; 
> what do they affect?  Should browsers care about them? Conformance 
> checkers?  What should authors be aware of, other than not straddling 
> elements across paragraph boundaries?  (And why should they care about 
> that?  That's not clearly explained either.)

This section is just defining the semantics of text that is directly in 
flow elements other than  elements. It's only really theoretically 
useful for people doing semantic processing of HTML documents. In practice 
it's useful for people who have debates about what HTML documents mean.


> In 4.2.3:
> 
> "If there are multiple base elements with href attributes, all but the
> first are ignored."
> 
> "If there are multiple base elements with target attributes, all but
> the first are ignored."
> 
> Why are these notes, and not normative?  Do they duplicate normative
> requirements elsewhere?

Yes.


> In 4.2.4:
> 
> "If the attribute is present, then the user agent must assume that the
> resource is of the given type. If the attribute is omitted, but the
> external resource link type has a default type defined, then the user
> agent must assume that the resource is of that type."
> 
> Why "must" and not "should"?  Perhaps the user agent has some good
> reason to think the attribute is wrong.

Because otherwise we don't get interoperable behaviour. That kind of 
reasoning is how we ended up with the crazy content sniffing behaviour we 
have now, with its assorted security issues.


> In 4.6.1:
> 
> "suports" -> "supports"

Fixed.


> 4.6.11 and 4.6.12:
> 
> Most new elements in HTML 5 either add clear functionality (e.g.,
> ) or provide convenient styling hooks (e.g., ).
>  and  seem to do neither.  What's the point of these
> elements, from an author's perspective?  Or even from anyone's
> perspective?  What use cases do they fulfill?

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.


> In particular, it seems like authors would be reluctant to use 
>  and  if they couldn't style them.  I don't think 
> there's any obvious way to really control the styling of these controls 
> with CSS, so authors would be stuck with whatever color scheme and 
> general feel the UA happens to support.  That seems like it would look 
> ugly compared to manually-constructed elements that serve the same 
> purpose.

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