Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.

[Maciej Stachowiak]

On Oct 9, 2009, at 4:58 PM, Alex Russell wrote:

On Fri, Oct 9, 2009 at 11:21 AM, Julian Reschke  
 wrote:


True, but there is no real "X-" prefix convention for HTTP headers.

But, there is a registration procedure, defined in RFC 3864. It  
defines two
registries, a provisional, and a permanent. The latter (and only  
that)

requires:

  Registration of a new message header field starts with construction
  of a proposal that describes the syntax, semantics and intended use
  of the field.  For entries in the Permanent Message Header Field
  Registry, this proposal MUST be published as an RFC, or as an Open
  Standard in the sense described by RFC 2026, section 7 [1].

()

The HTML5 requirement goes further than the IETF requirement; I would
consider that a bug.


The more general point is that neither the spec nor the Validator
doesn't seem to be savvy to any of this. The request that we observe
the defacto "X-*" prefix is just a softer form of the general request
that the spec should not call headers that it doesn't understand
"invalid", casting documents that use them for compatibility reasons
into invalidity purgatory. I'd strongly prefer that the spec were
silent on un-specified values, noting instead that they should not
cause a document to become invalid, rather than carving out special
handling for one prefix.


HTML5 has a lot of extension points where, to make an extension valid,  
you have to provide an open standard specifying its behavior. The idea  
is that if you want something to be conforming, you have to specify it  
well enough to allow interoperable implementations. The design of X-UA- 
Compatible seems to make interoperability impractical. And I suspect  
Microsoft has no interest in specifying it in the form of an open  
standard. So making it noncomforming is serving the goals of the spec,  
just as using proprietary elements or attributes is nonconforming. You  
could question the goals, but they seem reasonable to me.


Regards,
Maciej

Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.

[Maciej Stachowiak]

On Oct 9, 2009, at 11:21 AM, Julian Reschke wrote:


True, but there is no real "X-" prefix convention for HTTP headers.

But, there is a registration procedure, defined in RFC 3864. It  
defines two registries, a provisional, and a permanent. The latter  
(and only that) requires:


  Registration of a new message header field starts with construction
  of a proposal that describes the syntax, semantics and intended use
  of the field.  For entries in the Permanent Message Header Field
  Registry, this proposal MUST be published as an RFC, or as an Open
  Standard in the sense described by RFC 2026, section 7 [1].

()

The HTML5 requirement goes further than the IETF requirement; I  
would consider that a bug.


I think the HTML5 requirement should be changed to allow any header in  
the Permanent Message Header Field Registry. Effectively, this would  
require either an RFC or an Open Standard. This seems just as good for  
HTML5's purposes as requiring an RFC.


Regards,
Maciej

Re: [whatwg] framesets

[Peter Brawley]

Edouard,

It seems you missed the start of this thread. One use case is 
coordinated browsing of a large database-driven tree in one scrollable 
subwindow and its nodes in another, under a header subwindow which 
(usually) has a tree search control which can direct the tree wubwindow 
to open & display down to the requested node. A frontend authentication 
page determines access to the page and optionally CRUD access to any 
combo of nodes. It must be possible to scroll either subwindow without 
affecting the other in any way. Tree & node subwindows to be editable 
and resizable. If a user does not have read access to a node, the node 
(and anything downstream from that node) is not visible to her. As in 
most standard database maintenance sites, data is not bookmarkable, so 
no tree node is bookmarkable, ie once the user comes in to read and/or 
manage the tree, the back button ignores all her tree moves & actions. 
In sum, the look and feel should resemble 
http://java.sun.com/javase/6/docs/api/?../technotes/guides/collections/index.html 
or 
http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp?topic=/com.ibm.wp.zos.doc/wps/dgn_navtree.html, 
plus (i) tree navigation should not add to the url stack and (ii) full 
CRUD must be supported for selected users.


A second use case is a questionnaire with a set of 600+ numbered yes-no 
answers in one xy-scrollable frame, an independently scrolling 
summary/stat info on that answer sheet, with the same rules as above, 
and optionally a third navigation/selection subwindow.


I searched the archives of this list for discussion of tree navigation & 
frames. I found Andrew Fedoniouk 
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html) 
saying "There are /use cases when frames are good/. As an example: 
online (and offline) help systems ...  In such cases /they provide level 
of usability higher than any other method of presenting content of such 
type./" That was what I too concluded from searching books & the web on 
the subject. Claims to the contrary made here are therefore surprising. 
I asked for examples of those claims, that the above specs can be met 
fully (i) with iframes (ii) without either frames or iframes. No-one 
pointed at an example that meets the spec fully. Closest is the MSDN 
site, which needs about ten times as much code as ours, and is tied to 
an OS. No thanks.


What's the justification? The above, plus data trees are increasingly 
important (eg see 
http://www.artfulsoftware.com/mysqlbook/sampler/mysqled1ch20.html), the 
interface needed to maintain them is as described, and such interfaces 
can be developed more cheaply & quickly on a web page with PHP than with 
desktop-oriented tools. The most straightforward way to implement that 
interface on a web page is the frameset (which might have a little 
something to do with why IBM and Sun use framesets to meet similar specs).


Framesets are commonly used to present trees and some other 
master-detail data structures. Removing the frameset from HTML5 is a 
mistake.


PB

-

Eduard Pascual wrote:

I have been following this discussion for many hours and it's getting
tiring. In addition, it doesn't seem to be leading anywhere; so please
let me suggest some ideas that may, at least, help it advance:

First: you have been asking for "counter-examples" (and you have been
given the MSDN one), but you haven't provided any specific example to
begin with. That would make a better starting point.

Second: you reject sound arguments claiming that "the use case
requires otherwise", but what's your use-case? Without clearly
specifying the use case, your arguments based on it aren't going to be
taken too seriously: they are basically based on nothing, until you
properly define the case they are supposedly based on. To specify a
use-case in a way that will be taken seriously by the editor and other
contributors:
- Clearly define the problem you are trying to solve. When doing so,
describe the problem in a way that is independent to the solution you
are proposing. For example, if you look on the archives, you'll see
that the use case for RDFa was often defined as "including RDF triples
on webpages": this didn't work because that's not the problem, RDF is
the solution. The same way, if you describe the need as "allowing
 on HTML5" you won't get anywhere: that's your own
suggestion to address the need, but which is the need?
Make sure that your use-case addresses real-world problems.
- Clearly specify and justify the requirements. Keep in mind that
"because the client wants it" is not enough justification; you'd need
to get an answer to "why does the client want it?". For example, if
someone hired me to build a web app that takes control of the users'
computer, I might come to the lists and ask for a feature to implement
that, based on the point that "the client wants it": that'd be
pointless and would go nowhere.

Third: once you have a well-defined use-case (or ideall

Re: [whatwg] framesets

[Eduard Pascual]

I have been following this discussion for many hours and it's getting
tiring. In addition, it doesn't seem to be leading anywhere; so please
let me suggest some ideas that may, at least, help it advance:

First: you have been asking for "counter-examples" (and you have been
given the MSDN one), but you haven't provided any specific example to
begin with. That would make a better starting point.

Second: you reject sound arguments claiming that "the use case
requires otherwise", but what's your use-case? Without clearly
specifying the use case, your arguments based on it aren't going to be
taken too seriously: they are basically based on nothing, until you
properly define the case they are supposedly based on. To specify a
use-case in a way that will be taken seriously by the editor and other
contributors:
- Clearly define the problem you are trying to solve. When doing so,
describe the problem in a way that is independent to the solution you
are proposing. For example, if you look on the archives, you'll see
that the use case for RDFa was often defined as "including RDF triples
on webpages": this didn't work because that's not the problem, RDF is
the solution. The same way, if you describe the need as "allowing
 on HTML5" you won't get anywhere: that's your own
suggestion to address the need, but which is the need?
Make sure that your use-case addresses real-world problems.
- Clearly specify and justify the requirements. Keep in mind that
"because the client wants it" is not enough justification; you'd need
to get an answer to "why does the client want it?". For example, if
someone hired me to build a web app that takes control of the users'
computer, I might come to the lists and ask for a feature to implement
that, based on the point that "the client wants it": that'd be
pointless and would go nowhere.

Third: once you have a well-defined use-case (or ideally, several
use-cases), you have a chance to get your proposal being taken
seriously. To do so, specify what you are proposing:
- State why currently existing solutions don't meet the requirements.
As far as this has gone, the only requirements that apparently aren't
met by  and other alternatives are the "break deep-linking"
and "break navigation" ones. Besides of the fact that you still need
to justify such requirements, that's actually easy to achieve with a
bit of ugly scripting.
- Describe your solution. State clearly how/why it meets each of the
requirements. Also, try to describe the specific changes required on
the spec.

If you manage to do that, your proposal will be definitely be taken
much more seriously.

Regards,
Eduard Pascual

Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.

[Alex Russell]

On Fri, Oct 9, 2009 at 11:21 AM, Julian Reschke  wrote:
> Alex Russell wrote:
>>
>> Howdy,
>>
>> As you may have heard, Google Chrome Frame is a plugin that helps web
>> authors target modern standards and renderer features. The current
>> mechanism for this switch is a value for an http-equiv meta tag, the
>> same mechanism which IE 8 introduced for helping authors ensure
>> renderer-level compatibility for content. The GCF team plans to
>> support HTTP headers with the same values in the near future [1]. As
>> currently specified, HTML 5 includes a list of pre-defined good values
>> for http-equiv [2] and specifies a pragma extensibility mechanism [3]
>> which predicates new entries on being registered HTTP headers from
>> duly submitted RFCs. This is onerous and does not fit well with
>> current network-level practice.
>>
>> RFC 2616 [4], section 6.2 provides a mechanism for coordinating
>> servers and clients to use extensions:
>>
>>   However, new or experimental header
>>   fields MAY be given the semantics of
>>   response-header fields if all parties in
>>   the communication recognize them to
>>   be response-header fields. Unrecognized
>>   header fields are treated as entity-header
>>   fields.
>> ...
>
> True, but there is no real "X-" prefix convention for HTTP headers.
>
> But, there is a registration procedure, defined in RFC 3864. It defines two
> registries, a provisional, and a permanent. The latter (and only that)
> requires:
>
>   Registration of a new message header field starts with construction
>   of a proposal that describes the syntax, semantics and intended use
>   of the field.  For entries in the Permanent Message Header Field
>   Registry, this proposal MUST be published as an RFC, or as an Open
>   Standard in the sense described by RFC 2026, section 7 [1].
>
> ()
>
> The HTML5 requirement goes further than the IETF requirement; I would
> consider that a bug.

The more general point is that neither the spec nor the Validator
doesn't seem to be savvy to any of this. The request that we observe
the defacto "X-*" prefix is just a softer form of the general request
that the spec should not call headers that it doesn't understand
"invalid", casting documents that use them for compatibility reasons
into invalidity purgatory. I'd strongly prefer that the spec were
silent on un-specified values, noting instead that they should not
cause a document to become invalid, rather than carving out special
handling for one prefix.

Regards

Re: [whatwg] framesets

[Peter Brawley]

Thomas,

>For example, compare:
>http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx
>with
http://java.sun.com/javase/6/docs/api/?../technotes/guides/collections/index.html
>(and note that this URL cannot be find in *any* link anywhere in the
>JavaDoc, and requires JavaScript to display the "The Collections
>Framework" page; while the MSDN page, even without JavaScript,
>correctly displays the "main content" and can still be navigated,
>though with highly degraded usability).
>See also 
>http://help.adobe.com/en_US/AS3LCR/Flash_10.0/?flash/accessibility/AccessibilityProperties.html&flash/accessibility/class-list.html

>(frames, same issue as JavaDoc, with the added possibility to control
>the "classList" frame's content; only discoverable if you read the
>JavaScript code in the frameset source)

Indeed. I prefer the Java & Sun framesets to the MSDN page, even if they 
pile up tree items in the url stack, but that's not the point. Nor is 
the point that a Microsoft maven might prefer the MSDN solution.


Quite apart from OS dependence issues, the points are (i) there are use 
cases for which the Java & Sun framesets are simple, correct solutions, 
and the MSDN solution is not, and (ii) revisions in standards ought not 
to render existing use-case-correct solutions unusable with other new 
features of the new standard.


PB

-


Thomas Broyer wrote:

On Fri, Oct 9, 2009 at 10:33 PM, Peter Brawley  wrote:
  

Boris,



use cases that the W3C wants to discourage ...
  

That W3C mindset promotes no greater good; it just imposes an idea of what
use cases should and shouldn't specify. Might as wellwrite popuo removal
into HTML5.



The use cases can still be addressed with  and a bit of pain if
resizing is desired, as far as I can tell.
  

I quoted Andrew Fedoniouk
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html),
"There are use cases when frames are good. As an example: online (and
offline) help systems ...  In such cases they provide level of usability
higher than any other method of presenting content of such type."



Usability of *HyperText* Markup Language involves being able to *link
to* the frameset as it is presented (which also means bookmarking).
Most users don't understand the concept of frames and don't understand
that when they bookmark a frameset (after having navigated within the
frames), what is bookmarked is not the "page" they were looking at
when they clicked the "bookmark this page" button.
While this can be made to work with JavaScript and (ab)using the #hash
part of the URL (à la AJAX applications' browser history
handling/management), it however is a usability issue with frames to
begin with.

  

I've not seen a counterexample. Have you?



I find MSDN as it is now much more usable than when it used frames,
even if that means that the treeview state (which subtree is
opened/closed) isn't preserves when navigating (but trees are not
"first class citizen" of web pages, they always involve JavaScript,
and in this case, localStorage or sessionStorage (or cookies, etc.)
could preserve the treeview state between pages; for the record,
 was an attempt to make data grids, and trees, become
first-class citizens, but it wasn't "stable" enough and has been
removed for Last Call).
For example, compare:
http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx
with
http://java.sun.com/javase/6/docs/api/?../technotes/guides/collections/index.html
(and note that this URL cannot be find in *any* link anywhere in the
JavaDoc, and requires JavaScript to display the "The Collections
Framework" page; while the MSDN page, even without JavaScript,
correctly displays the "main content" and can still be navigated,
though with highly degraded usability).

See also 
http://help.adobe.com/en_US/AS3LCR/Flash_10.0/?flash/accessibility/AccessibilityProperties.html&flash/accessibility/class-list.html
(frames, same issue as JavaDoc, with the added possibility to control
the "classList" frame's content; only discoverable if you read the
JavaScript code in the frameset source)


  

So this is all about assuming that the bit of pain will be enough of an
inconvenience
for authors that they will either address the use case in some way not
involving iframes
at all (and which presumably has a lower pain threshild; what is this way?)
  

As above, no-one seems able to point to a non-frameset solution.



It depends if you consider the MSDN a non-frameset solution to your
"problem"; but I guess you're very attached to the "doesn't affect
treeview state and scroll position" thing (which isn't impossible to
solve; see above)

IMO, your mysqlquerytree example would be better solved using AJAX
(and innerHTML to inject the retrieved "web parts"): no need for
sessions on the server-side –at least for the treeview state storage–,
which means a more "RESTful" approach, with caching made possible
(even if it is only Vary:Cookie/Cache-Con

Re: [whatwg] Some discrepencies and example remarks

[Tab Atkins Jr.]

On Fri, Oct 9, 2009 at 5:33 PM, Yuvalik Webdesign
 wrote:
>> From: Tab Atkins Jr.
>> > Also, a side-bar, what is that, since side-bars are usually
>> separately layed-out and not always directly "around the content".
>>
>> You're interpreting "around" too strictly here.  It means just
>> "nearby" here.  It means exactly what it says -  can be used
>> for marking up the sort of thing that you typically see in a sidebar
>> in magazines.  It is also useful for marking up the traditional
>> "sidebar content" of webpages, where there's a fairly narrow column to
>> the left or right of the main content containing tangential
>> information like blogrolls.
>
> So you are saying that  can be generally used as the smaller columns 
> on pages regardless of their contents, as long as it is somehow related to 
> the page (which obviously it is always)?

Yes.  If it's tangentially related (that is, it can be removed from
the document without affecting the meaning of the document), use
 (unless , , or  is more appropriate).

>> > C)
>> > When talking about outline (in the context of sectioning) I gather we
>> are NOT talking about the DOM-tree, but about (a Table Of) Contents
>> kind of outline. Does a generic page-header and footer (containing a
>> site-wide logo, style and navigation) belong in such an outline? If
>> not, does this mean it has to be enclosed in a separate SECTION
>> element? Nothing about this is made clear either in wording or
>> examples.
>>
>> The headings that may be contained in  belong in the outline,
>> and those are indicated simply by marking them up with , ,
>> etc.  Don't overthink it.  ^_^
>
> I think you misunderstand my point/question. A "page-header" (or 
> "page-footer") can consist of more than just semantic content and navigation. 
> It can consist of a logo, styling, non-related information (sometimes above 
> this header we have search boxes and login panels, etc. etc). Do these become 
> part of the  or is the  to become part of a  in such 
> cases? Also, if below a header with content we have a styled image (purely 
> for visual means) does this become part of the header or not? Where is the 
> line drawn? See also below.

The non-related stuff should be wrapped in s, and then can go
inside or outside the  - it shouldn't really matter.

Frex, in the header on http://www.igofigure.com (a site I control, but
that is currently HTML4), the two tag lines would be  and  in
an , the nav bar just below would be a , and everything
else would be s.  Just for styling convenience, I'd put them
all in the .

> Perhaps a small example, currently I am working on a site where content which 
> is generally regarded as a header, is placed as a sidebar on the lower right 
> of the page. It only contains a logo and a slideshow. Is this a  or 
> is this a ? I can give you several dozens of those questions.

If it's acting like the site header, then yeah, it should be .
 The slideshow is probably tangential, and would be in an .

> What I mean is, the spec doesn't give us examples other than those which are 
> obvious, it doesn't give us insight in more complex lay-outs. And once the 
> spec is ready and becomes used by others like me (which maybe less 
> insightfull than you are in the spec since we weren't so closely involved in 
> it) then those designers will be faced with questions the spec has no answers 
> for.

I meant it when I said you were overthinking things.  ^_^  Don't try
too hard; the categories are general and pretty simple.  As well, it's
not really expected that most authors will read the spec, but rather
that they'll read tutorials and examples on the web, which can go more
in depth about particular types of layouts.

~TJ

Re: [whatwg] framesets

[Peter Brawley]

Markus,

> I think that the discussion if or not there may be a use case where 
framesets are "good" is not the point.


We agree there, and I'd go further: declaring a mechanism for hiding 
intrapage links "bad" is an overreach, to put it mildly.


>So, if the people who discuss and define the HTML5 standard *do not 
like* framesets,

>it is IMO reason enough for them to take them out of this standard.

There we disagree. A main W3C responsibility is to facilitate the web. 
Removing a feature /which is used because use cases require it/ is 
destructive to the web by diminishing support for a required feature.


PB

-

Markus Ernst wrote:

Peter Brawley schrieb:

Eduard,

 >Everything that can be achieved with  can be done through
 >+.

If that's so, someone ought to be able to point at some examples.

I think that the discussion if or not there may be a use case where 
framesets are "good" is not the point.


Supposing that someone can produce examples, the argument for 
removing frames from HTML5 becomes: "frameset has been in HTML till 
now, /but is being removed because we do not like it/. If you insist 
on such use cases, re-architect them." That's a misuse of standards.


This is rather the point. There might be a use case where dictatorship 
is good - only a dictator might i.e. make laws to really protect the 
environment, which would not be possible in a democracy. There might 
even be a use case where chemical weapons are good - they might i.e. 
serve to fight a rat plague somewhere in a third-world country. Still 
we (well, I hope most of us) *do not like* dictatorship and chemical 
weapons. This is reason enough to try to contribute to a world where 
they are not wide-spread.


So, if the people who discuss and define the HTML5 standard *do not 
like* framesets, it is IMO reason enough for them to take them out of 
this standard. This will, as stated already by several posters, not 
prevent you from using a frameset to do something "good" with it, and 
you will be as safe as you are now, as UAs will support legacy content 
for the years to come.




No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: 10/09/09 08:10:00


  

Re: [whatwg] Some discrepencies and example remarks

[Yuvalik Webdesign]

> From: Tab Atkins Jr.
> > Also, a side-bar, what is that, since side-bars are usually
> separately layed-out and not always directly "around the content".
> 
> You're interpreting "around" too strictly here.  It means just
> "nearby" here.  It means exactly what it says -  can be used
> for marking up the sort of thing that you typically see in a sidebar
> in magazines.  It is also useful for marking up the traditional
> "sidebar content" of webpages, where there's a fairly narrow column to
> the left or right of the main content containing tangential
> information like blogrolls.

So you are saying that  can be generally used as the smaller columns on 
pages regardless of their contents, as long as it is somehow related to the 
page (which obviously it is always)?

> > C)
> > When talking about outline (in the context of sectioning) I gather we
> are NOT talking about the DOM-tree, but about (a Table Of) Contents
> kind of outline. Does a generic page-header and footer (containing a
> site-wide logo, style and navigation) belong in such an outline? If
> not, does this mean it has to be enclosed in a separate SECTION
> element? Nothing about this is made clear either in wording or
> examples.
> 
> The headings that may be contained in  belong in the outline,
> and those are indicated simply by marking them up with , ,
> etc.  Don't overthink it.  ^_^

I think you misunderstand my point/question. A "page-header" (or "page-footer") 
can consist of more than just semantic content and navigation. It can consist 
of a logo, styling, non-related information (sometimes above this header we 
have search boxes and login panels, etc. etc). Do these become part of the 
 or is the  to become part of a  in such cases? Also, if 
below a header with content we have a styled image (purely for visual means) 
does this become part of the header or not? Where is the line drawn? See also 
below.

> 
> > The spec is not very clear anywhere about styling practices (I know
> this is CSS' job, but within HTML the mark-up should at least be
> mentioned).
> 
> What do you mean here?  The Rendering section describes a default
> stylesheet that is recommended for normal visual UAs to employ.
> 
> > D)
> > All in all I would like to recommend, and I hope you will seriously
> consider, rewriting all the examples. Currently the examples are not
> representative of real-world cases. I suggest you find a collection of
> existing websites of all types (blog, webshop, social-site,
> educational, company-profile, application etc. etc.) and base your
> examples on that. Trying to show good and clear use cases and
> differences.
> 
> Can you give any examples?  I've been able to use the elements pretty
> usefully on my own pages based on spec text, especially since the last
> round of changes/clarifications.
> 

What I mean is that I can understand and read the spec when seen from a "pure" 
content point of view. A lot of information regarding the outline and how 
content is to be marked up. But very little in regard to the actual marking up 
of lay-out (which has less to do with content, but can still act as containers 
for content).

Perhaps a small example, currently I am working on a site where content which 
is generally regarded as a header, is placed as a sidebar on the lower right of 
the page. It only contains a logo and a slideshow. Is this a  or is 
this a ? I can give you several dozens of those questions.
What I mean is, the spec doesn't give us examples other than those which are 
obvious, it doesn't give us insight in more complex lay-outs. And once the spec 
is ready and becomes used by others like me (which maybe less insightfull than 
you are in the spec since we weren't so closely involved in it) then those 
designers will be faced with questions the spec has no answers for.

Again, this is no critique on the spec itself, just on the lack of more real 
and complex lay-out examples related to content mark-up.

Evert

Re: [whatwg] framesets

[Thomas Broyer]

On Fri, Oct 9, 2009 at 10:33 PM, Peter Brawley  wrote:
> Boris,
>
>> use cases that the W3C wants to discourage ...
>
> That W3C mindset promotes no greater good; it just imposes an idea of what
> use cases should and shouldn't specify. Might as wellwrite popuo removal
> into HTML5.
>
>> The use cases can still be addressed with  and a bit of pain if
>> resizing is desired, as far as I can tell.
>
> I quoted Andrew Fedoniouk
> (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html),
> "There are use cases when frames are good. As an example: online (and
> offline) help systems ...  In such cases they provide level of usability
> higher than any other method of presenting content of such type."

Usability of *HyperText* Markup Language involves being able to *link
to* the frameset as it is presented (which also means bookmarking).
Most users don't understand the concept of frames and don't understand
that when they bookmark a frameset (after having navigated within the
frames), what is bookmarked is not the "page" they were looking at
when they clicked the "bookmark this page" button.
While this can be made to work with JavaScript and (ab)using the #hash
part of the URL (à la AJAX applications' browser history
handling/management), it however is a usability issue with frames to
begin with.

> I've not seen a counterexample. Have you?

I find MSDN as it is now much more usable than when it used frames,
even if that means that the treeview state (which subtree is
opened/closed) isn't preserves when navigating (but trees are not
"first class citizen" of web pages, they always involve JavaScript,
and in this case, localStorage or sessionStorage (or cookies, etc.)
could preserve the treeview state between pages; for the record,
 was an attempt to make data grids, and trees, become
first-class citizens, but it wasn't "stable" enough and has been
removed for Last Call).
For example, compare:
http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx
with
http://java.sun.com/javase/6/docs/api/?../technotes/guides/collections/index.html
(and note that this URL cannot be find in *any* link anywhere in the
JavaDoc, and requires JavaScript to display the "The Collections
Framework" page; while the MSDN page, even without JavaScript,
correctly displays the "main content" and can still be navigated,
though with highly degraded usability).

See also 
http://help.adobe.com/en_US/AS3LCR/Flash_10.0/?flash/accessibility/AccessibilityProperties.html&flash/accessibility/class-list.html
(frames, same issue as JavaDoc, with the added possibility to control
the "classList" frame's content; only discoverable if you read the
JavaScript code in the frameset source)


>>So this is all about assuming that the bit of pain will be enough of an
>> inconvenience
>>for authors that they will either address the use case in some way not
>> involving iframes
>>at all (and which presumably has a lower pain threshild; what is this way?)
>
> As above, no-one seems able to point to a non-frameset solution.

It depends if you consider the MSDN a non-frameset solution to your
"problem"; but I guess you're very attached to the "doesn't affect
treeview state and scroll position" thing (which isn't impossible to
solve; see above)

IMO, your mysqlquerytree example would be better solved using AJAX
(and innerHTML to inject the retrieved "web parts"): no need for
sessions on the server-side –at least for the treeview state storage–,
which means a more "RESTful" approach, with caching made possible
(even if it is only Vary:Cookie/Cache-Control:private, it's still
better than server state), scalability improvements (less data –state–
kept on the server, less requests to the server –caching *and* the
fact that it's a one-page thing: once you've loaded a subtree, even if
you collapse and re-open it, you don't have to reload it–)
... just like the Google Document Reader (here showing the GWT 1.5 doc):
http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

Re: [whatwg] framesets

[Markus Ernst]

Peter Brawley schrieb:

Eduard,

 >Everything that can be achieved with  can be done through
 >+.

If that's so, someone ought to be able to point at some examples.

I think that the discussion if or not there may be a use case where 
framesets are "good" is not the point.


Supposing that someone can produce examples, the argument for removing 
frames from HTML5 becomes: "frameset has been in HTML till now, /but is 
being removed because we do not like it/. If you insist on such use 
cases, re-architect them." That's a misuse of standards.


This is rather the point. There might be a use case where dictatorship 
is good - only a dictator might i.e. make laws to really protect the 
environment, which would not be possible in a democracy. There might 
even be a use case where chemical weapons are good - they might i.e. 
serve to fight a rat plague somewhere in a third-world country. Still we 
(well, I hope most of us) *do not like* dictatorship and chemical 
weapons. This is reason enough to try to contribute to a world where 
they are not wide-spread.


So, if the people who discuss and define the HTML5 standard *do not 
like* framesets, it is IMO reason enough for them to take them out of 
this standard. This will, as stated already by several posters, not 
prevent you from using a frameset to do something "good" with it, and 
you will be as safe as you are now, as UAs will support legacy content 
for the years to come.

Re: [whatwg] Some discrepencies and example remarks

[Tab Atkins Jr.]

On Fri, Oct 9, 2009 at 12:12 PM, Yuvalik Webdesign
 wrote:
> B)
> It also says for ASIDE that:
> "The aside element represents a section of a page that consists of content 
> that is tangentially related to the content around the aside element, and 
> which could be considered separate from that content. Such sections are often 
> represented as sidebars in printed typography.
> The element can be used for typographical effects like pull quotes or 
> sidebars..."
>
> Isn't a pull-quote to be placed in a blockquote? (which is a sectioning root 
> if I am not mistaken?)

No, actual quotes as part of the content go in .
Pull-quotes are those things you see sometimes in magazine articles
where a particular quote that's already in the article is duplicated
and specially laid out for effect.

> Also, a side-bar, what is that, since side-bars are usually separately 
> layed-out and not always directly "around the content".

You're interpreting "around" too strictly here.  It means just
"nearby" here.  It means exactly what it says -  can be used
for marking up the sort of thing that you typically see in a sidebar
in magazines.  It is also useful for marking up the traditional
"sidebar content" of webpages, where there's a fairly narrow column to
the left or right of the main content containing tangential
information like blogrolls.

> Also, it says at the SECTION element:
> "When an element is needed for styling purposes or as a convenience for 
> scripting, authors are encouraged to use the div element instead."
>
> Does this only apply to SECTION, or also to ASIDE?

In general, if something exists for the sole purpose of scripting or
styling convenience, it should be  or .  The reason only
 mentions this specifically is because it has the thinnest
semantics - it just represents a segment of content, but indicates
that this segment is significant in the page outline.  The other
elements like  have sufficiently specific semantics that it's
less of a concern that they'll be misused for general
styling/scripting hooks.

> C)
> When talking about outline (in the context of sectioning) I gather we are NOT 
> talking about the DOM-tree, but about (a Table Of) Contents kind of outline. 
> Does a generic page-header and footer (containing a site-wide logo, style and 
> navigation) belong in such an outline? If not, does this mean it has to be 
> enclosed in a separate SECTION element? Nothing about this is made clear 
> either in wording or examples.

The headings that may be contained in  belong in the outline,
and those are indicated simply by marking them up with , ,
etc.  Don't overthink it.  ^_^

> The spec is not very clear anywhere about styling practices (I know this is 
> CSS' job, but within HTML the mark-up should at least be mentioned).

What do you mean here?  The Rendering section describes a default
stylesheet that is recommended for normal visual UAs to employ.

> D)
> I also find a lot of Notes that are phrased in such a way that they keep the 
> interpretation open for discussion.
> Things like "when it would make sense" or "other content that is considered 
> separate from the main content" or "content that is tangentially related" 
> etc. etc.
> In the real world these kinds of guidelines are open for discussion on a 
> per-situation basis. And may lead to mis-use of the elements.

That's really about as specific as you can get, though, or else you
risk lots of real-world stuff not fitting *any* definition.  The
misuse due to misinterpretation of these elements should hopefully be
minimal - if you have specific concerns/confusions about how
particular content should be marked up using the new elements, please
share!

> E)
> The TIME element, I know, I know. I followed that discussion and a lot has 
> been said about it. My main concern now is that the spec is still not clear 
> on how and where it can be used correctly.
> For example, marking up times and dates for historical documents... in the 
> discussion on this list it has been explicitly implied that this element is 
> NOT to be used for that, but in the spec I can still interpret the wording to 
> mean that I may.

If you can mark them up under the limitations on the content of
@datetime, more power to you.  The point of that section is to make
clear that marking up historical dates was *not* the primary use-case,
or even an auxiliary use-case, so you shouldn't be surprised if it
doesn't work out well (like if you end up with a date before 1AD that
can't be marked up with , while all your other dates are fine).

> D)
> All in all I would like to recommend, and I hope you will seriously consider, 
> rewriting all the examples. Currently the examples are not representative of 
> real-world cases. I suggest you find a collection of existing websites of all 
> types (blog, webshop, social-site, educational, company-profile, application 
> etc. etc.) and base your examples on that. Trying to show good and clear use 
> cases and differences.

Can y

Re: [whatwg] framesets

[Eduard Pascual]

On Fri, Oct 9, 2009 at 10:39 PM, Peter Brawley  wrote:
> Eduard,
>
>>Everything that can be achieved with  can be done through
>>+.
>
> If that's so, someone ought to be able to point at some examples.
I just got something even better [1]: it doesn't even use : it
goes away with s, CSS, and scripting.
+ would make things simpler, since the page would only
need to add a bit of script to handle the resizing.

> Supposing that someone can produce examples, the argument for removing
> frames from HTML5 becomes: "frameset has been in HTML till now, but is being
> removed because we do not like it. If you insist on such use cases,
> re-architect them." That's a misuse of standards.
That's not the argument. It would be something more like "frameset has
arisen several issues and doesn't solve anything that can't be solved
in a different way. If you insist on using frameset, just forget about
HTML5 validation."
After all, the only purpose of validation is to have a hint of
potential interoperability and accessibility issues. If you are using
, you should already be aware of the issues you might face,
so you don't need a validator to hint them to you.

>>What'd be the point of keeping two sources of issues when one can be
>>enough to cover all use-cases?
>
> If your premiss is correct, backward compatibility.
Backward compatibility is not handled at the language level, but at
the application level.  will not stop working: browsers will
keep handling it as they have until now. Leaving  out of the
spec only affects validation.
Furthermore, AFAIK it's entirely valid to have an HTML4 Frameset
doctype for a .html file, and refer from the  to files that
use the HTML5 doctype and new features. Since  has always
been intended to be used only from a "frameset page" or "master page",
what purpose would serve allowing them on a non-frameset doctype?
Furthermore, since HTML5 adds no features at all to , would
it make any sense to define a "HTML5 Frameset doctype"?

In summary: you can still use  as much as you want; and
trigger either "quirks" or "standard" mode on the client side. In
addition, if you manage properly your files and doctypes, you can even
have everything validating. What are you exactly asking for?

Regards,
Eduard Pascual

[1]: 
http://msdn.microsoft.com/en-us/library/system.windows.forms.htmldocument.aspx

Re: [whatwg] framesets

[Peter Brawley]

Brian,

>There are no switches that put the browser in HTML5 mode or anything 
like that;
>the only switch is based on whether you have one of a few given 
doctypes, which

>only affects whether you're put in quirks mode or in standards mode.

Why relegate a perfectly sound use case to a cul-de-sac? It would be 
better to add to frames standards such that they're simpler to use.


PB

-

Brian Campbell wrote:

On Oct 9, 2009, at 2:47 PM, Peter Brawley wrote:

I'm arguing that framesets have been part of HTML4, developers used 
them in good faith, and removing them from HTML5 unfairly & 
arbitrarily imposes a Hobson's choice of keeping existing 
functionality while foregoing new HTML5 functionality, or 
re-architecting existing functionality in order to use new HTML5 
functionality.


No, there is not choice you have to make. Framesets will still work in 
HTML5, they just won't allow you to validate. The page you cited, 
 already 
doesn't validate against HTML 4.01 (you are missing a doctype, and 
missing a title element), so I'm not sure why validation should 
suddenly matter. There are no features in HTML5 that are being 
withheld from pages which don't conform to the spec. There are no 
switches that put the browser in HTML5 mode or anything like that; the 
only switch is based on whether you have one of a few given doctypes, 
which only affects whether you're put in quirks mode or in standards 
mode.


-- Brian



No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: 10/09/09 08:10:00


  

Re: [whatwg] framesets

[Peter Brawley]

Eduard,

>Everything that can be achieved with  can be done through
>+.

If that's so, someone ought to be able to point at some examples.

Supposing that someone can produce examples, the argument for removing 
frames from HTML5 becomes: "frameset has been in HTML till now, /but is 
being removed because we do not like it/. If you insist on such use 
cases, re-architect them." That's a misuse of standards.


>What'd be the point of keeping two sources of issues when one can be
>enough to cover all use-cases?

If your premiss is correct, backward compatibility.

PB

--

Eduard Pascual wrote:

On Fri, Oct 9, 2009 at 10:17 PM, Peter Brawley  wrote:
  

So why *are*
frames banned, if you can easily replace them with iframes and get the
exact same lousy behavior?  Because iframes also have less evil uses,
and frames don't, I guess?
  

Designation of reasonable uses as "evil" is authoritarian nonsense.

PB



Both  and  are a source of several issues.
Everything that can be achieved with  can be done through
+.
What'd be the point of keeping two sources of issues when one can be
enough to cover all use-cases?
Since  can handle all the use-cases for , and some
that  just can't, it's obvious which one to drop.

Regards,
Eduard Pascual



No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: 10/09/09 08:10:00


  

Re: [whatwg] framesets

[Peter Brawley]

Boris,

> use cases that the W3C wants to discourage ...

That W3C mindset promotes no greater good; it just imposes an idea of 
what use cases should and shouldn't specify. Might as wellwrite popuo 
removal into HTML5.


> The use cases can still be addressed with  and a bit of pain 
if resizing is desired, as far as I can tell. 

I quoted Andrew Fedoniouk 
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html), 
"There are use cases when frames are good. As an example: online (and 
offline) help systems ...  In such cases they provide level of usability 
higher than any other method of presenting content of such type."


I've not seen a counterexample. Have you?

>So this is all about assuming that the bit of pain will be enough of 
an inconvenience
>for authors that they will either address the use case in some way not 
involving iframes
>at all (and which presumably has a lower pain threshild; what is this 
way?)


As above, no-one seems able to point to a non-frameset solution.

>or not address
>the use case at all (unlikely, since they're being paid to address it). 


IMO money has no place in this discussion.

> Since UAs must continue supporting framesets anyway, the reasoning 
behind removing them seems somewhat weak to me.


Yes.

PB

-

Boris Zbarsky wrote:

On 10/9/09 2:55 PM, Peter Brawley wrote:

Framesets are part of the current HTML standard and should remain.


This isn't really a convincing argument.  There are various other 
things that are part of HTML 4.01 that are worth removing and have 
been removed.


That said, I'm not sure why there's a worry about what's in the 
standard given the 
http://www.artfulsoftware.com/infotree/mysqlquerytree.php example 
(which doesn't actually validate per the HTML 4.01 standard, since 
it's missing a doctype).


On a general note, though, the reasoning behind removing framesets 
seems to be that they make it very easy to address specific authoring 
use cases that the W3C wants to discourage, right?  The use cases can 
still be addressed with  and a bit of pain if resizing is 
desired, as far as I can tell.  So this is all about assuming that the 
bit of pain will be enough of an inconvenience for authors that they 
will either address the use case in some way not involving iframes at 
all (and which presumably has a lower pain threshild; what is this 
way?) or not address the use case at all (unlikely, since they're 
being paid to address it).  Since UAs must continue supporting 
framesets anyway, the reasoning behind removing them seems somewhat 
weak to me.


-Boris



No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: 10/09/09 08:10:00


  

Re: [whatwg] framesets

[Eduard Pascual]

On Fri, Oct 9, 2009 at 10:17 PM, Peter Brawley  wrote:
>>So why *are*
>>frames banned, if you can easily replace them with iframes and get the
>>exact same lousy behavior?  Because iframes also have less evil uses,
>>and frames don't, I guess?
>
> Designation of reasonable uses as "evil" is authoritarian nonsense.
>
> PB

Both  and  are a source of several issues.
Everything that can be achieved with  can be done through
+.
What'd be the point of keeping two sources of issues when one can be
enough to cover all use-cases?
Since  can handle all the use-cases for , and some
that  just can't, it's obvious which one to drop.

Regards,
Eduard Pascual

Re: [whatwg] framesets

[Yuvalik Webdesign]

> From: Peter Brawley
> Designation of reasonable uses as "evil" is authoritarian nonsense.

Sorry to break into the discussion, but as pointed out, you can still use 
frames if you want to. The way I see it you have three choices:

1) Keep using HTML4
2) Loose the frames and use HTML5
3) Use HTML5 but also keep using the HTML4 frames

Now, option 3 might sound silly, but you could always say that part of your 
pages validate in HTML4 and the other part in HTML5. In essence, the validators 
tell you nothing about how your pages behave in browsers, and as long as your 
code is sound (which doesn't have to be valid mind you) it will render 
perfectly, and will continue to do so for a very long time I suspect.

Now I am not advocating such a course of action, but I could see how it would 
benefit in certain situations. Keep in mind that the only authority the 
spec-writers have is over the spec itself, not over your use of it.

Evert

Re: [whatwg] framesets

[Peter Brawley]

So why *are*
frames banned, if you can easily replace them with iframes and get the
exact same lousy behavior?  Because iframes also have less evil uses,
and frames don't, I guess?


Designation of reasonable uses as "evil" is authoritarian nonsense.

PB

-



Aryeh Gregor wrote:

On Fri, Oct 9, 2009 at 2:47 PM, Peter Brawley  wrote:
  

Right, the point is that the use case specifies tree navigation to be
entirely independent of navigation to and from the page, that tree and
detail subwindows be independently scrollable & resizable, and that tree
nodes not be externally linkable. The response that the client ought not to
want this is, well, beyond W3C's brief.



This is actually the WHATWG list, not the W3C.  But in any case, both
organizations think it's completely appropriate for them to pressure
authors to avoid bad features.  I guess you can feel free to argue
that they shouldn't, but I don't think you'll convince them.

  

I'm arguing that framesets have been part of HTML4, developers used them in
good faith, and removing them from HTML5 unfairly & arbitrarily imposes a
Hobson's choice of keeping existing functionality while foregoing new HTML5
functionality, or re-architecting existing functionality in order to use new
HTML5 functionality.



You aren't *forced*.  You can make a document that uses both frames
and HTML5 features.  It will work, it's just not valid HTML5.

On Fri, Oct 9, 2009 at 2:55 PM, Peter Brawley  wrote:
  

It's not your brief to decide what's beneficial for a client.



As defined by who?  For instance, the W3C's mission is "To lead the
World Wide Web to its full potential by developing protocols and
guidelines that ensure long-term growth for the Web."
  That includes prohibiting things it
considers harmful.

  

You are arguing for imposing one way of doing things. Ugh.



Well, yes.  The WHATWG and W3C are standards bodies.  Standards are,
by definition, things that impose one way of doing things.

On Fri, Oct 9, 2009 at 2:57 PM, Boris Zbarsky  wrote:
  

I don't see how they wouldn't.  Everything you can accomplish with
 and  you can do with  plus gobs of javascript to
make the drag-resizing work (probably badly, unlike the UA-provided resizing
for ), no?  Oh, and more hacks to get the initial sizing right and
such, of course...



Ah, I didn't understand how navigation in iframes works.  So why *are*
frames banned, if you can easily replace them with iframes and get the
exact same lousy behavior?  Because iframes also have less evil uses,
and frames don't, I guess?



No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: 10/09/09 08:10:00


  

Re: [whatwg] framesets

[Jonas Sicking]

On Fri, Oct 9, 2009 at 12:13 PM, Aryeh Gregor  wrote:
> On Fri, Oct 9, 2009 at 2:57 PM, Boris Zbarsky  wrote:
>> I don't see how they wouldn't.  Everything you can accomplish with
>>  and  you can do with  plus gobs of javascript to
>> make the drag-resizing work (probably badly, unlike the UA-provided resizing
>> for ), no?  Oh, and more hacks to get the initial sizing right and
>> such, of course...
>
> Ah, I didn't understand how navigation in iframes works.  So why *are*
> frames banned, if you can easily replace them with iframes and get the
> exact same lousy behavior?  Because iframes also have less evil uses,
> and frames don't, I guess?

The big difference is that s can be used in good ways,
framesets essentially can't.

Another reason do deprecate  but not  is that we
don't need *two* ways to make poorly behaving pages.

/ Jonas

Re: [whatwg] framesets

[Brian Campbell]

On Oct 9, 2009, at 2:47 PM, Peter Brawley wrote:

I'm arguing that framesets have been part of HTML4, developers used  
them in good faith, and removing them from HTML5 unfairly &  
arbitrarily imposes a Hobson's choice of keeping existing  
functionality while foregoing new HTML5 functionality, or re- 
architecting existing functionality in order to use new HTML5  
functionality.


No, there is not choice you have to make. Framesets will still work in  
HTML5, they just won't allow you to validate. The page you cited,  already doesn't validate against HTML 4.01 (you are missing a  
doctype, and missing a title element), so I'm not sure why validation  
should suddenly matter. There are no features in HTML5 that are being  
withheld from pages which don't conform to the spec. There are no  
switches that put the browser in HTML5 mode or anything like that; the  
only switch is based on whether you have one of a few given doctypes,  
which only affects whether you're put in quirks mode or in standards  
mode.


-- Brian

Re: [whatwg] framesets

[Boris Zbarsky]

On 10/9/09 2:55 PM, Peter Brawley wrote:

Framesets are part of the current HTML standard and should remain.


This isn't really a convincing argument.  There are various other things 
that are part of HTML 4.01 that are worth removing and have been removed.


That said, I'm not sure why there's a worry about what's in the standard 
given the http://www.artfulsoftware.com/infotree/mysqlquerytree.php 
example (which doesn't actually validate per the HTML 4.01 standard, 
since it's missing a doctype).


On a general note, though, the reasoning behind removing framesets seems 
to be that they make it very easy to address specific authoring use 
cases that the W3C wants to discourage, right?  The use cases can still 
be addressed with  and a bit of pain if resizing is desired, as 
far as I can tell.  So this is all about assuming that the bit of pain 
will be enough of an inconvenience for authors that they will either 
address the use case in some way not involving iframes at all (and which 
presumably has a lower pain threshild; what is this way?) or not address 
the use case at all (unlikely, since they're being paid to address it). 
 Since UAs must continue supporting framesets anyway, the reasoning 
behind removing them seems somewhat weak to me.


-Boris

Re: [whatwg] framesets

[Aryeh Gregor]

On Fri, Oct 9, 2009 at 2:47 PM, Peter Brawley  wrote:
> Right, the point is that the use case specifies tree navigation to be
> entirely independent of navigation to and from the page, that tree and
> detail subwindows be independently scrollable & resizable, and that tree
> nodes not be externally linkable. The response that the client ought not to
> want this is, well, beyond W3C's brief.

This is actually the WHATWG list, not the W3C.  But in any case, both
organizations think it's completely appropriate for them to pressure
authors to avoid bad features.  I guess you can feel free to argue
that they shouldn't, but I don't think you'll convince them.

> I'm arguing that framesets have been part of HTML4, developers used them in
> good faith, and removing them from HTML5 unfairly & arbitrarily imposes a
> Hobson's choice of keeping existing functionality while foregoing new HTML5
> functionality, or re-architecting existing functionality in order to use new
> HTML5 functionality.

You aren't *forced*.  You can make a document that uses both frames
and HTML5 features.  It will work, it's just not valid HTML5.

On Fri, Oct 9, 2009 at 2:55 PM, Peter Brawley  wrote:
> It's not your brief to decide what's beneficial for a client.

As defined by who?  For instance, the W3C's mission is "To lead the
World Wide Web to its full potential by developing protocols and
guidelines that ensure long-term growth for the Web."
  That includes prohibiting things it
considers harmful.

> You are arguing for imposing one way of doing things. Ugh.

Well, yes.  The WHATWG and W3C are standards bodies.  Standards are,
by definition, things that impose one way of doing things.

On Fri, Oct 9, 2009 at 2:57 PM, Boris Zbarsky  wrote:
> I don't see how they wouldn't.  Everything you can accomplish with
>  and  you can do with  plus gobs of javascript to
> make the drag-resizing work (probably badly, unlike the UA-provided resizing
> for ), no?  Oh, and more hacks to get the initial sizing right and
> such, of course...

Ah, I didn't understand how navigation in iframes works.  So why *are*
frames banned, if you can easily replace them with iframes and get the
exact same lousy behavior?  Because iframes also have less evil uses,
and frames don't, I guess?

Re: [whatwg] framesets

[Boris Zbarsky]

On 10/9/09 2:19 PM, Aryeh Gregor wrote:

I don't see how iframes would allow you to deliberately mess up
navigation in the same way as frames do.


I don't see how they wouldn't.  Everything you can accomplish with 
 and  you can do with  plus gobs of javascript 
to make the drag-resizing work (probably badly, unlike the UA-provided 
resizing for ), no?  Oh, and more hacks to get the initial 
sizing right and such, of course...


-Boris

Re: [whatwg] framesets

[Peter Brawley]

Aryeh,

>I don't see why that's beneficial.

It's not your brief to decide what's beneficial for a client.

>It conflicts with expected
>behavior.

It does not conflict with what these users expect.

> If you follow a link and then click "back", your
>link-following should be undone. You shouldn't be taken to a totally
>different page that you left half an hour ago.

You are arguing for imposing one way of doing things. Ugh.

>That's not how the W3C or the WHATWG or any standards bodies operate.
>If you want a feature in HTML5, you have to argue that it would help
>the web to support it, not just that some authors want it.

Framesets are part of the current HTML standard and should remain.

PB

-

Aryeh Gregor wrote:

On Fri, Oct 9, 2009 at 1:47 PM, Peter Brawley  wrote:
  

It suggests no such thing. Your "suggestion", applied to surgery, would be
that primum non nocere implies surgery should never remove hurt or remove
useful tissue. The inference is overinclusive, to put it mildly. W3C's job
is to enable, not function like a commissariat.



The W3C's and WHATWG's jobs are to make standards that promote the
overall health of the web.  This isn't always compatible with allowing
all authors to do everything they want.  To take a more clear-cut
example, a lot of authors would like to be able to stop users from
downloading videos.   deliberately doesn't try to support this
use-case, because it's viewed as harmful.  So those authors will have
to hack up solutions using Flash or JavaScript or whatever, or else
give up and allow it.

Of course, no one actually has to follow the standards.  You can still
use frames.  Your page just won't validate.  If you think the W3C and
WHATWG are commissariats, this shouldn't worry you, since all it says
is your page doesn't follow what the W3C and/or WHATWG say.

  

These are not external links. You want these pages to make each item
externally linkable. The client does not. The client wins this debate hands
down.



That's not how the W3C or the WHATWG or any standards bodies operate.
If you want a feature in HTML5, you have to argue that it would help
the web to support it, not just that some authors want it.  Your
current arguments are very unlikely to get the spec changed (although
I don't have any say in that).

Users of a site using frames will have a worse experience, because
features like link-sharing and bookmarking won't work.  You've said
that you would *like* these features not to work.  Why, exactly?  This
kind of degradation needs to be justified.

  

Already explained. So that a user may enter and exit the frameset as one page



I don't see why that's beneficial.  It conflicts with expected
behavior.  If you follow a link and then click "back", your
link-following should be undone.  You shouldn't be taken to a totally
different page that you left half an hour ago.

On Fri, Oct 9, 2009 at 2:09 PM, Thomas Broyer  wrote:
  

Framesets, iframes, AJAX+innerHTML all allow this; you can't present
this as an argument for frameset or against their removal



I don't see how iframes would allow you to deliberately mess up
navigation in the same way as frames do.  AJAX would, and does, but
that's a lot harder for authors to implement, so asking for an easier
way seems legitimate.



No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: 10/09/09 08:10:00


  

Re: [whatwg] framesets

[Peter Brawley]

Thomas,

>Framesets, iframes, AJAX+innerHTML all allow this; you can't present
>this as an argument for frameset or against their removal (though,
>actually, I think you didn't, and the discussion just wen this road

Right, the point is that the use case specifies tree navigation to be 
entirely independent of navigation to and from the page, that tree and 
detail subwindows be independently scrollable & resizable, and that tree 
nodes /not/ be externally linkable. The response that the client ought 
not to want this is, well, beyond W3C's brief.


>you could just use iframes too to the same effect,
>except frame resizing, that would need some additional scripting; did
>I adequately describe your argument here?)

I've been looking, but I've not seen an adequate iframe implementation 
of this spec.


I'm arguing that framesets have been part of HTML4, developers used them 
in good faith, and removing them from HTML5 unfairly & arbitrarily 
imposes a Hobson's choice of keeping existing functionality while 
foregoing new HTML5 functionality, or re-architecting existing 
functionality in order to use new HTML5 functionality.


PB

-


Thomas Broyer wrote:

On Fri, Oct 9, 2009 at 7:47 PM, Peter Brawley  wrote:
  

A design goal of this use case is to isolate individual framed items from
URL back/forward/history.external linking. Analagous to watching a picture
show where selecting N pictures does not commit you to hitting the Back
button N times to get back out.


Why shouldn't it?
  

Because the use case demands otherwise.



It's how all other links work. Behavior should be consistent.
  

These are not external links. You want these pages to make each item
externally linkable. The client does not. The client wins this debate hands
down.



Framesets, iframes, AJAX+innerHTML all allow this; you can't present
this as an argument for frameset or against their removal (though,
actually, I think you didn't, and the discussion just wen this road
while the use case you were showing is that clicking on a link in any
frame, that loads a new doc within this same frame doesn't have any
side effect on the other frames; for instance, you do not "lose" your
scroll position in the other frames, MSDN doesn't behave exactly the
same here; though you could just use iframes too to the same effect,
except frame resizing, that would need some additional scripting; did
I adequately describe your argument here?)


  




No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: 10/09/09 08:10:00


  

Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.

[Julian Reschke]

Alex Russell wrote:

Howdy,

As you may have heard, Google Chrome Frame is a plugin that helps web
authors target modern standards and renderer features. The current
mechanism for this switch is a value for an http-equiv meta tag, the
same mechanism which IE 8 introduced for helping authors ensure
renderer-level compatibility for content. The GCF team plans to
support HTTP headers with the same values in the near future [1]. As
currently specified, HTML 5 includes a list of pre-defined good values
for http-equiv [2] and specifies a pragma extensibility mechanism [3]
which predicates new entries on being registered HTTP headers from
duly submitted RFCs. This is onerous and does not fit well with
current network-level practice.

RFC 2616 [4], section 6.2 provides a mechanism for coordinating
servers and clients to use extensions:

   However, new or experimental header
   fields MAY be given the semantics of
   response-header fields if all parties in
   the communication recognize them to
   be response-header fields. Unrecognized
   header fields are treated as entity-header
   fields.
...


True, but there is no real "X-" prefix convention for HTTP headers.

But, there is a registration procedure, defined in RFC 3864. It defines 
two registries, a provisional, and a permanent. The latter (and only 
that) requires:


   Registration of a new message header field starts with construction
   of a proposal that describes the syntax, semantics and intended use
   of the field.  For entries in the Permanent Message Header Field
   Registry, this proposal MUST be published as an RFC, or as an Open
   Standard in the sense described by RFC 2026, section 7 [1].

()

The HTML5 requirement goes further than the IETF requirement; I would 
consider that a bug.


BR, Julian

Re: [whatwg] framesets

[Aryeh Gregor]

On Fri, Oct 9, 2009 at 1:47 PM, Peter Brawley  wrote:
> It suggests no such thing. Your "suggestion", applied to surgery, would be
> that primum non nocere implies surgery should never remove hurt or remove
> useful tissue. The inference is overinclusive, to put it mildly. W3C's job
> is to enable, not function like a commissariat.

The W3C's and WHATWG's jobs are to make standards that promote the
overall health of the web.  This isn't always compatible with allowing
all authors to do everything they want.  To take a more clear-cut
example, a lot of authors would like to be able to stop users from
downloading videos.   deliberately doesn't try to support this
use-case, because it's viewed as harmful.  So those authors will have
to hack up solutions using Flash or JavaScript or whatever, or else
give up and allow it.

Of course, no one actually has to follow the standards.  You can still
use frames.  Your page just won't validate.  If you think the W3C and
WHATWG are commissariats, this shouldn't worry you, since all it says
is your page doesn't follow what the W3C and/or WHATWG say.

> These are not external links. You want these pages to make each item
> externally linkable. The client does not. The client wins this debate hands
> down.

That's not how the W3C or the WHATWG or any standards bodies operate.
If you want a feature in HTML5, you have to argue that it would help
the web to support it, not just that some authors want it.  Your
current arguments are very unlikely to get the spec changed (although
I don't have any say in that).

Users of a site using frames will have a worse experience, because
features like link-sharing and bookmarking won't work.  You've said
that you would *like* these features not to work.  Why, exactly?  This
kind of degradation needs to be justified.

> Already explained. So that a user may enter and exit the frameset as one page

I don't see why that's beneficial.  It conflicts with expected
behavior.  If you follow a link and then click "back", your
link-following should be undone.  You shouldn't be taken to a totally
different page that you left half an hour ago.

On Fri, Oct 9, 2009 at 2:09 PM, Thomas Broyer  wrote:
> Framesets, iframes, AJAX+innerHTML all allow this; you can't present
> this as an argument for frameset or against their removal

I don't see how iframes would allow you to deliberately mess up
navigation in the same way as frames do.  AJAX would, and does, but
that's a lot harder for authors to implement, so asking for an easier
way seems legitimate.

Re: [whatwg] framesets

[Thomas Broyer]

On Fri, Oct 9, 2009 at 7:47 PM, Peter Brawley  wrote:
>>> A design goal of this use case is to isolate individual framed items from
>>> URL back/forward/history.external linking. Analagous to watching a picture
>>> show where selecting N pictures does not commit you to hitting the Back
>>> button N times to get back out.
>>
>>Why shouldn't it?
>
> Because the use case demands otherwise.
>
>> It's how all other links work. Behavior should be consistent.
>
> These are not external links. You want these pages to make each item
> externally linkable. The client does not. The client wins this debate hands
> down.

Framesets, iframes, AJAX+innerHTML all allow this; you can't present
this as an argument for frameset or against their removal (though,
actually, I think you didn't, and the discussion just wen this road
while the use case you were showing is that clicking on a link in any
frame, that loads a new doc within this same frame doesn't have any
side effect on the other frames; for instance, you do not "lose" your
scroll position in the other frames, MSDN doesn't behave exactly the
same here; though you could just use iframes too to the same effect,
except frame resizing, that would need some additional scripting; did
I adequately describe your argument here?)


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

Re: [whatwg] framesets

[Peter Brawley]

> Oy, from the fact that users find web page links useful, it does not 
follow

> that all identified content ought to be so linked.

>It suggests that not linking is a serious drawback.

It suggests no such thing. Your "suggestion", applied to surgery, would 
be that /primum non nocere/ implies surgery should never remove hurt or 
remove useful tissue. The inference is overinclusive, to put it mildly. 
W3C's job is to enable, not function like a commissariat.

> A design goal of this use case is to isolate individual framed items from
> URL back/forward/history.external linking. Analagous to watching a 
picture

> show where selecting N pictures does not commit you to hitting the Back
> button N times to get back out.

>Why shouldn't it?

Because the use case demands otherwise.

> It's how all other links work. Behavior should be consistent.

/These are not external links./ You want these pages to make each item 
externally linkable. /The client does not/. The client wins this debate 
hands down.

> More significantly, each item may have its own permission setting.

>Why are frames useful for that? You can just display a permissions
>error if the user is unauthorized.

The use case specifies otherwise.

> This use case needs to isolate items within the page from
> back/forward/history and external links.

>Why? That seems to detract from the utility here, not add to it.

Already explained. So that a user may enter and exit the frameset as one 
page


PB

-

Aryeh Gregor wrote:
On Fri, Oct 9, 2009 at 12:55 PM, Peter Brawley  
wrote:
Oy, from the fact that users find web page links useful, it does not 
follow

that all identified content ought to be so linked.


It suggests that not linking is a serious drawback.


A design goal of this use case is to isolate individual framed items from
URL back/forward/history.external linking. Analagous to watching a 
picture

show where selecting N pictures does not commit you to hitting the Back
button N times to get back out.


Why shouldn't it? It's how all other links work. Behavior should be
consistent.


More significantly, each item may have its
own permission setting.


Why are frames useful for that? You can just display a permissions
error if the user is unauthorized.


This use case needs to isolate items within the page from
back/forward/history and external links.


Why? That seems to detract from the utility here, not add to it.




No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: 
10/09/09 08:10:00

Re: [whatwg] the cite element

[tjeddo]

On Tue, Oct 6, 2009 at 12:52 PM, Gordon P. Hemsley  wrote:
> I also propose allowing parenthetical citations and footnote markers
> (as is used in the various W3C/WHATWG specifications) to also be
> marked up with , though I'm not sure if TabAtkins agrees with me
> on that point.
>

I agree.  In fact I argue that this is should be the primary use case
for the cite element (i.e., acknowledging sources). The current HTML5
draft definition provided for the cite element is inconsistent with
the HTML4 specification, and furthermore now prohibits the cite
element from being used for actual in-text citations as it was
primarily intended for in HTML4 (see below) . I believe it would be
most beneficial to provide a new element to simply markup the title of
works, or just settle for using the  or  tags, and reserve
the cite element for true in-text citations.

To support my point here are some relevant quotes and characteristic
examples given from the HTML4.01 specification [5].

Here is the definition provided for the cite element in HTML4.01.
"CITE: Contains a citation or a reference to other sources [5, p. 91]."

The HTML4.01 specification provides the following examples
demonstrating the uses of the cite element:

"As Harry S. Truman said, The buck stops
here. [5, p. 91]"

and more importantly

"More information can be found in [ISO-] [5, p. 91]."

Both these examples are now illegal under the current HTML5 draft
definition for the cite element. While clarity certainly needs to be
provided on the usage of the cite element; it is the second example
that most closely matches the spirit and intention of the definition.
That is, in-text citations. HTML5 should focus on refining the
specification to handle this second in-text citation example. I've
taken a shot at formalizing the emerging concepts people have been
discussing on this mailing list to support valid in-text citations
using the cite element. For those looking for the value proposition in
all this, you can skim to the end of the email.
Constructive criticism and corrections are appreciated.

A Proposed Markup Scheme for the CITE element in HTML5

I've sampled a variety of passages containing real citations to markup
in the emerging citation scheme that is being discussed on this
mailing list. This way I don't have to overly contrive my examples. My
goal here is to illustrate how the cite element can be revised to
support first class citation support in HTML5.  Also, all these
examples are taken from sources about writing so there is a good
chance we will all agree they are valid examples.

Example 1A [1]:
Human beings have been described as "symbol-using
animals" (Burke 3).

Candidate HTML5 Markup:
Humans have been described as
symbol-using animals
(Burke 3).

Note: The cite element is used here to make the citation
relationship between the paraphrased/quoted content
and the original source explicit. The 'for' attribute indicates
the paraphrased/quoted content that, in this case, is the
content of the span element with id="symbols". The href
attribute provides a URI that resolves to a bibliography
entry (in this case on the same page), or an actual online
resource that contains the paraphrased/quoted content.
HTML5 aware browsers would render the "(Burke 3)" text
as a hyperlink that would move the browsers displayed area
to the fragment "#bib-burke" on the same page
(the bibliography entry). This could alternatively be an
explicit URI with or without a fragment identifier appended
that navigates to a separate page.

Example 1B [1]:
Human beings have been described by Kenneth Burke as
"symbol-using animals" (3).

Note: An MLA-valid variant of Example 1A

Candidate HTML5 Markup:
[Option 1]

Human beings have been described by
Kenneth Burke
as symbol-using animals (3).

Note: It is the content of the whole sentence and not just
the part between  tags that needs to be attributed to
the author, therefore something like option 2 may be more
appropriate.

[Option 2]


Human beings have been described by
Kenneth Burke
as symbol-using animals (3).



Note: Here an empty cite element is provided with just
attributes to make the citation relationship between
the cited content and the original source explicit.
 tags around the author's name can be optionally
added to provide a hyperlink from the author's name to the
bibliography entry.

Example 2 [4, p. 7]:
For this reason, the American computer scientist Leslie Lamport
has developed the LaTeX format (Lamport, 1985), which provides a
set of higher-level commands for the production of complex
documents.

Candidate HTML5 Markup:
For this reason, the American computer
scientist Leslie Lamport has developed the Latex format
(Lamport, 1985),
which provides a set of higher-level commands for the production
of comple

Re: [whatwg] framesets

[Aryeh Gregor]

On Fri, Oct 9, 2009 at 12:55 PM, Peter Brawley  wrote:
> Oy, from the fact that users find web page links useful, it does not follow
> that all identified content ought to be so linked.

It suggests that not linking is a serious drawback.

> A design goal of this use case is to isolate individual framed items from
> URL back/forward/history.external linking. Analagous to watching a picture
> show where selecting N pictures does not commit you to hitting the Back
> button N times to get back out.

Why shouldn't it?  It's how all other links work.  Behavior should be
consistent.

> More significantly, each item may have its
> own permission setting.

Why are frames useful for that?  You can just display a permissions
error if the user is unauthorized.

> This use case needs to isolate items within the page from
> back/forward/history and external links.

Why?  That seems to detract from the utility here, not add to it.

[whatwg] Some discrepencies and example remarks

[Yuvalik Webdesign]

First off, I apologise if this message appears twice in the list. After 
registration, something went wrong on my end and it seems my message was not 
picked up by the list. If it does appear twice, again my apologies. Disregard 
the other one.

In regard to my remarks, I would also like to point out that I am looking at 
the spec from a web designers point of view (not a developer or a programmer)

I followed the progress of the spec and the discussions on this list for some 
time now, and I feel it is time for me to vent some of my findings and ideas.
I will limit myself to section 4 (The elements of HTML) 
http://dev.w3.org/html5/spec/Overview.html#semantics.

I Find a lot of the descriptive texts, notes and examples to be either 
incomplete, confusing, ambiguous and sometimes even contradictory (again, from 
a designers point of view).
Esp. In regard to the Sectioning Elements. Some examples of this are:

A)
In the NAV element it says:
"In particular, it is common for footers to have a list of links to various key 
parts of a site, but the footer element is more appropriate in such cases, and 
no nav element is necessary for those links."

But then in the example of the ASIDE we find:

  
   Archives —
   About me —
   Copyright
  
 

B)
It also says for ASIDE that:
"The aside element represents a section of a page that consists of content that 
is tangentially related to the content around the aside element, and which 
could be considered separate from that content. Such sections are often 
represented as sidebars in printed typography.
The element can be used for typographical effects like pull quotes or 
sidebars..."

Isn't a pull-quote to be placed in a blockquote? (which is a sectioning root if 
I am not mistaken?) Also, a side-bar, what is that, since side-bars are usually 
separately layed-out and not always directly "around the content". Also, it 
says at the SECTION element:
"When an element is needed for styling purposes or as a convenience for 
scripting, authors are encouraged to use the div element instead."

Does this only apply to SECTION, or also to ASIDE?

C)
When talking about outline (in the context of sectioning) I gather we are NOT 
talking about the DOM-tree, but about (a Table Of) Contents kind of outline. 
Does a generic page-header and footer (containing a site-wide logo, style and 
navigation) belong in such an outline? If not, does this mean it has to be 
enclosed in a separate SECTION element? Nothing about this is made clear either 
in wording or examples.

The spec is not very clear anywhere about styling practices (I know this is 
CSS' job, but within HTML the mark-up should at least be mentioned).

D)
I also find a lot of Notes that are phrased in such a way that they keep the 
interpretation open for discussion.
Things like "when it would make sense" or "other content that is considered 
separate from the main content" or "content that is tangentially related" etc. 
etc.
In the real world these kinds of guidelines are open for discussion on a 
per-situation basis. And may lead to mis-use of the elements.

E)
The TIME element, I know, I know. I followed that discussion and a lot has been 
said about it. My main concern now is that the spec is still not clear on how 
and where it can be used correctly.
For example, marking up times and dates for historical documents... in the 
discussion on this list it has been explicitly implied that this element is NOT 
to be used for that, but in the spec I can still interpret the wording to mean 
that I may.

D)
All in all I would like to recommend, and I hope you will seriously consider, 
rewriting all the examples. Currently the examples are not representative of 
real-world cases. I suggest you find a collection of existing websites of all 
types (blog, webshop, social-site, educational, company-profile, application 
etc. etc.) and base your examples on that. Trying to show good and clear use 
cases and differences.

Evert

Re: [whatwg] framesets

[Peter Brawley]

Try bookmarking a specific page, giving someone a link to a specific
page . . . you can't.  There's one URL for the whole thing, no matter
what page you have open.  It seems you can't even use the back and
forward buttons -- navigating doesn't create a new history entry.
(This appears to be true at least in Firefox and Chrome.)  Linking is
what makes the World Wide Web work, and frames completely break it.


Oy, from the fact that users find web page links useful, it does not 
follow that all identified content ought to be so linked.


A /design goal/ of this use case is to isolate individual framed items 
from URL back/forward/history.external linking. Analagous to watching a 
picture show where selecting N pictures does not commit you to hitting 
the Back button N times to get back out. More significantly, each item 
may have its own permission setting.


Linking is /one functionality/ that makes the web work. /It's not the 
only one/. This use case /needs to isolate/ items within the page from 
back/forward/history and external links.


PB



Thomas Broyer wrote:

On Fri, Oct 9, 2009 at 6:04 PM, Aryeh Gregor  wrote:
  

On Thu, Oct 8, 2009 at 10:41 PM, Peter Brawley  wrote:



A small example is at
http://www.artfulsoftware.com/infotree/mysqlquerytree.php. All the content
is from a MySQL db. It's a small part of the tree & read-only. Our networks
(and some clients) run edit-enabled versions of that frameset. The tree can
be any size. Some client implementations have an extra frame on the right.
  

Try bookmarking a specific page, giving someone a link to a specific
page . . . you can't.  There's one URL for the whole thing, no matter
what page you have open.  It seems you can't even use the back and
forward buttons -- navigating doesn't create a new history entry.
(This appears to be true at least in Firefox and Chrome.)  Linking is
what makes the World Wide Web work, and frames completely break it.


[...]
  

 I don't know why back and forward don't work in the browsers I tried
it in, but they don't do that either.



That's because it uses parent.frames["details"].location.replace(...)
and parent.frames["tree"].location.replace(...)

(in this case, I'd talk about a "developer [who has] mismanaged the
Back button")

  

 Removing a feature that's
intrinsically broken is absolutely the correct use of the standards
process.



I'd add however that replacing a frameset with iframes doesn't solve
the problem. MSDN (online) correctly (IMO) does *not* use either
frames or iframes, and still works great (using JavaScript, but
Peter's example requires JavaScript too). i'd even say it works better
than Peter's example because the tree state is maintained on the
client-side, which means requests to the server can be cached
efficiently (and additionally are lighter-weight and don't even
require server-side processing)

  




No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: 10/09/09 08:10:00


  

Re: [whatwg] framesets

[Thomas Broyer]

On Fri, Oct 9, 2009 at 6:04 PM, Aryeh Gregor  wrote:
> On Thu, Oct 8, 2009 at 10:41 PM, Peter Brawley  
> wrote:
>
>> A small example is at
>> http://www.artfulsoftware.com/infotree/mysqlquerytree.php. All the content
>> is from a MySQL db. It's a small part of the tree & read-only. Our networks
>> (and some clients) run edit-enabled versions of that frameset. The tree can
>> be any size. Some client implementations have an extra frame on the right.
>
> Try bookmarking a specific page, giving someone a link to a specific
> page . . . you can't.  There's one URL for the whole thing, no matter
> what page you have open.  It seems you can't even use the back and
> forward buttons -- navigating doesn't create a new history entry.
> (This appears to be true at least in Firefox and Chrome.)  Linking is
> what makes the World Wide Web work, and frames completely break it.
[...]
>  I don't know why back and forward don't work in the browsers I tried
> it in, but they don't do that either.

That's because it uses parent.frames["details"].location.replace(...)
and parent.frames["tree"].location.replace(...)

(in this case, I'd talk about a "developer [who has] mismanaged the
Back button")

> Removing a feature that's
> intrinsically broken is absolutely the correct use of the standards
> process.

I'd add however that replacing a frameset with iframes doesn't solve
the problem. MSDN (online) correctly (IMO) does *not* use either
frames or iframes, and still works great (using JavaScript, but
Peter's example requires JavaScript too). i'd even say it works better
than Peter's example because the tree state is maintained on the
client-side, which means requests to the server can be cached
efficiently (and additionally are lighter-weight and don't even
require server-side processing)

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

Re: [whatwg] framesets

[Boris Zbarsky]

On 10/9/09 12:04 PM, Aryeh Gregor wrote:

  I don't know why back and forward don't work in the browsers I tried
it in


Here's what "copy link location" gives me for a randomly picked link in 
the menu on the left in Firefox:


javascript:parent.frames["detail"].location.replace("infoitem.php?_sess=sess1255105042&id=24");

Here's what it gives me for the little expander widget of one of those 
links:


javascript:parent.frames["tree"].location.replace("infotree.php?_sess=sess1255105042&t=557&toggle=3#557");

Note the replace() calls.

What was that about developers mismanaging the back button?

-Boris

Re: [whatwg] framesets

[Aryeh Gregor]

On Thu, Oct 8, 2009 at 10:41 PM, Peter Brawley  wrote:
> Thanks for responding. Perhaps you can show me otherwise, but containing a
> browsable tree insided a fixed sidebar does not give us independently
> scrolling subwindows side by side on one page, with the possibility of
> editing in either subwindow without the slightest effect n the other.

It works to a considerable degree.  Look at this example:

http://www.w3.org/Style/Examples/007/menus

You can see how the box in the upper right could be moved to the left,
and a margin could be left on the main content.  The navigation box
can be independently scrollable by using overflow-y: auto or scroll.

One major practical drawback is that this doesn't work in IE6, but
that should be irrelevant in a few years.  Also, position: absolute is
probably acceptable fallback in many cases for those users.

Another significant drawback is that while you can interact with the
frames independently, any navigation will navigate all frames at once.
 But that's really a feature, not a bug.  All the problems with frames
stem from the fact that the frames are independently navigable.  You
can pretty easily preserve the state of the navigation menu using
JavaScript, since you have to change it using JavaScript anyway.

> (Of course even if it is possible to do it without frames, new standards
> ought not to require that perfectly functional, legal, working code be
> rewritten on pain of standards non-compliance.)

Of course they should, if part of a previous standard was found to
cause problems.  Otherwise we'd never be able to fix historical
mistakes.  There are enough mistakes we can't fix even if we wanted
to, without refusing to get rid of mistakes when we can.

> A small example is at
> http://www.artfulsoftware.com/infotree/mysqlquerytree.php. All the content
> is from a MySQL db. It's a small part of the tree & read-only. Our networks
> (and some clients) run edit-enabled versions of that frameset. The tree can
> be any size. Some client implementations have an extra frame on the right.

Try bookmarking a specific page, giving someone a link to a specific
page . . . you can't.  There's one URL for the whole thing, no matter
what page you have open.  It seems you can't even use the back and
forward buttons -- navigating doesn't create a new history entry.
(This appears to be true at least in Firefox and Chrome.)  Linking is
what makes the World Wide Web work, and frames completely break it.

See also: http://en.wikipedia.org/wiki/Framing_(World_Wide_Web)#Criticism

> It seems to me that removing framesets from HTML5 mainly because search
> engines don't like them & developers have often mismanaged the Back button
> is a misuse of the standards process.

Search engines are indifferent to frames, as far as I know.  It has
nothing to do with developers (of what?) mismanaging anything --
frames inherently break linking/bookmarking/etc.  URLs no longer work.
 I don't know why back and forward don't work in the browsers I tried
it in, but they don't do that either.  Removing a feature that's
intrinsically broken is absolutely the correct use of the standards
process.

Re: [whatwg] Restarting the media element resource fetch algorithm after "load" event

[Robert O'Callahan]

On Fri, Oct 9, 2009 at 8:32 PM, Philip Jägenstedt  wrote:

> Aesthetics is not a serious argument. More importantly, the progress events
> spec [1] requires that exactly one of error/abort/load be fired followed by
> loadend. Dropping load and loadend would be a willful violations of that
> spec. In my opinion, the progress events spec should be the one to change.
>
> [1] http://www.w3.org/TR/progress-events/
>

I agree.

That spec says

> If the Operation successfully completes, the user agent *must* dispatch a
> load event.
>
Here we're just dealing with an operation that never completes. The only
real problem in the spec is that it says "Exactly one of these *must* be
dispatched", which seems to just not have considered the possibility of
operations that run indefinitely.

Some other Mozilla developers have actually argued that progress events in
general don't make sense for media elements. The 'buffered' TimeRanges
attribute gives you much more accurate and useful information than progress
events. The progress event 'loaded' and 'total' attributes don't make a lot
of sense in implementations where data may be discarded and redownloaded
during the load. (If you discard some data, does the next progress event
have a smaller 'loaded' value than the last one? Or does 'total' increase by
the size of the discarded data?) But I don't want to open that can of worms
just yet :-).

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] Session history and frames in the previous top level browsing context

[Ian Hickson]

On Sat, 3 Oct 2009, Olli Pettay wrote:
> 
> seems like HTML5 doesn't properly specify what should happen if the 
> 'previous top level page' contained frames and go(-) is used 
> to navigate back.
> 
> Browsers also do different things. A pretty simple testcase is here 
> http://mozilla.pettay.fi/moztests/history/Start.html Just click the 
> links until 'B iframe 2' is loaded. go(-2) should apparently load 
> previous top level page, and in its iframe it should load the previously 
> loaded document, not the document, which iframe element in the top level 
> page refers to. Section 6.10 doesn't seem to specify that behavior 
> properly.
> 
> Perhaps even more interesting case is go(-3). Which one is the right 
> thing to do, IE8 behavior or FF3.6/Opera10? And if IE8's, why its 'Back' 
> button behaves differently.

IE8 actually behaves exactly like what the spec says, it seems (and it 
does seem to match it's back button, unless I'm missing something). As far 
as I can tell, the spec isn't ambiguous here.


> And this all is still just about static pages. Things get more 
> complicated when (i)frames are added and removed dynamically.

The spec actually doesn't explicitly cover anything to do with how to deal 
with navigating subframes when a Document has been evicted from the cache 
and is reloaded during session history traversal. I'm not really sure 
exactly what to do about that. It's not clear to me what the right 
solution should be. Does anyone have any proposals?

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

Re: [whatwg] functionality absorbed into ?

[Ian Hickson]

On Sat, 3 Oct 2009, Oli Studholme wrote:
> 
> In talking with authors about HTML5 [1] I’ve found it seems 
> confusing for many people, and I’ve also found it a little difficult to 
> explain so it’s easy to understand (conversation = why? outline 
> algorithm. huh?). Currently it’s only role is to hide subheadings from 
> the outline algorithm and it doesn’t map to a common use pattern for 
> adding semantic meaning. There doesn’t seem to be any tangible benefit 
> to authors in using it.

The tangible benefit is that when navigating the document by section, or 
when generating a table of contents, there will be the right number of 
sections.

For example, the W3C copy of HTML5 says:

   HTML5
   A vocabulary and associated APIs for HTML and XHTML
   Editor's Draft 9 October 2009
   ...
   Abstract
   ...

However, this is _not_ meant to mean:

   
HTML5

 A vocabulary and associated APIs for HTML and XHTML


 Editor's Draft 9 October 2009
 ...


 Abstract
 ...

...

...which is what it would be interpreted as. This is what is meant:

   
HTML5;
A vocabulary and associated APIs for HTML and XHTML;
Editor's Draft 9 October 2009
...

 Abstract
 ...

...

...and expressing that is only really possible with  (or some 
similar feature, like an attribute toggle somewhere):

   

 HTML5
 A vocabulary and associated APIs for HTML and XHTML
 Editor's Draft 9 October 2009

...

 Abstract
 ...

...


> Superfriends suggested a Boolean attribute for  to determine
> if all child - elements are included in the outline[2].

That would unfortunately prevent things like:

   
My great blog
Navigation
(navigation links...)
About me
(intro...)
   


> The current  model excludes all subtitles from the outline.

Well, UAs can show the text, it just prevents the subtitles from 
generating new sections in the outline.


> Assuming that subtitles should not be included in the outline (eg to 
> make sure the highest-ranked title is indeed descriptive), what if 
>  by default masked subtitles from the outline algorithm as 
>  currently does?

In , there are no subtitles, the titles would be actual titles for 
subsections. Previously,  was just called  and did what 
you describe, but people indicated they wanted sections in .


> Currently #the-header-element[3] mentions a “Little Green Guys With 
> Guns” example in which - elements in the  but outside 
>  create implied  elements via the outline algorithm. If 
>  hides all but one - element this won’t happen (this is 
> also a potential issue with the Boolean attribute idea). While the spec 
> states authors should add wrapping s I suspect many won’t 
> bother and rely on implied ones (unless they need CSS hooks). This would 
> also be potentially confusing compared with , and possibly 
> encourage authors to mistakenly add s with s inside of 
> a  (copy&paste mistakes etc).

Indeed.


> While this idea has drawbacks I feel ’s lack of tangible
> author benefit and ‘occasional use’ nature will result in it not being
> widely used when it should be.

The most common uses will likely only take a few WordPress template 
changes for it to end up being used in a lot of places.

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

Re: [whatwg] framesets

[Rimantas Liubertas]

> Thanks for responding. Perhaps you can show me otherwise, but containing a
> browsable tree insided a fixed sidebar does not give us independently
> scrolling subwindows side by side on one page, with the possibility of
> editing in either subwindow without the slightest effect n the other. That
> is the requirement, framesets let us meet it, and nothing else we know of
> does.

How about overflow-y:scroll? (PoC: http://rimantas.com/bits/cssscroll.html ).
However I do not agree that this kind of navigation necessarily
"provides level of usability higher
than any other method of presenting content of such type".

> (Of course even if it is possible to do it without frames, new standards
> ought not to require that perfectly functional, legal, working code be
> rewritten on pain of standards non-compliance.)

New standards to not require anyone to rewrite anything. Older standards
stay valid. Why not just use HTML4 with frameset DTD?
<…>

Regards,
Rimantas
--
http://rimantas.com/

Re: [whatwg] Restarting the media element resource fetch algorithm after "load" event

[Philip Jägenstedt]

On Thu, 08 Oct 2009 22:53:45 +0200, Robert O'Callahan  
 wrote:


On Fri, Oct 9, 2009 at 7:31 AM, Philip Jägenstedt   
wrote:



I wouldn't be particularly opposed to dropping the load event, unless
there's a use case for the guarantee that the resource won't be evicted  
from

cache as long as the page is loaded.



If there is a need for that, then I think we should add some kind of  
pinning
API, although I'm not sure how it would avoid the problem of greedy  
authors

pinning resources unnecessarily. But we'd have to consider the actual use
cases.


I'd say that the autobuffer attribute is exactly that API, which gives  
both author control and browser liberty to ignore it when necessary.


--
Philip Jägenstedt
Opera Software

Re: [whatwg] Restarting the media element resource fetch algorithm after "load" event

[Philip Jägenstedt]

On Fri, 09 Oct 2009 08:42:12 +0200, Simon Pieters  wrote:

On Thu, 08 Oct 2009 23:19:28 +0200, Robert O'Callahan  
 wrote:


On Fri, Oct 9, 2009 at 6:42 AM, Eric Carlson   
wrote:



  I am not worried about the aesthetics of not having the event.  I am
somewhat concerned about existing content that uses it (including many  
of
the WebKit layout tests :-( ), but I think we will be better off in  
the long

run if we get rid of the event and network state now.



Me too. I'm game if you are!

So I propose:
1) Remove the NETWORK_LOADED state and "load" and "loadend" events from
media elements.


'loadend' also fires after 'abort' and (when using the src attribute)  
'error'. Should that stay as is, or also be removed?


Since we're going to contradict the progress events spec anyway, I would  
suggest dropping all 'loadend' events. They're just not very useful.



The resource fetch algorithm simply never transitions from
step 2 to step 3.
2) Modify Gecko and Webkit accordingly.

If we do part 2, which I think is already permitted by the spec, then
authors will stop depending on "load" whether or not we get consensus  
for

altering the spec.

Rob






--
Philip Jägenstedt
Opera Software

Re: [whatwg] Restarting the media element resource fetch algorithm after "load" event

[Philip Jägenstedt]

On Thu, 08 Oct 2009 23:08:32 +0200, Robert O'Callahan  
 wrote:


On Fri, Oct 9, 2009 at 1:32 AM, Philip Jägenstedt   
wrote:



The spec notes that "Some resources, e.g. streaming Web radio, can never
reach the NETWORK_LOADED state." In my understanding, you mustn't go to
NETWORK_LOADED if you can't guarantee that the resource will remain in
cache. Browsers with clever caching or small caches simply won't send a  
load

event most of the time.



Right, HTML5 allows Gecko to simply never enter the NETWORK_LOADED state  
and

send a "load" event. That would be the simplest thing for us to do, and I
think the best in terms of letting us do intelligent caching. But I'd  
prefer

not to do it alone.


No objection to dropping the event and implementing as such here.


Aesthetically, however, I think it would be strange to not have the load

event.



If you mean because of the analogy with the "load" events of other  
elements,


Aesthetics is not a serious argument. More importantly, the progress  
events spec [1] requires that exactly one of error/abort/load be fired  
followed by loadend. Dropping load and loadend would be a willful  
violations of that spec. In my opinion, the progress events spec should be  
the one to change.


[1] http://www.w3.org/TR/progress-events/

--
Philip Jägenstedt
Opera Software