Re: [whatwg] notation for typographical uncertainty

[Brian Campbell]

On Sep 20, 2009, at 8:43 PM, ddailey wrote:


Ya'll probably have dealt with this already but here is the usage case

My son and I are are typing my recently deceased Dad's memoirs from  
the Manhattan project.


I'm saying to son: "if you can't figure out what it says, type the  
characters you are sure about. Use '?' marks for the letters that  
you aren't sure about."


 Ultimately this is ASCII with the most minimal of markup.

Question: what markup will be least cumbersome (and hence most  
recommended) within a plain text document that may ultimately be  
converted (automagically) to HTML5, assuming, in the meantime, that  
we may stoop so low as to put it in HTML4. I know folks claim HTML5  
will never break the web, but those folks and I have some beer to  
drink before we see eye to eye on that subject, having seen the web  
break so many times in the last 1.7 decades since I started playing  
with HTML at NCSA. Let us say I am a skeptic.

cheers
David


I'm rather confused about what your question is. Are you asking if you  
can use question marks as an ad-hoc markup for unknown characters?  
There's nothing in HTML5 that will break that usage, so that should be  
fine. But I don't think that there's been anything in the history of  
HTML that has gone so far as appropriating formerly legal characters  
for markup. Can you point to such an example?


Is there a particular form of breakage that you are trying to avoid?  
HTML5 does obsolete a few features, though none that I think should be  
relevant to the use case that you provided, and it documents how  
browsers must render obsolete features which have worked in the past,  
so that features being made obsolete does not break anything that  
already works. If you can find examples in the draft of this not being  
the case, you should probably point those out.


-- Brian

Re: [whatwg] document.head

[Garrett Smith]

On Sun, Sep 20, 2009 at 9:42 PM, Garrett Smith  wrote:
> On Sun, Sep 20, 2009 at 8:51 PM, Juriy Zaytsev  wrote:
>>
>> On Sep 20, 2009, at 10:29 PM, Garrett Smith wrote:
>>
>>> On Sun, Sep 20, 2009 at 2:47 PM, Michael A. Puls II
>>>  wrote:

 On Sun, 20 Sep 2009 16:15:11 -0400, Joseph Pecoraro 
 wrote:

> On Sep 20, 2009, at 3:57 PM, Michael A. Puls II wrote:
>>
>> I think it'd be cool to have to complement document.documentElement and
>> document.body.
>
> On Sep 20, 2009, at 4: 00PM, Juriy Zaytsev wrote:
>>

[...]

>> but HEAD was still reported as first child.
>>
>
> Wow, that's bizarre.
>
> Result:
> Opera 10, Chrome 2, Safari 4
> #comment, test1
> HEAD,
> #comment, test 2
> BODY,
>
> IE 5.5+, Firefox 3.5, Seamonkey 1.1
> HEAD,
> BODY,
>
> Blackberry Storm 9000
> #comment, test1
> HEAD,
> #comment, test 2
> BODY,
> #comment, test 3
>
>
> The first result seems nearly right, except for the last comment "test
> 3". I believe the Blackberry result is the correct one, though I can't
> cite a reference that backs this up.
>
> example document:

Ah, mistakenly posted different code than the results reflect.

The real example code used:





documentElement.childNodes

onload = function() {
  var childNodesArray = [],
  cn;
  var childNodes = document.documentElement.childNodes;
  for(var i = 0; i < childNodes.length; i++) {
cn = childNodes[i];
childNodesArray[i] = [cn.nodeName, cn.nodeValue||""];
  }
  document.body.firstChild.data = childNodesArray.join("\n");
};



-



- and the Browser running on the BlackBerry, is BlackBerry9000/4.6.x

Garrett

Re: [whatwg] document.head

[Garrett Smith]

On Sun, Sep 20, 2009 at 8:51 PM, Juriy Zaytsev  wrote:
>
> On Sep 20, 2009, at 10:29 PM, Garrett Smith wrote:
>
>> On Sun, Sep 20, 2009 at 2:47 PM, Michael A. Puls II
>>  wrote:
>>>
>>> On Sun, 20 Sep 2009 16:15:11 -0400, Joseph Pecoraro 
>>> wrote:
>>>
 On Sep 20, 2009, at 3:57 PM, Michael A. Puls II wrote:
>
> I think it'd be cool to have to complement document.documentElement and
> document.body.

 On Sep 20, 2009, at 4: 00PM, Juriy Zaytsev wrote:
>
> Surely better than abominable –
> `document.getElementsByTagName('head')[0]` :)

 I agree. Unfortunately that is the most popular method I've seen.  There
 are better solutions, but they haven't caught on.  I think a smarter
 idea
 would be to look at the children of the  element.  Something like
 this
 almost always works:

  var head = document.documentElement.firstChild
>>>
>>> It wasn't very long ago though that in Opera for example, head wasn't
>>> guaranteed to be the first child of the documentElement. But, that'll
>>> work
>>> now and is pretty good.
>>>
>>
>> The documentElement.firstChild cannot be expected to be head. It could
>> be a text node. For example:-
>>
>> 
>>  
>> ...
>>
>> the first child node of HTML looks like a textNode with the value
>> "\n\n\u0020\u0020".
>>
>> document.getElementsByTagName("head")[0] could be expected to produce
>> (in a valid HTML document) a result that is more consistent than
>> document.firstChild.
>
> That was exactly my thought when `firstChild` was mentioned here first time.
> I was suspecting IE to return textnode but couldn't reproduce it in either
> 6, 7 or 8. I also tried inserting comment in between:
>
> 
>  
>  
>  ...
>
> but HEAD was still reported as first child.
>

Wow, that's bizarre.

Result:
Opera 10, Chrome 2, Safari 4
#comment, test1
HEAD,
#comment, test 2
BODY,

IE 5.5+, Firefox 3.5, Seamonkey 1.1
HEAD,
BODY,

Blackberry Storm 9000
#comment, test1
HEAD,
#comment, test 2
BODY,
#comment, test 3


The first result seems nearly right, except for the last comment "test
3". I believe the Blackberry result is the correct one, though I can't
cite a reference that backs this up.

example document:





documentElement.childNodes

onload = function() {
  var childNodesArray = [];
  var childNodes = document.documentElement.childNodes;
  for(var i = 0; i < childNodes.length; i++) {
childNodesArray[i] = childNodes[i].nodeName;
  }
  document.body.firstChild.data = childNodesArray.join("\n");
};



-



Garrett

Re: [whatwg] document.head

[Juriy Zaytsev]

On Sep 20, 2009, at 10:29 PM, Garrett Smith wrote:


On Sun, Sep 20, 2009 at 2:47 PM, Michael A. Puls II
 wrote:
On Sun, 20 Sep 2009 16:15:11 -0400, Joseph Pecoraro >

wrote:


On Sep 20, 2009, at 3:57 PM, Michael A. Puls II wrote:


I think it'd be cool to have to complement  
document.documentElement and

document.body.


On Sep 20, 2009, at 4: 00PM, Juriy Zaytsev wrote:


Surely better than abominable –
`document.getElementsByTagName('head')[0]` :)


I agree. Unfortunately that is the most popular method I've seen.   
There
are better solutions, but they haven't caught on.  I think a  
smarter idea
would be to look at the children of the  element.  Something  
like this

almost always works:

  var head = document.documentElement.firstChild


It wasn't very long ago though that in Opera for example, head wasn't
guaranteed to be the first child of the documentElement. But,  
that'll work

now and is pretty good.



The documentElement.firstChild cannot be expected to be head. It could
be a text node. For example:-


  
...

the first child node of HTML looks like a textNode with the value
"\n\n\u0020\u0020".

document.getElementsByTagName("head")[0] could be expected to produce
(in a valid HTML document) a result that is more consistent than
document.firstChild.


That was exactly my thought when `firstChild` was mentioned here first  
time. I was suspecting IE to return textnode but couldn't reproduce it  
in either 6, 7 or 8. I also tried inserting comment in between:



  
  
  ...

but HEAD was still reported as first child.

FWIW, looking at HTML's DTD, it seems that HEAD and BODY tags should  
always be in this exact order - 


--
kangax

Re: [whatwg] document.head

[Joseph Pecoraro]

On Sep 20, 2009, at 10: 29PM, Garrett Smith wrote:
On Sun, 20 Sep 2009 16:15:11 -0400, Joseph Pecoraro >

Something like this almost always works:

  var head = document.documentElement.firstChild


The documentElement.firstChild cannot be expected to be head. It could
be a text node. For example:-


  
...

the first child node of HTML looks like a textNode with the value
"\n\n\u0020\u0020".

document.getElementsByTagName("head")[0] could be expected to produce
(in a valid HTML document) a result that is more consistent than
document.firstChild.



Even despite the white space, I got the  element in Safari,  
Firefox, and Opera.  But, you're absolutely right, I'm not saying my  
suggestion is bulletproof, only that it can be expected to perform far  
better!


However, I am interested in seeing a solution that is bulletproof and  
one that performs well!  Namely, "document.head".


Cheers,
- Joe

Re: [whatwg] document.head

[Garrett Smith]

On Sun, Sep 20, 2009 at 2:47 PM, Michael A. Puls II
 wrote:
> On Sun, 20 Sep 2009 16:15:11 -0400, Joseph Pecoraro 
> wrote:
>
>> On Sep 20, 2009, at 3:57 PM, Michael A. Puls II wrote:
>>>
>>> I think it'd be cool to have to complement document.documentElement and
>>> document.body.
>>
>> On Sep 20, 2009, at 4: 00PM, Juriy Zaytsev wrote:
>>>
>>> Surely better than abominable –
>>> `document.getElementsByTagName('head')[0]` :)
>>
>> I agree. Unfortunately that is the most popular method I've seen.  There
>> are better solutions, but they haven't caught on.  I think a smarter idea
>> would be to look at the children of the  element.  Something like this
>> almost always works:
>>
>>   var head = document.documentElement.firstChild
>
> It wasn't very long ago though that in Opera for example, head wasn't
> guaranteed to be the first child of the documentElement. But, that'll work
> now and is pretty good.
>

The documentElement.firstChild cannot be expected to be head. It could
be a text node. For example:-


   
...

the first child node of HTML looks like a textNode with the value
"\n\n\u0020\u0020".

document.getElementsByTagName("head")[0] could be expected to produce
(in a valid HTML document) a result that is more consistent than
document.firstChild.

Garrett
Garrett

Re: [whatwg] notation for typographical uncertainty

[Chris Cressman]

On Sun, Sep 20, 2009 at 8:43 PM, ddailey  wrote:
...
> Question: what markup will be least cumbersome (and hence most recommended)
> within a plain text document that may ultimately be converted
> (automagically) to HTML5, assuming, in the meantime, that we may stoop so
> low as to put it in HTML4. I know folks claim HTML5 will never break the
> web, but those folks and I have some beer to drink before we see eye to eye
> on that subject, having seen the web break so many times in the last 1.7
> decades since I started playing with HTML at NCSA. Let us say I am a
> skeptic.

W3C has published "HTML 5 differences from HTML 4" [1]. If I
understand your question, I think that document will be helpful,
particularly the sections on changed and absent elements/attributes.
Avoid the absent elements and review the changed elements and you
should be fine.

[1] http://www.w3.org/TR/html5-diff/

--
Chris Cressman
http://chriscressman.com

Re: [whatwg] document.head

[Jonas Sicking]

On Sun, Sep 20, 2009 at 2:47 PM, Michael A. Puls II
 wrote:
> On Sun, 20 Sep 2009 16:15:11 -0400, Joseph Pecoraro 
> wrote:
>
>> On Sep 20, 2009, at 3:57 PM, Michael A. Puls II wrote:
>>>
>>> I think it'd be cool to have to complement document.documentElement and
>>> document.body.
>>
>> On Sep 20, 2009, at 4: 00PM, Juriy Zaytsev wrote:
>>>
>>> Surely better than abominable –
>>> `document.getElementsByTagName('head')[0]` :)
>>
>> I agree. Unfortunately that is the most popular method I've seen.  There
>> are better solutions, but they haven't caught on.  I think a smarter idea
>> would be to look at the children of the  element.  Something like this
>> almost always works:
>>
>>   var head = document.documentElement.firstChild
>
> It wasn't very long ago though that in Opera for example, head wasn't
> guaranteed to be the first child of the documentElement. But, that'll work
> now and is pretty good.
>
> Yet, I still like document.head as it's shorter and it's more direct about
> what you're doing.
>
> I think I remember someone saying that Netscape (the somewhat recent, not
> too old versions) had support for document.head, for a little while at
> least. And, in HTML, head is pretty important.

Yup, another aspect is that I think we can promote correct usage of
HTML by making it as easy to put stuff into  as into  when
using the DOM.

/ Jonas

[whatwg] notation for typographical uncertainty

[ddailey]

Ya'll probably have dealt with this already but here is the usage case

My son and I are are typing my recently deceased Dad's memoirs from the 
Manhattan project.

I'm saying to son: "if you can't figure out what it says, type the characters 
you are sure about. Use '?' marks for the letters that you aren't sure about."

 Ultimately this is ASCII with the most minimal of markup.

Question: what markup will be least cumbersome (and hence most recommended) 
within a plain text document that may ultimately be converted (automagically) 
to HTML5, assuming, in the meantime, that we may stoop so low as to put it in 
HTML4. I know folks claim HTML5 will never break the web, but those folks and I 
have some beer to drink before we see eye to eye on that subject, having seen 
the web break so many times in the last 1.7 decades since I started playing 
with HTML at NCSA. Let us say I am a skeptic. 
cheers
David

Re: [whatwg] document.head

[Michael A. Puls II]

On Sun, 20 Sep 2009 16:15:11 -0400, Joseph Pecoraro   
wrote:



On Sep 20, 2009, at 3:57 PM, Michael A. Puls II wrote:
I think it'd be cool to have to complement document.documentElement and  
document.body.


On Sep 20, 2009, at 4: 00PM, Juriy Zaytsev wrote:
Surely better than abominable – `document.getElementsByTagName 
('head')[0]` :)


I agree. Unfortunately that is the most popular method I've seen.  There  
are better solutions, but they haven't caught on.  I think a smarter  
idea would be to look at the children of the  element.  Something  
like this almost always works:


   var head = document.documentElement.firstChild


It wasn't very long ago though that in Opera for example, head wasn't  
guaranteed to be the first child of the documentElement. But, that'll work  
now and is pretty good.


Yet, I still like document.head as it's shorter and it's more direct about  
what you're doing.


I think I remember someone saying that Netscape (the somewhat recent, not  
too old versions) had support for document.head, for a little while at  
least. And, in HTML, head is pretty important.


--
Michael

Re: [whatwg] document.head

[Juriy Zaytsev]

On Sep 20, 2009, at 5:20 PM, Joseph Pecoraro wrote:


On Sep 20, 2009, at 4: 24PM, Juriy Zaytsev wrote:

Speaking of `document.head`, I think Mootools does exactly that.



Good thinking.  I took a look at some JavaScript Libraries /  
Frameworks.  Here are some quick counts of how many times I could  
see that they use the "getElementsByTagName" method of getting the  
"head" element:


 - MooTools 1.2.3 has: 2
 - jQuery 1.3.2 has: 2
 - Ext 3.0.0 has: 5
 - YUI 3.0.0b1 has: >10
 - Prototype 1.6.1, MochiKit 1.4.2, Dojo 1.3.2 have: 0


There are none in Prototype.js simply because it is a rather small and  
low level library (I'm one of its core developers, btw). Libraries  
that use, say, "global eval" abstraction and/or dependency management  
(for scripts and styles) such as YUI obviously use HEAD more often  
(which your numbers confirm).


[...]

Re: [whatwg] document.head

[Yehuda Katz]

Yep! So what's the reason not to do it ;)
-- Yehuda

On Sun, Sep 20, 2009 at 2:20 PM, Joseph Pecoraro wrote:

> On Sep 20, 2009, at 4: 24PM, Juriy Zaytsev wrote:
>
>> Speaking of `document.head`, I think Mootools does exactly that.
>>
>
>
> Good thinking.  I took a look at some JavaScript Libraries / Frameworks.
>  Here are some quick counts of how many times I could see that they use the
> "getElementsByTagName" method of getting the "head" element:
>
>  - MooTools 1.2.3 has: 2
>  - jQuery 1.3.2 has: 2
>  - Ext 3.0.0 has: 5
>  - YUI 3.0.0b1 has: >10
>  - Prototype 1.6.1, MochiKit 1.4.2, Dojo 1.3.2 have: 0
>
> I am not making any criticism of the libraries.  I'm just re-enforcing the
> fact that it is a popular method of getting the "head" element, and adding
> document.head would be a worthwhile improvement.
>
> - Joe
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

Re: [whatwg] document.head

[Joseph Pecoraro]

On Sep 20, 2009, at 4: 24PM, Juriy Zaytsev wrote:

Speaking of `document.head`, I think Mootools does exactly that.



Good thinking.  I took a look at some JavaScript Libraries /  
Frameworks.  Here are some quick counts of how many times I could see  
that they use the "getElementsByTagName" method of getting the "head"  
element:


  - MooTools 1.2.3 has: 2
  - jQuery 1.3.2 has: 2
  - Ext 3.0.0 has: 5
  - YUI 3.0.0b1 has: >10
  - Prototype 1.6.1, MochiKit 1.4.2, Dojo 1.3.2 have: 0

I am not making any criticism of the libraries.  I'm just re-enforcing  
the fact that it is a popular method of getting the "head" element,  
and adding document.head would be a worthwhile improvement.


- Joe

Re: [whatwg] document.head

[Juriy Zaytsev]

On Sep 20, 2009, at 4:15 PM, Joseph Pecoraro wrote:


On Sep 20, 2009, at 3:57 PM, Michael A. Puls II wrote:
I think it'd be cool to have to complement document.documentElement  
and document.body.


On Sep 20, 2009, at 4: 00PM, Juriy Zaytsev wrote:
Surely better than abominable – `document.getElementsByTagName 
('head')[0]` :)


I agree. Unfortunately that is the most popular method I've seen.   
There are better solutions, but they haven't caught on.  I think a  
smarter idea would be to look at the children of the   
element.  Something like this almost always works:


 var head = document.documentElement.firstChild


Yep, I've seen that too. That's slightly better (i.e. less verbose)  
than `gEBTN` -based approach (although less descriptive too).


Speaking of `document.head`, I think Mootools does exactly that.

--
kangax

Re: [whatwg] document.head

[Joseph Pecoraro]

On Sep 20, 2009, at 3:57 PM, Michael A. Puls II wrote:
I think it'd be cool to have to complement document.documentElement  
and document.body.


On Sep 20, 2009, at 4: 00PM, Juriy Zaytsev wrote:
Surely better than abominable – `document.getElementsByTagName 
('head')[0]` :)


I agree. Unfortunately that is the most popular method I've seen.   
There are better solutions, but they haven't caught on.  I think a  
smarter idea would be to look at the children of the  element.   
Something like this almost always works:


  var head = document.documentElement.firstChild

- Joe

Re: [whatwg] document.head

[Juriy Zaytsev]

On Sep 20, 2009, at 3:57 PM, Michael A. Puls II wrote:

On Sun, 20 Sep 2009 14:22:38 -0400, Joseph Pecoraro > wrote:



Was there any discussion for including "document.head" in HTML5?


I think it'd be cool to have to complement document.documentElement  
and document.body.


Surely better than abominable – `document.getElementsByTagName('head') 
[0]` :)

Re: [whatwg] document.head

[Michael A. Puls II]

On Sun, 20 Sep 2009 14:22:38 -0400, Joseph Pecoraro   
wrote:



Was there any discussion for including "document.head" in HTML5?


I think it'd be cool to have to complement document.documentElement and  
document.body.


--
Michael

Re: [whatwg] behavior

[Michael A. Puls II]

On Sun, 20 Sep 2009 14:49:11 -0400, Boris Zbarsky  wrote:


On 9/18/09 6:35 PM, Michael A. Puls II wrote:

With  when
the page is parsed (or added to the document), what would happen?

Would it be something like this?:

1. Create the plug-in instance.

2. fetch file.swf

3. Give the file.swf stream to the plug-in when it requests it.

4. Fetch file.flv when the plug-in requests it

5. If autoplay, start playing the video (audio only since the 
isn't shown)


#5 is up to the plug-in; the browser doesn't do that part.


Understood.

What we should do in this case, imo, is instantiate the plug-in, tell it  
the data we have, tell it it's not being shown (has a null window in  
NPAPI terms), and let it do whatever it wants with that situation.  I  
believe Flash, in theory, pauses itself whenever its window is set to  
null.


O.K.


Or, would those optimizations not be triggered at all by display: none,
or would it depend on the plug-in or plug-in API or whatever the browser
feels like doing?


Depends on the plug-in and plug-in API, yes.


O.K.


In other words, if browsers make it so display: none doesn't prevent the
loading of a plug-in, does display: none still prevent the automatic
streaming of the file in @data by the browser


I'd think no (especially since you have to do the data load to even  
figure out whether the data is going to be handled by a plug-in to start  
with; right now given the markup in your example Gecko will do the HTTP  
GET on file.swf no matter what).



(for plug-ins, not native types like text/html)?


You don't know which it is until you've gotten at least the HTTP headers  
of the response (and possibly the first 512 bytes of the body, or  
whatever the content sniffing mechanism uses).



The reason I ask is that if existing web pages use multiple 's
that load videos for example, that are initially set to display: none
and only shown later, then if browsers start fetching all these files as
soon as the page loads


They already have to do that, and will continue to, because the HTTP  
headers from the response are needed to determine how to handle the  
data.  Right now they might just abort that load as soon as they  
discover that the data is being handled by a plug-in.  That's what Gecko  
does.


O.K. All that makes sense. You have to fetch to know what you've got. And,  
in the case of just  where there's no data to fetch until  
the plug-in decides what to do with the params it gets, the plug-in could  
do like you said above where it perhaps doesn't do anything or pauses  
while the window is null.


Note that aborting the load is sometimes a more expensive operation (in  
terms of affecting the loading of other content) than completing the  
load, depending on bandwidth, latency, and data size... The higher the  
latency, the higher the bandwidth, and the smaller the data, the more  
expensive canceling gets.  Amusingly enough, that means it's more  
expensive (holding data size constant) on your typical cell phone than  
on your typical home PC...


Interesting. Thanks very much.

O.K., so put simply, HTML5 should explicitly mention that the css display  
property for ,  (and  in the handling section) has  
absolutely no effect on plug-in instantiation and destroying and has  
absolutely no effect on @src and @data resource fetching.


HTML5 could also be extra clear by example that display: none doesn't  
destroy, or prevent the creation of, the plug-in instance and that  
changing the display value doesn't destroy the instance.


Lastly, HTML5 could briefly mention that what the plug-in does when its  
window/area is not displayed because of display: none, is plug-in and  
plug-in API dependent.


Then, anything else can be sorted out elsewhere like in the NPAPI spec  
amongst browser vendors.


Does that sound good? Is everyone else O.K. with this too? I don't think  
HTML5 should just imply the above by being silent about it.


It should briefly make good mention of it, imo. (Not those exact words,  
but something to that effect). (I don't currently see anything in the spec  
that covers this)


Thanks again.

--
Michael

Re: [whatwg] behavior

[Boris Zbarsky]

On 9/18/09 6:35 PM, Michael A. Puls II wrote:

With  when
the page is parsed (or added to the document), what would happen?

Would it be something like this?:

1. Create the plug-in instance.

2. fetch file.swf

3. Give the file.swf stream to the plug-in when it requests it.

4. Fetch file.flv when the plug-in requests it

5. If autoplay, start playing the video (audio only since the 
isn't shown)


#5 is up to the plug-in; the browser doesn't do that part.  What we 
should do in this case, imo, is instantiate the plug-in, tell it the 
data we have, tell it it's not being shown (has a null window in NPAPI 
terms), and let it do whatever it wants with that situation.  I believe 
Flash, in theory, pauses itself whenever its window is set to null.



Or, would those optimizations not be triggered at all by display: none,
or would it depend on the plug-in or plug-in API or whatever the browser
feels like doing?


Depends on the plug-in and plug-in API, yes.


In other words, if browsers make it so display: none doesn't prevent the
loading of a plug-in, does display: none still prevent the automatic
streaming of the file in @data by the browser


I'd think no (especially since you have to do the data load to even 
figure out whether the data is going to be handled by a plug-in to start 
with; right now given the markup in your example Gecko will do the HTTP 
GET on file.swf no matter what).



(for plug-ins, not native types like text/html)?


You don't know which it is until you've gotten at least the HTTP headers 
of the response (and possibly the first 512 bytes of the body, or 
whatever the content sniffing mechanism uses).



The reason I ask is that if existing web pages use multiple 's
that load videos for example, that are initially set to display: none
and only shown later, then if browsers start fetching all these files as
soon as the page loads


They already have to do that, and will continue to, because the HTTP 
headers from the response are needed to determine how to handle the 
data.  Right now they might just abort that load as soon as they 
discover that the data is being handled by a plug-in.  That's what Gecko 
does.  Note that aborting the load is sometimes a more expensive 
operation (in terms of affecting the loading of other content) than 
completing the load, depending on bandwidth, latency, and data size... 
The higher the latency, the higher the bandwidth, and the smaller the 
data, the more expensive canceling gets.  Amusingly enough, that means 
it's more expensive (holding data size constant) on your typical cell 
phone than on your typical home PC...


-Boris

[whatwg] document.head

[Joseph Pecoraro]

Was there any discussion for including "document.head" in HTML5?   
Searching the mailing list shows document.head show up a few times in  
example code [1][2].  However, there has been no proposal, and it is  
not mentioned in the document's IDL [3] in the Spec.


Developers often do the following to get a reference to the   
element (top 2 google results) [4]:


var head = document.getElementsByTagName('head')[0];

Its useful for developers to use that reference to manipulate/append  
stylesheets, scripts, and 

Re: [whatwg] the cite element

[Smylers]

Erik Vorhes writes:

> A use-case for "person's name" in the context of :
> 
> In reference to many Classical texts one will often refer to the
> author in lieu of the title (or in some cases that author's corpus).

That isn't an argument for people's names _in general_ being marked up;
it's an argument for marking them up in the specific case where they are
used as (nicknames of) titles of works.

> E.g.:
> 
> You should read Herodotus.

That's using "Herodotus" as the title of a work.  In many fields it's
common to refer to well-known works by nicknames, such as 'Smith &
Thomas', 'The Dragon Book', 'The Red Book', or 'The White Album'.  So
 should be used for them.

But it doesn't follow that  should be used for any other
occurrences of those terms -- the people Smith and Thomas, or a book
which just happens to be red.

Smylers

Re: [whatwg] the cite element

[Smylers]

Jim Jewett writes:

> In
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-September/023005.html,
> Ian quoted Erik Vorhes as writing:
> 
> > > Put another way, if you had no prior knowledge of the current
> > > HTML5 definition of  (and perhaps any other specification's
> > > definition of the element), what would seem to be logical and
> > > appropriate uses of the element?
> 
> Ian:
> > You mean based on just the element name? I wouldn't use it without
> > reading the spec first. Most people seem to think it means
> > "italics", though, for what that's worth.
> 
> I think that gets at the root of the problem with cite.  Most people
> don't read the spec, or even know where to find it.  cite isn't common
> enough to just copy by example, and it turns out to be ambiguous as
> the name of an element or attribute.

But why would somebody be in the situation where they encounter ,
want to use it, but aren't sure where?

Surely that's backwards?  Why would authors be trying to use elements
for the sake of them?

I'd expect the more usual sequence to be an author typing some text,
blissfully unaware of , then coming to the title of a book and
wanting it to be styled differently so as to convey that to users, and
looking for the element to use.

I don't think anybody's claiming that "cite" is a great name.  But it's
what we have.

> Do you wrap the actual excerpt (the precise thing you're citing), or
> the name of the source?

The name of the work is the part that readers typically have
distinguished to them.

> If you wrap the name/title of the source, is there a way to show the
> scope of what you're attributing?

Not in HTML5 (but possibly with a microformat specifically for that).
In what way do you envisage this being conveyed to or of use to users?

> My own interpretation of (a fraction of)
> http://philip.html5.org/data/cite.txt did not support narrowing the
> definition only to titles.

But in the cases where  is being used for things other than titles
of works, what does it achieve?  How do users benefit?

If authors are spending time on using an element which has no effect on
users (and Hixie's pointed out that in many cases where  is used
other than for titles of works authors use CSS to remove the default
italics, to ensure that users don't actually have the presence of the
 conveyed to them) then there's no reason for HTML5 to continue to
support it.

Rather it does authors a favour; they'll no longer have to spend time
doing something of no benefit.

> These do seem useful; if you wanted more information, it might well be
> "How do I contact this photographer or that model to get something
> similar?"

How does the use of  make that any easier for users than if, say,
 (or  or  or whatever) had been used instead?

Smylers

Re: [whatwg] fyi: Strict Transport Security specification

[Giorgio Maone]

Hi,

fwiw, NoScript 1.9.8.9 (next stable release, to be published during the 
incoming week), will support STS according to the current specification.


I had heard just yesterday from a leader Asian e-commerce player who 
wants to deploy it as soon as possible (even in the beginning of October).
I'm chatting with their security staff right now, and they're enthusiast 
of this development (especially of WebKit support).


Cheers
--
Giorgio Maone
http://hackademix.net
http://noscript.net

=JeffH wrote, On 20/09/2009 1.59:

Of possible interest to public-html@ & whatwg@ denizens...

[apologies for duplication]

--- Forwarded Message

Date:Fri, 18 Sep 2009 18:00:50 -0700
From:=JeffH 
To:  public-weba...@w3.org
cc:  Jeff Hodges ,
 Adam Barth ,
 Collin Jackson 
Subject: fyi: Strict Transport Security specification

Hi,

We wish to bring the following draft specification to your attention..

 Strict Transport Security (STS)



It specifies a refined approach to that described by Jackson and Barth 
in..


 ForceHTTPS: Protecting High-Security Web Sites from Network Attacks
 https://crypto.stanford.edu/forcehttps/


An experimental implementation of STS will be appearing in the Google 
Chrome

dev channel in the not-too-distant future..

 Google Chrome 4.0.211.0 (dev channel)


Sid Stamm (of Mozilla) has a Firefox extension presently implementing
an earlier revision of this specification (a soon-to-appear v2.0 of
the extension will implement the present spec version)..

 Force-TLS 1.0.3
 https://addons.mozilla.org/en-US/firefox/addon/12714

Sid also discusses this approach in this blog post..

 Locking up the valuables: Opt-in security with ForceTLS



We are interested in bringing this work to W3C WebApps Working Group as a
Recommendation-track specification. We are willing to license it under 
W3C
terms, we understand that it may change due to implementer or public 
feedback,

and that should it be of interest to other implementors, we're willing to
contribute to editorial and test suite efforts.

We're looking forward to the WebApps WG's feedback and comments.

Thanks,

=JeffH
PayPal InfoSec Team

Collin Jackson
Carnegie Mellon University

Adam Barth
University of California Berkeley

--- End of Forwarded Message