Csaba Gabor wrote:
Therefore, it makes sense to float those values to the top of the
select element in a reasonable way. What's reasonable? I would like
to suggest: frequencyLimit=percent
I assume you would want this to work across different sites? If so, you
have a privacy problem. I can
[I posted this message in March; hixie asked me to go away and read the
previous discussion[0]. I have now done so. The two issues raised seemed
to be it's like Content-MD5 and people will just switch browsers.
Both are addressed in the updated spec.]
Some WHAT-WG participants may be aware of
Robert J Crisler wrote:
From my perspective, and for what it's worth, I doubt that
the ideals of the W3C as expressed in 3.12.7.1 http://3.12.7.1 would
result in a situation that would be superior to simply letting the
international standards body for audio and video codecs deal with these
Robert J Crisler wrote:
The text under 3.12.7.1 could have been written ten years ago:
It would be helpful for interoperability if all browsers could support
the same codecs. However, there are no known codecs that satisfy all the
current players: we need a codec that is known to not require
Ian Hickson wrote:
This was discussed back in 2006:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-November/thread.html#7825
As far as I can tell, the issues raised in that thread are not yet
addressed by the proposal above.
Thanks for the pointer. I don't think I was around
Some WHAT-WG participants may be aware of Link Fingerprints, which was a
way to embed the hash of a file in a link to that file, thereby ensuring
that the link user got only the exact file the link creator was
referring to.
http://www.foo.com/file.zip#!sha256:09F9...
Implementing this idea
Maciej Stachowiak wrote:
This has
been discussed to death already, but here are our basic reasons:
- MPEG-4 is an ISO open standard (although unfortunately
patent-encumbered).
No-one is telling you not to support MPEG-4.
- H.264 offers considerably better quality at the same bitrate than
Dave Singer wrote:
What is more, no-one with
deep pockets has yet used the Ogg codecs seriously, and therefore there
is no honey pot to attract the submarines (hm, do submarines like
honey?). This is not the case with H.264 and AAC, as we have made, um,
some money using them, among others.
Benjamin Hawkes-Lewis wrote:
I honestly don't think the property values are well-named. either is
confusing and vague; dont-want is a misspelled colloquialism. How
about one of the following possibilities:
captions: wanted
captions: unwanted
captions: no-preference
What happened to yes, no,
Jerason Banes wrote:
That effectively restricts the storage to a single domain and is in line
with how cookies work today.
Yes, it does. But I don't think I have been insufficiently clear.
My issue is not with the idea of DOM Storage as a whole, but with the
idea of sharing information
Ian Hickson wrote:
Yeah, this is mentioned in the security section:
http://www.whatwg.org/specs/web-apps/current-work/#security5
...along with recommended solutions to mitigate it.
All of those mitigation measures seem to be non-ideal.
Have any browser makers expressed opinions on which
Ian Hickson wrote:
Note that the HTML5 spec requires browsers not to convert text/plain to a
more dangerous type (text/plain is either treated as text/plain or
application/octet-stream according to the spec).
Excellent.
Although I also mention my story as a general counterpoint to the Well,
Ian Hickson wrote:
That's what Content-Type was. Why would Content-Type-2 be any more likely
to be respected than Content-Type?
It wasn't a serious suggestion, merely an expression of frustration.
Although Content-Type-2 might do better than Content-Type if web servers
were strongly,
Magnus Gasslander wrote:
I see you have done some work to prevent reflow loops with percentage
root heights 100%, but how does your patch handle an iframe document
that looks like this? (I can think of nastier testcases also, where
bottom is embedded further down in the document)
That
Ian Hickson wrote:
Now we could exand that
by putting, e.g., a hash into the sandbox element's attributes:
body
pHello, you said:
sandbox md5=e59ff97941044f85df5297e1c302d260Hello World/sandbox
/p
/body
...but that doesn't actually help us determine where the end should be.
Jonas Sicking wrote:
Basic idea:
The idea is basically an element like iframe but that renders the
linked page, instead of inside a square area, in flow with the main
page. This idea is really rough still, but I hope to try to implement it
in a not too distant future to solidify it a bit. One
Geoffrey Sneddon wrote:
Looking through the spec again, there is nothing about backslashes in
URI's path being treated as a forward slash, behaviour needed for
compatibility for quite a few websites.
I would be rather surprised if that were true, given that Firefox
doesn't do it and I've
Kornel Lesinski wrote:
I was just referring to the concept. Something similar could be made for
HTML.
It has been, albeit requiring script at the moment:
http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html
Gerv
Maciej Stachowiak wrote:
Maciej Stachowiak wrote:
What I mean is that unlike the case for other browser vendors, it
won't cost us anything in patent license fees.
Ah, right. So you want MPEG because it gives Apple (and Microsoft, I
guess) a financial competitive advantage over other
Maciej Stachowiak wrote:
This isn't the first time you've restated something in what seems like a
needlessly inflammatory way. Your earlier message in the thread
basically said that unless Apple implements Ogg Theora, we don't
actually have a commitment to interoperability.
Close. Unless
Maciej Stachowiak wrote:
Reasons Apple would like MPEG4 + H.264 + AAC to be the preferred codec
stack
--
- We already need to support these for video production and consumer
electronics (so no extra patent cost to us)
I don't understand this point. There's no extra patent cost in
Gervase Markham wrote:
I'll let others comment on this. But I would note that JPEG2000 is
technically superior to JPEG, but hasn't been widely implemented due to
patent issues.
Correction: in part due to patent issues.
The problem is not that it's $5 million, it's that the amount is unknown
Ian Hickson wrote:
On Thu, 29 Mar 2007, Gervase Markham wrote:
Dave Singer wrote:
No, writing it into the HTML specification is not a commercial reason.
Assuming you have commercial reasons for supporting HTML 5 (which I
suspect you do, otherwise you wouldn't be here) then having Ogg
Dave Singer wrote:
At 9:48 +0100 28/03/07, Gervase Markham wrote:
Dave Singer wrote:
Yes. I re-iterate; we have nothing aganist the Ogg or Theora
codecs; we just don't have a commercial reason to implement them,
and we'd rather not have the HTML spec. try to force the issue. It
just
Dave Singer wrote:
Yes. I re-iterate; we have nothing aganist the Ogg or Theora codecs;
we just don't have a commercial reason to implement them, and we'd
rather not have the HTML spec. try to force the issue. It just gets
ugly (like the 3G exception).
But that's circular reasoning. We
Gareth Hay wrote:
At best, we can only conclude that this is a very grey area
throughout different regions of the world, and as such, is not only
out with the scope of this list, but possibly of the spec itself.
That's a non-sequitur.
Why does it not follow?
The fact that there is legal
Simon Pieters wrote:
Browsers are allowed to provide full screen, however there's no API for
it. Entering fullscreen should only be under the control of the user,
otherwise the author could hijack the user's screen and no way to get
out of it (e.g. as soon as the user tries to exit fullscreen,
Robert Sayre wrote:
It seems a few people believe this list is an appropriate venue for
discussion of legal issues like trademarks and patents. Well, I don't
know of any lawyers that participate here, but perhaps a more focused
list could attract some legal expertise. Here's whatwg-legal:
Ian Hickson wrote:
Biting off more
than we can chew is a common mistake in Web specification development.
lynx -dump -nolist http://www.whatwg.org/specs/web-apps/current-work/ |
wc --words
143147
lynx -dump -nolist http://www.whatwg.org/specs/web-forms/current-work/ |
wc --words
40523
Martin Atkins wrote:
Perhaps you and I have different ideas about what is meant by full
screen, but why would a page need to hide anything when the video is
full screen? The page itself won't be visible, because the video will be
taking up the entire screen!
My thought was that it would be
liorean wrote:
I'm sure Gervase just doesn't use a Mac, so he hasn't felt how lacking
the support for full screen mode is in Mac browsers.
It's true that I don't use a Mac.
However, I think it's a reasonable position that the idea of going to
full screen is a user agent thing (no matter what
Gareth Hay wrote:
I really don't understand this attitude, it was a very clear point,
pressing F11 in a *large* number of browsers does not provide a
'fullscreen' mode. I mean, how many mobile devices even have an F11?
Er, F11 was an example (that's what it is in Firefox).
I could have said
Nicholas Shanks wrote:
What is chrome ?
I mean, I know what it really is, but that seems to have nothing to do
with computers or web browsers (except for the chromium-coloured iPod
phone).
Sorry. It means things like toolbars, menu bars, status bars and other
non-content-area UI.
Gerv
Gareth Hay wrote:
I think it should be like this, as you are telling the video element
to go fullscreen and *not* the page.
That's my opinion.
I guess that's the heart of it. My view is the opposite. I don't think
video should be special in this regard.
If you want to see an embedded image
Colin Lieberman wrote:
Drop tabindex altogether. It's just not useful.
Before doing that, it might make sense to consult the accessibility
teams of the UA vendors. In Mozilla's case, that's Aaron Leventhal. I
believe that there have been recent changes to this property to better
allow
Bjoern Hoehrmann wrote:
In case of video, there is no need to implement anything using style
sheets, behaviors, or scripting, you can use it directly, right now,
it's easy as pie,
html xmlns:t=urn:schemas-microsoft-com:time
?import namespace=t implementation=#default#time2
body
Behnam ZWNJ Esfahbod wrote:
The second one is to get the web server decide which image file is
better. An Apache httpd module can select the best response for a
request for image the-company-logo if it knows which size is needed,
and what mime-types are acceptable.
My idea is to add a field to
Maciej Stachowiak wrote:
Restricting the types of content that the video element can handle
will stifle future innovation, and will likely be ignored by browser
vendors who decide they would like to support new formats. It would also
be unprecedented relative to type restrictions on other HTML
James Graham wrote:
Widespread deployment (despite not working in many situations Flash has
close enough to 100% of the desktop market for content producers to
ignore the rest). In practice this means at least two things. Firstly,
browser manufacturers without significant in-house video
Shadow2531 wrote:
With that said, if a browser can make its video element support as
many formats as it wants (which I believe most people want), I do
believe that its essential that
there be a base format that must (or strongly should) be supported.
That base format might be theora or something
Nicholas Shanks wrote:
It may be a good idea to specify an either-or-both policy and include a
second video format, allowing vendors a little freedom as to which to
implement.
Either? But if one major browser implements one, and another
implements the other, then you end up in the situation
Elliotte Harold wrote:
I'm just not sure that I see a strong enough use case here to justify
the introduction of another element most browsers will not support for
years if ever.
I think there's a strong driver for uptake. As I understand it, all
these video-sharing sites are paying
Spartanicus wrote:
Another current common frustration amongst authors is how to get file
based media files to play before they've been fully downloaded. This is
currently achieved by using text based redirector files containing the
url to the actual media file, but these redirector formats have
Anne van Kesteren wrote:
Opera has some internal expiremental builds with an implementation of a
video element. The element exposes a simple API (for the moment) much
like the Audio() object:
play()
pause()
stop()
Were any sort of fast-forward or rewind functions considered?
Gerv
Mihai Sucan wrote:
No. I really meant commas, not semicolons. This is because I use commas
to separate multiple email addresses in the To: field in Opera M2. I'm
quite certain it also works in Outlook,
Incredibly (at least last time I looked) it only works when you check a
particular
Kornel Lesinski wrote:
But what about browsers that don't have access to GPS device nor
geocoding service? These browsers could still return city and postcode
information provided by the user and that could be enough for many
applications (nearest branch locators, etc.).
Every browser should
Mihai Sucan wrote:
Not if it does the simple, smart thing that Thunderbird does - if you
paste in a comma-separated list of addresses, turn it into a list of
single entries.
You've now added even more work: parse the list of emails, and add the
new inputs for each email address.
You
Kornel Lesinski wrote:
For some applications location given in format other than lat/long may
be more useful and less privacy-sensitive.
The privacy-sensitivity problem can be easily dealt with by reducing the
accuracy of the lat/long given.
For example name of the city might be good enough
Adrian Sutton wrote:
Did you notice in your development of an WYSIWYG HTML editor things
from the specification that
- were very difficult to implement?
- were missing in the HTML language itself to make it easier to
control the editing?
There are a couple of things to note
Ryan Sarver wrote:
The biggest problem with this implementation is that it requires an
additional service on top of standard GPS.
I wasn't envisaging any geocoding services. In my example, the address
would be one the user had entered, and (assuming the machine has GPS at
all) the browser
Michel Fortin wrote:
About that, I would like to suggest that the current text be changed to
reserve class names starting with a dash - for private use. That way
that we would have a pool of class names which are guarantied to not be
taken over later when new predefined class names are added.
Anne van Kesteren wrote:
On Wed, 21 Feb 2007 10:41:12 +0100, Gervase Markham [EMAIL PROTECTED]
wrote:
Surely it would make much more sense to have all the predefined class
names start with a dash? After all, XHTML5 is not yet standardised,
whereas people have been using all sorts of random
Anne van Kesteren wrote:
The analogy I tried to make (apparently it failed) is that design
decisions for C/C++ are not necessarily good for HTML.
Right. But they aren't necessarily bad either. What is wrong with
picking a clean rather than a dirty namespace for predefined class
names? Or
Michel Fortin wrote:
I'm beginning to think that the link fingerprint method is best
solution because the hash is more portable as part of the URL. I could
for instance copy a fingerprinted URL right into this email:
http://example.com/file#!md5!b3187253c1667fac7d20bb762ad53967
Indeed,
Ian Hickson wrote:
If the idea is that UAs that implement this would stop you from using the
file if the checksum didn't match, then this would just cause users to use
browsers _without_ this feature to download files, since those browsers
wouldn't complain about data corruption. It works when
XcomCoolDude wrote:
How about a hash attribute for all elements that link to external files
(a, img, etc.)?
It would allow you to pass an MD5, SHA-1, SHA-256, or other hash to a
user-agent for automatic comparison with the linked file.
A related proposal is:
Ian Hickson wrote:
The file you have downloaded has been corrupted or tampered with.
It works when I use IE but when I use Camari, it says that the file has
been corrupted. Oh man, I'm not using Camari then! I don't need my music
to get corrupted!
Yes, yes. I don't think it's impossible to
dolphinling wrote:
What if the canvas and span are surrounded by something with
font-weight:bold? Will the text in the canvas be drawn bold, too?
It's the responsibility of the page designer to make sure the text they
are measuring is styled the same as the text they want the metrics of.
Stefan Haustein wrote:
I think it is very important to be able to determine the rendered size
of the text.
Can't you determine the size from the accessible version you are
doubtless creating inside the canvas element? ;-)
(This assumes that if you draw a string in 8px Monaco on a canvas,
David Hyatt wrote:
and then the API would be something like:
drawText(y-coord of baseline, barchart, myText)
I like this idea :-)
At the risk of overcomplicating, vertical text is a common requirement
for graphs and charts. If this is simpler to implement than the
arbitrary text rotation
Alfonso Baqueiro wrote:
The canvas component is very promising, but the lack of drawString
method could be a great error for its success, this lack is a huge
limitation, how could you resolve this problem?
I've suggested this in the past as a solution to this problem: why not
have a
Alex Vincent wrote:
In the past, user agents have allowed file upload controls to
reference files not local to the computer in question. For validity
purposes, I wonder if this should still be allowed under Web Forms
2.0.
I don't think you could forbid it; this is a feature that people use,
Henri Sivonen wrote:
Could you elaborate on the use cases? Are there a lot of use cases on
the Web now that force site author to hack awkward JavaScript widgets
themselves? Can't they continue using those hacks for uses cases that
are not mainstream like airline reservations?
Could we perhaps
Henri Sivonen wrote:
Sounds like architecture astronautics to me.
It's a fair cop, guv.
That is, you are probably right :-)
Gerv
Alex Vincent wrote:
For anyone interested in seeing WF2 implemented in mozilla.org code,
I invite you to read and comment on
http://wiki.mozilla.org/DOM:Web_Forms_2.0 . Please bear in mind this
is intended as an internal design document, and this is very much a
first draft - so it will
Ian Hickson wrote:
3. Otherwise, if the user has disabled the checking for this text,
then the checking is disabled.
4. Otherwise, if the user has forced the checking for this text to
always be enabled, then the checking is enabled.
5. Otherwise, if the element with which the
Alexey Feldgendler wrote:
Check spelling:
( ) Never
(*) As the page author suggests
( ) Always
But that really brings out the foolishness of the idea. I can imagine a
user looking at that option and thinking Duh - how on earth is the page
author ever going to know when and how I want spelling
James Graham wrote:
The only sensible use case that has been suggested so far is for online
email apps which allow 1 email addresses in an input type=text -
in this case none of the text will be recognized by the spellchecker vs.
an input type=text which contains an email subject line, which
The Web Applications 1.0 spec says:
5.7.3. The StorageItem interface
Items in Storage objects are represented by objects implementing the
StorageItem interface.
interface StorageItem {
attribute boolean secure;
attribute DOMString value;
};
I would like to
Douglas Crockford wrote:
The JSONRequest does only one thing:
snip
Are you planning to take the excellent advice from I forget who to
change the name? The name XmlHttpRequest sucks because it doesn't
necessarily return XML, and it doesn't have to be over HTTP. Let's not
tie the name of a new
Hallvord R M Steen wrote:
You are right, if no variables are created one can't see the data by
loading it in a SCRIPT tag. Are you aware of intranets/CMSes that use
this as a security mechanism?
That's not actually right. I'm pretty sure this came across a public
security list, so...
You can
Darin Fisher wrote:
Keep in mind that there is also the problem that the POST request may
have undesirable side-effects. The web app probably needs a request
header from the browser to tell it what domain is sending it data. The
Referer header is not sufficient since the browser will not
Simon Pieters wrote:
Browsers could mark all errors as red in view source. In Firefox you can
select a piece of text and view selection source, which will bring up
the serialized DOM.
They could (at least, as far as I understand the issue), for XHTML at
least (not HTML5), if they wanted to
Shadow2531 wrote:
I just threw them together as a proof of concept, but I have no doubt
that the class attribute value should be a space separated list of
classnames and the getElementByClassName function should split up the
class attribute value into an array and then search for the class
Shadow2531 wrote:
O.K. Then, it should be getElementByClassName*s*() where you have
have 1 or more classname arguments. If you pass more than 1 class
name, both class names have to be present in the classname attribute
for the element to match.
This seems like a sensible change. Call it
Jim Ley wrote:
Rather than talk about technical details, can be talk about the actual
use cases please, working groups keep on creating things which need
implementing, testing etc. without once giving the use case. This
thread is now 21 messages old and there's not one use case which is
ROBO Design wrote:
I believe there's some disagreement on what is this function supposed to
do.
Well, not according to the current spec, which says:
1. Should it return *all* elements which have *all* the class names wanted?
this one. Of course, you may disagree with the spec.
4. Should
Jim Ley wrote:
I know nothing of this attaching events to a class name of which you
speak. Can you give me a reference to a document or proposal describing it?
It's the one use case described in this mailing list,
See e.g.
Jim Ley wrote:
Yes, but they're all using it to attach events to every one of the
class, which is why you have to look at use cases, the reason they're
doing it is not because getElementsByClassName is missing, but because
addEventListenerToClass or -moz-binding etc. are missing.
But why
Alexey Feldgendler wrote:
1. create. The options aren't very useful because one can add nodes by
cloning, and you can't control what nodes are cloned. The definitions
should rather be changed to insertion of nodes into the document. So,
the script is free to create or clone elements, but they
Ian Hickson wrote:
My first impression is that it is far too complex and over-engineered.
OK... What do you think the requirements are for a solution to this
problem? I tried to make my types of restrictions match up with common
use cases, but I may well have picked the wrong ones.
The problem
81 matches
Mail list logo
