Re: [whatwg] Something better than DOM_QUOTA_ERROR when LocalStorage is immutable?
On Wed, 03 Jun 2009 23:15:31 +0200, Jeremy Orlow jor...@chromium.org wrote: *Please, keep this on topic. There's no point to rehashing http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019238.htmlor any of the other similar debates on private browsing and localStorage's persistence guarantees.* When in private browsing mode, WebKit should not write any data to the hard drive. In addition, WebKit does not allow changes to localStorage that aren't going to be written to disk. Currently, it returns a DOM_QUOTA_ERROR on setItem when private browsing is enabled, and silently fails for removeItem and clear. The silent failures are obviously bad, but even the (ab)use of DOM_QUOTA_ERROR kind of bothers me. Is there an exciting exception that'd work better to tell the script the change failed because localStorage is currently immutable? If not, is there any chance it could be added to the spec? Obviously only browser vendors that share WebKit's philosophy on localStorage's guarantee of persistence would actually use this, but I think it'd be far better than the current behavior. Doesn't this reveal what mode the user is using to view the site? That seems kind of bad. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Vulgar fractions
Vulgar fractions should be supported in hypertext markup without recourse to MathML. They are vulgar, after all. Requiring the full-blown math rendering engine for everyday business activities, cooking and the like is hardly acceptable for authors that use vulgar fractions for quantities and prices (the latter perhaps historical) but do not understand much in mathematics (it is quite possible). (OTOH, I sort of suspect that this rendering mechanism can be delegated to CSS because it is a general typesetting mechanism not specific to HTML.) IMHO, Chris
Re: [whatwg] Vulgar fractions
On Thu, Jun 4, 2009 at 11:08 AM, Kristof Zelechovski giecr...@stegny.2a.pl wrote: Vulgar fractions should be supported in hypertext markup without recourse to MathML. They are vulgar, after all. Requiring the full-blown math rendering engine for everyday business activities, Um, HTML5 requires MathML, so arguing against it is pointless. cooking and the like is hardly acceptable for authors that use vulgar fractions for quantities and prices (the latter perhaps historical) but do not understand much in mathematics (it is quite possible). What's an Author? is it a person or a piece of software. I think it's perfectly reasonable to expect that software allow users to enter strange numbers and for the software to generate HTML5 compatible MathML syntax.
Re: [whatwg] Vulgar fractions
I think it is perfectly reasonable to expect authors to enter their markup in a TEXTAREA box with no bells and whistles. I am not against MathML math (of course) but requiring MathML for cooking recipes is wrong. Chris
Re: [whatwg] A few comments on the keygen tag
On Wed, Jun 3, 2009 at 3:52 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 15 Apr 2009, Anders Rundgren wrote: Now to the really problematic stuff: keygen is not really an HTML tag, it is actually 2 phases of a 3-phase key provisioning protocol. I don't see why a protocol should be plugged into a page GUI. The alternatives all use APIs or specific plugins that indeed may be spawned from an HTML page but that's something completely different. I agree, keygen seems like a poor design. That's one of the reasons I didn't extend it in HTML5; we're just defining what it does in browsers so that new browsers can implement it if they want to be compatible with the existing browsers. We could possibly make it non-conforming though. I don't have a strong opinion either way, on one hand I think we want to discourage its use since it's a pretty crappy feature, on the other hand, I'm not sure that the people that are using it have a choice, so making it non-conforming without providing any alternatives isn't going make anyone stop using it. / Jonas
Re: [whatwg] Pre-Last Call Comments
Small-print legalese is dull, repetitive, has little to do with the actual content, requires a trained lawyer to read and usually contains almost no markup. Sites often wrap it in a scrollable box so that it does not interfere with the page. Even if the target reader manages to read that stuff, there is little chance that she will understand it correctly. The way to deal with small print is to copy it out of the page as text and send it to your lawyer for interpretation. The recommendation of keeping small print small should be kept. If the reader happens to have a chance to understand it herself, she can restyle it in user CSS or use the zoom tool on it. IMHO, Chris
Re: [whatwg] A few comments on the keygen tag
On Jun 4, 2009, at 1:26 AM, Jonas Sicking wrote: On Wed, Jun 3, 2009 at 3:52 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 15 Apr 2009, Anders Rundgren wrote: Now to the really problematic stuff: keygen is not really an HTML tag, it is actually 2 phases of a 3-phase key provisioning protocol. I don't see why a protocol should be plugged into a page GUI. The alternatives all use APIs or specific plugins that indeed may be spawned from an HTML page but that's something completely different. I agree, keygen seems like a poor design. That's one of the reasons I didn't extend it in HTML5; we're just defining what it does in browsers so that new browsers can implement it if they want to be compatible with the existing browsers. We could possibly make it non-conforming though. I don't have a strong opinion either way, on one hand I think we want to discourage its use since it's a pretty crappy feature, on the other hand, I'm not sure that the people that are using it have a choice, so making it non-conforming without providing any alternatives isn't going make anyone stop using it. I share your distaste for keygen. But I also agree that it's unhelpful to make it nonconforming without providing an alternative. Maybe in HTML6, if we develop a better solution in the meantime. - Maciej
Re: [whatwg] The keygen element
On Wed, Jun 3, 2009 at 3:31 PM, Ian Hickson i...@hixie.ch wrote: Which is more likely to be adopted as a cross browser standard? A new html tag? or a new JavaScript object/method? It would presumably depend on how it is to be used. If it's for form submission, then an element would make more sense. If it's for applications, then an API would be better. As a browser developer I'd say that the likeliness something is implemented depends heavily on how useful it is perceived to be, and somewhat on how hard it is to implement. If a feature doesn't seem very useful, I wouldn't advocate adding it no matter how easy it is to implement. On the other hand, if a feature is hard enough to implement that we can implement two other features, that add up to more usefulness, then implementing those two features seem to serve the web more. All of this is very simplified of course, and highly subjective. But neither a new element or a new JS object is hard to implement in and of itself. So use the best solution for the task, that's the most likely to yield a useful feature. / Jonas
Re: [whatwg] How long should sessionStorage data persist?
On Wed, Jun 3, 2009 at 12:31 AM, Ian Hickson i...@hixie.ch wrote: On Sat, 4 Apr 2009, João Eiras wrote: On , Jeremy Orlow jor...@google.com wrote: I think this also applies: NOTE: The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support resuming sessions after a restart. Should that restore sessionStorage data ? Aren't you making sessionStorage much more complicated while the same use cases are covered by localStorage ? sessionStorage could be optimized to be just a volatile amount of data in memory, but these requirements require sessionStorage to implement the same disk IO heuristics, and a complex heuristic to decide when to erase sessionStorage completly. I vote for the data to be present just while a page is open or is restored from history or by going back. User agents aren't required to do the above; but they are allowed to if they so desire. So the complexity is entirely optional (and I don't expect most UAs to avail themselves of this option). For the record, I think Firefox does this already. / Jonas
Re: [whatwg] the cite element
On Thu, Jun 4, 2009 at 3:13 AM, Kristof Zelechovski giecr...@stegny.2a.pl wrote: The HTML is required to produce a meaningful rendering without CSS. The level of reader surprise at the default rendering of cite Aristotle/cite said is high and such markup should be verbally deprecated. (I agree that it cannot be technically invalid, of course.) If I'm reading your message correctly, you assert that the spec's documentation of semantic uses for cite must be limited because of how browsers render text within cite by default. But the argument in favor of limiting cite in the spec. to titles becomes almost immediately problematic. According to many scholarly style guides (e.g., APA, MLA, and Chicago), default browser styles properly italicize citeCrime and Punishment/cite, but they would improperly italicize the title to an article in a periodical. Logically, then, if we are to use default styling as a baseline for the usage of cite, the spec. would need to identify which kinds of titles are appropriate to wrap within that element. In addition, I'm skeptical about how much users are surprised when they encounter italicized text. Visually, at least, by default cite renders no differently from em, so it's not as if italicization is an issue in itself; and judging my some of the seemingly random uses of em in the wild, I doubt this is as big an issue as you suggest. So count me as seconding Andrew Hagen's suggestions regarding cite. It's too semantically useful an element to preemptively limit its use only to titles. Erik Vorhes
Re: [whatwg] Something better than DOM_QUOTA_ERROR when LocalStorage is immutable?
On Jun 4, 2009, at 12:27 AM, Anne van Kesteren wrote: Doesn't this reveal what mode the user is using to view the site? That seems kind of bad. It all depends on the intent of the feature. Some browsers have features intended to shield the identity of the person doing browsing from the site. Similarly the browser would not want the site to be able to detect that this was an anonymous browsing session. Safari has long had a feature, Private Browsing, intended to allow browsing without leaving record on the computer that the browsing took place. That feature makes no attempt to mislead the websites about who is doing the browsing and does not try to “anonymize” the browsing. And the code in WebKit we are discussing was originally created to implement part of this Safari feature. -- Darin
[whatwg] Changing postMessage() to allow sending unentangled ports
Hi all,
I'd like to propose a change to the spec for postMessage(). Currently the
spec reads:
Throws an
INVALID_STATE_ERRhttp://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#invalid_state_err
if
the ports array is not null and it contains either null entries, duplicate
ports, or ports that are not entangled.
I'd like to suggest that we allow sending ports that are not entangled (i.e.
ports that have been closed) - the rationale is two-fold:
1) We removed MessagePort.active because it exposes details about garbage
collection (i.e. an application could determine whether the other side of a
MessagePort was collected or not based on testing the active attribute of
a port). Throwing an exception in postMessage() is the same thing - it
provides details about whether the other end of the port has been collected.
2) Imagine the following scenario: Window W has two workers, A and B. Worker
A wants to send a set of messages to Worker B by queuing those messages on a
MessagePort, then asking Window W to forward that port to Worker B:
Window W code:
workerA.onmessage(evt) {
if (evt.data == forward) {
// Currently this would throw an exception if the passed port is
closed/unentangled.
workerB.postMessage(messageFromA, evt.ports);
}
}
Worker A code:
function sendMessagesToB() {
var channel = new MessageChannel();
channel.port1.postMessage(message 1);
channel.port1.postMessage(message 2);
channel.port1.postMessage(message 3);
// Send port to worker B via Window W
postMessage(forward, [channel.port2]);
}
Now Worker A is done with its port - it wants to close the port. But it
can't safely do so until it knows that Window W has forwarded the port to
Worker B, so it needs to build in some kind of ack mechanism to know when
it's safe to close the port. Even worse, what if Worker A wants to shut down
- it can't safely shut down until it knows that its message has been
delivered, because the port would get closed when the owner closes.
Since the port still acts as a task source even when it is closed, there
seems to be no reason not to allow passing unentangled ports around - it's a
reasonable way to represent a set of messages. And if you think about it,
there's no reason why this is allowed:
postMessage(msg, port)
port.close()
while this is prohibited:
port.close();
postMessage(msg, port);
Given that in both cases the port will almost certainly be closed before the
message is delivered to the target.
-atw
Re: [whatwg] the cite element
The level of surprise of an article cited as a book is far smaller than a real author looking like a fictitious person, as in the default rendering of CITE Aristotle/CITE said. Not everybody is an expert in scholarly style guides but most readers feel the difference between direct speech and indirect speech. You can, of course, say It was not EM Plato/EM , it was EM Aristotle/EM ! but this kind of emphasis is rarely needed and the interpretation of the rendering is obvious from the context in this case. I contend that citing articles from periodicals is not well supported, starting with the problem of lack of support in the NID urn:ISSN. However, formal citations are not inserted into running text, which is what the CITE element in principle is for. They are set aside as footnotes or endnotes in order to keep the text readable. There is nothing wrong with the default rendering of the article title in running text where symbolic bibliography references are not used, e.g. because the text is for the average reader. IMHO, Chris
[whatwg] HTML5 3.7.2 - document.write
I have a question about section 3.7.2. Under step 5, it says that it is
considered a reentrant invocation of parser if the document.write() method was
called from script executing inline. Does this include document.write() calls
invoked from user actions (e.g. onclick)? I assume not, but I'm getting varying
behavior from the major browsers for this test case (click on the button to
run):
---
HTMLHEAD
script id=outter type=text/javascript
function doDoc() {
document.write('I am scr'+'ipt type=text/javascript id=inner
src=code.js/scr'+'iptthe bdocument/b');
document.close();
}
/script
/HEADBODY
button onclick=doDoc()runDoc/button
/BODY/HTML
---
Inside code.js:
---
document.write('img src=testIMG.jpg /');
---
testIMG.jpg is some image.
Chrome2/Safari4beta, Firefox3: the image shows up in the middle of the
sentence, where the script tag is. This seems to go with the interpretation
that the document.write call is not reentrant.
Opera10: the image shows up at the end of the sentence, which goes with the
interpretation that the document.write call *is* reentrant (and there's a
missing step in the spec to run any pending external scripts at the end of
section 3.7.2)
IE6: doesn't seem to run that nested script at all as far as I can tell, which
seems to also go with the interpretation that it's not reentrant and there's no
missing steps in the spec.
If my interpretation of the spec is correct, The Webkit/Gecko behavior is
correct, and Opera/IE are incorrect. Thoughts?
Cheers,
kats
[whatwg] Smart cards and the keygen element
A guesstimate is that less than 1 out of 10 000 smart cards actually are provisioned with keygen. There are two reasons for that: 1. keygen does not support the information/processes involved 2. current smart cards are unsuitable for on-line provisioning by end-users Due to this smart cards are generally always provisioned by card administrators using highly proprietary and expensive software, mostly only running on Windows. There's no problem to fix in other words! Anders
[whatwg] do not encourage use of small element for legal text (was: Pre-Last Call Comments)
Responding to Kristof Zelechovski. I have a copy of the Constitution of the United States on my web site. That is a legal text. It also qualifies as legalese, a derogatory term. If I were to change it to HTML 5, the current spec encourages me to place the entire Constitution in small elements. The same logic would apply for any legal document, including receipts for e-commerce purchases. I find that unfortunate because it makes the HTML 5 spec look foolish and irrelevant. Encouraging use of small print for legalese also encourages this: h1 a href=continue.html Welcome to the BigCo web site. Click to continue. /a /h1 smallBy clicking above, you agree that BigCo can charge your credit card $10 per visit to the BigCo web site per page clicked./small Now that might not stand if challenged in a court, but it is definitely not the kind of thing that the HTML 5 spec should condone. And yet, in its current form, it does. What ought to constitute outright fraud is encouraged by the HTML 5 spec in its current form. The HTML 5 spec also encourages, in its current form, placing any legal disclaimer in a small element. Therefore, we could have this result. h1BigCo Services: We guarantee our work/h1 smallExcept between the hours of 12:01 am and 11:59 pm./small That is a deceptive use of a disclaimer that the HTML 5 spec encourages. This is most unfortunate. There is no middle ground here. Encouraging legal text to be in a small element except when it is deceptive or inappropriate would at best lead to confusion. I'm not saying that everyone who puts legal text in small print is doing something bad, but generally speaking, that is a practice to avoid if possible. By making the changes I suggested, people can still use the small element for legal text. They can also choose other markup. It's just that the HTML 5 spec will do the right thing, and not go out of its way to make legal text small and hard to read. Andrew Hagen contact2...@awhlink.com
Re: [whatwg] do not encourage use of small element for legal text (was: Pre-Last Call Comments)
While I actually defended the recommendation to use the SMALL element for legal text, and I am still ready to do it, it is worth noting that the text of section 4.6.6. does not contain such a recommendation. It merely states that out of possible uses of the SMALL element, the legal use is the most common. The term legalese does not apply to pages that have the text of law as the main content, as in your example with the constitution. It only applies to cases where the legal text describes either the current page or the thing described by the current page and it is considered secondary to the main content. The example h1 a href=continue.html Welcome to the BigCo web site. Click to continue. /a /h1 smallBy clicking above, you agree that BigCo can charge your credit card $10 per visit to the BigCo web site per page clicked./small is incorrect, it should read: p a href=continue.html Welcome to the BigCo web site. Click to continue. /a STRONG Terms and conditions apply (see below)./STRONG /p smallBy clicking above, you agree that BigCo can charge your credit card $10 per visit to the BigCo web site per page clicked./small (Legal text itself can be small but its existence must be advertised so that the customer knows what to send to her lawyer.) Regarding the example h1BigCo Services: We guarantee our work/h1 smallExcept between the hours of 12:01 am and 11:59 pm./small It is also incorrect: a warranty is as much of legalese as a disclaimer. Would it make everybody happier if the relevant text quoted warranties alongside disclaimers? IMHO, Chris
Re: [whatwg] [html5] Pre-Last Call Comments
Am Mittwoch, den 03.06.2009, 13:23 +0200 schrieb Kristof Zelechovski: The validator generates an error for the classid attribute (in line with what the specification says, I think). An error, unlike a warning, breaks any complex process that depends on successful validation of the components. Why should you care about validation at all in this case (using proprietary non-standard technology) ? I think the specification text should be rephrased so that the validator can issue a warning instead. For the time being, the only practical workaround for this incompatibility is to use Internet Explorer magic comments. What's wrong with that ? Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Smart cards and the keygen element
redirected FYI :-) Eddy Nigg wrote: A guesstimate is that less than 1 out of 10 000 smart cards actually are provisioned with keygen. Can you backup your statement with facts please? I wrote guesstimate. However, if we exclude a limited number of security nerds (that mainly produce cards for themselves), and concentrate on REAL smart card deployments; you got about a million eID cards in Estonia, None of these were provisioned using keygen; they were presumably produced in some kind of card factory. For enterprises most of us know that Windows is the de-facto standard so even if they had actually used end-user provisioning, it would have been through Xenroll and CSPs rather than with keygen and PKCS #11. But why in the world would anybody bother with keygen, Xenroll, or generateCRMFRequest, for provisioning smart cards when: - you still have to do 80% of the gory stuff (formatting, PIN, PUK) in a Windows-only proprieterary card management application? - all bets are off regarding where keys actually were created? That is, keygen is left for soft certificates that by default are not even PIN-protected. In my vocabulary that spells insignificant. Anders - Original Message - From: Eddy Nigg eddy_n...@startcom.org Newsgroups: mozilla.dev.tech.crypto To: dev-tech-cry...@lists.mozilla.org Sent: Thursday, June 04, 2009 20:52 Subject: Re: Smart cards and the keygen element On 06/04/2009 09:40 PM, Anders Rundgren: A guesstimate is that less than 1 out of 10 000 smart cards actually are provisioned with keygen. Can you backup your statement with facts please? -- Regards
Re: [whatwg] [html5] Pre-Last Call Comments
The ActiveX components I use are proprietary non-standard technology. Granted. However, the interface to them, HTML, is standard and non-proprietary. Of course, one can use proprietary extensions like namespaces and data sources as well, and sometimes it is necessary for rendering and data management, but the classid attribute has not been the case until (yesterday). Valid code simply makes a better interface overall, which means validating it makes sense. Using IE magic comments causes the validator to skip not only the parts that have been invalidated, such as the classid attribute, but also the parts that would be valid otherwise. If there is error in there, it will go undetected, which is bad. Chris
Re: [whatwg] the cite element
Rendering the name Aristotle in italic by itself, if not used for emphasis, indicates that the name is used in an oblique, indirect way, perhaps referring to a fictitious person or a nickname, the person referred to as Aristotle by a 3rd party. Please do not ask me why this is so; I shall not be able to give a definitive answer. You may disagree, of course. I never said that titles MUST be rendered in an italic style. All I said is that, in the context where scholarly style guides prescribe normal style, the surprise factor of the user agent rendering it in italic style instead is negligible. OTOH, the surprise factor of the user agent rendering the *author* in italic style is unacceptable. I fully agree that this is an unfortunate circumstance. IMHO, Chris
Re: [whatwg] do not encourage use of small element for legal text (was: Pre-Last Call Comments)
Do you seriously believe any client in an industry where he has to step carefully enough to worry about typographical formatting of legal notices is fool enough to follow a not-even-recommendation in the HTML5 specification over what his lawyer tells him is the correct thing to do? Jeff
Re: [whatwg] HTML as a text format: Should title be optional?
On Fri, 17 Apr 2009, �istein E. Andersen wrote: HTML can be used as an advanced text format, and people may want to convert existing plain text to HTML. For example's sake, consider the following: A Short Document This is a short plain-text document which someone might want to convert into HTML. As faithful readers of this list will recall, /R�gles typographiques/ requires note names to be typeset in italics (/ut/, /r�/, /mi/, etc.), which is not possible in plain text. This corresponds to the following HTML: h1A Short Document/h1 pThis is a short plain-text document which someone might want to convert into HTML. pAs faithful readers of this list will recall, iR�gles typographiques/i requires note names to be typeset in italics (iut/i, ir�/i, imi/i, etc.), which is not possible in plain text. Unfortunately, this is not valid; the following two lines must be added to the top: !DOCTYPE html titleA Short Document/title A title is usually a good idea, but is it really necessary to require this for conformance? After all, a title is not something which an author is likely to forget, and leaving it out has no unexpected consequences. Leaving it out has a pretty important consequence, it breaks user interfaces that need to refer to the document, e.g. bookmarks features in browsers. On Sat, 18 Apr 2009, Randy Drielinger wrote: If you're converting from a textfile, title could refer to the filename. If it's an automated process, it can be added by default. If it's manual, they'll have to remember the short html5 doctype and the title element. It does indeed seem easy to include it. On Fri, 17 Apr 2009, Michael Enright wrote: If you use HTML as a text file format you can still let the receiving parser infer all sorts of tags and allow yourself to write things like Andersen's first HTML version. If you want a title, put a title element in. Is the concern about validation? Can one really get in that much trouble without a pedantic validator checking your work? Could the validator's warning about missing doctype be taken as advisory? Is the doctype a problem? It only affects the details of rendering (by turning off quirks) and HTML5 is still not equivalent to pagemaker anyway, especially without CSS. I'm not sure what you are asking for here. On Sat, 18 Apr 2009, �istein E. Andersen wrote: It could, but chances are that the original filename would typically be less useful than the URL, which is what most browsers use when the title element is omitted, so this rather sounds like an argument against forcing authors to include a title. I don't see why this would be the case. In practice, however, if one is at a loss as to what to use for the title, but one has an h1, then I would recommend using the h1's contents. Yes, my concern is that a validator should be useful as an authoring tool and not overwhelm the author with spurious errors. As I see it, leaving out title is very much like leaving out a paragraph of text and not something that should matter for validation. As it affects user interfaces, and since the cost of including a title is so low, I think it makes sense to continue to make it required. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fwd: Entity parsing
On Fri, 24 Apr 2009, Øistein E. Andersen wrote: When a named character reference is followed by a semicolon, it clearly has to be expanded, but how to handle non-semicolon-terminated character references is less obvious. Let IE4 (resp. HTML4, HTML5) be a non-semicolon-terminated named character reference from the IE4 (resp. HTML4, HTML5) set, and let . (full stop) represent any character other than semicolon, and ^ (circumflex) any character which is (roughly) not an ASCII letter or digit (i.e., [^a-zA-Z0-9]). Not completely unreasonable sets of character references to expand (outside of attribute values) include: 1) IE4^ 2) IE4. 3) HTML4^ 4) IE4. HTML4^ 5) HTML4. 6) IE4. HTML5^ 7) HTML4. HTML5^ 8) HTML5. (The set of character references to be expanded in attribute values could be obtained by replacing . by ^ above.) Currently, Opera follows 1), IE 2), and Safari and Firefox 3). My main concern is that HTML4^ is actually legitimate in HTML4 and works in both Safari and Firefox today, and that HTML5 should not change the rendering of valid HTML4 pages unless there is a good reason to do so. Could you give an example of what you mean? I'm having trouble following your description above. As far as I can tell HTML5 more or less matches what legacy pages need, but if there are specific entities that should be parsed in a different way than HTML5 says they should, I'm happy to fix this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Parsing RFC3339 constructs
On Mon, 27 Apr 2009, Julian Reschke wrote: Michael(tm) Smith wrote: Ian Hickson i...@hixie.ch, 2009-04-25 05:35 +: On Fri, 2 Jan 2009, Asbjørn Ulsberg wrote: Reading the spec, I have to wonder: Does HTML5 need to specify as much as it does inline? Can't more of it be referenced to ISO 8601 or even better; RFC 3339? I really fancy how Atom (RFC 4287) has defined date constructs: http://www.atompub.org/rfc4287.html#date.constructs Does not RFC 3339 defined date and time in a satisfactory manner to use directly in HTML5? The problem isn't so much the syntax definitions as the parsing definitions. We need very specific parsing rules; it's not clear that there is anything to refer to that does the job we need here. It seems pretty clear that there isn't anything else to refer to for the date/time parsing rules -- but to me at least, specifying those rules seems orthogonal to specifying the date/time syntax, and I would think the syntax could just be defined by making reference to the productions[1] in RFC 3339 (instead of completely redefining them), while stating any exceptions. [1] http://tools.ietf.org/html/rfc3339#section-5.6 I think the exceptions might just amount to: - the literal letters T and Z must be uppercase Any technical reason why they have to? Not really. We just need a separator. - a year must be four or more digits, and must be greater that zero a year must be four or more digits -- sounds like an alternative format that an additional RFC, updating RFC 3339 could specify. must be greater that zero -- that's not syntax :-) So yes, I think referring to RFC 3339, even if it's just a narrative mention, would be good. Why? Ian replied: I don't understand what that would gain us. It would help people understand what the difference to RFC 3339 is. Why is that important or desirable? It seems that comparisons to other specs would be better placed in other documents. HTML5 doesn't even describe how it differs from its previous version (HTML4), why would it include descriptions of differences from otherwise unrelated RFCs? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When closing the browser
On Mon, 27 Apr 2009, Tab Atkins Jr. wrote: On Mon, Apr 27, 2009 at 1:24 PM, Ian Hickson i...@hixie.ch wrote: One option would be to have an attribute, say body logout=, which causes the user agent to ping the site when the window is closed and there are no other windows open to the same origin. Of course this would break if the other window in question was open to a different page that didn't have the logout= attribute.. Maybe it should be invoked if there are no other pages open that have the same logout= attribute? This has the advantage of not depending on JavaScript, and not affecting the browser's performance (no waiting for sync XHR, etc). It would work somewhat like PING does today, though probably using POST. As an author, I'd definitely use it. I'd want the second option (ping when you close the last window with a given logout attribute), as that would allow me to define 'domains' within the same origin that track logins separately. It would be easy to code against the lack of this (just do an occasional cleanup of sessions that have aged too much, which you'd have to do anyway in case of nonstandard browser exits), but would allow better, more reliable security for users with browsers that implement it. Trying to handle this through javascript onunload is nontrivial currently, but @logout would make it both trivial and dependable. On Mon, 27 Apr 2009, Jo�o Eiras wrote: What if there is a loss of connectivity or the user agent crashes ? Relying on user agent telling when documents are unloaded has never been reliable nor will ever be. So, websites do timeouts and will continue to do so because those are needed. This is really about making the whole logout process more friendly for the web developer though. I thought of exporting a service, using a special element or something, which the user agent could call when if unloads all documents related to that origin or a special token in that element. Like logout specialtoken=123abcsessionid content=/logout The user agent would do a GET request of /logout when it no longer had documents loaded on windows with a logout tag with that specific specialtoken value. specialtoken (or whaever you'd like to call it) could be optional and in that case the user agent could rely on origin. This way, the server would not need to count the number of loaded documents. On Mon, 27 Apr 2009, Philipp Kempgen wrote: Maybe link rel=logout href=... is more suitable? Server-side applications should probably implement that in a way such that just one session (identified by a session cookie or whatever) gets logged out -- in contrast to all sessions of a user. The user might be logged in using 2 different browsers and might want to log out in one browser but keep the session active in the second one. And I'd probably want a same domain policy for the logout ping be implemented in the browser. On Tue, 28 Apr 2009, Bil Corry wrote: I like the idea -- thinking out loud here, rather than invoking it when all pages having the same logout= attribute are closed, can it instead use some other grouping identifier? That would allow a developer to pass back unique information from each page via the URI. And I like POST instead of GET. A same-origin restriction would be good too. Would the browser accept a response from the logout? I'm thinking that could be used to immediate end the cookie(s). I like Philipp's idea of making this a new rel value. I encourage people who are interested in this idea to add it to the WHATWG RelExtensions wiki, write a spec for it (you can put it on a page on that wiki if you like) and then see if browser vendors are interested in supporting this feature. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Reconstructing formatting elements (8.2.5)
On Tue, 28 Apr 2009, Kartikaya Gupta wrote: On Tue, 28 Apr 2009 01:15:30 + (UTC), Ian Hickson i...@hixie.ch wrote: The behavior HTML5 requires is thus intentional for compat with IE. We could avoid cloning quite as many by eating whitespace after a table-related tag (tr, td, etc) by resetting the table taint flag at those points... would that be desireable? I would say yes, but I don't feel too strongly about it. I don't like the large number of clones that result in the current algorithm, but then again, the HTML code in question probably doesn't occur that often. I've left it as is for now then. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML as a text format: Should title be optional?
On Fri, 17 Apr 2009, Michael Enright wrote: If you use HTML as a text file format you can still let the receiving parser infer all sorts of tags and allow yourself to write things like Andersen's first HTML version. If you want a title, put a title element in. Is the concern about validation? Can one really get in that much trouble without a pedantic validator checking your work? Could the validator's warning about missing doctype be taken as advisory? Is the doctype a problem? It only affects the details of rendering (by turning off quirks) and HTML5 is still not equivalent to pagemaker anyway, especially without CSS. I'm not sure what you are asking for here. I was addressing the potential drawbacks of permitting oneself to make an HTML file that didn't have a DOCTYPE in it. One of the drawbacks might be that the rendering would be in quirks mode. But if an author is leaving off tags, they aren't in a position to demand precise rendering in the first place. It's okay with me if DOCTYPE is required for valid HTML5 as long as in practice the parsers behave predictably when it isn't there.
[whatwg] AppCache and javascript url question?
What appcache (if any) should the resulting iframes be associated with? I
think per the spec, the answer is none. Is that the correct answer?
html manifest='myManifestFile'
body
script language=JavaScript
function frameContents1()
{
var doc = frame1.document;
doc.open();
doc.write('img src=image.png');
doc.close();
return;
}
function frameContents2()
{
return hello;
}
/script
iframe name=frame1 src=javascript:parent.frameContents1()
iframe name=frame2 src=javascript:parent.frameContents2()
/body
/html
Re: [whatwg] registerProtocolHandler() in HTML 5 is not sufficient for real use
On Tue, 28 Apr 2009, bryan rasmussen wrote: Generally speaking, the feature was intended for sites that wished to hook into URLs provided by _other_ sites, e.g. webmail hooking into mailto:, or web-based phone systems hooking into tel:. Only schemes that are actual registered schemes are supposed to be used: http://www.iana.org/assignments/uri-schemes.html This is not intended for sites that make up their own. Is that written anywhere? This cute and non-normative section implies otherwise: ||[ Protocol Handler Registration ]||| || | This Web page: | || |Kittens at work | |http://kittens.example.org/ | || | ...would like permission to handle the protocol x-meow: | | using the following Web-based application: | || |Kittens-at-work displayer | |http://kittens.example.org/?show=%s | || | Do you trust the administrators of the kittens.example. | | org domain? | || | ( Trust kittens.example.org ) (( Cancel )) | || I've attempted to address this (in part by changing the example above, and in part by explicitly saying This feature is not intended to be used with non-standard protocols). Is the new text suitably clearer on this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Link.onload; defer on style, depends
On Tue, 28 Apr 2009, Boris Zbarsky wrote: Ian Hickson wrote: Ah, yes. good point. I can require that relatively simply (just have the tasks that are queued for 'load' events themselves delay the page's load event) That's exactly what Gecko does. should I? I'd prefer that, but I'd be interested in feedback from other implementors. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] size attribute
On Tue, 28 Apr 2009, Ojan Vafai wrote: On Tue, Apr 28, 2009 at 12:34 AM, Ian Hickson i...@hixie.ch wrote: For implementors, the spec already gives, to the pixel, the length required (in the rendering section). Speaking of which, the spec isn't quite accurate to what IE does here. The spec lists (size-1)�avg + max as the converting a character width to pixels algorithm, which matches IE for text inputs, but not for textareas. For textareas it's just size�avg. Fixed, I think. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video and acceleration
On Wed, 29 Apr 2009, Simon Fraser wrote: Taking the video full-screen is an approach that makes a lot of sense for mobile devices. It's unfortunate that the spec shies away from the full-screen issue. The spec doesn't really shy away from it; it's just that the spec isn't the right place for it. There are two options as I see it: video-specific full page as you describe here, which is easily provided by a user-agent specific user interface (e.g. a button that appears when you hover on the video), and the general full-screen mechanism along with media-specific style sheets (e.g. F11 and media=projection). If the spec does say something about performance of video, I think it should be no more than a note that performance may differ across browsers, and can be affected in various ways that may be non-obvious to the page author, related to the layout and styling of the video and other elements on the page. I don't think such a note wold really be of much help to authors, so I haven't included it. I agree with the rest of your comments. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] code attributes
On Wed, 29 Apr 2009, ddailey wrote: 1. Having to type precodelt;tagname/code/pre seemed a little bit silly to me: is there a use case for *not* wanting pre when doing code? Could that not be handled as an attribute of the code if so? code is used a lot to refer to method names and the like, where the contents aren't preformatted. (For example, HTML5 uses code over 14,000 times but pre only about 500 times currently.) 2. having to escape as lt; in the middle of code seems like work for the author that could just as easily be handled by the browser. In the old days, xmp worked pretty well... why no replacement for its functionality?? If you can use XML, use ![CDATA[ ... ]] to escape the element's contents. In text/html, I think for HTML5 we've introduced enough changes to the parser for one version; I'd rather not add more until the current set have been well-implemented. 3. trying to style a code so that it would have an indented margin, a border, a default font-style (monospaced), preserve within -line indentation, and work consistently across browsers seemed to defy my humble abilities with CSS. (see http://srufaculty.sru.edu/david.dailey/cs427/StateOfArt-Dailey.html#test_file as an example of the very clumsy solution I ultimately opted for -- IE still doesn't preserve within-line indentation in this solution-- it used a styled table with a styled td and was particularly gross!.) If this is due to bugs, I encourage you to report them to your browser vendors. If it is due to limitations of CSS, I encourage you to bring this to the attention of the CSS working group. 4. if we could just write code language=xml html body svgrect//svg /body /html /code, it'd be nice to have the page render the HTML just as is. I'm not really sure what you mean here. 5. Some of the good folks on either whatwg-irc or htmlwg-irc let me know that codephappy/ppsad/p/code was bad form, and that I should use precode instead. It never would have dawned on me that the first was bad form, nor that the second would be good form. (maybe it should have dawned on me, but I speak html sorta like I speak english, more through habit than training, and not very formally at that). Second the introduction of p within code was actually generated by a robot that converted a bunch of MS Word to html so someone other than me must have thought it was a good idea to do it that way. The main reason not to allow this is that there are some very unintuitive results when parsing text/html where phrasing elements (like code) contain non-phrasing content (like p -- especially p, in fact). I'm not sure what we can do about this. On Thu, 30 Apr 2009, Smylers wrote: 2. having to escape as lt; in the middle of code seems like work for the author that could just as easily be handled by the browser. It could. But doing so would prevent being able to use other elements inside code, such as: pType codels vardir/var/code to see what's in the directory vardir/var./p That's a good point; HTML5 itself does this a lot in the spec text. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
