Re: [whatwg] Removing rel=feed
On Tue, 6 Oct 2009, Mark Pilgrim wrote: This is an email followup from an IRC discussion long ago, at Ian's request. http://krijnhoetmer.nl/irc-logs/whatwg/20090416#l-507 # [23:30] mpilgrim test cases: http://diveintomark.org/tmp/relalternate.html and http://diveintomark.org/tmp/relfeed.html # [23:30] mpilgrim all modern browsers support the former (except google chrome, which has no feed autodiscovery at all) # [23:31] mpilgrim firefox 3 supports rel=feed # [23:31] Hixie sounds right # [23:31] mpilgrim firefox 2 does not support rel=feed # [23:32] mpilgrim opera 9.62 does not support rel=feed # [23:32] mpilgrim safari 4 beta does not support rel=feed # [23:32] mpilgrim IE8 final does not support rel=feed http://krijnhoetmer.nl/irc-logs/whatwg/20090518#l-32 # [04:45] mpilgrim i've completed my rel=feed research ( c.f. http://krijnhoetmer.nl/irc-logs/whatwg/20090416#l-507 ) # [04:46] mpilgrim i sampled 3 billion web pages from google's latest index # [04:46] mpilgrim weeding out errors like rel='RSS 2.0 feed' and false positives like rel='service.feed', # [04:46] mpilgrim i found exactly 1 page that uses rel='feed' according to specification and to the exclusion of any other autodiscovery mechanism # [04:46] mpilgrim http://seiji.asia/ # [04:47] mpilgrim and they have a visible link on their page that also links to their feed # [04:48] mpilgrim so there would be little harm in removing rel=feed support from the only browser that actually supports it # [04:48] mpilgrim and little harm in removing it from html 5 To sum up: only one browser has ever implemented rel=feed, despite it being in the draft spec for several years, and real-world usage of the feature is miniscule. I recommend removing the section called 'Link type feed' from HTML5 altogether, and redefining 'Link type alternate' in a way that does not depend on rel=feed. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.
On Wed, 7 Oct 2009, Alex Russell wrote: 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. It is onerous intentionally; the idea is to reduce the use of this mechanism, as it has almost universally been misused. 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. Server and client authors have used the X-* convention to denote such extension fields as a forward-compatible prefix. In order for HTML 5 to better represent real-world content, we'd like to request that an exception be made to the registered via RFC rule for http-equiv headers which are prefixed with X-, or, alternately, that the spec simply declare that unlisted keys and values will not be considered invalid, but rather that only invalid values for listed keys trigger validity errors. This would make X-UA-Compatible conforming, which is not desireable. We want to _discourage_ mechanisms that lead to vendor-targetting of that nature. On Fri, 9 Oct 2009, Maciej Stachowiak wrote: 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. Indeed. On Fri, 9 Oct 2009, Julian Reschke wrote: 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]. (http://tools.ietf.org/html/rfc3864#section-4.1) The HTML5 requirement goes further than the IETF requirement; I would consider that a bug. On Fri, 9 Oct 2009, Maciej Stachowiak wrote: 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. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] framesets
I assume Javadocs are a legitimate use case for HTML5. What's the right way to implement Javadocs in HTML5? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] keyboard behaviour inside of editable area
On Thu, 8 Oct 2009, Alexander Surkov wrote: The suggestion is to treat control element as special character, i.e. when you move through the text by arrow keys and control element is met then control element should be focused and its selection should be changed appropriately. When control has the focus then keyboard behaviour is defined by control preferences with once exception. If particular navigation key isn't processed by control or doesn't have any defined action then editor rules are applied. This seems reasonable (though I'd prefer to study it in a usability lab before making a stronger statement), but it also seems like an implementation detail -- there's nothing that really requires that the user agent even support arrow keys, let alone that they work in a particular way. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.
On Oct 10, 2009, at 08:20, Maciej Stachowiak wrote: 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. I disagree unless we really want to enable http-equiv as a way of specifying browser-only HTTP header equivalents that intermediaries ignore. OTOH, if we want to enable only pragmas that the HTML layer must recognize for backwards-compatibility, enumerating the permitted values is quite reasonable. As for X-UA-Compatible specifically, when Microsoft did it, it was decried as a bad thing. Why does it become a good thing when Google does it? I can see one crucial difference: In IE8 without Chrome Frame (when your domain isn't blacklisted), X-UA-Compatible is a mechanism for opting into a legacy engine. As long as being able to implement the legacy complexity is advantageous in use retention/acquisition, sites opting into legacy IE behavior enable a lock-in to IE. chrome=1 is more similar to IE=Edge than opting into a legacy IE. However, another way of viewing this is that if user switched from IE to Chrome proper (or Firefox or Safari or Opera), *other* sites would be less able to use IE-only code. However, both IE=Edge and chrome=1 let users *also* keep the hard-to-clone legacy complexity for *other* sites. If this creates a situation where IE+Chrome Frame is the most compatible browser, the outcome isn't necessarily good for the overall health of the Web, since the IE part would still lock the user into Windows and even within Windows out of Gecko or Presto. I guess it's too early to tell if Chrome Frame will have an overall positive impact (making authors write to the multi-vendor interoperable platform without having to write a special code path for one vendor) or whether it'll have an overall negative impact either strengthening IE or leading authors to write WebKit-only code (or even Chrome-only code). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] The legend element
On Thu, 8 Oct 2009, Markus Ernst wrote:
I found this post by Ian Hickson from August 15, 2006 in the list
archive:
On Sat, 1 Apr 2006, Henri Sivonen wrote:
Since the omission of legend does not cause any horrible effects,
I suggest making legend optional and reaffirming that if it
appears, it can appear only once per fieldset and only as the
first child (ignoring whitespace).
I agree, and I will do this as part of HTML5, where I am defining
content models. If you don't object, I'll leave this change out of WF2
for now. (If you do object, then let me know, and I'll shoehorn it in
somehow.)
It looks like this change has not made it into the HTML5 spec so far.
Oops. Done.
Additionnally I want to suggest to make it possible to place the legend
element outside the fieldset element, providing a for attribute (just
as it is possible to place the label element apart from it's form field
element).
This is significantly harder to pull off, for the same reason that we
haven't been able to use legend for figure. I recommend we wait for
the next version of HTML before doing this.
Background: When writing template based applications, it can be useful
to provide a placeholder for the whole fieldset, and another one for the
legend, as template authors might want to place or style them
individually.
Example - a questionnaire:
Template Variable {question} outputs:
legend for=question1What ist your favorite Pet?/legend
Template Variable {answers} outputs:
fieldset id=question1
plabelinput type=radio name=q1 value=CatCat/label/p
plabelinput type=radio name=q1 value=DogDog/label/p
plabelinput type=radio name=q1 value=AntAnt/label/p
/fieldset
One author might want to use this template:
h2{question}/h2
{answers}
The other one prefers:
table
tr
td{question}/td
td{answers}/td
/tr
/td
While the desired results can be easily achieved with the current legend
specification when coding manually, it is quite hard to implement with a
template system, needing separate template variables for both the
fieldset start and end tags, and a loop for the questions. With the
focus of making an application as easy to use as possible (which
includes template authoring), application authors might rather go
without fieldset and legend, and accept the loss of structural
consistency and accessibility as a trade-off.
I am sure this change would not break legacy content in new browsers;
anyway I have no Idea how far it would break HTML5 content in legacy
browsers.
I don't understand why the fieldset and legend can't be in the
template.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.
Henri Sivonen wrote: On Oct 10, 2009, at 08:20, Maciej Stachowiak wrote: 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. I disagree unless we really want to enable http-equiv as a way of specifying browser-only HTTP header equivalents that intermediaries ignore. I think that's an orthogonal discussion. Requiring RFC when the IETF requires something different appears to be a bug. ... As for X-UA-Compatible specifically, when Microsoft did it, it was decried as a bad thing. Why does it become a good thing when Google does it? ... It doesn't. ... BR, Julian
Re: [whatwg] framesets
On Sun, 11 Oct 2009 23:43:03 +0200, Eduard Pascual herenva...@gmail.com wrote: For it to be taken seriously by the editor, I strongly recommend that you send spec-ready quality text, I recommend sticking to use cases, requirements, links to real-world pages, and proposed solutions with pros/cons. frameset is not being removed from HTML. It's being removed from the set of conforming elements in HTML, along with e.g. applet. It's not being removed from what browsers have to implement: HTML5 specs frameset for browsers in the parsing, rendering and obsolete features sections. It's just not being updated because there was nothing to add to it, so it stays the same. Not really: Elements in the following list are entirely obsolete, and must not be used by authors: frame frameset noframes Either use iframe and CSS instead, or use server-side includes to generate complete pages with the various invariant parts merged in. http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#non-conforming-features Taking all this together, here comes again: the question I have already asked several times, and you haven't answered: What are you asking for? I would presume that Peter is asking for frameset, frame and noframes to be part of the set of conforming elements in HTML. Correct, Peter? -- Simon Pieters Opera Software
Re: [whatwg] framesets
bay117-w3028b5e214edae8ab9a8eb83...@phx.gbl pine.lnx.4.62.0910120719160.25...@hixie.dreamhostps.com Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Does pushState apply to bookmarking ?From reading section 6.10 of the spec it seems to apply only to back/forward navigation.If it does, it seems a good solution for iframe bookmarking problem. Date: Mon, 12 Oct 2009 09:12:34 + From: i...@hixie.ch To: wha...@whatwg.org Subject: Re: [whatwg] framesets On Thu, 8 Oct 2009, Peter Brawley wrote: According to http://www.w3.org/TR/2009/WD-html5-diff-20090825/, The following elements are not in HTML 5 because their usage affected usability and accessibility for the end user in a negative way: * frame * frameset * noframes As Andrew Fedoniouk said on this list in 2007 (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 agree wholeheartedly, esp. when the topic list is long (thousands or millions of items) and itself editable, and the required interface is for flexible, independent scrolling of freely choosable bits of the topic tree in the left frame without affecting anything in the right detail frame. As Andrew said, frames are the only good way to do this. New standards ought not to remove required functionalities, ought not to break perfectly good legal working code, and ought not to impose Hobson's choice of keeping functionality vs remaining standards-compliant. How do we get the unwise decision to remove framesets revisited? Except for resizing, anything you can do with framesets, you can do better with iframes and CSS. In addition, with pushState(), you can fix the bookmarking problem in a better way than with framesets. Resizing is something that's harder to do, but that's a presentational issue that we need to fix anyway, independent of frames. Framesets have a number of problems, chief amongst them that bookmarking is dysfunctional, but also that the accessibility story for frames is rather poor, and that there the presentation with frames is much less pleasing than with other features (e.g. in Safari, this page: http://www.artfulsoftware.com/infotree/mysqlquerytree.php ...has a vertical scrollbar for the top frame -- a problem you wouldn't get if instead of four pages, you had three, with the main one containing two iframes from the left and right frames). In addition to iframes, other techniques exist to get similar results, e.g. AJAX. The use case covered by frameset is definitely handled (Getting rid of the frames altogether is probably best, since then tools like search engines can actually return useful links. However, I understand if some authors are unwilling to do the work to get to that point. iframes, on the other hand, are very easy to migrate to.) On Fri, 9 Oct 2009, Peter Brawley wrote: W3C's job is to enable, not function like a commissariat. This isn't the W3C. On Fri, 9 Oct 2009, 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. Actually, you only need to use frames in the frameset page, so if your only concern is what validates, you could just use HTML4 Frameset for the frameset page, and HTML5 for the content pages. But I would still strongly discourage using framesets. On Fri, 9 Oct 2009, Jonas Sicking wrote: The big difference is that iframes can be used in good ways, framesets essentially can't. Another reason do deprecate frameset but not iframe is that we don't need *two* ways to make poorly behaving pages. Indeed. On Fri, 9 Oct 2009, Peter Brawley wrote: 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 how we roll here. :-) 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. Backwards-compatibility is preserved: HTML5 defines how framesets are to be implemented, so your pages won't stop working with HTML5 browsers. They just won't be conforming HTML5, because we want to discourage the use of framesets in favour of better solutions. On Fri, 9 Oct 2009, Peter Brawley wrote: Why
Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.
On Oct 11, 2009, at 11:57 PM, Henri Sivonen wrote: On Oct 10, 2009, at 08:20, Maciej Stachowiak wrote: 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. I disagree unless we really want to enable http-equiv as a way of specifying browser-only HTTP header equivalents that intermediaries ignore. Sorry, my statement was ambiguous. To be more specific: I think the HTML5 requirement should be changed to allow any header in the Permanent Message Header Field Registry to be registered as a pragma extension (instead of only headers defined by an RFC). I think this has no impact on your point of concern. OTOH, if we want to enable only pragmas that the HTML layer must recognize for backwards-compatibility, enumerating the permitted values is quite reasonable. Are you suggesting that the pragma extensions registry should be removed entirely? Regards, Maciej
Re: [whatwg] The legend element
Ian Hickson schrieb:
Additionnally I want to suggest to make it possible to place the legend
element outside the fieldset element, providing a for attribute (just
as it is possible to place the label element apart from it's form field
element).
This is significantly harder to pull off, for the same reason that we
haven't been able to use legend for figure. I recommend we wait for
the next version of HTML before doing this.
Would it be possible and easy to allow label for fieldsets? This looks
somehow consistent to me:
h2label for=question1Favorite pet?/labelh2
fieldset id=question1
plabelinput type=radio name=q1 value=CatCat/label/p
plabelinput type=radio name=q1 value=DogDog/label/p
plabelinput type=radio name=q1 value=AntAnt/label/p
/fieldset
or:
label
h2Favorite pet?h2
fieldset
plabelinput type=radio name=q1 value=CatCat/label/p
plabelinput type=radio name=q1 value=DogDog/label/p
plabelinput type=radio name=q1 value=AntAnt/label/p
/fieldset
/label
Background: When writing template based applications, it can be useful
to provide a placeholder for the whole fieldset, and another one for the
legend, as template authors might want to place or style them
individually.
Example - a questionnaire:
Template Variable {question} outputs:
legend for=question1What ist your favorite Pet?/legend
Template Variable {answers} outputs:
fieldset id=question1
plabelinput type=radio name=q1 value=CatCat/label/p
plabelinput type=radio name=q1 value=DogDog/label/p
plabelinput type=radio name=q1 value=AntAnt/label/p
/fieldset
One author might want to use this template:
h2{question}/h2
{answers}
The other one prefers:
table
tr
td{question}/td
td{answers}/td
/tr
/td
While the desired results can be easily achieved with the current legend
specification when coding manually, it is quite hard to implement with a
template system, needing separate template variables for both the
fieldset start and end tags, and a loop for the questions. With the
focus of making an application as easy to use as possible (which
includes template authoring), application authors might rather go
without fieldset and legend, and accept the loss of structural
consistency and accessibility as a trade-off.
I am sure this change would not break legacy content in new browsers;
anyway I have no Idea how far it would break HTML5 content in legacy
browsers.
I don't understand why the fieldset and legend can't be in the
template.
That is how I do it now. The downside of it is the fact that some
themplate authors might forget it - a relevant number of web designers
in fact don't even know about fieldsets, as forms usually work with or
without them. Anyway it is not a big problem; it would just be a nice
enhancement of consistency if the template engine were able to output
*all* form structuring elements.
Re: [whatwg] Some discrepencies and example remarks
On Fri, 9 Oct 2009, Yuvalik Webdesign wrote: 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: footer nav a href=/archivesArchives/a — a href=/aboutAbout me/a — a href=/copyrightCopyright/a /nav /footer The nav isn't necessary, but it is allowed. I've tried to clarify the text you quote above. 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?) Sure, you can put the text in a blockquote or q in the aside. One of the examples does this, in fact (search for People ask me what I do). Also, a side-bar, what is that, since side-bars are usually separately layed-out and not always directly around the content. Not sure what you are asking here. 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? It applies to everything, actually, but it's listed explicitly in the section section because that has been the element we have seen most often abused for generic purposes. (Some people seem to just use section like they used div.) 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. Right. 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. I don't understand why this is a question. Why would it not belong in the outline? 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). Could you elaborate on what you had in mind? Note that default styles are listed in detail in their own section. 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. If you have any specific cases you think should be tightened up, please feel free to bring them up. It's hard to know exactly which ones you think are too vague. 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. It's fine to use it for historic documents for recent history. The spec mentions that using it for times before Gregorian dates is tricky. It's impossible to give dates before about 1AD Julian (before exactly 1AD Gregorian). I don't really know what else we could say. 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. Please file specific bugs or send specific e-mails for each example you think should be reworked; there are over 300 examples in the spec and without knowing what is wrong with each one, if I just go through them all and change them, they're just going to go from one kind of bad example to another kind of bad example. On Sat, 10 Oct 2009, Yuvalik Webdesign wrote: So you are saying that aside 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)? More or less. I think you misunderstand my
Re: [whatwg] The banner-role for headers
On Sat, 10 Oct 2009, Yuvalik Webdesign wrote: In section 3.2.6 (Assistive technologies) it states in the table that header has an implied ARIA role of “banner”. However, the spec description of header does not comply with the description of the banner-role in the ARIA-spec. ARIA states: “A region that contains the primary heading or web site title. Most of the content of a banner is site-oriented, rather than being page-specific. [...], the author *SHOULD mark no more than _one element_ with the banner role*.” Which makes sense to me, a banner is not a header. In other words, if header implies a banner-role, it may only be used once on a page unless that role is overridden for additional headers. Is this an oversight in the spec or is this to remain like this? If so, how should this contradiction be approached by designers/developers. That's an oversight. What would be a better ARIA role to use for header? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Is there any reason for the continued existence of enctype attribute at the form element
On Sun, 11 Oct 2009, Simon Pieters wrote: On Sun, 11 Oct 2009 11:38:51 +0200, Ian Hickson i...@hixie.ch wrote: While I agree that it is probably an authoring error if the author included a type=file control on a page with the default enctype, Should thus validators flag this as an error? As a warning, maybe. Making it a conformance error seems a bit drastic. Maybe we should, though? On Sun, 11 Oct 2009, Mark Kaplun wrote: I think that in practice no one is writing his own mime handling routines to handle the data in a post message, and people just use a framework which handles it for them. I am familiar with the way PHP handles posts and I know that for the PHP code the mime type is handled by PHP itself and you don't care about it in your code. In your example the form will work, because the server code never did any assumptions on the mime type. I don't know enough about other server languages but I would assume that handling the post mime type automagically is one of the basic candies that every modern server language provides. Maybe I should have started with an example where the current behavior hurts: I am developing plugins and themes for wordpress. An often requested feature is to have an image associate with a post/category/whatever. Worpress has a plugin api and I can use it to add fields to admin forms, so in theory I just need to add a file input. The problem is that all of the admin except for one are textual and do not specify an enctype, and therefor I have to add some JS code to change the enctype on the client side, or develop some pointless buffering and string replacement to set the correct enctype. On Sun, 11 Oct 2009, Boris Zbarsky wrote: While this may be true (and I'm not sure it's as true as one would like) some of these frameworks are more or less capable than others. Some expect the data in a _very_ particular format (such that changing the order of elements in the submitted data, for example breaks them); I would not expect them to switch easily between different enctypes. A surprising amount of form POST processing seems to happen in an exe on the server, not in any sort of modern scripting language. At least based on the bugs we've gotten filed whenever we change anything about it. On Sun, 11 Oct 2009, Mark Kaplun wrote: Boris, I have agreed with your first response that I don't know enough about all the crazy things that people might be doing, to make this attribute to disappear. However I don't see how changing the default mime type will have any affect on the existing web pages and for web pages which will be authored in the next few years, as long as there are tested against IE8. IMHO this attribute is a bug in the specification which is causing annoyance to any web developer which do not use IDE's to create forms. Changing the default the way I described might create a different annoyance, but in my opinion it will be a much lesser one. I've certainl written CGI scripts without libraries where the CGI script only supports one enctype. I doubt I'm alone in this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag-and-drop feedback
On Sun, 11 Oct 2009, Garrett Smith wrote: My question is: Which browser does document.initDragEvent work in? Do you mean DragEvent.initDragEvent? Document.initDragEvent is inordinately long and cumbersome, taking 16 arguments, and requiring the creation of a DataTransfer object. That seems extremely cumbersome just to get a drag event to fire. This method doesn't seem to be implemented anywhere FWICT. Was it copied from an existing implementation? It seems to have been an invention. But whose? It's just the usual way things are done for events. I'll follow whatever DOM3 Events says to do. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] framesets
On Mon, 12 Oct 2009, tali garsiel wrote: Does pushState apply to bookmarking? Insofar as bookmarking uses the document's current address, yes. (Bookmarking, being a UI feature, isn't defined in HTML5.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The legend element
On Mon, 12 Oct 2009, Markus Ernst wrote: Ian Hickson schrieb: Additionnally I want to suggest to make it possible to place the legend element outside the fieldset element, providing a for attribute (just as it is possible to place the label element apart from it's form field element). This is significantly harder to pull off, for the same reason that we haven't been able to use legend for figure. I recommend we wait for the next version of HTML before doing this. Would it be possible and easy to allow label for fieldsets? I don't understand the use case. This looks somehow consistent to me: h2label for=question1Favorite pet?/labelh2 fieldset id=question1 plabelinput type=radio name=q1 value=CatCat/label/p plabelinput type=radio name=q1 value=DogDog/label/p plabelinput type=radio name=q1 value=AntAnt/label/p /fieldset Why is this preferable to: fieldset legendFavorite pet?/legend plabelinput type=radio name=q1 value=CatCat/label/p plabelinput type=radio name=q1 value=DogDog/label/p plabelinput type=radio name=q1 value=AntAnt/label/p /fieldset ...? or: label h2Favorite pet?h2 fieldset plabelinput type=radio name=q1 value=CatCat/label/p plabelinput type=radio name=q1 value=DogDog/label/p plabelinput type=radio name=q1 value=AntAnt/label/p /fieldset /label Why is this preferable to the above? I don't understand why the fieldset and legend can't be in the template. That is how I do it now. The downside of it is the fact that some themplate authors might forget it - a relevant number of web designers in fact don't even know about fieldsets, as forms usually work with or without them. Anyway it is not a big problem; it would just be a nice enhancement of consistency if the template engine were able to output *all* form structuring elements. I don't understand the problem, but if it's not a big problem, then I would suggest we punt on it until the next version. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Is there any reason for the continued existence of enctype attribute at the form element
Ian Hickson wrote: On Sun, 11 Oct 2009, Mark Kaplun wrote: Boris, I have agreed with your first response that I don't know enough about all the crazy things that people might be doing, to make this attribute to disappear. However I don't see how changing the default mime type will have any affect on the existing web pages and for web pages which will be authored in the next few years, as long as there are tested against IE8. IMHO this attribute is a bug in the specification which is causing annoyance to any web developer which do not use IDE's to create forms. Changing the default the way I described might create a different annoyance, but in my opinion it will be a much lesser one. I've certainl written CGI scripts without libraries where the CGI script only supports one enctype. I doubt I'm alone in this. Ian, if posting was implemented my way (browser selects best encoding as default) when you wrote the CGI, your work was harder, easier or no change at all?
Re: [whatwg] The banner-role for headers
From: Ian Hickson Which makes sense to me, a banner is not a header. In other words, if header implies a banner-role, it may only be used once on a page unless that role is overridden for additional headers. Is this an oversight in the spec or is this to remain like this? If so, how should this contradiction be approached by designers/developers. That's an oversight. What would be a better ARIA role to use for header? I am no expert, but looking at the ARIA spec, I doubt there is a role that fits the header element. The closest I can find is the heading role, but that is more closely related to, and already implemented on Hx and hgroup. I see three possibilities, but anybody feel free to comment on these: 1) Don't give header an implied ARIA-role. 2) Give header the header role. 3) Leave the banner role, but give clear instructions on the fact that it may only be used once and how to remove the role from subsequent headers. Personally I think 3) is *not* workable. Evert
Re: [whatwg] Some discrepencies and example remarks
From: Ian Hickson 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. Right. 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. I don't understand why this is a question. Why would it not belong in the outline? Because of the fact the outline is a sort of TOC, and sometimes stuff that goes in a header doesn't belong in a TOC (since it is not content in the strictest sense of the word). But I think Tab Atkins answered this by giving me the advice not to over-think this too much. And he is probably right. 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). Could you elaborate on what you had in mind? Note that default styles are listed in detail in their own section. I know, but that was not what I had in mind. I wish there were some examples that showed the difference in mark-ups between using section, article etc. and div. Again, maybe I am trying too much here, but let me explain: When starting a job you get content from the client (well, hopefully ;-) You start out by categorizing and sorting this content; this process can be an actual job you do, or something you do subconsciously while working at the site. In an ideal situation, it is easy to sort the content in two categories: content that belongs in the outline and pure lay-out. But sometimes this choice is not so black and white. In those cases, one designer may use a div while another may use a section or an aside. Now I am not saying the spec should educate on this (as it has been mentioned, this is a job for tutorial sites etc.), but what I am saying is that it may be prudent to use more complex examples in the spec that address the difference in when to use section etc. and when to use div to make the line less gray. Please file specific bugs or send specific e-mails for each example you think should be reworked; there are over 300 examples in the spec and without knowing what is wrong with each one, if I just go through them all and change them, they're just going to go from one kind of bad example to another kind of bad example. I'd be perfectly happy to provide you with some examples, but I hope you will give me some helpfull feedback if I make a mistake in them. I will rework the examples for sectioning elements. Is a time-frame of two weeks ok with you? 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 header or is this a div? Can you provide the URI? I would be happy to take a look, and maybe base an example in the spec on this. As I am still working in the site it is local, so no URI. Also I am somewhat uncomfortable with sending you the source-code as it is rather messy right now (I had to rework the site as the client had some new ideas he wanted to try out). I will try to include this code in the examples I will send. Thanks for your answers, Evert
[whatwg] Transparent Content
I have an argument with a colleague of mine regarding Transparent elements. He filed a bug regarding this in bugzilla and I wrote to the html5doctor about it with a question, but neither action has answered our question. The way I understand it, a Transparent Element can contain the same elements its direct parent can. The way my colleague understands it, is that a transparent element can be wrapped around any other element. Which is it? Or is it something else? The section about Transparent Content (3.2.5.2) Is not very easy to understand, any chance it could be re-phrased? Specifically this sentence: “When a content model includes a part that is transparent, those parts must not contain content that would not be conformant if all transparent elements in the tree were replaced, in their parent element, by the children in the transparent part of their content model, retaining order.” If I knew what it meant I would offer a suggestion, but I am at a loss as to understand this. Evert
Re: [whatwg] The legend element
Ian Hickson schrieb:
On Mon, 12 Oct 2009, Markus Ernst wrote:
Ian Hickson schrieb:
Additionnally I want to suggest to make it possible to place the
legend element outside the fieldset element, providing a for
attribute (just as it is possible to place the label element apart
from it's form field element).
This is significantly harder to pull off, for the same reason that we
haven't been able to use legend for figure. I recommend we wait
for the next version of HTML before doing this.
Would it be possible and easy to allow label for fieldsets?
I don't understand the use case.
I am sorry I seem to have missed to make the use case really
transparent. My use case is a template system with separate placeholders
for labels and input fields, where input fields can be fieldsets in some
cases, e.g.:
Relevant part of the template:
!-- BEGIN form-fields-loop --
tr
tdh2{label}/h2/td
td{input-html}/td
/tr
!-- END form-fields-loop --
Placeholder outputs of first row:
{label}: label for=q1What is your name?/label
{input-html}:
input id=q1 type=text name=Name
Placeholder outputs of 2nd row:
{label}: label for=q2What is favourite pet?/label
{input-html}:
fieldset id=q2
plabelinput type=radio name=Pet value=CatCat/label/p
plabelinput type=radio name=Pet value=DogDog/label/p
plabelinput type=radio name=Pet value=AntAnt/label/p
/fieldset
Placeholder outputs of 3rd row:
{label}: label for=q3When are you born?/label
{input-html}:
fieldset id=q3
labelMonth:
select name=Month
option value=01January/option
...
/select
/label
labelYear: input type=text name=Year size=4/label
/fieldset
Rows 2 and 3 illustrate the use case. For my original suggestion replace
label with legend in those rows.
This looks somehow consistent to me:
h2label for=question1Favorite pet?/labelh2
fieldset id=question1
plabelinput type=radio name=q1 value=CatCat/label/p
plabelinput type=radio name=q1 value=DogDog/label/p
plabelinput type=radio name=q1 value=AntAnt/label/p
/fieldset
Why is this preferable to:
fieldset
legendFavorite pet?/legend
plabelinput type=radio name=q1 value=CatCat/label/p
plabelinput type=radio name=q1 value=DogDog/label/p
plabelinput type=radio name=q1 value=AntAnt/label/p
/fieldset
It is in a case where you want to output the label/legend separate from
the fieldset HTML, as in the above example.
or:
label
h2Favorite pet?h2
fieldset
plabelinput type=radio name=q1 value=CatCat/label/p
plabelinput type=radio name=q1 value=DogDog/label/p
plabelinput type=radio name=q1 value=AntAnt/label/p
/fieldset
/label
Why is this preferable to the above?
This is not preferable, I just mentioned this as it is the other way
label can be applied.
I don't understand why the fieldset and legend can't be in the
template.
That is how I do it now. The downside of it is the fact that some
themplate authors might forget it - a relevant number of web designers
in fact don't even know about fieldsets, as forms usually work with or
without them. Anyway it is not a big problem; it would just be a nice
enhancement of consistency if the template engine were able to output
*all* form structuring elements.
I don't understand the problem, but if it's not a big problem, then I
would suggest we punt on it until the next version.
I know the HTML5 spec is quite advanced already. Having label for
fieldset (or legend outside it) would make things easier in some
special cases, and maybe also promote the use of fieldsets. If this is a
non-trivial change or even possibly introduces new problems, of course
it might be better to schedule it for later versions.
Re: [whatwg] framesets
pine.lnx.4.62.0910121145480.25...@hixie.dreamhostps.com Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 I guess it's not a HTML5 question but more a best practice question but ... In case an application has navigation menus that cannot be reloaded each time.Only the content part should be reloaded. What is a better 1. Using an iframe for the content and fixing bookmarking/back button 2. Using Ajax to update the content - a single document application The issue with the later option is not user experience but browser performance. Is never reloading the document, only updating the DOM harmful? (like caches wont be cleaned , garbage collection will not be done properly) . Maybe it's browser specific but it also has to do with what browsers are supposed to support and test. Date: Mon, 12 Oct 2009 11:46:37 + From: i...@hixie.ch To: t_gars...@hotmail.com CC: wha...@whatwg.org Subject: RE: [whatwg] framesets On Mon, 12 Oct 2009, tali garsiel wrote: Does pushState apply to bookmarking? Insofar as bookmarking uses the document's current address, yes. (Bookmarking, being a UI feature, isn't defined in HTML5.) -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' _ Windows Live: Make it easier for your friends to see what youre up to on Facebook. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009
Re: [whatwg] Transparent Content
On Mon, Oct 12, 2009 at 8:21 AM, Yuvalik Webdesign postmas...@yuvalik.org wrote: I have an argument with a colleague of mine regarding Transparent elements. He filed a bug regarding this in bugzilla and I wrote to the html5doctor about it with a question, but neither action has answered our question. The way I understand it, a Transparent Element can contain the same elements its direct parent can. The way my colleague understands it, is that a transparent element can be wrapped around any other element. Which is it? Or is it something else? The section about Transparent Content (3.2.5.2) Is not very easy to understand, any chance it could be re-phrased? Specifically this sentence: “When a content model includes a part that is transparent, those parts must not contain content that would not be conformant if all transparent elements in the tree were replaced, in their parent element, by the children in the transparent part of their content model, retaining order.” If I knew what it meant I would offer a suggestion, but I am at a loss as to understand this. Neither of you are *quite* right, but you are much closer to correct than your colleague. A transparent element *must* contain the same kinds of elements that its direct parent can. The meaning of transparent is simply that, if you removed the element but left its children, the document would still be conforming. It does *not* mean that you can wrap a transparent element around anything, as some elements have very specific rules about what children they may have. Frex, you can't wrap an arbitrary transparent element around a td. ~TJ
Re: [whatwg] Is there any reason for the continued existence of enctype attribute at the form element
On 10/11/09 11:06 AM, Mark Kaplun wrote: Boris, I have agreed with your first response that I don't know enough about all the crazy things that people might be doing, to make this attribute to disappear. However I don't see how changing the default mime type will have any affect on the existing web pages It'll change how existing web pages with file controls (whether visible or not) and no enctype set are submitted, right? IMHO this attribute is a bug in the specification which is causing annoyance to any web developer which do not use IDE's to create forms. Changing the default the way I described might create a different annoyance, but in my opinion it will be a much lesser one. My point is that changing the default might not be possible in UAs without causing compat issues with existing pages. It might work, it might not. It'd be a big risk for whichever UA tries it first. -Boris
Re: [whatwg] Transparent Content
From: Tab Atkins Jr. Neither of you are *quite* right, but you are much closer to correct than your colleague. A transparent element *must* contain the same kinds of elements that its direct parent can. The meaning of transparent is simply that, if you removed the element but left its children, the document would still be conforming. It does *not* mean that you can wrap a transparent element around anything, as some elements have very specific rules about what children they may have. Frex, you can't wrap an arbitrary transparent element around a td. So, if I understand correctly I should read: When a content model includes a part that is transparent, that part must not contain content that would not be conformant if the transparent element in the tree would be removed, while retaining the order of the tree. ?
Re: [whatwg] Transparent Content
On Mon, Oct 12, 2009 at 9:52 AM, Yuvalik Webdesign postmas...@yuvalik.org wrote: From: Tab Atkins Jr. Neither of you are *quite* right, but you are much closer to correct than your colleague. A transparent element *must* contain the same kinds of elements that its direct parent can. The meaning of transparent is simply that, if you removed the element but left its children, the document would still be conforming. It does *not* mean that you can wrap a transparent element around anything, as some elements have very specific rules about what children they may have. Frex, you can't wrap an arbitrary transparent element around a td. So, if I understand correctly I should read: When a content model includes a part that is transparent, that part must not contain content that would not be conformant if the transparent element in the tree would be removed, while retaining the order of the tree. ? Yes, that's correct. It's essentially a rewording of what's in the spec (just more focused on the element rather than the parent/children, as the current spec text is). ~TJ
Re: [whatwg] framesets
tali garsiel schrieb: pine.lnx.4.62.0910121145480.25...@hixie.dreamhostps.com Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 I guess it's not a HTML5 question but more a best practice question but ... In case an application has navigation menus that cannot be reloaded each time.Only the content part should be reloaded. What is a better 1. Using an iframe for the content and fixing bookmarking/back button 2. Using Ajax to update the content - a single document application The issue with the later option is not user experience but browser performance. Is never reloading the document, only updating the DOM harmful? (like caches wont be cleaned , garbage collection will not be done properly) . Maybe it's browser specific but it also has to do with what browsers are supposed to support and test. I assume that if you do care about search engines, the Ajax approach will require some amount of extra coding in order to make the content indexable. Anyway, with extra coding you can also match most of Peter's requirements regarding user experience with a single-page solution. I am sure you can pass the state of the navigation tree via query string, and accordingly collapse or expand the nodes when a page is loaded. You can also pass the current scroll position of the page. What may be missing is the possibility to pass the scroll position of the navigation or content, if they are in divs with overflow:scroll. I am not familiar enough with DOM - if they do not yet exist, it might be worth to consider enabling pageYOffset, pageXOffset, scrollBy() and scrollTo() for all element objects that can contain scrollable content rather than for the window object only.
Re: [whatwg] framesets
Ian, 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? I believe Andrew's statement to be incorrect. If your belief is correct, there must be sites which accomplish this spec with tables + iframes (for example). No contributor has managed to point to them. search engines can't index into them (search is a critical part of help systems), pages in them can't easily be bookmarked A DB row is a tree node and it must be possible to block bookmarking of such rows. 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 how we roll here. :-) So I see. It's appalling. PB - Ian Hickson wrote: On Thu, 8 Oct 2009, Peter Brawley wrote: According to http://www.w3.org/TR/2009/WD-html5-diff-20090825/, The following elements are not in HTML 5 because their usage affected usability and accessibility for the end user in a negative way: * frame * frameset * noframes As Andrew Fedoniouk said on this list in 2007 (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 agree wholeheartedly, esp. when the topic list is long (thousands or millions of items) and itself editable, and the required interface is for flexible, independent scrolling of freely choosable bits of the topic tree in the left frame without affecting anything in the right detail frame. As Andrew said, frames are the only good way to do this. New standards ought not to remove required functionalities, ought not to break perfectly good legal working code, and ought not to impose Hobson's choice of keeping functionality vs remaining standards-compliant. How do we get the unwise decision to remove framesets revisited? Except for resizing, anything you can do with framesets, you can do better with iframes and CSS. In addition, with pushState(), you can fix the bookmarking problem in a better way than with framesets. Resizing is something that's harder to do, but that's a presentational issue that we need to fix anyway, independent of frames. Framesets have a number of problems, chief amongst them that bookmarking is dysfunctional, but also that the accessibility story for frames is rather poor, and that there the presentation with frames is much less pleasing than with other features (e.g. in Safari, this page: http://www.artfulsoftware.com/infotree/mysqlquerytree.php ...has a vertical scrollbar for the top frame -- a problem you wouldn't get if instead of four pages, you had three, with the main one containing two iframes from the left and right frames). In addition to iframes, other techniques exist to get similar results, e.g. AJAX. The use case covered by frameset is definitely handled (Getting rid of the frames altogether is probably best, since then tools like search engines can actually return useful links. However, I understand if some authors are unwilling to do the work to get to that point. iframes, on the other hand, are very easy to migrate to.) On Fri, 9 Oct 2009, Peter Brawley wrote: W3C's job is to enable, not function like a commissariat. This isn't the W3C. On Fri, 9 Oct 2009, 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. Actually, you only need to use frames in the frameset page, so if your only concern is what validates, you could just use HTML4 Frameset for the frameset page, and HTML5 for the content pages. But I would still strongly discourage using framesets. On Fri, 9 Oct 2009, Jonas Sicking wrote: The big difference is that iframes can be used in good ways, framesets essentially can't. Another reason do deprecate frameset but not iframe is that we don't need *two* ways to make poorly behaving pages. Indeed. On Fri, 9 Oct 2009, Peter Brawley wrote: 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: [whatwg] framesets
Peter, Can you explain what you mean by A DB row is a tree node and it must be possible to block bookmarking of such rows. a little more? From my understanding, a developer could accomplish this with an onclick handler and some URI arguments, but it seems like you're focused on the browser itself preventing the bookmarking of the link. What would preventing bookmarking by the browser accomplish that an onclick handler that rewrites the URI of the link not accomplish? Mike Ressler On Mon, Oct 12, 2009 at 11:21 AM, Peter Brawley p...@artfulsoftware.comwrote: Ian, 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? I believe Andrew's statement to be incorrect. If your belief is correct, there must be sites which accomplish this spec with tables + iframes (for example). No contributor has managed to point to them. search engines can't index into them (search is a critical part of help systems), pages in them can't easily be bookmarked A DB row is a tree node and it must be possible to block bookmarking of such rows. 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 how we roll here. :-) So I see. It's appalling. PB - Ian Hickson wrote: On Thu, 8 Oct 2009, Peter Brawley wrote: According to http://www.w3.org/TR/2009/WD-html5-diff-20090825/, The following elements are not in HTML 5 because their usage affected usability and accessibility for the end user in a negative way: * frame * frameset * noframes As Andrew Fedoniouk said on this list in 2007 (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 agree wholeheartedly, esp. when the topic list is long (thousands or millions of items) and itself editable, and the required interface is for flexible, independent scrolling of freely choosable bits of the topic tree in the left frame without affecting anything in the right detail frame. As Andrew said, frames are the only good way to do this. New standards ought not to remove required functionalities, ought not to break perfectly good legal working code, and ought not to impose Hobson's choice of keeping functionality vs remaining standards-compliant. How do we get the unwise decision to remove framesets revisited? Except for resizing, anything you can do with framesets, you can do better with iframes and CSS. In addition, with pushState(), you can fix the bookmarking problem in a better way than with framesets. Resizing is something that's harder to do, but that's a presentational issue that we need to fix anyway, independent of frames. Framesets have a number of problems, chief amongst them that bookmarking is dysfunctional, but also that the accessibility story for frames is rather poor, and that there the presentation with frames is much less pleasing than with other features (e.g. in Safari, this page: http://www.artfulsoftware.com/infotree/mysqlquerytree.php ...has a vertical scrollbar for the top frame -- a problem you wouldn't get if instead of four pages, you had three, with the main one containing two iframes from the left and right frames). In addition to iframes, other techniques exist to get similar results, e.g. AJAX. The use case covered by frameset is definitely handled (Getting rid of the frames altogether is probably best, since then tools like search engines can actually return useful links. However, I understand if some authors are unwilling to do the work to get to that point. iframes, on the other hand, are very easy to migrate to.) On Fri, 9 Oct 2009, Peter Brawley wrote: W3C's job is to enable, not function like a commissariat. This isn't the W3C. On Fri, 9 Oct 2009, 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. Actually, you only need to use frames in the frameset page, so if your only concern is what validates, you could just use HTML4 Frameset for the frameset page, and HTML5 for the content pages.
Re: [whatwg] Is there any reason for the continued existence of enctype attribute at the form element
Boris Zbarsky wrote: On 10/11/09 11:06 AM, Mark Kaplun wrote: Boris, I have agreed with your first response that I don't know enough about all the crazy things that people might be doing, to make this attribute to disappear. However I don't see how changing the default mime type will have any affect on the existing web pages It'll change how existing web pages with file controls (whether visible or not) and no enctype set are submitted, right? Is there any reason why someone will do such a thing by design? unless there is some exotic reason, this is an example to a form which do not perform its role. In any case the doctype for this kind of old pages will not be html 5 IMHO this attribute is a bug in the specification which is causing annoyance to any web developer which do not use IDE's to create forms. Changing the default the way I described might create a different annoyance, but in my opinion it will be a much lesser one. My point is that changing the default might not be possible in UAs without causing compat issues with existing pages. It might work, it might not. It'd be a big risk for whichever UA tries it first. -Boris This is kind of an egg and a chicken problem. Currently the standards specifies the application/x-www-form-urlencoded mime as default, and if the standard remains the same the UA will not be able to change their behavior.
Re: [whatwg] framesets
On Mon, Oct 12, 2009 at 10:21 AM, Peter Brawley p...@artfulsoftware.com wrote: A DB row is a tree node and it must be possible to block bookmarking of such rows. You keep implying that frames make it possible to block bookmarking. They do not. Anyone can right click-open frame and then just bookmark that page. Frames do make it more difficult for the casual user to bookmark things, but if you're relying on this for some sort of security, you're being very naive in believing that *anything* client-side will work. You need to implement this protection server-side for it to be reliable. Frames are not the correct answer to this requirement. ~TJ
Re: [whatwg] Is there any reason for the continued existence of enctype attribute at the form element
On 10/12/09 11:32 AM, Mark Kaplun wrote: Is there any reason why someone will do such a thing by design? unless there is some exotic reason, this is an example to a form which do not perform its role. That depends on whether the server actually expects to get anything from the file input. In any case the doctype for this kind of old pages will not be html 5 Why does that matter? The point is that browser behavior will NOT depend on the doctype but rather HTML5 will be backwards compatible with existing behavior. This is kind of an egg and a chicken problem. Currently the standards specifies the application/x-www-form-urlencoded mime as default, and if the standard remains the same the UA will not be able to change their behavior. The UA can't change behavior not because of the standard but because of existing content that might be relying on that behavior. If it's shown there is no such content, then changing is easy: you just change UAs and the standard, in any desired order. -Boris
Re: [whatwg] framesets
Mike, Can you explain what you mean by A DB row is a tree node and it must be possible to block bookmarking of such rows. a little more? From my understanding, a developer could accomplish this with an onclick handler and some URI arguments, but it seems like you're focused on the browser itself preventing the bookmarking of the link. There are good database reasons to block bookmarks to table rows, so that must be doable. That user requirement conflicts with the judgement, often voiced by HTML standards custodians, that frames are bad because they screw up bookmarking. The use case that mainly motivates my objection to this says that the datatree maintenance page must function as a black box with no internal HTML bookmarking at all---except for exit, navigation must be controlled entirely by database/tree logic. The argument is not, therefore, that HTML5 should support new methods of bookmark blocking. The argument is that for this use case, which is best served by framesets till proved otherwise (and no-one has yet), the bookmark objection to framesets is invalid. Yes I agree there are lots of ways to block data bookmarking. PB -- Mike Ressler wrote: Peter, Can you explain what you mean by A DB row is a tree node and it must be possible to block bookmarking of such rows. a little more? From my understanding, a developer could accomplish this with an onclick handler and some URI arguments, but it seems like you're focused on the browser itself preventing the bookmarking of the link. What would preventing bookmarking by the browser accomplish that an onclick handler that rewrites the URI of the link not accomplish? Mike Ressler On Mon, Oct 12, 2009 at 11:21 AM, Peter Brawley p...@artfulsoftware.com mailto:p...@artfulsoftware.com wrote: Ian, 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? I believe Andrew's statement to be incorrect. If your belief is correct, there must be sites which accomplish this spec with tables + iframes (for example). No contributor has managed to point to them. search engines can't index into them (search is a critical part of help systems), pages in them can't easily be bookmarked A DB row is a tree node and it must be possible to block bookmarking of such rows. 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 how we roll here. :-) So I see. It's appalling. PB - Ian Hickson wrote: On Thu, 8 Oct 2009, Peter Brawley wrote: According to http://www.w3.org/TR/2009/WD-html5-diff-20090825/, The following elements are not in HTML 5 because their usage affected usability and accessibility for the end user in a negative way: * frame * frameset * noframes As Andrew Fedoniouk said on this list in 2007 (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 agree wholeheartedly, esp. when the topic list is long (thousands or millions of items) and itself editable, and the required interface is for flexible, independent scrolling of freely choosable bits of the topic tree in the left frame without affecting anything in the right detail frame. As Andrew said, frames are the only good way to do this. New standards ought not to remove required functionalities, ought not to break perfectly good legal working code, and ought not to impose Hobson's choice of keeping functionality vs remaining standards-compliant. How do we get the unwise decision to remove framesets revisited? Except for resizing, anything you can do with framesets, you can do better with iframes and CSS. In addition, with pushState(), you can fix the bookmarking problem in a better way than with framesets. Resizing is something that's harder to do, but that's a presentational issue that we need to fix anyway, independent of frames. Framesets have a number of problems, chief amongst them that bookmarking is dysfunctional, but also that the accessibility story for frames is rather poor, and that there the presentation with
Re: [whatwg] framesets
On Mon, Oct 12, 2009 at 5:21 PM, Peter Brawley wrote: 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? I believe Andrew's statement to be incorrect. If your belief is correct, there must be sites which accomplish this spec with tables + iframes (for example). No contributor has managed to point to them. What's wrong or missing in MSDN and/or Google Documentation Reader? http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5 -- Thomas Broyer /tɔ.ma.bʁwa.je/
Re: [whatwg] framesets
On Mon, Oct 12, 2009 at 6:01 PM, Peter Brawley p...@artfulsoftware.com wrote: The use case that mainly motivates my objection to this says that the datatree maintenance page must function as a black box with no internal HTML bookmarking at all---except for exit, navigation must be controlled entirely by database/tree logic. The argument is not, therefore, that HTML5 should support new methods of bookmark blocking. The argument is that for this use case, which is best served by framesets till proved otherwise (and no-one has yet), the bookmark objection to framesets is invalid. You have not proven why this use case [...] is best served by framesets either. Actually, framesets alone don't answer your requirement, you have to add: - a bit of JavaScript to use location.replace(...) in your links to simulate a single page application - a bit of something to block bookmarking (user cannot use right click - open this frame in a new tab/window); unless we don't have the same definition for no internal HTML bookmarking I say that your use case is best served by AJAX (à la Google Document Reader, just without the history trick using the location's hash). -- Thomas Broyer /tɔ.ma.bʁwa.je/
Re: [whatwg] framesets
There are good database reasons to block bookmarks to table rows, so that must be doable. I still don't get what database has to do with it? block bookmars to table rows? Does it make any sense at all? … Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] framesets
Peter, Thanks for the clarification, I think I have a little better understanding now. (Sorry I jumped into the mailing list in the middle of the conversation and missed some of the earlier context) Are we currently discussing implementation details around a proposed tree structure control? I heard a few people talk about framesets vs. frames vs. divs, but I thought the proposal was that there would be a new tree tag? I guess my confusion lies in why frames framesets are being discussed at all. The black box part of the tree view has me a little confused as well. I would think that such a structure would benefit greatly by allowing JavaScript access to its elements. And if such access to its internal elements were available, then why wouldn't a developer simply implement one of the many ways to block data bookmarking that you and I are aware of? I was envisioning a tree tag that would support expanding and collapsing rows without forcing the developer to jump through fire-y JavaScript hoops to get the implementation correct. Then any modification to the tree would be handled by the application developer via JavaScript or through a new page view. Am I way off base? Mike Ressler On Mon, Oct 12, 2009 at 12:01 PM, Peter Brawley p...@artfulsoftware.comwrote: Mike, Can you explain what you mean by A DB row is a tree node and it must be possible to block bookmarking of such rows. a little more? From my understanding, a developer could accomplish this with an onclick handler and some URI arguments, but it seems like you're focused on the browser itself preventing the bookmarking of the link. There are good database reasons to block bookmarks to table rows, so that must be doable. That user requirement conflicts with the judgement, often voiced by HTML standards custodians, that frames are bad because they screw up bookmarking. The use case that mainly motivates my objection to this says that the datatree maintenance page must function as a black box with no internal HTML bookmarking at all---except for exit, navigation must be controlled entirely by database/tree logic. The argument is not, therefore, that HTML5 should support new methods of bookmark blocking. The argument is that for this use case, which is best served by framesets till proved otherwise (and no-one has yet), the bookmark objection to framesets is invalid. Yes I agree there are lots of ways to block data bookmarking. PB -- Mike Ressler wrote: Peter, Can you explain what you mean by A DB row is a tree node and it must be possible to block bookmarking of such rows. a little more? From my understanding, a developer could accomplish this with an onclick handler and some URI arguments, but it seems like you're focused on the browser itself preventing the bookmarking of the link. What would preventing bookmarking by the browser accomplish that an onclick handler that rewrites the URI of the link not accomplish? Mike Ressler On Mon, Oct 12, 2009 at 11:21 AM, Peter Brawley p...@artfulsoftware.comwrote: Ian, 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? I believe Andrew's statement to be incorrect. If your belief is correct, there must be sites which accomplish this spec with tables + iframes (for example). No contributor has managed to point to them. search engines can't index into them (search is a critical part of help systems), pages in them can't easily be bookmarked A DB row is a tree node and it must be possible to block bookmarking of such rows. 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 how we roll here. :-) So I see. It's appalling. PB - Ian Hickson wrote: On Thu, 8 Oct 2009, Peter Brawley wrote: According to http://www.w3.org/TR/2009/WD-html5-diff-20090825/, The following elements are not in HTML 5 because their usage affected usability and accessibility for the end user in a negative way: * frame * frameset * noframes As Andrew Fedoniouk said on this list in 2007 (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 agree wholeheartedly, esp. when the topic list is long (thousands or millions of items) and itself editable, and the
Re: [whatwg] Some discrepencies and example remarks
From: Ian Hickson [mailto:i...@hixie.ch] Please file specific bugs or send specific e-mails for each example you think should be reworked; there are over 300 examples in the spec and without knowing what is wrong with each one, if I just go through them all and change them, they're just going to go from one kind of bad example to another kind of bad example. So I decided to start already with an example. I went through some old code to find a suitable use-case and I found one that I think might be beneficial since it is used quite often on all sorts of sites in one shape or another. But right from the start I get stuck. The existing (HTML4) code is as follows: The page has a header and a footer which we will disregard for the sake of this example. Between this header and footer we have: div id=detail img src=example1.jpg / /div ul lia href=example1.jpgimg src=example1_thmb.jpg //a/li lia href=example2.jpgimg src=example2_thmb.jpg //a/li lia href=example3.jpgimg src=example3_thmb.jpg //a/li lia href=example4.jpgimg src=example4_thmb.jpg //a/li /ul So in essence, we are talking about a portfolio (with some AJAX in the background which we will ignore). Clicking on a thumbnail in the ul will show the detailed picture inside the div. I left out arguments which have no bearing on the discussion. Depending on your point of view one will or will not call this an application, so in itself it is a good example of ambiguous content. How should this be redone in HTML5? I come across the following questions: 1) Should this entire code be wrapped in a section? The argument for it being that this entire portfolio should show up in the outline as a whole. The argument against it being that since it is the only content on the page no section is needed and that it is conceivable that in the future extra content could be added in between the div and the ul which is not related to either. 2) Should the div be replaced by section? The argument being that this detail-picture is actually the main content of the page and could also include extra information (like a textual description) in the future. The argument against is simply that the img is adequately semantic and the div is there only for lay-out/scripting. 3) Should the ul be wrapped in an aside? Since it is definitely related to the detail-picture. But see also 5) 4) Should the ul be replaced by a nav? Argument for it is that clicking on a thumbnail changes (part of) the page and is therefore not a true list of items but a form of navigation. The argument against is that it is highly debatable if this constitutes a real form of navigation. 5) Now stretching a bit, it is conceivable that someone may argue that the thumbnails are actually the main-content and that the detail-picture is nothing more than a detail of part of that content. Evert
Re: [whatwg] Some discrepencies and example remarks
On Mon, Oct 12, 2009 at 11:18 AM, Yuvalik Webdesign postmas...@yuvalik.org wrote: From: Ian Hickson [mailto:i...@hixie.ch] Please file specific bugs or send specific e-mails for each example you think should be reworked; there are over 300 examples in the spec and without knowing what is wrong with each one, if I just go through them all and change them, they're just going to go from one kind of bad example to another kind of bad example. So I decided to start already with an example. I went through some old code to find a suitable use-case and I found one that I think might be beneficial since it is used quite often on all sorts of sites in one shape or another. But right from the start I get stuck. The existing (HTML4) code is as follows: The page has a header and a footer which we will disregard for the sake of this example. Between this header and footer we have: div id=detail img src=example1.jpg / /div ul lia href=example1.jpgimg src=example1_thmb.jpg //a/li lia href=example2.jpgimg src=example2_thmb.jpg //a/li lia href=example3.jpgimg src=example3_thmb.jpg //a/li lia href=example4.jpgimg src=example4_thmb.jpg //a/li /ul So in essence, we are talking about a portfolio (with some AJAX in the background which we will ignore). Clicking on a thumbnail in the ul will show the detailed picture inside the div. I left out arguments which have no bearing on the discussion. Depending on your point of view one will or will not call this an application, so in itself it is a good example of ambiguous content. How should this be redone in HTML5? I come across the following questions: 1) Should this entire code be wrapped in a section? The argument for it being that this entire portfolio should show up in the outline as a whole. The argument against it being that since it is the only content on the page no section is needed and that it is conceivable that in the future extra content could be added in between the div and the ul which is not related to either. No need if, as you say, this is the only content on the page (+ header and footer). body is an implicit sectioning root. 2) Should the div be replaced by section? The argument being that this detail-picture is actually the main content of the page and could also include extra information (like a textual description) in the future. The argument against is simply that the img is adequately semantic and the div is there only for lay-out/scripting. Without any further context, I'm going to assume that the div is indeed purely a styling/scripting hook. In that case, it should remain a div. 3) Should the ul be wrapped in an aside? Since it is definitely related to the detail-picture. But see also 5) Definitely not; it's part of the application. From your snippet, the page seems to be built as a picture-app, which means both the image and the thumbnails work together; neither is tangential to the purpose of the page like a sidebar would be. 4) Should the ul be replaced by a nav? Argument for it is that clicking on a thumbnail changes (part of) the page and is therefore not a true list of items but a form of navigation. The argument against is that it is highly debatable if this constitutes a real form of navigation. No, it probably shouldn't be a nav. It's possible to argue for it, but this probably isn't a primary navigation for the page. It's just part of the application. 5) Now stretching a bit, it is conceivable that someone may argue that the thumbnails are actually the main-content and that the detail-picture is nothing more than a detail of part of that content. Nah, both pieces work together to create the application. Arguing that is really esoteric semantic-hacking, and isn't necessary. ~TJ
Re: [whatwg] Some discrepencies and example remarks
From: Tab Atkins Jr. Definitely not; it's part of the application. From your snippet, the page seems to be built as a picture-app, which means both the image and the thumbnails work together; neither is tangential to the purpose of the page like a sidebar would be. I think this is the core of the problem. There is a large grey area where design and development overlap. Most designers would most definitely *not* call this an app, but I guess most developers would. The line between designer and developer is not clearly marked, there is consensus on both side of the spectrum at the end, but the more you get towards the middle, the less clear it becomes. Suppose the example I gave looks like this: iframe src=example1_jpg.html name=detail p A long story regarding the companies' origins and goals... /p div id=advert.../div ul lia target=detail href=example1_jpg.htmlimg src=example1_thmb.jpg //a/li lia target=detail href=example2_jpg.htmlimg src=example2_thmb.jpg //a/li lia target=detail href=example3_jpg.htmlimg src=example3_thmb.jpg //a/li lia target=detail href=example4_jpg.htmlimg src=example4_thmb.jpg //a/li /ul First of all, this example works more or less the same as the other one, except this time there is no scripting, so could it technically still be called an application? Secondly, it divides the detail-picture from the thumbnails with oodles of non related content. Now, if this means the mark-up in this example should be different from the previous example, this means the mark-up is therefore not JUST semantic-related, and that would defy the main intent of HTML5 if I am not mistaken? I hope I am making my point clear? Evert
Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.
On Sun, Oct 11, 2009 at 11:57 PM, Henri Sivonen hsivo...@iki.fi wrote: On Oct 10, 2009, at 08:20, Maciej Stachowiak wrote: 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. I disagree unless we really want to enable http-equiv as a way of specifying browser-only HTTP header equivalents that intermediaries ignore. It's already done. That horse has left the barn. OTOH, if we want to enable only pragmas that the HTML layer must recognize for backwards-compatibility, enumerating the permitted values is quite reasonable. As for X-UA-Compatible specifically, when Microsoft did it, it was decried as a bad thing. Why does it become a good thing when Google does it? I disagree both with the assertion that MSFT's original proposal was bad and also that there's some different standard that should be implicit based on who's doing it. The approach is valuable in the real world where fixed investments actually *do* cause market distortions. MSFT's original proposal had merit (although I dislike the solution they eventually shipped). I can see one crucial difference: In IE8 without Chrome Frame (when your domain isn't blacklisted), X-UA-Compatible is a mechanism for opting into a legacy engine. As long as being able to implement the legacy complexity is advantageous in use retention/acquisition, sites opting into legacy IE behavior enable a lock-in to IE. You're basing this assumption on the follow chain of events: 1.) many browsers jettison compatibility with proprietary or deprecated technology 2.) enterprises upgrade their browsers, finding that old sites no longer work 3.) enterprises find that they have incentive to upgrade their sites to modern standards This doesn't represent some large chunk of the problem. Instead, we see that: 1.) many browsers jettison compatibility with proprietary or deprecated technology 2.) enterprises understand this, so they actively resist deploying new renderers 3.) renderer exclusivility in the browser market causes adverse selection against web developers, shifting costs to them, distorting the market for renderer features and reducing developer ability to adopt new browser features sooner, even on new projects Hixie's favored approach is very likely to have the effect new renderers are adopted more slowly because of these dynamics. chrome=1 is more similar to IE=Edge than opting into a legacy IE. Yep. Regardless, we're pretty far afield. The question I'd like to understand the group's thinking on is: can the http-equiv meta variant be brought into line with real-world usage by the HTML 5 spec? However, another way of viewing this is that if user switched from IE to Chrome proper (or Firefox or Safari or Opera), *other* sites would be less able to use IE-only code. However, both IE=Edge and chrome=1 let users *also* keep the hard-to-clone legacy complexity for *other* sites. If this creates a situation where IE+Chrome Frame is the most compatible browser, the outcome isn't necessarily good for the overall health of the Web, since the IE part would still lock the user into Windows and even within Windows out of Gecko or Presto. You're making a value judgement about what's good for the web based on an instantaneous view. What's to keep *any* renderer from holding the web back in the same way that NN4 once did? That's a question of market dynamics, not the intent of individual actors. I want a web where we're not beholden to the whims of *any* individual organization. Chrome Frame is designed to hasten the arrival of that future and the behavior of IE=Edge and chrome=1 are an important part of that change. I'll argue strongly that both are important in delivering a web that is compatible, more future-proof (the assumption with both is that things WILL change), and less silo'd as a result of the assumption that things will continue to change. The baseline is a temporary artifact of the transition to a better, faster-evolving world. Regards I guess it's too early to tell if Chrome Frame will have an overall positive impact (making authors write to the multi-vendor interoperable platform without having to write a special code path for one vendor) or whether it'll have an overall negative impact either strengthening IE or leading authors to write WebKit-only code (or even Chrome-only code). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.
On Sun, Oct 11, 2009 at 11:39 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 7 Oct 2009, Alex Russell wrote: 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. It is onerous intentionally; the idea is to reduce the use of this mechanism, as it has almost universally been misused. 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. Server and client authors have used the X-* convention to denote such extension fields as a forward-compatible prefix. In order for HTML 5 to better represent real-world content, we'd like to request that an exception be made to the registered via RFC rule for http-equiv headers which are prefixed with X-, or, alternately, that the spec simply declare that unlisted keys and values will not be considered invalid, but rather that only invalid values for listed keys trigger validity errors. This would make X-UA-Compatible conforming, which is not desireable. We want to _discourage_ mechanisms that lead to vendor-targetting of that nature. On Fri, 9 Oct 2009, Maciej Stachowiak wrote: 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. Indeed. On Fri, 9 Oct 2009, Julian Reschke wrote: 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]. (http://tools.ietf.org/html/rfc3864#section-4.1) The HTML5 requirement goes further than the IETF requirement; I would consider that a bug. On Fri, 9 Oct 2009, Maciej Stachowiak wrote: 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. Done. So just to clarify: should we standardize X-UA-Compatible at the IETF, the validator would no longer complain about it, assuming that you'll accept it in the wiki (which I'd like to be clear on)? Regards
Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.
Alex Russell wrote: ... So just to clarify: should we standardize X-UA-Compatible at the IETF, the validator would no longer complain about it, assuming that you'll accept it in the wiki (which I'd like to be clear on)? ... To standardize it in the IETF, it would probably need to be renamed, though. BR, Julian
Re: [whatwg] framesets
Thomas, What's wrong or missing in MSDN and/or Google Documentation Reader? http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5 The Google solution needs at least 1,100 lines of JavaScript (perhaps much more, can't get at all the code). I need 120. The MSDN solution looks like a huge OS-dependent hack. As is, both expose node bookmarking, and I can't make out how either would behave if tree pruning node edits were added. PB
Re: [whatwg] Navigation events generated during unload
On 10/12/09 1:55 AM, Ian Hickson wrote: Why is the form.submit() ignored? It's not ignored in, e.g.: http://www.hixie.ch/tests/adhoc/html/navigation/unload/same-origin/004.html But in this case the form action is same-origin with the load that's happening Oops, that's a vestigial bit. The comment is non-normative (and wrong); the actual normative text makes javascript: async, only about:blank is sync. Fixed. Ah, ok. Thanks. Also, I'm not quite sure what the part about unloading that comes after the algorithm you pointed me to means. Does it mean that once you get the response and start parsing the new document you queue a task to unload the old one? That doesn't seem at all right to me, since at this point the new document can be running scripts that touch the WindowProxy they share... Not sure what you mean here. I've tried to clarify that the new page must be active before any scripts run. Looking at the algorithm steps when I made my last comment, it sounded like the new data starts coming in, the UA starts processing it, and queues a task to unload the old document. Gecko at the moment, for example, unloads the old document immediately after firing unload on it, and before parsing any of the new document. Is that the behavior the spec calls for? -Boris
Re: [whatwg] Some discrepencies and example remarks
On Mon, Oct 12, 2009 at 1:56 PM, Yuvalik Webdesign postmas...@yuvalik.org wrote: From: Tab Atkins Jr. iframe src=example1_jpg.html name=detail p A long story regarding the companies' origins and goals... /p div id=advert.../div ul lia target=detail href=example1_jpg.htmlimg src=example1_thmb.jpg //a/li lia target=detail href=example2_jpg.htmlimg src=example2_thmb.jpg //a/li lia target=detail href=example3_jpg.htmlimg src=example3_thmb.jpg //a/li lia target=detail href=example4_jpg.htmlimg src=example4_thmb.jpg //a/li /ul I don't think the markup should be any different. The thumbnails still appear to be part of the content. The advert in the middle should probably be an aside, though. ^_^ Ok, thanks. But shouldn't the iframe and the p be in separate sections? (seeing as they are not related to each other). Depends. Would you put heading on each of those? If so, then sure. That's the most basic determining criteria for if a section should be used. If you wouldn't, then no. Sometimes things just mash together like that. ~TJ
Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.
On Oct 12, 2009, at 11:02 AM, Julian Reschke wrote: Alex Russell wrote: ... So just to clarify: should we standardize X-UA-Compatible at the IETF, the validator would no longer complain about it, assuming that you'll accept it in the wiki (which I'd like to be clear on)? ... To standardize it in the IETF, it would probably need to be renamed, though. And the standard would have to describe what it actually does, which would probably require some input from Microsoft. At some point, to advance on the IETF standards track, it would need multiple interoperable implementations. That prospect does not seem likely. Regards, Maciej
Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.
Am Mon, 12 Oct 2009 14:24:20 -0700 schrieb Jonas Sicking jo...@sicking.cc: […] Unless you count IE-based browsers, such as maxathon, a separate implementation. / Jonas Which we don't because they do not have a seperate rendering engine, amirite? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net signature.asc Description: PGP signature
Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.
Maciej Stachowiak wrote: On Oct 12, 2009, at 11:02 AM, Julian Reschke wrote: Alex Russell wrote: ... So just to clarify: should we standardize X-UA-Compatible at the IETF, the validator would no longer complain about it, assuming that you'll accept it in the wiki (which I'd like to be clear on)? ... To standardize it in the IETF, it would probably need to be renamed, though. And the standard would have to describe what it actually does, which would probably require some input from Microsoft. At some point, to advance on the IETF standards track, it would need multiple interoperable implementations. That prospect does not seem likely. That would be true for the transition from Proposed to Draft Standard. Few specs ever get here. Best regards, Julian
Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.
On Mon, Oct 12, 2009 at 5:14 PM, Maciej Stachowiak m...@apple.com wrote: And the standard would have to describe what it actually does, which would probably require some input from Microsoft. At some point, to advance on the IETF standards track, it would need multiple interoperable implementations. That prospect does not seem likely. You could define a generic syntax that allows any browser to use XUAC, and count IE and Chrome Frame as independent interoperable implementations. Of course, they'd respond to the header in slightly different ways (keying off different strings), but only as required by the spec.
Re: [whatwg] Drag-and-drop feedback
On Mon, Oct 12, 2009 at 4:37 AM, Ian Hickson i...@hixie.ch wrote: On Sun, 11 Oct 2009, Garrett Smith wrote: My question is: Which browser does document.initDragEvent work in? Do you mean DragEvent.initDragEvent? AH, yeah. The event is under MouseEvent, then? So:- document.createEvent(MouseEvents); Document.initDragEvent is inordinately long and cumbersome, taking 16 arguments, and requiring the creation of a DataTransfer object. That seems extremely cumbersome just to get a drag event to fire. This method doesn't seem to be implemented anywhere FWICT. Was it copied from an existing implementation? It seems to have been an invention. But whose? It's just the usual way things are done for events. I'll follow whatever DOM3 Events says to do. Sorry, but I don't see how that answers my questions. It seems it was not copied from existing implementations, but was instead an invention. Who wrote that API? Garrett
Re: [whatwg] keyboard behaviour inside of editable area
Hi, Ian. Thank you for the answer. AFAIK usually accessibility people tend to define kind of universal behaviour on mouse/keyboard interaction depending on OS of course. This case is probably not this one and behaviour should be implementation dependent. I'm not sure. Therefore I brought this issue for discussion. I'm happy you find the described behaviour reasonable. Thank you again. Alex. On Mon, Oct 12, 2009 at 3:04 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 8 Oct 2009, Alexander Surkov wrote: The suggestion is to treat control element as special character, i.e. when you move through the text by arrow keys and control element is met then control element should be focused and its selection should be changed appropriately. When control has the focus then keyboard behaviour is defined by control preferences with once exception. If particular navigation key isn't processed by control or doesn't have any defined action then editor rules are applied. This seems reasonable (though I'd prefer to study it in a usability lab before making a stronger statement), but it also seems like an implementation detail -- there's nothing that really requires that the user agent even support arrow keys, let alone that they work in a particular way. Cheers, -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag-and-drop feedback
On Mon, 12 Oct 2009, Garrett Smith wrote: On Mon, Oct 12, 2009 at 4:37 AM, Ian Hickson i...@hixie.ch wrote: On Sun, 11 Oct 2009, Garrett Smith wrote: My question is: Which browser does document.initDragEvent work in? Do you mean DragEvent.initDragEvent? AH, yeah. The event is under MouseEvent, then? So:- document.createEvent(MouseEvents); It's a DragEvent, so you have to do: document.createEvent(DragEvent); Document.initDragEvent is inordinately long and cumbersome, taking 16 arguments, and requiring the creation of a DataTransfer object. That seems extremely cumbersome just to get a drag event to fire. This method doesn't seem to be implemented anywhere FWICT. Was it copied from an existing implementation? It seems to have been an invention. But whose? It's just the usual way things are done for events. I'll follow whatever DOM3 Events says to do. Sorry, but I don't see how that answers my questions. It seems it was not copied from existing implementations, but was instead an invention. Who wrote that API? The DragEvent interface is new in HTML5, but it uses the same conventions as all interfaces that inherit from Event. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] localStorage feedback
On Thu, 17 Sep 2009, Jeremy Orlow wrote:
On Thu, Sep 17, 2009 at 1:32 AM, Ian Hickson i...@hixie.ch wrote:
I think we should be very careful before introducing a fourth storage
mechanism to make sure that whatever we introduce really is something
that's going to be very useful and really solve problems. I'd really
rather not rush into adding yet another mechanism at this point.
Sure. But what about the other idea Robert and Drew had (in the workers +
local storage thread) about just having a WorkerLocalStorage mechanism?
That's a fourth storage mechanism, so my comments above apply.
On Wed, 23 Sep 2009, Brett Cannon wrote:
Before the move to structured clones one could tell if a key was set by
calling getItem() and seeing if it returned null (had to use === as
someone could have called setItem() w/ null, but that would be coerced
to a string for storage). But with the latest draft's switch to
structured clones that test no longer clearly differentiates between
whether the value returned by getItem() signifies that the key was not
set, or the key was set with the value null.
I believe you can test if a key is in the storage area using:
if (key in storage) { ... }
For example:
if ('document' in window.localStorage) { ... }
And since I just subscribed to the mailing list, I was wondering if the
whole workers/localStorage discussion ended or not, as I can provide a
(potentially minor) real-world use-case for sharing access between the
page and worker if people want to hear it (in a new email of course).
I think everyone agrees that we need a storage mechanism in workers; the
question is what it should be. That's basically the same as the question
of what should happen with the Web Database spec -- I don't think we would
want to end up with multiple storage systems in workers. The answer to
this question depends on the result of this debate in the Web Apps WG.
On Wed, 23 Sep 2009, Jeremy Orlow wrote:
What are the use cases for wanting to store data beyond strings (and
what can be serialized into strings) in LocalStorage? I can't think of
any that outweigh the negatives:
1) From previous threads, I think it's fair to say that we can all
agreed that LocalStorage is a regrettable API (mainly due to its
synchronous nature). If so, it seems that making it more powerful and
thus more attractive to developers is just asking for trouble. After
all, the more people use it, the more lock contention there'll be, and
the more browser UI jank users will be sure to experience. This will
also be worse because it'll be easier for developers to store large
objects in LoaclStorage.
2) As far as I can tell, there's no where else in the spec where you
have to serialize structured clone(able) data to disk. Given that
LocalStorage is supposed to throw an exception if any ImageData is
contained and since File and FileData objects are legal, it seems as
though making LocalStorage handle structured clone data has a fairly
high cost to implementors. Not to mention that disallowing ImageData in
only this one case is not intuitive.
I think allowing structured clone(able) data in LocalStorage is a big
mistake. Enough so that, if SessionStorage and LocalStorage can't
diverge on this issue, it'd be worth taking the power away from
SessionStorage.
The main use case is storing File objects when offline for later upload. I
think that far outweighs the negatives you list above. We need this, and
there's no other storage mechanism that everyone agrees is good enough.
the problem here is that localStorage is a pile of global variables.
we are trying to give people global variables without giving them tools
to synchronize access to them. the claim i've heard is that developers
are not savy enough to use those tools properly. i agree that
developers tend to use tools without fully understanding them. ok, but
then why are we giving them global variables?
The global variables have implicit locks such that you can build the tools
for explicit locking on top of them:
// run this first, in one script block
var id = localStorage['last-id'] + 1;
localStorage['last-id'] = id;
localStorage['email-ready-' + id] = 0; // begin
// these can run each in separate script blocks as desired
localStorage['email-subject-' + id] = subject;
localStorage['email-from-' + id] = from;
localStorage['email-to-' + id] = to;
localStorage['email-body-' + id] = body;
// run this last
localStorage['email-ready-' + id] = 1; // commit
On Thu, 24 Sep 2009, Darin Fisher wrote:
The current API exposes race conditions to the web. The implicit
dropping of the storage lock is that. In Chrome, we'll have to drop an
existing lock whenever a new lock is acquired. That can happen due to a
variety of really odd cases (usually related to nested loops or nested
JS execution), which will be difficult for
Re: [whatwg] localStorage feedback
On Tue, Oct 13, 2009 at 3:07 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 9 Sep 2009, Darin Fisher wrote: What about navigating an iframe to a reference fragment, which could trigger a scroll event? The scrolling has to be done synchronously for compat with the web. You can only do that with same-domain pages, as far as I can tell. (Does that really have to be synchronous? Later in the thread I mentioned that in Gecko, the 'scroll' event is asynchronous, which suggests that Web compatibility does not require it to be synchronous. Right now we don't define the 'scroll' event anywhere. What are the semantics it needs?) Perhaps it should be defined in CSSOM, alongside scrollTop/scrollLeft? In Gecko, it's just something that fires asynchronously after a node's scrollTop/scrollLeft have changed. Scroll events for the viewport fire at the document and bubble to the window, scroll events on elements with 'overflow' not 'visible' fire at that element and don't bubble. 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] 4.10.5 - value of hidden inputs
On Mon, 12 Oct 2009 01:44:39 + (UTC), Ian Hickson i...@hixie.ch wrote: On Tue, 6 Oct 2009, Kartikaya Gupta wrote: [...] Fixed the spec. That works, thanks. kats
Re: [whatwg] X-UA-Compatible, X-* headers, validators, etc.
On Mon, Oct 12, 2009 at 3:38 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Mon, Oct 12, 2009 at 5:14 PM, Maciej Stachowiak m...@apple.com wrote: And the standard would have to describe what it actually does, which would probably require some input from Microsoft. At some point, to advance on the IETF standards track, it would need multiple interoperable implementations. That prospect does not seem likely. You could define a generic syntax that allows any browser to use XUAC, and count IE and Chrome Frame as independent interoperable implementations. Of course, they'd respond to the header in slightly different ways (keying off different strings), but only as required by the spec. That's what I was considering. Only token parsing for the values really needs to be defined. Behavior in response does not.
