On 5/26/11 2:06 PM, Dennis Joachimsthaler wrote:
a href='http://example.com/user_content/harmless_text_file.txt'
disposition='attachment; filename=Important_Security_Update.exe'
At least in the case of Firefox for that particular case on Windows
thefilename will be sanitized...
So what does
On 5/26/11 2:16 PM, Dennis Joachimsthaler wrote:
Wouldn't this be no immediate problem on Linux type OSs? There's usually
no execution bit set on files downloaded.
Yes, that's the one saving grace. Usually is key, though.
And practically you can run ALL files as binaries, it looks for the
On 5/26/11 3:12 PM, Dennis Joachimsthaler wrote:
Oh I see the problem... Is it the bang? #!/bin/perl #!/bin/python
#!/bin/bash
could very well result in the text file being executed in one of those
interpreters,
right?
Yes, but even worse on some systems a .pl file will just handed over to
On 5/26/11 4:40 PM, Dennis Joachimsthaler wrote:
Though I think it still would happen rarely that a pl file gets downloaded.
The problem is getting the user to save a text file you control as a .pl
file.
I mean who on the most popular system, Windows, has a Perl interpreter
installed?
On 5/27/11 1:10 PM, Aryeh Gregor wrote:
Also, consider a third possibility: currently, the part ofscript
async that's captured by the first timing in Ian's/Boris' example
(whether it's parsing or compilation or whatever) blocks the main
thread in browsers, even though it's async. (Right?)
It looks like Gecko, Presto, and Webkit all support on* event attributes
on all DOM elements, not just HTMLElement.
IE9 seems to only support them on HTMLElement.
I would propose that these be supported on all Elements at least for
events that are not element-specific (e.g. click).
-Boris
On 5/29/11 11:08 AM, John J. Barton wrote:
(I've not seen a for attribute on a script element. Is there any
documentation on what it does?)
http://www.idocs.com/tags/scripts/_SCRIPT_FOR.html sort of describes it.
So does MSDN if you read carefully enough, but the latter's description
is
On 6/3/11 9:16 AM, Eduard Pascual wrote:
Ok, I have never even thought about using the filename argument with
an explicit inline disposition. When I am in control of the headers,
I find it easier to fix the filename with 301/302 redirects
That doesn't work if the data is dynamically generated.
On 6/3/11 8:09 AM, Nils Dagsson Moskopp wrote:
Eduard Pascualherenva...@gmail.com schrieb am Fri, 3 Jun 2011
10:23:25 +0200:
This grants the ability for any content provider to use an explicit
Content-Disposition: inline HTTP header to effectively block
download links from arbitrary sources.
On 6/3/11 10:39 AM, Eduard Pascual wrote:
http://mysite.org/generate_progress_report.php?quarter=Q12010
Wouldn't that default (in the absence of a Content-disposition) to
generate_progress_report.php as the filename?
Depends on the browser. But yes. And that's a crappy filename for the
On 6/3/11 11:46 AM, Bjartur Thorlacius wrote:
Note that some browsers will do weird parsing of the query params to
attempt to extract a useful filename. That seems strictly worse than
just using Content-Disposition.
That's slightly better than just using the last non-empty path
component,
On 6/3/11 2:48 PM, Eduard Pascual wrote:
For a typical snippet of client-side form validation, one or two extra
lines of JS can beautify in advance for a GET form.
Why are you assuming there's any client-side validation code involved?
I'm not sure what do you mean by no one ever sees the
On 6/3/11 2:58 PM, Bjartur Thorlacius wrote:
On 6/3/11, Boris Zbarskybzbar...@mit.edu wrote:
On 6/3/11 11:46 AM, Bjartur Thorlacius wrote:
Note that some browsers will do weird parsing of the query params to
attempt to extract a useful filename. That seems strictly worse than
just using
On 6/5/11 3:53 PM, Bjartur Thorlacius wrote:
On 6/5/11, Boris Zbarskybzbar...@mit.edu wrote:
Why need they be? This isn't Bittorrent.
I think you completely misunderstood my mail... the point is that
browses do NOT all use the last non-empty path component; some try to
guess a filename based
On 6/6/11 4:45 PM, Ian Hickson wrote:
data:text/html,body onload=alert(window[0].location)iframe
src=javascript:''
Woah, funky. (Gecko thinks the location is javascript:''.)
Well... it sort of is. ;)
It's defined; see the section on theonject element.
I've read that section, in
On 6/15/11 4:31 AM, Eduard Pascual wrote:
2011/6/14 Rafał Miłeckizaj...@gmail.com:
We already have required attribute and :valid plus :invalid classes,
which are nice. However some may want to display additional warning
when form wasn't filled correctly. Just some single warning, not
specific
On 6/15/11 1:08 PM, Mounir Lamouri wrote:
Isn't that somewhat related to CSS UI too?
Last I checked, CSS UI defined that the pseudo-classes exist, but left
when they apply up to the language defining the elements.
By the way, for what it worth, I've mention that in this mailing list
and
On 6/15/11 3:12 PM, Eduard Pascual wrote:
2011/6/15 Boris Zbarskybzbar...@mit.edu:
No, it wouldn't. The point here is to style based on a _form_ that is
invalid. Whether a form is valid or not is up to the language defining
forms, that being HTML.
Sorry, I assumed the simple definition that
On 6/16/11 2:32 PM, Dimitri Glazkov wrote:
What if we do this:
1) By default,style scoped implies that all selectors in this
stylesheet are prefixed with :scope.
2) Unless the :scope is already in the selector.
I could live with that.
Especially if we allowed the CSSOM in this situation to
On 6/16/11 3:00 PM, Aryeh Gregor wrote:
Assuming we don't match WebKit/Opera here, though, does everyone agree
we should still place constraints on what selections can be generated
by *user* actions? E.g., if you havebfoo/bbar, and the user
places the cursor in between foo and bar by any means,
On 6/16/11 3:22 PM, Ryosuke Niwa wrote:
It's inevitable in some sense because we can't guess the user intent
although Firefox and Microsoft Word seem to use the direction to which
user moved caret as a hint.
Indeed.
And the fact that the two DOM positions correspond to the same
user-visible
On 6/17/11 1:15 AM, Roland Steiner wrote:
Nitpick: prefixing :scope is only equivalent to limiting selector
matching to the current scope iff there is no ancestor scope.
Ancestor scope defined how?
For a scoped stylesheet, there is only one scope, I would think: the
parentNode of the style
On 6/17/11 1:39 AM, Roland Steiner wrote:
Having another scoped stylesheet under an element further up.
Why does that matter for the way rules in _this_ sheet are treated?
-Boris
On 6/17/11 8:49 AM, Anne van Kesteren wrote:
On Fri, 27 May 2011 21:11:59 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
It looks like Gecko, Presto, and Webkit all support on* event
attributes on all DOM elements, not just HTMLElement.
IE9 seems to only support them on HTMLElement.
I would
On 6/17/11 12:57 PM, Boris Zbarsky wrote:
On 6/17/11 8:49 AM, Anne van Kesteren wrote:
On Fri, 27 May 2011 21:11:59 +0200, Boris Zbarsky bzbar...@mit.edu
wrote:
It looks like Gecko, Presto, and Webkit all support on* event
attributes on all DOM elements, not just HTMLElement.
IE9 seems
On 6/17/11 1:40 PM, Aryeh Gregor wrote:
At a minimum, for instance, we could guarantee that a selection's
boundary point is always in a Text or Element node that descends from
a Document. That would be a big simplification by itself. Does
anyone object to that?
At first blush, that seems
On 6/21/11 5:21 AM, Hallvord R. M. Steen wrote:
Another issue I noticed is in the text under the heading the
javascript: URL scheme - specifically the last otherwise part of the
text. This is about trying to navigate a window from a different origin
to a javascript: URL. Don't we expect a
On 6/22/11 11:51 AM, Hallvord R. M. Steen wrote:
Opera actually does a check earlier - there is an origin check if a
script attempts to set location / location.href to a string that starts
with javascript:.
That's fine, as long as there is _also_ a check right before the script
runs.
(This
On 6/26/11 6:14 PM, Aryeh Gregor wrote:
So this is probably my pure math background showing through rather
than a very useful contribution to the discussion. If the API were
designed for mathematicians, now . . .
The argument could still be made that we want behavior to be continuous
On 6/26/11 8:18 PM, Robert O'Callahan wrote:
Gradients already aren't continuous where the start and end points are
equal. I think it would be OK to draw nothing as Aryeh suggests. At
least it's easy to spec and implement, and I doubt authors will care
(they haven't cared about the browser
On 7/5/11 3:58 PM, Michael Davidson wrote:
Prompting for permissions is much less annoying than opening a new window
That's unclear. Especially if permission grants are persistent.
so I don't think the same standards should apply.
If anything, persistent permission grants should have a
On 7/5/11 4:48 PM, Michael Davidson wrote:
Granting permission, yes. But just asking for permission?
If the asking for permission can happen in a context in which the user
can't tell what's being asked for, it's a really bad idea...
I say it's less annoying because (in Chrome, anyway), the
On 7/5/11 5:04 PM, Michael Davidson wrote:
If the asking for permission can happen in a context in which the
user can't tell what's being asked for, it's a really bad idea...
Can you clarify what you mean? Requiring an in-page click doesn't mean
that the user understands either.
On 7/7/11 9:15 PM, James Robinson wrote:
bikeshed-topic
partial interface Window {
readonly attribute double monotonicTime;
};
This seems like a good idea to me (modulo bikeshedding on the exact
name; I have no obvious opinions there). Right now Gecko has some
places where we actually
On 7/7/11 10:36 PM, Robert O'Callahan wrote:
One question is whether you allow the value to change while a script runs.
When using the value to schedule animations, it would be helpful for the
value to only change between stable states.
If you refer to this value during requestAnimationFrame,
On 6/13/11 8:09 PM, Ian Hickson wrote:
It's possible to switch these relevant checks to walk the ownerDocument
chain instead, say. Then we need to audit all the callsites to make
sure this makes sense at them and figure out what to do for the ones
where it doesn't. (For example, should
On 7/18/11 10:55 PM, Dimitri Glazkov wrote:
I actually really like this proposal.
Let's do this. Roland, Dave, Boris -- what do y'all think?
The proposal being that all selectors are scoped except the ones where
:root is present in the first sequence of simple selectors (not quite
what
On 7/19/11 12:10 AM, Roland Steiner wrote:
Just to nail this down:
foo .bar
scoped, foo must be the scope element or a descendant
This is actually an interesting question. Does this end up
corresponding to:
:scope foo .bar, foo:scope .bar
or to just
:scope foo .bar
? The
On 7/19/11 12:30 AM, Roland Steiner wrote:
I think one could argue for either case. Personally, I think it's
advantageous to include the scoping element (i.e., use :scope foo .bar,
foo:scope .bar), in order to be able to do style the scoping element
itself rather than its children individually,
On 7/19/11 9:12 PM, Ian Hickson wrote:
Would other browser vendors be willing to change to only look atbase
href inhead?
Gecko used to implement that back when the spec said it.
This caused site compat issues. See
https://bugzilla.mozilla.org/show_bug.cgi?id=593807 (United checkin
outside
On 7/20/11 4:54 AM, Anne van Kesteren wrote:
On Wed, 20 Jul 2011 05:07:05 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
That said, I'm not sure I understand the security concern. What kind
of whitelist-based filter would let through scripts whose URIs it
does not control, exactly? Can
On 7/21/11 11:51 PM, Mark Callow wrote:
Seems like a bug in the whitelist filter to me. Shouldn't the filter be
checking requests using the full URL just before they are dispatched?
We're talking a filter on the HTML generation, not in the browser.
-Boris
On 7/28/11 6:05 PM, Anne van Kesteren wrote:
So the SVG WG discussed this and they would like this as well. (They
basically want the same behavior as HTML has here and converge as much
as possible.) The change to the current mechanism required for SVG is to
expose an evt variable somehow in
On 8/9/11 11:29 AM, Justin Novosad wrote:
I second that. And in support of the spec, let me just say that the
clamp-to-edge is essential for many existing canvas-based games that
use large images as sprite maps. Without clamping to the edge of the
source rectangle
We're talking about clamping
On 8/9/11 11:18 AM, David Flanagan wrote:
I assume that the use of an implements declaration rather than direct
inheritance is done to create a clean boundary between the DOM spec and
the HTML spec.
Or just to reflect Ian's belief that all documents should implement all
document intefaces.
On 8/9/11 1:59 PM, David Flanagan wrote:
Yes, that is the case in FF and Chrome, at least. I didn't bring that up
because my intuition is that browsers could make that change (adding
HTMLDocument members to non-HTML documents) without as much web
compatibility impact.
Maybe. Adding them to
On 9/8/11 8:23 PM, David Flanagan wrote:
function(event) {
with(event.target.ownerDocument) {
with(event.target.form || {}) {
with(event.target) {
alert(x);
}
}
}
}
This is almost exactly how Chrome implements it. It's all sorts of
buggy. See
On 9/9/11 5:46 AM, Hallvord R. M. Steen wrote:
All in all, this problem has bitten us many times on major sites, wasted
many hours of QA time on complex analysis, required site patches for
Hotmail and tripadvisor.com, and is still a potential compat problem
with Facebook code. I expect to keep
On 9/9/11 3:40 PM, Ian Hickson wrote:
Only documents; media elements don't use 'readystatechange' events (they
have specific events for specific readyState transitions).
Ah, ok.
This is what I'm leaning towards at the moment. Are there any objections
to removing the readyState support
On 9/9/11 5:46 PM, Ian Hickson wrote:
On Fri, 9 Sep 2011, Boris Zbarsky wrote:
On 9/9/11 3:40 PM, Ian Hickson wrote:
This is what I'm leaning towards at the moment. Are there any
objections to removing the readyState support fromscript (reverting
r6543) and moving onreadystatechange
On 9/10/11 11:00 AM, Kyle Simpson wrote:
So, can I clarify something? You have moved `onreadystatechange` and
`readyState` off of the script element entirely, and onto the HTML
element?
No. They've been removed from elements (and windows) entirely. They
remain on Document.
In regards to
On 9/10/11 7:44 PM, Adam Barth wrote:
It seems like a bad idea to require look-ahead to parse data URLs. Is
there some reason we can't just treat the whole payload as part of the
document?
Yes. It breaks the xlink:href='#greenRect' sort of thing in SVG, unless
you do some sort of other
On 9/10/11 7:53 PM, Nils Dagsson Moskopp wrote:
Is fragment use in data URIs possible at all?
Possible, and desirable; otherwise SVG data: URIs are pretty much useless.
The last point – interoperability – is satisfied by any widely
implemented outcome. The first point – author expectations –
On 9/10/11 9:04 PM, Nils Dagsson Moskopp wrote:
Oops, partial misunderstanding. While I did not think of SVG (thanks),
I wanted to know how often authors have erred here by not properly
encoding their data, expecting it to work.
Good question.
Given that it used to work in Gecko, WebKit, and
On 9/10/11 10:39 PM, Bjoern Hoehrmann wrote:
* Boris Zbarsky wrote:
On the other hand, this would presumably mostly be a problem for people
hand-writing data: URIs. Any sort of data: URI generator would get this
right, as you point out.
(That seems very much like saying Any sort of SQL query
On 9/10/11 11:09 PM, Bjoern Hoehrmann wrote:
I read Daniel as saying that Firefox now implements the correct behavior
Yep.
but the definition of correct behavior should be changed to allow some
addtional convenience for no reason other than convenience.
He explicitly mentioned that we're
On 9/10/11 11:20 PM, Kyle Simpson wrote:
So, can I clarify something? You have moved `onreadystatechange` and
`readyState` off of the script element entirely, and onto the HTML
element?
No. They've been removed from elements (and windows) entirely. They
remain on Document.
So, if I
On 9/15/11 9:40 AM, Dimitri Glazkov wrote:
@global seems cool.
Seems like it needs CSS core grammar changes to be usable with @media
and the like, right?
-Boris
On 9/15/11 11:13 AM, Tab Atkins Jr. wrote:
On Thu, Sep 15, 2011 at 10:27 AM, Boris Zbarskybzbar...@mit.edu wrote:
On 9/15/11 9:40 AM, Dimitri Glazkov wrote:
@global seems cool.
Seems like it needs CSS core grammar changes to be usable with @media and
the like, right?
No, there's no core
On 9/20/11 5:40 PM, Simon Pieters wrote:
However, it is still possible to tell if the user is logged in or not if
a site serves a script for a particular URL when the user is logged in
and redirects to the home page or so when the user is not logged in.
Can't you tell this from the load event
On 9/25/11 5:35 PM, Ryosuke Niwa wrote:
So Gecko fires a click event on a button even if
it had display: none or visibiliy: hidden?
In this situation, yes. Just like as if you called dispatchEvent on it.
Of course you can't trigger click events on such a button using an
actual mouse, since
On 9/26/11 2:09 PM, Tyler Close wrote:
AFAICT, there is no API that the intent handler can
reliably use to determine the correct targetOrigin for this
postMessage invocation.
That's correct, though as long as you don't use too much in the way of
about:blank or javascript: or data: URIs,
On 10/4/11 2:32 PM, Odin Hørthe Omdal wrote:
WebKit, on the other hand, only taints the image and loads it anyway,
breaking the spec.
File a bug on them please? The idea of CORS is that CORS-using requests
stop making the harmful distinction between ability to embed and ability
to read.
On 10/4/11 2:41 PM, Julien Chaffraix wrote:
* However, FF loads the stylesheet synchronously whereas Opera does it
asynchronously from a JS perspective
Uh... Firefox does not load anything synchronously.
What Firefox does do is block execution of script tags (but not
timeouts, callbacks,
On 10/4/11 2:44 PM, Anne van Kesteren wrote:
On Tue, 04 Oct 2011 20:32:02 +0200, Ian Hickson i...@hixie.ch wrote:
The idea is that if the server explicitly rejected the CORS request, then
the image should not be usable at all.
FWIW, from a CORS-perspective both scenarios are fine. CORS only
On 10/4/11 3:02 PM, Anne van Kesteren wrote:
Sure, but not more than per usual. Note that if you do not specify the
crossorigin attribute the image can still get untainted. And if it does
not you would still display the image (as always).
Yes; the point of specifying crossorigin is to opt in
On 10/4/11 3:04 PM, Kenneth Russell wrote:
As far as I can tell the tainting behavior WebKit implements is
correct, and is specified by the text in
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element
. Scroll down to step 6 in the algorithm for
On 10/4/11 3:14 PM, Anne van Kesteren wrote:
On Tue, 04 Oct 2011 21:06:29 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
Yes; the point of specifying crossorigin is to opt in to the security
model we think the web _should_ have but that we can't roll out across
the board. Yet.
Well, what you
On 10/4/11 4:24 PM, Kenneth Russell wrote:
I don't think that this is a good argument for the currently specified
behavior. The server only has the option of declining cross-origin
access if the application specified the crossorigin attribute.
A server has the option of declining _all_ non
On 10/4/11 5:25 PM, Anne van Kesteren wrote:
I think http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html is
a better strategy for achieving that.
Possibly.
The advantage being that only changes on the server are required.
Once all clients implement that proposal, yes?
-Boris
On 10/5/11 9:01 PM, Julien Chaffraix wrote:
Ah. Do they set disabled and expect it to take effect whenever the sheet
actually appears?
Yes, we have seen some regressions because people were expecting exactly that.
So for what it's worth, Gecko implemented the current behavior of
creating
On 10/6/11 12:11 PM, Adam Barth wrote:
It sounds like you're arguing that it's better for developers if we
fail fast and hard
In some cases, yes. It's a tradeoff in every case, obviously.
A meta-issue: if you disagree with the spec text when implementing
something, silently implementing
On 10/6/11 5:54 PM, Adam Barth wrote:
On Thu, Oct 6, 2011 at 10:02 AM, Boris Zbarskybzbar...@mit.edu wrote:
A meta-issue: if you disagree with the spec text when implementing
something, silently implementing something else seems strictly worse than
raising a spec issue (and still implementing
On 10/16/11 2:15 PM, Francis Boumphrey wrote:
My point is, as the only possible use for a DOCTYPE declaration in HTML (any
version) is for including!ENTITYdeclarations
And triggering browsers' standards mode, most importantly.
why bother with an DOCTYPE declaration at all.
To trigger
On 10/17/11 4:56 PM, Bronislav Klučka wrote:
I cannot find :scope pseudo-class selector definition anywhere
http://dev.w3.org/2006/webapi/selectors-api2/#the-scope-pseudo-class
and
http://dev.w3.org/csswg/selectors4/#scope-pseudo
-Boris
On 10/22/11 6:09 AM, Daniel Glazman wrote:
text/plain; charset=iso-8859-1
This is wrong. Nothing in the MIME or the HTTP specs says such a
whitespace is mandatory. Whitespace is explicitely forbidden between
type and subtype, between parameter-name and parameter-value, but that's
all. AFAIC,
On 10/22/11 6:11 AM, Daniel Glazman wrote:
Le 22/10/11 10:11, Anne van Kesteren a écrit :
We do not want to sniff text/plain more than strictly necessary.
One thing I should add : conformance to specs _is_ strictly
necessary. Both MIME and HTTP don't make this spec mandatory.
Daniel, I
On 10/22/11 11:02 AM, Daniel Glazman wrote:
I strongly suggest
some prose explaining why these strings, why like that, why no other
ones, based on what you just wrote above. Informative note if you want.
An informative note would make a lot of sense to me here.
-Boris
On 10/28/11 4:55 PM, Ojan Vafai wrote:
I agree in general. Changing add/remove is definitely worth doing. In the
case of toggle, WebKit already returns a boolean
Gecko likewise.
-Boris
On 10/28/11 3:26 PM, Ashley Gullen wrote:
Overall, I think this proposal is very simple, straightforward to
standardise and implement, genuinely useful, and would significantly
encourage 2D gaming in HTML5 for comparitively little effort. Is it
possible that this could be included in the
On 11/2/11 11:40 AM, Michael A. Puls II wrote:
Boris mention that it was considered a bug by Mozilla that object is
affected by the display property (including display: none).
The bug in Mozilla was pretty broad: any changes to the CSS box
structure affected the plug-in. That's the bug we
On 11/2/11 11:52 PM, Michael A. Puls II wrote:
If we want to keep the display: none behavior that's in current
browsers, I'm not going to object. Just saying that it'd be nice
(better/make more sense) if the use-case for display: none (deferring
instantiation till it's shown) was handled by an
On 11/9/11 9:25 AM, Anne van Kesteren wrote:
It seems wrong to me to add new features to obsoleted features. If there
are good reasons for using frame, maybe it should be made conforming.
If there are no such reasons, there are no reasons either for adding new
features to it.
Well, there's
On 11/15/11 11:25 AM, Anne van Kesteren wrote:
UA does not have an important level.
In Gecko it actually does: it's a level that overrides the user
important level. Such a level is sort of needed in some cases, no
matter what you actually choose to call it.
-Boris
On 11/18/11 11:56 AM, Gavin Kistner wrote:
In each of the eight combinations of (img heightwidth/CSS heightwidth/SVG heightwidth)
being present or not, what are the intrinsic dimensions of the image drawn to
the canvas?
The spec defines this, no? It's cited in
On 11/18/11 12:14 PM, Gavin Kistner wrote:
Add one followup: what if you draw the image to the canvas at a 'large'
resolution, drawImage(img,0,0,200,200)?
Presumably this shouldn't change what source pixels are used for `drawImage`.
You're still assuming there are source pixels. There
On 11/18/11 12:21 PM, Tab Atkins Jr. wrote:
The correct behavior would be to lean on the sizing algorithm at
http://dev.w3.org/csswg/css3-images/#default-sizing. All that needs
to be done is to define the default object size,
That's exactly what the HTML5 spec does right now.
-Boris
On 11/18/11 12:26 PM, Boris Zbarsky wrote:
On 11/18/11 12:14 PM, Gavin Kistner wrote:
However, I've added this test to my URL above and we see that Chrome
has perfectly anti-aliashed circles in all cases, where Firefox is
visibly upscaling a lower-resolution bitmap.
I consider this a Gecko
On 11/21/11 9:22 AM, Jake Verbaten wrote:
As long as G+ is only an optional addition for people who want to use it,
does it really do harm?
As long as all technical discussion ends up in a central place where
everyone can see it at some point, no harm done.
My experience is that once you
On 11/21/11 10:38 AM, Anne van Kesteren wrote:
On Mon, 21 Nov 2011 16:16:22 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
As long as all technical discussion ends up in a central place where
everyone can see it at some point, no harm done.
My experience is that once you have side channels
On 11/21/11 10:48 AM, Boris Zbarsky wrote:
My impression is that following all changes to the specification via
the revision control system is a pretty large burden, if nothing else
because there is no obvious way to do it linked from anywhere I can
find. Maybe a small set of people in the know
On 11/21/11 11:04 AM, Anne van Kesteren wrote:
Following everything what is going on with regards to the platform is
impossible these days. There are too many pieces.
Indeed. What's needed is a way to notice when changes to a particular
piece happen. There isn't one.
A poor stand-in would
On 11/21/11 3:26 PM, Ian Hickson wrote:
What's needed is a way to notice when changes to a particular piece
happen. There isn't one.
Which pieces do you _not_ want to be notified of changes to?
Whatever doesn't affect code I maintain, with my implementor hat on.
Yes, I know this is vague.
On 11/21/11 3:39 PM, Ian Hickson wrote:
If you can tell me which pieces those are, I can see what I can do about
updating the annotations mechanism to make those checkins easier to filter
out.
That's the problem. The set of changes that matter to a particular
person is not static...
Up
On 11/21/11 3:54 PM, Ian Hickson wrote:
If the number of people who would benefit from explicit annotations is
small, I would be happy to add explicit annotations for those people.
Given that the set of people who would like to know about spec changes
in their area probably includes all
On 11/21/11 7:40 PM, Ian Hickson wrote:
If people could e-mail me the lists of topics they would be interested in
being e-mailed diffs for, it would give me a good idea of what coarseness
would be helpful here, and thus whether this is a realistic idea.
Things I probably care about right now:
On 11/25/11 10:19 PM, Cameron McCormack wrote:
1. if property name is in set S, then:
a. look on element
b. look on element's form (if it has one)
c. look on document
otherwise:
a. look at element's named properties (if it has any)
b. look at element's form's named properties (if it has a form)
On 11/26/11 1:03 AM, Yehuda Katz wrote:
Honestly, before this discussion, I would have been surprised to hear
that this works at all. It also seems to me that the group of people who
know how to add an expando and the group of people who use onxxx= is
pretty small to begin with.
This isn't
On 11/29/11 10:27 PM, Yehuda Katz wrote:
Got it. Can we come up with a real-worldish example of someone using
expandos with barewords?
I'll look around. I recall seeing things like that somewhat recently,
but I might be misremembering
-Boris
On 12/1/11 2:12 PM, Aryeh Gregor wrote:
On Fri, Nov 25, 2011 at 11:06 PM, Boris Zbarskybzbar...@mit.edu wrote:
It would break existing pages that use expandos on elements or documents via
barewords in on* attributes.
Isn't that the point of look at element's named properties (if it has
any)
601 - 700 of 1308 matches
Mail list logo
