On 11/08/15 15:08, Majid Valipour wrote:
According to HTML5 spec persisted user state (scroll, scale, form values,
etc)
should be restored before dispatching popstate event. (See steps 9 and 14 in
history traversal algorithm[1]).
Gecko and IE follow the spec order for scroll position but in
On 02/04/15 09:36, Simon Pieters wrote:
I think we should not design a new API to test for features that should
already be testable but aren't because of browser bugs. Many in that
list are due to browser bugs. All points under HTML5 are browser bugs
AFAICT. Audio/video lists some
On 18/11/14 23:14, Sam Ruby wrote:
Note: I appear to have direct update access to urltestdata.txt, but I
would appreciate a review before I make any updates.
FYI all changes to web-platform-tests* are expected to be via GH pull
request with an associated code review, conducted by someone other
On 19/11/14 14:55, Domenic Denicola wrote:
web-platform-tests is huge. I only need a small piece. So for
now, I'm making do with a wget in my Makefile, and two patch
files which cover material that hasn't yet made it upstream.
Right, I was suggesting the other way around: hosting the
On 19/11/14 16:02, Domenic Denicola wrote:
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of
James Graham
That sounds like unnecessary complexity to me. It means that random
third party contributers need to know which repository to submit
changes to if they edit the urld
On 01/10/14 14:21, Tab Atkins Jr. wrote:
On Wed, Oct 1, 2014 at 9:18 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Oct 1, 2014 at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Wait, what? Anytime you request something, not getting it is
exceptional. Not sure how you can make an
On 24/09/14 02:54, Jonas Sicking wrote:
In the meantime, I'd like to add a property to window.navigator to
enable websites to get the same information from there as is already
available in the UA string. That would at least help with the parsing
problem.
And if means that we could more
On 22/08/14 19:29, Brian Kardell wrote:
On Fri, Aug 22, 2014 at 1:52 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Aug 22, 2014 at 7:15 PM, Brian Kardell bkard...@gmail.com wrote:
I still think that calling it bodyStream actually helps understanding
all you need and it's
On 21/08/14 18:52, Jake Archibald wrote:
take was suggested in IRC as an alternative to consume, which has
precedence http://dom.spec.whatwg.org/#dom-mutationobserver-takerecords
I'm still worried we're querySelectorAlling (creating long function names
for common actions), but I can live
On Fri, May 9, 2014 at 9:56 AM, David Young dyo...@pobox.com wrote:
The algorithms don't have to run as fast as possible, they only have to
run fast enough that the system is responsive to the user. If there is
a motion graphic, you need to run the algorithm fast enough that the
motion
On 25/11/13 10:32, Kornel Lesiński wrote:
On 25 November 2013 08:00:10 Yoav Weiss y...@yoav.ws wrote:
It contains some parts that I'm not sure have a consensus around them
yet:
* It defines picture as controlling img, where earlier on this
list we
discussed mostly the opposite (img querying
On 19/11/13 22:07, Simon Pieters wrote:
The selection algorithm would only consider source elements that are
previous siblings of the img if the parent is a picture element, and
would be called in place of the current 'process the image candidates'
in the spec (called from 'update the image
On 20/11/13 12:07, Simon Pieters wrote:
On Wed, 20 Nov 2013 12:30:18 +0100, James Graham
ja...@hoppipolla.co.uk wrote:
This seems like a nice proposal. There seems to be a minor problem
that elements created through innerHTML will have the parser created
flag set and so will not start loading
On 20/11/13 14:19, Shane Hudson wrote:
On Wed, Nov 20, 2013 at 12:32 PM, Yoav Weiss y...@yoav.ws wrote:
I think it's worth while to enable the `sizes` attribute and url/density
pairs on img as well.
It would enable authors that have just variable-width images with no
art-direction to avoid
On 19/11/13 01:55, Kornel Lesiński wrote:
On Tue, 19 Nov 2013 01:12:12 -, Tab Atkins Jr. jackalm...@gmail.com
wrote:
AFAIK it makes it as easy to implement and as safe to use as src-N.
Simon, who initially raised concerns about use of source in picture
found that solution acceptable[2].
On 18/11/13 03:25, Daniel Cheng wrote:
On Mon, Nov 18, 2013 at 12:19 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Sun, Nov 17, 2013 at 5:16 AM, Ryosuke Niwa rn...@apple.com wrote:
Without starting a debate on what semantics or aesthetics mean, syntax
is a big deal. A bad syntax can
On 18/11/13 16:36, matmarquis.com wrote:
I recall that some of the more
specific resistance was due to the complication involved in
implementing and testing existing media elements, but I can’t claim
to understand precisely what manner of browser-internal complications
`source` elements brought
On 10/10/13 18:14, David Barrett-Kahn wrote:
On GC being a source of cross-browser difficulty: I think you can fix that
by stating in the messageport spec when we guarantee to implicitly close
the connection (when its host page closes) and when we provide no
guarantees (when it loses all its
On 04/29/2013 05:26 AM, Robert O'Callahan wrote:
On Mon, Apr 29, 2013 at 3:11 PM, Glenn Maynard gl...@zewt.org wrote:
On Sun, Apr 28, 2013 at 9:11 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
It would be easy for us to add some Firefox-only or FirefoxOS-only API
here, but that seems
On 04/29/2013 11:42 AM, Robert O'Callahan wrote:
On Mon, Apr 29, 2013 at 8:56 PM, James Graham jgra...@opera.com
mailto:jgra...@opera.com wrote:
On 04/29/2013 05:26 AM, Robert O'Callahan wrote:
Also, this is a feature where it's trivial for applications to
gracefully
On 04/29/2013 03:51 PM, Boris Zbarsky wrote:
On 4/29/13 6:50 AM, James Graham wrote:
So far we have kept the model where the load event is auomatically
managed by the UA, rather than giving the developer direct control of it.
Developers already have direct control over the load event
On 03/28/2013 12:06 PM, Mohammad Al Houssami (Alumni) wrote:
Hello everyone.
I was wondering if there is some sort of tests for the Tokenizer along with the
correct output of tokens as well as a way of representing tokens.
What I have in mind is running the tokenizer on some HTML input and
On Wed, 9 Jan 2013, Boris Zbarsky wrote:
On 1/9/13 4:12 PM, Adam Barth wrote:
window.addEventListener.call(otherWindow, click, function() {});
This example does not appear to throw an exception in Chrome. It
appears to just returns undefined without doing anything (except
logging a
On Wed, 12 Dec 2012, Ian Hickson wrote:
On Wed, 12 Dec 2012, Henri Sivonen wrote:
On Sat, Dec 8, 2012 at 11:05 PM, Ian Hickson i...@hixie.ch wrote:
the order between abc and xyz is reversed in the tree.
Does anyone have any preference for how this is fixed?
Does it need to be fixed? That
On 11/08/2012 07:19 PM, Bobby Holley wrote:
The current spec for the Location object doesn't match reality. At the
moment, the spec says that Location is a per-Window object that describes
the associated Document. However, in our testing, it appears that none of
the user-agents (Gecko, WebKit,
On 11/07/2012 05:52 PM, Ojan Vafai wrote:
On Wed, Nov 7, 2012 at 6:23 AM, Simon Pieters sim...@opera.com wrote:
My impression from TPAC is that implementors are on board with the idea of
adding main to HTML, and we're left with Hixie objecting to it.
For those of use who couldn't make it,
On 10/02/2012 02:34 AM, Boris Zbarsky wrote:
On 10/1/12 6:10 PM, Ian Hickson wrote:
On Tue, 19 Jun 2012, Boris Zbarsky wrote:
On 6/19/12 1:56 PM, Charlie Reis wrote:
That's from the [if] the user agent determines that the two browsing
contexts are related enough that it is ok if they reach
On 08/29/2012 11:46 AM, Andy Davies wrote:
Anyone know when Safari and Opera are likely to support the Navigation
Timing API? http://www.w3.org/TR/navigation-timing/
In general we (Opera) don't discuss our roadmap. In particular I can't
offer you any estimates of when features will ship.
On 08/07/2012 07:51 PM, Jonas Sicking wrote:
I don't mind supporting *decoding* from basically any encoding that
Anne's spec enumerates. I don't see a downside with that since I
suspect most implementations will just call into a generic decoding
backend anyway, and so supporting the same set of
On 08/08/2012 12:27 PM, Markus Ernst wrote:
It is better because art direction and bandwidth use cases can be solved
differently in an appropriate manner:
- For the bandwidth use case, no MQ is needed, but only some information
on the sources available to let the UA decide which source to load.
On 08/02/2012 06:57 PM, Ian Hickson wrote:
But now consider the short-term cost of adding an element to the head. All
it does is make a few elements in the head leak to the body. The page
still works fine in legacy UAs (none of the elements only work in the
head).
But it will break any
There seems to be general agreement (amongst browsers, not yet the spec)
that if a document does something that causes a new load event from
within an onload handler (document.open/document.close_ the second load
event is not dispatched. This also applies to the load event on iframe
elements
On 07/30/2012 05:44 PM, Boris Zbarsky wrote:
On 7/30/12 11:10 AM, James Graham wrote:
I don't think I have a strong opinion about what should happen here, but
the Gecko behaviour could be easier to implement, and the WebKit
behaviour slightly safer (presumably the point of this anomaly
On Tue, 19 Jun 2012, Charlie Reis wrote:
On Tue, Jun 19, 2012 at 11:38 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/19/12 1:56 PM, Charlie Reis wrote:
That's from the [if] the user agent
determines that the two browsing contexts are related enough that
it is
On 06/14/2012 04:06 AM, Boris Zbarsky wrote:
On 6/13/12 7:44 PM, Michal Zalewski wrote:
The degree of separation between browsing contexts is intuitive in the
case of Chrome
Except it's not, because Chrome will sometimes put things in the same
process when they could have gone in different
On 06/12/2012 08:56 PM, Boris Zbarsky wrote:
On 6/12/12 6:30 AM, James Graham wrote:
Based on some tests ([1]-[5]), it seems that WebKit seems to cancel the
navigation in the unload handler always, Opera seems to always carry out
the navigation in the unload handler, and Gecko seems to follow
What is the expected behaviour of navigation triggered from unload
handlers? In particular, what stops such navigations from re-triggering
the unload handler, and thus starting yet another navigation?
It looks like the spec tries to make a distinction between navigations
that are cross-origin
On 05/21/2012 04:34 PM, Boris Zbarsky wrote:
On 5/21/12 10:09 AM, Mounir Lamouri wrote:
On 05/20/2012 03:04 PM, Boris Zbarsky wrote:
On 5/20/12 5:45 AM, Paul Irish wrote:
Since no one mentioned it, I just wanted to make sure this thread is
aware
of the Network Information API [1], which
On 05/21/2012 04:50 PM, Boris Zbarsky wrote:
On 5/21/12 10:42 AM, James Graham wrote:
Can you point me to the discussion of usecases that led to this design?
Me personally, no. I wasn't involved in either the spec or the Gecko
impl; I'm just reading the code
Sorry; s/you/anyone/
(I
On Mon, 21 May 2012, Mounir Lamouri wrote:
On 05/21/2012 04:34 PM, Boris Zbarsky wrote:
On 5/21/12 10:09 AM, Mounir Lamouri wrote:
On 05/20/2012 03:04 PM, Boris Zbarsky wrote:
On 5/20/12 5:45 AM, Paul Irish wrote:
Since no one mentioned it, I just wanted to make sure this thread is
aware
On Sun, 20 May 2012, Boris Zbarsky wrote:
On 5/20/12 5:45 AM, Paul Irish wrote:
Since no one mentioned it, I just wanted to make sure this thread is aware
of the Network Information API [1], which provides
navigator.connection.bandwidth
It's been recently implemented (to some degree) in both
On 05/18/2012 12:16 PM, Markus Ernst wrote:
2. Have there been thoughts on the scriptability of @srcset? While
sources can be added to resp. removed from picture easily with
standard DOM methods, it looks to me like this would require complex
string operations for @srcset.
Are there any use
On Wed, 16 May 2012, Glenn Maynard wrote:
On Wed, May 16, 2012 at 8:35 PM, Maciej Stachowiak m...@apple.com wrote:
The downside of the CG as executed is that it was much less successful
in attracting browser implementor feedback (in part because it was
apparently not advertised in places
On Wed, 16 May 2012, Matthew Wilcox wrote:
First off I know that a number of people say this is not possible. I
am not wanting to argue this because I don't have the knowledge to
argue it - but I do want to understand why, and currently I do not.
Please also remember that I can only see this
On Sun, 13 May 2012, David Goss wrote:
A common sentiment here seems to be that the two proposed responsive
image solutions solve two different use cases:
- img srcset for serving different resolutions of a content image
(for bandwidth and dpi)
- picture for serving different versions of a
On Sat, 12 May 2012, Boris Zbarsky wrote:
On 5/12/12 9:28 AM, Mathew Marquis wrote:
While that information may be available at the time the img tag is parsed,
I don’t believe it will be available at the time of prefetching
Which information?
At least in Gecko, prefetching happens when the
On 03/21/2012 04:53 PM, Joshua Bell wrote:
As for the API, how about:
enc = new Encoder(euc-kr)
string1 = enc.encode(bytes1)
string2 = enc.encode(bytes2)
string3 = enc.eof() // might return empty string if all is fine
And similarly you would have
dec = new Decoder(shift_jis)
On Fri, 16 Mar 2012, Glenn Maynard wrote:
On Fri, Mar 16, 2012 at 11:19 AM, Joshua Bell jsb...@chromium.org wrote:
And just to be clear, the use case is decoding data formats where string
fields are variable length null terminated.
A concrete example is ZIP central directories.
I think
On Fri, 16 Mar 2012, Charles Pritchard wrote:
On 3/16/2012 2:17 PM, Boris Zbarsky wrote:
On 3/16/12 5:12 PM, Joshua Bell wrote:
FYI, there was some follow up IRC conversation on this. With Typed Arrays
as currently specified - that is, that Uint16Array has platform endianness
For what it's
On 03/14/2012 12:38 AM, Tab Atkins Jr. wrote:
On Tue, Mar 13, 2012 at 4:11 PM, Glenn Maynardgl...@zewt.org wrote:
The API on that wiki page is a reasonable start. For the same reasons that
we discussed in a recent thread (
On Mon 06 Feb 2012 05:00:55 PM CET, Boris Zbarsky wrote:
On 2/6/12 10:52 AM, Matthew Wilcox wrote:
1) client asks for spdy://website.com
2) server responds with content and adds a request bandwidth device
screen size header
Again, the screen size is not invariant during the lifetime of a
On Mon, 6 Feb 2012, Boris Zbarsky wrote:
On 2/6/12 11:42 AM, James Graham wrote:
Sure. I'm not entirely sure how sympathetic I am to the need to produce
reduced-functionality pages... The examples I've encountered have mostly
been in one of three buckets:
1) Why isn't the desktop
On 12/15/2011 10:17 PM, Ilya Sherman wrote:
To that end we would like to propose adding an autocompletetype attribute
[1] to the HTML5 specification,
This name is very verbose. Isn't there something shorter — for example
fieldtype — that we could use instead?
On Thu, 8 Dec 2011, Boris Zbarsky wrote:
On 12/8/11 3:56 PM, Tab Atkins Jr. wrote:
Remember that widths refer to the
browser window, not the monitor
For the 'width' and 'height' media queries, yes.
For the 'device-width' and 'device-height' media queries, no.
It's not clear that
On Tue, 6 Dec 2011, Anne van Kesteren wrote:
Especially changing the way head is parsed is
hairy. Every new element we introduce there will cause a body to be implied
before it in down-level clients. That's very problematic.
Yes, I consider adding new elements to head to be very very bad for
On Tue, 6 Dec 2011, James Hawkins wrote:
On Tue, Dec 6, 2011 at 1:16 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Dec 6, 2011 at 1:14 PM, James Hawkins jhawk...@google.com wrote:
Originally we envisioned using a self-closing tag placed in head for
the intent tag; however, we're now
There seems to be some interest in making all concrete interfaces in the
DOM constructible (there also seems to be some interest in making
abstract interfaces constructible, but that seems insane to me and I
will speak no further of it).
This presents some special difficulties for HTML
On Mon, 7 Nov 2011, Michael A. Puls II wrote:
On Mon, 07 Nov 2011 09:00:14 -0500, James Graham jgra...@opera.com wrote:
There seems to be some interest in making all concrete interfaces in the
DOM constructible (there also seems to be some interest in making abstract
interfaces constructible
On Sat, 29 Oct 2011, Robert O'Callahan wrote:
On Wed, Oct 19, 2011 at 11:57 PM, James Graham jgra...@opera.com wrote:
On 10/19/2011 06:40 AM, Anne van Kesteren wrote:
Is that an acceptable limitation? Alternatively we could postpone the
nested fullscreen scenario for now (i.e. make
On 10/19/2011 06:40 AM, Anne van Kesteren wrote:
Is that an acceptable limitation? Alternatively we could postpone the
nested fullscreen scenario for now (i.e. make requestFullscreen fail if
already fullscreen).
I think punting on this makes sense. Pages can detect the failure and do
On 08/30/2011 10:44 AM, Anne van Kesteren wrote:
On Tue, 30 Aug 2011 10:38:19 +0200, Jonas Sicking jo...@sicking.cc wrote:
In general I think it's better to have functions that deal with child
lists on Node rather than on Element/Document/DocumentFragment.
I think it might still make sense to
On 08/22/2011 09:09 AM, Bronislav Klučka wrote:
On 21.8.2011 18:44, John Tamplin wrote:
On Sun, Aug 21, 2011 at 5:05 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
Hello,
I'm looking at current WebSocket interface specification
On 07/25/2011 05:30 AM, Bjartur Thorlacius wrote:
Are JavaScript implementors willing to reimplement window.status? There
are obvious security problems with drawing an author-provided string
where a certain URI is expected, but could window.defaultStatus not set
the name (_NET_WM_NAME or
On 06/17/2011 08:34 PM, Aryeh Gregor wrote:
On Thu, Jun 16, 2011 at 5:39 PM, Daniel Chengdch...@chromium.org wrote:
A variation of this idea has been proposed in the past but was largely seen
as undesirable--see
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026254.html. In
On 04/11/2011 03:40 PM, Tomasz Jamroszczak wrote:
I've got another proposal for making summary and details easier to
implement and - what's more important - easier to understand and thus
easier to use.
Instead of making summary inside details working as legend inside
fieldset, we can throw away
On 04/07/2011 05:55 PM, Tab Atkins Jr. wrote:
On Thu, Apr 7, 2011 at 6:09 AM, Lachlan Huntlachlan.h...@lachy.id.au wrote:
3. We'd like to get some feedback from web developers, and agreement from
other browser vendors, about exactly which glyphs are most appropriate to
use for these
On 03/30/2011 12:12 AM, Jonas Sicking wrote:
But I'm totally fine with punting on this for the future and just
disallowing redirects on an API level for now.
Yes, I think this is the right thing to do at the moment.
On 03/29/2011 03:27 PM, Wilhelm Joys Andersen wrote:
Hi,
I'm currently writing tests in preparation for Opera's implementation
of details and summary. In relation to this, I have a few questions
about issues that, as far as I can tell, are currently undefined in the
specification.
The spec
On 03/10/2011 09:20 AM, Jukka K. Korpela wrote:
My question is: Is this acceptable use of the SECTION element, even in a
flow that mostly consists of P elements, not wrapped inside SECTION
elements of their own?
If I understand you correctly, it is not the intended use of section —
i.e.
On 03/01/2011 04:50 PM, Ben Rimmington wrote:
However, some mobile platforms have a local notification service [3]
[4] [5] [6]. A new window.notify() function might be useful, so that
a background card/tab/window can display a message to the user.
See [1] for the current state-of-play in
On 02/11/2011 04:40 PM, Nicholas Zakas wrote:
We've gone back and forth around implementation specifics, and now
I'd like to get a general feeling on direction. It seems that enough
people understand why a solution like this is important, both on the
desktop and for mobile, so what are the next
On 01/13/2011 10:05 PM, Aryeh Gregor wrote:
In defining the interface for Node, some of the attributes are defined
like The parentElement attribute must return the parent node of the
context node if there is a parent and it is an Element node, or null
otherwise. while others are defined like
On 10/06/2010 04:04 AM, Philip Jägenstedt wrote:
As an aside, the idea of using an HTML parser for the cue text wasn't
very popular.
Why? Were any technical reasons given?
Finally, some things I think are broken in the current WebSRT parser:
One more from me: the spec is unusually hard
On Mon, 20 Sep 2010, Mounir Lamouri wrote:
Hi,
For a few days, Firefox's nightly had a bug related to value sanitizing
which happens to be a specification bug.
With the current specification, these two elements will not have the
same value:
input value=foo#13;bar type='hidden'
input
On 09/21/2010 10:12 AM, Boris Zbarsky wrote:
On 9/21/10 4:06 AM, James Graham wrote:
The concept of Creating an Element already exists [1] and is atomic,
Where does it say that it's atomic? I don't see that anywhere (and in
fact, the create an element code in the Gecko parser is most
Following some discussion of [1], it was pointed out to me that it is
possible to make two pages on separate subdomains communicate without
either setting their document.domain by proxing the communication
through pages that have set their document.domain. There is a demo of
this at [2].
I'm
On Sat, 1 May 2010, Nikita Popov wrote:
I do not deny, that keygen has it's use cases (the nobody was hyperbolic).
I only think, that the use cases are *very* rare. It is overkill to introduce
an HTML element therefore. It would be much more sane to provide a JS API (as
Janos proposed.) [I
On 04/29/2010 01:47 AM, Jesse McCarthy wrote:
I see why H2-H6 are retained for certain uses, but -- except in an
HGROUP -- there's no good reason to use H2-H6 when writing new code with
explicitly marked-up sections, is there?
Support for legacy clients (e.g. current AT) that has not been
On 04/28/2010 10:39 AM, Eoin Kilfeather wrote:
Well, I agree that the web author shouldn't worry about how it is
achieved, but would it not be the case that the author needs to indicate
which view is for which display? That is to say the author would be
required to flag the output for correct
On 04/28/2010 10:27 AM, David Bruant wrote:
When I started this thread, my point was to define a normalized way
(through ECMAScript binding) to add array extras to array-like objects
in the scope of HTML5 (HTMLCollection and inheriting interfaces).
I don't see any reason yet to try to find a
Keryx Web wrote:
2009-09-16 03:08, Ian Hickson skrev:
I'd like to renamearticle, if someone can come up with a better word
that means blog post, blog comment, forum post, or widget. I do think
there is an important difference between a subpart of a page that is
a potential candidate for
Quoting Simon Pieters sim...@opera.com:
On Sun, 13 Sep 2009 10:52:18 +0200, Ian Hickson i...@hixie.ch wrote:
s/2000/1999/
Since when?
Oops. I thought the 21st century started 2000, but it seems I was wrong.
Since almost everyone uses the zero-based-century convention it would
be much
Quoting Ian Hickson i...@hixie.ch:
On Tue, 25 Aug 2009, Jens Alfke wrote:
Potential result: I was having trouble logging into FooDocs.com,
so my friend
suggested I delete the cookies for that site. After that I could log in, but
now the document I was working on this morning has lost all
Adrian Sutton wrote:
On 27/08/2009 15:47, Maciej Stachowiak m...@apple.com wrote:
- Cached for convenience - discarding this will affect performance but not
functionality.
- Useful for offline use - discarding this will prevent some data from being
accessed when offline.
- Critical for offline
Robert O'Callahan wrote:
On Fri, Jul 10, 2009 at 7:36 PM, James Graham jgra...@opera.com wrote:
Is there a good reason to return the empty string rather than false? The
empty string seems very unhelpful to authors since it doesn't play nicely
with debugging prompts and is non-obvious to infer
Quoting Kartikaya Gupta lists.wha...@stakface.com:
Really, it's not that much work to make sure the API can have
bindings in other languages. As long as you can write WebIDL for it
(and provide relevant DOM feature strings wherever necessary), you
should get it for free. I would also
Kristof Zelechovski wrote:
Regarding
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.
html#weeks:
A week begins on Sunday, not on Monday.
Not according to ISO [1]
[1] http://en.wikipedia.org/wiki/ISO_week_date
Bruce D'Arcus wrote:
So exactly what is the process by which this gets resolved? Is there one?
Hixie will respond to substantive emails sent to this list at some
point. However there are some hundreds of outstanding emails (see [1])
so the responses can take a while. If you have a pressing
jgra...@opera.com wrote:
Quoting Philip Taylor excors+wha...@gmail.com:
On Sun, May 10, 2009 at 11:32 AM, Ian Hickson i...@hixie.ch wrote:
One of the more elaborate use cases I collected from the e-mails sent in
over the past few months was the following:
USE CASE: Annotate structured
Bruce Lawson wrote:
This may already be in the spec, but I couldn't find it.
I think the spec should explicity require UAs to provide a mehanism to
mute audio and to pause video, even if the controls attribute is not set.
This would not make sense in some situations e.g. for a UA designed to
Aryeh Gregor wrote:
On Tue, Apr 14, 2009 at 10:18 AM, Patrick Mueller
pmue...@muellerware.org wrote:
This is the first time I've seen the requirement for such a beast. You can
understand the desire for it, given the context, but still. Does anything
else in JavaScript make use of such a data
Diego Eis wrote:
This is not correct in HTML4?
h1Romeo and Juliet/h1
h3a tragedy in Italian style/h3
If you fed that markup into a tool that produced the outline of the
document (e.g. for a screen reader, a toc generator or an ordinary
browser navigation aid), it would look something like
Markus Ernst wrote:
So, while e-mail addresses have a strictly defined format, this does not
apply to phone numbers. Internationalisation would be necessary to
validate them, and still it would be a hard task, as complete sets of
valid formats might not be available for every country.
FWIW I
Randy Drielinger wrote:
So instead of fixing the web, we're fixing the spec (and thus
implementing fakepath in browsers)?
It's purely a question of what browser makers are prepared to implement.
The spec has to reflect a consensus amongst browser makers so that it
actualy gets implemented,
Philip Taylor wrote:
and make sure their stylesheets use the selector .time instead of
time, to guarantee everything is going to work correctly even with
unexpected input values.
So the restriction adds complexity (and bugs) to code that wants to be
good and careful and generate valid markup.
Jeremy Doig wrote:
Measuring the rate at which the playback buffer is filling/emptying gives a
fair indication of network goodput, but there does not appear to be a way to
measure just how well the client is playing the video itself. If I have a
wimpy machine behind a fat network connection, you
Since header is intended to be useful to make subheaders not appear in
the ToC, the move from
h1Foo/h1
h2Bar/h2
to
header
h1Foo/h1
h2Bar/h2
/header
shouldn't, IMHO, result in ugly borders that everyone has to nuke
(compare with img border=0).
Yeah, that's a good point. I've
Mikko Rantalainen wrote:
My second sentence was trying to argument that page author has no
business forcing the spellchecking on if the page author cannot force
the spellchecking language! Especially for a case where the page
contains a mix of multiple languages.
Not really. Consider e.g.
There seems to be some confusion about whether members of WHATWG are
just people on the mailing list or are people on the oversight
committee. Since it is almost never necessary to discuss the oversight
committee I suggest it is worth using the common term members to mean
people on the mailing
Giovanni Gentili wrote:
Why we must restrict the use case to a single vocabulary
or analyze all the possibile vocabularies?
I think it's be better to generalize the problem
and find a unique solution for human/machine.
The issue when trying to abstract problems is that you can end up doing
1 - 100 of 230 matches
Mail list logo
