Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, Aug 14, 2009 at 4:08 AM, Philip Jägenstedtphil...@opera.com wrote: On Fri, 14 Aug 2009 12:48:59 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Fri, Aug 14, 2009 at 7:54 PM, Dr. Markus Waltherwalt...@svox.com wrote: Silvia Pfeiffer wrote: 2009/8/14 Dr. Markus Walther walt...@svox.com: Hi, The .start/.end properties were dropped in favor of media fragments, which the Media Fragments Working Group is producing a spec for. Who decided this? Has this decision been made public on this list? It will be something like http://www.example.com/movie.mov#t=12.33,21.16 var audioObject = new Audio(); audioObject.src ='data:audio/x-wav;base64,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; // play entire audio audioObject.play(); // play (0.54328,0.72636) media fragment ? Not in this way. In fact, the new way will be much much simpler and does not require javascript. With the code snippet given I was pointing out that it is not obvious (to me at least) how the proposed media fragment solution covers data URIs. If it is not meant to cover them, it is limited in a way that the solution it seeks to replace is not. I see no reason why they should not be applicable to data URIs when it is obvious that the data URI is a media file. This has not yet been discussed, but would be an obvious use case. BTW: Did the start and end attribute implementations that you refer to cover the data scheme, too? To my knowledge/experience, there is nothing special about data URIs. Any differences in how they work with the DOM interface or media fragments are more than likely implementation bugs. The problem is that you can't use fragment identifiers with data-URIs. For example data:text/plain,hello world#frag Represents a text/plain document with the contents: hello world#frag It does not represent the 'frag' part of a document with the text 'hello world'. / Jonas
Re: [whatwg] Remove addCueRange/removeCueRanges
On Sat, 15 Aug 2009 08:47:32 +0200, Jonas Sicking jo...@sicking.cc wrote: The problem is that you can't use fragment identifiers with data-URIs. For example data:text/plain,hello world#frag Represents a text/plain document with the contents: hello world#frag It does not represent the 'frag' part of a document with the text 'hello world'. Actually, I think that is false (and a bug in Firefox). At the time the data URI RFC was written RFC 2396 was still the URI RFC and there fragment identifiers were not a formal part of the URI syntax but rather something you could append to any URI during retrieval operations, which is clearly what data URIs are for. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, Aug 14, 2009 at 11:58 PM, Anne van Kesterenann...@opera.com wrote: On Sat, 15 Aug 2009 08:47:32 +0200, Jonas Sicking jo...@sicking.cc wrote: The problem is that you can't use fragment identifiers with data-URIs. For example data:text/plain,hello world#frag Represents a text/plain document with the contents: hello world#frag It does not represent the 'frag' part of a document with the text 'hello world'. Actually, I think that is false (and a bug in Firefox). At the time the data URI RFC was written RFC 2396 was still the URI RFC and there fragment identifiers were not a formal part of the URI syntax but rather something you could append to any URI during retrieval operations, which is clearly what data URIs are for. Would be great to get clarification on that. Safari seems to behave the same (though not if you modify a fragment on a already entered uri) / Jonas
Re: [whatwg] BWTP for WebSocket transfer protocol
Jonas Sicking wrote: ... Similarly content negotiation is something I would say is even more doubtful that it has provided any value. The only site where I can remember seeing content negotiation actually used is on w3.org, an organization that is safe can be considered experts on web standards. ... google.com does use it for language selection (at least it did a few months ago when Ian claimed nobody was using it :-). Also keep in mind that Content Negotiation is widely and successfully used for negotiating compression (Content-Encoding: gzip) and different machine-to-machine formats (xml vs json). ... However even here things immediately failed. When firefox started claiming that we supported application/xml, several urls stopped working since the browser was sent the XML file used to generate the specification, rather than something that actually usefully could be rendered. ... Did it come with an XSLT PI? BR, Julian
Re: [whatwg] BWTP for WebSocket transfer protocol
On Sat, Aug 15, 2009 at 2:59 AM, Julian Reschkejulian.resc...@gmx.de wrote: However even here things immediately failed. When firefox started claiming that we supported application/xml, several urls stopped working since the browser was sent the XML file used to generate the specification, rather than something that actually usefully could be rendered. Did it come with an XSLT PI? No. / Jonas
Re: [whatwg] small element should allow nested elements
On 14 Aug 2009, at 10:09, Ian Hickson wrote: I wouldn't bother wrapping any of the above as small print. If you're structuring this enough that you have numbered lists and paragraphs and everything, then it's either not small print, or it shouldn't be. As Aryeh said, my experience has been the inverse, this is small print. I've got the terms and conditions for a competition, which is small print for the whole thing. Currently I'm manually wrapping every sentence in a small tag (as per my example). For example, the BBC's web site is using the 62.5% rule, then by default pages are shown in 1.2em. The exception being their terms pages, which overrides the font size to 1em in a terms.css style sheet. This is because they want the text to appear as small print. BBC Terms: http://www.bbc.co.uk/terms/ Random blog post on the BBC (most, if not all pages are the same font size): http://www.bbc.co.uk/blogs/thereporters/robertpeston/2009/08/what_rbss_results_say_about_qe.html They're using CSS to visually create the small print effect on a large amount of text. From my understanding of the HTML 5 spec, the right semantics to use is the small element, but if they used it on their existing terms page, in the way that the spec current outlines it would bloat the page with the extra nested small element. Wrapping the entire block in small (or individual blocks) would be much more maintainable, and it would give the copy the right semantic meaning. Is that correct? Allowing elements to wrap both inlines and blocks is a huge can of worms which has caused all kinds of problems for ins, del, and a. I really don't want to start adding more elements to this list of complexity. Is there any record of these issues. I know of 1 rendering issue that Firefox has with nesting the section element inside the a element (but I'm sure you're referring to previously solved issues). I'd be happy to go through those issues and see if I can run tests against the small element through each of the browser engines to see if the issues still apply to small element. Cheers, Remy Sharp Left Logic ___ I'm running a conference in Brighton on 20-Nov called: Full Frontal JavaScript Conference http://2009.full-frontal.org
Re: [whatwg] small element should allow nested elements
Remy Sharp writes: On 14 Aug 2009, at 10:09, Ian Hickson wrote: I wouldn't bother wrapping any of the above as small print. If you're structuring this enough that you have numbered lists and paragraphs and everything, then it's either not small print, or it shouldn't be. For example, the BBC's ... default pages are shown in 1.2em. The exception being their terms pages, which overrides the font size to 1em in a terms.css style sheet. BBC Terms: http://www.bbc.co.uk/terms/ That's an entire page of legalese. The legalese is the point of the page. It doesn't need marking up in some way from the rest of the text on the page because there isn't any such text. This is because they want the text to appear as small print. CSS seems an entirely reasonable way of doing that. If a CSS-less user doesn't get the text delivered smaller no meaning is lost (since the user reading that page is aware that it's all small print). Ditto for a listen whose speaking browser uses the normal voice for it. Where small might be useful is another page which has a competition on it (in regular sized text) followed by: p smallTerms and conditions apply. For full details see the a href=http://www.bbc.co.uk/terms/;standard BBC Tamp;Cs./a./small /p In that case the short amount of 'small print' is distinguished from the surrounding text. Visual users can see it as such; a speaking browser could read it out faster. Smylers
Re: [whatwg] DOMTokenList: mutation clarification
On Mon, 10 Aug 2009, Sylvain Pasche wrote: 2) (using the class attribute for the discussion) What should happen when you do a remove(foo) on an element which has no class attribute? My understanding is that it shouldn't add a class attribute with an empty string. That's because the remove() algorithm starts with an empty string and doesn't change it, so the when the object mutates this empty string, case shouldn't be true (and thus no attribute modification should happen). However Simon's testcase [1] doesn't agree with this, and adds an empty string. So maybe it's worth clarifying this situation? I think that the spec now implies that you set the attribute to the empty string. Do you agree? I don't think it changes the interpretation of this border case and I still think the spec implies that no attribute is added. You are correct, I misinterpreted my own text! I've added an example so that this is crystal clear. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 2.2.2 editorial
On Mon, 10 Aug 2009, Elliotte Rusty Harold wrote: For example, while strongly discouraged to do so, an implementation Foo Browser could add a new DOM attribute fooTypeTime to a control's DOM interface that returned the time it took the user to select the current value of a control (say). while strongly discouraged to do so -- while strongly discouraged from doing so delete (say). It's informal and redundant with For example. I assume these are two independent suggestions. I've done the first. I don't have a problem with the examples being informal, and I don't think it's redundant with the for example -- without it, it's not clear if fooTypeTime could return anything else if it was invented, or if it would only be allowed to return whatever it is the example says it can return. So I haven't done the second. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 2.3 editorial: operators, operations, or ?
On Mon, 10 Aug 2009, Elliotte Rusty Harold wrote: This specification defines several comparison operators for strings. Really, operators? Is this the right word here? Maybe it should be several comparison operations on strings or several possible comparisons for strings. What's wrong with operators? They are literally functions that the rest of the spec uses, it seems like the right word here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 2.4.4.3 editorial
On Mon, 10 Aug 2009, Elliotte Rusty Harold wrote: As with the previous algorithms, when this one is invoked, the steps must be followed in the order given, aborting at the first step that returns something. I suggest deleting when this one is invoked. It doesn't really add anything. I've reworded this sentence. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] small element should allow nested elements
Here's the actual example I'm working with: http://2009.full-frontal.org/ticket-draw (at the bottom of the page) You can see that I've had to wrap each inner li element, and also that the li bullet sizes don't match that of the text. It seems logical to me to wrap the entire ol element in the small tag. Remy Sharp On 15 Aug 2009, at 12:29, Smylers wrote: Where small might be useful is another page which has a competition on it (in regular sized text) followed by: p smallTerms and conditions apply. For full details see the a href=http://www.bbc.co.uk/terms/;standard BBC Tamp;Cs./ a./small /p
Re: [whatwg] 2.3 editorial: operators, operations, or ?
On Sat, Aug 15, 2009 at 4:40 AM, Ian Hicksoni...@hixie.ch wrote: On Mon, 10 Aug 2009, Elliotte Rusty Harold wrote: This specification defines several comparison operators for strings. Really, operators? Is this the right word here? Maybe it should be several comparison operations on strings or several possible comparisons for strings. What's wrong with operators? They are literally functions that the rest of the spec uses, it seems like the right word here. A function is not an operator. According to Wikipedia, In mathematics, an operator is a function which operates on (or modifies) another function. A comparison is an operation on strings (data), not on other functions. In traditional programming languages such as Java and C, an operator is usually a language defined symbol, and occasionally a user defined symbol. That also doesn't apply here. For instance, in Java, operators are special symbols that perform specific operations on one, two, or three operands, and then return a result. What you're describing is likely a function or perhaps an operation, but I don't think it's an operator in the commonly understood senses of the term amongst the people likely to be reading this spec. -- Elliotte Rusty Harold elh...@ibiblio.org
Re: [whatwg] Section 1.7 abstract language
What term would you recommend rather than language that is more understandable than data model or information model? Would vocabulary be ok? Vocabulary may be an an improvement over abstract language--I'd need to think further about that--but I think Kevin's suggestion is likely better. The spec defines a language (not abstract) with two syntaxes (or dialects, or variants). E.g. This specification defines a language for describing documents and applications, and some APIs for interacting with in-memory representations of resources that use this language. The in-memory representation is known as DOM5 HTML, or the DOM for short. Various syntaxes can be used to transmit documents written in this language, two of which are defined in this specification. The first such syntax is HTML5. This is the format recommended for most authors. It is compatible with all legacy Web browsers. If a document is transmitted with the MIME type text/html, then it will be processed as an HTML5 document by Web browsers. The second syntax defined here uses XML, and is known as XHTML5 -- Elliotte Rusty Harold elh...@ibiblio.org
Re: [whatwg] 2.3 editorial: operators, operations, or ?
On Sat, Aug 15, 2009 at 8:16 AM, Elliotte Rusty Haroldelh...@ibiblio.org wrote: On Sat, Aug 15, 2009 at 4:40 AM, Ian Hicksoni...@hixie.ch wrote: On Mon, 10 Aug 2009, Elliotte Rusty Harold wrote: This specification defines several comparison operators for strings. Really, operators? Is this the right word here? Maybe it should be several comparison operations on strings or several possible comparisons for strings. What's wrong with operators? They are literally functions that the rest of the spec uses, it seems like the right word here. A function is not an operator. According to Wikipedia, In mathematics, an operator is a function which operates on (or modifies) another function. A comparison is an operation on strings (data), not on other functions. In traditional programming languages such as Java and C, an operator is usually a language defined symbol, and occasionally a user defined symbol. That also doesn't apply here. For instance, in Java, operators are special symbols that perform specific operations on one, two, or three operands, and then return a result. What you're describing is likely a function or perhaps an operation, but I don't think it's an operator in the commonly understood senses of the term amongst the people likely to be reading this spec. The term 'operator' *is* sometimes used to just mean 'function' in functional languages. The term 'comparison operator' in specific is fairly normal in my experience. ~TJ
[whatwg] Drag and Drop Security Model and current implementations
Hi Ian et al, I've been playing with some of the current implementations of the Drag and Drop feature described in section 7.10 of the spec. The current security model seems a bit too strict in my opinion and needs some tweaking. Please find below my two proposals for changes in section 7.10.3 and 7.10.7. Any comments very much appreciated. Aron during the dragover event: Full access to the dataTransfer object should be granted if the dragover event gets fired on a page with the exact same location as the location from where the dragstart event originated from. With location I mean at least full hostname and port (or default), not necessarily the protocol. This precise behaviour is currently implemented in Google Chrome 2.0.172.40 and Firefox 3.5, whereas Internet Explorer always grants full access regardless of different hostnames in the location between the originating dragstart and dragover events, so it would be compatible with this change. I believe this behaviour makes a lot of sense for a Web-Developer of a complex Web-Application which works over more than one browser-window as it would give him much more flexiblity on what can be done and previewed and decided on during a dragover operation before an actual drop event happens. Personally I'd guess the reason for this being implemented in Chrome and Firefox already is because their development-labs requested it. 2nd proposal during the dragover event: Access to the readonly attribute 'types' of the dataTransfer object should always be granted during a dragover event to allow the potential target element to response accordingly. The current spec doesn't allow a potential target element to decide during a dragover event based on the dragged data if it wants to accept a potential drop of that data or not. It always has to accept potential drops by preventing the default behaviour of the dragover event even if it can't process the data during a drop event. This can give the wrong indication to the user of the user agent if it turns out the element can't process the data when the drop event gets fired. Obviously it makes a lot of sense from a security perspective to restrict the access to the dataTransfer object during a potentially meaningless dragover event. However some indication on what type the data is should be given during the dragover event. The best compromise I believe would be to allow exclusive and read only access to the 'types' attribute of the dataTransfer object so that it can find out of what type the data is which can be potentially dropped upon it. All current implementations don't transfer any sensitive or confidential data in the types attribute. And obviously by definition of the current spec the 'types' attribute is not meant to be used for user data as it has to be used to specify the data types exlusively. Maybe to discourage abuse of the types attribute the length of each item should be limited as well as the characters it can hold. For instance I don't think it should accept any newline or linebreak characters.
Re: [whatwg] 2.3 editorial: operators, operations, or ?
On Sat, Aug 15, 2009 at 7:32 AM, Tab Atkins Jr.jackalm...@gmail.com wrote: The term 'operator' *is* sometimes used to just mean 'function' in functional languages. The term 'comparison operator' in specific is fairly normal in my experience. True, but I do not want to assume familiarity with functional programing languages in order to comprehend the spec. Comparison operators most commonly refers to symbols such as , =, ==, ===, and so forth. In some languages such as Fortran it may refer to alphabetic symbols such as .GT or .LE. However it is not what is being described in this section of the HTML5 specification. -- Elliotte Rusty Harold elh...@ibiblio.org
Re: [whatwg] A tag for measurements / quantity?
On Tue, 11 Aug 2009, Max Romantschuk wrote: Having used the web for the past 15 years I've always felt that it's a shame when you run into a page with a set of measurements and those can't be interpreted automatically in a sensible fashion. Especially with the fact that there are both imperial and metric units still around in this day and age. An backwards compatible inline element to specify a quantity would be rather trivial: quantity unit=cm12 cm/quantity quantity unit=kg2 kg/quantity With this implementation a number inside the quantity element would be interpreted as the numerical value of the unit. Other characters would be ignored. That way old browsers would simply ignore the unknown tag, whereas a browser aware of this tag could provide DOM hooks for things like implementing a browser extension to convert between metric and imperial units. I don't really understand the use case here. What problem would this be solving? What do we have to demonstrate that this problem matters? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] idle minds want to know...
[21:28] Dashiva Does anyone know when JF went from against wcag2 to being for it? Sometime between the 27 April 2006 Draft (http://www.w3.org/TR/2006/WD-WCAG20-20060427/) and the 11 December 2007 Draft (http://www.w3.org/TR/2007/WD-WCAG20-20071211/) I think it was on a Tuesday. JF
[whatwg] SharedWorkers and the name parameter
Currently, SharedWorkers accept both a url parameter and a name parameter - the purpose is to let pages run multiple SharedWorkers using the same script resource without having to load separate resources from the server. [ request that name be scoped to the URL, rather than the entire origin, because not all parts of example.com can easily co-ordinate.] Would there be a problem with using URL fragments to distinguish the workers? Instead of: new SharedWorker(url.js, name); Use new SharedWorker(url.js#name); and if you want a duplicate, call it new SharedWorker(url.js#name2); The normal semantics of fragments should prevent the repeated server fetch. -jJ
Re: [whatwg] HTML5 History Management
Ian Hickson wrote: On Wed, 5 Aug 2009, Nathan Hammond wrote: I should have stated this one with a goal: the ability to ensure that the popstate event always fires with a full understanding of the (app/page) state when navigating through history. This would be lost when a user manually changes the hash. With that as my goal, history.replace does not achieve what I am trying to accomplish. Neither does pushState without a URL as that still registers a new history point. All the information about the state really should be in the URL, such that the state of the app after the user manually changes the hash, and the state of the app after the user returns to a point in the history where he had manually changed the hash, really should be the same. This has never been true for server-side web applications so why should it be this way for client-side apps? My understanding of the purpose of pushState has been that it is there to aid client-side apps in behaving like server- side apps wrt history traversal. Not to make them more different and break user expectations. I don't think we should encourage cases where the same URL can correspond to multiple states, which this would encourage. This statement confuses me as the whole point of pushState seems to be to store unique state in addition to the URL. If the URL can be used to infer the state anyway, then what's the point of storing it in the history entry? But you may have a different purpose for these state objects. I'm expecting to store things like step-for-step state from wizard-like flows, or user interface state similar to (but in addition to) the browser's own handling of saving/restoring form field values and scroll position. Though, when taking a more thorough look at what is spec:ed, it seems these use cases are indeed not supported, due to state update limitations and how events are ordered. It would be very interesting to hear about the scenarios you have in mind, to be able to comment correctly. It would be great if you could flesh out (or point to) a concrete example of correct and intended usage of this history state object mechanism. [suggesting .hashvalue on hashchange event] I really don't follow. Imagine you're updating what's visible based on the hash, and the user changes the hash twice in a row quickly such that by the time you get the first event, the location's already changed again. Why wouldn't you be happy to ignore the first location? F ex, because your client-side app may update some state based on what (or how many times) individual fragments have been visited. Maybe something in the spirit of read count or so. Two other notes about the history state mechanism: 1) The popstate event is sort of a misnomer as it doesn't pop the state. Popping would imply removing it from its stack, but this is not the case as it remains in place in the history to be retrieved any number of times. A better name could be something like restorestate. 2) This text at the end of 6.10.1: | When state object entries are added, a URL can be | provided. This URL is used to replace the state object | entry if the Document is evicted. I'm not sure how to interpret this. Does it (implicitly) say that all state objects are evicted when the owning Document is evicted? And does the popstate event really supply the URL string in its .state member, instead of the real object, in these cases? One super-minor nit: In 6.10.3 we have: | (which happens during [[session history traversal]], as | described above) The link points to 6.11.9 which is below, not above. Best regards Mike Wilson
Re: [whatwg] 2.3 editorial: operators, operations, or ?
On Sat, Aug 15, 2009 at 9:16 AM, Elliotte Rusty
Haroldelh...@ibiblio.org wrote:
A function is not an operator. According to Wikipedia, In
mathematics, an operator is a function which operates on (or modifies)
another function. A comparison is an operation on strings (data), not
on other functions.
In mathematics, operator is often defined to be a function from a
set (or some finite Cartesian product of the set with itself) to the
same set. Or, really, it can be used to just mean an arbitrary
function, like linear operator meaning the same as linear
map/linear transformation.
The Wikipedia article contradicts itself. In the lede, it has the
quote you cite, but later it says:
The word operator can in principle be applied to any function.
However, in practice it is most often applied to functions which
operate on mathematical entities of higher complexity than real
numbers, such as vectors, random variables, or mathematical
expressions.
The second statement is correct. I've corrected the first.
Of course, in mathematical parlance, operators do have to be
functions, and comparisons usually aren't viewed as functions in
mathematics. They're viewed as orderings, a different type of
relation. But you could always view an arbitrary relation as a
function with range {0, 1}, and in computing, comparison operator is
common.
I do agree that comparison operator sounds a little weird in this
context. I can't really put my finger on why, though, or think of a
better term. I think it's harmless, anyway, and not worth wasting
much time on given the amount of real work to be done.
Re: [whatwg] Parsing RFC3339 constructs
On Tue, 11 Aug 2009, Nils Dagsson Moskopp wrote: Am Dienstag, den 11.08.2009, 07:27 + schrieb Ian Hickson: On Tue, 11 Aug 2009, Julian Reschke wrote: Ian Hickson wrote: On Mon, 27 Apr 2009, Asbjørn Ulsberg wrote: On Mon, 27 Apr 2009 12:59:11 +0200, Julian Reschke julian.resc...@gmx.de wrote: - the literal letters T and Z must be uppercase Any technical reason why they have to? Any reason why they don't? It simplifies processing a tiny amount. So for a tiny win, you change the format? By a tiny amount, yes. It will be interesting to see if parsers choose to also get lowercase letters. I'd half-expect that to work, not at least because there may already be RFC-compliant libraries in the wild. The spec explicitly points out that implementors shouldn't naively use ISO8601 libraries. So if they do by the time HTML n is the standard, will the uppercase restriction be removed in HTML n+1 ? HTML5 itself will have to change if the implementations don't implement what it says. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] scripts, defer, document.write and DOMContentLoaded
On Tue, 11 Aug 2009, Kristof Zelechovski wrote: 1. The specification defines the term script source to mean either the text or the infoset, depending whether the script is text-based or XML-based. What is the script source for type text/xml then? Assuming you mean an internal script, the children of the script element. What happens when the XML is invalid? Assuming you mean in an XHTML document, the parser would have failed long before the script element was completely parsed and executed. If you mean a text/html document, then I don't know which XML you mean. 2. Why doesn't script source mean the text of the script in all cases? Because that would break XML-based scripting languages. 3. Microsoft Internet Explorer supports XHTML as text/xml, although it does not support XHTML as application/xhtml+xml. But I did not mention XHTML anywhere in my question. OTOH, any XML makes a SCRIPT for IE - a data script. Or did you mean a data script to be necessarily plain text? I fail to see it specified. I have no idea what you are asking. 4. So, the question is whether such data scripts are allowed to be loaded externally. AIUI, they are not allowed. AFAIK, they are supported, at least in MSIE. I'm not aware of any UAs implementing an XML-based scripting language, so I don't know how one would be able to say. 5a: XML-based scripts are not accessible as infosets, they can only be executed; 5b: data scripts are only text/plain; 5c: XML islands in SCRIPT elements are not supported. In particular, execution of arbitrary XML data in the browser is not allowed to attach an XML document to the SCRIPT element. (Why not, given that you allow the browser to do whatever it likes with script of type application/x-whatever?) Is that correct? I have no idea what you're talking about here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 2.3 editorial: operators, operations, or ?
On Sat, Aug 15, 2009 at 10:11 PM, Aryeh Gregorsimetrical+...@gmail.com wrote: I do agree that comparison operator sounds a little weird in this context. I can't really put my finger on why, though, That might be because the typical use for the word comparison is as... a _noun_ ( not an adjective :) or think of a better term. The logical grammar correction for the two words already there, would _seem_ to be: comparative[1] operations[2] I think it's harmless, anyway, and not worth wasting much time on given the amount of real work to be done. Indeed. An explanation[3] of the word operator or the realm[3] of operational procedures...can be _quite_ complex. ;) -- -- -- -- ô¿ô¬ K e V i N /¯\ On Sat, Aug 15, 2009 at 9:16 AM, Elliotte Rusty Haroldelh...@ibiblio.org wrote: On Sat, Aug 15, 2009 at 4:40 AM, Ian Hicksoni...@hixie.ch wrote: On Mon, 10 Aug 2009, Elliotte Rusty Harold wrote: This specification defines several comparison operators for strings. Really, operators? Is this the right word here? Maybe it should be several comparison operations on strings or several possible comparisons for strings. What's wrong with operators? They are literally functions that the rest of the spec uses, it seems like the right word here. A function is not an operator. According to Wikipedia, In mathematics, an operator is a function which operates on (or modifies) another function. A comparison is an operation on strings (data), not on other functions. In traditional programming languages such as Java and C, an operator is usually a language defined symbol, and occasionally a user defined symbol. That also doesn't apply here. For instance, in Java, operators are special symbols that perform specific operations on one, two, or three operands, and then return a result. What you're describing is likely a function or perhaps an operation, but I don't think it's an operator in the commonly understood senses of the term amongst the people likely to be reading this spec. -- Elliotte Rusty Harold elh...@ibiblio.org [1] http://www.merriam-webster.com/dictionary/comparative [2] http://www.merriam-webster.com/dictionary/operations [3] http://books.google.com/books?id=rhvDiOxOUe4Clpg=PA341pg=PA340
