Re: [whatwg] a onlyreplace
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 script element? - what does it mean for stylesheets and scoped stylesheets? - what does it mean for the root of the replaced subtree? Let's call that the bound element and the binding : how are deferred to the subtree even handlers attached to the bound element? - I don't like a onlyreplace because that works only with elements inside the body of a document. I want a generic mechanism that can apply to elements in head too... - 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... [1] http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html [2] http://www.w3.org/Submission/1997/12/ /Daniel
Re: [whatwg] a onlyreplace
Daniel Glazman schrieb:
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 :-)
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.
- 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.
That said, there are a few problems to solve:
- what means exactly replacement here? What's the scope of a
script element?
- what does it mean for stylesheets and scoped stylesheets?
- what does it mean for the root of the replaced subtree? Let's call
that the bound element and the binding : how are deferred to the
subtree even handlers attached to the bound element?
- I don't like a onlyreplace because that works only with elements
inside the body of a document. I want a generic mechanism that can
apply to elements in head too...
Are you sure about that? I assumed this was valid:
html
head
title id=titleMy title/title
style id=mystyle
@import url(mystyle.css);
#contents h2 { color:red; }
/style
script
alert(This one is not replaced);
/script
script id=script2
function foo() { alert(bar); }
/script
base onlyreplace=title mystyle script2 contents
/head
body
ul id=navigation
lia href=otherpage.html onlyreplace/li
/ul
div id=contents
pText/p
div
/body
/head
Anyway, it might be reasonable to always replace the title 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?
Re: [whatwg] a onlyreplace
Looking at this (simplified) example from Markus: html head title id=titleMy title/title base onlyreplace=title /head body ul id=navigation lia href=otherpage.html onlyreplace/li /ul div id=contents pText/p div /body /head Would it be better to be able to specify multiple onlyload base elements? Like so: html head title id=titleMy title/title base id=onlyreplace1 onlyreplace=title base id=onlyreplace2 onlyreplace=contents /head body ul id=navigation lia href=otherpage1.html onlyreplace=onlyreplace1Replace the title/a/li lia href=otherpage2.html onlyreplace=onlyreplace2Replace the content/a/li /ul div id=contents pText/p pa href=otherpage2.html onlyreplace=onlyreplace2Replace me/a/p div /body /head 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
Re: [whatwg] a onlyreplace
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 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? 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. head link id=myreplacement rel=prefetch href=http://www.example.com/foo.html#bar/ /head body p rel=replace src=#myreplacement/ /body /Daniel
Re: [whatwg] object behavior
On Sun, 18 Oct 2009, Michael A. Puls II wrote: However, if I use createDocument() to create an HTMLDocument and then append an HTMLObjectElement to that document, the plug-in shouldn't load as the document is not active/has no browsing context or something. Good point. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] object behavior
On Thu, 22 Oct 2009 08:23:33 -0400, Ian Hickson i...@hixie.ch wrote: On Sun, 18 Oct 2009, Michael A. Puls II wrote: However, if I use createDocument() to create an HTMLDocument and then append an HTMLObjectElement to that document, the plug-in shouldn't load as the document is not active/has no browsing context or something. Good point. Fixed. Thanks. -- Michael
Re: [whatwg] a onlyreplace
On Thu, Oct 22, 2009 at 1:56 AM, Daniel Glazman daniel.glaz...@disruptive-innovations.com wrote: 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 actually consider that a loss. It's addressing a different problem, you see. HTMLOverlays is basically client-side includes. While you can hack it into solving a similar problem to @onlyreplace, that's not its primary purpose and the bookmarkability seems like it would be poor. (Note - bookmarkability of abusing htmloverlays as a navigation mechanism, not of using them as intended.) @onlyreplace is simply a way of specifying slightly different navigation semantics on your links. The original page load is the same as normal (unlike HTMLOverlays, where the initial request is a partially-empty page), and navigation is what's changed (unlike HTMLOverlays, which utilize normal navigation and just slot in the overlays again on pageload). Different solutions to different problems. 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 :-) I think that's because we're doing different things, like I said. ^_^ There's a very small target in the problem-space I'm working in that's good, while nearly everything else is bad. If people interpreted HTMLOverlays as solving the same problem as what I'm trying to solve with @onlyreplace, then yeah, it's a bad solution. It may be fine at solving its own problem. That said, there are a few problems to solve: - what means exactly replacement here? What's the scope of a script element? replacement is semantically identical to setting outerHTML on the target elements. I'm not sure what you mean by scope of a script element. - what does it mean for stylesheets and scoped stylesheets? Nothing special. - what does it mean for the root of the replaced subtree? Let's call that the bound element and the binding : how are deferred to the subtree even handlers attached to the bound element? The entire subtree is replaced, root and all. Event handlers attached to the root or any child are lost. Either reregister them in the swapIn event, or use event delegation on an ancestor. - I don't like a onlyreplace because that works only with elements inside the body of a document. I want a generic mechanism that can apply to elements in head too... Hm? There's nothing about @onlyreplace that only works for body elements. Where did you get that impression? (I'd like to know so I can reword things if needed.) As long as an element has an id it can be replaced. - 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... I think you misunderstand the mechanics of @onlyreplace. It doesn't change anything when you first load a page, and it shouldn't be at all similar to prefetching. It only operates when you click on a link with the @onlyreplace attribute. The browser then makes an ordinary request for the desired page, parses it with scripting disabled, and locates elements with the given ids to swap into the old page. ~TJ
Re: [whatwg] a onlyreplace
Tab Atkins Jr. wrote: I actually consider that a loss. It's addressing a different problem, you see. HTMLOverlays is basically client-side includes. While you It's client-side only because I implemented in JS that way! Explain me what prevents from implementing server-side? I think you misunderstand the mechanics of @onlyreplace. It doesn't change anything when you first load a page, and it shouldn't be at all similar to prefetching. It only operates when you click on a link with the @onlyreplace attribute. The browser then makes an ordinary request for the desired page, parses it with scripting disabled, and locates elements with the given ids to swap into the old page. Exactly. And I said this is a good start and not enough. We could do simple AND more powerful than that. /Daniel
Re: [whatwg] a onlyreplace
On Thu, Oct 22, 2009 at 9:47 AM, Daniel Glazman daniel.glaz...@disruptive-innovations.com wrote: Tab Atkins Jr. wrote: I actually consider that a loss. It's addressing a different problem, you see. HTMLOverlays is basically client-side includes. While you It's client-side only because I implemented in JS that way! Explain me what prevents from implementing server-side? Nothing, of course, but then it seems equivalent to any other server-side-include mechanism. It may have a better syntax for many cases (in fact, it looks like it probably does), but it's otherwise relatively unremarkable and doesn't require any changes to browsers. Specifically, it doesn't do anything like what @onlyreplace does. Navigation still involves a complete tear-down and refresh of the page, js state, etc. I think you misunderstand the mechanics of @onlyreplace. It doesn't change anything when you first load a page, and it shouldn't be at all similar to prefetching. It only operates when you click on a link with the @onlyreplace attribute. The browser then makes an ordinary request for the desired page, parses it with scripting disabled, and locates elements with the given ids to swap into the old page. Exactly. And I said this is a good start and not enough. We could do simple AND more powerful than that. Can you elaborate? If you understand @onlyreplace, then you must be hinting at a larger abstraction than I can see currently. To my eyes @onlyreplace and overlays (XUL, HTML, or otherwise) only share some basic surface similarities, in that they both have a replace an element with one from another document with the same id mechanic. The way that mechanic is used, and the effect it has on the page, the UI, the user experience, and the browser is completely different. ~TJ
Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]
Øistein E. Andersen wrote: 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. First, JIS-X-0208 and JIS-X-0212 are not in IANA Charsets, moreover those correct names as spec are JIS X 0208 and JIS X 0212. Second, JIS_C6226-1983, JIS_X0212-1990, and EBCDICs are not ASCII compatible. So they are out of discouraged; mustn't use. Finally, Why ISO 2022 series is discouraged is not clear. Anyway, most of charsets defined RFC 1345 are not clear. Conversion table between Unicode is needed. -- NARUSE, Yui nar...@airemix.jp
Re: [whatwg] Issues with Web Sockets API
17.10.2009, в 3:20, Ian Hickson написал(а): I'm not really sure what else to say to be honest. Should I just leave it at cookies and nothing else? Really I just want to support Basic (and I guess Digest) authentication (primarily for over-TLS connections), so that sites that use Basic auth, like, say, porn sites, or the W3C, can also use it for their Web Socket connections. I could just limit it that way; would that work? Formally limiting support for Basic auth would be workable, I guess. Implementation of Digest authentication is already non-trivial enough for me to wish that we don't implement it at first. Or perhaps authentication should be limited to cookies in v1 indeed. If /code/, interpreted as ASCII, is 401, then let /mode/ be _authenticate_. Otherwise, fail the Web Socket connection and abort these steps. 407 (proxy authenticate) also likely needs to be supported. Proxies wouldn't work with WebSockets in general. Could you please elaborate? I thought there was a setup that could work with most deployed HTTPS proxies - one could run WebSockets server on port 443. Oh, I see what you're saying. Proxy authentication of this nature is covered by step 2 of the handshake algorithm, as part of connect to that proxy and ask it to open a TCP/IP connection to the host given by / host/ and the port given by /port/. There's even an example showing auth headers being sent to the proxy. By the time we get down to parsing the response, we're long past the point where we might be authenticating to a proxy. Is that a problem? Hmm, I actually don't know for sure. Step 2 only covers the case when the user agent is configured to use a proxy - but an organization may have a transparent proxy intercepting requests. But I do not know if such a proxy can practically request authentication by returning a 407 response (blurring the meaning of transparent a bit, but anyway). I could add support for 407 here and just say that you jump back to step 2 and include the authentication this time, would that work? If the answer to my above concern is yes, then it should work, as long as the text doesn't require double TLS handshake or something like that. Some authentication schemes (e.g. NTLM) work on connection basis, so I don't think that closing the connection right after receiving a challenge can work with them. Yeah, that's quite possible. Is this something you plan to correct in the spec? Is there much to correct? I don't understand what would need to change here. Does NTLM not work with HTTP without pipelining? You probably meant HTTP persistent connections here, not pipelining. Yes, since NTLM authentication works on connections and not individual requests, closing the connection after receiving a challenge will make it inoperable, as far as I know. Or do you mean that you would rather have authentication be a first-class primitive operation in Web Socket, instead of relying on the HTTP features? We could do that: instead of faking an HTTP communication, we could have a header in the handshake that means after this, the client must send one more handshake consisting of an authentication token, and if the UA fails to send the right extra bit, then fail. I think if we did this, we'd want to punt until version 2, though. Yes, I think that relying on HTTP specs to define authentication to Web Sockets takes the fake HTTP handshake concept too far. - WBR, Alexey Proskuryakov
Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]
On 22 Oct 2009, at 17:15, NARUSE, Yui wrote: First, JIS-X-0208 and JIS-X-0212 are not in IANA Charsets, I am not sure what you mean; they are both listed at http://www.iana.org/assignments/character-sets: Name: JIS_C6226-1983 [RFC1345,KXS2] MIBenum: 63 Source: ECMA registry Alias: iso-ir-87 Alias: x0208 Alias: JIS_X0208-1983 Alias: csISO87JISX0208 Name: JIS_X0212-1990 [RFC1345,KXS2] MIBenum: 98 Source: ECMA registry Alias: x0212 Alias: iso-ir-159 Alias: csISO159JISX02121990 moreover those correct names as spec are JIS X 0208 and JIS X 0212. (The IANA registry is internally inconsistent and often disagrees with official standards when it comes to capitalisation, dashes/hyphens, underscores and spaces, so it is difficult to get this right. Please excuse me for not always paying due attention to such details in e- mails. Of course, the specifications should follow either IANA or the official standard as appropriate, depending on what it is referring to.) Second, JIS_C6226-1983, JIS_X0212-1990, and EBCDICs are not ASCII compatible. So they are out of discouraged; mustn't use. EBCDIC is clearly not ASCII-compatible and may be unique amongst the character sets in the IANA registry in providing the full ASCII repertoire in a different arrangement. JIS_C6226-1983 and JIS_X0212-1990 as defined in RFC1345 (i.e., on their own) do not contain basic ASCII characters at all, so it makes little sense to use them for HTML documents without adding ASCII or the ASCII-based JIS C 6220-1969, which would give something like EUC- JP or ISO-2022-JP. JIS_C6226-1983 contains wide versions of ASCII characters, but those are not interpreted as HTML mark-up (unless I am mistaken). JIS_X0212-1990 does not contain ASCII, kana or basic kanji, so it is of extremely limited usefulness on its own even in a plain- text setting. Warning against completely useless encodings seems pointless. Many other encodings in the IANA registry are ASCII-incompatible in different ways; what I do not understand is what makes the ones currently mentioned in the HTML5 draft particularly harmful. Finally, Why ISO 2022 series is discouraged is not clear. We agree on this point. Anyway, most of charsets defined RFC 1345 are not clear. Conversion table between [those charsets and] Unicode is needed. Quite. Anne van Kesteren, I and several others are currently trying to document how browsers handle different encodings at http://wiki.whatwg.org/wiki/Web_Encodings, and defining mappings to Unicode is one of the goals. Your contribution would be much appreciated. -- Øistein E. Andersen
Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]
Øistein E. Andersen wrote: On 22 Oct 2009, at 17:15, NARUSE, Yui wrote: First, JIS-X-0208 and JIS-X-0212 are not in IANA Charsets, I am not sure what you mean; they are both listed at http://www.iana.org/assignments/character-sets: Name: JIS_C6226-1983 [RFC1345,KXS2] MIBenum: 63 Source: ECMA registry Alias: iso-ir-87 Alias: x0208 Alias: JIS_X0208-1983 Alias: csISO87JISX0208 Where is the word JIS-X-0208 ? Name: JIS_X0212-1990 [RFC1345,KXS2] MIBenum: 98 Source: ECMA registry Alias: x0212 Alias: iso-ir-159 Alias: csISO159JISX02121990 Where is the word JIS-X-0212 ? moreover those correct names as spec are JIS X 0208 and JIS X 0212. Please excuse me for not always paying due attention to such details in e-mails. Of course, the specifications should follow either IANA or the official standard as appropriate, depending on what it is referring to.) Not for you, this sentense is in current HTML5 Draft 4.2.5.5. That is why I paid attention. Anyway, most of charsets defined RFC 1345 are not clear. Conversion table between [those charsets and] Unicode is needed. Quite. Anne van Kesteren, I and several others are currently trying to document how browsers handle different encodings at http://wiki.whatwg.org/wiki/Web_Encodings, and defining mappings to Unicode is one of the goals. Your contribution would be much appreciated. ICU has large set of tables which likely to cover many MS Codepages. (Of course it should be verified) http://bugs.icu-project.org/trac/browser/data/trunk/charset/data/ucm And I have a CP51932 table made from .NET Framework's Coonverter. http://nkf.sourceforge.jp/ucm/cp51932.ucm -- NARUSE, Yui nar...@airemix.jp
Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]
On Thu, Oct 22, 2009 at 9:23 PM, Øistein E. Andersen li...@coq.no wrote: On 22 Oct 2009, at 17:15, NARUSE, Yui wrote: Finally, Why ISO 2022 series is discouraged is not clear. We agree on this point. The string 숍訊昱穿 encoded as ISO-2022-KR is the bytes 0e 3c 73 63 72 69 70 74 3e. A UA that doesn't support ISO-2022-KR (e.g. Chrome, when I last checked) will decode it as Windows-1252 and get the string script, which is bad. So a site that uses ISO-2022-KR is very likely to expose some users to XSS attacks, which seems like a good reason to discourage that encoding. The same applies to other ISO-2022 encodings. -- Philip Taylor exc...@gmail.com
Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]
On 22 Oct 2009, at 22:45, Philip Taylor wrote: On Thu, Oct 22, 2009 at 9:23 PM, Øistein E. Andersen li...@coq.no wrote: On 22 Oct 2009, at 17:15, NARUSE, Yui wrote: Finally, Why ISO 2022 series is discouraged is not clear. We agree on this point. The string 숍訊昱穿 encoded as ISO-2022-KR is the bytes 0e 3c 73 63 72 69 70 74 3e. A UA that doesn't support ISO-2022-KR (e.g. Chrome, when I last checked) will decode it as Windows-1252 and get the string script, which is bad. [...] If that is the reason, at least HZ encoding would seem to be affected as well. Explicitly discouraging a more or less random subset of the problematic encdodings without providing rationale makes it difficult to assess whether or not other, somewhat similar, encodings should be avoided as well, which was the main issue I wanted to raise. -- Øistein E. Andersen
Re: [whatwg] .tags()
On Mon, 19 Oct 2009, Jonas Sicking wrote: I've been meaning to send a formal email on this subject, and with the recent discussion going on over in the W3C webapps mailing list I figured now was a good time. I'd like to formally request that .tags() is removed from the HTMLCollection interface. Unless it can be shown that .tags() is needed for compatibility with the web Mozilla has no plans to implement this property. Back when we implemented document.all, we judged that there were enough sites using document.all.tags() to implement the property on the document.all collection, however we haven't seen any information indicating that this is needed elsewhere. I've removed it and filed bugs on WebKit and Opera. If the bugs get WONTFIXed, though, then I'd like there to be a spec defining how this should work. Based on how for example the video codec issue was handled, where part of the spec was dropped since one major browser vendor indicated that they would not support a feature, I'd request that the same treatment was given to .tags(), and thus remove it from the spec. There's a spec for Theora. There's no other spec for tags(). What we removed was the (quite unusual) requirement that implementors of one spec (HTML) implement another (Theora), not the actual definition of how the feature should work (the Theora spec still exists). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] noreferrer link relation clarifications
On Tue, 20 Oct 2009, Nate Chapin wrote: I was wondering if I could get some clarification about a couple things in the specification of the noreferrer link relation: 1. Is it the intent for the opener attribute to potentially be non-null when a hyperlink does not create a new browsing context? I don't understand the question. window.opener is set to whatever the Window was that caused this Window to be opened. It is only tangentially related to hyperlinks, in that hyperlinks can be a way to open windows. That is, should any page that cares to use the noreferrer link relation and truly wants to suppress the opener attribute be expected to do that suppression manually or use target=_blank? Without using target=, there's no new opener window to suppress, as far as I can tell. I'm not clear whether there's any reason for the source page to care whether its opener is exposed, rather than just being concerned whether it appears as the opener. As far as I'm aware, there's no reason to care about whether one's opener is exposed at all. The only reason that one would suppress the opener is to allow multi-process browsers like Chrome to sever the connection between the two, allowing the new window to run in a new process. 2. What is the proper behavior of a statement like a rel=noreferrer href=#fooScroll to foo/a ? It's a bit absurd to suppress to be requesting that a referrer not be sent for a scrolling action (since no requests should be sent anyway), so presumably the behavior is simply to ensure that the opener attribute remains intact? There's no request here and no browsing context is opened, so rel=noreferrer would have no effect in this case. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Issue on drag drop example in specification?
On Wed, 21 Oct 2009, Shumpei Shiraishi wrote:
!DOCTYPE html
html
head
meta charset=UTF-8
title/title
style type=text/css
ul, li {
-webkit-user-drag: element;
}
/style
script type=text/javascript
function onDragStart(event) {
if (event.target.tagName.toLowerCase() == li) {
var dt = event.dataTransfer;
dt.dropEffect = copy;
dt.setData(listItemId, event.target.id);
} else {
event.preventDefault();
}
return true;
}
function onDrop(event) {
var id = event.dataTransfer.getData(listItemId);
var li = document.getElementById(id);
if (li li.parentNode != event.currentTarget) {
li.parentNode.removeChild(li);
event.currentTarget.appendChild(li);
}
event.stopPropagation();
}
function onDragOver(event) {
event.preventDefault();
}
function onDragEnter(event) {
var types = event.dataTransfer.types;
for (var i = 0; i types.length; i++) {
if (types[i] == listItemId) {
// When this code is ommited, drag drop operation should be canceled.
// But it doesn't come to that on Safari4 and FF3.5. Why?
// event.preventDefault();
return true;
}
}
}
Here you want to put the preventDefault() after the for() loop, so that it
cancels the event only if the type was not found.
/script
/head
body
ul id=list1
ondragstart=onDragStart(event)
ondragenter=onDragEnter(event)
ondragover=onDragOver(event)
ondrop=onDrop(event)
li id=apple1 draggable=trueAPPLE/li
li id=grape1 draggable=trueGRAPE/li
li id=orange1 draggable=trueORANGE/li
/ul
ul id=list2
ondragstart=onDragStart(event)
ondragenter=onDragEnter(event)
ondragover=onDragOver(event)
ondrop=onDrop(event)
li id=apple2 draggable=trueApple/li
li id=grape2 draggable=trueGrape/li
li id=orange2 draggable=trueOrange/li
/ul
/body
/html
With that modification, your example works for me in Firefox. It crashes
the Safari build I have, not sure what that's about.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drop event on form controls
On Wed, 21 Oct 2009, Olli Pettay wrote: 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. Fixed. On Wed, 21 Oct 2009, Olli Pettay wrote: contentEditable may need special handling too. Also fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] A call for tighter validation standards
Much of what I wanted to discuss was discussed rather elegantly within a post from August 2009 (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021725.html) on this mailing list, but I would like to take it a step further. Henri Sivonen made some very valid points within that post, and I agree with most of what he said. I also wrote an open letter to the WHATWG on the HTMLCenter blog (http://www.htmlcenter.com/blog/an-open-letter-to-whatwg/) laying out some of my thoughts. I would like to use this message to build upon what I wrote in that blog post, but I don't really want to rehash what I've already said. My main concerns about the current version of the HTML5 specs were laid out pretty well by Henri in the mailing list message from August 2009 I linked above. However, I wanted to reiterate the ones that concern me and add my thoughts. 1. Unquoted attributes 2. Implied tags (such as leaving out a closing paragraph tag) 3. Inconsistent use of the closing slash on empty elements My concern with all three of these points is that they are relying on the browser to interpret the coder's intent when rendering the elements. The unquoted attributes and implied tags are subject to wide interpretation by the browsers. Regarding the unquoted attributes, I fear that new coders might not understand when and why attributes should be quoted and will spend a lot of time wondering why their pages are not rendering properly. For instance, imagine a new coder trying to declare inline style definitions without quoting the style attributes. How will a browser interpret something like: p style=width: 500px; height: 100px; It becomes even more dangerous in that height and width are actually attributes of most HTML elements, so the browser will have to do quite a bit of work to figure out what to do with these types of definitions. The implied tags can be just as frightening. For instance (and I realize this is not the best example, but it's the one I can think of at the moment), what happens with the following: HTML Version: pThis is some paragraph text. spanThis is some more text/span XHTML Version: pThis is some paragraph text./p spanThis is some more text./span In the XHTML version above, it's obvious that the span will be separated from the paragraph text. However, in the HTML version, browsers will include the span in the paragraph (unless appropriate CSS is applied to the span). I would like to reiterate that I am not asking the WHATWG to recommend browsers dropping support for any older HTML specs (in fact, I am very much in support of the browsers continuing to support all older HTML specs and, to the best of their ability, supporting HTML from before there were specs and recommendations). However, what I am asking is that the WHATWG consider writing the specs so that those older, less rigid styles of coding do not validate according to the standard. Coders will still be free to write the code with implied closing tags, unquoted attributes and inconsistent use of the closing slash, but I don't believe that type of code should validate, as it does not conform to an actual standard, rather it conforms to exceptions to standards. In my blog post, I likened the looser standards of HTML5 to removing laws against driving while intoxicated. Sure, abolishing those laws would not force anyone to drive drunk, but without any legal ramifications for doing so, it would be much more prevalent. As with that example, if the standards for HTML are loosened as compared to XHTML 1 (served as text/html), coders will not feel the need to code neatly or consistently, and we will begin to slip back into the spaghetti code we experienced throughout the 1990s. I appreciate you taking the time to read this message, and I hope I can have at least a little bit of an impact on the formation of these standards. Thank you. Curtiss Grymala curt...@ten-321.com
Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]
On Wed, 21 Oct 2009, �istein E. Andersen wrote: 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. HZ-GB-2312 uses the byte ASCII uses for ~ as the escape character. ISO-2022-* uses the control codes. That's the difference. Discouraged encodings: �4.2.5.5 Specifying the document's character encoding� advises against certain encodings. 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); This is talking about character encodings, not character sets. JIS_C6226-1983 is a registered character encoding in the IANA registry. 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). The reason for including these is to discourage encodings known to have security issues. I've added HZ-GB-2312, which can be used in a similarly dangerous fashion. (Basically the danger for user agents is in an attacker using an encoding that a user agent could autodetect, while a site interprets the bytes safely; that would allow those encodings to be used to smuggle script elements in a way that a naive whitelisting filter would think is safe.) It might be better to say *why* particular encodings are better avoided, whether or not the list of discouraged encodings be presented as definitive. I've added a note. (Incidentally, this advice probably deserves not to be �hidden� in a section nominally reserved for character encoding *declaration* issues.) Yeah. I considered moving it to the Writing HTML documents section, but that one doesn't apply to conformance checkers, so it ends up being more of a pain, since the advice would have to be split into multiple pieces so that it applied appropriately. It's not a big deal. 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�. Fixed. On Fri, 23 Oct 2009, NARUSE, Yui wrote: 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. First, JIS-X-0208 and JIS-X-0212 are not in IANA Charsets, moreover those correct names as spec are JIS X 0208 and JIS X 0212. On Thu, 22 Oct 2009, �istein E. Andersen wrote: I am not sure what you mean; they are both listed at http://www.iana.org/assignments/character-sets: Name: JIS_C6226-1983 [RFC1345,KXS2] MIBenum: 63 Source: ECMA registry Alias: iso-ir-87 Alias: x0208 Alias: JIS_X0208-1983 Alias: csISO87JISX0208 Name: JIS_X0212-1990 [RFC1345,KXS2] MIBenum: 98 Source: ECMA registry Alias: x0212 Alias: iso-ir-159 Alias: csISO159JISX02121990 On Fri, 23 Oct 2009, NARUSE, Yui wrote: Where is the word JIS-X-0208 ? Where is the word JIS-X-0212 ? The exact string isn't there, that's why I included the preferred MIME names in brackets in the spec. On Fri, 23 Oct 2009, NARUSE, Yui wrote: Second, JIS_C6226-1983, JIS_X0212-1990, and EBCDICs are not ASCII compatible. So they are out of discouraged; mustn't use. You can use non-ASCII-compatible encodings (e.g. UTF-16). Finally, Why ISO 2022 series is discouraged is not clear. Hopefully this is clear now. Anyway, most of charsets defined RFC 1345 are not clear. Conversion table between Unicode is needed. On Thu, 22 Oct 2009, �istein E. Andersen wrote: moreover those correct names as spec are JIS X 0208 and JIS X 0212. (The IANA registry is internally inconsistent and often disagrees with official standards when it comes to capitalisation, dashes/hyphens, underscores and spaces, so it is difficult to get this right. Please excuse me for not always paying due attention to such details in e-mails. Of course, the specifications should follow either IANA or the official standard as appropriate, depending on what it is referring to.) Second, JIS_C6226-1983, JIS_X0212-1990, and EBCDICs are not ASCII compatible. So they are out of discouraged; mustn't use. EBCDIC is clearly not ASCII-compatible and may be unique amongst the character sets in the IANA
Re: [whatwg] Issues with Web Sockets API
(cc'ing hybi by request, since changes to the WebSocket spec are discussed below) On Thu, 22 Oct 2009, Alexey Proskuryakov wrote: 17.10.2009, в 3:20, Ian Hickson написал(а): I'm not really sure what else to say to be honest. Should I just leave it at cookies and nothing else? Really I just want to support Basic (and I guess Digest) authentication (primarily for over-TLS connections), so that sites that use Basic auth, like, say, porn sites, or the W3C, can also use it for their Web Socket connections. I could just limit it that way; would that work? Formally limiting support for Basic auth would be workable, I guess. Implementation of Digest authentication is already non-trivial enough for me to wish that we don't implement it at first. Or perhaps authentication should be limited to cookies in v1 indeed. Ok, I've removed the authentication stuff from this version. If /code/, interpreted as ASCII, is 401, then let /mode/ be _authenticate_. Otherwise, fail the Web Socket connection and abort these steps. 407 (proxy authenticate) also likely needs to be supported. Proxies wouldn't work with WebSockets in general. Could you please elaborate? I thought there was a setup that could work with most deployed HTTPS proxies - one could run WebSockets server on port 443. Oh, I see what you're saying. Proxy authentication of this nature is covered by step 2 of the handshake algorithm, as part of connect to that proxy and ask it to open a TCP/IP connection to the host given by /host/ and the port given by /port/. There's even an example showing auth headers being sent to the proxy. By the time we get down to parsing the response, we're long past the point where we might be authenticating to a proxy. Is that a problem? Hmm, I actually don't know for sure. Step 2 only covers the case when the user agent is configured to use a proxy - but an organization may have a transparent proxy intercepting requests. But I do not know if such a proxy can practically request authentication by returning a 407 response (blurring the meaning of transparent a bit, but anyway). I don't see how such a proxy could handle WebSocket anyway. The WebSocket protocol isn't really intended to be proxied. I could add support for 407 here and just say that you jump back to step 2 and include the authentication this time, would that work? If the answer to my above concern is yes, then it should work, as long as the text doesn't require double TLS handshake or something like that. I've added text in the spec that says to handle 407 basically like HTTP, closing the connection and jumping back to step 2. Or do you mean that you would rather have authentication be a first-class primitive operation in Web Socket, instead of relying on the HTTP features? We could do that: instead of faking an HTTP communication, we could have a header in the handshake that means after this, the client must send one more handshake consisting of an authentication token, and if the UA fails to send the right extra bit, then fail. I think if we did this, we'd want to punt until version 2, though. Yes, I think that relying on HTTP specs to define authentication to Web Sockets takes the fake HTTP handshake concept too far. Ok. We'll revisit this in the next version, I guess. I'm not sure there's really much point doing anything beyond cookie auth anyway. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A call for tighter validation standards
On Thu, 22 Oct 2009, Curtiss Grymala wrote: 1. Unquoted attributes 2. Implied tags (such as leaving out a closing paragraph tag) 3. Inconsistent use of the closing slash on empty elements My concern with all three of these points is that they are relying on the browser to interpret the coder's intent when rendering the elements. The unquoted attributes and implied tags are subject to wide interpretation by the browsers. HTML5 defines exactly how they are to be treated, removing any room for interpretation. Regarding the unquoted attributes, I fear that new coders might not understand when and why attributes should be quoted and will spend a lot of time wondering why their pages are not rendering properly. I'm skeptical that when people forget to quote their attributes, it's because they don't understand that they need quoting. It doesn't take much to understand that p title=Hello World! class=blue ...needs quotes. For instance, imagine a new coder trying to declare inline style definitions without quoting the style attributes. How will a browser interpret something like: p style=width: 500px; height: 100px; What the browsers must do with this is fully defined, it's the same as: p style=width: 500px;= height:= 100px;= I think authors would figure out that something was wrong pretty soon, though, when their element didn't change size. It becomes even more dangerous in that height and width are actually attributes of most HTML elements, so the browser will have to do quite a bit of work to figure out what to do with these types of definitions. Not really. The spec defines it precisely, and it's actually no more work than dealing with correct attributes. (It's the same work, in fact.) The implied tags can be just as frightening. For instance (and I realize this is not the best example, but it's the one I can think of at the moment), what happens with the following: HTML Version: pThis is some paragraph text. spanThis is some more text/span XHTML Version: pThis is some paragraph text./p spanThis is some more text./span In the XHTML version above, it's obvious that the span will be separated from the paragraph text. However, in the HTML version, browsers will include the span in the paragraph (unless appropriate CSS is applied to the span). I think it's pretty obvious that the span is part of the paragraph in the HTML version, personally. :-) I would like to reiterate that I am not asking the WHATWG to recommend browsers dropping support for any older HTML specs (in fact, I am very much in support of the browsers continuing to support all older HTML specs and, to the best of their ability, supporting HTML from before there were specs and recommendations). However, what I am asking is that the WHATWG consider writing the specs so that those older, less rigid styles of coding do not validate according to the standard. I think less rigid styles are good, and are what made the Web the success that it is. Authors are welcome to use validators that complain about this kind of markup, but we should enforce this style on everyone. Some people (e.g. me) like being able to omit tags. It's a whole heck of a lot easier to maintain this: table thead tr thSong thSinger tbody tr tdOriginal Prankster tdThe Offspring /table ...than: table thead tr thSong/th thSinger/th /tr /thead tbody tr tdOriginal Prankstertd tdThe Offspring/td /tr /tbody /table (Did you notice the error in the second one?) Coders will still be free to write the code with implied closing tags, unquoted attributes and inconsistent use of the closing slash, but I don't believe that type of code should validate, as it does not conform to an actual standard, rather it conforms to exceptions to standards. The point of making things invalid is to say that authors aren't free to do it. You can write invalid markup is not a valid argument. If we're ok with people writing it, then it should be valid. In my blog post, I likened the looser standards of HTML5 to removing laws against driving while intoxicated. Sure, abolishing those laws would not force anyone to drive drunk, but without any legal ramifications for doing so, it would be much more prevalent. IMHO that's a very dubious analogy. First, there are mental health issues relating to drinking while intoxicated (alcohol addiction, a neurological disease, can lead to such behaviour, for instance). Second, omitting tags doesn't lead to people dying. As with that example, if the standards for HTML are loosened as compared to XHTML 1 (served as text/html), coders will not feel the need to code neatly or consistently, and we will begin to slip back into the spaghetti code we experienced throughout the 1990s. Valid HTML4 is not spaghetti code. Invalid
Re: [whatwg] .tags()
On Thu, Oct 22, 2009 at 5:26 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 19 Oct 2009, Jonas Sicking wrote: I've been meaning to send a formal email on this subject, and with the recent discussion going on over in the W3C webapps mailing list I figured now was a good time. I'd like to formally request that .tags() is removed from the HTMLCollection interface. Unless it can be shown that .tags() is needed for compatibility with the web Mozilla has no plans to implement this property. Back when we implemented document.all, we judged that there were enough sites using document.all.tags() to implement the property on the document.all collection, however we haven't seen any information indicating that this is needed elsewhere. I've removed it and filed bugs on WebKit and Opera. If the bugs get WONTFIXed, though, then I'd like there to be a spec defining how this should work. Thanks! / Jonas
