On Thu, 21 Apr 2005, Dean Edwards wrote:
>
> I'm not sure that Section 2 of WA1 belongs in the spec. None of it seems
> to have much to do with web applications and it makes up 50% of the
> document.
I originally would have agreed, however when making the Web Forms 2 spec
one important piece o
Ian,
I'm not sure that Section 2 of WA1 belongs in the spec. None of it seems
to have much to do with web applications and it makes up 50% of the
document.
I know I've said this before but shouldn't this be a separate document?
Wasn't that the plan for the other bits and pieces of HTML5 anyway?
I have some concern about restriction on the
applicability of the readonly attribute on some of the
form elements. The readonly attribute should be
applicable to all form elements that can change. This
means that the elements that should not support the
readonly attribute is the output and button e
On 21 Apr 2005, at 08:40, Dimitri Glazkov wrote:
Oh yeah, I agree on programmable image being quite useful. The
question is why only limit the capability to a special CANVAS element
(whose semantics are questionable), when any block-level element could
have this ability.
I agree with this, and with
Ian Hickson wrote:
Speaking of setTimeout, where is this defined?
http://whatwg.org/specs/web-apps/current-work/#settimeout
OK. That's twice in one day. I'm off to read the WA1 spec
-dean
On Wed, 20 Apr 2005, Brad Neuberg wrote:
>
> As someone who works with web application development, here's some of
> the things that would make my life easier. Also, including certain
> methods as part of the standard that I usually have to roll on my own
> would make things more standardized:
At 01:11 PM 4/20/2005, you wrote:
On 4/20/05, Dean Edwards <[EMAIL PROTECTED]> wrote:
> Speaking of setTimeout, where is this defined?
Nowhere, and in fact the string method is the commoner implementation,
there are a number of implementations which do not support a function
reference.
uniqueID is
[I'll get back to the rest of the thread when I actually work on the
relevant parts of the spec (I agree with the proposals in general, so
there isn't much for me to add), but just jumping in here:]
On Wed, 20 Apr 2005, Dean Edwards wrote:
>
> Speaking of setTimeout, where is this defined?
Oh yeah, I agree on programmable image being quite useful. The
question is why only limit the capability to a special CANVAS element
(whose semantics are questionable), when any block-level element could
have this ability.
The thing is, programmable image is with almost 100% certainty will be
a pr
dolphinling wrote:
+1
I would ask what semantics canvas has. ol means the content is an
ordered list, em means the content is emphasized, span and div mean the
content is different, but in a way not associated with any element. Even
img and object mean the content is external, (usually) with non
+1
I would ask what semantics canvas has. ol means the content is an
ordered list, em means the content is emphasized, span and div mean the
content is different, but in a way not associated with any element. Even
img and object mean the content is external, (usually) with non-html
semantics.
Dimitri Glazkov wrote:
I would rather see this:
Stuff
with this as bound behavior:
var weightedTags = document.getElementById("weightedTags");
var context = weightedTags.getContext("CanvasRenderingContext2D");
// use content of the weightedTags to draw with context
// ...
Does this make any sens
On 4/20/05, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
> > Isn't the main functional value behind the canvas element is the
> > rendering context? If so, what is the significance of the canvas
> > element itself? Take away the behavior, and you've got yourself
> > another SPACER tag.
>
> Not re
On 4/20/05, Dean Edwards <[EMAIL PROTECTED]> wrote:
> Speaking of setTimeout, where is this defined?
Nowhere, and in fact the string method is the commoner implementation,
there are a number of implementations which do not support a function
reference.
uniqueID is very useful, I to use it all the
Dimitri Glazkov wrote:
Isn't the main functional value behind the canvas element is the
rendering context? If so, what is the significance of the canvas
element itself? Take away the behavior, and you've got yourself
another SPACER tag.
Not really. Since you know what the element is for it has some
Brad Neuberg wrote:
* Have a document.getByPath() method that takes an XPath expression to
traverse and find any nodes in the document; this would be _extremely_
powerful and would erase a huge amount of boilerplate code needed for
walking over the DOM using the standard DOM traversal methods.
I guess I am still struggling to grasp the concepts, so please be
patient with me.
Isn't the main functional value behind the canvas element is the
rendering context? If so, what is the significance of the canvas
element itself? Take away the behavior, and you've got yourself
another SPACER tag.
Brad Neuberg wrote:
* Right now most people directly access an elements className property,
without realizing that they might be clobbering multi-classed elements
(i.e. something with class="class1 class2"). I usually have to create
wrapper methods to ensure that this doesn't happen, such as
x
Brad Fults wrote:
On 4/20/05, Dean Edwards <[EMAIL PROTECTED]> wrote:
Yes, but as I said initially, that creates a closure. This is not always
the most efficient solution. Your code won't work anyway because "i" is
variable. The closure would need to be more complicated to work properly.
Talking ab
As someone who works with web application development, here's some of the
things that would make my life easier. Also, including certain methods as
part of the standard that I usually have to roll on my own would make
things more standardized:
* Have a document.getByPath() method that takes an
Brad Fults wrote:
Besides your other points I think it would also be important to specify
the content model the element can have and the possibility to restrict
this content model.
...
Although such a selection method would be convenient, I think it makes
more sense to specify such exceptions on
Dean Jackson wrote:
Obviously this has pretty significant accessibility problems. There
is no content in - it's just script. With document-based
graphics solutions, such as SVG and even Flash, there is real content
in the document. Accessibility tools can access that content and
provide alternate
ï wrote:
I don't completely understand the rationale for the canvas-element in WA1.
It seems to overlap a lot with the use case for SVG.
I'm guessing here, as I haven't really followed or studied it, but I
believe it's a way for authors to change bitmap images through script,
as opposed to vecto
On 4/20/05, Dean Edwards <[EMAIL PROTECTED]> wrote:
> Ian Hickson wrote:
> > On Wed, 20 Apr 2005, Dean Edwards wrote:
> > I beg to differ:
> >
> >elem[i].disabled = true;
> >setTimeout(function () { elem[i].disabled = false }, 1);
> >
> > That looks a lot easier than the eval() to me. And s
Dean Jackson wrote:
I've seen the Dashboard widgets that use canvas (there isn't many of
them). In every case it would be just as easy to use SVG, and much
more suitable (and probably with better performance). My feeling is
that canvas provides a worse alternative to a problem that is already
solve
Brad Fults wrote:
On 4/20/05, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
Besides your other points I think it would also be important to specify
the content model the element can have and the possibility to restrict
this content model.
...
Although such a selection method would be conve
On 4/20/05, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
> Besides your other points I think it would also be important to specify
> the content model the element can have and the possibility to restrict
> this content model.
> ...
>
Although such a selection method would be convenient, I think
On 21 Apr 2005, at 01:20, Olav Junker Kjær wrote:
I don't completely understand the rationale for the canvas-element in
WA1.
It seems to overlap a lot with the use case for SVG. Of course WF2
competes directly with XForms also, but WF2 has the critical advantage
that it is backwards compatible,
I don't completely understand the rationale for the canvas-element in WA1.
It seems to overlap a lot with the use case for SVG. Of course WF2
competes directly with XForms also, but WF2 has the critical advantage
that it is backwards compatible, implementable in script (which allows
an IE implem
On Anne Van Kesteren's blog
(http://annevankesteren.nl/archives/2005/04/canvas-element),
Sjoerd Visscher said:
> This should never have been an element. The best way to do this is to
> only create a canvas interface, just like the audio interface. With
> the interface you would have to choose an
Ian Hickson wrote:
On Wed, 20 Apr 2005, Dean Edwards wrote:
So you'd submit to a hidden and then disable the main page?
Yep. The iframe then unlocks the page when submission is complete.
Forgetting about iframes for a minute. This is analogous to disabling
the entire application (not the chrome)
On Wed, 20 Apr 2005, Dean Edwards wrote:
> >
> > So you'd submit to a hidden and then disable the main page?
>
> Yep. The iframe then unlocks the page when submission is complete.
> Forgetting about iframes for a minute. This is analogous to disabling
> the entire application (not the chrome).
Ian Hickson wrote:
On Wed, 20 Apr 2005, Dean Edwards wrote:
The use case is a web app that submits data to a hidden iframe. This is
common in JSP type backends. The hidden frame then updates the page with
new data. Maybe this is just me working on projects that are designed
wrong! Anyone else en
On Wed, 20 Apr 2005, Dean Edwards wrote:
>
> The use case is a web app that submits data to a hidden iframe. This is
> common in JSP type backends. The hidden frame then updates the page with
> new data. Maybe this is just me working on projects that are designed
> wrong! Anyone else encounter t
Olav Junker KjÃr wrote:
"parentElement" would always be the same as "parentNode" though, won't it?
parentNode could also be a document fragment.
Ian Hickson wrote:
On Wed, 20 Apr 2005, Dean Edwards wrote:
1) Mozilla's DOMContentLoaded event is very handy.
Good idea.
2) I'd like to be able to lock/disable an entire document. This is
useful when submitting to hidden frames. It helps prevent users from
re-submitting data before it has been p
Dean Edwards wrote:
It would be handy to have the following DOM properties:
childElements
firstChildElement
lastChildElement
previousElement
nextElement
parentElement
handy but definitely not required.
I think "childElements" corresponds to IE's "children" collection
(except that "children" includ
On Wed, 20 Apr 2005, Dean Edwards wrote:
>
> 1) Mozilla's DOMContentLoaded event is very handy. It fires when a
> node's content has been loaded and parsed (the DOM has been
> constructed). This is much better than the standard onload event as it
> doesn't wait for binary content to also load.
There are some scripting tweaks I'd like to see in WA1. Apologies if
these have been covered already:
1) Mozilla's DOMContentLoaded event is very handy. It fires when a
node's content has been loaded and parsed (the DOM has been
constructed). This is much better than the standard onload event a
Olav Junker KjÃr wrote:
Anyways, editing could be broken up into these topics:
- A way to mark an element as editable (the contentEditable attribute).
Besides your other points I think it would also be important to specify
the content model the element can have and the possibility to restrict
thi
On Wed, 20 Apr 2005, Peter Karlsson wrote:
> >
> > However, the only legal value in accept-charset should be utf8 when
> > the method is GET.
>
> UTF-8 and US-ASCII, probably.
That's what I'd written, actually.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://
Olav Junker Kjær on 2005-04-20:
However, is it really the right thing to allow arbitrary encodings of GET
queries in the first place? The official Right Way to encode URLs is to
use Utf8, and it seems strange to allow a different encoding after the
question mark.
Strange as it may seem, that's t
42 matches
Mail list logo
