Re: [whatwg] FYI: HTML usage data from Disqus websites
On Wed, 19 Jan 2011 11:59:12 +0100, Anton Kovalyov wrote: I work as a front-end engineer at Disqus. We are pretty popular commenting widget installed on around 500k websites throughout the world and visited by 300mln+ unique visitors per month. I am working on a project to gather some statistical data from the pages where our code is running to help us with some performance tuning. However, I want to use the opportunity and ask if this group is interested in some specific reports (like http://code.google.com/webstats/index.html). If you have some stats you'd like to see, let me know (by replying to this thread) and I will try to make it happen. Of course, the data will be completely anonymous and it has to be related to WHATWG's main focus. Results will be published probably by me on behalf of the company. If you could give the same kind of data "webstats" gathered but for your dataset that would be great. But anything really might give some insight into what is going on on the Web. :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Revisiting innerWidth quirks
On Fri, 14 Jan 2011 15:04:11 +0100, Boris Zbarsky wrote: On 1/14/11 2:05 AM, Charles Pritchard wrote: I don't know that FF supports matchMedia http://dev.w3.org/csswg/cssom-view/#dom-window-matchmedia Not yet. I don't believe we've even reviewed that proposal for sanity yet. David Baron came up with the current design. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] submit: button vs input
On Thu, 13 Jan 2011 16:21:17 +0100, Alan Plum wrote: is there any official recommendation for which element to use for form submission buttons? Historically, input has been preferred because of button's implementation differences in IE6. Now that IE6 support is becoming less and less of an issue for many websites, that argument is loosing importance and I've actually heard web design schools recommend using buttons instead. The "HTML5" spec doesn't seem to cover this issue at all. The WHAT WG HTML 5 spec's commenting tool uses input (type=button no less!), which indicates a certain preference, but again it's not clear whether this can be regarded as authoritative. Any input? Both are fine. PS: Yes, that was a horrible pun. Heh, I missed it initially. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Consecutive hyphen-minus characters in comments/in ACE-strings of IDNs
On Fri, 07 Jan 2011 02:10:26 +0100, Ian Hickson wrote: The question, I guess, is which of the following do we think is more important: * Helping authors not write HTML markup that might be hard to convert to XML, and helping authors avoid nesting comments accidentally, by flagging "--" sequences in comments * Getting out of the way of authors who want to put "--" sequences in comments, e.g. because they use "--" as a long dash (as I do all the time!), or because they want to comment out punycoded URLs. Currently the spec assumes the former is more important. Personally, I think the latter is rather more useful, but then I use "--" as long dashes all the time! When this was last studied, the weight of argument was on the stricter "disallow --" side of things, presumably. I'm open to changing this back; does anyone else have an opinion on this? I think the main concern back then was compatibility with legacy browsers. I would not mind easing the restriction as relatively soon all browsers will have HTML5 comment parsing. And given that are clear delimiters disallowing -- does not make a whole lot of sense. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Timed tracks: feedback compendium
On Wed, 05 Jan 2011 10:58:56 +0100, Philip Jägenstedt wrote: Therefore, my thinking is that comments should be removed during parsing and not be exposed to any layer above it. CSS does that too. It has not caused problems so far. It does mean editing tools need a slightly different DOM, but that is always the case as they want to preserve whitespace details, etc., too. At least editors that have both a text and visual interface. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] input element list attribute and filtering suggestions
On Fri, 31 Dec 2010 01:36:44 +0100, Ian Hickson wrote: The thing that makes this different than "Google suggest"-style UI is that in the latter case you need a script that continually polls for more appropriate suggestions and updates the list -- for this kind of thing we'd probably want to use a direct API, we wouldn't want to have scripts have to poke at the DOM in real time. For the "Google suggest"-style UI you also need to be able to show more than just options. Google has buttons, tables, images, and all kinds of other things in its dropdown. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Onpopstate is Flawed
On Sun, 19 Dec 2010 08:42:09 +0100, Henry Chan wrote: *bump* This is really serious, it blocks a very good use of the API, and it's unreliable to use it if back and forward is clicekd before onload. This got fixed, no? http://html5.org/tools/web-apps-tracker?from=5685&to=5686 -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Bluetooth devices
On Sat, 11 Dec 2010 22:53:47 +0100, Bjartur Thorlacius wrote: On 12/2/10, Diogo Resende wrote: For example, a medical device may have no interest to the OS but a web app (just like a desktop app) could get some interesting information and perhaps send some instructions. Maybe some API like the geolocation.. Wrong layering. HTML is for providing information, not deciding what to do with it. Provide data, information, let UA gather and user use. What do you mean with this? I don't think Don was talking about mouse/kb/video/gps stuff. That should be handled by the OS and reflected to the current APIs as wired alternatives do. I think Don meant to be able to scan other types of devices and be able to interact with them. What makes other devices so different that they need special exposition? They are far more common. We always try to optimize the common case. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] element "img" with HTTP POST method
On Fri, 10 Dec 2010 03:26:14 +0100, Adam Barth wrote: On Thu, Dec 9, 2010 at 4:46 PM, Tab Atkins Jr. wrote: Why wouldn't Logout work, with some CSS to make it look like a link if you wanted that? It's too much work. :) Maybe we should make work without ancestor for these cases? Not sure if it is really worth it though. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Bluetooth
On Thu, 02 Dec 2010 15:50:07 +0100, Diogo Resende wrote: This is exactly my point (and probably Don). I was not thinking about common i/o devices. I was thinking about a way to somehow connect to an uncommon device. Maybe something like websockets, maybe devsockets :P Heh. I can see 3 important steps to do this: - have a way expose diferent devices (so the app can search/list) - have permission to access a specific device (yes/no/remember) (the browser should do the bluetooth pairing stuff) These two should be done via I think. Giving blatant access to external devices from web pages would be quite the security risk. - talk to the device with some kind of stream/socket Does anyone think this could be a good idea? I certainly think it's cool. :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Bluetooth
On Thu, 02 Dec 2010 15:17:37 +0100, Silvia Pfeiffer wrote: IMO it's not so much about how the device is connected, but rather what the device is: e.g. if it's a storage device then it should come up as a storage device and not as a USB or FW device - the latter doesn't really say what its use is. That is only interesting for devices that are commonly used. For the long tail you need some kind of open-ended API. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Bluetooth
On Thu, 02 Dec 2010 15:05:06 +0100, Diogo Resende wrote: What about having the possibility to "use" a device other than a video? Maybe a specific hardware. I agree about not having a distinction on the hardware stack being used, but there should be a way for an app to be able to access an USBx/BT/FW device. Ideally we can have some abstract layer -- so type of hardware does not need to be exposed -- that JavaScript can script against. Not sure how feasible that is though. It would be quite cool if all kinds of devices such as game controllers, medical devices, etc. can be connected in a browser-agnostic way (i.e. no extensions) and the page could provide the implementation. Seems somewhat far away though. :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] EventSource: treating mailto as 204 does not work
On Thu, 02 Dec 2010 14:10:33 +0100, Anne van Kesteren wrote: For fetching EventSource resources treating mailto as if it was a 204 does not work as that reestablishes the connection. The result should be more akin a network error of some kind I think. Similarly to how other cross-origin requests fail if CORS is not used. I will add some tests for this. javascript, about:blank etc. should also be treated like this, naturally. Only http/https can currently work cross-origin. (And maybe browser proprietary schemes.) -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] EventSource: resolving URLs
Per the EventSource specification URLs are resolved against the "first script". However, implementations -- Opera and Chrome -- appear to resolve URLs in the same way they are resolved for XMLHttpRequest. I.e. against the Document the interface object is associated with. That is why this testcase is failing: http://tc.labs.opera.com/apis/EventSource/eventsource-constructor-url-multi-window.htm It makes some sense to me to resolve URLs in the same way as XMLHttpRequest. Does "first script" really make sense here? I also wonder if "first script" is actually ever used for this. (Did not put time in investigating that for now.) -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] EventSource: treating mailto as 204 does not work
For fetching EventSource resources treating mailto as if it was a 204 does not work as that reestablishes the connection. The result should be more akin a network error of some kind I think. Similarly to how other cross-origin requests fail if CORS is not used. I will add some tests for this. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Javascript: URLs as element attributes
On Wed, 01 Dec 2010 19:11:25 +0100, timeless wrote: On Wed, Dec 1, 2010 at 5:29 PM, Boris Zbarsky wrote: Oh, the other thing that JavaScript can do that data: can't do is trade off url length for CPU time. A data: URI to write out the first 3000 Fibonacci numbers would be a lot longer than the equivalent javascript: URI. Again, one would have to find non-silly use cases here. mandelbrot sets These can also be done with data:text/html,... and maybe . It is slightly longer, but not much. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Bluetooth
On Wed, 01 Dec 2010 06:37:09 +0100, Saurabh Jain wrote: We need access to Bluetooth devices using the Device element. Without Bluetooth access some of the use cases, specially in the mobile device domain would not be achievable. I think the question is why does it matter they are connected via Bluetooth? Should we really have a USB/Bluetooh/Firewire/etc. distinction at the web platform level? That seems like a bad thing. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Wed, 01 Dec 2010 00:27:23 +0100, Ian Hickson wrote: An update since this topic was discussed on this list before: I updated the vendor-specific syntax a while back to be x-vendor-foo="" for content attributes, and .vendorFoo for IDL members; attributes starting with an underscore are also reserved but their use is not encouraged. If we do .vendorFoo shouldn't we just do vendor-foo=""? "opera", "moz", "webkit", "ms" are unique enough and HTML attributes generally do not use hyphens anyway. (And yes, there will be some more vendors, etc. But over the years there have not been many extensions at all so this is all rather manageable.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Proposal: Characters data (coordinate and sizes)
On Tue, 30 Nov 2010 13:33:07 +0100, Anton Byrna wrote: Hello everyone, how about API that give ability to get information about character coordinates (and sizes) on the page. For now to get this info, we need wrap every symbol in it's own tag and calculate it position, maybe I'm wrong, but another approach I don't know. http://dev.w3.org/csswg/cssom-view/#extensions-to-the-range-interface -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Make radio button group suffering from being missing
On Thu, 04 Nov 2010 01:20:37 +0100, Mounir Lamouri wrote: Currently, when a radio button is required, it will suffer from being missing if no radio elements in the radio button group is checked. However, radio elements in the group will not suffer from being missing if they do not have the required attribute. In other words, if you try to style invalid elements with :invalid, and do: only the first element will be styled. I think we should move the requirement to the radio button group that way: "The radio button group suffers from being missing if one of the input elements in the radio button group is required and all of them have a checkedness that is false." and radio elements would have this constraint: "If the radio button group is suffering from being missing, the element is suffering from being missing.". That way, all radio elements in the same radio button group will have the same validity state. That would be less annoying for authors and error proof while making things clearer (IMO). I'm thinking of implementing that for Gecko 2.0/Firefox 4 so I would like to know if you know any reason that would make the current behavior more appropriate than the one described here. Do you have tests for this by any chance? I agree it makes sense to always treat them as a group. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] need a way to set output format from StreamRecorder
On Fri, 26 Nov 2010 19:01:40 +0100, Per-Erik Brodin wrote: A Stream can be treated as an abstract representation of a media stream. When a Stream is to be transported over a peer-to-peer connection, the format can be negotiated between the peers. In the current ConnectionPeer API, such format negotiation would be transparent to the API. If we would specify a single resolution for video, for example, that resolution may be to high for some mobile devices to encode in real-time. A mismatch in supported formats is just one reason why a peer-to-peer transport may fail, but that doesn't mean that the peers can't communicate. When relaying through a server you can interoperate with anything. Via a server, maybe, if the author took care of having a transcoder there. Ideally P2P is without such an intermediary. And although authors can exclude parties now by using proprietary plug-ins, I am not convinced we should make that an intrinsic part of the web. Not finding a codec / simply using VP8 will make that a reality however. If you are referring to sendFile(file) on ConnectionPeer, the file may just as well come from the user's hard drive via and thus it will be up to the application to ensure that whatever is sent to the other peer is usable there. That is quite a different scenario from exchanging a live media feed. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] need a way to set output format from StreamRecorder
On Sat, 27 Nov 2010 21:26:58 +0100, Silvia Pfeiffer wrote: As for choosing a single codec - if we end up not being able to agree on a single compressed codec for audio/video streaming, we will get into a situation where all your involved parties in a video or audio conference have to use the same browser (or select from a restricted group of browsers only) for a live communication. I guess it's workable, but kinda strange for an open platform like the Web. I would not really even want to consider that as an acceptable outcome, to be honest. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Server-Sent Events parsing issue
On Thu, 25 Nov 2010 18:21:35 +0100, ATSUSHI TAKAYAMA wrote: I would say the simpler the rule is, the better. So a line without colon should be ignored. Also for the example in the spec; -a single "data:" line followed by an empty line should fire a message event with an empty string data, and -two "data:" lines followed by an empty line should fire a message event with an LF as data (push every line followed by an LF, then remove the last LF and fire it) That works for me. Hixie? People from WebKit? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Canvas gradients color interpolation - change to premultiplied?
On Tue, 23 Nov 2010 23:09:40 +0100, Philip Taylor
wrote:
On Tue, Nov 23, 2010 at 8:43 PM, Tab Atkins Jr.
wrote:
Right now, canvas gradients interpolate their colors in
non-premultiplied space; that is, the raw values of r, g, b, and a are
interpolated independently. This has the unfortunate effect that
colors darken as they transition to transparent, as "transparent" is
defined as "rgba(0,0,0,0)", a transparent black. Under this scheme,
the color halfway between "yellow" and "transparent" is
"rgba(127,127,0,.5)", a partially-transparent dark yellow, rather than
"rgba(255,255,0,.5)".*
If you define the gradient as interpolating from solid yellow to
transparent black, I'd expect that it *should* be semi-transparent
blackish-yellow in the middle.
If you want it to be pure yellow, don't use a keyword which is
explicitly specified as transparent black - define the gradient from
rgba(255,255,0,1) to rgba(255,255,0,0) instead. Then you'll get
rgba(255,255,0,0.5) in the middle.
The rest of the platform has switched to using premultiplied colors
for interpolation, because they react better in cases like this**.
CSS transitions and CSS gradients now explicitly use premultiplied
colors, and SVG ends up interpolating similarly (they don't quite have
the same problem - they track opacity separate from color, so
transitioning from "color:yellow;opacity:1" to
"color:yellow;opacity:0" gives you "color:yellow;opacity:.5" in the
middle, which is the moral equivalent of "rgba(255,255,0,.5)").
That sounds like SVG gradients *can't* be using premultiplied colours.
A transition from "color:yellow;opacity:1" to "color:black;opacity:0"
will have rgba(127,127,0,0.5) in the middle, and it's impossible to
get that if you are using premultiplied colours. You'd have to have
A=1 at the start and A=0 at the end, so (with premultiplied colour)
the end would be interpreted as rgba(0,0,0,0), so you'd get the same
as interpolating to "color:yellow;opacity:0" (i.e. rgba(255,255,0,0.5)
in the middle), which is not what SVG does.
http://www.w3.org/TR/SVGTiny12/painting.html#Gradients says explicitly
its behaviour is the non-premultiplied behaviour we currently get with
canvas. ("gradient from fully transparent red, via partly transparent
dark yellow, to fully opaque lime" - the RGB components of fully
transparent colours are preserved.)
Maybe CSS should have originally used the keyword "transparentblack"
instead of "transparent" (though the distinction didn't matter before
gradients existed) - changing the gradient algorithm solely to work
more intuitively when people happen to use that one particular
incorrectly-named keyword seems backwards, and a mistake in CSS.
(Perhaps CSS gradients could avoid this problem by overriding the
meaning of the "transparent" keyword, so that instead of rgba(0,0,0,0)
it means A=0 with the mean RGB of the adjacent colour stops. That
would let it work as people naturally expect when they use that
keyword, and they can use the rgba() syntax if they really want
transparent black or transparent yellow or transparent red etc.)
The people at Opera responsible for the graphics layer agree with Philip's
point of view. They also pointed out we do support rgba() in SVG.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Server-Sent Events parsing issue
On Thu, 14 Oct 2010 14:23:41 +0200, ATSUSHI TAKAYAMA wrote: On Wed, Oct 13, 2010 at 10:00 AM, Anne van Kesteren wrote: On Tue, 12 Oct 2010 06:41:59 +0200, ATSUSHI TAKAYAMA wrote: It's a minor error in the spec in the Server-Sent Events spec. http://dev.w3.org/html5/eventsource/#event-stream-interpretation When processing a line with only "data:", the data buffer will be the empty string and the LF character added at the "process the field" stage. When dispatching the event, the first step "If the data buffer is an empty string, set the data buffer and the event name buffer to the empty string and abort these steps." does not apply here (since we have the LF character, which will be removed in the step 2). So it does fire a MessageEvent with an empty string as the data property. I think the steps 1 and 2 of the dispatching should be the other way round. Why would we not want to dispatch an event where data is the empty string in this case? I do not think this is an error. (Although admittedly I once thought it was.) Well, in that case the example should be re-written: = http://dev.w3.org/html5/eventsource/#event-stream-interpretation The following stream fires just one event: data data data data: The first and last blocks do nothing, since they do not contain any actual data (the data buffer remains at the empty string, and so nothing gets dispatched). The middle block fires an event with the data set to a single newline character. Maybe you are right and the specification is wrong (and the example is correct). http://tc.labs.opera.com/apis/EventSource/format-field-data.htm (this is written against the example; passes in Opera, fails in WebKit) I don't really mind which way we go here I think. = up to here It's slightly out of topic, but what's the idea behind making a line without a semicolon make the whole line the "field"? The 3 out of 4 possible "field" names, "event", "id" and "retry" make no sense without the value. Also "data" line without any message seems useless to me, and even if you do want it without a message "data:" does the job. Maybe this should be tightened up indeed. I can update the test suite either way. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Clarification request on Server-Sent Events Last-Event-ID
On Fri, 12 Nov 2010 23:53:51 +0100, Nicholas Zakas wrote: Just a quick question about the Last-Event-ID header. The spec currently says: If the event source's last event ID string is not the empty string, then a Last-Event-ID HTTP header must be included with the request, whose value is the value of the event source's last event ID string, encoded as UTF-8. Consider the following scenario: a connection is established and one of the events has an id of "foo", so the last event ID of the event source is now "foo". The connection drops and on reconnect, the header Last-Event-ID: foo is sent per the spec. The next stream of events coming through do not have any IDs. The connection is dropped again. The question is whether or not Last-Event-ID: foo should be sent a second time? Technically, it is the last event ID of the event source, and the spec never mentions resetting the last event ID outside of an empty "id" field in the stream. WebKit and Opera both match the specification here. I have added a testcase for this behavior: http://tc.labs.opera.com/apis/EventSource/format-field-id-2.htm You can get the source code for the tests here: http://tc.labs.opera.com/svn If you want to contribute more tests following this style. Let me know! -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 21:04:37 +0100, Jonas Sicking wrote: I agree that unless we get other groups in on this change, and get things like SVG cross-references and CSS styling reacting to these id and class-list changes, then we're just making things more confusing by making the DOM pretend that the class changed, when no other systems agree. Well yes, obviously .class notation, #id, etc. would all have to remain functioning. To me it makes sense to define ID/class-ness at the DOM level. CSS operates on that level too. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 20:06:02 +0100, Boris Zbarsky wrote: On 11/23/10 2:02 PM, Anne van Kesteren wrote: So if I set Element.className on an element that is not in a namespace and has no attributes. Its attributes collection remains empty or something? Hmm. I would think this should throw (since this won't do what you expect; e.g. CSS selectors and getElemetsByClassName won't start matching it). I would much rather just make it work. Otherwise moving it to Element does not really seem right. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 19:48:03 +0100, Boris Zbarsky wrote: On 11/23/10 12:58 PM, Anne van Kesteren wrote: So that you do not need namespace knowledge. Namespace knowledge where? As an implementor? Or as an author? Either? The whole point if a universal .classList and .className is to make authors not have to deal with namespace knowledge, imo. And it doesn't require mapping to a specific attr name for that. So if I set Element.className on an element that is not in a namespace and has no attributes. Its attributes collection remains empty or something? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 18:50:06 +0100, Jeff Schiller wrote: While we're on the topic of commonizing things at Element - can we introduce an 'inner' property on Element? This would map to innerHTML for HTMLElements. Other languages could introduce parsing rules for getting/setting that property. Presumably XML grammars would use the rules at http://dev.w3.org/html5/spec/apis-in-html-documents.html#innerhtml http://html5.org/specs/dom-parsing.html It's simply called Element.innerHTML. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 18:37:51 +0100, Boris Zbarsky wrote: On 11/23/10 12:20 PM, Anne van Kesteren wrote: My plan is to define Element.id, Element.className, Element.classList, and getElementsByClassName in DOM Core. And tie getElementById to Element.id somehow, tie Element.id to an attribute named "id", and Element.className to an attribute named "class". Why do we want to tie .className to a particular attribute name? I agree it may not be that convenient for authors if a particular language wants to use some other attr name for classes, but presumably they'd have really good reasons for doing that if they do it at all? So that you do not need namespace knowledge. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] need a way to set output format from StreamRecorder
On Fri, 19 Nov 2010 19:50:42 +0100, Per-Erik Brodin wrote: We are about to start implementing stream.record() and StreamRecorder. The spec currently says that “the file must be in a format supported by the user agent for use in audio and video elements” which is a reasonable restriction. However, there is currently no way to set the output format of the resulting File that you get from recorder.stop(). It is unlikely that specifying a default format would be sufficient if you in addition to container formats and codecs consider resolution, color depth, frame rate etc. for video and sample size and rate, number of channels etc. for audio. Perhaps an argument should be added to record() that specifies the output format from StreamRecorder as a MIME type with parameters? Since record() should probably throw when an unsupported type is supplied, it would perhaps be useful to have a canRecordType() or similar to be able to test for supported formats. But if we want interoperability for streams, also taking into account P2P messaging, we need a single format. Otherwise users with different browsers could end up not being able to communicate. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Fri, 19 Nov 2010 17:34:29 +0100, Boris Zbarsky wrote: Given that SVG also has classes, it would make some sense to move classList from HTMLElement to Element. That way SVG, and any other languages that define classes (XUL comes to mind, actually) can benefit from it as well. Note that Gecko's current classList implementation lives on Element. My plan is to define Element.id, Element.className, Element.classList, and getElementsByClassName in DOM Core. And tie getElementById to Element.id somehow, tie Element.id to an attribute named "id", and Element.className to an attribute named "class". -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] DOMTimeStamp in W3C Core 3
On Tue, 23 Nov 2010 15:29:00 +0100, John Knottenbelt wrote: Do you know where i can find the WebIDL spec that mentions DOMTimeStamp? I couldn't find a reference to it in http://www.w3.org/TR/2010/WD-WebIDL-20101021/ . http://dev.w3.org/2006/webapi/WebIDL/#common-DOMTimeStamp I wonder why the TR/ version does not include a link there. TR/ is almost always out of date. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] DOMTimeStamp in W3C Core 3
On Tue, 23 Nov 2010 11:52:12 +0100, John Knottenbelt wrote: Can anybody hazard a guess as to when the DOM Level 3 TR might be updated with this change? DOMTimeStamp is now defined in Web IDL. DOM Core is now http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Constraint validation feedback (various threads)
On Tue, 16 Nov 2010 16:04:08 +0100, Mounir Lamouri wrote: There is a LinkedIn form broken because of that: there are two fields with a non-HTML5 placeholder (ie. it's the value) which is set with .value="something" but the field has a maxlength set to 4 (it's a year). With a checkbox checked, one of this field will be hidden, with a value greater than the maxlength making the form always invalid. Actually, that specific problem was addressed long ago based on feedback from us: "Constraint validation: If an element has a maximum allowed value length, and its dirty value flag is true, and the code-point length of the element's value is greater than the element's maximum allowed value length, then the element is suffering from being too long." The "dirty value flag" is only true when the user has edited the control. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Encrypted HTTP and related security concerns - make mixed content warnings accessible from JS?
On Fri, 12 Nov 2010 23:02:16 +0100, Ingo Chao wrote: An event that says 'something was loaded insecurely' would be helpful. No need to report the URL, and no need to have the ability to prevent the loading in the first place. The bug reporting tool of the mashup page would inform me that the mixed content warning event was fired. These issues have to be investigated manually in any case. Maybe this is something that should be warned for in the error console instead then? Why does this need to be an API exposed to the web? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] question on @width and @height attributes on
On Mon, 08 Nov 2010 14:16:35 +0100, Simon Pieters wrote: On Mon, 08 Nov 2010 08:27:30 +0100, Silvia Pfeiffer wrote: seems to share the same fate, such that I am confused whether a percentage value on @width and @height attributes on are not allowed any more either. has the same rules as . The width/height IDL attributes are quite special. So those do not exactly match I think. The ones for probably need some rewording now they are no longer strings. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Exposing filenames in DataTransfer
On Thu, 21 Oct 2010 02:20:57 +0200, Daniel Cheng wrote: To clarify, I wasn't proposing that pages need to know details of a particular OS. Things like "text/plain", "text/uri-list", "text/html", etc. are automatically mapped by the UA to whatever the appropriate platform idiom is. I just thought it would be useful to also expose things that the UA itself doesn't natively understand--it just gets passed through to the web content. I was saying that if you get this on one OS but not another you might get pages that depend on a particular OS if not coded carefully. However, this led to the above problem with filenames being exposed. This can, to some extent, be mitigated by blacklisting certain types; I'm just wondering if people feel that the additional utility is worth the risk of potentially exposing file paths because of a chatty file manager, or if anyone has any ideas on how to mitigate this risk. It should probably work with a whitelist. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On Fri, 22 Oct 2010 23:07:47 +0200, Jonas Sicking wrote: Actually, pages like gmail needs and uses the whole string "Aryeh Gregor ", so you don't want to strip it down to just the email address. I suspect that we'll end up having to support this format of email addresses too, either as another @type value, or using some opt-in boolean attribute. Yeah, it was supported in the past I think. I forgot why support was dropped. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On Fri, 22 Oct 2010 23:09:41 +0200, Jonas Sicking wrote: On Fri, Oct 22, 2010 at 2:57 AM, Anne van Kesteren wrote: I do not really get why it being comma-separated is not just the submission format. The UI could be quite different. E.g. on the iPhone email client it is more like an inline list. I think the specification is simply not abstract enough here, as it is for the other controls. FWIW, it's not just a submission format, but also a JS format since .value returns a comma-separated list too. Sure, I would expect the way it is serialized for submission and for .value to be the same. I would not expect any whitespace there either. The way it is currently defined does not make much sense to me and seems to assume a particular UI. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On Fri, 22 Oct 2010 19:44:42 +0200, Boris Zbarsky wrote:
On 10/22/10 1:25 PM, Garrett Smith wrote:
What is wrong with splitting on comma, e.g.
var validAddressList = inp.value.split(",");
That depends on what meaning of "email address" is used here. Is:
"Zbarsky, Boris"
a valid "email address"?
Not per HTML5.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Make "f...@bar.com, " a valid email address list
On Thu, 21 Oct 2010 15:31:04 +0200, Mounir Lamouri wrote: For the moment, a valid email address list is a set of comma-separated tokens where each tokens are a valid email address so in the case of "f...@bar.com, ", "f...@bar.com" is a valid email address but not "". I do not really get why it being comma-separated is not just the submission format. The UI could be quite different. E.g. on the iPhone email client it is more like an inline list. I think the specification is simply not abstract enough here, as it is for the other controls. Unfortunately, as soon as you want to put a UI on top of that, values will always be appended by ", ". Indeed, a comma have to be added to mark that the user is now editing another email address so the UI can suggests new ones. Without adding the comma automatically, the user would have to add it by hand to have the UI suggesting new entries. So, if we do not fix the specifications, all multiple> with a UI will be whether invalid or really annoying to implement. You can found an example of that kind of UI in GMail. I think we should change the specifications so an email address list will be valid if it's ending with a comma (plus trailing whitespaces). In other words, if a list of email address have more than one token, the last one can be the empty string. We are thinking of implementing this change in Gecko 2.0 so feedback are very welcome. I think it would be better to simply omit that trailing comma. Which should be allowed. If the specification currently does not allow that (somehow) it would be a bug and is just something that needs clarification. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Server-Sent Events and CORS
On Tue, 19 Oct 2010 21:24:25 +0200, Nicholas Zakas wrote: IMHO, CORS really needs to be included as part of any implementation so that this can be used at scale. Otherwise, developers would be forced to use an iframe/postMessage() mechanism to work around the same origin policy. Are there any plans to formally include CORS in the spec? Yes. As soon as CORS for XMLHttpRequest is more widely deployed we'll start to introduce it elsewhere in the platform. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Exposing filenames in DataTransfer
On Tue, 19 Oct 2010 00:15:27 +0200, Daniel Cheng
wrote:
Sorry, I'm using "properties" as a generic term for different types of
data that might be set in a drag. A lot of file managers try to be
helpful and
populate alternative metadata for a file. Some of this metadata contains
file system paths. If the web dragging clipboard mirrors the native
dragging clipboard, then the metadata will be visible to web apps. In
this example, if you were on Linux with my patch, you could call
event.dataTransfer.getData("x-special/gnome-icon-list") while handling a
drop and the returned string would contain the file system path.
It seems wrong to expose it in a way native to a particular operating
system so it seems better to filter it out for now even if that is more
work. We should keep web platform APIs OS-independent.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Question regarding event: in server-sent events
On Mon, 18 Oct 2010 19:38:46 +0200, Nicholas Zakas wrote: Just for my own understanding, what you're saying is: 1) Any event name in the stream must be a valid event name in that it must not have spaces, special characters, etc. (The wording in the spec made me think that it must be an event name that is listed in the DOM Events spec, such as click.) Yes, although it is not clear whether per the current DOM Events specification an event name with a space would be invalid. 2) When you define an custom event name, this still fires the message event with event.type set to the custom event name. Well, it dispatches an event that uses the MessageEvent interface. But e.g. a function attached to onmessage will not be invoked, as the event is not named message, but something else. So you need obj.addEventListener(customEvent, ...). -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Question regarding event: in server-sent events
On Fri, 15 Oct 2010 20:34:14 +0200, Nicholas Zakas wrote: In reading through the spec, it looks like this is legal in the event stream: event: foo data: bar And then processed as: If the event name buffer is not the empty string but is also not a valid event type name, as defined by the DOM Events specification, set the data buffer and the event name buffer to the empty string and abort these steps. If I'm reading this correctly, an event name of "foo" would fail this step in the process and not cause a message event to be fired. However, if the event name were for example "click", then this would be okay and the following step would be taken: "foo" is a valid event type name. This would only fail when Event.initEvent(event name buffer, ...) fails. It seems per the current draft of DOM Events that will be never so maybe this ought to be reworded some. But then DOM Events is not done yet so... 3) Assuming I've understood the current spec correctly, what is the use case for named events? To make dispatching to different parts of the code easier. Without having to create some kind of logic that parses the data first. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] link.sizes and [PutForwards=value]
On Thu, 14 Oct 2010 15:46:30 +0200, Olli Pettay wrote: may I wonder why on earth any new API, like link.sizes uses PutForwards? IMHO, PutForwards should be limited to the awkward DOM0 APIs like window.location. What's wrong with PutForwards? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Server-Sent Events parsing issue
On Tue, 12 Oct 2010 06:41:59 +0200, ATSUSHI TAKAYAMA wrote: It's a minor error in the spec in the Server-Sent Events spec. http://dev.w3.org/html5/eventsource/#event-stream-interpretation When processing a line with only "data:", the data buffer will be the empty string and the LF character added at the "process the field" stage. When dispatching the event, the first step "If the data buffer is an empty string, set the data buffer and the event name buffer to the empty string and abort these steps." does not apply here (since we have the LF character, which will be removed in the step 2). So it does fire a MessageEvent with an empty string as the data property. I think the steps 1 and 2 of the dispatching should be the other way round. Why would we not want to dispatch an event where data is the empty string in this case? I do not think this is an error. (Although admittedly I once thought it was.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] self-closing tags in html5
On Sun, 26 Sep 2010 22:12:16 +0200, William F Hammond wrote: [Originally mailed to whatwg on Sat, 25 Sep 2010 22:24:49 -0400, but blocked from the list due to subscription troubles] Glad it worked out now! [...] For example, while it is true that major browsers seem to treat "" as an open tag, the relevant question for backward comptatibility is whether anyone has been relying on the idea that "" can be used to begin a non-empty paragraph. Indeed, and the answer has not changed since this email to public-html-comme...@w3.org: http://lists.w3.org/Archives/Public/public-html-comments/2010Sep/0022.html :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] self-closing tags in html5
On Sun, 26 Sep 2010 04:24:49 +0200, William F Hammond wrote: For example, while it is true that major browsers seem to treat "" as an open tag, the relevant question for backward comptatibility is whether anyone has been relying on the idea that "" can be used to begin a non-empty paragraph. Sites unfortunately do things like that so we cannot introduce this as a global syntax. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Propsal: Mechanism for converting rgb, hex, and named color strings between one another
On Wed, 22 Sep 2010 23:49:53 +0200, Daniel Buchner wrote: Thoughts? I think CSSColorComponentValue in the CSSOM should eventually get this ability. Discussion on CSSOM take mostly place on www-st...@w3.org. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Question about gradient stops in canvas and parsing as CSS colors
On Wed, 22 Sep 2010 16:47:02 +0200, Boris Zbarsky wrote: Clearly I happen to think Gecko's behavior is the sane one here, but there's a clear interoperability problem either way. Certainly Opera and Gecko interpreted the spec differently. Might be the way we invoke the CSS code. I think the Gecko behavior makes sense. Philip, can your test suite cover this? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Proposal: add attributes etags & last-modified to element.
On Mon, 20 Sep 2010 08:25:09 +0200, Julian Reschke wrote: Resources that should be cached (stylesheets, images) but change at unexpected times are indeed a problem. A well understood approach is to push some kind of version indicator into the URI (such as query parameter). Yeah, I was wondering why that was not acceptable here. (Using /script?v=1 etc. where /script?v=x has near-infinite caching.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] multipart/form-data when POSTing through an XMLHttpRequest (FileApi file)
On Fri, 17 Sep 2010 20:41:19 +0200, Dennis Joachimsthaler wrote: I do currently wonder, after a lot of hours of researching, if there is any possibility to upload files with values through XMLHttpRequest? The XmlHttpRequest just ends the request after the first "send". There should be a more thought out API for multipart/form-data since we have the new FileApi. Of course: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-formdata-interface Any suggestions? (Or, any knowledge how it is done today? I can't find anything about it! Crazy.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] ArrayBuffer and ByteArray questions
On Tue, 14 Sep 2010 21:13:46 +0200, Jian Li wrote: Yes, we only need to add it to BlobBuilder so that it can be applied to both FileReader, XHR.send and any other place that take the blob. send() takes everything straight as well. BlobBuilder should not be a prerequisite to transmit bytes, in my opinion. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Timed tracks: feedback compendium
On Tue, 14 Sep 2010 10:33:42 +0200, Philip Jägenstedt wrote: I don't know, do we need comments anywhere? Putting them between cues might work, but is that useful? Apart from text/plain I cannot think of a "web" text format that does not have comments. Validators should probably recommend against them for the next couple of years though, as only browsers would support that feature in the immediate future. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Interface of the readystatechange event
On Mon, 13 Sep 2010 16:33:01 +0200, Sergey Ilinsky wrote: I could not find information on what DOM Events interface does readystatechange event have. Can someone point me to where it is defined/mentioned? Where the specification defines it to be dispatched it says to "fire a simple event named readystatechange". The definition of "firing a simple event named e" says to use the Event interface. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Proposal: Make about:srcdoc resolvable on iframes containing a @srcdoc.
On Sun, 12 Sep 2010 17:13:28 +0200, Justin Schuh wrote: [...] Resolvable is a term the about URL scheme draft uses to determine whether a given about URL returns a resource or not when used somewhere. E.g. about:blank resolves to a text/html resource consisting of the empty string. That about:srcdoc does not resolve does not mean its browsing context cannot be navigated. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] The choice of script global object to use when the script element is moved
On Wed, 08 Sep 2010 11:20:30 +0200, Adam Barth wrote: The goal of AllowedScripts is not to limit a privilege to a subset of an origin. Rather, the goal is to prevent an attacker who can inject markup into a document from executing script. Put another way, if you're already executing script, then it's not trying to withhold any privileges. Fair enough. I guess if one page gets compromised all else that is same origin is lost anyway. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] The choice of script global object to use when the script element is moved
On Tue, 07 Sep 2010 22:57:27 +0200, Adam Barth wrote: It sounds like CSP is creating sub-origin privileges. Sub-origin privileges don't really work, so it's unclear to what a sensible result would be. This is a problem with your alternative CSP proposal as well, no? https://wiki.mozilla.org/Security/CSP/AllowedScripts It prevents a bunch of things, but when loaded in an iframe someone else on the same-origin can still inject a script of some sorts. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] ArrayBuffer and ByteArray questions
On Wed, 08 Sep 2010 01:09:13 +0200, Jian Li wrote: Several specs, like File API and WebGL, use ArrayBuffer, while other spec, like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same name all across our specs? Since we define ArrayBuffer in the Typed Arrays spec ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html), should we favor ArrayBuffer? In addition, can we consider adding ArrayBuffer support to BlobBuilder, FormData, and XMLHttpRequest.send()? So TC39 is going to leave this thing alone? I.e. are we sure ArrayBuffer is the way of the future? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, 31 Aug 2010 16:02:02 +0200, Tab Atkins Jr. wrote: Right. So a vendor shouldn't choose "data" as their prefix. I could imagine we get ariaset in the future and maybe others. But it is unlikely to be a big problem since there are so many prefixes to chose from. And experimental attributes should really be avoided and only be around for limited amount of time... -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Video with MIME type application/octet-stream
Devil's advocate. On Tue, 31 Aug 2010 15:40:18 +0200, Boris Zbarsky wrote: On 8/31/10 3:36 AM, Ian Hickson wrote: The Microsoft guys responded to my suggestion that they might want to implement something like this with "what's the benefit of doing that?". One obvious benefit is that videos with the wrong type will not work, and hence videos will be sent with the right type. If the question is what the benefits of that are, one is that the "view video in new window" context menu option actually works. If you sniff you can sniff there too. Another benefit is that you can send someone the link to the video, instead of the embedding page, and it will work. If you sniff you can sniff there too. (Unless that user uses a competitor's browser, but that would be an incentive to encourage that user to use the sniffing browser.) Another is that when you save the video to disk the browser will fix up the extension correctly, if needed. If you sniff you can fix it up correctly too. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Cache manifests and cross-origin resources
On Fri, 27 Aug 2010 22:15:17 +0200, Michael Nordman wrote: Resources from an origin different than the manifest's origin will be cached, but they will never be used to satisfy a a frame navigation. They're only eligible to be loaded as subresources into pages/workers that are associated with the cache containing those resources. Thanks. We currently have a same-origin restriction in place for explicit entries, but will update to match the specification. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] XMLHttpRequest and HTML5
Thanks for the changes, some comments below. On Tue, 31 Aug 2010 01:58:52 +0200, Ian Hickson wrote: On Sat, 7 Aug 2010, Anne van Kesteren wrote: 2) Is there any reason we cannot also use this "no browsing context" clause to define document.cookie rather than having a special type of Document object? Seems much better. Since the spec is already written... I can see cases where you could have a Document that had no browsing context but did have cookies. So... But there are no such cases currently. It would be nicer if the special casing was the other way around so XMLHttpRequest did not have to say anything. (And Web DOM Core when it is written.) 4) I could not test Internet Explorer but so far only WebKit exposes document.domain in XMLHttpRequest and it does not throw on getting and on setting it throws a SECURITY_ERR (not INVALID_STATE_ERR). If we align with document.cookie as suggested above maybe this should align too and getting should return the empty string and setting should be ignored. Done. I guess throwing is fine too. 5) I think we want to ban document.lastModified too. At least for cross-origin requests and the way we did it elsewhere was to then ban it for same-origin as well. (The HTTP header can be read instead. It also does not seem like a huge loss.) What's wrong with exposing document.lastModified? I guess nothing. Last-Modified is safe. 6) If you provide some hook or tell me how to do it I can define the origin of the Document returned by responseXML in XMLHttpRequest. HTML already defines this. Or do you mean we should move that to the XHR spec? That is what I meant, yes. If we can do all this that should turn it into a one-way dependency with most definitions being completely self-contained. I'm not sure it's worth it in the case of the origin thing. So what happens when we define how to get a Document out of a File? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Mon, 30 Aug 2010 14:35:03 +0200, L. David Baron wrote: But the problem with adding a new general selectors feature is that authors will discover it and try to use it for things that aren't ok being ASCII-only. Yeah, maybe. But we could define it as some kind of token feature. As far as I know we do not have any markup languages which use compatibility caseless tokens. And hopefully we are not going to introduce any either. Alternatively you could have something like input:type(password) I suppose. Would work slightly better for unknown controls that fallback to text, too. Or even more alternatively we could decide not to care about this being difficult to select since in practice people will use lowercase values. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Sun, 29 Aug 2010 15:01:27 +0200, L. David Baron wrote: On Wednesday 2010-08-25 10:28 +0200, Anne van Kesteren wrote: We need a feature for case-insensitive matching in Selectors already for XHTML (if we really care about this, not sure we do). Allowing case-insensitive matching beyond matching of a fixed set of ASCII-only values seems scary. If such a general selectors feature were defined as ASCII-only, then it would appear to work but then break for cases where it needed to be more than ASCII-only (or where the standard ASCII-only algorithm is incorrect, such as Turkish, where where I/i are not case-equivalents; İ/i and I/ı are). If it weren't ASCII-only, it would involve significantly more complexity than what's needed to support HTML. I think it can be ASCII-only. You "need" it for input[type=password] and such. The only attributes that are currently "compatibility caseless" are name on and name on . -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] oninput for contentEditable
On Sat, 28 Aug 2010 03:16:16 +0200, Ojan Vafai wrote: WebKit has added the input event to contentEditable nodes. That part of this proposal seemed non-controversial. Do other browser vendors support changing the description of this event to apply to contentEditable nodes as well? Yeah, seems like a good idea. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Cache manifests and cross-origin resources
With the current model makingyourinterwebsboring.com can define a cache manifest and basically point to a lot of external news sites. When any of those sites is then fetched directly they would be taken from the cache. That does not seem optimal. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Validator.nu Bug: "Error: XHTML element noscript not allowed as child of XHTML element head in this context."
On Fri, 27 Aug 2010 11:10:44 +0200, Hugh Guiney wrote: I am using noscript as permitted, "In a head element of an HTML document, if there are no ancestor noscript elements." but still getting an error from Validator.nu saying it's not allowed. is HTML-only. I.e. not allowed in XHTML. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] base64 entities
On Thu, 26 Aug 2010 22:30:00 +0200, Julian Reschke wrote: I now get the point about the additional problems in script, but I fail to see how the proposal addresses this, unless expanding these entities is suppose to happen *after* parsing the script. If you have ele.innerHTML = '&%;' inside it would be expanded the moment innerHTML is invoked </tt><tt>(inside script entities are not expanded) and thus be safe from </tt><tt>"" injection and such. So yes, it happens after. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On Thu, 26 Aug 2010 02:28:49 +0200, Chris Double wrote: On Thu, Aug 26, 2010 at 5:25 AM, Eric Carlson wrote: FWIW, I agree with Silvia that a new file extension and MIME type make sense. I also think that a new file extension and MIME type is the way to go. Would Firefox / Safari support text/srt files in some undocumented fashion then or just simply not support those? The former would not really be an acceptable solution to me. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Wed, 25 Aug 2010 09:44:34 +0200, Christoph Päper wrote: I for one would expect that selector to match that element, although I would never write HTML like that. Imagine a browser or user stylesheet where you would effectively have to list all possible casings. We need a feature for case-insensitive matching in Selectors already for XHTML (if we really care about this, not sure we do). -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Wed, 25 Aug 2010 01:00:50 +0200, Ian Hickson wrote: On Thu, 29 Jul 2010, Anne van Kesteren wrote: On Wed, 28 Jul 2010 01:32:13 +0200, Ian Hickson wrote: > I've been working under the assumption that we want to eradicate as > many differences between XHTML and HTML as possible, and that there's > virtually no compatibility constraint on the XHTML side. > > If this is an area where we should keep the differences, though, I'm > quite happy to change the spec accordingly. > > Do any other browser vendors have opinions here? Are there > compatibility constraints I'm not aware of? I still think we should make matching on values always case-sensitive, including in HTML. Does that not have compatibility problems? e.g. I'm sure people do: ... Sure, but I highly doubt people do that and expect p[align=center] to work, especially since that has not always worked in all browsers. (Other than some popular Selectors test suite.) To clarify, what I meant to say is that I still think matching on attribute values in Selectors for HTML should always be case-sensitive and we should not have a magic list. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, 17 Aug 2010 20:40:20 +0200, Tab Atkins Jr. wrote: Is this supposed to be a general policy? We couldn't determine whether to go with or without dashes when naming an attribute in the bidi meeting a few months ago - current practice seems to go both ways, from a trawl of the attribute index. Yeah, see e.g. the various form* attributes, autofocus, item* attributes. The only new attribute I can think of with a dash is data- and that's a special case. Elements have no dashes at all. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] scrollIntoView()
On Tue, 17 Aug 2010 13:53:59 +0200, Olli Pettay wrote: What is your testcase here? I was looking at the code and seems like scrollToView is sync in Gecko. And a simple testcase showed that window.scrollY was updated right after the method call. (note, scroll events aren't sync). I was talking about the events. They are synchronous in WebKit as far as I can tell. I'm happy to define them as asynchronous though. Being compatible with Gecko seems better. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] scrollIntoView()
Ian has suggested several times so far that I take over editing of the scrollIntoView() method and define it in the CSSOM View Module: http://dev.w3.org/csswg/cssom-view/ I agree that is a more appropriate place. I played around with it a little and it seems that in browsers other than Opera invoking the method affects the scrolling position of ancestor documents. I.e. if you have a document in an iframe where scrollIntoView() is invoked on an element not only will that document scroll, but the document the iframe is in will scroll as well. In addition this will dispatch events to each document object of which the document is scrolled, and any elements that are scrolled in the process (the order is innermost-outermost, and sync in Webkit, async in Gecko, afaict). I was wondering whether this should happen cross-origin as well. That seems like a minor leak of some sorts. And if that should happen, should the sandbox="" attribute disable it? Cheers, -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, 17 Aug 2010 06:32:33 +0200, Robert O'Callahan wrote: On Tue, Aug 17, 2010 at 4:05 PM, Ian Hickson wrote: Hmm, good point. Any other suggestions? Mozilla has already added a number of extensions using just a "moz" prefix ... e.g. mozInnerScreenX, mozPaintCount, mozRequestAnimationFrame. Webkit has added extensions using a "webkit" prefx ... e.g. webkitDisplayingFullscreen. In theory I guess that pattern could conflict with new features. But in practice it doesn't seem likely unless new engines enter the market and choose prefixes poorly. (I.e., don't choose a prefix that matches an English verb or noun.) Note that this is for element attributes, not interface members. Having said that, vendor-name (i.e. a single dash) is probably sufficient. It seems highly unlikely we will ever use webkit-, ms-, o-, gecko- as an attribute name. In fact, iirc we follow the policy that new attribute names will not have hyphens in them, unless it is for some kind of pattern (like data-). -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Bluetooth devices
On Mon, 16 Aug 2010 20:03:14 +0200, Don Rosen wrote: Is there any intention to provide access to Bluetooth devices through the Device element? We do not really have a clear roadmap for this feature. It very much depends on what web authors and implementors want to do with it. But e.g. external hard drives are being considered and whether that goes over Bluetooth or USB will hopefully be transparent to the API. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Proposal: Add HTMLElement.innerText
On Mon, 16 Aug 2010 11:23:55 +0200, Maciej Stachowiak wrote: We do consider this, but since the status quo is "every browser but Firefox implements it", it's not clear that flipping WebKit-based browsers from one column to the other is a genuine interoperability improvement. Nor does it seem clear that changing all other browsers to match the odd man out is even the best overall strategy to getting there. We would need to get a very solid definition for it though as it is not at all implemented in the same way. http://software.hixie.ch/utilities/js/live-dom-viewer/ ...test w(encodeURI(document.body.innerText)) Opera does not use a newline for set to display:block and includes (contrary to e.g. Chrome) the contents of the
Re: [whatwg] Proposal: Add HTMLElement.innerText
On Sun, 15 Aug 2010 08:30:28 +0200, Adam Barth wrote: On Sat, Aug 14, 2010 at 11:18 PM, Robert O'Callahan wrote: On Sun, Aug 15, 2010 at 6:16 PM, Robert O'Callahan wrote: Wouldn't you consider the interoperability benefits to the Web platform? Not to mention the benefit of simplifying the platform a tiny bit by removing a feature which mostly duplicates another much more well-known feature. I'm all for interoperability, but who's going to twist Microsoft's arm to remove the feature from IE? If nobody else supports it they might remove it too. Maybe hidden behind people using a standards DOCTYPE, but that is something at least. As far as simplifying the platform, innerText is but one grain of sand on the beach. There's not quite that many APIs :-) I personally think it's worth it to try cut down on legacy features when we can. Even if it's only one feature at a time. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Appcache feedback (various threads)
On Fri, 13 Aug 2010 15:02:01 +0200, Patrick Mueller wrote: On 8/12/10 6:29 PM, Ian Hickson wrote: On Thu, 29 Jul 2010, Anne van Kesteren wrote: XML would be much too complex for what is needed. We could possibly remove the media type check and resort to using the "CACHE MANIFEST" identifier (i.e. "sniffing"), but the HTTP gods will get angry. Yeah, that's pretty much the way it is. Although I haven't personally had a problem dealing with the content-type requirement, I have heard from at least one other colleague who did; their server was harder to configure. I had assumed the reason for having the specific text/cache-manifest content type was to force people to "opt-in" to support, instead of being able to just read a random URL and having it interpreted, perhaps maliciously, as a manifest. If that's not a concern, then I'd like to understand the ramifications of getting the HTTP angry gods angry by ignoring the content-type. In HTTP (starting HTTP/1.0), entity bodies are identified by the Content-Type header, not by themselves. We violate that for a number of scenarios, but we try to stay clear of it in new, until such time comes that we give up completely on Content-Type. It's a compromise. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] HTML5 (including next generation additions still in development) - Mozilla Firefox (Not Responding)
On Thu, 12 Aug 2010 14:24:10 +0200, Mike Wilcox wrote: I'm perplexed at the resistance. We've tried telling our clients not to use IE6, "IE8 is much faster". But inevitably, we have to make it work. This is not nytimes.com. There's http://whatwg.org/html and http://whatwg.org/C available for people with slow connections/browsers. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Iframe dimensions
On Wed, 11 Aug 2010 19:03:28 +0200, Adam Barth wrote: On Wed, Aug 11, 2010 at 8:05 AM, Markus Ernst wrote: A solution at authoring level for cases where the author controls both pages would be quite helpful. I think of a meta element in the embedded document that specifies one or more domains that are allowed to embed it seamlessly in an iframe, such as e.g.: I think that this would be ok from a security POV, and much easier than using CORS. That feels like re-inventing CORS. Maybe we should make CORS easier to use instead? What exactly is hard about it? (Though I should note we should carefully study whether using CORS here is safe and sound. For instance, you may want to allow seamless embedding, but not share content.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On Wed, 11 Aug 2010 15:09:34 +0200, Silvia Pfeiffer wrote: HTML and CSS have predefined structures within which their languages grow and are able to grow. WebSRT has newlines to structure the format, which is clearly not very useful for extensibility. No matter how we turn this, the xml background or HTML and the name-value background of CSS provide them with in-built extensibility, which WebSRT does not have. The parser has the "bad cue loop" concept for ignoring supposedly bogus lines. Seems extensible to me. Sure, that's why the tools should be updated to support the standard format instead rather than each having their own variant of SRT. They don't have their own variant of SRT - they only have their own parsers. That comes down to the same thing in my opinion. This is like saying browsers did not all have their own variant of HTML4. Some will tolerate crap at the end of the "-->" line. Others won't. That's no break of "conformance" to the basic "spec" as given in http://en.wikipedia.org/wiki/SubRip#SubRip_text_file_format . They all interoperate on the basic SRT format. But they don't interoperate on the WebSRT format. That's why WebSRT has to be a new format. By that reasoning HTML5 would have had to be a new format too. And CSS 2.1 as opposed to CSS 2, etc. (And if they really just take in text like that they should at least run some kind of validation so not all kinds of garbage can get in.) That's not a requirement of the "spec". It's requirement is to render whatever characters are given in cues. That's why it is so simple. But it is not so simple because various extensions are out there in the wild and are used so the concerns you have with respect to WebSRT already apply. Sure. All I need to do is rename the file. Not much trouble at all. Better than believing I can just copy stuff from others since it's apparently the same format and then it breaks the SRT environment that I already have and that works. At least with the copy approach you would still see something in your SRT environment. The bits would just be ignored or some such. That's already part of Ian's proposal: it already supports multiple different approaches of parsing cues. No extra complexity here. Actually that is not true. There is only one approach to parsing in Ian's proposal. A the moment, cues can have one of two different types of content: (see http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#syntax-0 [...] So that means in essence two different parsers. Per the parser section there is only one. See the end of http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#parsing-0 -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On Wed, 11 Aug 2010 13:35:30 +0200, Silvia Pfeiffer wrote: On Wed, Aug 11, 2010 at 7:31 PM, Anne van Kesteren wrote: While players are transitioning to WebSRT they will ensure that they do not break with future versions of the format. That's impossible, since we do not know what future versions will look like and what features we may need. If that is impossible it would be impossible for HTML and CSS too. And clearly it is not. I'm pretty sure that several will break. We cannot just test a handful of available applications and if they don't break assume none will. In fact, all existing applications that get loaded with a WebSRT file with extended features will display text with stuff that is not expected - in particular if the "metadata" case is used. And wrong rendering is bad, e.g. if it's part of a production process, burnt onto the video, and shipped to hearing-impaired customers. Or stored in an archive. Sure, that's why the tools should be updated to support the standard format instead rather than each having their own variant of SRT. (And if they really just take in text like that they should at least run some kind of validation so not all kinds of garbage can get in.) I don't think so. It just makes things more complex for authors (learn two formats, I see that as an advantage: I can learn the simple format and be off to a running start immediately. Then, when I find out that I need more features, I can build on top of already existing knowledge for the richer format and can convert my old files through a simple renaming of the resources. Or could you learn the simple format from a tutorial that only teaches that and when you see someone else using more complex features you can just copy and paste them and use them directly. This is pretty much how the web works. have to convert formats (i.e. change mime) in order to use new features (which could be as simple as a fragment for some Japanese track) If I know from the start that I need these features, I will immediately learn WebSRT. But you don't. , more complex for implementors (need two separate implementations as to not encourage authors to use features of the more complex one in the less complex one), more complex for conformance checkers (need more code), etc. Seems highly suboptimal to me. That's already part of Ian's proposal: it already supports multiple different approaches of parsing cues. No extra complexity here. Actually that is not true. There is only one approach to parsing in Ian's proposal. My theory is: we only implement support for WebSRT in the browser - that it happens to also support SRT is a positive side effect. It works for the Web - and it works for the existing SRT communities and platforms. They know they have to move to WebSRT in the long run, but right now they can get away with simple SRT support and still deliver for the Web. And they have a growth path into a new file format that provides richer features. This is the proposal. That they are the same format should not matter. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On Wed, 11 Aug 2010 10:30:23 +0200, Silvia Pfeiffer
wrote:
On Wed, Aug 11, 2010 at 5:04 PM, Anne van Kesteren
wrote:
That is the approach we have for most formats (and APIs) on the web
(CSS, HTML, XMLHttpRequest) and so far a version identifier need (or
need for a replacement) has not yet arisen.
There are Web formats with a version attribute, such as Atom, RSS and
even HTTP has a version number.
None of these have really executed a successful version strategy though.
Syndication in particular is quite bad, we should learn from that.
See e.g. http://diveintomark.org/archives/2004/02/04/incompatible-rss
Also, I can see that structured formats with a
clear path for how extensions would be included may not need such a
version
attribute. WebSRT is not such a structured format, which is what makes
all the difference. For example, you simply cannot put a new element
outside the root element in XML, but you can easily put a new element
anywhere in WebSRT - which might actually make a lot of sense if you
think e.g. about adding
SVG and CSS inline in future.
There is all kinds of ways we could address this. For instance, we could
add a feature that makes a line ignored and use that in the future for new
features. While players are transitioning to WebSRT they will ensure that
they do not break with future versions of the format. There might be
enough extensibility in the current WebSRT parsing rules for this, I have
not checked.
It doesn't take into account good practice in software development,
though, where there is a minor version number and a major version
number. A change of the minor version number is ignored by apps that
need to display
something - it just gives a hint that new features were introduced that
shouldn't break anything. It's basically metadata to give a hint to
applications where it really matters, e.g. if an application relies on
new features to be available. A change of major version number, however,
essentially means it's a new format and thus breaks existing stuff to
allow the world to move forwards within the same "namespace" and
experience
framework.
What works for software products does not work for formats with universal
deployment on which we want to get interoperability between various
vendors. They are very distinct.
But it is not complex at all and everyone else supports most of the
extensions the WebSRT format has.
All of the WebSRT extensions that do not exist in {basic SRT , , }
are not supported by anyone yet.
Existing SRT authoring tools, media players, transcoding tools, etc. do
not
support the cue settings (see
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-cue-settings),
or parsing of random text in the cues, or the voice markers. So, I
disagree with "everyone else supports most of the extensions of the
WebSRT format".
Do they throw an error or do they just ignore the settings? If the latter
it does not seem like a problem. If the former authors will probably not
use these features for a while until they are better supported.
Also, what I man with the word "complex" is actually a good thing: a
format that supports lots of requirements that go beyond the basic ones.
Thus, it's actually a good thing to have a simple format (i.e. SRT) and
a "complex"
(maybe rather: rich? capable?) format (i.e. WebSRT).
I don't think so. It just makes things more complex for authors (learn two
formats, have to convert formats (i.e. change mime) in order to use new
features (which could be as simple as a fragment for some Japanese
track), more complex for implementors (need two separate implementations
as to not encourage authors to use features of the more complex one in the
less complex one), more complex for conformance checkers (need more code),
etc. Seems highly suboptimal to me.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On Wed, 11 Aug 2010 01:43:01 +0200, Silvia Pfeiffer wrote: That's a good approach and will reduce the need for breaking backwards-compatibility. In an xml-based format that need is 0, while with a text format where the structure is ad-hoc, that need can never be reduced to 0. That's what I am concerned about and that's why I think we need a version identifier. If we end up never using/changing the version identifier, the better so. But I'd much rather we have it now and can identify what specification a file adheres to than not being able to do so later. XML is also text-based. ;-) But more seriously, if we ever need to make changes that would completely break backwards compatibility we should just use a new format rather than fit it into an existing one. That is the approach we have for most formats (and APIs) on the web (CSS, HTML, XMLHttpRequest) and so far a version identifier need (or need for a replacement) has not yet arisen. Might be worth reading through some of: http://www.w3.org/2002/09/wbs/40318/issues-4-84-objection-poll/results On Tue, Aug 10, 2010 at 7:49 PM, Philip Jägenstedt wrote: That would make text/srt and text/websrt synonymous, which is kind of pointless. No, it's only pointless if you are a browser vendor. For everyone else it is a huge advantage to be able to choose between a guaranteed simple format and a complex format with all the bells and whistles. But it is not complex at all and everyone else supports most of the extensions the WebSRT format has. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] XMLHttpRequest and HTML5
Ian, if you could tackle the following soonish that would be nice as I try to get the test suite for XMLHttpRequest together. 1) document.location returns null when there is no browsing context for the Document. document.defaultView needs this too. (It returns null in the implementations I tested.) 2) Is there any reason we cannot also use this "no browsing context" clause to define document.cookie rather than having a special type of Document object? Seems much better. 3) And document.domain too, maybe? (There is a difference here currently which is that document.domain just special cases XMLHttpRequest whereas the cookie-free Document object concept also applies to createDocument(). I suspect document.domain should have the same restrictions, but I am not sure. It would be nice however if document.domain did not have to reference XMLHttpRequest.) 4) I could not test Internet Explorer but so far only WebKit exposes document.domain in XMLHttpRequest and it does not throw on getting and on setting it throws a SECURITY_ERR (not INVALID_STATE_ERR). If we align with document.cookie as suggested above maybe this should align too and getting should return the empty string and setting should be ignored. 5) I think we want to ban document.lastModified too. At least for cross-origin requests and the way we did it elsewhere was to then ban it for same-origin as well. (The HTTP header can be read instead. It also does not seem like a huge loss.) 6) If you provide some hook or tell me how to do it I can define the origin of the Document returned by responseXML in XMLHttpRequest. If we can do all this that should turn it into a one-way dependency with most definitions being completely self-contained. Thanks, -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Feedback on the Mozilla FullScreen API proposal
On Fri, 06 Aug 2010 00:17:54 +0200, Simon Fraser wrote: or have some constants for behavior: const unsigned short ALLOW_KEYBOARD_INPUT = 1; void requestFullScreen(unsigned short behavior) This would be extensible, and would allow us to permit other behaviors later. Can't we use a string then -- a space-separated list of tokens? Constants are somewhat icky to use in JavaScript and here you would have to use some trickery if you would actually want to request several kinds of behaviors using a single constant in the future. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] appCache manifest file
On Thu, 29 Jul 2010 12:10:53 +0200, Zi Bin Cheah wrote: Why did we want to use a new file extension .manifest in appcache. Wouldn't it be better to to just use a XML file instead, one benefit is eliminating the requirement of specifying MIME type in .htaccess. XML would be much too complex for what is needed. We could possibly remove the media type check and resort to using the "CACHE MANIFEST" identifier (i.e. "sniffing"), but the HTTP gods will get angry. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r4949 - [giow] (0) The CSS rules need to do attribute value matching consistently across [...]
On Wed, 28 Jul 2010 01:32:13 +0200, Ian Hickson wrote: I've been working under the assumption that we want to eradicate as many differences between XHTML and HTML as possible, and that there's virtually no compatibility constraint on the XHTML side. If this is an area where we should keep the differences, though, I'm quite happy to change the spec accordingly. Do any other browser vendors have opinions here? Are there compatibility constraints I'm not aware of? I still think we should make matching on values always case-sensitive, including in HTML. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Timed tracks for
On Tue, 27 Jul 2010 13:40:32 +0200, Sam Dutton wrote: >> The addCueRange() API has been removed and replaced with a feature based on the subtitle mechanism. << I'm not sure what this means -- are you referring to timed track cues? This was an older API. You can find it in older W3C drafts or in subversion, e.g. http://www.w3.org/TR/2009/WD-html5-20090212/video.html#cue-ranges Also -- is trackgroup out of the spec? It was never in, as far as I know. :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Cross-origin opt-in for seamless iframes [was: Iframe dimensions]
On Wed, 07 Jul 2010 16:36:30 +0200, Markus Ernst wrote: I tried to read about CORS, but did not understand the whole of it. Can CORS be set up via server-side scripting, with PHP or whatever? Then it will be an acceptable solution, and sooner or later libraries will be available for both the server and the client side. If CORS must be set up by the server administrator, it will be a problem in shared hosting environments. Anyway, for something that looks as easy as allowing an iframe to seamlessly integrate a document, the overhead of server-side setup and client-side scripting looks huge to me, and it also has the downside of being dependent on Javascript. Dependent on JavaScript? Adding a header to a resource is not a huge overhead. (As an aside, even in shared hosting environments you can usually have complete control over what goes out. It's just more complicated. But it does not become less complicated if you have your own hosting environment either...) But this discussion is premature. We should first have a couple of implementations of seamless before we make things more complicated. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Resolutions meta tag proposal
On Tue, 06 Jul 2010 13:52:24 +0200, André Luís wrote: [...] i still prefer the way I suggested earlier, to make work like the other media tags: , with child elements that could have either a resolution="96" (per proposal of Roger) attribute or a media query... We cannot have child elements for . Content (legacy and new) constraints how is and will be parsed. Anyway, is it still time to have this conversation? Will additions to the spec be considered? Yes, though extensions to the element can be done independently from the specification. As a standalone specification. Since this Retina (high res screens) business is very new, there isn't much real-world usage to harvest proof of... but is there a process or a set of steps a proposal must go through? There is a somewhat informal process, yes: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F Personally I do not think detailed control is needed at all. It requires way too much configuration and hassle for little benefit. What Dave Hyatt outlined in http://webkit.org/blog/55/high-dpi-web-sites/ for the img element is good enough. I.e. always load the high resolution version and scale it down for "lesser" displays using height/width. Sure, some more bandwidth is used, but that is not a big deal, especially if you consider that the higher resolution version goes to the device with less bandwidth. So if bandwidth was a concern we would not be having this discussion. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] More YouTube response
On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan wrote: Well this isnt really a list where we should talk about the dos and donts of web content distribution. DRM content can be embedded in the video tag and decoded using installable plugins so its not really an issue for this list I dont think. We cant dictate how the specs are used so try to keep the conversation technology neutral. Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have in the first place. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Allowing ">" in attribute values
On Thu, 24 Jun 2010 04:13:56 +0200, Benjamin M. Schwartz wrote: The HTML5 spec appears to allow ">" inside an attribute value. For example, the following page (note the body tag) passes the experimental HTML5 validator at w3c.org: I think ">" should be disallowed inside attribute values. It is disallowed in XHTML [1]. It is disallowed in HTML 4.01 [2]. Disallowing it in HTML5 would avoid unnecessary divergence, and also sometimes simplify parsing. Why would it simplify parsing? It's rather nice to allow it for the feature. [1] according to the validator in XHTML 1.1 Strict mode. 'character ">" is not allowed in the value of attribute' [2] http://www.w3.org/TR/REC-html40/charset.html#h-5.3.2 "Similarly, authors should use ">" (ASCII decimal 62) in text instead of ">" to avoid problems with older user agents that incorrectly perceive this as the end of a tag (tag close delimiter) when it appears in quoted attribute values." It is also disallowed by the HTML 4.01 Strict validator. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Speech input element
On Tue, 15 Jun 2010 17:08:40 +0200, Satish Sampath wrote: To add a little more clarity - we initially proposed a speech input API using a new element. The top feedback we received was to extend speech as a form of input to existing elements instead of creating a new speech control. We have taken that into account in the new proposal which extends speech input to existing form elements and other editable elements. Please take a fresh look and share your thoughts. Could you maybe post a link to the proposal? Or in case you intended to attach it: it didn't get through. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] idea about html code security anti xss
On Wed, 16 Jun 2010 03:19:59 +0200, gabme...@westweb.at wrote: Please let me know what you think about this idea. We considered something like this before, but it was thought to be too complicated and not backwards compatible enough. In the current draft you will find which does what you propose with the relatively small change that the sandboxed code is inside an attribute rather than an element. For fallback the src attribute can be used. -- Anne van Kesteren http://annevankesteren.nl/
