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] Please consider adding a couple more datetime types - type="year" and type="month-day"
On Sun, 8 Aug 2010, Tantek �~Gelik wrote: > > the 6 new datetime types are quite useful for a variety of > use-cases but could use 2 more that fit in with the current set. > > In addition to current new absolute types of "date", "week", "month", it > makes sense to add type="year" as well for choosing a year value. Why? > And in addition to the current new relative type of "time", it makes > sense to add type="month-day" as well (for a inputting a month and a day > without a year, e.g. for a birthday without birth year, or for entering > custom annual holidays). Is this common? Do you have examples of pages doing this? On Mon, 9 Aug 2010, Kit Grose wrote: > > The field being four digits long doesn't restrict its contents to four > digits only. I suppose you do raise an interesting concern; should the > "year" field also permit the entry of BC/AD? If so, that might > invalidate the ability to use a number field; you'd need to use a > validation pattern on a standard text field. On Mon, 9 Aug 2010, Ben Schwarz wrote: > > While creating an input that works for every use case you can think of > sounds like a good idea, I'd like to question weather a user would ever > *enter a date* that would require the inclusion of BC/AD. It all depends on the use cases. Without use cases, there's no way to evaluate the proposals. On Mon, 9 Aug 2010, Brett Zamir wrote: > > How about a pull-down for Wikipedia which lets you choose the year or period? Doesn't wikipedia handle this fine today? > Or a charting application which looks at trends in history. Do you have any examples? > While some uses may be more common than others, I personally favor going > the extra kilometre to allow full expressiveness for whatever ranges are > allowed. Completeness is not a good design strategy. :-) You end up with lots of things that need implementing that are not well tested and end up being quite buggy. On Mon, 9 Aug 2010, Andy Mabbett wrote: > > It took only seconds to find: > >http://www.guernsey.net/~sgibbs/roman.html > > which requires (for some dates) entry of 1, 2, and 3-figure and BC > years. I couldn't figure out how to enter any BC years there. For AD years it seems to be fine -- and indeed, unless we provide a Julian calendar widget, that page would never be able to use our work anyway. It is well outside the 80% use case target. > Likewise: > >http://www.smart.net/~mmontes/ec-cal.html > >"Please enter a year after A.D. 325" This page seems to be fine as is; why would you need a new input control for this? On Mon, 9 Aug 2010, Marshall Eubanks wrote: > > What I would recommend is, in addition to the datetime input types, an > optional type= (e.g., type=""Gregorian"), which could be > ignored or used, as the circumstances required. It's not clear what this would do. Wouldn't the user be the one who should pick the calendar? Nothing stops a browser from exposing the date widget as a Julian Day calendar widget. On Mon, 9 Aug 2010, Ryosuke Niwa wrote: > > I'd just say that there might be a demand for this feature in Japan (if > localized properly) because all official government document needs to > dated with "era name" (http://en.wikipedia.org/wiki/Japanese_era_name). > Some banks even implement their internal database systems using "era" > system, and it's always cumbersome for humans to convert between "era" > and Gregorian year. On Mon, 9 Aug 2010, Ian Fette (�~B��~B��~C��~C~U�~B��~C~C�~C~F�~B�) wrote: > > And niwa-san, on every document I've ever filled out for the Japanese > government, I've always written 1985年 instead of 昭和60年 and it's > yet to cause me any problems ;-) I do understand that there are some > sites that want it written in the traditional form, but these seem to be > precious few and far between, and frankly are not the sites I would > expect to find HTML5 form input elements on anyways if the US government > is any indication of moving to new standards... On Tue, 10 Aug 2010, Ryosuke Niwa wrote: > > But there are users who don't know how to convert from "xxǯ" to > year 19xx (like my parents and grandparents who has to spend at least > half a minute recalling their birth years in Gregorian calendar), and > only remember their birth years in xx. Some people even buy a > conversion table and keep it in their wallet just so that they can > convert between two systems. Forcing them to remember their birth years > in 19xx isn't user-friendly and simply a poor UI localization. For , I would definitely expect Japanese UAs to offer this kind of feature. Once this takes off, if it would be helpful in Japan, we can definitely extend the feature to type=year if people often need to specify years in one format and have trouble remembering how that format maps to the other. I don't know how common that is. On Sun, 8 Aug 2010, Tantek �~Gelik wrote: > > * this semantic gives browsers the opportunity to present a "ye
Re: [whatwg] @srcdoc and default @sandbox
On Aug 30, 2010, at 4:11 PM, Tab Atkins Jr. wrote: > On Mon, Aug 30, 2010 at 2:08 PM, Adam Barth wrote: >> On Mon, Aug 30, 2010 at 1:58 PM, Maciej Stachowiak wrote: >>> Should @seamless imply @sandbox too, then? >> >> I think there lots of use cases for seamless that don't require >> sandbox. For example, suppose a site wants to show a login form on >> many pages by only wants to implement the login logic once. It's >> entirely reasonable to wish to place the login form in a seamless >> iframe. If we required @sandbox for seamless, that would interfere >> with the login form working properly with password managers. > > Precisely; @seamless was *not* designed with the intention of always > being used with @sandbox. It's just a nice feature to have for > s in general. So there's no real connection between @seamless > and @sandbox like there is between @srcdoc and @sandbox. @seamless was in fact designed to help @sandbox meet more use cases (in particular ones where embedding untrusted content in a fixed rect is not sufficient). But it can be used without @sandbox, and has some plausible uses along those lines, though they were not the initial use cases considered. LIkewise for @srcdoc. Indeed, many use cases are well-served by using all three in tandem. My point being, don't mix up orthogonal features in arbitrary ways. If @srcdoc implies @sandbox, but @seamless does not, someone reviewing for security has to remember exactly which set of similar-sounding attributes cause sandboxing, instead of following the simple rule "just look for @sandbox". Things are clearer when security policy is explicit, and not implied by non-security behaviors. Regards, Maciej
[whatwg] element feedback
On Sat, 7 Aug 2010, Tantek �~Gelik wrote: > > the new element is very useful for absolute dates and times, but > omits several useful granularity levels, in particular for dates. > > The following additional date granularities would be useful, and are > fairly straightforward to incorporate into the spec (and > implementations): > > * year only: > * year-month only: -MM (also corresponds to output form of input > type=month) > * year-week only: -WNN (also corresponds to output form of input > type=week) > * month-day only: --MM-DD (common birthdays without year use case) > > http://wiki.whatwg.org/wiki/Time#Date_granularity As far as I can tell, none of these are use cases for YEAR, as opposed to just YEAR. (But it's hard to tell, because the wiki page is very brief and doesn't even use full sentences.) On Mon, 9 Aug 2010, Tantek �~Gelik wrote: > > HTML5 provides mechanisms for both semantically inputting datetime > values (via the 6 new datetime types), and semantically > outputting datetime values (via the new element). However, the > types/granularities of dates and times that are supported do not match > up on input vs output, and they should. Why? > From a design, learning/teaching perspective, it is much better if they > are made to match up, that is if every type/granularity of datetime that > can be entered can also be semantically marked up (and vice versa). Why? > It would be great if you could add your +1 accordingly to allowing > to markup just a year: > http://wiki.whatwg.org/wiki/Time#year_only Note that I completely ignore volume of feedback and only look at the actual arguments presented. +1s and -1s have no effect on the spec. On Tue, 10 Aug 2010, Tantek �~Gelik wrote: > > We know from experience with past methods of duplicated invisible > (meta)data, and more recently, development/use/experience with visible > microformats, that when we are able to re-use the visible data, > published *once*, by humans for humans, we get more accurate data over > time, than when we have at times asked for *duplicating* the data in a > different (more machine readable) format (or location). This experience > yielded the microformats adoption of the DRY principle - don't repeat > yourself - in application to (meta)dataformat designs and techniques. > > The element currently encourages DRY violations in most of its > use cases (duplication of datetime information inside the 'datetime' > attribute in addition to the visible content of the element). You don't have to give content in the element. In fact it's basically only allowed for fallback for legacy UAs. > 1. composite nested time elements. > > In short, instead of this (actual example derived from markup of blog > post HTML5 watch[1] by Jeremy Keith) > > > Sunday, December 13th, 2009 > 5:43pm > > > We want to be able to do this: > > > Sunday, December 13th, 2009 > 5:43pm > > > and have the parent element composite a complete datetime from > the child elements with separate date and time. There's just as much hidden metadata and a ton more markup. That seems like a loss to me. Why not just do: ...which means the same thing and has no hidden metadata? (Modulo timezone issues; note that floating datetimes aren't allowed with currently.) > 2. am pm and coarser time parsing > > Summary: by permitting am pm and coarser time values, many more > instances of time markup can be minimized to in-content only (not > requiring a datetime attribute) and thus reduce many DRY violations. > > In short, instead of this (actual example derived from markup of blog > post HTML5 watch by Jeremy Keith, with nested time elements per > previous proposal) > > > Sunday, December 13th, 2009 > 5:43pm > > > We want to be able to do this: > > > Sunday, December 13th, 2009 > 5:43pm > > > It's a minor DRY improvement (time info is no longer duplicated), but > one that we think is worth it across the numerous pieces of content > authored as such and the resulting increased accuracy from DRY > reduction. > > This type of am pm parsing as spec'd in the Value Class Pattern has been > interoperably implemented and shipped (Operator, X2V). Thus we think it > is reasonable to add this similar feature to HTML5. Again, just use a single with no content and put all the data in the datetime="" attribute. On Wed, 11 Aug 2010, Tantek �~Gelik wrote: > > The first markup example in section 4.6.9 needs updating: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element > > Current Example and text: > === snip === > > http://www.web2con.com/";>http://www.web2con.com/ > Web 2.0 Conference: > October 5 - > 19, > at the Argent Hotel, San Francisco, CA > > > (The end date is encoded as one day after the last date of the event > because in the iCalendar format, end dates are excl
Re: [whatwg] XMLHttpRequest and HTML5
On Sat, 7 Aug 2010, Anne van Kesteren wrote: > > 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.) Done. > 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... > 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.) Done. > 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. > 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? > 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? > 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] @srcdoc and default @sandbox
On Mon, Aug 30, 2010 at 2:08 PM, Adam Barth wrote: > On Mon, Aug 30, 2010 at 1:58 PM, Maciej Stachowiak wrote: >> Should @seamless imply @sandbox too, then? > > I think there lots of use cases for seamless that don't require > sandbox. For example, suppose a site wants to show a login form on > many pages by only wants to implement the login logic once. It's > entirely reasonable to wish to place the login form in a seamless > iframe. If we required @sandbox for seamless, that would interfere > with the login form working properly with password managers. Precisely; @seamless was *not* designed with the intention of always being used with @sandbox. It's just a nice feature to have for s in general. So there's no real connection between @seamless and @sandbox like there is between @srcdoc and @sandbox. ~TJ
Re: [whatwg] @srcdoc and default @sandbox
On Mon, Aug 30, 2010 at 1:57 PM, Maciej Stachowiak wrote: > > On Aug 30, 2010, at 11:27 AM, Justin Schuh wrote: > >> On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak wrote: >>> >>> I think it's better to let these remain orthogonal features. In general I >>> think it is a net negative to usability when Feature A implicitly turns on >>> Feature B. Implicit relationships like this make the Web platform more >>> confusing. >> >> Security features are typically effective only when deployed in >> concert and when they default to their most restrictive state. As I >> understand, srcdoc is intended primarily as a security feature >> (because non-security use cases already have solutions). So, srcdoc >> should behave like a well-spec'd security feature and provide it's >> strongest level of protection by default, requiring the author to >> scale it back if needed. Otherwise we'll end up with common vulnerable >> cases because many people will expect secure default behavior, >> regardless of whether or not we spec it. > > At least as currently drafted, srcdoc is not a security feature. It's a > convenience feature. It is also designed to work well in tandem with a > particular security feature (sandbox). But by itself, it is not a security > feature. Data URLs already provide this. And if convenience is the primary goal, it seems like there are much better ways to implement the same feature. However, maybe I'm missing something. Could you give a scenario where the convenience factor is significant, and not already served by another feature? Thanks, -j
Re: [whatwg] @srcdoc and default @sandbox
> > >>> On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote: > This would mean that there is no way for an author to use @srcdoc > *without* sandboxing. This appears to be a minority use-case in the > first place (as far as I can tell, it's pretty much just useful for > testing purposes), but the author can always use a data: url in that > case. > I'm not convinced this is that small of a use-case even if it's not the primary one. We should provide a way to turn off sandboxing if we're going to make it the default for anything. Ojan
Re: [whatwg] @srcdoc and default @sandbox
On Mon, Aug 30, 2010 at 1:58 PM, Maciej Stachowiak wrote: > > On Aug 30, 2010, at 11:27 AM, Tab Atkins Jr. wrote: > >> On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak wrote: >>> >>> On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote: >>> While talking with the implementor of @srcdoc in Webkit, it came up that, though @srcdoc is *designed* for use with @sandbox, the author still has to explicitly add @sandbox to the or else they don't get the sandbox security model. Can we make this automatic? Specifically, when >>> srcdoc=foo> is specified (without @sandbox), it drops into the sandbox security model as if was used. If @sandbox is explicitly added, its value is instead used, so the author can set the sandbox security flags if desired. This would mean that there is no way for an author to use @srcdoc *without* sandboxing. This appears to be a minority use-case in the first place (as far as I can tell, it's pretty much just useful for testing purposes), but the author can always use a data: url in that case. >>> >>> I think it's better to let these remain orthogonal features. In general I >>> think it is a net negative to usability when Feature A implicitly turns on >>> Feature B. Implicit relationships like this make the Web platform more >>> confusing. >> >> While I agree with you in general, in this particular case I cannot. >> @srcdoc wasn't designed as an orthogonal feature - it was explicitly >> built with @sandbox in mind, to allow authors to shove generic content >> into the sandbox without incurring a network request. It has only >> niche technical use outside the context of @sandbox. > > Should @seamless imply @sandbox too, then? I think there lots of use cases for seamless that don't require sandbox. For example, suppose a site wants to show a login form on many pages by only wants to implement the login logic once. It's entirely reasonable to wish to place the login form in a seamless iframe. If we required @sandbox for seamless, that would interfere with the login form working properly with password managers. Adam
Re: [whatwg] @srcdoc and default @sandbox
On Aug 30, 2010, at 11:27 AM, Tab Atkins Jr. wrote: > On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak wrote: >> >> On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote: >> >>> While talking with the implementor of @srcdoc in Webkit, it came up >>> that, though @srcdoc is *designed* for use with @sandbox, the author >>> still has to explicitly add @sandbox to the or else they >>> don't get the sandbox security model. >>> >>> Can we make this automatic? Specifically, when >> srcdoc=foo> is specified (without @sandbox), it drops into >>> the sandbox security model as if >>> was used. If @sandbox is explicitly added, its value is instead used, >>> so the author can set the sandbox security flags if desired. >>> >>> This would mean that there is no way for an author to use @srcdoc >>> *without* sandboxing. This appears to be a minority use-case in the >>> first place (as far as I can tell, it's pretty much just useful for >>> testing purposes), but the author can always use a data: url in that >>> case. >> >> I think it's better to let these remain orthogonal features. In general I >> think it is a net negative to usability when Feature A implicitly turns on >> Feature B. Implicit relationships like this make the Web platform more >> confusing. > > While I agree with you in general, in this particular case I cannot. > @srcdoc wasn't designed as an orthogonal feature - it was explicitly > built with @sandbox in mind, to allow authors to shove generic content > into the sandbox without incurring a network request. It has only > niche technical use outside the context of @sandbox. Should @seamless imply @sandbox too, then? Regards, Maciej
Re: [whatwg] @srcdoc and default @sandbox
On Aug 30, 2010, at 11:27 AM, Justin Schuh wrote: > On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak wrote: >> >> I think it's better to let these remain orthogonal features. In general I >> think it is a net negative to usability when Feature A implicitly turns on >> Feature B. Implicit relationships like this make the Web platform more >> confusing. > > Security features are typically effective only when deployed in > concert and when they default to their most restrictive state. As I > understand, srcdoc is intended primarily as a security feature > (because non-security use cases already have solutions). So, srcdoc > should behave like a well-spec'd security feature and provide it's > strongest level of protection by default, requiring the author to > scale it back if needed. Otherwise we'll end up with common vulnerable > cases because many people will expect secure default behavior, > regardless of whether or not we spec it. At least as currently drafted, srcdoc is not a security feature. It's a convenience feature. It is also designed to work well in tandem with a particular security feature (sandbox). But by itself, it is not a security feature. Regards, Maciej
Re: [whatwg] @srcdoc and default @sandbox
On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak wrote: > > On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote: > >> While talking with the implementor of @srcdoc in Webkit, it came up >> that, though @srcdoc is *designed* for use with @sandbox, the author >> still has to explicitly add @sandbox to the or else they >> don't get the sandbox security model. >> >> Can we make this automatic? Specifically, when > srcdoc=foo> is specified (without @sandbox), it drops into >> the sandbox security model as if >> was used. If @sandbox is explicitly added, its value is instead used, >> so the author can set the sandbox security flags if desired. >> >> This would mean that there is no way for an author to use @srcdoc >> *without* sandboxing. This appears to be a minority use-case in the >> first place (as far as I can tell, it's pretty much just useful for >> testing purposes), but the author can always use a data: url in that >> case. > > I think it's better to let these remain orthogonal features. In general I > think it is a net negative to usability when Feature A implicitly turns on > Feature B. Implicit relationships like this make the Web platform more > confusing. While I agree with you in general, in this particular case I cannot. @srcdoc wasn't designed as an orthogonal feature - it was explicitly built with @sandbox in mind, to allow authors to shove generic content into the sandbox without incurring a network request. It has only niche technical use outside the context of @sandbox. Further, omitting @sandbox seems like an easy mistake to make, and one that you won't realize is a mistake until an attack gets through. Avoiding that sort of security model was precisely why @srcdoc was designed the way it was - we want to make it hard to fail, and obvious when you do. ~TJ
Re: [whatwg] @srcdoc and default @sandbox
On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak wrote: > > On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote: > >> While talking with the implementor of @srcdoc in Webkit, it came up >> that, though @srcdoc is *designed* for use with @sandbox, the author >> still has to explicitly add @sandbox to the or else they >> don't get the sandbox security model. >> >> Can we make this automatic? Specifically, when > srcdoc=foo> is specified (without @sandbox), it drops into >> the sandbox security model as if >> was used. If @sandbox is explicitly added, its value is instead used, >> so the author can set the sandbox security flags if desired. >> >> This would mean that there is no way for an author to use @srcdoc >> *without* sandboxing. This appears to be a minority use-case in the >> first place (as far as I can tell, it's pretty much just useful for >> testing purposes), but the author can always use a data: url in that >> case. > > I think it's better to let these remain orthogonal features. In general I > think it is a net negative to usability when Feature A implicitly turns on > Feature B. Implicit relationships like this make the Web platform more > confusing. Security features are typically effective only when deployed in concert and when they default to their most restrictive state. As I understand, srcdoc is intended primarily as a security feature (because non-security use cases already have solutions). So, srcdoc should behave like a well-spec'd security feature and provide it's strongest level of protection by default, requiring the author to scale it back if needed. Otherwise we'll end up with common vulnerable cases because many people will expect secure default behavior, regardless of whether or not we spec it. -j
Re: [whatwg] @srcdoc and default @sandbox
On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote: > While talking with the implementor of @srcdoc in Webkit, it came up > that, though @srcdoc is *designed* for use with @sandbox, the author > still has to explicitly add @sandbox to the or else they > don't get the sandbox security model. > > Can we make this automatic? Specifically, when srcdoc=foo> is specified (without @sandbox), it drops into > the sandbox security model as if > was used. If @sandbox is explicitly added, its value is instead used, > so the author can set the sandbox security flags if desired. > > This would mean that there is no way for an author to use @srcdoc > *without* sandboxing. This appears to be a minority use-case in the > first place (as far as I can tell, it's pretty much just useful for > testing purposes), but the author can always use a data: url in that > case. I think it's better to let these remain orthogonal features. In general I think it is a net negative to usability when Feature A implicitly turns on Feature B. Implicit relationships like this make the Web platform more confusing. Regards, Maciej
Re: [whatwg] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Mon, Aug 30, 2010 at 4:19 AM, Simon Pieters wrote: > This change clashes with data-*. How? Are you missing the fact that *two* consecutive hyphens are needed?
[whatwg] @srcdoc and default @sandbox
While talking with the implementor of @srcdoc in Webkit, it came up that, though @srcdoc is *designed* for use with @sandbox, the author still has to explicitly add @sandbox to the or else they don't get the sandbox security model. Can we make this automatic? Specifically, when is specified (without @sandbox), it drops into the sandbox security model as if was used. If @sandbox is explicitly added, its value is instead used, so the author can set the sandbox security flags if desired. This would mean that there is no way for an author to use @srcdoc *without* sandboxing. This appears to be a minority use-case in the first place (as far as I can tell, it's pretty much just useful for testing purposes), but the author can always use a data: url in that case. As a seperate issue, a @srcdoc should be able to receive @seamless as well, even when it's officially unique-origin (that is, when the author doesn't go out of their way to set @sandbox=allow-same-origin). There is precedent for this in the spec - a text/html-sandboxed resource loaded into an iframe (which is required to be unique-origin) can receive @seamless, because it's not "actually" cross-origin; it only acts that way for particular security purposes which don't apply to the use of @seamless here. ~TJ
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 Monday 2010-08-30 14:28 +0200, Anne van Kesteren wrote: > 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 . 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. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
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] [html5] r5307 - [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers [...]
On Tue, 17 Aug 2010 00:14:17 +0200, wrote: Author: ianh Date: 2010-08-16 15:14:15 -0700 (Mon, 16 Aug 2010) New Revision: 5307 Modified: complete.html index source Log: [giow] (0) use vendor--feature instead of _vendor-feature since Apple engineers think underscores are ugly. Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9590 Modified: source === --- source 2010-08-16 22:11:13 UTC (rev 5306) +++ source 2010-08-16 22:14:15 UTC (rev 5307) @@ -2347,15 +2347,16 @@ For markup-level features that are intended for use with the HTML syntax, extensions should be limited to new - attributes of the form "_vendor-feature", where + attributes of the form "vendor--feature", where vendor is a short string that identifies the vendor responsible for the extension, and feature is the name of the feature. New element names - should not be created. Using attributes for such extensions - exclusively allows extensions from multiple vendors to co-exist on - the same element, which would not be possible with elements. Using - the "_vendor-feature is the name of the feature. (Note the use of + two hyphens in the name.) New element names should not be + created. Using attributes for such extensions exclusively allows + extensions from multiple vendors to co-exist on the same element, + which would not be possible with elements. Using the "vendor--feature" form allows extensions to be made without risk of conflicting with future additions to the specification. @@ -2369,14 +2370,14 @@ these features could write:This smells of lemons! -
+ - Attribute names starting with a U+005F LOW LINE character (_) are - reserved for user agent use and are guaranteed to never be formally - added to the HTML language. + Attribute names containing two consecutive U+002D HYPHEN-MINUS + (-) characters are reserved for user agent use and are guaranteed to + never be formally added to the HTML language. Pages that use such attributes are by definition non-conforming. This change clashes with data-*. -- Simon Pieters Opera Software
