in HTML5.
Fair enough. Seems we're still lacking someone to continue the work Simon
started :/
--
Anne van Kesteren
http://annevankesteren.nl/
ugh I would personally prefer if we could
move the HTML5 specific bits of DOM Core to Web DOM Core which then would
simply state the exceptions for HTML documents. That way the methods are
defined in one place which makes more sense to me.
--
Anne van Kesteren
http://annevankesteren.nl/
do browsers do?
Third is about Web addresses in HTML 5. (this spec is also this ML?)
http://www.w3.org/html/wg/href/draft
You want public-...@w3.org or public-h...@w3.org for that draft.
--
Anne van Kesteren
http://annevankesteren.nl/
On Tue, 08 Sep 2009 17:57:36 +0200, Dimitri Glazkov
wrote:
On Tue, Sep 8, 2009 at 6:12 AM, Anne van Kesteren
wrote:
FWIW, this is why I think pushState is great. If you bookmark it and
later
visit that page it allows the server to directly give the right content
back
instead of first
to a non-starter it would allow you to create
interfaces that have the same URL regardless of whether JavaScript is
enabled or disabled and still use fancy effects and downloaded content
incrementally when JavaScript is enabled.
--
Anne van Kesteren
http://annevankesteren.nl/
does not seem worth
it given that the IE Team apparently found more and that going forward
authors should use .files to be able to deal with multiple files as
well.
--
Anne van Kesteren
http://annevankesteren.nl/
).
Whereas most field types have a Min and Max attribute, this does not
appear to be true of date/time fields.
What makes you think they do not apply there?
--
Anne van Kesteren
http://annevankesteren.nl/
/2006/webapi/FileUpload/publish/FileAPI.html
--
Anne van Kesteren
http://annevankesteren.nl/
so thought it was pretty
clear we wanted the burden to be on user agents. (I also recall, but am
not a 100% sure, that developers from Mozilla agreed to this, even though
it would be hard to make it all work in Gecko.)
--
Anne van Kesteren
http://annevankesteren.nl/
he scrollbars be disabled (preventing
the user from seeing the content)?
That depends on platform UI conventions.
--
Anne van Kesteren
http://annevankesteren.nl/
e data more portable.
--
Anne van Kesteren
http://annevankesteren.nl/
ML5 might not be the best place for that though. It definitely
has all the right people involved, but encodings affect more than just
HTML.
--
Anne van Kesteren
http://annevankesteren.nl/
On Sun, 30 Aug 2009 03:44:26 +0200, Ian Hickson wrote:
On Tue, 25 Aug 2009, Anne van Kesteren wrote:
Also, maxlength cannot be enforced as client-side validation requirement
due to compatibility issues.
I thought we had worked around that with the dirty value flag?
I misremembered. However
them a subdomain of some sorts rather than a
directory if you want the offering to be somewhat secure.
--
Anne van Kesteren
http://annevankesteren.nl/
via ECMAScript or initiate
requests from there, etc. Paths cannot be trusted to provide security.
(Maybe the specification should point that out.)
--
Anne van Kesteren
http://annevankesteren.nl/
ons that do
not require the cloud at all and basically consist of a set of static
documents distributed over HTTP.
--
Anne van Kesteren
http://annevankesteren.nl/
On Tue, 25 Aug 2009 18:57:59 +0200, Peter Kasting
wrote:
On Tue, Aug 25, 2009 at 12:05 AM, Anne van Kesteren
wrote:
Also, maxlength cannot be enforced as client-side validation requirement
due to compatibility issues.
I don't grasp what you're saying here. Are you saying that ma
.
Though somewhat inconsistent with type=url, but then IDN email addresses
are not quite there yet.
Opera 9.64 seems to reject IDNs in (but I'm not
totally sure on this, my IDN might just be wrong somehow).
We might not support them yet, I haven't checked.
--
Anne van Kes
cannot be enforced as client-side validation requirement due to
compatibility issues.
--
Anne van Kesteren
http://annevankesteren.nl/
On Tue, 25 Aug 2009 02:19:55 +0200, TAMURA, Kent wrote:
> I'd like stricter rule for it. e.g.
> dot-atom-text "@" 1*(ALPHA / DIGIT) 1*("." 1*(ALPHA / DIGIT))
That does not work with IDNs.
--
Anne van Kesteren
http://annevankesteren.nl/
On Wed, 19 Aug 2009 22:47:57 +0200, Anne van Kesteren wrote:
> Today every browser implements their own encoding label matching
> algorithm, supports their own list of encodings, their own list of
> encoding label aliases, and everything sort of works, but not really.
>
> HTML5
large body of Web content.
This means new clients will have to reverse engineer that list from existing
clients which I think is bad.
--
Anne van Kesteren
http://annevankesteren.nl/
the URI syntax but rather something you
could append to any URI during retrieval operations, which is clearly what data
URIs are for.
--
Anne van Kesteren
http://annevankesteren.nl/
On Fri, 14 Aug 2009 16:02:52 +0200, Tab Atkins Jr. wrote:
> Is there some other place I should be looking in the multipage spec?
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#the-textarea-element-0
--
Anne van Kesteren
http://annevankesteren.nl/
your argument on that will not be stylable.
I think the idea is that it will be stylable though.
--
Anne van Kesteren
http://annevankesteren.nl/
but the current algorithm does not
seem to cut it. E.g. sites rely on the fact that EUC_JP is not a
recognized encoding but EUC-JP is.
--
Anne van Kesteren
http://annevankesteren.nl/
(No informed opinion on allowing cycles.)
--
Anne van Kesteren
http://annevankesteren.nl/
harmod/ )
--
Anne van Kesteren
http://annevankesteren.nl/
can invent class conventions if they so desire. In any case, HTML5 also
provides Microdata which could be used for this. I very much agree that
experimenting with this before standardizing is the right thing to do. (That's
how came to be.)
--
Anne van Kesteren
http://annevankesteren.nl/
tf-8 text.
> var text = binaryBlob.getText();
> document.getElementById("content").innerHTML = text;
> }
> }
Having dedicated support for a subset of archiving formats in within the API
for File objects makes sense to me. Latest draft of the File API I know of is
ht
t at,
> say, http://www.whatwg.org/specs/ would be handy; or even better, the
> references section in the HTML5 spec could list them.
I created an overview here:
http://wiki.whatwg.org/wiki/HTML5_spin-offs
Not sure where to best link it from. Someone else may figure that out :-)
-
the same URL processor
everywhere (though sometimes the URL character encoding flag is set to UTF-8
and cannot be changed). As such it would be nice to know if that is still true
here or whether this is a pre-processing step specific to HTML attribute values.
--
Anne van Kesteren
http://annevankesteren.nl/
of them)
decide that Ian is no longer making good decisions they can override him as
well.
Ultimately implementors of Web browsers can also decide not to adopt the
specification. Authors can do the same. There's quite a lot of checks and
balances I think. Way more for instance than with the
On Fri, 24 Jul 2009 04:56:15 +0200, Boris Zbarsky wrote:
> Anne van Kesteren wrote:
>> From what I heard so far it is there because of document.all. If
>> document.all does indeed need to return a separate object as HTML5
>> suggests we can probably remove it from HTMLCol
On Fri, 24 Jul 2009 12:00:41 +0200, Anne van Kesteren wrote:
> On Fri, 24 Jul 2009 06:44:55 +0200, Ian Hickson wrote:
>> Hmm... Maybe a position:fixed text field somewhere on the page, with a
>> submit button to send that feedback as mail... that could work. It could
>> gi
y
>> interested in seeing a commenting system.
>
> Hmm... Maybe a position:fixed text field somewhere on the page, with a
> submit button to send that feedback as mail... that could work. It could
> give the ID of the most recently clicked area of the page, or something.
elementFromPoint()?
--
Anne van Kesteren
http://annevankesteren.nl/
s indeed need to return a separate object as HTML5 suggests we can probably
>remove it from HTMLCollection in due course.
--
Anne van Kesteren
http://annevankesteren.nl/
re part of the request to the manifest file
so you could serve up a different one from the server based on cookie data.
Is the problem supporting multiple users completely client-side? I can see how
that might not work very well.
--
Anne van Kesteren
http://annevankesteren.nl/
timized object when dealing with style sheets or getElementsByClassName().
Alternatively we could require I suppose that in quirks mode class names are
normalized to be lowercase or some such and keep getElementsByClassName() and
classList case-sensitive...
--
Anne van Kesteren
http://annevankesteren.nl/
n we have a looping API at all is
for seamless looping. (Otherwise you'd simply listen for the ended event and
invoke play() when it is dispatched.)
--
Anne van Kesteren
http://annevankesteren.nl/
for some time now ?
It means that you support DOM Level 2 HTML for XHTML. Not that you support
XHTML 2.0.
--
Anne van Kesteren
http://annevankesteren.nl/
. Killing this useless list seems like the
best way forward. As far as I know there is no compatibility reason for having
it other than that test suite and having it be an arbitrary number of
attributes is just confusing and slightly increases code complexity and testing.
--
Anne van Kest
ly calls out setting them.
--
Anne van Kesteren
http://annevankesteren.nl/
On Wed, 01 Jul 2009 18:29:17 +0200, Peter Kasting
wrote:
On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren
wrote:
The "vendor consensus" line of argument seems like a very dangerous
slippery slope. It would mean that whenever a vendor refuses to
implement something it has to be
ot
good at all in my opinion.
--
Anne van Kesteren
http://annevankesteren.nl/
the input event object? The input
event is already deployed. Why do we need to introduce a new version and
duplicate functionality? DOM Level 3 Events is still a WD.
--
Anne van Kesteren
http://annevankesteren.nl/
for .
By the way, did anyone ever implement textInput from DOM Level 3 Events?
If not maybe someone should email www-dom about "nuking" that.
--
Anne van Kesteren
http://annevankesteren.nl/
uot; or "hover" etc. Invalid event types
> should probably throw an error or something... or maybe this is more
> in the scope of DOM Events.
That is still quite a bit of complexity for little benefit.
--
Anne van Kesteren
http://annevankesteren.nl/
deployment I don't
expect changes to this to be within the realm of possibilities.
By the way, change requests for this specification should be made to
public-weba...@w3.org. localStorage and friends are no longer part of HTML5.
--
Anne van Kesteren
http://annevankesteren.nl/
they aren't
> permitted then it should accept neither of them (and therefore have to
> implement a 'which day is January 1st' algorithm, which I'm guessing it
> currently doesn't).
Or maybe it implements the bogus one the specification previously defined.
--
Anne van Kesteren
http://annevankesteren.nl/
ears -- with the text
> "Worker". That didn't really elucidate matters:
>
> http://www.whatwg.org/html5#serializability-of-script-execution
>
> What's this about?
It's an unimplemented feature. In this case a cross-specification reference to
Web Workers.
--
Anne van Kesteren
http://annevankesteren.nl/
On Mon, 15 Jun 2009 23:45:02 +0200, Boris Zbarsky wrote:
> Anne van Kesteren wrote:
>> On Mon, 15 Jun 2009 18:25:03 +0200, Adam Roben wrote:
>>> DOM 3 Core defines the DOMStringList interface [1], [...]
>> I don't think anybody actually implements this interface
ins.
[1]
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#DOMStringList
--
Anne van Kesteren
http://annevankesteren.nl/
On Wed, 10 Jun 2009 20:36:30 +0200, Brett Zamir wrote:
That'd be fine by me if at least DOMParser + XMLSerializer was being
officially standardized on...
See the separate thread on those objects.
--
Anne van Kesteren
http://annevankesteren.nl/
onous loading in perfect
> conditions.
We should probably nuke it.
> It seems that everyone wants DOM3 L&S to die and to have everyone use JS
> to make their own wrapper around XHR + DOMParser + XMLSerializer etc. to
> do what DOM3 L&S does.
Yeah, no need for two high-leve
terfaces we want to
provide to deal with files.
--
Anne van Kesteren
http://annevankesteren.nl/
On Wed, 10 Jun 2009 00:08:23 +0200, Øistein E. Andersen wrote:
> Le 9 juin 09 à 10h55, Anne van Kesteren écrivit :
>> So should HTML5 mention that Windows-932 maps to Windows-31J? (It does
>> not appear in the IANA registry.)
>
> That is an interesting question.
jects that can be
passed to the send() method as argument and define how they are to be
serialized and maybe how they affect the Content-Type header.
--
Anne van Kesteren
http://annevankesteren.nl/
On Tue, 09 Jun 2009 01:42:57 +0200, Øistein E. Andersen wrote:
> Le 5 juin 09, Anne van Kesteren écrivit :
>> Is the implication here that Shift_JIS and Shift-JIS are distinct [...]?
>
> No, Shift-JIS and Windows-932 are commonly used names/labels for the
> encodings that
gt; ...though it will probably rely on the upcoming File API to actually
> obtain files to upload.
And as such is not defined yet at all, but that is pretty much the plan, yes.
--
Anne van Kesteren
http://annevankesteren.nl/
ting a little with respect to picking the first or last header in case of
multiple Location headers. I forgot the specifics unfortunately, but I believe
Opera was not consistent.
--
Anne van Kesteren
http://annevankesteren.nl/
On Fri, 05 Jun 2009 10:14:46 +0200, Ian Hickson wrote:
> On Fri, 5 Jun 2009, Anne van Kesteren wrote:
>>
>> Is the implication here that Shift_JIS and Shift-JIS are distinct
>> despite the encoding matching rules in Unicode not allowing for that? If
>> that is t
extensions
>> in
>> both NEC and IBM (Shift-JIS) positions. This is actually Windows-932:
>>
>> Shift-JIS < Windows-932
>>
>> [...]
--
Anne van Kesteren
http://annevankesteren.nl/
s, but I
> think it'd be far better than the current behavior.
Doesn't this reveal what mode the user is using to view the site? That seems
kind of bad.
--
Anne van Kesteren
http://annevankesteren.nl/
On Wed, 03 Jun 2009 09:34:08 +0200, Chris DiBona wrote:
> Yeah, this is really pretty difficult stuff. The lgpl is probably the
> least understood and most complicated free software licenses.
Thanks for taking the time to explain it!
--
Anne van Kesteren
http://annevankesteren.nl/
cant amount of complexity themselves. Defining the
rules for parsing and creating a raw database file in a secure way is a
whole new layer of issues and the gain seems small.
--
Anne van Kesteren
http://annevankesteren.nl/
ad in just doing this through
XMLHttpRequest, some processing, and the database API?
--
Anne van Kesteren
http://annevankesteren.nl/
ired until the
selected resource is completely loaded. I.e. as step 4 of the "resource fetch
algorithm".
--
Anne van Kesteren
http://annevankesteren.nl/
> be allowed (origins are not equal).
>
> Opinions?
I'd rather not leak document.domain leak more than necessary. Especially with
it being bound to the Public Suffix List. If you want to communicate across
origins you can always use postMessage().
--
Anne van Kesteren
http://annevankesteren.nl/
re probably more ways to exploit the difference besides what I listed.
* It might make people think that style elements would work. (I
believe we're reasonably sure this would break things.)
* It might make people think that style attributes would work.
(I believe we're reasonably s
lize a subtree rooted at a given node without
> removing the node from its current location in the DOM.
Isn't this true for innerHTML too?
--
Anne van Kesteren
http://annevankesteren.nl/
Although it seems most browsers have adopted these APIs, HTML5 offers basically
identical APIs in the form of
document.innerHTML
or is there something that DOMParser / XMLSerializer can do that
document.innerHTML cannot?
--
Anne van Kesteren
http://annevankesteren.nl/
metimes drawing you svg will
work, and sometimes it won't. That's why it's a bad API.
That's not quite what we implemented (and proposed) though. In case there
is no intrinsic size you'd just fall back to a default size. I.e. similar
to how , , etc. work.
--
Anne van Kesteren
http://annevankesteren.nl/
still validate it when it starts
with a digit, in XML. Just not with DTD/XSD validation.
--
Anne van Kesteren
http://annevankesteren.nl/
D/XSD realm.
--
Anne van Kesteren
http://annevankesteren.nl/
ed in August or so per
the issue tracker.)
--
Anne van Kesteren
http://annevankesteren.nl/
it.
--
Anne van Kesteren
http://annevankesteren.nl/
On Mon, 04 May 2009 23:52:21 +0200, fantasai
wrote:
[...]
Regardless of whether the effect of the rules is wrong, the name of the
attribute is frame, not frames, as far as I can tell.
--
Anne van Kesteren
http://annevankesteren.nl/
nd
CanvasPixelArray would be nice to avoid. (I'd be fine with renaming ImageData
to CanvasData as well.)
--
Anne van Kesteren
http://annevankesteren.nl/
ment object directly to drawImage() and friends.
--
Anne van Kesteren
http://annevankesteren.nl/
tails here though. Is there a reason that they can't
dispatch in a guaranteed order?
Note that per DOM Level 3 Events (still a draft) the dispatch order is
defined (register order). I believe that is also required for Web compat
at this point, though I'm not a 100% sure.
--
An
an element because parses just
like and friends.
--
Anne van Kesteren
http://annevankesteren.nl/
to uppercase has the same effect as converting to uppercase
ASCII.
That's not true. You can get Unicode characters in HTML element names.
(You still want to lowercase only the ASCII characters though.)
--
Anne van Kesteren
http://annevankesteren.nl/
On Fri, 03 Apr 2009 06:26:43 +0200, Robert O'Callahan
wrote:
Mozilla could probably get behind that, but I don't know who else is
willing to bite the bullet.
The problem already exists for document.cookie, no? And the current API is
by far the most convenient the use.
-
ually ensure
(when implemented) that some normalized form of the data goes to the
server. If that is not a goal here I'm not sure we should introduce a
type="" attribute value for it.
--
Anne van Kesteren
http://annevankesteren.nl/
On Sun, 29 Mar 2009 15:01:51 +0200, Giovanni Campagna
wrote:
2009/3/29 Anne van Kesteren :
I'm not sure if you're correct about those differences, but even if you
are they are not the only differences. E.g. LEIRIs perform
normalization if the input encoding is non-Unicode. U
itor of the new draft might not read this list at all.)
--
Anne van Kesteren
http://annevankesteren.nl/
in Opera.
--
Anne van Kesteren
http://annevankesteren.nl/
On Tue, 24 Mar 2009 17:23:20 +0100, Alex Henrie
wrote:
On Tue, Mar 24, 2009 at 8:15 AM, Anne van Kesteren
wrote:
Microsoft did. And nothing changed in well over a year. (They say so in
a comment on the blog post.)
Perhaps the buggy code was only sent to IE, and Firefox got more
ation developers...) Furthermore, once we get interoperable
support for and the fileList proposal starts
moving we can provide cleaner access directly to the file name there.
--
Anne van Kesteren
http://annevankesteren.nl/
part of a URL (after it has been determined what the URL is
for a given context) does not work because?
--
Anne van Kesteren
http://annevankesteren.nl/
ested in hearing your point. Is it whitespace?
--
Anne van Kesteren
http://annevankesteren.nl/
is a superset of the other (as long as URL
encoding is UTF-8) I don't see a point in having both.
--
Anne van Kesteren
http://annevankesteren.nl/
On Mon, 23 Mar 2009 11:31:01 +0100, Julian Reschke
wrote:
Anne van Kesteren wrote:
Well yes, and a subset of those is browser based. Besides that, most
feed readers handle HTML. Do you think they should have two separate
URL parsing functions?
Yes, absolutely.
Why?
I'm not conv
On Mon, 23 Mar 2009 11:25:19 +0100, Julian Reschke
wrote:
Anne van Kesteren wrote:
Be careful; depending on what you call "Web content". For instance, I
would consider the Atom feed content (RFC4287) as "Web content", but
Atom really uses IRIs, and doesn't need wo
re browser implementations of feeds reject non-IRIs in some way?
I would expect them to use the same URL handling everywhere.
Don't leak out workarounds into areas where they aren't needed.
I'm not convinced that having two ways of handling essentially the same
thing is good.
--
Anne van Kesteren
http://annevankesteren.nl/
On Fri, 20 Mar 2009 00:00:03 +0100, Jonas Sicking wrote:
On Thu, Mar 19, 2009 at 3:54 PM, Anne van Kesteren
wrote:
Also, it's not that
hard to encode something as UTF-8 these days and the reduced complexity
would be a nice benefit.
Do such tools always insert a BOM as well? So that
libraries should work.
Would such libraries have a lot of non-UTF-8 characters? Also, it's not
that hard to encode something as UTF-8 these days and the reduced
complexity would be a nice benefit.
--
Anne van Kesteren
http://annevankesteren.nl/
text/event-stream and text/cache-manifest. Both which simply require UTF-8.
--
Anne van Kesteren
http://annevankesteren.nl/
object or img
element. They are different.
--
Anne van Kesteren
http://annevankesteren.nl/
1001 - 1100 of 1841 matches
Mail list logo
