On Sat, Oct 17, 2009 at 8:37 PM, Darin Fisher wrote:
> On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson wrote:
> ...
>>
>> On Thu, 15 Oct 2009, Darin Fisher wrote:
>> >
>> > This is interesting since documentURI is a read/write property:
>> > http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-
On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson wrote:
> On Thu, 15 Oct 2009, Darin Fisher wrote:
>>
>> This is interesting since documentURI is a read/write property:
>> http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-documentURI
>
> I assume that is a mistake. Does anyone support document
On Sat, Oct 17, 2009 at 12:45 PM, Nelson Menezes
wrote:
> 2009/10/17 Jonas Sicking :
>> In fact, you don't even need to use pushState. For now this can be
>> faked using onhashchange and fragment identifier tricks. It's
>> certainly not as elegant as pushState (that is, after all, why
>> pushState
On Thu, 15 Oct 2009, Charles Pritchard wrote:
> >
> > Turning off anti-aliasing just trades one problems for another.
>
> I'm not sure I understand what that trade is -- isn't that something
> that the individual user of Canvas would take into account when flipping
> the switch?
Sure, but you're
On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson wrote:
...
> On Thu, 15 Oct 2009, Darin Fisher wrote:
> >
> > This is interesting since documentURI is a read/write property:
> > http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-documentURI
>
> I assume that is a mistake. Does anyone support
On Thu, 15 Oct 2009, Boris Zbarsky wrote:
> On 10/15/09 3:35 PM, Gregg Tavares wrote:
> > I was wondering if there as been a proposal for either an optional
> > argument to setInterval that makes it only callback if the window is
> > visible OR maybe a window.setRenderInterval.
>
> You might be
On Thu, 15 Oct 2009, Jeremy Orlow wrote:
>
> I'd like to propose we remove the "source" attribute from storage
> events. ( http://dev.w3.org/html5/webstorage/#the-storage-event) In
> Chrome, we cannot provide access to a window object unless it's in the
> same process. Since there's no way to
If you'd like to see what this looks like in Javascript, I implemented
this technique several years ago. One place you can see it publicly is
the swapFromHttp() function at:
http://havel.columbia.edu/media_panels/js/MochiPlus.js
You can see it in action on some pages like:
http://havel.columbia.e
On Thu, 15 Oct 2009, Philip Jägenstedt wrote:
>
> Is there a reason why HTMLPropertyCollection.namedItem unlike some other
> collections' .namedItem don't return an element if there is only 1
> element in the collection at the time the method is called? Perhaps this
> is legacy quirks that we do
2009/10/17 Jonas Sicking :
> In fact, you don't even need to use pushState. For now this can be
> faked using onhashchange and fragment identifier tricks. It's
> certainly not as elegant as pushState (that is, after all, why
> pushState was added), but it's something that can be tried today.
Well
On Sat, Oct 17, 2009 at 11:16 AM, Dion Almaer wrote:
> This feels like really nice sugar, but maybe the first step should be to get
> the shim out that gets it working using JS now and then see how it works
> in practice. I totally understand why this looks exciting, but I have the
> same unea
This feels like really nice sugar, but maybe the first step should be to get
the shim out that gets it working using JS now and then see how it works
in practice. I totally understand why this looks exciting, but I have the
same uneasiness as Jonas. It feels like a LOT of magic to go grab a pa
Tab Atkins Jr. schrieb:
On Sat, Oct 17, 2009 at 12:22 AM, Jonas Sicking wrote:
Also, what should happen if the user presses the 'back' button?
If the browser can remember what the page state was previously, just
swap in the old parts. If not, but it at least remembers what parts
were replace
On Sat, Oct 17, 2009 at 12:22 AM, Jonas Sicking wrote:
> On Fri, Oct 16, 2009 at 11:06 AM, Tab Atkins Jr. wrote:
>> Promoting this reply to top-level because I think it's crazy good.
>>
>> On Fri, Oct 16, 2009 at 11:09 AM, Aryeh Gregor
>> wrote:
>>> On Fri, Oct 16, 2009 at 10:16 AM, Tab Atkins
On Sat, 17 Oct 2009, Keryx Web wrote:
>
> However, does not this open up the possibility of getting rid of dt/dd
> in details and use an hx element, which is a much better solution from a
> semantic POV?
The elements are valid flow content, so there'd be no way to
distinguish the element fro
On Wed, 14 Oct 2009, Alexey Proskuryakov wrote:
> 13.10.2009, в 4:11, Ian Hickson написал(а):
> > >
> > > Is this meant to mimic some behavior that existing clients have for
> > > HTTP already?
> >
> > Yes, as it says, the idea is for UAs to send the same headers they
> > would send if the prot
2009-10-17 12:04, Ian Hickson skrev:
A rider suggestion: expose in the page outline as the heading
for the.
I considered this, but I don't really want to make the algorithm any more
complicated, and I'm not really sure we'd want that exposed, any more than
you want the headings for individual
On Wed, 14 Oct 2009, Jeremy Keith wrote:
> Hixie wrote:
> > > Then it might be nice to clarify this with a few words in the spec,
> > > as "The fieldset element represents a set of form controls
> > > optionally grouped under a common name" can be read as implying
> > > structuring and thus acce
2009/10/17 Jonas Sicking :
> On Fri, Oct 16, 2009 at 11:06 AM, Tab Atkins Jr. wrote:
>> Promoting this reply to top-level because I think it's crazy good.
>>
>> On Fri, Oct 16, 2009 at 11:09 AM, Aryeh Gregor
>> wrote:
>>> On Fri, Oct 16, 2009 at 10:16 AM, Tab Atkins Jr.
>>> wrote:
As well
On Fri, 16 Oct 2009 05:28:46 -0400, Ian Hickson wrote:
On Sun, 20 Sep 2009, Michael A. Puls II wrote:
O.K., so put simply, HTML5 should explicitly mention that the css
display property for , (and in the handling
section) has absolutely no effect on plug-in instantiation and
destroying and ha
On Wed, 14 Oct 2009, Yuvalik Webdesign wrote:
>
> I'll give it one more go. ;-)
>
> Perhaps you could leave the existing sentence, but add:
>
> "In short; a transparent element must have the same content model as its
> parent."
>
> Or something to that effect?
On Wed, 14 Oct 2009, Tab Atkins J
On Wed, 14 Oct 2009, Michael(tm) Smith wrote:
> Ian Hickson , 2009-10-14 03:41 +:
> >
> > As far as I can see the options are as follows:
> >
> > 1. Drop support for and for now, revisit it later.
> >
> > 2. Use , and don't expect to be able to use it in any browsers
> > sanely for a
On Tue, 13 Oct 2009, Boris Zbarsky wrote:
> On 10/13/09 10:58 PM, Ian Hickson wrote:
> > Ah, I see. Yes, that makes sense. Are you ok with what the spec says
> > despite this minor difference? (It seems that what the spec says is a
> > mote more self-consistent, but I could be biased! ;-) )
>
>
On Fri, Oct 16, 2009 at 4:43 PM, Tab Atkins Jr. wrote:
[snip]
> Isn't if inefficient to request the whole page and then throw most of
> it out? With proper AJAX you can just request the bits you want.
> ==
> This is a valid complaint, but one wh
On Sat, Oct 17, 2009 at 5:37 PM, Oliver Hunt wrote:
>
> On Oct 16, 2009, at 8:10 PM, Robert O'Callahan wrote:
>
> I think there is a reasonable argument that the spec should be changed so
> that compositing happens only within the shape. (In cairo terminology, all
> operators should be bounded.)
On Fri, Oct 16, 2009 at 9:55 PM, Boris Zbarsky wrote:
> On 10/16/09 8:21 PM, Ben Laurie wrote:
>>
>> The point is that if I think I'm sourcing something safe but it can be
>> overridden by the MIME type, then I have a problem.
>
> Perhaps we need an attribute on that says to only render the data
On Tue, 13 Oct 2009, Peter Brawley wrote:
> >
> > Your requirements aren't met by framesets
>
> Eh? Our solution meets the requirement and uses framesets.
As others have discussed, you explained that use wanted framesets because
they prevented bookmarking, but they don't.
> > s have been demo
27 matches
Mail list logo
