elements are included in the outline[2]. The current model excludes all subtitles from the outline. Assuming that subtitles should not be included in the outline (eg to make sure the highest-ranked title is indeed descriptive), what if

by default masked subtitles from the outline algorithm as currently does? This would mean is no longer necessary, and make

less optional (it currently feels like solely a CSS hook from an author perspective). Currently #the-header-element[3] mentions a ?Little Green Guys With Guns? example in which

-

elements in the
but outside create implied
elements via the outline algorithm. If
hides all but one
-
element this won?t happen (this is also a potential issue with the Boolean attribute idea). While the spec states authors should add wrapping
s I suspect many won?t bother and rely on implied ones (unless they need CSS hooks). This would also be potentially confusing compared with
, and possibly encourage authors to mistakenly add
s with
s inside of a
(copy&paste mistakes etc). While this idea has drawbacks I feel ?s lack of tangible author benefit and ?occasional use? nature will result in it not being widely used when it should be. I?d like to hear your opinion on both this idea and the Superfriends Boolean attribute idea (which I haven?t found discussed in the list). Thanks for your time peace - oli PS note
elements implied by the outline algorithm aren?t present in the DOM and so are not styled (thanks @vant) [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-hgroup-element [2] http://www.zeldman.com/superfriends/guide/#hgroup [3] http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-header-element From dean.edwards at gmail.com Sat Oct 3 01:51:36 2009 From: dean.edwards at gmail.com (Dean Edwards) Date: Sat, 03 Oct 2009 09:51:36 +0100 Subject: [whatwg] The new content model for
breaks rendering in MSIE5-7 In-Reply-To: References: <4AC20FE1.8000200@gmail.com> <4AC23F93.5040204@gmail.com> <4AC25234.7020303@keryx.se> <4AC25B1D.1050505@gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> Message-ID: <4AC71098.6000907@gmail.com> On 03/10/2009 03:38, Tab Atkins Jr. wrote: > Agreed, but
won't be usable at all in modern browsers > (without hacking support in via js) until everyone updates. That's the whole point of this thread. We are specifying something that won't be usable for years. Let's make the spec better so that we can use
sooner. -dean From jackalmage at gmail.com Sat Oct 3 08:34:57 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Sat, 3 Oct 2009 10:34:57 -0500 Subject: [whatwg] The new content model for
breaks rendering in MSIE5-7 In-Reply-To: <4AC71098.6000907@gmail.com> References: <4AC20FE1.8000200@gmail.com> <4AC25B1D.1050505@gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> <4AC71098.6000907@gmail.com> Message-ID: On Sat, Oct 3, 2009 at 3:51 AM, Dean Edwards wrote: > On 03/10/2009 03:38, Tab Atkins Jr. wrote: >> >> Agreed, but
?won't be usable at all in modern browsers >> (without hacking support in via js) until everyone updates. > > That's the whole point of this thread. We are specifying something that > won't be usable for years. Let's make the spec better so that we can use >
sooner. But we won't be able to, really. As it stands,
doesn't "work" in any of the modern browsers. You are forced to use js to hack the toggling functionality in. IE6 and IE7 are slightly more broken, in that they require a relatively invasive script hack to get them to the same level of not-working that all the other browsers have. If we mint a new element, we pay the costs of adding yet another vaguely-heading element to add to the dozen+ we already have in the language, and what's the benefit? IE6 and IE7 will require a less invasive hack to get them to the same level of not-working that all the other browsers have. I can definitely understand why it's felt that that's not sufficient benefit to justify it. No modern browser gets anything out of the deal, only a pair of legacy browsers that are, finally, on their way out. And we'd be saddled with still more naming confusion regarding which of the dozen elements is appropriate in
as opposed to
, ,
, etc. despite them all serving roughly the same purpose. A permanent cost to solve a temporary problem that will disappear on its own, and one that doesn't even need solving - the only benefit is that you get to change your toggle scripts to look for
rather than
sooner. I wanna use
soon too - it gives me the warm fuzzies for some reason even if I have to hack the functionality in myself. But I can accept waiting until IE7 is irrelevant. I'm going to be doing that anyway for a number of other HTML5 features. ~TJ From webmaster at keryx.se Sat Oct 3 10:03:02 2009 From: webmaster at keryx.se (Keryx Web) Date: Sat, 03 Oct 2009 19:03:02 +0200 Subject: [whatwg] The new content model for
breaks rendering in MSIE5-7 In-Reply-To: References: <4AC20FE1.8000200@gmail.com> <4AC23C01.7030203@gmail.com> <4AC23F93.5040204@gmail.com> <4AC25234.7020303@keryx.se> <4AC25B1D.1050505@gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> Message-ID: <4AC783C6.1090907@keryx.se> 2009-10-03 00:51, Tab Atkins Jr. skrev: >
/
only have parsing problems in IE6 and IE7. Both of them > are, finally, actually dropping off the radar. Windows 7 will > accelerate this as people upgrade with an OS that runs IE8 by default. > Give it 2 years or so and most places will be able to justify > ignoring IE7 (many/most sites already ignore IE6). The IE6/7 problem is not the only one. A number of people, myself included, have expressed dissatisfaction from a semantic and teachability viewpoint. It is not better to let dt/dd have three (or perhaps 2) different meanings, and different syntactic rules depending upon the parent element than it would be to have 2 more elements. And if the use cases for details and/or figure is so weak, that they would be dropped JUST BECAUSE they would introduce yet 1 or 2 additional elements to make them work, than we might as well drop them. Do it right or do not do it at all! If an element has (1) a whole new semantic meaning in one place than it has in another place, and (b) different syntactic rules in one place than it has in another place, it is NOT THE SAME ELEMENT by definition. Let's not kid ourselves. We ARE introducing new elements here. It just so happens that they share the same name as 2 old ones. Or at least the same abbreviated name, since some people suggest that they would be expanded to "details type" and "details data", when used with details. What further proof do you need to understand that we are de facto introducing new elements, even if we confusingly, re-use old names? -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/ From jackalmage at gmail.com Sat Oct 3 12:47:06 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Sat, 3 Oct 2009 14:47:06 -0500 Subject: [whatwg] The new content model for
breaks rendering in MSIE5-7 In-Reply-To: <4AC783C6.1090907@keryx.se> References: <4AC20FE1.8000200@gmail.com> <4AC23F93.5040204@gmail.com> <4AC25234.7020303@keryx.se> <4AC25B1D.1050505@gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> <4AC783C6.1090907@keryx.se> Message-ID: On Sat, Oct 3, 2009 at 12:03 PM, Keryx Web wrote: > 2009-10-03 00:51, Tab Atkins Jr. skrev: > >>
/
?only have parsing problems in IE6 and IE7. ?Both of them >> are, finally, actually dropping off the radar. ?Windows 7 will >> accelerate this as people upgrade with an OS that runs IE8 by default. >> ?Give it 2 years or so and most places will be able to justify >> ignoring IE7 (many/most sites already ignore IE6). > > The IE6/7 problem is not the only one. A number of people, myself included, > have expressed dissatisfaction from a semantic and teachability viewpoint. > > It is not better to let dt/dd have three (or perhaps 2) different meanings, > and different syntactic rules depending upon the parent element than it > would be to have 2 more elements. > > And if the use cases for details and/or figure is so weak, that they would > be dropped JUST BECAUSE they would introduce yet 1 or 2 additional elements > to make them work, than we might as well drop them. > > Do it right or do not do it at all! > > If an element has (1) a whole new semantic meaning in one place than it has > in another place, and (b) different syntactic rules in one place than it has > in another place, it is NOT THE SAME ELEMENT by definition. > > Let's not kid ourselves. We ARE introducing new elements here. It just so > happens that they share the same name as 2 old ones. Or at least the same > abbreviated name, since some people suggest that they would be expanded to > "details type" and "details data", when used with details. > > What further proof do you need to understand that we are de facto > introducing new elements, even if we confusingly, re-use old names? Well, no amount of proof would do so; only a convincing enough argument. I, personally, do not feel that
's semantics change between
and
. Nor do I feel they have different syntax at all -
and
do have slightly different syntaxes, but it's very minor and pretty much bound up in the fact that
has multiple name/value pairs while
has only one, so
doesn't have to worry about ordering in the same way that
does. You see, I've authored lots of internal applications for myself and others in my company. Tree structures figure prominently, since these application are often relatively thin layers over the database structure. Looking back, I appear to be split evenly and arbitrarily between using nested
s to handle this structure and using nested headings/sections to handle it. There really doesn't appear to be much rhyme or reason behind my choice of one or the other. Either would be appropriate. The only thing I can see is that possibly the pages I saw more as lists I used
s for, while the pages I saw more as documents I used headings/sections for. So, in my mind,
/
do not hold some special meaning that locks them into only ever being used in
.
is a heading element, nothing more, effectively equivalent to
.
is a sectioning element, nothing more, effectively equivalent (though used slightly differently) to
. Both
and
declare the name for some body of data contained in
or
. Thus using
and
in
to fulfill the same purpose (wrapping the "name" and the "data") is completely natural to me. That's not to say that other solutions wouldn't also be natural, but I find nothing wrong with the status quo on semantic or usability concerns. I mean, would you complain about using or <caption> or <label> or <legend> or what-have-you in <details>? The change in semantics and syntax would be as great or greater than <dt>/<dd>. It so happens that all of those are worse* from a rendering perspective than <dt>/<dd>, so we've discarded them as solutions. But none of them are privileged as 'closer' to the syntax or semantics of the toggler and data elements of <details>. ~TJ * I know that the equivalence is not complete - <h> has an effect on the document outline that <dt> does not. But aside from that, they're equivalent in my eyes. From chuck at jumis.com Sat Oct 3 16:10:53 2009 From: chuck at jumis.com (Charles Pritchard) Date: Sat, 03 Oct 2009 16:10:53 -0700 Subject: [whatwg] Canvas Proposal: aliasClipping property Message-ID: <4AC7D9FD.6050902@jumis.com> There have been a few discussions about anti-aliasing / aliasing in Canvas implementations. Of those I read through, the conflict remains. In some implementations: when drawImage is used along with a clipping path, feathering is applied. This shows up in several projective transformation demos contrasting Firefox with Chrome. I believe that if we allow a toggle for this setting, we can bring some compatibility to the two systems. Enumerate two aliasClipping values : "aliased", "feathered" I consider "anti-aliased" to confusing, I think "feathered" is a better name. ..... [Supplemental] interface CanvasRenderingContext2D { attribute DOMString aliasClipping; // default "feathered" } context . aliasClipping [ = value ] Returns the current aliasing of the clipping region, as applied to rendering operations. Can be set, to change the aliasing value. If any of the arguments are not implemented, throws a NOT_SUPPORTED_ERR exception. CanvasRenderingContext2D.prototype.defineSetter('aliasClipping') { throw NOT_SUPPORTED_ERR; } From gundersen at gmail.com Sat Oct 3 18:34:44 2009 From: gundersen at gmail.com (Marius Gundersen) Date: Sun, 4 Oct 2009 11:34:44 +1000 Subject: [whatwg] Canvas Proposal: aliasClipping property In-Reply-To: <4AC7D9FD.6050902@jumis.com> References: <4AC7D9FD.6050902@jumis.com> Message-ID: <45f4181c0910031834u3741c4cft2dff2caf87129d1a@mail.gmail.com> This sounds like a very good proposal, but can we extend it to include other things than just drawImage? I'm not sure how useful it would be, but it could perhaps include all the other drawing options, like stroking and filling paths created with lineTo, arc, etc. Marius Gundersen On Sun, Oct 4, 2009 at 9:10 AM, Charles Pritchard <chuck at jumis.com> wrote: > There have been a few discussions about anti-aliasing / aliasing in Canvas > implementations. > Of those I read through, the conflict remains. > > In some implementations: when drawImage is used along with a clipping path, > feathering is applied. This shows up in several projective transformation > demos > contrasting Firefox with Chrome. > > I believe that if we allow a toggle for this setting, we can bring some > compatibility > to the two systems. > > Enumerate two aliasClipping values : "aliased", "feathered" > > I consider "anti-aliased" to confusing, I think "feathered" is a better > name. > > ..... > > [Supplemental] > interface CanvasRenderingContext2D { > attribute DOMString aliasClipping; // default "feathered" > } > > context . aliasClipping [ = value ] > > Returns the current aliasing of the clipping region, as applied to > rendering operations. > > Can be set, to change the aliasing value. > > If any of the arguments are not implemented, throws a NOT_SUPPORTED_ERR > exception. > > CanvasRenderingContext2D.prototype.defineSetter('aliasClipping') { throw > NOT_SUPPORTED_ERR; } > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091004/96c76cef/attachment.htm> From robert at ocallahan.org Sat Oct 3 18:46:56 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Sun, 4 Oct 2009 14:46:56 +1300 Subject: [whatwg] Canvas Proposal: aliasClipping property In-Reply-To: <4AC7D9FD.6050902@jumis.com> References: <4AC7D9FD.6050902@jumis.com> Message-ID: <11e306600910031846t375ed2d1q405a210ad76b2aac@mail.gmail.com> I think "feathered" isn't a good term. It's vary rarely used in graphics in my experience. "aliasClipping" isn't a good term either, since there's no clipping going on typically. I would just have boolean property named "antialias". 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] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091004/d0a800f3/attachment.htm> From webmaster at keryx.se Sun Oct 4 02:13:00 2009 From: webmaster at keryx.se (Keryx Web) Date: Sun, 04 Oct 2009 11:13:00 +0200 Subject: [whatwg] The new content model for <details> breaks rendering in MSIE5-7 In-Reply-To: <dd0fbad0910031247s2de6baf3r8d825aed345faa32@mail.gmail.com> References: <4AC20FE1.8000200@gmail.com> <4AC23F93.5040204@gmail.com> <4AC25234.7020303@keryx.se> <4AC25B1D.1050505@gmail.com> <dd0fbad0909291241k1f578f4ft84bbab51cb9a76e5@mail.gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> <dd0fbad0910021551k1c784944jbc3256a67e575d3a@mail.gmail.com> <4AC783C6.1090907@keryx.se> <dd0fbad0910031247s2de6baf3r8d825aed345faa32@mail.gmail.com> Message-ID: <4AC8671C.6020603@keryx.se> 2009-10-03 21:47, Tab Atkins Jr. skrev: > Well, no amount of proof would do so; only a convincing enough > argument. I, personally, do not feel that<dt>'s semantics change > between<dl> and<details>. Nor do I feel they have different syntax > at all -<dl> and<details> do have slightly different syntaxes, but > it's very minor and pretty much bound up in the fact that<dl> has > multiple name/value pairs while<details> has only one, so<details> > doesn't have* to worry about ordering in the same way that<dl> does. > > etc In what way is the SYNTAX different? We seem to agree on this: First and foremost, in <dl> the order is all important. Here it would not matter. In <dl> one may have several <dd> for each <dt> (or several <dt>'s in a row), here one may not. You call this "minor", I say confusing. But we have in fact created a new syntax - why is that better than creating new elements? In what way is the SEMANTICS different? > So, in my mind, <dt>/<dd> do not hold some special meaning that > locks them into only ever being used in <dl>. <dt> is a heading > element, nothing more, effectively equivalent to <h1>. Well, that is not what the SPEC says is it? > I mean, would you complain about using <title> or <caption> or <label> > or <legend>... in <details>? Yes, I would. I am arguing in favor of introducing a new element, which would be the zero cost solution, since <details> is new anyway. + No hacks besides those that we already use to get details working as such in legacy browsers. + When implementing details the browser vendors will not have a harder time using a new element than they would using dt/dd. + We would keep the several meanings per element count down, which from a teachability POV is more important than keeping the total number of elements down. And from that POV nuances are often harder to pick up than anything else. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/ From ian at hixie.ch Sun Oct 4 04:48:29 2009 From: ian at hixie.ch (Ian Hickson) Date: Sun, 4 Oct 2009 11:48:29 +0000 (UTC) Subject: [whatwg] <dialog> removal In-Reply-To: <63df84f0909021833pc75c953va61b2c1c15335880@mail.gmail.com> References: <4A81087F.1000800@romantschuk.fi> <Pine.LNX.4.62.0908152220170.6420@hixie.dreamhostps.com> <4A89179D.1040606@romantschuk.fi> <7c2a12e20908170630j59ed1458haeafaef274f26e93@mail.gmail.com> <4A8BA0BA.1030507@romantschuk.fi> <AE2B216B-34B9-43F6-BF48-DD87178450F1@adactio.com> <4A8C142F.5030609@opera.com> <Pine.LNX.4.62.0908280026200.13789@hixie.dreamhostps.com> <63df84f0908280116u3db8f9f2t45b401f592ca8973@mail.gmail.com> <Pine.LNX.4.62.0909022147190.6775@hixie.dreamhostps.com> <63df84f0909021833pc75c953va61b2c1c15335880@mail.gmail.com> Message-ID: <Pine.LNX.4.62.0910041146340.25383@hixie.dreamhostps.com> On Wed, 2 Sep 2009, Jonas Sicking wrote: > > > > Neither <dialog> nor <meter> were added because they are expected to > > be used in great numbers. Both were added to prevent another element > > from being _mis_used. (Specifically, <dialog> takes away from the risk > > of people marking up dialogs as association lists, and <meter> takes > > away from the risk of people marking up gauges as progress bars.) > > While I can see the argument for <meter>, I'm not sure I see it with > <dialog>. First of all, as others have pointed out, <dialog> is > generally not feature-full enough to mark up dialogs. Second, given that > association lists already exist, we should be able to check existing > pages to see if people are abusing lists to mark up dialogs. > > I started by looking at some sites with the Romeo and Juliet play: > > http://www.william-shakespeare.info/act1-script-text-romeo-and-juliet.htm > Uses > > http://shakespearemiami.tripod.com/id22.html > Uses <blockquote> > > http://shakespeare.mit.edu/romeo_juliet/full.html > Uses <blockquote> > > http://www.script-o-rama.com/movie_scripts/r/romeo-and-juliet-script-screenplay.html > Uses <pre> > > http://www.clicknotes.com/romeo/T11.html > and > > http://www.opensourceshakespeare.org/views/plays/play_view.php?WorkID=romeojuliet&Act=1&Scene=1&Scope=scene > One <ul><li>...</li></ul> for each quote. > > http://www.cambridge.org/us/catalogue/catalogue.asp?isbn=9780521618700&ss=exc > Uses > > > I also looked for transcripts of the frost/nixon interview: > http://www.guardian.co.uk/theguardian/2007/sep/07/greatinterviews1 > Uses > > http://digbysblog.blogspot.com/2008/06/inspiration-by-digby-as-constitutional.html > Uses > > http://www.ourblook.com/Reporters-and-the-Media/The-Nixon-Interviews-with-David-Frost.html > Uses > > http://remember-nixon.org/ > Uses <pre> > > https://pol.moveon.org/archive/breakingthelaw_sub1.html > Basically uses one <ul><li>...</li></ul> for each quote. > > http://belowthebeltway.com/2009/04/30/condi-rice-channels-richard-nixon-if-the-president-authorizes-it-its-not-illegal/ > Uses > > > I also looked at transcripts for the "Silly Job Interview" play by Monty Python: > > http://www.orangecow.org/pythonet/sketches/intview.htm > Uses > (this site does use a list, but not for the actual dialog) > > http://www.ibras.dk/montypython/episode05.htm > Uses a table with a <tr> for each line in the dialog. > (This is actually another monty python skit, but it turned up in my > search and I figured it didn't really matter) > > http://montypython.50webs.com/scripts/Series_1/35.htm > Uses > > http://www.ulrikchristensen.dk/scripts/montypython/sillyjob.html > Uses > > http://www.cardinalfang.net/episodes/season_one/silly_job_interview.html > Uses (and <o:p>) > > > Finally I simply did a google search for "interview transcript": > http://www.cbsnews.com/stories/2003/12/28/60minutes/main590381.shtml > Uses > > http://www.pokerlistings.com/blog/ashman103-the-interview-transcript > Uses > > http://www.pgatour.com/2009/tournaments/r027/08/30/sunday.transcript.slocum/index.html > Uses > > http://www.blazersedge.com/2009/8/15/990765/clyde-drexler-interview-transcript > Uses > > http://www.npr.org/templates/story/story.php?storyId=7065633 > Uses > > http://www.boston.com/sports/football/patriots/reiss_pieces/2008/05/bill_belichicks.html > Uses > > http://d5.allthingsd.com/20070531/d5-gates-jobs-transcript/ > Uses > > http://www.guardian.co.uk/media/2008/nov/08/dizzee-rascal-paxman-jeremy-bbc > Uses > > http://www.telegraph.co.uk/news/newstopics/jaycee-lee-dugard/6105540/Phillip-Garridos-interview-transcript.html > Uses > > http://www.defenselink.mil/transcripts/transcript.aspx?transcriptid=2594 > Uses > > http://entertainment.timesonline.co.uk/tol/arts_and_entertainment/tv_and_radio/article2777973.ece > Uses > > http://www.cdi.org/adm/1351/Yafei.html > Uses > > http://www.ronsuskind.com/thewayoftheworld/transcripts/ > Uses > > http://www.anusha.com/osamaint.htm > Uses Thanks for this research! Based on the data above, I removed <dialog> (a few weeks ago now), and replaced it with a section on how to mark up conversations that tries to pave the cowpath that most of the above walk (namely, using ). (Sorry for the late replying relative to the time of the edit.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Sun Oct 4 05:01:23 2009 From: ian at hixie.ch (Ian Hickson) Date: Sun, 4 Oct 2009 12:01:23 +0000 (UTC) Subject: [whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol) In-Reply-To: <4AA18B47.6050205@gmail.com> References: <4A7B7C7C.3040202@mortbay.com> <58A4FD12-353D-4ADA-AE7C-99F4A31FD8D4@apple.com> <4A7BD6FF.8020804@mortbay.com> <63df84f0908072030t5f8d16e9hb13236030adbf129@mail.gmail.com> <4A81E67B.1030004@gmail.com> <63df84f0908111835r3213f87dh4fb451b8aa28b21d@mail.gmail.com> <Pine.LNX.4.62.0908141035510.6420@hixie.dreamhostps.com> <63df84f0908141413j557f06a9x7f4f2aab8fd38671@mail.gmail.com> <Pine.LNX.4.62.0909040538130.6775@hixie.dreamhostps.com> <4AA18B47.6050205@gmail.com> Message-ID: <Pine.LNX.4.62.0910041158310.25383@hixie.dreamhostps.com> On Fri, 4 Sep 2009, Wellington Fernando de Macedo wrote: > > Ian, do you intend to add any other features to the first version of > WebSocket? If yes, which ones? I was thinking of adding multiplexing, but after discussing this with a variety of people, I'm leaning towards leaving the protocol as is, and letting authors implement their own multiplexing if they need it. Other than that, I have no plans to add any features or make any further major changes to the normative requirements in the protocol unless someone brings up some serious problems. I recommend rereading the spec and comparing it to any tests and implementations before shipping, as there have been a number of subtle changes over the past few months, such as dropping redirect support, changing the default ports, changing how URLs are parsed, and the like. I have some outstanding feedback on WebSockets, which I'll be getting to in the coming days. HTH, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jackalmage at gmail.com Sun Oct 4 07:51:13 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Sun, 4 Oct 2009 09:51:13 -0500 Subject: [whatwg] The new content model for <details> breaks rendering in MSIE5-7 In-Reply-To: <4AC8671C.6020603@keryx.se> References: <4AC20FE1.8000200@gmail.com> <4AC25B1D.1050505@gmail.com> <dd0fbad0909291241k1f578f4ft84bbab51cb9a76e5@mail.gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> <dd0fbad0910021551k1c784944jbc3256a67e575d3a@mail.gmail.com> <4AC783C6.1090907@keryx.se> <dd0fbad0910031247s2de6baf3r8d825aed345faa32@mail.gmail.com> <4AC8671C.6020603@keryx.se> Message-ID: <dd0fbad0910040751p144a2482o9ba21f28f1ea21aa@mail.gmail.com> On Sun, Oct 4, 2009 at 4:13 AM, Keryx Web <webmaster at keryx.se> wrote: > I am arguing in favor of introducing a new element, which would be the zero > cost solution, since <details> is new anyway. It's not a zero-cost solution, though. It introduces another* nearly identical heading-type element to the language, joining the ranks of the dozen+ we already have. Trying to remember what heading-type element to use in <details> as opposed to in <fieldset> or what-have-you is a learning nightmare of a different variety. > + No hacks besides those that we already use to get details working as such > in legacy browsers. <dt> only requires extra hacks in two browsers that are on the way out. Given a little bit more time they'll be gone completely, and we can stop worrying about this. > + When implementing details the browser vendors will not have a harder time > using a new element than they would using dt/dd. I'm not certain what you mean by this. Indeed they won't have a harder time - the difficulty will be the same either way. > + We would keep the several meanings per element count down, which from a > teachability POV is more important than keeping the total number of elements > down. > > And from that POV nuances are often harder to pick up than anything else. Just teach <dt>/<dd> in a way that makes this easier to learn. ~TJ From dean.edwards at gmail.com Sun Oct 4 08:58:00 2009 From: dean.edwards at gmail.com (Dean Edwards) Date: Sun, 04 Oct 2009 16:58:00 +0100 Subject: [whatwg] The new content model for <details> breaks rendering in MSIE5-7 In-Reply-To: <dd0fbad0910040751p144a2482o9ba21f28f1ea21aa@mail.gmail.com> References: <4AC20FE1.8000200@gmail.com> <4AC25B1D.1050505@gmail.com> <dd0fbad0909291241k1f578f4ft84bbab51cb9a76e5@mail.gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> <dd0fbad0910021551k1c784944jbc3256a67e575d3a@mail.gmail.com> <4AC783C6.1090907@keryx.se> <dd0fbad0910031247s2de6baf3r8d825aed345faa32@mail.gmail.com> <4AC8671C.6020603@keryx.se> <dd0fbad0910040751p144a2482o9ba21f28f1ea21aa@mail.gmail.com> Message-ID: <4AC8C608.2020402@gmail.com> On 04/10/2009 15:51, Tab Atkins Jr. wrote: > <dt> only requires extra hacks in two browsers that are on the way > out. Given a little bit more time they'll be gone completely, and we > can stop worrying about this. > I'm sorry but you are really understating the problem here. -dean From jackalmage at gmail.com Sun Oct 4 10:11:31 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Sun, 4 Oct 2009 12:11:31 -0500 Subject: [whatwg] The new content model for <details> breaks rendering in MSIE5-7 In-Reply-To: <4AC8C608.2020402@gmail.com> References: <4AC20FE1.8000200@gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> <dd0fbad0910021551k1c784944jbc3256a67e575d3a@mail.gmail.com> <4AC783C6.1090907@keryx.se> <dd0fbad0910031247s2de6baf3r8d825aed345faa32@mail.gmail.com> <4AC8671C.6020603@keryx.se> <dd0fbad0910040751p144a2482o9ba21f28f1ea21aa@mail.gmail.com> <4AC8C608.2020402@gmail.com> Message-ID: <dd0fbad0910041011o37866f98q4212fceac2c2b9e1@mail.gmail.com> On Sun, Oct 4, 2009 at 10:58 AM, Dean Edwards <dean.edwards at gmail.com> wrote: > On 04/10/2009 15:51, Tab Atkins Jr. wrote: >> >> <dt> ?only requires extra hacks in two browsers that are on the way >> out. ?Given a little bit more time they'll be gone completely, and we >> can stop worrying about this. >> > > I'm sorry but you are really understating the problem here. Can you elaborate? Are there rendering problems in any other browsers? Are you expecting IE6 and IE7 to remain relevant forever? Is there something else I'm missing? Is this too many questions in a row? ~TJ From dean.edwards at gmail.com Sun Oct 4 10:56:55 2009 From: dean.edwards at gmail.com (Dean Edwards) Date: Sun, 04 Oct 2009 18:56:55 +0100 Subject: [whatwg] The new content model for <details> breaks rendering in MSIE5-7 In-Reply-To: <dd0fbad0910041011o37866f98q4212fceac2c2b9e1@mail.gmail.com> References: <4AC20FE1.8000200@gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> <dd0fbad0910021551k1c784944jbc3256a67e575d3a@mail.gmail.com> <4AC783C6.1090907@keryx.se> <dd0fbad0910031247s2de6baf3r8d825aed345faa32@mail.gmail.com> <4AC8671C.6020603@keryx.se> <dd0fbad0910040751p144a2482o9ba21f28f1ea21aa@mail.gmail.com> <4AC8C608.2020402@gmail.com> <dd0fbad0910041011o37866f98q4212fceac2c2b9e1@mail.gmail.com> Message-ID: <4AC8E1E7.3000006@gmail.com> On 04/10/2009 18:11, Tab Atkins Jr. wrote: > On Sun, Oct 4, 2009 at 10:58 AM, Dean Edwards<dean.edwards at gmail.com> wrote: >> On 04/10/2009 15:51, Tab Atkins Jr. wrote: >>> >>> <dt> only requires extra hacks in two browsers that are on the way >>> out. Given a little bit more time they'll be gone completely, and we >>> can stop worrying about this. >>> >> >> I'm sorry but you are really understating the problem here. > > Can you elaborate? Are there rendering problems in any other > browsers? > Is there something else I'm missing? Is this too many questions in a > row? > MSIE5-7 usage is currently between 25% and 30%. It will take a number of years before it becomes insignificant. The two hacks you mention are fairly hideous. One of them can potentially prevent other scripts from executing. We've gone full circle on this subject now. We are starting to repeat ourselves. -dean From ian at hixie.ch Sun Oct 4 19:32:12 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 5 Oct 2009 02:32:12 +0000 (UTC) Subject: [whatwg] More prohibited characters for unquoted attributes are needed In-Reply-To: <7c2a12e20909071045m60b36520s8cf050d8f0e3e8db@mail.gmail.com> References: <7c2a12e20909060435w346d6d70l486fe1ceb3e0d9bf@mail.gmail.com> <066122B3-B866-49C9-BE1C-735FB085596F@googlemail.com> <7c2a12e20909071045m60b36520s8cf050d8f0e3e8db@mail.gmail.com> Message-ID: <Pine.LNX.4.62.0910050200140.25383@hixie.dreamhostps.com> On Mon, 7 Sep 2009, Aryeh Gregor wrote: > On Mon, Sep 7, 2009 at 1:34 PM, Geoffrey Sneddon > <foolistbar at googlemail.com> wrote: > > Apparently Hixie had previously said he didn't want to change this as it > > will become a non-issue over time. I think it does matter due to the > > security issues it presents in existing UAs. Conforming markup (using > > elements/attributes allowed in HTML 4.01) should not cause JS to execute in > > one browser but not in another. > > I agree with you as an author. I wrote an HTML output function in > MediaWiki assuming that what the standard says is known to be > interoperable, which is apparently wrong. If I hadn't been keeping up > with HTML 5, I would have introduced an XSS vulnerability because of > some browsers' handling of `. > > If the problem will go away with time, then perhaps a later version of > the standard could make such unquoted attributes conforming, once > there's no more problem with them. As far as I can tell, this is an IE bug; treating "`" as an attribute quoting character is non-conforming in any version of HTML so far, it seems. I'm certainly not going to make it non-conforming to stumble into any IE bug or difference in parsing between IE and previous specs or other browsers; we'd just end up with an asanine set of conformance requirements. For example, should this be non-conforming? <!DOCTYPE html> <title>Test
Search: This perfectly innocent piece of HTML content (HTML2-compliant except for the DOCTYPE) results in a non-tree DOM in IE8. Should we make it non-conforming? Similarly, IE conditional comments make it trivial to trigger scripts in IE but not another UA; indeed people do this on purpose. Should we make those non-conforming also? As I understand it, the attack here is a site that allows the user to input text that is used verbatim in two attributes, such that the user can set the first attribute's value to: ` ...and the second to: ` onload='...payload...' end=x ...with the assumption that the site is going to not quote the first one, and quote the second one with double quotes: ...which in IE, for some reason, gets treated as: I've disallowed ` in unquoted attribute values for now, but I think we should revert this once IE has fixed this bug for a few years. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Sun Oct 4 21:13:14 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 5 Oct 2009 04:13:14 +0000 (UTC) Subject: [whatwg] HTML 5 drag and drop feedback In-Reply-To: <491930550909171309q6259123cu87886cb9d0aefb52@mail.gmail.com> References: <851CE2FD-C766-4C19-B399-D42E7D50232A@280north.com> <0024AA4F-6B6B-4D51-A4AF-472101DDCFDC@280north.com> <6C811B97-5584-4BEB-BF20-1B5D82C1C8E4@280north.com> <491930550909171309q6259123cu87886cb9d0aefb52@mail.gmail.com> Message-ID: On Thu, 17 Sep 2009, Sebastian Markb?ge wrote: > > No browser has implemented the copy/paste part of the spec. Few parts of the spec are perfectly implemented anywhere today, indeed. That's what it'll take years to get to -- that's where the "2022" estimate comes from, in fact -- I doubt we'll have two perfect implementations before then. > As for lazy data... > > If the drag/drop is actually a copy/paste, you still have to serialize > ALL data. If your script made the assumption that it wouldn't, then that > could cause some interesting bloated clipboard. To me, this is just > another example of why the copy/paste API should be separate. I don't see why copy and paste is different than drag and drop here. In both cases, you would want to push a promise into the dataTransfer (or its analogue) for performance reasons. > I've also suggested that you allow for lazy loading of data as entire > files using: dataTransfer.setRemoteData(type, uri); > > Using a remote URI in the clipboard, that API could lazily load data > even after the document is unloaded. > > But I also like the idea of a callback. Yes, I think this is a worthwhile addition to the API -- once the implementations are closer to what the spec says. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Sun Oct 4 23:40:00 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 5 Oct 2009 06:40:00 +0000 (UTC) Subject: [whatwg] Quoted (') and (") appear as ('''') and (''''') In-Reply-To: <471B7E36-97A6-4FC3-A6BA-068B3E5A8229@coq.no> References: <471B7E36-97A6-4FC3-A6BA-068B3E5A8229@coq.no> Message-ID: On Thu, 17 Sep 2009, ?istein E. Andersen wrote: > > Printable Unicode characters are referred to in at least five different ways: > U+003D EQUALS SIGN (`=`) > U+003D EQUALS SIGN ("`=`") > U+003D EQUALS SIGN character (=) > U+002D HYPHEN-MINUS ("-") > U+003D EQUALS SIGN > > Printable ASCII-characters are usually referred to as follows: > 0x3D (ASCII '=') > > The ideal solution would of course be to make this fully consistent ? e.g., by > using the style U+... (`...`) for Unicode all the time and perhaps > also 0x... (ASCII `...`) for ASCII. > > Failing that, "'" and '"' (two occurrences of each, excluding an unrelated > unproblematic instance inside a script) should be changed since they appear > confusingly as ''''' and '''' in a sans-serif typeface. Fixed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From simonp at opera.com Mon Oct 5 02:34:55 2009 From: simonp at opera.com (Simon Pieters) Date: Mon, 05 Oct 2009 11:34:55 +0200 Subject: [whatwg] [html5] r4029 - [e] (0) Example of
use without
. In-Reply-To: References: <20090929055721.2003F38E1F3@hixie.dreamhostps.com> Message-ID: On Wed, 30 Sep 2009 00:54:14 +0200, Ian Hickson wrote: > On Tue, 29 Sep 2009, Gordon P. Hemsley wrote: >> >> s/Html/html/ > > Actually that was intentional in that example. I like to show a variety > of > syntaxes so that people can see that they can do whichever one they > prefer. ...but my original comment still stands: s/DOCTPE/DOCTYPE/ -- Simon Pieters Opera Software From ian at hixie.ch Mon Oct 5 03:49:42 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 5 Oct 2009 10:49:42 +0000 (UTC) Subject: [whatwg] status of html5 Custom scheme and content handlers? In-Reply-To: References: Message-ID: On Fri, 18 Sep 2009, brg wrote: > > RE: 6.8.2 > status of html5 Custom scheme and content handlers? > > I ask because I am interesting in providing an implementation, and am > wondering if it is stable enough to start. It is currently marked as a > Working Draft, although I can not find any discussion since late spring, > 2009. It's been implemented and shipped in Firefox for some time. I don't know how stable it is, though. There have been some suggestions that we should use a different design altogether, though nobody has really suggested anything better yet. Things get more stable the more implementations we have, though. > It reads as if the spec is fairly complete to provide an experimental > implementation, but perhaps could use a list of forbidden schemes > (eg.http, https, file). I didn't want to give an explicit list, because each browser might have a different set of special schemes, and I didn't want to mislead implementors into not thinking about this carefully. HTH, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Oct 5 04:27:08 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 5 Oct 2009 11:27:08 +0000 (UTC) Subject: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling In-Reply-To: References: Message-ID: On Sat, 19 Sep 2009, Michael A. Puls II wrote: > > Currently, registerProtcolHandler works like this: > > navigator.registerProtocolHandler("protocol", "http://example.org/?uri=%s", "title"); > > However, this doesn't allow the site to specify some useful and > important information about the site like: > > 1. What encoding the server expects. For example, uri= might expect the > protocol link that was invoked in the browser to be interpreted as > koi8-r instead of utf-8. This might be the case even if the page that > uses registerProtocolHandler uses Windows-1251 for example. Sites that want to use registerProtocolHandler() must use UTF-8. > 2. The location of an icon like a favicon.ico file or png etc. I could see that as being mildly useful, though I would be concerned with the phishing risk. It seems that in most cases, the UA could just reuse the favicon of the page that registered the handler, though, maybe refreshing it from the page of the handler after the first time it is used. Also, it's unclear how we'd let the icon get updated when the site's icon changes; if we honour HTTP caching semantics or have a forced lifetime, then we have a privacy leak (a hostile site could maybe register a handler forcibly using a variety of induced-click techniques, or using social engineering, and then would just need to listen to the regular pings from the client updating the image), and if we don't ever update the image, then instead we have an out-of-date icon which could be worse than no icon at all. > 3. URI to a help page where the site explains how it makes uses of > registerProtocolHandler and gives help and support contacts etc. The UA can already keep track of the page from which the user registered the handler, which seems suitable. > 4. Whether to use "POST" instead of GET. Always use GET. You're only sending a URL anyway. > Finally, it's unfortunate that registerProtocolHandler can't optionally > support a custom format string for the second argument and a format > argument that's a function that gets the URI the user clicked on passed > to it. Why can't the server just do that server-side? That way it doesn't have to worry about updating clients later if it wants to support more features. > It's also unfortunate that it's so domain restricted. That's a good > default, but you can see that Firefox has an override for a reason. Not sure what you mean here. > For example, all of these webmails don't support what > registerProtocolHandler emits. They only support individual values, > which are different for each webmail. > > "http://mymail.operamail.com/scripts/mail/Outblaze.mail?compose=1&did=1&a=1&to=&subject=&body=&cc=&bcc=" > "http://mail.live.com/mail/EditMessageLight.aspx?n=&to=&cc=&bcc=&subject=&body=" > "http://compose.mail.yahoo.com/?To=&Subj=&Cc=&Bcc=&Body=" > "http://your_squirrelmail_server.com/src/compose.php?send_to=&subject=&body=&send_to_cc=&send_to_bcc=" > "http://your_horde_server.com/horde/imp/compose.php?popup=0&to=&cc=&msg=&subject=&bcc=" > "http://mail01.mail.com/scripts/mail/Outblaze.mail?composeto=&subject=&body=&cc=&bcc=&compose=1" > "http://win.mail.ru/cgi-bin/sentmsg?To=&CC=&BCC=&Subject=&BodyUTF8=&accel=1" > "http://your_roundcubemail_server/?_task=mail&_action=compose&_to=&_subject=&_body=&_cc=&_bcc=" > > In these cases, the URI format string in registerProtocolHandler would > need a %key for to, subject, body, cc and bcc. The site could use %t, > %j, %k and %l and %m for these for example. But, for the UA to > understand those %keys (since the UA would only understands %s), a > custom function would be needed that did the processing on the link the > user clicked and returned the URI argument with the %keys replaced with > the desired values. If a site wanted to support these, it need but provide a CGI script that parsed the mailto: URL and redirected the user to the appropriate server. It could even support other encodings. On Tue, 22 Sep 2009, Michael A. Puls II wrote: > > Say the user sees that things are not working right with the handler. > The user goes into the options to see what's doing with the handler > settings and notices the link. The user clicks on it. Then, on the page, > it says "Attention: We've changed some things with what our server > accepts from our protocol handler. You need to register the handler > again by clicking here to get the updated version" for example. User > does and is happy again. :) This seems highly optimistic. I think a more likely scenario is user finds things are broken, user goes whining in a forum, someone there points them to the site that they are whining about, and on the site there's a notice or something. Or, the user finds it's broken, and they just go straight to the site and try to reregister, and it "fixes" itself (with the addition of a new handler). I don't think the link you're suggesting would get much if any traffic. I'm not sure why a handler would break though. I mean, there's very little that can change. Sites can always just do redirects. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From shadow2531 at gmail.com Mon Oct 5 06:37:05 2009 From: shadow2531 at gmail.com (Michael A. Puls II) Date: Mon, 05 Oct 2009 09:37:05 -0400 Subject: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling In-Reply-To: References: Message-ID: On Mon, 05 Oct 2009 07:27:08 -0400, Ian Hickson wrote: > On Sat, 19 Sep 2009, Michael A. Puls II wrote: >> >> Currently, registerProtcolHandler works like this: >> >> navigator.registerProtocolHandler("protocol", >> "http://example.org/?uri=%s", "title"); >> >> However, this doesn't allow the site to specify some useful and >> important information about the site like: >> >> 1. What encoding the server expects. For example, uri= might expect the >> protocol link that was invoked in the browser to be interpreted as >> koi8-r instead of utf-8. This might be the case even if the page that >> uses registerProtocolHandler uses Windows-1251 for example. > > Sites that want to use registerProtocolHandler() must use UTF-8. O.K., so you definitely, no doubt about it, want to make that a requirement. If so, fine, just want to make sure. >> 2. The location of an icon like a favicon.ico file or png etc. > > I could see that as being mildly useful, though I would be concerned with > the phishing risk. It seems that in most cases, the UA could just reuse > the favicon of the page that registered the handler, though, maybe > refreshing it from the page of the handler after the first time it is > used. Also, it's unclear how we'd let the icon get updated when the > site's > icon changes; if we honour HTTP caching semantics or have a forced > lifetime, then we have a privacy leak (a hostile site could maybe > register > a handler forcibly using a variety of induced-click techniques, or using > social engineering, and then would just need to listen to the regular > pings from the client updating the image), and if we don't ever update > the > image, then instead we have an out-of-date icon which could be worse than > no icon at all. > > >> 3. URI to a help page where the site explains how it makes uses of >> registerProtocolHandler and gives help and support contacts etc. > > The UA can already keep track of the page from which the user registered > the handler, which seems suitable. O.K., there can be some guidelines/tutorials that recommend that the page that registers the handler is also the help page so that UAs can use that info if needed. It could also be recommended in such a tutorial that the page should use the desired favicon so UAs can use it if they want (and how they want and with what restrictions they want) >> 4. Whether to use "POST" instead of GET. > > Always use GET. You're only sending a URL anyway. But, with POST you can send longer data (depending on the server and its config). Since %s is a percent-encoded version of data that's usually already percent-encoded (in parts of the URI), a lot of that length is lost in just percent-encoding (lots of "%2525"s for example). Also, the devs for one webmail even prefer POST data as they said that it's less revealing when submitting through a proxy. But, I never validated that. >> Finally, it's unfortunate that registerProtocolHandler can't optionally >> support a custom format string for the second argument and a format >> argument that's a function that gets the URI the user clicked on passed >> to it. > > Why can't the server just do that server-side? That way it doesn't have > to > worry about updating clients later if it wants to support more features. I'm not saying they can't. More like, I'm saying they won't or cannot in a timely manner and that there's a better chance of support if they don't have to change their server-side scripts and can just use a little JS. Also, with your user hat on, you should see why it'd be great to have a standardized function to do customize handling yourself to workaround lack of support for %s. >> It's also unfortunate that it's so domain restricted. That's a good >> default, but you can see that Firefox has an override for a reason. > > Not sure what you mean here. "file:///c:/documents%20and%20settings/user/desktop/test.html" can't register a "mailto" handler for "http://foo.org/?uri=%s" in Firefox by default. The URL argument has to be on the same domain or it is denied. Firefox does have an override though in about config, which you must use to get that to work. I see the spec leaves this up to the UA to do what it wants though, so nevermind. I also seem to remember that the intent was that the registered handler would only be invoked when clicking on links on pages on the domain that registered the handler. That would mean that the protocol handling would only work on the site's pages and no other sites. However, I don't see that in the spec and that's not how it works in FF, so nevermind. >> For example, all of these webmails don't support what >> registerProtocolHandler emits. They only support individual values, >> which are different for each webmail. >> >> "http://mymail.operamail.com/scripts/mail/Outblaze.mail?compose=1&did=1&a=1&to=&subject=&body=&cc=&bcc=" >> "http://mail.live.com/mail/EditMessageLight.aspx?n=&to=&cc=&bcc=&subject=&body=" >> "http://compose.mail.yahoo.com/?To=&Subj=&Cc=&Bcc=&Body=" >> "http://your_squirrelmail_server.com/src/compose.php?send_to=&subject=&body=&send_to_cc=&send_to_bcc=" >> "http://your_horde_server.com/horde/imp/compose.php?popup=0&to=&cc=&msg=&subject=&bcc=" >> "http://mail01.mail.com/scripts/mail/Outblaze.mail?composeto=&subject=&body=&cc=&bcc=&compose=1" >> "http://win.mail.ru/cgi-bin/sentmsg?To=&CC=&BCC=&Subject=&BodyUTF8=&accel=1" >> "http://your_roundcubemail_server/?_task=mail&_action=compose&_to=&_subject=&_body=&_cc=&_bcc=" >> >> In these cases, the URI format string in registerProtocolHandler would >> need a %key for to, subject, body, cc and bcc. The site could use %t, >> %j, %k and %l and %m for these for example. But, for the UA to >> understand those %keys (since the UA would only understands %s), a >> custom function would be needed that did the processing on the link the >> user clicked and returned the URI argument with the %keys replaced with >> the desired values. > > If a site wanted to support these, it need but provide a CGI script that > parsed the mailto: URL and redirected the user to the appropriate server. > It could even support other encodings. Yep, this is basically what Gmail does and works great. It basically converts "https://mail.google.com/mail/?extsrc=mailto&url=" into what's really supported, which is: "http://mail.google.com/mail/?compose=1&view=cm&fs=1&to=&su=&body=&cc=&bcc=". However, it doesn't seem like many other sites will do that or even get the mailto URI parsing right. They can't even fix the bugs in their regular compose URIs. (I hate to name names, but mail.live.com and mail.yahoo.com are absolutely horrible at getting things right in these cases. But, as you know, users still insist on using those sites, so standardized workaround capabilities sound great to me. You can read through to get an idea of some of the problems.) If you could do custom handling with registerProtocolHandler, you could register a handler yourself and do the processing as you like and do any workarounds that are needed for the site. The alternative will be for each UA to support its own advanced registerHandler function. Was trying to avoid that though. But, I guess sites could wrap them all into a single function. In short, I'm saying that registerProtocolHandler is currently useless for registering most webmails as a "mailto" handler. Now, I think registering webmails as "mailto" handlers is a very, very, very important use case. It perhaps even deserves its own function that can support existing webmail compose URIs. IMO, fwiw. > On Tue, 22 Sep 2009, Michael A. Puls II wrote: >> >> Say the user sees that things are not working right with the handler. >> The user goes into the options to see what's doing with the handler >> settings and notices the link. The user clicks on it. Then, on the page, >> it says "Attention: We've changed some things with what our server >> accepts from our protocol handler. You need to register the handler >> again by clicking here to get the updated version" for example. User >> does and is happy again. :) > > This seems highly optimistic. I think a more likely scenario is user > finds > things are broken, user goes whining in a forum, someone there points > them > to the site that they are whining about, and on the site there's a notice > or something. Or, the user finds it's broken, and they just go straight > to > the site and try to reregister, and it "fixes" itself (with the addition > of a new handler). > > I don't think the link you're suggesting would get much if any traffic. > > I'm not sure why a handler would break though. I mean, there's very > little > that can change. Sites can always just do redirects. O.K. Thanks -- Michael From mark at marksw.com Mon Oct 5 09:48:02 2009 From: mark at marksw.com (Mark Kaplun) Date: Mon, 05 Oct 2009 19:48:02 +0300 Subject: [whatwg] Is there any reason for the continued existence of enctype attribute at the form element Message-ID: <4ACA2342.5040703@marksw.com> I have only learned now that there is a "text/palin" option that I have never heard of, so maybe I'm wrong, but my impression is that there are only two forms of form, a textual and a file upload. IMHO the browser can inspect the form before submitting it and decide by itself what is the correct encoding to use. Can the use of this attribute be deprecated, be valid only for backward compatibility? Mark. From jonas at sicking.cc Mon Oct 5 12:36:21 2009 From: jonas at sicking.cc (Jonas Sicking) Date: Mon, 5 Oct 2009 12:36:21 -0700 Subject: [whatwg] Is there any reason for the continued existence of enctype attribute at the form element In-Reply-To: <4ACA2342.5040703@marksw.com> References: <4ACA2342.5040703@marksw.com> Message-ID: <63df84f0910051236w33d91d82y1c7161c6586fbf8a@mail.gmail.com> On Mon, Oct 5, 2009 at 9:48 AM, Mark Kaplun wrote: > I have only learned now that there is a "text/palin" option that I have > never heard of, so maybe I'm wrong, but my impression is that there are only > two forms of form, a textual and a file upload. IMHO the browser can inspect > the form before submitting it and decide by itself what is the correct > encoding to use. There was also a proposal for "mccain/palin" enctype, but the proposal died out towards the end of last year. / Jonas From bzbarsky at MIT.EDU Mon Oct 5 13:37:35 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Mon, 05 Oct 2009 16:37:35 -0400 Subject: [whatwg] Is there any reason for the continued existence of enctype attribute at the form element In-Reply-To: <4ACA2342.5040703@marksw.com> References: <4ACA2342.5040703@marksw.com> Message-ID: <4ACA590F.1040800@mit.edu> On 10/5/09 12:48 PM, Mark Kaplun wrote: > I have only learned now that there is a "text/palin" option that I have > never heard of, so maybe I'm wrong, but my impression is that there are > only two forms of form, a textual and a file upload. IMHO the browser > can inspect the form before submitting it and decide by itself what is > the correct encoding to use. You can use multipart/form-data with a form that doesn't include any file uploads (and people do this). Presumably they might have reasons for this (e.g. they happen to have a sane multipart MIME parsing library and don't want to deal with the url-encoding mess the application/x-www-form-urlencoded option produces. -Boris From ian at hixie.ch Mon Oct 5 16:28:28 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 5 Oct 2009 23:28:28 +0000 (UTC) Subject: [whatwg] document.head In-Reply-To: References: <6F7B10D2-9E54-46EC-A053-866C162BC796@gmail.com> <6983E57B-A6A8-4D69-9ECA-83E46D6772E8@gmail.com> Message-ID: On Sun, 20 Sep 2009, Joseph Pecoraro wrote: > > Was there any discussion for including "document.head" in HTML5? > Searching the mailing list shows document.head show up a few times in > example code [1][2]. However, there has been no proposal, and it is not > mentioned in the document's IDL [3] in the Spec. > > Developers often do the following to get a reference to the > element (top 2 google results) [4]: > > var head = document.getElementsByTagName('head')[0]; > > Its useful for developers to use that reference to manipulate/append > stylesheets, scripts, and

APPLE

GRAPE

ORANGE

Apple

Grape

Orange

From surkov.alexander at gmail.com Tue Oct 20 22:14:21 2009 From: surkov.alexander at gmail.com (Alexander Surkov) Date: Wed, 21 Oct 2009 13:14:21 +0800 Subject: [whatwg] keyboard behaviour inside of editable area In-Reply-To: <26b395e60910200314y3e30b1f6w381c5c65c095ab77@mail.gmail.com> References: <26b395e60910200314y3e30b1f6w381c5c65c095ab77@mail.gmail.com> Message-ID: Hi, Josh. If I get right HTML5 assumes to treat HTML controls inside of editable area as normal controls. Therefore it's really helpful to know how much special mobile platforms might want to treat controls in editable area. I agree editor behaviour on user input should be defined by platform. However I wouldn't agree it should be browser-dependent. Starting from the point HTML controls inside of editable area are normal controls I just want to ensure these controls are accessible, partially it means they should be operable by keyboard because it's primary tool for assistive technologies users. Shortly all I suggest is to use editor's keyboard navigation rules if caret is on text or use control's keyboard navigation rules if control is focused, also I tried to define rules to make focus transition from editor to control. Therefore I don't touch BiDi behaviour because it's automatically addressed in this case. As well in this light arrow keys in my proposal are just an example to describe desired behaviour. It should be valid for Windows but another keys or ways might be required on another platforms. So my proposal is rather an idea than real proposal, an idea I like to discuss or get it approved. All of this is an attempt to produce general rules to ensure HTML controls are operable. Since controls inside of editable area are normal controls then it shouldn't be allowed to edit option labels (add or remove them), all you can do is to change the selected option. I can see a cases when it might be useful to have an ability to edit options. However I keep in mind default behaviour only. The default behaviour might be overridden by additional editor settings or web service directly to meet these needs. Thank you. Alex. On Tue, Oct 20, 2009 at 6:14 PM, timeless wrote: > On Mon, Oct 12, 2009 at 10:04 AM, Ian Hickson wrote: >> there's nothing that really requires that the >> user agent even support arrow keys, let alone that they work in a >> particular way. > > I believe MicroB, Fennec, and probably Mobile Safari will tend to > treat form controls as very special. > > I don't see any reason to specify this, as in reality, it's up to the > browser and platform to decide how such things should work. Ideally > the teams developing such platforms will evolve solutions which work > for their users. If they don't, I'd expect their users to act as > consumers and vote with their wallets/eyeballs.... (Sadly, that is > unlikely to be a good thing for MicroB). > > Of note, the N900 in most regional variants doesn't have up/down arrow > keys. And when people specify how arrow keys work in contentEditable, > i'd expect them to try to specify how arrow keys work while is > active (an attempt to influence selection length/shape). > > I've heard rumors that Qt has (plans?) for some magical way to control position. > > Alexander Surkov's proposal also doesn't covered BiDi behavior.... > > Also, it's unclear to me what the goal is. Should I, as an end user of > an editable page, be able to edit a ? Message-ID: <1F665702-96C4-4E2D-AC4C-213D48E8829B@apple.com> HTML5 currently says that the signature algorithm used with should be any of "those listed in section 2.2.1 ('RSA Signature Algorithm') of RFC 3279." However, both WebKit and Gecko only ever use the md5WithRSAEncryption signature algorithm. And apparently WebKit ran into compatibility issues with MIT's websites back in 2004 when it tried to use the id- sha1 signature algorithm instead. I'd recommend that HTML5 change to say that only the md5WithRSAEncryption signature algorithm should be used for . -Adam From liszt at coq.no Wed Oct 21 14:39:00 2009 From: liszt at coq.no (=?ISO-8859-1?Q?=D8istein_E._Andersen?=) Date: Wed, 21 Oct 2009 22:39:00 +0100 Subject: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range] In-Reply-To: References: <4B419876-1551-447D-8C77-1B702724EDC8@coq.no> <6E531C99-3CEF-446A-9BE3-1FF79CDA839B@coq.no> <1F0A9F09-B0F8-4AF3-B02B-0C18FF42EAC1@coq.no> Message-ID: On 19 Oct 2009, at 05:52, Ian Hickson wrote: > I've noted your e-mail here [...] and moved the whole thing out of > the spec. That does not seem to apply to the last part of the original e-mail, quoted below. ?istein E. Andersen > Other character encoding issues: > -------------------------------- > > ASCII-compatibility: > The note in ?2.1.5 Character encodings? seems to say that ?variants > of ISO-2022? (presumably including common ones like ISO-2022-CN, > ISO-2022KR and ISO-2022-JP) are ASCII-compatible, whereas HZ-GB-2312 > is not, and I cannot find anything in Section 2.1.5 that would > explain this difference. > > > Discouraged encodings: > ?4.2.5.5 Specifying the document's character encoding? advises > against certain encodings. (Incidentally, this advice probably > deserves not to be ?hidden? in a section nominally reserved for > character encoding declaration issues.) In particular: > >> Authors should not use JIS-X-0208 (JIS_C6226-1983), JIS-X-0212 >> (JIS_X0212-1990), encodings based on ISO-2022, and encodings based >> on EBCDIC. > > It is not clear what this means (e.g., the character set > JIS_C6226-1983 in any encoding, or only when encoded alone according > to RFC1345 as described above); the list of discouraged encodings > seems conspicuously short if it is supposed to be complete; and the > lack of rationale makes it difficult to understand why these > encodings are considered particularly harmful (JIS_C6226-1983 v. > JIS_C6226-1978 or ISO-2022 v. HZ, to mention but two at least > initially puzzling cases). It might be better to say why > particular encodings are better avoided, whether or not the list of > discouraged encodings be presented as definitive. > > Minor grammar detail in 4.2.5.5: >> Conformance checkers may advise against authors using legacy >> encodings. > > This is ambiguous. It should probably be ?advise against authors? > using legacy encodings? or better ?advise authors against using > legacy encodings?. From sebastian at calyptus.eu Wed Oct 21 16:21:34 2009 From: sebastian at calyptus.eu (=?ISO-8859-1?Q?Sebastian_Markb=E5ge?=) Date: Thu, 22 Oct 2009 01:21:34 +0200 Subject: [whatwg] Drop event on form controls In-Reply-To: <4ADF2394.3070401@helsinki.fi> References: <4ADEFB48.2030409@helsinki.fi> <4ADF2394.3070401@helsinki.fi> Message-ID: <491930550910211621n2c0abf55ie66376a54d0a2150@mail.gmail.com> I agree, IE and Firefox dispatches the drop event for both form controls and contentEditable even if dragover isn't canceled. They insert the dropped data unless drop event is canceled. WebKit (Windows) inserts the dropped data but doesn't fire the drop event. If dragover is canceled, then WebKit doesn't insert the dropped data but it does fire the drop event. I tend to agree with the IE and Firefox model. That's more useful. If the default operation is to allow a drop, then you shouldn't have to "prevent default" it to get the drop event. If the default operation isn't to allow a drop, then it shouldn't. Also, the inserted text should be inserted unless the drop event is canceled. But not if preventDefault is called. On Wed, Oct 21, 2009 at 5:07 PM, Olli Pettay wrote: > contentEditable may need special handling too. > Haven't tested how IE (or other browsers) handles that. > > > -Olli > > > On 10/21/09 3:15 PM, Olli Pettay wrote: > >> Hi all, >> >> seems like the draft doesn't specify properly what should happen when >> dropping something to a (text) form control. >> >> The draft says that if dragover isn't canceled, then drag operation >> becomes none, and then later "if the current drag operation is none... >> then the drag operation failed." >> >> Seems like dragover needs to have some default handling when dispatched >> to form controls. >> IE does dispatch a drop event when dragging something to a form control. >> >> br, >> >> -Olli >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.glazman at disruptive-innovations.com Wed Oct 21 23:56:46 2009 From: daniel.glazman at disruptive-innovations.com (Daniel Glazman) Date: Thu, 22 Oct 2009 08:56:46 +0200 Subject: [whatwg] In-Reply-To: References: Message-ID: <4AE0022E.8040801@disruptive-innovations.com> Hi there, That onlyreplace attribute is not enough, and trust me, I have spent quite a while on solutions transforming HTML documents using bits contained in external instances... Hixie referenced at some point in the thread my HTMLOverlays proposal [1] and that proposal has a clear plus compared to the onlyreplace attribute: it's not meant to ONLY replace but ALSO to add elements to an existing container, using an order defined by the web author and not only appending overlaid elements. That's a _major_ win compared to onlyreplace. I am not saying here that onlyreplace is a bad idea, it's even a very good one. And I find VERY amusing to read super-positive comments about it that are exactly contrary to comments I received myself on HTMLOverlays while the two proposals are rather similar :-) That said, there are a few problems to solve: - what means exactly "replacement" here? What's the scope of a

Text

Anyway, it might be reasonable to always replace the element, as it is recommended to have individual titles for every page, and looks like an overkill to give this unique element an id, just to reference it in the onlyreplace list. > - I think a mechanism using a <link> element is better because it's > similar to prefetching. It's also semantically better because it > used a _very_ old proposal of mine called "link dereferencing" [1]. > And of course it is better because it can help resolving the > progressive rendering issues of <a onlyreplace> since the head > is parsed before the body... Can you give a code example how this could look like? From Chris.Taylor at figureout.com Thu Oct 22 02:22:41 2009 From: Chris.Taylor at figureout.com (Chris Taylor) Date: Thu, 22 Oct 2009 10:22:41 +0100 Subject: [whatwg] <a onlyreplace> In-Reply-To: <4AE0223A.3010905@gmx.ch> References: <dd0fbad0910161106r628fe6c5me6b3db686a3188b9@mail.gmail.com> <4AE0022E.8040801@disruptive-innovations.com> <4AE0223A.3010905@gmx.ch> Message-ID: <7805560CD71B3B4793F5FDBCDE22E52B1994491BAB@tpexmb01> Looking at this (simplified) example from Markus: <html> <head> <title id="title">My title

Text

Would it be better to be able to specify multiple onlyload base elements? Like so: My title

Replace the title

Replace the content

Text

Replace me

That way it gives authors much more control over that they choose to be replaced. This does mean that the "onlyreplace" attribute on links (and forms) should perhaps be renamed "onlyreplaceref" or similar. Has this idea already been put forward by someone else? (I may have missed it). Chris This message has been scanned for malware by SurfControl plc. www.surfcontrol.com From daniel.glazman at disruptive-innovations.com Thu Oct 22 02:35:22 2009 From: daniel.glazman at disruptive-innovations.com (Daniel Glazman) Date: Thu, 22 Oct 2009 11:35:22 +0200 Subject: [whatwg] In-Reply-To: <4AE0223A.3010905@gmx.ch> References: <4AE0022E.8040801@disruptive-innovations.com> <4AE0223A.3010905@gmx.ch> Message-ID: <4AE0275A.3010108@disruptive-innovations.com> Markus Ernst wrote: > They are crucially different in some points: > - HTMLOverlays is a ready-to-use script solution. It does not require > any specification nor implementation by UAs. Instead, it requires work > on the authoring side; using HTMLOverlays means totally re-writing your > websites. It's ready as a script, yes, and that is absolutely not satisfactory. It's so simple that it could be specified and implemented by browsers. > - HTMLOverlays does not degrade nicely. If a UA does not support > scripting, or the script is not found for any reason, there is no way to > render the page in a useable manner. This also applies to search > engines, which will not see anything that is part of the overlay - this > will typically apply to the whole navigation. Agreed, and that's why I think a standardized solution is better. > > - I think a mechanism using a element is better because it's > > similar to prefetching. It's also semantically better because it > > used a _very_ old proposal of mine called "link dereferencing" [1]. > > And of course it is better because it can help resolving the > > progressive rendering issues of since the head > > is parsed before the body... > > Can you give a code example how this could look like? > Sure. That only requires to extend the rel attribute to any element. Semantically, it's perfectly ok since onlyreplace is really establishing a link of some sort to a potentially external resource.
From ian at hixie.ch Thu Oct 22 05:23:33 2009 From: ian at hixie.ch (Ian Hickson) Date: Thu, 22 Oct 2009 12:23:33 +0000 (UTC) Subject: [whatwg]
,
, etc. despite them all serving roughly the same purpose. A permanent cost to solve a temporary problem that will disappear on its own, and one that doesn't even need solving - the only benefit is that you get to change your toggle scripts to look for
rather than
sooner. I wanna use
soon too - it gives me the warm fuzzies for some reason even if I have to hack the functionality in myself. But I can accept waiting until IE7 is irrelevant. I'm going to be doing that anyway for a number of other HTML5 features. ~TJ From webmaster at keryx.se Sat Oct 3 10:03:02 2009 From: webmaster at keryx.se (Keryx Web) Date: Sat, 03 Oct 2009 19:03:02 +0200 Subject: [whatwg] The new content model for
breaks rendering in MSIE5-7 In-Reply-To: References: <4AC20FE1.8000200@gmail.com> <4AC23C01.7030203@gmail.com> <4AC23F93.5040204@gmail.com> <4AC25234.7020303@keryx.se> <4AC25B1D.1050505@gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> Message-ID: <4AC783C6.1090907@keryx.se> 2009-10-03 00:51, Tab Atkins Jr. skrev: >
/
only have parsing problems in IE6 and IE7. Both of them > are, finally, actually dropping off the radar. Windows 7 will > accelerate this as people upgrade with an OS that runs IE8 by default. > Give it 2 years or so and most places will be able to justify > ignoring IE7 (many/most sites already ignore IE6). The IE6/7 problem is not the only one. A number of people, myself included, have expressed dissatisfaction from a semantic and teachability viewpoint. It is not better to let dt/dd have three (or perhaps 2) different meanings, and different syntactic rules depending upon the parent element than it would be to have 2 more elements. And if the use cases for details and/or figure is so weak, that they would be dropped JUST BECAUSE they would introduce yet 1 or 2 additional elements to make them work, than we might as well drop them. Do it right or do not do it at all! If an element has (1) a whole new semantic meaning in one place than it has in another place, and (b) different syntactic rules in one place than it has in another place, it is NOT THE SAME ELEMENT by definition. Let's not kid ourselves. We ARE introducing new elements here. It just so happens that they share the same name as 2 old ones. Or at least the same abbreviated name, since some people suggest that they would be expanded to "details type" and "details data", when used with details. What further proof do you need to understand that we are de facto introducing new elements, even if we confusingly, re-use old names? -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/ From jackalmage at gmail.com Sat Oct 3 12:47:06 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Sat, 3 Oct 2009 14:47:06 -0500 Subject: [whatwg] The new content model for
breaks rendering in MSIE5-7 In-Reply-To: <4AC783C6.1090907@keryx.se> References: <4AC20FE1.8000200@gmail.com> <4AC23F93.5040204@gmail.com> <4AC25234.7020303@keryx.se> <4AC25B1D.1050505@gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> <4AC783C6.1090907@keryx.se> Message-ID: On Sat, Oct 3, 2009 at 12:03 PM, Keryx Web wrote: > 2009-10-03 00:51, Tab Atkins Jr. skrev: > >>
/
?only have parsing problems in IE6 and IE7. ?Both of them >> are, finally, actually dropping off the radar. ?Windows 7 will >> accelerate this as people upgrade with an OS that runs IE8 by default. >> ?Give it 2 years or so and most places will be able to justify >> ignoring IE7 (many/most sites already ignore IE6). > > The IE6/7 problem is not the only one. A number of people, myself included, > have expressed dissatisfaction from a semantic and teachability viewpoint. > > It is not better to let dt/dd have three (or perhaps 2) different meanings, > and different syntactic rules depending upon the parent element than it > would be to have 2 more elements. > > And if the use cases for details and/or figure is so weak, that they would > be dropped JUST BECAUSE they would introduce yet 1 or 2 additional elements > to make them work, than we might as well drop them. > > Do it right or do not do it at all! > > If an element has (1) a whole new semantic meaning in one place than it has > in another place, and (b) different syntactic rules in one place than it has > in another place, it is NOT THE SAME ELEMENT by definition. > > Let's not kid ourselves. We ARE introducing new elements here. It just so > happens that they share the same name as 2 old ones. Or at least the same > abbreviated name, since some people suggest that they would be expanded to > "details type" and "details data", when used with details. > > What further proof do you need to understand that we are de facto > introducing new elements, even if we confusingly, re-use old names? Well, no amount of proof would do so; only a convincing enough argument. I, personally, do not feel that
's semantics change between
and
. Nor do I feel they have different syntax at all -
and
do have slightly different syntaxes, but it's very minor and pretty much bound up in the fact that
has multiple name/value pairs while
has only one, so
doesn't have to worry about ordering in the same way that
does. You see, I've authored lots of internal applications for myself and others in my company. Tree structures figure prominently, since these application are often relatively thin layers over the database structure. Looking back, I appear to be split evenly and arbitrarily between using nested
s to handle this structure and using nested headings/sections to handle it. There really doesn't appear to be much rhyme or reason behind my choice of one or the other. Either would be appropriate. The only thing I can see is that possibly the pages I saw more as lists I used
s for, while the pages I saw more as documents I used headings/sections for. So, in my mind,
/
do not hold some special meaning that locks them into only ever being used in
.
is a heading element, nothing more, effectively equivalent to
.
is a sectioning element, nothing more, effectively equivalent (though used slightly differently) to
. Both
and
declare the name for some body of data contained in
or
. Thus using
and
in
to fulfill the same purpose (wrapping the "name" and the "data") is completely natural to me. That's not to say that other solutions wouldn't also be natural, but I find nothing wrong with the status quo on semantic or usability concerns. I mean, would you complain about using or <caption> or <label> or <legend> or what-have-you in <details>? The change in semantics and syntax would be as great or greater than <dt>/<dd>. It so happens that all of those are worse* from a rendering perspective than <dt>/<dd>, so we've discarded them as solutions. But none of them are privileged as 'closer' to the syntax or semantics of the toggler and data elements of <details>. ~TJ * I know that the equivalence is not complete - <h> has an effect on the document outline that <dt> does not. But aside from that, they're equivalent in my eyes. From chuck at jumis.com Sat Oct 3 16:10:53 2009 From: chuck at jumis.com (Charles Pritchard) Date: Sat, 03 Oct 2009 16:10:53 -0700 Subject: [whatwg] Canvas Proposal: aliasClipping property Message-ID: <4AC7D9FD.6050902@jumis.com> There have been a few discussions about anti-aliasing / aliasing in Canvas implementations. Of those I read through, the conflict remains. In some implementations: when drawImage is used along with a clipping path, feathering is applied. This shows up in several projective transformation demos contrasting Firefox with Chrome. I believe that if we allow a toggle for this setting, we can bring some compatibility to the two systems. Enumerate two aliasClipping values : "aliased", "feathered" I consider "anti-aliased" to confusing, I think "feathered" is a better name. ..... [Supplemental] interface CanvasRenderingContext2D { attribute DOMString aliasClipping; // default "feathered" } context . aliasClipping [ = value ] Returns the current aliasing of the clipping region, as applied to rendering operations. Can be set, to change the aliasing value. If any of the arguments are not implemented, throws a NOT_SUPPORTED_ERR exception. CanvasRenderingContext2D.prototype.defineSetter('aliasClipping') { throw NOT_SUPPORTED_ERR; } From gundersen at gmail.com Sat Oct 3 18:34:44 2009 From: gundersen at gmail.com (Marius Gundersen) Date: Sun, 4 Oct 2009 11:34:44 +1000 Subject: [whatwg] Canvas Proposal: aliasClipping property In-Reply-To: <4AC7D9FD.6050902@jumis.com> References: <4AC7D9FD.6050902@jumis.com> Message-ID: <45f4181c0910031834u3741c4cft2dff2caf87129d1a@mail.gmail.com> This sounds like a very good proposal, but can we extend it to include other things than just drawImage? I'm not sure how useful it would be, but it could perhaps include all the other drawing options, like stroking and filling paths created with lineTo, arc, etc. Marius Gundersen On Sun, Oct 4, 2009 at 9:10 AM, Charles Pritchard <chuck at jumis.com> wrote: > There have been a few discussions about anti-aliasing / aliasing in Canvas > implementations. > Of those I read through, the conflict remains. > > In some implementations: when drawImage is used along with a clipping path, > feathering is applied. This shows up in several projective transformation > demos > contrasting Firefox with Chrome. > > I believe that if we allow a toggle for this setting, we can bring some > compatibility > to the two systems. > > Enumerate two aliasClipping values : "aliased", "feathered" > > I consider "anti-aliased" to confusing, I think "feathered" is a better > name. > > ..... > > [Supplemental] > interface CanvasRenderingContext2D { > attribute DOMString aliasClipping; // default "feathered" > } > > context . aliasClipping [ = value ] > > Returns the current aliasing of the clipping region, as applied to > rendering operations. > > Can be set, to change the aliasing value. > > If any of the arguments are not implemented, throws a NOT_SUPPORTED_ERR > exception. > > CanvasRenderingContext2D.prototype.defineSetter('aliasClipping') { throw > NOT_SUPPORTED_ERR; } > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091004/96c76cef/attachment-0002.htm> From robert at ocallahan.org Sat Oct 3 18:46:56 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Sun, 4 Oct 2009 14:46:56 +1300 Subject: [whatwg] Canvas Proposal: aliasClipping property In-Reply-To: <4AC7D9FD.6050902@jumis.com> References: <4AC7D9FD.6050902@jumis.com> Message-ID: <11e306600910031846t375ed2d1q405a210ad76b2aac@mail.gmail.com> I think "feathered" isn't a good term. It's vary rarely used in graphics in my experience. "aliasClipping" isn't a good term either, since there's no clipping going on typically. I would just have boolean property named "antialias". 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] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091004/d0a800f3/attachment-0002.htm> From webmaster at keryx.se Sun Oct 4 02:13:00 2009 From: webmaster at keryx.se (Keryx Web) Date: Sun, 04 Oct 2009 11:13:00 +0200 Subject: [whatwg] The new content model for <details> breaks rendering in MSIE5-7 In-Reply-To: <dd0fbad0910031247s2de6baf3r8d825aed345faa32@mail.gmail.com> References: <4AC20FE1.8000200@gmail.com> <4AC23F93.5040204@gmail.com> <4AC25234.7020303@keryx.se> <4AC25B1D.1050505@gmail.com> <dd0fbad0909291241k1f578f4ft84bbab51cb9a76e5@mail.gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> <dd0fbad0910021551k1c784944jbc3256a67e575d3a@mail.gmail.com> <4AC783C6.1090907@keryx.se> <dd0fbad0910031247s2de6baf3r8d825aed345faa32@mail.gmail.com> Message-ID: <4AC8671C.6020603@keryx.se> 2009-10-03 21:47, Tab Atkins Jr. skrev: > Well, no amount of proof would do so; only a convincing enough > argument. I, personally, do not feel that<dt>'s semantics change > between<dl> and<details>. Nor do I feel they have different syntax > at all -<dl> and<details> do have slightly different syntaxes, but > it's very minor and pretty much bound up in the fact that<dl> has > multiple name/value pairs while<details> has only one, so<details> > doesn't have* to worry about ordering in the same way that<dl> does. > > etc In what way is the SYNTAX different? We seem to agree on this: First and foremost, in <dl> the order is all important. Here it would not matter. In <dl> one may have several <dd> for each <dt> (or several <dt>'s in a row), here one may not. You call this "minor", I say confusing. But we have in fact created a new syntax - why is that better than creating new elements? In what way is the SEMANTICS different? > So, in my mind, <dt>/<dd> do not hold some special meaning that > locks them into only ever being used in <dl>. <dt> is a heading > element, nothing more, effectively equivalent to <h1>. Well, that is not what the SPEC says is it? > I mean, would you complain about using <title> or <caption> or <label> > or <legend>... in <details>? Yes, I would. I am arguing in favor of introducing a new element, which would be the zero cost solution, since <details> is new anyway. + No hacks besides those that we already use to get details working as such in legacy browsers. + When implementing details the browser vendors will not have a harder time using a new element than they would using dt/dd. + We would keep the several meanings per element count down, which from a teachability POV is more important than keeping the total number of elements down. And from that POV nuances are often harder to pick up than anything else. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/ From ian at hixie.ch Sun Oct 4 04:48:29 2009 From: ian at hixie.ch (Ian Hickson) Date: Sun, 4 Oct 2009 11:48:29 +0000 (UTC) Subject: [whatwg] <dialog> removal In-Reply-To: <63df84f0909021833pc75c953va61b2c1c15335880@mail.gmail.com> References: <4A81087F.1000800@romantschuk.fi> <Pine.LNX.4.62.0908152220170.6420@hixie.dreamhostps.com> <4A89179D.1040606@romantschuk.fi> <7c2a12e20908170630j59ed1458haeafaef274f26e93@mail.gmail.com> <4A8BA0BA.1030507@romantschuk.fi> <AE2B216B-34B9-43F6-BF48-DD87178450F1@adactio.com> <4A8C142F.5030609@opera.com> <Pine.LNX.4.62.0908280026200.13789@hixie.dreamhostps.com> <63df84f0908280116u3db8f9f2t45b401f592ca8973@mail.gmail.com> <Pine.LNX.4.62.0909022147190.6775@hixie.dreamhostps.com> <63df84f0909021833pc75c953va61b2c1c15335880@mail.gmail.com> Message-ID: <Pine.LNX.4.62.0910041146340.25383@hixie.dreamhostps.com> On Wed, 2 Sep 2009, Jonas Sicking wrote: > > > > Neither <dialog> nor <meter> were added because they are expected to > > be used in great numbers. Both were added to prevent another element > > from being _mis_used. (Specifically, <dialog> takes away from the risk > > of people marking up dialogs as association lists, and <meter> takes > > away from the risk of people marking up gauges as progress bars.) > > While I can see the argument for <meter>, I'm not sure I see it with > <dialog>. First of all, as others have pointed out, <dialog> is > generally not feature-full enough to mark up dialogs. Second, given that > association lists already exist, we should be able to check existing > pages to see if people are abusing lists to mark up dialogs. > > I started by looking at some sites with the Romeo and Juliet play: > > http://www.william-shakespeare.info/act1-script-text-romeo-and-juliet.htm > Uses > > http://shakespearemiami.tripod.com/id22.html > Uses <blockquote> > > http://shakespeare.mit.edu/romeo_juliet/full.html > Uses <blockquote> > > http://www.script-o-rama.com/movie_scripts/r/romeo-and-juliet-script-screenplay.html > Uses <pre> > > http://www.clicknotes.com/romeo/T11.html > and > > http://www.opensourceshakespeare.org/views/plays/play_view.php?WorkID=romeojuliet&Act=1&Scene=1&Scope=scene > One <ul><li>...</li></ul> for each quote. > > http://www.cambridge.org/us/catalogue/catalogue.asp?isbn=9780521618700&ss=exc > Uses > > > I also looked for transcripts of the frost/nixon interview: > http://www.guardian.co.uk/theguardian/2007/sep/07/greatinterviews1 > Uses > > http://digbysblog.blogspot.com/2008/06/inspiration-by-digby-as-constitutional.html > Uses > > http://www.ourblook.com/Reporters-and-the-Media/The-Nixon-Interviews-with-David-Frost.html > Uses > > http://remember-nixon.org/ > Uses <pre> > > https://pol.moveon.org/archive/breakingthelaw_sub1.html > Basically uses one <ul><li>...</li></ul> for each quote. > > http://belowthebeltway.com/2009/04/30/condi-rice-channels-richard-nixon-if-the-president-authorizes-it-its-not-illegal/ > Uses > > > I also looked at transcripts for the "Silly Job Interview" play by Monty Python: > > http://www.orangecow.org/pythonet/sketches/intview.htm > Uses > (this site does use a list, but not for the actual dialog) > > http://www.ibras.dk/montypython/episode05.htm > Uses a table with a <tr> for each line in the dialog. > (This is actually another monty python skit, but it turned up in my > search and I figured it didn't really matter) > > http://montypython.50webs.com/scripts/Series_1/35.htm > Uses > > http://www.ulrikchristensen.dk/scripts/montypython/sillyjob.html > Uses > > http://www.cardinalfang.net/episodes/season_one/silly_job_interview.html > Uses (and <o:p>) > > > Finally I simply did a google search for "interview transcript": > http://www.cbsnews.com/stories/2003/12/28/60minutes/main590381.shtml > Uses > > http://www.pokerlistings.com/blog/ashman103-the-interview-transcript > Uses > > http://www.pgatour.com/2009/tournaments/r027/08/30/sunday.transcript.slocum/index.html > Uses > > http://www.blazersedge.com/2009/8/15/990765/clyde-drexler-interview-transcript > Uses > > http://www.npr.org/templates/story/story.php?storyId=7065633 > Uses > > http://www.boston.com/sports/football/patriots/reiss_pieces/2008/05/bill_belichicks.html > Uses > > http://d5.allthingsd.com/20070531/d5-gates-jobs-transcript/ > Uses > > http://www.guardian.co.uk/media/2008/nov/08/dizzee-rascal-paxman-jeremy-bbc > Uses > > http://www.telegraph.co.uk/news/newstopics/jaycee-lee-dugard/6105540/Phillip-Garridos-interview-transcript.html > Uses > > http://www.defenselink.mil/transcripts/transcript.aspx?transcriptid=2594 > Uses > > http://entertainment.timesonline.co.uk/tol/arts_and_entertainment/tv_and_radio/article2777973.ece > Uses > > http://www.cdi.org/adm/1351/Yafei.html > Uses > > http://www.ronsuskind.com/thewayoftheworld/transcripts/ > Uses > > http://www.anusha.com/osamaint.htm > Uses Thanks for this research! Based on the data above, I removed <dialog> (a few weeks ago now), and replaced it with a section on how to mark up conversations that tries to pave the cowpath that most of the above walk (namely, using ). (Sorry for the late replying relative to the time of the edit.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Sun Oct 4 05:01:23 2009 From: ian at hixie.ch (Ian Hickson) Date: Sun, 4 Oct 2009 12:01:23 +0000 (UTC) Subject: [whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol) In-Reply-To: <4AA18B47.6050205@gmail.com> References: <4A7B7C7C.3040202@mortbay.com> <58A4FD12-353D-4ADA-AE7C-99F4A31FD8D4@apple.com> <4A7BD6FF.8020804@mortbay.com> <63df84f0908072030t5f8d16e9hb13236030adbf129@mail.gmail.com> <4A81E67B.1030004@gmail.com> <63df84f0908111835r3213f87dh4fb451b8aa28b21d@mail.gmail.com> <Pine.LNX.4.62.0908141035510.6420@hixie.dreamhostps.com> <63df84f0908141413j557f06a9x7f4f2aab8fd38671@mail.gmail.com> <Pine.LNX.4.62.0909040538130.6775@hixie.dreamhostps.com> <4AA18B47.6050205@gmail.com> Message-ID: <Pine.LNX.4.62.0910041158310.25383@hixie.dreamhostps.com> On Fri, 4 Sep 2009, Wellington Fernando de Macedo wrote: > > Ian, do you intend to add any other features to the first version of > WebSocket? If yes, which ones? I was thinking of adding multiplexing, but after discussing this with a variety of people, I'm leaning towards leaving the protocol as is, and letting authors implement their own multiplexing if they need it. Other than that, I have no plans to add any features or make any further major changes to the normative requirements in the protocol unless someone brings up some serious problems. I recommend rereading the spec and comparing it to any tests and implementations before shipping, as there have been a number of subtle changes over the past few months, such as dropping redirect support, changing the default ports, changing how URLs are parsed, and the like. I have some outstanding feedback on WebSockets, which I'll be getting to in the coming days. HTH, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jackalmage at gmail.com Sun Oct 4 07:51:13 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Sun, 4 Oct 2009 09:51:13 -0500 Subject: [whatwg] The new content model for <details> breaks rendering in MSIE5-7 In-Reply-To: <4AC8671C.6020603@keryx.se> References: <4AC20FE1.8000200@gmail.com> <4AC25B1D.1050505@gmail.com> <dd0fbad0909291241k1f578f4ft84bbab51cb9a76e5@mail.gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> <dd0fbad0910021551k1c784944jbc3256a67e575d3a@mail.gmail.com> <4AC783C6.1090907@keryx.se> <dd0fbad0910031247s2de6baf3r8d825aed345faa32@mail.gmail.com> <4AC8671C.6020603@keryx.se> Message-ID: <dd0fbad0910040751p144a2482o9ba21f28f1ea21aa@mail.gmail.com> On Sun, Oct 4, 2009 at 4:13 AM, Keryx Web <webmaster at keryx.se> wrote: > I am arguing in favor of introducing a new element, which would be the zero > cost solution, since <details> is new anyway. It's not a zero-cost solution, though. It introduces another* nearly identical heading-type element to the language, joining the ranks of the dozen+ we already have. Trying to remember what heading-type element to use in <details> as opposed to in <fieldset> or what-have-you is a learning nightmare of a different variety. > + No hacks besides those that we already use to get details working as such > in legacy browsers. <dt> only requires extra hacks in two browsers that are on the way out. Given a little bit more time they'll be gone completely, and we can stop worrying about this. > + When implementing details the browser vendors will not have a harder time > using a new element than they would using dt/dd. I'm not certain what you mean by this. Indeed they won't have a harder time - the difficulty will be the same either way. > + We would keep the several meanings per element count down, which from a > teachability POV is more important than keeping the total number of elements > down. > > And from that POV nuances are often harder to pick up than anything else. Just teach <dt>/<dd> in a way that makes this easier to learn. ~TJ From dean.edwards at gmail.com Sun Oct 4 08:58:00 2009 From: dean.edwards at gmail.com (Dean Edwards) Date: Sun, 04 Oct 2009 16:58:00 +0100 Subject: [whatwg] The new content model for <details> breaks rendering in MSIE5-7 In-Reply-To: <dd0fbad0910040751p144a2482o9ba21f28f1ea21aa@mail.gmail.com> References: <4AC20FE1.8000200@gmail.com> <4AC25B1D.1050505@gmail.com> <dd0fbad0909291241k1f578f4ft84bbab51cb9a76e5@mail.gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> <dd0fbad0910021551k1c784944jbc3256a67e575d3a@mail.gmail.com> <4AC783C6.1090907@keryx.se> <dd0fbad0910031247s2de6baf3r8d825aed345faa32@mail.gmail.com> <4AC8671C.6020603@keryx.se> <dd0fbad0910040751p144a2482o9ba21f28f1ea21aa@mail.gmail.com> Message-ID: <4AC8C608.2020402@gmail.com> On 04/10/2009 15:51, Tab Atkins Jr. wrote: > <dt> only requires extra hacks in two browsers that are on the way > out. Given a little bit more time they'll be gone completely, and we > can stop worrying about this. > I'm sorry but you are really understating the problem here. -dean From jackalmage at gmail.com Sun Oct 4 10:11:31 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Sun, 4 Oct 2009 12:11:31 -0500 Subject: [whatwg] The new content model for <details> breaks rendering in MSIE5-7 In-Reply-To: <4AC8C608.2020402@gmail.com> References: <4AC20FE1.8000200@gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> <dd0fbad0910021551k1c784944jbc3256a67e575d3a@mail.gmail.com> <4AC783C6.1090907@keryx.se> <dd0fbad0910031247s2de6baf3r8d825aed345faa32@mail.gmail.com> <4AC8671C.6020603@keryx.se> <dd0fbad0910040751p144a2482o9ba21f28f1ea21aa@mail.gmail.com> <4AC8C608.2020402@gmail.com> Message-ID: <dd0fbad0910041011o37866f98q4212fceac2c2b9e1@mail.gmail.com> On Sun, Oct 4, 2009 at 10:58 AM, Dean Edwards <dean.edwards at gmail.com> wrote: > On 04/10/2009 15:51, Tab Atkins Jr. wrote: >> >> <dt> ?only requires extra hacks in two browsers that are on the way >> out. ?Given a little bit more time they'll be gone completely, and we >> can stop worrying about this. >> > > I'm sorry but you are really understating the problem here. Can you elaborate? Are there rendering problems in any other browsers? Are you expecting IE6 and IE7 to remain relevant forever? Is there something else I'm missing? Is this too many questions in a row? ~TJ From dean.edwards at gmail.com Sun Oct 4 10:56:55 2009 From: dean.edwards at gmail.com (Dean Edwards) Date: Sun, 04 Oct 2009 18:56:55 +0100 Subject: [whatwg] The new content model for <details> breaks rendering in MSIE5-7 In-Reply-To: <dd0fbad0910041011o37866f98q4212fceac2c2b9e1@mail.gmail.com> References: <4AC20FE1.8000200@gmail.com> <4AC265C8.8020405@gmail.com> <4AC27447.1020208@keryx.se> <4AC6802F.3020306@gmail.com> <dd0fbad0910021551k1c784944jbc3256a67e575d3a@mail.gmail.com> <4AC783C6.1090907@keryx.se> <dd0fbad0910031247s2de6baf3r8d825aed345faa32@mail.gmail.com> <4AC8671C.6020603@keryx.se> <dd0fbad0910040751p144a2482o9ba21f28f1ea21aa@mail.gmail.com> <4AC8C608.2020402@gmail.com> <dd0fbad0910041011o37866f98q4212fceac2c2b9e1@mail.gmail.com> Message-ID: <4AC8E1E7.3000006@gmail.com> On 04/10/2009 18:11, Tab Atkins Jr. wrote: > On Sun, Oct 4, 2009 at 10:58 AM, Dean Edwards<dean.edwards at gmail.com> wrote: >> On 04/10/2009 15:51, Tab Atkins Jr. wrote: >>> >>> <dt> only requires extra hacks in two browsers that are on the way >>> out. Given a little bit more time they'll be gone completely, and we >>> can stop worrying about this. >>> >> >> I'm sorry but you are really understating the problem here. > > Can you elaborate? Are there rendering problems in any other > browsers? > Is there something else I'm missing? Is this too many questions in a > row? > MSIE5-7 usage is currently between 25% and 30%. It will take a number of years before it becomes insignificant. The two hacks you mention are fairly hideous. One of them can potentially prevent other scripts from executing. We've gone full circle on this subject now. We are starting to repeat ourselves. -dean From ian at hixie.ch Sun Oct 4 19:32:12 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 5 Oct 2009 02:32:12 +0000 (UTC) Subject: [whatwg] More prohibited characters for unquoted attributes are needed In-Reply-To: <7c2a12e20909071045m60b36520s8cf050d8f0e3e8db@mail.gmail.com> References: <7c2a12e20909060435w346d6d70l486fe1ceb3e0d9bf@mail.gmail.com> <066122B3-B866-49C9-BE1C-735FB085596F@googlemail.com> <7c2a12e20909071045m60b36520s8cf050d8f0e3e8db@mail.gmail.com> Message-ID: <Pine.LNX.4.62.0910050200140.25383@hixie.dreamhostps.com> On Mon, 7 Sep 2009, Aryeh Gregor wrote: > On Mon, Sep 7, 2009 at 1:34 PM, Geoffrey Sneddon > <foolistbar at googlemail.com> wrote: > > Apparently Hixie had previously said he didn't want to change this as it > > will become a non-issue over time. I think it does matter due to the > > security issues it presents in existing UAs. Conforming markup (using > > elements/attributes allowed in HTML 4.01) should not cause JS to execute in > > one browser but not in another. > > I agree with you as an author. I wrote an HTML output function in > MediaWiki assuming that what the standard says is known to be > interoperable, which is apparently wrong. If I hadn't been keeping up > with HTML 5, I would have introduced an XSS vulnerability because of > some browsers' handling of `. > > If the problem will go away with time, then perhaps a later version of > the standard could make such unquoted attributes conforming, once > there's no more problem with them. As far as I can tell, this is an IE bug; treating "`" as an attribute quoting character is non-conforming in any version of HTML so far, it seems. I'm certainly not going to make it non-conforming to stumble into any IE bug or difference in parsing between IE and previous specs or other browsers; we'd just end up with an asanine set of conformance requirements. For example, should this be non-conforming? <!DOCTYPE html> <title>Test
Search: This perfectly innocent piece of HTML content (HTML2-compliant except for the DOCTYPE) results in a non-tree DOM in IE8. Should we make it non-conforming? Similarly, IE conditional comments make it trivial to trigger scripts in IE but not another UA; indeed people do this on purpose. Should we make those non-conforming also? As I understand it, the attack here is a site that allows the user to input text that is used verbatim in two attributes, such that the user can set the first attribute's value to: ` ...and the second to: ` onload='...payload...' end=x ...with the assumption that the site is going to not quote the first one, and quote the second one with double quotes: ...which in IE, for some reason, gets treated as: I've disallowed ` in unquoted attribute values for now, but I think we should revert this once IE has fixed this bug for a few years. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Sun Oct 4 21:13:14 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 5 Oct 2009 04:13:14 +0000 (UTC) Subject: [whatwg] HTML 5 drag and drop feedback In-Reply-To: <491930550909171309q6259123cu87886cb9d0aefb52@mail.gmail.com> References: <851CE2FD-C766-4C19-B399-D42E7D50232A@280north.com> <0024AA4F-6B6B-4D51-A4AF-472101DDCFDC@280north.com> <6C811B97-5584-4BEB-BF20-1B5D82C1C8E4@280north.com> <491930550909171309q6259123cu87886cb9d0aefb52@mail.gmail.com> Message-ID: On Thu, 17 Sep 2009, Sebastian Markb?ge wrote: > > No browser has implemented the copy/paste part of the spec. Few parts of the spec are perfectly implemented anywhere today, indeed. That's what it'll take years to get to -- that's where the "2022" estimate comes from, in fact -- I doubt we'll have two perfect implementations before then. > As for lazy data... > > If the drag/drop is actually a copy/paste, you still have to serialize > ALL data. If your script made the assumption that it wouldn't, then that > could cause some interesting bloated clipboard. To me, this is just > another example of why the copy/paste API should be separate. I don't see why copy and paste is different than drag and drop here. In both cases, you would want to push a promise into the dataTransfer (or its analogue) for performance reasons. > I've also suggested that you allow for lazy loading of data as entire > files using: dataTransfer.setRemoteData(type, uri); > > Using a remote URI in the clipboard, that API could lazily load data > even after the document is unloaded. > > But I also like the idea of a callback. Yes, I think this is a worthwhile addition to the API -- once the implementations are closer to what the spec says. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Sun Oct 4 23:40:00 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 5 Oct 2009 06:40:00 +0000 (UTC) Subject: [whatwg] Quoted (') and (") appear as ('''') and (''''') In-Reply-To: <471B7E36-97A6-4FC3-A6BA-068B3E5A8229@coq.no> References: <471B7E36-97A6-4FC3-A6BA-068B3E5A8229@coq.no> Message-ID: On Thu, 17 Sep 2009, ?istein E. Andersen wrote: > > Printable Unicode characters are referred to in at least five different ways: > U+003D EQUALS SIGN (`=`) > U+003D EQUALS SIGN ("`=`") > U+003D EQUALS SIGN character (=) > U+002D HYPHEN-MINUS ("-") > U+003D EQUALS SIGN > > Printable ASCII-characters are usually referred to as follows: > 0x3D (ASCII '=') > > The ideal solution would of course be to make this fully consistent ? e.g., by > using the style U+... (`...`) for Unicode all the time and perhaps > also 0x... (ASCII `...`) for ASCII. > > Failing that, "'" and '"' (two occurrences of each, excluding an unrelated > unproblematic instance inside a script) should be changed since they appear > confusingly as ''''' and '''' in a sans-serif typeface. Fixed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From simonp at opera.com Mon Oct 5 02:34:55 2009 From: simonp at opera.com (Simon Pieters) Date: Mon, 05 Oct 2009 11:34:55 +0200 Subject: [whatwg] [html5] r4029 - [e] (0) Example of
use without
. In-Reply-To: References: <20090929055721.2003F38E1F3@hixie.dreamhostps.com> Message-ID: On Wed, 30 Sep 2009 00:54:14 +0200, Ian Hickson wrote: > On Tue, 29 Sep 2009, Gordon P. Hemsley wrote: >> >> s/Html/html/ > > Actually that was intentional in that example. I like to show a variety > of > syntaxes so that people can see that they can do whichever one they > prefer. ...but my original comment still stands: s/DOCTPE/DOCTYPE/ -- Simon Pieters Opera Software From ian at hixie.ch Mon Oct 5 03:49:42 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 5 Oct 2009 10:49:42 +0000 (UTC) Subject: [whatwg] status of html5 Custom scheme and content handlers? In-Reply-To: References: Message-ID: On Fri, 18 Sep 2009, brg wrote: > > RE: 6.8.2 > status of html5 Custom scheme and content handlers? > > I ask because I am interesting in providing an implementation, and am > wondering if it is stable enough to start. It is currently marked as a > Working Draft, although I can not find any discussion since late spring, > 2009. It's been implemented and shipped in Firefox for some time. I don't know how stable it is, though. There have been some suggestions that we should use a different design altogether, though nobody has really suggested anything better yet. Things get more stable the more implementations we have, though. > It reads as if the spec is fairly complete to provide an experimental > implementation, but perhaps could use a list of forbidden schemes > (eg.http, https, file). I didn't want to give an explicit list, because each browser might have a different set of special schemes, and I didn't want to mislead implementors into not thinking about this carefully. HTH, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Oct 5 04:27:08 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 5 Oct 2009 11:27:08 +0000 (UTC) Subject: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling In-Reply-To: References: Message-ID: On Sat, 19 Sep 2009, Michael A. Puls II wrote: > > Currently, registerProtcolHandler works like this: > > navigator.registerProtocolHandler("protocol", "http://example.org/?uri=%s", "title"); > > However, this doesn't allow the site to specify some useful and > important information about the site like: > > 1. What encoding the server expects. For example, uri= might expect the > protocol link that was invoked in the browser to be interpreted as > koi8-r instead of utf-8. This might be the case even if the page that > uses registerProtocolHandler uses Windows-1251 for example. Sites that want to use registerProtocolHandler() must use UTF-8. > 2. The location of an icon like a favicon.ico file or png etc. I could see that as being mildly useful, though I would be concerned with the phishing risk. It seems that in most cases, the UA could just reuse the favicon of the page that registered the handler, though, maybe refreshing it from the page of the handler after the first time it is used. Also, it's unclear how we'd let the icon get updated when the site's icon changes; if we honour HTTP caching semantics or have a forced lifetime, then we have a privacy leak (a hostile site could maybe register a handler forcibly using a variety of induced-click techniques, or using social engineering, and then would just need to listen to the regular pings from the client updating the image), and if we don't ever update the image, then instead we have an out-of-date icon which could be worse than no icon at all. > 3. URI to a help page where the site explains how it makes uses of > registerProtocolHandler and gives help and support contacts etc. The UA can already keep track of the page from which the user registered the handler, which seems suitable. > 4. Whether to use "POST" instead of GET. Always use GET. You're only sending a URL anyway. > Finally, it's unfortunate that registerProtocolHandler can't optionally > support a custom format string for the second argument and a format > argument that's a function that gets the URI the user clicked on passed > to it. Why can't the server just do that server-side? That way it doesn't have to worry about updating clients later if it wants to support more features. > It's also unfortunate that it's so domain restricted. That's a good > default, but you can see that Firefox has an override for a reason. Not sure what you mean here. > For example, all of these webmails don't support what > registerProtocolHandler emits. They only support individual values, > which are different for each webmail. > > "http://mymail.operamail.com/scripts/mail/Outblaze.mail?compose=1&did=1&a=1&to=&subject=&body=&cc=&bcc=" > "http://mail.live.com/mail/EditMessageLight.aspx?n=&to=&cc=&bcc=&subject=&body=" > "http://compose.mail.yahoo.com/?To=&Subj=&Cc=&Bcc=&Body=" > "http://your_squirrelmail_server.com/src/compose.php?send_to=&subject=&body=&send_to_cc=&send_to_bcc=" > "http://your_horde_server.com/horde/imp/compose.php?popup=0&to=&cc=&msg=&subject=&bcc=" > "http://mail01.mail.com/scripts/mail/Outblaze.mail?composeto=&subject=&body=&cc=&bcc=&compose=1" > "http://win.mail.ru/cgi-bin/sentmsg?To=&CC=&BCC=&Subject=&BodyUTF8=&accel=1" > "http://your_roundcubemail_server/?_task=mail&_action=compose&_to=&_subject=&_body=&_cc=&_bcc=" > > In these cases, the URI format string in registerProtocolHandler would > need a %key for to, subject, body, cc and bcc. The site could use %t, > %j, %k and %l and %m for these for example. But, for the UA to > understand those %keys (since the UA would only understands %s), a > custom function would be needed that did the processing on the link the > user clicked and returned the URI argument with the %keys replaced with > the desired values. If a site wanted to support these, it need but provide a CGI script that parsed the mailto: URL and redirected the user to the appropriate server. It could even support other encodings. On Tue, 22 Sep 2009, Michael A. Puls II wrote: > > Say the user sees that things are not working right with the handler. > The user goes into the options to see what's doing with the handler > settings and notices the link. The user clicks on it. Then, on the page, > it says "Attention: We've changed some things with what our server > accepts from our protocol handler. You need to register the handler > again by clicking here to get the updated version" for example. User > does and is happy again. :) This seems highly optimistic. I think a more likely scenario is user finds things are broken, user goes whining in a forum, someone there points them to the site that they are whining about, and on the site there's a notice or something. Or, the user finds it's broken, and they just go straight to the site and try to reregister, and it "fixes" itself (with the addition of a new handler). I don't think the link you're suggesting would get much if any traffic. I'm not sure why a handler would break though. I mean, there's very little that can change. Sites can always just do redirects. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From shadow2531 at gmail.com Mon Oct 5 06:37:05 2009 From: shadow2531 at gmail.com (Michael A. Puls II) Date: Mon, 05 Oct 2009 09:37:05 -0400 Subject: [whatwg] registerProtocolHandler - allow site to specify more info and do custom handling In-Reply-To: References: Message-ID: On Mon, 05 Oct 2009 07:27:08 -0400, Ian Hickson wrote: > On Sat, 19 Sep 2009, Michael A. Puls II wrote: >> >> Currently, registerProtcolHandler works like this: >> >> navigator.registerProtocolHandler("protocol", >> "http://example.org/?uri=%s", "title"); >> >> However, this doesn't allow the site to specify some useful and >> important information about the site like: >> >> 1. What encoding the server expects. For example, uri= might expect the >> protocol link that was invoked in the browser to be interpreted as >> koi8-r instead of utf-8. This might be the case even if the page that >> uses registerProtocolHandler uses Windows-1251 for example. > > Sites that want to use registerProtocolHandler() must use UTF-8. O.K., so you definitely, no doubt about it, want to make that a requirement. If so, fine, just want to make sure. >> 2. The location of an icon like a favicon.ico file or png etc. > > I could see that as being mildly useful, though I would be concerned with > the phishing risk. It seems that in most cases, the UA could just reuse > the favicon of the page that registered the handler, though, maybe > refreshing it from the page of the handler after the first time it is > used. Also, it's unclear how we'd let the icon get updated when the > site's > icon changes; if we honour HTTP caching semantics or have a forced > lifetime, then we have a privacy leak (a hostile site could maybe > register > a handler forcibly using a variety of induced-click techniques, or using > social engineering, and then would just need to listen to the regular > pings from the client updating the image), and if we don't ever update > the > image, then instead we have an out-of-date icon which could be worse than > no icon at all. > > >> 3. URI to a help page where the site explains how it makes uses of >> registerProtocolHandler and gives help and support contacts etc. > > The UA can already keep track of the page from which the user registered > the handler, which seems suitable. O.K., there can be some guidelines/tutorials that recommend that the page that registers the handler is also the help page so that UAs can use that info if needed. It could also be recommended in such a tutorial that the page should use the desired favicon so UAs can use it if they want (and how they want and with what restrictions they want) >> 4. Whether to use "POST" instead of GET. > > Always use GET. You're only sending a URL anyway. But, with POST you can send longer data (depending on the server and its config). Since %s is a percent-encoded version of data that's usually already percent-encoded (in parts of the URI), a lot of that length is lost in just percent-encoding (lots of "%2525"s for example). Also, the devs for one webmail even prefer POST data as they said that it's less revealing when submitting through a proxy. But, I never validated that. >> Finally, it's unfortunate that registerProtocolHandler can't optionally >> support a custom format string for the second argument and a format >> argument that's a function that gets the URI the user clicked on passed >> to it. > > Why can't the server just do that server-side? That way it doesn't have > to > worry about updating clients later if it wants to support more features. I'm not saying they can't. More like, I'm saying they won't or cannot in a timely manner and that there's a better chance of support if they don't have to change their server-side scripts and can just use a little JS. Also, with your user hat on, you should see why it'd be great to have a standardized function to do customize handling yourself to workaround lack of support for %s. >> It's also unfortunate that it's so domain restricted. That's a good >> default, but you can see that Firefox has an override for a reason. > > Not sure what you mean here. "file:///c:/documents%20and%20settings/user/desktop/test.html" can't register a "mailto" handler for "http://foo.org/?uri=%s" in Firefox by default. The URL argument has to be on the same domain or it is denied. Firefox does have an override though in about config, which you must use to get that to work. I see the spec leaves this up to the UA to do what it wants though, so nevermind. I also seem to remember that the intent was that the registered handler would only be invoked when clicking on links on pages on the domain that registered the handler. That would mean that the protocol handling would only work on the site's pages and no other sites. However, I don't see that in the spec and that's not how it works in FF, so nevermind. >> For example, all of these webmails don't support what >> registerProtocolHandler emits. They only support individual values, >> which are different for each webmail. >> >> "http://mymail.operamail.com/scripts/mail/Outblaze.mail?compose=1&did=1&a=1&to=&subject=&body=&cc=&bcc=" >> "http://mail.live.com/mail/EditMessageLight.aspx?n=&to=&cc=&bcc=&subject=&body=" >> "http://compose.mail.yahoo.com/?To=&Subj=&Cc=&Bcc=&Body=" >> "http://your_squirrelmail_server.com/src/compose.php?send_to=&subject=&body=&send_to_cc=&send_to_bcc=" >> "http://your_horde_server.com/horde/imp/compose.php?popup=0&to=&cc=&msg=&subject=&bcc=" >> "http://mail01.mail.com/scripts/mail/Outblaze.mail?composeto=&subject=&body=&cc=&bcc=&compose=1" >> "http://win.mail.ru/cgi-bin/sentmsg?To=&CC=&BCC=&Subject=&BodyUTF8=&accel=1" >> "http://your_roundcubemail_server/?_task=mail&_action=compose&_to=&_subject=&_body=&_cc=&_bcc=" >> >> In these cases, the URI format string in registerProtocolHandler would >> need a %key for to, subject, body, cc and bcc. The site could use %t, >> %j, %k and %l and %m for these for example. But, for the UA to >> understand those %keys (since the UA would only understands %s), a >> custom function would be needed that did the processing on the link the >> user clicked and returned the URI argument with the %keys replaced with >> the desired values. > > If a site wanted to support these, it need but provide a CGI script that > parsed the mailto: URL and redirected the user to the appropriate server. > It could even support other encodings. Yep, this is basically what Gmail does and works great. It basically converts "https://mail.google.com/mail/?extsrc=mailto&url=" into what's really supported, which is: "http://mail.google.com/mail/?compose=1&view=cm&fs=1&to=&su=&body=&cc=&bcc=". However, it doesn't seem like many other sites will do that or even get the mailto URI parsing right. They can't even fix the bugs in their regular compose URIs. (I hate to name names, but mail.live.com and mail.yahoo.com are absolutely horrible at getting things right in these cases. But, as you know, users still insist on using those sites, so standardized workaround capabilities sound great to me. You can read through to get an idea of some of the problems.) If you could do custom handling with registerProtocolHandler, you could register a handler yourself and do the processing as you like and do any workarounds that are needed for the site. The alternative will be for each UA to support its own advanced registerHandler function. Was trying to avoid that though. But, I guess sites could wrap them all into a single function. In short, I'm saying that registerProtocolHandler is currently useless for registering most webmails as a "mailto" handler. Now, I think registering webmails as "mailto" handlers is a very, very, very important use case. It perhaps even deserves its own function that can support existing webmail compose URIs. IMO, fwiw. > On Tue, 22 Sep 2009, Michael A. Puls II wrote: >> >> Say the user sees that things are not working right with the handler. >> The user goes into the options to see what's doing with the handler >> settings and notices the link. The user clicks on it. Then, on the page, >> it says "Attention: We've changed some things with what our server >> accepts from our protocol handler. You need to register the handler >> again by clicking here to get the updated version" for example. User >> does and is happy again. :) > > This seems highly optimistic. I think a more likely scenario is user > finds > things are broken, user goes whining in a forum, someone there points > them > to the site that they are whining about, and on the site there's a notice > or something. Or, the user finds it's broken, and they just go straight > to > the site and try to reregister, and it "fixes" itself (with the addition > of a new handler). > > I don't think the link you're suggesting would get much if any traffic. > > I'm not sure why a handler would break though. I mean, there's very > little > that can change. Sites can always just do redirects. O.K. Thanks -- Michael From mark at marksw.com Mon Oct 5 09:48:02 2009 From: mark at marksw.com (Mark Kaplun) Date: Mon, 05 Oct 2009 19:48:02 +0300 Subject: [whatwg] Is there any reason for the continued existence of enctype attribute at the form element Message-ID: <4ACA2342.5040703@marksw.com> I have only learned now that there is a "text/palin" option that I have never heard of, so maybe I'm wrong, but my impression is that there are only two forms of form, a textual and a file upload. IMHO the browser can inspect the form before submitting it and decide by itself what is the correct encoding to use. Can the use of this attribute be deprecated, be valid only for backward compatibility? Mark. From jonas at sicking.cc Mon Oct 5 12:36:21 2009 From: jonas at sicking.cc (Jonas Sicking) Date: Mon, 5 Oct 2009 12:36:21 -0700 Subject: [whatwg] Is there any reason for the continued existence of enctype attribute at the form element In-Reply-To: <4ACA2342.5040703@marksw.com> References: <4ACA2342.5040703@marksw.com> Message-ID: <63df84f0910051236w33d91d82y1c7161c6586fbf8a@mail.gmail.com> On Mon, Oct 5, 2009 at 9:48 AM, Mark Kaplun wrote: > I have only learned now that there is a "text/palin" option that I have > never heard of, so maybe I'm wrong, but my impression is that there are only > two forms of form, a textual and a file upload. IMHO the browser can inspect > the form before submitting it and decide by itself what is the correct > encoding to use. There was also a proposal for "mccain/palin" enctype, but the proposal died out towards the end of last year. / Jonas From bzbarsky at MIT.EDU Mon Oct 5 13:37:35 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Mon, 05 Oct 2009 16:37:35 -0400 Subject: [whatwg] Is there any reason for the continued existence of enctype attribute at the form element In-Reply-To: <4ACA2342.5040703@marksw.com> References: <4ACA2342.5040703@marksw.com> Message-ID: <4ACA590F.1040800@mit.edu> On 10/5/09 12:48 PM, Mark Kaplun wrote: > I have only learned now that there is a "text/palin" option that I have > never heard of, so maybe I'm wrong, but my impression is that there are > only two forms of form, a textual and a file upload. IMHO the browser > can inspect the form before submitting it and decide by itself what is > the correct encoding to use. You can use multipart/form-data with a form that doesn't include any file uploads (and people do this). Presumably they might have reasons for this (e.g. they happen to have a sane multipart MIME parsing library and don't want to deal with the url-encoding mess the application/x-www-form-urlencoded option produces. -Boris From ian at hixie.ch Mon Oct 5 16:28:28 2009 From: ian at hixie.ch (Ian Hickson) Date: Mon, 5 Oct 2009 23:28:28 +0000 (UTC) Subject: [whatwg] document.head In-Reply-To: References: <6F7B10D2-9E54-46EC-A053-866C162BC796@gmail.com> <6983E57B-A6A8-4D69-9ECA-83E46D6772E8@gmail.com> Message-ID: On Sun, 20 Sep 2009, Joseph Pecoraro wrote: > > Was there any discussion for including "document.head" in HTML5? > Searching the mailing list shows document.head show up a few times in > example code [1][2]. However, there has been no proposal, and it is not > mentioned in the document's IDL [3] in the Spec. > > Developers often do the following to get a reference to the > element (top 2 google results) [4]: > > var head = document.getElementsByTagName('head')[0]; > > Its useful for developers to use that reference to manipulate/append > stylesheets, scripts, and

APPLE

GRAPE

ORANGE

Apple

Grape

Orange

From surkov.alexander at gmail.com Tue Oct 20 22:14:21 2009 From: surkov.alexander at gmail.com (Alexander Surkov) Date: Wed, 21 Oct 2009 13:14:21 +0800 Subject: [whatwg] keyboard behaviour inside of editable area In-Reply-To: <26b395e60910200314y3e30b1f6w381c5c65c095ab77@mail.gmail.com> References: <26b395e60910200314y3e30b1f6w381c5c65c095ab77@mail.gmail.com> Message-ID: Hi, Josh. If I get right HTML5 assumes to treat HTML controls inside of editable area as normal controls. Therefore it's really helpful to know how much special mobile platforms might want to treat controls in editable area. I agree editor behaviour on user input should be defined by platform. However I wouldn't agree it should be browser-dependent. Starting from the point HTML controls inside of editable area are normal controls I just want to ensure these controls are accessible, partially it means they should be operable by keyboard because it's primary tool for assistive technologies users. Shortly all I suggest is to use editor's keyboard navigation rules if caret is on text or use control's keyboard navigation rules if control is focused, also I tried to define rules to make focus transition from editor to control. Therefore I don't touch BiDi behaviour because it's automatically addressed in this case. As well in this light arrow keys in my proposal are just an example to describe desired behaviour. It should be valid for Windows but another keys or ways might be required on another platforms. So my proposal is rather an idea than real proposal, an idea I like to discuss or get it approved. All of this is an attempt to produce general rules to ensure HTML controls are operable. Since controls inside of editable area are normal controls then it shouldn't be allowed to edit option labels (add or remove them), all you can do is to change the selected option. I can see a cases when it might be useful to have an ability to edit options. However I keep in mind default behaviour only. The default behaviour might be overridden by additional editor settings or web service directly to meet these needs. Thank you. Alex. On Tue, Oct 20, 2009 at 6:14 PM, timeless wrote: > On Mon, Oct 12, 2009 at 10:04 AM, Ian Hickson wrote: >> there's nothing that really requires that the >> user agent even support arrow keys, let alone that they work in a >> particular way. > > I believe MicroB, Fennec, and probably Mobile Safari will tend to > treat form controls as very special. > > I don't see any reason to specify this, as in reality, it's up to the > browser and platform to decide how such things should work. Ideally > the teams developing such platforms will evolve solutions which work > for their users. If they don't, I'd expect their users to act as > consumers and vote with their wallets/eyeballs.... (Sadly, that is > unlikely to be a good thing for MicroB). > > Of note, the N900 in most regional variants doesn't have up/down arrow > keys. And when people specify how arrow keys work in contentEditable, > i'd expect them to try to specify how arrow keys work while is > active (an attempt to influence selection length/shape). > > I've heard rumors that Qt has (plans?) for some magical way to control position. > > Alexander Surkov's proposal also doesn't covered BiDi behavior.... > > Also, it's unclear to me what the goal is. Should I, as an end user of > an editable page, be able to edit a ? Message-ID: <1F665702-96C4-4E2D-AC4C-213D48E8829B@apple.com> HTML5 currently says that the signature algorithm used with should be any of "those listed in section 2.2.1 ('RSA Signature Algorithm') of RFC 3279." However, both WebKit and Gecko only ever use the md5WithRSAEncryption signature algorithm. And apparently WebKit ran into compatibility issues with MIT's websites back in 2004 when it tried to use the id- sha1 signature algorithm instead. I'd recommend that HTML5 change to say that only the md5WithRSAEncryption signature algorithm should be used for . -Adam From liszt at coq.no Wed Oct 21 14:39:00 2009 From: liszt at coq.no (=?ISO-8859-1?Q?=D8istein_E._Andersen?=) Date: Wed, 21 Oct 2009 22:39:00 +0100 Subject: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range] In-Reply-To: References: <4B419876-1551-447D-8C77-1B702724EDC8@coq.no> <6E531C99-3CEF-446A-9BE3-1FF79CDA839B@coq.no> <1F0A9F09-B0F8-4AF3-B02B-0C18FF42EAC1@coq.no> Message-ID: On 19 Oct 2009, at 05:52, Ian Hickson wrote: > I've noted your e-mail here [...] and moved the whole thing out of > the spec. That does not seem to apply to the last part of the original e-mail, quoted below. ?istein E. Andersen > Other character encoding issues: > -------------------------------- > > ASCII-compatibility: > The note in ?2.1.5 Character encodings? seems to say that ?variants > of ISO-2022? (presumably including common ones like ISO-2022-CN, > ISO-2022KR and ISO-2022-JP) are ASCII-compatible, whereas HZ-GB-2312 > is not, and I cannot find anything in Section 2.1.5 that would > explain this difference. > > > Discouraged encodings: > ?4.2.5.5 Specifying the document's character encoding? advises > against certain encodings. (Incidentally, this advice probably > deserves not to be ?hidden? in a section nominally reserved for > character encoding declaration issues.) In particular: > >> Authors should not use JIS-X-0208 (JIS_C6226-1983), JIS-X-0212 >> (JIS_X0212-1990), encodings based on ISO-2022, and encodings based >> on EBCDIC. > > It is not clear what this means (e.g., the character set > JIS_C6226-1983 in any encoding, or only when encoded alone according > to RFC1345 as described above); the list of discouraged encodings > seems conspicuously short if it is supposed to be complete; and the > lack of rationale makes it difficult to understand why these > encodings are considered particularly harmful (JIS_C6226-1983 v. > JIS_C6226-1978 or ISO-2022 v. HZ, to mention but two at least > initially puzzling cases). It might be better to say why > particular encodings are better avoided, whether or not the list of > discouraged encodings be presented as definitive. > > Minor grammar detail in 4.2.5.5: >> Conformance checkers may advise against authors using legacy >> encodings. > > This is ambiguous. It should probably be ?advise against authors? > using legacy encodings? or better ?advise authors against using > legacy encodings?. From sebastian at calyptus.eu Wed Oct 21 16:21:34 2009 From: sebastian at calyptus.eu (=?ISO-8859-1?Q?Sebastian_Markb=E5ge?=) Date: Thu, 22 Oct 2009 01:21:34 +0200 Subject: [whatwg] Drop event on form controls In-Reply-To: <4ADF2394.3070401@helsinki.fi> References: <4ADEFB48.2030409@helsinki.fi> <4ADF2394.3070401@helsinki.fi> Message-ID: <491930550910211621n2c0abf55ie66376a54d0a2150@mail.gmail.com> I agree, IE and Firefox dispatches the drop event for both form controls and contentEditable even if dragover isn't canceled. They insert the dropped data unless drop event is canceled. WebKit (Windows) inserts the dropped data but doesn't fire the drop event. If dragover is canceled, then WebKit doesn't insert the dropped data but it does fire the drop event. I tend to agree with the IE and Firefox model. That's more useful. If the default operation is to allow a drop, then you shouldn't have to "prevent default" it to get the drop event. If the default operation isn't to allow a drop, then it shouldn't. Also, the inserted text should be inserted unless the drop event is canceled. But not if preventDefault is called. On Wed, Oct 21, 2009 at 5:07 PM, Olli Pettay wrote: > contentEditable may need special handling too. > Haven't tested how IE (or other browsers) handles that. > > > -Olli > > > On 10/21/09 3:15 PM, Olli Pettay wrote: > >> Hi all, >> >> seems like the draft doesn't specify properly what should happen when >> dropping something to a (text) form control. >> >> The draft says that if dragover isn't canceled, then drag operation >> becomes none, and then later "if the current drag operation is none... >> then the drag operation failed." >> >> Seems like dragover needs to have some default handling when dispatched >> to form controls. >> IE does dispatch a drop event when dragging something to a form control. >> >> br, >> >> -Olli >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.glazman at disruptive-innovations.com Wed Oct 21 23:56:46 2009 From: daniel.glazman at disruptive-innovations.com (Daniel Glazman) Date: Thu, 22 Oct 2009 08:56:46 +0200 Subject: [whatwg] In-Reply-To: References: Message-ID: <4AE0022E.8040801@disruptive-innovations.com> Hi there, That onlyreplace attribute is not enough, and trust me, I have spent quite a while on solutions transforming HTML documents using bits contained in external instances... Hixie referenced at some point in the thread my HTMLOverlays proposal [1] and that proposal has a clear plus compared to the onlyreplace attribute: it's not meant to ONLY replace but ALSO to add elements to an existing container, using an order defined by the web author and not only appending overlaid elements. That's a _major_ win compared to onlyreplace. I am not saying here that onlyreplace is a bad idea, it's even a very good one. And I find VERY amusing to read super-positive comments about it that are exactly contrary to comments I received myself on HTMLOverlays while the two proposals are rather similar :-) That said, there are a few problems to solve: - what means exactly "replacement" here? What's the scope of a

Text

Anyway, it might be reasonable to always replace the element, as it is recommended to have individual titles for every page, and looks like an overkill to give this unique element an id, just to reference it in the onlyreplace list. > - I think a mechanism using a <link> element is better because it's > similar to prefetching. It's also semantically better because it > used a _very_ old proposal of mine called "link dereferencing" [1]. > And of course it is better because it can help resolving the > progressive rendering issues of <a onlyreplace> since the head > is parsed before the body... Can you give a code example how this could look like? From Chris.Taylor at figureout.com Thu Oct 22 02:22:41 2009 From: Chris.Taylor at figureout.com (Chris Taylor) Date: Thu, 22 Oct 2009 10:22:41 +0100 Subject: [whatwg] <a onlyreplace> In-Reply-To: <4AE0223A.3010905@gmx.ch> References: <dd0fbad0910161106r628fe6c5me6b3db686a3188b9@mail.gmail.com> <4AE0022E.8040801@disruptive-innovations.com> <4AE0223A.3010905@gmx.ch> Message-ID: <7805560CD71B3B4793F5FDBCDE22E52B1994491BAB@tpexmb01> Looking at this (simplified) example from Markus: <html> <head> <title id="title">My title

Text

Would it be better to be able to specify multiple onlyload base elements? Like so: My title

Replace the title

Replace the content

Text

Replace me

That way it gives authors much more control over that they choose to be replaced. This does mean that the "onlyreplace" attribute on links (and forms) should perhaps be renamed "onlyreplaceref" or similar. Has this idea already been put forward by someone else? (I may have missed it). Chris This message has been scanned for malware by SurfControl plc. www.surfcontrol.com From daniel.glazman at disruptive-innovations.com Thu Oct 22 02:35:22 2009 From: daniel.glazman at disruptive-innovations.com (Daniel Glazman) Date: Thu, 22 Oct 2009 11:35:22 +0200 Subject: [whatwg] In-Reply-To: <4AE0223A.3010905@gmx.ch> References: <4AE0022E.8040801@disruptive-innovations.com> <4AE0223A.3010905@gmx.ch> Message-ID: <4AE0275A.3010108@disruptive-innovations.com> Markus Ernst wrote: > They are crucially different in some points: > - HTMLOverlays is a ready-to-use script solution. It does not require > any specification nor implementation by UAs. Instead, it requires work > on the authoring side; using HTMLOverlays means totally re-writing your > websites. It's ready as a script, yes, and that is absolutely not satisfactory. It's so simple that it could be specified and implemented by browsers. > - HTMLOverlays does not degrade nicely. If a UA does not support > scripting, or the script is not found for any reason, there is no way to > render the page in a useable manner. This also applies to search > engines, which will not see anything that is part of the overlay - this > will typically apply to the whole navigation. Agreed, and that's why I think a standardized solution is better. > > - I think a mechanism using a element is better because it's > > similar to prefetching. It's also semantically better because it > > used a _very_ old proposal of mine called "link dereferencing" [1]. > > And of course it is better because it can help resolving the > > progressive rendering issues of since the head > > is parsed before the body... > > Can you give a code example how this could look like? > Sure. That only requires to extend the rel attribute to any element. Semantically, it's perfectly ok since onlyreplace is really establishing a link of some sort to a potentially external resource.
From ian at hixie.ch Thu Oct 22 05:23:33 2009 From: ian at hixie.ch (Ian Hickson) Date: Thu, 22 Oct 2009 12:23:33 +0000 (UTC) Subject: [whatwg]

in the third example. SEMANTIC 2D -------------------------------------------

Hello World!

Hello World!

-

-

-

in the third example. SEMANTIC 2D -------------------------------------------

Hello World!

Hello World!

-

-

-

in the third example. SEMANTIC 2D -------------------------------------------

Hello World!

Hello World!

*. is a sectioning element, nothing more, effectively equivalent (though used slightly differently) to . Both and declare the name for some body of data contained in or . Thus using and

declare the name for some body of data contained in or . Thus using and

in the third example. SEMANTIC 2D -------------------------------------------

Hello World!

Hello World!